jedit-devel Mailing List for jEdit

Bugs item #691891, was opened at 2003-02-23 17:32
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=691891&group_id=588

Category: plugins
Group: minor bug
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Conor MacNeill (conormac)
Assigned to: Slava Pestov (spestov)
Summary: Console error pattern for Ant missing "-"

Initial Comment:
Ant task names may contain hyphens. This needs to be
added to the console plugin's error pattern.

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

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

Bugs item #692588, was opened at 2003-02-24 18:20
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=692588&group_id=588

Category: plugins
Group: minor bug
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Slava Pestov (spestov)
Summary: Commando: Ant option assuming any XML to be the build file

Initial Comment:
The logic for the Commando "Ant" command will 
use the build.xml file in the project directory, 
unless the file in the active buffer happens to be an 
XML file.  In this case, it will assume this XML file 
to be the Ant build file.

I'm using JEdit frequently for XML files and for 
Docbook, so hitting the Ant command is resulting 
in it ignoring my build.xml file and trying to 
run "report.xml" or whatever is in my current buffer 
instead.

Build.XML is a very standard name for the Ant build 
file, so much so that if you have another-named 
XML file in the buffer, chances are it's not the Ant 
build file--just another XML document instead.

It may be better to make the file guessing logic 
stricter:  always choose the build.xml file in the 
project directory, unless the file in the active buffer 
is also called build.xml (say, if I've opened one 
from another directory), in which case go with that 
build.xml version instead.

Thanks,
Glen



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

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

Bugs item #528821, was opened at 2002-03-11 21:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=528821&group_id=588

Category: plugin manager
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Slava Pestov (spestov)
Summary: Fix loading/unloading of plugins

Initial Comment:
Please fix the unnoying need to restart jEdit when we
load or unload plugins.  The way that it can be done
takes advantage of heirarchical classloaders.

Basically, you have a parent classloader that takes care
of all the core classes.  For EACH plugin jar, you load
it in its own classloader with the parent being the core
classloader.

Something along the lines of this:

m_coreManager = this.class.getClassLoader();
m_classloaderMap = new HashMap();

// for new jars added to the system
m_classloaderMap.put( pathToPlugin,
               new UrlClassLoader( pathToPlugin ) );

// to remove a plugin
m_classloaderMap.remove( pathToPlugin );

// to update a plugin
m_classloaderMap.put( pathToPlugin,
               new UrlClassLoader( pathToPlugin ) );


// to load a class for the plugin
ClassLoader loader = (ClassLoader)
            m_classloaderMap.get( pathToPlugin );
Plugin pi = (Plugin)
     loader.loadClass( Plugin.START_CLASS )
     .newInstance();

Of course, when you no longer need it, you have the
plugin clean up after itself and remove the entry in
the classloaderMap.


We use this approach in Apache Cocoon to load
dynamically generated classes at runtime.  We re-
compile the code any time the source is altered.
We have seen this work quite well in the server
arena.  You should be able to use it in jEdit.

BTW:

URL for Apache Cocoon is
http://xml.apache.org/cocoon

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

>Comment By: Dale Anson (daleanson)
Date: 2003-02-28 11:55

Message:
Logged In: YES 
user_id=187628

Would this approach make it possible for plugins to have
different versions of the same library jar file? That is,
could plugin A rely on version 1.0 of blah.jar and plugin B
rely on version 1.3 of blah.jar and both jars could be
loaded at the same time? If so, this would go a long way
toward eliminating the odd dependencies that one plugin may
have on another (there may be no real dependency except for
a library file) and would allow a plugin to better control
its library files. 

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

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

Bugs item #672047, was opened at 2003-01-21 16:05
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=672047&group_id=588

Category: plugins
Group: normal bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Derek Groothuis (dgroo)
Assigned to: Nobody/Anonymous (nobody)
>Summary: DotComplete plugin - NPE on quit...

Initial Comment:
I am getting a NullPointerException on certain
occasions when I try to quit (using File->Quit).  It
appears to be related to closing Plugins windows, but
the actual error has occured with respect to several
plugins, so I'm guessing it might be in the API itself.
 The exception I've been getting is:

