jedit-devel Mailing List for jEdit

www.activeclickweb.com/java/jedit

It works and it works well.  On the above web page you will find a 
download for the binaries.
In the zip are three files
1. jedit.exe - the launcher
2. jedit.reg - registry change to get the right click menu option.  You 
will have to edit the file and change to where you put the jedit.exe
3. launch.properties - properties file that tells the launcher where to 
find your jvm and the jedit.jar file.

Right now the launcher just takes a list of files to have jedit open.  
I'll add a -diff option as soon as the diff plugin is fixed.

I've tested it with chinese characters in the file path and it opens 
those files as well.

The thing it lacks is a property setting to customize the jvm options.  
I'll add this in the next day or two and post it on my page.  Then I'll 
attempt to port it to Linux.

Brian

Bugs item #982899, was opened at 2004-06-30 10:58
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=982899&group_id=588

Category: text area and syntax packages
Group: minor bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Single Selection Text Area Color not working

Initial Comment:
jEdit 4.2pre14 on OS X 10.3.4

When I change the color of the "Single Selection" under the "Text 
Area" preference, it does not take effect.  The color on the 
preference page changes, but there is actually no change to the 
color when selecting items.

Additionally, when I close and reopen preferences, the Single 
Selection color reverts to the original color.  FYI -- original color is 
RGB 0,0,128

Thanks!

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

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

Okay, if anyone is interested, I finished the changes and checked them
into jEdit cvs, the module is plugins/BufferLocal. I added a menu item to
close the stale buffers on demand rather than automatically, which I think
is a lot better than auto-closing, but auto-closing is there too.

Dale


> Yeah, but I write plugins to do what _I_ want :)
>
> Seriously, I thought it would be handy, but now I don't. That doesn't mean
> others wouldn't find it useful. I added an option pane to the plugin so
> the automatic buffer closing can be turned off and the time limit for how
> long a file can stay open without being looked at can be set. I've got a
> bit of refactoring to do, then I'll check in the changes to cvs when I'm
> done testing and post a note here.
>
> Dale
>
>
>>            Just because it is annoying to some does not mean it
>> shouldn't
>> be there.  Just make it an option that you can turn on or off.
>>
>>  Brian
>>
>>  da...@ge... wrote:
>>     I'd be interested too. I resurrected the old code for BufferLocal
>> last
>> night, not much to it. It would be interesting to see how yours would
>> work. I still find the automatically closing buffers more annoying
>> than useful, I think something along the lines of a button or menu
>> item to click to close stale buffers would be more useful.
>> Patrick Wright wrote:                 My current idea is not to add
>> this to the existing (3? 4?) buffer-management plugins, but just to
>> have a simple little plugin that tracks these timestamps for buffers,
>> which can then be used from macros as necessary--the macro just needs
>> the times, it can do what it wants afterwards.                 Well, a
>> plugin only for storing the timestamps is even less functionality then
>> the macro. I'd think this small plugin can also implement the actual
>> closing of the old buffers. This gives you the possibility to
>> automatically close the old inactive buffers, without the user
>> explicilitly requesting that.                  I am testing a plugin
>> locally that does just that.                 Cool, I'd be interested.
>> Alex  -- Alexander Klimetschek
>> ------------------------------------------------------- This SF.Net
>> email sponsored by Black Hat Briefings & Training. Attend Black
>> Hat Briefings & Training, Las Vegas July 24-29 -  digital self
>> defense, top technical experts, no vendor pitches,  unmatched
>> networking opportunities. Visit www.blackhat.com
>> ------------------------------------------------------- This SF.Net
>> email sponsored by Black Hat Briefings & Training. Attend Black Hat
>> Briefings & Training, Las Vegas July 24-29 -  digital self defense,
>> top technical experts, no vendor pitches,  unmatched networking
>> opportunities. Visit www.blackhat.com --
>> ----------------------------------------------- jEdit Developers' List
>> jEd...@li...
>> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> --
> -----------------------------------------------
> jEdit Developers' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Project Viewer 2.0.3 running on JEdit 4.1 final

Initial Comment:
sp_...@ea...

