GNU bug report logs - #58835
28.1; try-complete-file-name-partially modifies text before point

Previous Next

Package: emacs;

Reported by: Anders Munch <ajm <at> flonidan.dk>

Date: Fri, 28 Oct 2022 12:32:02 UTC

Severity: normal

Tags: notabug, wontfix

Found in version 28.1

Done: Stefan Kangas <stefankangas <at> gmail.com>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 58835 in the body.
You can then email your comments to 58835 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#58835; Package emacs. (Fri, 28 Oct 2022 12:32:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Anders Munch <ajm <at> flonidan.dk>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Fri, 28 Oct 2022 12:32:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Anders Munch <ajm <at> flonidan.dk>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: 28.1; try-complete-file-name-partially modifies text before point
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.

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))




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58835; Package emacs. (Fri, 28 Oct 2022 13:19:02 GMT) Full text and rfc822 format available.

Message #8 received at 58835 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Anders Munch <ajm <at> flonidan.dk>
Cc: 58835 <at> debbugs.gnu.org
Subject: Re: bug#58835: 28.1;
 try-complete-file-name-partially modifies text before point
Date: Fri, 28 Oct 2022 16:18:31 +0300
tags 58835 notabug wontfix
thanks

> From: Anders Munch <ajm <at> 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?




Added tag(s) wontfix and notabug. Request was from Eli Zaretskii <eliz <at> gnu.org> to control <at> debbugs.gnu.org. (Fri, 28 Oct 2022 13:19:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58835; Package emacs. (Sat, 29 Oct 2022 04:13:04 GMT) Full text and rfc822 format available.

Message #13 received at 58835 <at> debbugs.gnu.org (full text, mbox):

From: Anders Munch <ajm <at> flonidan.dk>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "58835 <at> debbugs.gnu.org" <58835 <at> debbugs.gnu.org>
Subject: Re: bug#58835: 28.1; try-complete-file-name-partially modifies text
 before point
Date: Fri, 28 Oct 2022 14:32:47 +0000
> 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





Reply sent to Stefan Kangas <stefankangas <at> gmail.com>:
You have taken responsibility. (Sat, 02 Sep 2023 16:44:02 GMT) Full text and rfc822 format available.

Notification sent to Anders Munch <ajm <at> flonidan.dk>:
bug acknowledged by developer. (Sat, 02 Sep 2023 16:44:02 GMT) Full text and rfc822 format available.

Message #18 received at 58835-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Anders Munch <ajm <at> flonidan.dk>, 58835-done <at> debbugs.gnu.org
Subject: Re: bug#58835: 28.1; try-complete-file-name-partially modifies text
 before point
Date: Sat, 2 Sep 2023 09:43:09 -0700
Eli Zaretskii <eliz <at> 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.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sun, 01 Oct 2023 11:24:13 GMT) Full text and rfc822 format available.

This bug report was last modified 180 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.