[Github-comments] [geany/geany] Summary of splitting the project file into project and project session (Issue #3022)

[elextr]

There are several issues and PRs relating to the topic and its hard to follow them all and to ensure they gel.  Having one persons use-case cut off another persons use case is rude and should not be allowed without consideration.  So I have made this summary issue to thrash out the best solution giving everyone their use-case.  Or if that not possible then least objectionable solution.

PLEASE DO NOT JUMP IN WITH YOUR SOLUTIONS UNTIL WE HAVE ALL THE USE_CASES RECORDED.

I will delete posts by anyone who jumps in with solutions before everyone is allowed to have their use-cases recorded, as your mother told you, don't talk over other people it makes the conversation hard to follow [end threat].

Lets start with the current implementation, why have "projects" at all, what does the current implementation provide and what are the benefits (which should not be lost when new use-cases are added) and limitations (which can happily be lost :-):

0. Operate perfectly well without any idea of a project, its all just files
   - has the benefits
     - simplicity
     - `session.conf` is now separate from `geany.conf` so it can be added to `.gitignore`[^1]
1. Its origin is lost in the mists of time, but the basic use-case seems to be grouping what the user is doing for different things the user is working on concurrently so that they can keep them separate,
   - provided by -c using a different config directory per project, 
     - which has the benefits:
       - allows multiple projects open at once (because it allows running multiple Geanys separately),
       - allows any setting including things in filetype files and geany.css to be made project specific, 
     - and the limitations:
       - cannot switch projects without restarting Geany
       - cannot be saved to git(hub/lab) without exposing the session which is likely to change every edit
       - has no obvious encapsulation of what defines the project
   - provided by current project system
     - which has the benefits
       - allows switching between projects without restart
       - has the concept of the project being encapsulated in a directory
       - all settings in one file which can be located in the project directory or outside it where it can avoid being git(hub/lab)ed
     - and the limitations
       - only one project open at once
       - very few settings can be project specific
       - cannot be saved to git(hub/lab) without issues[^1]
     - the two methods are orthogonal and do not necessarily play well together
2. Additional "project" related features in plugins (that I know about, please post others or correction of my understanding)
   - project_organiser, extends Geany projects to
     - allow adding additional trees to the encapsulation
     - automated tag generation for files in the encapsulated project making autocomplete, goto declaration/definition etc work for files not open
     - header/source swap within the encapsulated project
   - geanyprj, separate from Geany projects, has its own config files
     - similar to above AFAICT
   - workbench
     - provides file lists and project tree manipulation for several Geany projects at once
     - unsure what else

That is really quite a lot of use-cases covered!! :smile:  

Often we tend to concentrate on the negatives/missing parts and don't see how much Geany actually has.  That risks cutting off existing capability with hastily made changes.

AFAICT the additional use-cases espoused (not always clearly) in various issues, PRs, ML, and discussions on the now defunct IRC are listed below, since many have been suggested several times I have not attributed any.

1. being able to move a whole project (outside Geany) in its current state without editing settings on arrival, examples:
   - move a project between different locations on the same machine
   - being able to move between different but similar machines (eg desktop and laptop, they are likely file system layout, and GUI size and layout compatible)
   - developing code on a large Linux machine then moving it to a Raspberry Pi for testing, (eg similar file system layout but different GUI size and layout requirements)
   - developing code on a Linux machine and moving it to a Windows/OSX machine for testing (or any other permutation) (eg likely different file system layout)
2. being able to save project settings in git(hub/lab) without[^1] and in addition allow being able to make project settings read-only to avoid accidental modification of settings the project (in the sense of the Geany project) wants to have specific, eg indentation style or long line position.
3. allowing many more settings to be project specific:
   -  by adding selected config capabilities to projects, eg more settings and more filetype settings other than build commands
   - or adding optional project capabilities to configs, eg the encapsulation concept

[^1]: problems with saving current config session or project files in git(hub/lab) are:
      - noise because session file and the project file are written often to keep the session current
      - information leakage, for example a session file containing something like "/home/me/my_secret_evil_project/taking_over_the_world.txt"

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3022
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.geany.org/pipermail/github-comments/attachments/20211126/9b7af7da/attachment.htm>