From: Eli Zaretskii <eliz@gnu.org>
To: Alex <agrambot@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: Native line numbers, final testing
Date: Wed, 05 Jul 2017 20:39:45 +0300 [thread overview]
Message-ID: <83y3s2n5pa.fsf@gnu.org> (raw)
In-Reply-To: <87fuecc7vg.fsf@lylat> (message from Alex on Tue, 04 Jul 2017 13:36:03 -0600)
> 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.
> 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.
> >> > And note that displaying the numbers in the margin would not have
> >> > solved the issue, since the width of the margins would still be
> >> > estimated by the same heuristics.
> >>
> >> So there's no reliable way to get the x-coordinate of the end of the
> >> left margin/fringe?
> >
> > Of course there is: call posn-at-point and its ilk.
> >
> > The problem is to know that x coordinate _before_ the margins actually
> > change their width. That is the problem to be solved in this case.
>
> I don't understand. If the x-coordinate can be calculated at the start
> of vertical-motion, then isn't that the x-coordinate before the margins
> change their width?
Yes. But I think we are talking past each other, see below.
> 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.)
> >> 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?
> > 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 believe that the C-n/C-p issue should at least be a blocker for 26.1.
We should be well past this long before we consider what blocks 26.1.
next prev parent reply other threads:[~2017-07-05 17:39 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 [this message]
2017-07-07 2:46 ` Alex
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=83y3s2n5pa.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=agrambot@gmail.com \
--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.