Re: Rename `eww' to `web'

["Stephen J. Turnbull" <stephen@xemacs.org>]

 > On 03 Jul 2013, at 18:43, Ted Zlatanov <tzz@lifelogs.com> wrote:

 > > I think it's pretty easy to tell a URL (we already do that in many
 > > packages), and the user can always use `find-file-literally'.

@tzz: That's hardly likely to make the user happy.  f-f-l delivers the
bytes found on disk, completely uninterpreted.

chad writes:

 > Unencoded full URL's cannot be valid filenames under the vast

"Valid *canonical* filenames".  In most cases the "//" marking the
authority will be interpreted as a single path separator.

 > majority of filesystems, including GNU/Linux and macosx. I think
 > they might theoretically be valid in w32 systems like ntfs, but

I don't think so; the "//" prefix for a share can't be preceded by a
drive letter.

 > many (most?) of those systems already allow the user to enter URLs
 > where filenames are requested, so it doesn't seem likely to be a
 > problem there, either.  Anyone know for sure?

Where's the system issue?  Inside Emacs, URL-encode whatever you're
given and prefix "file:///" to it.  If that exists, ask the user if
the local file is what they want.  Otherwise, try the URL-encoded form
literally.  This try-and-prompt behavior should be optional, as I
suspect it's rarely applicable and even more rarely wanted.

The issue here is going to be edge cases involving `default-directory',
which should probably be renamed `default-base-url'.

 > It seems like we just recently built this dispatcher functionality
 > for sending email from emacs, didn't we?

No, that's been around for decade, at least.

 > If not, perhaps it's as simple as a set of standardized aliases for
 > common functionality, with the defaults set to a choose-from-a-list
 > function?

It's not that simple.  The base case is, but users typically want to
be able to tune their preferred implementation.  For common options,
there should be standard custom variables in Emacs, but people should
also be able to drill down to the implementation and use its option
names.  Building a generic way to handle all this functionality for
different applications is not going to be trivial.

For the moment I think building dispatchers on a case-by-case basis
isn't so hard, and eventually somebody will get the itch.