[debug] SessionManager: session saved: SOAP
[error] AWT-EventQueue-0: java.lang.NullPointerException
[error] AWT-EventQueue-0: 	at
dotcomplete.popup.BasePopup.dispose(Unknown Source)
[error] AWT-EventQueue-0: 	at
dotcomplete.popup.SuicidalMsgPopup.dispose(Unknown Source)
[error] AWT-EventQueue-0: 	at
java.awt.Window$1$DisposeAction.run(Window.java:534)
[error] AWT-EventQueue-0: 	at
java.awt.Window.dispose(Window.java:552)
[error] AWT-EventQueue-0: 	at
org.gjt.sp.jedit.View.close(Unknown Source)
[error] AWT-EventQueue-0: 	at
org.gjt.sp.jedit.jEdit.exit(Unknown Source)
[error] AWT-EventQueue-0: 	at
org.gjt.sp.jedit.jEdit.closeView(Unknown Source)
[error] AWT-EventQueue-0: 	at
org.gjt.sp.jedit.jEdit.closeView(Unknown Source)
[error] AWT-EventQueue-0: 	at
org.gjt.sp.jedit.View$WindowHandler.windowClosing(Unknown
Source)
[error] AWT-EventQueue-0: 	at
java.awt.AWTEventMulticaster.windowClosing(AWTEventMulticaster.java:287)
[error] AWT-EventQueue-0: 	at
java.awt.Window.processWindowEvent(Window.java:1102)
[error] AWT-EventQueue-0: 	at
javax.swing.JFrame.processWindowEvent(JFrame.java:266)
[error] AWT-EventQueue-0: 	at
java.awt.Window.processEvent(Window.java:1061)
[error] AWT-EventQueue-0: 	at
java.awt.Component.dispatchEventImpl(Component.java:3598)
[error] AWT-EventQueue-0: 	at
java.awt.Container.dispatchEventImpl(Container.java:1623)
[error] AWT-EventQueue-0: 	at
java.awt.Window.dispatchEventImpl(Window.java:1585)
[error] AWT-EventQueue-0: 	at
java.awt.Component.dispatchEvent(Component.java:3439)
[error] AWT-EventQueue-0: 	at
java.awt.EventQueue.dispatchEvent(EventQueue.java:450)
[error] AWT-EventQueue-0: 	at
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:197)
[error] AWT-EventQueue-0: 	at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
[error] AWT-EventQueue-0: 	at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144)
[error] AWT-EventQueue-0: 	at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136)
[error] AWT-EventQueue-0: 	at
java.awt.EventDispatchThread.run(EventDispatchThread.java:99)


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

Comment By: Derek Groothuis (dgroo)
Date: 2003-01-22 11:05

Message:
Logged In: YES 
user_id=566189

Slava - looks like you're right.  I'll let the developer
know.  The other bug (weird files opening) does appear to be
related to something else, though...

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

Comment By: Slava Pestov (spestov)
Date: 2003-01-21 16:15

Message:
Logged In: YES 
user_id=2280

If you look at the traceback, it mentions the DotComplete
plugin. Try removing this plugin.

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

Comment By: Derek Groothuis (dgroo)
Date: 2003-01-21 16:06

Message:
Logged In: YES 
user_id=566189

Sorry - using 4.1pre8 on Windows XP

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

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

Bugs item #424234, was opened at 2001-05-15 10:42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=424234&group_id=588

Category: plugins
Group: normal bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: pressing Esc with codeaid pop open

Initial Comment:
when a codeaid popup is open, pressing escape 
generates this error:

