RE: naming functions [was: Ibuffer: w and B default to buffer at current line]

[Drew Adams]

> > Is `forward-char' a bad name, because with a negative
> > prefix arg it moves backward? Is it a bad name because
> > it is singular and a prefix arg > 1 moves further than
> > one position?
> 
> > Should the name have been `move-char' or `move-chars'?
> > If so, then what about binding forward and backward
> > default behaviors to different keys, `C-f' and `C-b'?
> 
> > I think (hope) you get the point. A function name only
> > goes so far toward indicating what the function does.
> > If a prefix arg to a command chooses alternative behavior,
> > then it would often be cumbersome and _less_ clear to
> > users, to use a name that tries to summarize all of the
> > behaviors.
> 
> The only point I'm seeing here is that we've been imprecise
> with our function names in the past.

No, that is not the point.  I tried to make clear that in
this example `forward-char' is a good name, not a bad name.

It is _not_ a bad name just because it is singular and a
prefix arg > 1 moves further than one position.  It is _not_
a bad name just because a negative prefix arg reverses its
direction from forward to backward.

It is a _good_ name because it describes the _default_
behavior well: move forward one character.  And the doc
string, not the function name, has the job of describing
the full behavior.

It is not often that a command that has multiple possible
behaviors can reasonably have all of those behaviors
reflected well in the command name.  When it can, great.
But what if it cannot?

Even the simple command `forward-char' (few are simpler)
has multiple behaviors.  Some might even call it "dwim"
because of this (I wouldn't).

Even this simple command raises interesting questions that
speak to points that you raised about the behavior and name
of a function (command in this case).  It doesn't get much
simpler than this, and yet the issues for design policy
discussed here so far are all present in this case.

> That is not a valid argument for how we should assess
> patches in the future.

No, of course not.  But no one suggested it is.  No one
has made the argument you seem to keep opposing, that
_just because_ something misguided was done in the past,
it should be done again.

> Yes, `forward-char' is misleading. `move-point' might
> have been a better choice.

You see, that's exactly _not_ the point I was making.

(And not because `move-point' doesn't mention the unit of
the move: char, or buffer position (vs word, sexp, etc.).)

Please see this question, which you did not address, and
which gets to the point:

  > > If [you think that `forward-char' should have been
  > > called `move-point'], then what about binding forward
  > > and backward default behaviors to different keys,
  > > `C-f' and `C-b'?

If we want the convenience of two different key bindings,
one moving forward by default and the other backward by
default, AND if we want the convenience of binding those
keys to named commands (and not, e.g. for backward,
(lambda (n) (interactive "p") (move-point (- n)))), then
what to call those two commands?

It's a serious question.  `move-point-1' & `move-point-2'?
Nah, those aren't great.  What would you call them, if
you could start over?

And if you want the names here to try to reflect what
these two commands actually can do, summarizing all of
the behaviors, then those names will be, I think,

  > > cumbersome and _less_ clear to users

What would you propose for those two different command
names, if not `forward-char' and `backward-char'?
`move-point' won't work for both.

Would you go for something like this?

`move-forward-1-char-but-maybe-more-and-maybe-backward'
`move-backward-1-char-but-maybe-more-and-maybe-forward'

Again, nah; those aren't great.  But it's a serious
question, starting from the aim of wanting names that
don't mislead by suggesting there is only one direction
and only one distance of movement.  If the command names
are to reflect more than the default case, what should
they be in this (simple) case?

Emacs policy/convention/tradition/history/habit has
generally been to name commands after their _default_
behaviors:

* singular: `char', not `chars' - even though a prefix
  arg can result in moving a different distance
* one with `forward' in the name and one with `backward' -
  even though a negative prefix arg reverses the direction

That's a simple approach.  It's the best I've come across.
But I truly would like to hear of something better, for
Emacs.

> What I will do, however, is reject the belief that because
> it happened in the past, this makes it OK to extend
> existing functions like this for the sake of expediency.

Again, that's good, but I don't think anyone has made
such an argument.

> I hope we can agree on the essential point here: don't
> pollute the behavior of functions because it's easy to
> do so.  With just a bit of extra work, we can avoid
> unnecessarily increasing our technical debt.

AFAICT, no one has disagreed with that - but good.  Agreed.

That, however, does not address the interesting issues you
raised, about function naming and about when/whether/how a
function can have multiple, alternative behaviors.

I'm comfortable with what Emacs has generally done in the
past in this regard, but we can certainly put it in question,
if you feel strongly about it.  Maybe there is a better
approach?

What would be the effect of a one-behavior-per-function
policy and a function-name-reflects-full-behavior policy?
What would those mean, for instance, for simple commands
such as `forward-char' and `backward-char'?

Yes, I know that you acknowledged that commands, as opposed
to non-interactive functions, _can_ have multiple behaviors.
But my impression is that you still would like to see a
command name reflect the full behavior.  I would too, when
feasible, but I think that is _not_ the usual case.

As for what behaviors should be combined in the same command,
I'm happy to see that you've said essentially the same thing
I said: The behaviors need to somehow belong together - a
command should not be a hodge-podge of unrelated behaviors.

People can disagree about what specific behaviors belong
together, but hopefully we can at least agree on the general
idea of them being related in some useful way.  (There will
always be lumpers and splitters, etc.)