emacsclient: support `/' directory separator on w32

emacsclient: support `/' directory separator on w32

[Michael Mauger]

[-- Attachment #1: Type: text/plain, Size: 189 bytes --]

Emacs supports forward slashes as directory separators on W32.  This small patch makes emacsclient recognize absolute filenames that use a forward slash rather than a backward slash on W32.

[-- Attachment #2: ec-wslash.diff --]
[-- Type: text/plain, Size: 1085 bytes --]

Index: emacs/lib-src/emacsclient.c
===================================================================
RCS file: /cvsroot/emacs/emacs/lib-src/emacsclient.c,v
retrieving revision 1.93
diff -c -r1.93 emacsclient.c
*** emacs/lib-src/emacsclient.c	23 Nov 2006 01:50:59 -0000	1.93
--- emacs/lib-src/emacsclient.c	24 Nov 2006 05:30:32 -0000
***************
*** 452,461 ****
  #ifdef WINDOWSNT
    /* X:\xxx is always absolute; X:xxx is an error and will fail.  */
    if (islower (tolower (filename[0]))
!       && filename[1] == ':' && filename[2] == '\\')
      return TRUE;
  
    /* Both \xxx and \\xxx\yyy are absolute.  */
    if (filename[0] == '\\') return TRUE;
  #endif
  
--- 452,462 ----
  #ifdef WINDOWSNT
    /* X:\xxx is always absolute; X:xxx is an error and will fail.  */
    if (islower (tolower (filename[0]))
!       && filename[1] == ':' && (filename[2] == '\\' || filename[2] == '/'))
      return TRUE;
  
    /* Both \xxx and \\xxx\yyy are absolute.  */
+   /* (The forward slash case is handled previously.) */
    if (filename[0] == '\\') return TRUE;
  #endif
  

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: emacsclient: support `/' directory separator on w32

[Eli Zaretskii]

> Date: Thu, 23 Nov 2006 21:45:25 -0800 (PST)
> From: Michael Mauger <mmaug@yahoo.com>
> 
> Emacs supports forward slashes as directory separators on W32.  This small
> patch makes emacsclient recognize absolute filenames that use a forward
> slash rather than a backward slash on W32.

Thanks, I installed this.

Re: emacsclient: support `/' directory separator on w32

[Jason Rumney]

 if (islower (tolower (filename[0]))

This looks strange. Is there a good reason not to use isalpha() here?

Re: emacsclient: support `/' directory separator on w32

[Juanma Barranquero]

On 11/25/06, Jason Rumney <jasonr@gnu.org> wrote:

> This looks strange. Is there a good reason not to use isalpha() here?

Sleep. And I don't mean the system call.

Please change it.

                    /L/e/k/t/u

Re: emacsclient: support `/' directory separator on w32

[Lennart Borgman]

Michael Mauger wrote:
> Emacs supports forward slashes as directory separators on W32.  This small patch makes emacsclient recognize absolute filenames that use a forward slash rather than a backward slash on W32.
> 
> 
> ------------------------------------------------------------------------
> 
> Index: emacs/lib-src/emacsclient.c
> ===================================================================
> RCS file: /cvsroot/emacs/emacs/lib-src/emacsclient.c,v
> retrieving revision 1.93
> diff -c -r1.93 emacsclient.c
> *** emacs/lib-src/emacsclient.c	23 Nov 2006 01:50:59 -0000	1.93
> --- emacs/lib-src/emacsclient.c	24 Nov 2006 05:30:32 -0000
> ***************
> *** 452,461 ****
>   #ifdef WINDOWSNT
>     /* X:\xxx is always absolute; X:xxx is an error and will fail.  */
>     if (islower (tolower (filename[0]))
> !       && filename[1] == ':' && filename[2] == '\\')
>       return TRUE;
>   
>     /* Both \xxx and \\xxx\yyy are absolute.  */
>     if (filename[0] == '\\') return TRUE;
>   #endif
>   
> --- 452,462 ----
>   #ifdef WINDOWSNT
>     /* X:\xxx is always absolute; X:xxx is an error and will fail.  */
>     if (islower (tolower (filename[0]))
> !       && filename[1] == ':' && (filename[2] == '\\' || filename[2] == '/'))
>       return TRUE;
>   
>     /* Both \xxx and \\xxx\yyy are absolute.  */
> +   /* (The forward slash case is handled previously.) */
>     if (filename[0] == '\\') return TRUE;
>   #endif


I do not understand "(The forward slash case is handled previously.)" -- 
is that correct?

Re: emacsclient: support `/' directory separator on w32

[Jason Rumney]

Lennart Borgman wrote:
> I do not understand "(The forward slash case is handled previously.)" 
> -- is that correct?

It is slightly strange English, but it is true that the forward slash 
case is handled a few lines above that comment in code that is compiled 
on all platforms.

But anyway, that comment was not part of what got checked in, and I 
don't see a great need for it, as the code is close enough to be easily 
spotted.

Re: emacsclient: support `/' directory separator on w32

[Eli Zaretskii]

> Date: Sat, 25 Nov 2006 00:15:20 +0000
> From: Jason Rumney <jasonr@gnu.org>
> Cc: Emacs Devel <emacs-devel@gnu.org>
> 
>  if (islower (tolower (filename[0]))
> 
> This looks strange. Is there a good reason not to use isalpha() here?

Are we 110% sure the drive letter can be only something for which
isalpha returns a non-zero value?  What about isalpha in non-English
locales, for example?

Perhaps we should just test that the second character is a colon, and
leave the first one alone?

Re: emacsclient: support `/' directory separator on w32

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> Are we 110% sure the drive letter can be only something for which
> isalpha returns a non-zero value?  What about isalpha in non-English
> locales, for example?

emacsclient does not call setlocale, thus it always operates in the C
locale.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: emacsclient: support `/' directory separator on w32

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Date: Sat, 25 Nov 2006 11:56:19 +0100
> Cc: emacs-devel@gnu.org, mmaug@yahoo.com, Jason Rumney <jasonr@gnu.org>
> 
> emacsclient does not call setlocale, thus it always operates in the C
> locale.

We are talking about what it does on Windows (that's where the drive
letter issue is relevant).  You are assuming that MS-Windows libraries
behave like they do on Posix platforms, but I'm not sure this
assumption isn't false.

Re: emacsclient: support `/' directory separator on w32

[Jason Rumney]

Eli Zaretskii wrote:
> Are we 110% sure the drive letter can be only something for which
> isalpha returns a non-zero value?  What about isalpha in non-English
> locales, for example?
>   
I'm 99% sure it can only be A-Z. But isalpha() covers a much larger 
range of characters anyway, and it certainly can't be punctuation or 
numeric characters.

Re: emacsclient: support `/' directory separator on w32

[Eli Zaretskii]

> Date: Sat, 25 Nov 2006 11:15:59 +0000
> From: Jason Rumney <jasonr@gnu.org>
> Cc: mmaug@yahoo.com, emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> > Are we 110% sure the drive letter can be only something for which
> > isalpha returns a non-zero value?  What about isalpha in non-English
> > locales, for example?
> >   
> I'm 99% sure it can only be A-Z. But isalpha() covers a much larger 
> range of characters anyway, and it certainly can't be punctuation or 
> numeric characters.

I was asking precisely because on MS-DOS, the drive letter could be
something like `[' or `_' (it allowed 32 letters starting from `A').

I'd say either check A-Z or don't check at all.  But that's a minor
nitpick anyway...

Re: emacsclient: support `/' directory separator on w32

[Juanma Barranquero]

On 11/25/06, Jason Rumney <jasonr@gnu.org> wrote:

> I'm 99% sure it can only be A-Z. But isalpha() covers a much larger
> range of characters anyway, and it certainly can't be punctuation or
> numeric characters.

This is a bit of a moot point. Deciding whether the name is absolute
or relative in emacsclient just changes whether we add the current
directory path or not. But when doing

  C:\default\path> emacsclient 3:\foo.bar

whether Emacs receives "C:\default\path\3:\foo.bar", or "3:\foo.bar"
is largely irrelevant, because they're invalid paths. anyway.

If anything, it's better to accept "X:\foo.bar" as absolute for
uncommon values of X, in case the user is running some weird network
software which allows non-letter drive names.

                    /L/e/k/t/u

Re: emacsclient: support `/' directory separator on w32

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andreas Schwab <schwab@suse.de>
>> Date: Sat, 25 Nov 2006 11:56:19 +0100
>> Cc: emacs-devel@gnu.org, mmaug@yahoo.com, Jason Rumney <jasonr@gnu.org>
>> 
>> emacsclient does not call setlocale, thus it always operates in the C
>> locale.
>
> We are talking about what it does on Windows (that's where the drive
> letter issue is relevant).  You are assuming that MS-Windows libraries
> behave like they do on Posix platforms, but I'm not sure this
> assumption isn't false.

This is standard C, POSIX does not come into play here.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: emacsclient: support `/' directory separator on w32

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Cc: jasonr@gnu.org, mmaug@yahoo.com, emacs-devel@gnu.org
> Date: Sat, 25 Nov 2006 15:26:33 +0100
> >
> > We are talking about what it does on Windows (that's where the drive
> > letter issue is relevant).  You are assuming that MS-Windows libraries
> > behave like they do on Posix platforms, but I'm not sure this
> > assumption isn't false.
> 
> This is standard C, POSIX does not come into play here.

How locales are set in the environment is not standard C.  In
particular, AFAIK, native Windows applications don't honor LANG and
LC_* variables, but instead look in the registry for the locale
definition.  Thus, unless I'm mistaken, there's no ``C locale'' per se
on Windows.

Re: emacsclient: support `/' directory separator on w32

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> How locales are set in the environment is not standard C.

It is.  See 7.11.1.1 The setlocale function.  The C locale is fully
specified by the standard.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: emacsclient: support `/' directory separator on w32

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Cc: jasonr@gnu.org, mmaug@yahoo.com, emacs-devel@gnu.org
> Date: Sat, 25 Nov 2006 15:51:01 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > How locales are set in the environment is not standard C.
> 
> It is.  See 7.11.1.1 The setlocale function.

This is a misunderstanding: by ``environment'' I meant the set of
environment variables outside the program, in the parent shell.

> The C locale is fully specified by the standard.

The standard defines how to set a C locale from within a program, not
how to set it from outside a program.  If emacsclient.c called
setlocale, which it doesn't, I wouldn't be wondering about isalpha.

The standard specifies that the locale should be C unless specified
otherwise, but I don't think the Windows runtime is compatible with
C9x, so we cannot rely on this behavior.  To say nothing of those
users who have some other locale set in their environment.

Re: emacsclient: support `/' directory separator on w32

[Richard Stallman]

    Deciding whether the name is absolute
    or relative in emacsclient just changes whether we add the current
    directory path or not.

In GNU, we use the term "path" only for a list of directories
to search, like the value of PATH.

Re: emacsclient: support `/' directory separator on w32

[Stuart D. Herring]

>> Index: emacs/lib-src/emacsclient.c
>> ===================================================================
>> RCS file: /cvsroot/emacs/emacs/lib-src/emacsclient.c,v
>> retrieving revision 1.93
>> diff -c -r1.93 emacsclient.c
>> *** emacs/lib-src/emacsclient.c	23 Nov 2006 01:50:59 -0000	1.93
>> --- emacs/lib-src/emacsclient.c	24 Nov 2006 05:30:32 -0000
>> ***************
>> *** 452,461 ****
>>   #ifdef WINDOWSNT
>>     /* X:\xxx is always absolute; X:xxx is an error and will fail.  */
>>     if (islower (tolower (filename[0]))
>> !       && filename[1] == ':' && filename[2] == '\\')
>>       return TRUE;
>>
>>     /* Both \xxx and \\xxx\yyy are absolute.  */
>>     if (filename[0] == '\\') return TRUE;
>>   #endif
>>
>> --- 452,462 ----
>>   #ifdef WINDOWSNT
>>     /* X:\xxx is always absolute; X:xxx is an error and will fail.  */
>>     if (islower (tolower (filename[0]))
>> !       && filename[1] == ':' && (filename[2] == '\\' || filename[2] ==
>> '/'))
>>       return TRUE;
>>
>>     /* Both \xxx and \\xxx\yyy are absolute.  */
>> +   /* (The forward slash case is handled previously.) */
>>     if (filename[0] == '\\') return TRUE;
>>   #endif

This is OT, but "X:xxx" is not an error for the filesystem; at least in
many cases, Windows maintains a notion of a current directory per drive,
which means that you get this behavior:

C:\> cd books
C:\BOOKS> cd d:\rocks
C:\BOOKS> rem Note that we haven't gone anywhere...
C:\BOOKS> d:
D:\ROCKS> rem but the command had an effect anyway.
D:\ROCKS> type c:warandpeace.txt
...
D:\ROCKS> rem That was c:\books\warandpeace.txt, not c:\warandpeace.txt:
D:\ROCKS> type c:\warandpeace.txt
File not found
D:\ROCKS> rem Other relative paths can be used:
D:\ROCKS> cd c:nonfiction
D:\ROCKS> c:
C:\BOOKS\NONFICTION> exit

I understand if emacsclient can't use this style of filename (because of
technical limitations, or just for simplicity), or if I'm misunderstanding
the intent of the code, but I thought it important that its existence be
known.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: emacsclient: support `/' directory separator on w32

[Juanma Barranquero]

On 11/27/06, Stuart D. Herring <herring@lanl.gov> wrote:

> I understand if emacsclient can't use this style of filename (because of
> technical limitations, or just for simplicity), or if I'm misunderstanding
> the intent of the code, but I thought it important that its existence be
> known.

It was know; I simply didn't want to add more Windows-specific
complexity to emacsclient. My comment about "X:xxx" being an error
didn't meant that it was an error on Windows, but that it would be an
error to emacsclient.

                    /L/e/k/t/u

Re: emacsclient: support `/' directory separator on w32

[Eli Zaretskii]

> Date: Mon, 27 Nov 2006 21:17:10 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> 
> On 11/27/06, Stuart D. Herring <herring@lanl.gov> wrote:
> 
> > I understand if emacsclient can't use this style of filename (because of
> > technical limitations, or just for simplicity), or if I'm misunderstanding
> > the intent of the code, but I thought it important that its existence be
> > known.
> 
> It was know; I simply didn't want to add more Windows-specific
> complexity to emacsclient.

And I support that decision.

Re: emacsclient: support `/' directory separator on w32

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Mon, 27 Nov 2006 21:17:10 +0100
>> From: "Juanma Barranquero" <lekktu@gmail.com>
>> 
>> On 11/27/06, Stuart D. Herring <herring@lanl.gov> wrote:
>> 
>> > I understand if emacsclient can't use this style of filename (because of
>> > technical limitations, or just for simplicity), or if I'm misunderstanding
>> > the intent of the code, but I thought it important that its existence be
>> > known.
>> 
>> It was know; I simply didn't want to add more Windows-specific
>> complexity to emacsclient.
>
> And I support that decision.

I admit to being surprised.  Drive relative filenames are not exactly
rare under Windows.  There does not happen to be a system call or
something which would make them absolute?

On the other hand, I don't know how Emacs itself deals with them.  It
probably does nothing to maintain its own drive-relative location when
doing `cd'.  And if it doesn't, there is not a terrible incentive to
make emacsclient do so unless drag&drop file names or similar
automatisms not under user control could also produce such file names.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: emacsclient: support `/' directory separator on w32

[Juanma Barranquero]

On 11/28/06, David Kastrup <dak@gnu.org> wrote:

> There does not happen to be a system call or
> something which would make them absolute?

Not a direct system call. In fact, IIRC Windows does not have the
concept of multiple default directories, just one default directory
for each process. It's the CMD shell the one remembering the last
directory (I was going to write "path", but I felt Richard's gaze, out
of nowhere :-) in each visited drive.

                    /L/e/k/t/u

Re: emacsclient: support `/' directory separator on w32

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 11/28/06, David Kastrup <dak@gnu.org> wrote:
>
>> There does not happen to be a system call or
>> something which would make them absolute?
>
> Not a direct system call. In fact, IIRC Windows does not have the
> concept of multiple default directories, just one default directory
> for each process. It's the CMD shell the one remembering the last
> directory (I was going to write "path", but I felt Richard's gaze, out
> of nowhere :-) in each visited drive.

How will an application other than CMD then interpret "A:whatever" ?
Always relative to the root of A: ?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: emacsclient: support `/' directory separator on w32

[Juanma Barranquero]

> How will an application other than CMD then interpret "A:whatever" ?
> Always relative to the root of A: ?

 C:\my\dir> dir i.log

 27/02/2006  10:01          13.178  i.log

 C:\my\dir> I:
 I:\> notepad c:i.log

It opens it. However, Start / Run "notepad c:i.log" does not find the file.

                    /L/e/k/t/u

Re: emacsclient: support `/' directory separator on w32

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

>> How will an application other than CMD then interpret "A:whatever" ?
>> Always relative to the root of A: ?
>
> C:\my\dir> dir i.log
>
> 27/02/2006  10:01          13.178  i.log
>
> C:\my\dir> I:
> I:\> notepad c:i.log
>
> It opens it.

So where does it get the information from?

> However, Start / Run "notepad c:i.log" does not find the file.

So what?  There is no system-wide cwd outside of DOS boxes AFAIR.
Start/Run c:i.log would not work when CMD was on C:\my\dir, so why
should it in this case?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: emacsclient: support `/' directory separator on w32

[Lennart Borgman]

Juanma Barranquero wrote:
>> How will an application other than CMD then interpret "A:whatever" ?
>> Always relative to the root of A: ?
> 
> C:\my\dir> dir i.log
> 
> 27/02/2006  10:01          13.178  i.log
> 
> C:\my\dir> I:
> I:\> notepad c:i.log
> 
> It opens it. However, Start / Run "notepad c:i.log" does not find the file.



And if you first open a file on I: in Notepad and then tried to open 
c:i.log it still works. So Notepad actually in some way knows about the 
.... eh ... directory last used on C:.

Re: emacsclient: support `/' directory separator on w32

[Juanma Barranquero]

On 11/28/06, David Kastrup <dak@gnu.org> wrote:

> So where does it get the information from?

Environment? I don't know. FindFirstFile / FindNextFile seem to work here.

> So what?  There is no system-wide cwd outside of DOS boxes AFAIR.

Yes, you're right. That last bit was a braino.

                    /L/e/k/t/u

Re: emacsclient: support `/' directory separator on w32

[Juanma Barranquero]

On 11/28/06, Juanma Barranquero <lekktu@gmail.com> wrote:

> Environment? I don't know.

I suddenly remembered.

I've made a little program to get a pointer to the environment block
and print its contents. Among normal variables, it contains this:

=::=::\
=C:=C:\my\dir
=I:=I:\

C:\my\dir> echo %=C:%
C:\my\dir

C:\my\dir> echo %=I:%
I:\

                    /L/e/k/t/u

Re: emacsclient: support `/' directory separator on w32

[Lennart Borgman]

Juanma Barranquero wrote:
> On 11/28/06, Juanma Barranquero <lekktu@gmail.com> wrote:
> 
>> Environment? I don't know.
> 
> I suddenly remembered.
> 
> I've made a little program to get a pointer to the environment block
> and print its contents. Among normal variables, it contains this:
> 
> =::=::\
> =C:=C:\my\dir
> =I:=I:\
> 
> C:\my\dir> echo %=C:%
> C:\my\dir
> 
> C:\my\dir> echo %=I:%
> I:\


Great. Then I guess GetFullPathName can be used in Emacsclient on w32.

Re: emacsclient: support `/' directory separator on w32

[Juanma Barranquero]

On 11/28/06, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:

> Great. Then I guess GetFullPathName can be used in Emacsclient on w32.

IMHO emacsclient is not in the business of going 'round looking for files.

                    /L/e/k/t/u

Re: emacsclient: support `/' directory separator on w32

[Lennart Borgman]

Juanma Barranquero wrote:
> On 11/28/06, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:
> 
>> Great. Then I guess GetFullPathName can be used in Emacsclient on w32.
> 
> IMHO emacsclient is not in the business of going 'round looking for files.


Well, it actually have to either require full path names or translate 
relative file names to full file names before sending the file names to 
emacs, or?

Re: emacsclient: support `/' directory separator on w32

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 11/28/06, Juanma Barranquero <lekktu@gmail.com> wrote:
>
>> Environment? I don't know.
>
> I suddenly remembered.
>
> I've made a little program to get a pointer to the environment block
> and print its contents. Among normal variables, it contains this:
>
> =::=::\
> =C:=C:\my\dir
> =I:=I:\
>
> C:\my\dir> echo %=C:%
> C:\my\dir
>
> C:\my\dir> echo %=I:%
> I:\

Makes sense.  The question is whether we should bother to heed this in
emacsclient.  _If_ we heed this sort of thing on the Emacs command
line in some manner, it would probably be cleaner if we did so in
emacsclient as well.

Does anybody have a clue here how Emacs itself behaves?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: emacsclient: support `/' directory separator on w32

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 11/28/06, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:
>
>> Great. Then I guess GetFullPathName can be used in Emacsclient on w32.
>
> IMHO emacsclient is not in the business of going 'round looking for files.

It certainly is, even in Unix.  You can call it with a relative
filename, and that filename certainly should not get expanded relative
to whatever Emacs' idea of a current working directory is, but rather
relative to what Emacsclient's idea is.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: emacsclient: support `/' directory separator on w32

[Juanma Barranquero]

On 11/28/06, David Kastrup <dak@gnu.org> wrote:

> The question is whether we should bother to heed this in
> emacsclient.

No, IMO.

                    /L/e/k/t/u

Re: emacsclient: support `/' directory separator on w32

[Juanma Barranquero]

On 11/28/06, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:

> Well, it actually have to either require full path names or translate
> relative file names to full file names before sending the file names to
> emacs, or?

I don't understand the question. It currently accepts absolute
pathnames, or pathnames relative to the current directory. Seems
sensible to me. And portable. Most operating systems have the concept
of a default current directory. I don't think most of them have the
concept of a default current directory for each
drive/device/filesystem/younameit (but I could be wrong).

                    /L/e/k/t/u

Re: emacsclient: support `/' directory separator on w32

[Juanma Barranquero]

On 11/28/06, David Kastrup <dak@gnu.org> wrote:

> It certainly is, even in Unix.  You can call it with a relative
> filename

Semantics. I don't call using the current directory "go looking for a
file". You apparently do.

                    /L/e/k/t/u

Re: emacsclient: support `/' directory separator on w32

[Lennart Borgman]

David Kastrup wrote:
> "Juanma Barranquero" <lekktu@gmail.com> writes:
> 
>> On 11/28/06, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:
>>
>>> Great. Then I guess GetFullPathName can be used in Emacsclient on w32.
>> IMHO emacsclient is not in the business of going 'round looking for files.
> 
> It certainly is, even in Unix.  You can call it with a relative
> filename, and that filename certainly should not get expanded relative
> to whatever Emacs' idea of a current working directory is, but rather
> relative to what Emacsclient's idea is.


I just took a look at the code. It does this by sending current working 
directory. Should not this be replaced on w32 with something using what 
Juanma found before, for example GetEnv("=C:")?

Re: emacsclient: support `/' directory separator on w32

[Lennart Borgman]

David Kastrup wrote:
> "Juanma Barranquero" <lekktu@gmail.com> writes:
> 
>> On 11/28/06, Juanma Barranquero <lekktu@gmail.com> wrote:
>>
>>> Environment? I don't know.
>> I suddenly remembered.
>>
>> I've made a little program to get a pointer to the environment block
>> and print its contents. Among normal variables, it contains this:
>>
>> =::=::\
>> =C:=C:\my\dir
>> =I:=I:\
>>
>> C:\my\dir> echo %=C:%
>> C:\my\dir
>>
>> C:\my\dir> echo %=I:%
>> I:\
> 
> Makes sense.  The question is whether we should bother to heed this in
> emacsclient.  _If_ we heed this sort of thing on the Emacs command
> line in some manner, it would probably be cleaner if we did so in
> emacsclient as well.
> 
> Does anybody have a clue here how Emacs itself behaves?


Without testing I guess this is hidden in the C IO routines.

Re: emacsclient: support `/' directory separator on w32

[Juanma Barranquero]

On 11/28/06, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:

> Should not this be replaced on w32 with something using what
> Juanma found before, for example GetEnv("=C:")?

Which, BTW, is meaningless in emacsclientw.exe (unless you pretend to
run emacsclientw.exe often from a console window).

                    /L/e/k/t/u

Re: emacsclient: support `/' directory separator on w32

[Lennart Borgman]

Juanma Barranquero wrote:
> On 11/28/06, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:
> 
>> Well, it actually have to either require full path names or translate
>> relative file names to full file names before sending the file names to
>> emacs, or?
> 
> I don't understand the question. It currently accepts absolute
> pathnames, or pathnames relative to the current directory. Seems
> sensible to me. And portable. Most operating systems have the concept
> of a default current directory. I don't think most of them have the
> concept of a default current directory for each
> drive/device/filesystem/younameit (but I could be wrong).


If Emacs would only get a relative file name it would have no chance to 
find the file. As I wrote in another letter it also gets the cwd, but in 
those cases we are discussing here it gets the wrong cwd.

So this is actually a bug that we should fix. It should be rather easy 
to do that by just using the cwd for the given file name's drive so to say.

Re: emacsclient: support `/' directory separator on w32

[Lennart Borgman]

Juanma Barranquero wrote:
> On 11/28/06, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:
> 
>> Should not this be replaced on w32 with something using what
>> Juanma found before, for example GetEnv("=C:")?
> 
> Which, BTW, is meaningless in emacsclientw.exe (unless you pretend to
> run emacsclientw.exe often from a console window).


There is really no reason to treat the command line and the GUI version 
different in the case of file name arguments.

Re: emacsclient: support `/' directory separator on w32

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 11/28/06, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:
>
>> Well, it actually have to either require full path names or translate
>> relative file names to full file names before sending the file names to
>> emacs, or?
>
> I don't understand the question. It currently accepts absolute
> pathnames, or pathnames relative to the current directory. Seems
> sensible to me. And portable.

I would not call that portable.  "portable" means "work everywhere",
not "work everywhere under the assumption that everywhere is supposed
to be like Unix".

> Most operating systems have the concept of a default current
> directory. I don't think most of them have the concept of a default
> current directory for each drive/device/filesystem/younameit (but I
> could be wrong).

Most operating systems have the concept of relative file names that
can resolve to different files in different environments.

So Emacsclient has to deal with this.  At the moment it appears to do
this by passing both the relative filename as well as what it
considers relevant for absolutizing it, the current work directory.

It appears that the current work directory alone is not sufficient.  I
see two approaches here: either Emacsclient will pass more info to
Emacs, or it creates the absolute file names itself.  The latter
sounds more sane to me, however it requires that Emacsclient itself
knows which parts on the command lines are filenames to be opened, and
which are just arguments to be interpreted by commands or stuff.

Maybe we really don't want to go there, but in the mean time, it
sounds flaky.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: emacsclient: support `/' directory separator on w32

[Juanma Barranquero]

On 11/28/06, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:

> There is really no reason to treat the command line and the GUI version
> different in the case of file name arguments.

But the GUI version won't receive (or need) these "default directory"
pseudo-envvars.

                    /L/e/k/t/u

Re: emacsclient: support `/' directory separator on w32

[Juanma Barranquero]

On 11/28/06, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:

> So this is actually a bug that we should fix.

Fix it, and propose the change.

                    /L/e/k/t/u

Re: emacsclient: support `/' directory separator on w32

[Lennart Borgman]

David Kastrup wrote:

> It appears that the current work directory alone is not sufficient.  I
> see two approaches here: either Emacsclient will pass more info to
> Emacs, or it creates the absolute file names itself.  The latter
> sounds more sane to me, however it requires that Emacsclient itself
> knows which parts on the command lines are filenames to be opened, and
> which are just arguments to be interpreted by commands or stuff.


It seems easier to use the environmental variable that Juanma found 
before (=C:, =D: etc)

Re: emacsclient: support `/' directory separator on w32

[Lennart Borgman]

Juanma Barranquero wrote:
> On 11/28/06, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:
> 
>> There is really no reason to treat the command line and the GUI version
>> different in the case of file name arguments.
> 
> But the GUI version won't receive (or need) these "default directory"
> pseudo-envvars.


I am not sure, but I can not find any logic in this unless the use of 
those "pseudo-envvars" is implemented in low level IO.

So it surely can make sense in the GUI version too if we want to make a 
UI that is consistent with other well behaved w32 programs.

Re: emacsclient: support `/' directory separator on w32

[David Kastrup]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> David Kastrup wrote:
>
>> It appears that the current work directory alone is not sufficient.  I
>> see two approaches here: either Emacsclient will pass more info to
>> Emacs, or it creates the absolute file names itself.  The latter
>> sounds more sane to me, however it requires that Emacsclient itself
>> knows which parts on the command lines are filenames to be opened, and
>> which are just arguments to be interpreted by commands or stuff.
>
>
> It seems easier to use the environmental variable that Juanma found
> before (=C:, =D: etc)

I don't see how.  Those would have to get passed into Emacs where they
would have to temporarily replace those variables in Emacs' own
environment while Emacs is processing the Emacsclient command line.

That sounds like a messy thing to do.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: emacsclient: support `/' directory separator on w32

[David Kastrup]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> Juanma Barranquero wrote:
>> On 11/28/06, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:
>>
>>> Well, it actually have to either require full path names or translate
>>> relative file names to full file names before sending the file names to
>>> emacs, or?
>>
>> I don't understand the question. It currently accepts absolute
>> pathnames, or pathnames relative to the current directory. Seems
>> sensible to me. And portable. Most operating systems have the concept
>> of a default current directory. I don't think most of them have the
>> concept of a default current directory for each
>> drive/device/filesystem/younameit (but I could be wrong).
>
>
> If Emacs would only get a relative file name it would have no chance
> to find the file. As I wrote in another letter it also gets the cwd,
> but in those cases we are discussing here it gets the wrong cwd.
>
> So this is actually a bug that we should fix. It should be rather easy
> to do that by just using the cwd for the given file name's drive so to
> say.

There can be several file names with different drives on the command
line, and I don't know whether Emacsclient knows which command line
arguments are actually file names.

If there is a good solution that is not excessively awkward, it might
nice producing it, but I am not sure of that.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: emacsclient: support `/' directory separator on w32

[Lennart Borgman]

David Kastrup wrote:

>> If Emacs would only get a relative file name it would have no chance
>> to find the file. As I wrote in another letter it also gets the cwd,
>> but in those cases we are discussing here it gets the wrong cwd.
>>
>> So this is actually a bug that we should fix. It should be rather easy
>> to do that by just using the cwd for the given file name's drive so to
>> say.
> 
> There can be several file names with different drives on the command
> line, and I don't know whether Emacsclient knows which command line
> arguments are actually file names.
> 
> If there is a good solution that is not excessively awkward, it might
> nice producing it, but I am not sure of that.

Emacsclient knows which args are file names and sends cwd just before 
the file name so it seems easy to fix. I am going to try later today.

Re: emacsclient: support `/' directory separator on w32

[Eli Zaretskii]

> Cc: "Juanma Barranquero" <lekktu@gmail.com>, emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Tue, 28 Nov 2006 09:26:41 +0100
> 
> I admit to being surprised.  Drive relative filenames are not exactly
> rare under Windows.

They are quite rare, actually.  And it doesn't make great sense to me
to support them in the context of emacsclient, where they are even
more rare, since emacsclient is normally invoked from another program.

> There does not happen to be a system call or something which would
> make them absolute?

Yes, there is such a system call, but I don't see a need to go to such
trouble.

> On the other hand, I don't know how Emacs itself deals with them.

It deals with them just fine.  But Emacs needs to handle file names
typed by a human, whereas emacsclient normally doesn't.  So it is an
important feature in Emacs, but an obscure one in emacsclient.

> It probably does nothing to maintain its own drive-relative location
> when doing `cd'.

There's no need: the OS does that for us.

> And if it doesn't, there is not a terrible incentive to make
> emacsclient do so unless drag&drop file names or similar automatisms
> not under user control could also produce such file names.

Right.

Re: emacsclient: support `/' directory separator on w32

[Eli Zaretskii]

> Date: Tue, 28 Nov 2006 12:59:35 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> On 11/28/06, David Kastrup <dak@gnu.org> wrote:
> 
> > There does not happen to be a system call or
> > something which would make them absolute?
> 
> Not a direct system call.

Really?  I do see such a system call: it's called _getdcwd, and we
actually use it in Emacs.

> In fact, IIRC Windows does not have the concept of multiple default
> directories, just one default directory for each process. It's the
> CMD shell the one remembering the last directory

This is different for different versions of Windows.  I think what you
say is only true for W2K/XP and later.

Re: emacsclient: support `/' directory separator on w32

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Tue, 28 Nov 2006 13:36:15 +0100
> Cc: emacs-devel@gnu.org
> 
> How will an application other than CMD then interpret "A:whatever" ?
> Always relative to the root of A: ?

I think Juanma is mistaken: an application has a cwd on every drive.
Try "ls c:", for example, after you change the cwd on the drive C.

Re: emacsclient: support `/' directory separator on w32

[Eli Zaretskii]

> Date: Tue, 28 Nov 2006 14:37:04 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> On 11/28/06, David Kastrup <dak@gnu.org> wrote:
> 
> > So where does it get the information from?
> 
> Environment? I don't know. FindFirstFile / FindNextFile seem to work here.

No, I think it's in the OS.  Otherwise, how would _getdcwd work?

Re: emacsclient: support `/' directory separator on w32

[Eli Zaretskii]

> Date: Tue, 28 Nov 2006 15:12:36 +0100
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> Cc: emacs-devel@gnu.org
> 
> Great. Then I guess GetFullPathName can be used in Emacsclient on w32.

I don't think we should mess with this, certainly not now.  Let's not
make unnecessary changes, because that interferes with the pretest.

Re: emacsclient: support `/' directory separator on w32

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Tue, 28 Nov 2006 15:20:55 +0100
> Cc: emacs-devel@gnu.org
> 
> Makes sense.  The question is whether we should bother to heed this in
> emacsclient.

No, I don't think so.

> Does anybody have a clue here how Emacs itself behaves?

It currently converts X: into X:/.

Re: emacsclient: support `/' directory separator on w32

[Eli Zaretskii]

> Date: Tue, 28 Nov 2006 16:43:18 +0100
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> Cc: Juanma Barranquero <lekktu@gmail.com>, emacs-devel@gnu.org
> 
> Emacsclient knows which args are file names and sends cwd just before 
> the file name so it seems easy to fix. I am going to try later today.

No, please don't!  This is an obscure and little-used case; rocking
the pretest boat for its sake is entirely inappropriate!

Re: emacsclient: support `/' directory separator on w32

[Juanma Barranquero]

On 11/28/06, Eli Zaretskii <eliz@gnu.org> wrote:

> Really?  I do see such a system call: it's called _getdcwd, and we
> actually use it in Emacs.

AFAICS, that's a library routine, not a system call (at least, the
Platform SDK documentation does not mention it). But I would've
mentioned it anyway if only I had thought of it :)