[debug] MemberPopup$KeyHandler: keyPressed source: 
[org.gjt.sp.jedit.textarea.JEditTextArea
[,2,26,998x718,layout=org.gjt.sp.jedit.textarea.JEditTe
xtArea$ScrollLayout,alignmentX=null,alignmentY=null,bor
der=org.gjt.sp.jedit.textarea.JEditTextArea$TextAreaBor
der@58f1fa,flags=16,maximumSize=,minimumSize=,preferred
Size=]]
[error] BeanShell: bsh.EvalError: Error in method 
invocation: Method removeSelection(int) not found in 
class'org.gjt.sp.jedit.textarea.JEditTextArea' : 
textArea .removeSelection ( textArea .getCaretPosition 
( ) ) 
[error] BeanShell: 	at bsh.BSHMethodInvocation.eval
(BSHMethodInvocation.java:31)
[error] BeanShell: 	at 
bsh.BSHPrimaryExpression.eval
(BSHPrimaryExpression.java:48)
[error] BeanShell: 	at bsh.BSHBlock.eval
(BSHBlock.java:29)
[error] BeanShell: 	at 
bsh.BshMethod.invokeDeclaredMethod(BshMethod.java:101)
[error] BeanShell: 	at 
bsh.BshMethod.invokeDeclaredMethod(BshMethod.java:47)
[error] BeanShell: 	at 
org.gjt.sp.jedit.BeanShell.invokeMethod
(BeanShell.java:314)
[error] BeanShell: 	at 
org.gjt.sp.jedit.BeanShellAction.invoke
(BeanShellAction.java:56)
[error] BeanShell: 	at 
org.gjt.sp.jedit.gui.InputHandler.invokeAction
(InputHandler.java:175)
[error] BeanShell: 	at 
org.gjt.sp.jedit.gui.DefaultInputHandler.keyPressed
(DefaultInputHandler.java:193)
[error] BeanShell: 	at 
org.gjt.sp.jedit.View.processKeyEvent(View.java:647)
[error] BeanShell: 	at 
java.awt.Component.processEvent(Unknown Source)
[error] BeanShell: 	at 
java.awt.Container.processEvent(Unknown Source)
[error] BeanShell: 	at java.awt.Window.processEvent
(Unknown Source)
[error] BeanShell: 	at 
java.awt.Component.dispatchEventImpl(Unknown Source)
[error] BeanShell: 	at 
java.awt.Container.dispatchEventImpl(Unknown Source)
[error] BeanShell: 	at 
java.awt.Window.dispatchEventImpl(Unknown Source)
[error] BeanShell: 	at 
java.awt.Component.dispatchEvent(Unknown Source)
[error] BeanShell: 	at 
java.awt.EventQueue.dispatchEvent(Unknown Source)
[error] BeanShell: 	at 
java.awt.EventDispatchThread.pumpOneEventForHierarchy
(Unknown Source)
[error] BeanShell: 	at 
java.awt.EventDispatchThread.pumpEventsForHierarchy
(Unknown Source)
[error] BeanShell: 	at 
java.awt.EventDispatchThread.pumpEvents(Unknown Source)
[error] BeanShell: 	at 
java.awt.EventDispatchThread.run(Unknown Source)

jdk1.3.1, win2k, jEdit 3.2pre1

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

>Comment By: Slava Pestov (spestov)
Date: 2003-02-28 12:31

Message:
Logged In: YES 
user_id=2280

out of date. 

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

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

Bugs item #695021, was opened at 2003-02-28 07:41
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=695021&group_id=588

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Crashes when saving under Blackdown JVM

Initial Comment:
Intermittent failure on Jedit 4.1pre11 when saving
files using the Blackdown JDK under Suse LInux.

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

>Comment By: Slava Pestov (spestov)
Date: 2003-02-28 12:31

Message:
Logged In: YES 
user_id=2280

More details please. What plugins are installed? Where are you saving 
the file? What settings are set in the Loading & Saving pane? 

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

Comment By: Nobody/Anonymous (nobody)
Date: 2003-02-28 11:38

Message:
Logged In: NO 

Also happens under IBM JDK 1.4 and SUN JDK 1.4

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

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

Bugs item #538261, was opened at 2002-04-02 06:28
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=538261&group_id=588

Category: editor core
Group: minor bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Toolbar icons aren't always repainted

Initial Comment:
OS: Windows 2000
jdk: 1.4.0

[seen in jEdit 4.0 pre7-
pre9]
Sometimes toolbar icons aren't repainted when they 
should. Only the background color shows where the icons should be. 
When moving your mouse pointer above an invisible icon it 
reappears.
The same problem exists also for the icons in the 
buffer selector and the file system browser.

[seen in jEdit 4.0 
pre7]
The X in the docking tabs have the same problem and these 
won't reappear when moving the mouse pointer above them, but you 
need to click them to make them reappear.

This "disappearing 
icons" problem was very much more frequent in pre7 than in pre8 and 
pre9, but it still exists. The problems seems to appear more 
frequently when bringing jEdit to the front from behind another 
window after using many other programs for a while. Also suspending 
and resuming windows can make the problem appear.

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

>Comment By: Slava Pestov (spestov)
Date: 2003-02-28 12:30

Message:
Logged In: YES 
user_id=2280

Java bug. 

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

Comment By: Jeffrey Burns (jfburns)
Date: 2002-10-15 13:18

Message:
Logged In: YES 
user_id=461047

If your using alot of plugins, you may need a heap larger
than the default 32 MB. This used to happen to me when
JIndex loaded the documentation index. I just loaded it now:
the memory status bar indicates 25 MB of a 35 MB heap now in
use. Linux users can modify JAVA_HEAP_SIZE in the startup
script. I believe that the jedit launcher for Windows has a
spinner to set the heap size, but I may be wrong. If not,
look for the -mx32m command line option and change 32 to
something larger.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-10-15 11:13

