[Geany-devel] Indentation using regex (was [PATCH 14/19] Rewrite tab switching queue)

Lex Trotman elextr at xxxxx
Wed Dec 7 02:04:33 UTC 2011


On Wed, Dec 7, 2011 at 11:06 AM, Jiří Techet <techet at gmail.com> wrote:
> On Tue, Dec 6, 2011 at 21:56, Lex Trotman <elextr at gmail.com> wrote:
>> [...]
>>> Maybe I don't understand it correctly but does this mean that if you
>>> open an existing file, you'd re-indent it completely based on the
>>> regexes? I don't think this is a good idea because this could lead to
>>> whitespace change in every line when you edit just a single line.
>>>
>>
>> No, thats another reason why I rejected option 1
>>
>>> Or does it mean to have these indent numbers just internally and use
>>> them only when when auto-indentation is done? I often work with files
>>> edited by many people over many years which have inconsistent indents.
>>> Imagine the correct indent size is 4 but someone used just 2 indents
>>> in the outer "if" block. If I insert new "if" inside this block, the
>>> indent size will be 6 because of the incorrect outer indent. This is
>>> exactly why I used the "delta" indent solution to be locally correct
>>> and have minimal impact on (and be minimally affected by) the rest of
>>> the code.
>>
>> The algorithm will give 6 since it only considers the previous line
>> and the line it is indenting which is the line with the cursor.
>>
>>
>>>
>>> One more thing - with global indents you have to be sure that the
>>> regexes catch all the indentation cases (without false positives)
>>> otherwise one error will affect the indentation everywhere in the rest
>>> of the file. You can do crazy stuff with some languages so I can
>>> imagine such a thing can happen easily (single line with end of
>>> multi-line comment followed by end block followed by another comment).
>>> With delta indentation it's much less critical - the indent may be
>>> incorrect for the next line but this won't affect the rest of the file
>>> in any negative way. Moreover, you usually don't do things like the
>>> comment example when you write the code and when you need
>>> auto-indentation; you usually add them afterwards when no
>>> autoindentation is needed.
>>>
>>> Final remark - better not to auto-indent at all than to indent
>>> incorrectly. There's nothing worse than an editor (actually anything)
>>> which tries to be smart in an annoying way.
>>
>> Don't worry there is no intention that auto-indentation does more than
>> give a mostly right indent on new lines and mostly correct it when you
>> type } on that new line.
>>
>> I did clearly say it should not change any manual indentation.
>
> Ah, sorry, after re-reading it again I think I misunderstood your
> algorithm originally so please forget what I said.
>
> What you propose sounds good. Basically the main difference is that
> you take the previous line indentation into account which is what my
> original algorithm didn't do. This really appears to solve all the
> problems in quite an elegant way (much nicer than the flags thing I
> suggested). Just a detail that strictly speaking the "N-1 line" should
> be previous non-empty line.

In fact I also omitted to say that comments should be ignored as well,
which means it has to run after scintilla lexing is complete.

>
> I'm actually not completely against the immediate indent when typing
> (without having to press enter). Your algorithm is capable of
> indentation "undo" when the regex doesn't match any more. I think it's
> quite OK if "fi" unindents the line and subsequent letter returns it
> back. Something like that already happens with syntax highlighting
> where the keyword becomes blue when you type it but changes back to
> black when you add additional letters.

Yes, my only objection was having to run the regexes over two lines
for each character, but maybe some judicious caching of the results of
line N-1 and the start of line N can reduce the work required most of
the time.

Cheers
Lex

>
> Cheers,
> Jiri
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel



More information about the Devel mailing list