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

Previous Next

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

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

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

From: Boruch Baum <boruch_baum <at> gmx.com>
To: Emacs Bug Reporting <bug-gnu-emacs <at> gnu.org>
Subject: read carefully: dired-file-name-at-point vs dired-filename-at-point
Date: Mon, 12 Oct 2020 10:26:38 -0400

[Message part 1 (text/plain, inline)]

The attached patch takes a step to remove confusion surrounding two
unfortunately named functions, fixes bugs in one of them, and makes them
more user-friendly. If this is all acceptable, let me know and I'll add
a NEWS entry.

+ dired-filename-at-point is moved from dired-x.el to a position
  alongside its sister function dired-file-name-at-point.

+ The code for dired-filename-at-point is simplified to an almost
  carbon copy of its sister function.

  + This also fixes bugs for cases of filenames with embedded spaces

  + This also suppresses errors, due to use of dired-get-filename with
    its arg NOERROR.

+ Both get a small style tweak to remove duplicated function calls to
  abbrev- or expand- file-name.

+ Both get aliases to make them distinguishable.

A follow-up to the attached patch, if accepted, would be to refactor all
the occurrences within dired.el / dired-x.el.

It would probably be a good idea to also add a deprecation notice to the
docstrings for the original names.

I came across this while developing the diredc package I've been
mentioning a lot lately, and presenting this as a separate patch removes
it from being snagged as part of discussion about that other proposal.

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

[dired-name-confusion.patch (text/x-diff, attachment)]

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

From: Richard Stallman <rms <at> gnu.org>
To: Boruch Baum <boruch_baum <at> gmx.com>
Cc: 43961 <at> debbugs.gnu.org
Subject: Re: bug#43961: read carefully: dired-file-name-at-point vs
 dired-filename-at-point
Date: Mon, 12 Oct 2020 23:49:33 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > + 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?
What makes it usefully different from
dired-file-name-at-point?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

From: Boruch Baum <boruch_baum <at> gmx.com>
To: Richard Stallman <rms <at> gnu.org>
Cc: 43961 <at> debbugs.gnu.org
Subject: Re: 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

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Boruch Baum <boruch_baum <at> gmx.com>
Cc: 43961 <at> debbugs.gnu.org, Richard Stallman <rms <at> gnu.org>
Subject: Re: bug#43961: read carefully: dired-file-name-at-point vs
 dired-filename-at-point
Date: Tue, 13 Oct 2020 06:54:31 +0200

Boruch Baum <boruch_baum <at> gmx.com> writes:

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

Why not just have one call the other, and wrap the results in
abbreviate-file-name?

(And then mark it as obsolete, since it doesn't seem very useful.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Boruch Baum <boruch_baum <at> gmx.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 43961 <at> debbugs.gnu.org, Richard Stallman <rms <at> gnu.org>
Subject: Re: bug#43961: read carefully: dired-file-name-at-point vs
 dired-filename-at-point
Date: Tue, 13 Oct 2020 06:25:12 -0400

On 2020-10-13 06:54, Lars Ingebrigtsen wrote:
> Boruch Baum <boruch_baum <at> gmx.com> writes:
>
> > They return different values. One returns an expanded (canonical)
> > path-name, and the other an abbreviated one.
>
> Why not just have one call the other, and wrap the results in
> abbreviate-file-name?

You could, but you wouldn't be saving anything since the inner function
would still need to perform the expansion, so for the abbreviated
function you end up in effect with an inefficient (abbrev (expand file))
instead of a choice between (abbrev file) or (expand file).

Also, much of the change ends up being defaliases, docstrings and
deprecation notices, so its more clearly presented without nesting
functions.

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

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

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

Boruch Baum <boruch_baum <at> gmx.com> writes:

> On 2020-10-13 06:54, Lars Ingebrigtsen wrote:
>> Boruch Baum <boruch_baum <at> gmx.com> writes:
>>
>> > They return different values. One returns an expanded (canonical)
>> > path-name, and the other an abbreviated one.
>>
>> Why not just have one call the other, and wrap the results in
>> abbreviate-file-name?
>
> You could, but you wouldn't be saving anything since the inner function
> would still need to perform the expansion, so for the abbreviated
> function you end up in effect with an inefficient (abbrev (expand file))
> instead of a choice between (abbrev file) or (expand file).
>
> Also, much of the change ends up being defaliases, docstrings and
> deprecation notices, so its more clearly presented without nesting
> functions.
>
> --
> hkp://keys.gnupg.net
> CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
Boruch you are mind reader! At least I thought so when I saw your mail
yesterday.

I was playing with Dired myself on Monday and I actually wrote a mail
about those two functions + file-name-directory and directory-file-name,
I just never send it.

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.

But I mostly disliked the name. Why are there two almost identical name
for different functionality? I like self-documented names for variables
but if there are names like directory-file-name and file-name-directory
or something like dired-file-name-at-point and dired-filename-at-point;
then I have to remember and actively think about which one was that I
want? Usually ends up with unnecessary look-up into docs, because I
don't remember which one was that I want. Not that I hate so much to
think :-), but it does interrupt the flow of thoughts.

