[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bug-reference.el: Allow custom handlers for opening URLs
From: |
Tassilo Horn |
Subject: |
Re: bug-reference.el: Allow custom handlers for opening URLs |
Date: |
Tue, 05 May 2020 09:06:34 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Stefan Monnier <address@hidden> writes:
>> So you mean we need to have a `browse-url-handlers' defcustom and a
>> `browse-url-handlers-default' defvar? Maybe you are right. On the
>> other hand, we haven't something like that for similar candidates
>> like `auto-mode-alist', too. There, we use the "if you don't like
>> it, remove it yourself" approach.
>
> Good point. In that case the solution is to forego the use of
> `defcustom`. I'm fine with that.
>
> After all, the autoloads are supposed to run before the .emacs, so the
> user can `add-to-list` just fine to override whatever was added by
> autoloads.
I don't quite understand. Let's assume debbugs would add a handler and
I wouldn't like to use it. Isn't it correct that it would add it as
soon as it is loaded which means either where I have a (require
'debbugs) in my .emacs or call one of its autoloaded functions?
If that was true, we could document that packages should append their
entries which would give the users a chance to override those entries
because theirs would come earlier in the alist. OTOH, when customizing
after the package has already been loaded and the entry is there, we
would have an undefined handler forever after the package was
uninstalled...
Or do you say it has an autoloaded (add-to-list ...) form?
Well, after some thinking I lean to the defvar + defcustom approach...
>> Symbol's value as variable is void: browse-url-mailto-function
>> make[2]: *** [Makefile:584: emacs.pdmp] Error 255
>> make[2]: Leaving directory '/home/horn/Repos/el/emacs/src'
>> make[1]: *** [Makefile:424: src] Error 2
>> make[1]: Leaving directory '/home/horn/Repos/el/emacs'
>> make: *** [Makefile:1119: bootstrap] Error 2
>> --8<---------------cut here---------------end--------------->8---
>>
>> When removing the autoload cookie, it builds fine. Why is that?
>> `browse-url-mailto-function' and `browse-url-man-function' are defined
>> way before `browse-url-handlers'.
>
> But they're not autoloaded, so in the loaddefs.el file, you have
> a reference to it without the preceding definition.
I'm pretty sure I've tried adding autoload cookies to them as well and
got the same error.
> Maybe the better option is to define (and use) a new function
> `browse-url-mailto` (or some other name) which just funcalls
> `browse-url-mailto-function`.
Sounds good. Will do.
Bye,
Tassilo
- bug-reference.el: Allow custom handlers for opening URLs, Tassilo Horn, 2020/05/03
- Re: bug-reference.el: Allow custom handlers for opening URLs, Stefan Monnier, 2020/05/03
- Re: bug-reference.el: Allow custom handlers for opening URLs, Tassilo Horn, 2020/05/03
- Re: bug-reference.el: Allow custom handlers for opening URLs, Stefan Monnier, 2020/05/03
- Re: bug-reference.el: Allow custom handlers for opening URLs, Tassilo Horn, 2020/05/04
- Re: bug-reference.el: Allow custom handlers for opening URLs, Stefan Monnier, 2020/05/04
- Re: bug-reference.el: Allow custom handlers for opening URLs, Tassilo Horn, 2020/05/04
- Re: bug-reference.el: Allow custom handlers for opening URLs, Stefan Monnier, 2020/05/04
- Re: bug-reference.el: Allow custom handlers for opening URLs,
Tassilo Horn <=
- Re: bug-reference.el: Allow custom handlers for opening URLs, Stefan Monnier, 2020/05/05
- Re: bug-reference.el: Allow custom handlers for opening URLs, Tassilo Horn, 2020/05/05
- Re: bug-reference.el: Allow custom handlers for opening URLs, Stefan Monnier, 2020/05/05
- browse-url.el: Custom handlers for certain URLs (was: bug-reference.el: Allow custom handlers for opening URLs), Tassilo Horn, 2020/05/05
- Re: bug-reference.el: Allow custom handlers for opening URLs, Yuri Khan, 2020/05/04
Re: bug-reference.el: Allow custom handlers for opening URLs, Arash Esbati, 2020/05/05