Interest in Emacs patched to handle Windows paths?

Interest in Emacs patched to handle Windows paths?

[Soegtrop, Michael]

Dear Cygwin Team and Users,

In May I modified Emacs for Cygwin so that it can truly handle Windows paths. I do a lot of MinGW cross compilation on Windows and want to seamlessly use tools like debuggers compiled for MinGW in Cygwin Emacs, so I need this. I also tried the Windows Emacs distrubution, but it didn't find it very convincing, because it comes with yet another Posix layer for Windows, and a rather heavy one. Cygwin Emacs is a substantially more elegant solution. One can find some emacs lisp packages to help with this, but they all rely on path translation, so an open works but the path Emacs uses internally is the Cygwin path then. This is in many cases not good enough. I found that I have to modify the core C file handling file (src/fileio.c) to make it really work.

I wanted to ask if there is general interest in this. If so I would like to publish this work. But to do so I would need some advice on how to do this. The path handling code of Emacs is localized (src/fileio.c) but quite obscure and I would even call it messy so it requires quite a few changes and it is hard to tell if my changes to support Posix and Windows paths in one build don't break compatibility with some ancient operating systems. For this reason it might be hard to get these changes into Emacs upstream, so that this would just be a compile time option.

The alternatives would be to have a separate package in Cygwin which applies a patch to emacs, say an emacs-winpath package I could maintain. Of cause I would try to get it upstream to reduce maintenance effort, but as I said, it might get tricky because I don't have access to a computer museum to test Emacs on all platforms it supports.

Please let me know your thoughts on this.

Best regards,

Michael
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Gary Kershaw
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Interest in Emacs patched to handle Windows paths?

[Ken Brown]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2528 bytes --]

On 7/26/2019 1:11 PM, Soegtrop, Michael wrote:
> Dear Cygwin Team and Users,
> 
> In May I modified Emacs for Cygwin so that it can truly handle Windows paths. I do a lot of MinGW cross compilation on Windows and want to seamlessly use tools like debuggers compiled for MinGW in Cygwin Emacs, so I need this. I also tried the Windows Emacs distrubution, but it didn't find it very convincing, because it comes with yet another Posix layer for Windows, and a rather heavy one. Cygwin Emacs is a substantially more elegant solution. One can find some emacs lisp packages to help with this, but they all rely on path translation, so an open works but the path Emacs uses internally is the Cygwin path then. This is in many cases not good enough. I found that I have to modify the core C file handling file (src/fileio.c) to make it really work.
> 
> I wanted to ask if there is general interest in this. If so I would like to publish this work. But to do so I would need some advice on how to do this. The path handling code of Emacs is localized (src/fileio.c) but quite obscure and I would even call it messy so it requires quite a few changes and it is hard to tell if my changes to support Posix and Windows paths in one build don't break compatibility with some ancient operating systems. For this reason it might be hard to get these changes into Emacs upstream, so that this would just be a compile time option.
> 
> The alternatives would be to have a separate package in Cygwin which applies a patch to emacs, say an emacs-winpath package I could maintain. Of cause I would try to get it upstream to reduce maintenance effort, but as I said, it might get tricky because I don't have access to a computer museum to test Emacs on all platforms it supports.

I made a brief attempt to do something like this a few years ago in response to 
a user request, and I found that every time I touched one part of the code, it 
broke another part of the code.  [My vague recollection is that I lost interest 
when completion stopped working.]

If you think you have something that works, I'd be interested in seeing it and 
testing it.

The discussion should probably continue on the cygwin-apps list, which is the 
place to discuss Cygwin packaging.

Ken (Cygwin's Emacs maintainer)
\x03B‹KCB”\x1c›Ø›\x19[H\x1c™\^[ܝ\x1cΈ\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÜ\x1c›Ø›\x19[\Ëš\x1d^[[\x03B‘TNˆ\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÙ˜\KÃB‘^[ØÝ[Y[\x18]\x1a[ÛŽˆ\b\b\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÙ^[ØÜËš\x1d^[[\x03B•[œÝXœØÜšX™H\x1a[™›Îˆ\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÛ[\vÈÝ[œÝXœØÜšX™K\Ú[\^[\x19CBƒB

Re: Interest in Emacs patched to handle Windows paths?

[Kaz Kylheku]

On 2019-07-26 10:11, Soegtrop, Michael wrote:
> Dear Cygwin Team and Users,
> 
> In May I modified Emacs for Cygwin so that it can truly handle Windows
> paths.

You might be interested in the Cygnal project: 
http://www.kylheku.com/cygnal/

In this project, I modified Cygwin itself to use Windows paths.
There are some other changes, of course, all documented in detail.

I use Cygnal for a native Windows port of the TXR language. This is just 
the
Cygwin version of txr.exe bundled with the patched cygwin.dll (plus some
additional needed libs), wrapped up in an installer.

There is no separate build; just packaging.

Cygnal isn't an environment; it doesn't replace Cygwin. It's a way of
deploying Cygwin programs stand-alone to Windows users who expect 
certain
Windows conventions, while retaining the advantages of Cygwin's large
and detailed POSIX API footprint.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

RE: Interest in Emacs patched to handle Windows paths?

[Soegtrop, Michael]

Dear Kaz,

> You might be interested in the Cygnal project:
> http://www.kylheku.com/cygnal/

from your description I would think this doesn't work for Emacs. Emacs has its own functions for path management, e.g. to decide what an absolute path is. These need to be adjusted inside of Emacs. OS support for the paths is not sufficient.

Best regards,

Michael
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Gary Kershaw
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

RE: Interest in Emacs patched to handle Windows paths?

[Kaz Kylheku]

On 2019-07-26 13:08, Soegtrop, Michael wrote:
> Dear Kaz,
> 
>> You might be interested in the Cygnal project:
>> http://www.kylheku.com/cygnal/
> 
> from your description I would think this doesn't work for Emacs. Emacs
> has its own functions for path management, e.g. to decide what an
> absolute path is.

Yes, like this:   :)

   C:\Users\kaz>txr
   This is the TXR Lisp interactive listener of TXR 221.
   Quit with :quit or Ctrl-D on empty line. Ctrl-X ? for cheatsheet.
   1> (abs-path-p "C:\\foo")
   t
   2> (abs-path-p "C:foo")
   nil
   3> (abs-path-p "/foo")
   t

Cygnal is not a magic fix for programs that manipulate path; it provides 
a POSIX-like system interface, but which takes Windows paths. If the 
program manipulates paths, that has to be ported/extended to support 
Windows paths.

What it provides is that the open() system call and others understand 
drive letter names and such.

chdir() understands the concept of a per-drive current working 
directory, and the "currently logged drive". Check this out:

   4> (chdir "f:") ;; basically a bare interface to the chdir syscall
   t
   5> (pwd) ;; wrapper for getcwd
   "F:/"
   6> (chdir "c:")
   t
   7> (pwd)
   "C:/Users/kaz"
   8>

If you want a program ported to Windows via Cygwin to understand native 
conventions, Cygnal goes a long way.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple