unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Anders Munch <ajm@flonidan.dk>
Cc: 58835@debbugs.gnu.org
Subject: bug#58835: 28.1; try-complete-file-name-partially modifies text before point
Date: Fri, 28 Oct 2022 16:18:31 +0300	[thread overview]
Message-ID: <83czacjdco.fsf@gnu.org> (raw)
In-Reply-To: <HE1PR0502MB3004993E1599B6CC6DE81EBBB4339@HE1PR0502MB3004.eurprd05.prod.outlook.com> (message from Anders Munch on Thu, 27 Oct 2022 08:35:51 +0000)

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?





  reply	other threads:[~2022-10-28 13:18 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-27  8:35 bug#58835: 28.1; try-complete-file-name-partially modifies text before point Anders Munch
2022-10-28 13:18 ` Eli Zaretskii [this message]
2022-10-28 14:32   ` Anders Munch
2023-09-02 16:43   ` Stefan Kangas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83czacjdco.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=58835@debbugs.gnu.org \
    --cc=ajm@flonidan.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).