Re: [Emacs-diffs] /srv/bzr/emacs/trunk r105295: * lisp/progmodes/etags.el (etags-file-of-tag, etags-tags-table-files)

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r105295: * lisp/progmodes/etags.el (etags-file-of-tag, etags-tags-table-files)

[Stefan Monnier]

>   * lisp/progmodes/etags.el (etags-file-of-tag, etags-tags-table-files)
>   (etags-tags-included-tables): Call `convert-standard-filename' on
>   the file names contained in TAGS so that windows Emacs can handle
>   TAGS files created by cygwin ctags.

Is that really right?
I mean, convert-standard-filename should only ever be called on absolute
file names, and we have no guarantee that file names in TAGS are
absolute, do we?


        Stefan

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r105295: * lisp/progmodes/etags.el (etags-file-of-tag, etags-tags-table-files)

[Sam Steingold]

On Mon, Aug 1, 2011 at 11:39 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>>   * lisp/progmodes/etags.el (etags-file-of-tag, etags-tags-table-files)
>>   (etags-tags-included-tables): Call `convert-standard-filename' on
>>   the file names contained in TAGS so that windows Emacs can handle
>>   TAGS files created by cygwin ctags.
>
> Is that really right?
> I mean, convert-standard-filename should only ever be called on absolute
> file names, and we have no guarantee that file names in TAGS are
> absolute, do we?

I think that they are already absolute when I call `convert-standard-filename'.
at any rate, it wfm new :-)


-- 
Sam Steingold <http://sds.podval.org>

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r105295: * lisp/progmodes/etags.el (etags-file-of-tag, etags-tags-table-files)

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 01 Aug 2011 23:39:17 -0400
> Cc: emacs-devel@gnu.org
> 
> >   * lisp/progmodes/etags.el (etags-file-of-tag, etags-tags-table-files)
> >   (etags-tags-included-tables): Call `convert-standard-filename' on
> >   the file names contained in TAGS so that windows Emacs can handle
> >   TAGS files created by cygwin ctags.
> 
> Is that really right?
> I mean, convert-standard-filename should only ever be called on absolute
> file names, and we have no guarantee that file names in TAGS are
> absolute, do we?

convert-standard-filename can be called on any file name, not just an
absolute ones.  Of course, it will only do what Sam wants if the file
name begins with /cygdrive/, i.e. is absolute, but your assertion
seemed to be more general than that.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r105295: * lisp/progmodes/etags.el (etags-file-of-tag, etags-tags-table-files)

[Francesco Potortì]

>>   * lisp/progmodes/etags.el (etags-file-of-tag, etags-tags-table-files)
>>   (etags-tags-included-tables): Call `convert-standard-filename' on
>>   the file names contained in TAGS so that windows Emacs can handle
>>   TAGS files created by cygwin ctags.
>
>Is that really right?
>I mean, convert-standard-filename should only ever be called on absolute
>file names, and we have no guarantee that file names in TAGS are
>absolute, do we?

No, we do not.  On the opposite, relative file names in tag files should
never be converted to absolute, and absolute ones never converted to
relative.  The users choose if they want relative or absolute file names
in tags:

33.3.2 Creating Tags Tables
---------------------------

...

   If you specify the source files with relative file names when you run
`etags', the tags file will contain file names relative to the
directory where the tags file was initially written.  This way, you can
move an entire directory tree containing both the tags file and the
source files, and the tags file will still refer correctly to the source
files.  If the tags file is in `/dev', however, the file names are made
relative to the current working directory.  This is useful, for
example, when writing the tags to `/dev/stdout'.

   When using a relative file name, it should not be a symbolic link
pointing to a tags file in a different directory, because this would
generally render the file names invalid.

   If you specify absolute file names as arguments to `etags', then the
tags file will contain absolute file names.  This way, the tags file
will still refer to the same files even if you move it, as long as the
source files remain in the same place.  Absolute file names start with
`/', or with `DEVICE:/' on MS-DOS and MS-Windows.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r105295: * lisp/progmodes/etags.el (etags-file-of-tag, etags-tags-table-files)

[Sam Steingold]