> This is different for different versions of Windows.  I think what you
> say is only true for W2K/XP and later.

Possibly. I admit I've not done much pre-2K programming lately.

                    /L/e/k/t/u

Re: emacsclient: support `/' directory separator on w32

[Eli Zaretskii]

> Date: Tue, 28 Nov 2006 21:28:41 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> > Really?  I do see such a system call: it's called _getdcwd, and we
> > actually use it in Emacs.
> 
> AFAICS, that's a library routine, not a system call (at least, the
> Platform SDK documentation does not mention it).

Fine, but GetFullPathname _is_ a system call, and I'm pretty sure
_getdcwd relies on it.

Re: emacsclient: support `/' directory separator on w32

[Juanma Barranquero]

On 11/28/06, Eli Zaretskii <eliz@gnu.org> wrote:

> Fine, but GetFullPathname _is_ a system call

You're right.

                    /L/e/k/t/u

Re: emacsclient: support `/' directory separator on w32

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Tue, 28 Nov 2006 15:20:55 +0100
>> Cc: emacs-devel@gnu.org
>> 
>> Makes sense.  The question is whether we should bother to heed this in
>> emacsclient.
>
> No, I don't think so.
>
>> Does anybody have a clue here how Emacs itself behaves?
>
> It currently converts X: into X:/.

Well, if it does, there would be little point in having emacsclient do
something different.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: emacsclient: support `/' directory separator on w32

