unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Eli Zaretskii'" <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: RE: file-truename, convert-standard-filename
Date: Sat, 6 Feb 2010 15:12:05 -0800	[thread overview]
Message-ID: <CBCE1B91725342F29EDB05C1E433A34C@us.oracle.com> (raw)
In-Reply-To: <83zl3mdo22.fsf@gnu.org>

> > That means that in order to use ANY file name (any 
> > file-name string, no matter where it was coded or how
> > it is produced), you need to apply c-s-f to it, if you
> > don't know whether the name is supported by all platforms 
> > that might be used by your code.
> 
> Again, the case when the string is known to be a name of an existing
> file is the important exception.  For example, if it comes from
> buffer-file-name, or from default-directory, or from other similar
> interfaces.

OK. Then add "and you do not know whether the file named exists" to what I
wrote. Again, that is the general case.

> > > If this part is understood, then just use 
> > > `convert-standard-filename' in any situation where a
> > > string to be used as a file name might not be
> > > valid on the underlying filesystem, 
> > 
> > Which for an unknown string (e.g. the string value of a 
> > variable) means ALL situations, no?
> 
> It could be, unless, again, you know that a file by that name already
> exists.

Got it.

> > BTW, I notice that prior to Emacs 23 the Emacs source code 
> > did not use c-s-f very much (e.g. defcustoms, such as in
> > recentf.el); Emacs 23 uses it much more.
> > I suppose this means that we had more problems with this 
> > before Emacs 23.
> 
> No, it just means we made some cleanup.  The situations where this
> really matters are very rare, and if you ignore the MS-DOS case, are
> almost non-existent.  People rarely use characters in file names that
> get you in trouble on MS-Windows.  And if the file name comes from the
> user, you can almost be certain she will never use such characters,
> and even if she does, she deserves the error message.
> 
> About the only real use-case is when the file name comes from the Lisp
> code itself.  Which is why I mentioned literal strings so many times.

Hm. That changes things considerably.

My summary:

THEORETICALLY, one _always_ needs c-s-f, unless either (1) you know that the
file that is named exists or (2) you know _all_ of the following: (2a) the file
system being used, (2b) the file name being used, and (2c) that the given file
name is a valid one for the given file system.

IN PRACTICE, however, the only real use-case is for MS-DOS support, and in
particular, only when the file name is a literal string in Lisp code.

Have I got it now?

If so, then for my purposes, since I do not care about MS-DOS support for my
code, I will _never_ need to use c-s-f. Hope I'm understanding correctly now.
For me, it seems, the ALWAYS of theoretically changes quickly to the NEVER of
practically. That's a big change.

If I've got it right, then (practically) the use of c-s-f is pretty much only an
internal one for Emacs development. I don't expect there is a lot of 3rd-party
code intended for MS-DOS. (But I might be mistaken about that.)

Anyway, assuming I finally understand this, thank you very much. (If I don't,
I'd be grateful if you would try once more.)

And I think you now know what kinds of things you might want to say and not say
in the doc, to clear things up. 

If you want my suggestion about that (the doc), and assuming my understanding is
correct, then I'd say that what I just wrote above (theoretical vs practical) is
all anyone needs to find in the doc. In particular: in practice, c-s-f is only
for MS-DOS support. So unless you develop code for the Emacs distribution, YAGNI
(use cases are "almost non-existent").

Thanks, Eli. If I'm still missing the point, please let me know.





  reply	other threads:[~2010-02-06 23:12 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-05 17:31 file-truename, convert-standard-filename Drew Adams
2010-02-05 18:15 ` Andreas Schwab
2010-02-05 18:33   ` Lennart Borgman
2010-02-05 19:45     ` Andreas Schwab
2010-02-05 19:49       ` Lennart Borgman
2010-02-05 20:14     ` Stefan Monnier
2010-02-05 20:18       ` Lennart Borgman
2010-02-06  1:10       ` Miles Bader
2010-02-05 23:51   ` Drew Adams
2010-02-05 19:04 ` Eli Zaretskii
2010-02-05 23:51   ` Drew Adams
2010-02-06  0:17     ` Lennart Borgman
2010-02-06  8:45       ` Eli Zaretskii
2010-02-06 16:55         ` Lennart Borgman
2010-02-06 19:12           ` Eli Zaretskii
2010-02-06 19:20             ` Lennart Borgman
2010-02-06  9:01     ` Eli Zaretskii
2010-02-06 15:33       ` Drew Adams
2010-02-06 19:33         ` Eli Zaretskii
2010-02-06 20:46           ` Drew Adams
2010-02-06 21:58             ` Eli Zaretskii
2010-02-06 23:12               ` Drew Adams [this message]
2010-02-07  4:01                 ` Eli Zaretskii
2010-02-08  1:38                 ` Stefan Monnier
2010-02-08  2:46                   ` Drew Adams
2010-02-26 18:33                 ` Davis Herring
2010-02-26 19:12                   ` Drew Adams
2010-02-26 19:35                     ` Davis Herring
2010-02-26 20:25                       ` Drew Adams
  -- strict thread matches above, loose matches on Subject: below --
2010-02-06  3:52 MON KEY
2010-02-06  8:28 ` Eli Zaretskii
     [not found]   ` <d2afcfda1002061814nc3e178fl5d93e21ea6bae7b5@mail.gmail.com>
2010-02-07  2:16     ` MON KEY
     [not found]     ` <83wrypelms.fsf@gnu.org>
2010-02-07 23:26       ` MON KEY
2010-02-08  0:28         ` Andreas Schwab
2010-02-08  4:10         ` Eli Zaretskii
     [not found]           ` <d2afcfda1002091330y53017b24w5e6bdf3c3d131a97@mail.gmail.com>
2010-02-09 21:32             ` MON KEY
2010-02-09 21:59               ` Andreas Schwab
2010-02-09 22:32             ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CBCE1B91725342F29EDB05C1E433A34C@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).