Re: read-file-name

Re: read-file-name

[Kevin Rodgers]

Elvin Peterson wrote:
 > Thanks.  The default is not an issue when the directory DIR is an
 > absolute path.  Shouldn't it show up in the read-file-name
 > documentation?

I don't see any difference in the behavior of read-file-name when DIR is
an absolute vs. relative path.  If I type RET at the prompt, both of
these forms return DIR:

(read-file-name "Image File: " "images")
(read-file-name "Image File: " "/images")

P.S. You probably want to use "images/" as DIR anyway -- see
      file-name-as-directory.

-- 
Kevin Rodgers

Re: read-file-name

[Elvin Peterson]

Kevin Rodgers wrote:
> Elvin Peterson wrote:
>  > Thanks.  The default is not an issue when the directory DIR is an
>  > absolute path.  Shouldn't it show up in the read-file-name
>  > documentation?
> 
> I don't see any difference in the behavior of read-file-name when DIR is
> an absolute vs. relative path.  If I type RET at the prompt, both of
> these forms return DIR:

Yes, the behavior is the same if you press RET.  However, it is 
completely different for TAB completion, where the first one fails in 
tha absence of the let workaround.

> 
> (read-file-name "Image File: " "images")
> (read-file-name "Image File: " "/images")
> 
> P.S. You probably want to use "images/" as DIR anyway -- see
>      file-name-as-directory.

I have done that, although it only seems to make a difference for VMS.

Re: read-file-name

[Kevin Rodgers]

Elvin Peterson wrote:
 > Kevin Rodgers wrote:
 >> I don't see any difference in the behavior of read-file-name when DIR is
 >> an absolute vs. relative path.  If I type RET at the prompt, both of
 >> these forms return DIR:
 >>
 >> (read-file-name "Image File: " "images")
 >> (read-file-name "Image File: " "/images")
 >
 > Yes, the behavior is the same if you press RET.  However, it is
 > completely different for TAB completion, where the first one fails in
 > tha absence of the let workaround.

Ah, well you didn't mention completion in either of your 2 previous
posts.

It does seem to be a bug, that read-file-name signals an error when
insert-default-directory is non-nil and DIR is a relative file name, and
the user types TAB or ?.  So I'm cross-posting this to gnu.emacs.bug and
directing followups there.

-- 
Kevin Rodgers

Re: read-file-name

[Kevin Rodgers]

Elvin Peterson wrote:
 > Kevin Rodgers wrote:
 >> I don't see any difference in the behavior of read-file-name when DIR is
 >> an absolute vs. relative path.  If I type RET at the prompt, both of
 >> these forms return DIR:
 >>
 >> (read-file-name "Image File: " "images")
 >> (read-file-name "Image File: " "/images")
 >
 > Yes, the behavior is the same if you press RET.  However, it is
 > completely different for TAB completion, where the first one fails in
 > tha absence of the let workaround.

Ah, well you didn't mention completion in either of your 2 previous
posts.

It does seem to be a bug, that read-file-name signals an error when
insert-default-directory is non-nil and DIR is a relative file name, and
the user types TAB or ?.  So I'm cross-posting this to gnu.emacs.bug and
directing followups there.

-- 
Kevin Rodgers

Re: read-file-name

[Thien-Thi Nguyen]

Elvin Peterson <elvin_peterson@yahoo.com> writes:

> I have done that, although it only seems to make a difference for VMS.

filename completion behavior under vms depends on emacs version.
historically, that piece of code was developed apart from the unixoid
filename completion code, the rationale probably being that less gray
hairs would thus be produced.  well, now we have all these colorful
dyes[1] so it turns out the best hair to play w/ is the gray kind, i.e.,
the well-aged and better-maintained mainstream codebase.

fwiw, for the work-in-progress emacs 21.x port[2], which re-integrates
the filename completion implementations (albeit imperfectly due to
axiomatic differences), i believe you can coax analogous behavior under
both unix and vms for the non-nested RELDIR case by using the construct:

  (read-file-name PROMPT (expand-file-name RELDIR))

