GNU bug report logs -
#29279
Sharing the margins
Previous Next
Full log
View this message in rfc822 format
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.
This bug report was last modified 7 years and 206 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.