I am having serious trouble with this update to the
plugin on both my Win2K machine at work and my Mac OS X
10.2 machine at home.  In both places I am running
JEdit 4.1 final, and in both places I had the plugin
installed in my local directory.  In both places I have
it running docked on the left.

However upon install this updated plugin, I get this
nasty message in the activity log.  At times I was also
getting an error dialog, but that does not seem to
happen (or at least I can't see it).  My entire JEdit
app no longer is repainted because this error comes up
(when the mouse goes over the buttons, they repaint),
so I have to uninstall Project Viewer to even get a
proper JEdit session open where I can see the menus.

I just looked through the source code for both the
Plugin and JEdit4.1 final.  This call to the
jEdit.getPlugin(String s) method is called.  It does
not exist in 4.1.  It appears to be called when there
is a problem in a BeanShell script.  Perhaps the method
exists in JEdit 4.2?

[error] AWT-EventQueue-0: java.lang.NoSuchMethodError:
org.gjt.sp.jedit.jEdit.getPlugin(Ljava/lang/String;Z)Lorg/gjt/sp/jedit/EditPlugin;
[error] AWT-EventQueue-0: 	at
projectviewer.vpt.IconComposer$Helper.getMessageState(Unknown
Source)
[error] AWT-EventQueue-0: 	at
projectviewer.vpt.IconComposer.composeIcon(Unknown Source)
[error] AWT-EventQueue-0: 	at
projectviewer.vpt.VPTFile.getIcon(Unknown Source)
[error] AWT-EventQueue-0: 	at
projectviewer.vpt.VPTCellRenderer.getTreeCellRendererComponent(Unknown
Source)
[error] AWT-EventQueue-0: 	at
javax.swing.plaf.basic.BasicTreeUI$NodeDimensionsHandler.getNodeDimensions(BasicTreeUI.java:2729)
[error] AWT-EventQueue-0: 	at
javax.swing.tree.AbstractLayoutCache.getNodeDimensions(AbstractLayoutCache.java:478)
[error] AWT-EventQueue-0: 	at
javax.swing.tree.VariableHeightLayoutCache$TreeStateNode.updatePreferredSize(VariableHeightLayoutCache.java:1342)
[error] AWT-EventQueue-0: 	at
javax.swing.tree.VariableHeightLayoutCache$TreeStateNode.expand(VariableHeightLayoutCache.java:1478)
[error] AWT-EventQueue-0: 	at
javax.swing.tree.VariableHeightLayoutCache.treeStructureChanged(VariableHeightLayoutCache.java:648)
[error] AWT-EventQueue-0: 	at
javax.swing.plaf.basic.BasicTreeUI$TreeModelHandler.treeStructureChanged(BasicTreeUI.java:2467)
[error] AWT-EventQueue-0: 	at
javax.swing.tree.DefaultTreeModel.fireTreeStructureChanged(DefaultTreeModel.java:561)
[error] AWT-EventQueue-0: 	at
javax.swing.tree.DefaultTreeModel.nodeStructureChanged(DefaultTreeModel.java:345)
[error] AWT-EventQueue-0: 	at
projectviewer.ProjectViewer.nodeStructureChanged(Unknown
Source)
[error] AWT-EventQueue-0: 	at
projectviewer.vpt.VPTSelectionListener.mousePressed(Unknown
Source)
[error] AWT-EventQueue-0: 	at
java.awt.AWTEventMulticaster.mousePressed(AWTEventMulticaster.java:218)
[error] AWT-EventQueue-0: 	at
java.awt.AWTEventMulticaster.mousePressed(AWTEventMulticaster.java:217)
[error] AWT-EventQueue-0: 	at
java.awt.AWTEventMulticaster.mousePressed(AWTEventMulticaster.java:217)
[error] AWT-EventQueue-0: 	at
java.awt.Component.processMouseEvent(Component.java:5018)
[error] AWT-EventQueue-0: 	at
java.awt.Component.processEvent(Component.java:4818)
[error] AWT-EventQueue-0: 	at
java.awt.Container.processEvent(Container.java:1380)
[error] AWT-EventQueue-0: 	at
java.awt.Component.dispatchEventImpl(Component.java:3526)
[error] AWT-EventQueue-0: 	at
java.awt.Container.dispatchEventImpl(Container.java:1437)
[error] AWT-EventQueue-0: 	at
java.awt.Component.dispatchEvent(Component.java:3367)
[error] AWT-EventQueue-0: 	at
java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3214)
[error] AWT-EventQueue-0: 	at
java.awt.LightweightDispatcher.processMouseEvent(Container.java:2926)
[error] AWT-EventQueue-0: 	at
java.awt.LightweightDispatcher.dispatchEvent(Container.java:2859)
[error] AWT-EventQueue-0: 	at
java.awt.Container.dispatchEventImpl(Container.java:1423)
[error] AWT-EventQueue-0: 	at
java.awt.Window.dispatchEventImpl(Window.java:1566)
[error] AWT-EventQueue-0: 	at
java.awt.Component.dispatchEvent(Component.java:3367)
[error] AWT-EventQueue-0: 	at
java.awt.EventQueue.dispatchEvent(EventQueue.java:445)
[error] AWT-EventQueue-0: 	at
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:190)
[error] AWT-EventQueue-0: 	at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:144)
[error] AWT-EventQueue-0: 	at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
[error] AWT-EventQueue-0: 	at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:130)
[error] AWT-EventQueue-0: 	at
java.awt.EventDispatchThread.run(EventDispatchThread.java:98)

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

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

