Re: [Geany-devel] Rewrite reflow
On Sat, 31 Mar 2012 13:48:59 +0400 Eugene Arshinov earshi...@gmail.com wrote: Hi all. A couple of weeks ago in Geany mailing list a discussion was raised about reimplementing Reflow paragraph command more correctly and consistently with Line breaking. Here is a link: [1] Finally I got to it and created pull request #35 [2]. As always, suggestions are welcome. [1]: http://lists.uvena.de/geany/2012-March/007960.html [2]: https://github.com/geany/geany/pull/35 -- Best regards, Eugene. A reminder for myself: after the pull request is accepted (if it happens anytime), it would be good to check bug report [3]. This bug report is about cursor positioning after reflow. Also, it would be good to check cursor positioning after Join lines. [3]:http://sf.net/tracker/index.php?func=detailaid=2875092group_id=153444atid=787791 ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Line operations
On Mon, 20 Feb 2012 20:03:17 +0100 Colomban Wendling lists@herbesfolles.org wrote: Le 19/02/2012 20:01, Eugene Arshinov a écrit : On Sun, 19 Feb 2012 17:24:00 +0100 Colomban Wendling lists@herbesfolles.org wrote: [...] The commands indeed work similarly to our own `move_lines` function. I posted pull request #24 [3] which removes `move_lines` function and leverages the commands. I hope it can be committed so that I can switch my effort of improving Move lines feature from Geany to Scintilla. Looks fine to -- apart of course it doesn't fix the initial problem yet. At least so there would be only one copy of the functionality. So just to be sure we understand each other: I drop your previous pull request (#21), apply this one (#24) and wait for your patch to be in Scintilla? Yes. But I don't promise that I'll post a request to Scintilla *soon*… No big deal IMO regarding how long this bug existed without any reports about it. See, while I use the feature quite often, I ran into the bug only once in real situation. So, it's now applied; Waits for Scintilla update :) Hello. There is some good news. Recently they applied a patch with an updated implementation of MOVESELECTEDLINES [1]. I guess, it will be in the next release. [1]:http://sf.net/tracker/?func=detailatid=102439aid=3511023group_id=2439 -- Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Rewrite reflow
Hi all. A couple of weeks ago in Geany mailing list a discussion was raised about reimplementing Reflow paragraph command more correctly and consistently with Line breaking. Here is a link: [1] Finally I got to it and created pull request #35 [2]. As always, suggestions are welcome. [1]: http://lists.uvena.de/geany/2012-March/007960.html [2]: https://github.com/geany/geany/pull/35 -- Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Where have the thirdparty plugins gone?
On Thu, 01 Mar 2012 23:52:31 +0100 Dominic Hopf dma...@googlemail.com wrote: Hi everyone, Lex pointed me to the issue, that the pages for the third-party plugins at http://plugins.geany.org/ are empty. I have to admit, that I maybe am not that up-to-date and thus, am not sure what actually happened to those plugins. Last thing I know of them is, that they were in the same SVN repository at SourceForge as Geany-Plugins. After the migration to GitHub they are gone - I guess that is intended. Does anyone know what happened to them? Do they exist anymore and just in another place? Or should I really remove them from the website? Regards, Dominic Hello. That was me who agreed to maintain the Mini-Script plugin. That plugin is now inside geany-plugins. Also it seems to have a working README. What should be done to place this README on the site? -- Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Line operations
On Mon, 6 Feb 2012 11:55:25 +0400 Eugene Arshinov earshi...@gmail.com wrote: On Sun, 05 Feb 2012 20:50:38 +0100 Colomban Wendling lists@herbesfolles.org wrote: Le 05/02/2012 13:51, Eugene Arshinov a écrit : Hello all. [snip] 2) I want to raise a question, do we need a join lines command? This command would be a companion of the existing reflow paragraph command, but in contrast with the latter, it would only join lines, but not split them. This command may be useful when, let's say, you have a document created by someone else who sticks with line breaking and inserts \n at column 80. Suppose that you prefer using line wrapping instead and want to remove those \n in a peace of a document which you're editing. The new command would help you a bit. Implementation of the new join lines command could use the bits of code already written for reflow paragraph (though, those bits need to be extracted/refactored first). Moreover, I already implemented it and, if the new command seems useful to anyone, I can put my implementation in a pull request. Not sure I see a use case for this (read: I probably wouldn't use it if it simply removes the EOLs), but why not if some wants it. But maybe Scintilla already have a message for it and thus we'd only need to use it? As Lex already wrote, there is SCI_LINESJOIN. And that's the command which is already used in Geany to implement reflow paragraph (to be more precise, two commands are used: LINESJOIN and LINESSPLIT). By the way, here is a related discussion: [Geany-devel] Support SCI_LINESJOIN and SCI_LINESSPLIT (patch included) [1]. The first message is authored by me :) [1]: http://lists.uvena.de/geany-devel/2009-July/000834.html I created pull request #26 [2] containing the implementation of the new Join lines command so that it won't get lost. [2]: https://github.com/geany/geany/pull/26 -- Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Line operations
On Sun, 19 Feb 2012 17:24:00 +0100
Colomban Wendling lists@herbesfolles.org wrote:
Le 19/02/2012 08:02, Eugene Arshinov a écrit :
Hi there.
Hi Eugene,
Quick overview - I posted a pull request [3] which removes
`move_lines` function and uses commands already available in
Scintilla. See below.
On Sun, 05 Feb 2012 20:50:38 +0100
Colomban Wendling lists@herbesfolles.org wrote:
Le 05/02/2012 13:51, Eugene Arshinov a écrit :
Hello all.
Hey Eugene,
I have several suggestions and questions about certain line
operations implemented in Geany.
1) Recently I found that move lines up/down command does not
work properly for the last line not ending with a newline. You
can easily check it yourself. Couple of minutes ago I made a pull
request [1] with an implementation of `editor.c:move_lines()`
which handles the problem. Dear unknown someone, please review
and pull if it's okay.
I know this problem, but it needed a so big code refactoring it
hurts (I want as a proof the fact your rewrite is... huge), so...
I just postponed it. Ok, shame on me.
I haven't reviewed the new code yet, but I'll do. Just as a note,
Scintilla has a command to do that that suffers (suffered?) of the
exact same bug we had. Maybe it'd be good to fix their copy and
use the SCI message in place of our code.
[snip]
I didn't find those Scintilla commands
(SCI_MOVESELECTEDLINES{UP,DOWN} to be precise) because they are not
mentioned in the official Scintilla documentation [1], though they
are of course mentioned in Scintilla.h. For completeness, here is
the feature request for Scintilla where those commands came from -
[2].
It is in the docs:
http://www.scintilla.org/ScintillaDoc.html#SCI_MOVESELECTEDLINESUP
Stupid me. Probably I searched for MOVELINES, not MOVESELECTEDLINES
The commands indeed work similarly to our own `move_lines`
function. I posted pull request #24 [3] which removes `move_lines`
function and leverages the commands. I hope it can be committed so
that I can switch my effort of improving Move lines feature from
Geany to Scintilla.
Looks fine to -- apart of course it doesn't fix the initial problem
yet. At least so there would be only one copy of the functionality.
So just to be sure we understand each other: I drop your previous pull
request (#21), apply this one (#24) and wait for your patch to be in
Scintilla?
Yes. But I don't promise that I'll post a request to Scintilla *soon*…
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Some obsolete(?) bug reports
On Sun, 19 Feb 2012 16:51:54 +0100 Colomban Wendling lists@herbesfolles.org wrote: Le 19/02/2012 01:06, Lex Trotman a écrit : [...] I just taught the file mangler to run geany -c so it never interrupts what a normal Geany is doing :) I don't think that's something everybody should need to do. Yes, true. [...] I personally do think what we do is definitely the Wrong Thing. Honestly, I always have found this behavior very counter-intuitive and not helpful. I mean, if I tell Geany to restore my session, I expect it to be restored whenever I start Geany, not only in some cases. Looking at it like that, then the current behaviour is wrong. I also checked a few other apps and all restore past sessions and add the new file to it, so I would say this is the behaviour a user would expect. OK, for me it's not a real problem since I always have one or more Geany instance open, but remembering the early times I did unexpectedly lost some session data because of this behavior. To summarize, I think that the current behavior will most likely NOT be the expected one and will disturb most users. See, even us do workaround that in some ways, either using -c or having an instance always open. Or both, so I *never* saw it as a problem :) So I'd say aye to Dimitar since he gently volunteered :) Moreover if it is a preference I don't see any loss; but I'd better see this preference turned on by default for new configurations if the restore session one is on. Colomban has been so persuasive Hehe :D that I don't even think it needs another option, the suggested behaviour is non-destructive, so why not just turn restoring sessions on or off. Agreed, another pref isn't needed, either always restore or never restore should be enough; IMO too. Sounds reasonable to everybody? I agree. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Line operations
Hi there.
Quick overview - I posted a pull request [3] which removes `move_lines`
function and uses commands already available in Scintilla. See below.
On Sun, 05 Feb 2012 20:50:38 +0100
Colomban Wendling lists@herbesfolles.org wrote:
Le 05/02/2012 13:51, Eugene Arshinov a écrit :
Hello all.
Hey Eugene,
I have several suggestions and questions about certain line
operations implemented in Geany.
1) Recently I found that move lines up/down command does not work
properly for the last line not ending with a newline. You can
easily check it yourself. Couple of minutes ago I made a pull
request [1] with an implementation of `editor.c:move_lines()` which
handles the problem. Dear unknown someone, please review and pull
if it's okay.
I know this problem, but it needed a so big code refactoring it hurts
(I want as a proof the fact your rewrite is... huge), so... I just
postponed it. Ok, shame on me.
I haven't reviewed the new code yet, but I'll do. Just as a note,
Scintilla has a command to do that that suffers (suffered?) of the
exact same bug we had. Maybe it'd be good to fix their copy and use
the SCI message in place of our code.
[snip]
I didn't find those Scintilla commands (SCI_MOVESELECTEDLINES{UP,DOWN}
to be precise) because they are not mentioned in the official Scintilla
documentation [1], though they are of course mentioned in Scintilla.h.
For completeness, here is the feature request for Scintilla where those
commands came from - [2].
The commands indeed work similarly to our own `move_lines` function. I
posted pull request #24 [3] which removes `move_lines` function and
leverages the commands. I hope it can be committed so that I can
switch my effort of improving Move lines feature from Geany to
Scintilla.
[1]:http://www.scintilla.org/ScintillaDoc.html
[2]:https://sourceforge.net/tracker/?func=detailaid=3304850group_id=2439atid=352439
[3]:https://github.com/geany/geany/pull/24
--
Best regards,
Eugene.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Some obsolete(?) bug reports
On Mon, 13 Feb 2012 17:14:19 -0800 Matthew Brush mbr...@codebrainz.ca wrote: On 02/11/2012 11:18 PM, Eugene Arshinov wrote: Hello. Sorry for bothering you so much. When I looked for existing bug reports related to changing document's filetype to None, I found a couple of reports that seems obsolete. Maybe some of the developers could spend some time to review them and mark them as CLOSED or whatever is applicable. 1. Incorrect indentation guides - ID: 2637071 [1] I opened the attached document and did not see any issues with indentation guides. I could miss something because I rarely use the guies, but... Maybe it was already fixed in Scintilla? Enrico replied to this report in 2009. I think this bug is still present if I understand it correctly. The attached file causes indentation guides to be shown on the blank line that has no indentation at all. Seems that I misunderstood the problem. Let's leave the report open. 2. Command line option to bring Geany to front - ID: 2276179 [2] Seems that some actions were performed to fix the bug, but the report's author didn't have time to check it. Maybe, as a long time has passed since 2009, the bug report can be closed? BTW, what is described in the report, works fine for me (Geany is brought to front). Enrico replied to this report in 2009, too. Just closed this one. Thanks :) 3. geany xyz.txt does not load files from session - ID: 2838686 [3] Here it wasn't decided whether of not Geany should restore session. I suggest we discuss this question and finally either fix the bug or mark it as WONTFIX. A long time ago I added to the Preferences dialog a checkbox that controlled the behaviour. This was done in the sm branch. If it's decided that a graphical preference is needed, I can extract code from there and make a pull request. However, currently I think that a hidden pref for that is better. Your opinions? I don't often use Geany for opening files from the command line and usually I always have a Geany window open so if I do, it's not an issue, so I can't really provide a worthwhile opinion here. It's same with me, actually :) But still it would be good to make a decision about the bug report. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Some obsolete(?) bug reports
Hello. Sorry for bothering you so much. When I looked for existing bug reports related to changing document's filetype to None, I found a couple of reports that seems obsolete. Maybe some of the developers could spend some time to review them and mark them as CLOSED or whatever is applicable. 1. Incorrect indentation guides - ID: 2637071 [1] I opened the attached document and did not see any issues with indentation guides. I could miss something because I rarely use the guies, but... Maybe it was already fixed in Scintilla? Enrico replied to this report in 2009. 2. Command line option to bring Geany to front - ID: 2276179 [2] Seems that some actions were performed to fix the bug, but the report's author didn't have time to check it. Maybe, as a long time has passed since 2009, the bug report can be closed? BTW, what is described in the report, works fine for me (Geany is brought to front). Enrico replied to this report in 2009, too. 3. geany xyz.txt does not load files from session - ID: 2838686 [3] Here it wasn't decided whether of not Geany should restore session. I suggest we discuss this question and finally either fix the bug or mark it as WONTFIX. A long time ago I added to the Preferences dialog a checkbox that controlled the behaviour. This was done in the sm branch. If it's decided that a graphical preference is needed, I can extract code from there and make a pull request. However, currently I think that a hidden pref for that is better. Your opinions? [1]:http://sf.net/tracker/index.php?func=detailaid=2637071group_id=153444atid=787791 [2]:http://sf.net/tracker/index.php?func=detailaid=2276179group_id=153444atid=787794 [3]:http://sf.net/tracker/index.php?func=detailaid=2838686group_id=153444atid=787791 -- Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Maintainerrequest: Geany-Mini-Script
Hi Frank. I sent a pull request [1] which contains the plugin integrated into geany-plugins. Review and pull, if you wish. I also created a repository [2] which contains geany-mini-script plugin at the state in which it was in SVN repo. [1]: https://github.com/geany/geany-plugins/pull/13 [2]: https://github.com/earshinov/geany-mini-script -- Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Maintainerrequest: Geany-Mini-Script
On Sun, 05 Feb 2012 11:53:20 +0100 Frank Lanitz fr...@frank.uvena.de wrote: Am 05.02.2012 11:43, schrieb Eugene Arshinov: I sent a pull request [1] which contains the plugin integrated into geany-plugins. Review and pull, if you wish. I also created a repository [2] which contains geany-mini-script plugin at the state in which it was in SVN repo. Cool. Will you take over maintainership of the code? If so, can do also an update on MAINTAINERS? Yes, I agree to be the maintainer. But, in MAINTAINERS file we specify plugin's web page. I'd like it to be [1], but the page can't exist yet. [1]: http://plugins.geany.org/geanyminiscript.html ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Maintainerrequest: Geany-Mini-Script
On Sun, 05 Feb 2012 15:50:54 +0100 Frank Lanitz fr...@frank.uvena.de wrote: Am 05.02.2012 12:17, schrieb Eugene Arshinov: On Sun, 05 Feb 2012 11:53:20 +0100 Frank Lanitz fr...@frank.uvena.de wrote: Am 05.02.2012 11:43, schrieb Eugene Arshinov: I sent a pull request [1] which contains the plugin integrated into geany-plugins. Review and pull, if you wish. I also created a repository [2] which contains geany-mini-script plugin at the state in which it was in SVN repo. Cool. Will you take over maintainership of the code? If so, can do also an update on MAINTAINERS? Yes, I agree to be the maintainer. But, in MAINTAINERS file we specify plugin's web page. I'd like it to be [1], but the page can't exist yet. During the process ... Can you check: [...] gms_gui.c: In function 'save_prefs_file': gms_gui.c:198:5: warning: too many arguments for format [-Wformat-extra-args] Uhh, sorry for a delay. I'll check it in 15 minutes. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Maintainerrequest: Geany-Mini-Script
On Sun, 05 Feb 2012 15:50:54 +0100 Frank Lanitz fr...@frank.uvena.de wrote: Am 05.02.2012 12:17, schrieb Eugene Arshinov: On Sun, 05 Feb 2012 11:53:20 +0100 Frank Lanitz fr...@frank.uvena.de wrote: Am 05.02.2012 11:43, schrieb Eugene Arshinov: I sent a pull request [1] which contains the plugin integrated into geany-plugins. Review and pull, if you wish. I also created a repository [2] which contains geany-mini-script plugin at the state in which it was in SVN repo. Cool. Will you take over maintainership of the code? If so, can do also an update on MAINTAINERS? Yes, I agree to be the maintainer. But, in MAINTAINERS file we specify plugin's web page. I'd like it to be [1], but the page can't exist yet. During the process ... Can you check: [...] gms_gui.c: In function 'save_prefs_file': gms_gui.c:198:5: warning: too many arguments for format [-Wformat-extra-args] Fixed. That was an innocent excessive argument of g_string_sprinf, probably left out after copy paste. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Maintainerrequest: Geany-Mini-Script
On Sun, 05 Feb 2012 11:36:22 -0800 Matthew Brush mbr...@codebrainz.ca wrote: On 02/05/2012 02:43 AM, Eugene Arshinov wrote: Hi Frank. I sent a pull request [1] which contains the plugin integrated into geany-plugins. Review and pull, if you wish. I also created a repository [2] which contains geany-mini-script plugin at the state in which it was in SVN repo. [1]: https://github.com/geany/geany-plugins/pull/13 [2]: https://github.com/earshinov/geany-mini-script Just out of curiosity, isn't Mini Script kind of redundant with having the Edit-Format-Send Selection To feature? I guess it has a few more options but it seems to do the same thing. True. An example of why the plugin can be useful: it allows to conveniently write temporary scripts and execute them immediately. Also, with the plugin you can open your script when you need it, and the script won't hang in the Send selection to... menu. By the way, it seems Send selection to has been available for a long time and even before than the original author wrote the Mini Script plugin (at the beginning of 2009). -- Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Line operations
On Sun, 05 Feb 2012 20:50:38 +0100 Colomban Wendling lists@herbesfolles.org wrote: Le 05/02/2012 13:51, Eugene Arshinov a écrit : Hello all. Hey Eugene, I have several suggestions and questions about certain line operations implemented in Geany. 1) Recently I found that move lines up/down command does not work properly for the last line not ending with a newline. You can easily check it yourself. Couple of minutes ago I made a pull request [1] with an implementation of `editor.c:move_lines()` which handles the problem. Dear unknown someone, please review and pull if it's okay. I know this problem, but it needed a so big code refactoring it hurts (I want as a proof the fact your rewrite is... huge), so... I just postponed it. Ok, shame on me. No problem. As the changes I made are (almost?) a complete rewrite, I would suggest viewing the differences side by side instead of `diff` format. That will be easier. Though, the resulting function indeed became longer than the previous version... I haven't reviewed the new code yet, but I'll do. Just as a note, Scintilla has a command to do that that suffers (suffered?) of the exact same bug we had. Maybe it'd be good to fix their copy and use the SCI message in place of our code. Uhh, I didn't know that… I'll take a look later. [1]: https://github.com/geany/geany/pull/21 2) I want to raise a question, do we need a join lines command? This command would be a companion of the existing reflow paragraph command, but in contrast with the latter, it would only join lines, but not split them. This command may be useful when, let's say, you have a document created by someone else who sticks with line breaking and inserts \n at column 80. Suppose that you prefer using line wrapping instead and want to remove those \n in a peace of a document which you're editing. The new command would help you a bit. Implementation of the new join lines command could use the bits of code already written for reflow paragraph (though, those bits need to be extracted/refactored first). Moreover, I already implemented it and, if the new command seems useful to anyone, I can put my implementation in a pull request. Not sure I see a use case for this (read: I probably wouldn't use it if it simply removes the EOLs), but why not if some wants it. But maybe Scintilla already have a message for it and thus we'd only need to use it? As Lex already wrote, there is SCI_LINESJOIN. And that's the command which is already used in Geany to implement reflow paragraph (to be more precise, two commands are used: LINESJOIN and LINESSPLIT). By the way, here is a related discussion: [Geany-devel] Support SCI_LINESJOIN and SCI_LINESSPLIT (patch included) [1]. The first message is authored by me :) [1]: http://lists.uvena.de/geany-devel/2009-July/000834.html -- Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Maintainerrequest: Geany-Mini-Script
On Sat, 12 Nov 2011 00:03:30 +0400 Eugene Arshinov earshi...@gmail.com wrote: On Thu, 10 Nov 2011 22:41:06 +0100 Frank Lanitz fr...@frank.uvena.de wrote: Am 08.10.2011 21:50, schrieb Eugene Arshinov: Unfortunately I didn't heard back of developer of geany-mini-script-plugin so today I like to ask you whether somebody likes to take over maintenance for geany-mini-script plugin inside geany-plugins-svn. It's untouched since maybe 2009 and to be honest I have no idea, what's the current status. Also I'm not 100% whether its still a useful plugin or maybe some other plugin is taking over the task in a better way. Personally I remember it as a possible useful plugin but don't have the resources to look after and used it 1 year for the last time. If nobody is feeling responsible I suggest, similar to previous plugins, we remove it from official repository. In case someone wants to try the plugin, here is a patch to make it compile. Did anyone try it? Does anyone likes to take it over and maybe integrate it into geany-plugins? If no one wants, I could take a minimal care of this plugin. Though, I can't promise I'll have time for it when it's needed. I still have SM-branch related stuff which I can't do for weeks... Hi Frank. I wonder what's the state of the geany-mini-scripts plugin now? It seems that only SVN's /geany-plugins/geany-plugins/ part was converted to Git, and AFAIR geany-mini-script was living next to geany-plugins (at /geany-plugins/geany-mini-script/) and wasn't converted. I can use the copy from my local geany-plugins Git repository (bound to the old SVN repository) and push it somewhere on Github. Then perhaps I can integrate the plugin into geany-plugins, push the result to a fork of geany-plugins and send a pull request. Is it the way to go? -- Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany-Plugins: MAINTAINERS file
On Fri, 06 Jan 2012 10:29:30 +0100 Frank Lanitz fr...@frank.uvena.de wrote: Hi folks, We have just added a MAINTAINERS into git to add a single point to find who is responsible for a plugin. Please be so kind and sending in patches or updating the file on your own for your plugins to show who is maintaining etc. File contains a little header with very brief instructions to do so. Hi. Here's xmlsnippets' maintainer info (e.g., mine) -- Best regards, Eugene.diff --git a/MAINTAINERS b/MAINTAINERS index f5f0d26..684dd74 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -175,7 +175,7 @@ W: http://plugins.geany.org/webhelper.html S: Supported xmlsnippets -P: -M: -W: -S: +P: Eugene Arshinov earshi...@gmail.com +M: Eugene Arshinov earshi...@gmail.com +W: http://plugins.geany.org/xmlsnippets.html +S: Maintained ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Q: how to switch to new Git repo?
Hi guys! It's me again, after a long time. Please help me organize my Geany repository. The last time I worked on Geany it was in SVN repository, and I was using it through git-svn. Now there are two Git repositories: the main one [1] and the one containing my sm-branch [2]. I assume I should make the fork of the former and put my sm branch there, but how do I transfer my sm branch, preserving merge commits (master - sm)? [1]: https://github.com/geany/geany [2]: https://github.com/techee/sm-branch/ -- Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Q: how to switch to new Git repo?
On Fri, 06 Jan 2012 16:55:06 +0100 Thomas Martitz thomas.mart...@student.htw-berlin.de wrote: Am 06.01.2012 16:52, schrieb Eugene Arshinov: Hi Thomas, Thanks for the reply. If I can't preserve merges anyway, I'm going to transfer the sm branch right from my existing local Git repository. That is, 1. I will fork the main repository and clone it 2. add existing local repository as a remote 3. rebase the sm branch from the remote onto the corresponding commit cloned from the fork. I guess, this should work. I dont think you can add the local repository as a remote (I am assuming that local repo is a git-svn repo from before the conversion) as the history is different. The history needs to be the same so git can reasonable tell which commits need to be rebased. I'll try. I'm going to use `git rebase --onto ...` which (iiuc) does not require common history between the rebased commits. And, local repository as a remote should work well: some time ago I even managed to use a local repository as a Git submodule (for experiment only :) Are you saying that the sm branch in [1] is out of date and you would rather use what you have locally? The sm branch in [1] is correct. I just don't want to clone it, as I already have the same state locally, to save bandwidth (which currently costs me some $). Best regards [1]: https://github.com/techee/sm-branch/ ___ 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] Q: how to switch to new Git repo?
It seems that everything went fine. My personal fork is https://github.com/earshinov/geany/, and the new home for sm branch is https://github.com/earshinov/geany/tree/sm. Jiří, I suppose you can safely remove your sm-branch repository. Thank you for keeping it for so long! -- Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Maintainerrequest: Geany-Mini-Script
On Thu, 10 Nov 2011 22:41:06 +0100 Frank Lanitz fr...@frank.uvena.de wrote: Am 08.10.2011 21:50, schrieb Eugene Arshinov: Unfortunately I didn't heard back of developer of geany-mini-script-plugin so today I like to ask you whether somebody likes to take over maintenance for geany-mini-script plugin inside geany-plugins-svn. It's untouched since maybe 2009 and to be honest I have no idea, what's the current status. Also I'm not 100% whether its still a useful plugin or maybe some other plugin is taking over the task in a better way. Personally I remember it as a possible useful plugin but don't have the resources to look after and used it 1 year for the last time. If nobody is feeling responsible I suggest, similar to previous plugins, we remove it from official repository. In case someone wants to try the plugin, here is a patch to make it compile. Did anyone try it? Does anyone likes to take it over and maybe integrate it into geany-plugins? If no one wants, I could take a minimal care of this plugin. Though, I can't promise I'll have time for it when it's needed. I still have SM-branch related stuff which I can't do for weeks... -- Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Maintainerrequest: Geany-Mini-Script
On Sun, 2 Oct 2011 22:39:42 +0200
Frank Lanitz fr...@frank.uvena.de wrote:
Hi folks,
Unfortunately I didn't heard back of developer of
geany-mini-script-plugin so today I like to ask you whether somebody
likes to take over maintenance for geany-mini-script plugin inside
geany-plugins-svn. It's untouched since maybe 2009 and to be honest I
have no idea, what's the current status. Also I'm not 100% whether its
still a useful plugin or maybe some other plugin is taking over the
task in a better way. Personally I remember it as a possible useful
plugin but don't have the resources to look after and used it 1 year
for the last time.
If nobody is feeling responsible I suggest, similar to previous
plugins, we remove it from official repository.
Hi Frank.
In case someone wants to try the plugin, here is a patch to make it
compile.
P.S. I remember that a couple of months ago I promised to send you an
overview of what changes are in the SM branch… I hope I will find time
for it in the near future.
--
Best regards,
Eugene
diff --git a/geany-mini-script/src/gms.c b/geany-mini-script/src/gms.c
index 90ef913..ef6b2e2 100644
--- a/geany-mini-script/src/gms.c
+++ b/geany-mini-script/src/gms.c
@@ -38,7 +38,7 @@
* - it will be loaded at next startup.
*/
-#includegeany.h
+#includegeanyplugin.h
/* headers */
#includestdlib.h
@@ -49,17 +49,6 @@
#includelocale.h
#endif
-
-/* geany headers */
-#includesupport.h
-#includeplugindata.h
-#includeeditor.h
-#includedocument.h
-#includeprefs.h
-#includeutils.h
-#includeui_utils.h
-#includepluginmacros.h
-
/* user header */
#includegms.h
#includegms_gui.h
@@ -77,7 +66,7 @@ PLUGIN_VERSION_CHECK(100)
/* All plugins must set name, description, version and author. */
PLUGIN_SET_INFO(_(geany mini-script), _(GMS (Geany Mini-Script filter plugin)),
-VERSION , _(Pascal BURLOT, a Geany user))
+0.1 , _(Pascal BURLOT, a Geany user))
static GtkWidget *gms_item = NULL ;
static gms_handle_t gms_hnd = NULL ;
@@ -90,12 +79,12 @@ static gchar*gms_command = NULL ;
static void create_selection_2_input_file( ScintillaObject *sci )
{
gchar *contents = NULL;
-gintsize_buf = p_sci-get_selected_text_length(sci);
+gintsize_buf = sci_get_selected_text_length(sci);
contents = GMS_G_MALLOC( gchar, size_buf + 1 ) ;
GMS_PNULL(contents) ;
-p_sci-get_selected_text( sci ,contents );
+sci_get_selected_text( sci ,contents );
g_file_set_contents(gms_get_in_filename(gms_hnd), contents, -1 , NULL );
GMS_G_FREE(contents);
@@ -124,10 +113,10 @@ static gchar *read_result_file( gchar *filename )
*/
static void select_entirely_doc( ScintillaObject *sci )
{
-gintsize_buf = p_sci-get_length(sci);
+gintsize_buf = sci_get_length(sci);
-p_sci-set_selection_start( sci , 0 ) ;
-p_sci-set_selection_end( sci , size_buf ) ;
+sci_set_selection_start( sci , 0 ) ;
+sci_set_selection_end( sci , size_buf ) ;
}
/**
@@ -136,7 +125,7 @@ static void select_entirely_doc( ScintillaObject *sci )
static void update_doc( ScintillaObject *sci, gchar * contents )
{
if (contents==NULL) return ;
-p_sci-replace_sel( sci, contents );
+sci_replace_sel( sci, contents );
}
/**
* \brief the function deletes the tempory files
@@ -189,11 +178,11 @@ static gint run_filter( ScintillaObject *sci )
}
else
{
-p_document-new_file( NULL, NULL, result ) ;
+document_new_file( NULL, NULL, result ) ;
}
}
GMS_G_FREE( result ) ;
-
+
return ret ;
}
@@ -202,7 +191,7 @@ static gint run_filter( ScintillaObject *sci )
*/
static void item_activate(GtkMenuItem *menuitem, gpointer gdata)
{
-GeanyDocument *doc = p_document-get_current();
+GeanyDocument *doc = document_get_current();
ScintillaObject *sci = doc-editor-sci ;
if ( gms_hnd == NULL )
return ;
@@ -230,12 +219,12 @@ static void item_activate(GtkMenuItem *menuitem, gpointer gdata)
guint nb_doc = 0 , i=0;
/* find the opened document in the geany session */
-while ( (doc = p_document-get_from_page(nb_doc))!=NULL ) nb_doc++;
+while ( (doc = document_get_from_page(nb_doc))!=NULL ) nb_doc++;
/* For each document */
for( i=0; inb_doc;i++)
{
-doc = p_document-get_from_page(i) ;
+doc = document_get_from_page(i) ;
sci = doc-editor-sci ;
select_entirely_doc( sci ) ;
create_selection_2_input_file(sci) ;
@@ -302,7 +291,7 @@ void plugin_init(GeanyData *data)
g_signal_connect(gms_item, activate, G_CALLBACK(item_activate), NULL);
/* make the menu item sensitive only when documents are open */
-
Re: [Geany-devel] Status of SM-Branch
On Thu, 30 Jun 2011 20:31:06 +0200 Frank Lanitz fr...@frank.uvena.de wrote: On Thu, 30 Jun 2011 11:31:21 +0400 Eugene Arshinov earshi...@gmail.com wrote: [...] So, the only useful thing in SM branch is the minor improvements. Even if someone has time to discuss them and decide to include them in trunk, it may be rather hard to cleanly extract the necessary patches from SM so that they apply to trunk. Well, not sure and just a thought. Would it be possible to extract the little improvements so they could be merged to trunk? Can you give a more detailed view on the et? What do the improvements include? Cheers, Frank OK, today I'll review the commit history and post here the list of improvements. Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] [PATCH] In messages show the actual text user entered in Find and Replace dialogs
On Sat, 21 May 2011 12:16:59 +0400 Eugene Arshinov earshi...@gmail.com wrote: On Tue, 17 May 2011 15:38:40 +0200 Colomban Wendling lists@herbesfolles.org wrote: Le 15/05/2011 14:29, Eugene Arshinov a écrit : Hi. When Escape sequences checkbox is checked in Find or Replace dialog, before escaping the find and replace strings we should save the original ones, so that they can be used in messages shown to user and in the history of those dialogs' entries. This is what the patch is about. I described in the commit message (see the top of the patch) the changes made in the code. Just in case, here is a copy: In the code, now we pass the original text together with the one that is actually searched for. New `original_text' field was added to GeanySearchData. A bug was fixed in document.c:show_replace_summary(): it did not escape the No matches found for ... string. Hope that I did not touch plugin API with these changes. In header files I changed the following: - document_find_text()'s signature - document_replace_text()'s signature - search_find_usage()'s signature - struct GeanySearchData Seems none of the functions you changed were in the plugin API, so it's fine. For the structure, since you appended to it, it's also fine. However, a few comments: 1) why did you used an extra string everywhere but in document.c:show_replace_summary()? OK it already do this, but it seems not consistent since you added an original_text. 2) on search.c:on_replace_dialog_response(), prefer initialize original_find to NULL and free it in fail rather than freeing it every time. (though anyway this function is ugly as-is with the backward goto jump just for failure) Otherwise looks OK to me. Attached are the original patch updated for current trunk (r5798) and another one containing changes according to your advice. In the second patch I also applied the same technique to show proper replace text in messages. Hi. Aren't these patches forgotten? ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] [PATCH] In messages show the actual text user entered in Find and Replace dialogs
On Fri, 3 Jun 2011 15:48:48 +0200 Enrico Tröger enrico.troe...@uvena.de wrote: On Fri, 03 Jun 2011 15:44:46 +0200, Colomban wrote: Hi, Le 03/06/2011 09:47, Eugene Arshinov a écrit : On Sat, 21 May 2011 12:16:59 +0400 Eugene Arshinov earshi...@gmail.com wrote: [...] Hi. Aren't these patches forgotten? Not really forgotten, but since I don't find that much time these days to review patches stuff (you might have noticed ^^), I didn't Similar here. Spare time is rare an currently, I focus my work on the new wiki to get this done ASAP. Sorry. So it's committed now. I also pushed another small commit to use the Yay, thanks Colomban. No problem, guys. I just wanted to remind that these patches exist. I don't really care much if they are committed in two weeks or two months. Thanks for committing and for the little additional patch. -- Best regards, Eugene ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] [PATCH] In messages show the actual text user entered in Find and Replace dialogs
On Tue, 17 May 2011 15:38:40 +0200
Colomban Wendling lists@herbesfolles.org wrote:
Le 15/05/2011 14:29, Eugene Arshinov a écrit :
Hi.
When Escape sequences checkbox is checked in Find or Replace
dialog, before escaping the find and replace strings we should save
the original ones, so that they can be used in messages shown to
user and in the history of those dialogs' entries. This is what
the patch is about.
I described in the commit message (see the top of the patch) the
changes made in the code. Just in case, here is a copy:
In the code, now we pass the original text together with the one
that is actually searched for. New `original_text' field was
added to GeanySearchData. A bug was fixed in
document.c:show_replace_summary(): it did not escape the No
matches found for ... string.
Hope that I did not touch plugin API with these changes. In header
files I changed the following:
- document_find_text()'s signature
- document_replace_text()'s signature
- search_find_usage()'s signature
- struct GeanySearchData
Seems none of the functions you changed were in the plugin API, so
it's fine. For the structure, since you appended to it, it's also
fine.
However, a few comments:
1) why did you used an extra string everywhere but in
document.c:show_replace_summary()? OK it already do this, but it seems
not consistent since you added an original_text.
2) on search.c:on_replace_dialog_response(), prefer initialize
original_find to NULL and free it in fail rather than freeing it every
time. (though anyway this function is ugly as-is with the backward
goto jump just for failure)
Otherwise looks OK to me.
Attached are the original patch updated for current trunk (r5798) and
another one containing changes according to your advice. In the second
patch I also applied the same technique to show proper replace text
in messages.
--
Best regards,
Eugene
From d8c2774fc3d89fe283df2d0234aed270a7fd033b Mon Sep 17 00:00:00 2001
From: Eugene Arshinov earshi...@gmail.com
Date: Sun, 15 May 2011 16:06:13 +0400
Subject: [PATCH 1/3] In messages show the actual text user entered in Find
and Replace dialogs. Previously we could put into a
message a string where escape sequences were already
translated.
In the code, now we pass the original text together with the one
that is actually searched for. New `original_text' field was added to
GeanySearchData. A bug was fixed in document.c:show_replace_summary(): it
did not escape the No matches found for ... string.
---
src/callbacks.c |4 +-
src/document.c | 50 -
src/document.h |8 +++---
src/editor.c|4 +-
src/search.c| 60 +-
src/search.h|4 ++-
6 files changed, 83 insertions(+), 47 deletions(-)
diff --git a/src/callbacks.c b/src/callbacks.c
index 9fbe2cd..da64a7f 100644
--- a/src/callbacks.c
+++ b/src/callbacks.c
@@ -538,6 +538,7 @@ on_toolbutton_save_clicked (GtkAction *action,
static void setup_find(const gchar *text, gboolean backwards)
{
setptr(search_data.text, g_strdup(text));
+ setptr(search_data.original_text, g_strdup(text));
search_data.flags = 0;
search_data.backwards = backwards;
search_data.search_bar = TRUE;
@@ -1037,7 +1038,7 @@ static void find_usage(gboolean in_session)
flags = SCFIND_MATCHCASE | SCFIND_WHOLEWORD;
}
- search_find_usage(search_text, flags, in_session);
+ search_find_usage(search_text, search_text, flags, in_session);
g_free(search_text);
}
@@ -2414,4 +2415,3 @@ on_mark_all1_activate (GtkMenuItem *menuitem,
{
keybindings_send_command(GEANY_KEY_GROUP_SEARCH, GEANY_KEYS_SEARCH_MARKALL);
}
-
diff --git a/src/document.c b/src/document.c
index 971936b..3e47d1c 100644
--- a/src/document.c
+++ b/src/document.c
@@ -1928,9 +1928,13 @@ gboolean document_search_bar_find(GeanyDocument *doc, const gchar *text, gint fl
/* General search function, used from the find dialog.
* Returns -1 on failure or the start position of the matching text.
- * Will skip past any selection, ignoring it. */
-gint document_find_text(GeanyDocument *doc, const gchar *text, gint flags, gboolean search_backwards,
- gboolean scroll, GtkWidget *parent)
+ * Will skip past any selection, ignoring it.
+ *
+ * @param text Text to find.
+ * @param original_text Text as it was entered by user, or @c NULL to use @c text
+ */
+gint document_find_text(GeanyDocument *doc, const gchar *text, const gchar *original_text,
+ gint flags, gboolean search_backwards, gboolean scroll, GtkWidget *parent)
{
gint selection_end, selection_start, search_pos;
@@ -1942,6 +1946,9 @@ gint document_find_text(GeanyDocument *doc, const gchar *text, gint flags, gbool
if (flags SCFIND_REGEXP)
search_backwards = FALSE;
+ if (!original_text)
+ original_text = text;
+
selection_start = sci_get_selection_start(doc-editor-sci
[Geany-devel] Can't compile Geany with -ansi (va_copy is undefined)
Hi, and sorry for spamming this list. I recently tried to compile Geany with -ansi flag as the HACKING file suggests. When compiling mio-memory.c GCC reports a warning that va_copy is undefined, and linker fails with the same message. Should something be done about it? -- Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Can't compile Geany with -ansi (va_copy is undefined)
On Sat, 21 May 2011 18:37:43 +1000 Lex Trotman ele...@gmail.com wrote: On 21 May 2011 18:23, Eugene Arshinov earshi...@gmail.com wrote: Hi, and sorry for spamming this list. I recently tried to compile Geany with -ansi flag as the HACKING file suggests. When compiling mio-memory.c GCC reports a warning that va_copy is undefined, and linker fails with the same message. Should something be done about it? Hi Eugene, The problem is likely to be that your glib wasn't configured with --ansi so the use of the G_VA_COPY created a call to va_copy which is C99 and so not allowed with --ansi. The advice in hacking might need to be altered to note that some systems may not be able to compile with --ansi because headers that they depend on use later than --ansi standards. Hi. Thanks for the clear explanation. -- Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] [PATCH] In messages show the actual text user entered in Find and Replace dialogs
Hi.
When Escape sequences checkbox is checked in Find or Replace dialog,
before escaping the find and replace strings we should save the
original ones, so that they can be used in messages shown to user and in
the history of those dialogs' entries. This is what the patch is about.
I described in the commit message (see the top of the patch) the changes
made in the code. Just in case, here is a copy:
In the code, now we pass the original text together with the one
that is actually searched for. New `original_text' field was added to
GeanySearchData. A bug was fixed in document.c:show_replace_summary():
it did not escape the No matches found for ... string.
Hope that I did not touch plugin API with these changes. In header
files I changed the following:
- document_find_text()'s signature
- document_replace_text()'s signature
- search_find_usage()'s signature
- struct GeanySearchData
--
Best regards,
Eugene.From 9897da03d7155c407834df61115379d2d5daf3de Mon Sep 17 00:00:00 2001
From: Eugene Arshinov earshi...@gmail.com
Date: Sun, 15 May 2011 16:06:13 +0400
Subject: [PATCH] In messages show the actual text user entered in Find and
Replace dialogs. Previously we could put into a message a
string where escape sequences were already translated.
In the code, now we pass the original text together with the one
that is actually searched for. New `original_text' field was added to
GeanySearchData. A bug was fixed in document.c:show_replace_summary(): it
did not escape the No matches found for ... string.
---
src/callbacks.c |4 +-
src/document.c | 50 -
src/document.h |8 +++---
src/editor.c|4 +-
src/search.c| 60 +-
src/search.h|4 ++-
6 files changed, 83 insertions(+), 47 deletions(-)
diff --git a/src/callbacks.c b/src/callbacks.c
index 9fbe2cd..da64a7f 100644
--- a/src/callbacks.c
+++ b/src/callbacks.c
@@ -538,6 +538,7 @@ on_toolbutton_save_clicked (GtkAction *action,
static void setup_find(const gchar *text, gboolean backwards)
{
setptr(search_data.text, g_strdup(text));
+ setptr(search_data.original_text, g_strdup(text));
search_data.flags = 0;
search_data.backwards = backwards;
search_data.search_bar = TRUE;
@@ -1037,7 +1038,7 @@ static void find_usage(gboolean in_session)
flags = SCFIND_MATCHCASE | SCFIND_WHOLEWORD;
}
- search_find_usage(search_text, flags, in_session);
+ search_find_usage(search_text, search_text, flags, in_session);
g_free(search_text);
}
@@ -2414,4 +2415,3 @@ on_mark_all1_activate (GtkMenuItem *menuitem,
{
keybindings_send_command(GEANY_KEY_GROUP_SEARCH, GEANY_KEYS_SEARCH_MARKALL);
}
-
diff --git a/src/document.c b/src/document.c
index 971936b..3e47d1c 100644
--- a/src/document.c
+++ b/src/document.c
@@ -1928,9 +1928,13 @@ gboolean document_search_bar_find(GeanyDocument *doc, const gchar *text, gint fl
/* General search function, used from the find dialog.
* Returns -1 on failure or the start position of the matching text.
- * Will skip past any selection, ignoring it. */
-gint document_find_text(GeanyDocument *doc, const gchar *text, gint flags, gboolean search_backwards,
- gboolean scroll, GtkWidget *parent)
+ * Will skip past any selection, ignoring it.
+ *
+ * @param text Text to find.
+ * @param original_text Text as it was entered by user, or @c NULL to use @c text
+ */
+gint document_find_text(GeanyDocument *doc, const gchar *text, const gchar *original_text,
+ gint flags, gboolean search_backwards, gboolean scroll, GtkWidget *parent)
{
gint selection_end, selection_start, search_pos;
@@ -1942,6 +1946,9 @@ gint document_find_text(GeanyDocument *doc, const gchar *text, gint flags, gbool
if (flags SCFIND_REGEXP)
search_backwards = FALSE;
+ if (!original_text)
+ original_text = text;
+
selection_start = sci_get_selection_start(doc-editor-sci);
selection_end = sci_get_selection_end(doc-editor-sci);
if ((selection_end - selection_start) 0)
@@ -1974,7 +1981,7 @@ gint document_find_text(GeanyDocument *doc, const gchar *text, gint flags, gbool
if ((selection_end == 0 ! search_backwards) ||
(selection_end == sci_len search_backwards))
{
- ui_set_statusbar(FALSE, _(\%s\ was not found.), text);
+ ui_set_statusbar(FALSE, _(\%s\ was not found.), original_text);
utils_beep();
return -1;
}
@@ -1982,12 +1989,12 @@ gint document_find_text(GeanyDocument *doc, const gchar *text, gint flags, gbool
/* we searched only part of the document, so ask whether to wraparound. */
if (search_prefs.suppress_dialogs ||
dialogs_show_question_full(parent, GTK_STOCK_FIND, GTK_STOCK_CANCEL,
-_(Wrap search and find again?), _(\%s\ was not found.), text))
+_(Wrap search and find again?), _(\%s\ was not found.), original_text))
{
gint ret;
sci_set_current_position(doc-editor-sci, (search_backwards) ? sci_len : 0, FALSE
Re: [Geany-devel] Patches for XML snippets plugin
On Sat, 23 Apr 2011 12:46:13 +0100% Nick Treleaven nick.trelea...@btinternet.com wrote: On Fri, 22 Apr 2011 15:28:14 +0400 Eugene Arshinov earshi...@gmail.com wrote: Updated patch (which only adds utils_find_open_xml_tag_pos) attached. Ok, committed. I fixed a bug that gets reported as a tag. Hi Nick, and sorry for the delay. Thank you for fixing this error and committing the patch. Can I now commit my XMLSnippets plugin to geany-plugins? I think I properly integrated it into the build system (it was easy as the plugin is a couple of files and does not depend on anything); it builds successfully on my machine with Autotools and Waf. -- Best regards, Eugene ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Patches for XML snippets plugin
On Mon, 25 Apr 2011 17:17:15 +0100% Nick Treleaven nick.trelea...@btinternet.com wrote: On Mon, 25 Apr 2011 19:47:49 +0400 Eugene Arshinov earshi...@gmail.com wrote: Can I now commit my XMLSnippets plugin to geany-plugins? I think I properly integrated it into the build system (it was easy as the plugin is a couple of files and does not depend on anything); it builds successfully on my machine with Autotools and Waf. Sure, go ahead. Hi. Seems that I don't have access to geany-plugins. I remember changing something in the Addons plugin, but probably I sent a patch then. Can I have access? Now added you to the project as statc - I had assumed you already had access ;-) I thought so, too. Now committed successfully, thanks. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Patches for XML snippets plugin
Hi Nick.
On Thu, 21 Apr 2011 14:21:39 +0100%
Nick Treleaven nick.trelea...@btinternet.com wrote:
On Sun, 3 Apr 2011 15:05:21 +0400
Eugene Arshinov earshi...@gmail.com wrote:
If anyone has some free time for me, please take a look at a
message I sent in November [1]. There I attached two patches for
Geany which were (and still are) necessary for XML Snippets plugin
that was discussed in that thread. You can also read at [1] about
what the patches do.
Now I attach the updated patches. Hope they will become a part of
Geany and the plugin (not yet released anywhere) will no longer
depend on these «third-party» patches.
I've now fixed the bug with {ob}pc{cb} in a different way and cleaned
up the original code so the cursor positions is handled quite simply,
also fixing tabs+spaces mode cursor positions.
Okay, thank you for this change. I saw that your implementation is
shorter and simpler than mine.
I'm not sure that exposing editor_snippets_make_replacements() is a
good idea.
This is actually a bug in the patch… The plugin does not need this
function. Updated patch (which only adds utils_find_open_xml_tag_pos)
attached.
--
Best regards,
Eugene.
diff --git a/ChangeLog b/ChangeLog
index 7a2600b..29e5a99 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2011-04-19 Eugene Arshinov earshinov(at)gmail(dot)com
+
+ * plugins/geanyfunctions.h, src/plugindata.h, src/plugins.c,
+ src/utils.c, src/utils.h:
+ Add utils_find_open_xml_tag_pos() function which was previously a
+ part of utils_find_open_xml_tag(). Add the new function to API.
+
+
2011-04-19 Nick Treleaven nick(dot)treleaven(at)btinternet(dot)com
* src/editor.c:
diff --git a/plugins/geanyfunctions.h b/plugins/geanyfunctions.h
index 8814cfc..5af341e 100644
--- a/plugins/geanyfunctions.h
+++ b/plugins/geanyfunctions.h
@@ -262,6 +262,8 @@
geany_functions-p_utils-utils_copy_environment
#define utils_find_open_xml_tag \
geany_functions-p_utils-utils_find_open_xml_tag
+#define utils_find_open_xml_tag_pos \
+ geany_functions-p_utils-utils_find_open_xml_tag_pos
#define ui_dialog_vbox_new \
geany_functions-p_ui-ui_dialog_vbox_new
#define ui_frame_new_with_alignment \
diff --git a/src/plugindata.h b/src/plugindata.h
index a831cb7..444f5ed 100644
--- a/src/plugindata.h
+++ b/src/plugindata.h
@@ -54,7 +54,7 @@
* @warning You should not test for values below 200 as previously
* @c GEANY_API_VERSION was defined as an enum value, not a macro.
*/
-#define GEANY_API_VERSION 209
+#define GEANY_API_VERSION 210
/** The Application Binary Interface (ABI) version, incremented whenever
* existing fields in the plugin data types have to be changed or reordered.
@@ -439,6 +439,7 @@ typedef struct UtilsFuncs
GError **error);
gchar** (*utils_copy_environment)(const gchar **exclude_vars, const gchar *first_varname, ...);
gchar* (*utils_find_open_xml_tag) (const gchar sel[], gint size);
+ const gchar* (*utils_find_open_xml_tag_pos) (const gchar sel[], gint size);
}
UtilsFuncs;
diff --git a/src/plugins.c b/src/plugins.c
index 886332c..66c7d9e 100644
--- a/src/plugins.c
+++ b/src/plugins.c
@@ -225,7 +225,8 @@ static UtilsFuncs utils_funcs = {
utils_str_remove_chars,
utils_get_file_list_full,
utils_copy_environment,
- utils_find_open_xml_tag
+ utils_find_open_xml_tag,
+ utils_find_open_xml_tag_pos
};
static UIUtilsFuncs uiutils_funcs = {
diff --git a/src/utils.c b/src/utils.c
index 5ea6042..9125118 100644
--- a/src/utils.c
+++ b/src/utils.c
@@ -285,13 +285,34 @@ gint utils_write_file(const gchar *filename, const gchar *text)
}
-/** Searches backward through @a size bytes looking for a '', then returns the tag, if any.
+/** Searches backward through @a size bytes looking for a ''
* @param sel .
* @param size .
- * @return The tag name.
+ * @return The tag name (newly allocated) or @c NULL if no opening tag was found
*/
gchar *utils_find_open_xml_tag(const gchar sel[], gint size)
{
+ const gchar *cur, *begin;
+
+ cur = utils_find_open_xml_tag_pos(sel, size);
+ if (cur == NULL)
+ return NULL;
+
+ cur++; /* skip the bracket */
+ begin = cur;
+ while (strchr(:_-., *cur) || isalnum(*cur))
+ cur++;
+ return g_strndup(begin, cur-begin);
+}
+
+
+/** Searches backward through @a size bytes looking for a ''
+ * @param sel .
+ * @param size .
+ * @return pointer to '' of the found opening tag within @a sel, or @c NULL if no opening tag was found
+ */
+const gchar *utils_find_open_xml_tag_pos(const gchar sel[], gint size)
+{
/* stolen from anjuta and modified */
const gchar *begin, *cur;
@@ -319,27 +340,15 @@ gchar *utils_find_open_xml_tag(const gchar sel[], gint size)
{
if (*cur == '')
break;
+ /* exit immediately if such non-valid XML/HTML is detected, e.g. scriptif a */
else if (*cur == '')
break;
--cur;
}
- if (*cur == '')
- {
- GString *result;
-
- cur++;
- if (*cur == '/')
- return NULL; /* we found a closing tag */
-
- result
Re: [Geany-devel] rewritten load_startup_files()
On Wed, 13 Apr 2011 21:51:17 +0300% Dimitar Zhekov dimitar.zhe...@gmail.com wrote: Hi (sigh), My first implementation was a bit naive. With Project based session files turned off, specifying a CL project should have absolutely no effect on the session loading. In particular, not only --no-session, but any of Load files from the last session = off, --new-instance, or CL file names after the project name should block the session. Not much of a difference though... Hi. I'd like to vote for including this patch. First of all, because it makes Geany behave ALMOST EXACTLY like it does in SM branch :D I must note that this version print GTK assertion in a couple of cases. This happens when user tries to (1) simultaneously open a project and load the default session and at the same time (2) has Use project-based project files preference unchecked. In these conditions the code calls (in the following order): main_load_project_from_command_line(); load_session_project_file(); configuration_open_files(); open_cl_files(); Function load_config() called by load_session_project_file() checks if any project is already loaded. The check fails, and load_config() does nothing except printing the assertion. So, the solution will be not to call load_session_project_file() here (as it does not do anything anyway, and default session seems to open even without this call). The second thought is that the code in this patch and in SM branch is QUITE different (although it behaves the same). Of course, I would prefer if Dimitar 1. took SM version 2. changed the code to get project filename from `argv' instead of new command-line option (cl_options.project) added in SM 2. cut off the unnecessary checks (**) 3. add a check for new_instance (in SM it implies load_session=false, so in my code I don't need to explicitly check new_instance) In this case the resulting code would be more similar to existing SM's… But (as you can see) there are maybe too many modifications that can introduce bugs (which are hard to find as all testing, I guess, is manual), so maybe it was a right decision to rewrite load_startup_files again from scratch (I mean, the trunk version :D). What I was trying to say is that I see three choices here 1. This patch is ignored… (so the behaviour remains a little buggy and inconvenient, as discussed by Dimitar and Lex, and different from SM's); 2. This patch is included in trunk and maybe (I am not sure it's worth doing it) I try to modify SM's version so it looks more similar and familiar for other developers who have already seen this patch's version (it will make sense if anyone anytime wants to dive into SM's version). 3. Someone takes SM version and cuts it down like I described before. I see little sense in doing it, as Dimitar has already prepared a nice patch which works fine (except the asserion) and is generally perfect (except it's code is different from SM's :D, oh I'm repeating myself). So, repeating what I said in the first paragraph, I vote for including this patch in trunk (choice #2). ** In SM there is additional handling of: - if Geany is being restored by the session manager - new load_session_if_any_files_loaded preference -- Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] rewritten load_startup_files()
On Fri, 22 Apr 2011 19:59:16 +0300% Dimitar Zhekov dimitar.zhe...@gmail.com wrote: On Fri, 22 Apr 2011 17:24:01 +0400 Eugene Arshinov earshi...@gmail.com wrote: I must note that this version print GTK assertion in a couple of cases. You only pointed one case. What are the others? This is my mistake. There is only one case (which I described). This happens when user tries to (1) simultaneously open a project and load the default session and at the same time (2) has Use project-based project files preference unchecked. [...] So, the solution will be not to call load_session_project_file() here (as it does not do anything anyway, and default session seems to open even without this call). Exactly. I was somehow under the impression that the call is needed to load the default session, but it's actually useless. Thanks. (But PBSF=off is really something - haven't seen it anywhere else.) Agree :) In SM there is additional handling of: - if Geany is being restored by the session manager - new load_session_if_any_files_loaded preference Assuming that prefs.load_session_if_any_files_loaded implies prefs.load_session: if (libsm_client_id != NULL || (prefs.load_session (argc = 1 || load_session_if_any_files_loaded) cl_options.load_session !cl_options.new_instance)) One of my goals was to make the inclusion of such things easier - just change the Load the default session condition, update the comment accordingly, and voila. Well, yes, this additional handling causes only some modification of conditions. So, I guess, it won't be hard for me to adapt you code to my SM if it's committed. -- Best regards, Eugene ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Patches for XML snippets plugin
Hi.
If anyone has some free time for me, please take a look at a message I
sent in November [1]. There I attached two patches for Geany which
were (and still are) necessary for XML Snippets plugin that was
discussed in that thread. You can also read at [1] about what the
patches do.
Now I attach the updated patches. Hope they will become a part of
Geany and the plugin (not yet released anywhere) will no longer depend
on these «third-party» patches.
[1] http://lists.uvena.de/pipermail/geany/2010-November/006210.html
--
Best regards,
Eugene.
diff --git a/ChangeLog b/ChangeLog
index 79a8519..461936a 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2011-03-29 Eugene Arshinov earshinov(at)gmail(dot)com
+
+ * src/editor.c, src/templates.c, src/templates.h:
+ Fix a bug in editor.c:snippets_make_replacements() with handling of
+ {ob} and {cb}. Function template_replace_common() now takes an
+ argument that controls if {ob} and {cb} should be replaced.
+
+
2011-03-28 Colomban Wendling colomban(at)geany(dot)org
* src/document.c, src/document.h, src/editor.c, src/keybindings.c:
diff --git a/src/editor.c b/src/editor.c
index c093e9c..1c0a11e 100644
--- a/src/editor.c
+++ b/src/editor.c
@@ -2475,12 +2475,13 @@ static gssize snippets_make_replacements(GeanyEditor *editor, GString *pattern,
gsize indent_size)
{
gssize cur_index = -1;
- gchar *whitespace;
- gint i, tmp_pos, whitespace_len, nl_count = 0;
+ gchar *whitespace, *ptr;
+ gint i, pos, whitespace_len, nl_count = 0, offset;
GHashTable *specials;
- GList *temp_list = NULL;
+ GList *temp_list = NULL, *node;
const GeanyIndentPrefs *iprefs = editor_get_indent_prefs(editor);
gint cursor_steps, old_cursor = 0;
+ gboolean cur_index_handled;
/* replace 'special' completions */
specials = g_hash_table_lookup(snippet_hash, Special);
@@ -2491,8 +2492,8 @@ static gssize snippets_make_replacements(GeanyEditor *editor, GString *pattern,
g_hash_table_foreach(specials, snippets_replace_specials, NULL);
}
- /* replace any template {foo} wildcards */
- templates_replace_common(pattern, editor-document-file_name, editor-document-file_type, NULL);
+ /* replace any template {foo} wildcards except braces {ob} and {cb} */
+ templates_replace_common(pattern, editor-document-file_name, editor-document-file_type, NULL, FALSE);
/* transform other wildcards */
/* convert to %newlines%, else we get endless loops */
@@ -2515,7 +2516,7 @@ static gssize snippets_make_replacements(GeanyEditor *editor, GString *pattern,
{
/* replace every %newline% (up to next %cursor%) with EOL,
* and update cursor_steps after */
- while ((tmp_pos = utils_strpos(pattern-str, %newline%)) cursor_steps tmp_pos != -1)
+ while ((pos = utils_strpos(pattern-str, %newline%)) cursor_steps pos != -1)
{
nl_count++;
utils_string_replace_first(pattern, %newline%, editor_get_eol_char(editor));
@@ -2523,7 +2524,7 @@ static gssize snippets_make_replacements(GeanyEditor *editor, GString *pattern,
}
/* replace every %ws% (up to next %cursor%) with whitespaces,
* and update cursor_steps after */
- while ((tmp_pos = utils_strpos(pattern-str, %ws%)) cursor_steps tmp_pos != -1)
+ while ((pos = utils_strpos(pattern-str, %ws%)) cursor_steps pos != -1)
{
utils_string_replace_first(pattern, %ws%, whitespace);
cursor_steps = utils_strpos(pattern-str, %cursor%);
@@ -2553,16 +2554,61 @@ static gssize snippets_make_replacements(GeanyEditor *editor, GString *pattern,
g_free(whitespace);
/* escape % last */
- /* Bug: {ob}pc{cb} will be replaced by % too */
- templates_replace_valist(pattern, {pc}, %, NULL);
+ pos = 0;
+ offset = 0;
+ node = temp_list;
+ cur_index_handled = FALSE;
+ while ((ptr = strchr(pattern-str + pos, '{')) != NULL)
+ {
+ pos = ptr - pattern-str;
+
+ /* synchronously iterate the list of cursor positions, applying current offset
+ * remember to handle cur_index separately */
+ if (!cur_index_handled cur_index + offset = pos)
+ {
+ cur_index += offset;
+ cur_index_handled = TRUE;
+ }
+ while (node GPOINTER_TO_INT(node-data) + offset = pos)
+ {
+ node-data += offset;
+ node = node-next;
+ }
+
+ if (strncmp(pattern-str + pos + 1, pc}, 3) == 0)
+ {
+ g_string_erase(pattern, pos + 1, 3);
+ pattern-str[pos] = '%';
+ pos++; /* one char inserted */
+ offset -= 3; /* pattern became 3 chars shorter */
+ }
+ else if (strncmp(pattern-str + pos + 1, ob}, 3) == 0)
+ {
+ g_string_erase(pattern, pos + 1, 3);
+ pattern-str[pos] = '{';
+ pos++; /* one char inserted */
+ offset -= 3; /* pattern became 3 chars shorter */
+ }
+ else if (strncmp(pattern-str + pos + 1, cb}, 3) == 0)
+ {
+ g_string_erase(pattern, pos + 1, 3);
+ pattern-str[pos] = '}';
+ pos++; /* one char inserted */
+ offset -= 3; /* pattern became 3 chars shorter */
+ }
+ else
+ pos++; /* skip the brace */
+ }
+ if (!cur_index_handled)
+ cur_index += offset;
+ for (; node; node = node-next)
+ node-data
Re: [Geany-devel] Proposed patch to fix issues with command line file loading
On Sat, 29 Jan 2011 11:11:27 +1100% Lex Trotman ele...@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. 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. 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. 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. BTW, great summary. 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
Re: [Geany-devel] Proposed patch to fix issues with command line file loading
On Sat, 29 Jan 2011 21:59:37 +1100% Lex Trotman ele...@gmail.com wrote: On 29 January 2011 19:35, Eugene Arshinov earshi...@gmail.com wrote: On Sat, 29 Jan 2011 11:11:27 +1100% Lex Trotman ele...@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. 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. 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. 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
Re: [Geany-devel] Proposed patch to fix issues with command line file loading
On Thu, 27 Jan 2011 10:20:26 +0100% weltall welta...@gmail.com wrote: 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 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. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] GIO file monitor - Re: Changed file saving implementation for systems with GIO
Hello Enrico, Lex, and Nick :) Sorry for the delay. On Mon, 29 Nov 2010 12:26:22 +% Nick Treleaven nick.trelea...@btinternet.com wrote: On Mon, 29 Nov 2010 09:18:56 +1100 Lex Trotman ele...@gmail.com wrote: I'm not surprised this code broke. I don't maintain it anymore and didn't expect anyone is still using it. I even think we should remove it as it never really worked as it should, AFAIR. The only reason I didn't yet remove is that it is hard for me as I spent so much time on it :). But as I don't have time to spend on it to get it actually working, we either remove it or someone else wants to maintain/improve/fix it. I turned on the #define only for an experiment, and it worked nicely for me (maybe because I don't use remote filesystems). I like that updated files are colored, so I can easily see which are changed/removed (btw, Reload all command would be useful). The code broke only after g_file_replace_contents was introduced because the code didn't account that there can be several change notifications for single write. The not-so-large patch I attached fixes this bug. But as said, so far, I'm not surprised it's dead and I don't care about fixing it. Sorry. Well, Eugenes solution looks ok, if he provides a clean patch with the last things discussed it could be applied to unstable for testing. You mean changing from doc-priv-mtime st.st_mtime to doc-priv-mtime != st.st_mtime? Yes, as I already wrote before, I think it's meaningful, so I'll send an updated patch if needed. Also, if we check mtime on change notification, maybe we no longer need FILE_IGNORE constant. This will cost us an additional mtime check. Yes, or perhaps it could go to trunk - I think USE_GIO_FILEMON is not documented anywhere so it shouldn't affect ordinary users. I agree :) Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] GIO file monitor - Re: Changed file saving implementation for systems with GIO
Hi.
I don't know whether it was this change which caused this, but after I
updated recently to r5395 and turned on the #define in document.c which
controls using GIO file monitor, each time I save a document (I only
use local filesystems) I get a dialog telling me the file was changed.
In debug output coming from document.c:monitor_file_changed_cb() I see
that CHANGE notification is sent twice after a file is saved. Maybe
it's g_file_replace_contents() which cause this, or it's a bug in my
GLib version, I don't know. I changed the code of the callback to
check mtime before setting doc-file_disk_status to CHANGE, and file
saving is now works correctly for me. If you think this change is
meaningful, consider the patch I attach. Apart of the change in the
callback it contains some other staff (which you may wish to not
commit).
Best regards,
Eugene.diff --git a/src/document.c b/src/document.c
index 7155460..b3ff914 100644
--- a/src/document.c
+++ b/src/document.c
@@ -436,37 +436,56 @@ static void monitor_file_changed_cb(G_GNUC_UNUSED GFileMonitor *monitor, G_GNUC_
G_GNUC_UNUSED GFile *other_file, GFileMonitorEvent event,
GeanyDocument *doc)
{
- g_return_if_fail(doc != NULL);
+ const gchar* prev_status_name;
+ const gchar* event_name;
+ const gchar* status_name;
+ g_return_if_fail(doc != NULL);
if (file_prefs.disk_check_timeout == 0)
return;
- geany_debug(%s: event: %d previous file status: %d,
- G_STRFUNC, event, doc-priv-file_disk_status);
+ prev_status_name = file_disk_status_get_name(doc-priv-file_disk_status);
+
switch (event)
{
case G_FILE_MONITOR_EVENT_CHANGES_DONE_HINT:
{
+ event_name = CHANGED;
if (doc-priv-file_disk_status == FILE_IGNORE)
doc-priv-file_disk_status = FILE_OK;
- else
-doc-priv-file_disk_status = FILE_CHANGED;
- g_message(%s: FILE_CHANGED, G_STRFUNC);
+ else if (doc-priv-file_disk_status != FILE_CHANGED)
+ {
+gboolean changed = TRUE;
+gchar *locale_filename = utils_get_locale_from_utf8(doc-file_name);
+struct stat st;
+if (g_stat(locale_filename, st) != 0)
+ g_warning(%s: Could not query mtime, G_STRFUNC);
+else
+ changed = doc-priv-mtime st.st_mtime;
+g_free(locale_filename);
+
+if (changed)
+ doc-priv-file_disk_status = FILE_CHANGED;
+ }
break;
}
case G_FILE_MONITOR_EVENT_DELETED:
{
+ event_name = DELETED;
doc-priv-file_disk_status = FILE_CHANGED;
- g_message(%s: FILE_MISSING, G_STRFUNC);
break;
}
default:
+ event_name = UNKNOWN;
break;
}
+
+ status_name = file_disk_status_get_name(doc-priv-file_disk_status);
+ geany_debug(%s: event: %s; status: %s - %s,
+ G_STRFUNC, event_name, prev_status_name, status_name);
+
if (doc-priv-file_disk_status != FILE_OK)
- {
ui_update_tab_status(doc);
- }
}
#endif
@@ -780,10 +799,9 @@ GeanyDocument *document_new_file(const gchar *utf8_filename, GeanyFiletype *ft,
editor_goto_pos(doc-editor, 0, FALSE);
document_try_focus(doc, NULL);
+ doc-priv-mtime = time(NULL);
#if USE_GIO_FILEMON
monitor_file_setup(doc);
-#else
- doc-priv-mtime = time(NULL);
#endif
/* the SCI signal (connect after initial setup(i.e. adding text)) */
@@ -1473,7 +1491,6 @@ gboolean document_reload_file(GeanyDocument *doc, const gchar *forced_enc)
static gboolean document_update_timestamp(GeanyDocument *doc, const gchar *locale_filename)
{
-#if ! USE_GIO_FILEMON
struct stat st;
g_return_val_if_fail(doc != NULL, FALSE);
@@ -1488,7 +1505,6 @@ static gboolean document_update_timestamp(GeanyDocument *doc, const gchar *local
}
doc-priv-mtime = st.st_mtime; /* get the modification time from file and keep it */
-#endif
return TRUE;
}
@@ -3024,8 +3040,8 @@ gboolean document_check_disk_status(GeanyDocument *doc, gboolean force)
if (file_prefs.disk_check_timeout == 0 || doc-real_path == NULL || doc-priv-is_remote)
return FALSE;
+ cur_time = time(NULL);
use_gio_filemon = (doc-priv-monitor != NULL);
-
if (use_gio_filemon)
{
if (doc-priv-file_disk_status != FILE_CHANGED ! force)
@@ -3033,10 +3049,8 @@ gboolean document_check_disk_status(GeanyDocument *doc, gboolean force)
}
else
{
- cur_time = time(NULL);
if (! force doc-priv-last_check (cur_time - file_prefs.disk_check_timeout))
return FALSE;
-
doc-priv-last_check = cur_time;
}
@@ -3047,8 +3061,7 @@ gboolean document_check_disk_status(GeanyDocument *doc, gboolean force)
/* doc may be closed now */
ret = TRUE;
}
- else if (! use_gio_filemon /* ignore these checks when using GIO */
- (G_UNLIKELY(doc-priv-mtime cur_time) || G_UNLIKELY(st.st_mtime cur_time)))
+ else if (G_UNLIKELY(doc-priv-mtime cur_time || st.st_mtime cur_time))
{
g_warning(%s: Something is wrong with the time stamps., G_STRFUNC);
}
@@ -3072,3 +3085,17 @@ gboolean document_check_disk_status(GeanyDocument *doc, gboolean force)
}
+const gchar* file_disk_status_get_name(FileDiskStatus status)
+{
+ switch(status)
+ {
+ case
Re: [Geany-devel] GIO file monitor - Re: Changed file saving implementation for systems with GIO
On Sun, 14 Nov 2010 21:24:39 +1100% Lex Trotman ele...@gmail.com wrote: On 14 November 2010 20:31, Eugene Arshinov earshi...@gmail.com wrote: Hi. I don't know whether it was this change which caused this, but after I updated recently to r5395 and turned on the #define in document.c which controls using GIO file monitor, each time I save a document (I only use local filesystems) I get a dialog telling me the file was changed. In debug output coming from document.c:monitor_file_changed_cb() I see that CHANGE notification is sent twice after a file is saved. Maybe it's g_file_replace_contents() which cause this, Possibly, g_file_replace_contents writes to the temp file and then renames the temp file to the old file, but why two??. The interesting thing is why doesn't any change to the file trigger the monitor no matter how its written?? Why does it only happen for GIO IO?? I was not fully correct. There were 2 CHANGE notifications and 1 unknown notification between them. Here is the output I get after opening, changing and saving a file: Geany-INFO: /tmp/temp.xml : XML (UTF-8) Geany-INFO: /tmp/temp.xml : XML (UTF-8) Geany-INFO: monitor_file_changed_cb: event: CHANGED; status: IGNORE - OK Geany-INFO: monitor_file_changed_cb: event: UNKNOWN; status: OK - OK Geany-INFO: monitor_file_changed_cb: event: CHANGED; status: OK - OK Note that with my patch the output is different from trunk, but things should be clear. I'll investigate the unknown notification a bit later today, maybe it is caused by the rename. or it's a bug in my GLib version, I don't know. Which version?? Recent 2.26.0 I changed the code of the callback to check mtime before setting doc-file_disk_status to CHANGE, and file saving is now works correctly for me. If you think this change is meaningful, consider the patch I attach. Apart of the change in the callback it contains some other staff (which you may wish to not commit). Well thats one way of telling the monitor that we know about the changes because we caused them :-) Cheers Lex Best regards, Eugene. ___ 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
Re: [Geany-devel] GIO file monitor - Re: Changed file saving implementation for systems with GIO
On Sun, 14 Nov 2010 22:02:31 +1100% Lex Trotman ele...@gmail.com wrote: On 14 November 2010 21:37, Eugene Arshinov earshi...@gmail.com wrote: On Sun, 14 Nov 2010 21:24:39 +1100% Lex Trotman ele...@gmail.com wrote: On 14 November 2010 20:31, Eugene Arshinov earshi...@gmail.com wrote: Hi. I don't know whether it was this change which caused this, but after I updated recently to r5395 and turned on the #define in document.c which controls using GIO file monitor, each time I save a document (I only use local filesystems) I get a dialog telling me the file was changed. In debug output coming from document.c:monitor_file_changed_cb() I see that CHANGE notification is sent twice after a file is saved. Maybe it's g_file_replace_contents() which cause this, Possibly, g_file_replace_contents writes to the temp file and then renames the temp file to the old file, but why two??. The interesting thing is why doesn't any change to the file trigger the monitor no matter how its written?? Why does it only happen for GIO IO?? I was not fully correct. There were 2 CHANGE notifications and 1 unknown notification between them. Here is the output I get after opening, changing and saving a file: Geany-INFO: /tmp/temp.xml : XML (UTF-8) Geany-INFO: /tmp/temp.xml : XML (UTF-8) Geany-INFO: monitor_file_changed_cb: event: CHANGED; status: IGNORE - OK Geany-INFO: monitor_file_changed_cb: event: UNKNOWN; status: OK - OK Geany-INFO: monitor_file_changed_cb: event: CHANGED; status: OK - OK Since what is called change here is actually last_change_hint, you could actually get it several times because its only probably the last change. Yes, and it also means that the original implementation, which ignores exactly one hint callback receives, is wrong. The comments near the #define actually tell that GIO based file monitoring is not completely stable, but when I ran an older version of Geany (maybe rev. 5380) with the #define turned on, saving seemed to work fine. Though there is a high probability that I'm wrong because I used that version only for testing new patches (i.e., rarely). Anyway, seems that I need to find a version where saving began to fail. The unknown could be move/rename delete or just plain change (probably *not* last??). Note that with my patch the output is different from trunk, but things should be clear. I'll investigate the unknown notification a bit later today, maybe it is caused by the rename. I'm not sure how g_file_monitor would report an atomic rename of a temp file over the file we are monitoring?? The directory entry is changed and the old inode and data deleted if this was the last hard link. You would have to test it or look at the source. Yes, there's a need for experiments. But I still don't understand why using g_file_set_contents or plain fwrite doesn't trigger the monitor?? I can't see anywhere in document.c where it muzzles the monitor whilst saving. Seems strange for me too. Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] GIO file monitor - Re: Changed file saving implementation for systems with GIO
On Sun, 14 Nov 2010 19:29:08 +0300% Eugene Arshinov earshi...@gmail.com wrote: On Sun, 14 Nov 2010 14:25:54 +0300% Eugene Arshinov earshi...@gmail.com wrote: On Sun, 14 Nov 2010 22:02:31 +1100% Lex Trotman ele...@gmail.com wrote: I'm not sure how g_file_monitor would report an atomic rename of a temp file over the file we are monitoring?? The directory entry is changed and the old inode and data deleted if this was the last hard link. You would have to test it or look at the source. Yes, there's a need for experiments. r5395 Geany-INFO: monitor_file_changed_cb: event: 1 previous file status: 2 Geany-Message: monitor_file_changed_cb: FILE_CHANGED Geany-INFO: monitor_file_changed_cb: event: 3 previous file status: 0 Geany-INFO: monitor_file_changed_cb: event: 1 previous file status: 0 Geany-Message: monitor_file_changed_cb: FILE_CHANGED r5065 (before g_file_replace_contents()) Geany-INFO: monitor_file_changed_cb: event: 0 previous file status: 2 Geany-INFO: monitor_file_changed_cb: event: 1 previous file status: 2 Geany-Message: monitor_file_changed_cb: FILE_CHANGED Events: 0 - CHANGED 1 - CHANGES_HINT (handled in Geany) 3 - CREATED It's natural that CREATED is reported, but it's still unclear why the first CHANGES_HINT is sent. Going to investigate further… Okay, [1] is the function of GLib 2.26.0 which is finally called in my case to open a stream for writing. In this particular case the original file is opened, but the fd is never used: instead a temporary file is opened and its fd is returned, and the original fd is just closed, hence the first meaningless change hint. By the way, the function hasn't changed in GLib's trunk since 2.26.0. [1] http://nopaste.geany.org/p/mefaf389 Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] GIO file monitor - Re: Changed file saving implementation for systems with GIO
On Mon, 15 Nov 2010 09:41:53 +1100% Lex Trotman ele...@gmail.com wrote: On 15 November 2010 03:29, Eugene Arshinov earshi...@gmail.com wrote: Some results after preliminary investigation: On Sun, 14 Nov 2010 14:25:54 +0300% Eugene Arshinov earshi...@gmail.com wrote: On Sun, 14 Nov 2010 22:02:31 +1100% Lex Trotman ele...@gmail.com wrote: On 14 November 2010 21:37, Eugene Arshinov earshi...@gmail.com wrote: On Sun, 14 Nov 2010 21:24:39 +1100% Lex Trotman ele...@gmail.com wrote: On 14 November 2010 20:31, Eugene Arshinov earshi...@gmail.com wrote: Hi. I don't know whether it was this change which caused this, but after I updated recently to r5395 and turned on the #define in document.c which controls using GIO file monitor, each time I save a document (I only use local filesystems) I get a dialog telling me the file was changed. In debug output coming from document.c:monitor_file_changed_cb() I see that CHANGE notification is sent twice after a file is saved. Maybe it's g_file_replace_contents() which cause this, Possibly, g_file_replace_contents writes to the temp file and then renames the temp file to the old file, but why two??. The interesting thing is why doesn't any change to the file trigger the monitor no matter how its written?? Why does it only happen for GIO IO?? I was not fully correct. There were 2 CHANGE notifications and 1 unknown notification between them. Here is the output I get after opening, changing and saving a file: Geany-INFO: /tmp/temp.xml : XML (UTF-8) Geany-INFO: /tmp/temp.xml : XML (UTF-8) Geany-INFO: monitor_file_changed_cb: event: CHANGED; status: IGNORE - OK Geany-INFO: monitor_file_changed_cb: event: UNKNOWN; status: OK - OK Geany-INFO: monitor_file_changed_cb: event: CHANGED; status: OK - OK Since what is called change here is actually last_change_hint, you could actually get it several times because its only probably the last change. Yes, and it also means that the original implementation, which ignores exactly one hint callback receives, is wrong. The comments near the #define actually tell that GIO based file monitoring is not completely stable, but when I ran an older version of Geany (maybe rev. 5380) with the #define turned on, saving seemed to work fine. Though there is a high probability that I'm wrong because I used that version only for testing new patches (i.e., rarely). Anyway, seems that I need to find a version where saving began to fail. Okay, it still fails at r5380. The change is caused by g_file_replace_contents() which was introduced before than that. The unknown could be move/rename delete or just plain change (probably *not* last??). Note that with my patch the output is different from trunk, but things should be clear. I'll investigate the unknown notification a bit later today, maybe it is caused by the rename. I'm not sure how g_file_monitor would report an atomic rename of a temp file over the file we are monitoring?? The directory entry is changed and the old inode and data deleted if this was the last hard link. You would have to test it or look at the source. Yes, there's a need for experiments. r5395 Geany-INFO: monitor_file_changed_cb: event: 1 previous file status: 2 Probably the change of atime, though I would have expected that to be an attribute change event. Geany-Message: monitor_file_changed_cb: FILE_CHANGED Geany-INFO: monitor_file_changed_cb: event: 3 previous file status: 0 Create when the rename is done, OK Geany-INFO: monitor_file_changed_cb: event: 1 previous file status: 0 Geany-Message: monitor_file_changed_cb: FILE_CHANGED Thats another change of atime when the file descriptor is closed (on Unix its closed *after* the rename). r5065 (before g_file_replace_contents()) Geany-INFO: monitor_file_changed_cb: event: 0 previous file status: 2 Geany-INFO: monitor_file_changed_cb: event: 1 previous file status: 2 Geany-Message: monitor_file_changed_cb: FILE_CHANGED And with safe file saving (ie g_file_set_contents) it just gets: Geany-INFO: monitor_file_changed_cb: event: 3 previous file status: 2 Because it only does the rename it doesn't do the other opens and closes. Its not the Glib version, it happens for me on 2.24.1 as well. The above looks to me like Glib is working properly, Geany just needs to learn to ignore changes of its own making better. Your mtime patch looks sensible to me, since we really don't want to reload unless the content changed. We don't care about changes to metadata since we don't use it. Except I suggest: changed = doc-priv-mtime st.st_mtime; be != instead of in case someone restores an old version using a tool that also restores the mtime
Re: [Geany-devel] HTML/XML autoindentation - Re: [PATCH] Some editor/snippets/keybindings enhancements
On Wed, 10 Nov 2010 17:51:18 +%
Nick Treleaven nick.trelea...@btinternet.com wrote:
On Tue, 2 Nov 2010 23:28:43 +0300
Eugene Arshinov earshi...@gmail.com wrote:
I think just add a html_tag_autoindentation field to
GeanyFiletypePrivate and use that.
Okay, the patch is attached.
Thanks, applied (with some changes).
I named the field 'xml_indent_tags' and
the filetype property 'indent_tags'. By default (like all fields in
GeanyFiletypePrivate) it is zero, but in global
filetypes.{xml,html} I set it to true.
I changed the filetype property to xml_indent_tags also, I think it's
clearer.
I changed the code slightly to check whether the document uses the
HTML/XML lexer rather than those filetypes, and to always read the
property. This should allow other filetypes that have XML syntax to
work also if the property is set.
Agree. Thanks for update and commit.
BTW, should we set xml_indent_tags=true for PHP, Docbook filetypes?
I think, yes, we should. I attach a patch that have this changes plus
some documentation in geany.txt (if you use this patch, please
regenerate geany.html yourself as my rst2html causes most of this file
to be changed).
Best regards,
Eugene.diff --git a/data/filetypes.docbook b/data/filetypes.docbook
index 26a7e11..8d16287 100644
--- a/data/filetypes.docbook
+++ b/data/filetypes.docbook
@@ -61,3 +61,7 @@ comment_use_indent=true
# context action command (please see Geany's main documentation for details)
context_action_cmd=
+
+# if this setting is set to true, a new line after a line ending with an
+# unclosed tag will be automatically indented
+indent_tags=true
\ No newline at end of file
diff --git a/data/filetypes.html b/data/filetypes.html
index e18ce75..f4cd2f6 100644
--- a/data/filetypes.html
+++ b/data/filetypes.html
@@ -32,7 +32,7 @@ comment_use_indent=true
# context action command (please see Geany's main documentation for details)
context_action_cmd=
-# If this setting is set to true, a new line after a line ending with an
+# if this setting is set to true, a new line after a line ending with an
# unclosed tag will be automatically indented
xml_indent_tags=true
diff --git a/data/filetypes.php b/data/filetypes.php
index 4d63874..ef80136 100644
--- a/data/filetypes.php
+++ b/data/filetypes.php
@@ -28,6 +28,10 @@ comment_use_indent=true
# context action command (please see Geany's main documentation for details)
context_action_cmd=
+# if this setting is set to true, a new line after a line ending with an
+# unclosed tag will be automatically indented
+indent_tags=true
+
[build_settings]
# %f will be replaced by the complete filename
# %e will be replaced by the filename without extension
diff --git a/data/filetypes.xml b/data/filetypes.xml
index e067e3d..62dde6e 100644
--- a/data/filetypes.xml
+++ b/data/filetypes.xml
@@ -103,6 +103,6 @@ comment_use_indent=true
# context action command (please see Geany's main documentation for details)
context_action_cmd=
-# If this setting is set to true, a new line after a line ending with an
+# if this setting is set to true, a new line after a line ending with an
# unclosed tag will be automatically indented
-xml_indent_tags=true
\ No newline at end of file
+xml_indent_tags=true
diff --git a/doc/geany.txt b/doc/geany.txt
index 6896419..8609583 100644
--- a/doc/geany.txt
+++ b/doc/geany.txt
@@ -3731,6 +3731,12 @@ symbol_list_sort_mode
1 Sort tags by appearance (line number)
= =
+xml_indent_tags
+If this setting is set to true, a new line after a line ending with an
+unclosed XML/HTML tag will be automatically indented. This only applies
+to filetypes for which HTML or XML lexer is used. Such filetypes have
+this setting in their system configuration files.
+
[build_settings] Section
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] HTML/XML autoindentation - Re: [PATCH] Some editor/snippets/keybindings enhancements
On Tue, 2 Nov 2010 15:13:12 +%
Nick Treleaven nick.trelea...@btinternet.com wrote:
On Fri, 29 Oct 2010 21:56:53 +0400
Eugene Arshinov earshi...@gmail.com wrote:
I wasn't thinking of brace autoindentation. In that case perhaps
it's simpler to add a HTML-specific setting to disable tag
autoindentation.
It makes sense, but since now I could not find an acceptable way to
implement it. I've just discovered that GeanyFiletype's are stored
in a pointer array, so instead of ordinary GeanyFiletype for HTML we
may add to the array an instance of hypothetical HtmlFiletype
{ GeanyFiletype parent; gboolean enable_tag_autoindentation } and of
course write some code to load enable_tag_autoindentation from
filetype config. Is it OK?
I think just add a html_tag_autoindentation field to
GeanyFiletypePrivate and use that.
Okay, the patch is attached. I named the field 'xml_indent_tags' and
the filetype property 'indent_tags'. By default (like all fields in
GeanyFiletypePrivate) it is zero, but in global filetypes.{xml,html} I
set it to true.
Best regards,
Eugene.diff --git a/data/filetypes.html b/data/filetypes.html
index 1e63c0c..9dcf5b2 100644
--- a/data/filetypes.html
+++ b/data/filetypes.html
@@ -32,6 +32,10 @@ comment_use_indent=true
# context action command (please see Geany's main documentation for details)
context_action_cmd=
+# If this setting is set to true, a new line after a line ending with an
+# unclosed tag will be automatically indented
+indent_tags=true
+
[build_settings]
# %f will be replaced by the complete filename
# %e will be replaced by the filename without extension
diff --git a/data/filetypes.xml b/data/filetypes.xml
index e71c8fc..17113fe 100644
--- a/data/filetypes.xml
+++ b/data/filetypes.xml
@@ -103,3 +103,6 @@ comment_use_indent=true
# context action command (please see Geany's main documentation for details)
context_action_cmd=
+# If this setting is set to true, a new line after a line ending with an
+# unclosed tag will be automatically indented
+indent_tags=true
\ No newline at end of file
diff --git a/src/editor.c b/src/editor.c
index 33483ae..4f12952 100644
--- a/src/editor.c
+++ b/src/editor.c
@@ -55,6 +55,7 @@
#include document.h
#include documentprivate.h
#include filetypes.h
+#include filetypesprivate.h
#include sciwrappers.h
#include ui_utils.h
#include utils.h
@@ -1360,7 +1361,8 @@ static gint get_indent_size_after_line(GeanyEditor *editor, gint line)
* should make the XML-related check */
if (additional_indent == 0 !editor_prefs.auto_close_xml_tags
(editor-document-file_type-id == GEANY_FILETYPES_HTML ||
- editor-document-file_type-id == GEANY_FILETYPES_XML))
+ editor-document-file_type-id == GEANY_FILETYPES_XML)
+ filetypes[editor-document-file_type-id]-priv-xml_indent_tags)
{
size += iprefs-width * get_xml_indent(sci, line);
}
diff --git a/src/filetypes.c b/src/filetypes.c
index e4d2a5b..b205774 100644
--- a/src/filetypes.c
+++ b/src/filetypes.c
@@ -1110,6 +1110,20 @@ static void load_settings(gint ft_id, GKeyFile *config, GKeyFile *configh)
/* read build settings */
build_load_menu(config, GEANY_BCS_FT, (gpointer)ft);
build_load_menu(configh, GEANY_BCS_HOME_FT, (gpointer)ft);
+
+ if (ft_id == GEANY_FILETYPES_XML || ft_id == GEANY_FILETYPES_HTML)
+ {
+ tmp = g_key_file_get_boolean(configh, settings, indent_tags, error);
+ if (error)
+ {
+ g_error_free(error);
+ error = NULL;
+ tmp = g_key_file_get_boolean(config, settings, indent_tags, error);
+ if (error) g_error_free(error);
+ else filetypes[ft_id]-priv-xml_indent_tags = tmp;
+ }
+ else filetypes[ft_id]-priv-xml_indent_tags = tmp;
+ }
}
diff --git a/src/filetypesprivate.h b/src/filetypesprivate.h
index 3a36ce9..335b602 100644
--- a/src/filetypesprivate.h
+++ b/src/filetypesprivate.h
@@ -43,6 +43,8 @@ typedef struct GeanyFiletypePrivate
gchar *last_string; /* last one compiled */
gboolean custom;
gint symbol_list_sort_mode;
+
+ gboolean xml_indent_tags; /* XML tag autoindentation, for HTML and XML filetypes */
}
GeanyFiletypePrivate;
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] HTML/XML autoindentation - Re: [PATCH] Some editor/snippets/keybindings enhancements
On Fri, 29 Oct 2010 15:31:37 +0100%
Nick Treleaven nick.trelea...@btinternet.com wrote:
On Thu, 28 Oct 2010 23:27:53 +0400
Eugene Arshinov earshi...@gmail.com wrote:
I think we could add a per-filetype indent mode option so it
would be easy to disable in case someone wanted to. The user
could then set auto-indent to basic for HTML.
I assume it's necessary to give users an opportunity to control
automatic indentation of tags (HTML) and braces (JS/PHP)
independently. I suggest making the new indent_mode option a
I wasn't thinking of brace autoindentation. In that case perhaps it's
simpler to add a HTML-specific setting to disable tag autoindentation.
It makes sense, but since now I could not find an acceptable way to
implement it. I've just discovered that GeanyFiletype's are stored
in a pointer array, so instead of ordinary GeanyFiletype for HTML we
may add to the array an instance of hypothetical HtmlFiletype
{ GeanyFiletype parent; gboolean enable_tag_autoindentation } and of
course write some code to load enable_tag_autoindentation from filetype
config. Is it OK?
Best regards,
Eugene.
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] HTML/XML autoindentation - Re: [PATCH] Some editor/snippets/keybindings enhancements
On Wed, 27 Oct 2010 17:16:59 +0100% Nick Treleaven nick.trelea...@btinternet.com wrote: On Tue, 26 Oct 2010 12:14:25 +0400 Eugene Arshinov earshi...@gmail.com wrote: For the present, I attach an updated patch which doesn't insert indentation after short HTML tags. OK, looks like a good solution. Do I understand correctly that you think we don't need GUI preference? I think we could add a per-filetype indent mode option so it would be easy to disable in case someone wanted to. The user could then set auto-indent to basic for HTML. I assume it's necessary to give users an opportunity to control automatic indentation of tags (HTML) and braces (JS/PHP) independently. I suggest making the new indent_mode option a combination of flags, each of which control what indent feature will be _disabled_. That this, the default for any filetype will be 0 (all features enabled). For filetypes which aren't HTML users will add 1 to disable autoindentation. For HTML they will add 1 to disable JS/PHP autoindentation and 2 to disable tag autoindentation. I inverse the semantics of flags, so that when an indent feature is added it will be turned on by default. Maybe it's better to name this option disable_indent and use strings instead of numbers. For example, disable_indent=braces,tags for HTML would disable autoindentation completely. Any thoughts/suggestions? Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Ensure new line on file end inserts new line when file is empty
I think it's a bug. I didn't notice it before as I usually use
addons plugin with Strip trailing blank lines option checked. Patch
attached, also modified to use utils_get_eol_char().
Best regards,
Eugene.diff --git a/src/editor.c b/src/editor.c
index a012f7d..7e01edc 100644
--- a/src/editor.c
+++ b/src/editor.c
@@ -4609,26 +4609,12 @@ void editor_strip_trailing_spaces(GeanyEditor *editor)
void editor_ensure_final_newline(GeanyEditor *editor)
{
gint max_lines = sci_get_line_count(editor-sci);
- gboolean append_newline = (max_lines == 1);
gint end_document = sci_get_position_from_line(editor-sci, max_lines);
- if (max_lines 1)
+ if (max_lines 1 end_document sci_get_position_from_line(editor-sci, max_lines - 1))
{
- append_newline = end_document sci_get_position_from_line(editor-sci, max_lines - 1);
- }
- if (append_newline)
- {
- const gchar *eol = \n;
- switch (sci_get_eol_mode(editor-sci))
- {
- case SC_EOL_CRLF:
-eol = \r\n;
-break;
- case SC_EOL_CR:
-eol = \r;
-break;
- }
- sci_insert_text(editor-sci, end_document, eol);
+ sci_insert_text(editor-sci, end_document,
+ utils_get_eol_char(sci_get_eol_mode(editor-sci)));
}
}
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Ensure new line on file end inserts new line when file is empty
On Sat, 16 Oct 2010 17:49:27 +1100% Lex Trotman ele...@gmail.com wrote: Hi Eugene, I'm not sure it is a bug, the pref setting is there is to ensure that the file ends in a newline, so an empty file will become just a new line (see od below). Thats working correctly AFAICT. l...@fred5 ~ $ od untitled 000 12 001 Cheers Lex Hi. Yes, of course it's logical that newline is always added, even for empty files. But it becomes that for non-empty files you get one empty line at the end, for empty files -- two empty lines. It's not quite useful and (IMHO) bad. Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Ensure new line on file end inserts new line when file is empty
On Sat, 16 Oct 2010 21:06:12 +1100% Lex Trotman ele...@gmail.com wrote: On 16 October 2010 19:52, Eugene Arshinov earshi...@gmail.com wrote: On Sat, 16 Oct 2010 17:49:27 +1100% Lex Trotman ele...@gmail.com wrote: Hi Eugene, I'm not sure it is a bug, the pref setting is there is to ensure that the file ends in a newline, so an empty file will become just a new line (see od below). Thats working correctly AFAICT. l...@fred5 ~ $ od untitled 000 12 001 Cheers Lex Hi. Yes, of course it's logical that newline is always added, even for empty files. But it becomes that for non-empty files you get one empty line at the end, for empty files -- two empty lines. It's not quite useful and (IMHO) bad. Well, if the file ends in a newline it will always appear as an empty line at the end even though there is nothing after the newline, the only way to avoid it is to not end in newline. If you don't like the blank line, delete the newline ... and turn off the preference so Geany won't add it back again ;-) No, I like a new line, but not two of them :D But there are some things that REQUIRE the file to end in newline, and IIUC that is what the ensure newline at file end preference is for, it has to add the newline. So it isn't a bug if the preference is selected. We may consider `wc -l' as an example. It (at least, the version I have) accounts the last line only if it ends with \n. With the option turned on, if a user creates an empty file with Geany and saves it, wc of course says it contains 1 line. I would prefer the file staying really empty and wc returning 0 lines. Note that I have to keep the option turned on to keep wc working properly in usual cases. Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Ensure new line on file end inserts new line when file is empty
Oh God, I left an erroneous check in the code. Updated patch attacked.diff --git a/src/editor.c b/src/editor.c
index a012f7d..8697c09 100644
--- a/src/editor.c
+++ b/src/editor.c
@@ -4609,26 +4609,12 @@ void editor_strip_trailing_spaces(GeanyEditor *editor)
void editor_ensure_final_newline(GeanyEditor *editor)
{
gint max_lines = sci_get_line_count(editor-sci);
- gboolean append_newline = (max_lines == 1);
gint end_document = sci_get_position_from_line(editor-sci, max_lines);
- if (max_lines 1)
+ if (end_document sci_get_position_from_line(editor-sci, max_lines - 1))
{
- append_newline = end_document sci_get_position_from_line(editor-sci, max_lines - 1);
- }
- if (append_newline)
- {
- const gchar *eol = \n;
- switch (sci_get_eol_mode(editor-sci))
- {
- case SC_EOL_CRLF:
-eol = \r\n;
-break;
- case SC_EOL_CR:
-eol = \r;
-break;
- }
- sci_insert_text(editor-sci, end_document, eol);
+ sci_insert_text(editor-sci, end_document,
+ utils_get_eol_char(sci_get_eol_mode(editor-sci)));
}
}
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Ensure new line on file end inserts new line when file is empty
On Sat, 16 Oct 2010 15:05:01 +0400 Eugene Arshinov earshi...@gmail.com wrote: Oh God, I left an erroneous check in the code. Updated patch attacked. I meant attached... ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Ensure new line on file end inserts new line when file is empty
On Sat, 16 Oct 2010 22:04:33 +1100%
Lex Trotman ele...@gmail.com wrote:
On 16 October 2010 21:39, Eugene Arshinov earshi...@gmail.com wrote:
On Sat, 16 Oct 2010 21:06:12 +1100%
Lex Trotman ele...@gmail.com wrote:
On 16 October 2010 19:52, Eugene Arshinov earshi...@gmail.com
wrote:
On Sat, 16 Oct 2010 17:49:27 +1100%
Lex Trotman ele...@gmail.com wrote:
Hi Eugene,
I'm not sure it is a bug, the pref setting is there is to ensure
that the file ends in a newline, so an empty file will become
just a new line (see od below). Thats working correctly AFAICT.
l...@fred5 ~ $ od untitled
000 12
001
Cheers
Lex
Hi.
Yes, of course it's logical that newline is always added, even
for empty files. But it becomes that for non-empty files you
get one empty line at the end, for empty files -- two empty
lines. It's not quite useful and (IMHO) bad.
Well, if the file ends in a newline it will always appear as an
empty line at the end even though there is nothing after the
newline, the only way to avoid it is to not end in newline. If
you don't like the blank line, delete the newline ... and turn off
the preference so Geany won't add it back again ;-)
No, I like a new line, but not two of them :D
But there are some things that REQUIRE the file to end in newline,
and IIUC that is what the ensure newline at file end preference
is for, it has to add the newline. So it isn't a bug if the
preference is selected.
We may consider `wc -l' as an example. It (at least, the version I
have) accounts the last line only if it ends with \n. With the
option turned on, if a user creates an empty file with Geany and
saves it, wc of course says it contains 1 line. I would prefer the
file staying really empty and wc returning 0 lines. Note that I
have to keep the option turned on to keep wc working properly in
usual cases.
I'm a bit confused, why turn on the preference in that case?
If I turn it off and write some text, for example
int main(int argc, char **argv){
return 0;
}
, and do not manually insert a newline, wc -l will return 2 which (I
believe) would be incorrect as there are 3 lines of code here.
What I
don't see is your patch checking the preference?
The function is called only when the preference is turned on. See
document_save_file() where editor_ensure_final_newline() is called.
Best regards,
Eugene.
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Ensure new line on file end inserts new line when file is empty
On Sat, 16 Oct 2010 22:37:29 +1100%
Lex Trotman ele...@gmail.com wrote:
On 16 October 2010 22:11, Eugene Arshinov earshi...@gmail.com wrote:
On Sat, 16 Oct 2010 22:04:33 +1100%
Lex Trotman ele...@gmail.com wrote:
On 16 October 2010 21:39, Eugene Arshinov earshi...@gmail.com
wrote:
On Sat, 16 Oct 2010 21:06:12 +1100%
Lex Trotman ele...@gmail.com wrote:
On 16 October 2010 19:52, Eugene Arshinov earshi...@gmail.com
wrote:
On Sat, 16 Oct 2010 17:49:27 +1100%
Lex Trotman ele...@gmail.com wrote:
Hi Eugene,
I'm not sure it is a bug, the pref setting is there is to
ensure that the file ends in a newline, so an empty file
will become just a new line (see od below). Thats working
correctly AFAICT.
l...@fred5 ~ $ od untitled
000 12
001
Cheers
Lex
Hi.
Yes, of course it's logical that newline is always added, even
for empty files. But it becomes that for non-empty files you
get one empty line at the end, for empty files -- two empty
lines. It's not quite useful and (IMHO) bad.
Well, if the file ends in a newline it will always appear as an
empty line at the end even though there is nothing after the
newline, the only way to avoid it is to not end in newline. If
you don't like the blank line, delete the newline ... and turn
off the preference so Geany won't add it back again ;-)
No, I like a new line, but not two of them :D
But there are some things that REQUIRE the file to end in
newline, and IIUC that is what the ensure newline at file end
preference is for, it has to add the newline. So it isn't a
bug if the preference is selected.
We may consider `wc -l' as an example. It (at least, the
version I have) accounts the last line only if it ends with \n.
With the option turned on, if a user creates an empty file with
Geany and saves it, wc of course says it contains 1 line. I
would prefer the file staying really empty and wc returning 0
lines. Note that I have to keep the option turned on to keep wc
working properly in usual cases.
I'm a bit confused, why turn on the preference in that case?
If I turn it off and write some text, for example
int main(int argc, char **argv){
return 0;
}
, and do not manually insert a newline, wc -l will return 2 which (I
believe) would be incorrect as there are 3 lines of code here.
Ok, so wc counts newlines, not lines, I can't say I've looked that
closely at it (or its documentation :-). But this argues that if the
option is set then Geany is correct in adding a newline, then it would
count right. But that is just one tool.
I think we are, as we say here, getting our wires a bit crossed.
What I'm expressing badly is that if a file ends in a newline you can
consider that there is nothing after that, or you can consider that it
has an empty unterminated line after the newline. Similarly an empty
file has no lines or it has one unterminated empty line. Geany takes
the empty unterminated line view, since a new untitled shows one
line on screen. But neither interpretation is right, it depends on
what you are using the file for and what the tools expect.
This is absolutely correct.
My argument is that, if someone (eg me) selects that I want my file to
end in newline (which is what the preference says) then thats what it
should do, irrespective of any interpretation or the length of the
file.
I understand what you mean and agree that this point of view is
meaningful.
My argument for unterminated lines view is that
1) Geany already uses this view in one aspect, as you wrote (and I
agree)
2) and so, to my knowledge, do most text utilities like wc (they do not
process last line if it is unterminated)
From this point of view, it's logical that Geany should never insert
unterminated empty lines, either if file is empty or when it already
contains trailing newline.
By the way, there is another argument for your point of view and
current behaviour. The code of editor_ensure_final_newline() is quite
old (it was inserted to utils.c in Initial import commit, rev 4) and
may be already considered a feature :-)
What I
don't see is your patch checking the preference?
The function is called only when the preference is turned on. See
document_save_file() where editor_ensure_final_newline() is called.
Oh Ok fine, I'm not at my development machine with all Geany source.
No problem.
Best regards,
Eugene.
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] insert line keybindings - Re: [PATCH] Some editor/snippets/keybindings enhancements
On Fri, 15 Oct 2010 18:45:11 +0100%
Nick Treleaven nick.trelea...@btinternet.com wrote:
On Fri, 8 Oct 2010 06:03:33 +0400
Eugene Arshinov earshi...@gmail.com wrote:
The drawback of the first patch is that I doubt it's so
useful. I know Vi[m] provides shortcuts for these actions ('o'
and 'O' in normal mode), but their necessity is questionable
for me. I implemented this to ease XML editing with tag
autocompletion turned on. Suppose you need to write to
consequent li's. Without this patch you need to press
End+Enter after writing the first li to place the cursor
where you need to start the second. With my patch, you only
need to press one shortcut you can assign in Preferences
Keybindings :)
Maybe we could add these. BTW you could use utils_get_eol_char().
Also we already have sci_get_line_indent_position().
I missed this function… Updated patch attached.
Thanks. Committed with changes - moved keybindings to the Insert group
and changed implementation a bit.
Thanks for committing. Your implementation using sci_send_command()
indeed looks better than mine.
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] altername session management implementation
On Fri, 8 Oct 2010 19:55:28 +0300% Dimitar Zhekov dimitar.zhe...@gmail.com wrote: On Fri, 8 Oct 2010 06:05:11 +0400 Eugene Arshinov earshi...@gmail.com wrote: On Sat, 2 Oct 2010 10:56:19 +0300% Dimitar Zhekov dimitar.zhe...@gmail.com wrote: Eugene, if you're going to combine the X SM implementatons someday, using the alternate save/restore instance, be sure to revert this change (or find a workaround, but I don't think it's worth). Thanks much for info, I'll take it into account. Something worse: an Open files in Geany at the same workspace, no matter how implemented, will be problematic for your current session save/restore. main_save() saves geany.conf for the primary instance, but there will be several primaries - one per desktop... You can switch to alternate, or lock/unlock geany.conf, or traverse the sockets. But traversing seems unreliable, a socket may be checked shortly before or after an instance dies. Actually I would prefer switching to alternate :-) But currently I don't have free time to work on this, so SM branch will stay outdated for a while… Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] snippet keybindings? - Re: [PATCH] Some editor/snippets/keybindings enhancements
Hi Nick On Tue, 5 Oct 2010 12:10:08 +0100% Nick Treleaven nick.trelea...@btinternet.com wrote: On Fri, 1 Oct 2010 16:12:40 +0100 Nick Treleaven nick.trelea...@btinternet.com wrote: Maybe we can incorporate the first patch into Geany? Power users who need snippet keybindings will be able to specify keybindings manually in snippets.conf, just like hidden prefs in geany.conf. This will keep the implementation simple, and ordinary users mostly likely do not need the keybindings. Now committed but changed so the keybindings are only read from the user keyfile. Thanks for the patches. The change was mainly to make editor_snippets_init() shorter for easier understanding. Now system keyfile snippet keybindings are supported too. Thanks for committing and improving the patch. These is a little flaw in current editor.c:load_kb() function. It will probably segfault if snippets.conf does not contain Keybindings section. You should check if (keys != NULL) before doing foreach_strv(ptr, keys). Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] [PATCH] Some editor/snippets/keybindings enhancements
On Thu, 30 Sep 2010 13:23:58 +0100%
Nick Treleaven nick.trelea...@btinternet.com wrote:
On Sat, 10 Jul 2010 21:48:35 +0400
Eugene Arshinov earshi...@gmail.com wrote:
Hi all.
I attach three patches:
1. Keybindings to insert new line after/before current
...
3. Automatically insert additional indentation in XML/HTML files if
previous line ends with an opening tag
I finally got round to replying to the other patches, sorry for the
delay.
The drawback of the first patch is that I doubt it's so useful. I
know Vi[m] provides shortcuts for these actions ('o' and 'O' in
normal mode), but their necessity is questionable for me. I
implemented this to ease XML editing with tag autocompletion turned
on. Suppose you need to write to consequent li's. Without this
patch you need to press End+Enter after writing the first li to
place the cursor where you need to start the second. With my
patch, you only need to press one shortcut you can assign in
Preferences Keybindings :)
Maybe we could add these. BTW you could use utils_get_eol_char().
Also we already have sci_get_line_indent_position().
I missed this function… Updated patch attached.
The drawback of the third patch is that it's not completed. If user
likes to leave HTML tags like br unclosed, she would be
disturbed by automatic indentation caused by my patch, so a check
box in Preferences is desirable. I'll code it as soon as we decide
this patch can go to trunk.
For HTML perhaps we could have a filetype pref for this.
What should it look like? I can't name this pref autoindent because
it would be confusing if for XML and HTML it only controls the
indentation after XML/HTML tags, not after braces in PHP/JS chunks. If
I make the pref more specific (e.g., xml-autoindent), it won't
probably be quite proper to insert such a specific member to
GeanyFiletype struct.
Maybe it's more appropriate to add a check button near Preferences
Editor Indentation Auto-indent mode list? AFAIK (never used it),
Match braces mode works only for braces languages and thus is
already somewhat filetype-specific.
For the present, I attach an updated patch which doesn't insert
indentation after short HTML tags. I also modified existing tag
autocompletion code so that it doesn't check for HTML tags if current
lexer is XML, not HTML. I slightly modified utils_find_open_xml_tag()
in order to reuse it in my autoindentation code. Particularly I removed
`check_tag' parameter and strange condition
else if (! check_tag *cur == '')
break;
I'm not sure why this condition was needed there.
Best regards,
Eugene.
diff --git a/src/editor.c b/src/editor.c
index 7e3f81e..11c7737 100644
--- a/src/editor.c
+++ b/src/editor.c
@@ -4011,7 +4011,7 @@ void editor_select_paragraph(GeanyEditor *editor)
/* simple indentation to indent the current line with the same indent as the previous one */
-static void smart_line_indentation(GeanyEditor *editor, gint first_line, gint last_line)
+void editor_smart_indentation_for_lines(GeanyEditor *editor, gint first_line, gint last_line)
{
gint i, sel_start = 0, sel_end = 0;
@@ -4063,12 +4063,12 @@ void editor_smart_line_indentation(GeanyEditor *editor, gint pos)
sci_start_undo_action(sci);
- smart_line_indentation(editor, first_line, last_line);
+ editor_smart_indentation_for_lines(editor, first_line, last_line);
/* set cursor position if there was no selection */
if (first_sel_start == first_sel_end)
{
- gint indent_pos = SSM(sci, SCI_GETLINEINDENTPOSITION, first_line, 0);
+ gint indent_pos = sci_get_line_indent_position(sci, first_line);
/* use indent position as user may wish to change indentation afterwards */
sci_set_current_position(sci, indent_pos, FALSE);
@@ -4107,7 +4107,7 @@ void editor_indentation_by_one_space(GeanyEditor *editor, gint pos, gboolean dec
for (i = first_line; i = last_line; i++)
{
- indentation_end = SSM(editor-sci, SCI_GETLINEINDENTPOSITION, i, 0);
+ indentation_end = sci_get_line_indent_position(editor-sci, i);
if (decrease)
{
line_start = SSM(editor-sci, SCI_POSITIONFROMLINE, i, 0);
diff --git a/src/editor.h b/src/editor.h
index e81a074..13e5637 100644
--- a/src/editor.h
+++ b/src/editor.h
@@ -213,6 +213,8 @@ void editor_insert_alternative_whitespace(GeanyEditor *editor);
void editor_indent(GeanyEditor *editor, gboolean increase);
+void editor_smart_indentation_for_lines(GeanyEditor *editor, gint first_line, gint last_line);
+
void editor_smart_line_indentation(GeanyEditor *editor, gint pos);
void editor_indentation_by_one_space(GeanyEditor *editor, gint pos, gboolean decrease);
diff --git a/src/keybindings.c b/src/keybindings.c
index b7ad875..e25cadc 100644
--- a/src/keybindings.c
+++ b/src/keybindings.c
@@ -364,6 +364,10 @@ static void init_default_kb(void)
keybindings_set_item(group, GEANY_KEYS_FORMAT_REFLOWPARAGRAPH, NULL,
GDK_j, GDK_CONTROL_MASK, format_reflowparagraph, _(_Reflow Lines
Re: [Geany-devel] r5121 stash question
On Sat, 2 Oct 2010 10:56:19 +0300% Dimitar Zhekov dimitar.zhe...@gmail.com wrote: On Tue, 28 Sep 2010 13:45:27 +0100 Nick Treleaven nick.trelea...@btinternet.com wrote: On Sun, 26 Sep 2010 14:52:26 +0300 Dimitar Zhekov dimitar.zhe...@gmail.com wrote: 2010-08-10 Nick Treleaven * src/stash.c: Fix writing the default value when a key is missing for hidden prefs, even if it was overridden when it was originally read. In what case is this required? If a hidden pref is overriden by reading, it exists in the keyfile, and so won't be written anyway. If the user deletes the overridden line in the keyfile ;-) I see. Thanks. Eugene, if you're going to combine the X SM implementatons someday, using the alternate save/restore instance, be sure to revert this change (or find a workaround, but I don't think it's worth). Thanks much for info, I'll take it into account. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] snippet keybindings? - Re: [PATCH] Some editor/snippets/keybindings enhancements
Hi again. Maybe we can incorporate the first patch into Geany? Power users who need snippet keybindings will be able to specify keybindings manually in snippets.conf, just like hidden prefs in geany.conf. This will keep the implementation simple, and ordinary users mostly likely do not need the keybindings. Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] snippet keybindings? - Re: [PATCH] Some editor/snippets/keybindings enhancements
On Tue, 28 Sep 2010 17:57:27 +1000% Lex Trotman ele...@gmail.com wrote: On 28 September 2010 17:34, Eugene Arshinov earshi...@gmail.com wrote: Hi again. Maybe we can incorporate the first patch into Geany? Power users who need snippet keybindings will be able to specify keybindings manually in snippets.conf, just like hidden prefs in geany.conf. This will keep the implementation simple, and ordinary users mostly likely do not need the keybindings. Makes sense if documented :-D Cheers Lex Agree :) ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] snippet keybindings? - Re: [PATCH] Some editor/snippets/keybindings enhancements
On Thu, 9 Sep 2010 11:41:10 +0100% Nick Treleaven nick.trelea...@btinternet.com wrote: On Thu, 9 Sep 2010 11:01:04 +0400 Eugene Arshinov earshi...@gmail.com wrote: OK, I didn't explain before what I had in mind but I think this patch is too complex. What I think we could accept is setting up the snippet keybinding group size and items (like a plugin) when snippets.conf is read, using any defaults found in the file. I don't think we should write to snippets.conf. If the user wants to set the keybinding in snippets.conf, then they must remember that it won't be kept in sync with keybindings.conf. This should make the code simpler. No, I didn't mean to read/save keybindings in snippets.conf. It is very strange that my patch does it, maybe I forgot to remove something from the code :) I'll recheck the patch, probably tomorrow. OK, it does not read keybindings from snippets.conf, only snippet names. Maybe function names are confusing: if you look at load_snippet_keybindings_from_snippets, you may think it really loads keybindings, but it doesn't :) Instead it reads just snippet names and accordingly updates list of snippet keybindings available in Preferences. BTW I replied to your first email before I saw this, sorry. IIUC, I think it would make the code much simpler if the user has to say which snippets they want keybindings for, not offering all snippets for keybindings. Maybe, but what will the interface look like? ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] snippet keybindings? - Re: [PATCH] Some editor/snippets/keybindings enhancements
On Fri, 10 Sep 2010 12:38:57 +0100% Nick Treleaven nick.trelea...@btinternet.com wrote: On Fri, 10 Sep 2010 11:11:02 +0400 Eugene Arshinov earshi...@gmail.com wrote: IIUC, I think it would make the code much simpler if the user has to say which snippets they want keybindings for, not offering all snippets for keybindings. Maybe, but what will the interface look like? I thought it would just list the snippets asked for. Anyway, I may be wrong about simplifying things, as I said, I haven't really studied the patch. Sorry that you've put quite a lot of work into this, but I see snippet keybindings as an extra thing which most people might just type the snippet name, so I think the implementation has to be quite simple to justify maintaining the change. Speaking about maintaining the change, maybe it's worth extracting snippet keybindings to a separate plugin? I think it can be done. In Geany itself I'll need a new signal on loading of snippets.conf, a function to activate a snippet by name, and a new function to set a keygroup with load and save callbacks. The original patch may be simpler, maybe it's best not to have to read snippet keybindings from keybindings.conf... Yes, it's simpler. But, on the opposite side, there a user must edit keybindings manually (probably with Preferences Keybindings opened in order to determine the text representation of the needed keybinding) and she can't get keybinding is already used notifications. Though, most users will rarely (if ever) need snippet keybindings. And, storing snippet keybindings in keybindings.conf, like all other keybindings, seems more natural to me, that saving them to snippets.conf. Though, AFAIK, Gedit Snippets plugin saves keybindings together with snippets. Hard to justify :) Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] snippet keybindings? - Re: [PATCH] Some editor/snippets/keybindings enhancements
On Wed, 18 Aug 2010 09:56:45 +1000%
Lex Trotman ele...@gmail.com wrote:
On 18 August 2010 00:35, Nick Treleaven
nick.trelea...@btinternet.com wrote:
On Tue, 17 Aug 2010 10:08:08 +1000
Lex Trotman ele...@gmail.com wrote:
If we do want snippet keybindings perhaps it would be better to
integrate with the existing keybindings rather than storing them
separately - then users could configure them in the normal way.
It's worth thinking.
This could be a bit of work since the number of snippets is
variable and the keybindings GUI is fixed. I had a quick look a
while ago with the view of allowing the extra build commands to
have keybindings but never came up with a simple way of handling
variable numbers of commands.
If you decide to add a general way of adding variable numbers of
entries in the keybindings GUI it could then be used elsewhere.
Plugins can change the number of keybindings in their plugin's key
group*, so maybe this could be done for other things in the core. It
would probably only take some small changes. 'Format-Send
selection to' keybindings could be variable size too.
*
http://www.geany.org/manual/reference/pluginutils_8h.html#e8eeecc54d81ce05457e04ad98028a68
Looks like a good solution, I never thought of looking in the plugin
interface.
Here is the new patch. It seems to be not so simple and clean as the
previous one, but now keybindings are edited in Preferences dialog as
(I believe) most users prefer.
Unfortunately, keybindings_set_item was not enough for me to implement
this. For example, I had to extend GeanyKeyGroup struct so that I have
a way to tweak loading from / saving to keybindings.conf. Anyway, any
suggestions about how to improve the patch are welcome.
Currently there are two little problems
- All underscores from keybinding names are removed (I wonder why), so
names of some special snippets are displayed incorrectly (**)
- Editing of keybindings in the Preferences dialog isn't caught
completely by Geany. For example, if I remove a keybinding using
click - BackSpace - Enter and press OK, Geany thinks I edited nothing
and does not update keybindings.conf. Though, as expected, the
removed keybinding no longer functions.
** and users are allowed to assign keybindings for special snippets
I finished this patch today, so I hadn't much time for testing.
As for now, everything except the two issues above seems to work fine.
Best regards,
Eugene.
diff --git a/src/editor.c b/src/editor.c
index 052d6c7..cbaf0dd 100644
--- a/src/editor.c
+++ b/src/editor.c
@@ -37,6 +37,7 @@
#include ctype.h
+#include stdlib.h
#include string.h
#include gdk/gdkkeysyms.h
@@ -105,6 +106,17 @@ static enum
static gchar indent[100];
+/* snippet keybindings */
+
+typedef struct
+{
+ gchar *name;
+ guint key;
+ GdkModifierType mods;
+} SnippetKeybinding;
+
+static GeanyKeyGroup *kb_group;
+
static void on_new_line_added(GeanyEditor *editor);
static gboolean handle_xml(GeanyEditor *editor, gint pos, gchar ch);
@@ -120,6 +132,15 @@ static void read_current_word(GeanyEditor *editor, gint pos, gchar *word, size_t
const gchar *wc, gboolean stem);
static gsize count_indent_size(GeanyEditor *editor, const gchar *base_indent);
+/* snippet keybindings */
+static void create_snippet_keybindings_group(guint count);
+static void save_snippet_keybindings(GKeyFile *config, const gchar *section, GeanyKeyGroup *group);
+static void load_snippet_keybindings_from_snippets(void);
+static void load_snippet_keybindings_from_keyfile(GKeyFile *config, const gchar *section,
+ GeanyKeyGroup *group);
+static void merge_snippet_keybindings(SnippetKeybinding *kbs, gsize len, gboolean from_snippets);
+static gboolean activate_snippet(guint key_id);
+
void editor_snippets_free(void)
{
@@ -134,7 +155,6 @@ void editor_snippets_init(void)
gchar *sysconfigfile, *userconfigfile;
gchar **groups_user, **groups_sys;
gchar **keys_user, **keys_sys;
- gchar *value;
GKeyFile *sysconfig = g_key_file_new();
GKeyFile *userconfig = g_key_file_new();
GHashTable *tmp;
@@ -162,15 +182,15 @@ void editor_snippets_init(void)
for (i = 0; i len; i++)
{
keys_sys = g_key_file_get_keys(sysconfig, groups_sys[i], len_keys, NULL);
+
/* create new hash table for the read section (= filetype) */
tmp = g_hash_table_new_full(g_str_hash, g_str_equal, g_free, g_free);
g_hash_table_insert(snippet_hash, g_strdup(groups_sys[i]), tmp);
for (j = 0; j len_keys; j++)
- {
g_hash_table_insert(tmp, g_strdup(keys_sys[j]),
- utils_get_setting_string(sysconfig, groups_sys[i], keys_sys[j], ));
- }
+ g_key_file_get_string(sysconfig, groups_sys[i], keys_sys[j], NULL));
+
g_strfreev(keys_sys);
}
@@ -186,23 +206,16 @@ void editor_snippets_init(void)
tmp = g_hash_table_new_full(g_str_hash, g_str_equal, g_free, g_free);
g_hash_table_insert(snippet_hash, g_strdup(groups_user[i]), tmp);
}
+
for (j = 0; j len_keys;
Re: [Geany-devel] snippet keybindings? - Re: [PATCH] Some editor/snippets/keybindings enhancements
On Sun, 29 Aug 2010 21:35:35 +0400%
Eugene Arshinov earshi...@gmail.com wrote:
On Wed, 18 Aug 2010 09:56:45 +1000%
Lex Trotman ele...@gmail.com wrote:
On 18 August 2010 00:35, Nick Treleaven
nick.trelea...@btinternet.com wrote:
On Tue, 17 Aug 2010 10:08:08 +1000
Lex Trotman ele...@gmail.com wrote:
If we do want snippet keybindings perhaps it would be better
to integrate with the existing keybindings rather than
storing them separately - then users could configure them in
the normal way.
It's worth thinking.
This could be a bit of work since the number of snippets is
variable and the keybindings GUI is fixed. I had a quick look a
while ago with the view of allowing the extra build commands to
have keybindings but never came up with a simple way of handling
variable numbers of commands.
If you decide to add a general way of adding variable numbers of
entries in the keybindings GUI it could then be used elsewhere.
Plugins can change the number of keybindings in their plugin's key
group*, so maybe this could be done for other things in the core.
It would probably only take some small changes. 'Format-Send
selection to' keybindings could be variable size too.
*
http://www.geany.org/manual/reference/pluginutils_8h.html#e8eeecc54d81ce05457e04ad98028a68
Looks like a good solution, I never thought of looking in the plugin
interface.
Here is the new patch. It seems to be not so simple and clean as the
previous one, but now keybindings are edited in Preferences dialog as
(I believe) most users prefer.
Unfortunately, keybindings_set_item was not enough for me to implement
this. For example, I had to extend GeanyKeyGroup struct so that I
have a way to tweak loading from / saving to keybindings.conf.
Anyway, any suggestions about how to improve the patch are welcome.
Currently there are two little problems
- All underscores from keybinding names are removed (I wonder why), so
names of some special snippets are displayed incorrectly (**)
- Editing of keybindings in the Preferences dialog isn't caught
completely by Geany. For example, if I remove a keybinding using
click - BackSpace - Enter and press OK, Geany thinks I edited
nothing and does not update keybindings.conf. Though, as expected,
the removed keybinding no longer functions.
** and users are allowed to assign keybindings for special snippets
I finished this patch today, so I hadn't much time for testing.
As for now, everything except the two issues above seems to work fine.
Best regards,
Eugene.
Sorry, that patch is a little outdated. Here is the last version.
diff --git a/src/editor.c b/src/editor.c
index 052d6c7..98f92f4 100644
--- a/src/editor.c
+++ b/src/editor.c
@@ -37,6 +37,7 @@
#include ctype.h
+#include stdlib.h
#include string.h
#include gdk/gdkkeysyms.h
@@ -105,6 +106,17 @@ static enum
static gchar indent[100];
+/* snippet keybindings */
+
+typedef struct
+{
+ gchar *name;
+ guint key;
+ GdkModifierType mods;
+} SnippetKeybinding;
+
+static GeanyKeyGroup *kb_group;
+
static void on_new_line_added(GeanyEditor *editor);
static gboolean handle_xml(GeanyEditor *editor, gint pos, gchar ch);
@@ -120,6 +132,15 @@ static void read_current_word(GeanyEditor *editor, gint pos, gchar *word, size_t
const gchar *wc, gboolean stem);
static gsize count_indent_size(GeanyEditor *editor, const gchar *base_indent);
+/* snippet keybindings */
+static void create_snippet_keybindings_group(guint count);
+static void save_snippet_keybindings(GKeyFile *config, const gchar *section, GeanyKeyGroup *group);
+static void load_snippet_keybindings_from_snippets(void);
+static void load_snippet_keybindings_from_keyfile(GKeyFile *config, const gchar *section,
+ GeanyKeyGroup *group);
+static void merge_snippet_keybindings(SnippetKeybinding *kbs, gsize len, gboolean from_snippets);
+static gboolean activate_snippet(guint key_id);
+
void editor_snippets_free(void)
{
@@ -134,7 +155,6 @@ void editor_snippets_init(void)
gchar *sysconfigfile, *userconfigfile;
gchar **groups_user, **groups_sys;
gchar **keys_user, **keys_sys;
- gchar *value;
GKeyFile *sysconfig = g_key_file_new();
GKeyFile *userconfig = g_key_file_new();
GHashTable *tmp;
@@ -162,15 +182,15 @@ void editor_snippets_init(void)
for (i = 0; i len; i++)
{
keys_sys = g_key_file_get_keys(sysconfig, groups_sys[i], len_keys, NULL);
+
/* create new hash table for the read section (= filetype) */
tmp = g_hash_table_new_full(g_str_hash, g_str_equal, g_free, g_free);
g_hash_table_insert(snippet_hash, g_strdup(groups_sys[i]), tmp);
for (j = 0; j len_keys; j++)
- {
g_hash_table_insert(tmp, g_strdup(keys_sys[j]),
- utils_get_setting_string(sysconfig, groups_sys[i], keys_sys[j], ));
- }
+ g_key_file_get_string(sysconfig, groups_sys[i], keys_sys[j], NULL));
+
g_strfreev(keys_sys);
}
@@ -186,23 +206,16
Re: [Geany-devel] snippet keybindings? - Re: [PATCH] Some editor/snippets/keybindings enhancements
Hi Nick On Mon, 16 Aug 2010 13:41:00 +0100% Nick Treleaven nick.trelea...@btinternet.com wrote: On Sat, 10 Jul 2010 21:48:35 +0400 Eugene Arshinov earshi...@gmail.com wrote: I attach three patches: Thanks; as we're preparing a bugfix release I haven't looked at them, but anyway: No problem, it can wait. 2. Snippet keybindings support Not sure about this - shouldn't the keybinding be typing the snippet name and pressing tab ;-) I use short names to minimise typing - b for a brace pair, c for a multiline comment. I tried, but even btab seems too long for me to type in order to get a brace pair. I must note, an easier and quicker way of inserting a brace pair is the main reason of why I wrote this patch, and I agree that there may be not so many uses of snippet keybindings. If we do want snippet keybindings perhaps it would be better to integrate with the existing keybindings rather than storing them separately - then users could configure them in the normal way. It's worth thinking. Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Building Geany from SVN
On Fri, 30 Jul 2010 15:47:52 +0100% Nick Treleaven nick.trelea...@btinternet.com wrote: On Sat, 24 Jul 2010 12:02:19 +0400 Eugene Arshinov earshi...@gmail.com wrote: I want to build Geany from the sources in SVN. Since the configure script is not included in the repository I had to use automake to generate it. I tried the following: ./aclocal ./automake --add-missing Unfortunately this failed with: configure.ac:9: required file `config.h.in' not found configure.ac:32: required file `./ltmain.sh' not found Am I missing something? Hi. Try ./autogen.sh. Strange that it's not mentioned at http://www.geany.org/manual/index.html#installation. Well, the manual is really for normal users, not necessarily people building from SVN. We mention ./autogen.sh here: http://www.geany.org/Download/SVN Ah, okay. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Building Geany from SVN
On Sat, 24 Jul 2010 09:53:09 +0200% Krasimir Angelov kr.ange...@gmail.com wrote: Hello all, I want to build Geany from the sources in SVN. Since the configure script is not included in the repository I had to use automake to generate it. I tried the following: ./aclocal ./automake --add-missing Unfortunately this failed with: configure.ac:9: required file `config.h.in' not found configure.ac:32: required file `./ltmain.sh' not found Am I missing something? Hi. Try ./autogen.sh. Strange that it's not mentioned at http://www.geany.org/manual/index.html#installation. Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Per document tab width
On Tue, 20 Jul 2010 22:20:52 +0200% Jiří Techet tec...@gmail.com wrote: Hi, I have one more feature idea and would like to ask if it is something that others would like to see too before I start implementing it. I'm working on a project where everyone expresses his personality by using different tab width for indenting - I have already seen sources with tab size of 2, 3, 4, 5, 6 and 8 (it's just a matter of time until I see a source with tab width 7). Of course, these people (or people who were editing the same source afterwards) also use spaces so sometimes it happens that I have e.g. tab size set to 4 but the other file I edit has tab size 2 and it uses spaces too, so what I see is that the lines using tab get indented less than the lines using spaces. I usually ignore it, but sometimes the code is so unreadable that I have to change the tab size. And this is the problem - with geany you have to do it either per project or globally, it's not possible for a single file. So I have to switch it in the project settings, look at the file, and switch it back again because I return back to a file with different indent size. I would propose to have one more entry in the Document menu called e.g. Tab size and placed under Indent type with a submenu containing numbers from 2 to 8 (I hope there is nobody so crazy that he would use tab for a single char indent or go over 8 characters) with a radio button selecting the active selection. The user could change the default tab size of the active document to anything he wishes. I think it may be useful, though I've never really needed it. This settings could also be saved into the project/session file so the files get reloaded with the same tab size settings. What do you think about this feature? For me, a better way would be to support Emacs/Vi mode lines. I know Gedit has a plugin for that, maybe this functionality can be borrowed from there. Mode lines will be also useful for specifying document encoding so that user don't have to choose it manually each time it opens the file (I sometimes have to work with files in cp1251, traditional codepage for Russian Windows…). Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] [PATCH] Some editor/snippets/keybindings enhancements
Hi all.
I attach three patches:
1. Keybindings to insert new line after/before current
2. Snippet keybindings support
3. Automatically insert additional indentation in XML/HTML files if
previous line ends with an opening tag
They must be unrelated and can be applied independently of each other.
Some of the patches have drawbacks. Before polishing them, I want to
know whether they are useful and may go to trunk.
The drawback of the first patch is that I doubt it's so useful. I know
Vi[m] provides shortcuts for these actions ('o' and 'O' in normal
mode), but their necessity is questionable for me. I implemented this
to ease XML editing with tag autocompletion turned on. Suppose you
need to write to consequent li's. Without this patch you need to
press End+Enter after writing the first li to place the cursor where
you need to start the second. With my patch, you only need to press
one shortcut you can assign in Preferences Keybindings :)
The drawback of the third patch is that it's not completed. If user
likes to leave HTML tags like br unclosed, she would be disturbed by
automatic indentation caused by my patch, so a check box in Preferences
is desirable. I'll code it as soon as we decide this patch can go to
trunk.
Speaking about the second patch, here is an example of assigning a
keybinding (I currently use it in my user snippets.conf):
# special group to define keybindings
# keybindings' format resembles the one used in Preferences
# Keybindings tab
[Keybindings]
block_cursor=Altbracketleft
Keybindings may be assigned either in user or global snippets.conf (I'm
not sure if the latter is useful). Another decision I made is to allow
keybindings for snippets in [Special] section (like block_cursor used
above). While block_cursor snippet is not very useful when you have
to type its name, it is useful when you just have to press a shortcut.
And, as usual for me, all of these patches lack user documentation…
Best regards,
Eugene.
diff --git a/src/editor.c b/src/editor.c
index 052d6c7..74129c7 100644
--- a/src/editor.c
+++ b/src/editor.c
@@ -3912,7 +3912,7 @@ void editor_select_paragraph(GeanyEditor *editor)
/* simple indentation to indent the current line with the same indent as the previous one */
-static void smart_line_indentation(GeanyEditor *editor, gint first_line, gint last_line)
+void editor_smart_indentation_for_lines(GeanyEditor *editor, gint first_line, gint last_line)
{
gint i, sel_start = 0, sel_end = 0;
@@ -3964,12 +3964,12 @@ void editor_smart_line_indentation(GeanyEditor *editor, gint pos)
sci_start_undo_action(sci);
- smart_line_indentation(editor, first_line, last_line);
+ editor_smart_indentation_for_lines(editor, first_line, last_line);
/* set cursor position if there was no selection */
if (first_sel_start == first_sel_end)
{
- gint indent_pos = SSM(sci, SCI_GETLINEINDENTPOSITION, first_line, 0);
+ gint indent_pos = sci_get_indent_position(sci, first_line);
/* use indent position as user may wish to change indentation afterwards */
sci_set_current_position(sci, indent_pos, FALSE);
@@ -4008,7 +4008,7 @@ void editor_indentation_by_one_space(GeanyEditor *editor, gint pos, gboolean dec
for (i = first_line; i = last_line; i++)
{
- indentation_end = SSM(editor-sci, SCI_GETLINEINDENTPOSITION, i, 0);
+ indentation_end = sci_get_indent_position(editor-sci, i);
if (decrease)
{
line_start = SSM(editor-sci, SCI_POSITIONFROMLINE, i, 0);
diff --git a/src/editor.h b/src/editor.h
index 70b3c0e..871b12e 100644
--- a/src/editor.h
+++ b/src/editor.h
@@ -212,6 +212,8 @@ void editor_insert_alternative_whitespace(GeanyEditor *editor);
void editor_indent(GeanyEditor *editor, gboolean increase);
+void editor_smart_indentation_for_lines(GeanyEditor *editor, gint first_line, gint last_line);
+
void editor_smart_line_indentation(GeanyEditor *editor, gint pos);
void editor_indentation_by_one_space(GeanyEditor *editor, gint pos, gboolean decrease);
diff --git a/src/keybindings.c b/src/keybindings.c
index 4e68723..4c487cd 100644
--- a/src/keybindings.c
+++ b/src/keybindings.c
@@ -371,6 +371,10 @@ static void init_default_kb(void)
keybindings_set_item(group, GEANY_KEYS_FORMAT_REFLOWPARAGRAPH, NULL,
GDK_j, GDK_CONTROL_MASK, format_reflowparagraph, _(_Reflow Lines/Block),
LW(reflow_lines_block1));
+ keybindings_set_item(group, GEANY_KEYS_FORMAT_INSERTLINE_AFTER, NULL,
+ 0, 0, format_insertline_after, _(Insert new line after current), NULL);
+ keybindings_set_item(group, GEANY_KEYS_FORMAT_INSERTLINE_BEFORE, NULL,
+ 0, 0, format_insertline_before, _(Insert new line before current), NULL);
group = ADD_KB_GROUP(INSERT, _(Insert), cb_func_insert_action);
@@ -2402,6 +2406,56 @@ static void reflow_paragraph(GeanyEditor *editor)
}
+static void insert_line_after(GeanyEditor *editor)
+{
+ ScintillaObject *sci = editor-sci;
+
+ gchar *eol;
+ gint line = sci_get_current_line(sci);
+
+ switch (sci_get_eol_mode(sci))
+ {
Re: [Geany-devel] altername session management implementation
On Sun, 4 Jul 2010 14:07:27 +0300% Dimitar Zhekov dimitar.zhe...@gmail.com wrote: On Fri, 2 Jul 2010 13:20:09 +0400 Eugene Arshinov earshi...@gmail.com wrote: 1. On my system your version do not automatically remove temporary SM-related session files. Is it supposed to do so? I saw that you specified DiscardCommand. I checked that relative paths do not work, even if SmCurrentDirectory is properly set. Ordinary users rarely run programs using relative paths, but still. With xfce, and SmCurrentDirectory specified, they are OK. As of GNOME... *sigh* I don't like to be harsh, but it has the worst XSM support [...] So if you feel like writing support for it... I do not. No, I don't like it, but there are some GNOME users out there :) Well, I guess we can somehow check if Geany is running under GNOME, and if so, delete the SM-file on normal (non-session) Geany quit. We can always delete the file ourselves. Seems that it won't be harmful for compliant session managers. And place a note in the documentation: under GNOME, specific versions of Geany should be run with absolute path if you want them restored on the next restart. I think it's better to have 5 or so additional lines of code than to leave this problem for end users. Since you are running GNOME, can you look at the environment variables for something specific? Just looked at the output of `set' command. Can see nothing GNOME-specific there. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] altername session management implementation
On Sun, 4 Jul 2010 15:00:00 +0300% Dimitar Zhekov dimitar.zhe...@gmail.com wrote: On Sun, 4 Jul 2010 15:20:12 +0400 Eugene Arshinov earshi...@gmail.com wrote: On Sun, 4 Jul 2010 14:07:27 +0300% Dimitar Zhekov dimitar.zhe...@gmail.com wrote: On Fri, 2 Jul 2010 13:20:09 +0400 Eugene Arshinov earshi...@gmail.com wrote: 1. On my system your version do not automatically remove temporary SM-related session files. Is it supposed to do so? I saw that you specified DiscardCommand. I checked that relative paths do not work, even if SmCurrentDirectory is properly set. Ordinary users rarely run programs using relative paths, but still. With xfce, and SmCurrentDirectory specified, they are OK. As of GNOME... *sigh* I don't like to be harsh, but it has the worst XSM support [...] So if you feel like writing support for it... I do not. No, I don't like it, but there are some GNOME users out there :) Well, I guess we can somehow check if Geany is running under GNOME, and if so, delete the SM-file on normal (non-session) Geany quit. We can always delete the file ourselves. Seems that it won't be harmful for compliant session managers. The XSMP does not specify when the SmDiscardCommand will/should be executed. For example, what if the user logs out, and only then unchecks Save this session for future use or something? Geany will be terminated without any notice, and the discarding remains to the SM. So we'd better do both. Yes, sorry for being not clear. I meant both specifying SmDiscardCommand and deleting file manually when user closes Geany. And place a note in the documentation: under GNOME, specific versions of Geany should be run with absolute path if you want them restored on the next restart. I think it's better to have 5 or so additional lines of code than to leave this problem for end users. This is a rare situation, and the executable name can't be determined 100% reliably without using /proc or something (there is no such UNIX API). You can try a few programs from the GNOME Official applications list, and if they simply store argv[0], I think it'll be too much for Geany to do more than that. No, we need to look for absolute path if and only if Geany is run using relative path. When Geany is run either using absolute path or without any path at all, we can leave the path as is. GNOME's session manager does not work only with relative paths. Getting absolute path from relative to current directory is ~5 lines without any hacks. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] altername session management implementation
On Thu, 1 Jul 2010 19:48:18 +0300% Dimitar Zhekov dimitar.zhe...@gmail.com wrote: On Thu, 1 Jul 2010 11:51:18 +0400 Eugene Arshinov earshi...@gmail.com wrote: On Wed, 30 Jun 2010 21:48:15 +0300% Dimitar Zhekov dimitar.zhe...@gmail.com wrote: 1. On my system your version do not automatically remove temporary SM-related session files. Is it supposed to do so? I saw that you specified DiscardCommand. They are removed when a program ceases to be part of the session (i.e. when you close an instance), not on session restart or something. But even if I open Geany and immediately close it, its temporary file is still there. I just checked out that the file still exists even after I logout and login again (i.e., after GNOME session manager is restarted). Well, under xfce-sm they are deleted as soon as the geany instance is closed (xfce has some other bugs though). With GNOME, a lot of the session management is implemented in it's session client library. The best and most compliant XSM is that of KDE4. And easier way to test than installing KDE is to temporarily disable the GNOME SM and use xsm(1). It's not suitable for practical work, but should be enough to try the creation/deletion of the .conf files. Thanks, I'll try that. (On that note, I don't think it's necessary for you to try guessing the absolute name of args[0], every program I've seen just stores argv[0] directly.) I checked that relative paths do not work, even if SmCurrentDirectory is properly set. Ordinary users rarely run programs using relative paths, but still. With xfce, and SmCurrentDirectory specified, they are OK. As of GNOME... *sigh* I don't like to be harsh, but it has the worst XSM support, especially for non-gnome programs, and always had. Instead of fixing it, they finally replaced XSMP with a D-Bus based protocol at the end of 2008. Yes, I heard about it. So if you feel like writing support for it... I do not. No, I don't like it, but there are some GNOME users out there :) There are some other fixes, I can send a patch against 5064 if you want. Yes, that would be good. I have an idea of combining your SM implementation with my sm branch (you know the branch now contains plenty of things apart of SM, e.g. changes in command-line handling, Geany session management, [...] If I finally do it, I'll send here resulting patch(es). Attached. To prevent an unlikely race condition, the Build - Set build commands settings should be saved on OK response, instead of when exiting Geany, but I believe your sm branch includes that. Okay, thanks. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] altername session management implementation
On Wed, 30 Jun 2010 21:48:15 +0300% Dimitar Zhekov dimitar.zhe...@gmail.com wrote: On Wed, 30 Jun 2010 12:09:43 +0400 Eugene Arshinov earshi...@gmail.com wrote: On Wed, 19 May 2010 14:17:52 +0300% Dimitar Zhekov hams...@mbox.contact.bg wrote: The patch applies against the latest svn-4933. Of course, it should not be included in 0.19, I only finished it today. Some parts of Eugene's SM were reverted, since they were not required. Hi. Several questions and suggestions here :) 1. On my system your version do not automatically remove temporary SM-related session files. Is it supposed to do so? I saw that you specified DiscardCommand. They are removed when a program ceases to be part of the session (i.e. when you close an instance), not on session restart or something. But even if I open Geany and immediately close it, its temporary file is still there. I just checked out that the file still exists even after I logout and login again (i.e., after GNOME session manager is restarted). 2. Is tm_get_real_path() really necessary in utils_option_entry_reverse_parse() for command-line options of G_OPTION_ARG_FILENAME type? I saw tm_get_real_path() is called from some other places in code, but have no idea why it's needed. That was not only unneeded, but buggy - the config directory and the socket file arguments could be non-existent. I removed it 10 days ago. 3. When specifying SmProgram value, you should properly handle the case when argv[0] does not contain path (i.e., when Geany is resolved using PATH). If argv[0] does not contain path, tm_get_real_path() returns NULL for it on my system, causing a segfault. That was also fixed, and the description of tm_get_real_path() has been changed - it said that a reasonable guess is returned even if the file does not exist. :-) Okay. (On that note, I don't think it's necessary for you to try guessing the absolute name of args[0], every program I've seen just stores argv[0] directly.) I checked that relative paths do not work, even if SmCurrentDirectory is properly set. Ordinary users rarely run programs using relative paths, but still. There are some other fixes, I can send a patch against 5064 if you want. Yes, that would be good. I have an idea of combining your SM implementation with my sm branch (you know the branch now contains plenty of things apart of SM, e.g. changes in command-line handling, Geany session management, recent settings-saving patches, my proof of concept method of merging recent lists etc.). That would require some work, but I think it's worth it. If I finally do it, I'll send here resulting patch(es). Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] configurable status line?
On Sat, 26 Jun 2010 20:31:12 +0200% Jiří Techet tec...@gmail.com wrote: On Sat, Jun 26, 2010 at 18:27, Nick Treleaven nick.trelea...@btinternet.com wrote: On Wed, 23 Jun 2010 17:58:11 +0100 Nick Treleaven nick.trelea...@btinternet.com wrote: On Wed, 23 Jun 2010 19:31:03 +0300 Dimitar Zhekov dimitar.zhe...@gmail.com wrote: Hi, everyone, The status line is pretty crowded, as you know, so how about making it configurable? Something like: line: %l / %n\t col: %c\t sel: %s ... I can write it, if you think that's a good idea. I don't think it's worth it. OK, having thought more about it I think it could be configurable as a hidden pref. That way we can hide any less generally useful things like line count by default. Personally I find the total number of lines quite useful - it tells you quickly how big the file is. Also the space wasted by its presence is relatively small because it shares the caption with the current line number. For me the least useful information is the INS/OVR indication because this is already indicated by the cursor. But in general I find the current state of the status bar OK. Jiri I second that. From my opinion: - number of lines indication may be useful; - INS/OVR indication is probably excessive; - current state is ok, it's not so overcrowded. Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] [PATCH] New instance indication
On Thu, 17 Jun 2010 13:36:18 +0100% Nick Treleaven nick.trelea...@btinternet.com wrote: On Thu, 17 Jun 2010 09:06:45 +0400 Eugene Arshinov earshi...@gmail.com wrote: Here are two trivial patches to add indication to status bar or title. I think indication is needed as sometimes it's still important for user to distinguish main and secondary instances. Personally I vote for indication in title (I changed my mind after I realized that status bar is too small for it). AFAIK Lex thinks the same. Cool, thanks. Unfortunately, we can't use the patch now as we are in string freeze for the upcoming 0.19 release. But I'd like to commit the patch afterwards. Hi Enrico. I'd like to remind you about the patch :) Applied the title patch, thanks ;-) Not at all, thanks for committing :) Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] SM r4968 bug - and more
On Wed, 16 Jun 2010 18:56:36 +0300% Dimitar Zhekov dimitar.zhe...@gmail.com wrote: On Wed, 16 Jun 2010 11:43:51 +0400 Eugene Arshinov earshi...@gmail.com wrote: On Tue, 15 Jun 2010 21:53:22 +0300% Dimitar Zhekov dimitar.zhe...@gmail.com wrote: It's sm_cmd_props(), in particular when run with --config. You should preserve alternate_configdir, like in my sm. Well, actually I preserve it (see the code of sm_cmd_props() and optentries_aux array in main.c). I wanted to say that you should not let main.c free it. The alternate sm I sent on may-19 does that (main.c @@ -707,7 +746,10 @@), but the app-configdir = g_strdup(alternate_config) you suggest is better. The bug may be in main.c:parse_command_line_options() where we simply assign app-configdir = alternate_config. And after that, in several places, we use setptr() and g_free() on app-configdir Exactly (except it's not a bug in sm-less Geany). I tested with g_strdup(), just to be sure - works. Great, committed now to SM (together with similar fixes for other string command-line options). Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] SM r5044 filename saving
On Thu, 17 Jun 2010 21:03:18 +0300% Dimitar Zhekov dimitar.zhe...@gmail.com wrote: Hi, Eugene, I see your sm now always saves the open files in the restart/clone command line, so their per-file settings are lost. Why not at least append :line:column to the file names? Better than nothing... Hi Thanks for suggestion, committed. Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] [PATCH] New instance indication
On Thu, 3 Jun 2010 13:30:53 +0200% Enrico Tröger enrico.troe...@uvena.de wrote: On Mon, 31 May 2010 11:08:57 +0400, Eugene wrote: Hi. Here are two trivial patches to add indication to status bar or title. I think indication is needed as sometimes it's still important for user to distinguish main and secondary instances. Personally I vote for indication in title (I changed my mind after I realized that status bar is too small for it). AFAIK Lex thinks the same. Cool, thanks. Unfortunately, we can't use the patch now as we are in string freeze for the upcoming 0.19 release. But I'd like to commit the patch afterwards. Hi Enrico. I'd like to remind you about the patch :) Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Git switch
On Sun, 13 Jun 2010 14:11:05 +0200% Frank Lanitz fr...@frank.uvena.de wrote: On Sun, 13 Jun 2010 14:01:02 +0200 Daniel Marjamäki daniel.marjam...@gmail.com wrote: I have a few years of daily experience both with SVN and GIT. We use SVN at work and I use GIT for all my personal projects. I like GIT better than SVN. In my humble opinion you shouldn't switch unless you are unhappy with sourceforge / svn. I agree. For our current development process I don't see any big need to change away from SVN. It will cost a lot of effort with no extra profit adding. I'd like to second that. And, while I use local Git repository for Geany, I'm completely happy with git-svn (and my separate SVN branch, of course :). Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] more project settings [multiple instance behaviour]
On Fri, 4 Jun 2010 12:13:39 +0400% Eugene Arshinov earshi...@gmail.com wrote: On Fri, 4 Jun 2010 12:17:38 +1000% Lex Trotman ele...@gmail.com wrote: On 4 June 2010 03:11, Dimitar Zhekov dimitar.zhe...@gmail.com wrote: Hi. Taking point from the proposition to merge the recent files, what do you think about considering the recent files a logical part of the file list, and load/save the open/recent file lists together? This way, we will have better/more recent files (one set for each project) without the need to override geany.conf on each file open/close. N.B. Since the list will be handled together, Project based session files will affect the recent file list too. Would suit me, depends on what other people think. This is a good alternative to global recent files list approach I described. I forgot a side note: this won't do for recent *projects* list. I think recent projects should be global. Though it won't prevent using the described approach for recent *files*. Per-project interface settings (mostly the interface layout) seems reasonable too IMHO. I have several programming projects, and the message window/side bar are very convinient for them. But for my other projects, one with XSMP documentation/snippets and another with BDF files, the message window/side bar are practically useless. Ditto. Not currently needed by me, but I'm sure it would be useful. As a side effect, if per-project recent files and interface settings are implemented, Eugene's sm will be able to restore the Geany-s state better. Isn't it time to make the two sm-s functionally more similar, so we could choose one based on the implementation only? Agree, that is part of what the list in the other thread was intended to do and why I was trying to define it in terms of user visible behaviour, so I'm all for this. The more similar the two versions are, the better. And, I agree, that would make it simpler to see their differences. Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] [PATCH] Doclist dirnames collapsing
On Fri, 4 Jun 2010 10:43:02 +0400% Eugene Arshinov earshi...@gmail.com wrote: Hi. This patch seems to fix collapsing dirnames in doclist to current project's base path if the latter contains trailing directory separator. Best regards, Eugene. To clarify why this patch is needed: current implementation behaves incorrectly if project path contains trailing directory separator and the path, with which project path is matched, is equal to project path, but does not contain trailing separator. Illustration: Project: home Project path: /home/eugene/ Path in doclist: /home/eugene Result with current implementation: /home/eugene Should be: home Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] [PATCH] Doclist dirnames collapsing
Hi.
This patch seems to fix collapsing dirnames in doclist to current
project's base path if the latter contains trailing directory
separator.
Best regards,
Eugene. diff --git a/src/sidebar.c b/src/sidebar.c
index 447d4d5..d88b2cd 100644
--- a/src/sidebar.c
+++ b/src/sidebar.c
@@ -359,20 +359,15 @@ static GtkTreeIter *get_doc_parent(GeanyDocument *doc)
gsize len = strlen(project_base_path);
const gchar *rest;
+ if (project_base_path[len-1] == G_DIR_SEPARATOR)
+ project_base_path[len-1] = '\0';
+
/* check whether the dir name matches or uses the project base path */
- if (!utils_str_equal(project_base_path, tmp_dirname))
- {
- const gchar *sep =
-(project_base_path[len-1] == G_DIR_SEPARATOR) ? NULL : G_DIR_SEPARATOR_S;
- setptr(project_base_path, g_strconcat(project_base_path, sep, NULL));
- }
if (g_str_has_prefix(tmp_dirname, project_base_path))
{
rest = tmp_dirname + len;
- dirname = g_strdup_printf(%s%s%s,
-app-project-name,
-(*rest != G_DIR_SEPARATOR *rest != '\0') ? G_DIR_SEPARATOR_S : ,
-rest);
+ if (*rest == G_DIR_SEPARATOR || *rest == '\0')
+dirname = g_strdup_printf(%s%s, app-project-name, rest);
}
g_free(project_base_path);
}
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Multiple instances of Geany issues
On Wed, 2 Jun 2010 21:55:04 +0300% Dimitar Zhekov dimitar.zhe...@gmail.com wrote: Most of the above are already available as patches. What remains: - Warnings (questions?) on Edit - Preferences, Project - Properties and Build - Set build commands. - Limit Project - Properties to saving the preferences only, and limit project_close() to saving the file list only. I can write the latter, if we agree on the above behaviour. I appreciate. I was going to implement it myself, but, if you suggest first… :) Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] SM r4968 bug - and more
On Thu, 3 Jun 2010 19:14:39 +0300% Dimitar Zhekov dimitar.zhe...@gmail.com wrote: On Wed, 2 Jun 2010 22:17:02 +0400 Eugene Arshinov earshi...@gmail.com wrote: On Wed, 2 Jun 2010 20:33:37 +0300% Dimitar Zhekov dimitar.zhe...@gmail.com wrote: The startup time between which two events? The SM does not know when a program is started, and does not care when/if it's first window will be displayed. You can even write a console program with SM support. :) Between, for example, establishing the connection and the time when we can handle the first message from session manager (i.e., the time message loop starts working). Again, it's just a wild guess. I read the above and was enlightened. The first message a SM sends to a newly registered application, when adding it to a session, is a SaveYourself(SaveLocal). With the sm_set_runtime_props() call in sm_save_yourself_callback() commented out, 4968 does not kill the session on startup. Interesting. It's worth debugging sm_set_runtime_props() with gdb step-by-step and see when session is killed. While reading sm.c, however, I noticed what looks like two more bugs. if (cl_options.load_session) /* Files will be restored by Geany session management facilities. */ store_project = store_files = FALSE; If I'm not mistaken, this code leaves the file/project list save/restore to Geany, for a main instance only. But what if you have 2+ main instances? They will all try to save their file list or active project in geany.conf; even with race .lock protection, only one will succeed; and on session restore, there will be 2+ identical instances. The fix is pretty easy, just remove the above check. Any per-file settings for project-less instances will be lost, but they are lost for the secondary project-less instances anyway... Well, in addition to removing the check I will have to forbid reading file list from config when an instance is started by session manager. Not too hard, though. To speak truth, when I wrote this code I didn't think about several main instances. I still does not understand why they are needed. Lex explained me why opening one project in several instances can be useful, but opening several main instances seems to be even more crazy stuff :) if (project_prefs.project_session) /* Files will be restored when the project is reopened. */ store_files = FALSE; This assumes that the value of project_prefs.project_session is identical at the time when Geany is stopped and then restarted. But with your sm, on restart, all geany-s read their options from the single geany.conf. What if I have 3 instances running, choose Edit - Preferences in one of them, and (un)check Project based session files? The other 2 instances will not be aware of the change when being stopped, and will get the new value when restarted. Good catch. Seems that always storing files in command-line and not loading them from project file on restore would fix this boundary case. Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] more project settings [multiple instance behaviour]
On Fri, 4 Jun 2010 12:17:38 +1000% Lex Trotman ele...@gmail.com wrote: On 4 June 2010 03:11, Dimitar Zhekov dimitar.zhe...@gmail.com wrote: Hi. Taking point from the proposition to merge the recent files, what do you think about considering the recent files a logical part of the file list, and load/save the open/recent file lists together? This way, we will have better/more recent files (one set for each project) without the need to override geany.conf on each file open/close. N.B. Since the list will be handled together, Project based session files will affect the recent file list too. Would suit me, depends on what other people think. This is a good alternative to global recent files list approach I described. Per-project interface settings (mostly the interface layout) seems reasonable too IMHO. I have several programming projects, and the message window/side bar are very convinient for them. But for my other projects, one with XSMP documentation/snippets and another with BDF files, the message window/side bar are practically useless. Ditto. Not currently needed by me, but I'm sure it would be useful. As a side effect, if per-project recent files and interface settings are implemented, Eugene's sm will be able to restore the Geany-s state better. Isn't it time to make the two sm-s functionally more similar, so we could choose one based on the implementation only? Agree, that is part of what the list in the other thread was intended to do and why I was trying to define it in terms of user visible behaviour, so I'm all for this. The more similar the two versions are, the better. And, I agree, that would make it simpler to see their differences. Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] SM r4968 bug - and more
On Fri, 4 Jun 2010 19:58:15 +0300% Dimitar Zhekov dimitar.zhe...@gmail.com wrote: On Fri, 4 Jun 2010 11:48:22 +0400 Eugene Arshinov earshi...@gmail.com wrote: On Thu, 3 Jun 2010 19:14:39 +0300% Dimitar Zhekov dimitar.zhe...@gmail.com wrote: With the sm_set_runtime_props() call in sm_save_yourself_callback() commented out, 4968 does not kill the session on startup. Interesting. It's worth debugging sm_set_runtime_props() with gdb step-by-step and see when session is killed. That didn't work, the session was killed asynchronously. But while trying to trace geany with nemiver, the session remained stable - only geany-4968 was closed, and a new geany was started, as if the SM tried to clone or restart it (hint restart now?), using the program name from the legacy SM protocol. Anyway, commenting out SmcSetProperties() for _both_ the restart and clone commands resulted in a stable running Geany. So there's probably something wrong with their prop values. I'll look at them. Well, in addition to removing the check I will have to forbid reading file list from config when an instance is started by session manager. Not too hard, though. Yes, a --no-session will do. You should mark it as non-persistent anyway, otherwise a geany once started with --no-session will come empty (no files open) each time the session is restored. Hm, I don't understand the last point. Why will no-session'ed instances come empty if their files are passed via command-line? My original thought was not using --no-session, but simply don't load files from config if --libsm-client-id is passed. To speak truth, when I wrote this code I didn't think about several main instances. I still does not understand why they are needed. Lex explained me why opening one project in several instances can be useful, but opening several main instances seems to be even more crazy stuff :) I have two main instances running (with sm) since may-19: one on desktop 1 with BDF/FNA files, and another on desktop 2 with geany source files. My file manager is set to open bdf/fna with geany socket file desktop1, and [ch] files with desktop2. But it'll be better to write a short script that runs geany with socket desktopcurrent. That's how nedit worked, very convinient. Yes, this is indeed useful. Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Multiple instances of Geany issues
Sorry, forgot to answer this in the afternoon. On Thu, 3 Jun 2010 16:11:03 +1000% Lex Trotman ele...@gmail.com wrote: On 3 June 2010 01:08, Eugene Arshinov earshi...@gmail.com wrote: On Wed, 2 Jun 2010 18:10:26 +1000% Lex Trotman ele...@gmail.com wrote: On 2 June 2010 17:19, Eugene Arshinov earshi...@gmail.com wrote: The second half of 6 (last main instance opening project wins) seems somewhat strange to me: * Shouldn't it also hold for secondary instances? I think we shouldn't differentiate the behaviour of main and secondary instances in respect to handling of project files. * I'd prefer last closing wins, not last opening wins (the way we usually implement things, isn't it?). Sorry if I wasn't clear enough, I was talking about Geany saving the current file list in the *config* file when a project is opened, not about the project file, when another instance closes its project, it restores the file list saved in the config by the instance that last *opened* a project. Thanks, now it's more clear, but I'm still confused. Could you further explain the last phrase when another instance closes its project, it restores the file list saved in the config by the instance that last *opened* a project? Why do we need such complexity (we must know whether the instance which was the last to write the file list to the config opened the project before or after us…)? Why can't we let the last instance overwrite the file list completely? This isn't added complexity, its just how it works now, if sm changes that then I didn't notice, sorry. Let me give example sequences: How it works with a single instance: open Geany, open several files, open project, Geany saves the list of several files in Geany.conf and opens the project file list, close project (which can be after several opens and closes of Geany) saves list of open files in project file and close them and then open the files listed in Geany.conf Perfect!! How it works with several instances (numbered): open Geany1, open several files1, open project1 Geany1 saves list of files1 in Geany.conf and opens the project1 file list, open --new-instance Geany2, open some files2, open project2, Geany2 saves the file list2 in Geany.conf overwriting file list1, close project1, Geany 1 saves project1 file list and opens file list2!!! it reads from Geany.conf, confused grumpy user :( Thanks for explanation. or if --new-instance versions are not allowed to save file list, how do they restore the open files when the project is closed? By limiting save it to the main instances I was hoping to reduce the surprise somewhat, but a better answer would be welcome. Well, in SM the file list and the recent project in the config are indeed saved only by main instances. Secondary instances are not allowed to touch them (being more concrete, in SM --new-instance implies --no-session). Which raises the second problem noted above. I don't claim to have a good solution for this one, I just want to get the solution with most user utility and least user surprise. We may store files that were opened before the project internally and properly restore them after the project is closed. It's a simple idea, but it may be difficult to implement because practically we'll have to maintain internally two projects: default project and opened real project (if any). Also, this will introduce a new challenge for Geany's session management and SM: whether we need to save also default project if real project was opened when Geany exited? Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Multiple instances of Geany issues
On Wed, 2 Jun 2010 12:14:48 +1000% Lex Trotman ele...@gmail.com wrote: snip Should they be combined? We never discussed such thing for 2+ instances, not even for 2+ main instances. Merging recent makes sense, indeed, but adding files to be open on the next run of Geany, or the next time a project is open?.. Just for clarity, in the question I meant several instances where the same project is opened. So in case we decide to merge recent, the resulting files should go to the project and nowhere else. Speaking about merging recent, I think it isn't worth implementing (too much efforts for a not so significant outcome). Maybe simply letting the instances race for the project file (with locking, of course) is the best choice… Hi all, Having gotten confused where each of the implementations is up to I want to summarise the overall operation. The same problem applies to three types of files, the config file (geany.conf), the project file and (possibly several) filetype files. BTW changing filetype files is not that rare, every time you add an option to your compile command you change one. Me, I add/remove -g quite often :) Actions performed by the user are fine because they serialise them, ie users can only do one thing at a time, problems only occur on multi instance session close and restart. I can summarise what is for me, the only correct answer (after a LOT of discussion, thanks for the patience Ditmar Eugene): 1. save the config/project/filetype file settings when changed, in any instance but with warning in non-main instances, no race because user serialises, last changed wins (see !! below), add reload menu item(s) to allow user to sync instances if desired 2. When closed by sm, save the file list in a per instance session file not the config/project file, then when the session is restarted each instance loads its session file list not the config/project file list and doesn't store in project or config file, no race 3. when closed by user, save the file list in the config/project file as normal, no race because user serialises closing, last wins (easily understandable) 4. when SIGHUPed, ie non-session multiple shutdown, save nothing (current behaviour) 5. when project loaded in non-main instance do not store current file list in config file, no race, and won't overwrite main instance list with an empty one 6. when project loaded in main instance (by user not by sm) store the current file list in config file, last main instance opening project wins, no race because user serialises (!!) Note item 1. currently all preferences are saved, lots more work but better, would be to only save those items changed so a sort of merge would happen instead of total overwrite, maybe this could be a later version. I think that covers it. No races, maximum flexibility with warnings for non-main instance changes and good restoration of the current session on restart. Great summary. Now what we need is a comparison table with four columns for trunk, trunk with your and Dimitar's patches, my SM and Dimitar's SM. At first glance, seems that my SM implements 1 (but without warnings and possibility of reload), 3, 4, 5, and the first half of 6. It does not implement 2, and I do not consider it a severe issue. I believe a normal user rarely opens one project in two instances or runs several main instances using --socket command line options. If he doesn't, there won't be any race. Even with my SM implementation :) The second half of 6 (last main instance opening project wins) seems somewhat strange to me: * Shouldn't it also hold for secondary instances? I think we shouldn't differentiate the behaviour of main and secondary instances in respect to handling of project files. * I'd prefer last closing wins, not last opening wins (the way we usually implement things, isn't it?). I admit I don't use recent file list much so my choice is for the easiest :). So I agree, I wouldn't bother merging recent list. Since its in the same file(s) as the file list just let it work as the file list does in 1-6. If enough users of the feature want it to merge, make it append to whats in the config/project file every time a file is opened/closed by user (ie act like a preference in 1. above). I'd prefer to not have this much traffic on the config/project file though, so by preference only. Just for clarity, this is how recent lists are now handled in SM, except that the preference is not provided. Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Multiple instances of Geany issues
On Wed, 2 Jun 2010 18:10:26 +1000% Lex Trotman ele...@gmail.com wrote: On 2 June 2010 17:19, Eugene Arshinov earshi...@gmail.com wrote: On Wed, 2 Jun 2010 12:14:48 +1000% Lex Trotman ele...@gmail.com wrote: snip Should they be combined? We never discussed such thing for 2+ instances, not even for 2+ main instances. Merging recent makes sense, indeed, but adding files to be open on the next run of Geany, or the next time a project is open?.. Just for clarity, in the question I meant several instances where the same project is opened. So in case we decide to merge recent, the resulting files should go to the project and nowhere else. Speaking about merging recent, I think it isn't worth implementing (too much efforts for a not so significant outcome). Maybe simply letting the instances race for the project file (with locking, of course) is the best choice… Hi all, Having gotten confused where each of the implementations is up to I want to summarise the overall operation. The same problem applies to three types of files, the config file (geany.conf), the project file and (possibly several) filetype files. BTW changing filetype files is not that rare, every time you add an option to your compile command you change one. Me, I add/remove -g quite often :) Actions performed by the user are fine because they serialise them, ie users can only do one thing at a time, problems only occur on multi instance session close and restart. I can summarise what is for me, the only correct answer (after a LOT of discussion, thanks for the patience Ditmar Eugene): 1. save the config/project/filetype file settings when changed, in any instance but with warning in non-main instances, no race because user serialises, last changed wins (see !! below), add reload menu item(s) to allow user to sync instances if desired 2. When closed by sm, save the file list in a per instance session file not the config/project file, then when the session is restarted each instance loads its session file list not the config/project file list and doesn't store in project or config file, no race 3. when closed by user, save the file list in the config/project file as normal, no race because user serialises closing, last wins (easily understandable) 4. when SIGHUPed, ie non-session multiple shutdown, save nothing (current behaviour) 5. when project loaded in non-main instance do not store current file list in config file, no race, and won't overwrite main instance list with an empty one 6. when project loaded in main instance (by user not by sm) store the current file list in config file, last main instance opening project wins, no race because user serialises (!!) Note item 1. currently all preferences are saved, lots more work but better, would be to only save those items changed so a sort of merge would happen instead of total overwrite, maybe this could be a later version. I think that covers it. No races, maximum flexibility with warnings for non-main instance changes and good restoration of the current session on restart. Great summary. Now what we need is a comparison table with four columns for trunk, trunk with your and Dimitar's patches, my SM and Dimitar's SM. Good idea, if Ditmar can say how his works against the points, I'll fill in trunk versions properly tomorrow, but quick look says: trunk: not 1, 2 is irrelevant (no sm), 3, 4, not 5 and can corrupt but took opening multiple instances in a script for it to happen, not 6 (stores on all project opens) patches, I think do: 1 without warning or reload, 2 still irrelevant, 3, 4, 5 I'm not sure, 6 without preference, I need to check where we ended up re main vs new-instance and what they saved. At first glance, seems that my SM implements 1 (but without warnings and possibility of reload), 3, 4, 5, and the first half of 6. It does not implement 2, and I do not consider it a severe issue. I believe a normal user rarely opens one project in two instances or runs several main instances using --socket command line options. If he doesn't, there won't be any race. Even with my SM implementation :) I'm confused, how does the session restore if you don't save each instance file list, current project etc.? My SM works by specifying restart command, where I can specify any command-line arguments. Opened project, files, and some settings (--new-instance, --no-session etc.) are passed this way. And as multi screen workstations are more common among developers, running multiple instances is the only way to get Geany on both screens, and they are likely to want the same project, thats what the user is working on after all. I agree less likely to be two main instances, but main and --new-instance is very likely, I'm planning to use it a lot to look at C++ .hpp and .cpp files at the same
Re: [Geany-devel] SM r4968 bug (was: Multiple instances of Geany issues)
On Wed, 2 Jun 2010 20:33:37 +0300% Dimitar Zhekov dimitar.zhe...@gmail.com wrote: On Wed, 2 Jun 2010 09:39:44 +0400 Eugene Arshinov earshi...@gmail.com wrote: On Tue, 1 Jun 2010 21:22:06 +0300% Dimitar Zhekov dimitar.zhe...@gmail.com wrote: 67 works, 68 fails. Stable. Thanks much for investigating this. Seems that it will be hard to fix. I've looked through the changes made by merge to files I usually touch in SM, but did not find anything that could cause such a failure. And core SM code in sm.c during the merge, of course, remained the same. It's somehow sm-related. If I comment out smc_conn = sm_connect(...), 4968 works. Nice, our estimates are now confirmed. BTW, you should pass the new client id to gdk_set_sm_client_id(), not the old/NULL one, but that's not the cause of the error. I don't know how to properly express it in English, but I sometimes think that making stupid little mistakes like this is my second nature. Or maybe the first? :) It's strange that even old client-id seemed to improve the behaviour of Geany on my system… Anyway, I'll fix this error soon, thanks for notice. In all cases I've googled it's only the program that crashes, not the entire session… Also, errno=32 (EPIPE) indicates something weird is going on. Maybe (blind guess), if startup time is nevertheless the issue, XFCE session manager terminates the connection on timeout… The startup time between which two events? The SM does not know when a program is started, and does not care when/if it's first window will be displayed. You can even write a console program with SM support. :) Between, for example, establishing the connection and the time when we can handle the first message from session manager (i.e., the time message loop starts working). Again, it's just a wild guess. Maybe you can track down the bug further by merging trunk to 4967 «step by step» and checking whether the bug is present after each step. When using binary search, those 500 trunk commits will require 10 steps to check. AFAIU, I had no large conflicts while merging. So, if you suddenly have free time for this method, please give it a try. That'll be a bit more complex. The commits are related, so I can't just arbitarily turn on/off half or quarter of them. But you can merge 1/2 to r67. If the bug appears, go back to r67 and merge 1/4. If the bug doesn't appear, merge 1/8 more. Such a method should work. And if the crash is caused by 2+ related changes, well... At least we will find the last of those changes, right? :) Anyway, I'll run some tests in the weekend. Thanks you very much in advance. Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Multiple instances of Geany issues
On Tue, 1 Jun 2010 19:55:27 +0300% Dimitar Zhekov dimitar.zhe...@gmail.com wrote: On Mon, 31 May 2010 13:35:26 +0400 Eugene Arshinov earshi...@gmail.com wrote: Just to mention, I ported to my SM branch the patches posted earlier in this thread. Also, I've changed the code to write changed recent files and projects lists to geany.conf as soon as possible instead of writing them on exit. [...] I wanted to test that, but the sm-4977 works quite amazing on my system: running geany closes the entire session, without as much as a xfce sm signal to the applications. The only error message I was able to record is ICE default IO error handler doing an exit(), pid = 8983, errno = 32. The pid is Geany's. It is terrible… I'm not experiencing this here in GNOME. Could you check previous revisions to determine when the bug appeared? After this one problem remains: handling of a project opened in several instances. It could be easy to apply immediate save technique for them too if we hadn't to maintain list of project's files. Currently, both the project settings and files are saved on any of Project - Preferences, Project - Close / New / Open and File - Quit. Following the logic of the other patches, IMHO Project - Preferences should save the settings only, and the other functions should save the file list only. Yes, precisely. As of a project open 2+ times, I expect the file list to be almost identical. It's not like running a -i instance, which starts with an empty file list. How should lists of files from several instances be combined? Should they be combined? We never discussed such thing for 2+ instances, not even for 2+ main instances. Merging recent makes sense, indeed, but adding files to be open on the next run of Geany, or the next time a project is open?.. Just for clarity, in the question I meant several instances where the same project is opened. So in case we decide to merge recent, the resulting files should go to the project and nowhere else. Speaking about merging recent, I think it isn't worth implementing (too much efforts for a not so significant outcome). Maybe simply letting the instances race for the project file (with locking, of course) is the best choice… Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] [PATCH] New instance indication
Hi.
Here are two trivial patches to add indication to status bar or
title. I think indication is needed as sometimes it's still important
for user to distinguish main and secondary instances. Personally I
vote for indication in title (I changed my mind after I realized
that status bar is too small for it). AFAIK Lex thinks the same.
Best regards,
Eugene.diff --git a/src/ui_utils.c b/src/ui_utils.c
index 304afb7..a7d532a 100644
--- a/src/ui_utils.c
+++ b/src/ui_utils.c
@@ -51,6 +51,7 @@
#include symbols.h
#include toolbar.h
#include geanymenubuttonaction.h
+#include main.h
GeanyInterfacePrefs interface_prefs;
@@ -243,12 +244,19 @@ void ui_update_statusbar(GeanyDocument *doc, gint pos)
g_string_append_printf(stats_str, style: %d, sci_get_style_at(doc-editor-sci, pos));
#endif
+ if (cl_options.new_instance)
+ {
+ g_string_append(stats_str, sp);
+ g_string_append(stats_str, NI);
+ }
+
/* can be overridden by status messages */
set_statusbar(stats_str-str, TRUE);
}
else /* no documents */
{
- set_statusbar(, TRUE); /* can be overridden by status messages */
+ gchar * message = cl_options.new_instance ? NI : ;
+ set_statusbar(message, TRUE); /* can be overridden by status messages */
}
}
@@ -2291,4 +2299,3 @@ void ui_editable_insert_text_callback(GtkEditable *editable, gchar *new_text,
if (stop_signal)
g_signal_stop_emission_by_name(editable, insert-text);
}
-
diff --git a/src/ui_utils.c b/src/ui_utils.c
index 304afb7..eb58cf4 100644
--- a/src/ui_utils.c
+++ b/src/ui_utils.c
@@ -51,6 +51,7 @@
#include symbols.h
#include toolbar.h
#include geanymenubuttonaction.h
+#include main.h
GeanyInterfacePrefs interface_prefs;
@@ -290,6 +291,10 @@ void ui_set_window_title(GeanyDocument *doc)
g_string_append(str, ] - );
}
g_string_append(str, Geany);
+ if (cl_options.new_instance)
+ {
+ g_string_append(str, _( (new instance)));
+ }
gtk_window_set_title(GTK_WINDOW(main_widgets.window), str-str);
g_string_free(str, TRUE);
}
@@ -2291,4 +2296,3 @@ void ui_editable_insert_text_callback(GtkEditable *editable, gchar *new_text,
if (stop_signal)
g_signal_stop_emission_by_name(editable, insert-text);
}
-
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] multiple instance save-settings - Re: Race condition when saving geany.conf
On Sun, 30 May 2010 19:36:14 +0200% Enrico Tröger enrico.troe...@uvena.de wrote: On Thu, 20 May 2010 22:52:49 +0400, Eugene wrote: Hey, sorry for the delay, I just don't manage to keep up with this stuff :(. No problem. Or, as another option, we can remove automatic saving of preferences when closing. As preferences are saved immediately after Preferences dialog is closed, this option wouldn't do any harm. Or would it? The historical reason for save on exit was to store window size and position and maybe other things (scribble content, maybe more). So, we still need to save on exit but maybe we can lower the amount of settings we want to save on exit, only those which are really necessary. (this is also a reply to Dimitar) Well, then it's not a big deal to only save_dialog_prefs() after the Preferences dialog is closed and save everything but dialog prefs (UI prefs, session etc.) on exit. That is logical and will solve the problem. Sounds ok to me. But I didn't have a look at the code to find maybe some potential problems with such a change. Okay. Just for clarity, the discussion about this topic has moved to a new thread http://lists.uvena.de/geany-devel/2010-May/002358.html. Dimitar and Lex have already posted there some patches. I've included those patches into my local SM repository. After I finish implementing the same behaviour for recent files and projects I'll commit everything to my SVN branch. Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] multiple instance save-settings - Re: Race condition when saving geany.conf
On Wed, 19 May 2010 23:05:26 +0200% Enrico Tröger enrico.troe...@uvena.de wrote: On Wed, 19 May 2010 22:13:40 +0400, Eugene wrote: On Wed, 19 May 2010 14:09:57 +0300% Dimitar Zhekov hams...@mbox.contact.bg wrote: On Wed, 19 May 2010 11:07:09 +0400 Eugene Arshinov earshi...@gmail.com wrote: Now committed, together with Tools Save configuration menu item. I hope Save configuration works for all instances, and not for the main instance only, as someone suggested. With main, the options can be saved by Edit - Preferences - OK anyway, and I would like to be able to save them from a secondary instance, and run a new Geany with them. Preference - OK is a good point… I did not know it saves configuration file immediately (yeah, again). Seems that it makes Save configuration unnecessary (at least, for main instance). I am against enabling Save configuration for secondary instances because (in case of current behaviour when the main instance saves configuration automatically on exit) it may confuse users. Suppose you have main instance and secondary instance running. You change preferences in the secondary instance and use Save configuration, then restart the main instance in order to make it apply new settings… and when the main instance is closing it silently overwrites them. So I thinks it's reasonable to force users to change their preferences in main instance only. Or, as another option, we can remove automatic saving of preferences when closing. As preferences are saved immediately after Preferences dialog is closed, this option wouldn't do any harm. Or would it? The historical reason for save on exit was to store window size and position and maybe other things (scribble content, maybe more). So, we still need to save on exit but maybe we can lower the amount of settings we want to save on exit, only those which are really necessary. (this is also a reply to Dimitar) Well, then it's not a big deal to only save_dialog_prefs() after the Preferences dialog is closed and save everything but dialog prefs (UI prefs, session etc.) on exit. That is logical and will solve the problem. Also, it is safe and reasonable to save preferences (and only them) after the dialog is closed even in secondary instances. Then Save Configuration won't be needed, unless someone expects this menu item to also save UI prefs, opened files and other things (which is a bad idea). Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Multiple instances of Geany issues
On Fri, 21 May 2010 14:34:36 +1000% Lex Trotman ele...@gmail.com wrote: Hi All, I've created this thread separate from Eugene's and Ditmar's session management threads because my concern is mostly about other parts of Geany and I don't want to be seen as criticising either of them as it was their input that started me thinking. New thread is a good idea. I am tired of looking up for recent messages in that large Race condition thread I created :-) Having multiple Geany instances is a great capability, * I can have two (or more) projects open to share code or to interrupt work on one to do something an another, * I can have Geany on *both* of my screens so I can see different parts of what I'm working on * I can set up my filemanager to open different instances so opening random files won't affect the work I'm doing My concern is that we should make sure that the way Geany works is safe and preferably causes no surprises when multiple instances are sharing files. There are three types of files that Geany instances could share and I think they should be handled differently: * Files being edited (the second of my use cases above). I don't think it is up to Geany to handle users editing the same file in multiple instances, its up to the user to sort it out when time comes to save. A user can always set readonly to protect against themselves. Making --readonly a command line option would be a good addition. * Project files (same project in two instances), since the user doesn't explicitly control the project file I think Geany is going to have to become involved in this case. The only options that I can see in this case are: ** when a project file has changed on disk (by date/time), for Geany to ask if it should save or save as or throw away any changes to project from this instance. This way an instance won't silently overwrite changes made by another instance, and with save as I can procrastinate by saving this instances changes elsewhere until I can decide which I want. ** only the Geany not started with --new-instance can save the project file The second option seems strange to me. Practically, it will forbid opening two projects simultaneously so that they are both saved. Or do I miss something? Also, I can't see the point in opening one project in two instances… So, as to me, it isn't worth writing any code to handle that. * Geany.conf (shared by any two or more instances), this is a real potential problem if multiple instances try to save the same file. Discussions in another thread seemed to come to the conclusion that only the Geany that was started without --new-instance should save it preventing races when several instances are closed at once. BUT this is not implemented in the SVN that is about to become 0.19 and in my test a new instance overwrote the main Geany.conf losing session, recent files etc!!! I think that preventing --new-instance from saving project and preference files should be implemented before 0.19 is released otherwise failing to close instances in the right order or missing an instance when logging out will overwrite the preferences. And configuring a filemanager to use --new-instance will overwrite when closed even if no other Geany is running. Well, actually there is a very simple solution -- just check if we are run with --new-instance in `configuration_save' and forbid saving anything in this case. This is what I committed to SM. But now there is a suggestion from Dimitar to also support changing preferences in secondary instances. The last solution I wrote in the large thread is to change automatic saving when closing. It should save only things that are not related to Preferences dialog (window position, opened files if needed etc.), and only in the main instance, of course. Changed preferences are saved immediately after applying changes user made in the Preferences dialog, either in a main instance or a secondary instance. As to me, I don't need to be able to change prefs in secondary instances as I always have main instance running. But this feature might be useful to other Geany users… Later on we can look at the other options and also look at indicating to the user which Geany instances can save, maybe by something after the Geany in the title bar? As to me, the title is already overcrowded (for example, just now I have notes.html - /home/eugene - [home] - Geany). Instead, I would like to see this indication in the status bar. Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] multiple instance save-settings - Re: Race condition when saving geany.conf
On Tue, 2 Mar 2010 15:23:31 +0300% Eugene Arshinov earshi...@gmail.com wrote: On Mon, 1 Mar 2010 16:08:18 +% Nick Treleaven nick.trelea...@btinternet.com wrote: On Sat, 27 Feb 2010 09:05:12 +1100 Lex Trotman ele...@gmail.com wrote: To be easy to implement, perhaps maybe only the first/main instance should save settings. We could have a Tools-Save Config menu item enabled for the first instance to allow the user to restart other instances with the new settings. I havn't looked in detail at what the -i option does but I assume it doesn't use or accept socket connections. Yes. The socket code only works for the 'main' instance. If so then I assume all Geany commands without the -i will be the same instance, and this is the one that should be able to save. (If a second instance of geany is run without passing filenames to the first, -i is implied). I really like this idea. It is simple to understand, rather convenient and uniform with the behaviour of new-instances, i.e., those instances should not touch any global data, either the default session or the settings. Now committed, together with Tools Save configuration menu item. Though, I think we should think of a better name for it as currently Save configuration and Reload configuration mean different things by configuration, which will probably confuse users. There needs to be a visual distinction of instances that can can't save. I agree, otherwise the user might think there was a bug saving settings. Any proposal for this visual distinction? Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] [PATCH] Fix frames' padding in the prefs dialog
On Thu, 11 Mar 2010 20:32:46 +0100% Enrico Tröger enrico.troe...@uvena.de wrote: On Wed, 10 Mar 2010 22:11:43 +0300, Eugene wrote: Hi. Disposition and padding of frames within the Preferences dialog is now inconsistent. This patch fixes it (in my opinion). Somebody, please review and commit/ignore it. Could you go a bit into details? The patch is a bit hard to read (which is by no means your fault, it's just that very big UI XML). I want to apply it but before I'd like to know which frames are inconsitent (I don't doubt there are inconsistencies, just too lazy too search :D). Thanks. No need to read the patch manually. You can apply the patch and open the modified geany.glade in Glade. There open the prefs dialog template and switch through all tabs. If you open prefs dialog from trunk next to it, you'll see the difference. An alternative way is to apply the patch and recompile Geany without installing. Then run the installed version (with the current version of the dialog), and the new executable (with the new dialog). Place the two dialogs next to each other and switch through tabs. When I said the frames being inconsistent, I meant that * some frames have zero border width while most of them have border width set to 5; * sometimes this border width is applied to each frame contained within a page, while usually the border width is assigned to the GtkVbox containing the frames; * sometimes the bottom frame on a page is expanded to consume the free vertical space available on that page (so the lower border of the frame is pushed to the bottom of the page), while usually the bottom frame is not expanded. These explanations (especially the last one) may be unclear, but you'll really see the difference if you compare the two version of the prefs dialog next to each other. Sorry that I didn't describe all this stuff in the previous mail. Was tired yesterday a bit. Best regards, Eugene. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
