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

Jiří Techet techet at xxxxx
Wed Sep 22 11:47:09 UTC 2010


On Sat, Sep 18, 2010 at 01:48, Lex Trotman <elextr at gmail.com> wrote:
> On 18 September 2010 02:00, Jiří Techet <techet at gmail.com> wrote:
>> On Fri, Sep 17, 2010 at 11:23, Lex Trotman <elextr at gmail.com> wrote:
>>
>>>>> Yes, I read the instructions (rare I admit) and I copied these regexen.
>>>>>
>>>>> I'll see if I get time to look at it some more today or tomorrow.
>>>>>
>>>>> Note that unless you are going to add the regexes to all filetypes
>>>>> then Geany still needs to behave as it currently does when there is no
>>>>> filetype regex(es).
>>>>
>>>> Currently geany only indents languages with braces (C, C++, Java,
>>>> Perl, ...) and Python, so these are the only languages whose patterns
>>>> have to be set.
>>>
>>> No, the "basic" setting just indents the same as the previous line and
>>> AFAIK works in all languages including "none" so it needs to work with
>>> no regexes.
>>
>> But this should work with my patch as far as I can tell - if no regex
>> exists for the given language, it just uses the same indent as on the
>> previous line.
>>
>
> But only if none is not selected?
>
>>>
>>> The regexes should replace both "current chars" and "match braces"
>>> settings (I think).
>>
>> No, the regexes only decide "when" to indent and not "how much" to
>> indent. the "current chars" method just looks at the previous line and
>> indents the next line by +indent_size or -indent_size while the "match
>> braces" method aligns } so that it is in the same column like the
>> opening brace.
>>
>> (However, I'm just wondering whether the "current chars" method
>> couldn't be removed completely. The "match braces" falls back to
>> "current chars" when it cannot be used and "match braces" is superior
>> for languages with braces.
>
> Thats what I meant by "replace them both".  So +1 for this.
>
>  Also the documentation doesn't really tell
>> you the difference of these methods so the only way to realize what
>> they do is to look at the source code.)
>
> I thought the auto-indentation section of the manual said that?

You are right - next time I really have to look at the manual instead
of relying on my poor brain.

>
>>
>>>
>>> I think it is really best to set the patterns
>>>> per-langauge - there may be slight differences between C and Perl for
>>>> example.
>>>
>>> Agree, in fact I think one of the current problems is caused by a
>>> "fix" to accomodate a common Perl usage.
>>>
>>> But it should be no problem to copy the patterns to the
>>>> filetype settings files that go under /usr/local/share/geany.
>>>>
>>>> What I'd like to see and what I'm not sure about how to do it in a
>>>> nice way is the possibility to switch between different indent styles
>>>> for different projects/files. For instance I maintain a project that
>>>> uses the GNU indent style while geany uses the ANSI style. Suggestions
>>>> are welcome.
>>>
>>>
>>> Ditto, I've got C++ in both GNU and Stroustrup styles, and despite my
>>> best arguments I'm not allowed to run them through a prettifier  to
>>> make them all the same, and thats in ONE project :-(
>>>
>>> To handle multiple styles, I'd have an entry in the [settings] section
>>> with a list of styles and each set of settings in its own section
>>> [indent-xxx] where xxx is the style name.
>>>
>>> I'd recommend that method over having all the settings in the same
>>> section with each setting having the style name in its key, although
>>> thats the way I did it for build settings and it works and is OK for
>>> computers it is hard for humans and these are hand edited settings.
>>>
>>> The styles could be added as a second section to the document-> indent
>>> type-> submenu, that would remove any need to add another top level
>>> menu entry.
>>
>> Yes, at least something like that. But I'd also like to be able to set
>> the indent style as a default style for a project (or globally) so I
>> don't have to manually set it for every file I open. This is a
>> per-filetype settings but having the option to set it for every file
>> type in the project settings dialog would make it a bit bloated.
>
> Welcome to the per project per filetype build command configuration
> problem :-D

Exactly what I want to avoid ;-).

>
> The build system solution of using the current file to select the
> filetype is, as you have pointed out in the past, potentially
> confusing, but the alternative is very bloating, especially since with
> custom filetypes you have to be able to handle an unknown number of
> filetypes.
>
> So I'd have to say that, for now anyway, the way to go would be for
> the combo box in the project and global prefs dialogs to show only the
> styles from the current filetype (plus none and basic) and to only set
> the current filetype.

If it's for the current filetype only, then I would just copy the most
confusing part of the per-filetype settings - I definitely don't want
to do it this way.

>
>
>  Maybe
>> some standard indent styles could exist so e.g. if you select "GNU
>> style" in the project settings dialog, geany would search for
>> [indent-gnu_style] section in the filetype settings file for each file
>> you are using in your project.
>
> Except for files where you have set it manually of course.
>
> Well gnu-style is meaningless for Python, and I wouldn't expect C to
> have a Stroustrup style etc. so the fixed list for all filetypes is
> always going to be insufficient.

OK, another idea. There would be a global and per-project "preferred
indent style" option containing the standard styles. Every filetype
would have its own default style and arbitrary number of additional
styles. If one of the styles matches the "preferred indent style",
this style will be used. Otherwise the default style will be used. So
for python, which has basically one style only, this single style will
be always used no matter what the preferred style is.

Finally, the document menu would have a submenu with all indent styles
for the document's filetype. This is IMO the only place which you
expect to be per-filetype.

Cheers,

Jiri

>
> Cheers
> Lex
>>
>> Cheers,
>>
>> Jiri
>>
>>>
>>> Maybe a later extension would be to save the style with the filename
>>> in sessions and/or recognise some mode line in the file eg Emacs type
>>> // -*- variable:value -*- settings.  There are several other things
>>> that have been suggested to be recognised like that (eg .h header
>>> files C or C++??).
>>>
>>> Cheers
>>> Lex
>>>
>>>>
>>>> Cheers,
>>>>
>>>> Jiri
>>>>
>>>>>
>>>>> Cheers
>>>>> Lex
>>>>>
>>>>>>
>>>> _______________________________________________
>>>> Geany-devel mailing list
>>>> Geany-devel at uvena.de
>>>> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>>>>
>>> _______________________________________________
>>> Geany-devel mailing list
>>> Geany-devel at uvena.de
>>> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>>>
>> _______________________________________________
>> Geany-devel mailing list
>> Geany-devel at uvena.de
>> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>>
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>



More information about the Devel mailing list