all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Alex <agrambot@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Native line numbers, final testing
Date: Thu, 06 Jul 2017 20:46:42 -0600	[thread overview]
Message-ID: <878tk1rmjx.fsf@lylat> (raw)
In-Reply-To: <83y3s2n5pa.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 05 Jul 2017 20:39:45 +0300")

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Alex <agrambot@gmail.com>
>> Cc: emacs-devel@gnu.org
>> Date: Tue, 04 Jul 2017 13:36:03 -0600
>> 
>> I've never heard of line-prefix before this discussion, so I don't know
>> what the expected behaviour of it is/should be. However, I don't believe
>> the width of the line numbers should have any bearing on the column
>> position of a particular character in the buffer. Indeed, C-x = at the
>> beginning of a line with display-line-numbers correctly shows
>> "column=0". So I don't see the link between your recipe and mine.
>
> "C-x =" just counts characters.  Try "M-: (posn-at-point) RET" for
> more insight.

OK, so C-n/C-p currently try to preserve the column calculated by either
posn-col-row or posn-actual-col-row? I believe I understand now, though
I still disagree that line numbers should behave similarly.

It appears that both nlinum and display-line-numbers contradict the 2nd
sentence of the documentation for line-move-visual. When the line number
width in nlinum increases, everything including the cursor is shifted
over. So if C-n triggers this change, then one could consider this to be
wrong behaviour.

In display-line-numbers, then C-n and C-p both may not preserve the
current horizontal screen position even when the line number width does
not (noticeably) change. Here, the horizontal screen position of the
cursor is moved by 1 character, but in contrast to the nlinum case, the
rest of the buffer contents remain horizontally stationary.

If one has to choose between these two behaviours, then I believe the
former is significantly more user-friendly. It is much easier to reason
about, and it does not change the horizontal cursor position relative to
buffer contents.

>> I highly doubt many, if anyone else, expect line numbers to behave like
>> this.
>
> It's quite possible.  I just want to hear that before I write the
> code.  Since I probably won't use line numbers (except for debugging
> problems they cause ;-), I don't think my judgment is good enough
> here.

I think a reasonable default is to behave similarly to the previous line
number implementations where it makes sense, and to change it if users
tend to dislike it. I suppose the contention here may be "where it makes
sense". I think it makes sense for the basic navigation commands to
behave similarly between the different implementations.

>> As a thought for the current problem, could you adjust the position
>> after vertical-motion is called if it turns out that the
>> line-number-width/margin-size changed?
>
> Sure.  I already write code to do that, I just stashed it waiting to
> see what this discussion concludes.  (And it isn't enough to make the
> correction inside vertical-motion: temporary-goal-column also needs to
> be adjusted.)

It's good to know that there's a working solution. I hope it will land
in Emacs.

>> >> Why don't these issues affect nlinum, since it sets
>> >> the width dynamically?
>> >
>> > Because nlinum and similar modes change the width of the margin
>> > _after_ C-n already moved point.  So C-n does its thing with the
>> > margin still at its old width, and doesn't need to deal with the width
>> > changing under its feet.
>> 
>> Didn't you write before (when talking about 'visual) that line number
>> calculation/display was done after the point is moved? In that case, how
>> is display-line-numbers different to what you just described (outside of
>> not using the margin)?
>
> I think I lost the focus of this discussion, so I'm not sure anymore
> I'm answering your questions correctly.  What is it that you are
> getting at with these questions?

Sorry, I think we both lost focus a bit since there's a few different
topics in this thread. Here, I believe we were talking about line
numbers in the margin, and if the property of being in the margin by
itself would be able to avoid this issue. I was under the assumption
that it would be, but assuming strict compliance to the documentation of
line-move-visual, then I think I get now why it wouldn't.

>> > I don't think this should be done in C.  I can provide a function to
>> > obtain the current width of the line-number display, and then a Lisp
>> > program, called from some suitable hook, could notice when the value
>> > becomes larger, and set display-line-number-width to that same value.
>> > Would that be satisfactory?
>> 
>> If the performance and convenience is about the same, then I suppose it
>> doesn't matter where it's implemented. What would be a suitable hook? I
>> see a pre-redisplay-functions, but not a post-redisplay-functions.
>
> pre-redisplay-functions should be OK, but I think even
> pre-command-hook is fine.  You really want to set this before
> redisplay runs, because after it runs it might be too late.
>
>> would you provide a specific display-line-number hook?
>
> I don't see why we would want such a hook, and what would it do and
> how.

I figured it would be best to change display-line-number-width as soon
as possible, and for the check to be made as infrequent as possible. A
hook called in the same area that it->lnum_width is changed would be the
best for that, though perhaps that's going overboard.

pre-command-hook definitely sounds better than pre-redisplay-functions,
but it would be nice if the check didn't have to be made every time a
command is issued. Although I suppose if the width accessor is a fast
constant lookup, then it doesn't really matter.



  reply	other threads:[~2017-07-07  2:46 UTC|newest]

