Re: Variable-width font indentation

[Herring, Davis]

>         match opt with
>         | []     -> []
>         | x :: t -> x :: f t
> 
> You'd want to scale the spaces according to the line *below*, not ebove,

As per your other message, that's a problem regardless of tab handling.  Yet 
more heuristics suggest themselves (in this case, looking for text shared 
between two adjacent lines to guide the alignment), but of course those are 
becoming a mess.

> and even then you'd have to account for the fact that 'x ' isn't as wide as 
> '[]'.

Maybe I misunderstand -- how is this a problem?  If the number of spaces is 
correct, it identifies the correct character to match against.

> Smart Tabs are also not very good for languages like ELisp with variable 
> indentation depths.

Which cases are hard?  I just see several places where you would use only 
spaces (_):

(progn
>-(foo)
>-(bar))

(and
_(foo)
_(bar))

(and (foo)
_____(bar))

> If anything, I think this is more of an argument in favor of
> elastic tabs (http://nickgravgaard.com/elastic-tabstops/).

Those are certainly interesting, but they have their own ambiguities (e.g.,

int>-x>-= 1,
>-y>-=2;
doTheFoo();>-// it's true
doTheBar();>-// so far

where there should not be a "column block" 4 lines tall).  They also of course 
do not play well with existing rendering (monospace or otherwise).

Davis