bug#6695: bug#8439: [PATCH] ffap.el -- detect paths with spaces (v4)

bug#6695: bug#8439: [PATCH] ffap.el -- detect paths with spaces (v4)

[Lars Ingebrigtsen]

jari <jari.aalto@cante.net> writes:

> In this patch (compared to previous v3):
>
>    - remove functions related to Cygwin and use cygwin-convert-path-from-windows
>
>    - obey END parameter in ffap-search-backward-file-end as originally
>      intended
>
>    - correct "path-separator" term into "dir-separator" everywhere

This was seven years ago, and not surprisingly, the patch doesn't apply
any more.

But I think the approach here seemed good -- going back in the buffer
and check whether you find something that matches a file on the file
system (if I understood the patch correctly).

Is there still interest in making this work, or has everybody given up
on using ffap with file names with spaces?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#6695: bug#8439: [PATCH] ffap.el -- detect paths with spaces (v4)

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> This was seven years ago, and not surprisingly, the patch doesn't apply
> any more.

I've respun the patch so that it now applies to Emacs 28, and the test
cases seem to kinda work?  The c: isn't included, but is that to be
expected?

I removed the Cygwin char translation stuff, because there was some
discussion about whether that was needed.

So what do people think?  Good or bad?  Does this work in any way
sensibly for people?

diff --git a/lisp/ffap.el b/lisp/ffap.el
index 4a506207d5..6d40fa8c45 100644
--- a/lisp/ffap.el
+++ b/lisp/ffap.el
@@ -1109,6 +1109,123 @@ ffap-string-at-point
   ;; Added at suggestion of RHOGEE (for ff-paths), 7/24/95.
   "Last string returned by the function `ffap-string-at-point'.")
 
