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.

Full log


Message #10 received at control <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?




This bug report was last modified 1 year and 261 days ago.

Previous Next


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