I've trimmed a couple of people I _know_ are on the xemacs-beta list.
No point in duplications.
>>>> "Kai" == Kai Grossjohann
Kai> Why do we have to use URL syntax if it is inconvenient?
Kai> Wouldn't "/ftp:user＠host:/path/to/file" work, too?
Specifically, it doesn't generalize very well to relative URLs with
non-default port numbers.
Various user interfaces will continue to be supported for backward
compatibility and convenience (although I think that the URL syntax is
sufficiently clumsy but common that somebody will soon write an
optimized completer or other convenient interface for it; for all I
know it might be the EFS syntax). I don't think anybody thinks
is a remotely acceptable substitute for "~/the-file-I-want". However,
as an internal interface (what Nelson is advocating), it has the great
advantage of being uniform. Other tools support it, users are
becoming familiar with it. As the lowest-common-denominator
for-sure-this-will-work syntax, I think those are very important.
Four things that haven't been mentioned yet (I think, I expired the
beginning of the thread):
o A user can check if the Not-Invented-Here protocol is supported
by his Emacs simply by typing in
What's the extended EFS representation of that URL?
o Implementers of new protocols with external programs that
support URLs just
(cons '("nihp" . "nihp-get")
Of course it won't be _that_ easy, but it will help.
o Nowadays lots of my fetches are "point-and-click-on-URL" in a
buffer somewhere. No munge-to-fit-Emacs-internal-representation
is necessary to implement that in a new application, nor any
separate quickly outdated URL-parsing library.
o When the URL syntax gets amended, we know how to revise the
Emacs internal representation. ("It won't," you say?)
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
What are those two straight lines for? "Free software rules."