Hi,
I've done some hacking on splitwindow.c and eliminated some bugs and added some features. I checked the geany/geany-plugins feature/bug trackers and I'll list which of the items I think can be closed.
The patches:
#0001 Enable code folding on the split window. Closes bug #3097780[1]
#0002 Enable Scintilla's default popup editor menu on the split window editor so that there's a way to copy/paste/undo/redo/etc. Closes bug #2983145[2] although the keybindings and main menu items still don't work in the split window.
#0003 Remove the widget reparenting in an attempt to make the plugin work on Windows again. Although I can't test on Windows, I think there's a good chance this will fix the issues and it seems to work fine on Linux as well. I base this on an old GTK+ FAQ entry[3]. If someone can confirm, it will close bug #2725342[4] and the plugin can be re-enabled on the Windows build.
#0004 Fix confusing terminology in Split View menu, which has annoyed me for some time. Closes bug #3203384[5] and feature request #2796316[6]
#0005 Stop unsplitting on document close unless there are no documents left open. This patch just uses the first available document in the documents array instead of unsplitting when the document in the split window is closed. I left a TODO comment in there, I'll fix it later unless someone else has the time.
While checking the bug/feature trackers, I noticed a few other items that can probably be closed.
Feature request #1530436[7]
Feature request #2969886[8] - based on the comments
Bug #2983106[9] - it's not impossible, Ctrl+Scroll works, just no keybindings and such.
Bug #2984797[10] - this one has bit me numerous times. I honestly don't know if I fixed with my patches or if someone else fixed it in a recent revision, but it seem to no longer be reproducible for me.
[1] https://sourceforge.net/tracker/index.php?func=detail&aid=3097780&gr... [2] https://sourceforge.net/tracker/index.php?func=detail&aid=2983145&gr... [3] http://www.fifi.org/doc/libgtk1.2-doc/faq-html/gtkfaq-5.html#ss5.17 [4] https://sourceforge.net/tracker/index.php?func=detail&aid=2725342&gr... [5] https://sourceforge.net/tracker/?func=detail&aid=3203384&group_id=22... [6] https://sourceforge.net/tracker/index.php?func=detail&aid=2796316&gr... [7] https://sourceforge.net/tracker/index.php?func=detail&aid=1530436&gr... [8] https://sourceforge.net/tracker/index.php?func=detail&aid=2969886&gr... [9] https://sourceforge.net/tracker/index.php?func=detail&aid=2983106&gr... [10] https://sourceforge.net/tracker/index.php?func=detail&aid=2984797&gr...
Happy Coding, Matthew Brush (codebrainz)
Hi Matthew,
Wow you've been busy, well done. Seems to work for me.
#0002 Enable Scintilla's default popup editor menu on the split window editor so that there's a way to copy/paste/undo/redo/etc.
Does this mean that editing now fully works between the two split windows?
Closes bug #2983145[2] although the keybindings and main menu items still don't work in the split window.
Except for these of course.
#0003 Remove the widget reparenting in an attempt to make the plugin work on Windows again. Although I can't test on Windows, I think there's a good chance this will fix the issues and it seems to work fine on Linux as well. I base this on an old GTK+ FAQ entry[3]. If someone can confirm, it will close bug #2725342[4] and the plugin can be re-enabled on the Windows build.
#0004 Fix confusing terminology in Split View menu, which has annoyed me for some time. Closes bug #3203384[5] and feature request #2796316[6]
Agree, originally the menu matched the underlying GPane but GPane describes the *children* being *arranged* horizontal or vertical, whereas the menu was describing the *parent* window being *split* horizontally or vertically, the opposite thing.
#0005 Stop unsplitting on document close unless there are no documents left open. This patch just uses the first available document in the documents array instead of unsplitting when the document in the split window is closed. I left a TODO comment in there, I'll fix it later unless someone else has the time.
[..]
Bug #2984797[10] - this one has bit me numerous times. I honestly don't know if I fixed with my patches or if someone else fixed it in a recent revision, but it seem to no longer be reproducible for me.
Can't reproduce on 0.20 Release version either.
Cheers Lex
Hi Matthew!
Le 17/03/2011 00:49, Matthew Brush a écrit :
#0001 Enable code folding on the split window. Closes bug #3097780[1]
Applied a slightly modified version to SVN, thanks! :)
#0002 Enable Scintilla's default popup editor menu on the split window editor so that there's a way to copy/paste/undo/redo/etc. Closes bug #2983145[2] although the keybindings and main menu items still don't work in the split window.
Not sure about this one since the menu is neither translatable nor look like other Geany's menus. Maybe manually implementing a basic menu would be better?
#0003 Remove the widget reparenting in an attempt to make the plugin work on Windows again. Although I can't test on Windows, I think there's a good chance this will fix the issues and it seems to work fine on Linux as well. I base this on an old GTK+ FAQ entry[3]. If someone can confirm, it will close bug #2725342[4] and the plugin can be re-enabled on the Windows build.
Not sure about this, what was the issues before (the one the code talked about)? I'd prefer one of the original authors to review this one if possible... Nick (or Enrico, seems you also worked on this), could you check this/tell what was exactly the issue?
#0004 Fix confusing terminology in Split View menu, which has annoyed me for some time. Closes bug #3203384[5] and feature request #2796316[6]
Applied in SVN, thanks (again).
#0005 Stop unsplitting on document close unless there are no documents left open. This patch just uses the first available document in the documents array instead of unsplitting when the document in the split window is closed. I left a TODO comment in there, I'll fix it later unless someone else has the time.
I committed a modified patch that should fix the issue you had (the TODO) and implement the behavior of your patch.
Regards, Colomban
On 03/26/11 17:31, Colomban Wendling wrote:
#0002 Enable Scintilla's default popup editor menu on the split window editor so that there's a way to copy/paste/undo/redo/etc. Closes bug #2983145[2] although the keybindings and main menu items still don't work in the split window.
Not sure about this one since the menu is neither translatable nor look like other Geany's menus. Maybe manually implementing a basic menu would be better?
Should a bug/feature request also be reported to Scintilla?
#0003 Remove the widget reparenting in an attempt to make the plugin work on Windows again. Although I can't test on Windows, I think there's a good chance this will fix the issues and it seems to work fine on Linux as well. I base this on an old GTK+ FAQ entry[3]. If someone can confirm, it will close bug #2725342[4] and the plugin can be re-enabled on the Windows build.
Not sure about this, what was the issues before (the one the code talked about)? I'd prefer one of the original authors to review this one if possible... Nick (or Enrico, seems you also worked on this), could you check this/tell what was exactly the issue?
See r3161 and r3163. also the bug report for this and FAQ entry linked from original message. I think it's best to have original authors (especially someone who is able to build on windows) to check this also.
Cheers, Matthew Brush
Not sure about this one since the menu is neither translatable nor look like other Geany's menus. Maybe manually implementing a basic menu would be better?
Should a bug/feature request also be reported to Scintilla?
Its not really Scintilla's problem that Geany menus look different :-)
And Scintilla/Scite has its own translation system which we havn't integrated, see http://code.google.com/p/scite-files/wiki/Translations
Cheers Lex
On 03/26/11 22:44, Lex Trotman wrote:
Not sure about this one since the menu is neither translatable nor look like other Geany's menus. Maybe manually implementing a basic menu
would
be better?
Should a bug/feature request also be reported to Scintilla?
Its not really Scintilla's problem that Geany menus look different :-)
Well, I didn't mean because the appearance :)
And Scintilla/Scite has its own translation system which we havn't integrated, see http://code.google.com/p/scite-files/wiki/Translations
Ah ok. I'm not very knowledgeable about translation stuff.
Cheers, Matthew Brush
On Sat, 26 Mar 2011 22:26:42 -0700, Matthew wrote:
On 03/26/11 17:31, Colomban Wendling wrote:
#0002 Enable Scintilla's default popup editor menu on the split window editor so that there's a way to copy/paste/undo/redo/etc. Closes bug #2983145[2] although the keybindings and main menu items still don't work in the split window.
Not sure about this one since the menu is neither translatable nor look like other Geany's menus. Maybe manually implementing a basic menu would be better?
Should a bug/feature request also be reported to Scintilla?
#0003 Remove the widget reparenting in an attempt to make the plugin work on Windows again. Although I can't test on Windows, I think there's a good chance this will fix the issues and it seems to work fine on Linux as well. I base this on an old GTK+ FAQ entry[3]. If someone can confirm, it will close bug #2725342[4] and the plugin can be re-enabled on the Windows build.
Not sure about this, what was the issues before (the one the code talked about)? I'd prefer one of the original authors to review this one if possible... Nick (or Enrico, seems you also worked on this), could you check this/tell what was exactly the issue?
See r3161 and r3163. also the bug report for this and FAQ entry linked from original message. I think it's best to have original authors (especially someone who is able to build on windows) to check this also.
I guess that means me :).
I tested the patch (#0003) on Windows and it works fine, at least I couldn't find any wrong behaviour.
The problems referenced in the code were about broken scrollbars, I don't remember exactly whether in the normal editor widget or in the splitted. And there were issues with the PRIMARY selection which behaved wrong. None of these I could reproduce with the patch #0003, neither on Windows nor Linux. Before the patch, on Windows the splitted window wasn't reparented probably and so was moved in the upper left corner of the Geany root window, this is also fixed with the patch.
I think we should commit it and see how it works for other people.
Regards, Enrico
On Sun, 27 Mar 2011 16:41:40 +0200, Enrico wrote:
On Sat, 26 Mar 2011 22:26:42 -0700, Matthew wrote:
On 03/26/11 17:31, Colomban Wendling wrote:
#0002 Enable Scintilla's default popup editor menu on the split window editor so that there's a way to copy/paste/undo/redo/etc. Closes bug #2983145[2] although the keybindings and main menu items still don't work in the split window.
Not sure about this one since the menu is neither translatable nor look like other Geany's menus. Maybe manually implementing a basic menu would be better?
Should a bug/feature request also be reported to Scintilla?
#0003 Remove the widget reparenting in an attempt to make the plugin work on Windows again. Although I can't test on Windows, I think there's a good chance this will fix the issues and it seems to work fine on Linux as well. I base this on an old GTK+ FAQ entry[3]. If someone can confirm, it will close bug #2725342[4] and the plugin can be re-enabled on the Windows build.
Not sure about this, what was the issues before (the one the code talked about)? I'd prefer one of the original authors to review this one if possible... Nick (or Enrico, seems you also worked on this), could you check this/tell what was exactly the issue?
See r3161 and r3163. also the bug report for this and FAQ entry linked from original message. I think it's best to have original authors (especially someone who is able to build on windows) to check this also.
I guess that means me :).
I tested the patch (#0003) on Windows and it works fine, at least I couldn't find any wrong behaviour.
The problems referenced in the code were about broken scrollbars, I don't remember exactly whether in the normal editor widget or in the splitted. And there were issues with the PRIMARY selection which behaved wrong. None of these I could reproduce with the patch #0003, neither on Windows nor Linux.
They still exist, at least the broken PRIMARY selection problem. It's easy to reproduce: select some text in the normal editor widget after you splitted it. You cannot paste the selected anymore by a middle click.
Colomban already reverted the two related commits. Thanks.
I think we should commit it and see how it works for other people.
Er, let's say I changed my mind...:D.
Regards, Enrico
Le 27/03/2011 16:41, Enrico Tröger a écrit :
On Sat, 26 Mar 2011 22:26:42 -0700, Matthew wrote:
#0003 Remove the widget reparenting in an attempt to make the plugin work on Windows again. Although I can't test on Windows, I think there's a good chance this will fix the issues and it seems to work fine on Linux as well. I base this on an old GTK+ FAQ entry[3]. If someone can confirm, it will close bug #2725342[4] and the plugin can be re-enabled on the Windows build.
Not sure about this, what was the issues before (the one the code talked about)? I'd prefer one of the original authors to review this one if possible... Nick (or Enrico, seems you also worked on this), could you check this/tell what was exactly the issue?
See r3161 and r3163. also the bug report for this and FAQ entry linked from original message. I think it's best to have original authors (especially someone who is able to build on windows) to check this also.
I guess that means me :).
I tested the patch (#0003) on Windows and it works fine, at least I couldn't find any wrong behaviour.
The problems referenced in the code were about broken scrollbars, I don't remember exactly whether in the normal editor widget or in the splitted. And there were issues with the PRIMARY selection which behaved wrong. None of these I could reproduce with the patch #0003, neither on Windows nor Linux. Before the patch, on Windows the splitted window wasn't reparented probably and so was moved in the upper left corner of the Geany root window, this is also fixed with the patch.
I think we should commit it and see how it works for other people.
Well, I committed it (r5636) but... reverted it as r5640. It initially look good, but breaks the X PRIMARY clipboard (aka the mouse one) in the normal Geany editor (even after unsplitting), so it's not acceptable.
We need a better fix then. Maybe you can try to find out why the X clipboard get broken on Scintilla (and fix it :D). If it get fixed, we will probably can re-apply the patch.
Regards, Colomban
On 03/27/11 09:11, Colomban Wendling wrote:
We need a better fix then. Maybe you can try to find out why the X clipboard get broken on Scintilla (and fix it :D). If it get fixed, we will probably can re-apply the patch.
I spent a lot of time studying the Scintilla source and trying various things there and in splitwindow.c. I don't see anywhere that Scintilla is breaking the PRIMARY selection. It seems to become the owner of the PRIMARY selection in ScintillaGTK::ClaimSelection() whenever text is selected, but I can't figure for life of me why it it's not working. It seems like it should own the PRIMARY selection in each widget where you're selecting text. Even setting the owner of the primary selection manually to the "original" scintilla, it still locks into the "split" scintilla.
So after spending way too much time on this, and getting nowhere, I give up. I'm attaching a patch that no dev is going to like because it behaves differently on Windows than it does on non-Windows to work around a know issue in GTK+ that is not documented to affect Windows differently than X windows. Either someone else needs to find the root of the problem deep inside GTK+ (ie. why it reparenting only breaks on Windows), we figure out what's happening in Scintilla, we use the slightly hacky approach of behaving differently on Windows, or we just leave the whole plugin stay disable and let the Windows users not have it, even though we *can* make it working. Since it's just a plugin, completely separate from the core code, which is already kinda hacky with what it's doing, my opinion is just to use the patch.
It's not my call, but the patch is here if you want it.
Cheers, Matthew Brush
On 28 March 2011 11:31, Matthew Brush mbrush@codebrainz.ca wrote:
On 03/27/11 09:11, Colomban Wendling wrote:
We need a better fix then. Maybe you can try to find out why the X clipboard get broken on Scintilla (and fix it :D). If it get fixed, we will probably can re-apply the patch.
I spent a lot of time studying the Scintilla source and trying various things there and in splitwindow.c. I don't see anywhere that Scintilla is breaking the PRIMARY selection. It seems to become the owner of the PRIMARY selection in ScintillaGTK::ClaimSelection() whenever text is selected, but I can't figure for life of me why it it's not working. It seems like it should own the PRIMARY selection in each widget where you're selecting text. Even setting the owner of the primary selection manually to the "original" scintilla, it still locks into the "split" scintilla.
So after spending way too much time on this, and getting nowhere, I give up. I'm attaching a patch that no dev is going to like because it behaves differently on Windows than it does on non-Windows to work around a know issue in GTK+ that is not documented to affect Windows differently than X windows. Either someone else needs to find the root of the problem deep inside GTK+ (ie. why it reparenting only breaks on Windows), we figure out what's happening in Scintilla, we use the slightly hacky approach of behaving differently on Windows, or we just leave the whole plugin stay disable and let the Windows users not have it, even though we *can* make it working. Since it's just a plugin, completely separate from the core code, which is already kinda hacky with what it's doing, my opinion is just to use the patch.
It's not my call, but the patch is here if you want it.
I only had a short time at lunch to look, but I noticed that Scintilla GTK selection code depends on USE_GTK_CLIPBOARD defined or not. I can't find where its defined so I presume its not. Maybe try with it defined?
Cheers Lex
Cheers, Matthew Brush
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 03/27/11 18:19, Lex Trotman wrote:
I only had a short time at lunch to look, but I noticed that Scintilla GTK selection code depends on USE_GTK_CLIPBOARD defined or not. I can't find where its defined so I presume its not. Maybe try with it defined?
https://github.com/codebrainz/geany/blob/master/scintilla/gtk/ScintillaGTK.c...
Seems to be defined for GTK+ >= 2.6.
Cheers, Matthew Brush
On 28 March 2011 13:35, Matthew Brush mbrush@codebrainz.ca wrote:
On 03/27/11 18:19, Lex Trotman wrote:
I only had a short time at lunch to look, but I noticed that Scintilla GTK selection code depends on USE_GTK_CLIPBOARD defined or not. I can't find where its defined so I presume its not. Maybe try with it defined?
https://github.com/codebrainz/geany/blob/master/scintilla/gtk/ScintillaGTK.c...
Seems to be defined for GTK+ >= 2.6.
I was in too much of a rush, missed it. In that case I can't add anything new except to note that watching the lists, GTK on windows seems a bit doubtful as to its maturity.
Like Thomas I'd say so long as the plugin continues to work on Linux and doesn't do anything *bad* on Windows then make it available with whatever differences on Windows documented, its better than not available at all.
Cheers Lex
Cheers, Matthew Brush _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 28.03.2011 02:31, Matthew Brush wrote:
So after spending way too much time on this, and getting nowhere, I give up. I'm attaching a patch that no dev is going to like because it behaves differently on Windows than it does on non-Windows to work around a know issue in GTK+ that is not documented to affect Windows differently than X windows. Either someone else needs to find the root of the problem deep inside GTK+ (ie. why it reparenting only breaks on Windows), we figure out what's happening in Scintilla, we use the slightly hacky approach of behaving differently on Windows, or we just leave the whole plugin stay disable and let the Windows users not have it, even though we *can* make it working. Since it's just a plugin, completely separate from the core code, which is already kinda hacky with what it's doing, my opinion is just to use the patch.
It's not my call, but the patch is here if you want it.
I agree here. Your patch is a lot better than "not working at all", isn't it?
Best regards.
On 03/27/11 09:11, Colomban Wendling wrote:
We need a better fix then. Maybe you can try to find out why the X clipboard get broken on Scintilla (and fix it :D). If it get fixed, we will probably can re-apply the patch.
When the ScintillaObject gets reparented (unrealized/re-realized), it doesn't re-setup the selection targets again (this is only done in ScintillaGTK::Initialize()).
The first patch #0001 is the same as the previous #0003 patch, which removes the reparenting stuff, to make Split Window work on Windows.
The second patch #0002 fixes the primary selection issue by moving gtk_selection_add_targets() and friends into the ScintillaGTK::RealizeThis() function, and also adds its counter-parts to the ScintillaGTK::UnRealizeThis() function.
The third patch #0003 fixes the issue where the I-Beam cursor is displayed even for the scrollbars when the widget is unrealized/re-realized. I tried a few different ways to do this, including trying to use Scintilla's SetCursor() function, but nothing seemed to work.
Everything *seems* to work now, and it's not hacky, IMO - except maybe #0003 a little bit ;).
Cheers, Matthew Brush
On 03/27/11 23:39, Matthew Brush wrote:
On 03/27/11 09:11, Colomban Wendling wrote:
We need a better fix then. Maybe you can try to find out why the X clipboard get broken on Scintilla (and fix it :D). If it get fixed, we will probably can re-apply the patch.
When the ScintillaObject gets reparented (unrealized/re-realized), it
I meant "When the ScintillaObject gets unrealized then re-realized...", I removed the reparenting stuff, which is/was meant to avoid the unrealizing/re-realizing :)
Cheers, Matthew Brush
On 28 March 2011 17:39, Matthew Brush mbrush@codebrainz.ca wrote:
On 03/27/11 09:11, Colomban Wendling wrote:
We need a better fix then. Maybe you can try to find out why the X clipboard get broken on Scintilla (and fix it :D). If it get fixed, we will probably can re-apply the patch.
When the ScintillaObject gets reparented (unrealized/re-realized), it doesn't re-setup the selection targets again (this is only done in ScintillaGTK::Initialize()).
The first patch #0001 is the same as the previous #0003 patch, which removes the reparenting stuff, to make Split Window work on Windows.
The second patch #0002 fixes the primary selection issue by moving gtk_selection_add_targets() and friends into the ScintillaGTK::RealizeThis() function, and also adds its counter-parts to the ScintillaGTK::UnRealizeThis() function.
The third patch #0003 fixes the issue where the I-Beam cursor is displayed even for the scrollbars when the widget is unrealized/re-realized. I tried a few different ways to do this, including trying to use Scintilla's SetCursor() function, but nothing seemed to work.
Everything *seems* to work now, and it's not hacky, IMO - except maybe #0003 a little bit ;).
Cheers, Matthew Brush
Hi Matthew,
I havn't had a chance to try it, but perhaps you should report the problem to Scintilla and submit the two patches to Neil. In general Geany tries to use an unmodified version of Scintilla so that changes don't have to be made each time its updated.
Since this is to fix a plugin problem not a core problem (albeit a core plugin) I would suggest waiting for the response from Scintilla rather than including patches in the Geany Scintilla.
What do others think?
Cheers Lex
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Mon, 28 Mar 2011 21:38:22 +1100, Lex wrote:
On 28 March 2011 17:39, Matthew Brush mbrush@codebrainz.ca wrote:
On 03/27/11 09:11, Colomban Wendling wrote:
We need a better fix then. Maybe you can try to find out why the X clipboard get broken on Scintilla (and fix it :D). If it get fixed, we will probably can re-apply the patch.
When the ScintillaObject gets reparented (unrealized/re-realized), it doesn't re-setup the selection targets again (this is only done in ScintillaGTK::Initialize()).
The first patch #0001 is the same as the previous #0003 patch, which removes the reparenting stuff, to make Split Window work on Windows.
The second patch #0002 fixes the primary selection issue by moving gtk_selection_add_targets() and friends into the ScintillaGTK::RealizeThis() function, and also adds its counter-parts to the ScintillaGTK::UnRealizeThis() function.
The third patch #0003 fixes the issue where the I-Beam cursor is displayed even for the scrollbars when the widget is unrealized/re-realized. I tried a few different ways to do this, including trying to use Scintilla's SetCursor() function, but nothing seemed to work.
Everything *seems* to work now, and it's not hacky, IMO - except maybe #0003 a little bit ;).
Cheers, Matthew Brush
Hi Matthew,
I havn't had a chance to try it, but perhaps you should report the problem to Scintilla and submit the two patches to Neil. In general Geany tries to use an unmodified version of Scintilla so that changes don't have to be made each time its updated.
Since this is to fix a plugin problem not a core problem (albeit a core plugin) I would suggest waiting for the response from Scintilla rather than including patches in the Geany Scintilla.
What do others think?
The same. First, the Scintilla patches should be shared with upstream, ideally they apply them. Then we can patch Geany.
Regards, Enrico
On 03/28/11 11:49, Enrico Tröger wrote:
On Mon, 28 Mar 2011 21:38:22 +1100, Lex wrote:
I havn't had a chance to try it, but perhaps you should report the problem to Scintilla and submit the two patches to Neil. In general Geany tries to use an unmodified version of Scintilla so that changes don't have to be made each time its updated.
Since this is to fix a plugin problem not a core problem (albeit a core plugin) I would suggest waiting for the response from Scintilla rather than including patches in the Geany Scintilla.
What do others think?
The same. First, the Scintilla patches should be shared with upstream, ideally they apply them. Then we can patch Geany.
Done.
I re-did the patches proper against Scintilla's Mercurial repository and posted a bug report on Source Forge[1].
[1] https://sourceforge.net/tracker/?func=detail&aid=3256153&group_id=24...
Cheers, Matthew Brush
On Mon, 28 Mar 2011 23:44:42 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
First, the Scintilla patches should be shared with upstream, ideally they apply them. Then we can patch Geany.
Done.
I re-did the patches proper against Scintilla's Mercurial repository and posted a bug report on Source Forge[1].
[1] https://sourceforge.net/tracker/?func=detail&aid=3256153&group_id=24...
Great, thanks. I added a comment to explain the plugin a bit more.
Regards, Nick
On 03/29/11 06:03, Nick Treleaven wrote:
On Mon, 28 Mar 2011 23:44:42 -0700 Matthew Brushmbrush@codebrainz.ca wrote:
First, the Scintilla patches should be shared with upstream, ideally they apply them. Then we can patch Geany.
Done.
I re-did the patches proper against Scintilla's Mercurial repository and posted a bug report on Source Forge[1].
[1] https://sourceforge.net/tracker/?func=detail&aid=3256153&group_id=24...
Great, thanks. I added a comment to explain the plugin a bit more.
The patches were committed[1][2].
So now, can we patch our copy of Scintilla, or do we need to wait until their next release and then until we update to that version?
I'm pretty confident those patches will apply cleanly on versions between ours and what they just got committed to, though I don't really understand Scintilla versions and how/when we update.
[1] http://scintilla.hg.sourceforge.net/hgweb/scintilla/scintilla/rev/e88a8a880c... [2] http://scintilla.hg.sourceforge.net/hgweb/scintilla/scintilla/rev/874b84aa77...
Cheers, Matthew Brush
On Tue, 29 Mar 2011 18:39:37 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
The patches were committed[1][2].
So now, can we patch our copy of Scintilla, or do we need to wait until their next release and then until we update to that version?
We can patch our copy now.
I'm pretty confident those patches will apply cleanly on versions between ours and what they just got committed to, though I don't really understand Scintilla versions and how/when we update.
We update soon after a Scintilla release unless it's a major Scintilla release that may introduce bugs.
Regards, Nick
On Wed, 30 Mar 2011 13:03:33 +0100, Nick wrote:
On Tue, 29 Mar 2011 18:39:37 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
The patches were committed[1][2].
Cool! (btw, I also didn't get the mails from the SF tracker although I'm monitoring it, also not all of these mails didn't arrive on the scintilla list, so I'd say also it's a problem at SF)
So now, can we patch our copy of Scintilla, or do we need to wait until their next release and then until we update to that version?
We can patch our copy now.
I'm pretty confident those patches will apply cleanly on versions between ours and what they just got committed to, though I don't really understand Scintilla versions and how/when we update.
We update soon after a Scintilla release unless it's a major Scintilla release that may introduce bugs.
Currently there is the problem with dropped support for old C++ compilers which may not affect us directly but more over the introduction of new C++0x code. For details see http://groups.google.com/group/scintilla-interest/browse_thread/thread/8f9c4.... Though Scintilla's release notes state that the Borland C++ support was removed, I'm not sure if the new C++0x code is already in. Nick, Lex, do you know more about the current status?
Regards, Enrico
Le 30/03/2011 22:59, Enrico Tröger a écrit :
On Wed, 30 Mar 2011 13:03:33 +0100, Nick wrote:
[...] We update soon after a Scintilla release unless it's a major Scintilla release that may introduce bugs.
Currently there is the problem with dropped support for old C++ compilers which may not affect us directly but more over the introduction of new C++0x code. For details see http://groups.google.com/group/scintilla-interest/browse_thread/thread/8f9c4.... Though Scintilla's release notes state that the Borland C++ support was removed, I'm not sure if the new C++0x code is already in. Nick, Lex, do you know more about the current status?
Good question, thanks Enrico for asking it :) Actually there is another patch that was applied to upstream Sinctilla I would like to see in our copy (related to Vala highlighting), so I wondered if we didn't wanted to update our scintilla copy at some point... but there is the C++0x thing.
Cheers, Colomban
Currently there is the problem with dropped support for old C++ compilers which may not affect us directly but more over the introduction of new C++0x code. For details see http://groups.google.com/group/scintilla-interest/browse_thread/thread/8f9c4.... Though Scintilla's release notes state that the Borland C++ support was removed, I'm not sure if the new C++0x code is already in. Nick, Lex, do you know more about the current status?
Good question, thanks Enrico for asking it :) Actually there is another patch that was applied to upstream Sinctilla I would like to see in our copy (related to Vala highlighting), so I wondered if we didn't wanted to update our scintilla copy at some point... but there is the C++0x thing.
Well Scintilla 2.25 does not use the std=c++0x option and it does use -Wall which includes a c++0x warning so I would say its reasonably safe.
Cheers Lex
On Thu, 31 Mar 2011 09:17:26 +1100 Lex Trotman elextr@gmail.com wrote:
Currently there is the problem with dropped support for old C++ compilers which may not affect us directly but more over the introduction of new C++0x code. For details see http://groups.google.com/group/scintilla-interest/browse_thread/thread/8f9c4.... Though Scintilla's release notes state that the Borland C++ support was removed, I'm not sure if the new C++0x code is already in. Nick, Lex, do you know more about the current status?
Good question, thanks Enrico for asking it :) Actually there is another patch that was applied to upstream Sinctilla I would like to see in our copy (related to Vala highlighting), so I wondered if we didn't wanted to update our scintilla copy at some point... but there is the C++0x thing.
Well Scintilla 2.25 does not use the std=c++0x option and it does use -Wall which includes a c++0x warning so I would say its reasonably safe.
Yes, and I'd expect Neil to mention it in the release notes if the requirements change. Now that C++0x has been finalised as C++ 2011 this might encourage him :-/
Regards, Nick
On Thu, 31 Mar 2011 16:56:44 +0100, Nick wrote:
On Thu, 31 Mar 2011 09:17:26 +1100 Lex Trotman elextr@gmail.com wrote:
Currently there is the problem with dropped support for old C++ compilers which may not affect us directly but more over the introduction of new C++0x code. For details see http://groups.google.com/group/scintilla-interest/browse_thread/thread/8f9c4.... Though Scintilla's release notes state that the Borland C++ support was removed, I'm not sure if the new C++0x code is already in. Nick, Lex, do you know more about the current status?
Good question, thanks Enrico for asking it :) Actually there is another patch that was applied to upstream Sinctilla I would like to see in our copy (related to Vala highlighting), so I wondered if we didn't wanted to update our scintilla copy at some point... but there is the C++0x thing.
Well Scintilla 2.25 does not use the std=c++0x option and it does use -Wall which includes a c++0x warning so I would say its reasonably safe.
Yes, and I'd expect Neil to mention it in the release notes if the requirements change. Now that C++0x has been finalised as C++ 2011 this might encourage him :-/
Ok, then we could update our Scintilla copy soon, either with the current release and patch Matthew's patches in or wait for the next release which includes the patches.
Regards, Enrico
On 03/31/11 10:34, Enrico Tröger wrote:
Ok, then we could update our Scintilla copy soon, either with the current release and patch Matthew's patches in or wait for the next release which includes the patches.
FWIW, I finally got Geany compiling on Windows XP. Even without the patches, using GTK+ 2.22, there is no problem with Split Window plugin here[1].
I guess patches applied would be good for older GTK+ versions.
[1] http://www.codebrainz.ca/images/screens/geany-splitwindow-xp.png
Cheers, Matthew Brush
On 03/30/11 05:03, Nick Treleaven wrote:
On Tue, 29 Mar 2011 18:39:37 -0700 Matthew Brushmbrush@codebrainz.ca wrote:
The patches were committed[1][2].
So now, can we patch our copy of Scintilla, or do we need to wait until their next release and then until we update to that version?
We can patch our copy now.
Now that we have all our ducks in a row, I've attached two patches to re-add Windows support to the Split Window plugin.
#0001 Applies the patches merged upstream and puts copies of the two patches in the scintilla/ directory (not sure if this is needed).
#0002 The patch that was applied and removed previously on SVN, but I recommitted on my local (up to date) Git copy and re-worded the commit message a bit. Probably any of the older versions of this patch will work just the same.
In the meantime, I'll keep testing...at least in Linux.
Cheers, Matthew Brush