Re: Variable-width font alignment

[Stephen Leake]

Eli Zaretskii <address@hidden> writes:

>> From: Stephen Leake <address@hidden>
>> Date: Sat, 10 Mar 2018 02:12:57 -0600
>> 
>>             Trace                    => Verbosity > 1,
>>             Put_Parse_Table          => Verbosity > 0,
>>             Ignore_Unused_Tokens     => Verbosity > 1,
>>             Ignore_Unknown_Conflicts => Verbosity > 1);
>> 
>> It seems to me that implementing this in a variable width font requires some
>> sort of align-region-local tab setting, which is a change to current align
>> algorithms (which just insert spaces).
>
> Whatever we do to adapt indentation to variable-pitch fonts, we _must_
> still begin by inserting spaces so that the same text looks aligned
> with fixed-pitch fonts.  Otherwise, we will be unable to let other
> people view our code/documents in other editors which use fixed-pitch
> fonts, or even in Emacs with fixed-pitch fonts.
>
> The features that align text when variable-pitch fonts are in use must
> work _on_top_ of the "basic" alignment that just uses spaces and tabs
> as we do today.

Right.

>> One step in align.el `align-areas' computes an `align-column'. In
>> variable-pitch-mode, we could convert that into a tab setting by
>> computing the pixel column of that character column in the line with the
>> least whitespace/longest text ("Ignore_Unknown_Conflicts =>" above).
>> 
>> I could try doing this. What is the best approach to implementing an
>> align-region-local tab setting?
>
> Any local change in whitespace width would need to use 'display' text
> properties, such as '(space :width (N))'.  

Ok; that doesn't need an explicit tab.

> The problem with that is that you cannot easily record this when you
> save the file, so these properties will have to be recomputed anew
> each time the file is visited. 

Right. For example, that happens now in info files; formatting is
applied to the links via text properties.

> Which will take us down the path of font-lock and JIT lock, something
> that I'd like to avoid. 

That's how align.el works now. We could modify it to only set the text
properties if the fixed-width spaces are correct, or when in a read-only
buffer, or in variable-pitch-mode.

On the other hand, the ada-mode currently in GELPA computes indentation
and faces from a parse of the source text. It works very well, as long
as the source is syntactically correct. I'm working on implementing
error recovery in the parser; it works fairly well at the moment, and
I'm still improving it.

It should be possible to compute alignments from the parse as well; that
would elminate some of the minor bugs in current ada-mode alignment. That
would still require a parse when visiting the file.

> We could also record that in a separate file, but I'm not sure such
> meta-data approach will be acceptable.

Computing the align properties from the source has to be fast enough to
be acceptable while editing (as align.el is now), so it will be
acceptable on visiting.

-- 
-- Stephe