[Geany-Users] Ruby indent not working

Lex Trotman elextr at gmail.com
Thu Jan 17 23:56:53 UTC 2013

On 18 January 2013 09:20, Thomas Martitz
<thomas.martitz at student.htw-berlin.de> wrote:
> Am 17.01.2013 23:00, schrieb Colomban Wendling:
>> Le 17/01/2013 22:00, Thomas Martitz a écrit :
>>> Am 17.01.2013 21:28, schrieb Lex Trotman:
>>>> On 17 January 2013 23:02, Sayth Renshaw <flebber.crue at gmail.com> wrote:
>>>>> Hi
>>>>> [...]
>>>>> Not sure if I have missed something Ruby specific
>>>> Hi,
>>>> Well, sort of, or rather Geany has missed something, Ruby specific
>>>> support for indenting :)
>>>> Geany autoindent is almost language independent, it knows how to:
>>>> 1. go to the same indent as last line
>>>> 2. indent and unindent on { and }
>>>> 3. as a special case only, indent on : in Python
>>>> None of these will work for Ruby IIUC.
>>>> What it needs is for someone to specify the algorithm, and to provide
>>>> a plugin that implements it (such language specific stuff shouldn't be
>>>> in core)
>>> I disagree.
>>> This is something that ought to be in the core, really. Language support
>>> is a core feature of Geany (and any IDE). It should work out of the box
>>> and not reside in disabled-by-default extensions. Especially if python
>>> can have its special case in the core.
>> Nope, I don't think so.  Actually I wish we support (someday) "filetype
>> plugins", e.g. a plugin that provides highlighting, tag parsing and any
>> other kind of useful language-specific features.  Maybe those plugins
>> should indeed be automagically loaded when opening a file using that
>> plugin's language, but it'd be great if the features where in a separate
>> entity.
>> Why?  Well, there are many reasons:
>> * It would use less resources: even though each filetype would probably
>> use more resources because of the plugin and loading thingie, nobody
>> uses 100 languages at the same time, nor in the same Geany run.
> If everything is phased out to plugins it can become a threat to Geany's
> main goal: Be fast & lightweight. It threatens "fast" calling into a shared
> library has a performance overhead,

Hi Thomas,

Since we load all plugin dlls with immediate binding to avoid
segfaults afterwards there is only the cost of one indirection to call
anything in the dll.  Thats not really significant.

> and for some things that overhead can
> become measurable or even noticeable (tag parsing or syntax highlighting are
> possible candidates). And it threatens lightweight, because the installation
> size grows significantly. Also, the .so files might be so large (just
> because they are .so files) that even loading a few uses more RAM than
> statically linking the code for all file types.

That rather depends on the sizes of the plugins, the one Matthew is
tinkering with off and on includes all of the Clang C/C++ parser in it

> Reducing RAM usage _only_ is not the holy grail, especially in times were
> RAM is cheap and multi-gigabyte RAM setups are the standard.
> Besides, IMO some langauge related stuff should be in the core because it's
> the most reliable way to provide a consistent experience across filetypes
> (though still not 100% reliable as we see in this bug report).

Unfortunately it tends to become a way of providing an acceptable
experience for some filetypes and a poor experience for others that
don't match the "norm".

> Furthermore, IMO, plugins should extend Geany's functionality. I would not
> consider enabling Ruby indentation as an extension, but rather a bug fix for
> something that should have worked out of the box since the beginning. In
> fact, it seems strange to invent a new plugin just for the purpose of fixing
> a bug in the core.

There is not and never has been any guarantee that indentation worked
for any specific language except Python where someone (before my time)
put it in core.  Understandable since indentation is *critical* to
python code.

> FWIW, could filetypes.conf provide block delimiters (similar to comment
> characters)? This would allow to remove the special cases itself out of the
> core code while still having the actual indentation code in the core.

See the discussion with Colomban on IRC, many languages don't use
"block delimiters" in the sense that say C does, often its the
language keywords, "if", "else" etc that trigger indentation, not
simply a begin/end pair and unindentations can be even more complex.


> Best regards.
> _______________________________________________
> Users mailing list
> Users at lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/users

More information about the Users mailing list