bug#19556: eww: make URI rewriting fully customizable

[Ivan Shmakov]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>>> From: Ivan Shmakov  Date: Sat, 10 Jan 2015 14:40:57 +0000
>>>>> Eli Zaretskii <eliz@gnu.org> writes:

 >>> Why put the "standard" rules into the defcustom?

 >> So to make the tricks played by EWW on unsuspecting URIs more
 >> obvious to the user.

 > How does that make it more obvious?

        By showing them in the “Customize Group” buffer?

 >>> 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

 > None of these replace the default behavior of their hookee functions.
 > They _add_ something to it.  The default behavior is not in the hook,
 > it's in the code that calls the hook.

        We seem to be disagreeing on the terms.  To me, the way
        unmodified Emacs behaves when started with ‘-Q’ is the default.

        To get different (custom) behavior, the user may add elements to
        hooks, lists of other kinds (including associative), keymaps, –
        or /remove/ from them; load or /unload/ packages; add, redefine
        or advise commands or functions; etc.

        For instance, electric-indent-mode is the default.  Using
        (electric-indent-mode -1) in one’s ~/.emacs is a customization.
        Calling log-edit-insert-message-template as part of
        log-edit-hook is the default.  Setting log-edit-hook to nil is a
        (perfectly valid) customization.  Providing a rich set of
        filename suffix to Emacs major mode pairs in auto-mode-alist is
        the default.  Tailoring that alist according to the modes one
        does and does not use is customization.  Etc.

        I see no reason for EWW to be different in that its default
        behavior cannot be customized – whether that’d mean adding
        elements to some list, removing others from there, or doing
        something else.

 > And anyway, I said "normally", so a couple of examples to the
 > contrary doesn't yet invalidate what I said.

        Should I look for a couple more examples on top of that couple
        within the Emacs source tree just for the sake of this argument?

 >> 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.

 > It sounds like we have some deep disagreement about what the hooks
 > are for.  You want a hook to _remove_ some behaviors, but that's not
 > what hooks are for.

        Except for those which are.

        Besides, what’d be the point of run-hook-with-args-until-success
        if not to allow the user to prepend his or her own function to
        override the behavior of the (default) functions coming later in
        that same hook?

 >>> 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.

 > Which is clearly wrong with some URIs.

        I see no way it could be wrong for /URIs proper./  Yes, that’d
        mean that M-x eww RET mary had a little lamb RET fails.  But so
        does Lynx, Wget and Curl, url-retrieve, C-x C-f, and what not.

        On the contrary, I find the eagerness of EWW to send what could
        easily be a mistyped URI to a third party somewhat disturbing.

        Customizing eww-search-prefix to refer to some non-existing
        service (or just setting it to a non-nil symbol) may be a decent
        work-around for the issue, but it also disables eww-search-words
        as an unfortunate side-effect.

 > Please let's not go that way.

        Sure.  Let’s instead make C-x C-f go DDG for completion and
        provide no option for the user to opt-out.

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A