jedit-devel Mailing List for jEdit

Trevor Harmon wrote:
> Hmm... I thought Java handled international keyboard layouts 
> automatically (at the VM level). Are you saying that any Java app that 
> wants to support international keyboards has to do so itself?

On MacOS X, KEY_PRESSED events always contain keycodes as if you had a 
QWERTY keyboard. KEY_TYPED events are correct. This is definately a bug 
that apple should fix.

> In any case, it seems to be messing things up for those of us with 
> regular keyboards. Perhaps this should be a user-settable option that it 
> is off by default?

Once Apple fixes this bug.

Slava

On Jul 31, 2004, at 3:10 PM, Slava Pestov wrote:

> This flag is needed for international keyboard handling on MacOS.

Hmm... I thought Java handled international keyboard layouts 
automatically (at the VM level). Are you saying that any Java app that 
wants to support international keyboards has to do so itself?

In any case, it seems to be messing things up for those of us with 
regular keyboards. Perhaps this should be a user-settable option that 
it is off by default?

Trevor

Hi,

This flag is needed for international keyboard handling on MacOS.

Normally, jEdit listens for a KEY_PRESSED event for keys like C+a, etc. 
With this flag on, it waits for a KEY_PRESSED for Control, then a 
KEY_TYPED for a.

Trevor Harmon wrote:
> There is a bug in jEdit's key event handler. To reproduce the bug, try 
> this on a Mac:
> 
> Type Command+, to open the search bar
> Type some search text
> Type Command+G to advance to the next match
> 
> In jEdit 4.1, the text area selection would advance to the next match. 
> On jEdit 4.2, however, nothing happens when the host OS is Macintosh. 
> Linux (and most probably Windows, too) does not exhibit this bug.
> 
> I've walked back through the CVS history and discovered that the bug 
> appeared during the overhaul of the key handling routines 
> (DefaultInputHandler.java, KeyEventTranslator.java, 
> KeyEventWorkaround.java) back in mid-June of 2003.
> 
> When I investigated further, I discovered that the root of the problem 
> seems to be a flag in Debug.java called ALTERNATIVE_DISPATCHER, which is 
> enabled only when the OS is Macintosh. Surprisingly, if I force this 
> flag to false, the bug disappears. Even more surprising is that jEdit's 
> key handling seems to work just fine with ALTERNATIVE_DISPATCHER 
> disabled. It seems to have no effect on my Mac (other than causing the 
> bug I described above!). This means that the flag is apparently useless, 
> since it is disabled for all other platforms anyway.
> 
> But perhaps I missing something. For those Mac users out there, can 
> anyone reproduce what I'm seeing? And does anybody know why 
> ALTERNATIVE_DISPATCHER is there in the first place?
> 
> Trevor
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com

There is a bug in jEdit's key event handler. To reproduce the bug, try 
this on a Mac:

Type Command+, to open the search bar
Type some search text
Type Command+G to advance to the next match

In jEdit 4.1, the text area selection would advance to the next match. 
On jEdit 4.2, however, nothing happens when the host OS is Macintosh. 
Linux (and most probably Windows, too) does not exhibit this bug.

I've walked back through the CVS history and discovered that the bug 
appeared during the overhaul of the key handling routines 
(DefaultInputHandler.java, KeyEventTranslator.java, 
KeyEventWorkaround.java) back in mid-June of 2003.

When I investigated further, I discovered that the root of the problem 
seems to be a flag in Debug.java called ALTERNATIVE_DISPATCHER, which 
is enabled only when the OS is Macintosh. Surprisingly, if I force this 
flag to false, the bug disappears. Even more surprising is that jEdit's 
key handling seems to work just fine with ALTERNATIVE_DISPATCHER 
disabled. It seems to have no effect on my Mac (other than causing the 
bug I described above!). This means that the flag is apparently 
useless, since it is disabled for all other platforms anyway.

But perhaps I missing something. For those Mac users out there, can 
anyone reproduce what I'm seeing? And does anybody know why 
ALTERNATIVE_DISPATCHER is there in the first place?

Trevor

I think I'll just remove this feature :)

