GNU bug report logs - #24057
25.1.50; ffap interprets comments beginning with "//" as file path

Previous Next

Full log

Message #51 received at 24057 <at> debbugs.gnu.org (full text, mbox):

From: Kaushal Modi <kaushal.modi <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24057 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#24057: 25.1.50; ffap interprets comments beginning with "//"
 as file path
Date: Mon, 25 Jul 2016 02:19:13 +0000

[Message part 1 (text/plain, inline)]

On Sun, Jul 24, 2016 at 10:17 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> I tried with a comment that begins like this:
>
>   ////share/foo
>
> and I don't think the proposed behavior will be correct in all cases.
> The problem is that comment-search-forward moves all the way past the
> leading 4 slashes, instead of only 2.


That is expected, as I posted in a table earlier:

|-----------------------------------+---------------------------------|
| Example string in `c-mode' buffer | Returned `ffap-string-at-point' |
|-----------------------------------+---------------------------------|
| x//tmp                            | "tmp"                           |
| //xtmp                            | "tmp"                           |
| x////tmp                          | "tmp"                           |
| ////xtmp                          | "tmp"                           |
| x// //tmp                         | ""                              |
| // //xtmp                         | "//tmp"                         |
|-----------------------------------+---------------------------------|

The problem with that is .. what is a user has a decorative comment like:

///I would like to
///share foo

It is not possible to know if the user liked to use "//" or "///" or "////"
or .. as the comment prefix. Also it is not possible to know if the user
meant "/share" or "//share".

So the best way to make the user's intent clear is by preceding the path
with a space. I can also create a patch with this info in the NEWS.

"// /share" -> User means "/share"
"// //share" -> User means "//share"
"/// /share" -> User means "/share"
"/// //share" -> User means "//share"

"//share" -> User means "share"
"///share" -> User means "share"
"////share" -> User means "share"
"/////share" -> User means "share"

Also thinking that the user meant "//share" in "////share" does not make
much sense. It's very confusing to count the number of slashes in there.
What is the user has "/////share" (5 slashes)? Where would we want the
ffap-string-at-point to guess the comment-starter<>comment boundary then?
We would rather have the user put a space to make it less confusing to read
the comment and also much simpler to implement the ffap parsing and much
less error prone.

While I can understand why the
> comment-start sequence should not be considered a potential file name,
> the stuff that follows it -- in this case, //share/foo -- should IMO
> be allowed to be a file name.
>

With the current state of ffap-string-at-point, it creates erroneous
behavior for many people including me. But with the patch, if a user needs
to put a path like "//share" in a comment for a major mode using "//" as
comment prefix, all they need to do is use a space to separate the two.
Also I think that it is very unlikely that someone would have a confusing
comment like "////share" where the user meant "//share" (or "/share").
-- 

Kaushal Modi

[Message part 2 (text/html, inline)]

Previous Next

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