GNU bug report logs - #13033
24.3.50; regression: read-file-name-internal handles "~" wrong

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13033 in the body.
You can then email your comments to 13033 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: 24.3.50; regression: read-file-name-internal handles "~" wrong
Date: Thu, 29 Nov 2012 13:44:52 -0800

This is on Windows.  I have Cygwin installed, but that should not
affect how Emacs interprets `~'.
 
My `user-login-name' is "dradams".  My `user-full-name' is "".
 
In this Emacs version,
(read-file-name-internal "~" 'file-exists-p nil) returns "~/dradams/".
 
That is wrong.  Not only is there no such directory as ~/dradams/".  But
my HOME environment variable is defined as "c:\\".
 
In 24.2 and in all previous Emacs versions (with the 2nd arg a dir, as needed),
(read-file-name-internal "~" 'file-exists-p nil) returns nil.
 
Please revert the code that causes this regression.

In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600)
 of 2012-11-19 on MS-W7-DANI
Bzr revision: 110950 monnier <at> iro.umontreal.ca-20121119182725-5p6w4wjimm7epggr
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
 -Ic:/emacs/libs/libXpm-3.5.10/include -Ic:/emacs/libs/libXpm-3.5.10/src
 -Ic:/emacs/libs/libpng-1.2.37-lib/include -Ic:/emacs/libs/zlib-1.2.5
 -Ic:/emacs/libs/giflib-4.1.4-1-lib/include
 -Ic:/emacs/libs/jpeg-6b-4-lib/include
 -Ic:/emacs/libs/tiff-3.8.2-1-lib/include
 -Ic:/emacs/libs/libxml2-2.7.8-w32-bin/include/libxml2
 -Ic:/emacs/libs/gnutls-3.0.9-w32-bin/include
 -Ic:/emacs/libs/libiconv-1.9.2-1-lib/include'
 

Message #8 received at 13033 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 13033 <at> debbugs.gnu.org
Subject: Re: bug#13033: 24.3.50; regression: read-file-name-internal handles
	"~" wrong
Date: Fri, 30 Nov 2012 00:58:29 +0100

On Thu, Nov 29, 2012 at 10:44 PM, Drew Adams <drew.adams <at> oracle.com> wrote:

> In this Emacs version,
> (read-file-name-internal "~" 'file-exists-p nil) returns "~/dradams/".

read-file-name-internal's docstring clearly says:  "Internal
subroutine for `read-file-name'.  Do not call this."

So it's not a regression as long as the public interface of
minibuffer.el is working as expected.

   J

Message #11 received at 13033 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 13033 <at> debbugs.gnu.org
Subject: Re: bug#13033: 24.3.50;
	regression: read-file-name-internal handles "~" wrong
Date: Thu, 29 Nov 2012 22:56:44 -0500

> In this Emacs version,
> (read-file-name-internal "~" 'file-exists-p nil) returns "~/dradams/".
> That is wrong.  Not only is there no such directory as ~/dradams/".  But
> my HOME environment variable is defined as "c:\\".
 
Can you tell me what happens when you do the following:

   (completion--embedded-envvar-table "~" 'file-exists-p nil)
or
   (completion--file-name-table "~" 'file-exists-p nil)
or
   (completion-file-name-table "~" 'file-exists-p nil)


        Stefan

Message #14 received at 13033 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 13033 <at> debbugs.gnu.org
Subject: RE: bug#13033: 24.3.50;
	regression: read-file-name-internal handles "~" wrong
Date: Thu, 29 Nov 2012 20:08:06 -0800

> Can you tell me what happens when you do the following:
> 
> (completion--embedded-envvar-table "~" 'file-exists-p nil)
nil

> (completion--file-name-table "~" 'file-exists-p nil)
"~dradams/"

> (completion-file-name-table "~" 'file-exists-p nil)
"~dradams/"

All from emacs -Q.  In Emacs 24.2 and 23.4 they all return nil.

Message #17 received at 13033 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 13033 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#13033: 24.3.50;
	regression: read-file-name-internal handles "~" wrong
Date: Fri, 30 Nov 2012 14:12:14 +0100

Juanma Barranquero <lekktu <at> gmail.com> writes:

> On Thu, Nov 29, 2012 at 10:44 PM, Drew Adams <drew.adams <at> oracle.com> wrote:
>
> > In this Emacs version,
> > (read-file-name-internal "~" 'file-exists-p nil) returns "~/dradams/".
>
> read-file-name-internal's docstring clearly says:  "Internal
> subroutine for `read-file-name'.  Do not call this."

I'm not sure if I understand the implications.  I thought something like
"Do not call this." is meant for the end users, but also for developers?

Emacs is the "extensible ... editor".  It is quite difficult for any
developer to extend Emacs and contribute packages if we only allow the
use of high-level public interface functions.

I'm helping Drew to fix problems in Icicles.  It was already hard to
understand the not very lengthy documented new completion code.  But if
we are disallowed to use it, we had to stop to develop something like
Icicles.

If we start to change our habits and write Emacs in a way that essential
primitives aren't allowed to be called by developers, this is the
beginning of the end of extensibility.  It is a bug if something like
`read-file-name-internal' is not allowed to be called in third-party
packages.

At university I learned that writing software happens in a way that
every function should have a clear specification for what it
does/returns, and a documentation of this.  Ok, I'm not that much a
software developer that I would know if this is always necessary in that
strong sense.  But it would be helpful if the sources of Emacs (which is
free software that may be used and modified by anyone) would be a bit
more readable and reusable than the compiled byte-code.


Michael.

Message #20 received at 13033 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: lekktu <at> gmail.com, 13033 <at> debbugs.gnu.org
Subject: Re: bug#13033: 24.3.50;
	regression: read-file-name-internal handles "~" wrong
Date: Fri, 30 Nov 2012 15:55:45 +0200

> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Date: Fri, 30 Nov 2012 14:12:14 +0100
> Cc: 13033 <at> debbugs.gnu.org
> 
> Juanma Barranquero <lekktu <at> gmail.com> writes:
> 
> > On Thu, Nov 29, 2012 at 10:44 PM, Drew Adams <drew.adams <at> oracle.com> wrote:
> >
> > > In this Emacs version,
> > > (read-file-name-internal "~" 'file-exists-p nil) returns "~/dradams/".
> >
> > read-file-name-internal's docstring clearly says:  "Internal
> > subroutine for `read-file-name'.  Do not call this."
> 
> I'm not sure if I understand the implications.  I thought something like
> "Do not call this." is meant for the end users, but also for developers?

It means "don't call it from Lisp applications outside basic Lisp
packages that come with Emacs."

If that is a limitation, then I suggest to request additional APIs or
extension of existing APIs, to cover the features which you miss in
the current code base and that prompted you to use this function.

> Emacs is the "extensible ... editor".  It is quite difficult for any
> developer to extend Emacs and contribute packages if we only allow the
> use of high-level public interface functions.

If that is true, then Emacs lacks some public APIs that should be
added or extended.  Using internal functions is not the way.

> If we start to change our habits and write Emacs in a way that essential
> primitives aren't allowed to be called by developers, this is the
> beginning of the end of extensibility.

Most primitives _are_ allowed to be called.  But when you see
something like "internal use only, don't call", that is not something
you should ignore, because whoever wrote that had something serious in
their minds.

> It is a bug if something like `read-file-name-internal' is not
> allowed to be called in third-party packages.

Then please submit bug reports, asking for features that you cannot
get from other APIs.

> At university I learned that writing software happens in a way that
> every function should have a clear specification for what it
> does/returns, and a documentation of this.

If they didn't teach you about the difference between internal APIs
and public APIs, then it's too bad.  Nevertheless, the distinction is
part of our lives.  Some languages have means to conceal private APIs
from external applications, but C and Emacs Lisp don't.  So we use
whatever we got; please always assume that there are good reasons for
that.  (It is OK, of course, to question those reasons, but ignoring
them is not wise, IMO.)

Message #23 received at 13033 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 13033 <at> debbugs.gnu.org
Subject: Re: bug#13033: 24.3.50; regression: read-file-name-internal handles
	"~" wrong
Date: Fri, 30 Nov 2012 12:00:32 -0500

>> Can you tell me what happens when you do the following:
>> (completion--embedded-envvar-table "~" 'file-exists-p nil)
> nil
>> (completion--file-name-table "~" 'file-exists-p nil)
> "~dradams/"
>> (completion-file-name-table "~" 'file-exists-p nil)
> "~dradams/"
> All from emacs -Q.  In Emacs 24.2 and 23.4 they all return nil.

OK, that makes sense since older versions did not support
user-name completion.  Now you say that (read-file-name-internal "~"
'file-exists-p nil) returns "~/dradams/" and I can't understand where
the additional slash comes from.

Also arguably, "~/" should also be a completion candidate, so the above
calls should not complete to "~dradams/" but to "~" (the common prefix
between the two possible completions).


        Stefan

Message #26 received at 13033 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 13033 <at> debbugs.gnu.org
Subject: RE: bug#13033: 24.3.50;
	regression: read-file-name-internal handles "~" wrong
Date: Fri, 30 Nov 2012 09:24:21 -0800

> OK, that makes sense since older versions did not support
> user-name completion.  Now you say that (read-file-name-internal "~"
> 'file-exists-p nil) returns "~/dradams/" and I can't understand where
> the additional slash comes from.
> 
> Also arguably, "~/" should also be a completion candidate, so 
> the above calls should not complete to "~dradams/" but to "~"
> (the common prefix between the two possible completions).

I cannot speak to why the / is included or why ~ is not considered the common
prefix.  Whoever implemented this change might be able to answer that.

To me, the important point in this bug report is that there is no such
directory: ~/dradams/.  And there is no such directory ~dradams either.
Returning either of those as a valid completion for a file/dir name is just
plain wrong, I think.

There is a directory that corresponds to ~.  It is the HOME (env var) directory,
which in my case is c:\.

Seems like perhaps something that might be relevant for Unix/GNU/Linux has been
inappropriately applied to Windows too.  Dunno.

I do not see why user-name completion (whatever that might mean for
Unix/GNU/Linux file-name completion) is involved at all on Windows.  The user
login name has nothing to do with the user's home directory.

Message #29 received at 13033 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 13033 <at> debbugs.gnu.org
Subject: Re: bug#13033: 24.3.50; regression: read-file-name-internal handles
	"~" wrong
Date: Fri, 30 Nov 2012 13:44:53 -0500

>> OK, that makes sense since older versions did not support
>> user-name completion.  Now you say that (read-file-name-internal "~"
>> 'file-exists-p nil) returns "~/dradams/" and I can't understand where
>> the additional slash comes from.
>> Also arguably, "~/" should also be a completion candidate, so 
>> the above calls should not complete to "~dradams/" but to "~"
>> (the common prefix between the two possible completions).

> I cannot speak to why the / is included or why ~ is not considered the common
> prefix.

Then let me state it more clearly: Are you really sure that

  (read-file-name-internal "~" 'file-exists-p nil) returns "~/dradams/"

even though

  (completion--file-name-table "~" 'file-exists-p nil) returns "~dradams/"

?  I ask because read-file-name-internal is defined as:

   (defalias 'read-file-name-internal
     (completion-table-in-turn #'completion--embedded-envvar-table
                               #'completion--file-name-table)

And I don't see where/why completion-table-in-turn would add a /.
I just want to make extra sure that that's indeed the problem, and not
a simple typo.

> And there is no such directory ~dradams either.

Actually, there should be (in the same sense that there is a directory
named ~, i.e. it's a shorthand expanded by Emacs, more specifically by
`expand-file-name').
What does C-x C-f ~dradams/.emacs RET do?  It should open your ~/.emacs file.

> I do not see why user-name completion (whatever that might mean for
> Unix/GNU/Linux file-name completion) is involved at all on Windows.  The user
> login name has nothing to do with the user's home directory.

`expand-file-name's docstring says:

   An initial `~USER/' expands to USER's home directory.


-- Stefan

Message #32 received at 13033 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 13033 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#13033: 24.3.50;
	regression: read-file-name-internal handles "~" wrong
Date: Fri, 30 Nov 2012 21:01:10 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Date: Fri, 30 Nov 2012 12:00:32 -0500
> Cc: 13033 <at> debbugs.gnu.org
> 
> Now you say that (read-file-name-internal "~" 'file-exists-p nil)
> returns "~/dradams/" and I can't understand where the additional
> slash comes from.

Windows doesn't support ~FOO specifications, because there's no
practical way of getting at the home directory of another user.  See
expand-file-name ('getpwnam' on w32.c returns NULL for any user name
but the current user's).

This explains ~/, but where "dradams" comes back after that is
probably explained by what the completion code does, being confused by
the above.

Message #35 received at 13033 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 13033 <at> debbugs.gnu.org
Subject: RE: bug#13033: 24.3.50;
	regression: read-file-name-internal handles "~" wrong
Date: Fri, 30 Nov 2012 11:50:36 -0800

> Are you really sure that
>   (read-file-name-internal "~" 'file-exists-p nil) returns 
> "~/dradams/" even though
>   (completion--file-name-table "~" 'file-exists-p nil) 
> returns "~dradams/"

No, sorry; my bad.  They both return "~dradams/".

> > And there is no such directory ~dradams either.
> 
> Actually, there should be (in the same sense that there is a directory
> named ~, i.e. it's a shorthand expanded by Emacs, more specifically by
> `expand-file-name').
> What does C-x C-f ~dradams/.emacs RET do?  It should open 
> your ~/.emacs file.

It does.  Now.  But it does not in older releases.

Is this change documented for Emacs on MS Windows?  Is it even documented (for
Emacs) for other platforms?  Emacs' handling of `~' is documented, but `~'
followed by `user-login-name'?

Well, searching, I do see something about it in (emacs) `Minibuffer File'.  And
surprisingly, that text is also there in Emacs 23, even though this behavior
seems new - it is not even in 24.2 (for Windows).

And I see nothing about it in NEWS, but perhaps I'm not looking in the right
places.  This is a user-visible change, AFAICT, so it should be called out in
the (Emacs 23) NEWS, I would think.

> > I do not see why user-name completion (whatever that might mean for
> > Unix/GNU/Linux file-name completion) is involved at all on 
> > Windows.  The user login name has nothing to do with the user's home
> > directory.
> 
> `expand-file-name's docstring says:
> 
>    An initial `~USER/' expands to USER's home directory.

That's OK for an Emacs convention.  I just was not aware of it.  (And for MS
Windows itself there is still no association between HOME and the user login
name, AFAIK.  This is an Emacs-only convention.  Nothing wrong with that,
obviously.)

Message #38 received at 13033 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: monnier <at> iro.umontreal.ca, 13033 <at> debbugs.gnu.org
Subject: Re: bug#13033: 24.3.50;
	regression: read-file-name-internal handles "~" wrong
Date: Fri, 30 Nov 2012 22:07:29 +0200

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Date: Fri, 30 Nov 2012 11:50:36 -0800
> Cc: 13033 <at> debbugs.gnu.org
> 
> > What does C-x C-f ~dradams/.emacs RET do?  It should open 
> > your ~/.emacs file.
> 
> It does.  Now.  But it does not in older releases.

Which older releases?  ~username/.emacs works for me on Windows in all
releases since 21.4.

> surprisingly, that text is also there in Emacs 23, even though this behavior
> seems new - it is not even in 24.2 (for Windows).

What happens in Emacs 24.2 for you?  Are you talking about

  C-x C-f ~dradams/.emacs RET

or about

  (read-file-name-internal "~" 'file-exists-p nil)

?

> >    An initial `~USER/' expands to USER's home directory.
> 
> That's OK for an Emacs convention.  I just was not aware of it.  (And for MS
> Windows itself there is still no association between HOME and the user login
> name, AFAIK.

Emacs on Windows supports ~USER only when USER is the current user.
This support always worked in Emacs on Windows.  ~USER for any other
username doesn't work on Windows, and never did.

(HOME is not recognized by MS-Windows itself, but HOMEDRIVE and
HOMEPATH are, and they change for each user as you'd expect.)

Message #41 received at 13033 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 13033 <at> debbugs.gnu.org
Subject: Re: bug#13033: 24.3.50; regression: read-file-name-internal handles
	"~" wrong
Date: Fri, 30 Nov 2012 15:08:57 -0500

>> Are you really sure that
>> (read-file-name-internal "~" 'file-exists-p nil) returns 
>> "~/dradams/" even though
>> (completion--file-name-table "~" 'file-exists-p nil) 
>> returns "~dradams/"
> No, sorry; my bad.  They both return "~dradams/".

OK, thanks, that makes a lot more sense.  So, that looks correct
(i.e. not a bug).  So, were you simply surprised at this behavior, or
did it actually lead to an actual problem somewhere?

>> > And there is no such directory ~dradams either.
>> Actually, there should be (in the same sense that there is a directory
>> named ~, i.e. it's a shorthand expanded by Emacs, more specifically by
>> `expand-file-name').
>> What does C-x C-f ~dradams/.emacs RET do?  It should open 
>> your ~/.emacs file.
> It does.  Now.  But it does not in older releases.

It's done so under posix "for ever".

> That's OK for an Emacs convention.  I just was not aware of it.  (And for MS
> Windows itself there is still no association between HOME and the user login
> name, AFAIK.  This is an Emacs-only convention.  Nothing wrong with that,
> obviously.)

Right, I'll let Windows users figure out whether it's useful or not.


        Stefan

Message #44 received at 13033 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 13033 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#13033: 24.3.50;
	regression: read-file-name-internal handles "~" wrong
Date: Fri, 30 Nov 2012 22:42:14 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Date: Fri, 30 Nov 2012 15:08:57 -0500
> Cc: 13033 <at> debbugs.gnu.org
> 
> >> > And there is no such directory ~dradams either.
> >> Actually, there should be (in the same sense that there is a directory
> >> named ~, i.e. it's a shorthand expanded by Emacs, more specifically by
> >> `expand-file-name').
> >> What does C-x C-f ~dradams/.emacs RET do?  It should open 
> >> your ~/.emacs file.
> > It does.  Now.  But it does not in older releases.
> 
> It's done so under posix "for ever".

And it's done so on Windows forever as well.

> > That's OK for an Emacs convention.  I just was not aware of it.  (And for MS
> > Windows itself there is still no association between HOME and the user login
> > name, AFAIK.  This is an Emacs-only convention.  Nothing wrong with that,
> > obviously.)
> 
> Right, I'll let Windows users figure out whether it's useful or not.

They (Windows users) already did.

Message #47 received at 13033 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: monnier <at> iro.umontreal.ca, 13033 <at> debbugs.gnu.org
Subject: RE: bug#13033: 24.3.50;
	regression: read-file-name-internal handles "~" wrong
Date: Fri, 30 Nov 2012 13:09:26 -0800

> > > What does C-x C-f ~dradams/.emacs RET do?  It should open 
> > > your ~/.emacs file.
> > 
> > It does.  Now.  But it does not in older releases.
> 
> Which older releases?  ~username/.emacs works for me on Windows in all
> releases since 21.4.

I meant that what is new (what this bug report is about) is new. ;-)
That is, completion of `~' to `~dradams/', or of `~dr' to `~dradams/', or
`~dradams' to `~dradams/'.

> What happens in Emacs 24.2 for you?  Are you talking about
> C-x C-f ~dradams/.emacs RET or about
> (read-file-name-internal "~" 'file-exists-p nil)

The latter.  See above.

> > >    An initial `~USER/' expands to USER's home directory.
> > 
> > That's OK for an Emacs convention.  I just was not aware of 
> > it.  (And for MS Windows itself there is still no association
> > between HOME and the user login name, AFAIK.
>
> Emacs on Windows supports ~USER only when USER is the current user.

Yes, that's what the doc says.  But until now, Emacs did not support expansion
of ~USER.  It supported only "expansion" of ~USER/.

> This support always worked in Emacs on Windows.

Expansion of ~USER/, yes; of ~USER, no.

Message #50 received at 13033 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 13033 <at> debbugs.gnu.org
Subject: RE: bug#13033: 24.3.50;
	regression: read-file-name-internal handles "~" wrong
Date: Fri, 30 Nov 2012 13:14:08 -0800

> OK, thanks, that makes a lot more sense.  So, that looks correct
> (i.e. not a bug).  So, were you simply surprised at this behavior, or
> did it actually lead to an actual problem somewhere?

Surprised, I guess.

Message #53 received at 13033 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: monnier <at> iro.umontreal.ca, 13033 <at> debbugs.gnu.org
Subject: Re: bug#13033: 24.3.50;
	regression: read-file-name-internal handles "~" wrong
Date: Sat, 01 Dec 2012 09:46:29 +0200

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <monnier <at> iro.umontreal.ca>, <13033 <at> debbugs.gnu.org>
> Date: Fri, 30 Nov 2012 13:09:26 -0800
> 
> > Emacs on Windows supports ~USER only when USER is the current user.
> 
> Yes, that's what the doc says.  But until now, Emacs did not support expansion
> of ~USER.  It supported only "expansion" of ~USER/.

You mean, 'M-: (expand-file-name "~dradams") RET' doesn't work for you
in any previous releases?  It does for me (with my username instead of
dradams) at least since 21.4.  It expands to my home directory.

If that is not what you mean, then what "expansion" are you talking
about?

Message #56 received at 13033 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: lekktu <at> gmail.com, 13033 <at> debbugs.gnu.org
Subject: Re: bug#13033: 24.3.50;
	regression: read-file-name-internal handles "~" wrong
Date: Sat, 01 Dec 2012 11:13:04 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> > It is a bug if something like `read-file-name-internal' is not
> > allowed to be called in third-party packages.
>
> Then please submit bug reports, asking for features that you cannot
> get from other APIs.

Ok, I'll remember that.  But I wouldn't be surprised if the new API
would just be a corrected and documented version of
`read-file-name-internal'.

> > At university I learned that writing software happens in a way that
> > every function should have a clear specification for what it
> > does/returns, and a documentation of this.
>
> If they didn't teach you about the difference between internal APIs
> and public APIs, then it's too bad.

Yeah, education here is quite strange and idealistic.  They even told us
that such specification and documentation would help developers
understanding the code, as well as it would help these people that maybe
want to change this code some years later.

> Nevertheless, the distinction is part of our lives.  Some languages
> have means to conceal private APIs from external applications, but C
> and Emacs Lisp don't.  So we use whatever we got; please always assume
> that there are good reasons for that.  (It is OK, of course, to
> question those reasons, but ignoring them is not wise, IMO.)

You're right, I think I question the reasons, in this case.

So, I don't think we disagree here.  IIUC, what we need for Icicles is a
completion table for filename completion that can be used as the
COLLECTION argument for `try-completion' or `all-completions'.  That is,
I guess, something like a not forbidden version of
`read-file-name-internal'.


Michael.

Message #59 received at 13033 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: monnier <at> iro.umontreal.ca, 13033 <at> debbugs.gnu.org
Subject: RE: bug#13033: 24.3.50;
	regression: read-file-name-internal handles "~" wrong
Date: Sat, 1 Dec 2012 08:34:28 -0800

> > > Emacs on Windows supports ~USER only when USER is the 
> > > current user.
> > 
> > Yes, that's what the doc says.  But until now, Emacs did 
> > not support expansion of ~USER.  It supported only "expansion"
> > of ~USER/.
> 
> You mean, 'M-: (expand-file-name "~dradams") RET' doesn't work for you
> in any previous releases?  It does for me (with my username instead of
> dradams) at least since 21.4.  It expands to my home directory.
> 
> If that is not what you mean, then what "expansion" are you talking
> about?

I thought I made clear that I was talking about completion.
I used quotation marks around "expansion" to emphasize that.
What is new is the completion behavior.

Message #62 received at 13033 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 'Stefan Monnier' <monnier <at> iro.umontreal.ca>, 13033 <at> debbugs.gnu.org
Subject: Re: bug#13033: 24.3.50;
 regression: read-file-name-internal handles "~" wrong
Date: Sat, 08 Feb 2014 18:51:38 -0800

"Drew Adams" <drew.adams <at> oracle.com> writes:

>> OK, thanks, that makes a lot more sense.  So, that looks correct
>> (i.e. not a bug).  So, were you simply surprised at this behavior, or
>> did it actually lead to an actual problem somewhere?
>
> Surprised, I guess.

So this doesn't seem to be a bug.  Closing.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.