Message:
Logged In: NO 

I have seen the same problem in other Java apps on JRE 
1.4.x. So I am starting to think its a Java bug.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-04-12 10:07

Message:
Logged In: NO 

Now it happened in jEdit 4.0 final, too.

I've also seen it happen to 
icons in the File System Browser.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-04-02 10:11

Message:
Logged In: NO 

i've seen it also in pre7 and pre8.  just got pre9, so i 
can't confirm.  i'm also on Win2k, jdk1.4.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-04-02 09:43

Message:
Logged In: NO 

> [seen in jEdit 4.0pre7]
> The X in the docking tabs have the same 
problem
> and these won't reappear when moving the mouse
> pointer 
above them, but you need to click them
> to make them reappear.

Now it 
happened in 4.0pre9, too.

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

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

Bugs item #410138, was opened at 2001-03-20 15:05
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=410138&group_id=588

Category: editor core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Slava Pestov (spestov)
Summary: Meta keys wrong with Dvorak keyboard on 

Initial Comment:
I am using jEdit on a Mac with Dvorak keyboard layout. All the meta keys are in the Qwerty location, not the Dvorak location. For example M+c becomes command-j because Querty c is Dvorak j.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-11-20 10:24

Message:
Logged In: NO 

This is not a JEdit problem, it is Mac OS X's JVM that
ignores the non-qwerty keyboard layout and it affects all
Java programs on Mac OS X.  It's best to just wait for Apple
to fix it (I'm going to report it there if it is not already
in their bug database)

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

Comment By: Gina Wilson (ginaw)
Date: 2001-08-07 14:25

Message:
Logged In: YES 
user_id=291834

Other than manually changing the key combinations I was wondering if there were any other solutions to this problem

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

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

Bugs item #523596, was opened at 2002-02-27 16:19
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=523596&group_id=588

Category: plugins
Group: normal bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Slava Pestov (spestov)
Summary: Focus moves to Console after recompile

Initial Comment:
The focus moves from the text area to the Console after a successfule 
recompile made after an unsuccessful compile.

This is 
extremely annoying.

(Tested with jEdit 4.0pre6, JCompiler 
1.5.0 and Console 3.1.)

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

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

Bugs item #528821, was opened at 2002-03-12 00:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=528821&group_id=588

Category: plugin manager
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Slava Pestov (spestov)
Summary: Fix loading/unloading of plugins

Initial Comment:
Please fix the unnoying need to restart jEdit when we
load or unload plugins.  The way that it can be done
takes advantage of heirarchical classloaders.

Basically, you have a parent classloader that takes care
of all the core classes.  For EACH plugin jar, you load
it in its own classloader with the parent being the core
classloader.

Something along the lines of this:

m_coreManager = this.class.getClassLoader();
m_classloaderMap = new HashMap();

// for new jars added to the system
m_classloaderMap.put( pathToPlugin,
               new UrlClassLoader( pathToPlugin ) );

// to remove a plugin
m_classloaderMap.remove( pathToPlugin );

// to update a plugin
m_classloaderMap.put( pathToPlugin,
               new UrlClassLoader( pathToPlugin ) );


// to load a class for the plugin
ClassLoader loader = (ClassLoader)
            m_classloaderMap.get( pathToPlugin );
Plugin pi = (Plugin)
     loader.loadClass( Plugin.START_CLASS )
     .newInstance();

Of course, when you no longer need it, you have the
plugin clean up after itself and remove the entry in
the classloaderMap.


We use this approach in Apache Cocoon to load
dynamically generated classes at runtime.  We re-
compile the code any time the source is altered.
We have seen this work quite well in the server
arena.  You should be able to use it in jEdit.

BTW:

URL for Apache Cocoon is
http://xml.apache.org/cocoon

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

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

Bugs item #534643, was opened at 2002-03-25 07:00
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=534643&group_id=588

Category: text area and syntax packages
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Slava Pestov (spestov)
Summary: Page up/dow keys don't go with word wrap

Initial Comment:
Hello there,

when using word wrap the page, the page up and page 
down keys make far too large jumps. I suppose this is because the 
calculation of how many lines to jump is done for real text lines 
(those with a number) and not for multiple lines one (numbered) 
line splits into when using word wrap.

I use jEdit 4.0 pre 7 
(just downloading pre 8 :-) with  the Sun JDK 1.4.0