> * Francesco Potortì <cbg@tah.bet> [2011-08-02 10:11:17 +0200]:
>
>>>   * lisp/progmodes/etags.el (etags-file-of-tag, etags-tags-table-files)
>>>   (etags-tags-included-tables): Call `convert-standard-filename' on
>>>   the file names contained in TAGS so that windows Emacs can handle
>>>   TAGS files created by cygwin ctags.
>>
>>Is that really right?
>>I mean, convert-standard-filename should only ever be called on absolute
>>file names, and we have no guarantee that file names in TAGS are
>>absolute, do we?
>
> No, we do not.  On the opposite, relative file names in tag files should
> never be converted to absolute, and absolute ones never converted to
> relative.  The users choose if they want relative or absolute file names
> in tags:
>
> 33.3.2 Creating Tags Tables
> ---------------------------

I use exuberant ctags which can create emacs-compatible TAGS files.
It can also process directories recursively and supports more languages
and language features than the emacs-supplied etags program.

It comes with cygwin on windows and writes files like this:

/cygdrive/d/algo-e/code/admin/butler/bin/activity.pl,52
\x7factivity.pl1,0
sub my_print($) {\x7fmy_print96,2369

I want to use these files with the native windows emacs.
With my patch I, indeed, can.

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031
http://dhimmi.com http://truepeace.org http://camera.org http://www.memritv.org
http://ffii.org http://mideasttruth.com http://thereligionofpeace.com
Are you smart enough to use Lisp?

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r105295: * lisp/progmodes/etags.el (etags-file-of-tag, etags-tags-table-files)

[Stefan Monnier]

> With my patch I, indeed, can.

I believe you.  But that doesn't mean it's the right way to fix it, nor
that it can't introduce other problems.


        Stefan

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r105295: * lisp/progmodes/etags.el (etags-file-of-tag, etags-tags-table-files)

[Stefan Monnier]

> convert-standard-filename can be called on any file name, not just an
> absolute ones.  Of course, it will only do what Sam wants if the file
> name begins with /cygdrive/, i.e. is absolute, but your assertion
> seemed to be more general than that.

C-h f convert-standard-filename RET:

   FILENAME should be an absolute file name since the conversion rules
   sometimes vary depending on the position in the file name.  E.g. c:/foo
   is a valid DOS file name, but c:/bar/c:/foo is not.


-- Stefan

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r105295: * lisp/progmodes/etags.el (etags-file-of-tag, etags-tags-table-files)

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: sds@gnu.org, emacs-devel@gnu.org
> Date: Tue, 02 Aug 2011 14:57:15 -0400
> 
> > convert-standard-filename can be called on any file name, not just an
> > absolute ones.  Of course, it will only do what Sam wants if the file
> > name begins with /cygdrive/, i.e. is absolute, but your assertion
> > seemed to be more general than that.
> 
> C-h f convert-standard-filename RET:
> 
>    FILENAME should be an absolute file name

That's a lie:

  desktop.el:210:  (convert-standard-filename ".emacs.desktop")
  desktop.el:216:  (convert-standard-filename ".emacs.desktop.lock")
  dired-x.el:768:(defcustom dired-local-variables-file (convert-standard-filename ".dired")
  ido.el:924:(defcustom ido-save-directory-list-file (convert-standard-filename "~/.ido.last")
  ps-bdf.el:104:			 (convert-standard-filename "~/.bdfcache.el"))
  recentf.el:72:(defcustom recentf-save-file (convert-standard-filename "~/.recentf")
  saveplace.el:72:(defcustom save-place-file (convert-standard-filename "~/.emacs-places")
  shadowfile.el:805:	    (shadow-expand-file-name (convert-standard-filename "~/.shadows"))))
  shadowfile.el:809:	     (convert-standard-filename "~/.shadow_todo"))))
  strokes.el:260:(defcustom strokes-file (convert-standard-filename "~/.strokes")

>                                                 since the conversion rules
>    sometimes vary depending on the position in the file name.  E.g. c:/foo
>    is a valid DOS file name, but c:/bar/c:/foo is not.

The example of a problem is correct, but the generalization is
obviously invalid.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r105295: * lisp/progmodes/etags.el (etags-file-of-tag, etags-tags-table-files)

[Stefan Monnier]

>> > convert-standard-filename can be called on any file name, not just an
>> > absolute ones.  Of course, it will only do what Sam wants if the file
>> > name begins with /cygdrive/, i.e. is absolute, but your assertion
>> > seemed to be more general than that.
>> C-h f convert-standard-filename RET:
>> FILENAME should be an absolute file name

> That's a lie:

>   desktop.el:210:  (convert-standard-filename ".emacs.desktop")
>   desktop.el:216:  (convert-standard-filename ".emacs.desktop.lock")
>   dired-x.el:768:(defcustom dired-local-variables-file (convert-standard-filename ".dired")

So these are the counter examples.

>> since the conversion rules sometimes vary depending on the position
>> in the file name.  E.g. c:/foo is a valid DOS file name, but
>> c:/bar/c:/foo is not.
> The example of a problem is correct, but the generalization is
> obviously invalid.

Still, the problem is that the intended meaning of
convert-standard-filename is unclear (what should it do on relative
file names?), and that the functionality require by the OP is not quite
the one provided by convert-standard-filename, AFAIK (and I don't think
we have exactly what he wants).

My understanding is:
- convert-standard-filename is to convert a predefined name, which may
  be mentioned in docs, using mostly Unix conventions so that it works
  on whichever OS we're using.  E.g. it may do things like map ".emacs"
  to "_emacs".
- the function Sam needs is one that converts from "file name using
  conventions used in the system in which Emacs is running" to "file
  name referring to the same file but such that Emacs can access it".
  Doing things like "However, on Windows and DOS, replace invalid
  characters" is not the right thing to do.

BTW the function he wants is also the function that should be applied to
files names received in command-line-args and as args to emacsclient
(as was recently requested by some other poster).


        Stefan

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r105295: * lisp/progmodes/etags.el (etags-file-of-tag, etags-tags-table-files)

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: sds@gnu.org,  emacs-devel@gnu.org
> Date: Tue, 02 Aug 2011 16:24:38 -0400
> 
> Still, the problem is that the intended meaning of
> convert-standard-filename is unclear (what should it do on relative
> file names?)

For relative file names, it should produce a relative file name whose
name is valid on the underlying filesystem.

This may mean converting more than a single component of the original
name, e.g., if it includes leading directories, as in
"~/.emacs.d/.emacs.something".

With that definition, the same applies to absolute file names, of
course.

> and that the functionality require by the OP is not quite
> the one provided by convert-standard-filename, AFAIK

The addition of converting Cygwin file names to native w32 file names
is an add-on functionality.  Originally, convert-standard-filename was
not supposed to handle these issues at all.  The function was actually
created for the DOS port, at RMS's advice (when he saw that I was
committing changes to defcustom's that used a different file name
conditioned by system-type).  The rest is history...

> My understanding is:
> - convert-standard-filename is to convert a predefined name, which may
>   be mentioned in docs, using mostly Unix conventions so that it works
>   on whichever OS we're using.  E.g. it may do things like map ".emacs"
>   to "_emacs".

Correct.

> - the function Sam needs is one that converts from "file name using
>   conventions used in the system in which Emacs is running" to "file
>   name referring to the same file but such that Emacs can access it".
>   Doing things like "However, on Windows and DOS, replace invalid
>   characters" is not the right thing to do.

Agreed.

> BTW the function he wants is also the function that should be applied to
> files names received in command-line-args and as args to emacsclient
> (as was recently requested by some other poster).

Indeed.

convert-standard-filename (was: [Emacs-diffs] /srv/bzr/emacs/trunk r105295: * lisp/progmodes/etags.el (etags-file-of-tag, etags-tags-table-files))

[Stefan Monnier]

>> Still, the problem is that the intended meaning of
>> convert-standard-filename is unclear (what should it do on relative
>> file names?)
> For relative file names, it should produce a relative file name whose
> name is valid on the underlying filesystem.

But how should it decide what is relative and what is not, e.g. in the
case of "c:/foo" (or worse "c:foo") mentioned in the docstring?

>> and that the functionality require by the OP is not quite
>> the one provided by convert-standard-filename, AFAIK
> The addition of converting Cygwin file names to native w32 file names
> is an add-on functionality.  Originally, convert-standard-filename was
> not supposed to handle these issues at all.  The function was actually
> created for the DOS port, at RMS's advice (when he saw that I was
> committing changes to defcustom's that used a different file name
> conditioned by system-type).  The rest is history...

Yes, the behavior is a mess, really.

>> My understanding is:
>> - convert-standard-filename is to convert a predefined name, which may
>> be mentioned in docs, using mostly Unix conventions so that it works
>> on whichever OS we're using.  E.g. it may do things like map ".emacs"
>> to "_emacs".
> Correct.

But now I wonder what "it works on whichever OS we're running" means:
I was thinking of "Emacs can use this name on whichever OS we're
running", but the slash-to-backslash conversion seems to indicate it's
rather meant for "Emacs can pass this to external processes and they'll
understand it".

I think we really need to clarify what it's supposed to do.
And since a grep indicates that it's misused at many places, maybe the
best solution is to make it obsolete and replace it with a new (set of)
function(s) with clearer semantics.

AFAICT, there are the following different needs:
- The original intention: convert a standard name such as "~/.emacs" so
  it works everywhere.  The argument should come from within Emacs.
  This should pretty much only be used with a constant argument.
  Maybe (a big maybe) it can be used for things like generating
  a filename from some other piece of data, but I think even that should
  be discouraged in favor of `md5'.
