From: Alex <agrambot@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Native line numbers, final testing
Date: Sun, 02 Jul 2017 23:06:29 -0600 [thread overview]
Message-ID: <874luuyuqy.fsf@lylat> (raw)
In-Reply-To: <837ezqq3gd.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 02 Jul 2017 18:10:58 +0300")
[-- Attachment #1: Type: text/plain, Size: 2567 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Alex <agrambot@gmail.com>
>> Cc: emacs-devel@gnu.org
>> Date: Sat, 01 Jul 2017 23:16:11 -0600
>> > I couldn't (yet) find a way of doing that.
>>
>> That's unfortunate; hopefully this can be fixed.
>
> I think I fixed that now.
The issue is a bit harder to encounter now, but it appears to still be
present. In xdisp.c:
M-g c 2970 RET
C-u 16 C-n
Then hit C-n a few times to reach line 87. The cursor will now be on
column 26 instead of column 27.
You can also test this by holding C-n or C-p and noticing the goal
column changing. This also affects C-v and M-v with
scroll-preserve-screen-position set to 'always.
>> > I firmly believe that line numbers should not be displayed on the
>> > margins, because that produces problems for packages that want to
>> > display stuff there.
>>
>> That seems to me to be an extensibility problem rather than line numbers
>> not belonging in the margins. Without fixing that problem, then there
>> will still be problems when multiple packages attempt to use the margins
>> simultaneously.
>
> That's correct, but since coexistence in the margin is problematic,
> core features, especially popular ones, should not use the margins, so
> as not to exacerbate the problems.
>
> 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? Why don't these issues affect nlinum, since it sets
the width dynamically?
>> That way, line numbers can have its own special area, and there will
>> be a clear x-coordinate for vertical-motion to start from, avoiding
>> a whole class of errors that you've had to deal with so far.
>
> See above: these problems won't be solved by going to the margin. The
> only way to solve them is to have a fixed width for line numbers,
> something that can be done, if desired, by suitable setting of
> display-line-number-width.
That will definitely alleviate the issues, but won't completely solve
them on its own (plus, one shouldn't have to set that to avoid them).
On this note, I'd like to again ask for dynamic growing of the width,
but not shrinking. That should also help towards avoiding this problem
in growing buffers.
I've edited and attached my previous proof of concept, but it uses
Fmake_local_variable, which doesn't look like it's used a lot in the C
side of Emacs. Is there a better way to make buffer local internal
variables?
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: line-numbers-grow-only.diff --]
[-- Type: text/x-diff, Size: 2193 bytes --]
diff --git a/src/xdisp.c b/src/xdisp.c
index 47b8141463..14f070d487 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -20872,7 +20872,12 @@ maybe_produce_line_number (struct it *it)
/* Compute the required width if needed. */
if (!it->lnum_width)
{
- if (NATNUMP (Vdisplay_line_number_width))
+ Lisp_Object cache = buffer_local_value (Qdisplay_line_number_width_cache,
+ it->w->contents);
+
+ if (NATNUMP (cache))
+ it->lnum_width = XFASTINT (cache);
+ else if (NATNUMP (Vdisplay_line_number_width))
it->lnum_width = XFASTINT (Vdisplay_line_number_width);
/* Max line number to be displayed cannot be more than the one
@@ -20891,6 +20896,9 @@ maybe_produce_line_number (struct it *it)
max_lnum = this_line + it->w->desired_matrix->nrows - 1 - it->vpos;
max_lnum = max (1, max_lnum);
it->lnum_width = max (it->lnum_width, log10 (max_lnum) + 1);
+ if (display_line_numbers_grow_only)
+ Fset (Fmake_local_variable (Qdisplay_line_number_width_cache),
+ make_number (it->lnum_width));
eassert (it->lnum_width > 0);
}
if (EQ (Vdisplay_line_numbers, Qrelative))
@@ -32594,6 +32602,18 @@ Any other value is treated as nil. */);
DEFSYM (Qdisplay_line_number_width, "display-line-number-width");
Fmake_variable_buffer_local (Qdisplay_line_number_width);
+ DEFVAR_BOOL ("display-line-numbers-grow-only", display_line_numbers_grow_only,
+ doc: /* Non-nil means only dynamically grow the display,
+and never shrink. */);
+ display_line_numbers_grow_only = false;
+
+ DEFVAR_LISP ("display-line-number-width-cache", Vdisplay_line_number_width_cache,
+ doc: /* Stores the maximum line number width seen. */);
+ Vdisplay_line_number_width_cache = Qnil;
+ DEFSYM (Qdisplay_line_number_width_cache, "display-line-number-width-cache");
+ Fmake_variable_buffer_local (Qdisplay_line_number_width_cache);
+ Funintern (Qdisplay_line_number_width_cache, Qnil);
+
DEFVAR_LISP ("display-line-numbers-current-absolute",
Vdisplay_line_numbers_current_absolute,
doc: /* Non-nil means display absolute number of current line.
next prev parent reply other threads:[~2017-07-03 5:06 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 [this message]
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
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
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=874luuyuqy.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 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).