[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#19556: eww: make URI rewriting fully customizable
From: |
Ivan Shmakov |
Subject: |
bug#19556: eww: make URI rewriting fully customizable |
Date: |
Sat, 10 Jan 2015 14:40:57 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) |
>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>>> From: Ivan Shmakov Date: Sat, 10 Jan 2015 13:17:55 +0000
[…]
> Why put the "standard" rules into the defcustom?
So to make the tricks played by EWW on unsuspecting URIs more
obvious to the user. Cf. eww-suggest-uris, BTW.
> why not leave them in place as "plan B", and leave the hook for
> customizations only?
It’s certainly a possibility; frankly, I have no strong
preference for doing it either way.
> That's what hooks are normally for -- _modifying_ the default
> behavior, not supplanting it.
Are they? For instance, when run with -Q, my find-file-hooks
includes ange-ftp-set-buffer-mode, epa-file-find-file-hook,
vc-find-file-hook, – which I’d consider pretty much a
prerequisite for the “default” behavior.
With these functions being explicitly listed, however, I could
easily drop everything but vc-find-file-hook off the list to get
rid of the functionality that tends to get in my way.
> E. g., with your suggestion, what happens if someone customizes the
> value to nil?
That’s simple: M-x eww will assume that the URIs it’s given
never need any special treatment. One consequence I’ve already
mentioned:
>> FWIW, removing eww-search-words from the hook allows one to type
>> something like https://en.wikipedia.org/wiki/Free software RET (note
>> the blank) at the prompt and be with that.
Removing just eww-search-words leads to more or less the same
effect. Dropping eww-uri-not-supported resolves #17959. And
so on.
--
FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A
bug#19556: eww: make URI rewriting fully customizable, Lars Magne Ingebrigtsen, 2015/01/10