bug#19556: eww: make URI rewriting fully customizable

[Ivan Shmakov <ivan@siamics.net>]

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