bug#58835: 28.1; try-complete-file-name-partially modifies text before point

bug#58835: 28.1; try-complete-file-name-partially modifies text before point

[Anders Munch]

When hippie-expand uses try-complete-file-name-partially on a partial
path which uses platform standard directory separators, then directory
separators are replaced with posix directory separators throughout the
entire path.

Functions that "expand" or "complete" should not change text before
point.

For example, when expanding
    c:\Documents
it becomes
    c:/Documents and settings/

Expected behaviour: Nothing changed before point, expand to:
    c:\Documents and settings/

Desired behaviour is to respect platform conventions and produce
    c:\Documents and settings\
but I realise that would be too much to ask.


In GNU Emacs 28.1 (build 2, x86_64-w64-mingw32)
 of 2022-04-20 built on AVALON
Windowing system distributor 'Microsoft Corp.', version 10.0.19044
System Description: Microsoft Windows 10 Pro (v10.0.2009.19044.2130)

Configured using:
 'configure --with-modules --without-dbus --with-native-compilation
 --without-compress-install CFLAGS=-O2'

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
XPM ZLIB

(NATIVE_COMP present but libgccjit not available)

Important settings:
  value of $LANG: DAN
  locale-coding-system: cp1252

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search seq byte-opt
gv bytecomp byte-compile cconv mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils time-date subr-x cl-loaddefs
cl-lib hippie-exp comint ansi-color ring iso-transl tooltip eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads w32notify
w32 lcms2 multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 62376 8924)
 (symbols 48 7619 1)
 (strings 32 22822 1513)
 (string-bytes 1 722817)
 (vectors 16 14919)
 (vector-slots 8 262293 11500)
 (floats 8 24 322)
 (intervals 56 219 0)
 (buffers 992 11))

bug#58835: 28.1; try-complete-file-name-partially modifies text before point

[Eli Zaretskii]

tags 58835 notabug wontfix
thanks

> From: Anders Munch <ajm@flonidan.dk>
> Date: Thu, 27 Oct 2022 08:35:51 +0000
> 
> When hippie-expand uses try-complete-file-name-partially on a partial
> path which uses platform standard directory separators, then directory
> separators are replaced with posix directory separators throughout the
> entire path.
> 
> Functions that "expand" or "complete" should not change text before
> point.

In general, yes.  But I see no reason to expect that with 110%
certainty in all cases, especially on MS-Windows.

> For example, when expanding
>     c:\Documents
> it becomes
>     c:/Documents and settings/
> 
> Expected behaviour: Nothing changed before point, expand to:
>     c:\Documents and settings/

This is a non-starter, sorry.  Emacs converts backslashes in Windows
file names to forward slashes at the first opportunity, and it does
that for very good reasons: to allow comparison of file names as
(almost) simple strings, and to avoid causing problems in code that
may not expect backslashes in file names.  This is why Emacs does this
conversion in expand-file-name, which is generally called before a
file name is passed to some C library function.  It does that also
when you call the completion commands -- again, to simplify textual
comparison of completion candidates.

> Desired behaviour is to respect platform conventions and produce
>     c:\Documents and settings\
> but I realise that would be too much to ask.

Indeed.

May I ask what is the real-life situation where this slash conversion
caused you trouble?

bug#58835: 28.1; try-complete-file-name-partially modifies text before point

[Anders Munch]

> May I ask what is the real-life situation where this slash conversion caused you trouble?

Any filename occurring in a text document may potentially be copy-pasted into
some other program.  In most other software that I use, filenames abide by the
platform convention, and a filename occurring in a text document may potentially
be copy-pasted into one of these other programs.  For example, into the address
bar of Windows Explorer, or into a file selection dialog.  For those purposes,
backslashes are the platform standard and frontslashes are not accepted.

For that reason, MS Windows filenames that I keep in text files are written
using backslashes.  When I write part of a file/directory name and use
hippie-expand to help write the rest, then the data that I have already entered
manually is changed, and must be hand-edited back.  Which is frustrating and
time-consuming, and has driven me to no longer use hippie-expand for this.

I'm well aware that GNU Emacs's approach to portability is to make all platforms
pretend they're POSIX, so I wasn't expecting much.  I didn't expect the
expansion to be corrected.  I was just hoping the manually entered text to the
left of point could be left unmangled.

regards, Anders

bug#58835: 28.1; try-complete-file-name-partially modifies text before point

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> tags 58835 notabug wontfix
> thanks
>
>> When hippie-expand uses try-complete-file-name-partially on a partial
>> path which uses platform standard directory separators, then directory
>> separators are replaced with posix directory separators throughout the
>> entire path.
>>
>> Functions that "expand" or "complete" should not change text before
>> point.
>
> In general, yes.  But I see no reason to expect that with 110%
> certainty in all cases, especially on MS-Windows.
>
>> For example, when expanding
>>     c:\Documents
>> it becomes
>>     c:/Documents and settings/
>>
>> Expected behaviour: Nothing changed before point, expand to:
>>     c:\Documents and settings/
>
> This is a non-starter, sorry.  Emacs converts backslashes in Windows
> file names to forward slashes at the first opportunity, and it does
> that for very good reasons: to allow comparison of file names as
> (almost) simple strings, and to avoid causing problems in code that
> may not expect backslashes in file names.  This is why Emacs does this
> conversion in expand-file-name, which is generally called before a
> file name is passed to some C library function.  It does that also
> when you call the completion commands -- again, to simplify textual
> comparison of completion candidates.

I'm therefore closing this bug report.