Hi, folks.
Dimitar Zhekov wrote:
Better for what? I use tabs for indentation because with the tab size, I can easily control the screen ammount of indentation, depending on the font and display. Saving disk space has nothing to do with that, I'll have to live very long to write 1GB of source code. :)
Likewise. I like tabs for indentation because 1 indent = 1 character, and everyone can have different ideas about how big that indent should be.
Lex Trotman wrote:
- There has been much discussion on the ML and several actual prototypes
of improved indentation/alignment schemes that are flexible enough to address many languages (even just many C style languages is a hard problem). None of them have been sufficiently correct, enough of the time, to overcome the problems of being really annoying when they are incorrect.
Yeah, I've seen a little of that discussion, and I'm not looking to solve it in 5 minutes :).
- But there is no way to tell Geany to not apply indentation per file, so
Geany will still do its thing independent of the plugin (and that includes moving } not just on enter).
Maybe what is needed is not a configuration file per language, but instead a code snippet per language? But I guess Geany would then have to rely on the presence of a dynamic language on the system, or else write it in C and have to rebuild from source to change it :s.
Splitting a line on user command is certainly an easier way to do it, I assume you mean last *unmatched* bracket on the line (that is not in a string or comment). Oh and don't forget C++ uses <> as brackets for templates, but don't confuse that with the places it uses them for gt and lt :)
Good point. I might actually ignore the angle bracket issue, unless it's really likely that people will have so many entries in a template that they'll want to split the line. Otherwise...I guess when it found a < it could search the rest of the line for a matching > and decide based on that.
Finally plugins should *not* bind keys by default, they have no way of knowing if the user has already bound that key to something else (and of course multiple plugins binding the same key :).
Oh, I know, I was just thinking aloud about which keybinding I might use.
Adding such analysis could be a big job but in my experience Emacs does produce a reasonable result.
Yeah, that looks too big for what I was thinking of, but thanks for pointing it out. I might use it as a reference.
Thomas Martitz wrote:
Bah, this "everything must be a plugin" really annoys me... What's wrong with you accepting new code in the core?
Actually, I agree that custom indentation schemes are too troublesome to include in core... unless someone, somehow, has a spark of genius allowing them to invent a perfect one-scheme-fits-all approach. This idea - particularly the Lua script - is far from that.
Am 17.07.2013 00:49, schrieb Thrawn:
Thomas Martitz wrote:
Bah, this "everything must be a plugin" really annoys me... What's wrong with you accepting new code in the core?
Actually, I agree that custom indentation schemes are too troublesome to include in core... unless someone, somehow, has a spark of genius allowing them to invent a perfect one-scheme-fits-all approach. This idea - particularly the Lua script - is far from that.
I didn't mean to suggest there is a one-scheme-fits-all solution. The core can totally have customizations to a generic algorithm (or even custom algorithms) on a per-language basis. What I question is the enforcement (I perceive it as such) to introduce all new functionality via (perhaps unreliable) plugins even if essential core features (indentation is clearly one of them) are concerned. There seems little, if any, consideration whether new stuff should go into the core or plugins. The plugin approach is the default and it seems hard to improve the core.
Plugins are nice, but still not ideal. The authors might not be dependable, the code quality can be bad, they are not automatically loaded (which is I guess the point of them, however it means that users cannot not be automatically exposed to new functionality) and there's non-zero overhead in both memory usage and performance. The first two obviously don't apply for plugins that ship with Geany.
Best regards.
On 17 July 2013 16:53, Thomas Martitz thomas.martitz@student.htw-berlin.dewrote:
Am 17.07.2013 00:49, schrieb Thrawn:
Thomas Martitz wrote:
Bah, this "everything must be a plugin" really annoys me... What's wrong with you accepting new code in the core?
Actually, I agree that custom indentation schemes are too troublesome to include in core... unless someone, somehow, has a spark of genius allowing them to invent a perfect one-scheme-fits-all approach. This idea - particularly the Lua script - is far from that.
I didn't mean to suggest there is a one-scheme-fits-all solution. The core can totally have customizations to a generic algorithm (or even custom algorithms) on a per-language basis. What I question is the enforcement (I perceive it as such) to introduce all new functionality via (perhaps unreliable) plugins even if essential core features (indentation is clearly one of them) are concerned. There seems little, if any, consideration whether new stuff should go into the core or plugins. The plugin approach is the default and it seems hard to improve the core.
Hi Thomas,
There are two questions:
1. Should a general solution to language specific indentation go in core, most definitely yes, when we know what that is !!!
So far such a solution has not been found, Colomban's regex prototype was closest but still had a high proportion of incorrect results leading to the conclusion that the approach was not capable enough. Implementing a bad approach in core and then having to try to fix/expand or replace it is just a waste of time.
So as I said trying out indentation schemes in plugins makes it easier to replace them (but the user can always still use the old one if they like it better, they can't do that with in-core code that has been removed). There is a PR that demonstrates that plugins can be autoloaded by filetypes, so each plugin only needs to do one language, making them simpler and easier to get right.
Then it will be possible to identify commonality that is suitable for implementing in core.
2. Should this particular function Thrawn is offering be in core? Since it is limited to one situation in one language (or group of {} languages) and he wants to implement it in Lua, no.
Plugins are nice, but still not ideal. The authors might not be dependable, the code quality can be bad, they are not automatically loaded (which is I guess the point of them, however it means that users cannot not be automatically exposed to new functionality) and there's non-zero overhead in both memory usage and performance. The first two obviously don't apply for plugins that ship with Geany.
Now that you mention it, there is probably no reason why we could not default enable some of the plugins shipped with geany, its just having the settings in the default config file. And possibly some more plugins could move to core (+1 for Enrico's Addons TODO for example :)
Note that it is probable that Geany core could provide some more support for plugin indentation, but as yet nobody is sure what that consists of.
Cheers Lex
Best regards.
______________________________**_________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-**bin/mailman/listinfo/develhttps://lists.geany.org/cgi-bin/mailman/listinfo/devel
I haven't been following all of the details of the whole conversation, but I just wanted to throw in my two cents:
I like how geany already keeps the indentation of the previous line and unindents with a single backspace independent of if the file is using tabs or spaces.
Any custom formatting-as-you-go I hope is only enable-able, perhaps that's why it would be best suited as a plugin. Weather that plugin is in the core plugins or geany-plugins doesn't matter to me. One of the reasons I like geany is because its editing consistently across the different languages. I don't particularly like tools that automatically fix indentation as I type on curly braces or whatever.
Also, most IDEs and editors can fit into two groups: full feature that can be stripped down, simple with enable-able features. I think of geany as the latter. I much prefer enabling plugins and features as I learn them or want them, rather than having more things pre-enabled as Lex suggests below.
Anyway, that's just my food for thought.
Thanks,
Steve
On 07/17/2013 02:01 AM, Lex Trotman wrote:
On 17 July 2013 16:53, Thomas Martitz <thomas.martitz@student.htw-berlin.de mailto:thomas.martitz@student.htw-berlin.de> wrote:
Am 17.07.2013 00:49, schrieb Thrawn: Thomas Martitz wrote: Bah, this "everything must be a plugin" really annoys me... What's wrong with you accepting new code in the core? Actually, I agree that custom indentation schemes are too troublesome to include in core... unless someone, somehow, has a spark of genius allowing them to invent a perfect one-scheme-fits-all approach. This idea - particularly the Lua script - is far from that. I didn't mean to suggest there is a one-scheme-fits-all solution. The core can totally have customizations to a generic algorithm (or even custom algorithms) on a per-language basis. What I question is the enforcement (I perceive it as such) to introduce all new functionality via (perhaps unreliable) plugins even if essential core features (indentation is clearly one of them) are concerned. There seems little, if any, consideration whether new stuff should go into the core or plugins. The plugin approach is the default and it seems hard to improve the core.Hi Thomas,
There are two questions:
- Should a general solution to language specific indentation go in
core, most definitely yes, when we know what that is !!!
So far such a solution has not been found, Colomban's regex prototype was closest but still had a high proportion of incorrect results leading to the conclusion that the approach was not capable enough. Implementing a bad approach in core and then having to try to fix/expand or replace it is just a waste of time.
So as I said trying out indentation schemes in plugins makes it easier to replace them (but the user can always still use the old one if they like it better, they can't do that with in-core code that has been removed). There is a PR that demonstrates that plugins can be autoloaded by filetypes, so each plugin only needs to do one language, making them simpler and easier to get right.
Then it will be possible to identify commonality that is suitable for implementing in core.
- Should this particular function Thrawn is offering be in core?
Since it is limited to one situation in one language (or group of {} languages) and he wants to implement it in Lua, no.
Plugins are nice, but still not ideal. The authors might not be dependable, the code quality can be bad, they are not automatically loaded (which is I guess the point of them, however it means that users cannot not be automatically exposed to new functionality) and there's non-zero overhead in both memory usage and performance. The first two obviously don't apply for plugins that ship with Geany.Now that you mention it, there is probably no reason why we could not default enable some of the plugins shipped with geany, its just having the settings in the default config file. And possibly some more plugins could move to core (+1 for Enrico's Addons TODO for example :)
Note that it is probable that Geany core could provide some more support for plugin indentation, but as yet nobody is sure what that consists of.
Cheers Lex
Best regards. _______________________________________________ Devel mailing list Devel@lists.geany.org <mailto:Devel@lists.geany.org> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel