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

Previous Next

Package: emacs;

Reported by: Boruch Baum <boruch_baum <at> gmx.com>

Date: Mon, 12 Oct 2020 14:28:02 UTC

Severity: minor

Tags: fixed, patch

Fixed in version 28.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Boruch Baum <boruch_baum <at> gmx.com>
To: Arthur Miller <arthur.miller <at> live.com>
Cc: 43961 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>, Richard Stallman <rms <at> gnu.org>
Subject: bug#43961: read carefully: dired-file-name-at-point vs dired-filename-at-point
Date: Tue, 13 Oct 2020 07:27:46 -0400
On 2020-10-13 12:58, Arthur Miller wrote:
> ...
> + file-name-directory and directory-file-name,

Another excellent example that I always find confusing, even after much
dired programming.

> dired-filename-at-point is supposed to return a filename closest to the
> point, according to docs. For me it didn't work at all.

I seems to not have been as well-maintained as its sister function,
possibly because they've been in separate files and the maintainer
forgot about one. One of its bugs is that it truncates file names at the
first embedded space.

> But I mostly disliked the name. Why are there two almost identical name
> for different functionality?

So annoying, and not limited to dired. I recently posted another in bug
report 43294 [1]. It's been languishing for ~6 weeks without a decision
for action, so your vote might be helpful there.

> I have seen also discussion about string-replace and replace-string, can
> we plase not? For the reason above. And for the new APIs added, please
> don't use naming patterns like word1-word2 and word2-word1 or similar
> where same words are used just with some slight variation.

+1

Also, match-string and string-match. IMO, match-string should be aliased
and to something like 'match-result' and deprecate the original name
with a long-horizon EOL to account for its ubiquity. @Lars: Should I
open a bug report separately for this?

[1] https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-09/msg00872.html

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




This bug report was last modified 4 years and 220 days ago.

Previous Next


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