Thread overview: 90+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-30 14:49 Native line numbers, final testing Eli Zaretskii
2017-06-30 17:51 ` Alex
2017-06-30 18:20   ` Eli Zaretskii
2017-06-30 19:06     ` Alex
2017-06-30 19:55       ` Eli Zaretskii
2017-06-30 21:15         ` Alex
2017-07-01  8:00           ` Eli Zaretskii
2017-07-01 21:00             ` Alex
2017-07-02  2:40               ` Eli Zaretskii
2017-07-02  5:16                 ` Alex
2017-07-02 15:10                   ` Eli Zaretskii
2017-07-02 16:47                     ` Stefan Monnier
2017-07-02 16:51                       ` Eli Zaretskii
2017-07-02 17:38                         ` Stefan Monnier
2017-07-02 19:27                           ` Eli Zaretskii
2017-07-03  5:06                     ` Alex
2017-07-03 15:24                       ` Eli Zaretskii
2017-07-04 19:36                         ` Alex
2017-07-05 17:39                           ` Eli Zaretskii
2017-07-07  2:46                             ` Alex [this message]
2017-07-07  6:19                               ` Eli Zaretskii
2017-07-07  9:24                                 ` Eli Zaretskii
2017-07-08 20:51                                   ` Alex
2017-07-09 20:16                                     ` James Cloos
2017-07-09 21:45                                       ` Yuri Khan
2017-07-10  2:33                                         ` Eli Zaretskii
2017-07-10  7:09                                           ` Yuri Khan
2017-07-10 17:02                                             ` Eli Zaretskii
2017-07-10  2:31                                       ` Eli Zaretskii
2017-07-10  5:35                                         ` James Cloos
2017-07-10 17:00                                           ` Eli Zaretskii
2017-07-10 18:15                                             ` Filipe Silva
2017-07-10 18:18                                               ` Eli Zaretskii
2017-07-10 18:23                                                 ` Filipe Silva
2017-07-10 18:32                                             ` James Cloos
2017-07-11 20:58                                             ` Alex
2017-07-11 21:18                                               ` Filipe Silva
2017-07-11 21:20                                                 ` Filipe Silva
2017-07-11 21:37                                                   ` Alex
2017-07-12  2:35                                               ` Eli Zaretskii
2017-07-12  2:53                                                 ` Alex
2017-07-12 14:21                                                   ` Eli Zaretskii
2017-07-12 17:22                                                     ` Alex
2017-07-12 17:25                                                       ` Alex
2017-07-12 18:38                                                       ` Eli Zaretskii
2017-07-12 20:03                                                         ` Alex
2017-07-13  2:38                                                           ` Eli Zaretskii
2017-07-13  4:11                                                             ` Alex
2017-07-13 15:56                                                               ` Eli Zaretskii
2017-07-26  3:50                                                                 ` Alex
2017-07-26 14:42                                                                   ` Eli Zaretskii
2017-07-29  6:12                                                                     ` Alex
2017-07-29  7:01                                                                       ` Eli Zaretskii
2017-07-07  9:47                                 ` Eli Zaretskii
2017-07-07  9:49                                   ` Eli Zaretskii
2017-07-07 11:14                                     ` Filipe Silva
2017-07-07 12:21                                       ` Eli Zaretskii
2017-07-07 12:29                                   ` Eli Zaretskii
     [not found]                                     ` <CAEwkUWN8GkCyOiF4jEgKuZwJHhvMgJi9yVnvggRvu+Yddfp4qQ@mail.gmail.com>
2017-07-07 12:56                                       ` Filipe Silva
2017-07-01  1:59 ` Filipe Silva
2017-07-02 19:27 ` James Nguyen
2017-07-03  2:33   ` Eli Zaretskii
2017-07-03  3:22     ` James Nguyen
2017-07-03 15:58       ` Eli Zaretskii
2017-07-03 17:04         ` James Nguyen
2017-07-04 10:57           ` Filipe Silva
2017-07-04 11:00             ` Filipe Silva
2017-07-04 13:51               ` Kaushal Modi
2017-07-04 14:30               ` Eli Zaretskii
2017-07-04 14:32             ` Eli Zaretskii
2017-07-04 14:48               ` Filipe Silva
2017-07-04 14:50                 ` Filipe Silva
2017-07-04 15:44                   ` Eli Zaretskii
2017-07-04 16:22                     ` Filipe Silva
2017-07-04 16:34                       ` Filipe Silva
2017-07-04 16:35                       ` Richard Copley
2017-07-04 16:44                         ` Eli Zaretskii
2017-07-04 17:13                           ` Richard Copley
2017-07-04 17:35                             ` Filipe Silva
2017-07-04 17:48                               ` Eli Zaretskii
2017-07-04 17:52                               ` Stefan Monnier
2017-07-10 18:22                                 ` Filipe Silva
2017-07-10 20:28                                   ` Stefan Monnier
2017-07-04 17:47                             ` Eli Zaretskii
2017-07-04 17:50                           ` Alex
2017-07-04 18:24                             ` Eli Zaretskii
2017-07-04 18:37                               ` Richard Copley
2017-07-04 18:43                                 ` Eli Zaretskii
2017-07-05 20:24 ` Andy Moreton
2017-07-06 17:24   ` Eli Zaretskii

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

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

  git send-email \
    --in-reply-to=878tk1rmjx.fsf@lylat \
    --to=agrambot@gmail.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.