- Take a filename from outside Emacs and convert it into something Emacs
  can use internally.  Can do things like cygwin handling.  Can assume
  that the provided filename is valid, so it doesn't need to be careful
  to drop invalid filename characters.  Can convert backslashes into
  slashes on Windows.
- Take an internal filename and convert it to something that can be used
  outside of Emacs.  E.g. convert slashes into backslashes.  Again, this
  can probably assume that the file name is already valid and doesn't
  need to drop funny chars.


        Stefan

Re: convert-standard-filename (was: [Emacs-diffs] /srv/bzr/emacs/trunk r105295: * lisp/progmodes/etags.el (etags-file-of-tag, etags-tags-table-files))

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: sds@gnu.org, emacs-devel@gnu.org
> Date: Fri, 05 Aug 2011 13:18:40 -0400
> 
> >> Still, the problem is that the intended meaning of
> >> convert-standard-filename is unclear (what should it do on relative
> >> file names?)
> > For relative file names, it should produce a relative file name whose
> > name is valid on the underlying filesystem.
> 
> But how should it decide what is relative and what is not, e.g. in the
> case of "c:/foo" (or worse "c:foo") mentioned in the docstring?

Why by file-name-absolute-p, of course ;-)

> But now I wonder what "it works on whichever OS we're running" means:
> I was thinking of "Emacs can use this name on whichever OS we're
> running", but the slash-to-backslash conversion seems to indicate it's
> rather meant for "Emacs can pass this to external processes and they'll
> understand it".