[Lennart Borgman]

Eli Zaretskii wrote:
>> Date: Tue, 28 Nov 2006 16:43:18 +0100
>> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
>> Cc: Juanma Barranquero <lekktu@gmail.com>, emacs-devel@gnu.org
>>
>> Emacsclient knows which args are file names and sends cwd just before 
>> the file name so it seems easy to fix. I am going to try later today.
> 
> No, please don't!  This is an obscure and little-used case; rocking
> the pretest boat for its sake is entirely inappropriate!


I decided to test since I consider it a bug. It is easy to fix once you 
understand the pretty obscure code in emacsclient.c. I have tested a 
little change like this:

   if ((argc - optind > 0))
     {
       for (i = optind; i < argc; i++)
	{
           int is_file;
           is_file = 0;
	  if (eval)
             ; /* Don't prepend any cwd or anything like that.  */
	  else if (*argv[i] == '+')
	    {
	      char *p = argv[i] + 1;
	      while (isdigit ((unsigned char) *p) || *p == ':') p++;
	      if (*p != 0)
		{
                   trace("+ obscure path\n");
		  SEND_QUOTED (cwd);
		  SEND_STRING ("/");
		}
	    }
           else //if (! file_name_absolute_p (argv[i]))
	    {
               //SEND_QUOTED (cwd);
	      //SEND_STRING ("/");
               /* It is a file name, expand it! */
               trace("file path\n");
               is_file = 1;
               expand_file_name(cwd, argv[i], srvfile);
	    }

           trace("is_file=%d\n", is_file);
           if (is_file)
             SEND_QUOTED (srvfile);
           else
             SEND_QUOTED (argv[i]);
	  SEND_STRING (" ");
	}
     }

