jedit-devel Mailing List for jEdit

Bugs item #950961, was opened at 2004-05-09 23:37
Message generated for change (Settings changed) made by kpouer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=950961&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: editor core
Group: minor bug
Status: Open
Resolution: None
Priority: 6
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Matthieu Casanova (kpouer)
Summary: Folding: handling newlines at the start of closed folds

Initial Comment:
Here is the example text folded using explicit folding:
1| //{{{
2| Folding
3| Test
4| Case
5| //}}}
6| Other text

which folds to:
1| //{{{ [4 lines]
6| Other text

By placing the caret after the last brace and pressing 
return we get the
following result:
1| //{{{
2| New text entered
7| Other text

In the editor the fold is now showen as unfolded, but the 
text within the fold is not displayed. To display the 
contents of the fold you have to close the fold and open 
it again which then would display the expected text:
1| //{{{
2| New text entered
3| Folding
4| Test
5| Case
6| //}}}
7| Other text

This error appears to exist with any folding plugin, not 
just explicit folding. Secondly, with explict folding only, 
placing the caret between the braces that make up the 
start of the fold whilst folded and pressing return causes 
the fold to be 'lost'. As in the space taken up by the fold 
is still indicated by jEdit but the fold is no longer 
displayed:
1| //{{
2|    ^{
7| Other text

There are three ways to get the fold back.
1) Delete the new line and whitespace entered.
This returns the fold in a closed position

2) Add new braces to complete the fold marker.
This adds the fold in an open position but without the 
origenal text displayed. Closing and reopening the fold 
corrects this, the same as the first bug.

3) Reopen the file

KeeperOfTheSoul <ex...@dy...>

----------------------------------------------------------------------

Comment By: Robert Schwenn (rschwenn)
Date: 2007-01-30 23:36

Message:
Logged In: YES 
user_id=1486645
Originator: NO

jEdit 4.3pre9: still occurs

Because "{{{" is the beginning of the fold, I find it's ok to create a new
line under "{{{" when hitting ENTER there. But to avoid confusion the fold
should be expanded automatically in this case.



----------------------------------------------------------------------

Comment By: Brad Mace (bemace)
Date: 2006-03-22 16:16

Message:
Logged In: YES 
user_id=370261

This still occurs in 4.3pre3.

I'd expect hitting 'enter' at the end of a collapsed fold
line would create a new line after the fold, rather than
inside the fold.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=950961&group_id=588

Bugs item #1193683, was opened at 2005-05-02 11:22
Message generated for change (Comment added) made by kpouer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1193683&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 7
Private: No
Submitted By: Matthieu Casanova (kpouer)
>Assigned to: Matthieu Casanova (kpouer)
Summary: folding bug, text is in a black hole

Initial Comment:
Hi, when you have some folded text (folding closed)

{{{ test
aaaa
bbbb
cccc
}}}

Close it you'll get