Plugin Bugs item #981992, was opened at 2004-06-29 11:02
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=981992&group_id=588

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dimitri Tarassenko (m1tk4)
Assigned to: Nobody/Anonymous (nobody)
Summary: PHPParser: @define(...) gives error

Initial Comment:
the following:

@define('SOME_CONST', 2);

brings up

"Unhandled error please report the bug"



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

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Good answer.<br>
<br>
But the reason I broke plugins with what I did is not because of
dynamic loading.&nbsp; They broke because plugins were assuming the
functionality of the innards of jedit and attaching listeners and
inserting code in places they probably should not have.&nbsp; Allowing this
to happen and not providing a well defined boundary keeps good
functionality out of the core because changing it will break the world.<br>
<br>
Brian<br>
<br>
Nathan Tenney wrote:<br>
<blockquote cite="mid...@ep..."
 type="cite">
  <pre wrap="">On Tue, Jun 29, 2004 at 10:34:36AM -0600, Brian Hawkins wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">There seems to be a common theme of "Don't modify the core code" =-O

Why is this?  Now I do understand some of the reason behind this 
statement, but I'm wondering if it should be revised.  Because of this 
mentality I see plugins being written and in essence hacking into the 
core from the outside to get the information they want.  Because of this 
the system becomes brittle.  You change one thing in the core and half 
the plugins break.  This is bad.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
My take on this is that there are several reasons for this.  Slava runs jEdit in much the same manner as Linux runs Linux.  Basically, any core functionality changes have to have a good basis, and not only that, you have to be able to convince Slava that there is a good reason for the change.  Some seem to think that this makes changing the core functionality too difficult, so they code their stuff as plugins, which Slava encourages, as it helps keep down feature creep.  If some functionality in a plugin makes sense in the core, it eventually gets there anyway, but beginning life as a pluging give the feature time to mature.  Second, it takes time for features to get into the core.  For example, if you wanted to add the buffer modified time stamp as a core feature, it wouldn't make it into 4.2, as its feature set is frozen.  You would have to wait until 4.3 began development.  Coding it as a plugin means it gets into common usage sooner, and then has a chance to migrate to t
he core, if that makes sense.

  </pre>
  <blockquote type="cite">
    <pre wrap="">The core should have a well defined public interface that should be used 
by plugins.  No assumptions should be made about the internal workings 
of the core.  This makes a very clear line of what is supported and what 
isn't.  Then changes to the core to make it better can be done more easily.

    </pre>
  </blockquote>
  <pre wrap=""><!---->I belive that jEdit already has a richly defined public interface for plugins.  The reason for plugins breaking with the 4.2 release, is that there was a wild departure from the 4.1 plugin interface to allow for dynamic loading of plugins.  This was something that had been discussed for several versions of jEdit, and Slava resisted putting it in for a while because of the potential for breaking plugins, and the massive changes it would require.  I suspect that he also wanted to take the time to do the best design job possible, because it was such a major departure from the previous implementation.


  </pre>