Trevor Harmon wrote:
> According to this thread:
> 
> http://sourceforge.net/mailarchive/message.php?msg_id=4265488
> 
> the incremental search bar is supposed to pass on left and right arrow 
> key events to the text area if hypersearch is off. However, this does 
> not seem to work. For example, if I do this sequence of key presses:
> 
> C+,
> <some search text>
> Right arrow
> 
> Then I would expect the search bar to disappear and the cursor to move 
> one place to the right. And indeed, the relevant code in SearchBar.java 
> seems to support this (around line 407):
> 
>                         case KeyEvent.VK_LEFT:
>                         case KeyEvent.VK_RIGHT:
>                                         ...
>                                                 
> view.removeToolBar(SearchBar.this);
>                                         ...
>                                         
> view.getEditPane().focusOnTextArea();
>                                         
> view.getEditPane().getTextArea().processKeyEvent(evt);
> 
> But on both Mac and Linux (haven't tested on Windows), pressing Right 
> simply causes the search bar to disappear. The cursor position does not 
> change. Is anyone else seeing this behavior?
> 
> Trevor
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com

According to this thread:

http://sourceforge.net/mailarchive/message.php?msg_id=4265488

the incremental search bar is supposed to pass on left and right arrow 
key events to the text area if hypersearch is off. However, this does 
not seem to work. For example, if I do this sequence of key presses:

C+,
<some search text>
Right arrow

Then I would expect the search bar to disappear and the cursor to move 
one place to the right. And indeed, the relevant code in SearchBar.java 
seems to support this (around line 407):

                         case KeyEvent.VK_LEFT:
                         case KeyEvent.VK_RIGHT:
                                         ...
                                                 
view.removeToolBar(SearchBar.this);
                                         ...
                                         
view.getEditPane().focusOnTextArea();
                                         
view.getEditPane().getTextArea().processKeyEvent(evt);

But on both Mac and Linux (haven't tested on Windows), pressing Right 
simply causes the search bar to disappear. The cursor position does not 
change. Is anyone else seeing this behavior?

Trevor

Hi:

There is a bug in the FtpPlugin's
ConnectionManager.java.
In method getConnectionInfo, the dialog box collected
info is put in the ConnectionInfo object, and put into
the logins HashMap, but if the user mistypes his
password, but not the userid, this info is stored as
hash, and passed to the work thread that does the
connection. Now, if the connection fails bacuase of
bad authentication, the user wants to try again, but
cannot because his login is already cached in logins,
and that info is being used over and over again.
The only option is to restart the editor.
The fix is to move the caching down to getConnection
method which is invoked by the work thead. If the
connection establishment fails, and an exception is
thrown, the logins cache is not filled.
The effected lines are marked by <ibuday> tags.

______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca

Hi,

Sure, update the patch if you want. Then I'll merge it.

Paul Russell wrote:
> Hi Salva,
> 
>      About a week ago I submitted a patch to the user
> guide plugin-implementation doc on this topic. See [
> jEdit-devel ] Code submission for User Guide plugin
> implementation doc.
> 
> Two questions:
> 1) Is this sort of patch useful to the project? I'm a
> big fan of doc, but I don't want to step on anyones
> toes.
> 2) If so, would you like me to update the patch with
> this latest info about the name change of the plugin
> on loading and unloading?
> 
> Paul
> 
> --- Slava Pestov <sl...@je...> wrote:
> 
>>Justin Dieters wrote:
>>
>>>Additionally, if the plugin all the sudden
>>
>>disappears on you when you 
>>
>>>unload it and you're wondering where it went,
>>
>>uncheck the 'Hide 
>>
>>>Libraries' box at the top left of the plugin
>>
>>manager.
>>
>>>This seems to get some people the first time they
>>
>>unload a plugin, 
>>
>>>myself included.
>>
>>This is 'fixed' in pre15. I say 'fixed' because the
>>table entry still 
>>changes from 'Foo Plugin' to 'Foo.jar', and you
>>can't see author/version 
>>info for unloaded plugins.
>>
>>Slava
>>
>>
>>
> 
> -------------------------------------------------------
> 
>>This SF.Net email is sponsored by BEA Weblogic
>>Workshop
>>FREE Java Enterprise J2EE developer tools!
>>Get your free copy of BEA WebLogic Workshop 8.1
>>today.
>>
> 
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> 
>>-- 
>>-----------------------------------------------
>>jEdit Developers' List
>>jEd...@li...
>>
> 
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
> 
> 
> 
> 
> 	
> 		
> __________________________________
> Do you Yahoo!?
> Vote for the stars of Yahoo!'s next ad campaign!
> http://advision.webevents.yahoo.com/yahoo/votelifeengine/

