jedit-devel Mailing List for jEdit

It is a bit more work, but it is possible to add a close button to a 
Java 5 JTabbedPane.  There is code in the SVN Plugin to do that.  
Perhaps that code should be added to CommonControls so BufferTabs (and 
any other plugin) could make easy use of it?

Dale

Bugs item #2830371, was opened at 2009-07-31 08:16
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2830371&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 API
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 7
Private: No
Submitted By: Alan Ezust (ezust)
Assigned to: Nobody/Anonymous (nobody)
Summary: Plugin Loading: activate optional dependencies

Initial Comment:
If a plugin has optional dependencies, they should be activated just like the non-optional dependencies,
when the plugin is activated.


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

>Comment By: Alan Ezust (ezust)
Date: 2009-07-31 11:59

Message:
So far, this is an issue that only effects users of PV and those who
monitor EBMessages from plugins that are not in core.
Ok, I will close this and say "won't fix".



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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-31 11:46

Message:
Not to me. The code (e.g. in my plugin) should take care not to
accidentally load plugins that it did not mean to.
Note that CtagsInterface supports many sources for its tag database;
archives, tag files, source trees, and projects. There may exist users who
use PV only occasionally, and may run sessions with no PV at all (PV is
installed, because it is occasionally used, but it is not loaded in those
sessions). I don't think that just because CtagsInterface has an optional
dependency on it, PV should also be loaded.

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

Comment By: Alan Ezust (ezust)
Date: 2009-07-31 10:36

Message:
you wouldn't have to worry about class circularity errors when accidentally
loading a class from an optional dependency.
I've experienced this mostly with projectviewer and console. But you see
it with ctagsinterface and pv now.
I think pv should always be activated before any of the plugins that use
it even as an optional dependency. 
The fact that it is not is a bit annoying to me. Not to you?


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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-31 09:42

Message:
I think in most cases. (Note that this is the state now, and I didn't see
any complaints about it)

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

Comment By: Alan Ezust (ezust)
Date: 2009-07-31 09:12

Message:
You mean some way of specifying the activate property of an optional
dependency?
Under what circumstances would you want to activate a plugin without its
optional dependencies?
Give me a use case.



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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-31 08:20

Message:
Are you sure about that? If you wrote this just to eliminate the edit bus
message "instanceof" issue, then I don't think this is necessarily right.
Maybe an optional dependency should have two types:
- always activate optional dependency before (if exists)
- do not activate optional dependency before

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

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

Bugs item #2830371, was opened at 2009-07-31 18:16
Message generated for change (Comment added) made by shlomy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2830371&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 API
Group: None
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Alan Ezust (ezust)
Assigned to: Nobody/Anonymous (nobody)
Summary: Plugin Loading: activate optional dependencies

Initial Comment:
If a plugin has optional dependencies, they should be activated just like the non-optional dependencies,
when the plugin is activated.


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

>Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-31 21:46

Message:
Not to me. The code (e.g. in my plugin) should take care not to
accidentally load plugins that it did not mean to.
Note that CtagsInterface supports many sources for its tag database;
archives, tag files, source trees, and projects. There may exist users who
use PV only occasionally, and may run sessions with no PV at all (PV is
installed, because it is occasionally used, but it is not loaded in those
sessions). I don't think that just because CtagsInterface has an optional
dependency on it, PV should also be loaded.

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

Comment By: Alan Ezust (ezust)
Date: 2009-07-31 20:36

Message:
you wouldn't have to worry about class circularity errors when accidentally
loading a class from an optional dependency.
I've experienced this mostly with projectviewer and console. But you see
it with ctagsinterface and pv now.
I think pv should always be activated before any of the plugins that use
it even as an optional dependency. 
The fact that it is not is a bit annoying to me. Not to you?


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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-31 19:42

Message:
I think in most cases. (Note that this is the state now, and I didn't see
any complaints about it)

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

Comment By: Alan Ezust (ezust)
Date: 2009-07-31 19:12

Message:
You mean some way of specifying the activate property of an optional
dependency?
Under what circumstances would you want to activate a plugin without its
optional dependencies?
Give me a use case.



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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-31 18:20

Message:
Are you sure about that? If you wrote this just to eliminate the edit bus
message "instanceof" issue, then I don't think this is necessarily right.
Maybe an optional dependency should have two types:
- always activate optional dependency before (if exists)
- do not activate optional dependency before

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

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

Like the bug Alan has filed, my plugin has an optional dependency on
PV, which is why PV is not automatically loaded before my plugin.
Personally, in my case, I wouldn't care to have PV loaded before my
plugin, since the PV dockable is always docked in my view during
startup, so it starts anyway. But I can just as well understand other
use cases where PV is not always used, only occasionally, but on the
other hand CtagsInterface would be always used, since startup.

So, while personally I don't care if optional dependencies are always
loaded before the plugins that optionally depend on them, I think this
is better be asked on the jedit-users list. Perhaps users will come up
with many scenarios where this is highly undesired.

Shlomy

On Fri, Jul 31, 2009 at 8:07 PM, Marcelo
Vanzin<va...@us...> wrote:
> On Fri, Jul 31, 2009 at 7:18 AM, Shlomy Reinstein<sre...@gm...> wrote:
>> Before I dive into details, please avoid checking the types of edit
>> bus messages of other plugins using "instanceof", such as:
>
> If you're using instanceof, shouldn't your plugin depend on the plugin
> that provides the class you're checking? If that's the case, isn't the
> dependency loaded before your plugin, rendering this issue moot?
>
> If it's an optional dependency, the bug that Alan just files might fix
> it. (And your code should make really sure that the code path you're
> mentioning never gets invoked if the dependency is not present -
> ProjectViewer itself does that in a few places, with ErrorList and
> InfoViewer).
>
> --
> Marcelo Vanzin
> mmv...@gm...
> "Life's too short to drink cheap beer."
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> --
> -----------------------------------------------
> jEdit Developers' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>

