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