unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Juri Linkov <juri@linkov.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 32839@debbugs.gnu.org
Subject: bug#32839: 27.0.50; recenter doesn't redisplay
Date: Sun, 30 Sep 2018 22:40:18 +0300	[thread overview]
Message-ID: <87efdau63h.fsf@mail.linkov.net> (raw)
In-Reply-To: <83a7nz5xgr.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 30 Sep 2018 09:08:20 +0300")

>> However, a minimal change that is needed here is to fix inconsistencies
>> in the recent changes: the argument name 'redisplay' is confusing -
>> it implies that it overrides the default value of recenter-redisplay
>> to force the redisplay.  A proper name would be 'interactive'.
>> There are dozens of commands already that use this naming convention.
>
> I don't think I agree.  The current name reflects what that argument
> causes, you just interpret "redisplay" to mean "redraw the frame",
> which is not an accurate interpretation, since the display engine has
> its own logic to decide what exactly needs to be redrawn at any
> particular moment.

When an argument name is a verb in the imperative mood, this means only
one thing: it should do what it claims it will do.  If it can't ensure
the result because it interprets it depending on other external conditions,
then the argument should be renamed to e.g. 'maybe-redisplay'.

> Renaming the argument as you propose would be a step backwards, since
> it describes the _purpose_ (as opposed to _effect_) of that argument,
> and that could easily change with further development, and is not
> accurate even with the current code.

Other commands that use the argument name 'interactive' have the same
assumption of describing the purpose, not effect.





  reply	other threads:[~2018-09-30 19:40 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-25 19:11 bug#32839: 27.0.50; recenter doesn't redisplay Juri Linkov
2018-09-25 20:08 ` Eli Zaretskii
2018-09-25 20:55   ` Juri Linkov
2018-09-26  5:39     ` Eli Zaretskii
2018-09-26 23:55       ` Juri Linkov
2018-09-27  6:44         ` Eli Zaretskii
2018-09-27 22:59           ` Juri Linkov
2018-09-28  6:22             ` Eli Zaretskii
2018-09-29 23:32               ` Juri Linkov
2018-09-30  6:08                 ` Eli Zaretskii
2018-09-30 19:40                   ` Juri Linkov [this message]
2018-10-01  5:34                     ` Eli Zaretskii
2018-09-29 23:38               ` Juri Linkov
2018-09-30  6:22                 ` Eli Zaretskii
2018-09-30 19:46                   ` Juri Linkov
2018-10-01  6:58                     ` Eli Zaretskii
2018-10-08 22:56                   ` Juri Linkov
2018-10-09  7:44                     ` martin rudalics
2020-02-07  0:30           ` Juri Linkov

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=87efdau63h.fsf@mail.linkov.net \
    --to=juri@linkov.net \
    --cc=32839@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /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).