The only important change here is that the expanding to an absolute file 
name is made explicit and therefore is easier to understand and to make 
system independent. You can see what I have commented out and the call 
to expand_file_name (which I just wrote, nothing special, just what we 
just wrote about for w32 and the same as above for other systems).

This works pretty well I believe. I will distribute it with my patched 
version and would be glad if we used it in the official version.

Gnuclient also had this bug before and I was quite disturbed of by it.

Re: emacsclient: support `/' directory separator on w32

[Lennart Borgman]

David Kastrup wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>>> From: David Kastrup <dak@gnu.org>
>>> Date: Tue, 28 Nov 2006 15:20:55 +0100
>>> Cc: emacs-devel@gnu.org
>>>
>>> Makes sense.  The question is whether we should bother to heed this in
>>> emacsclient.
>> No, I don't think so.
>>
>>> Does anybody have a clue here how Emacs itself behaves?
>> It currently converts X: into X:/.
> 
> Well, if it does, there would be little point in having emacsclient do
> something different.

There still is. Emacsclient is used from outside Emacs and there we 
should try to be consistent with the existing UI.

Re: emacsclient: support `/' directory separator on w32

[David Kastrup]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> David Kastrup wrote:
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> From: David Kastrup <dak@gnu.org>
>>>> Date: Tue, 28 Nov 2006 15:20:55 +0100
>>>> Cc: emacs-devel@gnu.org
>>>>
>>>> Makes sense.  The question is whether we should bother to heed this in
>>>> emacsclient.
>>> No, I don't think so.
>>>
>>>> Does anybody have a clue here how Emacs itself behaves?
>>> It currently converts X: into X:/.
>>
>> Well, if it does, there would be little point in having emacsclient do
>> something different.
>
> There still is. Emacsclient is used from outside Emacs and there we
> should try to be consistent with the existing UI.