</blockquote>
</body>
</html>

On Tue, Jun 29, 2004 at 10:34:36AM -0600, Brian Hawkins wrote:
> There seems to be a common theme of "Don't modify the core code" =3D-O
>=20
> Why is this?  Now I do understand some of the reason behind this=20
> statement, but I'm wondering if it should be revised.  Because of this=20
> mentality I see plugins being written and in essence hacking into the=20
> core from the outside to get the information they want.  Because of this=
=20
> the system becomes brittle.  You change one thing in the core and half=20
> the plugins break.  This is bad.

My take on this is that there are several reasons for this.  Slava runs jEd=
it in much the same manner as Linux runs Linux.  Basically, any core functi=
onality changes have to have a good basis, and not only that, you have to b=
e able to convince Slava that there is a good reason for the change.  Some =
seem to think that this makes changing the core functionality too difficult=
, so they code their stuff as plugins, which Slava encourages, as it helps =
keep down feature creep.  If some functionality in a plugin makes sense in =
the core, it eventually gets there anyway, but beginning life as a pluging =
give the feature time to mature.  Second, it takes time for features to get=
 into the core.  For example, if you wanted to add the buffer modified time=
 stamp as a core feature, it wouldn't make it into 4.2, as its feature set =
is frozen.  You would have to wait until 4.3 began development.  Coding it =
as a plugin means it gets into common usage sooner, and then has a chance t=
o migrate to the core, if that makes sense.

>=20
> The core should have a well defined public interface that should be used=
=20
> by plugins.  No assumptions should be made about the internal workings=20
> of the core.  This makes a very clear line of what is supported and what=
=20
> isn't.  Then changes to the core to make it better can be done more easil=
y.
>=20
I belive that jEdit already has a richly defined public interface for plugi=
ns.  The reason for plugins breaking with the 4.2 release, is that there wa=
s a wild departure from the 4.1 plugin interface to allow for dynamic loadi=
ng of plugins.  This was something that had been discussed for several vers=
ions of jEdit, and Slava resisted putting it in for a while because of the =
potential for breaking plugins, and the massive changes it would require.  =
I suspect that he also wanted to take the time to do the best design job po=
ssible, because it was such a major departure from the previous implementat=
ion.


--=20
IANAL -- But I play one on /.

----------------------------------
Nathan Tenney
Alumni Utah State University
eu...@ya...
----------------------------------

I have it working, but am travelling tomorrow, so can't post till
Tuesday...it is a pretty simple thing, kind of overkill for a plugin, but
what the hell, the world is young. Will let you know when it is there.

> I'd be interested too. I resurrected the old code for BufferLocal last
> night, not much to it. It would be interesting to see how yours would
> work. I still find the automatically closing buffers more annoying than
> useful, I think something along the lines of a button or menu item to
> click to close stale buffers would be more useful.
>
>
>> Patrick Wright wrote:
>>> My current idea is not to add this to the existing (3? 4?)
>>> buffer-management plugins, but just to have a simple little plugin th=
at
>>> tracks these timestamps for buffers, which can then be used from macr=
os
>>> as
>>> necessary--the macro just needs the times, it can do what it wants
>>> afterwards.
>>
>> Well, a plugin only for storing the timestamps is even less
>> functionality then the macro. I'd think this small plugin can also
>> implement the actual closing of the old buffers. This gives you the
>> possibility to automatically close the old inactive buffers, without t=
he
>> user explicilitly requesting that.
>>
>>> I am testing a plugin locally that does just that.
>>
>> Cool, I'd be interested.
>>
>> Alex
>>
>> --
>> Alexander Klimetschek
>>
>> <kli...@t-...>
>>
>
>
>

Yeah, but I write plugins to do what _I_ want :)

Seriously, I thought it would be handy, but now I don't. That doesn't mean
others wouldn't find it useful. I added an option pane to the plugin so
the automatic buffer closing can be turned off and the time limit for how
long a file can stay open without being looked at can be set. I've got a
bit of refactoring to do, then I'll check in the changes to cvs when I'm
done testing and post a note here.