Hi Salva,

     About a week ago I submitted a patch to the user
guide plugin-implementation doc on this topic. See [
jEdit-devel ] Code submission for User Guide plugin
implementation doc.

Two questions:
1) Is this sort of patch useful to the project? I'm a
big fan of doc, but I don't want to step on anyones
toes.
2) If so, would you like me to update the patch with
this latest info about the name change of the plugin
on loading and unloading?

Paul

--- Slava Pestov <sl...@je...> wrote:
> Justin Dieters wrote:
> > Additionally, if the plugin all the sudden
> disappears on you when you 
> > unload it and you're wondering where it went,
> uncheck the 'Hide 
> > Libraries' box at the top left of the plugin
> manager.
> > 
> > This seems to get some people the first time they
> unload a plugin, 
> > myself included.
> 
> This is 'fixed' in pre15. I say 'fixed' because the
> table entry still 
> changes from 'Foo Plugin' to 'Foo.jar', and you
> can't see author/version 
> info for unloaded plugins.
> 
> Slava
> 
> 
>
-------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic
> Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1
> today.
>
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> -- 
> -----------------------------------------------
> jEdit Developers' List
> jEd...@li...
>
https://lists.sourceforge.net/lists/listinfo/jedit-devel
> 



	
		
__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/

Justin Dieters wrote:
> Additionally, if the plugin all the sudden disappears on you when you 
> unload it and you're wondering where it went, uncheck the 'Hide 
> Libraries' box at the top left of the plugin manager.
> 
> This seems to get some people the first time they unload a plugin, 
> myself included.

This is 'fixed' in pre15. I say 'fixed' because the table entry still 
changes from 'Foo Plugin' to 'Foo.jar', and you can't see author/version 
info for unloaded plugins.

Slava

I second that, perhaps this could be refactored as part of 4.3? I came
across this recently because I wanted to use the search functionality as
part of a plugin I am working on...and found that the logic for stepping
through files was in the GUI code...

There should probably be a discussion on what this should include, becaus=
e
that search plugin (XSearch?) includes some features I think should be in
the standard, like skipping comments...

Slava, if you think this might go into 4.3, I'd be glad to work with you
and others on the refactoring when the time comes.

Patrick

> Rather the code needs to be refactored so that it can perform a search
using a specified set of parameters -- as opposed to the global set of
parameters, which should be used by the GUI only.
>
>
> Gerd Knops wrote:
>> Slava, SearchAndReplace should really have something along save/restor=
e
or push/pop to save it's settings. A number of plugins (like
>> CodeBrowser) have to perform those contortions, and have to make some
assumptions about SearchAndReplace.
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=3D4721&alloc_id=3D10040&op=3Dclick
> --
> -----------------------------------------------
> jEdit Developers' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>

Hi,

Plugins using the jEdit 4.1 API, and plugins with an activate=startup 
property are activated before any buffers are open.

jEdit 4.2 plugins can be activated at any time -- so they have to handle 
both cases, initial buffers already opened, and buffers not yet opened.

Dale Anson wrote:
> Okay, I get what your issue is now. I'm not up on the start up sequence 
> of jEdit, I'm not sure if the plugins get loaded before the buffers (I 
> think they do -- from my activity log, it appears the plugins are 
> loaded, then buffers are reopened). The BufferLocal plugin is set for 
> deferred loading, so it does find buffers open in it's start() method.

Rather the code needs to be refactored so that it can perform a search 
using a specified set of parameters -- as opposed to the global set of 
parameters, which should be used by the GUI only.


Gerd Knops wrote:
> Slava, SearchAndReplace should really have something along save/restore 
> or push/pop to save it's settings. A number of plugins (like 
> CodeBrowser) have to perform those contortions, and have to make some 
> assumptions about SearchAndReplace.

Hi,

This is documented in the Swing API documentation.