I don't see any sense in implementing something for the Emacsclient
commandline which does not work similarly for the Emacs commandline.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: emacsclient: support `/' directory separator on w32

[Juanma Barranquero]

On 11/29/06, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:

> Emacsclient is used from outside Emacs and there we
> should try to be consistent with the existing UI.

For some definition of "consistency", of course.

W:\> gzip c:input.txt
c:input.txt: No such file or directory

W:\> diff c:get-diskusage.ps1 c:get-fileversion.ps1
diff: c:get-diskusage.ps1: No such file or directory
diff: c:get-fileversion.ps1: No such file or directory

W:\> grep solve c:sudoku.hs
grep: c:sudoku.hs: No such file or directory

etc. etc.

                    /L/e/k/t/u

Re: emacsclient: support `/' directory separator on w32

[Lennart Borgman]

Juanma Barranquero wrote:
> On 11/29/06, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:
> 
>> Emacsclient is used from outside Emacs and there we
>> should try to be consistent with the existing UI.
> 
> For some definition of "consistency", of course.
> 
> W:\> gzip c:input.txt
> c:input.txt: No such file or directory
> 
> W:\> diff c:get-diskusage.ps1 c:get-fileversion.ps1
> diff: c:get-diskusage.ps1: No such file or directory
> diff: c:get-fileversion.ps1: No such file or directory
> 
> W:\> grep solve c:sudoku.hs
> grep: c:sudoku.hs: No such file or directory
> 
> etc. etc.


These are just bugs. If you use findstr instead of grep it works. If you 
use notepad it works.

I am not quite sure, but I believe I have seen that the recommendation 
from MS for a file argument is to use GetFullPathName. However it was 
quite a while since I looked into that.

Re: emacsclient: support `/' directory separator on w32

[Lennart Borgman]

David Kastrup wrote:

> I don't see any sense in implementing something for the Emacsclient
> commandline which does not work similarly for the Emacs commandline.

You have to start correcting bugs somewhere ;-)

Re: emacsclient: support `/' directory separator on w32

[Juanma Barranquero]

On 11/29/06, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:

> These are just bugs.

I think the word you were searching for is "counterexamples".

                    /L/e/k/t/u

Re: emacsclient: support `/' directory separator on w32

[David Kastrup]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> David Kastrup wrote:
>
>> I don't see any sense in implementing something for the Emacsclient
>> commandline which does not work similarly for the Emacs
>> commandline.
>
> You have to start correcting bugs somewhere ;-)

Emacsclient is supposed to be a substitute for Emacs.  I consider
giving it isolated different semantics more a bug than a bug fix.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: emacsclient: support `/' directory separator on w32

[Eli Zaretskii]

> Date: Wed, 29 Nov 2006 00:12:00 +0100
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> CC:  dak@gnu.org,  lekktu@gmail.com,  emacs-devel@gnu.org
> 
> This works pretty well I believe. I will distribute it with my patched 
> version and would be glad if we used it in the official version.

Why do you insist on distributing deviant versions, when the official
ones are not broken?

Please, let's just drop this issue until after the release.  The right
fix is not that simple; I agree with David that emacsclient should be
consistent with Emacs, not with notepad.

Re: emacsclient: support `/' directory separator on w32

[Eli Zaretskii]

> Date: Wed, 29 Nov 2006 00:28:50 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> On 11/29/06, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:
> 
> > Emacsclient is used from outside Emacs and there we
> > should try to be consistent with the existing UI.
> 
> For some definition of "consistency", of course.
> 
> W:\> gzip c:input.txt
> c:input.txt: No such file or directory
> 
> W:\> diff c:get-diskusage.ps1 c:get-fileversion.ps1
> diff: c:get-diskusage.ps1: No such file or directory
> diff: c:get-fileversion.ps1: No such file or directory
> 
> W:\> grep solve c:sudoku.hs
> grep: c:sudoku.hs: No such file or directory

You have buggy ports; mine do work with c:foo.

Re: emacsclient: support `/' directory separator on w32

[Eli Zaretskii]

> Date: Wed, 29 Nov 2006 01:51:51 +0100
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> Cc: emacs-devel@gnu.org
> 
> I am not quite sure, but I believe I have seen that the recommendation 
> from MS for a file argument is to use GetFullPathName.

But Emacs does not do it, see expand-file-name.  So your proposed
changes make emacsclient behave differently than Emacs.

Re: emacsclient: support `/' directory separator on w32

[Lennart Borgman]

Eli Zaretskii wrote:
>> Date: Wed, 29 Nov 2006 01:51:51 +0100
>> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
>> Cc: emacs-devel@gnu.org
>>
>> I am not quite sure, but I believe I have seen that the recommendation 
>> from MS for a file argument is to use GetFullPathName.
> 
> But Emacs does not do it, see expand-file-name.  So your proposed
> changes make emacsclient behave differently than Emacs.


What is the reason that Emacs does not do it?

Re: emacsclient: support `/' directory separator on w32

[Lennart Borgman]

Eli Zaretskii wrote:
>> Date: Wed, 29 Nov 2006 00:12:00 +0100
>> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
>> CC:  dak@gnu.org,  lekktu@gmail.com,  emacs-devel@gnu.org
>>
>> This works pretty well I believe. I will distribute it with my patched 
>> version and would be glad if we used it in the official version.
> 
> Why do you insist on distributing deviant versions, when the official
> ones are not broken?


Because I think the official version is a little bit broken and lack 
some functionality. BTW I distribute both the official and the patched 
version.


> Please, let's just drop this issue until after the release.  The right
> fix is not that simple; I agree with David that emacsclient should be
> consistent with Emacs, not with notepad.


I think that both Emacs and Emacsclient should be consistent with the UI 
on w32 and therefore with Notepad.

Re: emacsclient: support `/' directory separator on w32

[Juanma Barranquero]

On 11/29/06, Eli Zaretskii <eliz@gnu.org> wrote:

> You have buggy ports; mine do work with c:foo.

MSYS/MinGW. I wouldn't call them buggy. They serve me well, and they
rarely ask for a raise; at most an update every now and then.

                    /L/e/k/t/u

Re: emacsclient: support `/' directory separator on w32

[David Kastrup]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> Eli Zaretskii wrote:
>>> Date: Wed, 29 Nov 2006 01:51:51 +0100
>>> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
>>> Cc: emacs-devel@gnu.org
>>>
>>> I am not quite sure, but I believe I have seen that the
>>> recommendation from MS for a file argument is to use
>>> GetFullPathName.
>>
>> But Emacs does not do it, see expand-file-name.  So your proposed
>> changes make emacsclient behave differently than Emacs.
>
>
> What is the reason that Emacs does not do it?

Emacs stores its idea of "relativeness" in `default-directory', a
buffer-local variable.

It is not clear how one would attempt to model drive-relativeness on
different drives than the one the buffer is in.  It is possible to
make `default-directory' point to a different drive from that of
`buffer-file-name'.  Maintaining the old drive-relative position at
the same time does not seem possible to do in a reasonably predictable
way.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: emacsclient: support `/' directory separator on w32

[Lennart Borgman]

David Kastrup wrote:
> Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
> 
>> Eli Zaretskii wrote:
>>>> Date: Wed, 29 Nov 2006 01:51:51 +0100
>>>> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
>>>> Cc: emacs-devel@gnu.org
>>>>
>>>> I am not quite sure, but I believe I have seen that the
>>>> recommendation from MS for a file argument is to use
>>>> GetFullPathName.
>>> But Emacs does not do it, see expand-file-name.  So your proposed
>>> changes make emacsclient behave differently than Emacs.
>>
>> What is the reason that Emacs does not do it?
> 
> Emacs stores its idea of "relativeness" in `default-directory', a
> buffer-local variable.
> 
> It is not clear how one would attempt to model drive-relativeness on
> different drives than the one the buffer is in.  It is possible to
> make `default-directory' point to a different drive from that of
> `buffer-file-name'.  Maintaining the old drive-relative position at
> the same time does not seem possible to do in a reasonably predictable
> way.


I also thought so at first. At a second thought it seems simple. Just 
set emacs working directory (on w32) at the same time as setting 
default-directory. Then GetFullPathName will always return a result that 
is consistent with default-directory.

However the glory details of coding this in emacs is not something I 
precisely know immediately how to do ;-)

And setting the working directory makes me a bit scared too. But is the 
working directory ever used in emacs? (I found one call to 
get_current_directory_name in smc_save_yourself.)


Some more trouble: You can ask emacs to edit a file with a name like 
d:/somepath/c:hello.txt. The characters

    \/:*?"<>|

are not allowed in the last part of a file or directory name on w32. 
(Actually using a file name with ":" in the name is possible, but it 
does not do what an innocent user expect. It creates a file with a 
hidden what-did-they-call-it? part.)

Unfortunately GetLongPathName() does not care about these characters. I 
therefore tried with GetLongPathName(), but I could not link with MingGW:

   oo-spd/i386/emacsclient.o(.text+0x283b):emacsclient.c:
      undefined reference to `GetLongPathName'

Maybe there is a better API for checking file names?

Re: emacsclient: support `/' directory separator on w32

[Juanma Barranquero]

On 11/29/06, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:

> It creates a file with a
> hidden what-did-they-call-it? part.)

Streams.

> Unfortunately GetLongPathName() does not care about these characters.

GetLongPathName() is unsupported on W95, according to the Platform SDK.

> therefore tried with GetLongPathName(), but I could not link with MingGW:
>
>    oo-spd/i386/emacsclient.o(.text+0x283b):emacsclient.c:
>       undefined reference to `GetLongPathName'

Not even with explicit GetLongPathNameA?

                    /L/e/k/t/u

Re: emacsclient: support `/' directory separator on w32

[Lennart Borgman]

Juanma Barranquero wrote:
> On 11/29/06, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:
> 
>> It creates a file with a
>> hidden what-did-they-call-it? part.)
> 
> Streams.
> 
>> Unfortunately GetLongPathName() does not care about these characters.
> 
> GetLongPathName() is unsupported on W95, according to the Platform SDK.

Thanks, I missed that.


>> therefore tried with GetLongPathName(), but I could not link with MingGW:
>>
>>    oo-spd/i386/emacsclient.o(.text+0x283b):emacsclient.c:
>>       undefined reference to `GetLongPathName'
> 
> Not even with explicit GetLongPathNameA?


