all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: help-gnu-emacs@gnu.org
Subject: Re: relative line numbers and folding: how to make they play along?
Date: Fri, 15 Jul 2016 17:22:07 +0300	[thread overview]
Message-ID: <83d1mf6kxc.fsf@gnu.org> (raw)
In-Reply-To: <jwvfurbm3aq.fsf-monnier+gmane.emacs.help@gnu.org> (message from Stefan Monnier on Fri, 15 Jul 2016 09:53:44 -0400)

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 15 Jul 2016 09:53:44 -0400
> 
> I was more thinking of the situation I mentioned in some other
> discussion: rewrite the top-level of the redisplay code in Elisp,

Conditioning the minor feature discussed in this thread on such a
thorough rewrite of the display code sounds like overkill to me.

> basically a function which:
> - asks the C code which windows need to be redisplayed.
> - call a C function on each of those windows to recompute the matrices.
> - detect the case where point is out of the window, and either move
>   point and call the recompute-matrices function, or call another
>   C function to do the scrolling.
> - then call a C function on each window/frame to update the display.
> 
> >From there we can hope to provide a more efficient/robust follow-mode
> (while still implementing it in Elisp).  And in that context, we should
> also be able to provide a more efficient relative-visual-linum-mode, tho
> it might require yet more access, such as subrs to scan/read the
> matrices, and maybe other subrs to modify the matrices (to update the
> margin).
> 
> Some of those primitives would probably also be useful in order to write
> tests of the redisplay code.
> 
> I think such a change should be doable without a complete rewrite of
> the redisplay.  But it would undoubtedly take a fair bit of work.

Frankly, I don't see any significant gains in your suggestion.
Basically, you suggest to leave the bulk of the display code
unchanged, and introduce a Lisp-level driver that calls its parts one
after the other.  Moreover, that Lisp will be called from C, since
that's where we currently invoke redisplay.  I don't see why we would
want that, and disagree with you that this will make the job of
follow-mode easier (because what follow-mode wants is intervene in the
middle of some of those parts you want to leave in C).

I think a much better plan is to expose some of the C data structures
to Lisp, and provide focused hooks at strategic places for Lisp to be
able to affect what redisplay does, by accessing those data structures
and making decisions based on that.



  reply	other threads:[~2016-07-15 14:22 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-11 15:11 relative line numbers and folding: how to make they play along? Filipe Silva
2016-07-12  4:51 ` Eli Zaretskii
2016-07-13  3:43   ` Filipe Silva
2016-07-13 20:10   ` Stefan Monnier
2016-07-13 20:23     ` Eli Zaretskii
2016-07-13 22:33       ` Filipe Silva
2016-07-14 15:02         ` Eli Zaretskii
     [not found]       ` <mailman.1359.1468449224.26859.help-gnu-emacs@gnu.org>
2016-07-14  1:29         ` Dan Espen
2016-07-14  2:36       ` Stefan Monnier
2016-07-14 15:06         ` Eli Zaretskii
2016-07-14 15:55           ` Filipe Silva
2016-07-14 15:58             ` Filipe Silva
2016-07-14 16:12               ` Eli Zaretskii
2016-07-14 16:51                 ` Filipe Silva
2016-07-14 18:23                   ` Boris
2016-07-14 21:03           ` Stefan Monnier
2016-07-15  0:04             ` Filipe Silva
2016-07-15  0:18               ` Stefan Monnier
2016-07-15  0:41                 ` Filipe
2016-07-15  7:07             ` Eli Zaretskii
2016-07-15 13:53               ` Stefan Monnier
2016-07-15 14:22                 ` Eli Zaretskii [this message]
2016-07-15 14:54                   ` Stefan Monnier
2016-07-15 15:34                     ` Filipe Silva
     [not found]           ` <mailman.1414.1468511758.26859.help-gnu-emacs@gnu.org>
2016-07-15  2:02             ` Dan Espen
     [not found]       ` <mailman.1374.1468463825.26859.help-gnu-emacs@gnu.org>
2016-07-14  3:20         ` Rusi
2016-07-14 12:17           ` Stefan Monnier

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=83d1mf6kxc.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=help-gnu-emacs@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.