GNU bug report logs - #7159
24.0.50; (1) `file-name-(non)directory': bad return values, (2) `directory-sep-char'

Previous Next

Full log

Message #20 received at 7159-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 7159-done <at> debbugs.gnu.org
Subject: Re: bug#7159: 24.0.50;
	(1) `file-name-(non)directory': bad return values,
	(2)	`directory-sep-char'
Date: Tue, 05 Oct 2010 03:09:30 -0400

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <7159-done <at> debbugs.gnu.org>
> Date: Mon, 4 Oct 2010 22:06:26 -0700
> 
> No one said that anyone is likely to pass a regexp in place of a file name.
> Sorry if my example misled you.

What other real-life use-cases exist that require such a
functionality?

> You say Emacs must recognize ?\ today at least, because mumblemumble things are
> complicated.  I say that even if that is so (and I believe you that it is),
> that's not the same as claiming that that _should_ be so.  This is a bug, a poor
> design/implementation decision, that we can hope to fix at some point.

It isn't a bug, it's a feature that is necessary on DOS and Windows.
"Fixing" that would introduce bugs, some subtle, others glaring.  So
these primitives, which are widely used in Emacs's own Lisp sources,
must retain their equal handling of both flavors of slashes in file
names.  If you still disagree, let's leave it at that, because we will
never agree.

> 
> > what's the filename part of "/foo\\(/a?\\)bar"?
> >   (file-name-nondirectory "/foo\\(/a?\\)bar") => "a?\\)bar"
> > Or how about this:
> >   (file-name-nondirectory "/foo[^/]*") => "]*"
> 
> The answer, for Emacs, should simply be to interpret the chars other than ?/ as
> file-name chars, not as directory separators.  It has nothing to do with
> interpreting regexp syntax.  It has only to do with interpreting a directory
> separator.

But the above output doesn't make sense.  The result is by no means
what file-name-directory and file-name-nondirectory are documented to
produce.  And the reason is that the argument is not a file name.  So
why what you are asking makes sense, and when will it be useful in
Emacs in practice?

> > It's not different.  These functions are used all the time for parsing
> > file names, including those in output of other programs.
> 
> But they should be used to parse Emacs file names (i.e., names that use only ?/
> as dir separator), nothing more.

No.  They are designed to parse file names that are valid on the
underlying OS.

> That's all I'm suggesting: keep `file-name-(non)directory' for Emacs file names,
> where that notion is platform-independent wrt dir separator.  Use other code as
> needed to translate to names that use only ?/ as dir separator.
> 
> > There are also users who use backslashes in their ~/.emacs files, when
> > they specify file names and programs.
> 
> So what?  Again, however & whenever Emacs receives such names, it can use code
> that translates them to Emacs file names (names with ?/ as dir separator).

But we already use that "other code": these two primitives (and
others) which DTRT with any file name that is valid on Windows.
There's no need to change anything.

It appears that you are asking for an additional set of functions,
which ignore backslashes on Windows.  If such functions are to become
part of Emacs, we need to hear the practical use-cases where they
would be useful.  You presented a single example, which you now say
was not relevant.  Please present relevant examples that would justify
yet another set of file-name APIs.  Otherwise, you can always write
such functions yourself, it's hardly a big job.

Btw, I suggest to move the rest of the discussion to emacs-devel, as
it's no longer relevant to the original bug report.  That mailing list
has more subscribers than the bug-reporting list, who may contribute
to the discussion.

> > If you do this, you will flood the application sources with ugly
> > system-dependent conditions.  Hardly a good idea.
> 
> I didn't say that the "application sources" should do that (though I'm not sure
> what you mean by that term).
> 
> I said that if some Emacs code expects a "file name" in some format different
> from the standard Emacs syntax - i.e., with some other directory separator, then
> specialized _Emacs_ code that recognizes such a format can translate it to the
> standard format: replace ?\ or another directory separator by ?/, the directory
> separator used by Emacs.

This code will be specific to Windows, and will clutter Lisp
application-level sources, such as gud.el, grep.el, compile.el,
etc. with the kinds of
  `(if (eq system-type 'windows-nt) fix-file-names-for-drew)'.
That's ugly and unergonomic.  The current situation, though not ideal,
is much better.

> > The special-case code has to be somewhere.  Having it at the current
> > low level in C, hidden from the Lisp programs, is the best we can do.
> 
> I agree that it has to be somewhere.  And I recognize that you are far more
> familiar with the Emacs implementation (and with Windows) than I.  My point is
> that there is no logical reason why the _standard_, _general_ Emacs functions
> for decomposing file names (within Emacs) should have to recognize two different
> chars as directory separators.

Yes, there's a perfectly valid reason: because these primitives are
used everywhere in Emacs packages, and those packages don't want to
know about differences in file format between Posix and Windows
platforms.

Again, we do that in a lot of places, most of which I don't even
remember.  The reason I can safely forget about them is _precisely_
that Lisp code doesn't have to worry about these issues, because the
primitives DTRT.  But here's one more example I just recalled: type
"M-x getenv RET PATH RET" and look at the value.  I'm sure if I think
more, I will recall more examples.  But why waste energy on a problem
that doesn't exist?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.