Bye Tobias

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

Comment By: Slava Pestov (spestov)
Date: 2002-12-30 22:31

Message:
Logged In: YES 
user_id=2280

4.1 improves this somewhat -- Scroll up/down page go with
soft wrap. Page up/down will be fixed in 4.2.

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

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

Bugs item #540024, was opened at 2002-04-05 17:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=540024&group_id=588

Category: editor core
Group: normal bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Slava Pestov (spestov)
>Summary: Undo fails to reset "modified" status

Initial Comment:
The following sequence involving "undo" causes jEdit to
fail to reset the document's status to "unmodified"
when it should:

1. Make a small modification to an unmodified file
(e.g. insert a space).
2. Undo the change.
3. Redo.
4. Undo again.

This sequence should reset the document to
"unmodified", but it doesn't.

I'm running version 4.0pre9 under Linux Mandrake 8.1.

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

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

Bugs item #550467, was opened at 2002-04-29 22:04
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=550467&group_id=588

Category: None
Group: minor bug
Status: Open
Resolution: Invalid
Priority: 1
Submitted By: Pierre Grimaud (ignatzmouse)
>Assigned to: Slava Pestov (spestov)
Summary: Vertical text not properly displayed

Initial Comment:
Under SunOS 5.8 JDK1.3.1, the vertical text associated 
with the left or right docked windows is not properly 
displayed. It works fine under Win32 (Win2000, jdk1.4).

For example, I docked "Ant Farm" and "JBrowse" in 
left. The two buttons does not display the name 
properly. 

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

Comment By: Pierre Grimaud (ignatzmouse)
Date: 2002-10-01 14:09

Message:
Logged In: YES 
user_id=530082

Ok, then let's describe a way of reproducing that. I am
using WinAxe 6.1 on Windows NT 4.0, and I selected "Courier
12 plain" as the font for "Button, Menu and Label". Then 
after restarting jEdit, the vertical text is screwed. Also,
if I check the properties again, the font displays
"monospaced 12 plain" and not "courier 12 plain" anymore....

I'm running jEdit 4.1pre4 but it had the same problem with
the version 4.0.3. I'm using jdk1.3 on a solaris box (SunOS
5.8 Generic_108528-13 sun4u sparc SUNW,Ultra-60)


[message] Log: When reporting bugs, please include the
following information:
[message] Log: java.version=1.3.0
[message] Log: java.vm.version=1.3.0
[message] Log: java.runtime.version=1.3.0
[message] Log: java.vendor=Sun Microsystems Inc.
[message] Log: java.compiler=null
[message] Log: os.name=SunOS
[message] Log: os.version=5.8
[message] Log: os.arch=sparc
[message] Log: user.home=/net/home/pierre
[message] Log: java.home=/auto/usrlocal/jdk1.3/jre
[message] Log:
java.class.path=/net/home/pierre/bin/jedit41/jedit.jar:/net/home/pierre/lib/IgnatzPackage.jar:/net/home/pierre/metreo/weblogic/wlserver6.1/lib/weblogic.jar:/usr/local/j2sdkee1.3.1/lib/j2ee.jar:/net/home/pierre/jeditClasses:/vobs/m2/tp/struts.jar


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

Comment By: Slava Pestov (spestov)
Date: 2002-06-05 21:09

Message:
Logged In: YES 
user_id=2280

Even if it is a Swing bug I'm sure a workaround can be
found. I'm re-opening the bug.

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

Comment By: Pierre Grimaud (ignatzmouse)
Date: 2002-06-05 17:49

Message:
Logged In: YES 
user_id=530082

It seems that some fonts does not display properly vertical 
text under X-Window. I don't know who handles the vertical 
display but I assumed that it is Swing so that's why I closed 
the bug.

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

Comment By: Pierre Grimaud (ignatzmouse)
Date: 2002-06-05 17:48

Message:
Logged In: YES 
user_id=530082

It seems that some fonts does not display properly vertical 
text under X-Window. I don't know who handles the vertical 
display but I assumed that it is Swing so that's why I closed 
the bug.

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

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

Bugs item #550820, was opened at 2002-04-30 18:37
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=550820&group_id=588

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Slava Pestov (spestov)
Summary: Display Problem on Mac OS X Dual Monitor

