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 01:51:53 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Thunderbird/56.0

This is a rough proposal on how separate bodies of code (minor modes, etc) can use the same margin without conflict.

Previous discussions:

http://lists.gnu.org/archive/html/emacs-devel/2015-11/msg01171.html
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27427#53

Primary goals:

- Allow multiple kinds of margin content to coexist (examples: http://lists.gnu.org/archive/html/emacs-devel/2015-11/msg01505.html). - Continue to use the text properties to set the contents of the margins (as opposed to having a line number based API, which seems to come with its own difficulties).

Outline:

We introduce two new variables, named like left-margin-columns-alist.

Each element is a cons which specifies some properties of the element, for instance:

- Priority (so the columns are in the same order on each line)
- Minimum width (if we want that, as opposed to just adding strings with that length the contents of this margin column) - Minimum "total" width, which would allow to use this column as padding so that the combined width of the margin reaches a given number (hopefully solving the writeroom-mode problem). - Padding (whether to pad this column with a space on one side if there is a next column)
- Text alignment within the column (left or right)

The keys in left-margin-columns-alist will be used as alternatives to `left-margin' in margin display specs.

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 the latter is considered too difficult, we can add "width" as a necessary parameter to the column properties. I think that would rule out the possibility of efficiently using the margins for the line numbers feature, though, which seems unfortunate. But the other uses of the margin that I'm aware of are not as dynamic.

Similar feature can be added for the fringes, too (for them, dynamic sizing isn't needed at all, probably).

Comments?





reply via email to

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