Hi, here is my first patch to the core.
It will allow the VFSFileChooserDialog to choose several directories.
In fact by you can call it like that
GUIUtilities.showVFSFileDialog(null, currentPath,
VFSBrowser.CHOOSE_DIRECTORY_DIALOG, true);
but if you choose multiple directories you'll get an error telling you
that only 1 IO can be performed at the same time.
The change is : when you select several files it will not try to open
the folders, but it will returns you the directories you selected.
If there were no directories in your selection it will returns the
current directory of the browser.
I attached to the mail the diff file (I worked on CVS version 1.46)
Matthieu

Bugs item #1173630, was opened at 2005-03-30 23:29
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=1173630&group_id=588
Category: editor core
Group: normal bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Klimetschek (aklimets)
Assigned to: Nobody/Anonymous (nobody)
Summary: Exception in format paragraph if cursor at the end of para
Initial Comment:
jEdit Version: jedit 4.3pre2 (based on cvs)
Steps to reproduce:
1. Normal text file with a paragraph
2. Put the cursor at the end of the paragraph (after
the last char, at the end of the line)
3. Execure Edit -> Text -> Format Paragraph
4. Paragraph is correctly formatted but the exception
listed below is thrown.
Note: The 259 is the number of characters in the
current paragraph.
java.lang.StringIndexOutOfBoundsException: String index
out of range: 259
at java.lang.String.charAt(String.java:558)
at
org.gjt.sp.jedit.TextUtilities.ignoringWhitespaceIndex(TextUtilities.java:641)
at
org.gjt.sp.jedit.textarea.JEditTextArea.formatParagraph(JEditTextArea.java:4273)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at bsh.Reflect.invokeOnMethod(Reflect.java:149)
at bsh.Reflect.invokeObjectMethod(Reflect.java:81)
at bsh.Name.invokeMethod(Name.java:856)
at
bsh.BSHMethodInvocation.eval(BSHMethodInvocation.java:72)
at
bsh.BSHPrimaryExpression.eval(BSHPrimaryExpression.java:102)
at
bsh.BSHPrimaryExpression.eval(BSHPrimaryExpression.java:47)
at bsh.BSHBlock.evalBlock(BSHBlock.java:130)
at bsh.BSHBlock.eval(BSHBlock.java:80)
at bsh.BshMethod.invokeImpl(BshMethod.java:349)
at bsh.BshMethod.invoke(BshMethod.java:246)
at bsh.BshMethod.invoke(BshMethod.java:171)
at
org.gjt.sp.jedit.BeanShell.runCachedBlock(BeanShell.java:507)
at
org.gjt.sp.jedit.BeanShellAction.invoke(BeanShellAction.java:76)
at
org.gjt.sp.jedit.gui.InputHandler.invokeAction(InputHandler.java:229)
at
org.gjt.sp.jedit.gui.InputHandler.invokeAction(InputHandler.java:195)
at
org.gjt.sp.jedit.gui.DefaultInputHandler.handleKey(DefaultInputHandler.java:356)
at org.gjt.sp.jedit.View.processKeyEvent(View.java:615)
at
org.gjt.sp.jedit.textarea.JEditTextArea.processKeyEvent(JEditTextArea.java:4748)
at java.awt.Component.processEvent(Component.java:5265)
at java.awt.Container.processEvent(Container.java:1966)
at
java.awt.Component.dispatchEventImpl(Component.java:3955)
at
java.awt.Container.dispatchEventImpl(Container.java:2024)
at java.awt.Component.dispatchEvent(Component.java:3803)
at
java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1810)
at
java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(DefaultKeyboardFocusManager.java:668)
at
java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(DefaultKeyboardFocusManager.java:916)
at
java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:794)
at
java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:632)
at
java.awt.Component.dispatchEventImpl(Component.java:3841)
at
java.awt.Container.dispatchEventImpl(Container.java:2024)
at java.awt.Window.dispatchEventImpl(Window.java:1766)
at java.awt.Component.dispatchEvent(Component.java:3803)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
at
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:234)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
at
java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1173630&group_id=588

