opening /tmp//foo doesn't work.

opening /tmp//foo doesn't work.

[Han Boetes]

Hi,

If you try to open /tmp//foo emacs will try to open /foo, of
course this is a great feature, but it forgets that /tmp//foo is a
valid notation of /tmp/foo.

So I would like to suggest that if opening /foo fails emacs will
s|//|/|g and then try to open /tmp/foo, and if that fails will
report that /foo and /tmp/foo do not exist.

I don't think it is important to evaluate all possibilities. So if
someone tries to open /tmp//foo//bar and tried to open /foo/bar
he's out of luck.



# Han

Re: opening /tmp//foo doesn't work.

[Alfred M. Szmidt]

   If you try to open /tmp//foo emacs will try to open /foo, of course
   this is a great feature, but it forgets that /tmp//foo is a valid
   notation of /tmp/foo.

Not remebering various standards exactly on the topic, but I don't
recall any guarante that /tmp//foo must be the same as /tmp/foo.

As for the side-effect behaviour you suggest, I think it would confuse
the hell out of me aleast...

Re: opening /tmp//foo doesn't work.

[Han Boetes]

Alfred M. Szmidt wrote:
> Han wrote:
> > If you try to open /tmp//foo emacs will try to open /foo, of
> > course this is a great feature, but it forgets that /tmp//foo
> > is a valid notation of /tmp/foo.
>
> Not remebering various standards exactly on the topic, but I
> don't recall any guarante that /tmp//foo must be the same as
> /tmp/foo.

This is not about standards, but about what is the expected
behaviour.

> As for the side-effect behaviour you suggest, I think it would
> confuse the hell out of me aleast...

I don't think so. In the case of /tmp//foo /foo will be searched
for first and that's what will be loaded and what is meant.

Just sometimes people type /tmp//foo while they mean /tmp/foo, and
in that case it's unlikely you will find /foo.

I'm quite sure this will be exactly what people meant and expected
to happen.



# Han

Re: opening /tmp//foo doesn't work.

[Alfred M. Szmidt]

   This is not about standards, but about what is the expected
   behaviour.

