GNU bug report logs - #43961
read carefully: dired-file-name-at-point vs dired-filename-at-point

Previous Next

Full log

View this message in rfc822 format

From: Boruch Baum <boruch_baum <at> gmx.com>
To: Richard Stallman <rms <at> gnu.org>
Cc: 43961 <at> debbugs.gnu.org
Subject: bug#43961: read carefully: dired-file-name-at-point vs dired-filename-at-point
Date: Tue, 13 Oct 2020 00:08:07 -0400

On 2020-10-12 23:49, Richard Stallman wrote:
>   > + dired-filename-at-point is moved from dired-x.el to a position
>   >   alongside its sister function
>
> What is the reason for keeping that function at all?

I couldn't possibly account for all the possible emacs users who may
have written private extensions over the years using one or the other of
the two functions, so in order to be courteous and not break anyone's
personal emacs I left both original symbol names extant and suggested a
deprecation warning that could be followed in a later version with an EOL.

As I think I mentioned, once (if) the patch is approved, a next step is
to grep the emacs core code-base and replace the function names.

> What makes it usefully different from dired-file-name-at-point?

They return different values. One returns an expanded (canonical)
path-name, and the other an abbreviated one.

This quickly becomes an emacs history/archaeology exercise (not my PhD):
the functions were written by different people at different times for
different packages. One function entered emacs core when package dired-x
(1993-, Sebastian Kremer) was integrated. My hunch is that modifications
and bug fixes over time were only applied the dired.el version.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Previous Next

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