On Fri, Jul 31, 2009 at 7:18 AM, Shlomy Reinstein<sre...@gm...> wrote:
> Before I dive into details, please avoid checking the types of edit
> bus messages of other plugins using "instanceof", such as:

If you're using instanceof, shouldn't your plugin depend on the plugin
that provides the class you're checking? If that's the case, isn't the
dependency loaded before your plugin, rendering this issue moot?

If it's an optional dependency, the bug that Alan just files might fix
it. (And your code should make really sure that the code path you're
mentioning never gets invoked if the dependency is not present -
ProjectViewer itself does that in a few places, with ErrorList and
InfoViewer).

-- 
Marcelo Vanzin
mmv...@gm...
"Life's too short to drink cheap beer."

Bugs item #2830371, was opened at 2009-07-31 08:16
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2830371&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 API
Group: None
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Alan Ezust (ezust)
Assigned to: Nobody/Anonymous (nobody)
Summary: Plugin Loading: activate optional dependencies

Initial Comment:
If a plugin has optional dependencies, they should be activated just like the non-optional dependencies,
when the plugin is activated.


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

>Comment By: Alan Ezust (ezust)
Date: 2009-07-31 10:36

Message:
you wouldn't have to worry about class circularity errors when accidentally
loading a class from an optional dependency.
I've experienced this mostly with projectviewer and console. But you see
it with ctagsinterface and pv now.
I think pv should always be activated before any of the plugins that use
it even as an optional dependency. 
The fact that it is not is a bit annoying to me. Not to you?


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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-31 09:42

Message:
I think in most cases. (Note that this is the state now, and I didn't see
any complaints about it)

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

Comment By: Alan Ezust (ezust)
Date: 2009-07-31 09:12

Message:
You mean some way of specifying the activate property of an optional
dependency?
Under what circumstances would you want to activate a plugin without its
optional dependencies?
Give me a use case.



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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-31 08:20

Message:
Are you sure about that? If you wrote this just to eliminate the edit bus
message "instanceof" issue, then I don't think this is necessarily right.
Maybe an optional dependency should have two types:
- always activate optional dependency before (if exists)
- do not activate optional dependency before

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

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

Plugin Central Submission item #2830169, was opened at 2009-07-31 01:18
Message generated for change (Comment added) made by elberry
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=625093&aid=2830169&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: Matthieu Casanova (kpouer)
Assigned to: Townsfolk (elberry)
Summary: BufferTabs 1.1.1

Initial Comment:
{{{ BufferTabs 1.1.1
    Source: https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/BufferTabs/tags/BufferTabs-1.1.1
    Announcement: Updated for 4.3pre17 api compatibility
    Requires Java 1.5
    Requires jEdit 04.03.17.00
    
    Short Description: Show tabs to switch buffers
    
    Long Description: Show tabs to switch buffers
 }}}

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

>Comment By: Townsfolk (elberry)
Date: 2009-07-31 09:57

Message:
released to plugin central.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-31 09:43

Message:
I introduced this part in the code, for the "close" buttons in the tabs.
This feature is only available in Java 6, so the code requires Java 6 to
compile, but it will also run with Java 5 because reflection is used to
determine if this functionality exists at run time.

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

Comment By: Townsfolk (elberry)
Date: 2009-07-31 09:39

Message:
Hi Matthieu,
   I'm getting some compile errors:
 [jp.javac] Compiling 5 source files to
/Users/eberry/development/projects/jedit/plugins/sandbox/BufferTabs-1.1.1/BufferTabs/build/classes
 [jp.javac]
/Users/eberry/development/projects/jedit/plugins/sandbox/BufferTabs-1.1.1/BufferTabs/buffertabs/BufferTabComponent.java:51:
cannot find symbol
 [jp.javac] symbol  : method
indexOfTabComponent(buffertabs.BufferTabComponent)
 [jp.javac] location: class buffertabs.BufferTabs
 [jp.javac] 				int index =
pane.indexOfTabComponent(BufferTabComponent.this);
 [jp.javac]                                                 ^
 [jp.javac]
/Users/eberry/development/projects/jedit/plugins/sandbox/BufferTabs-1.1.1/BufferTabs/buffertabs/BufferTabComponent.java:58:
cannot find symbol
 [jp.javac] symbol  : method
indexOfTabComponent(buffertabs.BufferTabComponent)
 [jp.javac] location: class buffertabs.BufferTabs
 [jp.javac] 				int index =
pane.indexOfTabComponent(BufferTabComponent.this);
 [jp.javac]                                                 ^
 [jp.javac]
/Users/eberry/development/projects/jedit/plugins/sandbox/BufferTabs-1.1.1/BufferTabs/buffertabs/BufferTabComponent.java:82:
cannot find symbol
 [jp.javac] symbol  : method
indexOfTabComponent(buffertabs.BufferTabComponent)
 [jp.javac] location: class buffertabs.BufferTabs
 [jp.javac] 				int index =
pane.indexOfTabComponent(BufferTabComponent.this);
 [jp.javac]                                                 ^
 [jp.javac] 3 errors

The Java req for the plugin is specified as Java 5, but looking at the
JTabbedPane javadocs, that method wasn't introduced until Java 6.
http://java.sun.com/javase/6/docs/api/javax/swing/JTabbedPane.html#indexOfTabComponent(java.awt.Component)

Do you want to up the Java Requirment?

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

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

Plugin Central Submission item #2830169, was opened at 2009-07-31 11:18
Message generated for change (Comment added) made by shlomy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=625093&aid=2830169&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: Matthieu Casanova (kpouer)
Assigned to: Townsfolk (elberry)
Summary: BufferTabs 1.1.1

