GNU bug report logs - #8439
[PATCH] ffap.el -- detect paths with spaces

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Andrew W. Nosenko" <andrew.w.nosenko <at> gmail.com>
Cc: hochberg <at> dmhsoftware.com, Eli Zaretskii <eliz <at> gnu.org>, 8439 <at> debbugs.gnu.org, Jari Aalto <jari.aalto <at> cante.net>
Subject: bug#8439: [PATCH] ffap.el -- detect paths with spaces (v2)
Date: Fri, 19 Oct 2012 21:45:25 -0400

>> C:\emacs\bin\prog1.exe on Windows or /usr/bin/prog1 on Unix.
> Eli, excuse me very much, but you cheating.

I don't see the relationship with cheating.  Yes, his example is
probably not too important, but I think if we want to add support for
spaces we first need to decide which cases we want to handle, since the
general case is simply impossible.

Here are some disorganized thoughts:
- many of the examples shown in this thread have to do with "one file
  name per line".  But if noone tells us beforehand that the file name
  goes to EOL, handling these well will unavoidably end up with too many
  false positives.
- we should think of good hints for beginning/end of file names.
  E.g. I think if we find something that matches "['\">,.][ \n]", we
  should probably assume it's the end of the file name (EOFN).
  Or " /" is probably a BOFN, whereas "/ " is an EOFN.
- maybe if the separators are forward slashes, we should assume that
  there's no space in the file name.

> But, if there no way to make false positives amount small enough, I
> would to propose an idea for extension: find-file-at-region().  You
> just select a region of text, and Emacs tries to interprets it as
> default value for find-file().

M-w C-x C-f C-y already handles this case.


        Stefan

Previous Next

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