emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Variable-width font alignment


From: Eli Zaretskii
Subject: Re: Variable-width font alignment
Date: Sat, 10 Mar 2018 10:56:50 +0200

> 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.

> 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))'.  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.  Which will take us down the path of font-lock and JIT lock,
something that I'd like to avoid.  We could also record that in a
separate file, but I'm not sure such meta-data approach will be
acceptable.

Another idea would be to modify align-areas such that it attempts to
find an align-column that will align given text without changing the
width of space and tab, by looking for some kind of LCD for the widths
of the text strings involved in this.  Not sure if this is workable,
though.



reply via email to

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