[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
signature.asc
Description: PGP signature
- Ibuffer: w and B default to buffer at current line, Tino Calancha, 2016/09/14
- Re: Ibuffer: w and B default to buffer at current line, John Wiegley, 2016/09/14
- Re: Ibuffer: w and B default to buffer at current line, Tino Calancha, 2016/09/14
- RE: Ibuffer: w and B default to buffer at current line, Drew Adams, 2016/09/14
- Re: Ibuffer: w and B default to buffer at current line, John Wiegley, 2016/09/15
- Re: Ibuffer: w and B default to buffer at current line, Eli Zaretskii, 2016/09/16
- RE: Ibuffer: w and B default to buffer at current line, Drew Adams, 2016/09/16
- Re: Ibuffer: w and B default to buffer at current line,
John Wiegley <=
- Re: Ibuffer: w and B default to buffer at current line, Eli Zaretskii, 2016/09/17
- RE: Ibuffer: w and B default to buffer at current line, Drew Adams, 2016/09/17
- Re: Ibuffer: w and B default to buffer at current line, Eli Zaretskii, 2016/09/17
- RE: Ibuffer: w and B default to buffer at current line, Drew Adams, 2016/09/17
- Re: Ibuffer: w and B default to buffer at current line, Eli Zaretskii, 2016/09/18
- naming functions [was: Ibuffer: w and B default to buffer at current line], Drew Adams, 2016/09/18
- Re: naming functions [was: Ibuffer: w and B default to buffer at current line], John Wiegley, 2016/09/18
- RE: naming functions [was: Ibuffer: w and B default to buffer at current line], Drew Adams, 2016/09/18
- Re: naming functions [was: Ibuffer: w and B default to buffer at current line], Eli Zaretskii, 2016/09/19
- Re: Ibuffer: w and B default to buffer at current line, John Wiegley, 2016/09/17