jedit-devel Mailing List for jEdit

Plugin Patches item #1854413, was opened at 2007-12-19 12:56
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997937&aid=1854413&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
Priority: 5
Private: No
Submitted By: David Bernard (dwayneb)
Assigned to: Alan Ezust (ezust)
Summary: [Console] fix bug in capture of extra line for error

Initial Comment:
CommandOutputParser add Error just after creation, so extraMessages aren't injected into ErrorList (doc set explicitly that adding extra must be done before adding Error).



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

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

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

right you are... This was the problem:
===================================================================
--- plugins/Console/trunk/console/StreamThread.java     2007-12-31
20:09:58 UTC (rev 11494)
+++ plugins/Console/trunk/console/StreamThread.java     2007-12-31
21:51:25 UTC (rev 11495)
@@ -175,6 +175,7 @@
               }
               finally
               {
+                       copt.finishErrorParsing();
                       try
                       {
                               in.close();

Committed revision 11495. Thanks again --alan


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

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

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

right you are... This was the problem:
===================================================================
--- plugins/Console/trunk/console/StreamThread.java     2007-12-31
20:09:58 UTC (rev 11494)
+++ plugins/Console/trunk/console/StreamThread.java     2007-12-31
21:51:25 UTC (rev 11495)
@@ -175,6 +175,7 @@
               }
               finally
               {
+                       copt.finishErrorParsing();
                       try
                       {
                               in.close();

Committed revision 11495. Thanks again --alan


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

Comment By: David Bernard (dwayneb)
Date: 2007-12-31 13:14

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

You're right, I didn't check with the ConsoleOutput of shell system.
I only test with my custom ConsoleOutput, that call "finishErrorParsing()"
at the end (in this case the last error is displayed). I though that is the
normal way.

What is the best place to call finishErrorParsing() (I'm not the author of
the method, it already exists) ?

Thanks

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

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

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

I'm testing this patch and it's not quite right yet... I find that if the
last (or only) error is a single line error message,
it never gets added to ErrorList.


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

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

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

I'm testing this patch and it's not quite right yet... I find that if the
last (or only) error is a single line error message,
it never gets added to ErrorList.


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

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

Plugin Patches item #1854413, was opened at 2007-12-19 12:56
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997937&aid=1854413&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
Priority: 5
Private: No
Submitted By: David Bernard (dwayneb)
Assigned to: Alan Ezust (ezust)
Summary: [Console] fix bug in capture of extra line for error

Initial Comment:
CommandOutputParser add Error just after creation, so extraMessages aren't injected into ErrorList (doc set explicitly that adding extra must be done before adding Error).



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

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

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

right you are... This was the problem:
===================================================================
--- plugins/Console/trunk/console/StreamThread.java     2007-12-31
20:09:58 UTC (rev 11494)
+++ plugins/Console/trunk/console/StreamThread.java     2007-12-31
21:51:25 UTC (rev 11495)
@@ -175,6 +175,7 @@
               }
               finally
               {
+                       copt.finishErrorParsing();
                       try
                       {
                               in.close();

Committed revision 11495. Thanks again --alan


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

Comment By: David Bernard (dwayneb)
Date: 2007-12-31 13:14

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

You're right, I didn't check with the ConsoleOutput of shell system.
I only test with my custom ConsoleOutput, that call "finishErrorParsing()"
at the end (in this case the last error is displayed). I though that is the
normal way.

What is the best place to call finishErrorParsing() (I'm not the author of
the method, it already exists) ?

Thanks

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

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

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

I'm testing this patch and it's not quite right yet... I find that if the
last (or only) error is a single line error message,
it never gets added to ErrorList.


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

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

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

I'm testing this patch and it's not quite right yet... I find that if the
last (or only) error is a single line error message,
it never gets added to ErrorList.


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

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

Plugin Patches item #1854413, was opened at 2007-12-19 21:56
Message generated for change (Comment added) made by dwayneb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997937&aid=1854413&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
Priority: 5
Private: No
Submitted By: David Bernard (dwayneb)
Assigned to: Alan Ezust (ezust)
Summary: [Console] fix bug in capture of extra line for error

Initial Comment:
CommandOutputParser add Error just after creation, so extraMessages aren't injected into ErrorList (doc set explicitly that adding extra must be done before adding Error).



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

Comment By: David Bernard (dwayneb)
Date: 2007-12-31 22:14

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

You're right, I didn't check with the ConsoleOutput of shell system.
I only test with my custom ConsoleOutput, that call "finishErrorParsing()"
at the end (in this case the last error is displayed). I though that is the
normal way.

What is the best place to call finishErrorParsing() (I'm not the author of
the method, it already exists) ?

Thanks

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

Comment By: Alan Ezust (ezust)
Date: 2007-12-31 21:17

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

I'm testing this patch and it's not quite right yet... I find that if the
last (or only) error is a single line error message,
it never gets added to ErrorList.


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

Comment By: Alan Ezust (ezust)
Date: 2007-12-31 21:17

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

I'm testing this patch and it's not quite right yet... I find that if the
last (or only) error is a single line error message,
it never gets added to ErrorList.


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

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

Plugin Patches item #1854413, was opened at 2007-12-19 12:56
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997937&aid=1854413&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
Priority: 5
Private: No
Submitted By: David Bernard (dwayneb)
Assigned to: Alan Ezust (ezust)
Summary: [Console] fix bug in capture of extra line for error

Initial Comment:
CommandOutputParser add Error just after creation, so extraMessages aren't injected into ErrorList (doc set explicitly that adding extra must be done before adding Error).



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

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

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

I'm testing this patch and it's not quite right yet... I find that if the
last (or only) error is a single line error message,
it never gets added to ErrorList.


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

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

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

I'm testing this patch and it's not quite right yet... I find that if the
last (or only) error is a single line error message,
it never gets added to ErrorList.


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

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

Plugin Patches item #1854413, was opened at 2007-12-19 12:56
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997937&aid=1854413&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
Priority: 5
Private: No
Submitted By: David Bernard (dwayneb)
Assigned to: Alan Ezust (ezust)
Summary: [Console] fix bug in capture of extra line for error

Initial Comment:
CommandOutputParser add Error just after creation, so extraMessages aren't injected into ErrorList (doc set explicitly that adding extra must be done before adding Error).



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

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

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

I'm testing this patch and it's not quite right yet... I find that if the
last (or only) error is a single line error message,
it never gets added to ErrorList.


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

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

Plugin Patches item #1854405, was opened at 2007-12-19 12:48
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997937&aid=1854405&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
Priority: 5
Private: No
Submitted By: David Bernard (dwayneb)
Assigned to: Alan Ezust (ezust)
Summary: [ErrorList] display error.extraMessages in GutterIcon

Initial Comment:
Allow to display ExtraMessages (for multiline message) in the texteditor at the "GutterIcon", instead of the first line.


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

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

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

Committed revision 11494.
Thanks! --alan


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

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

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

Committed revision 11494.
Thanks! --alan


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

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

Plugin Patches item #1854405, was opened at 2007-12-19 12:48
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997937&aid=1854405&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
Priority: 5
Private: No
Submitted By: David Bernard (dwayneb)
Assigned to: Alan Ezust (ezust)
Summary: [ErrorList] display error.extraMessages in GutterIcon

Initial Comment:
Allow to display ExtraMessages (for multiline message) in the texteditor at the "GutterIcon", instead of the first line.


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

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

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

Committed revision 11494.
Thanks! --alan


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

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

Bugs item #1861282, was opened at 2007-12-31 01:04
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1861282&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: severe bug
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Shlomy Reinstein (shlomy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Deadlock on startup

Initial Comment:
With the jEdit trunk version, and the released version of ProjectViewer (2.9.0.0), jEdit frequently fails to start. I debugged it to find out the following flow that causes the deadlock:
1. During startup, jEdit loads the view configuration from perspective.xml, and tries to open the buffers that are specified there. Loading the buffers is done in the background, in a work thread.
2. As part of loading the perspective.xml file, jEdit tries to restore the dockable windows that were open the last time, one of them was the ProjectViewer dockable.
3. As part of the initialization of the ProjectViewer dockable, it tries to set the root node of the project tree to the last-open project. I configured ProjectViewer to automatically close & open buffers as needed when switching projects, so setting the root node of the project tree attempts to close those buffers that are loaded in the background (that were listed in perpsective.xml as "auto load"). It does that by calling "jEdit.closeBuffer(...)".
4. jEdit.closeBuffer(...) finds that the buffer is still performing an I/O request (being loaded in the background), and invokes "VFSManager.waitForRequests()". This call never returns.

I don't know the exact cause of all this, but I suspect that the jEdit.closeBuffer(...) is called from PV in the AWT thread, and I guess that the notification that the buffer is done loading is also registered to run in the AWT thread, so closeBuffer(...) blocks the AWT thread and prevents the notification to which it is waiting to actually take place.

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

>Comment By: Alan Ezust (ezust)
Date: 2007-12-31 11:37

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

Marcelo, can you help Shlomy with this? I run into this myself quite often
when testing the CtagsInterfacePlugin.

Also, I have seen this with PV 2.1.3.7 (last released PV). 2.9 is not the
last released PV.



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

Comment By: Alan Ezust (ezust)
Date: 2007-12-31 11:37

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

Marcelo, can you help Shlomy with this? I run into this myself quite often
when testing the CtagsInterfacePlugin.

Also, I have seen this with PV 2.1.3.7 (last released PV). 2.9 is not the
last released PV.



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

Comment By: Shlomy Reinstein (shlomy)
Date: 2007-12-31 01:06

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

I'm sorry I can't put exact steps to reproduce this, since this does not
always happen and I guess it requires that at least 4 files were open last
time.
Something else I don't understand is why files that are not in the last
open project are registered as "autoload" in perspective.xml, I guess
there's some problem with the PerspectiveManager / Projectviewer
synchronization.

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

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

Bugs item #1861282, was opened at 2007-12-31 01:04
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1861282&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: severe bug
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Shlomy Reinstein (shlomy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Deadlock on startup

Initial Comment:
With the jEdit trunk version, and the released version of ProjectViewer (2.9.0.0), jEdit frequently fails to start. I debugged it to find out the following flow that causes the deadlock:
1. During startup, jEdit loads the view configuration from perspective.xml, and tries to open the buffers that are specified there. Loading the buffers is done in the background, in a work thread.
2. As part of loading the perspective.xml file, jEdit tries to restore the dockable windows that were open the last time, one of them was the ProjectViewer dockable.
3. As part of the initialization of the ProjectViewer dockable, it tries to set the root node of the project tree to the last-open project. I configured ProjectViewer to automatically close & open buffers as needed when switching projects, so setting the root node of the project tree attempts to close those buffers that are loaded in the background (that were listed in perpsective.xml as "auto load"). It does that by calling "jEdit.closeBuffer(...)".
4. jEdit.closeBuffer(...) finds that the buffer is still performing an I/O request (being loaded in the background), and invokes "VFSManager.waitForRequests()". This call never returns.

I don't know the exact cause of all this, but I suspect that the jEdit.closeBuffer(...) is called from PV in the AWT thread, and I guess that the notification that the buffer is done loading is also registered to run in the AWT thread, so closeBuffer(...) blocks the AWT thread and prevents the notification to which it is waiting to actually take place.

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

>Comment By: Alan Ezust (ezust)
Date: 2007-12-31 11:37

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

Marcelo, can you help Shlomy with this? I run into this myself quite often
when testing the CtagsInterfacePlugin.

Also, I have seen this with PV 2.1.3.7 (last released PV). 2.9 is not the
last released PV.



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

Comment By: Shlomy Reinstein (shlomy)
Date: 2007-12-31 01:06

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

I'm sorry I can't put exact steps to reproduce this, since this does not
always happen and I guess it requires that at least 4 files were open last
time.
Something else I don't understand is why files that are not in the last
open project are registered as "autoload" in perspective.xml, I guess
there's some problem with the PerspectiveManager / Projectviewer
synchronization.

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

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

Bugs item #1811138, was opened at 2007-10-10 13:09
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1811138&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: George D. (scclockdr)
Assigned to: Nobody/Anonymous (nobody)
Summary: xSearch relpace field two down arrows vs one

Initial Comment:
The replace textarea sports 2 downarrows vs the one downarrow in the find textarea.

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

>Comment By: Alan Ezust (ezust)
Date: 2007-12-31 11:30

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

This looks like a bug in the org.gjt.sp.jedit.gui.HistoryTextField class,
because there is nothing in the XSearch plugin that draws those arrow
buttons. It's all handled by the HistoryTextField.

Strange that it only comes up in the XSearch plugin though.
Any ideas why this might be?





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

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

Plugin Bugs item #1759783, was opened at 2007-07-24 09:29
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=1759783&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: 5
Private: No
Submitted By: Alan Ezust (ezust)
Assigned to: Nicholas O'Leary (olearyni)
Summary: FTP plugin: should not remember bad passphrase

Initial Comment:
If I make a typo when FTP plugin is asking me for the passphrase, I get a failed auth which is what I expect, but subsequent attempts to do VFS operations there should pop up the passphrase dialog again and ask me to retry.
At the moment, I have to invoke the FTP "forget remote passwords" option, before reconnecting and re-entering my passphrase, in order to access that SFTP server.



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

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

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

Nick, I think you forgot to mark this as closed, but this seems to be
fixed now.


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

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

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

Nick, I think you forgot to mark this as closed, but this seems to be
fixed now.


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

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

Plugin Bugs item #1759783, was opened at 2007-07-24 09:29
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=1759783&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: 5
Private: No
Submitted By: Alan Ezust (ezust)
Assigned to: Nicholas O'Leary (olearyni)
Summary: FTP plugin: should not remember bad passphrase

Initial Comment:
If I make a typo when FTP plugin is asking me for the passphrase, I get a failed auth which is what I expect, but subsequent attempts to do VFS operations there should pop up the passphrase dialog again and ask me to retry.
At the moment, I have to invoke the FTP "forget remote passwords" option, before reconnecting and re-entering my passphrase, in order to access that SFTP server.



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

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

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

Nick, I think you forgot to mark this as closed, but this seems to be
fixed now.


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

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

Plugin Bugs item #1805461, was opened at 2007-10-01 01:12
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=1805461&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: Kevin Krum (mongy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Version conflict in plugin manager - JCompiler

Initial Comment:
The list of available plugins contains a version mismatch that makes it impossible to install JCompiler via the plugin manager.  The compatible version is also not listed on the plugins page on jedit.org.  To install JCompiler, I had to manually install Console 4.2.6.5 from  here:

http://sourceforge.net/project/showfiles.php?group_id=64089&package_id=67153



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

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

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

Which version of jedit are you using?

I can fix plugin central to expose the correct version for 4.2 if it is
correctly marked as a branch.

jcompiler depends on javacore, which is no longer supported in jedit 4.3.

Someone needs to update the jcompiler plugin to use javasidekick instead
of javacore, so that it can work
with jedit 4.3





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

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

Plugin Bugs item #1858936, was opened at 2007-12-27 05:53
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=1858936&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: Duplicate
Priority: 5
Private: No
Submitted By: Dion (redl0tus)
Assigned to: Alan Ezust (ezust)
Summary: No window when attempting opening remote file

Initial Comment:
When attempting to open a remote file via FTP/SFTP no file chooser window opens.  On the console this warning appears:
[warning] EditAction$Wrapper: Unknown action: vfs.browser.sftp

jEdit 4.3pre12 using Java 1.5.0_11
Ubuntu Linux 2.6.20-16-386 #2 i686 GNU/Linux



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

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

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

Re-packaged FTP 0.9.2 on plugin central.
due to missing browser.actions.xml


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

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

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

Re-packaged FTP 0.9.2 on plugin central.
due to missing browser.actions.xml


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

Comment By: Dion (redl0tus)
Date: 2007-12-28 00:05

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

Deleting the plugin and reinstalling does not help.  I used also a fresh
profile, with an empty classpath, also no difference.

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

Comment By: Matthieu Casanova (kpouer)
Date: 2007-12-27 09:45

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

This is duplicate of 1847133
You can try to delete the plugin and reinstall it, I think it is fixed now

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

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

Plugin Bugs item #1858936, was opened at 2007-12-27 05:53
Message generated for change (Settings changed) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=1858936&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: Duplicate
Priority: 5
Private: No
Submitted By: Dion (redl0tus)
>Assigned to: Alan Ezust (ezust)
Summary: No window when attempting opening remote file

Initial Comment:
When attempting to open a remote file via FTP/SFTP no file chooser window opens.  On the console this warning appears:
[warning] EditAction$Wrapper: Unknown action: vfs.browser.sftp

jEdit 4.3pre12 using Java 1.5.0_11
Ubuntu Linux 2.6.20-16-386 #2 i686 GNU/Linux



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

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

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

Re-packaged FTP 0.9.2 on plugin central.
due to missing browser.actions.xml


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

Comment By: Dion (redl0tus)
Date: 2007-12-28 00:05

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

Deleting the plugin and reinstalling does not help.  I used also a fresh
profile, with an empty classpath, also no difference.

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

Comment By: Matthieu Casanova (kpouer)
Date: 2007-12-27 09:45

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

This is duplicate of 1847133
You can try to delete the plugin and reinstall it, I think it is fixed now

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

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

Plugin Bugs item #1847133, was opened at 2007-12-08 21:26
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=1847133&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: 5
Private: No
Submitted By: liu li (pi1ot)
>Assigned to: Alan Ezust (ezust)
Summary: FTP: missing browser.actions.xml

Initial Comment:
Windows XP SP2
JRE:1.6.0_03-b05
jEdit: 4.3pre12
FTP: 0.9.2

FileBrowser -> Plugins -> FTP -> Connect to FTP Server...

13:25:54 [warning] EditAction$Wrapper: Unknown action: vfs.browser.ftp


FileBrowser -> Plugins -> FTP -> Connect to Secure FTP Server...

13:25:56 [warning] EditAction$Wrapper: Unknown action: vfs.browser.sftp




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

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

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

I just replaced the FTP 0.9.2 on plugin central.
It will still take a couple of hours for the mirrors to catch up, but it
should be fixed now.


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

Comment By: liu li (pi1ot)
Date: 2007-12-28 02:57

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

packaged with browser.actions.xml, bugfixed.
File Added: FTP.jar

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

Comment By: Dion (redl0tus)
Date: 2007-12-28 00:08

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

I also have this problem, reinstalling with a fresh profile makes no
difference.

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

Comment By: Alan Ezust (ezust)
Date: 2007-12-27 20:15

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

it's a missing browser.actions.xml actually. And it is a problem in the
currently packaged FTP 0.9.2 that is being served on plugin central.



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

Comment By: Alan Ezust (ezust)
Date: 2007-12-27 20:15

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

it's a missing browser.actions.xml actually. And it is a problem in the
currently packaged FTP 0.9.2 that is being served on plugin central.



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

Comment By: liu li (pi1ot)
Date: 2007-12-27 19:24

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

reinstall and no change, bug remain.
there is actions.xml in ftp.jar, no difference with the older version of
ftp plugin.

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

Comment By: Matthieu Casanova (kpouer)
Date: 2007-12-27 10:01

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

I think the problem was a missing actions.xml file in the jar. Can you try
to delete FTP plugin and redownload it ?

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

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

Bugs item #1262368, was opened at 2005-08-17 20:02
Message generated for change (Comment added) made by kpouer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1262368&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: plugin manager
Group: normal bug
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Björn Kautler (vampire0)
Assigned to: Nobody/Anonymous (nobody)
Summary: Libraries not deleted if Plugin is not loaded

Initial Comment:
If a plugin is not loaded and you delete it, then the
libraries shiped with that plugin remain in the
jars-directory and are not deleted.
If you e. g. have AntFarm installed, which is shipped
with  the libraries ant.jar and ant-optional.jar, then
deactivate/unload it and then delete/uninstall it, then
the two libraries are not deleted. If you delete the
Plugin while it is loaded, the libraries are deleted.

Environment:
jEdit 4.2final
Windows XP Pro SP2
Sun Java 1.5.0_04


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

>Comment By: Matthieu Casanova (kpouer)
Date: 2007-12-31 15:14

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

I think it is fixed now

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

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

Bugs item #1538715, was opened at 2006-08-11 15:56
Message generated for change (Comment added) made by kpouer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1538715&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: text area and syntax packages
Group: normal bug
>Status: Pending
>Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Björn Kautler (vampire0)
Assigned to: Nobody/Anonymous (nobody)
Summary: Action "expand-fold" works only if collapsed

Initial Comment:
Action "expand-fold" ("Expand fold fully"-menuitem) 
works only if the fold-area is collapsed, not if it 
is expanded, but subfolds are collapsed.

Sorry if this is a dupe, but I have many bugs to post 
and am too lazy to check them all for dupes 
currently. :-)

OS: Windows XP
Java Version: Sun Java 1.5.0_06-b05
jEdit Version: SVN Revision 6684


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

>Comment By: Matthieu Casanova (kpouer)
Date: 2007-12-31 14:50

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

I don't understand : this action expands fold under the caret, if it is
already expanded it should do nothing.
Or you mean that you are in an expanded fold but your caret is on a
subfold that is collapsed ?
I tried, it seems to work as expected, could you check ?

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

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

Bugs item #1694131, was opened at 2007-04-04 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=1694131&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: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: stc1 (stc1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Save as => Overwrite File => Message

Initial Comment:
1.) "Save as"
-------------
When I save a new File with "Save as" the File Browser opens.
If I choose an existing File in the Directory, the File will be overwritten, of course.
Plaese implement a Message Box, which will ask you, if you really want to overwrite the existing File.
It happened to me that I wanted to save a new File, looked around in the directories, where I want to save it,
and saw a File which I was wondering what it was and wanted to open it ... ;(


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

>Comment By: Matthieu Casanova (kpouer)
Date: 2007-12-31 14:39

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

It seems fixed, but I don't know who did it

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

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

Bugs item #1861282, was opened at 2007-12-31 11:04
Message generated for change (Comment added) made by shlomy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1861282&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: severe bug
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Shlomy Reinstein (shlomy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Deadlock on startup

Initial Comment:
With the jEdit trunk version, and the released version of ProjectViewer (2.9.0.0), jEdit frequently fails to start. I debugged it to find out the following flow that causes the deadlock:
1. During startup, jEdit loads the view configuration from perspective.xml, and tries to open the buffers that are specified there. Loading the buffers is done in the background, in a work thread.
2. As part of loading the perspective.xml file, jEdit tries to restore the dockable windows that were open the last time, one of them was the ProjectViewer dockable.
3. As part of the initialization of the ProjectViewer dockable, it tries to set the root node of the project tree to the last-open project. I configured ProjectViewer to automatically close & open buffers as needed when switching projects, so setting the root node of the project tree attempts to close those buffers that are loaded in the background (that were listed in perpsective.xml as "auto load"). It does that by calling "jEdit.closeBuffer(...)".
4. jEdit.closeBuffer(...) finds that the buffer is still performing an I/O request (being loaded in the background), and invokes "VFSManager.waitForRequests()". This call never returns.

I don't know the exact cause of all this, but I suspect that the jEdit.closeBuffer(...) is called from PV in the AWT thread, and I guess that the notification that the buffer is done loading is also registered to run in the AWT thread, so closeBuffer(...) blocks the AWT thread and prevents the notification to which it is waiting to actually take place.

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

>Comment By: Shlomy Reinstein (shlomy)
Date: 2007-12-31 11:06

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

I'm sorry I can't put exact steps to reproduce this, since this does not
always happen and I guess it requires that at least 4 files were open last
time.
Something else I don't understand is why files that are not in the last
open project are registered as "autoload" in perspective.xml, I guess
there's some problem with the PerspectiveManager / Projectviewer
synchronization.

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

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

Bugs item #1861282, was opened at 2007-12-31 11:04
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=1861282&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: severe bug
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Shlomy Reinstein (shlomy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Deadlock on startup

Initial Comment:
With the jEdit trunk version, and the released version of ProjectViewer (2.9.0.0), jEdit frequently fails to start. I debugged it to find out the following flow that causes the deadlock:
1. During startup, jEdit loads the view configuration from perspective.xml, and tries to open the buffers that are specified there. Loading the buffers is done in the background, in a work thread.
2. As part of loading the perspective.xml file, jEdit tries to restore the dockable windows that were open the last time, one of them was the ProjectViewer dockable.
3. As part of the initialization of the ProjectViewer dockable, it tries to set the root node of the project tree to the last-open project. I configured ProjectViewer to automatically close & open buffers as needed when switching projects, so setting the root node of the project tree attempts to close those buffers that are loaded in the background (that were listed in perpsective.xml as "auto load"). It does that by calling "jEdit.closeBuffer(...)".
4. jEdit.closeBuffer(...) finds that the buffer is still performing an I/O request (being loaded in the background), and invokes "VFSManager.waitForRequests()". This call never returns.

I don't know the exact cause of all this, but I suspect that the jEdit.closeBuffer(...) is called from PV in the AWT thread, and I guess that the notification that the buffer is done loading is also registered to run in the AWT thread, so closeBuffer(...) blocks the AWT thread and prevents the notification to which it is waiting to actually take place.

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

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

Bugs item #1811136, was opened at 2007-10-10 13:01
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1811136&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: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: George D. (scclockdr)
Assigned to: Nobody/Anonymous (nobody)
Summary: Dragged text to the search area drops a dup in the buffer

Initial Comment:
When dragging (Ctrl+drag) a piece of text to the find field. When it is dropped a copy of the dragged text is also dropped into the buffer at an unexpected location.
Win xp
ver 11pre win installer
xSearch vs core find


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

>Comment By: SourceForge Robot (sf-robot)
Date: 2007-12-30 19:20

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

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

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

Comment By: Matthieu Casanova (kpouer)
Date: 2007-12-16 14:15

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

Hi, I tried but I cannot reproduce your problem. What find field do you
talk about ? I tried with the search bar and the search dialog of jEdit
with 4.3pre12.


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

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

Bugs item #1721208, was opened at 2007-05-18 11:53
Message generated for change (Comment added) made by kpouer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1721208&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: keyboard / mouse
Group: normal bug
>Status: Pending
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Anka (ancad)
Assigned to: Nobody/Anonymous (nobody)
Summary: keybord not working properly

Initial Comment:
using version 4.3pre9 windows

i open an existing file and i try to write some numbers using the right side keyboard (the one that activates with numlock) and nothing appears.
If i write something else using the letter keys of a number using the the keys above the letters everything is ok.
After i wrote something, the document is sort of "activated" for the right side keyboard too and i can write numbers using that one too, but If the first thin when i open the document is write a number with the right keyboard is not working. (NUMLOCK is activated and i don;t chenge that setting during the test)

this is very strange...and in 4.2 version was working correct

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

>Comment By: Matthieu Casanova (kpouer)
Date: 2007-12-30 16:00

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

I think it is fixed in the trunk, could you try the latest sources ?

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

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

Feature Requests item #1657798, was opened at 2007-02-12 09:31
Message generated for change (Comment added) made by kpouer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350588&aid=1657798&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: plugins
Group: v4.3
>Status: Closed
>Resolution: Rejected
Priority: 5
Private: No
Submitted By: Dmitry Stropaloff (helions8)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add to release

Initial Comment:
Please

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

>Comment By: Matthieu Casanova (kpouer)
Date: 2007-12-30 15:37

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

I don't think adding macros that are so specific is a good idea. The users
of those macros can download them if they want

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

Comment By: Dmitry Stropaloff (helions8)
Date: 2007-02-12 09:34

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

Please, add to release this files (edit mode and macros). This is for Arch
Linux users.

All of this can be found on community portal:
http://community.jedit.org/?q=node/view/3444
http://community.jedit.org/?q=node/view/3443
http://community.jedit.org/?q=node/view/3442
File Added: Generate_md5_sum.bsh

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

Comment By: Dmitry Stropaloff (helions8)
Date: 2007-02-12 09:32

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

File Added: Make_arch_package.bsh

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

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

Plugin Patches item #1854405, was opened at 2007-12-19 21:48
Message generated for change (Settings changed) made by kpouer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997937&aid=1854405&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
Priority: 5
Private: No
Submitted By: David Bernard (dwayneb)
Assigned to: Alan Ezust (ezust)
Summary: [ErrorList] display error.extraMessages in GutterIcon

Initial Comment:
Allow to display ExtraMessages (for multiline message) in the texteditor at the "GutterIcon", instead of the first line.


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

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