jedit-devel Mailing List for jEdit

Plugin Bugs item #2930625, was opened at 2010-01-12 07:19
Message generated for change (Settings changed) made by daleanson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=2930625&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: nathanmickler ()
Assigned to: Dale Anson (daleanson)
Summary: FTP Bug with TaskList 2.0

Initial Comment:
I am using jEdit 4.4pre1 (same behavior with jEdit 4.4) and Tasklist 2.0.  If I use Tasklist on a local file, it works great -- but it does not work with a remote file that I am editing using the FTP plugin.

Has anybody seen a fix for this behavior?

The error messages I receive are copied below.

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

8:16:44 AM [SwingWorker-pool-23582715-thread-44] [error] SwingWorker-pool-23582715-thread-44: java.lang.IllegalArgumentException: Unsupported URI scheme
8:16:44 AM [SwingWorker-pool-23582715-thread-44] [error] SwingWorker-pool-23582715-thread-44:  at ftp.FtpAddress.<init>(FtpAddress.java:49)
8:16:44 AM [SwingWorker-pool-23582715-thread-44] [error] SwingWorker-pool-23582715-thread-44:  at ftp.FtpVFS.getFileName(FtpVFS.java:108)
8:16:44 AM [SwingWorker-pool-23582715-thread-44] [error] SwingWorker-pool-23582715-thread-44:  at org.gjt.sp.jedit.Buffer.setPath(Buffer.java:1835)
8:16:44 AM [SwingWorker-pool-23582715-thread-44] [error] SwingWorker-pool-23582715-thread-44:  at org.gjt.sp.jedit.Buffer.<init>(Buffer.java:1635)
8:16:44 AM [SwingWorker-pool-23582715-thread-44] [error] SwingWorker-pool-23582715-thread-44:  at org.gjt.sp.jedit.jEdit.openTemporary(jEdit.java:1649)
8:16:44 AM [SwingWorker-pool-23582715-thread-44] [error] SwingWorker-pool-23582715-thread-44:  at org.gjt.sp.jedit.jEdit.openTemporary(jEdit.java:1608)
8:16:44 AM [SwingWorker-pool-23582715-thread-44] [error] SwingWorker-pool-23582715-thread-44:  at tasklist.AbstractTreeTaskList$Runner.buildTreeModel(AbstractTreeTaskList.java:277)
8:16:44 AM [SwingWorker-pool-23582715-thread-44] [error] SwingWorker-pool-23582715-thread-44:  at tasklist.AbstractTreeTaskList$Runner.doInBackground(AbstractTreeTaskList.java:180)
8:16:44 AM [SwingWorker-pool-23582715-thread-44] [error] SwingWorker-pool-23582715-thread-44:  at tasklist.AbstractTreeTaskList$Runner.doInBackground(AbstractTreeTaskList.java:141)
8:16:44 AM [SwingWorker-pool-23582715-thread-44] [error] SwingWorker-pool-23582715-thread-44:  at common.swingworker.SwingWorker$1.call(SwingWorker.java:277)
8:16:44 AM [SwingWorker-pool-23582715-thread-44] [error] SwingWorker-pool-23582715-thread-44:  at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
8:16:44 AM [SwingWorker-pool-23582715-thread-44] [error] SwingWorker-pool-23582715-thread-44:  at java.util.concurrent.FutureTask.run(Unknown Source)
8:16:44 AM [SwingWorker-pool-23582715-thread-44] [error] SwingWorker-pool-23582715-thread-44:  at common.swingworker.SwingWorker.run(SwingWorker.java:316)
8:16:44 AM [SwingWorker-pool-23582715-thread-44] [error] SwingWorker-pool-23582715-thread-44:  at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
8:16:44 AM [SwingWorker-pool-23582715-thread-44] [error] SwingWorker-pool-23582715-thread-44:  at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
8:16:44 AM [SwingWorker-pool-23582715-thread-44] [error] SwingWorker-pool-23582715-thread-44:  at java.lang.Thread.run(Unknown Source)

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

Comment By: Dale Anson (daleanson)
Date: 2010-01-13 16:34

Message:
I think I have this fixed, but I'm having a little trouble testing it. 
TaskList is part of the daily build process, would you get the new version
from the url below tomorrow after the build and give it a try?

http://www.tellurianring.com/projects/jedit-daily/index.php?dir=TaskList

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

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

Plugin Bugs item #2922694, was opened at 2009-12-29 00:44
Message generated for change (Comment added) made by daleanson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=2922694&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: Shlomy Reinstein (shlomy)
Assigned to: Dale Anson (daleanson)
Summary: TaskList: Project tasks tab not working

Initial Comment:
The tab for Project Tasks says there are no tasks in the project, although I have several open buffers from the active project and the other tabs show the tasks in them.

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

>Comment By: Dale Anson (daleanson)
Date: 2010-01-31 16:40

Message:
Fixed, revision 17162.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-12-29 09:47

Message:
Yes, definitely. I noticed that sometimes it does not scan the project for
some reason. Mostly this problem happens on jEdit startup, even if a
project is active. But sometimes also switching from a group to a project
doesn't make it load the project.

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

Comment By: Dale Anson (daleanson)
Date: 2009-12-29 09:20

Message:
Just checking -- was ProjectViewer actually active and was a project active
in ProjectViewer when you saw this?  The Project Files tab is the only one
that depends on ProjectViewer, and looks for ProjectViewer plugin to be
active and for a project to be open.  If ProjectViewer is active and a
project group is selected, no tasks will appear in the Project Files tab.

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

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

Plugin Bugs item #2926776, was opened at 2010-01-06 02:53
Message generated for change (Comment added) made by daleanson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=2926776&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: Shlomy Reinstein (shlomy)
Assigned to: Dale Anson (daleanson)
Summary: TaskList: Current File tab not updated

Initial Comment:
Frequently when I change the current buffer by clicking the tab of another buffer (using BufferTabs), the "Current File" tab in TaskList is not updated to show the tasks in the current buffer.
I don't know if it's related (maybe it's a separate issue), sometimes tasks are shown in the "Current File" tab even though their types are included in the Filter (i.e. if I click the Filter button, their check-boxes are clear but the tasks are nevertheless shown).

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

>Comment By: Dale Anson (daleanson)
Date: 2010-01-31 16:11

Message:
Closing, I think this is fixed.

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

Comment By: Dale Anson (daleanson)
Date: 2010-01-07 16:58

Message:
At least part of this is fixed now, the filter is now applied when the
buffer is changed.  

I'm having a hard time reproducing the part about the tasks are not being
updated to those of the current buffer.  Does it only happen when switching
buffers using BufferTabs?

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2010-01-06 03:03

Message:
Additional information about the filter: The filters seem to stop affecting
the shown tasks when the current buffer is changed. The filters button
keeps showing the same filter, but the tasks shown are no longer filtered
once the buffer is changed.

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

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

Plugin Feature Requests item #2922303, was opened at 2009-12-28 07:53
Message generated for change (Settings changed) made by daleanson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=2922303&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: Shlomy Reinstein (shlomy)
Assigned to: Dale Anson (daleanson)
Summary: TaskList: Add option to disable patterns

Initial Comment:
It would be very useful to be able to disable some patterns temporarily (still keep them on the list, but in disabled state), so they can be restored later.
For example, I have files with many "TODO" tasks. For certain development tasks, I'd like to disable these and see only my custom tasks.
Removing these tasks from the list will enable me to later use "reset", but "reset" will lose my custom settings.

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

Comment By: Dale Anson (daleanson)
Date: 2009-12-28 19:59

Message:
I checked in a fix for this in revisions 16766 and 16767.  Please give that
a try and let me know what you think.  I added a toolbar to the output
panel and added a filter menu to the toolbar.  This just filters the
current task list tabs and does not change the tasks defined in the options
at all.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-12-28 08:25

Message:
Would the filter persist? If it would, then it's okay, but there should be
a way to reset the filter and see the task type again.

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

Comment By: Dale Anson (daleanson)
Date: 2009-12-28 08:22

Message:
I'm thinking that rather than using the plugin options, a new item on the
context menu for the task list output display would let you filter by one
or more task types would work well for this.  What do you think? 

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

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

Plugin Bugs item #2942475, was opened at 2010-01-29 12:17
Message generated for change (Comment added) made by daleanson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=2942475&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: Alan Ezust (ezust)
>Assigned to: Alan Ezust (ezust)
Summary: JavaSideKick: use project properties or .classpath

Initial Comment:
JavaSideKick should not store any project properties in the java 'properties' file.
It should all go in either files that are stored in the project tree (as the case with .classpath)
or in ProjectViewer's properties via PV's API.


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

>Comment By: Dale Anson (daleanson)
Date: 2010-01-31 16:03

Message:
Alan, would you please clarify?  I think this is relation to a recent
thread on the developer's mailing list, but from that thread and this
request, I'm not sure what needs to be done.

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

Comment By: Alan Ezust (ezust)
Date: 2010-01-29 12:20

Message:
Or maybe it should just use eclipse .project files too.


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

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

Plugin Central Submission item #2943421, was opened at 2010-01-31 14:49
Message generated for change (Tracker Item Submitted) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=625093&aid=2943421&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: Alan Ezust (ezust)
Assigned to: Nobody/Anonymous (nobody)
Summary: SshConsole 1.0.2

Initial Comment:
{{{ SshConsole 1.0.2
    Source: Source code is in SVN with the tag tags/release-1.0.2
    Announcement:
     Fixed ConcurrentModificationException (# 2491847  - M. Casanova)
     Fixed broken close connections action (due to changes in
    accessibility by beanshell macros in core)


    Requires Java 1.5
    Requires jEdit 04.03.99.00
    Required plugins:
        console.ConsolePlugin 4.4
        ftp.FtpPlugin 0.9.7
        errorlist.ErrorListPlugin 1.7

    Short Description: Allows you to issue compile commands remotely via ssh in the same location as the sftp:// file you are editing, and parses the output for errors in ErrorList.

    Long Description: <html>
<p>SshConsole is an extension of the FTP, Console and ErrorList plugins. SshConsole is configured to execute commands on the same host, and in the same directory, as the directory you are currently browsing in the FSB or editing in jEdit via <tt>sftp://</tt>. It uses Console to parse the output for errors to show in ErrorList. This makes it easier to compile remote files and quickly jump to the errors.
</p>
</html>
 }}}


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

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

That's definitely a better solution, but will take some time to develop if
it's implemented.

Bugs item #2943274, was opened at 2010-02-01 00:16
Message generated for change (Tracker Item Submitted) made by zcjsg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2943274&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: virtual file systems
Group: Regressive (new to devel)
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Chuanjun Zhang (zcjsg)
Assigned to: Marcelo Vanzin (vanza)
Summary:  :: File System Browser can`t not work with windows 7

Initial Comment:
when using the File System Browser , I found it could not list the any file or directories;
I tried many times,but it still cant`t use it.
I dont`t know why
my system is "windows 7",using "jedit 4.3 stable version"

java.lang.RuntimeException: java.io.IOException: Could not get shell folder ID list
	at sun.awt.shell.Win32ShellFolderManager2$ComInvoker.invoke(Win32ShellFolderManager2.java:506)
	at sun.awt.shell.Win32ShellFolder2.getFileSystemPath(Win32ShellFolder2.java:563)
	at sun.awt.shell.Win32ShellFolder2.composePathForCsidl(Win32ShellFolder2.java:211)
	at sun.awt.shell.Win32ShellFolder2.<init>(Win32ShellFolder2.java:224)
	at sun.awt.shell.Win32ShellFolderManager2.getNetwork(Win32ShellFolderManager2.java:126)
	at sun.awt.shell.Win32ShellFolder2$7.call(Win32ShellFolder2.java:547)
	at sun.awt.shell.Win32ShellFolder2$7.call(Win32ShellFolder2.java:544)
	at sun.awt.shell.Win32ShellFolderManager2$ComInvoker.invoke(Win32ShellFolderManager2.java:491)
	at sun.awt.shell.Win32ShellFolder2.getFileSystemPath(Win32ShellFolder2.java:544)
	at sun.awt.shell.Win32ShellFolder2.access$300(Win32ShellFolder2.java:55)
	at sun.awt.shell.Win32ShellFolder2$2.call(Win32ShellFolder2.java:286)
	at sun.awt.shell.Win32ShellFolder2$2.call(Win32ShellFolder2.java:284)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at sun.awt.shell.Win32ShellFolderManager2$ComInvoker$3.run(Win32ShellFolderManager2.java:458)
	at java.lang.Thread.run(Thread.java:619)
Caused by: java.io.IOException: Could not get shell folder ID list
	at sun.awt.shell.Win32ShellFolder2.getFileSystemPath0(Native Method)
	at sun.awt.shell.Win32ShellFolder2.access$900(Win32ShellFolder2.java:55)
	at sun.awt.shell.Win32ShellFolder2$8.call(Win32ShellFolder2.java:565)
	at sun.awt.shell.Win32ShellFolder2$8.call(Win32ShellFolder2.java:563)
	at sun.awt.shell.Win32ShellFolderManager2$ComInvoker.invoke(Win32ShellFolderManager2.java:491)
	... 17 more


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

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

Plugin Bugs item #2941375, was opened at 2010-01-28 11:57
Message generated for change (Comment added) made by k_satoda
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=2941375&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: Marcelo Vanzin (vanza)
Assigned to: Nobody/Anonymous (nobody)
Summary: Console interrupting stdout / stderr threads too soon

Initial Comment:
When cleaning up after a child process is done, the Console plugin interrupts all the threads it spawns to read stdout / stderr. Problem is, it doesn't check to see whether those threads are really blocked, and sometimes interrupts valid operations. For example, simply changing the mode of the current buffer (with "chmod blah $f") causes the thread handling the EditBus message that Console itself triggers to be interrupted:

6:53:00 PM [Thread-20] [error] EditBus: java.lang.InterruptedException
6:53:00 PM [Thread-20] [error] EditBus:  at java.lang.Object.wait(Native Method)
6:53:00 PM [Thread-20] [error] EditBus:  at java.lang.Object.wait(Object.java:485)
6:53:00 PM [Thread-20] [error] EditBus:  at java.awt.EventQueue.invokeAndWait(EventQueue.java:992)
6:53:00 PM [Thread-20] [error] EditBus:  at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1323)
6:53:00 PM [Thread-20] [error] EditBus:  at org.gjt.sp.jedit.EditBus.send(EditBus.java:211)                   
6:53:00 PM [Thread-20] [error] EditBus:  at org.gjt.sp.jedit.BufferHistory.notifyChange(BufferHistory.java:406)
6:53:00 PM [Thread-20] [error] EditBus:  at org.gjt.sp.jedit.BufferHistory.setEntry(BufferHistory.java:115)    
6:53:00 PM [Thread-20] [error] EditBus:  at org.gjt.sp.jedit.EditPane.saveCaretInfo(EditPane.java:361)
6:53:00 PM [Thread-20] [error] EditBus:  at org.gjt.sp.jedit.visitors.SaveCaretInfoVisitor.visit(SaveCaretInfoVisitor.java:36)
6:53:00 PM [Thread-20] [error] EditBus:  at org.gjt.sp.jedit.View.visit(View.java:1321)
6:53:00 PM [Thread-20] [error] EditBus:  at org.gjt.sp.jedit.jEdit.visit(jEdit.java:2867)
6:53:00 PM [Thread-20] [error] EditBus:  at org.gjt.sp.jedit.jEdit.checkBufferStatus(jEdit.java:2259)
6:53:00 PM [Thread-20] [error] EditBus:  at org.gjt.sp.jedit.jEdit.checkBufferStatus(jEdit.java:2237)
6:53:00 PM [Thread-20] [error] EditBus:  at console.ConsoleProcess.threadDone(ConsoleProcess.java:315)
6:53:00 PM [Thread-20] [error] EditBus:  at console.StreamThread.run(StreamThread.java:187)

(This happens both with my patch to fire EditBus messages in the AWT and without it.)

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

>Comment By: Kazutoshi Satoda (k_satoda)
Date: 2010-01-31 18:02

Message:
Today I got bitten by the deadlock. It was now fixed in r17157 of
ErrorList.

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

Comment By: Marcelo Vanzin (vanza)
Date: 2010-01-30 15:24

Message:
The hang is a deadlock caused by ErrorList because of the new EditBus
behavior:

"Thread-14" prio=10 tid=0x097bf400 nid=0x11f6 in Object.wait()
[0xe990b000]
   java.lang.Thread.State: WAITING (on object monitor)                    

        at java.lang.Object.wait(Native Method)                           

        - waiting on <0xf3397930> (a
java.awt.EventQueue$1AWTInvocationLock)
        at java.lang.Object.wait(Object.java:485)                         
 
        at java.awt.EventQueue.invokeAndWait(EventQueue.java:992)         
 
        - locked <0xf3397930> (a java.awt.EventQueue$1AWTInvocationLock)  
 
        at
javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1323)
        at org.gjt.sp.jedit.EditBus.send(EditBus.java:211)                
  
        at errorlist.ErrorSource.registerErrorSource(ErrorSource.java:58) 
  
        - locked <0xf07a5da0> (a java.util.Vector) 

"AWT-EventQueue-0" prio=10 tid=0x096a4000 nid=0x11a1 waiting for monitor
entry [0xeab55000]
   java.lang.Thread.State: BLOCKED (on object monitor)                    
                
        at errorlist.ErrorSource.getErrorSources(ErrorSource.java:93)     
                
        - waiting to lock <0xf07a5da0> (a java.util.Vector)  


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

Comment By: Alan Ezust (ezust)
Date: 2010-01-30 15:07

Message:
It looks like since your change with how editbus handlers are sent, there
is a more serious problem with console - for me it locks up whenever there
are errors as a result of the output.
But there are some other screwy things about how the end of the subprocess
are handled, I know. And also hard for me to reproduce since they are very
timing sensitive, so I am not even sure how to debug this. Help?


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

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

As far as I recall, the plugin's cache is built only when the plugin
is loaded, and contains only objects that are included in the jar, not
anything that is created later during runtime.

To continue what I wrote in the other email, I think that cleanup of
stale objects should not be automatic, as it's too risky. Instead,
there should be a tool to present it to the user in the most
user-friendly way possible, and let the user to decide what to delete
and what to keep.

Similar to my suggestion with project dependency types, it would be
useful if each property was registered with jEdit, associating it with
a meaningful description and the jar file that uses it (perhaps
several jars). This would help the user understand which properties
might still be needed, and in addition, jEdit would be able (with some
overhead of course) to remove properties that are no longer needed -
if all plugins that used a property are loaded, and the property is
not registered by any plugin, it can be removed.

Shlomy

On Sun, Jan 31, 2010 at 5:36 AM, Damien Radtke <dam...@gm...> wrote:
> It does make a backup; it saves the properties file to properties.orig. And
> it's based on a fixed set; anything defined in the property files that come
> with jEdit or in any plugin's property file will be kept. I understand that
> it's somewhat risky, but I posted it to jedit-devel with the idea of making
> it less so. This was partly in response to your comment in the other
> conversation about there not being a way to clear out unused properties, and
> so this was my first step in attempting to accomplish that.
>
> Regarding properties defined dynamically, if there is a way to save those in
> the plugin's cache then there's no problem, because each plugin's cache is
> where the macro searches for properties to keep, not necessarily in the
> hard-coded .props file.
>

It does make a backup; it saves the properties file to properties.orig. And
it's based on a fixed set; anything defined in the property files that come
with jEdit or in any plugin's property file will be kept. I understand that
it's somewhat risky, but I posted it to jedit-devel with the idea of making
it less so. This was partly in response to your comment in the other
conversation about there not being a way to clear out unused properties, and
so this was my first step in attempting to accomplish that.

Regarding properties defined dynamically, if there is a way to save those in
the plugin's cache then there's no problem, because each plugin's cache is
where the macro searches for properties to keep, not necessarily in the
hard-coded .props file.

I don't understand - is your macro based on a "working set", which is
a growing set of properties which the user accessed recently (e.g.
during the last week), or is it based on a "fixed" set of properties
that includes what you wrote below?

Either way, this can be quite risky to use. For example, some of my
plugins define jEdit properties based on user input - properties that
you won't find anywhere except the java code itself (they are not part
of the .props files). A typical user is not aware of these properties
(unless the user tracks changes to the properties file).

At the very least, I suggest that the macro makes a backup of the
current properties before clearing any properties that it considers
unused.

Shlomy


On Sun, Jan 31, 2010 at 1:34 AM, Damien Radtke <dam...@gm...> wrote:
> I wrote a small macro that attempts to clear all unused properties
> from jEdit. It works by maintaining a list of properties to keep using
> a set, then iterating through all of the defined properties and
> unsetting any not contained in the set. Properties to keep are
> determined by reading through some property files defined in the jedit
> jar (jedit.props and jedit_gui.props), properties with a special
> ending (currently just .shortcut and .dock-position), anything saved
> in a plugin's cache, and a few are added manually. From my quick tests
> it appears to work fine with no adverse effects, but I wanted to see
> how it works for others, and if it's stable enough then maybe include
> it with jEdit.
>
> Hopefully this will help speed up jEdit for anyone who's getting
> bogged down with a lot of unused properties.
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> --
> -----------------------------------------------
> jEdit Developers' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>
>

I wrote a small macro that attempts to clear all unused properties
from jEdit. It works by maintaining a list of properties to keep using
a set, then iterating through all of the defined properties and
unsetting any not contained in the set. Properties to keep are
determined by reading through some property files defined in the jedit
jar (jedit.props and jedit_gui.props), properties with a special
ending (currently just .shortcut and .dock-position), anything saved
in a plugin's cache, and a few are added manually. From my quick tests
it appears to work fine with no adverse effects, but I wanted to see
how it works for others, and if it's stable enough then maybe include
it with jEdit.

Hopefully this will help speed up jEdit for anyone who's getting
bogged down with a lot of unused properties.

Patches item #2938170, was opened at 2010-01-23 22:08
Message generated for change (Comment added) made by fmjrey
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300588&aid=2938170&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: Accepted
Priority: 5
Private: No
Submitted By: François Rey (fmjrey)
Assigned to: Alan Ezust (ezust)
Summary: File Browser dynamic menu support

Initial Comment:
The attached patch brings some minor changes to EditPlugin and VFSBrowser in order to support dynamic menu.
Right now the FSB only support the addition of static menu defined in properties plugin.classname.browser-menu and plugin.classname.browser-menu-item.
This adds support for plugin.classname.browser-menu.code=code to instantiate a DynamicMenuProvider.

This is needed by the new Launcher plugin I'm writing so that it can provide a menu which content depends on the selected items.

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

Comment By: François Rey (fmjrey)
Date: 2010-01-30 23:46

Message:
As per k_satoda request for documentation, fold and @since tag, here is an
incremental patch file.
jEdit-EditPlugin-VFSBrowser-patch-fmjrey-20100130-browser-dyn-menu-support.txt

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

Comment By: Alan Ezust (ezust)
Date: 2010-01-30 08:27

Message:
Committed 17147


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

Comment By: François Rey (fmjrey)
Date: 2010-01-29 11:32

Message:
The method removed is private and belongs to a package private inner class.
That should be enough to ensure removing it does not break anything.
However the method is not all lost: it's now a public method of the outer
class.


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

Comment By: Alan Ezust (ezust)
Date: 2010-01-29 03:38

Message:
I notice in the patch that another method is removed - also called
getSelectedFiles but with different signature.
Is that intentional? Did you verify that no plugins use it?


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

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

Plugin Central Submission item #2942879, was opened at 2010-01-30 11:45
Message generated for change (Tracker Item Submitted) made by daleanson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=625093&aid=2942879&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: Dale Anson (daleanson)
Assigned to: Nobody/Anonymous (nobody)
Summary: Calculator 1.2

Initial Comment:
{{{ CalculatorPlugin 1.2.0
    Source: Source code is in SVN with the tag https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/Calculator/tags/1.2.0
    Announcement: Bug fixes and feature enhancements:
    - Fixed bug 2411641, creating a new function didn't work.
    - Adjusted layout so it works well with a variety of look and feels.
    - Rearranged some of the buttons for a more logical grouping.
    - Added store and recall feature like on the HP-35.
    - Added swing workers for operations so jEdit doesn't hang while a long running calculation is taking place.
    - Fixed keyboard handling for 'divide' operation.
    Requires Java 1.6
    Requires jEdit 04.02.01.00
    
    Short Description: An RPN calculator.
    
    Long Description: 
<html>
<p>
This plugin provides an RPN calculator. It has these features:
<br>
<ul>
<li>4 register stack</li>
<li>Integer base 2, 8, 10, 16, and base 10 float operation</li>
<li>BigDecimal, Float, BigInteger, and Integer modes</li>
<li>Access to all math functions in java.lang.Math</li>
<li>Can use java.lang.StrictMath if needed</li>
<li>Standard plus, minus, multiply, divide, and mod operations</li>
<li>Boolean and, or, xor, and not operations</li>
<li>Stack manipulation controls</li>
<li>Programmable (recordable) functions</li>
<li>Hundreds of constant values</li>
</ul>
</p>
<html>
 }}}

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

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

> To go along with the different sets of dependencies, should there be a
> way to enable/disable them? If the list of dependency types used grows
> and each project is only interested in using one, then there should
> probably be some way to disable the ones not used on a per-project
> basis. I'm still a little on the fence myself about what the best way
> to do that would be, so it's not that important, but it's something to
> consider.

They will be enabled by the registration. Only registered dependency
types will appear in the GUI.
With time, this may cause obsolete dependency types to exist - no one
will read them, and they won't be visible in the GUI, but will
continue to take disk space and possibly add to project load / save
time.
The same problem exists today with jEdit properties - I don't know of
any way to make them automatically disappear when no one needs them
any more. A plugin can ask jEdit to remove a private property when
it's no longer needed, but for a shared property, the list of
references need to be maintained in order to know when all references
are removed.

> In terms of UI design, I think it would be cleaner to have
> "Dependencies" be the PV pane and then have that pane be tabbed
> according to which dependencies were registered. This  would make it
> easier to enable or disable them too, if that becomes implemented.

Having a separate tab for each dependency type is not very convenient
for the user in my opinion (this is why I combined them in
CtagsInterface). We can think of several ways to group related
dependency types together, and maybe have several groups as children
of the 'Dependencies' node in the tree.

Shlomy

I think we're on to something. =)

To go along with the different sets of dependencies, should there be a
way to enable/disable them? If the list of dependency types used grows
and each project is only interested in using one, then there should
probably be some way to disable the ones not used on a per-project
basis. I'm still a little on the fence myself about what the best way
to do that would be, so it's not that important, but it's something to
consider.

In terms of UI design, I think it would be cleaner to have
"Dependencies" be the PV pane and then have that pane be tabbed
according to which dependencies were registered. This  would make it
easier to enable or disable them too, if that becomes implemented.

ez...@us... wrote:
>  		String menuProperty = "plugin." + getClassName() + ".browser-menu";
> -		if(jEdit.getProperty(menuProperty) != null)
> +		String codeProperty = "plugin." + getClassName() + ".browser-menu.code";
> +		if(jEdit.getProperty(menuProperty) != null
> +			|| jEdit.getProperty(codeProperty) != null)
>  		{

Is there documentation for the ".browser-menu.code" property?

If this is a new property to interact with plugins, I think it should have
a corresponding new documentation.

> +	public VFSFile[] getSelectedFiles(Component source)

Here, missing explicit fold and @since tag.

I also noticed the old one, which takes no argument, don't have
documentation. Could you please supply it?

-- 
k_satoda

Hi there

Please find below a link to a survey related to my PhD research work to evaluate OSS usability improvement from Industry Perspective.
It shall not not take more than 5 minutes of your precious time. 
Your identity is neither required nor recorded. The participation is highly valued and appreciated.
 
http://www.kwiksurveys.com/online-survey.php?surveyID=BOHMN_8d5c35f8

Thank you and Best Regards

Arif Raza

>> (2) Each plugin that uses project dependencies will first register the
>> dependency kinds it uses with PV. The registration will include a name
>> and a type. The name will be used for accessing the dependency value
>> using (1), allowing plugins to share dependency information by simply
>> using the same name. The type will be used by PV for the GUI
>> presentation of this property (I think something similar is done in
>> Console Commando feature).
>
> Not sure I completely understand you here, but I think I like it.

Plugins will use several types of dependencies. Each type will have an
associated name (e.g. 'projects', 'classpath'). You can ask a project
for its dependencies of a particular type using the type name - e.g.
VPTProject.getDependencies("classpath"). Plugins that want to use the
same type of dependency will simply use the type name to access the
dependencies. The dependencies of a project will be stored based on
the type only, and not based on the plugin.
Each dependency type will also have an associated "value type" - e.g.
list of projects or list of directories - which will be used to
determine which GUI widget to use for configuring the value.
CtagsInterface, for example, uses different widgets for the project
list
and for the source trees - for the projects, it queries PV for all
available projects, and for the source trees, it allows you to select
a directory using a file dialog.
Before PV has any dependency info stored for its projects, the plugins
should register the dependency types they're interested in, so that PV
can provide the GUI for configuring them.

>>
>> PV will have a generic 'Dependencies' pane, whose contents will depend
>> on the registered dependency kinds.
>
> So in other words, JavaSideKick will register a "java" dependency kind, and
> therefore,
> if we have that plugin installed, we will see classpath in the same pane but
> if we don't have
> javasidekick, we won't see it ? If it does end up working that way, very
> cool!

Yes, that's exactly what I meant.

Shlomy

Plugin Feature Requests item #2941820, was opened at 2010-01-28 21:41
Message generated for change (Comment added) made by kerik-sf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=2941820&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: michael michaud (michaudm)
>Assigned to: kerik (kerik-sf)
Summary: XML Plugin : accessibility from java mode

Initial Comment:
Would it be possible to get access to "Characters to Entities" command while editing javadoc in a java file ?
I usually use entities like é, which are OK with javadoc and a bit more readable than numric entities, but I think both can do the trick.

Thanks for any help  

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

>Comment By: kerik (kerik-sf)
Date: 2010-01-30 09:47

Message:
I intend to make "Characters to Entities" and "Entities to Characters"
available in all edit modes.
Then, the buffer has not been parsed by XML Sidekick, to escape non ascii
characters to their numerical entity and < & > to their escaping. 
Any comment ?

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

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

Shlomy, you're my hero!!


:-)


On Fri, Jan 29, 2010 at 9:55 PM, Shlomy Reinstein <sre...@gm...>wrote:

> Hi,
>
> I did not completely understand what you want to include in the
> classpath and how it will be specified there.
> One (small) detail that should be arrange is ensuring that plugins
> access the dependencies files (whatever it is) sequentially, so that a
> plugin does not happen to read it while another plugin is writing it.
>
> Yes, we need a common API for getting/setting the info so that plugins
don't need to each parse/store the data themselves.
And that info should be loaded and saved at the same time as the rest of the
project info is loaded/saved.


> I suggest something like the following:
> (1) All access to dependencies will be done through PV, not directly
> by plugins. VPTProject will include methods for retrieving (maybe also
> setting) the dependencies. This will ensure sequential access.
>

Yes!!!


> (2) Each plugin that uses project dependencies will first register the
> dependency kinds it uses with PV. The registration will include a name
> and a type. The name will be used for accessing the dependency value
> using (1), allowing plugins to share dependency information by simply
> using the same name. The type will be used by PV for the GUI
> presentation of this property (I think something similar is done in
> Console Commando feature).
>

Not sure I completely understand you here, but I think I like it.

>
> PV will have a generic 'Dependencies' pane, whose contents will depend
> on the registered dependency kinds.


So in other words, JavaSideKick will register a "java" dependency kind, and
therefore,
if we have that plugin installed, we will see classpath in the same pane but
if we don't have
javasidekick, we won't see it ? If it does end up working that way, very
cool!


> When the user changes dependencies
> using this pane, an edit bus message will be sent to keep the plugins
> updated.
> How and where to save the dependencies should no longer be relevant
> for plugins since they only access the dependencies via PV.
>

Yes!

Patches item #2938170, was opened at 2010-01-23 13:08
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300588&aid=2938170&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: Accepted
Priority: 5
Private: No
Submitted By: François Rey (fmjrey)
>Assigned to: Alan Ezust (ezust)
Summary: File Browser dynamic menu support

Initial Comment:
The attached patch brings some minor changes to EditPlugin and VFSBrowser in order to support dynamic menu.
Right now the FSB only support the addition of static menu defined in properties plugin.classname.browser-menu and plugin.classname.browser-menu-item.
This adds support for plugin.classname.browser-menu.code=code to instantiate a DynamicMenuProvider.

This is needed by the new Launcher plugin I'm writing so that it can provide a menu which content depends on the selected items.

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

>Comment By: Alan Ezust (ezust)
Date: 2010-01-29 23:27

Message:
Committed 17147


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

Comment By: François Rey (fmjrey)
Date: 2010-01-29 02:32

Message:
The method removed is private and belongs to a package private inner class.
That should be enough to ensure removing it does not break anything.
However the method is not all lost: it's now a public method of the outer
class.


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

Comment By: Alan Ezust (ezust)
Date: 2010-01-28 18:38

Message:
I notice in the patch that another method is removed - also called
getSelectedFiles but with different signature.
Is that intentional? Did you verify that no plugins use it?


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

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

Plugin Bugs item #2941375, was opened at 2010-01-27 18:57
Message generated for change (Comment added) made by vanza
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=2941375&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: Marcelo Vanzin (vanza)
Assigned to: Nobody/Anonymous (nobody)
Summary: Console interrupting stdout / stderr threads too soon

Initial Comment:
When cleaning up after a child process is done, the Console plugin interrupts all the threads it spawns to read stdout / stderr. Problem is, it doesn't check to see whether those threads are really blocked, and sometimes interrupts valid operations. For example, simply changing the mode of the current buffer (with "chmod blah $f") causes the thread handling the EditBus message that Console itself triggers to be interrupted:

6:53:00 PM [Thread-20] [error] EditBus: java.lang.InterruptedException
6:53:00 PM [Thread-20] [error] EditBus:  at java.lang.Object.wait(Native Method)
6:53:00 PM [Thread-20] [error] EditBus:  at java.lang.Object.wait(Object.java:485)
6:53:00 PM [Thread-20] [error] EditBus:  at java.awt.EventQueue.invokeAndWait(EventQueue.java:992)
6:53:00 PM [Thread-20] [error] EditBus:  at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1323)
6:53:00 PM [Thread-20] [error] EditBus:  at org.gjt.sp.jedit.EditBus.send(EditBus.java:211)                   
6:53:00 PM [Thread-20] [error] EditBus:  at org.gjt.sp.jedit.BufferHistory.notifyChange(BufferHistory.java:406)
6:53:00 PM [Thread-20] [error] EditBus:  at org.gjt.sp.jedit.BufferHistory.setEntry(BufferHistory.java:115)    
6:53:00 PM [Thread-20] [error] EditBus:  at org.gjt.sp.jedit.EditPane.saveCaretInfo(EditPane.java:361)
6:53:00 PM [Thread-20] [error] EditBus:  at org.gjt.sp.jedit.visitors.SaveCaretInfoVisitor.visit(SaveCaretInfoVisitor.java:36)
6:53:00 PM [Thread-20] [error] EditBus:  at org.gjt.sp.jedit.View.visit(View.java:1321)
6:53:00 PM [Thread-20] [error] EditBus:  at org.gjt.sp.jedit.jEdit.visit(jEdit.java:2867)
6:53:00 PM [Thread-20] [error] EditBus:  at org.gjt.sp.jedit.jEdit.checkBufferStatus(jEdit.java:2259)
6:53:00 PM [Thread-20] [error] EditBus:  at org.gjt.sp.jedit.jEdit.checkBufferStatus(jEdit.java:2237)
6:53:00 PM [Thread-20] [error] EditBus:  at console.ConsoleProcess.threadDone(ConsoleProcess.java:315)
6:53:00 PM [Thread-20] [error] EditBus:  at console.StreamThread.run(StreamThread.java:187)

(This happens both with my patch to fire EditBus messages in the AWT and without it.)

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

>Comment By: Marcelo Vanzin (vanza)
Date: 2010-01-29 22:24

Message:
The hang is a deadlock caused by ErrorList because of the new EditBus
behavior:

"Thread-14" prio=10 tid=0x097bf400 nid=0x11f6 in Object.wait()
[0xe990b000]
   java.lang.Thread.State: WAITING (on object monitor)                    

        at java.lang.Object.wait(Native Method)                           

        - waiting on <0xf3397930> (a
java.awt.EventQueue$1AWTInvocationLock)
        at java.lang.Object.wait(Object.java:485)                         
 
        at java.awt.EventQueue.invokeAndWait(EventQueue.java:992)         
 
        - locked <0xf3397930> (a java.awt.EventQueue$1AWTInvocationLock)  
 
        at
javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1323)
        at org.gjt.sp.jedit.EditBus.send(EditBus.java:211)                
  
        at errorlist.ErrorSource.registerErrorSource(ErrorSource.java:58) 
  
        - locked <0xf07a5da0> (a java.util.Vector) 

"AWT-EventQueue-0" prio=10 tid=0x096a4000 nid=0x11a1 waiting for monitor
entry [0xeab55000]
   java.lang.Thread.State: BLOCKED (on object monitor)                    
                
        at errorlist.ErrorSource.getErrorSources(ErrorSource.java:93)     
                
        - waiting to lock <0xf07a5da0> (a java.util.Vector)  


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

Comment By: Alan Ezust (ezust)
Date: 2010-01-29 22:07

Message:
It looks like since your change with how editbus handlers are sent, there
is a more serious problem with console - for me it locks up whenever there
are errors as a result of the output.
But there are some other screwy things about how the end of the subprocess
are handled, I know. And also hard for me to reproduce since they are very
timing sensitive, so I am not even sure how to debug this. Help?


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

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

Ok, I will check it when I have time (some time during next week). I
used it all the time at work, and never noticed any problems. The
problems you see may be related to the fact that the plugin runs Ctags
on the actual file and not on the contents of the jEdit buffer. I will
see if I can change that (after all, I use the buffer contents for
parsing remote files, but then I just create a local temporary file
with the contents and parse it).

Shlomy

On Sat, Jan 30, 2010 at 8:04 AM, Marcelo Vanzin
<va...@us...> wrote:
> CtagsSideKick looks really bad at multi-thread vs. awt issues.
> Enabling it while running the substance l&f causes all sorts of
> warning in the terminal.
>
> On Fri, Jan 29, 2010 at 9:48 PM, Alan Ezust <ala...@gm...> wrote:
>> I just noticed Console is locking up on me while I run "make" in it. I have
>> ctagssidekick parser active.
>> Look at these strange exceptions:
>
> --
> Marcelo Vanzin
> mmv...@gm...
> "Life's too short to drink cheap beer."
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> --
> -----------------------------------------------
> jEdit Developers' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>