Initial Comment:
When jEdit window is moved to the secondary 
monitor it doesn't work entirely properly. When 
resized it sets it height and width to the height and 
width of the screen (correct thing to do) and then 
sets the top of the menu bar several pixels down 
(wrong thing to do) seemingly to accomodate the 
finder menu that should be displayed at the top. Of 
course, since this is the second monitor there is 
not a finder menu at the top of the screen. Also, the 
window is too tal as a result (the window height 
does not compensate for the top being set lower). 
Trying to move the menu bar into the region it 
seems to believe is occupied by the finder menu 
causes the window to stutter and jump back down 
to the lower position. Since the window is too tall 
for the screen the lower right hand corner is 
unavailable (thus the window can't be resized to fit 
the screen).

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-04-30 20:45

Message:
Logged In: NO 

That is a known bug in Apple's Java implementation.

Not much jEdit can do about this.

Gerd

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

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

Bugs item #568715, was opened at 2002-06-13 18:02
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=568715&group_id=588

Category: plugins
Group: normal bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Slava Pestov (spestov)
Summary: FTP plugin and VMS

Initial Comment:
FTP plug in does not work when trying to access VMS
machines. On initial login, the FTP plugin tries to
issue a "cd ./". This is Unix file path terminology,
which is not legal under VMS. 

Specific error displayed is:
Cannot list directory. ftp.FtpException:550 %RMS-F-SYN,
file specification error: [./]

Log file output is:
[debug] FtpClient: sending command: PWD
[debug] FtpClient: received response: 257
"DISK$USER4:[xxx.xxx]"
[debug] ConnectionManager$Connection: Connection to
boise5:21 locked
[debug] ConnectionManager$Connection: Connection to
boise5:21 released
[debug] ConnectionManager$Connection: Connection to
boise5:21 locked
[debug] FtpClient: sending command: TYPE A N
[debug] FtpClient: received response: 200 TYPE command
okay.
[debug] FtpClient: sending command: CWD /
[debug] FtpClient: received response: 550 %RMS-F-SYN,
file specification syntax error: [./]
[debug] ConnectionManager$Connection: Connection to
boise5:21 released
[debug] DockableWindowManager$Entry: Adding log-viewer
with position bottom
[debug] ConnectionManager: Closing connection to boise5:21
[debug] FtpClient: sending command: QUIT
[debug] FtpClient: received response: 221 Service
closing connection.

Does the "cd ./" really have to be there. Don't you
automatically get placed in the users home directory
upon ftp login?

If the "cd ./" has to be there for some hosts, can it
be made optional?

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

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

Bugs item #555755, was opened at 2002-05-14 00:59
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=555755&group_id=588

Category: editor core
Group: normal bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Fan Ho Yin (beebebebebe)
>Assigned to: Slava Pestov (spestov)
Summary: No confirmation for deleted file on exit

Initial Comment:
The "File Deleted on Disk" dialog does not show up when
exiting jEdit. Sometimes it does appear but gives no
chance to re-save the deleted file.

To reproduce this behaviour:
1) open two files
2) delete the file opened in the non-active buffer
3) close jEdit

if changes have been made on the active buffer the
"File Deleted on Disk" dialog will show up after the
"Unsaved Changes" dialog, but it exits straight away
after clicked "OK". On the other hand if no change has
been made on the active buffer the "File Deleted on
Disk" dialog wouldn't show up at all.

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

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

Bugs item #567346, was opened at 2002-06-11 06:38
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=567346&group_id=588

Category: plugins
Group: normal bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Slava Pestov (spestov)
Summary: FTP plugin does not lock read-only files

Initial Comment:
When jEdit is used for editing files in a remote host with the 
FTP plugin, read-only files are not locked and can be 
overwritten.

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

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

Bugs item #598505, was opened at 2002-08-21 19:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=598505&group_id=588

Category: editor core
Group: normal bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Lars Hoss (woeye)
>Assigned to: Slava Pestov (spestov)
Summary: MacOS X + german keyboard layout prob

Initial Comment:
The EditAction "next-char" is assigned to Alt + L. The same 
keystoke is assigned to the "@" character on the Mac keyboard 
using german keyboard layout as well. Therefore this keystroke 
produces the "@" character followed by a jump to the next 
character. I could circumvent the problem by removing the line

next-char.shortcut2=A+l

from the file jedit_keys.props. 

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

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

Bugs item #601948, was opened at 2002-08-29 11:51
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=601948&group_id=588

Category: macros
Group: None
Status: Open
Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Slava Pestov (spestov)
Summary: Macro Recording drops HTML code

