bug-gnu-emacs
[Top][All Lists]
Advanced

[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: Mon, 13 Nov 2017 21:16:30 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Thunderbird/56.0

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

I'm not sure I understand the "Zero means ..." passage, though.

That's your "total width" thing, for margin users that just want to
set the overall width of the margins without displaying anything
there.  Like Joost Kramer's visual-fill-column and similar packages.

OK, but why "maximum width"? workroom-mode wanted to set the total width, but if we want to describe what will happen with the column in question, the value sounds more like "minimum total width".

In addition to signifying a neutral position, does it supposed to switch
the meaning of this function into something that
set-right-margin/set-left-margin can call, for backward compatibility?

Yes, set-window-margins will most probably be reimplemented by calling
the above.

Which area will the left-margin specs be drawn on, then? Ones without any particular symbol specified.

Seems like a wart, using ORDINAL this way. And what's going to happen
when somebody else calls window-margin-add with non-zero ORDINAL? Will
the end result depend on which call happens first?

Yes.  And the result is returned, so the caller knows that.  If you
have better ideas for requesting a particular position in the margin,
let's hear them.

Having ORDINAL to be a number is totally fine to me.

Having ORDINAL = 0 mean something else, not so great. Especially if the result is to have the padding in this column, necessary to reach the specified total width.

I imagine workroom-mode might have a idea where they want the padding to end up (to the left or to the right of all columns). So instead of co-opting the ORDINAL argument to mean "cols will total cols"

Here's an interesting question: after such an API is added, will it be
feasible to re-implement display-line-numbers-mode using a margin
column, instead of the special separate area?

Yes.  But using margins from Emacs internals means that the
window-parameters which hold the column specs will change behind the
back of the Lisp applications, which I'm not sure is a Good Thing.

I was thinking more along the lines of being able to specify a spec-returning function (that uses the current buffer position), instead of only using the text properties. But changing the margins directly sounds faster.

Maybe not an entirely good thing, but certainly an improvement for the authors of third-party code.

It will also be somewhat slower.

We should probably measure before discarding this idea.





reply via email to

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