I forgot to add also that sometimes SciTE looses focus and it's somewhat tricky to gain it back. It could be problem with Compiz, but I noticed this only with SciTE when I drag and drop files on SciTE launcher
> Working with some text files I noticed this (reproducible):
> regex search pattern ".*\d$"
> I hit match all and continue to work
> after that I try to search same pattern again and SciTE freezes and I > must terminate process
Can't reproduce this. Perhaps there is some feature of the files or the subsequent expression that is associated with this behaviour.
> While here, also "SciTE help" menu action doesn't work. HTML files are > on usual location /usr/share/scite/
If the global options was installed in the right spot then it should be calling xdg-open which works for me although there is a warning from firefox-bin. There may be a stale options file that calls netscape which is no longer installed.
> I forgot to add also that sometimes SciTE looses focus and it's > somewhat tricky to gain it back. It could be problem with Compiz, but > I noticed this only with SciTE when I drag and drop files on SciTE > launcher
Looks like the window manager has gone into a strange mode.
On Dec 19, 11:32 pm, Neil Hodgson <nyamaton...@gmail.com> wrote:
> zetah:
> > Working with some text files I noticed this (reproducible):
> > regex search pattern ".*\d$"
> > I hit match all and continue to work
> > after that I try to search same pattern again and SciTE freezes and I
> > must terminate process
> Can't reproduce this. Perhaps there is some feature of the files or
> the subsequent expression that is associated with this behaviour.
Perhaps it depends on file content. Here is how it can be reproduced:
Open text file (some README or similar with more then ~100 text lines)
and Find "match all" this pattern ".*\w$". Then try again
> > While here, also "SciTE help" menu action doesn't work. HTML files are
> > on usual location /usr/share/scite/
> If the global options was installed in the right spot then it
> should be calling xdg-open which works for me although there is a
> warning from firefox-bin. There may be a stale options file that calls
> netscape which is no longer installed.
If you mean about "SciTEGlobal.properties" it's on same place as help
files : /usr/share/scite/
> > I forgot to add also that sometimes SciTE looses focus and it's
> > somewhat tricky to gain it back. It could be problem with Compiz, but
> > I noticed this only with SciTE when I drag and drop files on SciTE
> > launcher
> Looks like the window manager has gone into a strange mode.
Yeah, Compiz is not the most reliable manager, but it's default on
Ubuntu
> Perhaps it depends on file content. Here is how it can be reproduced: > Open text file (some README or similar with more then ~100 text lines) > and Find "match all" this pattern ".*\w$". Then try again
> > Perhaps it depends on file content. Here is how it can be reproduced:
> > Open text file (some README or similar with more then ~100 text lines)
> > and Find "match all" this pattern ".*\w$". Then try again
>> It even freezes SciTE on first try to match all ".*\d$"
I have not been able to get SciTE to freeze either, using 3.0.2 on Windows XP. Well, I should say that while I used the test file at the link above, I didn't do "match all" because I don't see that feature. I used the regular expression match to repeatedly find one at a time, and I used it to "Mark All", and neither of those gave me any problems that I noticed.
>>> It even freezes SciTE on first try to match all ".*\d$"
> I have not been able to get SciTE to freeze either, using 3.0.2 on > Windows XP. Well, I should say that while I used the test file at the > link above, I didn't do "match all" because I don't see that feature. > I used the regular expression match to repeatedly find one at a time, > and I used it to "Mark All", and neither of those gave me any problems > that I noticed.
> John
> -- > You received this message because you are subscribed to the Google Groups "scite-interest" group. > To post to this group, send email to scite-interest@googlegroups.com. > To unsubscribe from this group, send email to scite-interest+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/scite-interest?hl=en.
SciTE window is dimmed like every unresponsive program on my OS
I still can't reproduce with gdb
CPU usage is high and process never finishes as I left SciTE like that
for some time. Although CPU isn't used greedy (20-25% on P4 3GHz) so
it doesn't stop me doing other things
About help file I mentioned earlier... I didn't know about setting in
global preferences - "command.scite.help" which wasn't present in my
SciTE global properties and I corrected that, so everything is perfect
now
> Same here (ubuntu 11.04, scite build from mercurial - gtk2), > but it freezes not if have:
> open.asynchronous=0
> in .SciTEUser.properties i was required to restart SciTE.
open.asynchronous was dropped from 3.0.2 and should have no effect. This behaviour is now controlled with the background.open.size and background.save.size properties.
While it doesn't have symbols for SciTE or Scintilla, its in ScintillaGTK::ClaimSelection asking to own the primary selection, probably after setting the selection as a result of a dialog action. The arguments to the gtk_selection_owner_set call are fairly simple and unlikely to go wrong. Its communicating with the X server so perhaps there is another application monitoring the primary selection or this is a remote X session. Its also possible that there is a loop in SciTE setting the selection repeatedly.
So that's why it wasn't easy to reproduce - if I had left selection in
editor and do a search/mark all than it would freeze. If I didn't had
selection in editor and do the same then it doesn't freeze.
I checked it and it's like that.
Thanks for explanation. Now I can avoid this problem :)
> While it doesn't have symbols for SciTE or Scintilla, its in
> ScintillaGTK::ClaimSelection asking to own the primary selection,
> probably after setting the selection as a result of a dialog action.
> The arguments to the gtk_selection_owner_set call are fairly simple
> and unlikely to go wrong. Its communicating with the X server so
> perhaps there is another application monitoring the primary selection
> or this is a remote X session. Its also possible that there is a loop
> in SciTE setting the selection repeatedly.
I misinterpreted your reply too soon, unfortunately.
Main problem is not in some selected text. It happen couple of times
afterwards without anything selected in editor. Backtrace is exactly
same as previously posted. I also changed my clipboard manager, just
in case - this is still open issue to me.
On Dec 23 2011, 11:38 am, Neil Hodgson <nyamaton...@gmail.com> wrote:
> While it doesn't have symbols for SciTE or Scintilla, its in
> ScintillaGTK::ClaimSelection asking to own the primary selection,
> probably after setting the selection as a result of a dialog action.
> The arguments to the gtk_selection_owner_set call are fairly simple
> and unlikely to go wrong. Its communicating with the X server so
> perhaps there is another application monitoring the primary selection
> or this is a remote X session. Its also possible that there is a loop
> in SciTE setting the selection repeatedly.
> same as previously posted. I also changed my clipboard manager, just > in case - this is still open issue to me.
I can reproduce this even with Windows XP. I noticed that you are using Linux, but your testfile[1] has CRLF line-ends. So if I load your file, change the SciTE line-end setting to LF and do Find->".*\d$"->Mark All, I get an unresponsive SciTE. Sometimes SciTE finds some random lines on the first run, but at last on the second run it get stuck.
> On Dec 23 2011, 11:38 am, Neil Hodgson <nyamaton...@gmail.com> wrote: >> or this is a remote X session. Its also possible that there is a loop >> in SciTE setting the selection repeatedly.
Yes. With that line-end setting the expression shouldn't match any line, because there is always a CR char between the last \d and the lineend (LF). The Problem is, that SciTE doesn't find the starting point either. So it is spinning around ("Wrap around") again and again. I can see this because the slider moves up and down, and the spin-around-sound is played every few ms ;-)
> Yes. With that line-end setting the expression shouldn't match any line, > because there is always a CR char between the last \d and the > lineend (LF).
That's not it. The problem is that the caret is inside a match for the regular expression. The search starts from the caret and matches immediately at the caret. The search continues to match later lines then loops back to the beginning and up towards the first line that matched. On the line of the first match it matches from the start of the line which is a different position from the initial match which was part way along the line. Because it isn't the same location, the loop doesn't terminate.
Committed a fix for the freeze on find bug. The resulting marks may not be as expected as the loop stops before creating a mark that will overlap the initial mark, so for the example ".*\d$" the contents of the line before the caret position will not be marked.