you can also try fiddling w/ the rest of the `read-file-name' args, to
override the (heuristic, fallable, unix-assuming) defaults.

thi


_________________________________________________________
[1] such as handlers triggering on stylized filenames,
    filenames w/ non-ASCII chars, etc.
[2] http://www.emacswiki.org/cgi-bin/wiki/EmacsOnVMS

find-file-literally-at-point

[Edward O'Connor]

Hi,

I recently found myself in need of such a function (I was going through
a bunch of files to strip out their UTF-8 BOMs, if you're curious), and
it was quick enough to put together:

(autoload 'ffap-guesser "ffap")
(defun find-file-literally-at-point ()
  "Open the file at point (like `ffap') with `find-file-literally'."
  (interactive)
  (find-file-literally (ffap-guesser)))

Is this something people might like to see added to ffap.el? I've signed
papers.


Thanks,
Ted

Re: find-file-literally-at-point

[Juri Linkov]

> I recently found myself in need of such a function (I was going through
> a bunch of files to strip out their UTF-8 BOMs, if you're curious),

Oh, I see.  That's what I regularly had to do on files produced
by Windows editors :)  Some time ago Emacs used to display BOMs,
so it was easy to see and delete BOMs, but now doesn't anymore,
since now the default coding system of files with the BOM is
`utf-8-with-signature'.  Forcing it to use `utf-8' with e.g.
`C-x RET c utf-8 RET C-x C-f' is a way to display BOMs
in an UTF-8 file.

> and it was quick enough to put together:
>
> (autoload 'ffap-guesser "ffap")
> (defun find-file-literally-at-point ()
>   "Open the file at point (like `ffap') with `find-file-literally'."
>   (interactive)
>   (find-file-literally (ffap-guesser)))
>
> Is this something people might like to see added to ffap.el?

When I added a few find-file related functions to ffap,
I don't remember why I missed `find-file-literally'.
Maybe because it has no keybinding (should we try to find one?).
So we definitely need such a function.

However, I wonder why you don't implement it using `ffap-file-finder'
and `call-interactively', like e.g. `ffap-alternate-file' does?
Like other ffap functions, it asks for a filename in the minibuffer,
and allows to get the default behavior with C-u.

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

FFAP (was: find-file-literally-at-point)

[Stefan Monnier]

> When I added a few find-file related functions to ffap,
> I don't remember why I missed `find-file-literally'.
> Maybe because it has no keybinding (should we try to find one?).
> So we definitely need such a function.

BTW, I'd be interested in trying to integrate the FFAP behavior into the
default find-file behavior.  If you people have ideas how such an
integration could take place, I'm all ears (of course, backward
compatibility with older users is very important).  Maybe we could have
an FFAP prefix, so <prefix> C-x C-f would `find-file-at-point'.
Or maybe we could have a keybinding in
minibuffer-local-filename-completion-map to bring in the
filename-at-point.


        Stefan

Re: FFAP

[Juri Linkov]

>> When I added a few find-file related functions to ffap,
>> I don't remember why I missed `find-file-literally'.
>> Maybe because it has no keybinding (should we try to find one?).
>> So we definitely need such a function.
>
> BTW, I'd be interested in trying to integrate the FFAP behavior into the
> default find-file behavior.  If you people have ideas how such an
> integration could take place, I'm all ears (of course, backward
> compatibility with older users is very important).

I had an idea for a long time how to do such an integration, but
not implemented it yet because I currently don't see how to do this
without loading the whole ffap.el by default.  Perhaps we should
rewrite most of the ffap functionality and simplify it.

The idea is to put a file/URL from the text around the point into
the minibuffer's default values list.  So typing `C-x C-f M-n'
on a file name will bring in it from the current buffer into the
minibuffer.  This is useful for all prompts that read files or
directories.  For instance, `M-x mkdir RET M-n' will try to fetch
the directory name from the current buffer, and so on.

> Or maybe we could have a keybinding in
> minibuffer-local-filename-completion-map to bring in the
> filename-at-point.

`M-n' is such a binding that users are already familiar with.
If it turns out that it's unsuitable, we could invent a new one.

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

Re: FFAP

[Stefan Monnier]

