opening /tmp//foo doesn't work.

classic Classic list List threaded Threaded
60 messages Options
123
Reply | Threaded
Open this post in threaded view
|

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


_______________________________________________
Emacs-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/emacs-devel
Reply | Threaded
Open this post in threaded view
|

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...



_______________________________________________
Emacs-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/emacs-devel
Reply | Threaded
Open this post in threaded view
|

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


_______________________________________________
Emacs-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/emacs-devel
Reply | Threaded
Open this post in threaded view
|

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.


_______________________________________________
Emacs-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/emacs-devel
Reply | Threaded
Open this post in threaded view
|

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


_______________________________________________
Emacs-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/emacs-devel
Reply | Threaded
Open this post in threaded view
|

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. :-)


_______________________________________________
Emacs-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/emacs-devel
Reply | Threaded
Open this post in threaded view
|

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

Tomas Zerolo
In reply to this post by Han Boetes
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

_______________________________________________
Emacs-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/emacs-devel

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

seewhydee
[hidden email] (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?


_______________________________________________
Emacs-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/emacs-devel
Reply | Threaded
Open this post in threaded view
|

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

Reiner Steib
In reply to this post by Han Boetes
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/



_______________________________________________
Emacs-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/emacs-devel
Reply | Threaded
Open this post in threaded view
|

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

Miles Bader-3
2005/11/13, Reiner Steib <[hidden email]>:
> `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.


_______________________________________________
Emacs-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/emacs-devel
Reply | Threaded
Open this post in threaded view
|

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

Randal L. Schwartz
In reply to this post by Tomas Zerolo
>>>>> "Tomas" == Tomas Zerolo <[hidden email]> 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
<[hidden email]> <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!


_______________________________________________
Emacs-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/emacs-devel
Reply | Threaded
Open this post in threaded view
|

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

Luc Teirlinck
In reply to this post by Miles Bader-3
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.


_______________________________________________
Emacs-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/emacs-devel
Reply | Threaded
Open this post in threaded view
|

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

Richard Stallman
In reply to this post by Han Boetes
    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?


_______________________________________________
Emacs-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/emacs-devel
Reply | Threaded
Open this post in threaded view
|

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

Miles Bader-3
In reply to this post by Luc Teirlinck
2005/11/13, Luc Teirlinck <[hidden email]>:
>    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.


_______________________________________________
Emacs-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/emacs-devel
Reply | Threaded
Open this post in threaded view
|

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

Drew Adams
In reply to this post by Richard 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?

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.



_______________________________________________
Emacs-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/emacs-devel
Reply | Threaded
Open this post in threaded view
|

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

Lars Hansen
In reply to this post by Richard Stallman
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.


_______________________________________________
Emacs-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/emacs-devel
Reply | Threaded
Open this post in threaded view
|

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

Richard Stallman
In reply to this post by Reiner Steib
      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?


_______________________________________________
Emacs-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/emacs-devel
Reply | Threaded
Open this post in threaded view
|

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

Stefan Monnier
In reply to this post by Han Boetes
> 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 @@
 
 ;;; 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))))))
-
-
-;;; 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)))
+
 ;;;###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


_______________________________________________
Emacs-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/emacs-devel
Reply | Threaded
Open this post in threaded view
|

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

Stefan Monnier
In reply to this post by Luc Teirlinck
> 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


_______________________________________________
Emacs-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/emacs-devel
Reply | Threaded
Open this post in threaded view
|

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

Lars Hansen
In reply to this post by seewhydee
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))



_______________________________________________
Emacs-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/emacs-devel
123