GNU bug report logs - #29279
Sharing the margins

Previous Next

Full log

Message #29 received at 29279 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 29279 <at> debbugs.gnu.org
Subject: Re: bug#29279: Sharing the margins
Date: Mon, 13 Nov 2017 21:16:30 +0200

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.