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

Previous Next

Package: emacs;

Reported by: Kaushal Modi <kaushal.modi <at> gmail.com>

Date: Fri, 22 Jul 2016 23:01:01 UTC

Severity: minor

Tags: fixed, patch

Merged with 7229, 8990

Found in versions 23.1, 23.3, 25.1.50

Fixed in version 26.1

Done: npostavs <at> users.sourceforge.net

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kaushal Modi <kaushal.modi <at> gmail.com>
Cc: 24057 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: bug#24057: 25.1.50; ffap interprets comments beginning with "//" as file path
Date: Sat, 23 Jul 2016 16:05:41 +0300
> From: Kaushal Modi <kaushal.modi <at> gmail.com>
> Date: Sat, 23 Jul 2016 11:56:40 +0000
> Cc: 24057 <at> debbugs.gnu.org, Noam Postavsky <npostavs <at> users.sourceforge.net>
> 
>  I see no reason to assume that file names cannot appear in comments.
> 
> I have already tested with these use cases and now it seems to do-the-right-thing:
> 
> In the below table, 'x' represents the point (the cursor would be on the character to its right).
> The second column shows the value that ffap-string-at-point is set to on doing C-x C-f (with the ido setup
> explained in the first email).
> 
> |-----------------------------------+---------------------------------|
> | 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" |
> |-----------------------------------+---------------------------------|
> 
> To try this out, paste the below in a new buffer and M-x c-mode.
> 
> //tmp
> ////tmp
> // //tmp
> 
> Now do C-x C-f with cursor at those 6 different points and you will see that an attempt to read /tmp happens
> only in the case of "// //tmp" when the point is anywhere in the "//tmp" portion following "// ".

Did you try this on some system where "//tmp" is a valid file name,
which is different from "/tmp"?




This bug report was last modified 8 years and 118 days ago.

Previous Next


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