[Geany-devel] Proposal: Project settings split - adding geany features

[Lex Trotman]

[...]
> First, I'd like to address these points, but I have actually thought of an
> alternative proposal which hopefully you might like and has much less impact
> on code. I'll start a new thread.

Ok, all specific points transferred to that thread.

Just one note that the point of raising it in the ML before doing it
was to see if anyone had better ideas for a solution.  Geany needs
more of that, as exhausting as it may be, rather than taking the first
suggestion or patch or pre-implemented pull request.  So thanks to
Nick and all who contributed.

>
> The point of arguing this out isn't especially for this feature, but for
> considering adding other features too.

Yes, its worthwhile discussing, but points like making the code
overcomplicated etc need to be discussed in terms of a specifc
implementation, as generalities they are meaningless (see below for
more rant :).

>
> My points are not just dev issues - users may want to backup their project
> file, which would be harder.

I don't understand how it would be harder, but anyway thats a specific.

> Users need to read the manual, which would take
> longer to understand.

Again this is a specific, but I don't understand how having session
info in a session file and project info in a project file is harder to
understand, or that most users would even need to care.

> Users might have to use buggier software, as more
> complex code is always more bug prone. Development issues become user issues
> indirectly.

Complicated isn't an absolute, it very much depends on experience,
something you think is blindingly obvious I may find horrendously
complex because I've never thought of that paradigm before.  I agree
that if the implementer considers it simple it is more likely to be
right, but that doesn't guarantee that all maintainers will easily get
their heads around it.

As an example Geany has many places where a short function then calls
another short function which calls another short function, none of
which are re-used.  Personally I find this way of writing code less
efficient and very hard to follow and understand as a whole, but
others find it easier to think only in terms of each little piece.
YMMV

[...]

> No, and also I'm not maintainer any more. But we do need to consider whether
> adding features is worth the maintenance and possible disruption.

They should always be considered, I just disagree with you (what,
never! :) and what I saw as overly general comments, ie "motherhood
and apple pie".

[...]

Cheers
Lex