No, I told it on the mingw-user list.

Re: emacsclient: support `/' directory separator on w32

[Eli Zaretskii]

> Date: Wed, 29 Nov 2006 09:29:34 +0100
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> CC:  lekktu@gmail.com,  emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> >> Date: Wed, 29 Nov 2006 01:51:51 +0100
> >> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> >> Cc: emacs-devel@gnu.org
> >>
> >> I am not quite sure, but I believe I have seen that the recommendation 
> >> from MS for a file argument is to use GetFullPathName.
> > 
> > But Emacs does not do it, see expand-file-name.  So your proposed
> > changes make emacsclient behave differently than Emacs.
> 
> 
> What is the reason that Emacs does not do it?

I don't know, perhaps some history, or maybe there's a problem in
supporting it on Windows due to some adverse side effects (I vaguely
remember some problems in the past, but perhaps my failing memory just
tricks me; I need to search archives of old discussions and ChangeLogs
for old changes).  To ``fix'' this now in Emacs would be a mistake,
since Emacs on Windows works like that for a long time, and no one
complained AFAIR.  It is a problem that needs to be carefully studied,
implemented and tested, and now is not the time to do it.

As long as Emacs does not support drive-relative file names, doing
that in emacsclient will only create confusion and bug reports.  Let's
let this issue lie; we have already a terrific new feature--emacsclient
is working on Windows.  Even if there's a limitation that it doesn't
support d:foo, it's not a grave problem; people will live with it, I
assure you.  Let's revisit the whole issue of drive-relative file
names after the release.

Re: emacsclient: support `/' directory separator on w32

[Eli Zaretskii]

> Date: Wed, 29 Nov 2006 09:32:33 +0100
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> CC:  lekktu@gmail.com,  emacs-devel@gnu.org
> > 
> > Why do you insist on distributing deviant versions, when the official
> > ones are not broken?
> 
> Because I think the official version is a little bit broken and lack 
> some functionality.

Distributing variants just adds to confusion and wastes precious
resources.  Therefore I think it should be done only if you have a
very good reason, and it certainly shouldn't be a knee-jerk reaction
to any disagreement.

> > Please, let's just drop this issue until after the release.  The right
> > fix is not that simple; I agree with David that emacsclient should be
> > consistent with Emacs, not with notepad.
> 
> 
> I think that both Emacs and Emacsclient should be consistent with the UI 
> on w32 and therefore with Notepad.

Solving this in both Emacs and emacsclient is a non-trivial job that
should not be undertaken now.  I hope you agree that solving it _only_
in emacsclient is a bad idea.

Re: emacsclient: support `/' directory separator on w32

[Eli Zaretskii]

> Date: Wed, 29 Nov 2006 10:17:53 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> On 11/29/06, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > You have buggy ports; mine do work with c:foo.
> 
> MSYS/MinGW. I wouldn't call them buggy.

If those are MSYS ports, it's no surprise they don't support d:foo:
MSYS is a Posix environment, not unlike Cygwin, so it wants Posix file
names.

I use GnuWin32 ports, which are native Windows executables that use
Windows runtime libraries.  They must support d:foo, since the Windows
API does.

Re: emacsclient: support `/' directory separator on w32

[Eli Zaretskii]

> Cc: Eli Zaretskii <eliz@gnu.org>, lekktu@gmail.com, emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Wed, 29 Nov 2006 10:57:05 +0100
> 
> Emacs stores its idea of "relativeness" in `default-directory', a
> buffer-local variable.
> 
> It is not clear how one would attempt to model drive-relativeness on
> different drives than the one the buffer is in.

If the OS maintains the cwd on each drive, I see no problem to do
this.  Do you?

> It is possible to make `default-directory' point to a different
> drive from that of `buffer-file-name'.  Maintaining the old
> drive-relative position at the same time does not seem possible to
> do in a reasonably predictable way.

Sorry, I'm not sure I understand the scenario.  Can you show a
hypothetical series of commands that illustrates the problem(s)?

Re: emacsclient: support `/' directory separator on w32

[Eli Zaretskii]

> Date: Wed, 29 Nov 2006 17:08:34 +0100
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> CC:  lekktu@gmail.com, Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> 
> But is the working directory ever used in emacs?

It is used implicitly each time you invoke a program without leading
directories in the executable name, or give a program arguments that
are relative file names.

> Maybe there is a better API for checking file names?

I suggest GetFullPathName.

Re: emacsclient: support `/' directory separator on w32

[Eli Zaretskii]

> Date: Wed, 29 Nov 2006 17:24:36 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> > Unfortunately GetLongPathName() does not care about these characters.
> 
> GetLongPathName() is unsupported on W95, according to the Platform SDK.

Not according to my records.  However, you need to include the
NewAPIs.h header file (from the platform SDK) to have them available.
That header defines macros that implement GetLongPathName as wrapper
that uses native Windows 9x functions to implement the same
functionality.

Re: emacsclient: support `/' directory separator on w32

[Eli Zaretskii]

> Date: Wed, 29 Nov 2006 17:37:01 +0100
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> Cc: emacs-devel@gnu.org
> 
> >> therefore tried with GetLongPathName(), but I could not link with MingGW:
> >>
> >>    oo-spd/i386/emacsclient.o(.text+0x283b):emacsclient.c:
> >>       undefined reference to `GetLongPathName'

> > Not even with explicit GetLongPathNameA?
> 
> No, I told it on the mingw-user list.

What version of MinGW runtime do you have?

Re: emacsclient: support `/' directory separator on w32

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: Eli Zaretskii <eliz@gnu.org>, lekktu@gmail.com, emacs-devel@gnu.org
>> From: David Kastrup <dak@gnu.org>
>> Date: Wed, 29 Nov 2006 10:57:05 +0100
>> 
>> Emacs stores its idea of "relativeness" in `default-directory', a
>> buffer-local variable.
>> 
>> It is not clear how one would attempt to model drive-relativeness on
>> different drives than the one the buffer is in.
>
> If the OS maintains the cwd on each drive, I see no problem to do
> this.  Do you?

Yes.  Emacs maintains a cwd for each buffer in `default-directory' and
hides the OS' idea of the cwd.  The command `cd' does not affect any
buffer except the current one.

If you let the OS maintain its per-application idea of a
drive-relative cwd, cd _will_ affect more than the current buffer.  If
the current buffer is visiting C:/whatever/file.txt, and I did a cd to
C:/bubbles in a different buffer, should C-x C-f c:junk.txt in the
buffer of file.txt open C:/bubbles/junk.txt, C:/junk.txt or
C:/whatever/junk.txt?

>> It is possible to make `default-directory' point to a different
>> drive from that of `buffer-file-name'.  Maintaining the old
>> drive-relative position at the same time does not seem possible to
>> do in a reasonably predictable way.
>
> Sorry, I'm not sure I understand the scenario.  Can you show a
> hypothetical series of commands that illustrates the problem(s)?

C-x C-f C:/dir/xxx.txt RET
M-x cd RET D:/woozle RET
C-x C-f D:/junk/ddd.txt RET
M-x cd RET D:poz RET      [ D:/poz or D:/woozle/poz? ]
C-x C-b xxx.txt RET
C-x C-f D:pizza RET [ D:/woozle/pizza, D:/poz/pizza,
                      D:/woozle/poz/pizza  or D:/pizza? ]

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: emacsclient: support `/' directory separator on w32

[Lennart Borgman]

Eli Zaretskii wrote:
>> Date: Wed, 29 Nov 2006 17:08:34 +0100
>> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
>> CC:  lekktu@gmail.com, Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
>>
>> But is the working directory ever used in emacs?
> 
> It is used implicitly each time you invoke a program without leading
> directories in the executable name, or give a program arguments that
> are relative file names.

But is not default-directory used then to set the working directory for 
the subprocess? Is that really the working directory from an OS point of 
view?


>> Maybe there is a better API for checking file names?
> 
> I suggest GetFullPathName.

Thanks, but that was what I tried to say did not work.

Re: emacsclient: support `/' directory separator on w32

[Lennart Borgman]

David Kastrup wrote:

> C-x C-f C:/dir/xxx.txt RET
> M-x cd RET D:/woozle RET
> C-x C-f D:/junk/ddd.txt RET
> M-x cd RET D:poz RET      [ D:/poz or D:/woozle/poz? ]
> C-x C-b xxx.txt RET
> C-x C-f D:pizza RET [ D:/woozle/pizza, D:/poz/pizza,
>                       D:/woozle/poz/pizza  or D:/pizza? ]

Did not my message get through? My suggestion was when setting 
default-directory also set the working directory for the OS. Then 
GetFullPathName will do the name resolving without any problem using the 
last value for the working directory on the drive specified to 
GetFullPathName.

In this case

C-x C-f C:/dir/xxx.txt RET
M-x cd RET D:/woozle RET (Sets default-directory to D:/woozle/)
C-x C-f D:/junk/ddd.txt RET (Sets default-directory to D:/junk/)
M-x cd RET D:poz RET   => D:/junk/poz
C-x C-b xxx.txt RET (Sets default-directory to C:/dir/)
C-x C-f D:pizza RET => D:/junk/pizza

Re: emacsclient: support `/' directory separator on w32

[Eli Zaretskii]

> Cc: lennart.borgman.073@student.lu.se, lekktu@gmail.com, emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Wed, 29 Nov 2006 20:01:42 +0100
> 
> If you let the OS maintain its per-application idea of a
> drive-relative cwd, cd _will_ affect more than the current buffer.  If
> the current buffer is visiting C:/whatever/file.txt, and I did a cd to
> C:/bubbles in a different buffer, should C-x C-f c:junk.txt in the
> buffer of file.txt open C:/bubbles/junk.txt, C:/junk.txt or
> C:/whatever/junk.txt?

It should probably visit the file C:/whatever/junk.txt, since Emacs
behaves as if the cwd changes whenever you switch buffers.

Re: emacsclient: support `/' directory separator on w32

[Eli Zaretskii]

> Date: Wed, 29 Nov 2006 20:14:37 +0100
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> CC: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org,  lekktu@gmail.com
> 
> Did not my message get through? My suggestion was when setting 
> default-directory also set the working directory for the OS.

