Hi all.
Preface -------
Recently I realized that I completely forgot to integrate project support into my XSMP support (which would reside in "sm" branch after some of my patches are committed). Currently my code stores open files, but it does not remember the project, if any was opened when Geany terminated.
I was looking through the code to understand how the integration could be implemented and testing how Geany behaves on opening and closing projects. I discovered some issues, and there are also some questions I'd like to ask. After all problems are solved and questions are answered, I'll prepare some more patches for "sm" branch.
Question #1 -----------
`load_startup_files' function within main.c (formatting is wrong):
/* when we want a new instance, we still load project session files unless -s was passed */ if (!cl_options.load_session || (!load_project_from_cl && cl_options.new_instance)) return;
Specifying "-s" while opening a projects causes Geany to open a blank document.
First, when geany instance is closed, the project is overwritten. Instead of the files which were previously there, there would be no files in the project. Is it a desired behaviour? Is it a desired way to clear a project?
Second, it is not intuitive. From my point of view, "-s" is there to not load the default session. When user tries to open a project and specify "-s", he should wish to open the project's files and not load the default session. Currently opening a project forbids loading the default session, so "-s" is not necessary. But I think the behaviour I described ("-s" is ignored) is more logical than opening a blank document instead of project's files.
What do you think?
Best regards, Eugene.
Am Sonntag, den 10.01.2010, 18:38 +0300 schrieb Eugene Arshinov:
Hi all.
Preface
Recently I realized that I completely forgot to integrate project support into my XSMP support (which would reside in "sm" branch after some of my patches are committed). Currently my code stores open files, but it does not remember the project, if any was opened when Geany terminated.
I was looking through the code to understand how the integration could be implemented and testing how Geany behaves on opening and closing projects. I discovered some issues, and there are also some questions I'd like to ask. After all problems are solved and questions are answered, I'll prepare some more patches for "sm" branch.
Question #1
`load_startup_files' function within main.c (formatting is wrong):
/* when we want a new instance, we still load project session files unless -s was passed */ if (!cl_options.load_session || (!load_project_from_cl && cl_options.new_instance)) return;
Specifying "-s" while opening a projects causes Geany to open a blank document.
First, when geany instance is closed, the project is overwritten. Instead of the files which were previously there, there would be no files in the project. Is it a desired behaviour? Is it a desired way to clear a project?
Second, it is not intuitive. From my point of view, "-s" is there to not load the default session. When user tries to open a project and specify "-s", he should wish to open the project's files and not load the default session. Currently opening a project forbids loading the default session, so "-s" is not necessary. But I think the behaviour I described ("-s" is ignored) is more logical than opening a blank document instead of project's files.
I agree to this one. I'd also expect the project files to be opened.
Regards, Dominic
On Sun, 10 Jan 2010 19:59:15 +0100, Dominic wrote:
Am Sonntag, den 10.01.2010, 18:38 +0300 schrieb Eugene Arshinov:
Hi all.
Preface
Recently I realized that I completely forgot to integrate project support into my XSMP support (which would reside in "sm" branch after some of my patches are committed). Currently my code stores open files, but it does not remember the project, if any was opened when Geany terminated.
I was looking through the code to understand how the integration could be implemented and testing how Geany behaves on opening and closing projects. I discovered some issues, and there are also some questions I'd like to ask. After all problems are solved and questions are answered, I'll prepare some more patches for "sm" branch.
Question #1
`load_startup_files' function within main.c (formatting is wrong):
/* when we want a new instance, we still load project session files unless -s was passed */ if (!cl_options.load_session || (!load_project_from_cl && cl_options.new_instance)) return;
Specifying "-s" while opening a projects causes Geany to open a blank document.
First, when geany instance is closed, the project is overwritten. Instead of the files which were previously there, there would be no files in the project. Is it a desired behaviour? Is it a desired way to clear a project?
By no means. I consider this a bug. Thanks for pointing this out.
Second, it is not intuitive. From my point of view, "-s" is there to not load the default session. When user tries to open a project and specify "-s", he should wish to open the project's files and not load the default session. Currently opening a project forbids loading the default session, so "-s" is not necessary. But I think the behaviour I described ("-s" is ignored) is more logical than opening a blank document instead of project's files.
I agree to this one. I'd also expect the project files to be opened.
Me too.
Regards, Enrico
On Mon, 11 Jan 2010 21:31:01 +0100% Enrico Tröger enrico.troeger@uvena.de wrote:
On Sun, 10 Jan 2010 19:59:15 +0100, Dominic wrote:
Am Sonntag, den 10.01.2010, 18:38 +0300 schrieb Eugene Arshinov:
Hi all.
<...>
Question #1
`load_startup_files' function within main.c (formatting is wrong):
/* when we want a new instance, we still load project session files unless -s was passed */ if (!cl_options.load_session || (!load_project_from_cl && cl_options.new_instance)) return;
Specifying "-s" while opening a projects causes Geany to open a blank document.
First, when geany instance is closed, the project is overwritten. Instead of the files which were previously there, there would be no files in the project. Is it a desired behaviour? Is it a desired way to clear a project?
By no means. I consider this a bug. Thanks for pointing this out.
Second, it is not intuitive. From my point of view, "-s" is there to not load the default session. When user tries to open a project and specify "-s", he should wish to open the project's files and not load the default session. Currently opening a project forbids loading the default session, so "-s" is not necessary. But I think the behaviour I described ("-s" is ignored) is more logical than opening a blank document instead of project's files.
I agree to this one. I'd also expect the project files to be opened.
Me too.
Thank you, Dominic and Enrico, for your opinions. I have a little patch to fix this issue (attached).
As an alternative, I have a completely rewritten `load_startup_files' function. I wrote it to understand all the conditions which were in the original implementation. My function is *MUCH* more verbose, but I think it can be easier to understand and modify. I *DID NOT TEST* it, so consider it to be a sketch. Enrico, if you like this implementation, I can test and update it, so it can be safely committed.
I need to know which way (the little patch or the rewritten function) is accepted as my future questions may require further modifications of `load_startup_files'.
Best regards, Eugene.
On Tue, 12 Jan 2010 22:19:33 +0300, Eugene wrote:
First, when geany instance is closed, the project is overwritten. Instead of the files which were previously there, there would be no files in the project. Is it a desired behaviour? Is it a desired way to clear a project?
By no means. I consider this a bug. Thanks for pointing this out.
Second, it is not intuitive. From my point of view, "-s" is there to not load the default session. When user tries to open a project and specify "-s", he should wish to open the project's files and not load the default session. Currently opening a project forbids loading the default session, so "-s" is not necessary. But I think the behaviour I described ("-s" is ignored) is more logical than opening a blank document instead of project's files.
I agree to this one. I'd also expect the project files to be opened.
Me too.
Thank you, Dominic and Enrico, for your opinions. I have a little patch to fix this issue (attached).
As an alternative, I have a completely rewritten `load_startup_files' function. I wrote it to understand all the conditions which were in the original implementation. My function is *MUCH* more verbose, but I think it can be easier to understand and modify. I *DID NOT TEST* it, so consider it to be a sketch. Enrico, if you like this implementation, I can test and update it, so it can be safely committed.
Cool!
I need to know which way (the little patch or the rewritten function) is accepted as my future questions may require further modifications of `load_startup_files'.
I do like your rewritten function more as it is more clear and more structured. I didn't test it as well yet but I think we should use it. If you don't have more changes it for now, I'll test and commit it then.Thanks!!
Regards, Enrico
On Sun, 17 Jan 2010 16:54:30 +0100% Enrico Tröger enrico.troeger@uvena.de wrote:
On Tue, 12 Jan 2010 22:19:33 +0300, Eugene wrote:
<...>
Thank you, Dominic and Enrico, for your opinions. I have a little patch to fix this issue (attached).
As an alternative, I have a completely rewritten `load_startup_files' function. I wrote it to understand all the conditions which were in the original implementation. My function is *MUCH* more verbose, but I think it can be easier to understand and modify. I *DID NOT TEST* it, so consider it to be a sketch. Enrico, if you like this implementation, I can test and update it, so it can be safely committed.
Cool!
I need to know which way (the little patch or the rewritten function) is accepted as my future questions may require further modifications of `load_startup_files'.
I do like your rewritten function more as it is more clear and more structured. I didn't test it as well yet but I think we should use it. If you don't have more changes it for now, I'll test and commit it then.Thanks!!
No, I don't have more changes for now. I tested the function a bit today, it works as expected (like the version in current trunk except the little bug with -s option fixed). The only change I made is that I merged two comment lines into one :) So you can use either the function code from my previous post or the attached patch.
Before you commit, I'd like to know how the changes would go to "sm" branch. It is not so important for me (as I use a local Git repository anyway), but it could be important for the one who will commit my patches (e.g., probably Nick). Will it be done using SVN merge, or will there be separate commits (same patches applied to different branches)?
Best regards, Eugene.
On Mon, 18 Jan 2010 17:17:02 +0300, Eugene wrote:
On Sun, 17 Jan 2010 16:54:30 +0100% Enrico Tröger enrico.troeger@uvena.de wrote:
On Tue, 12 Jan 2010 22:19:33 +0300, Eugene wrote:
<...>
Thank you, Dominic and Enrico, for your opinions. I have a little patch to fix this issue (attached).
As an alternative, I have a completely rewritten `load_startup_files' function. I wrote it to understand all the conditions which were in the original implementation. My function is *MUCH* more verbose, but I think it can be easier to understand and modify. I *DID NOT TEST* it, so consider it to be a sketch. Enrico, if you like this implementation, I can test and update it, so it can be safely committed.
Cool!
I need to know which way (the little patch or the rewritten function) is accepted as my future questions may require further modifications of `load_startup_files'.
I do like your rewritten function more as it is more clear and more structured. I didn't test it as well yet but I think we should use it. If you don't have more changes it for now, I'll test and commit it then.Thanks!!
No, I don't have more changes for now. I tested the function a bit today, it works as expected (like the version in current trunk except the little bug with -s option fixed). The only change I made is that I merged two comment lines into one :) So you can use either the function code from my previous post or the attached patch.
Before you commit, I'd like to know how the changes would go to "sm" branch. It is not so important for me (as I use a local Git repository anyway), but it could be important for the one who will commit my patches (e.g., probably Nick). Will it be done using SVN merge, or will there be separate commits (same patches applied to different branches)?
I just added you to the project at Sourceforge, so you have SVN write access.
Just commit this patch and your other pending patches into the SM branch. This way the patches don't get lost and will make review/testing easier. When you are done and things seem to work, we can merge the branch into trunk.
Just be sure to follow our coding styles where possible (see HACKING), this would reduce additional work when merging the changes but I guess this is pretty obvious :).
Thanks again for your efforts!
Regards, Enrico
On Sun, 24 Jan 2010 14:36:53 +0100% Enrico Tröger enrico.troeger@uvena.de wrote:
On Mon, 18 Jan 2010 17:17:02 +0300, Eugene wrote:
<...>
Before you commit, I'd like to know how the changes would go to "sm" branch. It is not so important for me (as I use a local Git repository anyway), but it could be important for the one who will commit my patches (e.g., probably Nick). Will it be done using SVN merge, or will there be separate commits (same patches applied to different branches)?
I just added you to the project at Sourceforge, so you have SVN write access.
Just commit this patch and your other pending patches into the SM branch. This way the patches don't get lost and will make review/testing easier. When you are done and things seem to work, we can merge the branch into trunk.
Okay. I'll have time to finish it during the next week.
Just be sure to follow our coding styles where possible (see HACKING), this would reduce additional work when merging the changes but I guess this is pretty obvious :).
Okay.
Best regards, Eugene.
Hi all. Another bunch of questions is here.
1. If user opens a project, all other filenames passed via command-line are ignored (see main.c:load_startup_files()). Why?
2. There is a related bug-report: [1]. Currently a command like "geany file.txt" does not open default session. I think the proposed behaviour (default session SHOULD be opened) is better.
With current version it's impossible to force the session to be opened, while with proposed behaviour everything is simple: if you want the session to be opened, type "geany file.txt"; if you don't, type "geany -s file.txt".
To be precise, with current version default session IS opened, but its files not. That means, the default session is overwritten after Geany is closed. A user may not like that (like any other unpredictable destructive behaviour).
The new behaviour is backward-incompatible, so maybe(?) it's worth providing a hidden option to turn on the new behaviour, like Nick suggested in the comments to the bug-report.
Any thoughts? If anyone votes for the new behaviour, I can implement it (in SM branch).
[1] http://sourceforge.net/tracker/index.php?func=detail&aid=2838686&group_id=153444&atid=787791
Best regards, Eugene.
On Sun, 7 Feb 2010 12:40:28 +0300, Eugene wrote:
Heya,
- If user opens a project, all other filenames passed via command-line
are ignored (see main.c:load_startup_files()). Why?
I guess the reason was related to the current behaviour you described below. Otherwise, I'm not sure.
- There is a related bug-report: [1]. Currently a command like "geany
file.txt" does not open default session. I think the proposed behaviour (default session SHOULD be opened) is better.
With current version it's impossible to force the session to be opened, while with proposed behaviour everything is simple: if you want the session to be opened, type "geany file.txt"; if you don't, type "geany -s file.txt".
To be precise, with current version default session IS opened, but its files not. That means, the default session is overwritten after Geany is closed. A user may not like that (like any other unpredictable destructive behaviour).
The new behaviour is backward-incompatible, so maybe(?) it's worth providing a hidden option to turn on the new behaviour, like Nick suggested in the comments to the bug-report.
Any thoughts? If anyone votes for the new behaviour, I can implement it (in SM branch).
I don't mind much but having a preferences (even a GUI pref) probably won't hurt and if you like to implement it in your branch, even better (maybe just skip the GUI pref part for now).
Other opinions?
Regards, Enrico
Hi,
Enrico Tröger a écrit :
On Sun, 7 Feb 2010 12:40:28 +0300, Eugene wrote:
Heya,
- If user opens a project, all other filenames passed via command-line
are ignored (see main.c:load_startup_files()). Why?
I guess the reason was related to the current behaviour you described below. Otherwise, I'm not sure.
It would be cool IMO that it simply open the other files in the project, I would use this sometimes. And I don't think it changes anything to the users that don't want this.
- There is a related bug-report: [1]. Currently a command like "geany
file.txt" does not open default session. I think the proposed behaviour (default session SHOULD be opened) is better.
With current version it's impossible to force the session to be opened, while with proposed behaviour everything is simple: if you want the session to be opened, type "geany file.txt"; if you don't, type "geany -s file.txt".
To be precise, with current version default session IS opened, but its files not. That means, the default session is overwritten after Geany is closed. A user may not like that (like any other unpredictable destructive behaviour).
The new behaviour is backward-incompatible, so maybe(?) it's worth providing a hidden option to turn on the new behaviour, like Nick suggested in the comments to the bug-report.
Any thoughts? If anyone votes for the new behaviour, I can implement it (in SM branch).
I don't mind much but having a preferences (even a GUI pref) probably won't hurt and if you like to implement it in your branch, even better (maybe just skip the GUI pref part for now).
Other opinions?
I'm completely with this. I was always annoyed by the behavior of "geany file" not opening the default session. Why? mostly because sometimes I just want to open a file with Geany, and I don't remember/realize/pay attention that Geany is not already opened, and as I strongly use the default session, I need to reopen some files manually that would have been reopened automatically by the session.
Ah, and another thing on the topic (or close to): I think that the default session should probably NOT be saved if a project is opened. Why? because: 1) It is probably useless: the list of opened files is already stored in the project, no need to save it twice. 2) I often have more than one instance of Geany opened: one with the default session (for small stuff unrelated to a specific project, or to too small projects to need a project file, or for every file I need to edit and close just after that, etc.) and one or more with a project opened. I'm used to close the Geany's instances in the right order - the projects, then the default session - but sometimes I do it wrong, and then I loose my default session to something I have already in a project file.
But about the preference to choose the behavior, I don't thing it would be useful. I don't see any case where it makes sense: if a user won't the session to be restored at startup, she just have to uncheck the preference that already exist and she's done.
Regards, Colomban
Hi guys. Thank you for the feedback.
On Sun, 07 Feb 2010 20:40:18 +0100% Colomban Wendling lists.ban@herbesfolles.org wrote:
Hi,
Enrico Tröger a écrit :
On Sun, 7 Feb 2010 12:40:28 +0300, Eugene wrote:
Heya,
- If user opens a project, all other filenames passed via
command-line are ignored (see main.c:load_startup_files()). Why?
I guess the reason was related to the current behaviour you described below. Otherwise, I'm not sure.
It would be cool IMO that it simply open the other files in the project, I would use this sometimes. And I don't think it changes anything to the users that don't want this.
I completely agree here.
- There is a related bug-report: [1]. Currently a command like
"geany file.txt" does not open default session. I think the proposed behaviour (default session SHOULD be opened) is better.
With current version it's impossible to force the session to be opened, while with proposed behaviour everything is simple: if you want the session to be opened, type "geany file.txt"; if you don't, type "geany -s file.txt".
To be precise, with current version default session IS opened, but its files not. That means, the default session is overwritten after Geany is closed. A user may not like that (like any other unpredictable destructive behaviour).
The new behaviour is backward-incompatible, so maybe(?) it's worth providing a hidden option to turn on the new behaviour, like Nick suggested in the comments to the bug-report.
Any thoughts? If anyone votes for the new behaviour, I can implement it (in SM branch).
I don't mind much but having a preferences (even a GUI pref) probably won't hurt and if you like to implement it in your branch, even better (maybe just skip the GUI pref part for now).
Other opinions?
I'm completely with this. I was always annoyed by the behavior of "geany file" not opening the default session. Why? mostly because sometimes I just want to open a file with Geany, and I don't remember/realize/pay attention that Geany is not already opened, and as I strongly use the default session, I need to reopen some files manually that would have been reopened automatically by the session.
Okay, I wrote a sketch for it, even with a GUI preference: [1]. If you have a better label for this option, tell me :)
Ah, and another thing on the topic (or close to): I think that the default session should probably NOT be saved if a project is opened. Why? because:
- It is probably useless: the list of opened files is already stored
in the project, no need to save it twice. 2) I often have more than one instance of Geany opened: one with the default session (for small stuff unrelated to a specific project, or to too small projects to need a project file, or for every file I need to edit and close just after that, etc.) and one or more with a project opened. I'm used to close the Geany's instances in the right order - the projects, then the default session - but sometimes I do it wrong, and then I loose my default session to something I have already in a project file.
Enrico and me discussed the behaviour of --new-instance command line option not so long ago. We decided that instances run with --new-instance should not ever touch the default session. AFAIR, in current trunk this option causes Geany not to load the session. In my version it also causes Geany not to save the session. The version in SM branch *partially* implements the behaviour: when I wrote the corresponding patch, I did not think about projects, so projects are not handled properly. Recently I coded the behaviour completely, the changes are ready to be committed.
But about the preference to choose the behavior, I don't thing it would be useful. I don't see any case where it makes sense: if a user won't the session to be restored at startup, she just have to uncheck the preference that already exist and she's done.
Me too. But we can't be sure that there are no users who wants the old behaviour. The way how other people use Geany may differ from ours… I think we need more opinions.
Also, It is easy to code the GUI preference, and the preference makes no harm to users (except they have to read one more label in the dialog) -- not a very high price for being compatible with older versions. So, we can keep the option until we are sure that it can be safely removed and almost nobody will complain.
Enrico: another bunch of commits are ready. They are:
* Use absolute paths to project files. Particularly, paths to recent projects' files are now stored as absolute.
* Make --new-instance imply --no-session, even if a project is opened. An addition to rev. 4567.
* Load files from command line even if a project is being opened.
* Add a GUI preference to control whether the default session is loaded if any files are opened via command-line (fix #2838686). Location of the preference: General > Startup tab > Startup frame.
Relative paths to projects' files were a little trouble for me. When I run Geany within the source tree for testing, passing a project, Geany remembered it, so now my Recent Projects menu is full of the same project file with different relative paths :)
What do you think? Can these be committed (together with updated changelog, of course)?
[1] http://xmages.net/upload/ff71e4ee.png
Best regards, Eugene.
On Mon, 8 Feb 2010 20:58:06 +0300, Eugene wrote:
Hey,
I'm completely with this. I was always annoyed by the behavior of "geany file" not opening the default session. Why? mostly because sometimes I just want to open a file with Geany, and I don't remember/realize/pay attention that Geany is not already opened, and as I strongly use the default session, I need to reopen some files manually that would have been reopened automatically by the session.
Okay, I wrote a sketch for it, even with a GUI preference: [1]. If you have a better label for this option, tell me :)
Don't worry about the label, we can improve it also at any later point.
Enrico: another bunch of commits are ready. They are:
- Use absolute paths to project files. Particularly, paths to recent
projects' files are now stored as absolute.
- Make --new-instance imply --no-session, even if a project is opened.
An addition to rev. 4567.
Load files from command line even if a project is being opened.
Add a GUI preference to control whether the default session is loaded
if any files are opened via command-line (fix #2838686). Location of the preference: General > Startup tab > Startup frame.
Relative paths to projects' files were a little trouble for me. When I run Geany within the source tree for testing, passing a project, Geany remembered it, so now my Recent Projects menu is full of the same project file with different relative paths :)
What do you think? Can these be committed (together with updated changelog, of course)?
Sure, it's your branch which is meant to be your place to get your code in :).
Regards, Enrico
On Sat, 13 Feb 2010 16:22:34 +0100% Enrico Tröger enrico.troeger@uvena.de wrote:
Okay, I wrote a sketch for it, even with a GUI preference: [1]. If you have a better label for this option, tell me :)
Don't worry about the label, we can improve it also at any later point.
Okay.
Enrico: another bunch of commits are ready. They are:
[snip]
Sure, it's your branch which is meant to be your place to get your code in :).
Committed.
Best regards, Eugene.
On Sun, 07 Feb 2010 20:40:18 +0100% Colomban Wendling lists.ban@herbesfolles.org wrote:
Ah, and another thing on the topic (or close to): I think that the default session should probably NOT be saved if a project is opened. Why? because:
- It is probably useless: the list of opened files is already stored
in the project, no need to save it twice. 2) I often have more than one instance of Geany opened: one with the default session (for small stuff unrelated to a specific project, or to too small projects to need a project file, or for every file I need to edit and close just after that, etc.) and one or more with a project opened. I'm used to close the Geany's instances in the right order - the projects, then the default session - but sometimes I do it wrong, and then I loose my default session to something I have already in a project file.
Just an addition to my previous answer [1]. With current version of Geany (ordinary, not from SM branch), when you open a new Geany instance using --new-instance (or -i), you can also pass --no-session (-s) and the instance won't touch the session. I often use this option myself (my "workflow" is similar to yours).
[1] http://lists.uvena.de/geany-devel/2010-February/001715.html
Best regards, Eugene.
Hi,
Eugene Arshinov a écrit :
Just an addition to my previous answer [1]. With current version of Geany (ordinary, not from SM branch), when you open a new Geany instance using --new-instance (or -i), you can also pass --no-session (-s) and the instance won't touch the session. I often use this option myself (my "workflow" is similar to yours).
[1] http://lists.uvena.de/geany-devel/2010-February/001715.html
Very strange… if I use -s together with -i, the files in my project are not loaded at all (it opens an empty geany window), and no error is reported or unexpected message appears with -v. However, the project is correctly saved. I don't have this problem with out -s.
Is this a bug of my build (unmodified SVN r4691, then very unlikely) or the expected behavior?
If it is related, note that I don't use geanyprj but the built-in project support.
Regards, Colomban
Hi.
On Mon, 22 Feb 2010 20:17:16 +0100% Colomban Wendling lists.ban@herbesfolles.org wrote:
Hi,
Eugene Arshinov a écrit :
Just an addition to my previous answer [1]. With current version of Geany (ordinary, not from SM branch), when you open a new Geany instance using --new-instance (or -i), you can also pass --no-session (-s) and the instance won't touch the session. I often use this option myself (my "workflow" is similar to yours).
[1] http://lists.uvena.de/geany-devel/2010-February/001715.html
Very strange… if I use -s together with -i, the files in my project are not loaded at all (it opens an empty geany window), and no error is reported or unexpected message appears with -v. However, the project is correctly saved. I don't have this problem with out -s.
Is this a bug of my build (unmodified SVN r4691, then very unlikely) or the expected behavior?
If it is related, note that I don't use geanyprj but the built-in project support.
This is a known bug, already discussed at geany-devel: [1]. It is fixed in SM branch (which, I hope, will be soon finished and ready for merging into trunk).
[1] http://lists.uvena.de/geany-devel/2010-January/001655.html
Best regards, Eugene.
Hi all. Here is the last question.
Preface. Currently if the first filename passed via command-line has ".geany" extension, it's opened as a project. If I implement project support in SM using this behaviour, there will be a little trouble.
The trouble. Suppose a user has neither default session not a project opened (example: "geany -s"), and he opens a project file to edit it manually. Then if he logs out without closing Geany, my SM code has to store opened files in restart command like "geany -s edited_proj.geany". You see what happens after that when Geany is restarted.
A solution. Provide a separate command-line option to open a project (e.g., "--project" or "-r" as "-p" is reserved for "--no-plugins"). This behaviour is more convenient and it eliminates the problem completely.
Absence of compatibility (1). BUT current behaviour is rather old and users may be familiar with it. Maybe(?) it is acceptable to drop that behaviour completely and tell all users about it (is there a way to do it? I believe that most of users are not subscribed to Geany mailing list). If it isn't acceptable, see below.
Making it compatible (2). Geany instance has some means to know whether it's run by a user or being restarted (via hidden command-line option I introduced to support XSMP). If an instance if being restarted, it is completely safe to disable the old behaviour and enable the new one. That solves the problem.
Removing the old behaviour (3). From my point of view, it is not comfortable to maintain two variations of handling command-line options (though the difference between them is little). Maybe(?) it is acceptable to keep the old behaviour in the next version (say, 0.19), but issue a warning to stderr when the old behaviour is used, and remove the old behaviour some time after that (say, in 0.20).
Conclusion. If (1) is acceptable, I'd prefer to implement (1). Otherwise, I'd like to implement (3).
Questions. Is (1) acceptable? Any other opinions?
Best regards, Eugene.
Hey Eugene,
Am Montag, den 15.02.2010, 14:12 +0300 schrieb Eugene Arshinov:
Hi all. Here is the last question.
Preface. Currently if the first filename passed via command-line has ".geany" extension, it's opened as a project. If I implement project support in SM using this behaviour, there will be a little trouble.
The trouble. Suppose a user has neither default session not a project opened (example: "geany -s"), and he opens a project file to edit it manually. Then if he logs out without closing Geany, my SM code has to store opened files in restart command like "geany -s edited_proj.geany". You see what happens after that when Geany is restarted.
A solution. Provide a separate command-line option to open a project (e.g., "--project" or "-r" as "-p" is reserved for "--no-plugins"). This behaviour is more convenient and it eliminates the problem completely.
Absence of compatibility (1). BUT current behaviour is rather old and users may be familiar with it. Maybe(?) it is acceptable to drop that behaviour completely and tell all users about it (is there a way to do it? I believe that most of users are not subscribed to Geany mailing list). If it isn't acceptable, see below.
I think it would be acceptable, even if compatibility is nicer. We have mailing lists, IRC channel and release notes where users can hear about any change. If there would be still a user who gets confused, he should subscribe to the mailing list and ask or at least file a bug at the sf tracker and hear about the change that way. I think that would be okay.
Making it compatible (2). Geany instance has some means to know whether it's run by a user or being restarted (via hidden command-line option I introduced to support XSMP). If an instance if being restarted, it is completely safe to disable the old behaviour and enable the new one. That solves the problem.
I tend to drop the old behaviour as written above. But let's wait for other opinions. Maybe the compatibility is the better solution.
Removing the old behaviour (3). From my point of view, it is not comfortable to maintain two variations of handling command-line options (though the difference between them is little). Maybe(?) it is acceptable to keep the old behaviour in the next version (say, 0.19), but issue a warning to stderr when the old behaviour is used, and remove the old behaviour some time after that (say, in 0.20).
That's the way I'd also prefer about compatibility, since it's just a "smoother" (1). :)
Regs, Dominic
On Mon, 15 Feb 2010 14:12:48 +0300, Eugene wrote:
Hi all. Here is the last question.
Preface. Currently if the first filename passed via command-line has ".geany" extension, it's opened as a project. If I implement project support in SM using this behaviour, there will be a little trouble.
The trouble. Suppose a user has neither default session not a project opened (example: "geany -s"), and he opens a project file to edit it manually. Then if he logs out without closing Geany, my SM code has to store opened files in restart command like "geany -s edited_proj.geany". You see what happens after that when Geany is restarted.
A solution. Provide a separate command-line option to open a project (e.g., "--project" or "-r" as "-p" is reserved for "--no-plugins"). This behaviour is more convenient and it eliminates the problem completely.
Absence of compatibility (1). BUT current behaviour is rather old and users may be familiar with it. Maybe(?) it is acceptable to drop that behaviour completely and tell all users about it (is there a way to do it? I believe that most of
No, not really. As Dominic said, we have the mailing lists, IRC and as a last resort the release notes. But there is no way to really tell all users about any changes. I'm afraid almost nobody really reads the release notes at all. But still, this shouldn't prevent us from going further...
Conclusion. If (1) is acceptable, I'd prefer to implement (1). Otherwise, I'd like to implement (3).
Questions. Is (1) acceptable? Any other opinions?
I prefer solution 1 as well. Yes, compatibility would be nicer but in this case it might be not that important and so not worth.
Regards, Enrico
Hi.
On Sun, 21 Feb 2010 14:55:16 +0100% Enrico Tröger enrico.troeger@uvena.de wrote:
On Mon, 15 Feb 2010 14:12:48 +0300, Eugene wrote:
Hi all. Here is the last question.
Preface. Currently if the first filename passed via command-line has ".geany" extension, it's opened as a project. If I implement project support in SM using this behaviour, there will be a little trouble.
The trouble. Suppose a user has neither default session not a project opened (example: "geany -s"), and he opens a project file to edit it manually. Then if he logs out without closing Geany, my SM code has to store opened files in restart command like "geany -s edited_proj.geany". You see what happens after that when Geany is restarted.
A solution. Provide a separate command-line option to open a project (e.g., "--project" or "-r" as "-p" is reserved for "--no-plugins"). This behaviour is more convenient and it eliminates the problem completely.
Absence of compatibility (1). BUT current behaviour is rather old and users may be familiar with it. Maybe(?) it is acceptable to drop that behaviour completely and tell all users about it (is there a way to do it? I believe that most of
No, not really. As Dominic said, we have the mailing lists, IRC and as a last resort the release notes. But there is no way to really tell all users about any changes. I'm afraid almost nobody really reads the release notes at all. But still, this shouldn't prevent us from going further...
Conclusion. If (1) is acceptable, I'd prefer to implement (1). Otherwise, I'd like to implement (3).
Questions. Is (1) acceptable? Any other opinions?
I prefer solution 1 as well. Yes, compatibility would be nicer but in this case it might be not that important and so not worth.
Okay, I've just implemented and committed (1). Actually, I'm glad I didn't need to spend more time to implement (3). :)
SM branch seems to be complete. Everybody is welcome for testing, especially with "Preferences -> General -> Misc -> Use project-based session files" check button unchecked; I don't know what it does and whether it can really infect project-related behaviour I changed.
Best regards, Eugene.
On Tue, 23 Feb 2010 01:17:05 +0300 Eugene Arshinov earshinov@gmail.com wrote:
SM branch seems to be complete. Everybody is welcome for testing, especially with "Preferences -> General -> Misc -> Use project-based session files" check button unchecked; I don't know what it does...
First, it stores the list of open files in your project file. In particular, when you exit Geany, the list is stored in the project file and not in geany.conf.
Then, when you open a project, geany closes all currently open files and loads the files from the the project.
...and whether it can really infect project-related behaviour I changed.
With this option turned on, and a project open, SM should probably save the project, and store a single SmPropValue "project.geany" in the properties instead of the full list of open files.
Why such an option exists is not entirely1 clear to me. In the other development environments/editors I've seen, opening a project always loads it's files, with or without a quetsion whether to close the currently open files (if they're not in a project).
-- E-gards: Jimmy
Hi.
On Tue, 23 Feb 2010 19:45:50 +0300% Dimitar Zhekov hamster@mbox.contact.bg wrote:
On Tue, 23 Feb 2010 01:17:05 +0300 Eugene Arshinov earshinov@gmail.com wrote:
SM branch seems to be complete. Everybody is welcome for testing, especially with "Preferences -> General -> Misc -> Use project-based session files" check button unchecked; I don't know what it does...
First, it stores the list of open files in your project file. In particular, when you exit Geany, the list is stored in the project file and not in geany.conf.
Then, when you open a project, geany closes all currently open files and loads the files from the the project.
Hmm..., here you describe the behaviour when that check button is *checked*, right? I have it checked too, so I know this behaviour. I didn't know what Geany do when the button is unchecked.
...and whether it can really infect project-related behaviour I changed.
With this option turned on, and a project open, SM should probably save the project, and store a single SmPropValue "project.geany" in the properties instead of the full list of open files.
Yes, when the button is checked, remembering the opened project is enough. Actually, that's how it's already implemented (committed to SM recently).
Why such an option exists is not entirely1 clear to me. In the other development environments/editors I've seen, opening a project always loads it's files, with or without a quetsion whether to close the currently open files (if they're not in a project).
Same for me. But, discussing whether this option is needed or not and cutting it out if it isn't needed would require more efforts than enhancing SM to work properly whether the button is checked or not :-)
Best regards, Eugene.
On Tue, 23 Feb 2010 21:58:38 +0300 Eugene Arshinov earshinov@gmail.com wrote:
Hmm..., here you describe the behaviour when that check button is *checked*, right? I have it checked too, so I know this behaviour. I didn't know what Geany do when the button is unchecked.
Sorry, I should have been more careful.
Why such an option exists is not entirely1 clear to me. In the other development environments/editors I've seen, opening a project always loads it's files, with or without a quetsion whether to close the currently open files (if they're not in a project).
Same for me. But, discussing whether this option is needed or not and cutting it out if it isn't needed would require more efforts than enhancing SM to work properly whether the button is checked or not :-)
Now that I think of it, with "Project Based Session Files" always on, and when no project is open, on "Save Yourself" geany SM could create a <smclientid>.geany file in the session directory and store the file list there. Then, if Geany is started with a smclientid argument, but without a project name, it can check for such a file and load it.
There won't be any ambiguity what files to load on startup, and the SM support will be based on the Geany session support, so that cursor positions in the different files, any explicitly selected file types, any Read only flags etc. will be restored - something that can't be achieved by storing the file names on the command line.
-- E-gards: Jimmy
On Tue, 23 Feb 2010 22:48:46 +0300% Dimitar Zhekov hamster@mbox.contact.bg wrote:
On Tue, 23 Feb 2010 21:58:38 +0300 Eugene Arshinov earshinov@gmail.com wrote:
Hmm..., here you describe the behaviour when that check button is *checked*, right? I have it checked too, so I know this behaviour. I didn't know what Geany do when the button is unchecked.
Sorry, I should have been more careful.
Why such an option exists is not entirely1 clear to me. In the other development environments/editors I've seen, opening a project always loads it's files, with or without a quetsion whether to close the currently open files (if they're not in a project).
Same for me. But, discussing whether this option is needed or not and cutting it out if it isn't needed would require more efforts than enhancing SM to work properly whether the button is checked or not :-)
Now that I think of it, with "Project Based Session Files" always on, and when no project is open, on "Save Yourself" geany SM could create a <smclientid>.geany file in the session directory and store the file list there. Then, if Geany is started with a smclientid argument, but without a project name, it can check for such a file and load it.
There won't be any ambiguity what files to load on startup, and the SM support will be based on the Geany session support, so that cursor positions in the different files, any explicitly selected file types, any Read only flags etc. will be restored - something that can't be achieved by storing the file names on the command line.
Storing file list in a file is an option, but it is more difficult then using the command line. If one needs to implement enhancements like saving cursor position, she would have no choice, but I have no such plans (and other developers either, I think). Moreover, using command-line reveals some troubles with Geany's project handling, and that's good as otherwise these troubles could remain unnoticed for a long time.
Best regards, Eugene.
On Tue, 2 Mar 2010 16:14:29 +0300 Eugene Arshinov earshinov@gmail.com wrote:
[...] Now that I think of it, with "Project Based Session Files" always on, and when no project is open, on "Save Yourself" geany SM could create a <smclientid>.geany file in the session directory and store the file list there. [...]
Storing file list in a file is an option, but it is more difficult then using the command line. [...]
That was an older idea. If the session save is to restore everything as precisely as possible, I believe the different .conf files are the way to go. But following the thread, that seems unlikely to be implemented.
-- E-gards: Jimmy
On Tue, 23 Feb 2010 01:17:05 +0300% Eugene Arshinov earshinov@gmail.com wrote:
SM branch seems to be complete.
That was a premature conclusion. While testing SM today, I discovered a serious issue that needs discussion. I'll post a separate message for that.
Everybody is welcome for testing, especially with "Preferences -> General -> Misc -> Use project-based session files" check button unchecked; I don't know what it does and whether it can really infect project-related behaviour I changed.
I had some time to test this check button tomorrow. Now I understand how it works, and there is only one issue that prevents enhancing SM so it works properly regardless of the button.
The issue is that files from the default session are always opened when Geany is run with --new-instance option and a project. Suppose the default session contains "1.txt". Then
"geany -i --project a.geany" opens 1.txt; "geany -i --project a.geany 2.txt 3.txt" opens 1.txt, 2.txt, 3.txt;
while
"geany -i" opens nothing "geany -i 2.txt 3.txt" opens 2.txt, 3.txt
You see, it is even inconsistent and meaningless, which itself is a sufficient reason to fix this.
How it prevents enhancing SM? Suppose you have a "geany" with 1.txt opened and "geany -i" with a.geany project and 2.txt and 3.txt files. There is no way to prevent 1.txt from being opened in "geany -i --project=a.geany -- 2.txt 3.txt" after restart, as the default session is always loaded.
The solution is straightforward: do not open the default session when --new-instance is specified, whether a project is being opened or not.
I'm going to commit the fix and SM enhancement quite soon.
Best regards, Eugene.