bug in file-name-shadow-mode

bug in file-name-shadow-mode

[Luc Teirlinck]

The following would appear to be a bug `file-name-shadow-mode'.

Do emacs -Q.

M-x customize-option RET file-name-shadow-mode RET

C-x C-f

Then set file-name-shadow-mode to t for the current session using the mouse.

You are still in the minibuffer.  Clearly, file-name-shadow-mode does
not work in that minibuffer.  This might be somewhat expected.  Worse
is that file-name-shadow-mode stays disabled in subsequent invocations
of the minibuffer, even though the variable file-name-shadow-mode is t.

Sincerely,

Luc.

Re: bug in file-name-shadow-mode

[Richard Stallman]

      Worse
    is that file-name-shadow-mode stays disabled in subsequent invocations
    of the minibuffer, even though the variable file-name-shadow-mode is t.

I am not sure what you mean.  Would you please provide precise instructions
for that part too?

Re: bug in file-name-shadow-mode

[Luc Teirlinck]

Richard Stallman wrote:

	 Worse
       is that file-name-shadow-mode stays disabled in subsequent invocations
       of the minibuffer, even though the variable file-name-shadow-mode is t.

   I am not sure what you mean.  Would you please provide precise instructions
   for that part too?

Do C-g to quit the current minibuffer.   Then do C-x C-f.
One now has ~/ in the minibuffer.  If you type an extra "/", the "~/"
preceding it does not get any special highlighting, as it should if
file-name-shadow-mode is t.

Sincerely,

Luc.

Re: bug in file-name-shadow-mode

[Richard Stallman]

    Do C-g to quit the current minibuffer.   Then do C-x C-f.
    One now has ~/ in the minibuffer.  If you type an extra "/", the "~/"
    preceding it does not get any special highlighting, as it should if
    file-name-shadow-mode is t.

The cause of this is that the minibuffer binds minibuffer-setup-hook
and therefore the local binding is what gets set.  Thus, exiting the
minibuffer wipes it out.

I think there is nothing to be done about this.  It would be hard to
fix and it probably isn't worth the trouble.

Re: bug in file-name-shadow-mode

[Stefan Monnier]

>     Do C-g to quit the current minibuffer.   Then do C-x C-f.
>     One now has ~/ in the minibuffer.  If you type an extra "/", the "~/"
>     preceding it does not get any special highlighting, as it should if
>     file-name-shadow-mode is t.

> The cause of this is that the minibuffer binds minibuffer-setup-hook
> and therefore the local binding is what gets set.  Thus, exiting the
> minibuffer wipes it out.

> I think there is nothing to be done about this.  It would be hard to
> fix and it probably isn't worth the trouble.

How 'bout the untested patch below?


        Stefan


--- files.el	15 fév 2005 11:00:48 -0500	1.745
+++ files.el	21 mar 2005 11:19:48 -0500	
@@ -928,20 +928,30 @@
 (defvar find-file-default nil
   "Used within `find-file-read-args'.")
 
+(defmacro minibuffer-with-setup-hook (fun &rest body)
+  "Add FUN to `minibuffer-setup-hook' while executing BODY.
+BODY should use the minibuffer at most once.
+Recursive uses of the minibuffer will not be affected."
+  (declare (indent 1) (debug t))
+  (let ((funname (make-symbol "setup-hook"))
+	(oldval (make-symbol "old-val")))
+    `(unwind-protect
+	 (progn
+	   (fset ',funname (lambda () (,fun)
+			     ;; Clear out this hook so it does not interfere
+			     ;; with any recursive minibuffer usage.
+			     (remove-hook 'minibuffer-setup-hook ',funname)))
+	   (add-hook 'minibuffer-setup-hook ',funname)
+	   ,@body)
+       (remove-hook 'minibuffer-setup-hook ',funname))))
+
 (defun find-file-read-args (prompt mustmatch)
   (list (let ((find-file-default
 	       (and buffer-file-name
-		    (abbreviate-file-name buffer-file-name)))
-	      (munge-default-fun
-	       (lambda ()
-		 (setq minibuffer-default find-file-default)
-		 ;; Clear out this hook so it does not interfere
-		 ;; with any recursive minibuffer usage.
-		 (pop minibuffer-setup-hook)))
-	      (minibuffer-setup-hook
-	       minibuffer-setup-hook))
-	  (add-hook 'minibuffer-setup-hook munge-default-fun)
-	  (read-file-name prompt nil default-directory mustmatch))
+		    (abbreviate-file-name buffer-file-name))))
+	  (minibuffer-with-setup-hook
+	      (lambda () (setq minibuffer-default find-file-default))
+	    (read-file-name prompt nil default-directory mustmatch)))
 	t))
 
 (defun find-file (filename &optional wildcards)

Re: bug in file-name-shadow-mode

[Luc Teirlinck]

Stefan Monnier wrote:

   > I think there is nothing to be done about this.  It would be hard to
   > fix and it probably isn't worth the trouble.

   How 'bout the untested patch below?

Seems to work.

Sincerely,

Luc.

Re: bug in file-name-shadow-mode

[Richard Stallman]

The use of fset makes this rather ugly.

If the idea is to put a function onto minibuffer-setup-hook just to
execute once, I see no reason to bind anything.  Just add the function
and design it to remove itself when run.  For safety's sake,
use an unwind-protect to remove the function from the list
in the case where an error prevented it from being run.
So how about this?

(defun find-file-read-args (prompt mustmatch)
  (list (let ((find-file-default
	       (and buffer-file-name
		    (abbreviate-file-name buffer-file-name)))
	      (find-file-read-args-hook-fn
	       (lambda ()
		 ;; Clear out this hook so it does not interfere
		 ;; with any recursive minibuffer usage.
	         (remove-hook 'minibuffer-setup-hook
		 	      find-file-read-args-hook-fn)
		 (setq minibuffer-default find-file-default))))
	  (unwind-protect
	      (progn
	        (add-hook 'minibuffer-setup-hook 
	    		  find-file-read-args-hook-fn)
	        (read-file-name prompt nil default-directory mustmatch))
	    (remove-hook 'minibuffer-setup-hook
	    		 find-file-read-args-hook-fn)))
 	t))

Meanwhile, do you understand what the purpose of this function is?
Is this what arranges to make M-n bring in the default file name?