Dale


>            Just because it is annoying to some does not mean it shouldn't
> be there.  Just make it an option that you can turn on or off.
>
>  Brian
>
>  da...@ge... wrote:
>     I'd be interested too. I resurrected the old code for BufferLocal last
> night, not much to it. It would be interesting to see how yours would
> work. I still find the automatically closing buffers more annoying
> than useful, I think something along the lines of a button or menu
> item to click to close stale buffers would be more useful.
> Patrick Wright wrote:                 My current idea is not to add
> this to the existing (3? 4?) buffer-management plugins, but just to
> have a simple little plugin that tracks these timestamps for buffers,
> which can then be used from macros as necessary--the macro just needs
> the times, it can do what it wants afterwards.                 Well, a
> plugin only for storing the timestamps is even less functionality then
> the macro. I'd think this small plugin can also implement the actual
> closing of the old buffers. This gives you the possibility to
> automatically close the old inactive buffers, without the user
> explicilitly requesting that.                  I am testing a plugin
> locally that does just that.                 Cool, I'd be interested.
> Alex  -- Alexander Klimetschek
> ------------------------------------------------------- This SF.Net
> email sponsored by Black Hat Briefings & Training. Attend Black
> Hat Briefings & Training, Las Vegas July 24-29 -  digital self
> defense, top technical experts, no vendor pitches,  unmatched
> networking opportunities. Visit www.blackhat.com
> ------------------------------------------------------- This SF.Net
> email sponsored by Black Hat Briefings & Training. Attend Black Hat
> Briefings & Training, Las Vegas July 24-29 -  digital self defense,
> top technical experts, no vendor pitches,  unmatched networking
> opportunities. Visit www.blackhat.com --
> ----------------------------------------------- jEdit Developers' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Just because it is annoying to some does not mean it shouldn't be
there.&nbsp; Just make it an option that you can turn on or off.<br>
<br>
Brian<br>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:da...@ge...">da...@ge...</a> wrote:<br>
<blockquote cite="mid1386.67.165.117.7.1088533396.squirrel@67.165.117.7"
 type="cite">
  <pre wrap="">I'd be interested too. I resurrected the old code for BufferLocal last
night, not much to it. It would be interesting to see how yours would
work. I still find the automatically closing buffers more annoying than
useful, I think something along the lines of a button or menu item to
click to close stale buffers would be more useful.


  </pre>
  <blockquote type="cite">
    <pre wrap="">Patrick Wright wrote:
    </pre>
    <blockquote type="cite">
      <pre wrap="">My current idea is not to add this to the existing (3? 4?)
buffer-management plugins, but just to have a simple little plugin that
tracks these timestamps for buffers, which can then be used from macros
as
necessary--the macro just needs the times, it can do what it wants
afterwards.
      </pre>
    </blockquote>
    <pre wrap="">Well, a plugin only for storing the timestamps is even less
functionality then the macro. I'd think this small plugin can also
implement the actual closing of the old buffers. This gives you the
possibility to automatically close the old inactive buffers, without the
user explicilitly requesting that.

    </pre>
    <blockquote type="cite">
      <pre wrap="">I am testing a plugin locally that does just that.
      </pre>
    </blockquote>
    <pre wrap="">Cool, I'd be interested.

Alex

--
Alexander Klimetschek

<a class="moz-txt-link-rfc2396E" href="mailto:kli...@t-...">&lt;kli...@t-...&gt;</a>

    </pre>
  </blockquote>
  <pre wrap=""><!---->



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings &amp; Training.
Attend Black Hat Briefings &amp; Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit <a class="moz-txt-link-abbreviated" href="http://www.blackhat.com">www.blackhat.com</a>
  </pre>
</blockquote>
</body>
</html>

I'd be interested too. I resurrected the old code for BufferLocal last
night, not much to it. It would be interesting to see how yours would
work. I still find the automatically closing buffers more annoying than
useful, I think something along the lines of a button or menu item to
click to close stale buffers would be more useful.