Initial Comment:
{{{ BufferTabs 1.1.1
    Source: https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/BufferTabs/tags/BufferTabs-1.1.1
    Announcement: Updated for 4.3pre17 api compatibility
    Requires Java 1.5
    Requires jEdit 04.03.17.00
    
    Short Description: Show tabs to switch buffers
    
    Long Description: Show tabs to switch buffers
 }}}

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

>Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-31 19:43

Message:
I introduced this part in the code, for the "close" buttons in the tabs.
This feature is only available in Java 6, so the code requires Java 6 to
compile, but it will also run with Java 5 because reflection is used to
determine if this functionality exists at run time.

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

Comment By: Townsfolk (elberry)
Date: 2009-07-31 19:39

Message:
Hi Matthieu,
   I'm getting some compile errors:
 [jp.javac] Compiling 5 source files to
/Users/eberry/development/projects/jedit/plugins/sandbox/BufferTabs-1.1.1/BufferTabs/build/classes
 [jp.javac]
/Users/eberry/development/projects/jedit/plugins/sandbox/BufferTabs-1.1.1/BufferTabs/buffertabs/BufferTabComponent.java:51:
cannot find symbol
 [jp.javac] symbol  : method
indexOfTabComponent(buffertabs.BufferTabComponent)
 [jp.javac] location: class buffertabs.BufferTabs
 [jp.javac] 				int index =
pane.indexOfTabComponent(BufferTabComponent.this);
 [jp.javac]                                                 ^
 [jp.javac]
/Users/eberry/development/projects/jedit/plugins/sandbox/BufferTabs-1.1.1/BufferTabs/buffertabs/BufferTabComponent.java:58:
cannot find symbol
 [jp.javac] symbol  : method
indexOfTabComponent(buffertabs.BufferTabComponent)
 [jp.javac] location: class buffertabs.BufferTabs
 [jp.javac] 				int index =
pane.indexOfTabComponent(BufferTabComponent.this);
 [jp.javac]                                                 ^
 [jp.javac]
/Users/eberry/development/projects/jedit/plugins/sandbox/BufferTabs-1.1.1/BufferTabs/buffertabs/BufferTabComponent.java:82:
cannot find symbol
 [jp.javac] symbol  : method
indexOfTabComponent(buffertabs.BufferTabComponent)
 [jp.javac] location: class buffertabs.BufferTabs
 [jp.javac] 				int index =
pane.indexOfTabComponent(BufferTabComponent.this);
 [jp.javac]                                                 ^
 [jp.javac] 3 errors

The Java req for the plugin is specified as Java 5, but looking at the
JTabbedPane javadocs, that method wasn't introduced until Java 6.
http://java.sun.com/javase/6/docs/api/javax/swing/JTabbedPane.html#indexOfTabComponent(java.awt.Component)

Do you want to up the Java Requirment?

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

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

Bugs item #2830371, was opened at 2009-07-31 18:16
Message generated for change (Comment added) made by shlomy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2830371&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 API
Group: None
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Alan Ezust (ezust)
Assigned to: Nobody/Anonymous (nobody)
Summary: Plugin Loading: activate optional dependencies

Initial Comment:
If a plugin has optional dependencies, they should be activated just like the non-optional dependencies,
when the plugin is activated.


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

>Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-31 19:42

Message:
I think in most cases. (Note that this is the state now, and I didn't see
any complaints about it)

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

Comment By: Alan Ezust (ezust)
Date: 2009-07-31 19:12

Message:
You mean some way of specifying the activate property of an optional
dependency?
Under what circumstances would you want to activate a plugin without its
optional dependencies?
Give me a use case.



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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-31 18:20

Message:
Are you sure about that? If you wrote this just to eliminate the edit bus
message "instanceof" issue, then I don't think this is necessarily right.
Maybe an optional dependency should have two types:
- always activate optional dependency before (if exists)
- do not activate optional dependency before

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

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

Plugin Central Submission item #2830169, was opened at 2009-07-31 01:18
Message generated for change (Comment added) made by elberry
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=625093&aid=2830169&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: Matthieu Casanova (kpouer)
Assigned to: Townsfolk (elberry)
Summary: BufferTabs 1.1.1

Initial Comment:
{{{ BufferTabs 1.1.1
    Source: https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/BufferTabs/tags/BufferTabs-1.1.1
    Announcement: Updated for 4.3pre17 api compatibility
    Requires Java 1.5
    Requires jEdit 04.03.17.00
    
    Short Description: Show tabs to switch buffers
    
    Long Description: Show tabs to switch buffers
 }}}

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

>Comment By: Townsfolk (elberry)
Date: 2009-07-31 09:39

Message:
Hi Matthieu,
   I'm getting some compile errors:
 [jp.javac] Compiling 5 source files to
/Users/eberry/development/projects/jedit/plugins/sandbox/BufferTabs-1.1.1/BufferTabs/build/classes
 [jp.javac]
/Users/eberry/development/projects/jedit/plugins/sandbox/BufferTabs-1.1.1/BufferTabs/buffertabs/BufferTabComponent.java:51:
cannot find symbol
 [jp.javac] symbol  : method
indexOfTabComponent(buffertabs.BufferTabComponent)
 [jp.javac] location: class buffertabs.BufferTabs
 [jp.javac] 				int index =
pane.indexOfTabComponent(BufferTabComponent.this);
 [jp.javac]                                                 ^
 [jp.javac]
/Users/eberry/development/projects/jedit/plugins/sandbox/BufferTabs-1.1.1/BufferTabs/buffertabs/BufferTabComponent.java:58:
cannot find symbol
 [jp.javac] symbol  : method
indexOfTabComponent(buffertabs.BufferTabComponent)
 [jp.javac] location: class buffertabs.BufferTabs
 [jp.javac] 				int index =
pane.indexOfTabComponent(BufferTabComponent.this);
 [jp.javac]                                                 ^
 [jp.javac]
