all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Stefan Monnier'" <monnier@iro.umontreal.ca>
Cc: 7617@debbugs.gnu.org
Subject: bug#7617: 24.0.50; `expand-file-name': removal of slashes
Date: Sun, 12 Dec 2010 20:32:12 -0800	[thread overview]
Message-ID: <8D21A82F766C4B0493597D9B294A7983@us.oracle.com> (raw)
In-Reply-To: <jwvy67u2v27.fsf-monnier+emacs@gnu.org>

> > I am using the function `expand*' on user input (one operation among
> > many), to do just what is advertised for `expand*'
> 
> There-s your problem.  You treat user input in a `read-file-name'
> as an actual file name (i.e. suitable to pass to functions like
> expand-file-name),

"Suitable to pass to functions like expand-file-name" is precisely the question
that you are begging.  That suitability is completely undefined so far.  Part of
this bug report asks that you document (a) just what is acceptable to
`expand-file-name' as "file-name" syntax (for each arg) and (b) what happens if
the arg is a string that is not of acceptable file-name syntax.

For (a) it is no doubt enough to say that it is whatever syntax is acceptable by
the current file system (if that is in fact the answer).  But that should be
stated explicitly, along with a description of (b).

> whereas it is actually a different beast, closely
> related, but different: it has this "..// -> /" and ".../~ -> 
> ~" rules, as well as env-var expansion (which also implies
> "$$ -> $" rewrite).  And even these special rules depend on
> file-name-handlers so, e.g., they do not apply to URLs but other
> rules may aaply to other special filenames.  I.e. the only safe
> thing to do is to first pass those strings through
> substitute-for-file-name.

Please read what I wrote.  I am looking for a function that gives the behavior
that is documented for `expand-file-name'.  That's all.

I do not want the slash-collapsing that also occurs but is (was before now)
undocumented.  And I do not want any of the input-transforming behavior provided
by `read-file-name' or `substitute-in-file-name'.  (I do not see any
`substitute-for-filename' function; I assume you meant `*-in-*'.)

In particular, I do not want ...// prefix removal or env var substitution.  I've
stated several times already that I am not looking for the behavior of
`substitute-in-file-name'.

If you do not regard the undocumented slash-collapsing of `expand-file-name' as
a bug, then I am obviously looking for a different function.  In any case, its
documented behavior (= the Emacs 20 behavior) is exactly what I am looking for.

Do you know a good way to get that behavior in Lisp?  I am getting it now by
calling `expand-file-name' within an envelope that restores any consecutive
slashes that get removed, but I'm looking for something less ugly.






  reply	other threads:[~2010-12-13  4:32 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-11 21:53 bug#7617: 24.0.50; `expand-file-name': removal of slashes Drew Adams
2010-12-12 15:58 ` Eli Zaretskii
2010-12-12 18:03   ` Drew Adams
2010-12-12 19:33     ` Eli Zaretskii
2010-12-12 20:21       ` Drew Adams
2010-12-12 20:32         ` Eli Zaretskii
2010-12-12 20:36           ` Drew Adams
2010-12-12 20:42         ` Andreas Schwab
2010-12-13  3:53         ` Stefan Monnier
2010-12-13  4:32           ` Drew Adams [this message]
2010-12-13  5:23             ` Eli Zaretskii
2010-12-13 14:51               ` Drew Adams
2010-12-13 15:17                 ` Eli Zaretskii
2010-12-13 15:47                   ` Drew Adams
2010-12-13 16:17                     ` Eli Zaretskii
2010-12-13 20:40                     ` Stefan Monnier
2010-12-12 22:35       ` Drew Adams
2010-12-12 23:40         ` Andreas Schwab
2010-12-13  5:17         ` Eli Zaretskii
2010-12-13 14:51           ` Drew Adams
2010-12-12 20:15     ` Andreas Schwab
2010-12-12 20:25       ` Drew Adams
2010-12-12 20:36         ` Andreas Schwab
2010-12-12 20:42           ` Drew Adams
2010-12-12 21:00             ` Andreas Schwab
2010-12-13  0:49     ` Jason Rumney
2010-12-12 20:39   ` Eli Zaretskii
2010-12-12 21:04 ` Andreas Schwab

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

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

  git send-email \
    --in-reply-to=8D21A82F766C4B0493597D9B294A7983@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=7617@debbugs.gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.