> Patrick Wright wrote:
>> My current idea is not to add this to the existing (3? 4?)
>> buffer-management plugins, but just to have a simple little plugin that
>> tracks these timestamps for buffers, which can then be used from macros
>> as
>> necessary--the macro just needs the times, it can do what it wants
>> afterwards.
>
> Well, a plugin only for storing the timestamps is even less
> functionality then the macro. I'd think this small plugin can also
> implement the actual closing of the old buffers. This gives you the
> possibility to automatically close the old inactive buffers, without the
> user explicilitly requesting that.
>
>> I am testing a plugin locally that does just that.
>
> Cool, I'd be interested.
>
> Alex
>
> --
> Alexander Klimetschek
>
> <kli...@t-...>
>

It is interesting to watch the list and peoples views on how the code 
should change.

There seems to be a common theme of "Don't modify the core code" =-O

Why is this?  Now I do understand some of the reason behind this 
statement, but I'm wondering if it should be revised.  Because of this 
mentality I see plugins being written and in essence hacking into the 
core from the outside to get the information they want.  Because of this 
the system becomes brittle.  You change one thing in the core and half 
the plugins break.  This is bad.

The core should have a well defined public interface that should be used 
by plugins.  No assumptions should be made about the internal workings 
of the core.  This makes a very clear line of what is supported and what 
isn't.  Then changes to the core to make it better can be done more easily.

A good example of a hack job (although I must say a very clever hack 
job) is the buffer tabs plugin.  It wedges its code right in the middle 
of the core.

The reason for this rant is my attempt to make a MDI look for jEdit.  So 
far it works great except that half the plugins do not work.  The reason 
is that I change the model from one EditPane one TextView  many buffers 
to one EditPane many TextViews with one buffer each.

What I propose is this:
Information needed by plugins should be provide via public API's or the 
EditBus.  No attaching listeners to internal components of the core.  
This assumes how the internals work.

If information can be easily provide by the core and does not break 
other well defined functionality of the core, go ahead and add it.  This 
will more then likely benefit others as well.

If a plugin is to be written that changes core functionality (like 
buffer switchers).  This should be consumed by the core via a well 
defined interface/abstract class that is implemented/inherited by the 
plugin and then consumed via that interface by the core.

Core objects should be returned to plugins via an interface not the 
class itself.  This becomes the contract of how to use the object.  This 
then prevents someone from adding a text or focus listener to an object 
because they know it inherits from JComponent.  If a plugin needs this 
information it should be provide via the interface of the EditBus.  Then 
it becomes a self documented contract of what functionality is provided.

Okay I'm off my soap box and have dawned my rain slicker.  You may 
proceed with the throwing of rotten fruit.

Brian

Patrick Wright wrote:

> I am looking for an event or call or something that I can hook a plugin
> into, when JEdit has finished loading and finished loading any
> Buffers/EditPanes that were left open the last time it was closed. This to
> get the initial list of open Buffers, before anything else happens.

You don't need an event. Just call jEdit.getBuffers() inside the 
plugin's start() method. Plugins are loaded after all initial buffers 
are opened (their content might not be loaded yet - I don't know - but 
you can listen for the BufferUpdate.LOADED message on the EditBus).

Alex

-- 
Alexander Klimetschek

<kli...@t-...>

I am looking for an event or call or something that I can hook a plugin
into, when JEdit has finished loading and finished loading any
Buffers/EditPanes that were left open the last time it was closed. This t=
o
get the initial list of open Buffers, before anything else happens.

EditorStarted?


Thanks
Patrick

Patrick Wright wrote:
> My current idea is not to add this to the existing (3? 4?)
> buffer-management plugins, but just to have a simple little plugin that
> tracks these timestamps for buffers, which can then be used from macros as
> necessary--the macro just needs the times, it can do what it wants
> afterwards.

Well, a plugin only for storing the timestamps is even less 
functionality then the macro. I'd think this small plugin can also 
implement the actual closing of the old buffers. This gives you the 
possibility to automatically close the old inactive buffers, without the 
user explicilitly requesting that.

> I am testing a plugin locally that does just that.

Cool, I'd be interested.

Alex

-- 
Alexander Klimetschek

<kli...@t-...>