The slash-to-backslash conversion is also a later addition.  It was
not needed originally, since DOS/Windows filesystems grok the forward
slash just fine, and all the programs from the DJGPP toolset (the
environment used to build and use Emacs on DOS) accept forward slashes
as well as backslashes.

> I think we really need to clarify what it's supposed to do.
> And since a grep indicates that it's misused at many places, maybe the
> best solution is to make it obsolete and replace it with a new (set of)
> function(s) with clearer semantics.

I agree this would be a good cleanup.

> AFAICT, there are the following different needs:
> - The original intention: convert a standard name such as "~/.emacs" so
>   it works everywhere.  The argument should come from within Emacs.
>   This should pretty much only be used with a constant argument.
>   Maybe (a big maybe) it can be used for things like generating
>   a filename from some other piece of data, but I think even that should
>   be discouraged in favor of `md5'.
> - Take a filename from outside Emacs and convert it into something Emacs
>   can use internally.  Can do things like cygwin handling.  Can assume
>   that the provided filename is valid, so it doesn't need to be careful
>   to drop invalid filename characters.  Can convert backslashes into
>   slashes on Windows.
> - Take an internal filename and convert it to something that can be used
>   outside of Emacs.  E.g. convert slashes into backslashes.  Again, this
>   can probably assume that the file name is already valid and doesn't
>   need to drop funny chars.

Something like that.  There's also dos-8+3-filename, which is needed
when one compares with string= internal file names with those found on
disk, but that's DOS-specific, or maybe it can be merged into the last
category.

Re: convert-standard-filename

[Stefan Monnier]

>> But how should it decide what is relative and what is not, e.g. in the
>> case of "c:/foo" (or worse "c:foo") mentioned in the docstring?
> Why by file-name-absolute-p, of course ;-)

This would mean that the input is interpreted in an OS-dependent way.
It would seem to make more sense to say that the arg to
convert-filename-argument (or its new replacement) should be
a Unix-style filename, i.e. "C:<foo>" is always interpreted as
a relative file name, even under Window or DOS.

>> AFAICT, there are the following different needs:
>> - The original intention: convert a standard name such as "~/.emacs" so
>> it works everywhere.  The argument should come from within Emacs.
>> This should pretty much only be used with a constant argument.
>> Maybe (a big maybe) it can be used for things like generating
>> a filename from some other piece of data, but I think even that should
>> be discouraged in favor of `md5'.
>> - Take a filename from outside Emacs and convert it into something Emacs
>> can use internally.  Can do things like cygwin handling.  Can assume
>> that the provided filename is valid, so it doesn't need to be careful
>> to drop invalid filename characters.  Can convert backslashes into
>> slashes on Windows.
>> - Take an internal filename and convert it to something that can be used
>> outside of Emacs.  E.g. convert slashes into backslashes.  Again, this
>> can probably assume that the file name is already valid and doesn't
>> need to drop funny chars.
> Something like that.  There's also dos-8+3-filename, which is needed
> when one compares with string= internal file names with those found on
> disk, but that's DOS-specific, or maybe it can be merged into the last
> category.

How 'bout a file-name-equal, which could also try to account for
case-sensitivity?
Hmm... I didn't check all uses of doc-8+3-filename, but at least the one
in files.el can't be replaced by file-name-equal.


        Stefan

Re: convert-standard-filename

[Lennart Borgman]

On Sun, Aug 7, 2011 at 17:33, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>> But how should it decide what is relative and what is not, e.g. in the
>>> case of "c:/foo" (or worse "c:foo") mentioned in the docstring?
>> Why by file-name-absolute-p, of course ;-)
>
> This would mean that the input is interpreted in an OS-dependent way.
> It would seem to make more sense to say that the arg to
> convert-filename-argument (or its new replacement) should be
> a Unix-style filename, i.e. "C:<foo>" is always interpreted as
> a relative file name, even under Window or DOS.

If we allow OS-dependent file names then does it not make more sense
to interpret them in the OS-dependent way? At least that seems much
more likely to make users surprised.

Re: convert-standard-filename

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: sds@gnu.org,  emacs-devel@gnu.org
> Date: Sun, 07 Aug 2011 11:33:53 -0400
> 
> >> But how should it decide what is relative and what is not, e.g. in the
> >> case of "c:/foo" (or worse "c:foo") mentioned in the docstring?
> > Why by file-name-absolute-p, of course ;-)
> 
> This would mean that the input is interpreted in an OS-dependent way.
> It would seem to make more sense to say that the arg to
> convert-filename-argument (or its new replacement) should be
> a Unix-style filename, i.e. "C:<foo>" is always interpreted as
> a relative file name, even under Window or DOS.

Although it makes sense, that would change the current semantics, and
probably break some existing code out there.

> How 'bout a file-name-equal, which could also try to account for
> case-sensitivity?

He-he, I was arguing for years that file names are not strings and
cannot be compared as strings.  Finally I have someone who agrees ;-)

There's also the case of 8+3 aliases of long file names on Windows, we
bumped into that some time ago (the value of temporary-file-directory
on Windows uses the 8+3 alias, because that's how Windows sets up the
environment variable).

