unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Ivan Shmakov <ivan@siamics.net>
Cc: 19556@debbugs.gnu.org
Subject: bug#19556: eww: make URI rewriting fully customizable
Date: Sat, 10 Jan 2015 19:37:22 +0200	[thread overview]
Message-ID: <83r3v25ygd.fsf@gnu.org> (raw)
In-Reply-To: <8761ce1rit.fsf@violet.siamics.net>

> 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	other threads:[~2015-01-10 17:37 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-10 13:17 bug#19556: eww: make URI rewriting fully customizable Ivan Shmakov
2015-01-10 14:19 ` Eli Zaretskii
2015-01-10 14:40   ` Ivan Shmakov
2015-01-10 16:01     ` Eli Zaretskii
2015-01-10 17:20       ` Ivan Shmakov
2015-01-10 17:37         ` Eli Zaretskii [this message]
2015-01-10 18:05           ` Ivan Shmakov
2015-01-10 14:29 ` Lars Magne Ingebrigtsen
2015-01-10 14:44   ` Ivan Shmakov
2015-01-10 14:58     ` Lars Magne Ingebrigtsen
2015-01-10 15:59       ` Ivan Shmakov
2015-01-10 16:08         ` Lars Magne Ingebrigtsen
2015-01-10 16:22           ` Lars Magne Ingebrigtsen
2015-01-10 18:24             ` Ivan Shmakov
2015-12-25  7:03   ` Lars Ingebrigtsen
2015-12-26  9:30     ` Ivan Shmakov
2015-01-10 15:02 ` Lars Magne Ingebrigtsen
2015-01-10 18:11   ` Ivan Shmakov
2015-01-11 14:58     ` Lars Magne Ingebrigtsen
2015-01-11 15:06       ` Lars Magne Ingebrigtsen
2015-01-11 18:22         ` Ivan Shmakov
2015-01-11 20:03           ` Eli Zaretskii
2015-01-11 20:17             ` Ivan Shmakov
2015-01-11 20:40               ` Eli Zaretskii
2015-01-11 21:46                 ` Lars Magne Ingebrigtsen
2015-01-11  1:59 ` Stefan Monnier
2015-01-11  6:25   ` Ivan Shmakov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83r3v25ygd.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=19556@debbugs.gnu.org \
    --cc=ivan@siamics.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).