+;; Test cases: (let ((ffap-file-name-with-spaces-flag t)) (ffap-string-at-point))
+;;
+;; c:/Program Files/Open Text Evaluation Media/Open Text Exceed 14 x86/Program here.txt
+;; c:/Program Files/Open Text Evaluation Media/Open Text Exceed 14 x86/Program Files/Hummingbird/
+;; c:\Program Files\Open Text Evaluation Media\Open Text Exceed 14 x86\Program Files\Hummingbird\
+;; c:\Program Files\Freescale\CW for MPC55xx and MPC56xx 2.10\PowerPC_EABI_Tools\Command_Line_Tools\CLT_Usage_Notes.txt
+;; C:\temp\program.log on Windows or /var/log/program.log on Unix.
+
+(defvar ffap-file-name-with-spaces-flag (memq system-type '(ms-dos windows-nt))
+  "If non-nil, enable looking for paths with spaces in `ffap-string-at-point'.
+Enabled in W32 by default.")
+
+(defun ffap-search-backward-file-end (&optional dir-separator end)
+  "Search backward position point where file would probably end.
+Optional DIR-SEPARATOR defaults to \"/\". The search maximum is
+`line-end-position' or optional END point.
+
+Suppose the cursor is somewhere that might be near end of file,
+the guessing would position point before punctuation (like comma)
+after the file extension:
+
+  C:\temp\file.log, which contain ....
+  =============================== (before)
+  ---------------- (after)
+
+
+  C:\temp\file.log on Windows or /tmp/file.log on Unix
+  =============================== (before)
+  ---------------- (after)
+
+The strategy is to search backward until DIR-SEPARATOR which defaults to
+\"/\" and then take educated guesses.
+
+Move point and return point if an adjustment was done."
+  (unless dir-separator
+    (setq dir-separator "/"))
+  (let ((opoint (point))
+	point punct end whitespace-p)
+    (when (re-search-backward
+	   (regexp-quote dir-separator) (line-beginning-position) t)
+      ;; Move to the beginning of the match..
+      (forward-char 1)
+      ;; ... until typical punctuation.
+      (when (re-search-forward "\\([][<>()\"'`,.:;]\\)"
+			       (or end
+				   (line-end-position))
+			       t)
+	(setq end (match-end 0))
+	(setq punct (match-string 1))
+	(setq whitespace-p (looking-at "[ \t\r\n]\\|$"))
+	(goto-char end)
+	(cond
+	 ((and (string-equal punct ".")
+	       whitespace-p)            ;end of sentence
+	  (setq point (1- (point))))
+	 ((and (string-equal punct ".")
+	       (looking-at "[a-zA-Z0-9.]+")) ;possibly file extension
+	  (setq point (match-end 0)))
+	 (t
+	  (setq point (point)))))
+      (goto-char opoint)
+      (when point
+	(goto-char point)
+	point))))
+
+(defun ffap-search-forward-file-end (&optional dir-separator)
+  "Search DIR-SEPARATOR and position point at file's maximum ending.
+This includes spaces.
+Optional DIR-SEPARATOR defaults to \"/\".
+Call `ffap-search-backward-file-end' to refine the ending point."
+  (unless dir-separator
+    (setq dir-separator "/"))
+  (let* ((chars                         ;expected chars in file name
+	  (concat "[^][^<>()\"'`;,#*|"
+		  ;; exclude the opposite as we know the separator
+		  (if (string-equal dir-separator "/")
+		      "\\\\"
+		    "/")
+		  "\t\r\n]"))
+	 (re (concat
+	      chars "*"
+	      (if dir-separator
+		  (regexp-quote dir-separator)
+		"/")
+	      chars "*")))
+    (when (looking-at re)
+      (goto-char (match-end 0)))))
+
+(defun ffap-dir-separator-near-point ()
+  "Search backward and forward for closest slash or backlash in line.
+Return string slash or backslash. Point is moved to closest position."
+  (let ((point (point))
+	str pos)
+    (when (looking-at ".*?/")
+      (setq str "/"
+	    pos (match-end 0)))
+    (when (and (looking-at ".*?\\\\")
+               (or (null pos)
+	           (< (match-end 0) pos)))
+      (setq str "\\"
+	    pos (match-end 0)))
+    (goto-char point)
+    (when (and (re-search-backward "/" (line-beginning-position) t)
+               (or (null pos)
+	           (< (- point (point)) (- pos point))))
+      (setq str "/"
+	    pos (1+ (point)))) ;1+ to keep cursor at the end of char
+    (goto-char point)
+    (when (and (re-search-backward "\\\\" (line-beginning-position) t)
+               (or (null pos)
+		   (< (- point (point)) (- pos point))))
+      (setq str "\\"
+	    pos (1+ (point))))
+    (when pos
+      (goto-char pos))
+    str))
+
 (defun ffap-string-at-point (&optional mode)
   "Return a string of characters from around point.
 
@@ -1128,7 +1245,8 @@ ffap-string-at-point
 
 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
+  (let* (dir-separator
+         (args
 	  (cdr
 	   (or (assq (or mode major-mode) ffap-string-at-point-mode-alist)
 	       (assq 'file ffap-string-at-point-mode-alist))))
@@ -1137,14 +1255,25 @@ ffap-string-at-point
          (beg (if region-selected
 		  (region-beginning)
 		(save-excursion
-		  (skip-chars-backward (car args))
-		  (skip-chars-forward (nth 1 args) pt)
+	          (if (and ffap-file-name-with-spaces-flag
+			   (memq mode '(nil file)))
+		      (when (setq dir-separator (ffap-dir-separator-near-point))
+		        (while (re-search-backward
+			        (regexp-quote dir-separator)
+			        (line-beginning-position) t)
+		          (goto-char (match-beginning 0))))
+		    (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)
+	          (when (and ffap-file-name-with-spaces-flag
+			     (memq mode '(nil file)))
+		    (ffap-search-forward-file-end dir-separator)
+		    (ffap-search-backward-file-end dir-separator))
 		  (point))))
          (region-len (- (max beg end) (min beg end))))
 


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#6695: bug#8439: [PATCH] ffap.el -- detect paths with spaces (v4)

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 8439@debbugs.gnu.org,  6695@debbugs.gnu.org,  Eli Zaretskii <eliz@gnu.org>
> Date: Fri, 14 Aug 2020 15:08:45 +0200
> 
> I've respun the patch so that it now applies to Emacs 28, and the test
> cases seem to kinda work?

Thanks.

> The c: isn't included, but is that to be expected?

Is it?  I thought the intent was to include the full file name, which
means the drive letter should be included.  Otherwise the file will
not be found.

> So what do people think?  Good or bad?  Does this work in any way
> sensibly for people?

Since the heuristic only covers some use cases, I think we should have
it off by default, and we should document its potential pitfalls in
the doc string.  With those qualifications, I'm okay with adding this
optional feature.

bug#6695: bug#8439: [PATCH] ffap.el -- detect paths with spaces (v4)

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> The c: isn't included, but is that to be expected?
>
> Is it?  I thought the intent was to include the full file name, which
> means the drive letter should be included.  Otherwise the file will
> not be found.

I don't have a Windows system to test with...  it's possible that the
functions return the file name including the c: on a Windows machine?

>> So what do people think?  Good or bad?  Does this work in any way
>> sensibly for people?
>
> Since the heuristic only covers some use cases, I think we should have
> it off by default, and we should document its potential pitfalls in
> the doc string.  With those qualifications, I'm okay with adding this
> optional feature.

OK, I've added some tests and pushed it to the trunk.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#6695: bug#8439: [PATCH] ffap.el -- detect paths with spaces (v4)

[Drew Adams]

> > The c: isn't included, but is that to be expected?
> 
> Is it?  I thought the intent was to include the full file name, which
> means the drive letter should be included.  Otherwise the file will
> not be found.
> 
> > So what do people think?  Good or bad?  Does this work in any way
> > sensibly for people?
> 
> Since the heuristic only covers some use cases, I think we should have
> it off by default, and we should document its potential pitfalls in
> the doc string.  With those qualifications, I'm okay with adding this
> optional feature.

FWIW: As the submitter of the original bug report
(#6695), I'd say this shouldn't be marked "fixed"
if the drive letter part (e.g. c:/) isn't included
on MS Windows.

It sounds like it represents some progress, but
it sounds like it's not fixed yet.