That's a scary suggestion.  For starters, it will have different
effects on Windows 9x and the newer versions (since cwd is a global OS
variable on Windows 9x).  It might also affect subprocesses and other
related aspects.  I don't think we should even think about going that
way.

Like I said: let's postpone this for after the release.

Re: emacsclient: support `/' directory separator on w32

[David Kastrup]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> David Kastrup wrote:
>
>> C-x C-f C:/dir/xxx.txt RET
>> M-x cd RET D:/woozle RET
>> C-x C-f D:/junk/ddd.txt RET
>> M-x cd RET D:poz RET      [ D:/poz or D:/woozle/poz? ]
>> C-x C-b xxx.txt RET
>> C-x C-f D:pizza RET [ D:/woozle/pizza, D:/poz/pizza,
>>                       D:/woozle/poz/pizza  or D:/pizza? ]
>
> Did not my message get through? My suggestion was when setting
> default-directory also set the working directory for the OS.

default-directory is a buffer-local variable.  I might be repeating
myself.  Changing it in one buffer does not affect other buffers.  I
have seen no argument that it would be a good idea to change this.

You are basically proposing that a (setq default-directory ... in one
buffer can affect the operation of stuff in other buffers.

If you take a look at the code for `cd', you'll see that its only
side-effect is setting the buffer-local `default-directory'.  There
are no system calls involved.

> Then GetFullPathName will do the name resolving without any problem
> using the last value for the working directory on the drive
> specified to GetFullPathName.
>
> In this case
>
> C-x C-f C:/dir/xxx.txt RET
> M-x cd RET D:/woozle RET (Sets default-directory to D:/woozle/)
> C-x C-f D:/junk/ddd.txt RET (Sets default-directory to D:/junk/)
> M-x cd RET D:poz RET   => D:/junk/poz
> C-x C-b xxx.txt RET (Sets default-directory to C:/dir/)
> C-x C-f D:pizza RET => D:/junk/pizza

I don't see how and when you are planning to call the operating
system.  `default-directory' changes in every visited buffer.  That
means that a (with-current-buffer "ddd.txt" nil) can change the
meaning of "D:xxx" in the current buffer when `default-directory' in
"ddd.txt" is "D:/plopp", and `default-directory' in the current buffer
is "C:/blubb".

The mere act of switching to a different buffer is supposed to have
such effects?

This is not sane.  We should certainly not do anything like that now,
and I severely doubt we should ever do that.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: emacsclient: support `/' directory separator on w32

[David Kastrup]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> Eli Zaretskii wrote:
>>> Date: Wed, 29 Nov 2006 17:08:34 +0100
>>> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
>>> CC:  lekktu@gmail.com, Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
>>>
>>> But is the working directory ever used in emacs?
>>
>> It is used implicitly each time you invoke a program without leading
>> directories in the executable name, or give a program arguments that
>> are relative file names.
>
> But is not default-directory used then to set the working directory
> for the subprocess?

No.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: emacsclient: support `/' directory separator on w32

[Lennart Borgman]

Eli Zaretskii wrote:
>> Date: Wed, 29 Nov 2006 20:14:37 +0100
>> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
>> CC: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org,  lekktu@gmail.com
>>
>> Did not my message get through? My suggestion was when setting 
>> default-directory also set the working directory for the OS.
> 
> That's a scary suggestion.  For starters, it will have different
> effects on Windows 9x and the newer versions (since cwd is a global OS
> variable on Windows 9x).  It might also affect subprocesses and other
> related aspects.  I don't think we should even think about going that
> way.


Do you mean that each process has the same working directory on Win 9x?

Does not each inferior process in Emacs has its own working directory? 
Is not this set from the value of default-directory when starting the 
process?


> Like I said: let's postpone this for after the release.


Yes, this is a bit scary. I will do some tests on my own and tell the 
results, but that is all.

Re: emacsclient: support `/' directory separator on w32

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: lennart.borgman.073@student.lu.se, lekktu@gmail.com, emacs-devel@gnu.org
>> From: David Kastrup <dak@gnu.org>
>> Date: Wed, 29 Nov 2006 20:01:42 +0100
>> 
>> If you let the OS maintain its per-application idea of a
>> drive-relative cwd, cd _will_ affect more than the current buffer.  If
>> the current buffer is visiting C:/whatever/file.txt, and I did a cd to
>> C:/bubbles in a different buffer, should C-x C-f c:junk.txt in the
>> buffer of file.txt open C:/bubbles/junk.txt, C:/junk.txt or
>> C:/whatever/junk.txt?
>
> It should probably visit the file C:/whatever/junk.txt, since Emacs
> behaves as if the cwd changes whenever you switch buffers.

But if the buffer in question has its cwd on a different drive, it is
not possible in the buffer to assign meaning to a directory relative
to a different drive.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: emacsclient: support `/' directory separator on w32

[Juanma Barranquero]

On 11/29/06, Eli Zaretskii <eliz@gnu.org> wrote:

> If those are MSYS ports, it's no surprise they don't support d:foo:
> MSYS is a Posix environment, not unlike Cygwin, so it wants Posix file
> names.

Hmm. Is c:\my\foo.bar a Posix file name?

> I use GnuWin32 ports, which are native Windows executables that use
> Windows runtime libraries.

I use some GnuWin32 tools. They give me more trouble that the
MSYS/MinGW tools (make conflicts with the shell, patch crashing on
not-well-formed patches, etc.).

                    /L/e/k/t/u

Re: emacsclient: support `/' directory separator on w32

[Lennart Borgman]

David Kastrup wrote:

>> In this case
>>
>> C-x C-f C:/dir/xxx.txt RET
>> M-x cd RET D:/woozle RET (Sets default-directory to D:/woozle/)
>> C-x C-f D:/junk/ddd.txt RET (Sets default-directory to D:/junk/)
>> M-x cd RET D:poz RET   => D:/junk/poz
>> C-x C-b xxx.txt RET (Sets default-directory to C:/dir/)
>> C-x C-f D:pizza RET => D:/junk/pizza
> 
> I don't see how and when you are planning to call the operating
> system.  `default-directory' changes in every visited buffer.  That
> means that a (with-current-buffer "ddd.txt" nil) can change the
> meaning of "D:xxx" in the current buffer when `default-directory' in
> "ddd.txt" is "D:/plopp", and `default-directory' in the current buffer
> is "C:/blubb".


Well, I thought on changing it at every buffer visit. But then I was 
thinking of user actions of course.


> The mere act of switching to a different buffer is supposed to have
> such effects?


If the user visit a new buffer in a window, yes. My thoughts are not 
very clear, but seems like this could be done after each user command. 
Set the current directory to default-directory then. Would that not be 
clear enough?


> This is not sane.  We should certainly not do anything like that now,
> and I severely doubt we should ever do that.


Maybe it is not sane, but I think it is close to the logic used in 
cmd.exe on w32 so it will be no surprise to the user IMHO.

Re: emacsclient: support `/' directory separator on w32

[Lennart Borgman]

David Kastrup wrote:
> Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
> 
>> Eli Zaretskii wrote:
>>>> Date: Wed, 29 Nov 2006 17:08:34 +0100
>>>> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
>>>> CC:  lekktu@gmail.com, Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
>>>>
>>>> But is the working directory ever used in emacs?
>>> It is used implicitly each time you invoke a program without leading
>>> directories in the executable name, or give a program arguments that
>>> are relative file names.
>> But is not default-directory used then to set the working directory
>> for the subprocess?
> 
> No.

But if I try

   M-x shell

or if I use something like

    (setq default-directory "c:/")
    (start-process "TEST" "TEST buffer" "cmd.exe")

it looks to me like default-directory was used. But maybe you mean other 
cases?

Re: emacsclient: support `/' directory separator on w32

[Juanma Barranquero]

On 11/29/06, Eli Zaretskii <eliz@gnu.org> wrote:

> However, you need to include the
> NewAPIs.h header file (from the platform SDK) to have them available.
> That header defines macros that implement GetLongPathName as wrapper
> that uses native Windows 9x functions to implement the same
> functionality.

Oh. My. God.

                    /L/e/k/t/u

Re: emacsclient: support `/' directory separator on w32

[Lennart Borgman]

Eli Zaretskii wrote:

> Distributing variants just adds to confusion and wastes precious
> resources.  Therefore I think it should be done only if you have a
> very good reason, and it certainly shouldn't be a knee-jerk reaction
> to any disagreement.


Yes, it adds to the confusion. I am aware of that and tries to tell that 
as clearly as possible on my web pages. If you have time and interest 
you can suggest improvements to this.

The things I have added in my patches are things that I think should go 
into emacs later. We might prefer slightly different coding but that is 
of very minor importance to many. I code for the functionality and try 
to make the code clear and structured.

I use this patches myself and I even doubt I would be using Emacs 
without some of them.

Of course we have different views of things sometimes, but that does not 
change my mind unless you can convince me. It is not a big problem for 
me if we disagree and I try not to act because of that. However I try to 
make my view clear and offer alternatives based on my view - with all 
efforts I think are reasonable to minimize the patches.


> Solving this in both Emacs and emacsclient is a non-trivial job that
> should not be undertaken now.  I hope you agree that solving it _only_
> in emacsclient is a bad idea.


I think we should solve it for emacsclient now because it is more 
integrated with the w32 UI, but let it be for Emacs until after the 
release. I see no problems with that.

However I believe also that we should try to solve the problems with bad 
filenames in both Emacs and Emacsclient now. This should not be to 
problematic I guess. It is only about testing for certain characters in 
the names. The main difficulty is perhaps what to do when a file name 
contains bad characters.

Re: emacsclient: support `/' directory separator on w32

[Lennart Borgman]

> However I believe also that we should try to solve the problems with bad 
> filenames in both Emacs and Emacsclient now. This should not be to 
> problematic I guess. It is only about testing for certain characters in 
> the names. The main difficulty is perhaps what to do when a file name 
> contains bad characters.


I tried to test for bad characters in emacsclient on w32. However it 
might be the wrong place since emacsclient does not have full knowledge 
of useful filenames  (tramp etc).

I have no really good suggestion for what to do with this. Maybe should 
the file names given to emacsclient be local to the OS? It seems like 
the actual interpretation today, but is it somewhere actually documented?