> Oddly enough, the BufferLocal plugin originally did just that -- it
> automatically closed buffers that had been opened but unused for a
> certain amount of time. The original name was "BufferMinderPlugin",
> which is where the "bmp" in the package name came from. That version wa=
s
> never actually released as it turned out that I didn't find the
> auto-close feature as handy as I'd thought it would be. However, it
> would be easy enough to add back in if others thought it would be usefu=
l.
>
> Getting a timestamp for when a buffer was opened, last viewable in an
> EditPane, changed (dirty), and so on is doable through the edit bus
> messages. I don't think it's necessary to have that as part of the
> Buffer class itself.
>
> Patrick, let me know if you're interested, and I'll add the
> functionality back into BufferLocal.

Dale

Interesting to know that BufferLocal used to have this behavior.

My feeling is this:
- the functionality best belongs in a script, as the rules for closing
windows should be changeable by individual users, without adding many
options to a plugin

- what we need in the core, or in a plugin, are just some additional
timestamps related to buffers

My current idea is not to add this to the existing (3? 4?)
buffer-management plugins, but just to have a simple little plugin that
tracks these timestamps for buffers, which can then be used from macros a=
s
necessary--the macro just needs the times, it can do what it wants
afterwards.

I am testing a plugin locally that does just that.

More discussion?
Patrick

Plugin Bugs item #981809, was opened at 2004-06-29 00:58
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=981809&group_id=588

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: PHPParser 1.0.0 unhandled error

Initial Comment:
This is kind of a silly little bug, but I'm just doign what it 
told me to, and reporting it.

the following source gives "Unhandled error please report 
the bug"

<?php
	for( $i = 0; $i++ )
	{
	}
?>

Doesn't seem to know what to do about an incomplete 
for(;;)

regards
joe...@ho...

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

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

At one stage, the server file format changed. The 'b' was added to make 
older versions of jEdit fail on loading it immediately, instead of 
trying to connect to an invalid socket etc. Consider it a version number...

Brian Hawkins wrote:
> Slava,
> 
> What is this line being added to the server file?
> out.write("b\n");
> 
> Copied from line 92 of EditServer.java
> 
> Brian
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital 
> self defense, top technical experts, no vendor pitches, unmatched 
> networking opportunities. Visit www.blackhat.com

Bugs item #981038, was opened at 2004-06-27 23:13
Message generated for change (Comment added) made by brianhks
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=981038&group_id=588

Category: editor core
Group: normal bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Ju-Myoung Kim (jmkim0913)
Assigned to: Nobody/Anonymous (nobody)
Summary: Right click open fail from Windows Explorer Korean

Initial Comment:
JE version: 4.1 final
OS: Windows2000
JVM: JavaTM 2 SDK, Standard Edition Version 1.4.2
Language: Korean

1. Open Windows Explorer.
2. Select a folder whose name contains Korean 
character.
3. Select a file.
4. Right click to open the file.
5. In JE, the Korean part of the path is changed to 
unreadable characters. (Refer to attachment)
6. The file open operation is failed.

Notes:
1. No problem with English path names.
2. No problem in opening the file through File System 
Browser of JE.

Thanks.


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

Comment By: Brian Hawkins (brianhks)
Date: 2004-06-28 10:26

Message:
Logged In: YES 
user_id=966362

I think the problem is in both the jedit core and the
launcher.  I'll look into this and how it works with the
launcher I've developed.  I'll post later with my findings.

Brian

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

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

Ciszkowski, Jacy wrote:

> Under Utilities->Globla Options-> Context Menu, you can add in
> shortcuts from macros, plugins etc...

thanks Jacy ... i see that.  However i want to add it programatically 
when my plugin is loaded.

Under Utilities->Globla Options-> Context Menu, you can add in shortcuts =
from macros, plugins etc...

-----Original Message-----
From: jed...@li...
[mailto:jed...@li...]On Behalf Of Alan
Williamson
Sent: Monday, June 28, 2004 3:46 PM
To: jed...@li...
Subject: [ jEdit-devel ] Right Hand Mouse Menu


Afternoon one and all.

I am the middle of developing a plugin for JEdit and i have to say to=20
being VERY impressed at the ease and power.  I am developing a debugger=20
and need to add an item to the right-hand-menu.

