Fix autoloaded register-definition-prefixes

[josephmturner]

Currently, autoload generation with shorthands results in:

(register-definition-prefixes "breadcrumb" '("bc-"))

The autoload prefix should be "breadcrumb-" so that breadcrumb.el will be autoloaded when users type in

M-x describe-function RET breadcrumb-

See (info "(elisp)Autoload by Prefix") for more information.

Related issues:

• Propagating the shorthand to the autoloads #3
• https://yhetil.org/emacs-bugs/[email protected]/

[tarsius]

As a side-note, if you place the local variables below it, then the statement in this line is no longer accurate. 😬

[joaotavora]

Feel free to fix. Always found that "ends here" kinda silly anyway. What's the point?

[josephmturner]

Feel free to fix. Always found that "ends here" kinda silly anyway. What's the point?

https://www.gnu.org/software/emacs/manual/html_node/elisp/Library-Headers.html says "Its purpose is to enable people to detect truncated versions of the file from the lack of a footer line."

[josephmturner]

I've gone ahead and fixed it.

[joaotavora]

I've gone ahead and fixed it.

But not in this PR, please. SOrry I should have been clearer.

[joaotavora]

"Its purpose is to enable people to detect truncated versions of the file from the lack of a footer line."

By the way, "enables people". Particular kinds of people who trade in truncated files coming up with genius ideas that no other language have.

[joaotavora]

Just so I understand this fix, is this enough to prevent (register-definition-prefixes "breadcrumb" '("bc-")) from happening?

[joaotavora]

Sorry, I closed this from a commit message, but I meant to close #23 instead. So reopening

[tarsius]

Just so I understand this fix, is this enough to prevent (register-definition-prefixes "breadcrumb" '("bc-")) from happening?

No, it only ensures that the correct prefix is also registered.

[joaotavora]

And are there any adverse effects (that you know of) to having two prefixes registered for a given package?

[tarsius]

I'm not aware of any, but I know very little about all this, so that doesn't mean much.

[joaotavora]

I think

;; Local Variables:
;; autoload-compute-prefixes: nil
;; End:

Should be added to this PR.

Also please make the commit message in the GNU changelog format (like other commit messages in this repo).

[josephmturner]

And are there any adverse effects (that you know of) to having two prefixes registered for a given package?

I don't know, but I agree with you that bc- should not be a registered prefix.

;; Local Variables:
;; autoload-compute-prefixes: nil
;; End:

I tried this, but as you pointed out in your email to the mailing list, autoload-compute-prefixes is not a variable, let alone a safe variable. Do you still want to add a local variable declaration even though Emacs will prompt about variables that may not be safe?

Also please make the commit message in the GNU changelog format (like other commit messages in this repo).

Done.

[joaotavora]

Do you still want to add a local variable declaration even though Emacs will prompt about variables that may not be safe?

I want this pull request fix register-definition-prefixes (whatever their point is) so that breadcrumb- is registered, and bc- is NOT registered.

[josephmturner]

I want this pull request fix register-definition-prefixes (whatever their point is) so that breadcrumb- is registered, and bc- is NOT registered.

Done! Emacs master branch master now autoloads (put 'autoload-compute-prefixes 'safe-local-variable), so my previous concern is resolved!

Thanks!

[joaotavora]

OK merged. And thanks. I'd rather the "ends here" thing hadn't been touched here, but no biggie anyway, I'll just remove that silly trailer soon anyway.

[tarsius]

OK merged. And thanks. I'd rather the "ends here" thing hadn't been touched here, but no biggie anyway, I'll just remove that silly trailer soon anyway.

I agree that it is silly in the age of version-control and would like to remove it from my libraries. But it's still the convention and if you go against it, linters will tell you about it.

I have learned to live with it and it is certainly not the hill I want to die on, but if you feel more strongly about it, I would encourage you to try to get this convention removed.

Or maybe just relaxed to IFF the file does not end with (provide 'the-feature), then it must end with ;;; the-feature.el ends here, or (at your option) ;; the-feature.el ends here (to make it less annoying for people using outline-minor-mode).

[josephmturner]

Or maybe just relaxed to IFF the file does not end with (provide 'the-feature), then it must end with ;;; the-feature.el ends here, or (at your option) ;; the-feature.el ends here (to make it less annoying for people using outline-minor-mode).

In that case, in breadcrumb.el, (provide 'breadcrumb) would need to go after:

;;;###autoload (register-definition-prefixes "breadcrumb" '("breadcrumb-"))

;; Local Variables:
;; read-symbol-shorthands: (("bc-" . "breadcrumb-"))
;; autoload-compute-prefixes: nil
;; End:

[joaotavora]

But it's still the convention and if you go against it, linters will tell you about it.

So what?

I would encourage you to try to get this convention removed.

Why me? you can try too! :-)

All these text-based tools are brittle and they don't cooperate. For example, the real reason that the "ends here" thing happened before the actual end is because add-file-local-variable, which is what I use to add file-local variables, doesn't know about it.