Bugs item #1171907, was opened at 2005-03-28 10:46
Message generated for change (Comment added) made by skielnik_sam
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1171907&group_id=588
Category: editor core
Group: minor bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Sam Skielnik (skielnik_sam)
Assigned to: Nobody/Anonymous (nobody)
Summary: Symbolic links not preserved when saving to Samba drive
Initial Comment:
Running Win2K with drive letters mapped to Solaris
Samba server.
Symbolic links are used on the Solaris filesystem to
point to text files.
When jEdit is used to edit the text file via one of the
symbolically linked locations on the Samba connection,
the file is written back to the Solaris filesystem as a text
file in that location instead of following the symbolic link
to the actual location of the text file.
When I test this using the ConTEXT editor on the same
files, the symbolic links are preserved during edit/save
operations. This leads me to believe it is possible with
jEdit as long as this is not a JVM I/O issue.
Thanks for the great editor!
----------------------------------------------------------------------
>Comment By: Sam Skielnik (skielnik_sam)
Date: 2005-03-29 09:06
Message:
Logged In: YES
user_id=1142297
Follow Up:
I forgot to mention that I am NOT using the Two-Stage save
option for saving files. Is jEdit making a temporary copy of
the file contents somewhere and moving that copy to the
location of the edited file/symbolic link? I'm wondering if that
is the difference between jEdit and the other editor I
mentioned. Thanks.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1171907&group_id=588

In an attempt to reduce the time between plugin batches and have a more
predictable release schedule, we're going to try to have monthly releases.
For a plugin to be included in the month's batch, it should be submitted
by the 20th of the month.
Hopefully, we'll be able to stick to this, or close to it.
As the first exception to this, we should have a small batch out soon
that won't have anything to do with this schedule -- it will only
consist of fixes and plugins that missed the last batch.
-Ollie

Bugs item #1171907, was opened at 2005-03-28 10:46
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=1171907&group_id=588
Category: editor core
Group: minor bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Sam Skielnik (skielnik_sam)
Assigned to: Nobody/Anonymous (nobody)
Summary: Symbolic links not preserved when saving to Samba drive
Initial Comment:
Running Win2K with drive letters mapped to Solaris
Samba server.
Symbolic links are used on the Solaris filesystem to
point to text files.
When jEdit is used to edit the text file via one of the
symbolically linked locations on the Samba connection,
the file is written back to the Solaris filesystem as a text
file in that location instead of following the symbolic link
to the actual location of the text file.
When I test this using the ConTEXT editor on the same
files, the symbolic links are preserved during edit/save
operations. This leads me to believe it is possible with
jEdit as long as this is not a JVM I/O issue.
Thanks for the great editor!
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1171907&group_id=588

Bugs item #1170726, was opened at 2005-03-25 12:25
Message generated for change (Comment added) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1170726&group_id=588
Category: editor core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unexpected Drag and Drop Behavior in jEdit 4.3pre2
Initial Comment:
When using jEdit 4.3pre2 using JDK5 text gets pasted at
odd places in the buffer if you do the following:
Select a block of text (more than one line)
Click on it to drag
Drop it on the gutter on the same level as where you
selected it
The selected text does not disappear (it stays were it
was), but it is also pasted somewhere in the buffer
(sometimes at the very top of the file) producing
unexpected results when saving the file because your
code has changed in unexpected places (not always visible).
//i\
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2005-03-25 12:58
Message:
Logged In: NO
Correction, it does not have to be multiple lines of text,
nor do you have to drag the selection to the gutter. Simply
clicking the selected area, moving the mouse to drag (the
small rectangle appears) and then releasing the mouse on the
highlighted portion (that you are attempting to drag) causes
the text to be pasted somewhere in the buffer.
//i\
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2005-03-25 12:33
Message:
Logged In: NO
Correction, it does not have to be multiple lines of text,
nor do you have to drag the selection to the gutter. Simply
clicking the selected area, moving the mouse to drag (the
small rectangle appears) and then releasing the mouse on the
highlighted portion (that you are attempting to drag) causes
the text to be pasted somewhere in the buffer.
//i\
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1170726&group_id=588