This is for when some clicks on a given part of the file to allow me to=20
set a breakpoint.

I can't see where i can do that.

:)

--=20
Alan Williamson, City Planner

w: http://www.BLOG-CITY.com/
e: al...@bl...
b: http://alan.blog-city.com/



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -=20
digital self defense, top technical experts, no vendor pitches,=20
unmatched networking opportunities. Visit www.blackhat.com
--=20
-----------------------------------------------
jEdit Developers' List
jEd...@li...
https://lists.sourceforge.net/lists/listinfo/jedit-devel

Afternoon one and all.

I am the middle of developing a plugin for JEdit and i have to say to 
being VERY impressed at the ease and power.  I am developing a debugger 
and need to add an item to the right-hand-menu.

This is for when some clicks on a given part of the file to allow me to 
set a breakpoint.

I can't see where i can do that.

:)

-- 
Alan Williamson, City Planner

w: http://www.BLOG-CITY.com/
e: al...@bl...
b: http://alan.blog-city.com/

Oddly enough, the BufferLocal plugin originally did just that -- it 
automatically closed buffers that had been opened but unused for a 
certain amount of time. The original name was "BufferMinderPlugin", 
which is where the "bmp" in the package name came from. That version was 
never actually released as it turned out that I didn't find the 
auto-close feature as handy as I'd thought it would be. However, it 
would be easy enough to add back in if others thought it would be useful.

Getting a timestamp for when a buffer was opened, last viewable in an 
EditPane, changed (dirty), and so on is doable through the edit bus 
messages. I don't think it's necessary to have that as part of the 
Buffer class itself.

Patrick, let me know if you're interested, and I'll add the 
functionality back into BufferLocal.

Dale


Patrick Wright wrote:

> I don't want to get into an argument...
> 
> 1) There are multiple buffer management plugins because people like
> different ways of viewing/conceptualizing and switching between multiple
> buffers. I guess you could create one plugin that was flexible enough to
> cover all these, but for some reason, no one has yet.
> 
> 2) My suggestion is that these two timestamps are two additional data
> points about a buffer that are useful to keep track of, in general,
> outside of this current use. I understand there are different ways to
> accomplish the same purpose...Another way to put it is, what should a
> Buffer be able to say about itself, what is essential to being a Buffer?
> 
> 
>>Patrick Wright wrote:
>>
>>
>>>My thought is that these timestamps are just two more points of
>>>information about a buffer that are currently not captured, and, were
>>>they
>>>captured, could be useful in general...
>>
>>It's easy for a plugin to do that. It just has to listen for the
>>open/save/close buffer events.
>>
>>
>>>Problem with adding it to buffer list is that there are several buffer
>>>managers in jEdit and we'd need to either choose just one to work with
>>>or
>>>add it to all of them.
>>
>>That's why I talked about the (non-existing) merged buffer-list plugin ;-)
>>
>>Alex
>>
>>--
>>Alexander Klimetschek
>>
>><kli...@t-...>
>>
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com

Slava,

What is this line being added to the server file?
out.write("b\n");

Copied from line 92 of EditServer.java

Brian

I don't want to get into an argument...

1) There are multiple buffer management plugins because people like
different ways of viewing/conceptualizing and switching between multiple
buffers. I guess you could create one plugin that was flexible enough to
cover all these, but for some reason, no one has yet.

2) My suggestion is that these two timestamps are two additional data
points about a buffer that are useful to keep track of, in general,
outside of this current use. I understand there are different ways to
accomplish the same purpose...Another way to put it is, what should a
Buffer be able to say about itself, what is essential to being a Buffer?

> Patrick Wright wrote:
>
>> My thought is that these timestamps are just two more points of
>> information about a buffer that are currently not captured, and, were
>> they
>> captured, could be useful in general...
>
> It's easy for a plugin to do that. It just has to listen for the
> open/save/close buffer events.
>
>> Problem with adding it to buffer list is that there are several buffer
>> managers in jEdit and we'd need to either choose just one to work with
>> or
>> add it to all of them.
>
> That's why I talked about the (non-existing) merged buffer-list plugin =
;-)
>
> Alex
>
> --
> Alexander Klimetschek
>
> <kli...@t-...>
>