On Sun, Jul 24, 2016 at 10:17 AM Eli Zaretskii <eliz@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