Initial Comment:
When creating a "code snippet" macro under Mac OSX the macro 
seems to drop HTML code that I have typed while recording the 
macro. For example, I hit MACROS > RECORD MACRO then 
type something like <h3>Title</h3> then STOP RECORDING 
MACRO ... when I save the Macro, assign a keyboard shortcut 
(which by the way, I have to RESTART JEdit for the new macro to 
display in the shortcuts list) and then run the macro, it displays 
the text: <Title> as it has cut out the HTML ... If I go in, edit the 
macro by hand and save it again, it works fine. This may not be a 
bug, it may be that Macros weren't meant for this, but if they 
weren't, it would be a nice feature.

jm...@ga...

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

Comment By: Slava Pestov (spestov)
Date: 2002-11-21 14:37

Message:
Logged In: YES 
user_id=2280

Actually the main problem (broken recording of <, >, &, with
XML plugin installed) still stands; it will be fixed in a
future XML plugin release. I am re-opening the bug.

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

Comment By: John Gellene (jgellene)
Date: 2002-11-21 10:24

Message:
Logged In: YES 
user_id=117073

There has been no response to my query for some time, and 
the main problem seems to be solved using the 
Macros>Rescan Macros feature, so I am closing this report.

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

Comment By: John Gellene (jgellene)
Date: 2002-10-07 22:57

Message:
Logged In: YES 
user_id=117073

The Macros>Rescan Macros command will refresh the 
macros menu after recording a new macro.  I cannot not 
replicate the error in the macro itself.  Could you post the 
BeanShell code of the recorded example macro?

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

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

Bugs item #601965, was opened at 2002-08-29 12:33
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=601965&group_id=588

Category: editor core
Group: severe bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Rosenberg (jbrosenberg)
>Assigned to: Slava Pestov (spestov)
>Summary: Softwrap -> jerky scrolling w/long lines

Initial Comment:
This is a serious problem....We are creating an XML 
text-editing use of the jEdit + XML plugin, where 
we need to markup individual paragraphs, that have 
no interspersed line returns.....

So, each paragraph is a long line (not super long, 
mind you)....Anyway, the scrolling is very jerky 
when soft-wrap is enabled....Very difficult to 
navigate a document.

I don't know if this is supposed to be fixed in 4.1 
or not, it doesn't appear to be improved the 4.1pre4 
version.  I have been working with 4.0.3.

In looking at the source code, it appears that it 
recalculates the virtual line number each time the 
text area is scrolled, instead of keeping a pre-
formatted virtual copy of the document in memory.

Not sure how complicated it would be to fix, but it 
quite clearly is necessary.  I am new to jEdit 
development, but don't mind tackling this, if I 
could have some insight as to the potential issues...

Not sure if this bug is related to bug #223174.

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

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

Bugs item #639930, was opened at 2002-11-18 02:30
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=639930&group_id=588

Category: search and replace
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Oliver Kitzing (oliverkitzing)
>Assigned to: Slava Pestov (spestov)
>Summary: JEdit doesn't find "ß" character

Initial Comment:
JEdit 4.1pre5 on WinXP.

Type

Außerdem

