unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: John Wiegley <jwiegley@gmail.com>
To: Drew Adams <drew.adams@oracle.com>
Cc: Eli Zaretskii <eliz@gnu.org>,
	emacs-devel@gnu.org, tino.calancha@gmail.com
Subject: Re: naming functions [was: Ibuffer: w and B default to buffer at current line]
Date: Sun, 18 Sep 2016 12:23:33 -0700	[thread overview]
Message-ID: <m2twddqafe.fsf@newartisans.com> (raw)
In-Reply-To: <054178e6-00ee-48ec-8799-3845c79675cd@default> (Drew Adams's message of "Sun, 18 Sep 2016 10:55:30 -0700 (PDT)")

[-- Attachment #1: Type: text/plain, Size: 1739 bytes --]

>>>>> Drew Adams <drew.adams@oracle.com> writes:

> 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. That is not a valid argument for how we should assess
patches in the future.

Yes, `forward-char' is misleading. `move-point' might have been a better
choice. But there are many ships like this that left the port long ago. I'm
not even suggesting we retroactively fix any of them. 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.

So unless you're actually arguing for it to be OK to extend functions beyond
their stated semantics, 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.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

  reply	other threads:[~2016-09-18 19:23 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-14  5:35 Ibuffer: w and B default to buffer at current line Tino Calancha
2016-09-14  6:41 ` John Wiegley
2016-09-14  7:21   ` Tino Calancha
2016-09-14 14:08     ` Drew Adams
2016-09-15 22:05     ` John Wiegley
2016-09-16  6:40       ` Eli Zaretskii
     [not found]       ` <<83intw5our.fsf@gnu.org>
2016-09-16 14:53         ` Drew Adams
2016-09-17 16:30           ` John Wiegley
2016-09-17 17:21             ` Eli Zaretskii
2016-09-17 21:35               ` John Wiegley
2016-09-17 23:26                 ` Drew Adams
2016-09-17 23:51                   ` John Wiegley
2016-09-18  1:45                     ` Drew Adams
2016-09-18  2:18                       ` John Wiegley
2016-09-18 14:26                 ` Eli Zaretskii
2016-09-18 19:35                   ` John Wiegley
     [not found]             ` <<83zin630i9.fsf@gnu.org>
2016-09-17 18:47               ` Drew Adams
2016-09-17 19:25                 ` Eli Zaretskii
     [not found]                 ` <<83vaxuib1p.fsf@gnu.org>
2016-09-17 19:33                   ` Drew Adams
2016-09-18 14:29                     ` Eli Zaretskii
     [not found]                   ` <<d33a60f5-b8b6-4637-b3e6-ea1b09d98f85@default>
     [not found]                     ` <<83poo1i8nf.fsf@gnu.org>
2016-09-18 17:55                       ` naming functions [was: Ibuffer: w and B default to buffer at current line] Drew Adams
2016-09-18 19:23                         ` John Wiegley [this message]
2016-09-18 23:24                           ` Drew Adams
2016-09-19 16:35                           ` Eli Zaretskii
2016-09-17 18:22   ` Ibuffer: w and B default to buffer at current line Tino Calancha
2016-09-26 12:08     ` Tino Calancha
2016-10-03 12:28       ` Tino Calancha

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m2twddqafe.fsf@newartisans.com \
    --to=jwiegley@gmail.com \
    --cc=drew.adams@oracle.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=tino.calancha@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).