Re: emacsclient: support `/' directory separator on w32

[Eli Zaretskii]

> Date: Wed, 29 Nov 2006 20:33:59 +0100
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> CC:  dak@gnu.org,  emacs-devel@gnu.org,  lekktu@gmail.com
> 
> Do you mean that each process has the same working directory on Win 9x?

Yes, IIRC.

> Does not each inferior process in Emacs has its own working directory? 

On newer versions of Windows, yes.  On older, I don't think so.

> Is not this set from the value of default-directory when starting the 
> process?

I don't remember; look at the code.  (David said no.)

Re: emacsclient: support `/' directory separator on w32

[Eli Zaretskii]

> Cc: lennart.borgman.073@student.lu.se, lekktu@gmail.com, emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Wed, 29 Nov 2006 20:39:31 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Cc: lennart.borgman.073@student.lu.se, lekktu@gmail.com, emacs-devel@gnu.org
> >> From: David Kastrup <dak@gnu.org>
> >> Date: Wed, 29 Nov 2006 20:01:42 +0100
> >> 
> >> If you let the OS maintain its per-application idea of a
> >> drive-relative cwd, cd _will_ affect more than the current buffer.  If
> >> the current buffer is visiting C:/whatever/file.txt, and I did a cd to
> >> C:/bubbles in a different buffer, should C-x C-f c:junk.txt in the
> >> buffer of file.txt open C:/bubbles/junk.txt, C:/junk.txt or
> >> C:/whatever/junk.txt?
> >
> > It should probably visit the file C:/whatever/junk.txt, since Emacs
> > behaves as if the cwd changes whenever you switch buffers.
> 
> But if the buffer in question has its cwd on a different drive, it is
> not possible in the buffer to assign meaning to a directory relative
> to a different drive.

Unless we store the cwd on each drive in a buffer-local variable, like
we do with default-directory.

Re: emacsclient: support `/' directory separator on w32

[Eli Zaretskii]

> Date: Wed, 29 Nov 2006 20:41:09 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> Hmm. Is c:\my\foo.bar a Posix file name?

No.  But MSYS does some magic to convert it internally, and evidently
that magic does not support the d:foo form.

> > I use GnuWin32 ports, which are native Windows executables that use
> > Windows runtime libraries.
> 
> I use some GnuWin32 tools. They give me more trouble that the
> MSYS/MinGW tools (make conflicts with the shell, patch crashing on
> not-well-formed patches, etc.).

I didn't say GnuWin32 ports are perfect; they aren't.  We were talking
about support for d:foo in native Windows programs.  I think the
conclusion is that it _is_ supported, do you agree?

Re: emacsclient: support `/' directory separator on w32

[Eli Zaretskii]

> Date: Wed, 29 Nov 2006 23:30:52 +0100
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> CC:  lekktu@gmail.com,  emacs-devel@gnu.org
> 
> > Solving this in both Emacs and emacsclient is a non-trivial job that
> > should not be undertaken now.  I hope you agree that solving it _only_
> > in emacsclient is a bad idea.
> 
> I think we should solve it for emacsclient now because it is more 
> integrated with the w32 UI, but let it be for Emacs until after the 
> release. I see no problems with that.

You are in clear disagreement here with several other developers,
including myself.

> However I believe also that we should try to solve the problems with bad 
> filenames in both Emacs and Emacsclient now.

What problems are those?  Please show a recipe to reproduce them.  (I
suggest a new thread with a new Subject.)

Re: emacsclient: support `/' directory separator on w32

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Wed, 29 Nov 2006 20:33:59 +0100
>> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
>> CC:  dak@gnu.org,  emacs-devel@gnu.org,  lekktu@gmail.com
>> 
>> Do you mean that each process has the same working directory on Win 9x?
>
> Yes, IIRC.
>
>> Does not each inferior process in Emacs has its own working directory? 
>
> On newer versions of Windows, yes.  On older, I don't think so.
>
>> Is not this set from the value of default-directory when starting the 
>> process?
>
> I don't remember; look at the code.  (David said no.)

I said "no" to whether setting default-directory changes the working
directory of Emacs.  Whether starting a process does so, I did not
check.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: emacsclient: support `/' directory separator on w32

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>
>> But if the buffer in question has its cwd on a different drive, it
>> is not possible in the buffer to assign meaning to a directory
>> relative to a different drive.
>
> Unless we store the cwd on each drive in a buffer-local variable,
> like we do with default-directory.

Certainly, that would be a manner of implementing this state.  Then
`expand-file-name' would likely have to be able to accept the data
structure used for that, too.

In short: there be dragons.  We certainly don't want to mess with this
idea now, and I have my doubts that we want to, ever.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: emacsclient: support `/' directory separator on w32

[Lennart Borgman]

Eli Zaretskii wrote:
>> Cc: lennart.borgman.073@student.lu.se, lekktu@gmail.com, emacs-devel@gnu.org
>> From: David Kastrup <dak@gnu.org>
>> Date: Wed, 29 Nov 2006 20:39:31 +0100
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> Cc: lennart.borgman.073@student.lu.se, lekktu@gmail.com, emacs-devel@gnu.org
>>>> From: David Kastrup <dak@gnu.org>
>>>> Date: Wed, 29 Nov 2006 20:01:42 +0100
>>>>
>>>> If you let the OS maintain its per-application idea of a
>>>> drive-relative cwd, cd _will_ affect more than the current buffer.  If
>>>> the current buffer is visiting C:/whatever/file.txt, and I did a cd to
>>>> C:/bubbles in a different buffer, should C-x C-f c:junk.txt in the
>>>> buffer of file.txt open C:/bubbles/junk.txt, C:/junk.txt or
>>>> C:/whatever/junk.txt?
>>> It should probably visit the file C:/whatever/junk.txt, since Emacs
>>> behaves as if the cwd changes whenever you switch buffers.
>> But if the buffer in question has its cwd on a different drive, it is
>> not possible in the buffer to assign meaning to a directory relative
>> to a different drive.
> 
> Unless we store the cwd on each drive in a buffer-local variable, like
> we do with default-directory.


Or if we let MS Windows take care of this by setting the working 
directory for Emacs as I suggested. (However I am not suggesting to do 
that now.)

Re: emacsclient: support `/' directory separator on w32

[Lennart Borgman]

Eli Zaretskii wrote:
>> Date: Wed, 29 Nov 2006 20:33:59 +0100
>> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
>> CC:  dak@gnu.org,  emacs-devel@gnu.org,  lekktu@gmail.com
>>
>> Do you mean that each process has the same working directory on Win 9x?
> 
> Yes, IIRC.
> 
>> Does not each inferior process in Emacs has its own working directory? 
> 
> On newer versions of Windows, yes.  On older, I don't think so.
> 
>> Is not this set from the value of default-directory when starting the 
>> process?
> 
> I don't remember; look at the code.  (David said no.)


 From my earlier tests it looks to me like it does that.

Re: emacsclient: support `/' directory separator on w32

[David Kastrup]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> Eli Zaretskii wrote:
>>>
>>> From: David Kastrup <dak@gnu.org>
>
>>> But if the buffer in question has its cwd on a different drive, it is
>>> not possible in the buffer to assign meaning to a directory relative
>>> to a different drive.
>>
>> Unless we store the cwd on each drive in a buffer-local variable, like
>> we do with default-directory.
>
> Or if we let MS Windows take care of this by setting the working
> directory for Emacs as I suggested. (However I am not suggesting to
> do that now.)

I suggest we drop the topic.  It does not appear like I am able to
explain the problems with your approach in a manner you'd understand.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: emacsclient: support `/' directory separator on w32

[Juanma Barranquero]

On 11/30/06, Eli Zaretskii <eliz@gnu.org> wrote:

> No.  But MSYS does some magic to convert it internally, and evidently
> that magic does not support the d:foo form.

OK, so MSYS tools support non-Posix file names but they don't support
C:foo. I suppose the porters didn't care, or didn't consider it
important enough. I tend to agree with them ;)

> I didn't say GnuWin32 ports are perfect; they aren't.

No, of course. I was only explaining why do I choose to use MSYS/MinGW
tools even if they would seem "broken" for some people.

> We were talking
> about support for d:foo in native Windows programs.  I think the
> conclusion is that it _is_ supported, do you agree?

It would be foolish not to agree that most programs, and certainly all
Microsoft-supplied ones, do support it. (Hmm, that's a "yes", of
course.)

                    /L/e/k/t/u

Re: emacsclient: support `/' directory separator on w32

[Lennart Borgman]

David Kastrup wrote:
> Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
> 
>> Eli Zaretskii wrote:
>>>> From: David Kastrup <dak@gnu.org>
>>>> But if the buffer in question has its cwd on a different drive, it is
>>>> not possible in the buffer to assign meaning to a directory relative
>>>> to a different drive.
>>> Unless we store the cwd on each drive in a buffer-local variable, like
>>> we do with default-directory.
>> Or if we let MS Windows take care of this by setting the working
>> directory for Emacs as I suggested. (However I am not suggesting to
>> do that now.)
> 
> I suggest we drop the topic.  It does not appear like I am able to
> explain the problems with your approach in a manner you'd understand.


I am sorry, David. I realize I have been a bit lacking in clear 
feedback. Yes, I believe I got your message and that it helped me get a 
clear picture of how to solve the problem without having to worry about 
disturbing other parts of Emacs. However I would also be glad to leave 
the subject to now.

Re: emacsclient: support `/' directory separator on w32

[Richard Stallman]

    > But is not default-directory used then to set the working directory
    > for the subprocess?

    No.

Yes, I think.  child_setup in callproc.c has code to do that.

Emacs's own current directory (at the system level) doesn't normally
matter, because Emacs does its own computations to produce absolute
file names.  The only time it would matter is when another process
is supposed to inherit it; and that, Emacs does manually (in child_setup,
for instance).

Re: emacsclient: support `/' directory separator on w32

[Eli Zaretskii]

> Cc: lennart.borgman.073@student.lu.se, lekktu@gmail.com, emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Thu, 30 Nov 2006 08:18:42 +0100
> 
> In short: there be dragons.  We certainly don't want to mess with this
> idea now, and I have my doubts that we want to, ever.

110% agreement.