Hi, I've noticed various issues with file loading from command line: 1) if the option load last session is not enabled project files can't be opened from command line: this happens because the code to handle them is wrapped in a prefs.load_lastsession if so the only way to load them from command line is having that option true. 2) trying to open a file (eg from double clicking in nautilus) will screw your session as command line loading of single files ignores your session opened files, except if geany was already opened.
So to fix those issues I've reorganized the code in the load_startup_file function in order to: 1) load the project files ignoring the session if a project file was specified at command line 2) allow to load more files in addition to the project file (removing so the limitation imposed there artificially - possible improvement to this would be adding a flag to open_cl_files as argument in order to avoid that pointer toying) 3) the open_cl_files is called after loading the session so the specifically selected files are opened last and so are automatically selected (what you would expect when opening a file from nautilus) 4) if the option to load last session is not enabled and there isn't a project file being loaded from command line and a project is not being loaded we just try to load files from command line if any
Stefano Angeleri
On Thu, 27 Jan 2011 10:20:26 +0100 weltall weltall2@gmail.com wrote:
I've noticed various issues with file loading from command line:
- if the option load last session is not enabled project files can't be
opened from command line: this happens because the code to handle them is wrapped in a prefs.load_lastsession if so the only way to load them from command line is having that option true.
Certainly a bug.
- trying to open a file (eg from double clicking in nautilus) will
screw your session as command line loading of single files ignores your session opened files, except if geany was already opened.
SciTE will do the same, and so will UltraEdit (the very old versions I used). If you want a permanent session, create a project.
So to fix those issues I've reorganized the code in the load_startup_file function in order to:
- load the project files ignoring the session if a project file was
specified at command line 2) allow to load more files in addition to the project file (removing so the limitation imposed there artificially - possible improvement to this would be adding a flag to open_cl_files as argument in order to avoid
Actually, the check if argv[1] is .geany is mainly for the file managers. You associate geany with the text files, and since .geany is text too, it automatically works. About the limitation of loading only the project file, I'm not sure, but loading a project and opening additional files at the same time does not seem very common.
that pointer toying) 3) the open_cl_files is called after loading the session so the specifically selected files are opened last and so are automatically selected (what you would expect when opening a file from nautilus)
Personally I'd expect to open only the file I clicked, be it in existing or new instance. And this change breaks the secondary instances, since you load the cl files after the check for new_instance.
- if the option to load last session is not enabled and there isn't a
project file being loaded from command line and a project is not being loaded we just try to load files from command line if any
On 28 January 2011 06:09, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Thu, 27 Jan 2011 10:20:26 +0100 weltall weltall2@gmail.com wrote:
I've noticed various issues with file loading from command line:
- if the option load last session is not enabled project files can't be
opened from command line: this happens because the code to handle them is wrapped in a prefs.load_lastsession if so the only way to load them from command line is having that option true.
Certainly a bug.
Yes, but the patch never loads the project session from a project on the command line since main_load_project_from_command_line is only ever called with FALSE?
- trying to open a file (eg from double clicking in nautilus) will
screw your session as command line loading of single files ignores your session opened files, except if geany was already opened.
SciTE will do the same, and so will UltraEdit (the very old versions I used). If you want a permanent session, create a project.
Need to support multiple default sessions. Too complicated??
So to fix those issues I've reorganized the code in the load_startup_file function in order to:
- load the project files ignoring the session if a project file was
specified at command line 2) allow to load more files in addition to the project file (removing so the limitation imposed there artificially - possible improvement to this would be adding a flag to open_cl_files as argument in order to avoid
Actually, the check if argv[1] is .geany is mainly for the file managers. You associate geany with the text files, and since .geany is text too, it automatically works. About the limitation of loading only the project file, I'm not sure, but loading a project and opening additional files at the same time does not seem very common.
Agree, need to be careful since the extra files will be added to the project session which is unlikely to be what you want??
that pointer toying) 3) the open_cl_files is called after loading the session so the specifically selected files are opened last and so are automatically selected (what you would expect when opening a file from nautilus)
Personally I'd expect to open only the file I clicked, be it in existing or new instance. And this change breaks the secondary instances, since you load the cl files after the check for new_instance.
- if the option to load last session is not enabled and there isn't a
project file being loaded from command line and a project is not being loaded we just try to load files from command line if any
-- E-gards: Jimmy
Cheers Lex
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Well the reasoning of that is because a lot of times I end up with having to kill geany (kill -9 or xkill) in order to not lose all the opened files listing due to a click, so really a project is not always the right way in this case (even more if the files come from several projects in practice) Il giorno ven, 28/01/2011 alle 10.29 +1100, Lex Trotman ha scritto:
On 28 January 2011 06:09, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Thu, 27 Jan 2011 10:20:26 +0100 weltall weltall2@gmail.com wrote:
I've noticed various issues with file loading from command line:
- if the option load last session is not enabled project files can't be
opened from command line: this happens because the code to handle them is wrapped in a prefs.load_lastsession if so the only way to load them from command line is having that option true.
Certainly a bug.
Yes, but the patch never loads the project session from a project on the command line since main_load_project_from_command_line is only ever called with FALSE?
yes it seems to not, like before, but before it didn't load project files at all without the flag to load the previous sessions set to true due to the fact the whole code was ifed out with the load session setting
- trying to open a file (eg from double clicking in nautilus) will
screw your session as command line loading of single files ignores your session opened files, except if geany was already opened.
SciTE will do the same, and so will UltraEdit (the very old versions I used). If you want a permanent session, create a project.
Need to support multiple default sessions. Too complicated??
Yeah that could be a solution even though It could be nice to maintain a certain level of coherency between already opened and not.
So to fix those issues I've reorganized the code in the load_startup_file function in order to:
- load the project files ignoring the session if a project file was
specified at command line 2) allow to load more files in addition to the project file (removing so the limitation imposed there artificially - possible improvement to this would be adding a flag to open_cl_files as argument in order to avoid
Actually, the check if argv[1] is .geany is mainly for the file managers. You associate geany with the text files, and since .geany is text too, it automatically works. About the limitation of loading only the project file, I'm not sure, but loading a project and opening additional files at the same time does not seem very common.
Agree, need to be careful since the extra files will be added to the project session which is unlikely to be what you want??
well that could be a thought... but from my tests loading a file while geany is already running (from nautilus for example) will add that file to the project so the behaviour is consistent at least.
that pointer toying) 3) the open_cl_files is called after loading the session so the specifically selected files are opened last and so are automatically selected (what you would expect when opening a file from nautilus)
Personally I'd expect to open only the file I clicked, be it in existing or new instance. And this change breaks the secondary instances, since you load the cl files after the check for new_instance.
- if the option to load last session is not enabled and there isn't a
project file being loaded from command line and a project is not being loaded we just try to load files from command line if any
-- E-gards: Jimmy
Cheers Lex
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
anyway I've expanded the patch to add an option to choose if the previous behaviour (minus the bug) is wished or not. bye Stefano Angeleri
On Fri, 28 Jan 2011 01:15:25 +0100 weltall weltall2@gmail.com wrote:
Yes, but the patch never loads the project session from a project on the command line since main_load_project_from_command_line is only ever called with FALSE?
yes it seems to not
It does, see my reply to Lex.
before it didn't load project files at all without the flag to load the previous sessions set to true due to the fact the whole code was if-ed out with the load session setting
To be precise, with prefs.load_session = false it does not load the project at all, that's why it is a bug.
I'm not sure if the correct behaviour with false should be to load the project only, like --no-session, or the project and it's session files, like Project -> Open. But not loading the project is wrong.
On Fri, 28 Jan 2011 10:29:22 +1100 Lex Trotman elextr@gmail.com wrote:
Yes, but the patch never loads the project session from a project on the command line since main_load_project_from_command_line is only ever called with FALSE?
Of course it loads them.
TRUE -> project_load_file_with_session() -> project_load_file() + configuration_open_files() FALSE -> project_load_file() only
Since load_startup_files() calls configuration_open_files() after loading the default or project session file names, TRUE is not required. The TRUE is for opening a project via socket.
- trying to open a file (eg from double clicking in nautilus) will
screw your session as command line loading of single files ignores your session opened files, except if geany was already opened.
SciTE will do the same, and so will UltraEdit (the very old versions I used). If you want a permanent session, create a project.
Need to support multiple default sessions. Too complicated??
Now let's give these default sessions names, to be able to identify them, and files to be saved, of course, and a distinctive filename suffix, for example ".geany", and we end up with projects.
You can create as many projects as you want to save file lists only, not related to any software (or other) projects. Name them "Default Session 1", "Default Session 2" etc. and that's it.
On 29 January 2011 04:24, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Fri, 28 Jan 2011 10:29:22 +1100 Lex Trotman elextr@gmail.com wrote:
Yes, but the patch never loads the project session from a project on the command line since main_load_project_from_command_line is only ever called with FALSE?
Of course it loads them.
TRUE -> project_load_file_with_session() -> project_load_file() + configuration_open_files() FALSE -> project_load_file() only
Since load_startup_files() calls configuration_open_files() after loading the default or project session file names, TRUE is not required. The TRUE is for opening a project via socket.
Hmmm straightforward (not)...
- trying to open a file (eg from double clicking in nautilus) will
screw your session as command line loading of single files ignores your session opened files, except if geany was already opened.
SciTE will do the same, and so will UltraEdit (the very old versions I used). If you want a permanent session, create a project.
Need to support multiple default sessions. Too complicated??
Now let's give these default sessions names, to be able to identify them, and files to be saved, of course, and a distinctive filename suffix, for example ".geany", and we end up with projects.
You can create as many projects as you want to save file lists only, not related to any software (or other) projects. Name them "Default Session 1", "Default Session 2" etc. and that's it.
I meant multiple sessions open at once so that files don't automatically add to the session (project) you have open.
For instance having to close the work project (session) I have open to open Geany files to try (and fail) to trace project load patterns in a patch.
And IMHO the session stuff needs to be separated from the project stuff since the session is per user but things like build commands and indents go with the source tree.
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Le 27/01/2011 20:09, Dimitar Zhekov a écrit :
On Thu, 27 Jan 2011 10:20:26 +0100 weltall weltall2@gmail.com wrote:
- trying to open a file (eg from double clicking in nautilus) will
screw your session as command line loading of single files ignores your session opened files, except if geany was already opened.
SciTE will do the same, and so will UltraEdit (the very old versions I used). If you want a permanent session, create a project.
I don't think so. First, it is an inconsistent behavior: ATM, opening a file with e.g. `geany myfile` will NOT result on the same state depending on whether Geany is already opened or not. If Geany is already running, the file will be appended to the session, but if Geany wasn't running, the session not only don't load, but will be lost (since a new one is saved on quit).
Second, I feel this rather annoying. Why have a session support at all if the session might be lost so easily, only by a "miss of attention"? (forget that Geany isn't running when opening a file) I had often lost some of my sessions because of this, and felt it quite annoying -- though since I generally always have Geany open, it's not *that* often.
I personally use projects for the projects I work on a lot, and for which I want almost all its files opened, and the default session for everything else. Say, a standalone file to edit, a file part of a source tree I don't work on enough to have a project file for it, etc. This does NOT mean that my session is something I don't care to loose. Sometime I just want to be able to re-open Geany as it was the last time, perhaps because the work is not finished yet but I have to close my session. And I feel very annoying if I need to open a file later and figure out after opening it that Geany was not running, and so that I've lost all my old work space.
And anyway, why use the session if you don't care about the opened files?
I haven't tested the patch yet, but the raised problem is a real concern IMHO. Well, it concerns me :)
Regards, Colomban
On Fri, 28 Jan 2011 03:01:06 +0100 Colomban Wendling lists.ban@herbesfolles.org wrote:
- trying to open a file (eg from double clicking in nautilus) will
screw your session as command line loading of single files ignores your session opened files, except if geany was already opened.
SciTE will do the same, and so will UltraEdit (the very old versions I used). If you want a permanent session, create a project.
I don't think so. First, it is an inconsistent behavior: ATM, opening a file with e.g. `geany myfile` will NOT result on the same state depending on whether Geany is already opened or not. If Geany is already running, the file will be appended to the session, but if Geany wasn't running, the session not only don't load, but will be lost (since a new one is saved on quit).
For me that's pretty consistent: when I click a file, Geany will open that exact file only, be it in existing instance, if any, or in a new instance. Why should it reload some temporarily edited/viewed files, when I explicitly specified which file I want open?
However, loading the previous files when a file is clicked if "Load files from the last session" is true, which this patch tries to achieve, would also be logical.
I personally use projects for the projects I work on a lot, and for which I want almost all its files opened, and the default session for everything else. Say, a standalone file to edit, a file part of a source tree I don't work on enough to have a project file for it, etc. This does NOT mean that my session is something I don't care to loose.
You can a project and name it "Default Session". Or even several of those.
And anyway, why use the session if you don't care about the opened files?
Why not use a "Default Session" if you care for them? You can even modify your .lnk file, panel command or menu entry to run "geany ~/path/Default.geany", except that not all DE-s allow menu editing.
BTW, I checked my Visual Studio 2008 today - it too works as Geany / SciTE / Ultra 7.
I haven't tested the patch yet, but the raised problem is a real concern IMHO. Well, it concerns me :)
Breaks geany -i filename.
Le 28/01/2011 19:16, Dimitar Zhekov a écrit :
On Fri, 28 Jan 2011 03:01:06 +0100 Colomban Wendling lists.ban@herbesfolles.org wrote:
- trying to open a file (eg from double clicking in nautilus) will
screw your session as command line loading of single files ignores your session opened files, except if geany was already opened.
SciTE will do the same, and so will UltraEdit (the very old versions I used). If you want a permanent session, create a project.
I don't think so. First, it is an inconsistent behavior: ATM, opening a file with e.g. `geany myfile` will NOT result on the same state depending on whether Geany is already opened or not. If Geany is already running, the file will be appended to the session, but if Geany wasn't running, the session not only don't load, but will be lost (since a new one is saved on quit).
For me that's pretty consistent: when I click a file, Geany will open that exact file only, be it in existing instance, if any, or in a new instance. Why should it reload some temporarily edited/viewed files, when I explicitly specified which file I want open?
I don't see why the session would be reloaded when not specifying any file then: "you have not opened any file, no file are open" seems to also make sense. Which (I guess) is the behavior when session is off.
However, loading the previous files when a file is clicked if "Load files from the last session" is true, which this patch tries to achieve, would also be logical.
So we quite agree that restoring the session anyway would be OK?
I personally use projects for the projects I work on a lot, and for which I want almost all its files opened, and the default session for everything else. Say, a standalone file to edit, a file part of a source tree I don't work on enough to have a project file for it, etc. This does NOT mean that my session is something I don't care to loose.
You can a project and name it "Default Session". Or even several of those.
Yes, but then I need to explicitly open it, regardless the fact that the session does the job perfectly well until you forget to launch Geany before sending it files to open.
And anyway, why use the session if you don't care about the opened files?
Why not use a "Default Session" if you care for them? You can even modify your .lnk file, panel command or menu entry to run "geany ~/path/Default.geany", except that not all DE-s allow menu editing.
I generally don't use my DE to launch Geany, but rather a CLI, so it needs typing more. And using an alias to open a project by default is not possible ATM since Geany doesn't open files specified on CL after a project file. However, I'm not sure it is really needed to b able to add file to a project when opening it.
And using a project for the session -- which (I repeat myself) would just be perfect for me if it would always be loaded -- seems hackish to me. I feel it as a workaround, not as the Right Way To Achieve this.
However, you didn't answered to my question :)
BTW, I checked my Visual Studio 2008 today - it too works as Geany / SciTE / Ultra 7.
...OK the behavior of other editors are a good start to see whether a particular behavior would be "unexpected". But it doesn't mean IMHO that we should follow that behavior, maybe there is a better alternative -- or at least that better fits <insert your name>'s expectations.
I haven't tested the patch yet, but the raised problem is a real concern IMHO. Well, it concerns me :)
Breaks geany -i filename.
Sad :/
Regards, Colomban
Il giorno ven, 28/01/2011 alle 20.16 +0200, Dimitar Zhekov ha scritto:
On Fri, 28 Jan 2011 03:01:06 +0100 Colomban Wendling lists.ban@herbesfolles.org wrote:
- trying to open a file (eg from double clicking in nautilus) will
screw your session as command line loading of single files ignores your session opened files, except if geany was already opened.
SciTE will do the same, and so will UltraEdit (the very old versions I used). If you want a permanent session, create a project.
I don't think so. First, it is an inconsistent behavior: ATM, opening a file with e.g. `geany myfile` will NOT result on the same state depending on whether Geany is already opened or not. If Geany is already running, the file will be appended to the session, but if Geany wasn't running, the session not only don't load, but will be lost (since a new one is saved on quit).
For me that's pretty consistent: when I click a file, Geany will open that exact file only, be it in existing instance, if any, or in a new instance. Why should it reload some temporarily edited/viewed files, when I explicitly specified which file I want open?
However, loading the previous files when a file is clicked if "Load files from the last session" is true, which this patch tries to achieve, would also be logical.
I personally use projects for the projects I work on a lot, and for which I want almost all its files opened, and the default session for everything else. Say, a standalone file to edit, a file part of a source tree I don't work on enough to have a project file for it, etc. This does NOT mean that my session is something I don't care to loose.
You can a project and name it "Default Session". Or even several of those.
And anyway, why use the session if you don't care about the opened files?
Why not use a "Default Session" if you care for them? You can even modify your .lnk file, panel command or menu entry to run "geany ~/path/Default.geany", except that not all DE-s allow menu editing.
BTW, I checked my Visual Studio 2008 today - it too works as Geany / SciTE / Ultra 7.
I haven't tested the patch yet, but the raised problem is a real concern IMHO. Well, it concerns me :)
Breaks geany -i filename.
no it doesn't break -i if you check the updated patch. I didn't even know there was such a function like -i when I’ve tried the first one (which is a great way to destroy your opened file session if you aren't cautious to close the additional instances before the first one with the full session). Visual studio doesn't store the previous session, at least not by default, it just shows a welcome pane asking what project to open. I don't have ultraedit 7 and scite. The fact other editors, anyway, have such a behaviour doesn't make it consistent. In any case, the updated patch has an option which gives the same exact behaviour of before if not enabled (could set it false as default, I've set it true) and allows those who see it as annoying and inconsistent (which seems to not be only me from the other posts) to maintain their session, at the same time it fixes the cited bug.
Hi,
To avoid citing the long discussion, now that I gave it more thought, since we have a "Load files from the last session" option, it seems natural for that option to control if the default session files should be loaded when starting Geany with filename argument(s).
(Personally I'll just turn it off, since my Geany is with x11 session management.)
no it doesn't break -i if you check the updated patch. I didn't even know there was such a function like -i when I’ve tried the first one
Oh. That was below a long citation and mailing list footers, so I missed it. Sorry.
Well the load_startup_files() is a bit hard to read now, despite the comments. If we agree on some reasonable behaviour - I personally see no point in yet another "keep session" option - it should probably be rewritten. But from my experience, it would be hard to persuade Enrico.
(which is a great way to destroy your opened file session if you aren't cautious to close the additional instances before the first one with the full session).
It was proposed, more than once, that the secondary instances should not save the default session, since they never load it. But as you can see, it still does. We should really try to convince the main developers (Nick / Enrico / Frank) once again, but they seem to be missing since 0.20 was released.
Visual studio doesn't store the previous session, at least not by default, it just shows a welcome pane asking what project to open. I don't have ultraedit 7 and scite.
My mistake again, I never start it by the endless Windows start menu, much less from the command line.
The fact other editors, anyway, have such a behaviour doesn't make it consistent.
But it makes it common. I checked SciTE and Ultra, and to my surprise, they both have a "load the last session" option, but ignore it when a filename argument is passed.
In any case, the updated patch has an option which gives the same exact behaviour of before if not enabled (could set it false as default, I've set it true) [...]
"Keep session" has no effect if "Load session" is false, so it should be disabled if "load" is unchecked. I think a set of radio buttons, for example "Never", "If no files specfied" and "Always", would be more clear. Yet again, the current option seems enough for me.
Hi,
Here is a sample load_startup_files() pseudocode that will hopefully:
1. Fix the CL project loading if prefs.load_session is false. 2. Open the default session files based on prefs.load_session even if command line files are passed. 3. Always open the command line files. 4. Make the startup simpler.
- local load_session = false
if (arg1 ends with ".geany") main_load_project_from_command_line(arg1, false) skip arg1 load_session = cl_options.load_session else if (cl_options.load_session && prefs.load_session && !new_instance) // filename(s) -> default session, not last project if (args <= 1) load_session_project_file() load_session = true
if (load_session) configuration_open_files() gtk_notebook_get_n_pages...
open_cl_files() -
This is the variant Colombian and I prefer, with no preference to avoid loading the default session if command line files are specified and prefs.load_session is true. For the command line, using -s and -i can be used to do that.
So now the idea of having the new file open in a new session if geany was not opened is not wanted anymore? Il giorno sab, 29/01/2011 alle 14.17 +0200, Dimitar Zhekov ha scritto:
Hi,
Here is a sample load_startup_files() pseudocode that will hopefully:
- Fix the CL project loading if prefs.load_session is false.
- Open the default session files based on prefs.load_session even if
command line files are passed. 3. Always open the command line files. 4. Make the startup simpler.
local load_session = false
if (arg1 ends with ".geany") main_load_project_from_command_line(arg1, false) skip arg1 load_session = cl_options.load_session else if (cl_options.load_session && prefs.load_session && !new_instance) // filename(s) -> default session, not last project if (args <= 1) load_session_project_file() load_session = true
if (load_session) configuration_open_files() gtk_notebook_get_n_pages...
open_cl_files()
This is the variant Colombian and I prefer, with no preference to avoid loading the default session if command line files are specified and prefs.load_session is true. For the command line, using -s and -i can be used to do that.
On Sat, 29 Jan 2011 17:39:31 +0100 weltall weltall2@gmail.com wrote:
So now the idea of having the new file open in a new session if geany was not opened is not wanted anymore?
I can live without it. But my view is biased, since I use Geany with x11 session management, so the main instances are pretty much permanent.
In the end, it's up to Enrico, Nick and Frank to decide. But the pseudocode can easily be modified to support it:
... else if (cl_options.load_session && prefs.load_session != Never && ! new_instance) if (args <= 1) // no filenames, restore project and session load_session_project_file() load_session = true else // filenames: no project, maybe default session load_session = prefs.load_session == Always ...
Or with separate load_session and keep_session variables, it doesn't matter.
On 30 January 2011 04:37, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Sat, 29 Jan 2011 17:39:31 +0100 weltall weltall2@gmail.com wrote:
So now the idea of having the new file open in a new session if geany was not opened is not wanted anymore?
I can live without it. But my view is biased, since I use Geany with x11 session management, so the main instances are pretty much permanent.
I'd have thought that you would be even *more* upset that the filemanager shoves extra files into your "permanent" sessions :-)
In other words --in-new-session is independent of session management and is about temporarily interrupting the session without modifying it.
Cheers Lex
PS the pseudocode modification below doesn't save the session on in-new-session
In the end, it's up to Enrico, Nick and Frank to decide. But the pseudocode can easily be modified to support it:
... else if (cl_options.load_session && prefs.load_session != Never && ! new_instance) if (args <= 1) // no filenames, restore project and session load_session_project_file() load_session = true else // filenames: no project, maybe default session load_session = prefs.load_session == Always ...
Or with separate load_session and keep_session variables, it doesn't matter.
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sun, 30 Jan 2011 07:10:36 +1100 Lex Trotman elextr@gmail.com wrote:
Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
weltall weltall2@gmail.com wrote:
So now the idea of having the new file open in a new session if geany was not opened is not wanted anymore?
I can live without it. But my view is biased, since I use Geany with x11 session management, so the main instances are pretty much permanent.
I'd have thought that you would be even *more* upset that the filemanager shoves extra files into your "permanent" sessions :-)
No. With session management, you can open the projects in secondary instances, and let the primary instances catch the double-clicking and command line. The secondary instances retain their status after restart, even if the primary instance does not exist any more (thanks, Eugene).
Maybe I shoudn't have used the word "main" instances for the ones that I mainly use... :) To clarify, they are both primary, on desktops used exclusively for a single project, and secondary.
In other words --in-new-session is independent of session management and is about temporarily interrupting the session without modifying it. [...] the pseudocode modification below doesn't save the session on in-new-session
IMO, --new-instance should not save the session, since it never loads it; combined with xsm, that's plenty of "temporarily interrupting the session without modifying it" to make in-new-session unneeded for me.
PS the pseudocode modification below doesn't save the session on in-new-session
Indeed. Yet you can make your own modification easier than tweaking the existing startup, not to speak about the 2nd weltall patch.
On 30 January 2011 21:40, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Sun, 30 Jan 2011 07:10:36 +1100 Lex Trotman elextr@gmail.com wrote:
Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
weltall weltall2@gmail.com wrote:
So now the idea of having the new file open in a new session if geany was not opened is not wanted anymore?
I can live without it. But my view is biased, since I use Geany with x11 session management, so the main instances are pretty much permanent.
I'd have thought that you would be even *more* upset that the filemanager shoves extra files into your "permanent" sessions :-)
No. With session management, you can open the projects in secondary instances, and let the primary instances catch the double-clicking and command line. The secondary instances retain their status after restart, even if the primary instance does not exist any more (thanks, Eugene).
Niiiice, I thought you said multi-instance sm wasn't working? but sounds the preferred way if it is (except for multi instance issues talked about elsewhere)
Maybe I shoudn't have used the word "main" instances for the ones that I mainly use... :) To clarify, they are both primary, on desktops used exclusively for a single project, and secondary.
Good idea, keeping things segragated will help to mitigate multi-instance issues (remember most of them are caused by liveware failures)
In other words --in-new-session is independent of session management and is about temporarily interrupting the session without modifying it. [...] the pseudocode modification below doesn't save the session on in-new-session
IMO, --new-instance should not save the session, since it never loads it; combined with xsm, that's plenty of "temporarily interrupting the session without modifying it" to make in-new-session unneeded for me.
The proposal is for a Geany without sm, if we add sm then it all needs to be looked at again in that light.
Cheers Lex
PS the pseudocode modification below doesn't save the session on in-new-session
Indeed. Yet you can make your own modification easier than tweaking the existing startup, not to speak about the 2nd weltall patch.
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Mon, 31 Jan 2011 09:03:44 +1100 Lex Trotman elextr@gmail.com wrote:
With session management, you can open the projects in secondary instances, and let the primary instances catch the double-clicking and command line. The secondary instances retain their status after restart, even if the primary instance does not exist any more (thanks, Eugene).
Niiiice, I thought you said multi-instance sm wasn't working? but sounds the preferred way if it is (except for multi instance issues talked about elsewhere)
Single instance ::= Each instance runs for itself and does not communicate with the others, other than for initial socket checking and argv passing. That is, the current Geany.
With the single instance sm, you can run as many instances as you want. That was implemented by Eugene; I added the prefs isolation.
On 1 February 2011 04:27, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Mon, 31 Jan 2011 09:03:44 +1100 Lex Trotman elextr@gmail.com wrote:
With session management, you can open the projects in secondary instances, and let the primary instances catch the double-clicking and command line. The secondary instances retain their status after restart, even if the primary instance does not exist any more (thanks, Eugene).
Niiiice, I thought you said multi-instance sm wasn't working? but sounds the preferred way if it is (except for multi instance issues talked about elsewhere)
Single instance ::= Each instance runs for itself and does not communicate with the others, other than for initial socket checking and argv passing. That is, the current Geany.
Ok, misunderstood
With the single instance sm, you can run as many instances as you want. That was implemented by Eugene; I added the prefs isolation.
-- E-gards: Jimmy
Sounds like a good thing to add to Geany, here is a checklist of the things I did before my build system branch was merged back into trunk
* make sure that there is not anything not related to sm in the branch * merge a recent trunk into the branch and fix the conflicts & check it works * run the coding style scripts on it and check for any stuff ups they might have made * ensure that the documentation has been updated comprehensively to reflect the new functionality and that it builds and looks ok (this is hard, you know what it does but you have to assume no knowledge on the part of the reader, ie me :-)
Cheers Lex
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 29 January 2011 05:16, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Fri, 28 Jan 2011 03:01:06 +0100 Colomban Wendling lists.ban@herbesfolles.org wrote:
- trying to open a file (eg from double clicking in nautilus) will
screw your session as command line loading of single files ignores your session opened files, except if geany was already opened.
SciTE will do the same, and so will UltraEdit (the very old versions I used). If you want a permanent session, create a project.
I don't think so. First, it is an inconsistent behavior: ATM, opening a file with e.g. `geany myfile` will NOT result on the same state depending on whether Geany is already opened or not. If Geany is already running, the file will be appended to the session, but if Geany wasn't running, the session not only don't load, but will be lost (since a new one is saved on quit).
For me that's pretty consistent: when I click a file, Geany will open that exact file only, be it in existing instance, if any, or in a new instance. Why should it reload some temporarily edited/viewed files, when I explicitly specified which file I want open?
Only because when you close Geany it will overwrite the previous session files list so its lost.
However, loading the previous files when a file is clicked if "Load files from the last session" is true, which this patch tries to achieve, would also be logical.
I personally use projects for the projects I work on a lot, and for which I want almost all its files opened, and the default session for everything else. Say, a standalone file to edit, a file part of a source tree I don't work on enough to have a project file for it, etc. This does NOT mean that my session is something I don't care to loose.
You can a project and name it "Default Session". Or even several of those.
And anyway, why use the session if you don't care about the opened files?
Why not use a "Default Session" if you care for them? You can even modify your .lnk file, panel command or menu entry to run "geany ~/path/Default.geany", except that not all DE-s allow menu editing.
You can't do that at the moment, but this is a good reason for the patches change to load files and the project file. Does it save the open session (project) first??
Cheers Lex
BTW, I checked my Visual Studio 2008 today - it too works as Geany / SciTE / Ultra 7.
I haven't tested the patch yet, but the raised problem is a real concern IMHO. Well, it concerns me :)
Breaks geany -i filename.
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Hi All,
Since its Saturday I've looked back at the thread and, at least for my own benefit, I'd like to try to summarise what I think the *preferred* behavior is.
I haven't attributed suggestions to anyone since many have participated in the thread but if I've misrepresented/misunderstood anything please comment.
1. Geany has one default unnamed session (per user) and named sessions (projects).
2. A Geany instance can have only one session open at once.
3. When the first Geany is started or Geany is started with --socket-file pointing to a non-existent file:
a. if the "do not reload session" preference is set or -s specified on the cl, do not load the default or a previously open named session, load a session specified on the command line or else start a new default session
b. if the "do not reload session" preference is not set and -s not specified, load a session specified on the command line or the previously open named session or the saved default session
c. a. or b. can be overridden by a --in_new_session option that opens a new default session.
d. any files on the command line are opened and added to the session that results from a, b or c.
e. the -i option is ignored
f. when Geany is closed save the current session (default or named) and save which is the current session so it can be reloaded.
4. When a Geany is already running and no --socket-file or --socket-file points to an existing file and no -i is specified:
a. if there is no session file specified on the cl and --in_new_session is not specified then load the files in the instance of Geany that matches the socket file and add them to the open session.
b. if a session file is specified or --in_new_session is specified then close and save the current session in the instance of Geany that matches the socket file and open the specified/new one then open the specified files and add them to the session. --in_new_session overrides a specified session file.
c. having opened files in the existing instance, quit this one and don't save anything.
5. When a Geany instance is running and -i is specified:
a. start a new instance of Geany, and behave as in 3. with "do not reload session" set.
b. On close if the current session is the default session do not save it, if it is a named session save it but do not save that it is the current session.
Issues about other preferences and other multiple instance behaviors are not the topic of this thread and have been ignored.
I think after the patch, except for the new --in-new-session option, the behavior is close to this but correct me (or the patch :-) if I'm wrong.
The --in-new-session is for files opened by file managers or downloads from firefox etc so that the current session is saved and not mucked up by the new files. This behavior was requested several times in the thread but since it isn't the right thing all the time I am suggesting making it an option. The previous session can then be restored by Project->Recent projects-> for named sessions or a new reload default session menu item. Or make the new menu item "reload last session" and let it figure out which it was.
Cheers Lex
On Sat, 29 Jan 2011 11:11:27 +1100% Lex Trotman elextr@gmail.com wrote:
Hi All,
Since its Saturday I've looked back at the thread and, at least for my own benefit, I'd like to try to summarise what I think the *preferred* behavior is.
I haven't attributed suggestions to anyone since many have participated in the thread but if I've misrepresented/misunderstood anything please comment.
- Geany has one default unnamed session (per user) and named sessions
(projects).
A Geany instance can have only one session open at once.
When the first Geany is started or Geany is started with
--socket-file pointing to a non-existent file:
a. if the "do not reload session" preference is set or -s specified on the cl, do not load the default or a previously open named session, load a session specified on the command line or else start a new default session
b. if the "do not reload session" preference is not set and -s not specified, load a session specified on the command line or the previously open named session or the saved default session
c. a. or b. can be overridden by a --in_new_session option that opens a new default session.
d. any files on the command line are opened and added to the session that results from a, b or c.
e. the -i option is ignored
f. when Geany is closed save the current session (default or named) and save which is the current session so it can be reloaded.
- When a Geany is already running and no --socket-file or
--socket-file points to an existing file and no -i is specified:
a. if there is no session file specified on the cl and --in_new_session is not specified then load the files in the instance of Geany that matches the socket file and add them to the open session.
b. if a session file is specified or --in_new_session is specified then close and save the current session in the instance of Geany that matches the socket file and open the specified/new one then open the specified files and add them to the session. --in_new_session overrides a specified session file.
Do I understand correctly that if a type-3 instance matching the socket file is running, it will close its session and all files and load files and (possibly) session specified here? If true, using --in-new-session for file managers etc. does not seem acceptable to me as user looses everything he has in already running type-3 instance every time he opens a file in a file manager.
c. having opened files in the existing instance, quit this one and don't save anything.
- When a Geany instance is running and -i is specified:
a. start a new instance of Geany, and behave as in 3. with "do not reload session" set.
b. On close if the current session is the default session do not save it, if it is a named session save it but do not save that it is the current session.
Issues about other preferences and other multiple instance behaviors are not the topic of this thread and have been ignored.
I think after the patch, except for the new --in-new-session option, the behavior is close to this but correct me (or the patch :-) if I'm wrong.
The --in-new-session is for files opened by file managers or downloads from firefox etc so that the current session is saved and not mucked up by the new files. This behavior was requested several times in the thread but since it isn't the right thing all the time I am suggesting making it an option. The previous session can then be restored by Project->Recent projects-> for named sessions or a new reload default session menu item. Or make the new menu item "reload last session" and let it figure out which it was.
BTW, great summary.
Cheers Lex _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 29 January 2011 19:35, Eugene Arshinov earshinov@gmail.com wrote:
On Sat, 29 Jan 2011 11:11:27 +1100% Lex Trotman elextr@gmail.com wrote:
Hi All,
Since its Saturday I've looked back at the thread and, at least for my own benefit, I'd like to try to summarise what I think the *preferred* behavior is.
I haven't attributed suggestions to anyone since many have participated in the thread but if I've misrepresented/misunderstood anything please comment.
- Geany has one default unnamed session (per user) and named sessions
(projects).
A Geany instance can have only one session open at once.
When the first Geany is started or Geany is started with
--socket-file pointing to a non-existent file:
a. if the "do not reload session" preference is set or -s specified on the cl, do not load the default or a previously open named session, load a session specified on the command line or else start a new default session
b. if the "do not reload session" preference is not set and -s not specified, load a session specified on the command line or the previously open named session or the saved default session
c. a. or b. can be overridden by a --in_new_session option that opens a new default session.
d. any files on the command line are opened and added to the session that results from a, b or c.
e. the -i option is ignored
f. when Geany is closed save the current session (default or named) and save which is the current session so it can be reloaded.
- When a Geany is already running and no --socket-file or
--socket-file points to an existing file and no -i is specified:
a. if there is no session file specified on the cl and --in_new_session is not specified then load the files in the instance of Geany that matches the socket file and add them to the open session.
b. if a session file is specified or --in_new_session is specified then close and save the current session in the instance of Geany that matches the socket file and open the specified/new one then open the specified files and add them to the session. --in_new_session overrides a specified session file.
Do I understand correctly that if a type-3 instance matching the socket file is running, it will close its session and all files and load files and (possibly) session specified here? If true, using --in-new-session for file managers etc. does not seem acceptable to me as user looses everything he has in already running type-3 instance every time he opens a file in a file manager.
Hi Eugene,
The intention is that the interrupted session is re-loadable (as per final comments) so it isn't "lost" but...
Neither a nor b is the right solution all the time, a always mucks up your existing session, b can't add things to an existing session.
Sadly file managers and similar only have one default.
Therefore which one you choose to configure the file manager default with will depend on your most common workflow, if it is to open things from the filemanager several times to the existing session then you want a. but if, like me, you open most files in Geany itself you can use b to make the filemanager/firefox open files in a new session, and you can add any more files to this new session within Geany (since it now defaults to the directory of the open file, which is most likely where you want to add extras from). And then you can recover the interrupted session later. Thats the use case for b and thats why I made --in-new-session an option.
c. having opened files in the existing instance, quit this one and don't save anything.
- When a Geany instance is running and -i is specified:
a. start a new instance of Geany, and behave as in 3. with "do not reload session" set.
b. On close if the current session is the default session do not save it, if it is a named session save it but do not save that it is the current session.
Issues about other preferences and other multiple instance behaviors are not the topic of this thread and have been ignored.
I think after the patch, except for the new --in-new-session option, the behavior is close to this but correct me (or the patch :-) if I'm wrong.
The --in-new-session is for files opened by file managers or downloads from firefox etc so that the current session is saved and not mucked up by the new files. This behavior was requested several times in the thread but since it isn't the right thing all the time I am suggesting making it an option. The previous session can then be restored by Project->Recent projects-> for named sessions or a new reload default session menu item. Or make the new menu item "reload last session" and let it figure out which it was.
BTW, great summary.
Glad its helpful,thanks.
Cheers Lex
Cheers Lex _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sat, 29 Jan 2011 21:59:37 +1100% Lex Trotman elextr@gmail.com wrote:
On 29 January 2011 19:35, Eugene Arshinov earshinov@gmail.com wrote:
On Sat, 29 Jan 2011 11:11:27 +1100% Lex Trotman elextr@gmail.com wrote:
Hi All,
Since its Saturday I've looked back at the thread and, at least for my own benefit, I'd like to try to summarise what I think the *preferred* behavior is.
I haven't attributed suggestions to anyone since many have participated in the thread but if I've misrepresented/misunderstood anything please comment.
- Geany has one default unnamed session (per user) and named
sessions (projects).
A Geany instance can have only one session open at once.
When the first Geany is started or Geany is started with
--socket-file pointing to a non-existent file:
a. if the "do not reload session" preference is set or -s specified on the cl, do not load the default or a previously open named session, load a session specified on the command line or else start a new default session
b. if the "do not reload session" preference is not set and -s not specified, load a session specified on the command line or the previously open named session or the saved default session
c. a. or b. can be overridden by a --in_new_session option that opens a new default session.
d. any files on the command line are opened and added to the session that results from a, b or c.
e. the -i option is ignored
f. when Geany is closed save the current session (default or named) and save which is the current session so it can be reloaded.
- When a Geany is already running and no --socket-file or
--socket-file points to an existing file and no -i is specified:
a. if there is no session file specified on the cl and --in_new_session is not specified then load the files in the instance of Geany that matches the socket file and add them to the open session.
b. if a session file is specified or --in_new_session is specified then close and save the current session in the instance of Geany that matches the socket file and open the specified/new one then open the specified files and add them to the session. --in_new_session overrides a specified session file.
Do I understand correctly that if a type-3 instance matching the socket file is running, it will close its session and all files and load files and (possibly) session specified here? If true, using --in-new-session for file managers etc. does not seem acceptable to me as user looses everything he has in already running type-3 instance every time he opens a file in a file manager.
Hi Eugene,
The intention is that the interrupted session is re-loadable (as per final comments) so it isn't "lost" but...
Neither a nor b is the right solution all the time, a always mucks up your existing session, b can't add things to an existing session.
Sadly file managers and similar only have one default.
Therefore which one you choose to configure the file manager default with will depend on your most common workflow, if it is to open things from the filemanager several times to the existing session then you want a. but if, like me, you open most files in Geany itself you can use b to make the filemanager/firefox open files in a new session, and you can add any more files to this new session within Geany (since it now defaults to the directory of the open file, which is most likely where you want to add extras from). And then you can recover the interrupted session later. Thats the use case for b and thats why I made --in-new-session an option.
Hi Lex.
Thanks for the explanation, it's now clear for me.
Also, for me the behaviour your summarized seems quite meaningful and it matches what I would expect, except the fact than I don't need --in-new-session option in my workflow.
c. having opened files in the existing instance, quit this one and don't save anything.
- When a Geany instance is running and -i is specified:
a. start a new instance of Geany, and behave as in 3. with "do not reload session" set.
b. On close if the current session is the default session do not save it, if it is a named session save it but do not save that it is the current session.
Issues about other preferences and other multiple instance behaviors are not the topic of this thread and have been ignored.
I think after the patch, except for the new --in-new-session option, the behavior is close to this but correct me (or the patch :-) if I'm wrong.
The --in-new-session is for files opened by file managers or downloads from firefox etc so that the current session is saved and not mucked up by the new files. This behavior was requested several times in the thread but since it isn't the right thing all the time I am suggesting making it an option. The previous session can then be restored by Project->Recent projects-> for named sessions or a new reload default session menu item. Or make the new menu item "reload last session" and let it figure out which it was.
BTW, great summary.
Glad its helpful,thanks.
Cheers Lex
Cheers Lex _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, 27 Jan 2011 10:20:26 +0100% weltall weltall2@gmail.com wrote:
Hi, I've noticed various issues with file loading from command line:
- if the option load last session is not enabled project files can't
be opened from command line: this happens because the code to handle them is wrapped in a prefs.load_lastsession if so the only way to load them from command line is having that option true. 2) trying to open a file (eg from double clicking in nautilus) will screw your session as command line loading of single files ignores your session opened files, except if geany was already opened.
So to fix those issues I've reorganized the code in the load_startup_file function in order to:
- load the project files ignoring the session if a project file was
specified at command line 2) allow to load more files in addition to the project file (removing so the limitation imposed there artificially - possible improvement to this would be adding a flag to open_cl_files as argument in order to avoid that pointer toying) 3) the open_cl_files is called after loading the session so the specifically selected files are opened last and so are automatically selected (what you would expect when opening a file from nautilus) 4) if the option to load last session is not enabled and there isn't a project file being loaded from command line and a project is not being loaded we just try to load files from command line if any
Stefano Angeleri
Just to mention, I had similar objections about a year ago when I wrote my version of session management support (the list probably knows what I'm talking about). This was discussed a little, and some patches were included in 'sm' branch. For example, load_startup_files() function in that branch differs significantly from trunk, and open_cl_files() does not have a check for `argc <= 1`. Geany's SVN browse seems to be unavailable now, but I think it should be possible there to view 'sm' branch.
It is harder to find the discussion than the patches themselves, but here is a couple of links:
http://lists.uvena.de/pipermail/geany-devel/2009-November/001577.html (X session management support) http://lists.uvena.de/geany-devel/2010-January/001655.html (Questions about Geany project support)
I don't object against your patches, but I'm just pointing to existing discussion which may be useful. I must note that there are no plans about including those patches from 'sm' branch in trunk (because nobody would want/have time to do it, and it won't be quite easy as 'sm' branch has become rather diverse from trunk), so your way is free :)
Regards, Eugene.
On Fri, 28 Jan 2011 11:31:21 +0300 Eugene Arshinov earshinov@gmail.com wrote:
On Thu, 27 Jan 2011 10:20:26 +0100% weltall weltall2@gmail.com wrote:
Hi, I've noticed various issues with file loading from command line:
- if the option load last session is not enabled project files
can't be opened from command line: this happens because the code to handle them is wrapped in a prefs.load_lastsession if so the only way to load them from command line is having that option true. 2) trying to open a file (eg from double clicking in nautilus) will screw your session as command line loading of single files ignores your session opened files, except if geany was already opened.
So to fix those issues I've reorganized the code in the load_startup_file function in order to:
- load the project files ignoring the session if a project file was
specified at command line 2) allow to load more files in addition to the project file (removing so the limitation imposed there artificially - possible improvement to this would be adding a flag to open_cl_files as argument in order to avoid that pointer toying) 3) the open_cl_files is called after loading the session so the specifically selected files are opened last and so are automatically selected (what you would expect when opening a file from nautilus) 4) if the option to load last session is not enabled and there isn't a project file being loaded from command line and a project is not being loaded we just try to load files from command line if any
Stefano Angeleri
Just to mention, I had similar objections about a year ago when I wrote my version of session management support (the list probably knows what I'm talking about). This was discussed a little, and some patches were included in 'sm' branch. For example, load_startup_files () function in that branch differs significantly from trunk, and open_cl_files() does not have a check for `argc <= 1`. Geany's SVN browse seems to be unavailable now, but I think it should be possible there to view 'sm' branch.
The branch is still available. To checkout its
svn co https://geany.svn.sourceforge.net/svnroot/geany/branches/sm
The sf viewer seems to be really down at the moment.
It is harder to find the discussion than the patches themselves, but here is a couple of links:
http://lists.uvena.de/pipermail/geany-devel/2009-November/001577.html (X session management support) http://lists.uvena.de/geany-devel/2010-January/001655.html (Questions about Geany project support)
I don't object against your patches, but I'm just pointing to existing discussion which may be useful. I must note that there are no plans about including those patches from 'sm' branch in trunk (because nobody would want/have time to do it, and it won't be quite easy as 'sm' branch has become rather diverse from trunk), so your way is free :)
Well, not sure whether I'm right the branch wasn't ready for including to trunk and nobody did care about later on. Please correct me if I'm wrong.
Cheers, Frank
On 31 January 2011 02:54, Frank Lanitz frank@frank.uvena.de wrote:
On Fri, 28 Jan 2011 11:31:21 +0300 Eugene Arshinov earshinov@gmail.com wrote:
On Thu, 27 Jan 2011 10:20:26 +0100% weltall weltall2@gmail.com wrote:
Hi, I've noticed various issues with file loading from command line:
- if the option load last session is not enabled project files
can't be opened from command line: this happens because the code to handle them is wrapped in a prefs.load_lastsession if so the only way to load them from command line is having that option true. 2) trying to open a file (eg from double clicking in nautilus) will screw your session as command line loading of single files ignores your session opened files, except if geany was already opened.
So to fix those issues I've reorganized the code in the load_startup_file function in order to:
- load the project files ignoring the session if a project file was
specified at command line 2) allow to load more files in addition to the project file (removing so the limitation imposed there artificially - possible improvement to this would be adding a flag to open_cl_files as argument in order to avoid that pointer toying) 3) the open_cl_files is called after loading the session so the specifically selected files are opened last and so are automatically selected (what you would expect when opening a file from nautilus) 4) if the option to load last session is not enabled and there isn't a project file being loaded from command line and a project is not being loaded we just try to load files from command line if any
Stefano Angeleri
Just to mention, I had similar objections about a year ago when I wrote my version of session management support (the list probably knows what I'm talking about). This was discussed a little, and some patches were included in 'sm' branch. For example, load_startup_files () function in that branch differs significantly from trunk, and open_cl_files() does not have a check for `argc <= 1`. Geany's SVN browse seems to be unavailable now, but I think it should be possible there to view 'sm' branch.
The branch is still available. To checkout its
svn co https://geany.svn.sourceforge.net/svnroot/geany/branches/sm
The sf viewer seems to be really down at the moment.
It is harder to find the discussion than the patches themselves, but here is a couple of links:
http://lists.uvena.de/pipermail/geany-devel/2009-November/001577.html (X session management support) http://lists.uvena.de/geany-devel/2010-January/001655.html (Questions about Geany project support)
I don't object against your patches, but I'm just pointing to existing discussion which may be useful. I must note that there are no plans about including those patches from 'sm' branch in trunk (because nobody would want/have time to do it, and it won't be quite easy as 'sm' branch has become rather diverse from trunk), so your way is free :)
Well, not sure whether I'm right the branch wasn't ready for including to trunk and nobody did care about later on. Please correct me if I'm wrong.
I guess now (post 0.20) is the time to do major additions, if a current trunk is merged with sm branch and it still works then maybe its time.
Cheers Lex
Cheers, Frank -- http://frank.uvena.de/en/
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Mon, 31 Jan 2011 09:06:26 +1100 Lex Trotman elextr@gmail.com wrote:
On 31 January 2011 02:54, Frank Lanitz frank@frank.uvena.de wrote:
On Fri, 28 Jan 2011 11:31:21 +0300 Eugene Arshinov earshinov@gmail.com wrote:
On Thu, 27 Jan 2011 10:20:26 +0100% weltall weltall2@gmail.com wrote:
Hi, I've noticed various issues with file loading from command line:
- if the option load last session is not enabled project files
can't be opened from command line: this happens because the code to handle them is wrapped in a prefs.load_lastsession if so the only way to load them from command line is having that option true. 2) trying to open a file (eg from double clicking in nautilus) will screw your session as command line loading of single files ignores your session opened files, except if geany was already opened.
So to fix those issues I've reorganized the code in the load_startup_file function in order to:
- load the project files ignoring the session if a project file
was specified at command line 2) allow to load more files in addition to the project file (removing so the limitation imposed there artificially - possible improvement to this would be adding a flag to open_cl_files as argument in order to avoid that pointer toying) 3) the open_cl_files is called after loading the session so the specifically selected files are opened last and so are automatically selected (what you would expect when opening a file from nautilus) 4) if the option to load last session is not enabled and there isn't a project file being loaded from command line and a project is not being loaded we just try to load files from command line if any
Stefano Angeleri
Just to mention, I had similar objections about a year ago when I wrote my version of session management support (the list probably knows what I'm talking about). This was discussed a little, and some patches were included in 'sm' branch. For example, load_startup_files () function in that branch differs significantly from trunk, and open_cl_files() does not have a check for `argc <= 1`. Geany's SVN browse seems to be unavailable now, but I think it should be possible there to view 'sm' branch.
The branch is still available. To checkout its
svn co https://geany.svn.sourceforge.net/svnroot/geany/branches/sm
The sf viewer seems to be really down at the moment.
It is harder to find the discussion than the patches themselves, but here is a couple of links:
http://lists.uvena.de/pipermail/geany-devel/2009-November/001577.html (X session management support) http://lists.uvena.de/geany-devel/2010-January/001655.html (Questions about Geany project support)
I don't object against your patches, but I'm just pointing to existing discussion which may be useful. I must note that there are no plans about including those patches from 'sm' branch in trunk (because nobody would want/have time to do it, and it won't be quite easy as 'sm' branch has become rather diverse from trunk), so your way is free :)
Well, not sure whether I'm right the branch wasn't ready for including to trunk and nobody did care about later on. Please correct me if I'm wrong.
I guess now (post 0.20) is the time to do major additions, if a current trunk is merged with sm branch and it still works then maybe its time.
I guess this is something the original author of the branch needs to do.
Cheers, Frank
On Sat, 26 Feb 2011 13:47:22 +0100% Frank Lanitz frank@frank.uvena.de wrote:
On Mon, 31 Jan 2011 09:06:26 +1100 Lex Trotman elextr@gmail.com wrote:
On 31 January 2011 02:54, Frank Lanitz frank@frank.uvena.de wrote:
On Fri, 28 Jan 2011 11:31:21 +0300 Eugene Arshinov earshinov@gmail.com wrote:
[snip]
It is harder to find the discussion than the patches themselves, but here is a couple of links:
http://lists.uvena.de/pipermail/geany-devel/2009-November/001577.html (X session management support) http://lists.uvena.de/geany-devel/2010-January/001655.html (Questions about Geany project support)
I don't object against your patches, but I'm just pointing to existing discussion which may be useful. I must note that there are no plans about including those patches from 'sm' branch in trunk (because nobody would want/have time to do it, and it won't be quite easy as 'sm' branch has become rather diverse from trunk), so your way is free :)
Well, not sure whether I'm right the branch wasn't ready for including to trunk and nobody did care about later on. Please correct me if I'm wrong.
I guess now (post 0.20) is the time to do major additions, if a current trunk is merged with sm branch and it still works then maybe its time.
I guess this is something the original author of the branch needs to do.
Cheers, Frank
Certainly. I've already merged trunk in my local Git repository, but I haven't yet find some time to carefully test the branch again. Though, I use this merged version at home every day and experience no problems, so most things should be fine. Tomorrow I'll update the SVN sm branch.
Best regards, Eugene.