On 18 January 2013 09:20, Thomas Martitz thomas.martitz@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@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:
- go to the same indent as last line
- indent and unindent on { and }
- 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.
Cheers Lex
Best regards.
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users