/Users/eberry/development/projects/jedit/plugins/sandbox/BufferTabs-1.1.1/BufferTabs/buffertabs/BufferTabComponent.java:82:
cannot find symbol
 [jp.javac] symbol  : method
indexOfTabComponent(buffertabs.BufferTabComponent)
 [jp.javac] location: class buffertabs.BufferTabs
 [jp.javac] 				int index =
pane.indexOfTabComponent(BufferTabComponent.this);
 [jp.javac]                                                 ^
 [jp.javac] 3 errors

The Java req for the plugin is specified as Java 5, but looking at the
JTabbedPane javadocs, that method wasn't introduced until Java 6.
http://java.sun.com/javase/6/docs/api/javax/swing/JTabbedPane.html#indexOfTabComponent(java.awt.Component)

Do you want to up the Java Requirment?

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

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

Plugin Central Submission item #2830169, was opened at 2009-07-31 01:18
Message generated for change (Settings changed) made by elberry
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=625093&aid=2830169&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: Matthieu Casanova (kpouer)
>Assigned to: Townsfolk (elberry)
Summary: BufferTabs 1.1.1

Initial Comment:
{{{ BufferTabs 1.1.1
    Source: https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/BufferTabs/tags/BufferTabs-1.1.1
    Announcement: Updated for 4.3pre17 api compatibility
    Requires Java 1.5
    Requires jEdit 04.03.17.00
    
    Short Description: Show tabs to switch buffers
    
    Long Description: Show tabs to switch buffers
 }}}

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

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

Bugs item #2830371, was opened at 2009-07-31 08:16
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2830371&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 API
Group: None
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Alan Ezust (ezust)
Assigned to: Nobody/Anonymous (nobody)
Summary: Plugin Loading: activate optional dependencies

Initial Comment:
If a plugin has optional dependencies, they should be activated just like the non-optional dependencies,
when the plugin is activated.


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

>Comment By: Alan Ezust (ezust)
Date: 2009-07-31 09:12

Message:
You mean some way of specifying the activate property of an optional
dependency?
Under what circumstances would you want to activate a plugin without its
optional dependencies?
Give me a use case.



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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-31 08:20

Message:
Are you sure about that? If you wrote this just to eliminate the edit bus
message "instanceof" issue, then I don't think this is necessarily right.
Maybe an optional dependency should have two types:
- always activate optional dependency before (if exists)
- do not activate optional dependency before

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

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

Bugs item #2830371, was opened at 2009-07-31 18:16
Message generated for change (Comment added) made by shlomy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2830371&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 API
Group: None
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Alan Ezust (ezust)
Assigned to: Nobody/Anonymous (nobody)
Summary: Plugin Loading: activate optional dependencies

Initial Comment:
If a plugin has optional dependencies, they should be activated just like the non-optional dependencies,
when the plugin is activated.


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

>Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-31 18:20

Message:
Are you sure about that? If you wrote this just to eliminate the edit bus
message "instanceof" issue, then I don't think this is necessarily right.
Maybe an optional dependency should have two types:
- always activate optional dependency before (if exists)
- do not activate optional dependency before

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

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

Bugs item #2830371, was opened at 2009-07-31 08:16
Message generated for change (Tracker Item Submitted) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2830371&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 API
Group: None
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Alan Ezust (ezust)
Assigned to: Nobody/Anonymous (nobody)
Summary: Plugin Loading: activate optional dependencies

Initial Comment:
If a plugin has optional dependencies, they should be activated just like the non-optional dependencies,
when the plugin is activated.


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

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

Hi,

Before I dive into details, please avoid checking the types of edit
bus messages of other plugins using "instanceof", such as:

  void handleMessage(EBMessage message)
  {
    if (message instanceof ProjectUpdate)
      ...
  }

Instead, use something like:

  void handleMessage(EBMessage message)
  {
    if (message.getClass().getName().endsWith("ProjectUpdate"))
      ...
  }

