[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ibuffer: w and B default to buffer at current line

From: John Wiegley
Subject: Re: Ibuffer: w and B default to buffer at current line
Date: Sat, 17 Sep 2016 09:30:00 -0700
User-agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.1 (darwin)

>>>>> Drew Adams <address@hidden> writes:

> I started to reply in a similar vein to Eli. On rereading John's mail I saw
> that he tried to separate what the behavior is for users from how the
> behavior is implemented, and his argument seems to be only about the latter
> (although it was not made as clearly as it might have been, IMO).

> IOW, I don't think John is arguing against the UI design of letting a key
> such as `C' or `F' in Dired have different behaviors depending on the use of
> a prefix arg.

> I think his only argument is about how that (good, not bad) behavior is
> implemented. He argues that there should be a separate function for acting
> on only the current line's file and not the marked files.

Hi Drew, you've summed up very well the point I was trying to convey. My
apologies if any hand-waving was perceived; I'd be happy to construct code
examples on any point, if that is needed.

The reason for my comment is that the original patch requested adding a new
argument to an existing function, in order to special-case the behavior of
that function in a way that does not fit with its current name and purpose.
I'd rather have two functions and a new command that calls the appropriate
function based on its context of use.

What I to avoid is coding special behavior into existing functions -- *in the
implementation* -- simply because it is convenient. It still bothers me that
`call-process-region' does this, for example, with its many and varied
meanings of the "START" argument -- some of which relate neither to the
meaning of "start", nor of "region".

When it comes to UI, I'm in complete agreement with Eli: I love DWIM behavior,
and think this is a virtue of Emacs, not a vice in any way.

So yes, I'm just thinking about the code: modularity, ease of maintenance,
clarity of purpose. These may be not be terribly specific statements, but they
are the motive for my comments.

John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]