(yes, that's german ;-) ) in a new file and try
to search it.

JEdit won't find it !



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

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

Bugs item #667042, was opened at 2003-01-13 03:22
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=667042&group_id=588

Category: editor core
Group: minor bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Lars Naber (nobettername)
>Assigned to: Slava Pestov (spestov)
Summary: File look-up case-sensitive

Initial Comment:
Hi,

since 4.1pre the "look-up" of a file in the file-manager is case-sensitive.

Example:
I want to open a file, but there are two files:

ABC.txt
test1.txt

When I type "ab", the first file is not chosen. I have to type "AB".

I really don't know if it's a bug or not, but 4.0.3 didn't have this problem.

Thanks.

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

Comment By: Lars Naber (nobettername)
Date: 2003-01-30 09:40

Message:
Logged In: YES 
user_id=686953

I'm very sorry. The stuff I wrote before is big rubbish and makes trouble when you type a filename to save.

The original problem is still unsolved in 4.1pre9.

Again sorry.

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

Comment By: Lars Naber (nobettername)
Date: 2003-01-27 04:13

Message:
Logged In: YES 
user_id=686953

I changed in the file
VFSFileChooserDialog.java
lines 440-442 the ignorecase to "true":

view.getTree().doTypeSelect(filenameField.getText(), true);

It seems to work.

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

Comment By: Lars Naber (nobettername)
Date: 2003-01-27 02:55

Message:
Logged In: YES 
user_id=686953

Thanks for use answer. I'll try to be more precise now.

I've done some tests. The oldest pre-version on my harddisk is 4.1pre5. It has the problem. It's still there in 
4.1pre8. I attached some images. Perhaps they will help?

jeditfo1.png (4.1pre8): I typed "bi" ("my normal way"), Bilbo.txt is not selected
jeditfo2.png (4.1pre8): I typed "BI", Bilbo.txt is not selected
jeditfo3.png (4.1pre8): I typed "Bi", Bilbo.txt is selected
jeditfo4.png (4.0.3): Typed "bi"... Cursor is placed on Bilbo.txt

[message] Log: java.version=1.4.0_01
[message] Log: java.vm.version=1.4.0_01-b03
[message] Log: java.runtime.version=1.4.0_01-b03
[message] Log: java.vendor=Sun Microsystems Inc.
[message] Log: java.compiler=null
[message] Log: os.name=Windows 95

Hope it helps...

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

Comment By: Carmine Lucarelli (carmine)
Date: 2003-01-24 14:45

Message:
Logged In: YES 
user_id=189246

What number "pre" version are you using?   I can't 
reproduce this bug with 4.1pre8.

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

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

Bugs item #615394, was opened at 2002-09-27 03:02
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=615394&group_id=588

Category: text area and syntax packages
Group: severe bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Slava Pestov (spestov)
>Summary: AT_LINE_START should apply to </END>

Initial Comment:
AT_LINE_START should apply to </END>
or there sould be an option that it does
for edit modes.

This is important for perl,
cause

=pod

    IT SHOULDN't STOP at this =cut
    BUT THE NEXT  

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

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

Bugs item #641279, was opened at 2002-11-20 10:41
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=641279&group_id=588

Category: editor core
Group: normal bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Lyons (plyons)
>Assigned to: Slava Pestov (spestov)
Summary: Complete Word popup list ignores keyboar

Initial Comment:
When the Complete Word feature pops up a list of
possible completions, you must dismiss this list with
the mouse.  You should be able to use the arrow keys to
highlight entries and ENTER to insert one and dismiss
the popup. ESC should dismiss the popup without
inserting text.  This bug severely reduces the
usefulness of Complete Word.  You should also be able
to continue typing and narrow the list down. As an
additional suggestion, I would suggest that Complete
Word work more like Mac OS X's Project Builder when
there is more than 1 possible completion - cycle
through them with each additional hit of the keyboard
command (C-b). Project Builder does this without a
popup, but keeping the popup would be OK as well.


JEdit 4.1 pre2
Java(TM) 2 Runtime Environment, Standard Edition (build
1.4.1-b21)
Debian GNU/Linux 2.4.19 kernel

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

Comment By: Peter Lyons (plyons)
Date: 2002-12-28 00:38

Message:
Logged In: YES 
user_id=653202

Just FYI I just downloaded JEdit 4.1pre7 and this bug is
still there.

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

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

Bugs item #648286, was opened at 2002-12-04 04:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=648286&group_id=588

Category: editor core
Group: None
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: David Rushby (woodsplitter)
>Assigned to: Slava Pestov (spestov)
Summary: integrated wheel mouse scrolling faulty

Initial Comment:
  In 4.1_pre6, the integrated wheel mouse scrolling
ignores system settings with regard to scrolling ('N
lines at a time' vs. 'one screen at a time').  This
would be no big deal if jEdit provided an option to
change the scrolling behavior, but no such option is
available, AFAIK.

  The WheelMouse plugin for jEdit 4.0.3 and earlier
behaved correctly; perhaps it would be a good reference
point for a bugfix?

  I'm using Win2000SP3 and Java 1.4.1_01.

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

Comment By: David Rushby (woodsplitter)
Date: 2002-12-25 22:45

Message:
Logged In: YES 
user_id=414645

Thanks for addressing this, Slava.

However, I just tried 4.1_pre7 on WinNT4/SP6a with Java
1.4.1_01, and this bug is still evident.

It's not a mouse driver problem or a WinNT4 deficiency,
either; native apps such as IE 6 behave properly, as do
cross-platform apps such as Mozilla and jEdit
4.0.3+WheelMouse plugin.

My work machine runs Windows 2000/SP3; I could try 4.1_pre7
on it and report the status of this bug on Win2000, if you'd
like.

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

Comment By: Slava Pestov (spestov)
Date: 2002-12-25 16:24

Message:
Logged In: YES 
user_id=2280

fixed in 4.1pre7.

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

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