[Geany-Devel] A direction for Geany

[Colomban Wendling]

Le 11/11/2013 08:18, Lex Trotman a écrit :
> Hi All,
> 
> [...]
> 
> 1. An architecture that allows multi-threading to be used for non-GUI
> tasks.  The most obvious of course is parsing.  At the moment none of
> the parsers support symbols in anything other than the global scope, and
> adding them would significantly increase the parsing effort, but doing
> it in a background thread would make the performance hit less obvious.
>  But there needs to be a careful design of the passing of data from the
> edit buffer to the parser and back to the symbol tables to minimise
> overhead, latency and ensure its non blocking.  With such an
> architecture other complex functionality can then also happen in the
> background without impacting Geany's responsive feel.

Multithreading is a good thing, and we should indeed consider using it,
and how and what could benefit from it.

But as a direct answer to the explanation, and after having made an
attempt at moving tag parsing to a separate thread, it's *really* not
that simple.

Actually, running the parsers in their own thread is quite easy.  This
requires copying the whole buffer, yes, but unless you lock the buffer
(which at best would prevent editing during the operation, at worse
freeze the UI), you basically have to make a copy.  And this isn't so
slow anyway.

But then you'll see that actually the parsers weren't the slow part, or
at least not as dominating as you might have though.  What I found was
terribly slow was maintaining the workspace tag array -- and this is
harder to move to another thread (though doable by copying it), because
again locking is complex.

I'm not saying it shouldn't be MT'd, but that one shouldn't be naive
about it (like I was): it basically requires a redesign of the Tagmanager.

> 2. Language specific assistance, such as indentation, or dynamic error
> marking and intelligent autocompletes.  I consider that these hang off
> the previous capability of better parsing/analysis of the program.
>  Matthew has demonstrated a prototype that provides some of these
> facilities using libclang (for the clang languages only C, C++, Obj-c).
>  But the current Geany architecture does not support plugging such
> things in easily, and with the number of languages that Geany supports,
> I would suggest that its small, light and fast tag would be severely
> threatened if assistance for all languages were plugged in at once.

Possibility for a plugin to more tightly integrate with completion,
calltips and alike is one important thing if we want to get better
language-specific support.  And I think we do.  Also allowing a plugin
to add a new language (with parser, lexer, etc), would be great.

After, whether loading filetype plugins on-demand or not, I'm not so
sure; plugins aren't so slow, and users could enable/disable the one
they don't use.  Auto-loading would probably be nice, but I'm not 100%
sure it's worth the additional complexity and separation from "regular"
plugins.  To be considered though.

> 3. Proper portability.  At the moment Geany is really a Linux
> application that has some limited (and buggy) support for Windows.  The
> main editing widget that Geany uses is available for many platforms and
> toolkits.  If Geany had an architecture that separated the target
> specific parts into a "backend" the way Scintilla does, then it would be
> possible to support multiple targets more easily, making Geany less at
> the mercy of one toolkit's direction (that means you deprecating GTK)
> and better able to support different platforms like OSX and Windows.
>  Work such as that Dimitar is doing for spawning on Windows naturally
> then falls into such a backend.

Matthew summed up pretty well IMO.  Although it looks like a good idea,
I don't think it's a fit for Geany.  And also, I believe that the UI
toolkit should do that, but I guess none actually do as good as one
could want.

> 4. Multiple top level windows.  As monitors are cheaper, being able to
> spread views of files to optimally utilise the screen space available
> adds to the users effectiveness.  Most languages support multiple
> modules in different files and many use multiple files for related
> parts, such as C/C++ header and body.  Looking at and editing several
> places/files at once has many uses.  As useful as splitwindows one and
> two are (especially together) they still assume a single rectangular top
> level is available for subdivision.  But different desktop menu layouts
> or having other applications visible at the same time can limit the
> contiguous rectangular space available.  Multiple top levels can make
> better use of non-rectangular space.

We already can run multiple Geany instances (but yes I know, there are
side issues).  For me the multi-windows thing would be a direct
consequence of a proper "no tie between UI and document" thing -- that I
hope we'll get some not so far away day.  And maybe splitwindow2 helps
at that (sorry, I still didn't manage to properly review this).

> These are all big changes that don't fall into the current Geany mode of
> "light maintenance and extra features as someone implements them".  For
> big changes like those above however, a clear design and a planned
> process is needed to ensure that the big changes don't clash with each
> other and that they are not derailed by interim smaller changes.
> 
> I would suggest the process to be:
> 
> 1. gather other major ideas for capabilities that Geany should plan to
> support
> 2. develop a design that supports these (or at least the most useful ones)
> 3. look at how that design can be implemented, can the existing design
> be mutated to it, or is it a clean framework that large parts of the
> existing functionality can plug into, or is it a whole clean
> implementation.  This also includes issues like languages to use (C,
> C++, Vala, Haskell etc).
> 4. depending on the outcome from 3. use a new repository organisation or
> at least a new branch in the existing Geany repo to ensure that the
> existing Geany is not destabilised by major changes as they take place.

New branch is necessary -- in a separate repo or not.  New repository
without a new branch basically means a fork, and I guess Geany can't
really afford that :)

> This is something very different to the way Geany is currently
> operating, and I don't know if the community wants to consider such a
> more structured approach.  If its felt that its worthwhile then I
> suggest that steps one and two are best achieved using the wiki and I
> will volunteer to set up and maintain page(s) for those phases at least.

I'm not sure how such a structured approach could work given the
manpower and free-time-porject aspect of Geany [1], but it surely is a
good idea to at the very lest try something and try to make it work.
Thanks a lot for that BTW.


Regards,
Colomban


[1] Though, one could hope that structured goals could attract more
contributors, since they'd have something concrete they could help build
-- as opposed to the usual "pick something you care about", it'd be
"there's some things to do, help if you care to".