> Hmm... I didn't check all uses of doc-8+3-filename, but at least the one
> in files.el can't be replaced by file-name-equal.

They all can.  dos-8+3-filename was introduced _only_ to be able to
compare and match file names as strings.

Re: convert-standard-filename

[Lennart Borgman]

On Sun, Aug 7, 2011 at 18:18, Eli Zaretskii <eliz@gnu.org> wrote:
>>
>> How 'bout a file-name-equal, which could also try to account for
>> case-sensitivity?
>
> He-he, I was arguing for years that file names are not strings and
> cannot be compared as strings.  Finally I have someone who agrees ;-)
>
> There's also the case of 8+3 aliases of long file names on Windows, we
> bumped into that some time ago (the value of temporary-file-directory
> on Windows uses the 8+3 alias, because that's how Windows sets up the
> environment variable).

You are not alone.

Re: convert-standard-filename

[Stefan Monnier]

>>>> But how should it decide what is relative and what is not, e.g. in the
>>>> case of "c:/foo" (or worse "c:foo") mentioned in the docstring?
>>> Why by file-name-absolute-p, of course ;-)
>> This would mean that the input is interpreted in an OS-dependent way.
>> It would seem to make more sense to say that the arg to
>> convert-filename-argument (or its new replacement) should be
>> a Unix-style filename, i.e. "C:<foo>" is always interpreted as
>> a relative file name, even under Window or DOS.
> If we allow OS-dependent file names then does it not make more sense
> to interpret them in the OS-dependent way? At least that seems much
> more likely to make users surprised.

The whole point of convert-standard-filename was to provide an
OS-dependent file name from an OS-independent one (typically from
a constant filename in a package).  So interpreting the input to this
function in an OS-dependent way is wrong.


        Stefan

Re: convert-standard-filename

[Stefan Monnier]

>> >> But how should it decide what is relative and what is not, e.g. in the
>> >> case of "c:/foo" (or worse "c:foo") mentioned in the docstring?
>> > Why by file-name-absolute-p, of course ;-)
>> This would mean that the input is interpreted in an OS-dependent way.
>> It would seem to make more sense to say that the arg to
>> convert-filename-argument (or its new replacement) should be
>> a Unix-style filename, i.e. "C:<foo>" is always interpreted as
>> a relative file name, even under Window or DOS.
> Although it makes sense, that would change the current semantics, and
> probably break some existing code out there.

Agreed.  I think that not only convert-standard-filename has drifted far
from its original purpose, but to fix it we need to define a new
function because too many callers require a behavior that's incompatible
with "the right convert-standard-filename".

>> How 'bout a file-name-equal, which could also try to account for
>> case-sensitivity?
> He-he, I was arguing for years that file names are not strings and
> cannot be compared as strings.  Finally I have someone who agrees ;-)

I always thought you weren't completely convinced.  I'm all for it.
We do want to define it carefully, tho.  E.g. it should only operate on
names without performing any actual file/directory lookup.

>> Hmm... I didn't check all uses of doc-8+3-filename, but at least the one
>> in files.el can't be replaced by file-name-equal.
> They all can.  dos-8+3-filename was introduced _only_ to be able to
> compare and match file names as strings.

The use in files.el is to generate a good backup file name, presumably
because "#foobar.perl#" would get turned into "#foobar.per" whereas we
prefer "#foobar.pe#".  I don't know how to do that with file-name-equal,
but admittedly, dos-8+3-filename is not sufficient to do it either: it
uses ad-hoc code in files.el.


        Stefan

Re: convert-standard-filename

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: sds@gnu.org,  emacs-devel@gnu.org
> Date: Sun, 07 Aug 2011 16:19:47 -0400
> 
> [file-name-equal] should only operate on names without performing
> any actual file/directory lookup.

Why do you want to avoid hitting the disk?  The code which needs to
deal with these cases should only run on the OS that supports such
file names.

> The use in files.el is to generate a good backup file name, presumably
> because "#foobar.perl#" would get turned into "#foobar.per" whereas we
> prefer "#foobar.pe#".  I don't know how to do that with file-name-equal,
> but admittedly, dos-8+3-filename is not sufficient to do it either: it
> uses ad-hoc code in files.el.

Ah, that one...  Yes, it just used the facility that was already
available.

Re: convert-standard-filename

[Sam Steingold]

On Sun, Aug 7, 2011 at 4:35 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> [file-name-equal] should only operate on names without performing
>> any actual file/directory lookup.
>
> Why do you want to avoid hitting the disk?

because hitting the disk is far more expensive.
when one is prepared to bear the cost, one can do
(file-name-equal (truename f1) (truename f2))

-- 
Sam Steingold <http://sds.podval.org>

Re: convert-standard-filename

[Lennart Borgman]