{{{ test [4 lines]

Delete one {

You'll have

{{ test

and no text fold anymore. It seems really dangerous
isn't it ?
But the weird thing is that the text is not completely
lost because you can type another { (no need to undo)
and the fold will reappear magically. So the text was
still here but hidden by jEdit's text area

----------------------------------------------------------------------

>Comment By: Matthieu Casanova (kpouer)
Date: 2007-08-01 00:06

Message:
Logged In: YES 
user_id=285591
Originator: YES

Hi, this bug is fixed in SVN now.
There is a lot of combination that can lead to this bug so I may have
forgot some case, please try and tell me if you find one

The bug 950961 is still not fixed, I'll see how to do it, it should be
similar.

----------------------------------------------------------------------

Comment By: Robert Schwenn (rschwenn)
Date: 2007-02-09 23:27

Message:
Logged In: YES 
user_id=1486645
Originator: NO

jEdit 4.3pre9: still occurs.

See also bug #950961 

java 1.5.0_10
WinXP SP2

----------------------------------------------------------------------

Comment By: Vic Elor (timecool2)
Date: 2006-05-08 00:22

Message:
Logged In: YES 
user_id=1487724

If you save and reload the file or use the expand level
command the text in question will unfold.

So the program seems to need to learn to update after the {
is removed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1193683&group_id=588

Bugs item #1670241, was opened at 2007-02-27 19:40
Message generated for change (Comment added) made by blueyed
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1670241&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: search and replace
Group: normal bug
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: daniel hahler (blueyed)
Assigned to: Alan Ezust (ezust)
Summary: "Synchronize" in Search dialog should use "last extension"

Initial Comment:
When a file like foo.class.php is opened and you click "Synchronize" in the "Search and Replace" dialog, the file glob pattern gets set to "*.class.php".

IMHO this should be rather "*.php" (only the "last" extension.

The Synchronize button uses MiscUtilities.getFileExtension and this returns the part of the filename, after the first dot.

This is meant to handle e.g. ".tar.gz" as an extension - so it should not get changed in MiscUtilities. Instead the "Synchronize" action should use a custom method IMHO.



----------------------------------------------------------------------

>Comment By: daniel hahler (blueyed)
Date: 2007-07-31 23:36

Message:
Logged In: YES 
user_id=663176
Originator: YES

Yes, I think this makes sense: have a special case for known file types
which have "double extensions". Are there others like .gz and .bz2?

What about "file.php.gz"? Should getFileExtension return "php.gz" for this
one?

----------------------------------------------------------------------

Comment By: Alan Ezust (ezust)
Date: 2007-07-31 23:05

Message:
Logged In: YES 
user_id=935841
Originator: NO

perhaps miscUtilities.getFileExtension should have a special case for any
.gz or .bz2 files

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1670241&group_id=588

Plugin Bugs item #1735797, was opened at 2007-06-12 16:50
Message generated for change (Comment added) made by kpouer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=1735797&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Matthieu Casanova (kpouer)
Assigned to: Nobody/Anonymous (nobody)
Summary: XML 2.0.6 : NoSuchMethodError

Initial Comment:
Hi, when trying sidekick complete in a CSS document I have this exception. Any idea of the reason ?
thanks

java.lang.NoSuchMethodError: org.apache.xml.resolver.CatalogManager.setAllowOasisXMLCatalogPI(Z)V
	at org.apache.xerces.util.XMLCatalogResolver.init(Unknown Source)
	at org.apache.xerces.util.XMLCatalogResolver.<init>(Unknown Source)
	at org.apache.xerces.util.XMLCatalogResolver.<init>(Unknown Source)
	at xml.Resolver.load(Unknown Source)
	at xml.Resolver.instance(Unknown Source)
	at sidekick.css.CssSideKickCompletion.readCompletionConfig(Unknown Source)
	at sidekick.css.CssSideKickCompletion.initialize(Unknown Source)
	at sidekick.css.CompletionRequest.<init>(Unknown Source)
	at sidekick.css.CSS2SideKickParser.complete(Unknown Source)
	at sidekick.SideKickActions.complete(SideKickActions.java:112)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at bsh.Reflect.invokeMethod(Reflect.java:134)
	at bsh.Reflect.invokeStaticMethod(Reflect.java:98)
	at bsh.Name.invokeMethod(Name.java:874)
	at bsh.BSHMethodInvocation.eval(BSHMethodInvocation.java:75)
	at bsh.BSHPrimaryExpression.eval(BSHPrimaryExpression.java:102)
	at bsh.BSHPrimaryExpression.eval(BSHPrimaryExpression.java:47)
	at bsh.BSHBlock.evalBlock(BSHBlock.java:130)
	at bsh.BSHBlock.eval(BSHBlock.java:80)
	at bsh.BshMethod.invokeImpl(BshMethod.java:362)
	at bsh.BshMethod.invoke(BshMethod.java:258)
	at bsh.BshMethod.invoke(BshMethod.java:186)
	at org.gjt.sp.jedit.BeanShell.runCachedBlock(BeanShell.java:509)
	at org.gjt.sp.jedit.BeanShellAction.invoke(BeanShellAction.java:76)
	at org.gjt.sp.jedit.gui.InputHandler.invokeAction(InputHandler.java:416)
	at org.gjt.sp.jedit.gui.InputHandler.invokeAction(InputHandler.java:382)
	at org.gjt.sp.jedit.gui.DefaultInputHandler.handleKey(DefaultInputHandler.java:373)
	at org.gjt.sp.jedit.input.AbstractInputHandler.processKeyEventKeyStrokeHandling(AbstractInputHandler.java:116)
	at org.gjt.sp.jedit.gui.InputHandler.processKeyEvent(InputHandler.java:185)
	at org.gjt.sp.jedit.textarea.TextArea.processKeyEvent(TextArea.java:4556)
	at java.awt.Component.processEvent(Unknown Source)
	at java.awt.Container.processEvent(Unknown Source)
	at java.awt.Component.dispatchEventImpl(Unknown Source)
	at java.awt.Container.dispatchEventImpl(Unknown Source)
	at java.awt.Component.dispatchEvent(Unknown Source)
	at java.awt.KeyboardFocusManager.redispatchEvent(Unknown Source)
	at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(Unknown Source)
	at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(Unknown Source)
	at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(Unknown Source)
	at java.awt.DefaultKeyboardFocusManager.dispatchEvent(Unknown Source)
	at java.awt.Component.dispatchEventImpl(Unknown Source)
	at java.awt.Container.dispatchEventImpl(Unknown Source)
	at java.awt.Window.dispatchEventImpl(Unknown Source)
	at java.awt.Component.dispatchEvent(Unknown Source)
	at java.awt.EventQueue.dispatchEvent(Unknown Source)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.run(Unknown Source)


----------------------------------------------------------------------

>Comment By: Matthieu Casanova (kpouer)
Date: 2007-07-31 23:05

Message:
Logged In: YES 
user_id=285591
Originator: YES

Hi I cannot reproduce it with 2.9.0 so I suppose it is fixed, I close the
bug.

----------------------------------------------------------------------

Comment By: Alan Ezust (ezust)
Date: 2007-07-31 22:10

Message:
Logged In: YES 
user_id=935841
Originator: NO

I can't reproduce this. Can you try with xerces plugin 2.9.0?


----------------------------------------------------------------------

Comment By: Alan Ezust (ezust)
Date: 2007-07-12 18:30

Message:
Logged In: YES 
user_id=935841
Originator: NO

It looks like it's using xml.Resolver, a new class I haven't fully tested
or started using yet.
It could use CatalogManager instead, but that relies on an old library I'd
like to phase out one of these days.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=1735797&group_id=588

Bugs item #1670241, was opened at 2007-02-27 10:40
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1670241&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: search and replace
Group: normal bug
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: daniel hahler (blueyed)
>Assigned to: Alan Ezust (ezust)
Summary: "Synchronize" in Search dialog should use "last extension"

Initial Comment:
When a file like foo.class.php is opened and you click "Synchronize" in the "Search and Replace" dialog, the file glob pattern gets set to "*.class.php".

IMHO this should be rather "*.php" (only the "last" extension.

The Synchronize button uses MiscUtilities.getFileExtension and this returns the part of the filename, after the first dot.

This is meant to handle e.g. ".tar.gz" as an extension - so it should not get changed in MiscUtilities. Instead the "Synchronize" action should use a custom method IMHO.



----------------------------------------------------------------------

>Comment By: Alan Ezust (ezust)
Date: 2007-07-31 14:05

Message:
Logged In: YES 
user_id=935841
Originator: NO

perhaps miscUtilities.getFileExtension should have a special case for any
.gz or .bz2 files

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1670241&group_id=588

Bugs item #1710748, was opened at 2007-05-01 11:39
Message generated for change (Settings changed) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1710748&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Deleted
>Resolution: Invalid
Priority: 7
Private: No
Submitted By: Alan Ezust (ezust)
Assigned to: Nobody/Anonymous (nobody)
Summary: Activity Log dockable doesn't show all [error] lines

Initial Comment:
I can see [debug] and [notice] in the dockable, but to see the errors, I have to look at the actual activity.log file. 




----------------------------------------------------------------------

Comment By: Alan Ezust (ezust)
Date: 2007-05-21 10:14

Message:
Logged In: YES 
user_id=935841
Originator: YES

I see some errors in it, but not all of them. 
For example, when SideKickTree has problems determining the mode of the
current buffer, it does this (line 623):

if (m == null) {
   Log.log(Log.ERROR, this, "SideKick: can't determine mode of current
buffer:" + b);
}

I can see this in the activity.log file, and in the standard error, but
not in the activity log dockable.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1710748&group_id=588

Patches item #1738506, was opened at 2007-06-16 16:08
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300588&aid=1738506&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Fatih Asici (fatih_asici)
Assigned to: Nobody/Anonymous (nobody)
Summary: Locale settings can cause failures when building docs

Initial Comment:
When using Turkish locale settings(LC_ALL=tr_TR.UTF-8), build of documentation files fails with these:

  [javadoc] Building index for all the packages and classes...
  [javadoc] java.util.MissingResourceException: Can't find resource for bundle com.sun.tools.doclets.internal.toolkit.resources.doclets, key doclet.ınterface
  [javadoc]     at java.util.ResourceBundle.getObject(ResourceBundle.java:325)
  [javadoc]     at java.util.ResourceBundle.getString(ResourceBundle.java:285)
  [javadoc]     at com.sun.tools.doclets.internal.toolkit.util.MessageRetriever.getText(MessageRetriever.java:114)
  [javadoc]     at com.sun.tools.doclets.internal.toolkit.util.MessageRetriever.getText(MessageRetriever.java:92)
  [javadoc]     at com.sun.tools.doclets.internal.toolkit.util.MessageRetriever.getText(MessageRetriever.java:81)
  [javadoc]     at com.sun.tools.doclets.internal.toolkit.util.MessageRetriever.getText(MessageRetriever.java:71)
  [javadoc]     at com.sun.tools.doclets.internal.toolkit.Configuration.getText(Configuration.java:627)
  
Problem exists in jedit4.3pre9 source archive. The attached patch fixes this.

----------------------------------------------------------------------

>Comment By: Alan Ezust (ezust)
Date: 2007-07-31 14:02

Message:
Logged In: YES 
user_id=935841
Originator: NO

Changing this to a patch. thanks for your contribution.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300588&aid=1738506&group_id=588

Bugs item #1633393, was opened at 2007-01-11 09:09
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1633393&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: editor core
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: pieroxy (pieroxy)
Assigned to: Nobody/Anonymous (nobody)
Summary: TextArea painting corruption when saving

Initial Comment:
Sometimes (usually after a bit of uptime using jEdit intensively) when I save a buffer, everything in the main TextArea goes wild. That is to say the display is broken and random stuff is displayed in place of the buffer I'm currently editing.

It first scared the hell out of me (thinking my buffer was corrupted) but only the display is. If I save again, the corruption changes (other random stuff is displayed - sometimes it goes back to normal) and if I scroll down (pagedown/up) or change buffer everything is back to normal. So all in all, jEdit is still usable.

Note that the syntax highlighting is unaffected by this bug. So I see garbage with the correct syntax highlighting of the buffer underneath. It is sometimes quite ... artistic ;)

Let me know if you need any more details or if I should try something while the display is messed up to help investigation.

Sorry if it's a dupe. I can't believe I'm the only one seeing that but I couldn't find this bug in the tracker...


[message] Log: java.version=1.6.0
[message] Log: java.vm.version=1.6.0-b105
[message] Log: java.runtime.version=1.6.0-b105
[message] Log: java.vendor=Sun Microsystems Inc.
[message] Log: java.compiler=null
[message] Log: os.name=Linux
[message] Log: os.version=2.6.17-10-generic
[message] Log: os.arch=i386
[message] Log: user.home=/home/pieroxy
[message] Log: java.home=/home/pieroxy/progs/jdk1.6.0/jre
[message] Log: java.class.path=/home/pieroxy/progs/jedit/jedit.jar
[notice] jEdit: jEdit version 4.3pre8


----------------------------------------------------------------------

>Comment By: Alan Ezust (ezust)
Date: 2007-07-31 14:01

Message:
Logged In: YES 
user_id=935841
Originator: NO

When this happens, I think that the line count, or the position of the
caret is incorrect. You'll notice this if yo try to scroll to the bottom of
the document.

currently, when it happens to me, I split and unsplit the editpane. The
resultant editpane looks fine after that.

I can't reproduce this reliably either.




----------------------------------------------------------------------

Comment By: Lindsey Simon (elsie)
Date: 2007-07-31 13:48

Message:
Logged In: YES 
user_id=130366
Originator: NO

I only encounter this bug with the XML plugin enabled. If I disable it,
the problem goes away. I'm seeing it currently on an ubuntu dapper and
feisty system with jedit 4.3pre10 using Java 1.6.0_01

----------------------------------------------------------------------

Comment By: Jeffrey Hoyt (jchoyt)
Date: 2007-02-13 08:35

Message:
Logged In: YES 
user_id=396194
Originator: NO

Though I can't reproduce this, I suspect it's caused by SideKick.  I've
only seen it in Java files, so it may be JavaSideKick.  The last two times
it's happened, I was able to get it to happen repeatedly when saving a
file.  The first time, when I disabled SideKick, it stopped.  Of course
stopping SideKick stops ALL the *SideKick plugins, so the next time, I just
diabled JavaSideKick and that also stopped the display corruption.  FWIW,
after I re-enable the plugins the problems does NOT come back.

Not sure what all this means, but I'd like to hear from others what TYPES
of files this happens to and whether or not they have SideKick installed
and set to parse on Save.

Jeff

----------------------------------------------------------------------

Comment By: Lemon Juice (lemon_juice)
Date: 2007-01-25 00:39

Message:
Logged In: YES 
user_id=1630383
Originator: NO

I can see this bug too - in 4.3pre7, pre8 and pre9. However, I haven't
been able to figure out when it happens, it seems random to me. The effect
is that certain lines in the display appear as duplicated while others
disappear, it looks like some portion of the display is shifted vertically
and when I move the cursor up and down, the lines seem to be repainted
properly. Minimizing and restoring jedit corrects the problem. Fortunately
the buffer is not corrupted, just the display. 

----------------------------------------------------------------------

Comment By: Marcelo Vanzin (vanza)
Date: 2007-01-11 22:03

Message:
Logged In: YES 
user_id=75113
Originator: NO

This has been seen by many people, but no one can easily duplicate it...
it doesn't seem to follow any pattern to be triggered. Interesting bug,
though, and pretty annoying.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1633393&group_id=588

Plugin Bugs item #1764901, was opened at 2007-07-31 15:50
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=1764901&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Lindsey Simon (elsie)
Assigned to: Nobody/Anonymous (nobody)
Summary: XML plugin causes weird characters in textarea on save

Initial Comment:
See Bug#1633393 in the regular jEdit tracker - I have repeatedly experienced this bug only when the XML plugin is enabled. I would really love to be using the XML plugin, but weird garbled text on my screen after save (which I do way too often) is a killa. I've seen it mentioned that it is perhaps caused by Sidekick, but I do not know.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=1764901&group_id=588

Bugs item #1633393, was opened at 2007-01-11 11:09
Message generated for change (Comment added) made by elsie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1633393&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: editor core
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: pieroxy (pieroxy)
Assigned to: Nobody/Anonymous (nobody)
Summary: TextArea painting corruption when saving

Initial Comment:
Sometimes (usually after a bit of uptime using jEdit intensively) when I save a buffer, everything in the main TextArea goes wild. That is to say the display is broken and random stuff is displayed in place of the buffer I'm currently editing.

It first scared the hell out of me (thinking my buffer was corrupted) but only the display is. If I save again, the corruption changes (other random stuff is displayed - sometimes it goes back to normal) and if I scroll down (pagedown/up) or change buffer everything is back to normal. So all in all, jEdit is still usable.

Note that the syntax highlighting is unaffected by this bug. So I see garbage with the correct syntax highlighting of the buffer underneath. It is sometimes quite ... artistic ;)

Let me know if you need any more details or if I should try something while the display is messed up to help investigation.

Sorry if it's a dupe. I can't believe I'm the only one seeing that but I couldn't find this bug in the tracker...


[message] Log: java.version=1.6.0
[message] Log: java.vm.version=1.6.0-b105
[message] Log: java.runtime.version=1.6.0-b105
[message] Log: java.vendor=Sun Microsystems Inc.
[message] Log: java.compiler=null
[message] Log: os.name=Linux
[message] Log: os.version=2.6.17-10-generic
[message] Log: os.arch=i386
[message] Log: user.home=/home/pieroxy
[message] Log: java.home=/home/pieroxy/progs/jdk1.6.0/jre
[message] Log: java.class.path=/home/pieroxy/progs/jedit/jedit.jar
[notice] jEdit: jEdit version 4.3pre8


----------------------------------------------------------------------

Comment By: Lindsey Simon (elsie)
Date: 2007-07-31 15:48

Message:
Logged In: YES 
user_id=130366
Originator: NO

I only encounter this bug with the XML plugin enabled. If I disable it,
the problem goes away. I'm seeing it currently on an ubuntu dapper and
feisty system with jedit 4.3pre10 using Java 1.6.0_01

----------------------------------------------------------------------

Comment By: Jeffrey Hoyt (jchoyt)
Date: 2007-02-13 10:35

Message:
Logged In: YES 
user_id=396194
Originator: NO

Though I can't reproduce this, I suspect it's caused by SideKick.  I've
only seen it in Java files, so it may be JavaSideKick.  The last two times
it's happened, I was able to get it to happen repeatedly when saving a
file.  The first time, when I disabled SideKick, it stopped.  Of course
stopping SideKick stops ALL the *SideKick plugins, so the next time, I just
diabled JavaSideKick and that also stopped the display corruption.  FWIW,
after I re-enable the plugins the problems does NOT come back.

Not sure what all this means, but I'd like to hear from others what TYPES
of files this happens to and whether or not they have SideKick installed
and set to parse on Save.

Jeff

----------------------------------------------------------------------

Comment By: Lemon Juice (lemon_juice)
Date: 2007-01-25 02:39

Message:
Logged In: YES 
user_id=1630383
Originator: NO

I can see this bug too - in 4.3pre7, pre8 and pre9. However, I haven't
been able to figure out when it happens, it seems random to me. The effect
is that certain lines in the display appear as duplicated while others
disappear, it looks like some portion of the display is shifted vertically
and when I move the cursor up and down, the lines seem to be repainted
properly. Minimizing and restoring jedit corrects the problem. Fortunately
the buffer is not corrupted, just the display. 

----------------------------------------------------------------------

Comment By: Marcelo Vanzin (vanza)
Date: 2007-01-12 00:03

Message:
Logged In: YES 
user_id=75113
Originator: NO

This has been seen by many people, but no one can easily duplicate it...
it doesn't seem to follow any pattern to be triggered. Interesting bug,
though, and pretty annoying.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1633393&group_id=588

Plugin Bugs item #1763986, was opened at 2007-07-30 13:17
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=1763986&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Deleted
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Alan Ezust (ezust)
>Assigned to: Alan Ezust (ezust)
Summary: AntFarm: incompatible with Ant 1.7.0

Initial Comment:
The AntFarm plugin doesn't seem to work when I am using Ant 1.7.0 instead of 1.6.5.

Symptoms: Showing the antfarm dockable, i can't see any build files, and when I try to add one, I see "loading..." message in the tree forever.

AntFarm needs a new maintainer.



----------------------------------------------------------------------

>Comment By: Alan Ezust (ezust)
Date: 2007-07-31 13:12

Message:
Logged In: YES 
user_id=935841
Originator: YES

nevermind. it seems to work as long as I include ant-launcher.jar in the
AntPlugin


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=1763986&group_id=588

Plugin Bugs item #1735797, was opened at 2007-06-12 07:50
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=1735797&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matthieu Casanova (kpouer)
Assigned to: Nobody/Anonymous (nobody)
Summary: XML 2.0.6 : NoSuchMethodError

Initial Comment:
Hi, when trying sidekick complete in a CSS document I have this exception. Any idea of the reason ?
thanks

java.lang.NoSuchMethodError: org.apache.xml.resolver.CatalogManager.setAllowOasisXMLCatalogPI(Z)V
	at org.apache.xerces.util.XMLCatalogResolver.init(Unknown Source)
	at org.apache.xerces.util.XMLCatalogResolver.<init>(Unknown Source)
	at org.apache.xerces.util.XMLCatalogResolver.<init>(Unknown Source)
	at xml.Resolver.load(Unknown Source)
	at xml.Resolver.instance(Unknown Source)
	at sidekick.css.CssSideKickCompletion.readCompletionConfig(Unknown Source)
	at sidekick.css.CssSideKickCompletion.initialize(Unknown Source)
	at sidekick.css.CompletionRequest.<init>(Unknown Source)
	at sidekick.css.CSS2SideKickParser.complete(Unknown Source)
	at sidekick.SideKickActions.complete(SideKickActions.java:112)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at bsh.Reflect.invokeMethod(Reflect.java:134)
	at bsh.Reflect.invokeStaticMethod(Reflect.java:98)
	at bsh.Name.invokeMethod(Name.java:874)
	at bsh.BSHMethodInvocation.eval(BSHMethodInvocation.java:75)
	at bsh.BSHPrimaryExpression.eval(BSHPrimaryExpression.java:102)
	at bsh.BSHPrimaryExpression.eval(BSHPrimaryExpression.java:47)
	at bsh.BSHBlock.evalBlock(BSHBlock.java:130)
	at bsh.BSHBlock.eval(BSHBlock.java:80)
	at bsh.BshMethod.invokeImpl(BshMethod.java:362)
	at bsh.BshMethod.invoke(BshMethod.java:258)
	at bsh.BshMethod.invoke(BshMethod.java:186)
	at org.gjt.sp.jedit.BeanShell.runCachedBlock(BeanShell.java:509)
	at org.gjt.sp.jedit.BeanShellAction.invoke(BeanShellAction.java:76)
	at org.gjt.sp.jedit.gui.InputHandler.invokeAction(InputHandler.java:416)
	at org.gjt.sp.jedit.gui.InputHandler.invokeAction(InputHandler.java:382)
	at org.gjt.sp.jedit.gui.DefaultInputHandler.handleKey(DefaultInputHandler.java:373)
	at org.gjt.sp.jedit.input.AbstractInputHandler.processKeyEventKeyStrokeHandling(AbstractInputHandler.java:116)
	at org.gjt.sp.jedit.gui.InputHandler.processKeyEvent(InputHandler.java:185)
	at org.gjt.sp.jedit.textarea.TextArea.processKeyEvent(TextArea.java:4556)
	at java.awt.Component.processEvent(Unknown Source)
	at java.awt.Container.processEvent(Unknown Source)
	at java.awt.Component.dispatchEventImpl(Unknown Source)
	at java.awt.Container.dispatchEventImpl(Unknown Source)
	at java.awt.Component.dispatchEvent(Unknown Source)
	at java.awt.KeyboardFocusManager.redispatchEvent(Unknown Source)
	at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(Unknown Source)
	at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(Unknown Source)
	at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(Unknown Source)
	at java.awt.DefaultKeyboardFocusManager.dispatchEvent(Unknown Source)
	at java.awt.Component.dispatchEventImpl(Unknown Source)
	at java.awt.Container.dispatchEventImpl(Unknown Source)
	at java.awt.Window.dispatchEventImpl(Unknown Source)
	at java.awt.Component.dispatchEvent(Unknown Source)
	at java.awt.EventQueue.dispatchEvent(Unknown Source)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.run(Unknown Source)


----------------------------------------------------------------------

>Comment By: Alan Ezust (ezust)
Date: 2007-07-31 13:10

Message:
Logged In: YES 
user_id=935841
Originator: NO

I can't reproduce this. Can you try with xerces plugin 2.9.0?


----------------------------------------------------------------------

Comment By: Alan Ezust (ezust)
Date: 2007-07-12 09:30

Message:
Logged In: YES 
user_id=935841
Originator: NO

It looks like it's using xml.Resolver, a new class I haven't fully tested
or started using yet.
It could use CatalogManager instead, but that relies on an old library I'd
like to phase out one of these days.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=1735797&group_id=588

Bugs item #1665225, was opened at 2007-02-21 05:52
Message generated for change (Settings changed) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1665225&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: editor core
Group: normal bug
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Marc DENTY (mdenty)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Editing files with 100000+ character lines is impossible

Initial Comment:
Hi,

When you edit a MySQL dump (~2600 lines / 13.8 Mo), jEdit freeze with 100% CPU.
I think this is due to very long lines (1 insert statement per table).

This is very annoying and I must use an other text editor.

--Marc

----------------------------------------------------------------------

Comment By: Alan Ezust (ezust)
Date: 2007-07-31 12:10

Message:
Logged In: YES 
user_id=935841
Originator: NO

Are you using "soft", "hard" or no line wrap? I bet that for soft wrap, it
would perform quite badly, but perhaps if you are not wrapping lines, it
won't need to do as much work... not that you'd want to use the horizontal
scrollbar to see a 1000000 character line, but this could narrow down the
problem. I'm changing the subject line to be more descriptive.


----------------------------------------------------------------------

Comment By: Marc DENTY (mdenty)
Date: 2007-07-31 00:22

Message:
Logged In: YES 
user_id=84736
Originator: YES

Hi,

This does not change anything since it seems to be caused by very long
lines (1000000 chars).

--Marc


----------------------------------------------------------------------

Comment By: Matthieu Casanova (kpouer)
Date: 2007-07-30 12:25

Message:
Logged In: YES 
user_id=285591
Originator: NO

Hi I opened bigger files, could you try to open such file with the text
edit mode ? (maybe rename the file so it doesn't match any glob in the
catalog)

----------------------------------------------------------------------

Comment By: Marcelo Vanzin (vanza)
Date: 2007-06-14 22:06

Message:
Logged In: YES 
user_id=75113
Originator: NO

This doesn't really need to be that severe. It's a limitation of the
current code.

I started a new branch to try to minimize copying of strings, and editing
files with long lines is MUCH MUCH faster with the current code in that
branch. The code doesn't work 100% correctly yet, though (so don't try it
at home!), and I haven't had much time to play with it.

----------------------------------------------------------------------

Comment By: Marc DENTY (mdenty)
Date: 2007-05-14 08:58

Message:
Logged In: YES 
user_id=84736
Originator: YES

It's difficult to say since Jedit is frozen after the bug triggers, but
JEdit eats 100% of one CPU.
Here is the stack trace given by jconsole : 
Name: AWT-EventQueue-0
State: RUNNABLE
Total blocked: 133 686  Total waited: 766 480

Stack trace: 
org.gjt.sp.jedit.TextUtilities.getTokenAtOffset(TextUtilities.java:73)
org.gjt.sp.jedit.TextUtilities.findMatchingBracket(TextUtilities.java:207)
org.gjt.sp.jedit.textarea.StructureMatcher$BracketMatcher.getMatch(StructureMatcher.java:70)
org.gjt.sp.jedit.textarea.TextArea.updateStructureHighlight(TextArea.java:5510)
org.gjt.sp.jedit.textarea.TextArea.access$300(TextArea.java:65)
org.gjt.sp.jedit.textarea.TextArea$1.actionPerformed(TextArea.java:6042)
javax.swing.Timer.fireActionPerformed(Timer.java:271)
javax.swing.Timer$DoPostEvent.run(Timer.java:201)
java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
java.awt.EventDispatchThread.run(EventDispatchThread.java:121)

Hope this help,

--Marc

----------------------------------------------------------------------

Comment By: Matthieu Casanova (kpouer)
Date: 2007-05-14 08:33

Message:
Logged In: YES 
user_id=285591
Originator: NO

Do you have an OutOfMemoryError in the activity log ?

----------------------------------------------------------------------

Comment By: Marc DENTY (mdenty)
Date: 2007-02-21 06:09

Message:
Logged In: YES 
user_id=84736
Originator: YES

This test was done under jEdit 4.3pre9

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1665225&group_id=588

Bugs item #1665225, was opened at 2007-02-21 05:52
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1665225&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: editor core
Group: normal bug
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Marc DENTY (mdenty)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Editing files with 1000000+ character lines is impossible

Initial Comment:
Hi,

When you edit a MySQL dump (~2600 lines / 13.8 Mo), jEdit freeze with 100% CPU.
I think this is due to very long lines (1 insert statement per table).

This is very annoying and I must use an other text editor.

--Marc

----------------------------------------------------------------------

>Comment By: Alan Ezust (ezust)
Date: 2007-07-31 12:10

Message:
Logged In: YES 
user_id=935841
Originator: NO

Are you using "soft", "hard" or no line wrap? I bet that for soft wrap, it
would perform quite badly, but perhaps if you are not wrapping lines, it
won't need to do as much work... not that you'd want to use the horizontal
scrollbar to see a 1000000 character line, but this could narrow down the
problem. I'm changing the subject line to be more descriptive.


----------------------------------------------------------------------

Comment By: Marc DENTY (mdenty)
Date: 2007-07-31 00:22

Message:
Logged In: YES 
user_id=84736
Originator: YES

Hi,

This does not change anything since it seems to be caused by very long
lines (1000000 chars).

--Marc


----------------------------------------------------------------------

Comment By: Matthieu Casanova (kpouer)
Date: 2007-07-30 12:25

Message:
Logged In: YES 
user_id=285591
Originator: NO

Hi I opened bigger files, could you try to open such file with the text
edit mode ? (maybe rename the file so it doesn't match any glob in the
catalog)

----------------------------------------------------------------------

Comment By: Marcelo Vanzin (vanza)
Date: 2007-06-14 22:06

Message:
Logged In: YES 
user_id=75113
Originator: NO

This doesn't really need to be that severe. It's a limitation of the
current code.

I started a new branch to try to minimize copying of strings, and editing
files with long lines is MUCH MUCH faster with the current code in that
branch. The code doesn't work 100% correctly yet, though (so don't try it
at home!), and I haven't had much time to play with it.

----------------------------------------------------------------------

Comment By: Marc DENTY (mdenty)
Date: 2007-05-14 08:58

Message:
Logged In: YES 
user_id=84736
Originator: YES

It's difficult to say since Jedit is frozen after the bug triggers, but
JEdit eats 100% of one CPU.
Here is the stack trace given by jconsole : 
Name: AWT-EventQueue-0
State: RUNNABLE
Total blocked: 133 686  Total waited: 766 480

Stack trace: 
org.gjt.sp.jedit.TextUtilities.getTokenAtOffset(TextUtilities.java:73)
org.gjt.sp.jedit.TextUtilities.findMatchingBracket(TextUtilities.java:207)
org.gjt.sp.jedit.textarea.StructureMatcher$BracketMatcher.getMatch(StructureMatcher.java:70)
org.gjt.sp.jedit.textarea.TextArea.updateStructureHighlight(TextArea.java:5510)
org.gjt.sp.jedit.textarea.TextArea.access$300(TextArea.java:65)
org.gjt.sp.jedit.textarea.TextArea$1.actionPerformed(TextArea.java:6042)
javax.swing.Timer.fireActionPerformed(Timer.java:271)
javax.swing.Timer$DoPostEvent.run(Timer.java:201)
java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
java.awt.EventDispatchThread.run(EventDispatchThread.java:121)

Hope this help,

--Marc

----------------------------------------------------------------------

Comment By: Matthieu Casanova (kpouer)
Date: 2007-05-14 08:33

Message:
Logged In: YES 
user_id=285591
Originator: NO

Do you have an OutOfMemoryError in the activity log ?

----------------------------------------------------------------------

Comment By: Marc DENTY (mdenty)
Date: 2007-02-21 06:09

Message:
Logged In: YES 
user_id=84736
Originator: YES

This test was done under jEdit 4.3pre9

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1665225&group_id=588

Plugin Bugs item #1764455, was opened at 2007-07-31 14:08
Message generated for change (Comment added) made by bgolding
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=1764455&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ben Golding (bgolding)
Assigned to: Nobody/Anonymous (nobody)
Summary: Console bug: some Perl errors do not appear in ErrorList

Initial Comment:
13:27:32 [message] Log: java.version=1.6.0
13:27:32 [message] Log: java.vm.version=1.6.0-b105
13:27:32 [message] Log: java.runtime.version=1.6.0-b105
----------------------------------------------------
jEdit 4.3pre10, Windows XP
Reproduced also on jEdit 4.3pre9, Redhat Linux
----------------------------------------------------
Plugins:
Console 4.3.3
ErrorList 1.5
----------------------------------------------------
This is perl, v5.8.8 built for MSWin32-x86-multi-thread
(with 33 registered patches, see perl -V for more detail)

Copyright 1987-2006, Larry Wall

Binary build 819 [267479] provided by ActiveState http://www.ActiveState.com
Built Aug 29 2006 12:42:41
====================================================
1. Run the attached example by typing "jedit_err.pl" in the Console.
2. The first error (Can't find string terminator) appears correctly in the error list.
3. Fix the error by adding " after world.
4. Run again.
5. The second error (Not enough arguments) does not appear in the error list, and is not highlighted in red in the Console.

See Plugin Options --> Console --> Error Patterns. The pattern

(.+) at ([^<>]+) line (\d+)(.|, (.+))

looks correct to me, so the cause is a mystery.

----------------------------------------------------------------------

>Comment By: Ben Golding (bgolding)
Date: 2007-07-31 16:51

Message:
Logged In: YES 
user_id=1857456
Originator: YES

Of course, you are right about \. not . (should have spotted that myself)
and the fix works for me :-)

Still, the original "buggy" pattern does match (although it does not match
the entire line). Also
   ^(.+) at ([^<>]+) line (\d+)(.|, (.+))$
does match. So I guess Console is doing something strange here, like
checking the start and end positions are 0 and end of string respectively.
It would be nice to fix this but not essential...

Thanks for your help, Ben

----------------------------------------------------------------------

Comment By: Shlomy Reinstein (shlomy)
Date: 2007-07-31 16:36

Message:
Logged In: YES 
user_id=1477607
Originator: NO

As far as I understand, the console is okay, it's the pattern that is
wrong. Note that "." in a regexp matches any non-newline, so the "." after
the line number should be "\.":
(.+) at ([^<>]+) line (\d+)(\.|, (.+))

And with this change, it works fine. Without this change, the pattern
matching fails because it picks the first option (".") that matches the
following character, but the line hasn't terminated yet so the entire match
fails. Please correct me if I'm wrong.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=1764455&group_id=588

Plugin Bugs item #1764455, was opened at 2007-07-31 16:08
Message generated for change (Comment added) made by shlomy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=1764455&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ben Golding (bgolding)
Assigned to: Nobody/Anonymous (nobody)
Summary: Console bug: some Perl errors do not appear in ErrorList

Initial Comment:
13:27:32 [message] Log: java.version=1.6.0
13:27:32 [message] Log: java.vm.version=1.6.0-b105
13:27:32 [message] Log: java.runtime.version=1.6.0-b105
----------------------------------------------------
jEdit 4.3pre10, Windows XP
Reproduced also on jEdit 4.3pre9, Redhat Linux
----------------------------------------------------
Plugins:
Console 4.3.3
ErrorList 1.5
----------------------------------------------------
This is perl, v5.8.8 built for MSWin32-x86-multi-thread
(with 33 registered patches, see perl -V for more detail)

Copyright 1987-2006, Larry Wall

Binary build 819 [267479] provided by ActiveState http://www.ActiveState.com
Built Aug 29 2006 12:42:41
====================================================
1. Run the attached example by typing "jedit_err.pl" in the Console.
2. The first error (Can't find string terminator) appears correctly in the error list.
3. Fix the error by adding " after world.
4. Run again.
5. The second error (Not enough arguments) does not appear in the error list, and is not highlighted in red in the Console.

See Plugin Options --> Console --> Error Patterns. The pattern

(.+) at ([^<>]+) line (\d+)(.|, (.+))

looks correct to me, so the cause is a mystery.

----------------------------------------------------------------------

>Comment By: Shlomy Reinstein (shlomy)
Date: 2007-07-31 18:36

Message:
Logged In: YES 
user_id=1477607
Originator: NO

As far as I understand, the console is okay, it's the pattern that is
wrong. Note that "." in a regexp matches any non-newline, so the "." after
the line number should be "\.":
(.+) at ([^<>]+) line (\d+)(\.|, (.+))

And with this change, it works fine. Without this change, the pattern
matching fails because it picks the first option (".") that matches the
following character, but the line hasn't terminated yet so the entire match
fails. Please correct me if I'm wrong.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=1764455&group_id=588

Bugs item #1764473, was opened at 2007-07-31 08:13
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1764473&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: editor core
Group: minor bug
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Darien Brown (unidyne)
Assigned to: Nobody/Anonymous (nobody)
Summary: Dialogs Appear Off Screen

Initial Comment:
This may be related to the bug reported in #659223.

On Windows, JEdit may display dialog boxes including Open File, Save, Print, and Search off screen. I have been able to duplicate this behaviour on two computers.

I have two monitors on the computer and open JEdit on the second monitor. If I close JEdit and later log into my computer via Terminal Services and use JEdit, everything appears to still work fine. If I then return to my computer and use JEdit on two monitors locally, all dialogs will be off-screen. Closing JEdit and reopening it does not fix the problem. I am not running JEdit server.

Logging out of the machine completely and logging back in will occasionally fix the issue. I suggest implementing a check on the dialog coordinates to fix this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1764473&group_id=588

Plugin Bugs item #1764455, was opened at 2007-07-31 14:08
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=1764455&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ben Golding (bgolding)
Assigned to: Nobody/Anonymous (nobody)
Summary: Console bug: some Perl errors do not appear in ErrorList

Initial Comment:
13:27:32 [message] Log: java.version=1.6.0
13:27:32 [message] Log: java.vm.version=1.6.0-b105
13:27:32 [message] Log: java.runtime.version=1.6.0-b105
----------------------------------------------------
jEdit 4.3pre10, Windows XP
Reproduced also on jEdit 4.3pre9, Redhat Linux
----------------------------------------------------
Plugins:
Console 4.3.3
ErrorList 1.5
----------------------------------------------------
This is perl, v5.8.8 built for MSWin32-x86-multi-thread
(with 33 registered patches, see perl -V for more detail)

Copyright 1987-2006, Larry Wall

Binary build 819 [267479] provided by ActiveState http://www.ActiveState.com
Built Aug 29 2006 12:42:41
====================================================
1. Run the attached example by typing "jedit_err.pl" in the Console.
2. The first error (Can't find string terminator) appears correctly in the error list.
3. Fix the error by adding " after world.
4. Run again.
5. The second error (Not enough arguments) does not appear in the error list, and is not highlighted in red in the Console.

See Plugin Options --> Console --> Error Patterns. The pattern

(.+) at ([^<>]+) line (\d+)(.|, (.+))

looks correct to me, so the cause is a mystery.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=1764455&group_id=588

Plugin Bugs item #1764242, was opened at 2007-07-31 10:45
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=1764242&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matthieu Casanova (kpouer)
Assigned to: Nobody/Anonymous (nobody)
Summary: SQL 1.06 causes an exception ?

Initial Comment:
Hi, I'm not sure the cause is SQL but this happens when I  execute the selection as query :

10:44:12 [error] AWT-EventQueue-0: Exception in thread "AWT-EventQueue-0" 
10:44:12 [error] AWT-EventQueue-0: java.lang.IndexOutOfBoundsException: bitIndex < 0: -1
10:44:12 [error] AWT-EventQueue-0:  at java.util.BitSet.get(BitSet.java:441)
10:44:12 [error] AWT-EventQueue-0:  at javax.swing.DefaultListSelectionModel.insertIndexInterval(DefaultListSelectionModel.java:592)
10:44:12 [error] AWT-EventQueue-0:  at javax.swing.plaf.basic.BasicListUI$Handler.intervalAdded(BasicListUI.java:2558)
10:44:12 [error] AWT-EventQueue-0:  at org.gjt.sp.util.Log$LogListModel.fireIntervalAdded(Log.java:444)
10:44:12 [error] AWT-EventQueue-0:  at org.gjt.sp.util.Log$LogListModel.access$400(Log.java:434)
10:44:12 [error] AWT-EventQueue-0:  at org.gjt.sp.util.Log$LogListModel$1.run(Log.java:516)
10:44:12 [error] AWT-EventQueue-0:  at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
10:44:12 [error] AWT-EventQueue-0:  at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
10:44:12 [error] AWT-EventQueue-0:  at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
10:44:12 [error] AWT-EventQueue-0:  at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
10:44:12 [error] AWT-EventQueue-0:  at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
10:44:12 [error] AWT-EventQueue-0:  at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
10:44:12 [error] AWT-EventQueue-0:  at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
10:44:12 [error] AWT-EventQueue-0:  at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=1764242&group_id=588

Bugs item #1732278, was opened at 2007-06-06 18:19
Message generated for change (Comment added) made by haraldko
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1732278&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: installer
Group: minor bug
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Elliotte Rusty Harold (elharo)
Assigned to: Nobody/Anonymous (nobody)
Summary: GPL does not require agreement

Initial Comment:
The license agreement screen in the installer is unnecessary. You are not required to accept the GPL in order to install or use a GPL-covered program. As the GPl itself states:


You are not required to accept this License, since you have not
signed it.  However, nothing else grants you permission to modify or
distribute the Program or its derivative works.  These actions are
prohibited by law if you do not accept this License.  Therefore, by
modifying or distributing the Program (or any work based on the
Program), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Program or works based on it.


It is only the normally prohibited act of redistributing the program that requires acceptance of the license agreement, and that acceptance is indicated merely by performing such an act. The clickthrough license screen should be removed.


----------------------------------------------------------------------

Comment By: Harald Korneliussen (haraldko)
Date: 2007-07-31 08:00

Message:
Logged In: YES 
user_id=1781933
Originator: NO

How about letting it stand, but let the reject button work just as fine,
possibly with a warning that you are not allowed to redistribute? :-P

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1732278&group_id=588

Bugs item #1741363, was opened at 2007-06-22 09:00
Message generated for change (Comment added) made by haraldko
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1741363&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: documentation
Group: minor bug
Status: Open
Resolution: None
Priority: 1
Private: No
Submitted By: Harald Korneliussen (haraldko)
Assigned to: Nobody/Anonymous (nobody)
Summary: Clicking on link in API reference (in help) causes exception

Initial Comment:
If you open JEdit help, go to the API reference and click on "frames" in the resulting html page, you get the following popup:

The file file:/ ...path to jEdit /doc/api/index.html?overview-summary.html
could not be loaded due to an I/O error.
(java.io.FileNotFoundException: ... path to jEdit\doc\api\index.html?overview-summary.html (File name, folder name or volume syntax is wrong))

Not a big deal, just cosmetic, really, but if frames don't work in the embedded browser, we may want to change the doclet to leave out that link. 

----------------------------------------------------------------------

>Comment By: Harald Korneliussen (haraldko)
Date: 2007-07-31 07:54

Message:
Logged In: YES 
user_id=1781933
Originator: YES

I updated, and the bug is still there in pre10 on Windows, after install
using the java-based installer. It seems to me that the problem is with
windows path names and the ?-frame syntax somehow. Possibly with the
windows JRE?

----------------------------------------------------------------------

Comment By: Harald Korneliussen (haraldko)
Date: 2007-07-31 07:41

Message:
Logged In: YES 
user_id=1781933
Originator: YES

I see that it works fine on Linux, both pre9 and pre10, but it's still
present on windows pre9. I'll upgrade there and see if that fixes it.

----------------------------------------------------------------------

Comment By: Shlomy Reinstein (shlomy)
Date: 2007-07-31 06:42

Message:
Logged In: YES 
user_id=1477607
Originator: NO

Works fine for me with both 4.3pre10 and the development version from SVN.
Can you try with 4.3pre10? Maybe it's been fixed already or it might be a
problem with the installation, perhaps for some reason files weren't copied
to the installation directory.


----------------------------------------------------------------------

Comment By: Harald Korneliussen (haraldko)
Date: 2007-06-22 09:03

Message:
Logged In: YES 
user_id=1781933
Originator: YES

Oh, and I forgot to mention the version. It's 4.3pre9, using Sun's
1.6.0_01

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1741363&group_id=588

Bugs item #1741363, was opened at 2007-06-22 09:00
Message generated for change (Comment added) made by haraldko
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1741363&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: documentation
Group: minor bug
Status: Open
Resolution: None
Priority: 1
Private: No
Submitted By: Harald Korneliussen (haraldko)
Assigned to: Nobody/Anonymous (nobody)
Summary: Clicking on link in API reference (in help) causes exception

Initial Comment:
If you open JEdit help, go to the API reference and click on "frames" in the resulting html page, you get the following popup:

The file file:/ ...path to jEdit /doc/api/index.html?overview-summary.html
could not be loaded due to an I/O error.
(java.io.FileNotFoundException: ... path to jEdit\doc\api\index.html?overview-summary.html (File name, folder name or volume syntax is wrong))

Not a big deal, just cosmetic, really, but if frames don't work in the embedded browser, we may want to change the doclet to leave out that link. 

----------------------------------------------------------------------

>Comment By: Harald Korneliussen (haraldko)
Date: 2007-07-31 07:41

Message:
Logged In: YES 
user_id=1781933
Originator: YES

I see that it works fine on Linux, both pre9 and pre10, but it's still
present on windows pre9. I'll upgrade there and see if that fixes it.

----------------------------------------------------------------------

Comment By: Shlomy Reinstein (shlomy)
Date: 2007-07-31 06:42

Message:
Logged In: YES 
user_id=1477607
Originator: NO

Works fine for me with both 4.3pre10 and the development version from SVN.
Can you try with 4.3pre10? Maybe it's been fixed already or it might be a
problem with the installation, perhaps for some reason files weren't copied
to the installation directory.


----------------------------------------------------------------------

Comment By: Harald Korneliussen (haraldko)
Date: 2007-06-22 09:03

Message:
Logged In: YES 
user_id=1781933
Originator: YES

Oh, and I forgot to mention the version. It's 4.3pre9, using Sun's
1.6.0_01

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1741363&group_id=588

Bugs item #1665225, was opened at 2007-02-21 14:52
Message generated for change (Comment added) made by mdenty
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1665225&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: editor core
Group: normal bug
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Marc DENTY (mdenty)
Assigned to: Nobody/Anonymous (nobody)
Summary: Editing MySQL dumps is impossible.

Initial Comment:
Hi,

When you edit a MySQL dump (~2600 lines / 13.8 Mo), jEdit freeze with 100% CPU.
I think this is due to very long lines (1 insert statement per table).

This is very annoying and I must use an other text editor.

--Marc

----------------------------------------------------------------------

>Comment By: Marc DENTY (mdenty)
Date: 2007-07-31 09:22

Message:
Logged In: YES 
user_id=84736
Originator: YES

Hi,

This does not change anything since it seems to be caused by very long
lines (1000000 chars).

--Marc


----------------------------------------------------------------------

Comment By: Matthieu Casanova (kpouer)
Date: 2007-07-30 21:25

Message:
Logged In: YES 
user_id=285591
Originator: NO

Hi I opened bigger files, could you try to open such file with the text
edit mode ? (maybe rename the file so it doesn't match any glob in the
catalog)

----------------------------------------------------------------------

Comment By: Marcelo Vanzin (vanza)
Date: 2007-06-15 07:06

Message:
Logged In: YES 
user_id=75113
Originator: NO

This doesn't really need to be that severe. It's a limitation of the
current code.

I started a new branch to try to minimize copying of strings, and editing
files with long lines is MUCH MUCH faster with the current code in that
branch. The code doesn't work 100% correctly yet, though (so don't try it
at home!), and I haven't had much time to play with it.

----------------------------------------------------------------------

Comment By: Marc DENTY (mdenty)
Date: 2007-05-14 17:58

Message:
Logged In: YES 
user_id=84736
Originator: YES

It's difficult to say since Jedit is frozen after the bug triggers, but
JEdit eats 100% of one CPU.
Here is the stack trace given by jconsole : 
Name: AWT-EventQueue-0
State: RUNNABLE
Total blocked: 133 686  Total waited: 766 480

Stack trace: 
org.gjt.sp.jedit.TextUtilities.getTokenAtOffset(TextUtilities.java:73)
org.gjt.sp.jedit.TextUtilities.findMatchingBracket(TextUtilities.java:207)
org.gjt.sp.jedit.textarea.StructureMatcher$BracketMatcher.getMatch(StructureMatcher.java:70)
org.gjt.sp.jedit.textarea.TextArea.updateStructureHighlight(TextArea.java:5510)
org.gjt.sp.jedit.textarea.TextArea.access$300(TextArea.java:65)
org.gjt.sp.jedit.textarea.TextArea$1.actionPerformed(TextArea.java:6042)
javax.swing.Timer.fireActionPerformed(Timer.java:271)
javax.swing.Timer$DoPostEvent.run(Timer.java:201)
java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
java.awt.EventDispatchThread.run(EventDispatchThread.java:121)

Hope this help,

--Marc

----------------------------------------------------------------------

Comment By: Matthieu Casanova (kpouer)
Date: 2007-05-14 17:33

Message:
Logged In: YES 
user_id=285591
Originator: NO

Do you have an OutOfMemoryError in the activity log ?

----------------------------------------------------------------------

Comment By: Marc DENTY (mdenty)
Date: 2007-02-21 15:09

Message:
Logged In: YES 
user_id=84736
Originator: YES

This test was done under jEdit 4.3pre9

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1665225&group_id=588

Bugs item #1691638, was opened at 2007-03-30 23:07
Message generated for change (Comment added) made by kpouer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1691638&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: normal bug
>Status: Open
Resolution: None
>Priority: 3
Private: No
Submitted By: Sebastian Lisken (sebastianlisken)
>Assigned to: Kazutoshi Satoda (k_satoda)
Summary: change history file (and others?) to UTF

Initial Comment:
If you supply characters in search/replace that are not covered in your system's default encoding (e.g. by pasting into the dialogue from Windows' Character Map utility), the next time you start jedit and try to use the search/replace history, those characters appear as question marks. This is at least true in my Western Windows, where the history file is written using Cp1252. The problem would therefore surely apply to anything that's in the history, not just search/replace.

The history should be written and read in some UTF encoding on all systems. I see in the release notes for 4.2pre14 that this same change has already been made for the abbreviations file, now in UTF8. Maybe it's time to stop and think of all "state" or "settings" files written by jedit and determine which ones should get that same treatment.


----------------------------------------------------------------------

>Comment By: Matthieu Casanova (kpouer)
Date: 2007-07-31 09:08

Message:
Logged In: YES 
user_id=285591
Originator: NO

As Kazutoshi said, there are HistoryTextFields everywhere in jEdit that
might have the same bug so I reopen it

----------------------------------------------------------------------

Comment By: Matthieu Casanova (kpouer)
Date: 2007-07-30 21:06

Message:
Logged In: YES 
user_id=285591
Originator: NO

Hi, what version do you use ?
the 4.3pre10 doesn't have history for search and replace anymore I think
so this bug could be obsolete

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1691638&group_id=588

2007/7/31, Kazutoshi Satoda <k_s...@f2...>:
> What did let you think so? I can't see any change about history for
> search/replace in recent releases.
>
> I found that JEditHistoryModelSaver uses the system default encoding on
> the "history" file in the settings directory. Switching the encoding to
> "UTF-8" seems to fix this bug.
>
> Please reopen the bug if you confirm this.
>
> I have an idea to minimize possible mismatch of the encoding at loading
> old "history" files; first try to load with "UTF-8" and fallback to the
> system default encoding if an encoding error is thrown.
>
> It's fine to assign me to the bug.

Hi, you're right I forgot the others history textfields. For the
search dialog, there were history textfields in 4.2 if I remember well
but they are replaced by text area now.
I reopen the bug and assign it to you.
And what do you think of this one ?
http://sourceforge.net/tracker/index.php?func=detail&aid=1729313&group_id=588&atid=100588
I think the fallback encoding would be a good fix for that, but maybe
you have another idea ?

Matthieu