all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dgutov@yandex.ru>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 29279@debbugs.gnu.org
Subject: bug#29279: Sharing the margins
Date: Mon, 13 Nov 2017 21:02:23 +0200	[thread overview]
Message-ID: <56131da6-14fb-d669-f69a-72fd2e696d5c@yandex.ru> (raw)
In-Reply-To: <83po8mkptj.fsf@gnu.org>

On 11/13/17 8:15 PM, Eli Zaretskii wrote:

> No, to the left.  If a Lisp program wants to align to the right, it
> should insert white space before the actual text.

That's only possible if it knows the resulting width. Which it will, in 
the current state of the discussion.

Still, it seems unnecessary if the somewhat faster C code could 
implement that for every user.

>>>> The display engine would scan the contents of the current window, process said specs, calculate which lines fit the window and which do not, set the total margin width appropriately, and display all columns in it. Some reflowing might be required.
> 
> If everything is already spelled out in a variable
> left-margin-columns-alist, then why do we need to scan the contents of
> the window?

In the first proposal, the actual width of the column would be 
auto-computed by the display engine based in the width of all relevant 
SPECs.

But we seem to have discarded this idea now.

>> I was hoping that we might consider some parts of redisplay to be "fast
>> enough" by now (posn-at-point is fast enough for ~500 FPS on my machine,
>> for instance), but indeed it should require some smart programming.
> 
> posn-at-point goes _once_ from window-start to the specified position,
> so on average it traverses half a window, once.  By contrast, we are
> now talking about redisplaying the window twice, and one of these 2
> times must traverse the entire window.  So we are talking about
> threefold slow-down on the average.

3-fold slowdown from 500 FPS seems acceptable to me.

> So yes, if the margin display depends heavily on what is in the
> window, especially on how many lines/characters are in the window, it
> will have hard time being Speedy Gonzales; such features are better
> implemented in C as an integral part of redisplay.  But not all uses
> of the margins are like that.  I will even risk saying that most of
> them aren't.  For that majority, calculating the maximum width they
> need from the margin at the end of a command is not a big deal, and
> could probably change relatively rarely.

Let's hope so.





  reply	other threads:[~2017-11-13 19:02 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-12 23:51 bug#29279: Sharing the margins Dmitry Gutov
2017-11-13 15:43 ` Eli Zaretskii
2017-11-13 17:24   ` Dmitry Gutov
2017-11-13 18:15     ` Eli Zaretskii
2017-11-13 19:02       ` Dmitry Gutov [this message]
2017-11-13 19:22         ` Eli Zaretskii
2017-11-13 19:33           ` Dmitry Gutov
2017-11-13 15:46 ` Eli Zaretskii
2017-11-13 17:54   ` Dmitry Gutov
2017-11-13 18:29     ` Eli Zaretskii
2017-11-13 19:16       ` Dmitry Gutov
2017-11-13 19:32         ` Eli Zaretskii
2017-11-13 21:16           ` Dmitry Gutov
2017-11-14 15:30             ` Eli Zaretskii
2017-11-14 22:39               ` Dmitry Gutov
2017-11-15  3:42                 ` Eli Zaretskii
2017-11-15 14:23                   ` Dmitry Gutov
2017-11-15 18:00                     ` Eli Zaretskii
2017-11-15 21:49                       ` Dmitry Gutov
2017-11-16 15:50                         ` Eli Zaretskii
2017-11-18 23:55                           ` Dmitry Gutov
2017-11-19 15:34                             ` Eli Zaretskii
2017-11-20 22:23                               ` Dmitry Gutov
2017-11-21 15:40                                 ` Eli Zaretskii
2017-11-15 18:51                 ` martin rudalics
2017-11-15 20:03                   ` Eli Zaretskii
2017-11-15 21:09                     ` Dmitry Gutov
2017-11-16 15:39                       ` Eli Zaretskii
2017-11-18 23:46                         ` Dmitry Gutov
2017-11-19 15:30                           ` Eli Zaretskii
2017-11-19  0:47             ` Joost Kremers
2017-11-19  9:20               ` Dmitry Gutov
2017-11-14  9:54       ` martin rudalics
2017-11-14 15:51         ` Eli Zaretskii
2017-11-15 18:50           ` martin rudalics
2017-11-14  9:54   ` martin rudalics
2017-11-14 15:51     ` Eli Zaretskii
2017-11-14 18:30       ` martin rudalics
2017-11-14 19:05         ` 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=56131da6-14fb-d669-f69a-72fd2e696d5c@yandex.ru \
    --to=dgutov@yandex.ru \
    --cc=29279@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 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.