On Sun, Aug 7, 2011 at 21:43, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>>>> But how should it decide what is relative and what is not, e.g. in the
>>>>> case of "c:/foo" (or worse "c:foo") mentioned in the docstring?
>>>> Why by file-name-absolute-p, of course ;-)
>>> This would mean that the input is interpreted in an OS-dependent way.
>>> It would seem to make more sense to say that the arg to
>>> convert-filename-argument (or its new replacement) should be
>>> a Unix-style filename, i.e. "C:<foo>" is always interpreted as
>>> a relative file name, even under Window or DOS.
>> If we allow OS-dependent file names then does it not make more sense
>> to interpret them in the OS-dependent way? At least that seems much
>> more likely to make users surprised.
>
> The whole point of convert-standard-filename was to provide an
> OS-dependent file name from an OS-independent one (typically from
> a constant filename in a package).  So interpreting the input to this
> function in an OS-dependent way is wrong.

I would rather have it return a file name that fits the OS, regardless
of the file name that it is given. I.e. it should work both if the
argument is an Emacs standard file name or if it is an OS style file
name.

That does not fit the current doc string but the description in info:

 -- Function: convert-standard-filename filename
     This function alters the file name FILENAME to fit the conventions
     of the operating system in use, and returns the result as a new
     string.

If it does not work this way then file names read in some way must be
tested first to see if which type they are.

Re: convert-standard-filename

[Eli Zaretskii]

> Date: Sun, 7 Aug 2011 17:20:29 -0400
> From: Sam Steingold <sds@gnu.org>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
> 
> On Sun, Aug 7, 2011 at 4:35 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> From: Stefan Monnier <monnier@iro.umontreal.ca>
> >> [file-name-equal] should only operate on names without performing
> >> any actual file/directory lookup.
> >
> > Why do you want to avoid hitting the disk?
> 
> because hitting the disk is far more expensive.

So?  Does someone want to call convert-standard-filename in a tight
loop or something?

> when one is prepared to bear the cost, one can do
> (file-name-equal (truename f1) (truename f2))

You assume that truename does all the canonicalization.  Perhaps on
Unix it does, but not on other platforms.  Again, the case of 8+3
aliases on Windows comes to mind.

Re: convert-standard-filename

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Mon, 8 Aug 2011 00:05:05 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, sds@gnu.org, emacs-devel@gnu.org
> 
> > The whole point of convert-standard-filename was to provide an
> > OS-dependent file name from an OS-independent one (typically from
> > a constant filename in a package).  So interpreting the input to this
> > function in an OS-dependent way is wrong.
> 
> I would rather have it return a file name that fits the OS, regardless
> of the file name that it is given.

That would be in contradiction with the function's purpose, see above.

> If it does not work this way then file names read in some way must be
> tested first to see if which type they are.

convert-standard-filename was originally not supposed to handle file
names that "are read", only file names that are hard-coded in Emacs
sources.

Re: convert-standard-filename

[Lennart Borgman]

On Mon, Aug 8, 2011 at 04:54, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Date: Mon, 8 Aug 2011 00:05:05 +0200
>> Cc: Eli Zaretskii <eliz@gnu.org>, sds@gnu.org, emacs-devel@gnu.org
>>
>> > The whole point of convert-standard-filename was to provide an
>> > OS-dependent file name from an OS-independent one (typically from
>> > a constant filename in a package).  So interpreting the input to this
>> > function in an OS-dependent way is wrong.
>>
>> I would rather have it return a file name that fits the OS, regardless
>> of the file name that it is given.
>
> That would be in contradiction with the function's purpose, see above.

Could it make any harm if it worked the way I suggested? Are there any
cases were the result would be ambigious?

Re: convert-standard-filename

[Stefan Monnier]

>>> [file-name-equal] should only operate on names without performing
>>> any actual file/directory lookup.
>> Why do you want to avoid hitting the disk?

Because I'd like it to work for files and directories which may not even
exist (yet?).  But maybe that's unrealistic (I guess the foobar ->
foob~1 rewrite in some Windows cases probably can't work without
hitting the disk).

> when one is prepared to bear the cost, one can do
> (file-name-equal (truename f1) (truename f2))

If it can only work for existing files/directories, then comparing the
output of file-attributes (esp elements 10 and 11) seems like a better
implementation, at least on POSIX.
But then it's not "file-name-equal" but "file-equal".


        Stefan

Re: convert-standard-filename

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Sun, 07 Aug 2011 23:24:17 -0400
> 
> >> Why do you want to avoid hitting the disk?
> 
> Because I'd like it to work for files and directories which may not even
> exist (yet?).  But maybe that's unrealistic (I guess the foobar ->
> foob~1 rewrite in some Windows cases probably can't work without
> hitting the disk).

It _can_ work, given slightly more work, and sometimes we will have to
be less than 100% reliable, e.g. if more than a single foob~N file
exist in the same directory.

> But then it's not "file-name-equal" but "file-equal".

Except for the issue with non-existing files, is there difference,
btw?

Re: convert-standard-filename

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Mon, 8 Aug 2011 05:23:19 +0200
> Cc: monnier@iro.umontreal.ca, sds@gnu.org, emacs-devel@gnu.org
> 
> On Mon, Aug 8, 2011 at 04:54, Eli Zaretskii <eliz@gnu.org> wrote:
> >> From: Lennart Borgman <lennart.borgman@gmail.com>
> >> Date: Mon, 8 Aug 2011 00:05:05 +0200
> >> Cc: Eli Zaretskii <eliz@gnu.org>, sds@gnu.org, emacs-devel@gnu.org
> >>
> >> > The whole point of convert-standard-filename was to provide an
> >> > OS-dependent file name from an OS-independent one (typically from
> >> > a constant filename in a package).  So interpreting the input to this
> >> > function in an OS-dependent way is wrong.
> >>
> >> I would rather have it return a file name that fits the OS, regardless
> >> of the file name that it is given.
> >
> > That would be in contradiction with the function's purpose, see above.
> 
> Could it make any harm if it worked the way I suggested?

