bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#19556: eww: make URI rewriting fully customizable


From: Eli Zaretskii
Subject: bug#19556: eww: make URI rewriting fully customizable
Date: Sat, 10 Jan 2015 19:37:22 +0200

> From: Ivan Shmakov <ivan@siamics.net>
> Date: Sat, 10 Jan 2015 17:20:42 +0000
> 
> >>>>> 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 buffer is too large to make anything obvious.

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

We are not talking about the Emacs behavior, we are talking about the
behavior of a certain function.  Things that are central to that
function's job are that function's default behavior.  find-file's job
is to find and visit files, and that functionality should not be in a
hook, available for removal by users.

Similarly, eww's job is to find and visit a URL, which includes
processing file:// URLs, and that functionality should always be in
the function, not in any hook.

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

It makes very little sense to me to customize out something that is an
inherent part of a function's job.

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

If you wish.  But I'd rather you invested your time and talent where
it could benefit Emacs more than by looking for those examples.

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

Hooks do not override behavior.  They let the user run some code
_in_addition_ to the normal behavior.  It's therefore no accident that
a hook is called near the end of the function which provides it, after

To _override_ behavior, we provide function variables that get used
_instead_ of the default.  Like indent-region-function, for example.
So in that case, you'd need to make 'eww' call the value of
eww-mangle-uri-function, whose default value is a function that does
what the current code does inside eww itself, and then users could
override that by providing their own URI-mangling function.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]