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
I tried some some other regex pattern but no problem with repeated
search. Must be some bug
While here, also "SciTE help" menu action doesn't work. HTML files are
on usual location /usr/share/scite/
> 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.
Looks like the window manager has gone into a strange mode.
Neil
> 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
Could not reproduce with this file:
http://heterobetainas.uah.es/jmol/README.txt
Neil
> Here is example file: http://pastebin.com/raw.php?i=sD2pgbmH
>
> It even freezes SciTE on first try to match all ".*\d$"
This does not freeze for me. You could try running under a debugger
to get a stack trace when the freeze occurs.
Neil
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
open.asynchronous=0
in .SciTEUser.properties i was required to restart SciTE.
best regards, Holger
2011/12/22 John Yeung <gallium....@gmail.com>:
> --
> You received this message because you are subscribed to the Google Groups "scite-interest" group.
> To post to this group, send email to scite-i...@googlegroups.com.
> To unsubscribe from this group, send email to scite-interes...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/scite-interest?hl=en.
>
--
Holger Kohnen
(Webentwickler)
Anklamer Str. 35
10115 Berlin
h.ko...@gmail.com
http://www.holgerkohnen.de
030 / 788 37 22
0173 / 38 62 791
> 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.
Neil
> I didn't know I can attach to running process.
>
> Here is bt from attaching to hanged scite process: http://pastebin.com/raw.php?i=9a9h0m91
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.
Neil
> 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 ;-)
HTH
Alfred
[1] <http://pastebin.com/raw.php?i=sD2pgbmH>
--
12135.3
> 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.
Neil
Available from Hg and from
http://www.scintilla.org/scite.zip Source
http://www.scintilla.org/wscite.zip Windows executable
Neil