Yes, it contradicts the purpose of the function, and thus makes its
result unpredictable, except by looking at the source.

> Are there any cases were the result would be ambigious?

The case of "c:foobar", as pointed out by Stefan earlier in this
thread.  If it's taken as a local absolute file name, then on Windows
there's no need to do anything about it.  If it is taken as a Posix
relative file name, the colon should be replaced with some other
character.

Re: convert-standard-filename

[Lennart Borgman]

On Mon, Aug 8, 2011 at 06:19, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> Are there any cases were the result would be ambigious?
>
> The case of "c:foobar", as pointed out by Stefan earlier in this
> thread.  If it's taken as a local absolute file name, then on Windows
> there's no need to do anything about it.  If it is taken as a Posix
> relative file name, the colon should be replaced with some other
> character.

I see. But on Windows it could hardly be a Posix relative file name,
or could it?

Re: convert-standard-filename

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Mon, 8 Aug 2011 06:26:28 +0200
> Cc: monnier@iro.umontreal.ca, sds@gnu.org, emacs-devel@gnu.org
> 
> On Mon, Aug 8, 2011 at 06:19, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> >> Are there any cases were the result would be ambigious?
> >
> > The case of "c:foobar", as pointed out by Stefan earlier in this
> > thread.  If it's taken as a local absolute file name, then on Windows
> > there's no need to do anything about it.  If it is taken as a Posix
> > relative file name, the colon should be replaced with some other
> > character.
> 
> I see. But on Windows it could hardly be a Posix relative file name,
> or could it?

It can't, so convert-standard-filename should replace the colon.
That's what convert-standard-filename does: takes a Posix file name
and produces a file name usable on non-Posix filesystems.

Re: convert-standard-filename

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> How 'bout a file-name-equal, which could also try to account for
>>> case-sensitivity?
>> He-he, I was arguing for years that file names are not strings and
>> cannot be compared as strings.  Finally I have someone who agrees ;-)
>
> I always thought you weren't completely convinced.  I'm all for it.
> We do want to define it carefully, tho.  E.g. it should only operate on
> names without performing any actual file/directory lookup.

It shall also support file name handlers. I would prefer 

(file-name-equal "/sudo::/" "/sudo:root@localhost:/") => t

if appropriate (depends on default settings). This doesn't need to touch
the remote host either.

>         Stefan

Best regards, Michael.

Re: convert-standard-filename

[Lennart Borgman]

On Mon, Aug 8, 2011 at 06:38, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Date: Mon, 8 Aug 2011 06:26:28 +0200
>> Cc: monnier@iro.umontreal.ca, sds@gnu.org, emacs-devel@gnu.org
>>
>> On Mon, Aug 8, 2011 at 06:19, Eli Zaretskii <eliz@gnu.org> wrote:
>> >
>> >> Are there any cases were the result would be ambigious?
>> >
>> > The case of "c:foobar", as pointed out by Stefan earlier in this
>> > thread.  If it's taken as a local absolute file name, then on Windows
>> > there's no need to do anything about it.  If it is taken as a Posix
>> > relative file name, the colon should be replaced with some other
>> > character.
>>
>> I see. But on Windows it could hardly be a Posix relative file name,
>> or could it?
>
> It can't, so convert-standard-filename should replace the colon.
> That's what convert-standard-filename does: takes a Posix file name
> and produces a file name usable on non-Posix filesystems.

And when does such a situation arise? (I.e. when does it happen that a
Posix file name looking like a Windows file name needs to be converted
to a Windows file name.)

Re: convert-standard-filename

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Mon, 8 Aug 2011 12:37:56 +0200
> Cc: monnier@iro.umontreal.ca, sds@gnu.org, emacs-devel@gnu.org
> 
> > It can't, so convert-standard-filename should replace the colon.
> > That's what convert-standard-filename does: takes a Posix file name
> > and produces a file name usable on non-Posix filesystems.
> 
> And when does such a situation arise? (I.e. when does it happen that a
> Posix file name looking like a Windows file name needs to be converted
> to a Windows file name.)

E.g., when saving a local backup for a remote file name.  Or whenever
else Emacs wants to use a colon in a file name, since Posix
filesystems allow any character.

Re: convert-standard-filename

[Lennart Borgman]

On Mon, Aug 8, 2011 at 13:31, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Date: Mon, 8 Aug 2011 12:37:56 +0200
>> Cc: monnier@iro.umontreal.ca, sds@gnu.org, emacs-devel@gnu.org
>>
>> > It can't, so convert-standard-filename should replace the colon.
>> > That's what convert-standard-filename does: takes a Posix file name
>> > and produces a file name usable on non-Posix filesystems.
>>
>> And when does such a situation arise? (I.e. when does it happen that a
>> Posix file name looking like a Windows file name needs to be converted
>> to a Windows file name.)
>
> E.g., when saving a local backup for a remote file name.