Why? The "instanceof" version can cause the other plugin to be loaded
- i.e. if the plugin which defines the message type (ProjectViewer in
this case) is not loaded, the JARClassLoader will be invoked to load
it. And one of the first things that JARClassLoader does is activate
the plugin. All this can happen just because the type of the edit bus
message was checked - not because the plugin really had to be loaded
(or activated).
The problem is a lot worse than just wasting resources. In the above
example, ProjectViewer will be loaded (if it wasn't loaded before) and
activated. Part of the activation is instantiating the plugin and
calling its "start" method. In the case of ProjectViewer, this will
also cause an edit bus message (ProjectUpdate) to be sent. Then, the
above 'handleMessage' will be called again, recursively, and will
check again if the message is "instanceof ProjectUpdate". Since the
JARClassLoader that was invoked to load the ProjectViewer hasn't
returned yet, the ProjectViewer is considered as currently being
loaded, but not loaded yet. So this recursive invocation of
"handleMessage" will generate a "ClassCircularityError" exception, and
I am not sure what the consequences are.

Instead of using "instanceof", which might load and activate the
plugin, it should be safe to use "message.getClass().getName()" and
check if the name is the type we expect. This will not cause the
plugin to be loaded. Perhaps at some point we'll add something to the
JARClassLoader to take care of this (if possible), but until then,
please avoid using "instanceof" with classes of other plugins.

Note that the danger is only for plugins that might not yet be loaded
when this edit bus message is sent. If you are sure that the other
plugin is already loaded, there is no problem with using "instanceof".

Thanks,
Shlomy

Plugin Bugs item #2828947, was opened at 2009-07-29 15:23
Message generated for change (Settings changed) made by shlomy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=2828947&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: Jocelyn Turcotte (jturcotte)
>Assigned to: Shlomy Reinstein (shlomy)
Summary: CtagsInterface - NPE on a clean setup

Initial Comment:
I got this error on 1.0 and 0.1

The plugin raise the following error and refuse to work or allow source tree configuration in the options pane:
1:55:56 PM [main] [error] main: java.lang.NullPointerException
1:55:56 PM [main] [error] main:  at java.lang.Class.forName0(Native Method)
1:55:56 PM [main] [error] main:  at java.lang.Class.forName(Class.java:169)
1:55:56 PM [main] [error] main:  at ctagsinterface.db.TagDB.<init>(TagDB.java:83)
1:55:56 PM [main] [error] main:  at ctagsinterface.main.CtagsInterfacePlugin.start(CtagsInterfacePlugin.java:63)
1:55:56 PM [main] [error] main:  at org.gjt.sp.jedit.PluginJAR.startPlugin(PluginJAR.java:1391)
1:55:56 PM [main] [error] main:  at org.gjt.sp.jedit.PluginJAR.activatePlugin(PluginJAR.java:752)
1:55:56 PM [main] [error] main:  at org.gjt.sp.jedit.PluginJAR.activatePluginIfNecessary(PluginJAR.java:822)
1:55:56 PM [main] [error] main:  at org.gjt.sp.jedit.jEdit.main(jEdit.java:482)

To reproduce:
- Rename you ~/.jedit directory
- Install the plugin

Workaround:
Edit ~/.jedit/properties and add the line 
options.CtagsInterface.dbSelectedPreset=hsqldb

The user should normally be able to chose the preset through the Change database settings dialog, however the Ok button do not work.

I guess that this property should have a default value.


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

>Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-31 15:28

Message:
Fixed in SVN rev. 15830.

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

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: editor core
Group: normal bug
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Boz Hogan (bozhogan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Custom Tab size not used for multiline tabbing

Initial Comment:
I'm new to jEdit.  I set my tab size to 4 spaces.  This works fine, until I try to increase the indent on many lines at once.  When I highlight a section of code and then press the TAB key, it indents every highlighted line 8 spaces instead of 4. I.e. it's ignoring the custom setting.

The result is that when I need to take a large section of code and enclose it in another construct like an if-block or while-loop etc. , I need to go through and add another tab to each line manually in order to maintain consistent format and readability. 

PS.  As a new user, it was hard to report the bug.  I had to sign up for jEdit Community (up to 24 hour wait) and then sign up for sourceforge.  Not a huge problem, but kind of a pain.

TY, and great product so far!

Thanks,
Boz

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

>Comment By: Boz Hogan (bozhogan)
Date: 2009-07-31 07:18

Message:
Thanks for the response.  I'm on the road, so I'll get back to you in a
couple days.

TY

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-30 20:48

Message:
Can you provide precise steps to reproduce what you see? (starting from an
empty buffer, or loading a file that you attach)
This will enable us to understand what the problem is exactly.
Thanks.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-24 09:30

Message:
I'd like to eliminate some misunderstanding here: The tab size you specify
in the options is not necessarily the indentation that will be used when
you select a line (or several) and click <tab>. When you click <tab>, the
auto-indent rules apply, and in most cases these rules do a lot more than
just add a tab.

The tab size you specify will be used when you click <tab> IF the selected
lines are at the top of the file (and thus, not influenced by previous
lines), or otherwise if the auto-indent rules specify that the selected
lines should be indented one level deeper than the previous non-empty
line.
Note that the options do not apply to existing text, they only apply to
new text you add, or to lines that you select and apply the
auto-indentation on.
So, for example, if you had a file that was created by some other editor,
or with other indentation options, changing the tab size won't have any
effect unless you actually select existing lines and invoke the auto-indent
action. So, if the nesting construct (e.g. "if") was indented with spaces,
you may not get the behavior you expect when indenting the lines inside the
construct.

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

Comment By: Alan Ezust (ezust)
Date: 2009-07-23 23:35

Message:
1. how did you set the tab size? in buffer options, or in global options -
editing? Buffer options only applies to that buffer and gets reset after
save/load.
2. If in global options - editing, did you set it for all modes, or just
one mode?
3. If not set for all modes, were you editing a file of the mode for which
you set the tab stop?




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

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

Plugin Bugs item #2829000, was opened at 2009-07-29 17:00
Message generated for change (Settings changed) made by shlomy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=2829000&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: Bertalan Fodor (fodber)
Assigned to: Shlomy Reinstein (shlomy)
Summary: MyDoggy doesn't send DockableWindowUpdate messages

Initial Comment:
If I use the MyDoggy dockable framework, then DockableWindowUpdate ACTIVATE and DEACTIVE messages are not sent to the EditBus.

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

>Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-31 13:56

Message:
Fixed in SVN rev. 15829. (In MyDoggyPlugin)

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

Comment By: Bertalan Fodor (fodber)
Date: 2009-07-31 09:17

Message:
I beleive it is a synchronization/threading question... 
If the PDF viewer dockable is created asynchronously to loading the buffer
and sending the BufferUpdate.LOADED message, then the PDF will be loaded
automatically only if the dockable is accidentally created before the
buffer load.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-30 22:34

Message:
I tried this scenario, and seems to me that it worked fine...

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

Comment By: Bertalan Fodor (fodber)
Date: 2009-07-30 22:31

Message:
Well, it won't break, certainly. See in the previous comment:
- open a LilyPond file, process it, open and dock the PDF preview. The PDF
appears
- restart jEdit - the PDF should be automatically displayed

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-30 20:54

Message:
I just tried LilyPondTool with MyDoggyPlugin, and it seems to be working
fine without the EditBus messages from the DockableWindowManager. Can you
show a scenario where it doesnt?

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

Comment By: Bertalan Fodor (fodber)
Date: 2009-07-30 13:15

Message:
Yes.
http://lily4jedit.svn.sourceforge.net/viewvc/lily4jedit/trunk/LilyPondTool/src/lilytool/pdf/dockable/DockablePdfViewer.java
Actually I'm waiting for the DockableWindowUpdate.ACTIVATED message :) 
Some example scenarios:
1. jEdit opens -> the dockable window should the current buffer
2. Have 2 buffers opened. Buffer1 is displayed in the dockable. Hide the
dockable, change to buffer2, show the dockable -> the dockable should
automatically display buffer2.

So I need a message before the dockable window's paint method is called.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-30 13:08

Message:
Can you be more specific - which EditBus messages are you expecting? And is
this different between MyDoggy and the core docking framework? As far as I
know both use lazy instantiation - they do not create the dockable panel
until it is first used.

Also, is your plugin source code available in SVN? Perhaps I can check it
myself to see all the problems?

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

Comment By: Bertalan Fodor (fodber)
Date: 2009-07-30 12:40

Message:
I've got another serious problem with that: the dockable window doesn't get
the startup messages. 
I do need to do some activity right after the initial view and buffers
opened. But it seems that the dockable window doesn't get any message that
it is now visible. 

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

Comment By: Bertalan Fodor (fodber)
Date: 2009-07-30 12:08

Message:
Yes, the notification would be better, but if the dockableWindowVisible is
working, then I could live with them. 
My only problem is about more than one instance, but that's a separate
story.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-30 12:03

Message:
That's what I was about to offer, but then I realized that this is not a
state check, but rather an event notification that is needed here.

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

Comment By: Romain Francois (rfrancois)
Date: 2009-07-30 11:59

Message:
Are you looking for the "isDockableWindowVisible" method of the
DockableWindowManager class. 

public abstract boolean isDockableWindowVisible(String name);
	

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

Comment By: Bertalan Fodor (fodber)
Date: 2009-07-30 11:47

Message:
That's fine.
I actually need to know when the dockable panel is itself visible. 

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-30 11:45

Message:
In the DockableWindowManager (the core docking framework), it is very
simple to know when a dockable is active. MyDoggyPlugin offers some
features that make it difficult to know. During startup, there is lazy
instantiation of dockables, so until the dockable contents is actually used
for the first time, it can be considered inactive. But once activated the
first time, there is no real "deactivation", unless the dockable is really
removed, as it can be laid out in different ways with other dockables, and
you can also see a "shadow preview" of the dockable without actually making
it visible by hovering on its button.

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

Comment By: Bertalan Fodor (fodber)
Date: 2009-07-30 10:05

Message:
I have a dockable PDF viewer in LilyPondTool plugin, which displays to
rendered version of the current file. Opening and decoding the PDF file is
resource-intensive, so I want to open only when the PDF viewer is activated
or is already displayed. So I need to check for activation and deactivation
of the viewer. 

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-29 17:40

Message:
Do you need them for your dockables? Can you be specific on what messages
you expect? MyDoggy, as well as other modern docking frameworks, are much
more flexible than the jEdit core docking framework and offer many
situations that are impossible in the core framework.


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

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

Bugs item #2818327, was opened at 2009-07-08 06:25
Message generated for change (Comment added) made by shlomy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2818327&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: Shlomy Reinstein (shlomy)
Summary: Plugin Error Dialog issues

Initial Comment:
When a plugin fails to load at startup, a plugin error is generated like this:
8:23:11 PM [main] [debug] EditBus: PluginUpdate[what=LOADED,exit=false,source=/home/ezust/.jedit/jars/mydoggy-plaf-1.5.0.jar]
8:23:11 PM [main] [error] ErrorListDialog$ErrorEntry: /home/ezust/.jedit/jars/Navigator.jar:
8:23:11 PM [main] [error] ErrorListDialog$ErrorEntry: Requires version 0.6 or later of code2html.Code2HTMLPlugin,
8:23:11 PM [main] [error] ErrorListDialog$ErrorEntry: but code2html.Code2HTMLPlugin is not installed.
8:23:11 PM [main] [debug] SplashScreen: init plugins:356ms

An error dialog pops up, which has no way of copying the message into the clipboard. But no error is logged in the "errors" status bar widget.

If the error was logged properly and could be seen again from the "errors" that would be nice.
Either that, or the copy to clipboard should be enabled from the textarea in the dialog.


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

>Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-31 13:20

Message:
Fixed in SVN rev. 15827.
I changed the plugin error dialog to use a text pane, from which the text
can be copied. The alternative, making these messages available using the
error status bar widget, is not appropriate, as it is meant for exceptions
and not for error messages that are handled by jEdit.

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

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

Plugin Central Submission item #2830169, was opened at 2009-07-31 10:18
Message generated for change (Tracker Item Submitted) made by kpouer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=625093&aid=2830169&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: Matthieu Casanova (kpouer)
Assigned to: Nobody/Anonymous (nobody)
Summary: BufferTabs 1.1.1

Initial Comment:
{{{ BufferTabs 1.1.1
    Source: https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/BufferTabs/tags/BufferTabs-1.1.1
    Announcement: Updated for 4.3pre17 api compatibility
    Requires Java 1.5
    Requires jEdit 04.03.17.00
    
    Short Description: Show tabs to switch buffers
    
    Long Description: Show tabs to switch buffers
 }}}

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

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: search and replace
Group: normal bug
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ben Golding (bengolding)
Assigned to: Nobody/Anonymous (nobody)
Summary: Filename filter is case sensitive on Windows

Initial Comment:
Using 'search in: all buffers' with the filter {*.cpp,*.h,*.hpp} does not match *.H if the extension is in upper case.
I didn't check 'search in: directory' but assume this could have the same issue.

Probably the filter match should be case insensitive on OSs like Windows which have case insensitive filenames, i.e. *.h or *.H (in filter) should match *.h or *.H (either in open buffers or on disk).

---
Windows XP SP3
jEdit 4.3pre17
Java 1.6.0_14

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

>Comment By: Ben Golding (bengolding)
Date: 2009-07-31 08:41

Message:
There is support for NFS remote drives in recent versions of Windows I
think. I guess in your example *.h [case insensitive] would match both
files in the search.

If you add a checkbox in global options, please can you make the default
case-insensitive for Windows users? That is what they would normally
expect. For instance if I use File->Open and type 'JEDIT.BAT' I will open
the file 'jedit.bat'. If I File->Open again and type 'jEdit.bat' it will
not open another buffer because the file is already open.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-31 06:01

Message:
I am not really sure how to approach this. I think the case-sensitive
property belongs to the file system, not to the OS. But I don't really
know, can Windows mount an NFS directory as a drive letter? If so, what
happens on Windows if the NFS directory has two files with the same name
except that one is with uppercase and the other with lowercase?
In any case I can add an option (check-box) to make the file globs
case-insensitive, but then I need to think there this option should be
placed, it is probably not only for the search dialog.

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

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

Plugin Bugs item #2829000, was opened at 2009-07-29 16:00
Message generated for change (Comment added) made by fodber
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=2829000&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: Bertalan Fodor (fodber)
Assigned to: Shlomy Reinstein (shlomy)
Summary: MyDoggy doesn't send DockableWindowUpdate messages

Initial Comment:
If I use the MyDoggy dockable framework, then DockableWindowUpdate ACTIVATE and DEACTIVE messages are not sent to the EditBus.

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

>Comment By: Bertalan Fodor (fodber)
Date: 2009-07-31 08:17

Message:
I beleive it is a synchronization/threading question... 
If the PDF viewer dockable is created asynchronously to loading the buffer
and sending the BufferUpdate.LOADED message, then the PDF will be loaded
automatically only if the dockable is accidentally created before the
buffer load.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-30 21:34

Message:
I tried this scenario, and seems to me that it worked fine...

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

Comment By: Bertalan Fodor (fodber)
Date: 2009-07-30 21:31

Message:
Well, it won't break, certainly. See in the previous comment:
- open a LilyPond file, process it, open and dock the PDF preview. The PDF
appears
- restart jEdit - the PDF should be automatically displayed

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-30 19:54

Message:
I just tried LilyPondTool with MyDoggyPlugin, and it seems to be working
fine without the EditBus messages from the DockableWindowManager. Can you
show a scenario where it doesnt?

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

Comment By: Bertalan Fodor (fodber)
Date: 2009-07-30 12:15

Message:
Yes.
http://lily4jedit.svn.sourceforge.net/viewvc/lily4jedit/trunk/LilyPondTool/src/lilytool/pdf/dockable/DockablePdfViewer.java
Actually I'm waiting for the DockableWindowUpdate.ACTIVATED message :) 
Some example scenarios:
1. jEdit opens -> the dockable window should the current buffer
2. Have 2 buffers opened. Buffer1 is displayed in the dockable. Hide the
dockable, change to buffer2, show the dockable -> the dockable should
automatically display buffer2.

So I need a message before the dockable window's paint method is called.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-30 12:08

Message:
Can you be more specific - which EditBus messages are you expecting? And is
this different between MyDoggy and the core docking framework? As far as I
know both use lazy instantiation - they do not create the dockable panel
until it is first used.

Also, is your plugin source code available in SVN? Perhaps I can check it
myself to see all the problems?

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

Comment By: Bertalan Fodor (fodber)
Date: 2009-07-30 11:40

Message:
I've got another serious problem with that: the dockable window doesn't get
the startup messages. 
I do need to do some activity right after the initial view and buffers
opened. But it seems that the dockable window doesn't get any message that
it is now visible. 

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

Comment By: Bertalan Fodor (fodber)
Date: 2009-07-30 11:08

Message:
Yes, the notification would be better, but if the dockableWindowVisible is
working, then I could live with them. 
My only problem is about more than one instance, but that's a separate
story.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-30 11:03

Message:
That's what I was about to offer, but then I realized that this is not a
state check, but rather an event notification that is needed here.

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

Comment By: Romain Francois (rfrancois)
Date: 2009-07-30 10:59

Message:
Are you looking for the "isDockableWindowVisible" method of the
DockableWindowManager class. 

public abstract boolean isDockableWindowVisible(String name);
	

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

Comment By: Bertalan Fodor (fodber)
Date: 2009-07-30 10:47

Message:
That's fine.
I actually need to know when the dockable panel is itself visible. 

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-30 10:45

Message:
In the DockableWindowManager (the core docking framework), it is very
simple to know when a dockable is active. MyDoggyPlugin offers some
features that make it difficult to know. During startup, there is lazy
instantiation of dockables, so until the dockable contents is actually used
for the first time, it can be considered inactive. But once activated the
first time, there is no real "deactivation", unless the dockable is really
removed, as it can be laid out in different ways with other dockables, and
you can also see a "shadow preview" of the dockable without actually making
it visible by hovering on its button.

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

Comment By: Bertalan Fodor (fodber)
Date: 2009-07-30 09:05

Message:
I have a dockable PDF viewer in LilyPondTool plugin, which displays to
rendered version of the current file. Opening and decoding the PDF file is
resource-intensive, so I want to open only when the PDF viewer is activated
or is already displayed. So I need to check for activation and deactivation
of the viewer. 

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-29 16:40

Message:
Do you need them for your dockables? Can you be specific on what messages
you expect? MyDoggy, as well as other modern docking frameworks, are much
more flexible than the jEdit core docking framework and offer many
situations that are impossible in the core framework.


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

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: search and replace
Group: normal bug
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ben Golding (bengolding)
Assigned to: Nobody/Anonymous (nobody)
Summary: Filename filter is case sensitive on Windows

Initial Comment:
Using 'search in: all buffers' with the filter {*.cpp,*.h,*.hpp} does not match *.H if the extension is in upper case.
I didn't check 'search in: directory' but assume this could have the same issue.

Probably the filter match should be case insensitive on OSs like Windows which have case insensitive filenames, i.e. *.h or *.H (in filter) should match *.h or *.H (either in open buffers or on disk).

---
Windows XP SP3
jEdit 4.3pre17
Java 1.6.0_14

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

>Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-31 08:01

Message:
I am not really sure how to approach this. I think the case-sensitive
property belongs to the file system, not to the OS. But I don't really
know, can Windows mount an NFS directory as a drive letter? If so, what
happens on Windows if the NFS directory has two files with the same name
except that one is with uppercase and the other with lowercase?
In any case I can add an option (check-box) to make the file globs
case-insensitive, but then I need to think there this option should be
placed, it is probably not only for the search dialog.

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

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

Bugs item #2821103, was opened at 2009-07-14 08:22
Message generated for change (Comment added) made by shlomy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2821103&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: editor core
Group: normal bug
Status: Open
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Chris Velevitch (cv105)
Assigned to: Nobody/Anonymous (nobody)
Summary: Autoreload without notification does not work

Initial Comment:
1. Only works the first time the file changes after you've set the option.
2. The option is not saved when you exit and run jEdit again.
3. Nothing happens if jEdit doesn't have application focus.

jEdit 4.3pre17 server mode, Java 1.6.0_11, Win XP Pro sp3

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

>Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-31 07:30

Message:
How do you suggest to handle this item? Maybe keep the value in memory when
reloading, restoring it after reload?

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-22 10:26

Message:
Not exactly. You may want to have one general reload behavior (e.g. always
reload without notification), but for a specific buffer, you may want to
trigger this off, and not have it reload.
And once you've specified using the Buffer Options that you don't want
auto-reload for a specific buffer, you may at some point want to switch it
back to the global option again. That's why the combo-box is there I think.

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

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

Message:
why the @#$@#$!! are there buffer options for buffer reloading behavior at
all, when all buffer options get reset on reload every time? 
They don't belong there at all in the first place. It seems almost
paradoxical that they exist.



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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-22 10:13

Message:
I think you misunderstood the meaning of "Buffer Options". The options in
the "Buffer Options" dialog only hold for the current buffer, as long as it
remains open, and as long as it has not been reloaded. The first reload of
the buffer (even without restarting jEdit) causes these options to be reset
to the default.
Maybe the "auto-reload" option should be named differently or provide
different choices in the Buffer Options dialog, to eliminate such
confusion.

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

Comment By: Chris Velevitch (cv105)
Date: 2009-07-22 09:55

Message:
Buffer options is overriding the global options. And it's being reset to an
undesired setting everytime you start jEdit up.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-20 23:43

Message:
Gee, thanks, I'd never have noticed that... :) I didn't even know this
option was available as a buffer option.

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

Comment By: Robert Schwenn (rschwenn)
Date: 2009-07-20 23:33

Message:
Chris, You're referring to BUFFER options, and You described their designed
behavior:

Changes to buffer options are only valid for this buffer and they get lost
when re-loading the buffer (unless You're using the BufferLocal plugin or
have written some of them as text into the buffer).

Since You've told jEdit to "autoreload..." it the buffer options are
immediately reset after the file was changed and You returned to jEdit.

If You want to change this option globally, go to Utilities -> Global
Options -> General...


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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-20 08:34

Message:
I forgot, after exiting jEdit, please attach also the file "activity.log"
in the jEdit settings directory.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-20 08:34

Message:
Please set this option to "autoreload without notification", then exit
jEdit, and then attach to this item the file named "propertiles" in the
jEdit settings directory (which is by default ".jedit" under your home
directory, ~/.jEdit on Unix or "C:\Documents and
Settings\<username>\.jEdit" on Windows).
Thanks.

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

Comment By: Chris Velevitch (cv105)
Date: 2009-07-20 05:32

Message:
I change the buffer option to "autoreload without notification", then
change the file externally with another tool, it changes fine the first
time without popping up the dialog. Without exiting jEdit, change he same
file again externally with another tool, jEdit sees that the file has
changed, but the notification dialog pops up. When I recheck the buffer
option, it has been reset to "automatically reload and notify user"

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

Comment By: Chris Velevitch (cv105)
Date: 2009-07-20 05:23

Message:
Every time I start jEdit the buffer option is always set to "automatically
reload and notify user". I change it to "autoreload without notification"
and then exit. Then I start it again, it's still says "automatically reload
and notify user". It doesn't seem to save the buffer option.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-07-19 21:51

Message:
I cannot reproduce this. Please do the following:
- Verify that the option "Check for file change upon:" has the value that
you expect. This determines when jEdit changes if a file has to be
reloaded.
- After setting the option "Autoreload without notifications", please
attach your "properties" file (in the jEdit settings directory) to this
item.


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

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

Mostly why I brought this up again is to find out the latest from Apple 
and if it would impact users.  It sounds like quite a few people would 
be left behind.  It turns out it isn't too hard to set up jEdit to run 
on Java 1.6 but still put out Java 1.5 class files. 

Dale



Alan Ezust wrote:
> It is very easy to allow for multiple released versions (branches)
> with different dependencies. We already have that for jedit 4.2 and
> 4.3preXX.
> In the case of some plugins, there are 3 branches already, as with
> Console (there is a java 1.4 branch that contains the latest version
> to support java 1.4).
>
>
>
> On Thu, Jul 30, 2009 at 3:27 PM, Shlomy Reinstein<sre...@gm...> wrote:
>   
>> Hi,
>>
>> Forwarding this to the list... Can anyone answer the question about
>> multiple released versions? I don't know about this myself.
>>
>> If the answer is yes, then we can possibly have 2 different branches
>> on such plugins, where one branch will be used for releasing the 1.6
>> version and the other will be used for releasing the 1.5 version. But
>> someone will need to do the backporting job...
>>     
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>