Which was my point, there is no `expected behaviour'.

   > As for the side-effect behaviour you suggest, I think it would
   > confuse the hell out of me aleast...

   I don't think so. In the case of /tmp//foo /foo will be searched
   for first and that's what will be loaded and what is meant.

What if I meant to create /foo and /tmp/foo just happens to exist?
Right now you get a very nice and consitent behaviour.

Your example only shows one specific case where it would be a nice
thing to do, doing it in general would simply confuse people I think.

Consider the case where you wish to create the file /etc/foo.conf,
your current working directory is /home/ams.  So what you will try to
do is to open /home/ams//etc/foo.conf, since /etc/foo.conf doesn't
exist, you end up opening /home/ams/etc/foo.conf, i.e. not what you
want at all.

Right now // has a single specific meaning, the less special cases the
better IMHO.

Re: opening /tmp//foo doesn't work.

[Han Boetes]

Alfred M. Szmidt wrote:
> Consider the case where you wish to create...

I never mentioned file-creation. I talked about opening files.
You're talking about something else.



# Han

Re: opening /tmp//foo doesn't work.

[Alfred M. Szmidt]

   > Consider the case where you wish to create...

   I never mentioned file-creation. I talked about opening files.
   You're talking about something else.

Oh, I thought you meant that it would behave that way in all cases.
Well, in that case it not be as confusing as I thought it might be.  I
kinda liked your idea, but thought it would be simply to confusing in
the general case. :-)

Re: opening /tmp//foo doesn't work.

[Tomas Zerolo]

[-- Attachment #1.1: Type: text/plain, Size: 412 bytes --]

On Sat, Nov 12, 2005 at 11:46:58AM +0059, Han Boetes wrote:
> Hi,
> 
> If you try to open /tmp//foo emacs will try to open /foo, of
> course this is a great feature, but it forgets that /tmp//foo is a
> valid notation of /tmp/foo.

To interpret /tmp//foo is surprising to me. For example, my OS says
/tmp//foo --> /tmp/foo, as I think most Unixen do (I think POSIX
dictates that).

Regards
-- tomas

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: opening /tmp//foo doesn't work.

[Chong Yidong]

tomas@tuxteam.de (Tomas Zerolo) writes:

> On Sat, Nov 12, 2005 at 11:46:58AM +0059, Han Boetes wrote:
>> Hi,
>> 
>> If you try to open /tmp//foo emacs will try to open /foo, of
>> course this is a great feature, but it forgets that /tmp//foo is a
>> valid notation of /tmp/foo.
>
> To interpret /tmp//foo is surprising to me. For example, my OS says
> /tmp//foo --> /tmp/foo, as I think most Unixen do (I think POSIX
> dictates that).

The reason is convenience.  This allows you to enter a new filename
without having to erase the default offered in the minibuffer.  (A
similar example: /tmp/~/foo goes to ~/foo).  I use this feature all
the time.

If you want to visit /tmp/foo, might I suggest entering /tmp/foo
instead of /tmp//foo?

Turning on file-name-shadow-mode by default (was: opening /tmp//foo doesn't work.)

[Reiner Steib]

On Sat, Nov 12 2005, Han Boetes wrote:

> If you try to open /tmp//foo emacs will try to open /foo, of
> course this is a great feature, but it forgets that /tmp//foo is a
> valid notation of /tmp/foo.

`file-name-shadow-mode' makes it quite obvious for the user what
happens.  It has been discussed previously to turn on
`file-name-shadow-mode' by default.  IIRC Richard asked people to try
it and check if there are problems.  I've been using
`file-name-shadow-mode' for about one year now (I didn't know about it
before) and I think it should be turned on by default.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Turning on file-name-shadow-mode by default (was: opening /tmp//foo doesn't work.)

[Miles Bader]

2005/11/13, Reiner Steib <reinersteib+gmane@imap.cc>:
> `file-name-shadow-mode' for about one year now (I didn't know about it
> before) and I think it should be turned on by default.

I think Richard agreed that it should be turned on, but I wasn't sure
how to do so; I posted a query here asking for pointers, but I don't
remember getting any replies, and I guess I forgot about it after
that.

[Also, Stefan wanted to rewrite it to not use regexps ... I'm not sure
what's up with that.  My only concern was that his method would be too
slow/consy, but it may be Ok in practice, I just don't know.  However
I guess that's orthogonal to turning it on.]

-Miles
--
Do not taunt Happy Fun Ball.

Re: opening /tmp//foo doesn't work.

[Randal L. Schwartz]

>>>>> "Tomas" == Tomas Zerolo <tomas@tuxteam.de> writes:

Tomas> To interpret /tmp//foo is surprising to me. For example, my OS says
Tomas> /tmp//foo --> /tmp/foo, as I think most Unixen do (I think POSIX
Tomas> dictates that).

As a very long time Unix user (since 1977) and a long time Emacs user,
I admit I *was* surprised that /tmp//foo in the shell was not the same
as /tmp//foo in "open file".  But once I realized what it was doing, I
was fine with it.

The hard part is remembering how to get /foo/~/bar/ to really mean a
tilde in the middle of the path.  I think you put \ in front of it,
no?

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: Turning on file-name-shadow-mode by default (was: opening /tmp//foo doesn't work.)

[Luc Teirlinck]

Miles Bader wrote:

   Also, Stefan wanted to rewrite it to not use regexps ... I'm not sure
   what's up with that.  My only concern was that his method would be too
   slow/consy, but it may be Ok in practice, I just don't know.  However
   I guess that's orthogonal to turning it on.

It was not orthogonal, since Stefan was supposedly going to fix the
problems with file-name-shadow-mode.  For instance
`file-name-shadow-mode' gave very confusing results when the file name
contains environment variables, like /home/$USER.  It also did not
know about the `\:' convention.  Stefan posted a patch fixing this.  I
was waiting for Stefan to install his changes before enabling
`file-name-shadow-mode' by default, but apparently Stefan never
installed them and I forgot about the entire thing.

Sincerely,

Luc.

Re: opening /tmp//foo doesn't work.

[Richard M. Stallman]

    So I would like to suggest that if opening /foo fails emacs will
    s|//|/|g and then try to open /tmp/foo, and if that fails will
    report that /foo and /tmp/foo do not exist.

It won't work, because `/tmp/' is deleted in the minibuffer
before Emacs ever tries to open a file.

That is a very important feature, and must be enabled by default.
However, it could make sense to turn off this feature when
insert-default-directory is nil.  Do people think that is a good idea?

Re: Turning on file-name-shadow-mode by default (was: opening /tmp//foo doesn't work.)

[Miles Bader]

2005/11/13, Luc Teirlinck <teirllm@dms.auburn.edu>:
>    slow/consy, but it may be Ok in practice, I just don't know.  However
>    I guess that's orthogonal to turning it on.
>
> It was not orthogonal, since Stefan was supposedly going to fix the
> problems with file-name-shadow-mode.

No.

It was decided that these problems are far too minor to worry about. 
If Stefan can fix them, great, but it should be turned on regardless.

-miles
--
Do not taunt Happy Fun Ball.

RE: opening /tmp//foo doesn't work.

[Drew Adams]

        So I would like to suggest that if opening /foo fails emacs will
        s|//|/|g and then try to open /tmp/foo, and if that fails will
        report that /foo and /tmp/foo do not exist.

    It won't work, because `/tmp/' is deleted in the minibuffer
    before Emacs ever tries to open a file.

    That is a very important feature, and must be enabled by default.
    However, it could make sense to turn off this feature when
    insert-default-directory is nil.  Do people think that is a good idea?

I don't.
But I can't give a good reason why ;-).

If people want to make it possible to interpret /tmp//foo as /tmp/foo, I'd
prefer that that be available only as a user option, as opposed to having it
happen now and again, depending on the context. IOW, I would like to control
that as a user, and not have the program or its designers decide for me.

I have no problem with the current (traditional) behavior.

Re: opening /tmp//foo doesn't work.

[Lars Hansen]

Richard M. Stallman wrote:

>That is a very important feature, and must be enabled by default.
>However, it could make sense to turn off this feature when
>insert-default-directory is nil.  Do people think that is a good idea?
>  
>
I was suprised by the interpretation of /tmp//foo, so I think
file-name-shadow-mode should be on by default.

Setting insert-default-directory to nil does not change the
interpretation of /tmp//foo, so I don't think file-name-shadow-mode
should be turned off here.

Re: Turning on file-name-shadow-mode by default (was: opening /tmp//foo doesn't work.)

[Richard M. Stallman]

      I've been using
    `file-name-shadow-mode' for about one year now (I didn't know about it
    before) and I think it should be turned on by default.

I agree.  Could someone please turn it on by default, and ack?

Re: opening /tmp//foo doesn't work.

[Stefan Monnier]

> So I would like to suggest that if opening /foo fails emacs will
> s|//|/|g and then try to open /tmp/foo, and if that fails will
> report that /foo and /tmp/foo do not exist.

I much prefer M-x file-name-shadow-mode RET

The /tmp//foo => /foo translation is (hopefully) only applied on
interactively input file names, so all we need is clear feedback about
what's going on.

BTW, I still have the following patch which makes file-name-shadow-mode work
correctly even with funny file-name-handlers and without horrible regexps.
Any objections?


        Stefan


Index: rfn-eshadow.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/rfn-eshadow.el,v
retrieving revision 1.15
diff -u -u -b -r1.15 rfn-eshadow.el
--- rfn-eshadow.el	6 Aug 2005 22:13:43 -0000	1.15
+++ rfn-eshadow.el	13 Nov 2005 21:03:59 -0000
@@ -98,7 +98,7 @@
   '(face file-name-shadow field shadow)
   "Properties given to the `shadowed' part of a filename in the minibuffer.
 Only used when `file-name-shadow-mode' is active.
-If emacs is not running under a window system,
+If Emacs is not running under a window system,
 `file-name-shadow-tty-properties' is used instead."
   :type file-name-shadow-properties-custom-type
   :group 'minibuffer)
@@ -121,20 +121,6 @@
 \f
 ;;; Internal variables
 
-;; Regexp to locate dividing point between shadow and real pathname
-(defconst rfn-eshadow-regexp
-  (cond ((memq system-type '(ms-dos windows-nt))
-	 ;; This horrible regexp considers the following patterns as
-	 ;; starting an absolute pathname, when following a `/' or an `\':
-	 ;;   L:  /  //  ~  $  \\  \\\\
-	 "\\(.*[^/]+/+?\\|/*?\\|\\)\\(~\\|$[^$]\\|$\\'\\|[][\\^a-z]:\\|//?\\([^][\\^a-z/$~]\\|[^/$~][^:]\\|[^/$~]?\\'\\)\\)")
-	(t
-	 ;; default is for unix-style filenames
-	 "\\(.*/\\)\\([/~]\\|$[^$]\\|$\\'\\)"))
-  "Regular expression used to match shadowed filenames.
-There should be at least one regexp group; the end of the first one
-is used as the end of the shadowed portion of the filename.")
-
 ;; A list of minibuffers to which we've added a post-command-hook.
 (defvar rfn-eshadow-frobbed-minibufs nil)
 
@@ -168,31 +154,48 @@
     (add-to-list 'rfn-eshadow-frobbed-minibufs (current-buffer))
     (add-hook 'post-command-hook #'rfn-eshadow-update-overlay nil t)))
 
+(defsubst rfn-eshadow-sifn-equal (goal pos)
+  (equal goal (condition-case nil
+		  (substitute-in-file-name
+		   (buffer-substring-no-properties pos (point-max)))
+		;; `substitute-in-file-name' can fail on partial input.
+		(error nil))))
+
 ;; post-command-hook to update overlay
 (defun rfn-eshadow-update-overlay ()
   "Update `rfn-eshadow-overlay' to cover shadowed part of minibuffer input.
-This is intended to be used as a minibuffer post-command-hook for
+This is intended to be used as a minibuffer `post-command-hook' for
 `file-name-shadow-mode'; the minibuffer should have already
 been set up by `rfn-eshadow-setup-minibuffer'."
-  ;; This is not really a correct implementation; it won't always do the
-  ;; right thing in the presence of environment variables that
-  ;; substitute-in-file-name would expand; currently it just assumes any
-  ;; environment variable contains an absolute filename.
-  (save-excursion
-    (let ((inhibit-point-motion-hooks t))
-      (goto-char (minibuffer-prompt-end))
-      ;; Update the overlay (which will evaporate if it's empty).
-      (move-overlay rfn-eshadow-overlay
-		    (point)
-		    (if (looking-at rfn-eshadow-regexp)
-			(match-end 1)
-		      (point))))))
-
-\f
-;;; Note this definition must be at the end of the file, because
-;;; `define-minor-mode' actually calls the mode-function if the
-;;; associated variable is non-nil, which requires that all needed
-;;; functions be already defined.  [This is arguably a bug in d-m-m]
+  (condition-case nil
+      (let ((goal (substitute-in-file-name (minibuffer-contents)))
+            (mid (overlay-end rfn-eshadow-overlay))
+            (start (minibuffer-prompt-end))
+            (end (point-max)))
+        (unless
+            ;; Catch the common case where the shadow does not need to move.
+            (and mid
+                 (or (eq mid end)
+                     (not (rfn-eshadow-sifn-equal goal (1+ mid))))
+                 (or (eq mid start)
+                     (rfn-eshadow-sifn-equal goal mid)))
+          ;; Binary search for the greatest position still equivalent to
+          ;; the whole.
+          (while (or (< (1+ start) end)
+                     (if (and (< (1+ end) (point-max))
+                              (rfn-eshadow-sifn-equal goal (1+ end)))
+                         ;; (SIFN end) != goal, but (SIFN (1+end)) == goal,
+                         ;; We've reached a discontinuity: this can happen
+                         ;; e.g. if `end' point to "/:...".
+                         (setq start (1+ end) end (point-max))))
+            (setq mid (/ (+ start end) 2))
+            (if (rfn-eshadow-sifn-equal goal mid)
+                (setq start mid)
+              (setq end mid)))
+          (move-overlay rfn-eshadow-overlay (minibuffer-prompt-end) start)))
+    ;; `substitute-in-file-name' can fail on partial input.
+    (error nil)))
+\f
 ;;;###autoload
 (define-minor-mode file-name-shadow-mode
   "Toggle File-Name Shadow mode.
@@ -220,5 +223,5 @@
 
 (provide 'rfn-eshadow)
 
-;;; arch-tag: dcf70a52-0115-4ec2-b1e3-4f8d3541a888
+;; arch-tag: dcf70a52-0115-4ec2-b1e3-4f8d3541a888
 ;;; rfn-eshadow.el ends here

Re: Turning on file-name-shadow-mode by default

[Stefan Monnier]

> know about the `\:' convention.  Stefan posted a patch fixing this.
> I was waiting for Stefan to install his changes before enabling
> `file-name-shadow-mode' by default, but apparently Stefan never
> installed them and I forgot about the entire thing.

The patch's ready to go (tho I don't know who tested it other than myself).
I'm just waiting for the green light.


        Stefan

Start value in minibuffer [Was: opening /tmp//foo doesn't work.]

[Lars Hansen]

Chong Yidong wrote:

>The reason is convenience.  This allows you to enter a new filename
>without having to erase the default offered in the minibuffer.  (A
>similar example: /tmp/~/foo goes to ~/foo).  I use this feature all
>the time.
>  
>
To me this feature seems as a rather awkward work-around the lack of a
general way to handle start values in the minibuffer.

I believe a good handling should allow the user to easily use the start
value in any of these ways:

1. As a default value.
2. As a template.
3. Not at all.

1. If the user just hits return, the start value should be used as a
default value.
2. If something similar to the start value is needed, it should be
possible the edit it. This is convenient in eg. a rename command if the
old name is inserted as the start value.
3. If one don't want to use the start value, it is annoying to have to
delete it. In this case it should possible to simply type what one wants
instead.

For those of you that use pc-selection-mode, I believe there is a
natural way to fulfill these requirements. Just try this:

(add-hook 'minibuffer-setup-hook 'select-minibuffer-contents)

(defun select-minibuffer-contents ()
  "Select minibuffer contents."
  (set-mark (point-max))
  (goto-char (minibuffer-prompt-end)))

(defadvice next-history-element (after select-minibuffer-contents activate)
  "Select minibuffer contents."
  (set-mark (point-max))
  (goto-char (minibuffer-prompt-end))
  (setq deactivate-mark nil))

RE: Start value in minibuffer [Was: opening /tmp//foo doesn't work.]

[Drew Adams]

    To me this feature seems as a rather awkward work-around the lack of a
    general way to handle start values in the minibuffer.

    I believe a good handling should allow the user to easily use the start
    value in any of these ways:

    1. As a default value.
    2. As a template.
    3. Not at all.

    1. If the user just hits return, the start value should be used as a
    default value.
    2. If something similar to the start value is needed, it should be
    possible [to] edit it. This is convenient in eg. a rename command if the
    old name is inserted as the start value.
    3. If one don't want to use the start value, it is annoying to have to
    delete it. In this case it should possible to simply type what one wants
    instead.

    For those of you that use pc-selection-mode, I believe there is a
    natural way to fulfill these requirements. Just try this:

    (add-hook 'minibuffer-setup-hook 'select-minibuffer-contents)

    (defun select-minibuffer-contents ()
      "Select minibuffer contents."
      (set-mark (point-max))
      (goto-char (minibuffer-prompt-end)))

    (defadvice next-history-element (after
    select-minibuffer-contents activate)
      "Select minibuffer contents."
      (set-mark (point-max))
      (goto-char (minibuffer-prompt-end))
      (setq deactivate-mark nil))

I think you're speaking of reading minibuffer input with a non-nil
INITIAL-INPUT argument (e.g. to `completing-read'), so that that value
appears initially in the minibuffer (for acceptance, deletion, or editing)
as a "start value".

Your code then makes sure this is preselected. If one is in pc-selection
mode (or delete-selection-mode), then typing will replace the selected start
value, and backspace will delete it.

Do I understand you correctly? If so...

It has been decided that the INITIAL-VALUE parameter to minibuffer-input
functions is more or less deprecated, in favor of the DEF (default-value)
parameter alone. The UI model chosen is not to burden the user with a start
value already in the minibuffer, but rather to let him use M-n to pull the
default value into the minibuffer (to serve as start value), if he wants it.

I don't like that decision, personally, but that's the way it is. I like
your approach, and I use something similar in my own library, icicles.el. I
also provide a user option to control whether or not the default value is
also used as a start value - for those who prefer the standard Emacs
approach to "start values":

icicle-use-default-as-init-value-flag:
 Non-nil means to use default value as init value when reading input.
 This is used by `completing-read'.  When the default-value argument is
 non-nil and the initial-input argument is nil or "",  the default
 value is inserted in the minibuffer as the initial input.

 This has the advantage of not requiring you to use `M-n' to retrieve
 the default value.  It has the disadvantage of making you empty the
 minibuffer if you do not want to use or edit the default value.

However, I think this issue is relatively independent of the treatment of //
and /~ in file-name input. I would not get rid of that special treatment,
even when the general behavior you describe is available. That shortcut is
useful at any time, not just with a "start value", and it erases only the
prefix through the slash, not the entire minibuffer content.

Re: Start value in minibuffer [Was: opening /tmp//foo doesn't work.]

[Lennart Borgman]

Drew Adams wrote:

>It has been decided that the INITIAL-VALUE parameter to minibuffer-input
>functions is more or less deprecated, in favor of the DEF (default-value)
>parameter alone. The UI model chosen is not to burden the user with a start
>value already in the minibuffer, but rather to let him use M-n to pull the
>default value into the minibuffer (to serve as start value), if he wants it.
>
>I don't like that decision, personally, but that's the way it is. I like
>  
>
I do not like that decision either. GUI applications at least on w32 use 
to select a field when you enter it. Maybe there is a chance to rethink 
this decision after the release. Could such things be put in the TODO list?

RE: Start value in minibuffer [Was: opening /tmp//foo doesn't work.]

[Drew Adams]

    I do not like that decision either. GUI applications at least
    on w32 use to select a field when you enter it. Maybe there is a
    chance to rethink this decision after the release. Could such
    things be put in the TODO list?

It's not clear which decision you are referring to. I was speaking of the
decision to deprecate INITIAL-VALUE insertion (in favor of using only DEF).
It sounds like you're arguing for preselection of an initial value.

IOW, there are two questions:

1. Can INIT-VALUE be reinstated as a legitimate (i.e. not disrecommended)
option?
2. Can preselection of an initial value be provided (e.g. as an option)?

In my post, I was considering #1 to be a precondition to #2, because of the
mention of "start value" by the OP. However, preselection could,
alternatively, be applied to the default value pulled in by M-n. That might
be something people would agree to.

I've asked for #1 before, and I don't expect any turnaround on that
question. The most we can hope for in that regard, I think, is a user option
to control the behavior, such as the one I mentioned.

Re: Start value in minibuffer [Was: opening /tmp//foo doesn't work.]

[Lennart Borgman]

Drew Adams wrote:

>    I do not like that decision either. GUI applications at least
>    on w32 use to select a field when you enter it. Maybe there is a
>    chance to rethink this decision after the release. Could such
>    things be put in the TODO list?
>
>It's not clear which decision you are referring to. I was speaking of the
>decision to deprecate INITIAL-VALUE insertion (in favor of using only DEF).
>It sounds like you're arguing for preselection of an initial value.
>
>IOW, there are two questions:
>
>1. Can INIT-VALUE be reinstated as a legitimate (i.e. not disrecommended)
>option?
>2. Can preselection of an initial value be provided (e.g. as an option)?
>  
>
I was arguing for considering 1+2 after the release. A little bit more 
actually since I also thought we might consider how to handle widget fields.

Re: Start value in minibuffer

[Stefan Monnier]

>     For those of you that use pc-selection-mode, I believe there is a
>     natural way to fulfill these requirements. Just try this:

>     (add-hook 'minibuffer-setup-hook 'select-minibuffer-contents)

>     (defun select-minibuffer-contents ()
>       "Select minibuffer contents."
>       (set-mark (point-max))
>       (goto-char (minibuffer-prompt-end)))

>     (defadvice next-history-element (after select-minibuffer-contents activate)
>       "Select minibuffer contents."
>       (set-mark (point-max))
>       (goto-char (minibuffer-prompt-end))
>       (setq deactivate-mark nil))

BTW, shouldn't pc-selection-mode do that?

> It has been decided that the INITIAL-VALUE parameter to minibuffer-input
> functions is more or less deprecated, in favor of the DEF (default-value)
> parameter alone.

Not for file names, which is why /tmp//foo is interpreted as /foo.


        Stefan

Re: Start value in minibuffer

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>     For those of you that use pc-selection-mode, I believe there is a
>>     natural way to fulfill these requirements. Just try this:
>
>>     (add-hook 'minibuffer-setup-hook 'select-minibuffer-contents)
>
>>     (defun select-minibuffer-contents ()
>>       "Select minibuffer contents."
>>       (set-mark (point-max))
>>       (goto-char (minibuffer-prompt-end)))
>
>>     (defadvice next-history-element (after select-minibuffer-contents activate)
>>       "Select minibuffer contents."
>>       (set-mark (point-max))
>>       (goto-char (minibuffer-prompt-end))
>>       (setq deactivate-mark nil))
>
> BTW, shouldn't pc-selection-mode do that?

.. and delete-selection-mode and cua-mode as well.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Turning on file-name-shadow-mode by default

[Luc Teirlinck]

Stefan Monnier wrote:

   The patch's ready to go (tho I don't know who tested it other than myself).

I did.  Seems to work very well.

Sincerely,

Luc.

Re: Turning on file-name-shadow-mode by default (was: opening /tmp//foo doesn't work.)

[Luc Teirlinck]

Richard Stallman wrote:

	 I've been using
       `file-name-shadow-mode' for about one year now (I didn't know about it
       before) and I think it should be turned on by default.

   I agree.  Could someone please turn it on by default, and ack?

I will do it, but I prefer to wait until Stefan's patch is installed.
I do not believe that one or two extra days will make a difference.
This is a minor mode, so there are some subtleties with Custom.  I
believe rfn-eshadow.el will need to be preloaded and I do not want to
check twice whether everything that it uses is defined at the time I
load it, once with the old code and once with the new code.

Sincerely,

Luc.

Re: Start value in minibuffer [Was: opening /tmp//foo doesn't work.]

[Miles Bader]

2005/11/14, Lennart Borgman <lennart.borgman.073@student.lu.se>:
> I do not like that decision either. GUI applications at least on w32 use
> to select a field when you enter it. Maybe there is a chance to rethink
> this decision after the release. Could such things be put in the TODO list?

Emacs is not W32, and will never be W32.  Perhaps that disturbs some
people, but ....

-Miles
--
Do not taunt Happy Fun Ball.

Re: Start value in minibuffer [Was: opening /tmp//foo doesn't work.]

[Lennart Borgman]

Miles Bader wrote:

>2005/11/14, Lennart Borgman <lennart.borgman.073@student.lu.se>:
>  
>
>>I do not like that decision either. GUI applications at least on w32 use
>>to select a field when you enter it. Maybe there is a chance to rethink
>>this decision after the release. Could such things be put in the TODO list?
>>    
>>
>
>Emacs is not W32, and will never be W32.  Perhaps that disturbs some
>people, but ....
>  
>
Oh, let us not give up ... ;-)  -- MS growth has not been that good the 
last five years.

Re: Start value in minibuffer

[Juri Linkov]

>> BTW, shouldn't pc-selection-mode do that?
>
> .. and delete-selection-mode and cua-mode as well.

There is one essential difference between pc-selection-mode,
delete-selection-mode and cua-mode.  pc-selection-mode
deactivates the mark after point movements.

For some time I tried to use the code below with delete-selection-mode.
It copies the default value from the prompt to the input area and
selects it.  But it is inconvenient when after starting to move point
to edit the default value, the selection doesn't become deactivated.
This is not like other GUI applications (e.g. many GTK applications)
work after selecting a field.  Perhaps this should be treated
specially in delete-selection-mode.

;; Prerequisites:
(minibuffer-electric-default-mode 1) ; hide default after copying it
(transient-mark-mode 1)
(delete-selection-mode 1)
(put 'previous-history-element 'delete-selection t)
(put 'next-history-element 'delete-selection t)
(put 'minibuffer-complete 'delete-selection t)
(put 'minibuffer-complete-and-exit 'delete-selection t)
(put 'exit-minibuffer 'delete-selection t)

(defun minibuffer-setup-default-value ()
  (when (and (= (length (minibuffer-contents-no-properties)) 0)
	     (save-excursion
	       (re-search-backward "\\( (default\\> \\(.*\\))\\):? \\'" nil t)))
    (push-mark (point) nil t)
    (insert (match-string-no-properties 2))))
(add-hook 'minibuffer-setup-hook 'minibuffer-setup-default-value)

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: Start value in minibuffer

[Drew Adams]

Another thing about preselecting an initial value in the minibuffer -

Although I provide that in my library as an option, I turn it off by
default. This is because I find that much of the time I want to edit that
value only slightly. If the entire value is preselected, then you must first
explicitly do something to deactivate the region. Otherwise (in PC-selection
mode or delete-selection mode), the entire value is deleted (e.g. replaced)
when you edit it.

For my own use, I prefer to leave the preselection option off, but I have a
handy key binding to empty the minibuffer (because I also use the default
value as an initial value).

I think a user's preference wrt treatment of initial minibuffer input has a
lot to do with whether or not most of the default or initial values are
useful with slight modification. If so, then it makes sense (to me) to use
an initial value, without preselection. If not, then leaving the default
value to be pulled in on demand makes sense, as does using an initial value
with preselection.

Different users will prefer different behaviors. Each approach has something
to be recommended. And, in the case where each approach is not optimal, it
still lets you get what you need with at most one keystroke:

1. `M-n' to pull in the default, in straight Emacs - because
   it's not there to begin with.

2. `C-SPC' to deselect a preselected init value in PC-selection
   mode or delete-selection mode - because you want to edit it
   slightly.

3. some keystroke (e.g. M-S-backspace) to erase the minibuffer
   (in the mode I use: init value without preselection) - when I
   don't want the value at all.

That is:

#1 makes you go through an extra step to get the default value.

#2 makes you go through an extra step to deactivate the selection.

#3 makes you go through an extra step to get rid of the value.

#1 and #2 are optimal when you don't want to edit the default value (just
take it or leave it).  #3 is optimal when you do want to edit it.

Re: Start value in minibuffer [Was: opening /tmp//foo doesn't work.]

[Lars Hansen]

Drew Adams wrote:

>Do I understand you correctly? If so...
>  
>
Yes.

Re: Start value in minibuffer

[Lars Hansen]

Drew Adams wrote:

>Different users will prefer different behaviors. Each approach has something
>to be recommended. And, in the case where each approach is not optimal, it
>still lets you get what you need with at most one keystroke:
>
>1. `M-n' to pull in the default, in straight Emacs - because
>   it's not there to begin with.
>
>2. `C-SPC' to deselect a preselected init value in PC-selection
>   mode or delete-selection mode - because you want to edit it
>   slightly.
>
>3. some keystroke (e.g. M-S-backspace) to erase the minibuffer
>   (in the mode I use: init value without preselection) - when I
>   don't want the value at all.
>
>That is:
>
>#1 makes you go through an extra step to get the default value.
>
>#2 makes you go through an extra step to deactivate the selection.
>
>#3 makes you go through an extra step to get rid of the value.
>
>#1 and #2 are optimal when you don't want to edit the default value (just
>take it or leave it).  #3 is optimal when you do want to edit it.
>  
>
I think you are right and clear! But then the most sensible thing would
be to make it optional. What about something like:

(defcustom minibuffer-insert-default-value nil
  "Insert DEFAULT-VALUE into minibuffer.
If non-nil, `read-from-minibuffer' inserts DEFAULT-VALUE into the
minibuffer if
INITIAL-CONTENTS is nil. If the value is 'select, the minibuffer
contents will
be selected."
  :type '(choice
    (const :tag "Don't insert default value" nil)
    (const :tag "Insert default value" t)
    (const :tag "Insert and select default value" select)))

With this option it is a good decision to use DEFAULT-VALUE rather than
INITIAL-CONTENTS in calls to read-from-minibuffer. Because then the
minibuffer will be empty when minibuffer-insert-default-value is nil.

I suggest to add this in etc/TODO to be looked at after the release.
What do people think?

Re: Start value in minibuffer [Was: opening /tmp//foo doesn't work.]

[Robert J. Chassell]

Today's GNU Emacs CVS snapshot, Mon, 2005 Nov 14  11:30 UTC
GNU Emacs 22.0.50.25 (i686-pc-linux-gnu, GTK+ Version 2.6.10)
started with

     emacs/src/emacs -Q -D

[Context: in the default user interface for C-x C-f (find-file) a
visit to /tmp/foo in which you type /emacs has you visiting /emacs,
not /tmp/emacs.]

Chong Yidong wrote:

   > The reason is convenience.  This allows you to enter a new
   > filename without having to erase the default offered in the
   > minibuffer. ...

To which Lars Hansen replied,

   To me this feature seems as a rather awkward work-around the lack
   of a general way to handle start values in the minibuffer.

I do not follow you.  How do you want to change to the current user
interface?

To take an example, I just went from

    /usr/local/src/emacs/lisp/files.el
to

    ~/.emacs

To do this, I typed     C-x C-f ~/.emacs RET
That is all.  

After typing            C-x C-f
I saw                   /usr/local/src/emacs/lisp/
as expected 
but, as I said, I typed ~/.emacs instead and visted my .emacs file.

       1. If the user just hits return, the start value should be used
       as a default value.

In this case, I do not want to go to the default value or any location
near it.

On the other hand, I could: for example, instead of ~/.emacs, I could
have typed

    ad TAB

to list add-log.el and visit it.  Or in the minibuffer, I can use
`M-p' (previous-history-element) to pull in a previous value.  Or I
can press return and see the current directory.

   2. If something similar to the start value is needed, it should be
   possible the edit it.  This is convenient in eg. a rename command
   if the old name is inserted as the start value.

Nor, at this time, do I not want to go to anything similar to the
start value.  However, I can and do edit the start value when I do
want to go to such a file, such as

    /usr/local/share/emacs/22.0.50/lisp/files.el.gz

I just did this.  I found out what comes after the `22' by using TAB
completion (minibuffer-complete).

   3. If one don't want to use the start value, it is annoying to have
   to delete it.  In this case it should possible to simply type what
   one wants instead.

Yes, it is annoying, and I have never done that.  I do not delete the
start value.

As far as I understand you, the current interface has been doing what
you say for several decades.

What do you want to change?

--
    Robert J. Chassell
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

RE: Start value in minibuffer

[Drew Adams]

    I think you are right and clear! But then the most sensible thing would
    be to make it optional. What about something like:

    (defcustom minibuffer-insert-default-value nil
      "Insert DEFAULT-VALUE into minibuffer.
    If non-nil, `read-from-minibuffer' inserts DEFAULT-VALUE into the
    minibuffer if
    INITIAL-CONTENTS is nil. If the value is 'select, the minibuffer
    contents will
    be selected."
      :type '(choice
        (const :tag "Don't insert default value" nil)
        (const :tag "Insert default value" t)
        (const :tag "Insert and select default value" select)))

There are actually three things we might consider making options:

1. Whether or not the default value is to be inserted in the
   minibuffer as an initial value.

2. If inserted, whether or not to preselect it.

3. Where to leave the cursor - at the beginning or end of the value.

These could be treated independently (3 separate options) or together. The
cursor position matters most for the preselection case, I think.

As an example, in my library, I provide the cursor-position option only in
case of preselection. So, I provide only one option, with these values:

(defcustom icicle-init-value 'insert
  "*Non-nil means to use default value as init value when reading input.
This is used by `completing-read'.  When the default-value argument is
non-nil and the initial-input argument is nil or \"\",  the default
value is inserted in the minibuffer as the initial input.

This has the advantage of not requiring you to use `M-n' to retrieve
the default value.  It has the disadvantage of making you empty the
minibuffer if you do not want to use or edit the default value.

The particular non-nil value determines whether or not the value is
preselected and, if preselected, where the cursor is left: at the
beginning or end of the value.  Possible values:

  nil               - Do not insert default value.
  `insert'          - Insert default value (leave cursor at end).
  `preselect-start' - Insert and preselect default value;
                      leave cursor at beginning.
  `preselect-start' - Insert and preselect default value;
                      leave cursor at end.

Preselection can be useful in Delete Selection mode or PC Selection
mode.  It makes it easy to replace the value by typing characters, or
delete it by hitting `C-d' or `DEL' (backspace).  However, all of the
initial input is lost if you type or hit `C-d' or `DEL'.  That is
inconvenient if you want to keep most of it and edit it only slightly."
  :type '(choice
          (const :tag "Do not insert default value as initial value"
nil)
          (const :tag "Insert (and leave cursor at end)"
insert)
          (const :tag "Insert, preselect, and leave cursor at beginning"
preselect-start)
          (const :tag "Insert, preselect, and leave cursor at end"
preselect-end))
  :group 'icicles)

Re: Turning on file-name-shadow-mode by default

[Richard M. Stallman]

    The patch's ready to go (tho I don't know who tested it other than myself).
    I'm just waiting for the green light.

Didn't someone say you wanted to fix things in the mode first?

Has anyone else tried this patch yet?

Re: Start value in minibuffer [Was: opening /tmp//foo doesn't work.]

[Lars Hansen]

Robert J. Chassell wrote:

>As far as I understand you, the current interface has been doing what
>you say for several decades.
>  
>
Yes, but only because Emacs interprets the minibuffer contents as /foo
although it is /tmp//foo.
IMHO that is not very elegant. And it does not work as a general
approach: Consider some command with initial value foo, and imagine the
user types bar. How would Emacs know if he means foobar (minibuffer
contents) or just bar?

Re: Start value in minibuffer [Was: opening /tmp//foo doesn't work.]

[Robert J. Chassell]

Today's GNU Emacs CVS snapshot, Mon, 2005 Nov 14  11:30 UTC
GNU Emacs 22.0.50.25 (i686-pc-linux-gnu, GTK+ Version 2.6.10)
started with

     emacs/src/emacs -Q -D

Lars Hansen wrote,

   ... Emacs interprets the minibuffer contents as /foo
   although it is /tmp//foo.
   IMHO that is not very elegant. And it does not work as a general
   approach: Consider some command with initial value foo, and imagine the
   user types bar. How would Emacs know if he means foobar (minibuffer
   contents) or just bar?

I do not understand you.

When I look at the file of a command using `C-x C-f' (find-file),
which I just did, Emacs always offers me the current directory and I
can type in the file name.  For example, /bin/ --> /bin/cat.

I always see the trailing / of the current directory and never end up
with /bincat, which would be bad were it to happen inadvertently.

When I do remove the trailing /, then I do create /bincat, an empty
file as I expect.

When I use `C-x C-v' (find-alternate-file), I remove just the command
name part of the complete offering, type in the name, and Emacs goes
to the appropriate file, /bin/cat --> /bin/bash.

We must be talking past each other.

--
    Robert J. Chassell
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Turning on file-name-shadow-mode by default

[Luc Teirlinck]

Richard Stallman wrote:

   Didn't someone say you wanted to fix things in the mode first?

The patch _is_ that fix.

   Has anyone else tried this patch yet?

I did.  It seems to work very well.

Sincerely,

Luc.

Re: Turning on file-name-shadow-mode by default

[Juri Linkov]

>    Has anyone else tried this patch yet?
>
> I did.  It seems to work very well.

Does it handle the "http://" prefix correctly?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Turning on file-name-shadow-mode by default

[Luc Teirlinck]

Juri Linkov wrote:

   >    Has anyone else tried this patch yet?
   >
   > I did.  It seems to work very well.

   Does it handle the "http://" prefix correctly?

I believe so.  After "http://", "http:/" is shadowed and "/" not, and
indeed, you visit "/".  After "/:http://" nothing is shadowed.
What is wrong with that?

Sincerely,

Luc.

Re: Turning on file-name-shadow-mode by default

[Juri Linkov]

>    Does it handle the "http://" prefix correctly?
>
> I believe so.  After "http://", "http:/" is shadowed and "/" not, and
> indeed, you visit "/".  After "/:http://" nothing is shadowed.
> What is wrong with that?

Some packages like FFAP can read both a file name and URL in the same
minibuffer.  With leading "http://" highlighting of URL is wrong.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Turning on file-name-shadow-mode by default

[Luc Teirlinck]

Juri Linkov wrote:

   >    Does it handle the "http://" prefix correctly?
   >
   > I believe so.  After "http://", "http:/" is shadowed and "/" not, and
   > indeed, you visit "/".  After "/:http://" nothing is shadowed.
   > What is wrong with that?

   Some packages like FFAP can read both a file name and URL in the same
   minibuffer.  With leading "http://" highlighting of URL is wrong.

I do not understand.  After "http://", the "http:/" _should _ be
shadowed, because "/" is what is going to be visited.
file-name-shadow-mode should tell me what is actually going to be
visited, not what would be visited if I enabled certain packages.
(And, actually "http://" visits "/", even if FFAP is enabled: I tried.)

After "/:http://" tramp is enabled and nothing is shadowed.

What very specifically is wrong with either of these two examples?
What would you expect to be shadowed or not shadowed and why?

Sincerely,

Luc.

Re: Turning on file-name-shadow-mode by default

[Miles Bader]

2005/11/15, Juri Linkov <juri@jurta.org>:
> >    Does it handle the "http://" prefix correctly?
> >
> > I believe so.  After "http://", "http:/" is shadowed and "/" not, and
> > indeed, you visit "/".  After "/:http://" nothing is shadowed.
> > What is wrong with that?
>
> Some packages like FFAP can read both a file name and URL in the same
> minibuffer.  With leading "http://" highlighting of URL is wrong.

Um, do they use `read-file-name' to read them?!?  If so, and if they
haven't somehow made substitute-in-file-name work correctly for URLs,
then they'll get screwed by completion anyway.  If they _have_ made
substitute-in-file-name work correctly for URLs, then Stefan's code
will (er, should) do the right thing.

-Miles
--
Do not taunt Happy Fun Ball.

Re: Turning on file-name-shadow-mode by default

[Luc Teirlinck]

   (And, actually "http://" visits "/", even if FFAP is enabled: I tried.)

To be more specific:

M-x load-library ffap
(ffap-bindings)
C-x C-f http:// RET

visits "/".

Sincerely,

Luc.

Re: Turning on file-name-shadow-mode by default

[Juri Linkov]

>    (And, actually "http://" visits "/", even if FFAP is enabled: I tried.)
>
> To be more specific:
>
> M-x load-library ffap
> (ffap-bindings)
> C-x C-f http:// RET
>
> visits "/".

You could try a complete URL like:

C-x C-f http://gnu.org/ RET

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Turning on file-name-shadow-mode by default

[Juri Linkov]

>> Some packages like FFAP can read both a file name and URL in the same
>> minibuffer.  With leading "http://" highlighting of URL is wrong.
>
> Um, do they use `read-file-name' to read them?!?

Almost.  `ffap-read-file-or-url' let-binds `minibuffer-completing-file-name'
to t and calls `completing-read' with its own predicate
`ffap-read-file-or-url-internal' which depending on the minibuffer contents
dispatches it either to `read-file-name-internal' or `ffap-read-url-internal'.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Turning on file-name-shadow-mode by default

[Luc Teirlinck]

Juri Linkov wrote:

   You could try a complete URL like:

   C-x C-f http://gnu.org/ RET

Yes, that has "http:/" shadowed and visits the web site.

Sincerely,

Luc.

Re: Turning on file-name-shadow-mode by default

[Luc Teirlinck]

>From my previous message:

   Juri Linkov wrote:

      You could try a complete URL like:

      C-x C-f http://gnu.org/ RET

   Yes, that has "http:/" shadowed and visits the web site.

That is, if FFAP is enabled.  Otherwise, it really complains that the
directory /gnu.org does not exist, as the shadowing indicates.

If it would be very difficult to make file-name-shadow-mode work 100%
correctly with FFAP and similar packages that redefine `C-x C-f' and
are not enabled by default, then the file-name-shadow-mode docstring
could just say that it does not work completely correctly with such
packages.

Without Stefan's patch, file-name-shadow-mode has problems even in
default Emacs and has trouble with Tramp.  It seems that Stefan's
version works correctly in default Emacs, even with Tramp, and only
has problems for packages that redefine `C-x C-f' in a non-trivial way.

Sincerely,

Luc.

Re: Start value in minibuffer [Was: opening /tmp//foo doesn't work.]

[Richard M. Stallman]

    1. Can INIT-VALUE be reinstated as a legitimate (i.e. not disrecommended)
    option?

My mind is made up on this issue, and I don't have time or interest
for reconsidering it, so please drop the subject.

Re: Start value in minibuffer [Was: opening /tmp//foo doesn't work.]

[Lars Hansen]

Robert J. Chassell wrote:

>I do not understand you.
>  
>
Ok, I try harder.

Assuming /usr/local exists on your system but contains no file named foo, do

   emacs -Q /usr/local/foo

Then do C-x C-f, and the minibuffer will contain the value "/usr/local/".

1. You can use the minibuffer contents as a default value: Hit RTN, and
you get a dired buffer listing /usr/local. That's fine.

2. You can use the minibuffer contents as a template: If you want a
listing of /usr/bin, you can edit the string "/usr/local/" so it becomes
"/usr/bin" and then hit RTN. That's fine too.

3. But if you want a listing of /etc, then you don't want to use the
minibuffer contents "/usr/local/" at all. To avoid forcing the user to
delete the minibuffer contents, Emacs allows you to just type "/etc".
This gives the string "/usr/local//etc". When you hit RTN, by magic, you
get a listing of /etc.

IMHO it is not intuitive and neither elegant that Emacs interprets
"/usr/local//etc" as "/etc". I think it would be better if the
minibuffer initial contents of "/usr/local/" had been deleted
automatically when the user starts to type.

One more thing: The approach of interpreting "/usr/local//etc" as "/etc"
works for file names because Emacs knows about file name syntax. But for
other commands with so special syntax, you can't do that. What I am
suggesting is something that works in all cases. Just as an option.

Re: Start value in minibuffer [Was: opening /tmp//foo doesn't work.]

[Miles Bader]

2005/11/16, Lars Hansen <larsh@soem.dk>:
> IMHO it is not intuitive and neither elegant that Emacs interprets
> "/usr/local//etc" as "/etc". I think it would be better if the
> minibuffer initial contents of "/usr/local/" had been deleted
> automatically when the user starts to type.

It is neither elegant nor intuitive to automatically have the entire
contents deleted when you type, necessitating defensive action as your
first step.  However that is what you're used to, so you think it is.

Since we are used to Emacs' file-name behavior, we like it.  It makes
the common case (appending to current dir) easy and fast, and also
makes the slightly more unusual but still not uncommon case (replacing
the current dir) also easy and fast.

-miles
--
Do not taunt Happy Fun Ball.

Re: Start value in minibuffer [Was: opening /tmp//foo doesn't work.]

[Lars Hansen]

Miles Bader wrote:

>Since we are used to Emacs' file-name behavior, we like it.  It makes
>the common case (appending to current dir) easy and fast, and also
>makes the slightly more unusual but still not uncommon case (replacing
>the current dir) also easy and fast.
>
Yes I know. I don't want to argue about what is best. I fully respect
that people have different taste and work in different ways. That why I
suggest an option.

I apologize if "neither elegant nor intuitive" has offended you, I
didn't mean to.

Re: Start value in minibuffer [Was: opening /tmp//foo doesn't work.]

[Richard M. Stallman]

    Yes, but only because Emacs interprets the minibuffer contents as /foo
    although it is /tmp//foo.
    IMHO that is not very elegant. And it does not work as a general
    approach: Consider some command with initial value foo, and imagine the
    user types bar. How would Emacs know if he means foobar (minibuffer
    contents) or just bar?

Could we please drop this argument?  I'm not going to change this, and
the discussion is a distraction from work that needs to be done.

Re: Turning on file-name-shadow-mode by default

[Richard M. Stallman]

       Didn't someone say you wanted to fix things in the mode first?

    The patch _is_ that fix.

       Has anyone else tried this patch yet?

    I did.  It seems to work very well.

Ok, let's install it.

Re: Start value in minibuffer [Was: opening /tmp//foo doesn't work.]

[Kevin Rodgers]

Lars Hansen wrote:
 > 3. But if you want a listing of /etc, then you don't want to use the
 > minibuffer contents "/usr/local/" at all. To avoid forcing the user to
 > delete the minibuffer contents, Emacs allows you to just type "/etc".
 > This gives the string "/usr/local//etc". When you hit RTN, by magic, you
 > get a listing of /etc.

I always type TAB before RET when entering a file name, so that (1) I
know what I'm getting and (2) the actual file name is added to the
history variable instead of the minibuffer contents.

-- 
Kevin Rodgers

Re: Turning on file-name-shadow-mode by default

[Stefan Monnier]

>> Has anyone else tried this patch yet?
>> I did.  It seems to work very well.
> Does it handle the "http://" prefix correctly?

If the file syntax handles http:// specially (i.e. if you turn on
url-handler-mode), then yes, it works correctly.  It directly uses
substitute-in-file-name, so (modulo bugs) it should work 100% correctly in
the sense that the full text will always be interpreted identically to the
non-shadowed text.

Regarding FFAP, file-name-shadow-mode handles it incorrectly because
file-name-shadow-mode assumes that when minibuffer-completing-file-name is
non-nil, the minibuffer's content will eventually be passed to
substitute-in-file-name, which is not the case for FFAP.  The fact that FFAP
sets minibuffer-completing-file-name to non-nil even though it allows
entering a string which is not a proper file name (i.e. not understood by
file operations) could be considered a bug.  E.g. the patch below to
complete.el (which should be installed) would also cause problems with FFAP.


        Stefan


--- complete.el	20 aoû 2005 19:26:01 -0400	1.45
+++ complete.el	15 nov 2005 17:47:05 -0500	
@@ -339,10 +339,7 @@
 (defvar PC-delims-list nil)
 
 (defvar PC-completion-as-file-name-predicate
-  (function
-   (lambda ()
-     (memq minibuffer-completion-table
-	   '(read-file-name-internal read-directory-name-internal))))
+  (lambda () minibuffer-completing-file-name)
    "A function testing whether a minibuffer completion now will work filename-style.
 The function takes no arguments, and typically looks at the value
 of `minibuffer-completion-table' and the minibuffer contents.")

Re: Turning on file-name-shadow-mode by default

[Stefan Monnier]

>        Didn't someone say you wanted to fix things in the mode first?
>     The patch _is_ that fix.

>        Has anyone else tried this patch yet?

>     I did.  It seems to work very well.

> Ok, let's install it.

Done.


        Stefan

Re: Turning on file-name-shadow-mode by default (was: opening /tmp//foo doesn't work.)

[Luc Teirlinck]

Richard Stallman wrote:

	 I've been using
       `file-name-shadow-mode' for about one year now (I didn't know about it
       before) and I think it should be turned on by default.

   I agree.  Could someone please turn it on by default, and ack?

Done,

Sincerely,

Luc.