Re: [Geany-devel] Separating session file lists from config (again)
On 2 October 2012 00:43, Colomban Wendling wrote:
> Le 10/09/2012 06:36, Lex Trotman a écrit :
> > Hi All,
> >
> > Its about that time of year when we have our annual discussion on
> > separating session data from config/project data :)
> >
> > By session data I mean the list of currently open files and MRU list.
> >
> > The advantages (that I can see):
> >
> > 1. Save config/project as its changed and not rushed at quit time (and
> > the quit save doesn't happen in the absence of a working, portable,
> > session management capability)
>
> TBH until proper multi-instance configuration sharing, I don't see
> what's so great with "not rushing at quit time" since we already also
> save one pref/project-prefs apply.
>
Are all settings saved on apply? not just the prefs/project prefs ones? I
thought there were some that still didn't for one reason or another, maybe
that should be changed as a separate thing anyway, in which case you are
right, the "rush" only applies to session data.
>
> > 2. Save session data periodically, or as it changes, or whenever,
> > without touching the config/project files. So the config isn't at
> > risk if the session save goes wrong.
>
> Why would the session save go wrong? There is no reason I can think of
> that would make periodical session saving less safe than settings saving.
>
Read "not happen" for "go wrong" then. Not happening because Geany is
killed by the WM/user is the most common way saving settings/sessions goes
wrong. If the save happens its unlikely to be a problem so long as its on a
local disk which isn't full. If the project file is on a network share or
worse still, on a ftpfs/sshfs/httpfs file system then lots can "go wrong"
and the chances are increased by periodic saving (not to mention potential
performance issues).
>
> > The only disadvantage for user config (that I can see) is that it adds
> > one file, say geany.session.conf alongside geany.conf
>
> That's definitely not a problem in the $GEANY_CONF_DIR.
>
Agree, but I had to think of *some* disadvantage to seem fair and even
handed :)
>
> > For project sessions just using another file in the same place as the
> > project file is more of a problem since project files can be in the
> > project tree and some people like to save them in VCS. So users would
> > have to make sure that their git.ignore (or whatever the other VCSes
> > use) is edited each time so that the session file isn't saved in the
> > VCS.
>
> I agree with Dimitar, if somebody is able to add a file to a VCS she
> must be able *not* to add that file. Is there *any* VCS around that
> adds files without asking before, unless explicitly told so? Nobody
> sane will do `git add .` or `svn add .` for committing changes.
>
Well, git add is part of the normal workflow, editing .gitignore isn't.
But I guess if the project file is being stored in VCS then you would
expect .gitignore (or whatever svn etc use) to be edited already to exclude
.session and .gitignore to be stored in the VCS as well.
>
> > A better option, especially since sessions are inherently user
> > related, is to store them in the user config location (or subdirectory
> > thereof). But how to link these files to the project files?
> >
> > The proposal is that each project gets a UUID generated when it is
> > created (or when its opened without one) which is saved in the project
> > file. This uuid is the name of the session file in the
> > ${GEANY_CONFIG}/sessions directory. That way, when a project is
> > opened, it is easy to uniquely find the session file if it exists.
> > Using things like filenames, project names etc will always have
> > clashes. Libuuid is used by GTK so it will always be available on all
> > platforms we use and so making the UUID is one call. (Pity GTK doesn't
> > expose it though)
> >
> > The number of session files can be left to grow like weeds, or can be
> > trimmed to a (configurable) maximum number deleting the oldest when
> > needed.
>
> PLEASE, no. This is IMO the easiest solution to make the fix worst than
> the issue. Not removing files would leave more and more useless files
> (not an option), and cleaning is almost impossible to do well -- your
> proposition might remove actually used sessions as easily as having >
> MAX_SESSION projects (not an option either).
>
Heh, heh, I was going to just say, sort by access time and delete the
oldest one before creating a new one, but then I remembered that all my
disks are mounted noatime :)
> > This proposal isn't about a proper session management capability,
> > there isn't one that works on enough platforms to be worth including.
> >
> > Any thoughts welcome.
>
> Reading my mail above, I see it might sound like I think $subject is
> just a bad idea. No, I think it would be a quite good thing, and for
> weird people adding project files to their VCS [1] would be most
> welcome. I also think that separating session and settings will
> probably help to someday improve the s
Re: [Geany-devel] PlugIn for Ruby Refactoring / Help overriding callbacks
On 2 October 2012 00:00, Rory Michele wrote: > Hi guys, > > I'm looking for help. To give you my level: I work as a (mostly ruby and > java) programmer and have some experience on that level, but this would > be my first bigger open-source project that I work on. So please be kind ;) > Hi Welcome, > > > I would like to write a geany plugin trying to provide helpful ruby > refactoring (I think thats the word, what I mean is looking up > (possible) declarations and usages), that can extend or replace the > functionality of "go to tag declaration/definition". I wish for that > because the current implementation looks only in open files as far as I > understand and I would like to provide this on a project basis, therefor > scanning also files not currently opened in geany. > Have you looked at both the project plugins, I think one or both do this? > > I know this is very intensiv to provide for ruby, however I'm thinking > to provide it only at explicit wish (e.g. special button), not to bother > the slim and fast design of geany. And as I'm doing the same for > "reverse engineering"/understanding geany right now with grep, I think > it should be possible at reasonable speed, unlike these java > implementations that they scan and index all at the beginning and kill > my memory ;) Now what do you think, is it appropriate to provide this > for geany or is it against a concept or something? > I am not sure I understand what you are proposing, since would your plugin not also "kill your memory" if it scans everything? It just won't do it until you press the magic key. > > The features I currently have in mind: > - a menu-point and keybinding for navigating to possible declarations > - a second mode for auto-completion (maybe pressing space another > time), that looks up possible classes the selected instance is of, to > show only relevant tags for autocompletion > - a menu-point and keybinding for listing possible usages (and the > possibility to navigate there) > Just from a user point of view it might be better if your plugin just replaced the Geany functionality rather than being an additional function, but I guess that can be found by experiment. The only one of the above that might be difficult(ish) is the second mode which seems to depend on a key sequence not a simple binding. Its not impossible, just Geany doesn't do that and so will give you no assistance. Might be better as another keybinding. > > Now the Questions: > I checked the demoplugin so in general I think I have a clue on how to > create the plugin. > Now what seems for me the best way to go would be to simple override the > callbacks for the existing "Go to Definition" etc. keybindings (as the > ui-buttons seem to also be using them). The first relevant key_binding_id I would like to overide the callback > for is GEANY_KEYS_GOTO_TAGDECLARATION. > And it is mapped to a function in keybindings.c on line 1886. > Now, this mapping I would like to overide. Is that possible and how? Or > do I have to create new UI-Elements and link them to my function. I > would not like the latter so much as the global settings for keybindings > wouldn't have effect, wouldn't they? > Hmmm, normally plugins don't override existing keybindings, and there is an argument that they should not set any keybindings until the user selects which ones to use. This is since the user can re-assign keycodes and the plugin can't tell what system or other plugins may be using a particular keycode. Even if it could tell, it would normally be considered to be rude to just splatter over it :( This has been a problem in the past with disagreements between plugins. Normally plugins just add another keybinding section and let the user assign codes, see for instance some of the plugins included with Geany for how to (reasonably) conveniently do this. As I noted above, in this case you may want to replace the normal functionality when your plugin is active, but I'm not sure it is possible at this time and you might have to intercept the keypress and grab it before Geany sees it. That of course adds complexity to your plugin and makes the keybinding preferences settings wrong. Cheers Lex > > Thanks for your help and I'll be happy to clarify any questions > rory > ___ > Geany-devel mailing list > Geany-devel@uvena.de > https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel > ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Separating session file lists from config (again)
Le 02/10/2012 00:26, Matthew Brush a écrit : > On 12-10-01 03:05 PM, Colomban Wendling wrote: >> Le 01/10/2012 23:15, Matthew Brush a écrit : >>> On 12-10-01 07:43 AM, Colomban Wendling wrote: Le 10/09/2012 06:36, Lex Trotman a écrit : > Hi All, > > Its about that time of year when we have our annual discussion on > separating session data from config/project data :) > > By session data I mean the list of currently open files and MRU list. > > The advantages (that I can see): > > 1. Save config/project as its changed and not rushed at quit time (and > the quit save doesn't happen in the absence of a working, portable, > session management capability) TBH until proper multi-instance configuration sharing, I don't see what's so great with "not rushing at quit time" since we already also save one pref/project-prefs apply. >>> >>> Open your favourite project in Geany and open a specific set of files >>> you need to work on a task, get the order of the files just right, >>> adjust the Geany window position and size and then get your find dialogs >>> positioned just perfect on your second screen. Now unplug your computer. >>> You will see :) >>> >>> For me it takes more time to get Geany back in order (finding project >>> file since it's not saved in the recent project list[1], finding open >>> files related to current task, since they aren't saved in recent files >>> list[2], etc.) than it does to restart the whole computer. >>> >>> P.S. My workaround (because my computer crashes a lot due to Flash) is >>> to get everything set up how I want for the current task, and then to >>> close Geany normally to force saving of all settings and then to reopen >>> it :) >> >> As I read Lex's sentence, he spoke about settings, not open files. And >> anyway, I don't see what separating file list from the rest of the >> config change in that matter. It doesn't magically brings >> immediate/periodical saving of the file list, and we can very well save >> everything *including the file list* without that. So I don't see why >> it's an argument in favor (or against) $subject. >> > > It's an argument in favour of "not rushing at quite time" (ie. yes, but I don't see the probably obvious link between "not rushing at quit time" and $subject. > periodically saving the .conf file(s) instead of only on closing) since > you said you didn't see what was so great about it. what I meant is that *we already save when prefs changes* so I don't see what's the problem with saving *also* at quit time. Anyway, I think you got my point, I got yours so there's probably no need to go further in the explanations -- but maybe why $subject helps for that matter. > > Cheers, > Matthew Brush > > ___ > Geany-devel mailing list > Geany-devel@uvena.de > https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Separating session file lists from config (again)
On 12-10-01 03:05 PM, Colomban Wendling wrote: Le 01/10/2012 23:15, Matthew Brush a écrit : On 12-10-01 07:43 AM, Colomban Wendling wrote: Le 10/09/2012 06:36, Lex Trotman a écrit : Hi All, Its about that time of year when we have our annual discussion on separating session data from config/project data :) By session data I mean the list of currently open files and MRU list. The advantages (that I can see): 1. Save config/project as its changed and not rushed at quit time (and the quit save doesn't happen in the absence of a working, portable, session management capability) TBH until proper multi-instance configuration sharing, I don't see what's so great with "not rushing at quit time" since we already also save one pref/project-prefs apply. Open your favourite project in Geany and open a specific set of files you need to work on a task, get the order of the files just right, adjust the Geany window position and size and then get your find dialogs positioned just perfect on your second screen. Now unplug your computer. You will see :) For me it takes more time to get Geany back in order (finding project file since it's not saved in the recent project list[1], finding open files related to current task, since they aren't saved in recent files list[2], etc.) than it does to restart the whole computer. P.S. My workaround (because my computer crashes a lot due to Flash) is to get everything set up how I want for the current task, and then to close Geany normally to force saving of all settings and then to reopen it :) As I read Lex's sentence, he spoke about settings, not open files. And anyway, I don't see what separating file list from the rest of the config change in that matter. It doesn't magically brings immediate/periodical saving of the file list, and we can very well save everything *including the file list* without that. So I don't see why it's an argument in favor (or against) $subject. It's an argument in favour of "not rushing at quite time" (ie. periodically saving the .conf file(s) instead of only on closing) since you said you didn't see what was so great about it. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Separating session file lists from config (again)
Le 01/10/2012 23:15, Matthew Brush a écrit : > On 12-10-01 07:43 AM, Colomban Wendling wrote: >> Le 10/09/2012 06:36, Lex Trotman a écrit : >>> Hi All, >>> >>> Its about that time of year when we have our annual discussion on >>> separating session data from config/project data :) >>> >>> By session data I mean the list of currently open files and MRU list. >>> >>> The advantages (that I can see): >>> >>> 1. Save config/project as its changed and not rushed at quit time (and >>> the quit save doesn't happen in the absence of a working, portable, >>> session management capability) >> >> TBH until proper multi-instance configuration sharing, I don't see >> what's so great with "not rushing at quit time" since we already also >> save one pref/project-prefs apply. >> > > Open your favourite project in Geany and open a specific set of files > you need to work on a task, get the order of the files just right, > adjust the Geany window position and size and then get your find dialogs > positioned just perfect on your second screen. Now unplug your computer. > You will see :) > > For me it takes more time to get Geany back in order (finding project > file since it's not saved in the recent project list[1], finding open > files related to current task, since they aren't saved in recent files > list[2], etc.) than it does to restart the whole computer. > > P.S. My workaround (because my computer crashes a lot due to Flash) is > to get everything set up how I want for the current task, and then to > close Geany normally to force saving of all settings and then to reopen > it :) As I read Lex's sentence, he spoke about settings, not open files. And anyway, I don't see what separating file list from the rest of the config change in that matter. It doesn't magically brings immediate/periodical saving of the file list, and we can very well save everything *including the file list* without that. So I don't see why it's an argument in favor (or against) $subject. > > Cheers, > Matthew Brush > > [1] Well for favourite projects it might be saved, but not if it's a new > project that hasn't experienced a closing before. > > [2] Unless you count the lame GTK+ open dialog recent files list which > is quite useless. > ___ > Geany-devel mailing list > Geany-devel@uvena.de > https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Separating session file lists from config (again)
On 12-10-01 07:43 AM, Colomban Wendling wrote: Le 10/09/2012 06:36, Lex Trotman a écrit : Hi All, Its about that time of year when we have our annual discussion on separating session data from config/project data :) By session data I mean the list of currently open files and MRU list. The advantages (that I can see): 1. Save config/project as its changed and not rushed at quit time (and the quit save doesn't happen in the absence of a working, portable, session management capability) TBH until proper multi-instance configuration sharing, I don't see what's so great with "not rushing at quit time" since we already also save one pref/project-prefs apply. Open your favourite project in Geany and open a specific set of files you need to work on a task, get the order of the files just right, adjust the Geany window position and size and then get your find dialogs positioned just perfect on your second screen. Now unplug your computer. You will see :) For me it takes more time to get Geany back in order (finding project file since it's not saved in the recent project list[1], finding open files related to current task, since they aren't saved in recent files list[2], etc.) than it does to restart the whole computer. P.S. My workaround (because my computer crashes a lot due to Flash) is to get everything set up how I want for the current task, and then to close Geany normally to force saving of all settings and then to reopen it :) Cheers, Matthew Brush [1] Well for favourite projects it might be saved, but not if it's a new project that hasn't experienced a closing before. [2] Unless you count the lame GTK+ open dialog recent files list which is quite useless. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Separating session file lists from config (again)
Le 10/09/2012 06:36, Lex Trotman a écrit :
> Hi All,
>
> Its about that time of year when we have our annual discussion on
> separating session data from config/project data :)
>
> By session data I mean the list of currently open files and MRU list.
>
> The advantages (that I can see):
>
> 1. Save config/project as its changed and not rushed at quit time (and
> the quit save doesn't happen in the absence of a working, portable,
> session management capability)
TBH until proper multi-instance configuration sharing, I don't see
what's so great with "not rushing at quit time" since we already also
save one pref/project-prefs apply.
> 2. Save session data periodically, or as it changes, or whenever,
> without touching the config/project files. So the config isn't at
> risk if the session save goes wrong.
Why would the session save go wrong? There is no reason I can think of
that would make periodical session saving less safe than settings saving.
> The only disadvantage for user config (that I can see) is that it adds
> one file, say geany.session.conf alongside geany.conf
That's definitely not a problem in the $GEANY_CONF_DIR.
> For project sessions just using another file in the same place as the
> project file is more of a problem since project files can be in the
> project tree and some people like to save them in VCS. So users would
> have to make sure that their git.ignore (or whatever the other VCSes
> use) is edited each time so that the session file isn't saved in the
> VCS.
I agree with Dimitar, if somebody is able to add a file to a VCS she
must be able *not* to add that file. Is there *any* VCS around that
adds files without asking before, unless explicitly told so? Nobody
sane will do `git add .` or `svn add .` for committing changes.
> A better option, especially since sessions are inherently user
> related, is to store them in the user config location (or subdirectory
> thereof). But how to link these files to the project files?
>
> The proposal is that each project gets a UUID generated when it is
> created (or when its opened without one) which is saved in the project
> file. This uuid is the name of the session file in the
> ${GEANY_CONFIG}/sessions directory. That way, when a project is
> opened, it is easy to uniquely find the session file if it exists.
> Using things like filenames, project names etc will always have
> clashes. Libuuid is used by GTK so it will always be available on all
> platforms we use and so making the UUID is one call. (Pity GTK doesn't
> expose it though)
>
> The number of session files can be left to grow like weeds, or can be
> trimmed to a (configurable) maximum number deleting the oldest when
> needed.
PLEASE, no. This is IMO the easiest solution to make the fix worst than
the issue. Not removing files would leave more and more useless files
(not an option), and cleaning is almost impossible to do well -- your
proposition might remove actually used sessions as easily as having >
MAX_SESSION projects (not an option either).
> This proposal isn't about a proper session management capability,
> there isn't one that works on enough platforms to be worth including.
>
> Any thoughts welcome.
Reading my mail above, I see it might sound like I think $subject is
just a bad idea. No, I think it would be a quite good thing, and for
weird people adding project files to their VCS [1] would be most
welcome. I also think that separating session and settings will
probably help to someday improve the settings sharing between instances.
The only problem is that I don't see immediate and tremendous gain, and
that I don't like the proposed solution -- not that I have a better one.
On the first point, I'd be happy to be proven wrong though, maybe I
just don't see the light.
Regards,
Colomban
[1] Yes, I don't really see the point. OK, the settings we have in
project files might be useful for the project. Indentation type & with,
and EOL style. First two are saved in each file by well known editors
(vim, emacs). Generally when people put project files in their VCS it's
because those project files are used as build system too.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] PlugIn for Ruby Refactoring / Help overriding callbacks
Hi guys, I'm looking for help. To give you my level: I work as a (mostly ruby and java) programmer and have some experience on that level, but this would be my first bigger open-source project that I work on. So please be kind ;) I would like to write a geany plugin trying to provide helpful ruby refactoring (I think thats the word, what I mean is looking up (possible) declarations and usages), that can extend or replace the functionality of "go to tag declaration/definition". I wish for that because the current implementation looks only in open files as far as I understand and I would like to provide this on a project basis, therefor scanning also files not currently opened in geany. I know this is very intensiv to provide for ruby, however I'm thinking to provide it only at explicit wish (e.g. special button), not to bother the slim and fast design of geany. And as I'm doing the same for "reverse engineering"/understanding geany right now with grep, I think it should be possible at reasonable speed, unlike these java implementations that they scan and index all at the beginning and kill my memory ;) Now what do you think, is it appropriate to provide this for geany or is it against a concept or something? The features I currently have in mind: - a menu-point and keybinding for navigating to possible declarations - a second mode for auto-completion (maybe pressing space another time), that looks up possible classes the selected instance is of, to show only relevant tags for autocompletion - a menu-point and keybinding for listing possible usages (and the possibility to navigate there) Now the Questions: I checked the demoplugin so in general I think I have a clue on how to create the plugin. Now what seems for me the best way to go would be to simple override the callbacks for the existing "Go to Definition" etc. keybindings (as the ui-buttons seem to also be using them). The first relevant key_binding_id I would like to overide the callback for is GEANY_KEYS_GOTO_TAGDECLARATION. And it is mapped to a function in keybindings.c on line 1886. Now, this mapping I would like to overide. Is that possible and how? Or do I have to create new UI-Elements and link them to my function. I would not like the latter so much as the global settings for keybindings wouldn't have effect, wouldn't they? Thanks for your help and I'll be happy to clarify any questions rory ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