Bugs item #1170726, was opened at 2005-03-25 12:25
Message generated for change (Comment added) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1170726&group_id=588
Category: editor core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unexpected Drag and Drop Behavior in jEdit 4.3pre2
Initial Comment:
When using jEdit 4.3pre2 using JDK5 text gets pasted at
odd places in the buffer if you do the following:
Select a block of text (more than one line)
Click on it to drag
Drop it on the gutter on the same level as where you
selected it
The selected text does not disappear (it stays were it
was), but it is also pasted somewhere in the buffer
(sometimes at the very top of the file) producing
unexpected results when saving the file because your
code has changed in unexpected places (not always visible).
//i\
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2005-03-25 12:33
Message:
Logged In: NO
Correction, it does not have to be multiple lines of text,
nor do you have to drag the selection to the gutter. Simply
clicking the selected area, moving the mouse to drag (the
small rectangle appears) and then releasing the mouse on the
highlighted portion (that you are attempting to drag) causes
the text to be pasted somewhere in the buffer.
//i\
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1170726&group_id=588

Bugs item #1170726, was opened at 2005-03-25 12:25
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=1170726&group_id=588
Category: editor core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unexpected Drag and Drop Behavior in jEdit 4.3pre2
Initial Comment:
When using jEdit 4.3pre2 using JDK5 text gets pasted at
odd places in the buffer if you do the following:
Select a block of text (more than one line)
Click on it to drag
Drop it on the gutter on the same level as where you
selected it
The selected text does not disappear (it stays were it
was), but it is also pasted somewhere in the buffer
(sometimes at the very top of the file) producing
unexpected results when saving the file because your
code has changed in unexpected places (not always visible).
//i\
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1170726&group_id=588

* Zaleski, Matthew (M.E.) [22.03.2005 19:03]:
>
> When I started having performance issues with jEdit, I tracked it down
> to my dual-monitor setup. If jEdit doesn't start in the primary monitor
> (for me), then jEdit scrolling is SLLOOOOWWW. Seems to be a bug in
> Sun's JVM, not in jEdit itself. If jEdit starts in my second monitor, I
> have to drag it back to primary, drop it, and drag it back to secondary
> to get jEdit accelerated. It seems that the JVM is not using
> accelerated GUI calls if the GUI initializes on the secondary monitor.
I only use one monitor, so this cannot be the issue. Also, in other
jEdit releases there's no problem. But I now use again 4.2, so I cannot
say very much about this issue now. Trying 4.3pre3 again, maybe the
problem is then gone (by itself).
Regards,
Bernhard
--

