* bug#24057: 25.1.50; ffap interprets comments beginning with "//" as file path @ 2016-07-22 23:00 Kaushal Modi 2016-07-22 23:11 ` Kaushal Modi ` (2 more replies) 0 siblings, 3 replies; 30+ messages in thread From: Kaushal Modi @ 2016-07-22 23:00 UTC (permalink / raw) To: 24057 [-- Attachment #1: Type: text/plain, Size: 4509 bytes --] Hi all, I lived with this bug for a long time and then I lived with a patched ffap-string-at-point for a long time :) The bug is that if (1) a major mode uses "//" as comment start chars, and (2) ido-mode is enabled, and (3) ffap feature is enabled, and (4) user does C-x C-f on a comment like "//foo" attempt is made to access "//foo" path. It's a very corner case bug, but I hit is very often as I work most of the time in a major mode that uses "//" to comment lines (verilog-mode). Here is the recipe to reproduce this in emacs -Q: (1) emacs -Q (2) Evaluate: (progn (c-mode) (insert "//This is a comment") (ido-mode) (setq ido-use-filename-at-point 'guess) (re-search-backward "//" (line-beginning-position))) (3) Hit "C-x C-f" You will see that emacs is trying to look for a path "//This"! This must not happen. The proposed fix adds a little intelligence to skip the comment start chars in the string stored to ffap-string-at-point var. Here is the proposed patch generated ignoring white space. I will post a proper git formatted patch in a follow up email. ===== diff --git a/lisp/ffap.el b/lisp/ffap.el index 7013e6e..ba62012 100644 --- a/lisp/ffap.el +++ b/lisp/ffap.el @@ -1097,29 +1097,50 @@ ffap-string-at-point (defun ffap-string-at-point (&optional mode) "Return a string of characters from around point. + MODE (defaults to value of `major-mode') is a symbol used to look up string syntax parameters in `ffap-string-at-point-mode-alist'. + If MODE is not found, we use `file' instead of MODE. + If the region is active, return a string from the region. -Sets the variable `ffap-string-at-point' and the variable -`ffap-string-at-point-region'." + +If the point is in a comment, ensure that the returned string does not contain +the comment start characters (especially for major modes that have '//' as +comment start characters). + +Sets variables `ffap-string-at-point' and `ffap-string-at-point-region'. " (let* ((args (cdr (or (assq (or mode major-mode) ffap-string-at-point-mode-alist) (assq 'file ffap-string-at-point-mode-alist)))) + (region-selected (use-region-p)) (pt (point)) - (beg (if (use-region-p) + (beg (if region-selected (region-beginning) (save-excursion (skip-chars-backward (car args)) (skip-chars-forward (nth 1 args) pt) (point)))) - (end (if (use-region-p) + ;; If point is in a comment like "//abc" (in `c-mode'), and a + ;; region is not selected, return the position of 'a'. + (comment-start-pos (unless region-selected + (save-excursion + (goto-char beg) + (comment-search-forward + (line-end-position) :noerror) + (point)))) + (end (if region-selected (region-end) (save-excursion (skip-chars-forward (car args)) (skip-chars-backward (nth 2 args) pt) (point))))) + (when (and comment-start-pos + (> end comment-start-pos)) + (setq beg comment-start-pos)) + ;; (message "comment-start-pos = %d end = %d beg = %d" + ;; comment-start-pos end beg) (setq ffap-string-at-point (buffer-substring-no-properties (setcar ffap-string-at-point-region beg) ===== In GNU Emacs 25.1.50.10 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.23) of 2016-07-22 built on ... Repository revision: 03f32876210f3dd68c71baa210e523c3b7581758 Windowing system distributor 'The X.Org Foundation', version 11.0.60900000 System Description: Red Hat Enterprise Linux Workstation release 6.6 (Santiago) Configured using: 'configure --with-modules --prefix=/home/kmodi/usr_local/apps/6/emacs/master 'CPPFLAGS=-fgnu89-inline -I/home/kmodi/usr_local/6/include -I/usr/include/freetype2 -I/usr/include' 'CFLAGS=-ggdb3 -O0' 'CXXFLAGS=-ggdb3 -O0' 'LDFLAGS=-L/home/kmodi/usr_local/6/lib -L/home/kmodi/usr_local/6/lib64 -ggdb3'' Configured features: XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK2 X11 MODULES Important settings: value of $LANG: en_US.UTF-8 value of $XMODIFIERS: @im=none locale-coding-system: utf-8-unix -- Kaushal Modi [-- Attachment #2: Type: text/html, Size: 6710 bytes --] ^ permalink raw reply related [flat|nested] 30+ messages in thread
* bug#24057: 25.1.50; ffap interprets comments beginning with "//" as file path 2016-07-22 23:00 bug#24057: 25.1.50; ffap interprets comments beginning with "//" as file path Kaushal Modi @ 2016-07-22 23:11 ` Kaushal Modi 2016-07-23 1:26 ` npostavs 2016-07-23 7:34 ` Eli Zaretskii 2 siblings, 0 replies; 30+ messages in thread From: Kaushal Modi @ 2016-07-22 23:11 UTC (permalink / raw) To: 24057; +Cc: cyd [-- Attachment #1: Type: text/plain, Size: 4041 bytes --] I am copying the last 3 committers on this section of the code to review this patch. Patch follows: From a9e94ba5789d2b1d524120efecd3f9ab9af641cc Mon Sep 17 00:00:00 2001 From: Kaushal Modi <kaushal.modi@gmail.com> Date: Fri, 22 Jul 2016 18:58:29 -0400 Subject: [PATCH] Do not include comment start chars in ffap string * lisp/ffap.el (ffap-string-at-point): If the point is in a comment, ensure that the returned string does not contain the comment start characters (especially for major modes that have '//' as comment start characters). Otherwise, in a major mode like c-mode, with `ido-mode' enabled and `ido-use-filename-at-point' set to `guess', doing "C-x C-f" on a "//foo" comment will initiate an attempt to access a path "//foo" (Bug#24057). --- lisp/ffap.el | 63 ++++++++++++++++++++++++++++++++++++++++-------------------- 1 file changed, 42 insertions(+), 21 deletions(-) diff --git a/lisp/ffap.el b/lisp/ffap.el index 7013e6e..ba62012 100644 --- a/lisp/ffap.el +++ b/lisp/ffap.el @@ -1097,33 +1097,54 @@ ffap-string-at-point (defun ffap-string-at-point (&optional mode) "Return a string of characters from around point. + MODE (defaults to value of `major-mode') is a symbol used to look up string syntax parameters in `ffap-string-at-point-mode-alist'. + If MODE is not found, we use `file' instead of MODE. + If the region is active, return a string from the region. -Sets the variable `ffap-string-at-point' and the variable -`ffap-string-at-point-region'." + +If the point is in a comment, ensure that the returned string does not contain +the comment start characters (especially for major modes that have '//' as +comment start characters). + +Sets variables `ffap-string-at-point' and `ffap-string-at-point-region'. " (let* ((args - (cdr - (or (assq (or mode major-mode) ffap-string-at-point-mode-alist) - (assq 'file ffap-string-at-point-mode-alist)))) - (pt (point)) - (beg (if (use-region-p) - (region-beginning) - (save-excursion - (skip-chars-backward (car args)) - (skip-chars-forward (nth 1 args) pt) - (point)))) - (end (if (use-region-p) - (region-end) - (save-excursion - (skip-chars-forward (car args)) - (skip-chars-backward (nth 2 args) pt) - (point))))) + (cdr + (or (assq (or mode major-mode) ffap-string-at-point-mode-alist) + (assq 'file ffap-string-at-point-mode-alist)))) + (region-selected (use-region-p)) + (pt (point)) + (beg (if region-selected + (region-beginning) + (save-excursion + (skip-chars-backward (car args)) + (skip-chars-forward (nth 1 args) pt) + (point)))) + ;; If point is in a comment like "//abc" (in `c-mode'), and a + ;; region is not selected, return the position of 'a'. + (comment-start-pos (unless region-selected + (save-excursion + (goto-char beg) + (comment-search-forward + (line-end-position) :noerror) + (point)))) + (end (if region-selected + (region-end) + (save-excursion + (skip-chars-forward (car args)) + (skip-chars-backward (nth 2 args) pt) + (point))))) + (when (and comment-start-pos + (> end comment-start-pos)) + (setq beg comment-start-pos)) + ;; (message "comment-start-pos = %d end = %d beg = %d" + ;; comment-start-pos end beg) (setq ffap-string-at-point - (buffer-substring-no-properties - (setcar ffap-string-at-point-region beg) - (setcar (cdr ffap-string-at-point-region) end))))) + (buffer-substring-no-properties + (setcar ffap-string-at-point-region beg) + (setcar (cdr ffap-string-at-point-region) end))))) (defun ffap-string-around () ;; Sometimes useful to decide how to treat a string. -- 2.9.2 -- Kaushal Modi [-- Attachment #2: Type: text/html, Size: 6885 bytes --] ^ permalink raw reply related [flat|nested] 30+ messages in thread
* bug#24057: 25.1.50; ffap interprets comments beginning with "//" as file path 2016-07-22 23:00 bug#24057: 25.1.50; ffap interprets comments beginning with "//" as file path Kaushal Modi 2016-07-22 23:11 ` Kaushal Modi @ 2016-07-23 1:26 ` npostavs 2016-07-23 7:38 ` Eli Zaretskii 2016-07-23 7:34 ` Eli Zaretskii 2 siblings, 1 reply; 30+ messages in thread From: npostavs @ 2016-07-23 1:26 UTC (permalink / raw) To: Kaushal Modi; +Cc: 24057 Kaushal Modi <kaushal.modi@gmail.com> writes: > Hi all, > > I lived with this bug for a long time and then I lived with a patched ffap-string-at-point for a long time :) > > The bug is that if > > (1) a major mode uses "//" as comment start chars, and > (2) ido-mode is enabled, and > (3) ffap feature is enabled, and > (4) user does C-x C-f on a comment like "//foo" > > attempt is made to access "//foo" path. Is possibly a dup of #7229 and/or #8990? ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#24057: 25.1.50; ffap interprets comments beginning with "//" as file path 2016-07-23 1:26 ` npostavs @ 2016-07-23 7:38 ` Eli Zaretskii 0 siblings, 0 replies; 30+ messages in thread From: Eli Zaretskii @ 2016-07-23 7:38 UTC (permalink / raw) To: npostavs; +Cc: 24057, kaushal.modi > From: npostavs@users.sourceforge.net > Date: Fri, 22 Jul 2016 21:26:45 -0400 > Cc: 24057@debbugs.gnu.org > > Is possibly a dup of #7229 and/or #8990? Yes, please merge all those. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#24057: 25.1.50; ffap interprets comments beginning with "//" as file path 2016-07-22 23:00 bug#24057: 25.1.50; ffap interprets comments beginning with "//" as file path Kaushal Modi 2016-07-22 23:11 ` Kaushal Modi 2016-07-23 1:26 ` npostavs @ 2016-07-23 7:34 ` Eli Zaretskii 2016-07-23 11:56 ` Kaushal Modi 2 siblings, 1 reply; 30+ messages in thread From: Eli Zaretskii @ 2016-07-23 7:34 UTC (permalink / raw) To: Kaushal Modi; +Cc: 24057 > From: Kaushal Modi <kaushal.modi@gmail.com> > Date: Fri, 22 Jul 2016 23:00:00 +0000 > > (1) a major mode uses "//" as comment start chars, and > (2) ido-mode is enabled, and > (3) ffap feature is enabled, and > (4) user does C-x C-f on a comment like "//foo" > > attempt is made to access "//foo" path. I see no reason to assume that file names cannot appear in comments. > (3) Hit "C-x C-f" > > You will see that emacs is trying to look for a path "//This"! > > This must not happen. I could agree with a user option to disable this behavior, but disabling it unconditionally is IMO a mistake. Thanks. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#24057: 25.1.50; ffap interprets comments beginning with "//" as file path 2016-07-23 7:34 ` Eli Zaretskii @ 2016-07-23 11:56 ` Kaushal Modi 2016-07-23 13:05 ` Eli Zaretskii 0 siblings, 1 reply; 30+ messages in thread From: Kaushal Modi @ 2016-07-23 11:56 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 24057, Noam Postavsky [-- Attachment #1: Type: text/plain, Size: 1736 bytes --] On Sat, Jul 23, 2016 at 3:34 AM Eli Zaretskii <eliz@gnu.org> wrote: > 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 "// ". I could agree with a user option to disable this behavior, but > disabling it unconditionally is IMO a mistake. > Of course, if this patch returns in unintended ffap-string-at-point, I will add a defcustom to enable this behavior. -- Kaushal Modi [-- Attachment #2: Type: text/html, Size: 3293 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#24057: 25.1.50; ffap interprets comments beginning with "//" as file path 2016-07-23 11:56 ` Kaushal Modi @ 2016-07-23 13:05 ` Eli Zaretskii 2016-07-23 13:23 ` Kaushal Modi 0 siblings, 1 reply; 30+ messages in thread From: Eli Zaretskii @ 2016-07-23 13:05 UTC (permalink / raw) To: Kaushal Modi; +Cc: 24057, npostavs > From: Kaushal Modi <kaushal.modi@gmail.com> > Date: Sat, 23 Jul 2016 11:56:40 +0000 > Cc: 24057@debbugs.gnu.org, Noam Postavsky <npostavs@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"? ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#24057: 25.1.50; ffap interprets comments beginning with "//" as file path 2016-07-23 13:05 ` Eli Zaretskii @ 2016-07-23 13:23 ` Kaushal Modi 2016-07-23 13:59 ` Eli Zaretskii 0 siblings, 1 reply; 30+ messages in thread From: Kaushal Modi @ 2016-07-23 13:23 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 24057, npostavs [-- Attachment #1: Type: text/plain, Size: 825 bytes --] On Sat, Jul 23, 2016 at 9:05 AM Eli Zaretskii <eliz@gnu.org> wrote: > Did you try this on some system where "//tmp" is a valid file name, > which is different from "/tmp"? > I have never dealt with such files. My brief attempt just to try creating such a file failed: km²~/temp/:> touch '//abc' touch: cannot touch `//abc': Permission denied km²~/temp/:> touch '\/\/abc' touch: cannot touch `\\/\\/abc': No such file or directory Can you show how to recreate the issue that you are thinking? Or can you try recreating the problem on your system with this patch? Or, should this patch anyways go in the master, and we let the emacs-devel give us feedback if this results in anything unexpected? I have used this patch in my config for few years now without any issue. -- Kaushal Modi [-- Attachment #2: Type: text/html, Size: 1594 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#24057: 25.1.50; ffap interprets comments beginning with "//" as file path 2016-07-23 13:23 ` Kaushal Modi @ 2016-07-23 13:59 ` Eli Zaretskii 2016-07-23 18:02 ` Noam Postavsky 2016-07-23 21:51 ` Kaushal Modi 0 siblings, 2 replies; 30+ messages in thread From: Eli Zaretskii @ 2016-07-23 13:59 UTC (permalink / raw) To: Kaushal Modi; +Cc: 24057, npostavs > From: Kaushal Modi <kaushal.modi@gmail.com> > Date: Sat, 23 Jul 2016 13:23:08 +0000 > Cc: 24057@debbugs.gnu.org, npostavs@users.sourceforge.net > > Did you try this on some system where "//tmp" is a valid file name, > which is different from "/tmp"? > > I have never dealt with such files. > > My brief attempt just to try creating such a file failed: > > km²~/temp/:> touch '//abc' > touch: cannot touch `//abc': Permission denied > km²~/temp/:> touch '\/\/abc' > touch: cannot touch `\\/\\/abc': No such file or directory > > Can you show how to recreate the issue that you are thinking? You need to be on a system that supports that. Windows is one of them; not sure if there are any others left nowadays. > Or can you try recreating the problem on your system with this patch? I didn't try. > Or, should this patch anyways go in the master, and we let the emacs-devel give us feedback if this results in > anything unexpected? It should definitely go to master only. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#24057: 25.1.50; ffap interprets comments beginning with "//" as file path 2016-07-23 13:59 ` Eli Zaretskii @ 2016-07-23 18:02 ` Noam Postavsky 2016-07-23 18:20 ` Eli Zaretskii 2016-07-23 18:22 ` Eli Zaretskii 2016-07-23 21:51 ` Kaushal Modi 1 sibling, 2 replies; 30+ messages in thread From: Noam Postavsky @ 2016-07-23 18:02 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 24057, Kaushal Modi On Sat, Jul 23, 2016 at 9:59 AM, Eli Zaretskii <eliz@gnu.org> wrote: >> Did you try this on some system where "//tmp" is a valid file name, >> which is different from "/tmp"? > You need to be on a system that supports that. Windows is one of > them; not sure if there are any others left nowadays. How does it work? C:\Users\npostavs>echo foo > //tmp The specified path is invalid. In Emacs: Saving file //tmp... Directory `//' does not exist; create? (y or n) y basic-save-buffer-2: //: no such directory This is on a newly-upgraded-to-Windows-10 box, Emacs 24.5 ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#24057: 25.1.50; ffap interprets comments beginning with "//" as file path 2016-07-23 18:02 ` Noam Postavsky @ 2016-07-23 18:20 ` Eli Zaretskii 2016-07-23 18:22 ` Eli Zaretskii 1 sibling, 0 replies; 30+ messages in thread From: Eli Zaretskii @ 2016-07-23 18:20 UTC (permalink / raw) To: Noam Postavsky; +Cc: 24057, kaushal.modi > From: Noam Postavsky <npostavs@users.sourceforge.net> > Date: Sat, 23 Jul 2016 14:02:36 -0400 > Cc: Kaushal Modi <kaushal.modi@gmail.com>, 24057@debbugs.gnu.org > > On Sat, Jul 23, 2016 at 9:59 AM, Eli Zaretskii <eliz@gnu.org> wrote: > >> Did you try this on some system where "//tmp" is a valid file name, > >> which is different from "/tmp"? > > You need to be on a system that supports that. Windows is one of > > them; not sure if there are any others left nowadays. > > How does it work? > > C:\Users\npostavs>echo foo > //tmp > The specified path is invalid. > > In Emacs: > > Saving file //tmp... > Directory `//' does not exist; create? (y or n) y > basic-save-buffer-2: //: no such directory > > This is on a newly-upgraded-to-Windows-10 box, Emacs 24.5 It's a UNC notation. Normally used for network shares. If you want to use this locally, you will need to create a share first. Valid UNC file/directory names look like //machine/share. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#24057: 25.1.50; ffap interprets comments beginning with "//" as file path 2016-07-23 18:02 ` Noam Postavsky 2016-07-23 18:20 ` Eli Zaretskii @ 2016-07-23 18:22 ` Eli Zaretskii 1 sibling, 0 replies; 30+ messages in thread From: Eli Zaretskii @ 2016-07-23 18:22 UTC (permalink / raw) To: Noam Postavsky; +Cc: 24057, kaushal.modi > From: Noam Postavsky <npostavs@users.sourceforge.net> > Date: Sat, 23 Jul 2016 14:02:36 -0400 > Cc: Kaushal Modi <kaushal.modi@gmail.com>, 24057@debbugs.gnu.org > > How does it work? > > C:\Users\npostavs>echo foo > //tmp > The specified path is invalid. Oh, and of course you cannot use forward slashes in CMD, you need to use backslashes instead, as in \\tmp\foo. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#24057: 25.1.50; ffap interprets comments beginning with "//" as file path 2016-07-23 13:59 ` Eli Zaretskii 2016-07-23 18:02 ` Noam Postavsky @ 2016-07-23 21:51 ` Kaushal Modi 2016-07-24 14:16 ` Eli Zaretskii 1 sibling, 1 reply; 30+ messages in thread From: Kaushal Modi @ 2016-07-23 21:51 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 24057, npostavs [-- Attachment #1: Type: text/plain, Size: 793 bytes --] On Sat, Jul 23, 2016 at 9:59 AM Eli Zaretskii <eliz@gnu.org> wrote: > You need to be on a system that supports that. Windows is one of > them; not sure if there are any others left nowadays. > > > Or can you try recreating the problem on your system with this patch? > > I didn't try. > Can you please try it out and see if this patch causes any issue with such paths? I believe that if you have "// //share/foo", it should still work fine. > > Or, should this patch anyways go in the master, and we let the > emacs-devel give us feedback if this results in > > anything unexpected? > > It should definitely go to master only. > Correct, I meant to emphasize that the patch be committed without a defcustom to begin with .. and then we can add the defcustom if needed. -- Kaushal Modi [-- Attachment #2: Type: text/html, Size: 1356 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#24057: 25.1.50; ffap interprets comments beginning with "//" as file path 2016-07-23 21:51 ` Kaushal Modi @ 2016-07-24 14:16 ` Eli Zaretskii 2016-07-25 2:19 ` Kaushal Modi 0 siblings, 1 reply; 30+ messages in thread From: Eli Zaretskii @ 2016-07-24 14:16 UTC (permalink / raw) To: Kaushal Modi; +Cc: 24057, npostavs > From: Kaushal Modi <kaushal.modi@gmail.com> > Date: Sat, 23 Jul 2016 21:51:47 +0000 > Cc: 24057@debbugs.gnu.org, npostavs@users.sourceforge.net > > You need to be on a system that supports that. Windows is one of > them; not sure if there are any others left nowadays. > > > Or can you try recreating the problem on your system with this patch? > > I didn't try. > > Can you please try it out and see if this patch causes any issue with such paths? I believe that if you have "// > //share/foo", it should still work fine. 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. 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. Thanks. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#24057: 25.1.50; ffap interprets comments beginning with "//" as file path 2016-07-24 14:16 ` Eli Zaretskii @ 2016-07-25 2:19 ` Kaushal Modi 2016-07-25 17:02 ` Eli Zaretskii 0 siblings, 1 reply; 30+ messages in thread From: Kaushal Modi @ 2016-07-25 2:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 24057, npostavs [-- Attachment #1: Type: text/plain, Size: 2930 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 6082 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#24057: 25.1.50; ffap interprets comments beginning with "//" as file path 2016-07-25 2:19 ` Kaushal Modi @ 2016-07-25 17:02 ` Eli Zaretskii 2016-07-25 17:13 ` Kaushal Modi 0 siblings, 1 reply; 30+ messages in thread From: Eli Zaretskii @ 2016-07-25 17:02 UTC (permalink / raw) To: Kaushal Modi; +Cc: 24057, npostavs > 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#24057: 25.1.50; ffap interprets comments beginning with "//" as file path 2016-07-25 17:02 ` Eli Zaretskii @ 2016-07-25 17:13 ` Kaushal Modi 2016-07-25 17:24 ` Eli Zaretskii 0 siblings, 1 reply; 30+ messages in thread From: Kaushal Modi @ 2016-07-25 17:13 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 24057, npostavs [-- Attachment #1: Type: text/plain, Size: 3603 bytes --] On Mon, Jul 25, 2016 at 1:03 PM Eli Zaretskii <eliz@gnu.org> wrote: > 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. > Thanks. AFAIU, ffap-string-at-point basically deals with just parsing the string and does not check if a path is valid. So the "////tmp" example in the table should apply to any use case. > > 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. > OK. > > 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. > Thanks for confirming that. > 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. > I thought about the comment-start variable, but for c-mode C-h v comment-start gives "/* " and C-h v comment-start-skip gives "\\(//+\\|/\\*+\\)\\s *" So it will take "/" followed by 1 or more "/" as comment start. > > 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. Thanks. > 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. > If the new behavior is not made the default then we will never know if it causes user annoyance. 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. > If that's the only way forward, I will add a defcustom in the next patch. But it doesn't feel right. A defcustom is being created for a very corner case. Even if I agree with that, it does not feel right to set its default value so that the buggy behavior is retained by default just to backward compatibility sake. How about we add the defcustom and set the default value so that this bug is fixed. And we wait for people using the master branch to report any issues caused by this. Also we let emacs-devel know that this defcustom is going in. -- Kaushal Modi [-- Attachment #2: Type: text/html, Size: 5331 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#24057: 25.1.50; ffap interprets comments beginning with "//" as file path 2016-07-25 17:13 ` Kaushal Modi @ 2016-07-25 17:24 ` Eli Zaretskii 2016-07-25 18:13 ` Kaushal Modi 0 siblings, 1 reply; 30+ messages in thread From: Eli Zaretskii @ 2016-07-25 17:24 UTC (permalink / raw) To: Kaushal Modi; +Cc: 24057, npostavs > From: Kaushal Modi <kaushal.modi@gmail.com> > Date: Mon, 25 Jul 2016 17:13:51 +0000 > Cc: 24057@debbugs.gnu.org, npostavs@users.sourceforge.net > > 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. > > If that's the only way forward, I will add a defcustom in the next patch. But it doesn't feel right. A defcustom is > being created for a very corner case. Even if I agree with that, it does not feel right to set its default value so > that the buggy behavior is retained by default just to backward compatibility sake. Not sure which behavior you call "buggy". I'm okay with unconditionally skipping the comment leader string, such as "//" in C/C++ case. If you want to skip more than that, I think skipping the rest should be optional, defaulting to off. How's that "buggy"? > How about we add the defcustom and set the default value so that this bug is fixed. And we wait for people > using the master branch to report any issues caused by this. Also we let emacs-devel know that this > defcustom is going in. I don't want us to introduce backward-incompatible behavior, except when strictly necessary. In this case, skipping the initial "//" is necessary, but skipping more slashes is not. Thanks. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#24057: 25.1.50; ffap interprets comments beginning with "//" as file path 2016-07-25 17:24 ` Eli Zaretskii @ 2016-07-25 18:13 ` Kaushal Modi 2016-07-25 20:18 ` Kaushal Modi 0 siblings, 1 reply; 30+ messages in thread From: Kaushal Modi @ 2016-07-25 18:13 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 24057, npostavs [-- Attachment #1: Type: text/plain, Size: 4328 bytes --] On Mon, Jul 25, 2016 at 1:24 PM Eli Zaretskii <eliz@gnu.org> wrote: > Not sure which behavior you call "buggy". I'm okay with > unconditionally skipping the comment leader string, such as "//" in > C/C++ case. If you want to skip more than that, I think skipping the > rest should be optional, defaulting to off. How's that "buggy"? > Thanks for the clarification. I thought that you were suggesting to have a defcustom that would either use or not use comment-search-forward in ffap-string-at-point with the default set such that the old (current) behavior of not skipping the comment starter at all is retained. I refer to this "not skipping the comment starter at all" behavior as buggy. > > How about we add the defcustom and set the default value so that this > bug is fixed. And we wait for people > > using the master branch to report any issues caused by this. Also we let > emacs-devel know that this > > defcustom is going in. > > I don't want us to introduce backward-incompatible behavior, except > when strictly necessary. In this case, skipping the initial "//" is > necessary, but skipping more slashes is not. > Understood. In that case, the code will have to be made more complex... Here's a quick attempt .. Can you please have a look at it? (defun modi/ffap-string-at-point (&optional mode) "Return a string of characters from around point. MODE (defaults to value of `major-mode') is a symbol used to look up string syntax parameters in `ffap-string-at-point-mode-alist'. If MODE is not found, we use `file' instead of MODE. If the region is active,return a string from the region. If the point is in a comment, ensure that the returned string does not contain the comment start characters (especially for major modes that have '//' as comment start characters). Sets variables `ffap-string-at-point' and `ffap-string-at-point-region'. " (let* ((args (cdr (or (assq (or mode major-mode) ffap-string-at-point-mode-alist) (assq 'file ffap-string-at-point-mode-alist)))) (region-selected (use-region-p)) (pt (point)) (beg (if region-selected (region-beginning) (save-excursion (skip-chars-backward (car args)) (skip-chars-forward (nth 1 args) pt) (point)))) (end (if region-selected (region-end) (save-excursion (skip-chars-forward (car args)) (skip-chars-backward (nth 2 args) pt) (point)))) beg-temp) ;; Ensure that if "//" is a valid comment starter in the current major ;; mode, then that is removed from the returned string. (when (and (null region-selected) ;; Check if the first character is '/' and not part of the ;; comment (save-excursion (goto-char beg) (and (looking-at "/") (null (nth 4 (syntax-ppss))))) ;; Check if the second character is '/' and also not part of ;; the comment (setq beg-temp (+ 1 beg)) (if (> end beg-temp) (save-excursion (goto-char beg-temp) (and (looking-at "/") (null (nth 4 (syntax-ppss))))) nil)) ;; Check if the third character *is* part of the comment (setq beg-temp (+ 2 beg)) (if (> end beg-temp) (save-excursion (goto-char beg-temp) (when (nth 4 (syntax-ppss)) (setq beg beg-temp))))) (message "beg = %d beg-temp = %S end = %d " beg beg-temp end) (prog1 (setq ffap-string-at-point (buffer-substring-no-properties (setcar ffap-string-at-point-region beg) (setcar (cdr ffap-string-at-point-region) end))) (message "dbg: %S" ffap-string-at-point) ))) (advice-add 'ffap-string-at-point :override #'modi/ffap-string-at-point) -- Kaushal Modi [-- Attachment #2: Type: text/html, Size: 6530 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#24057: 25.1.50; ffap interprets comments beginning with "//" as file path 2016-07-25 18:13 ` Kaushal Modi @ 2016-07-25 20:18 ` Kaushal Modi 2016-07-26 14:41 ` Eli Zaretskii 2017-03-17 2:10 ` npostavs 0 siblings, 2 replies; 30+ messages in thread From: Kaushal Modi @ 2016-07-25 20:18 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 24057, npostavs [-- Attachment #1: Type: text/plain, Size: 6268 bytes --] Here a git formatted patch .. it's an optimized, generic version of the snippet in my previous email. It's now "/" agnostic. Here's the new table of expected values of ffap-string-at-point: (x indicates the (point)) |-----------------------------------+---------------------------------| | Example string in `c-mode' buffer | Returned `ffap-string-at-point' | |-----------------------------------+---------------------------------| | x//tmp | "tmp" | | //xtmp | "tmp" | | x///tmp | "/tmp" | | //x/tmp | "/tmp" | | x////tmp | "//tmp" | | ////xtmp | "//tmp" | | x// //tmp | "" | | // x/tmp | "/tmp" | | // x//tmp | "//tmp" | |-----------------------------------+---------------------------------| ===== Patch follows From 5e000cebb993a8cdccdf5e67f6b0eb66b4a267d8 Mon Sep 17 00:00:00 2001 From: Kaushal Modi <kaushal.modi@gmail.com> Date: Mon, 25 Jul 2016 16:08:50 -0400 Subject: [PATCH] Do not include comment start chars in ffap string * lisp/ffap.el (ffap-string-at-point): If the point is in a comment, ensure that the returned string does not contain the comment start characters (especially for major modes that have '//' as comment start characters). Otherwise, in a major mode like c-mode, with `ido-mode' enabled and `ido-use-filename-at-point' set to `guess', doing "C-x C-f" on a "//foo" comment will initiate an attempt to access a path "//foo" (Bug#24057). --- lisp/ffap.el | 87 +++++++++++++++++++++++++++++++++++++++++++++--------------- 1 file changed, 65 insertions(+), 22 deletions(-) diff --git a/lisp/ffap.el b/lisp/ffap.el index 7013e6e..8708a17 100644 --- a/lisp/ffap.el +++ b/lisp/ffap.el @@ -1097,33 +1097,76 @@ ffap-string-at-point (defun ffap-string-at-point (&optional mode) "Return a string of characters from around point. + MODE (defaults to value of `major-mode') is a symbol used to look up string syntax parameters in `ffap-string-at-point-mode-alist'. + If MODE is not found, we use `file' instead of MODE. -If the region is active, return a string from the region. -Sets the variable `ffap-string-at-point' and the variable -`ffap-string-at-point-region'." + +If the region is active,return a string from the region. + +If the point is in a comment, ensure that the returned string does not contain +the comment start characters (especially for major modes that have '//' as +comment start characters). + +Sets variables `ffap-string-at-point' and `ffap-string-at-point-region'. " (let* ((args - (cdr - (or (assq (or mode major-mode) ffap-string-at-point-mode-alist) - (assq 'file ffap-string-at-point-mode-alist)))) - (pt (point)) - (beg (if (use-region-p) - (region-beginning) - (save-excursion - (skip-chars-backward (car args)) - (skip-chars-forward (nth 1 args) pt) - (point)))) - (end (if (use-region-p) - (region-end) - (save-excursion - (skip-chars-forward (car args)) - (skip-chars-backward (nth 2 args) pt) - (point))))) + (cdr + (or (assq (or mode major-mode) ffap-string-at-point-mode-alist) + (assq 'file ffap-string-at-point-mode-alist)))) + (region-selected (use-region-p)) + (pt (point)) + (beg (if region-selected + (region-beginning) + (save-excursion + (skip-chars-backward (car args)) + (skip-chars-forward (nth 1 args) pt) + (point)))) + (end (if region-selected + (region-end) + (save-excursion + (skip-chars-forward (car args)) + (skip-chars-backward (nth 2 args) pt) + (point)))) + (beg-new beg)) + ;; (message "ffap-string-at-point dbg: beg = %d end = %d" beg end) + ;; If the initial characters of the to-be-returned string are the + ;; current major mode's comment starter characters, *and* are not + ;; part of a comment, remove those from the returned string + ;; (Bug#24057). + ;; Example comments in `c-mode' (which considers lines beginning + ;; with "//" as comments): + ;; //tmp - This is a comment. It does not contain any path reference. + ;; ///tmp - This is a comment. The "/tmp" portion in that is a path. + ;; ////tmp - This is a comment. The "//tmp" portion in that is a path. + (when (and + ;; Proceed if no region is selected by the user. + (null region-selected) + ;; Check if END character is part of a comment. + (save-excursion + (goto-char end) + (nth 4 (syntax-ppss)))) + (save-excursion + ;; Increment BEG till point at BEG is in a comment too. + ;; (nth 4 (syntax-ppss)) will be null for comment start + ;; characters (for example, for the "//" characters in + ;; `c-mode' line comments). + (setq beg (catch 'break + (while (< beg-new end) + (goto-char beg-new) + (if (nth 4 (syntax-ppss)) ; in a comment + (throw 'break beg-new) + (setq beg-new (1+ beg-new)))) + end)))) ; Set BEG to END if no throw happens + ;; (message "ffap-string-at-point dbg: beg = %d beg-new = %d" + ;; beg beg-new) (setq ffap-string-at-point - (buffer-substring-no-properties - (setcar ffap-string-at-point-region beg) - (setcar (cdr ffap-string-at-point-region) end))))) + (buffer-substring-no-properties + (setcar ffap-string-at-point-region beg) + (setcar (cdr ffap-string-at-point-region) end))) + ;; (message "ffap-string-at-point dbg: ffap-string-at-point = %S" + ;; ffap-string-at-point) + ffap-string-at-point)) (defun ffap-string-around () ;; Sometimes useful to decide how to treat a string. -- 2.9.2 -- Kaushal Modi [-- Attachment #2: Type: text/html, Size: 10390 bytes --] ^ permalink raw reply related [flat|nested] 30+ messages in thread
* bug#24057: 25.1.50; ffap interprets comments beginning with "//" as file path 2016-07-25 20:18 ` Kaushal Modi @ 2016-07-26 14:41 ` Eli Zaretskii 2016-07-26 15:11 ` Kaushal Modi 2017-03-17 2:10 ` npostavs 1 sibling, 1 reply; 30+ messages in thread From: Eli Zaretskii @ 2016-07-26 14:41 UTC (permalink / raw) To: Kaushal Modi; +Cc: 24057, npostavs > From: Kaushal Modi <kaushal.modi@gmail.com> > Date: Mon, 25 Jul 2016 20:18:27 +0000 > Cc: 24057@debbugs.gnu.org, npostavs@users.sourceforge.net > > Here a git formatted patch .. it's an optimized, generic version of the > snippet in my previous email. It's now "/" agnostic. Thanks. Most of the patch looks like whitespace changes? > + (setq beg (catch 'break > + (while (< beg-new end) > + (goto-char beg-new) > + (if (nth 4 (syntax-ppss)) ; in a comment > + (throw 'break beg-new) > + (setq beg-new (1+ beg-new)))) > + end)))) ; Set BEG to END if no throw happens Is there any problem with a more conventional while loop that stops when syntax-ppss has its 5th element non-nil? Why did you need to use throw and catch here? ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#24057: 25.1.50; ffap interprets comments beginning with "//" as file path 2016-07-26 14:41 ` Eli Zaretskii @ 2016-07-26 15:11 ` Kaushal Modi 0 siblings, 0 replies; 30+ messages in thread From: Kaushal Modi @ 2016-07-26 15:11 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 24057, npostavs [-- Attachment #1: Type: text/plain, Size: 5129 bytes --] On Tue, Jul 26, 2016 at 10:42 AM Eli Zaretskii <eliz@gnu.org> wrote: > > Here a git formatted patch .. it's an optimized, generic version of the > > snippet in my previous email. It's now "/" agnostic. > > Thanks. Most of the patch looks like whitespace changes? > I selected the whole defun and did auto-ident (C-M-\). The submitted patch was a result of that. I thought it's a good idea to update the indentation of the whole function. May be the lisp-indent-function changed since this function was updated last time? In any case, here is the patch ignoring whitespace changes. Note of caution that the indentation will look messed up when you merge this patch: ===== diff --git a/lisp/ffap.el b/lisp/ffap.el index 7013e6e..d1bca04 100644 --- a/lisp/ffap.el +++ b/lisp/ffap.el @@ -1097,33 +1097,73 @@ ffap-string-at-point (defun ffap-string-at-point (&optional mode) "Return a string of characters from around point. + MODE (defaults to value of `major-mode') is a symbol used to look up string syntax parameters in `ffap-string-at-point-mode-alist'. + If MODE is not found, we use `file' instead of MODE. + If the region is active,return a string from the region. -Sets the variable `ffap-string-at-point' and the variable -`ffap-string-at-point-region'." + +If the point is in a comment, ensure that the returned string does not contain +the comment start characters (especially for major modes that have '//' as +comment start characters). + +Sets variables `ffap-string-at-point' and `ffap-string-at-point-region'. " (let* ((args (cdr (or (assq (or mode major-mode) ffap-string-at-point-mode-alist) (assq 'file ffap-string-at-point-mode-alist)))) + (region-selected (use-region-p)) (pt (point)) - (beg (if (use-region-p) + (beg (if region-selected (region-beginning) (save-excursion (skip-chars-backward (car args)) (skip-chars-forward (nth 1 args) pt) (point)))) - (end (if (use-region-p) + (end (if region-selected (region-end) (save-excursion (skip-chars-forward (car args)) (skip-chars-backward (nth 2 args) pt) - (point))))) + (point)))) + (beg-new beg)) + ;; (message "ffap-string-at-point dbg: beg = %d end = %d" beg end) + ;; If the initial characters of the to-be-returned string are the + ;; current major mode's comment starter characters, *and* are not part + ;; of a comment, remove those from the returned string (Bug#24057). + ;; Example comments in `c-mode' (which considers lines beginning with + ;; "//" as comments): + ;; //tmp - This is a comment. It does not contain any path reference. + ;; ///tmp - This is a comment. The "/tmp" portion in that is a path. + ;; ////tmp - This is a comment. The "//tmp" portion in that is a path. + (when (and + ;; Proceed if no region is selected by the user. + (null region-selected) + ;; Check if END character is part of a comment. + (save-excursion + (goto-char end) + (nth 4 (syntax-ppss)))) + (save-excursion + ;; Increment BEG till point at BEG is in a comment too. + ;; (nth 4 (syntax-ppss)) will be nil for comment start characters + ;; (for example, for the "//" characters in `c-mode' line comments). + (setq beg (catch 'break + (while (< beg-new end) + (goto-char beg-new) + (if (nth 4 (syntax-ppss)) ; in a comment + (throw 'break beg-new) + (setq beg-new (1+ beg-new)))) + end)))) ; Set BEG to END if no throw happens + ;; (message "ffap-string-at-point dbg: beg = %d beg-new = %d" beg beg-new) (setq ffap-string-at-point (buffer-substring-no-properties (setcar ffap-string-at-point-region beg) - (setcar (cdr ffap-string-at-point-region) end))))) + (setcar (cdr ffap-string-at-point-region) end))) + ;; (message "ffap-string-at-point dbg: ffap-string-at-point = %S" + ;; ffap-string-at-point) + ffap-string-at-point)) (defun ffap-string-around () ;; Sometimes useful to decide how to treat a string. ===== > + (setq beg (catch 'break > > + (while (< beg-new end) > > + (goto-char beg-new) > > + (if (nth 4 (syntax-ppss)) ; in a comment > > + (throw 'break beg-new) > > + (setq beg-new (1+ beg-new)))) > > + end)))) ; Set BEG to END if no throw happens > > Is there any problem with a more conventional while loop that stops > when syntax-ppss has its 5th element non-nil? Why did you need to use > throw and catch here? > Throw and catch just feels more intuitive to me. This construct also sets beg to end if no throw happens. It's just a difference of style; feel free to refactor it. -- Kaushal Modi [-- Attachment #2: Type: text/html, Size: 7645 bytes --] ^ permalink raw reply related [flat|nested] 30+ messages in thread
* bug#24057: 25.1.50; ffap interprets comments beginning with "//" as file path 2016-07-25 20:18 ` Kaushal Modi 2016-07-26 14:41 ` Eli Zaretskii @ 2017-03-17 2:10 ` npostavs 2017-03-17 2:13 ` npostavs 2017-03-17 22:16 ` Kaushal Modi 1 sibling, 2 replies; 30+ messages in thread From: npostavs @ 2017-03-17 2:10 UTC (permalink / raw) To: Kaushal Modi; +Cc: 24057 Kaushal Modi <kaushal.modi@gmail.com> writes: > * lisp/ffap.el (ffap-string-at-point): If the point is in a comment, > ensure that the returned string does not contain the comment start > characters (especially for major modes that have '//' as comment start > characters). > Why is there a blank line here? > Otherwise, in a major mode like c-mode, with `ido-mode' enabled and > `ido-use-filename-at-point' set to `guess', doing "C-x C-f" on a "//foo" > comment will initiate an attempt to access a path "//foo" (Bug#24057). > --- > + ;; (message "ffap-string-at-point dbg: beg = %d end = %d" beg end) This can be removed. > + ;; Check if END character is part of a comment. > + (save-excursion > + (goto-char end) > + (nth 4 (syntax-ppss)))) This could be just (nth 4 (syntax-ppss end)). > + (save-excursion > + ;; Increment BEG till point at BEG is in a comment too. > + ;; (nth 4 (syntax-ppss)) will be null for comment start > + ;; characters (for example, for the "//" characters in > + ;; `c-mode' line comments). > + (setq beg (catch 'break > + (while (< beg-new end) > + (goto-char beg-new) > + (if (nth 4 (syntax-ppss)) ; in a comment > + (throw 'break beg-new) > + (setq beg-new (1+ beg-new)))) > + end)))) ; Set BEG to END if no throw happens This could be just ;; Move BEG to beginning of comment (after the comment start ;; characters), or END, whichever comes first. (let ((state (syntax-ppss beg))) (unless (nth 4 state) (parse-partial-sexp beg end nil nil state t) (setq beg (point)))) > + ;; (message "ffap-string-at-point dbg: beg = %d beg-new = %d" > + ;; beg beg-new) > + ;; (message "ffap-string-at-point dbg: ffap-string-at-point = %S" > + ;; ffap-string-at-point) These can be removed. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#24057: 25.1.50; ffap interprets comments beginning with "//" as file path 2017-03-17 2:10 ` npostavs @ 2017-03-17 2:13 ` npostavs 2017-03-17 22:16 ` Kaushal Modi 1 sibling, 0 replies; 30+ messages in thread From: npostavs @ 2017-03-17 2:13 UTC (permalink / raw) To: Kaushal Modi; +Cc: 24057 npostavs@users.sourceforge.net writes: > >> + ;; Check if END character is part of a comment. >> + (save-excursion >> + (goto-char end) >> + (nth 4 (syntax-ppss)))) > > This could be just (nth 4 (syntax-ppss end)). Sorry, that should be (save-excursion (nth 4 (syntax-ppss end))) ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#24057: 25.1.50; ffap interprets comments beginning with "//" as file path 2017-03-17 2:10 ` npostavs 2017-03-17 2:13 ` npostavs @ 2017-03-17 22:16 ` Kaushal Modi 2017-03-17 23:30 ` npostavs 1 sibling, 1 reply; 30+ messages in thread From: Kaushal Modi @ 2017-03-17 22:16 UTC (permalink / raw) To: npostavs; +Cc: 24057 [-- Attachment #1.1: Type: text/plain, Size: 3139 bytes --] Hi Noam, Thanks for the detailed review. My comments are inline below. Also I have attached a new patch re-based to the current master, and applying all your suggestions. On Thu, Mar 16, 2017 at 10:09 PM <npostavs@users.sourceforge.net> wrote: > Kaushal Modi <kaushal.modi@gmail.com> writes: > > > * lisp/ffap.el (ffap-string-at-point): If the point is in a comment, > > ensure that the returned string does not contain the comment start > > characters (especially for major modes that have '//' as comment start > > characters). > > > > Why is there a blank line here? > Is it is convention to not format the commit summaries into multiple paragraphs? I reread http://git.savannah.gnu.org/cgit/emacs.git/plain/CONTRIBUTE but didn't find any mention on that. But I have removed that newline from the patch that I attach with this email. > > Otherwise, in a major mode like c-mode, with `ido-mode' enabled and > > `ido-use-filename-at-point' set to `guess', doing "C-x C-f" on a "//foo" > > comment will initiate an attempt to access a path "//foo" (Bug#24057). > > --- > > > + ;; (message "ffap-string-at-point dbg: beg = %d end = %d" beg end) > > This can be removed. > Understood, the patch was still not in final stages.. The attached patch does not have any debug statements. > > + ;; Check if END character is part of a comment. > > + (save-excursion > > + (goto-char end) > > + (nth 4 (syntax-ppss)))) > > This could be just (nth 4 (syntax-ppss end)). > Thanks. TIL that syntax-ppss as POS as optional arg. Also retaining the save-excursion as you correct yourself in the followup email. > > + (save-excursion > > + ;; Increment BEG till point at BEG is in a comment too. > > + ;; (nth 4 (syntax-ppss)) will be null for comment start > > + ;; characters (for example, for the "//" characters in > > + ;; `c-mode' line comments). > > + (setq beg (catch 'break > > + (while (< beg-new end) > > + (goto-char beg-new) > > + (if (nth 4 (syntax-ppss)) ; in a comment > > + (throw 'break beg-new) > > + (setq beg-new (1+ beg-new)))) > > + end)))) ; Set BEG to END if no throw happens > > This could be just > > ;; Move BEG to beginning of comment (after the comment start > ;; characters), or END, whichever comes first. > (let ((state (syntax-ppss beg))) > (unless (nth 4 state) > (parse-partial-sexp beg end nil nil state t) > (setq beg (point)))) > Thanks! I did not know about parse-partial-sexp. Here too, I need to retain the save-excursion, else the point will move after the comment start chars if it is at the BOL in c-mode on a line like //tmp > > + ;; (message "ffap-string-at-point dbg: beg = %d beg-new = %d" > > + ;; beg beg-new) > > > + ;; (message "ffap-string-at-point dbg: ffap-string-at-point = %S" > > + ;; ffap-string-at-point) > > These can be removed. > Done! Review review the attached. Thanks! -- Kaushal Modi [-- Attachment #1.2: Type: text/html, Size: 5788 bytes --] [-- Attachment #2: 0001-Do-not-include-comment-start-chars-in-ffap-string.patch --] [-- Type: application/octet-stream, Size: 3852 bytes --] From eda7a96b66f6937e094b0d76364c6711984db254 Mon Sep 17 00:00:00 2001 From: Kaushal Modi <kaushal.modi@gmail.com> Date: Fri, 17 Mar 2017 18:03:23 -0400 Subject: [PATCH] Do not include comment start chars in ffap string * lisp/ffap.el (ffap-string-at-point): If the point is in a comment, ensure that the returned string does not contain the comment start characters (especially for major modes that have '//' as comment start characters). Otherwise, in a major mode like c-mode, with `ido-mode' enabled and `ido-use-filename-at-point' set to `guess', doing "C-x C-f" on a "//foo" comment will initiate an attempt to access a path "//foo" (Bug#24057). Co-authored-by: Noam Postavsky <npostavs@gmail.com> --- lisp/ffap.el | 41 ++++++++++++++++++++++++++++++++++++++--- 1 file changed, 38 insertions(+), 3 deletions(-) diff --git a/lisp/ffap.el b/lisp/ffap.el index d7222bfb68..a15083f4fa 100644 --- a/lisp/ffap.el +++ b/lisp/ffap.el @@ -1110,32 +1110,67 @@ ffap-string-at-point (defun ffap-string-at-point (&optional mode) "Return a string of characters from around point. + MODE (defaults to value of `major-mode') is a symbol used to look up string syntax parameters in `ffap-string-at-point-mode-alist'. + If MODE is not found, we use `file' instead of MODE. + If the region is active, return a string from the region. -Set the variable `ffap-string-at-point' and the variable + +If the point is in a comment, ensure that the returned string does not +contain the comment start characters (especially for major modes that +have '//' as comment start characters). + +Set the variables `ffap-string-at-point' and `ffap-string-at-point-region'. + When the region is active and larger than `ffap-max-region-length', return an empty string, and set `ffap-string-at-point-region' to '(1 1)." (let* ((args (cdr (or (assq (or mode major-mode) ffap-string-at-point-mode-alist) (assq 'file ffap-string-at-point-mode-alist)))) + (region-selected (use-region-p)) (pt (point)) - (beg (if (use-region-p) + (beg (if region-selected (region-beginning) (save-excursion (skip-chars-backward (car args)) (skip-chars-forward (nth 1 args) pt) (point)))) - (end (if (use-region-p) + (end (if region-selected (region-end) (save-excursion (skip-chars-forward (car args)) (skip-chars-backward (nth 2 args) pt) (point)))) (region-len (- (max beg end) (min beg end)))) + + ;; If the initial characters of the to-be-returned string are the + ;; current major mode's comment starter characters, *and* are + ;; not part of a comment, remove those from the returned string + ;; (Bug#24057). + ;; Example comments in `c-mode' (which considers lines beginning + ;; with "//" as comments): + ;; //tmp - This is a comment. It does not contain any path reference. + ;; ///tmp - This is a comment. The "/tmp" portion in that is a path. + ;; ////tmp - This is a comment. The "//tmp" portion in that is a path. + (when (and + ;; Proceed if no region is selected by the user. + (null region-selected) + ;; Check if END character is part of a comment. + (save-excursion + (nth 4 (syntax-ppss end)))) + ;; Move BEG to beginning of comment (after the comment start + ;; characters), or END, whichever comes first. + (save-excursion + (let ((state (syntax-ppss beg))) + ;; (nth 4 (syntax-ppss)) will be nil for comment start chars + (unless (nth 4 state) + (parse-partial-sexp beg end nil nil state :commentstop) + (setq beg (point)))))) + (if (and (natnump ffap-max-region-length) (< region-len ffap-max-region-length)) ; Bug#25243. (setf ffap-string-at-point-region (list beg end) -- 2.11.0 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* bug#24057: 25.1.50; ffap interprets comments beginning with "//" as file path 2017-03-17 22:16 ` Kaushal Modi @ 2017-03-17 23:30 ` npostavs 2017-03-18 1:28 ` Kaushal Modi 0 siblings, 1 reply; 30+ messages in thread From: npostavs @ 2017-03-17 23:30 UTC (permalink / raw) To: Kaushal Modi; +Cc: 24057 Kaushal Modi <kaushal.modi@gmail.com> writes: > Is it is convention to not format the commit summaries into multiple > paragraphs? I reread > http://git.savannah.gnu.org/cgit/emacs.git/plain/CONTRIBUTE but didn't find > any mention on that. But I have removed that newline from the patch that I > attach with this email. Oh, then I don't understand why you separated that sentence into its own paragraph, it seemed like a continuation of the same idea. (In general, paragraphs should go before the ChangeLog entries, because that format doesn't allow for multiple paragraphs in the same entry (AFAIK)). > characters (especially for major modes that have '//' as comment start > characters). Otherwise, in a major mode like c-mode, with `ido-mode' ^^^ There should be double space between sentences though. > > Thanks! I did not know about parse-partial-sexp. Here too, I need to retain > the save-excursion, else the point will move after the comment start chars > if it is at the BOL in c-mode on a line like Oops, right. (I would consider just putting a single save-excursion around the 'when', but it doesn't hugely matter either way (and Drew would probably not like the single save-excursion version ;) [1]).) [1]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25777#38 ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#24057: 25.1.50; ffap interprets comments beginning with "//" as file path 2017-03-17 23:30 ` npostavs @ 2017-03-18 1:28 ` Kaushal Modi 2017-03-18 15:41 ` npostavs 0 siblings, 1 reply; 30+ messages in thread From: Kaushal Modi @ 2017-03-18 1:28 UTC (permalink / raw) To: npostavs; +Cc: 24057 [-- Attachment #1.1: Type: text/plain, Size: 1880 bytes --] On Fri, Mar 17, 2017 at 7:29 PM <npostavs@users.sourceforge.net> wrote: > > Oh, then I don't understand why you separated that sentence into its own > paragraph, it seemed like a continuation of the same idea. (In general, > paragraphs should go before the ChangeLog entries, because that format > doesn't allow for multiple paragraphs in the same entry (AFAIK)). > It's alright. I have kept the whole thing as a single paragraph. > > characters (especially for major modes that have '//' as comment start > > characters). Otherwise, in a major mode like c-mode, with `ido-mode' > ^^^ > > There should be double space between sentences though. > The attached patch has this fixed. Btw if you don't mind explaining: - How did you detect that minor missing space? Do you have a minor mode? Or do you have a check function? - Being used to using single spaces at end of sentences, I always forget adding double spaces. Is there a robust way to ensure that sentences always end in double spaces in commit messages and in the docstrings? > > > > Thanks! I did not know about parse-partial-sexp. Here too, I need to > retain > > the save-excursion, else the point will move after the comment start > chars > > if it is at the BOL in c-mode on a line like > > Oops, right. (I would consider just putting a single save-excursion > around the 'when', but it doesn't hugely matter either way (and Drew > would probably not like the single save-excursion version ;) [1]).) > > [1]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25777#38 It did actually occur to merge the two save-excursions, but for code clarity, I kept them separate. I did not want to merge the save-excursion in the "condition" part with the "action" part in (when (condition) action) The attached patch has the double space fixed in the commit message. Thanks. -- Kaushal Modi [-- Attachment #1.2: Type: text/html, Size: 3290 bytes --] [-- Attachment #2: 0001-Do-not-include-comment-start-chars-in-ffap-string.patch --] [-- Type: application/octet-stream, Size: 3853 bytes --] From cf61fa11dd0e0a7353c697957a16ec182b188fa9 Mon Sep 17 00:00:00 2001 From: Kaushal Modi <kaushal.modi@gmail.com> Date: Fri, 17 Mar 2017 18:03:23 -0400 Subject: [PATCH] Do not include comment start chars in ffap string * lisp/ffap.el (ffap-string-at-point): If the point is in a comment, ensure that the returned string does not contain the comment start characters (especially for major modes that have '//' as comment start characters). Otherwise, in a major mode like c-mode, with `ido-mode' enabled and `ido-use-filename-at-point' set to `guess', doing "C-x C-f" on a "//foo" comment will initiate an attempt to access a path "//foo" (Bug#24057). Co-authored-by: Noam Postavsky <npostavs@gmail.com> --- lisp/ffap.el | 41 ++++++++++++++++++++++++++++++++++++++--- 1 file changed, 38 insertions(+), 3 deletions(-) diff --git a/lisp/ffap.el b/lisp/ffap.el index d7222bfb68..a15083f4fa 100644 --- a/lisp/ffap.el +++ b/lisp/ffap.el @@ -1110,32 +1110,67 @@ ffap-string-at-point (defun ffap-string-at-point (&optional mode) "Return a string of characters from around point. + MODE (defaults to value of `major-mode') is a symbol used to look up string syntax parameters in `ffap-string-at-point-mode-alist'. + If MODE is not found, we use `file' instead of MODE. + If the region is active, return a string from the region. -Set the variable `ffap-string-at-point' and the variable + +If the point is in a comment, ensure that the returned string does not +contain the comment start characters (especially for major modes that +have '//' as comment start characters). + +Set the variables `ffap-string-at-point' and `ffap-string-at-point-region'. + When the region is active and larger than `ffap-max-region-length', return an empty string, and set `ffap-string-at-point-region' to '(1 1)." (let* ((args (cdr (or (assq (or mode major-mode) ffap-string-at-point-mode-alist) (assq 'file ffap-string-at-point-mode-alist)))) + (region-selected (use-region-p)) (pt (point)) - (beg (if (use-region-p) + (beg (if region-selected (region-beginning) (save-excursion (skip-chars-backward (car args)) (skip-chars-forward (nth 1 args) pt) (point)))) - (end (if (use-region-p) + (end (if region-selected (region-end) (save-excursion (skip-chars-forward (car args)) (skip-chars-backward (nth 2 args) pt) (point)))) (region-len (- (max beg end) (min beg end)))) + + ;; If the initial characters of the to-be-returned string are the + ;; current major mode's comment starter characters, *and* are + ;; not part of a comment, remove those from the returned string + ;; (Bug#24057). + ;; Example comments in `c-mode' (which considers lines beginning + ;; with "//" as comments): + ;; //tmp - This is a comment. It does not contain any path reference. + ;; ///tmp - This is a comment. The "/tmp" portion in that is a path. + ;; ////tmp - This is a comment. The "//tmp" portion in that is a path. + (when (and + ;; Proceed if no region is selected by the user. + (null region-selected) + ;; Check if END character is part of a comment. + (save-excursion + (nth 4 (syntax-ppss end)))) + ;; Move BEG to beginning of comment (after the comment start + ;; characters), or END, whichever comes first. + (save-excursion + (let ((state (syntax-ppss beg))) + ;; (nth 4 (syntax-ppss)) will be nil for comment start chars + (unless (nth 4 state) + (parse-partial-sexp beg end nil nil state :commentstop) + (setq beg (point)))))) + (if (and (natnump ffap-max-region-length) (< region-len ffap-max-region-length)) ; Bug#25243. (setf ffap-string-at-point-region (list beg end) -- 2.11.0 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* bug#24057: 25.1.50; ffap interprets comments beginning with "//" as file path 2017-03-18 1:28 ` Kaushal Modi @ 2017-03-18 15:41 ` npostavs 2017-03-23 13:01 ` npostavs 0 siblings, 1 reply; 30+ messages in thread From: npostavs @ 2017-03-18 15:41 UTC (permalink / raw) To: Kaushal Modi; +Cc: 24057 tags 24057 patch quit Kaushal Modi <kaushal.modi@gmail.com> writes: > Btw if you don't mind explaining: > - How did you detect that minor missing space? Do you have a minor mode? Or > do you have a check function? I enable ocd-mode in my brain while reading patches ;) > - Being used to using single spaces at end of sentences, I always forget > adding double spaces. More seriously, I've gotten used to using double spaces and so single spaced sentences stand out to me more now. > Is there a robust way to ensure that sentences always > end in double spaces in commit messages and in the docstrings? The trouble is that sometimes a period followed by a space doesn't end a sentence, e.g., in "Mr. Foo". Actually, this ambiguity is what convinced me to switch over to double spacing. Such cases might be rare enough in commit messages and docstrings that we could get away with some automatic warning on all matches for "\\sw[.] \\<" though. > > The attached patch has the double space fixed in the commit message. Thanks, I will push to master in a couple of days. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#24057: 25.1.50; ffap interprets comments beginning with "//" as file path 2017-03-18 15:41 ` npostavs @ 2017-03-23 13:01 ` npostavs 2017-03-23 13:30 ` Kaushal Modi 0 siblings, 1 reply; 30+ messages in thread From: npostavs @ 2017-03-23 13:01 UTC (permalink / raw) To: Kaushal Modi; +Cc: 24057 tags 24057 fixed close 24057 26.1 quit npostavs@users.sourceforge.net writes: > > Thanks, I will push to master in a couple of days. Done [1: e472cfe8f3] 1: 2017-03-23 08:57:13 -0400 e472cfe8f3b01f29a49614f6207e4128e8b36b8c Do not include comment start chars in ffap string ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#24057: 25.1.50; ffap interprets comments beginning with "//" as file path 2017-03-23 13:01 ` npostavs @ 2017-03-23 13:30 ` Kaushal Modi 0 siblings, 0 replies; 30+ messages in thread From: Kaushal Modi @ 2017-03-23 13:30 UTC (permalink / raw) To: Noam Postavsky; +Cc: 24057 [-- Attachment #1: Type: text/plain, Size: 256 bytes --] Thank you! On Thu, Mar 23, 2017, 8:59 AM <npostavs@users.sourceforge.net> wrote: > > Done [1: e472cfe8f3] > > 1: 2017-03-23 08:57:13 -0400 e472cfe8f3b01f29a49614f6207e4128e8b36b8c > Do not include comment start chars in ffap string > -- Kaushal Modi [-- Attachment #2: Type: text/html, Size: 720 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2017-03-23 13:30 UTC | newest] Thread overview: 30+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-07-22 23:00 bug#24057: 25.1.50; ffap interprets comments beginning with "//" as file path Kaushal Modi 2016-07-22 23:11 ` Kaushal Modi 2016-07-23 1:26 ` npostavs 2016-07-23 7:38 ` Eli Zaretskii 2016-07-23 7:34 ` Eli Zaretskii 2016-07-23 11:56 ` Kaushal Modi 2016-07-23 13:05 ` Eli Zaretskii 2016-07-23 13:23 ` Kaushal Modi 2016-07-23 13:59 ` Eli Zaretskii 2016-07-23 18:02 ` Noam Postavsky 2016-07-23 18:20 ` Eli Zaretskii 2016-07-23 18:22 ` Eli Zaretskii 2016-07-23 21:51 ` Kaushal Modi 2016-07-24 14:16 ` Eli Zaretskii 2016-07-25 2:19 ` Kaushal Modi 2016-07-25 17:02 ` Eli Zaretskii 2016-07-25 17:13 ` Kaushal Modi 2016-07-25 17:24 ` Eli Zaretskii 2016-07-25 18:13 ` Kaushal Modi 2016-07-25 20:18 ` Kaushal Modi 2016-07-26 14:41 ` Eli Zaretskii 2016-07-26 15:11 ` Kaushal Modi 2017-03-17 2:10 ` npostavs 2017-03-17 2:13 ` npostavs 2017-03-17 22:16 ` Kaushal Modi 2017-03-17 23:30 ` npostavs 2017-03-18 1:28 ` Kaushal Modi 2017-03-18 15:41 ` npostavs 2017-03-23 13:01 ` npostavs 2017-03-23 13:30 ` Kaushal Modi
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.