> I had an idea for a long time how to do such an integration, but
> not implemented it yet because I currently don't see how to do this
> without loading the whole ffap.el by default.  Perhaps we should
> rewrite most of the ffap functionality and simplify it.

By "integration" I mostly mean the functionality, not necessarily
the code.  But if it means preloading ffap.el, that's not necessarily
a bad thing, although I think that by integrating it, we can make it
a lot simpler, so I expect that a complete rewrite will be preferable
(especially since we probably wouldn't provide every single last detail
of ffap's functionality).

> The idea is to put a file/URL from the text around the point into
> the minibuffer's default values list.  So typing `C-x C-f M-n'
> on a file name will bring in it from the current buffer into the
> minibuffer.

I thought about it but M-n is already used in some file prompts for
other purposes, so the user would then have to hit M-n more than once to
get the file-at-point, which makes it cumbersome.  I think a dedicated
keybinding would be better.

BTW, another possibility is to do what complete.el does: use a special
file name (complete.el uses "<>" but we could choose something else,
like " ") to mean file-at-point.  I think it's a worse solution (both
because it may collide with a real file name, and more importantly
because it makes it impossible/difficult to edit the file-at-point), but
I throw it out, for completeness's sake.


        Stefan

Re: FFAP

[Juri Linkov]

> By "integration" I mostly mean the functionality, not necessarily
> the code.  But if it means preloading ffap.el, that's not necessarily
> a bad thing, although I think that by integrating it, we can make it
> a lot simpler, so I expect that a complete rewrite will be preferable
> (especially since we probably wouldn't provide every single last detail
> of ffap's functionality).

I forgot that we already have a clean and small counterpart of ffap
that can be preloaded instead of ffap.el.  It is thingatpt.el.
With (thing-at-point 'filename) it returns the filename at point,
and with (thing-at-point 'url) it returns the URL at point.

>> The idea is to put a file/URL from the text around the point into
>> the minibuffer's default values list.  So typing `C-x C-f M-n'
>> on a file name will bring in it from the current buffer into the
>> minibuffer.
>
> I thought about it but M-n is already used in some file prompts for
> other purposes,

Let's see what currently M-n does in file prompts (0. means the default
input, and 1. - the minibuffer's content after one M-n):

`C-x C-f' in a non-file buffer:
0. current directory name

`C-x C-f' in a file buffer:
0. current directory name
1. file name of the current buffer

`C-x C-v' in a file buffer:
0. file name of the current buffer
1. file name of the current buffer
(the last case has duplicates)

> so the user would then have to hit M-n more than once to get the
> file-at-point, which makes it cumbersome.

After adding a file name at point:

`C-x C-f' in a non-file buffer:
0. current directory name
1. file name at point

`C-x C-f' in a file buffer:
0. current directory name
1. file name of the current buffer
2. file name at point

`C-x C-v' in a file buffer:
0. file name of the current buffer
1. file name at point

So M-n more than once is only in a file buffer,
where we could add a file name at point before
the file name of the current buffer:

`C-x C-f' in a file buffer:
0. current directory name
1. file name at point
2. file name of the current buffer

> I think a dedicated keybinding would be better.

Of course, a dedicated keybinding would be good as well.
IIRC, the last time this has been discussed where Drew
proposed `M-.' to yank text at point into the minibuffer in:
http://thread.gmane.org/gmane.emacs.devel/50372

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

read-file-name (was: FFAP)

[Juri Linkov]

All completion functions support a list of default values
except `read-file-name'.  The following patch fills this hole.

Index: lisp/minibuffer.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/minibuffer.el,v
retrieving revision 1.93
diff -c -r1.93 minibuffer.el
*** lisp/minibuffer.el	2 Nov 2009 02:06:40 -0000	1.93
--- lisp/minibuffer.el	9 Nov 2009 10:12:38 -0000
***************
*** 1265,1271 ****
  Default name to DEFAULT-FILENAME if user exits the minibuffer with
  the same non-empty string that was inserted by this function.
   (If DEFAULT-FILENAME is omitted, the visited file name is used,
!   except that if INITIAL is specified, that combined with DIR is used.)
  If the user exits with an empty minibuffer, this function returns
  an empty string.  (This can only happen if the user erased the
  pre-inserted contents or if `insert-default-directory' is nil.)
--- 1265,1272 ----
  Default name to DEFAULT-FILENAME if user exits the minibuffer with
  the same non-empty string that was inserted by this function.
   (If DEFAULT-FILENAME is omitted, the visited file name is used,
!   except that if INITIAL is specified, that combined with DIR is used.
!   If DEFAULT-FILENAME is a list of file names, the first file name is used.)
  If the user exits with an empty minibuffer, this function returns
  an empty string.  (This can only happen if the user erased the
  pre-inserted contents or if `insert-default-directory' is nil.)
***************
*** 1308,1314 ****
    (setq dir (abbreviate-file-name dir))
    ;; Likewise for default-filename.
    (if default-filename
!       (setq default-filename (abbreviate-file-name default-filename)))
    (let ((insdef (cond
                   ((and insert-default-directory (stringp dir))
                    (if initial
--- 1309,1317 ----
    (setq dir (abbreviate-file-name dir))
    ;; Likewise for default-filename.
    (if default-filename
!       (if (consp default-filename)
! 	  (setq default-filename (mapcar 'abbreviate-file-name default-filename))
! 	(setq default-filename (abbreviate-file-name default-filename))))
    (let ((insdef (cond
                   ((and insert-default-directory (stringp dir))
                    (if initial
***************
*** 1357,1365 ****
  			       (not (zerop (length file))))
                        (setq default-filename file)
                        (setq dir (file-name-directory dir)))
!                     (if default-filename
!                         (setq default-filename
!                               (expand-file-name default-filename dir)))
                      (setq add-to-history t)
                      (x-file-dialog prompt dir default-filename
  				   dialog-mustmatch
--- 1360,1371 ----
  			       (not (zerop (length file))))
                        (setq default-filename file)
                        (setq dir (file-name-directory dir)))
!                     (when default-filename
! 		      (setq default-filename
! 			    (expand-file-name (if (consp default-filename)
! 						  (car default-filename)
! 						default-filename)
! 					      dir)))
                      (setq add-to-history t)
                      (x-file-dialog prompt dir default-filename
  				   dialog-mustmatch
***************
*** 1371,1376 ****
--- 1377,1384 ----
            ;; it has to mean that the user typed RET with the minibuffer empty.
            ;; In that case, we really want to return ""
            ;; so that commands such as set-visited-file-name can distinguish.
+ 	  (when (consp default-filename)
+ 	    (setq default-filename (car default-filename)))
            (when (eq val default-filename)
              ;; In this case, completing-read has not added an element
              ;; to the history.  Maybe we should.

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

Re: read-file-name

[Stefan Monnier]

> All completion functions support a list of default values
> except `read-file-name'.  The following patch fills this hole.

Looks OK, feel free to install it.

> !       (if (consp default-filename)
> ! 	  (setq default-filename (mapcar 'abbreviate-file-name default-filename))
> ! 	(setq default-filename (abbreviate-file-name default-filename))))

That should be

       (setq default-filename
             (if (consp default-filename)
                 (mapcar 'abbreviate-file-name default-filename)
               (abbreviate-file-name default-filename))))


-- Stefan

Re: read-file-name

[Juri Linkov]

>> All completion functions support a list of default values
>> except `read-file-name'.  The following patch fills this hole.
>
> Looks OK, feel free to install it.
>
>> !       (if (consp default-filename)
>> ! 	  (setq default-filename (mapcar 'abbreviate-file-name default-filename))
>> ! 	(setq default-filename (abbreviate-file-name default-filename))))
>
> That should be
>
>        (setq default-filename
>              (if (consp default-filename)
>                  (mapcar 'abbreviate-file-name default-filename)
>                (abbreviate-file-name default-filename))))

Done.

BTW, do you know an Emacs function that does such
common subexpression elimination?

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

Re: read-file-name

[Stefan Monnier]

> BTW, do you know an Emacs function that does such
> common subexpression elimination?

No,


        Stefan