The edit bus architecture needs to be this way to keep it flexible. There =
should=0D
be no specifics in the jEdit core at all. =0D
=0D
A lot of the plugins also depend on each other. For example, the SwitchBuf=
fer=0D
plugin allows the user to display entries in the colours defined by the Fil=
e=0D
System Browser. If the user changes those colours I need to make sure that=
=0D
SwitchBuffer knows about it and clears its cache of colours. If SwitchBuff=
er=0D
only ever recieved SwitchBuffer related messages then it would never know a=
bout=0D
this update and be displaying out of date colours.=0D
=0D
The architecture as it stands is very simple and it puts all the knowledge =
of who=0D
needs what messages in the individual plugins which is where it should be r=
eally.=0D
=0D
Hope this helps=0D
Cheers=0D
Lee=0D
=0D
On Wed Mar 23 3:38 , "Colin Canfield" sent:=0D
=0D
>I understand about loose coupling and not wanting to know who the receiver=
is =0D
>but I would have thought part of this should be some way for me to determi=
ne =0D
>if this message effects me.=0D
>=0D
>For example, on the properties page; I seem to be getting a updated =0D
>properties notification whenever any properties are changed for any plug i=
n. =0D
>=0D
>The same for Dockable window; whenever a new plugin dockable window is =0D
>created I seem to be receiving a message; shouldn't this only be a new =0D
>Dockable window associated with my Plug in is created ? =0D
>=0D
>Thanks, Colin=0D
>=0D
>=0D
>On Sun, 20 Mar 2005 16:19:00 +0100, Daniel Wunsch wrote=0D
>> On Sunday 20 March 2005 05:30, Colin Canfield wrote:=0D
>> > > Hello,=0D
>> > >=0D
>> > > I was wondering how I can tell if a message is meant for my plugin?=
=0D
>> =0D
>> there is no "meant for my plugin" - the EditBus just broadcasts =0D
>> events to anyone interested.=0D
>> =0D
>> this is not a bug, this is a feature:=0D
>> the sender should not have to know who will receive its=0D
>> Events. this is called loose coupling.=0D
>> =0D
>> > > There doesn't seem to be any nice way; apart from lots of different=
=0D
>> > > tests if it comes from a View type message, Buffer etc..... I seem t=
o=0D
>> > > be able to do a getSource for some message types, but not for=0D
>> > > others...=0D
>> =0D
>> the source is where the Event came from, not where its meant to go.=0D
>> =0D
>> the questions are: are the Events you are talking about=0D
>> Events your plugin casts, or some internal jEdit class?=0D
>> and: what to you want to achieve?=0D
>> =0D
>> daniel=0D
>> =0D
>> -------------------------------------------------------=0D
>> SF email is sponsored by - The IT Product Guide=0D
>> Read honest & candid reviews on hundreds of IT Products from real users.=
=0D
>> Discover which products truly live up to the hype. Start reading now.=0D
>> http://ads.osdn.com/\?ad_id=3D6595&alloc_id=3D14396&op=3Dclick=0D
>> -- =0D
>> -----------------------------------------------=0D
>> jEdit Developers' List=0D
>> jEdit-devel@...=0D
>> https://lists.sourceforge.net/lists/listinfo/jedit-devel=0D
>=0D
>=0D
>--=0D
>Colin Canfield=0D
>Business Analyst=0D
>Explorative Software Pty Ltd =0D
>0412 197 943=0D
>colinc@...=0D
>=0D
>=0D
>=0D
>-------------------------------------------------------=0D
>This SF.net email is sponsored by: 2005 Windows Mobile Application Contest=
=0D
>Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones=
=0D
>for the chance to win $25,000 and application distribution. Enter today at=
=0D
>http://ads.osdn.com/\?ad_id=3D6882&alloc_id=3D15148&op=3Dclick=0D
>-- =0D
>-----------------------------------------------=0D
>jEdit Developers' List=0D
>jEdit-devel@...=0D
>https://lists.sourceforge.net/lists/listinfo/jedit-devel=0D
=0D
=0D

Is there a date planned for the next plugin release?
I want to know when to start getting the Ruby plugin ready for release. ;)
Rob
Matthieu Casanova wrote:
> Hi, yes I think a schedule would be nice, but in the other hand
> packaging takes time and packagers are volonteer so it's difficult to
> ask them schedules. But maybe like the previous plugin release a mail
> could be sent to the mailing list to announce the next release, maybe
> 2 weeks before, so developpers could finish their job to release their
> plugins...

I understand about loose coupling and not wanting to know who the receiver is
but I would have thought part of this should be some way for me to determine
if this message effects me.
For example, on the properties page; I seem to be getting a updated
properties notification whenever any properties are changed for any plug in.
The same for Dockable window; whenever a new plugin dockable window is
created I seem to be receiving a message; shouldn't this only be a new
Dockable window associated with my Plug in is created ?
Thanks, Colin
On Sun, 20 Mar 2005 16:19:00 +0100, Daniel Wunsch wrote
> On Sunday 20 March 2005 05:30, Colin Canfield wrote:
> > > Hello,
> > >
> > > I was wondering how I can tell if a message is meant for my plugin?
>
> there is no "meant for my plugin" - the EditBus just broadcasts
> events to anyone interested.
>
> this is not a bug, this is a feature:
> the sender should not have to know who will receive its
> Events. this is called loose coupling.
>
> > > There doesn't seem to be any nice way; apart from lots of different
> > > tests if it comes from a View type message, Buffer etc..... I seem to
> > > be able to do a getSource for some message types, but not for
> > > others...
>
> the source is where the Event came from, not where its meant to go.
>
> the questions are: are the Events you are talking about
> Events your plugin casts, or some internal jEdit class?
> and: what to you want to achieve?
>
> daniel
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> --
> -----------------------------------------------
> jEdit Developers' List
> jEdit-devel@...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
--
Colin Canfield
Business Analyst
Explorative Software Pty Ltd
0412 197 943
colinc@...