Patrick Wright wrote:
> I have been working on a plugin that loads a JTree with some file lists
> based on search criteria, and the search can take a little while to
> process.
> 
> My question is, if I run the search in a background thread, and then want
> to update the TreeModel (either by adding individual nodes, or a new model
> entirely), should the update to the TreeModel go on the Swing event thread
> with invokeLater() or not?
> 
> What I am wondering is about the common knowledge that Swing components
> should only be modified on the Swing event processing thread. I think this
> definitely applies to things like add(component), but not sure about
> things like setModel(), adding or removing listeners, etc.--all at least
> setModel() can in turn generate messages for the GUI to update, but those
> would be asynchronous, wouldn't they, processed through the event queue?
> 
> Confused.
> 
> TIA
> Patrick
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_idG21&alloc_id040&op=click

Hi Robert,

> I'm using Martin's jEdit launcher & after a crash (I'm currently cursed
> with a very flaky laptop that's due to be replaced soon)
Okay, what happens:

When jedit starts, it creates a file called "server" in the ".jedit" =20
directory. If this file is present, the jedit launcher knows, there is an=
 =20
instance of jedit running.
BUT if unfortunately jedit crashes this file isn't deleted and jedit =20
launcher still thinks, jedit is running, but in fact it isn't.

I have patched this issue in a new version, which I will release within =20
the next 3 days.

Workaround at the moment: delete "server" - file in .jedit directory =20
manually! Then use jedit launcher!

Best regards

Martin
--=20
Martin Fischbach
http://www.martin-fischbach.de

I have been working on a plugin that loads a JTree with some file lists
based on search criteria, and the search can take a little while to
process.

My question is, if I run the search in a background thread, and then want
to update the TreeModel (either by adding individual nodes, or a new mode=
l
entirely), should the update to the TreeModel go on the Swing event threa=
d
with invokeLater() or not?

What I am wondering is about the common knowledge that Swing components
should only be modified on the Swing event processing thread. I think thi=
s
definitely applies to things like add(component), but not sure about
things like setModel(), adding or removing listeners, etc.--all at least
setModel() can in turn generate messages for the GUI to update, but those
would be asynchronous, wouldn't they, processed through the event queue?

Confused.

TIA
Patrick

Hi,

This is certainly a good feature and I'm glad you decided to make a
patch for it! It should go into 4.3.

I have a couple of suggestions; using an attribute of the
VFS.DirectoryEntry for a time stamp. The attribute could be lazily
loaded. Also the updated methods in Buffer.java are sufficiently long
that they could be split up.

Slava

Timothy Gates wrote:
> Attached is a patch in unified diff format. It adds an optional
> timestamp method to the Virtual File System and support in Buffer.java
> to handle automatically reloading of VFS buffers if the timestamp is
> available and changes just like the local file system.
> 
> 
> ------------------------------------------------------------------------
> 
> diff -ur jEdit/org/gjt/sp/jedit/Buffer.java jEditNew/org/gjt/sp/jedit/Buffer.java
> --- jEdit/org/gjt/sp/jedit/Buffer.java	2004-06-04 10:18:34.000000000 +1000
> +++ jEditNew/org/gjt/sp/jedit/Buffer.java	2004-07-20 12:57:29.000000000 +1000
> @@ -179,7 +179,26 @@
>  		if(reload || !getFlag(NEW_FILE))
>  		{
>  			if(file != null)
> +			{
>  				modTime = file.lastModified();
> +			}
> +			else if(path != null)
> +			{
> +				VFS vfs = VFSManager.getVFSForPath(path);
> +				Object session = vfs.createVFSSession(path, view);
> +				if(session != null)
> +				{
> +					try {
> +						long stamp = vfs._timestamp(session, path, view);
> +						if(stamp != -1) {
> +							modTime = stamp;
> +						}
> +					} catch(IOException ioe) {
> +						Log.log(Log.ERROR,this,path + ": failed to obtain timestamp.");
> +						Log.log(Log.ERROR,this,ioe);
> +					}
> +				}
> +			}
>  
>  			// Only on initial load
>  			if(!reload && autosaveFile != null && autosaveFile.exists())
> @@ -431,10 +450,27 @@
>  		if(path == null && getFlag(NEW_FILE))
>  			return saveAs(view,rename);
>  
> +		long newModTime = -1;
>  		if(path == null && file != null)
>  		{
> -			long newModTime = file.lastModified();
> -
> +			newModTime = file.lastModified();
> +		}
> +		else if(path != null)
> +		{
> +			VFS vfs = VFSManager.getVFSForPath(path);
> +			Object session = vfs.createVFSSession(path, view);
> +			if(session != null)
> +			{
> +				try {
> +					newModTime = vfs._timestamp(session, path, view);
> +				} catch(IOException ioe) {
> +					Log.log(Log.ERROR,this,path + ": failed to obtain timestamp.");
> +					Log.log(Log.ERROR,this,ioe);
> +				}
> +			}
> +		}
> +		if(newModTime != -1)
> +		{
>  			if(newModTime != modTime
>  				&& jEdit.getBooleanProperty("view.checkModStatus"))
>  			{
> @@ -498,29 +534,55 @@
>  	 */
>  	public int checkFileStatus(View view)
>  	{
> +		Log.log(Log.WARNING, this, path + ": checkFileStatus requested.");
>  		// - don't do these checks while a save is in progress,
>  		// because for a moment newModTime will be greater than
>  		// oldModTime, due to the multithreading
> -		// - only supported on local file system
> -		if(!getFlag(IO) && !getFlag(LOADING) && file != null
> +		// - supported on local file system and vfs
> +		if(!getFlag(IO) && !getFlag(LOADING) && (file != null || path != null)
>  			&& !getFlag(NEW_FILE))
>  		{
> -			boolean newReadOnly = (file.exists() && !file.canWrite());
> -			if(newReadOnly != getFlag(READ_ONLY))
> +			if(file != null)
>  			{
> -				setFlag(READ_ONLY,newReadOnly);
> -				EditBus.send(new BufferUpdate(this,null,
> -					BufferUpdate.DIRTY_CHANGED));
> +				boolean newReadOnly = (file.exists() && !file.canWrite());
> +				if(newReadOnly != getFlag(READ_ONLY))
> +				{
> +					setFlag(READ_ONLY,newReadOnly);
> +					EditBus.send(new BufferUpdate(this,null,
> +						BufferUpdate.DIRTY_CHANGED));
> +				}
>  			}
>  
>  			long oldModTime = modTime;
> -			long newModTime = file.lastModified();
> +			long newModTime = -1;
> +			if(file != null)
> +			{
> +				newModTime = file.lastModified();
> +			}
> +			else
> +			{
> +				VFS vfs = VFSManager.getVFSForPath(path);
> +				Object session = vfs.createVFSSession(path, view);
> +				if(session != null)
> +				{
> +					try {
> +						newModTime = vfs._timestamp(session, path, view);
> +					} catch(IOException ioe) {
> +						Log.log(Log.ERROR,this,path + ": failed to obtain timestamp.");
> +						Log.log(Log.ERROR,this,ioe);
> +					}
> +				}
> +				else
> +				{
> +					Log.log(Log.WARNING, this, path + ": Unable to check status session is null.");
> +				}
> +			}
>  
> -			if(newModTime != oldModTime)
> +			if(newModTime != -1 && newModTime != oldModTime)
>  			{
>  				modTime = newModTime;
>  
> -				if(!file.exists())
> +				if(file != null && !file.exists())
>  				{
>  					setFlag(NEW_FILE,true);
>  					setDirty(true);
> @@ -532,6 +594,10 @@
>  				}
>  			}
>  		}
> +		else
> +		{
> +			Log.log(Log.WARNING, this, path + ": Invalid point to check status.");
> +		}
>  
>  		return FILE_NOT_CHANGED;
>  	} //}}}
> @@ -3988,7 +4054,13 @@
>  		if(rename)
>  		{
>  			if(file != null)
> +			{
>  				modTime = file.lastModified();
> +			}
> +			else if(path != null)
> +			{
> +				
> +			}
>  
>  			if(!error)
>  			{
> diff -ur jEdit/org/gjt/sp/jedit/io/VFS.java jEditNew/org/gjt/sp/jedit/io/VFS.java
> --- jEdit/org/gjt/sp/jedit/io/VFS.java	2003-09-08 11:24:11.000000000 +1000
> +++ jEditNew/org/gjt/sp/jedit/io/VFS.java	2004-07-20 08:51:32.000000000 +1000
> @@ -728,6 +728,22 @@
>  		return false;
>  	} //}}}
>  
> +	//{{{ _timestamp() method
> +	/**
> +	 * Gets a timestamp for the specified URL if available
> +	 * (-1 signifies unavailable).
> +	 * @param session The VFS session
> +	 * @param path The path
> +	 * @param comp The component that will parent error dialog boxes
> +	 * @exception IOException if an I/O error occurs
> +	 * @since jEdit 4.2pre16
> +	 */
> +	public long _timestamp(Object session, String path, Component comp)
> +		throws IOException
> +	{
> +		return -1;
> +	} //}}}
> +
>  	//{{{ _rename() method
>  	/**
>  	 * Renames the specified URL. Some filesystems might support moving

On Jul 16, 2004, at 5:28 PM, kasper b. graversen wrote:

> hello. Im creating macros for quickly jumping around in latex 
> documents. I simply recorded a macro where i search for a specific 
> string. However,  unfortunately after the macro has executed, the 
> settings the macro used is remembered for the next search. Thus Im 
> trying to save the old settings, perform the macro and the restore the 
> settings. Alas, I have problems restoring the search string. My macros 
> looks like the following
>
  [..]

Slava, SearchAndReplace should really have something along save/restore 
or push/pop to save it's settings. A number of plugins (like 
CodeBrowser) have to perform those contortions, and have to make some 
assumptions about SearchAndReplace.

That being said, the code in CodeBrowser looks very similar, it fails 
to save the SearchFileSet, but does save the getBeanShellReplace flag 
you are missing. Unless the order is important I can not see why your 
code isn't working. Below the relevant excerpt from CodeBrowser.

Gerd


				// Save current Serach panel values
				String searchString=SearchAndReplace.getSearchString();
				boolean ignoreCase=SearchAndReplace.getIgnoreCase();
				boolean useRegexp=SearchAndReplace.getRegexp();
				boolean reverse=SearchAndReplace.getReverseSearch();
				boolean bean=SearchAndReplace.getBeanShellReplace();
				boolean wrap=SearchAndReplace.getAutoWrapAround();
				
				// Set for our search
				SearchAndReplace.setSearchString(pattern);
				SearchAndReplace.setIgnoreCase(false);
				SearchAndReplace.setRegexp(true);
				SearchAndReplace.setReverseSearch(false);
				SearchAndReplace.setBeanShellReplace(false);
				SearchAndReplace.setAutoWrapAround(true);
				SearchAndReplace.setSearchFileSet(new CurrentBufferSet());
				
				// Search
				try
				{
					SearchAndReplace.find(currentView,currentBuffer,0);
					
					// Code to find repeated occurrences removed...
				}
				catch(Exception ex)
				{
				}
				
				// Restore previous values
				SearchAndReplace.setSearchString(searchString);
				SearchAndReplace.setIgnoreCase(ignoreCase);
				SearchAndReplace.setRegexp(useRegexp);
				SearchAndReplace.setReverseSearch(reverse);
				SearchAndReplace.setBeanShellReplace(bean);
				SearchAndReplace.setAutoWrapAround(wrap);

Hi,

I'm using Martin's jEdit launcher & after a crash (I'm currently cursed
with a very flaky laptop that's due to be replaced soon) I cannot start
jEdit; jedit.exe gives me a message saying "jEdit is already running".
I'm guessing it's creating a lock file or something, but I can't see it
anywhere obvious.


	
		
__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/

Attached is a patch in unified diff format. It adds an optional
timestamp method to the Virtual File System and support in Buffer.java
to handle automatically reloading of VFS buffers if the timestamp is
available and changes just like the local file system.

hsa...@ya...

		
---------------------------------
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!

Hi,

The BufferUpdate.CREATED message is only sent once per buffer.

Paul Russell wrote:
> Hi,
> 
> Is there any way to only add a listener to a buffer
> only once?
> 
> I'm working on a plugin that needs to be aware of
> events in the buffer.  In the handleMessage method of
> my plugin I have the code below.
> 
> My problem is that each time I Reload a buffer, my
> plugin adds itself to that buffer as another listener,
> which seems like bad form and causes my plugin to get
> multiple copies of all event messages.
> 
> Here's the code:
> if(bufferMessage.getWhat() == BufferUpdate.LOADED)
> {
>     Buffer buffer = bufferMessage.getBuffer();
>     buffer.addBufferChangeListener(this);
>                 
>     BufferChangeListener bufferListeners[] = 
>                buffer.getBufferChangeListeners();
>                 
> 
>     Log.log( Log.DEBUG, Bookmarks.class,
> 	        "Number of bufferListeners " + 
>                  bufferListeners.length);
>                  
> }
> 
> That log statement shows that there is one more
> listener is in the buffer each time the buffer is
> reloaded.
> 
> Any help would be helpful.
> 
> Thanks
> Paul
> 
> 
> 		
> __________________________________
> Do you Yahoo!?
> Vote for the stars of Yahoo!'s next ad campaign!
> http://advision.webevents.yahoo.com/yahoo/votelifeengine/
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click

Hi,

Is there any way to only add a listener to a buffer
only once?

I'm working on a plugin that needs to be aware of
events in the buffer.  In the handleMessage method of
my plugin I have the code below.

My problem is that each time I Reload a buffer, my
plugin adds itself to that buffer as another listener,
which seems like bad form and causes my plugin to get
multiple copies of all event messages.

Here's the code:
if(bufferMessage.getWhat() == BufferUpdate.LOADED)
{
    Buffer buffer = bufferMessage.getBuffer();
    buffer.addBufferChangeListener(this);
                
    BufferChangeListener bufferListeners[] = 
               buffer.getBufferChangeListeners();
                

    Log.log( Log.DEBUG, Bookmarks.class,
	        "Number of bufferListeners " + 
                 bufferListeners.length);
                 
}

That log statement shows that there is one more
listener is in the buffer each time the buffer is
reloaded.

Any help would be helpful.

Thanks
Paul


		
__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/

hello. Im creating macros for quickly jumping around in latex documents. I=
 simply recorded a macro where i search for a specific string. However,=
  unfortunately after the macro has executed, the settings the macro used=
 is remembered for the next search. Thus Im trying to save the old=
 settings, perform the macro and the restore the settings. Alas, I have=
 problems restoring the search string. My macros looks like the following


// store original settings
String ss =3D SearchAndReplace.getSearchString();
boolean awa=3D SearchAndReplace.getAutoWrapAround();
boolean rs =3D SearchAndReplace.getReverseSearch();
boolean ic =3D SearchAndReplace.getIgnoreCase();
boolean r  =3D SearchAndReplace.getRegexp();
SearchFileSet sfs =3D SearchAndReplace.getSearchFileSet();

// run macro
SearchAndReplace.setSearchString("\\subsection{");
SearchAndReplace.setAutoWrapAround(true);
SearchAndReplace.setReverseSearch(true);
SearchAndReplace.setIgnoreCase(false);
SearchAndReplace.setRegexp(false);
SearchAndReplace.setSearchFileSet(new CurrentBufferSet());
SearchAndReplace.find(view);

// restore search settings 
SearchAndReplace.setSearchString(ss);
SearchAndReplace.setAutoWrapAround(awa);
SearchAndReplace.setReverseSearch(rs);
SearchAndReplace.setIgnoreCase(ic);
SearchAndReplace.setRegexp(r);
SearchAndReplace.setSearchFileSet(sfs);
System.out.println("reading again: " + SearchAndReplace.getSearchString());=
  // does not print the value of 'ss' :(



what am I doing wrong?

-kasper
please help save our planet! At least click daily on
http://rainforest.care2.com/  and   http://www.therainforestsite.com/
and tell your friends to do the same...

Hi all,

	This email contains a submission for an update to the
user guide. I sent a similar email 2 days ago, but
instead of attaching the diff I included the entire
file and no a Moderator needs to review the mail.
Instead of wasting the moderators time, I’ve resent
with the diff.

The gist of my last email was:

+ This update adds documentation to the user guide on
how to dynamically reload plugins without updating
jEdit.

+ Thanks to Dale Anson, Justin Dieters and Slava
Pestov for providing me with details and caveats on
reloading plugins.	

+ The attached file is the diff of the latest version
of plugin-implement.xml and my updated version. It
includes the following changes

+ There is a new last page in the table of contents or
how to implement a plugin. It is called “Reloading the
Plugin”
+ There is a link from the “How Plugins are Loaded”
page to the “Reloading the Plugin” page.
+ The last “good luck” sentence of the that used to be
on the “Compiling the Plugin” page has been moved to
the “Reloading the Plugin” page

That’s it. This is my first time submitting anything
to the jEdit project, so let me know if I’m stepping
on anyone’s toes or if there is a better way to help
out.

Paul


	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail