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

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