Stavros.Macrakis@crg.bull.fr (03/30/89)
My most common use of fill prefixes is for nested paragraphs with
hanging indentation, where the fill prefix consists simply of N
spaces. It would seem possible to arrange that filling recognised
this, so that I wouldn't need to do C-x . each time I moved to a
different indentation level.
My proposal: that instead of the fill prefix string, there be a fill
prefix regex. The length of string matched by the regex is the amount
of indentation (that is, the fill prefix is that many spaces). If the
regex doesn't match, then the fill prefix is the number of initial
spaces/tabs at the beginning of the line.
Suppose, for instance, that my fill prefix regex is
" *[0-9]+\(\.[0-9]*\) "
(that is, any number of spaces followed by a section number then two
spaces). We would then get the following auto-indent behavior:
2.3.3 This is the beginning of section 2.3.3. Wrap
around of lines continues here.
The two objections I can see to such a scheme are:
1. regex preprocessing and interpretation take too long;
2. non-space indentation isn't handled.
As for (1), I don't know if the time would be unacceptable. If so,
perhaps there ought to be some way to save preprocessed regexes (once
they're preprocessed, looking-at should be very rapid). This would be
useful for other applications as well.
For (2), I admit that I very rarely use non-space indentation, and
when I do, I probably don't need the auto-indentation feature. So I
should choose one or the other. There is one application I can see
for the two together: editing and reformatting "> "-prefix quotes in
mail. This could actually be handled by having a one-bit variable
which tells you whether to use the matched prefix itself as the fill
prefix, or instead that number of spaces.
What do you think?
-s