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