bug#24057: 25.1.50; ffap interprets comments beginning with "//" as file path

[Eli Zaretskii <eliz@gnu.org>]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Mon, 25 Jul 2016 02:19:13 +0000
> Cc: 24057@debbugs.gnu.org, npostavs@users.sourceforge.net
> 
>     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:

If I understood you correctly, the table you posted didn't cover
systems which support UNC file names, so you asked me to try on such a
system.  The above was my response to your request.

> 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".

IMO, it isn't Emacs's place to second-guess the user in a way that
prohibits valid use cases.

> So the best way to make the user's intent clear is by preceding the path with a space.

When there's whitespace between the comment leader and the rest, the
problem I'm talking about doesn't exist.

> 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?

If you want to code a backward-compatible solution, then skipping the
comment-start regexp should do, I think.  Where it stops, ffap should
start looking for valid file names.

> 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").

I see your point.  My point is that when we introduce
backward-incompatible behavior, which makes previously valid use cases
invalid, such incompatible behavior should initially be opt-in, even
if it looks to you that the previous behavior made no sense.  I have
enough gray hair to testify how such decisions in the past turned out
to be annoyances for some users.  Later, usually years later, we could
collect user experience and decide to make this the default behavior.

So if you disagree with my suggestion to skip comment-start instead of
using comment-search-forward, the behavior you propose should IMO be
off by default.

Thanks.