* bug#13033: 24.3.50; regression: read-file-name-internal handles "~" wrong
@ 2012-11-29 21:44 Drew Adams
2012-11-29 23:58 ` Juanma Barranquero
2012-11-30 3:56 ` Stefan Monnier
0 siblings, 2 replies; 20+ messages in thread
From: Drew Adams @ 2012-11-29 21:44 UTC (permalink / raw)
To: 13033
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@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'
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#13033: 24.3.50; regression: read-file-name-internal handles "~" wrong
2012-11-29 21:44 bug#13033: 24.3.50; regression: read-file-name-internal handles "~" wrong Drew Adams
@ 2012-11-29 23:58 ` Juanma Barranquero
2012-11-30 13:12 ` Michael Heerdegen
2012-11-30 3:56 ` Stefan Monnier
1 sibling, 1 reply; 20+ messages in thread
From: Juanma Barranquero @ 2012-11-29 23:58 UTC (permalink / raw)
To: Drew Adams; +Cc: 13033
On Thu, Nov 29, 2012 at 10:44 PM, Drew Adams <drew.adams@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
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#13033: 24.3.50; regression: read-file-name-internal handles "~" wrong
2012-11-29 21:44 bug#13033: 24.3.50; regression: read-file-name-internal handles "~" wrong Drew Adams
2012-11-29 23:58 ` Juanma Barranquero
@ 2012-11-30 3:56 ` Stefan Monnier
2012-11-30 4:08 ` Drew Adams
1 sibling, 1 reply; 20+ messages in thread
From: Stefan Monnier @ 2012-11-30 3:56 UTC (permalink / raw)
To: Drew Adams; +Cc: 13033
> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#13033: 24.3.50; regression: read-file-name-internal handles "~" wrong
2012-11-30 3:56 ` Stefan Monnier
@ 2012-11-30 4:08 ` Drew Adams
2012-11-30 17:00 ` Stefan Monnier
0 siblings, 1 reply; 20+ messages in thread
From: Drew Adams @ 2012-11-30 4:08 UTC (permalink / raw)
To: 'Stefan Monnier'; +Cc: 13033
> 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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#13033: 24.3.50; regression: read-file-name-internal handles "~" wrong
2012-11-29 23:58 ` Juanma Barranquero
@ 2012-11-30 13:12 ` Michael Heerdegen
2012-11-30 13:55 ` Eli Zaretskii
0 siblings, 1 reply; 20+ messages in thread
From: Michael Heerdegen @ 2012-11-30 13:12 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: 13033
Juanma Barranquero <lekktu@gmail.com> writes:
> On Thu, Nov 29, 2012 at 10:44 PM, Drew Adams <drew.adams@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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#13033: 24.3.50; regression: read-file-name-internal handles "~" wrong
2012-11-30 13:12 ` Michael Heerdegen
@ 2012-11-30 13:55 ` Eli Zaretskii
2012-12-01 10:13 ` Michael Heerdegen
0 siblings, 1 reply; 20+ messages in thread
From: Eli Zaretskii @ 2012-11-30 13:55 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: lekktu, 13033
> From: Michael Heerdegen <michael_heerdegen@web.de>
> Date: Fri, 30 Nov 2012 14:12:14 +0100
> Cc: 13033@debbugs.gnu.org
>
> Juanma Barranquero <lekktu@gmail.com> writes:
>
> > On Thu, Nov 29, 2012 at 10:44 PM, Drew Adams <drew.adams@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.)
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#13033: 24.3.50; regression: read-file-name-internal handles "~" wrong
2012-11-30 4:08 ` Drew Adams
@ 2012-11-30 17:00 ` Stefan Monnier
2012-11-30 17:24 ` Drew Adams
2012-11-30 19:01 ` Eli Zaretskii
0 siblings, 2 replies; 20+ messages in thread
From: Stefan Monnier @ 2012-11-30 17:00 UTC (permalink / raw)
To: Drew Adams; +Cc: 13033
>> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#13033: 24.3.50; regression: read-file-name-internal handles "~" wrong
2012-11-30 17:00 ` Stefan Monnier
@ 2012-11-30 17:24 ` Drew Adams
2012-11-30 18:44 ` Stefan Monnier
2012-11-30 19:01 ` Eli Zaretskii
1 sibling, 1 reply; 20+ messages in thread
From: Drew Adams @ 2012-11-30 17:24 UTC (permalink / raw)
To: 'Stefan Monnier'; +Cc: 13033
> 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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#13033: 24.3.50; regression: read-file-name-internal handles "~" wrong
2012-11-30 17:24 ` Drew Adams
@ 2012-11-30 18:44 ` Stefan Monnier
2012-11-30 19:50 ` Drew Adams
0 siblings, 1 reply; 20+ messages in thread
From: Stefan Monnier @ 2012-11-30 18:44 UTC (permalink / raw)
To: Drew Adams; +Cc: 13033
>> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#13033: 24.3.50; regression: read-file-name-internal handles "~" wrong
2012-11-30 17:00 ` Stefan Monnier
2012-11-30 17:24 ` Drew Adams
@ 2012-11-30 19:01 ` Eli Zaretskii
1 sibling, 0 replies; 20+ messages in thread
From: Eli Zaretskii @ 2012-11-30 19:01 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 13033
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 30 Nov 2012 12:00:32 -0500
> Cc: 13033@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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#13033: 24.3.50; regression: read-file-name-internal handles "~" wrong
2012-11-30 18:44 ` Stefan Monnier
@ 2012-11-30 19:50 ` Drew Adams
2012-11-30 20:07 ` Eli Zaretskii
2012-11-30 20:08 ` Stefan Monnier
0 siblings, 2 replies; 20+ messages in thread
From: Drew Adams @ 2012-11-30 19:50 UTC (permalink / raw)
To: 'Stefan Monnier'; +Cc: 13033
> 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.)
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#13033: 24.3.50; regression: read-file-name-internal handles "~" wrong
2012-11-30 19:50 ` Drew Adams
@ 2012-11-30 20:07 ` Eli Zaretskii
2012-11-30 21:09 ` Drew Adams
2012-11-30 20:08 ` Stefan Monnier
1 sibling, 1 reply; 20+ messages in thread
From: Eli Zaretskii @ 2012-11-30 20:07 UTC (permalink / raw)
To: Drew Adams; +Cc: 13033
> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Fri, 30 Nov 2012 11:50:36 -0800
> Cc: 13033@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.)
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#13033: 24.3.50; regression: read-file-name-internal handles "~" wrong
2012-11-30 19:50 ` Drew Adams
2012-11-30 20:07 ` Eli Zaretskii
@ 2012-11-30 20:08 ` Stefan Monnier
2012-11-30 20:42 ` Eli Zaretskii
2012-11-30 21:14 ` Drew Adams
1 sibling, 2 replies; 20+ messages in thread
From: Stefan Monnier @ 2012-11-30 20:08 UTC (permalink / raw)
To: Drew Adams; +Cc: 13033
>> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#13033: 24.3.50; regression: read-file-name-internal handles "~" wrong
2012-11-30 20:08 ` Stefan Monnier
@ 2012-11-30 20:42 ` Eli Zaretskii
2012-11-30 21:14 ` Drew Adams
1 sibling, 0 replies; 20+ messages in thread
From: Eli Zaretskii @ 2012-11-30 20:42 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 13033
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 30 Nov 2012 15:08:57 -0500
> Cc: 13033@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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#13033: 24.3.50; regression: read-file-name-internal handles "~" wrong
2012-11-30 20:07 ` Eli Zaretskii
@ 2012-11-30 21:09 ` Drew Adams
2012-12-01 7:46 ` Eli Zaretskii
0 siblings, 1 reply; 20+ messages in thread
From: Drew Adams @ 2012-11-30 21:09 UTC (permalink / raw)
To: 'Eli Zaretskii'; +Cc: 13033
> > > 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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#13033: 24.3.50; regression: read-file-name-internal handles "~" wrong
2012-11-30 20:08 ` Stefan Monnier
2012-11-30 20:42 ` Eli Zaretskii
@ 2012-11-30 21:14 ` Drew Adams
2014-02-09 2:51 ` Lars Ingebrigtsen
1 sibling, 1 reply; 20+ messages in thread
From: Drew Adams @ 2012-11-30 21:14 UTC (permalink / raw)
To: 'Stefan Monnier'; +Cc: 13033
> 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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#13033: 24.3.50; regression: read-file-name-internal handles "~" wrong
2012-11-30 21:09 ` Drew Adams
@ 2012-12-01 7:46 ` Eli Zaretskii
2012-12-01 16:34 ` Drew Adams
0 siblings, 1 reply; 20+ messages in thread
From: Eli Zaretskii @ 2012-12-01 7:46 UTC (permalink / raw)
To: Drew Adams; +Cc: 13033
> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <monnier@iro.umontreal.ca>, <13033@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?
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#13033: 24.3.50; regression: read-file-name-internal handles "~" wrong
2012-11-30 13:55 ` Eli Zaretskii
@ 2012-12-01 10:13 ` Michael Heerdegen
0 siblings, 0 replies; 20+ messages in thread
From: Michael Heerdegen @ 2012-12-01 10:13 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: lekktu, 13033
Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#13033: 24.3.50; regression: read-file-name-internal handles "~" wrong
2012-12-01 7:46 ` Eli Zaretskii
@ 2012-12-01 16:34 ` Drew Adams
0 siblings, 0 replies; 20+ messages in thread
From: Drew Adams @ 2012-12-01 16:34 UTC (permalink / raw)
To: 'Eli Zaretskii'; +Cc: 13033
> > > 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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#13033: 24.3.50; regression: read-file-name-internal handles "~" wrong
2012-11-30 21:14 ` Drew Adams
@ 2014-02-09 2:51 ` Lars Ingebrigtsen
0 siblings, 0 replies; 20+ messages in thread
From: Lars Ingebrigtsen @ 2014-02-09 2:51 UTC (permalink / raw)
To: Drew Adams; +Cc: 13033
"Drew Adams" <drew.adams@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/
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2014-02-09 2:51 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-11-29 21:44 bug#13033: 24.3.50; regression: read-file-name-internal handles "~" wrong Drew Adams
2012-11-29 23:58 ` Juanma Barranquero
2012-11-30 13:12 ` Michael Heerdegen
2012-11-30 13:55 ` Eli Zaretskii
2012-12-01 10:13 ` Michael Heerdegen
2012-11-30 3:56 ` Stefan Monnier
2012-11-30 4:08 ` Drew Adams
2012-11-30 17:00 ` Stefan Monnier
2012-11-30 17:24 ` Drew Adams
2012-11-30 18:44 ` Stefan Monnier
2012-11-30 19:50 ` Drew Adams
2012-11-30 20:07 ` Eli Zaretskii
2012-11-30 21:09 ` Drew Adams
2012-12-01 7:46 ` Eli Zaretskii
2012-12-01 16:34 ` Drew Adams
2012-11-30 20:08 ` Stefan Monnier
2012-11-30 20:42 ` Eli Zaretskii
2012-11-30 21:14 ` Drew Adams
2014-02-09 2:51 ` Lars Ingebrigtsen
2012-11-30 19:01 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).