[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 14:35:57 -0700 |
User-agent: |
Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.1 (darwin) |
>>>>> Eli Zaretskii <address@hidden> writes:
>> 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.
> If DWIM is okay in the UI, then functions that behave in support of that UI
> should also be okay.
Since this responses surprised me a bit, I'm going to assume that I've
misunderstood somehow.
Let me give a hypothetical example: Assume for the sake of argument that
`count-lines' did not report characters as well, and that someone wished to
extend the `count-lines' command so that, given a prefix arg, it would count
characters instead of lines.
What I think should happen in this case is that a new command be created:
count-items-in-region, which by default counts lines, but with a prefix
argument counts characters. This leaves that command open to many new
behaviors in future, while `count-lines' keeps doing just what it says: count
lines.
What I would object to is adding a new argument to `count-lines', called
`characters-p', that changes the behavior of count-lines to now count
characters instead (again, remember this is hypothetical, I know that today's
`count-lines' already counts characters as well).
Just because I want DWIM from my interface, doesn't mean I need to implement
it as DWIM in my functions. I believe -- very strongly -- that each function
should do one thing and one thing well, and this one thing should be
documented well. I don't like magical functions with lots of alternative
behaviors, unless it is a command created for the purpose of magically
dispatching to other functions based on its context of use. Such magical
interface functions are quite alright in my book; but complexifying the
behavior of core functions is not.
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
signature.asc
Description: PGP signature
- Re: Ibuffer: w and B default to buffer at current line, (continued)
- Re: Ibuffer: w and B default to buffer at current line, John Wiegley, 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/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 <=
- 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, John Wiegley, 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, John Wiegley, 2016/09/17
- Re: Ibuffer: w and B default to buffer at current line, Eli Zaretskii, 2016/09/18
- Re: Ibuffer: w and B default to buffer at current line, John Wiegley, 2016/09/18
Re: Ibuffer: w and B default to buffer at current line, Tino Calancha, 2016/09/17