I understand that logic was 'objectoworkon-followed-by-operation' but I
still find it unnecessary convoluted. It is just so much more
straightforward if each function has unique descriptive name, and yes I
am aware that such names are sometimes hard to get by.

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.

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

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: Re: 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

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Boruch Baum <boruch_baum <at> gmx.com>
Cc: 43961 <at> debbugs.gnu.org, Richard Stallman <rms <at> gnu.org>
Subject: Re: bug#43961: read carefully: dired-file-name-at-point vs
 dired-filename-at-point
Date: Wed, 14 Oct 2020 05:45:51 +0200

Boruch Baum <boruch_baum <at> gmx.com> writes:

>> Why not just have one call the other, and wrap the results in
>> abbreviate-file-name?
>
> You could, but you wouldn't be saving anything since the inner function
> would still need to perform the expansion, so for the abbreviated
> function you end up in effect with an inefficient (abbrev (expand file))
> instead of a choice between (abbrev file) or (expand file).

It's not about code efficiency -- whether this function is efficient or
not doesn't make any difference, since we'd deprecate it, and change the
callers.

> Also, much of the change ends up being defaliases, docstrings and
> deprecation notices, so its more clearly presented without nesting
> functions.

Sorry, I don't think this is a good change.  Renaming these functions
just because we have two almost identical ones (when we should just
remove one of them) doesn't make much sense.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Boruch Baum <boruch_baum <at> gmx.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 43961 <at> debbugs.gnu.org, Richard Stallman <rms <at> gnu.org>
Subject: Re: bug#43961: read carefully: dired-file-name-at-point vs
 dired-filename-at-point
Date: Wed, 14 Oct 2020 00:19:11 -0400

On 2020-10-14 05:45, Lars Ingebrigtsen wrote:
> It's not about code efficiency -- whether this function is efficient or
> not doesn't make any difference, since we'd deprecate it, and change the
> callers.

> Sorry, I don't think this is a good change.  Renaming these functions
> just because we have two almost identical ones (when we should just
> remove one of them) doesn't make much sense.

Maybe you're catching me on a bad day, but I don't have the patience to
continue this discussion. IMO, you're making a glaringly bad call. If my
presentation was inadequate, that's on me; I can't present any clearer
than I have already done previously on this thread, so someone else is
going to need to carry the ball on this, or maybe you'll re-read the
thread more carefully and change your mind. I'm moving on to other
issues.

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

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

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

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

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

I just did that.  dired-filename-at-point is not used anywhere except
dired-x.el.

I expect that none of the published Lisp packages uses
dired-filename-at-point.
-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Richard Stallman <rms <at> gnu.org>
Cc: 43961 <at> debbugs.gnu.org, Boruch Baum <boruch_baum <at> gmx.com>
Subject: Re: bug#43961: read carefully: dired-file-name-at-point vs
 dired-filename-at-point
Date: Wed, 14 Oct 2020 06:58:07 +0200

Richard Stallman <rms <at> gnu.org> writes:

>   > 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.
>
> I just did that.  dired-filename-at-point is not used anywhere except
> dired-x.el.
>
> I expect that none of the published Lisp packages uses
> dired-filename-at-point.

And I looked at the code now, and it seems the bug reporter
misunderstood the point of the function: It's used to guess a file name
in non-dired buffers, while dired-file-name-at-point is a dired function
that just returns the file name in a dired buffer.

So they're totally unrelated functions, but dired-filename-at-point has
an unfortunate name.  I've now renamed it (but kept
dired-filename-at-point as an obsolete alias).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Richard Stallman <rms <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 43961 <at> debbugs.gnu.org, boruch_baum <at> gmx.com
Subject: Re: bug#43961: read carefully: dired-file-name-at-point vs
 dired-filename-at-point
Date: Wed, 14 Oct 2020 23:57:12 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > So they're totally unrelated functions, but dired-filename-at-point has
  > an unfortunate name.  I've now renamed it (but kept
  > dired-filename-at-point as an obsolete alias).

Thanks for cleaning up that confusion.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Previous Next

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