bug#74178: Handle tab stops on display so they work in variable-pitch-mode

[Eli Zaretskii]

> Date: Sat, 02 Nov 2024 19:06:54 +0100
> From: dannym@friendly-machines.com
> 
> Right now, when using variable-pitch-mode, there's no way for the user
> to make tables.  This patch adds a feature to do that.
> 
> This patch handles tab-stop-list in the display part of emacs so that
> they work as expected when using variable-pitch-mode.
> 
> The unit of the values in tab-stop-list is space characters.
> 
> The reasons why those values are in space characters are:
> 
> - Works with HiDPI and LoDPI screens the same way with the same values
> inside tab-stop-list.
> - Works in console emacs.
> - Works in graphical emacs.
> - Is backward compatible.
> 
> My assumption is that existing user files either don't have any '\t'
> in their buffers or they are using the (previous) high-level version
> of emacs tab-stop-list (which will replace all '\t' by some spaces),
> not both.  This way, emacs without the patch is forward-compatible
> to emacs with the patch.
> 
> This is a version that will use tabs in the order they appear in the
> tab-stop-list, (on purpose) regardless of whether the text on the
> line already exceeded the respective tab stop position (because it's
> still better not to use the wrong column in the table).
> 
> Each respective tab stop, in order, will be used for a respective
> '\t', per line. If these fixed tab stops are used up, it will fall
> back to the automatic tab stops every tab_width that emacs also
> already had done before.
> 
> The list of tab stops is buffer-local--as before.

Thanks, but please tell how this feature is intended to be used.  In
particular, what would be the value of the new buffer-local variable,
and how will the tab stops of this value be determined by users or
Lisp programs who want to take advantage of this feature?

There are also some technical problems with the idea of your
implementation: for example, it sounds like the display iterator will
need to always start from the beginning of a physical line, otherwise
it will be unable to correctly account for the tab stops before the
position where it is initialized.  But let's ignore these aspects for
now and talk about the general idea, because it's possible that the
feature could be implemented in some other way that is free of these
problems.

P.S. There's also the issue of assigning to the FSF the copyright for
your work, without which we will be unable to accept a contribution of
this size.  Should I send you the form to fill and the instructions,
to start the legal paperwork rolling?