[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#29279: Sharing the margins

From: Dmitry Gutov
Subject: bug#29279: Sharing the margins
Date: Wed, 15 Nov 2017 23:49:05 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Thunderbird/56.0

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

Yes, but "being the rightmost" might mean "being right next to the
text", for whatever purposes.

So far, I doubt it's going to come up as a real, hard requirement. But
we'll probably see.

I could think of something similar to overlay-arrow, only using the
margin.  Such a feature will want the arrow to be as close to buffer
text as possible.

Yeah, OK.

If not, let's put all padding on the outside and be done with that concern.

This is doable, but the implementation will be more complex.
Remember: the display engine lays out stuff left to right.  So padding
what's left after we are done with all of the "columns" is easy;
padding _before_ requires that you either compute all the widths in
advance, or that you come back after laying out the columns and insert
the stretch before it, moving all the glyphs to the right.

Sounds straightforward to me. Since we know the sizes of all the columns in advance, we can just substract them from the target total width, and pad with the resulting number of spaces.

Having extra padding between columns (your original idea) would be more complex to implement, IIUC.

Again, as long as the text-area dimensions didn't change, it could be
argued that the hook shouldn't run.

That's some creative nomenclature lawyering. :-)

It isn't.  It's just how the implementation works.

Still. To the user, the line numbers column is more like an extra margin than anything else.

Further, even though we have a separate accessor for its width (line-number-display-width), if a package depends on it and needs to draw something based on its value, it should want to be notified when there is a change (*). window-configuration-change-hook seems natural. Unless we have a separate hook for that?

OK then, what's the practical problem with saying that margins are also
part of "text-area dimensions"?

It's hard to implement.  window-configuration-change-hook currently
runs from functions that change window dimensions or the buffer
displayed in it; those never run inside redisplay.  What you (and some
others) propose will have to run in the middle of redisplaying a
window, and who knows what running arbitrary Lisp at that point will
or could do?

Not necessarily. Can't you save the necessary data to a variable, finish redisplay, and then run the hook (if the data says so)?

In addition, it will require us to record somewhere (probably, in the
window object) the last used width for number display, so we could
compare that with the new one.  This is not as simple as it sounds,
because most redisplay cycles avoid redrawing the entire window, so
determining just where in the code to perform this comparison is a
non-trivial decision.

*resigned shrug*

So I'd like to avoid this if possible.

It's somewhat hypothetical, but I'd like to refer to (*) above. That is, somebody will probably ask for that anyway, sooner or later.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]