all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Daniel Colascione <dancol@dancol.org>
Cc: Emacs development discussions <emacs-devel@gnu.org>
Subject: Re: substitute-in-file-name is not distributive
Date: Tue, 30 Oct 2012 14:58:18 -0400	[thread overview]
Message-ID: <jwvehkflsfy.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <508FEBD8.8090505@dancol.org> (Daniel Colascione's message of "Tue, 30 Oct 2012 08:01:44 -0700")

>> Hmm... that's odd.  Can you give me some details:
>> - tell me exactly which text you typed in the minibuffer.
> I typed "c:\bin\" in the minibuffer and hit tab. After hitting tab, the
> minibuffer contained "c:/usr/bin", with point at the end.
>> - also tell me how the rfn-eshadow highlights the file name at each step.
> Now that you mention it, I do see that the leading "c:" in the
> minibuffer is highlighted.  That explains why we're substituting
> "c:/usr/bin" and not "/usr/bin".

Right.
The "c:" is highlighted because (s-i-f-n "c:\\bin") = (s-i-f-n "\\bin").
Now the problem is that when you replace \bin by /usr/bin suddenly that
same rule doesn't apply any more.

Hmm... I think the core of the problem here is that minibuffer
completion is actually only performed on "the current field" which is
usually the whole minibuffer content, but not with rfn-eshadow.
To fix this, we should invert the relationship between
minibuffer-complete and completion-in-region (i.e. minibuffer-complete
should call completion-in-region rather than the other way around).
This would probably be a good change, but we can't do it for 24.3.

You should be able to work around this problem by removing "field
shadow" from file-name-shadow-properties.

>> Right.  BTW I'm not convinced this is the right pattern to use for your
>> file-name-handler.  I think catching "\\[a-zA-Z]:" or something along
>> these lines might be a better choice.
> Not all paths I want to catch are absolute,

Why not?  Which non-absolute file names [we only use "path" for lists
of directories, as in $INFOPATH] would you need/want to rewrite?
Do you just want to replace \ with / in relative file names or is there
more to it?

> Even "absolute" paths can be drive-letter-relative and begin with
> a simple backslash.

Right, that's what triggers the above problem.

>> BTW, does Cygwin allow backslashes in file-names or does it interpret it
>> as a separator, like Windows does?
> Cygwin interprets backslashes as separators.

So Cygin itself treats "\\bin" and "/bin" as equivalent, but your
rewrite rules treat "\\bin" as a Windows file name and rewrite it to
"/usr/bin"?

If you limit yourself to:
- rewrite "\\`[a-zA-Z]:" to "/cygdrive/c" (regardless if it is followed
  by backslashes or forwardslashes).
- rewrite \ to / everywhere.
This should cover the main needs without tripping over the above problem.


        Stefan



  reply	other threads:[~2012-10-30 18:58 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-10  5:36 substitute-in-file-name is not distributive Daniel Colascione
2012-10-10  6:39 ` Andreas Schwab
2012-10-10 15:31 ` Eli Zaretskii
2012-10-10 16:48   ` Daniel Colascione
2012-10-10 17:18     ` Eli Zaretskii
2012-10-10 17:40       ` Daniel Colascione
2012-10-11  3:25   ` Stephen Leake
2012-10-25  3:20 ` Stefan Monnier
2012-10-25  3:28   ` Daniel Colascione
2012-10-27 16:08     ` Stefan Monnier
2012-10-28 19:09     ` Stefan Monnier
2012-10-30  4:10       ` Daniel Colascione
2012-10-30 13:15         ` Stefan Monnier
2012-10-30 15:01           ` Daniel Colascione
2012-10-30 18:58             ` Stefan Monnier [this message]
2012-10-30 20:12               ` Daniel Colascione
2012-10-30 21:24                 ` Stefan Monnier
2012-10-30 21:34                   ` Daniel Colascione
2012-10-31  3:41                     ` Stefan Monnier

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=jwvehkflsfy.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=dancol@dancol.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 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.