A good example, but this could be handled by a part of
convert-standard-filename (the default behaviour does not have to take
this into account).

> Or whenever
> else Emacs wants to use a colon in a file name, since Posix
> filesystems allow any character.

If we could stop Emacs from thinking too much by itself we might be
able to handle this ;-)

Re: convert-standard-filename

[Stefan Monnier]

>> >> Why do you want to avoid hitting the disk?
>> Because I'd like it to work for files and directories which may not even
>> exist (yet?).  But maybe that's unrealistic (I guess the foobar ->
>> foob~1 rewrite in some Windows cases probably can't work without
>> hitting the disk).
> It _can_ work, given slightly more work, and sometimes we will have to
> be less than 100% reliable, e.g. if more than a single foob~N file
> exist in the same directory.

If you say so.

>> But then it's not "file-name-equal" but "file-equal".
> Except for the issue with non-existing files, is there difference,
> btw?

Ever heard of (symbolic|hard) links?


        Stefan

Re: convert-standard-filename

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: sds@gnu.org,  emacs-devel@gnu.org
> Date: Mon, 08 Aug 2011 14:20:56 -0400
> 
> >> But then it's not "file-name-equal" but "file-equal".
> > Except for the issue with non-existing files, is there difference,
> > btw?
> 
> Ever heard of (symbolic|hard) links?

Not sure.  Something vague comes to mind...

So what are they? file-name-equal or file-equal, or maybe both?

Re: convert-standard-filename

[Stefan Monnier]

>> >> But then it's not "file-name-equal" but "file-equal".
>> > Except for the issue with non-existing files, is there difference,
>> > btw?
>> Ever heard of (symbolic|hard) links?
> Not sure.  Something vague comes to mind...
> So what are they? file-name-equal or file-equal, or maybe both?

I think they're file-equal but not file-name-equal, since I consider
file-name-equal to be something that shouldn't pay too much attention to
the actual existing files.

But that's part of the issues that need to be clarified in the design
of file-name-equal.  BTW, rather than file-name-equal we may prefer to
provide file-name-canonical such that

  (defun file-name-equal (f1 f2)
    (equal (file-name-canonical f1) (file-name-canonical f2)))

In any case, all these things are for post-24.1.


        Stefan

Re: convert-standard-filename

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: sds@gnu.org, emacs-devel@gnu.org
> Date: Mon, 08 Aug 2011 17:24:02 -0400
> 
> >> Ever heard of (symbolic|hard) links?
> > Not sure.  Something vague comes to mind...
> > So what are they? file-name-equal or file-equal, or maybe both?
> 
> I think they're file-equal but not file-name-equal, since I consider
> file-name-equal to be something that shouldn't pay too much attention to
> the actual existing files.

That is a slippery slope, IMO: many users of these APIs will neither
know nor care whether the files by those names exist or not.

It also raises some hard-to-resolve questions of applicability of each
API to non-Posix platforms.  E.g., the 8+3 alias is a kind of hard
link, but comes into existence the moment its original file does, and
OTOH can be computed even if the original file does not exist.

So I would suggest a single API, not 2.  If some Lisp program wants to
drill down to the hard/symbolic link level, there are already APIs to
do that.

> But that's part of the issues that need to be clarified in the design
> of file-name-equal.  BTW, rather than file-name-equal we may prefer to
> provide file-name-canonical such that
> 
>   (defun file-name-equal (f1 f2)
>     (equal (file-name-canonical f1) (file-name-canonical f2)))

Another slippery slope, IMO: on some platforms the "canonical" file
name cannot be computed unless the file exists.  Unless you redefine
"canonical" to be a derivative of file-name-equal according to the
above defun, in which case it will probably confuse the heck out of
programmers who are used to canonicalize_file_name and realpath.

> In any case, all these things are for post-24.1.

Well, 24.1 is already in the past, nes pas? ;-)

Re: convert-standard-filename

[Stefan Monnier]

> So I would suggest a single API, not 2.  If some Lisp program wants to
> drill down to the hard/symbolic link level, there are already APIs to
> do that.

I'm not suggesting two APIs.  I'm just pointing out the different
possibilities and the need for the function we want to define to be
clear about what are its semantics.


        Stefan

Re: convert-standard-filename

[Stefan Monnier]

>> (defun file-name-equal (f1 f2)
>> (equal (file-name-canonical f1) (file-name-canonical f2)))

> Another slippery slope, IMO: on some platforms the "canonical" file
> name cannot be computed unless the file exists.  Unless you redefine
> "canonical" to be a derivative of file-name-equal according to the
> above defun, in which case it will probably confuse the heck out of
> programmers who are used to canonicalize_file_name and realpath.

Again, I'm not necessarily advocating this approach.  It does have
some advantages (e.g. if you want to define a map (alist/hash) from file
names to values, where file names need to be compared with
file-name-equal).  But it may indeed prove impossible/impractical
to implement.


        Stefan