jedit-devel Mailing List for jEdit

On 30/11/2009, at 19.12, Kazutoshi Satoda wrote:

> Shlomy Reinstein wrote:
>> I took a quick look at many bugs, and found out the following:
> 
>> 1. Many (I'd say roughly about 25%) of the bugs are mode-specific.
>> These are not part of the jEdit core, but instead of the mode files.
>> Some of them are probably fixed by now, but in any case they should
>> not be counted as jEdit bugs wrt the release process, I think.
> 
> I disagree on this point.
> 
> Separating plugin-bugs seems reasonable for me since plugins can be
> released in their own schedule, not with the core release schedule.
> As for mode files, they are released with core. Here I can't see any
> reason to separate the bugs on this line. I think this viewpoint is
> same from users.
> 
>> 2. Many other bugs are OS-X-specific, and although they are part of
>> the core, they are somewhat special, as they do not occur with other
>> operating systems, and I think they should also not block releases.
> 
> I hope this is true.
> 
> I have felt a little increase of developers who seem to have handy
> Mac OS X environment; Seph, Eric, ...
> 
> It might good to ask them to verify this.
Feel free to assign OS X issues to me then I will have a look.

Seph

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: plugin API
Group: normal bug
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Charles Brockman (cbrockman)
Assigned to: Matthew Gilbert (voxmea)
Summary: VoxSpell User Dictionary Malfunction from the Context Menu

Initial Comment:
VoxSpell version 1.0.7 apparently does not correctly implement the context popup menu. I enable VoxSpell and highlight a misspelled word. Then I right-click the mouse and select "Add -" from the popup menu to add the word to the user dictionary. Then underlining is removed from the highlighted word and all other instances of that word in the document. The user dictionary does not change and if I close and restart jEdit, the previously added word is again marked as misspelled.

On the other hand, if I select VoxSpell from the Plugins menu and then select Add Word, the misspelled word is apparently added to the user dictionary as expected.

I'm using Java version 1.6.0_17 and ErrorList 1.7 with jEdit 4.3pre18.


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

>Comment By: Matthew Gilbert (voxmea)
Date: 2009-11-30 15:15

Message:
Please try 1.0.8. Thanks for reporting this!

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

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

Plugin Central Submission item #2906243, was opened at 2009-11-30 15:14
Message generated for change (Tracker Item Submitted) made by voxmea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=625093&aid=2906243&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Matthew Gilbert (voxmea)
Assigned to: Nobody/Anonymous (nobody)
Summary: VoxSpell release 1.0.8

Initial Comment:

{{{ VoxSpell 1.0.8
    Source: Source code is in SVN with the tag release-1.0.8.
    Announcement: 
        =========
        Changelog
        =========
        
        Bug Fixes
        ---------
        
         - Fixed bug #2906226 - add and ignore actions were reversed in the context
           menu.
        
    Requires Java 1.5
    Requires jEdit 04.03.15.00
    Required plugins: 
        errorlist.ErrorListPlugin 1.7
    
    Short Description: English Language Spell Checker
    
    Long Description: <html>

<p>The VoxSpell plugin checks the spelling of English language documents
(more languages may be supported in the future, contact the author if you're
willing to help). It comes bundled with an English language dictionary produced
from the SCOWL word list hosted at (<a
href="http://wordlist.sourceforge.net/">Kevin's Word List Page</a>).</p>

<p>Warning: the algorithm used to store the word suggestion list is unoptimized.
This plugin consumes, typically, ~30MB of memory</p>

</html>
 }}}

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

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

Bugs item #2906226, was opened at 2009-11-30 14:42
Message generated for change (Settings changed) made by voxmea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2906226&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: plugin API
Group: normal bug
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Charles Brockman (cbrockman)
>Assigned to: Matthew Gilbert (voxmea)
Summary: VoxSpell User Dictionary Malfunction from the Context Menu

Initial Comment:
VoxSpell version 1.0.7 apparently does not correctly implement the context popup menu. I enable VoxSpell and highlight a misspelled word. Then I right-click the mouse and select "Add -" from the popup menu to add the word to the user dictionary. Then underlining is removed from the highlighted word and all other instances of that word in the document. The user dictionary does not change and if I close and restart jEdit, the previously added word is again marked as misspelled.

On the other hand, if I select VoxSpell from the Plugins menu and then select Add Word, the misspelled word is apparently added to the user dictionary as expected.

I'm using Java version 1.6.0_17 and ErrorList 1.7 with jEdit 4.3pre18.


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

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

Bugs item #2906226, was opened at 2009-11-30 11:42
Message generated for change (Tracker Item Submitted) made by cbrockman
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2906226&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: plugin API
Group: normal bug
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Charles Brockman (cbrockman)
Assigned to: Nobody/Anonymous (nobody)
Summary: VoxSpell User Dictionary Malfunction from the Context Menu

Initial Comment:
VoxSpell version 1.0.7 apparently does not correctly implement the context popup menu. I enable VoxSpell and highlight a misspelled word. Then I right-click the mouse and select "Add -" from the popup menu to add the word to the user dictionary. Then underlining is removed from the highlighted word and all other instances of that word in the document. The user dictionary does not change and if I close and restart jEdit, the previously added word is again marked as misspelled.

On the other hand, if I select VoxSpell from the Plugins menu and then select Add Word, the misspelled word is apparently added to the user dictionary as expected.

I'm using Java version 1.6.0_17 and ErrorList 1.7 with jEdit 4.3pre18.


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

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

Shlomy Reinstein wrote:
> I took a quick look at many bugs, and found out the following:

> 1. Many (I'd say roughly about 25%) of the bugs are mode-specific.
> These are not part of the jEdit core, but instead of the mode files.
> Some of them are probably fixed by now, but in any case they should
> not be counted as jEdit bugs wrt the release process, I think.

I disagree on this point.

Separating plugin-bugs seems reasonable for me since plugins can be
released in their own schedule, not with the core release schedule.
As for mode files, they are released with core. Here I can't see any
reason to separate the bugs on this line. I think this viewpoint is
same from users.

> 2. Many other bugs are OS-X-specific, and although they are part of
> the core, they are somewhat special, as they do not occur with other
> operating systems, and I think they should also not block releases.

I hope this is true.

I have felt a little increase of developers who seem to have handy
Mac OS X environment; Seph, Eric, ...

It might good to ask them to verify this.

> 3. Some of the bugs are probably already fixed (though they were fixed
> indirectly, for other issues or as part of usual maintenance, so the
> one who fixed was not aware of the open bug report and didn't close
> it). It would, however, require a non-neglectible effort to check the
> bugs one by one and see which are fixed.
(snip)
> It would be great if users or developers could go over the existing
> bugs and check which are fixed, which are not, and preferably rate
> their priority. But this is a big task, given the number of bugs. I
> don't have time to do this myself.

If the problem is lack of time to test and comment, I think calling
help on jedit-users or jedit-announce can be good way. This can also
be applied for the previous point of Mac OS X.

I believe anyone can post a comment which just says like "Works with
jEdit 4.3pre18 + JRE 6u17 + Windows XP SP2". Developers can set the
status (most will go to "Pending") and resolution based on the fact
provided by users.

Any objection?

-- 
k_satoda

Alan Ezust wrote:
> Anyway, I would like to try that for a little while before we resort to
> branching.
> Maybe it won't work. Maybe we will need 2 branches. If so, well, so be it.
> We have the tags that we can make branches from at any time if we need to.

The following page clearly describes what will happen in general.
http://producingoss.com/en/release-branches.html

At least, I will really feel hardness to make a large change on trunk.
You might say "make a branch at the time". But it will be another mental
burden to make such change.

For what reason can you believe in that this won't happen on jEdit?

-- 
k_satoda

Anyway, I would like to try that for a little while before we resort to
branching.
Maybe it won't work. Maybe we will need 2 branches. If so, well, so be it.
We have the tags that we can make branches from at any time if we need to.

2009/11/30 Alan Ezust <ala...@gm...>

>
>
> 2009/11/30 Kazutoshi Satoda <k_s...@f2...>
>
> Dalibor Petričević wrote:
>>
>>
>> > I agree that feature freeze without branching is not very common thing
>> > in software development but in this situation is necessary to make a
>> > clear cut for a few months, fix current code base and then continue to
>> > build on sane and healthy code base.
>>
>> For what reason or logic does branching make such missions impossible?
>>
>> How 4.3.1 (and later patch releases) will be made without branching?
>> (Are you proposing "no patch release" for 4.3, really?)
>>
>>
> We can make later releases without branching the same way we have been
> making releases without branching. We just won't call them "pre" anymore.
>
> Thanks to daily builds and the updater plugin, we can consider our releases
> "stable" and the dailies will contain whatever people are working on.
>
>
>

2009/11/30 Kazutoshi Satoda <k_s...@f2...>

> Dalibor Petričević wrote:
>
>
> > I agree that feature freeze without branching is not very common thing
> > in software development but in this situation is necessary to make a
> > clear cut for a few months, fix current code base and then continue to
> > build on sane and healthy code base.
>
> For what reason or logic does branching make such missions impossible?
>
> How 4.3.1 (and later patch releases) will be made without branching?
> (Are you proposing "no patch release" for 4.3, really?)
>
>
We can make later releases without branching the same way we have been
making releases without branching. We just won't call them "pre" anymore.

Thanks to daily builds and the updater plugin, we can consider our releases
"stable" and the dailies will contain whatever people are working on.

Dalibor Petričević wrote:
>> Could you please explain what is the problem in the current release
>> procedure, which can be solved by your proposal? I could not figure out.
> 
> I do not want to go into current release procedure.

Again, please explain what is the problem with the current release
procedure.

I don't see anything re-reading the release-procedure.txt.

> I agree that feature freeze without branching is not very common thing
> in software development but in this situation is necessary to make a
> clear cut for a few months, fix current code base and then continue to
> build on sane and healthy code base.

For what reason or logic does branching make such missions impossible?

How 4.3.1 (and later patch releases) will be made without branching?
(Are you proposing "no patch release" for 4.3, really?)

-- 
k_satoda

I don't have a definitive answer since I don't know if it is
intentional, but I'd say it is a bug.  Chapter 1 of the jEdit help
manual says the right mouse button is used to show the context menu,
which agrees with the Java Look and Feel Design Guidelines:

"In your design, assume a two-button mouse. Use mouse button 1
(usually the left button) for selection, activation of components,
dragging, and the display of drop-down menus. Use mouse button 2
(usually the right button) to display contextual menus. Do not use the
middle mouse button; it is not available on most target platforms."

Dale


On Mon, Nov 30, 2009 at 4:05 AM, Shlomy Reinstein <sre...@gm...> wrote:
> Hi,
> I forward this to this list because the subject does not match my question.
> Is the text selection using right-click and drag intentional, or is it a bug?
> Shlomy
>
>
> ---------- Forwarded message ----------
> From: Shlomy Reinstein <sre...@gm...>
> Date: Mon, Nov 30, 2009 at 11:37 AM
> Subject: Re: [ jEdit-users ] consideration to change context menu behaviour
> To: e-letter <in...@gm...>
> Cc: jed...@li...
>
>
> Why are you selecting text with the right mouse button? This should be
> done using the left mouse button, just like in most other applications
> that allow selection.
>
> I was not even aware that it's possible to select text with the right
> mouse button. Is there a reason for this? It seems like a bug to me
> that moving the right mouse button selects text.
>
> Shlomy
>
> On Mon, Nov 30, 2009 at 11:30 AM, e-letter <in...@gm...> wrote:
>> Readers,
>>
>> When using the mouse right button to select a block/column of text,
>> the context menu window interferes with the view. It would be better
>> if the context menu disappeared when the CTRL button was pressed with
>> the mouse right button
>>
>> yours,
>>
>> jeditatconference.jabber.org
>> jedit 43pre11
>> ibm java 150
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>> trial. Simplify your report design, integration and deployment - and focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> --
>> -----------------------------------------------
>> jEdit Users' List
>> jEd...@li...
>> https://lists.sourceforge.net/lists/listinfo/jedit-users
>>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> --
> -----------------------------------------------
> jEdit Developers' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>

Plugin Feature Requests item #1694134, was opened at 2007-04-04 12:25
Message generated for change (Settings changed) made by voituk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=1694134&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: stc1 (stc1)
>Assigned to: Voituk Vadim (voituk)
Summary: Open a File over SFTP (File Changed)

Initial Comment:
3.) Open a File over SFTP (Plugin) and Save the File later
----------------------------------------------------------
When somebody else the File has modified during this Time
the modification from "somebody" is lost.
Can you implement a time compare (when the time has changed on the file on the server),
then you get a warning, would be nice.

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

Comment By: Voituk Vadim (voituk)
Date: 2009-04-20 10:23

Message:
There is no way to automate this one ftp/sftp filesystems, so it should be
last-mod-time comparison. 

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

Comment By: Kevin Hunter (hunteke)
Date: 2009-04-20 00:46

Message:
Pardon my (mis)understanding of the VFS, but shouldn't this be something
that happens for all files, (S)FTP or otherwise?

For local, non-FTP files, this is already done.  I know of inotify for
Linux, but don't know how it's done for other OSs.  Is this something that
could be automatic, or does the FTP plugin have to do it since remote files
aren't, well, local?

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

Comment By: Voituk Vadim (voituk)
Date: 2009-04-19 23:31

Message:
Moved to Plugin Feature request.
This feature will be useful for me too.

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

Comment By: Kevin Hunter (hunteke)
Date: 2009-04-19 19:24

Message:
Has this been implemented?  If so, suggest closing this bug.

If not, suggest moving this to a feature request.

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

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

Plugin Central Submission item #2905919, was opened at 2009-11-30 13:36
Message generated for change (Tracker Item Submitted) made by voituk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=625093&aid=2905919&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Voituk Vadim (voituk)
Assigned to: Alan Ezust (ezust)
Summary: FTP 0.9.7

Initial Comment:
{{{ FTP 0.9.7
Source: Source code is in SVN with the tag
plugins/FTP/tags/release-0-9-7
Announcement:
 - New improved FTP URL parser: Fixed bugs #2893214, #2768807, #2334496, #1953257, #899119 (by Vadim Voituk)
 - jsch lib updated to version 0.1.42</para></listitem>

Requires Java 1.5
Requires jEdit 04.03.17.00

Short Description: The FTP plugin adds the ability to browse directories
and edit files on (s)FTP servers.

Long Description: <html>
<p>The FTP plugin plugs into jEdit's virtual filesystem to allow
transparent access to (S)FTP servers. It integrates with the filesystem
browser (hence you can do things like add favorites which point to remote
servers, and such), caches remote directory listings for improved
performance, remembers passwords, and has optional support for
passive-mode
FTP.</p>
</html>
}}}

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

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

Plugin Bugs item #1743583, was opened at 2007-06-26 17:32
Message generated for change (Comment added) made by voituk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=1743583&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 8
Private: No
Submitted By: Matthieu Casanova (kpouer)
Assigned to: Nobody/Anonymous (nobody)
Summary: Ftp 0.9.1 cannot list directories recursively

Initial Comment:
Hi, I'm trying to list the files in a directory recursively, and it seems the plugin goes in loop.
The reason is that in every directory there is an entry "." so when I'm listing
sftp://192.168.1.1/test/
It will try to get the files from sftp://192.168.1.1/test/. and from sftp://192.168.1.1/test/./. and it never ends.
This was working in the past, but I don't remeber in what version it was broken

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

>Comment By: Voituk Vadim (voituk)
Date: 2009-11-30 13:26

Message:
Could you please check if the problem still appears? 

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

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

Hi,
I forward this to this list because the subject does not match my question.
Is the text selection using right-click and drag intentional, or is it a bug?
Shlomy


---------- Forwarded message ----------
From: Shlomy Reinstein <sre...@gm...>
Date: Mon, Nov 30, 2009 at 11:37 AM
Subject: Re: [ jEdit-users ] consideration to change context menu behaviour
To: e-letter <in...@gm...>
Cc: jed...@li...


Why are you selecting text with the right mouse button? This should be
done using the left mouse button, just like in most other applications
that allow selection.

I was not even aware that it's possible to select text with the right
mouse button. Is there a reason for this? It seems like a bug to me
that moving the right mouse button selects text.

Shlomy

On Mon, Nov 30, 2009 at 11:30 AM, e-letter <in...@gm...> wrote:
> Readers,
>
> When using the mouse right button to select a block/column of text,
> the context menu window interferes with the view. It would be better
> if the context menu disappeared when the CTRL button was pressed with
> the mouse right button
>
> yours,
>
> jeditatconference.jabber.org
> jedit 43pre11
> ibm java 150
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> --
> -----------------------------------------------
> jEdit Users' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-users
>

Plugin Bugs item #2867582, was opened at 2009-09-26 21:58
Message generated for change (Settings changed) made by voituk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=2867582&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Christoph Geschwind (chrisgeschwind)
Assigned to: Nobody/Anonymous (nobody)
Summary: FTP Plugin crashes Vista 64 Networking

Initial Comment:
Connecting to my FTP Server works, opening a file works, saving it somehow crashes my Internet Connection, making me unable to recover it, rebooting is the only thing that helps.
I have a fresh installation of Vista 64 Business with Java 1.6.0_16 and jEdit 4.3pre17.

I think with a different SFTP server there is no problem, I'll try that again later and post here if not.
On my Notebook with a slightly older jEdit Version (installed on may '09) and Win XP SP2 everything works fine, same Server.

Hope you have an idea, I really appreciate using jEdit and spent about 5 hours to find a different editor that suits my needs and didnt find one :-(

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

>Comment By: Voituk Vadim (voituk)
Date: 2009-11-30 13:03

Message:
Can`t reproduce.

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

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

Plugin Bugs item #899119, was opened at 2004-02-17 23:59
Message generated for change (Comment added) made by voituk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=899119&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Brad Mace (bemace)
Assigned to: Slava Pestov (spestov)
Summary: FTP ignores password in url

Initial Comment:
The FTP plugin doesn't seem to look at the password in
urls.  When opening a url including username and
password, it prompts for a password, using the entire
username:password string as the username.

Here's what I'm doing in case I'm just wrong:

VFS vfs = VFSManager.getVFSForProtocol("ftp");
		Object session =
vfs.createVFSSession("ftp://anonymous:weather%40j...@we...:21/data/observations/metar/stations/",jEdit.getActiveView());
		InputStream is =
vfs._createInputStream(session,"ftp://anonymous:weather%40j...@we...:21/data/observations/metar/stations/"+icao.toUpperCase()+".TXT",false,jEdit.getActiveView());

This works fine when run from a JUnit test outside of
jEdit, but always prompts for a password when used in
another plugin.

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

>Comment By: Voituk Vadim (voituk)
Date: 2009-11-30 12:43

Message:
Fixed in version 0.9.7

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

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

Hi,

On Sun, 29 Nov 2009 23:03:12 +0200
Shlomy Reinstein <sre...@gm...> wrote:

> Other than that, many users still use 4.2 only because they consider
> any 'pre' release to be less stable.

In this case you should really release a new version without the 'pre'
extension asap (imho).

4.2 final is ancient, do you really want people to use this version
instead of the latest 4.3preX? Is it really better? At least more
bugfree? I don't believe this.

If you want that the more conservative user stays with 4.2 keep on
creating pre-releases, but if not, you should really consider to
release a version without 'pre' soon. 

I'm using the latest daily build without problems. As everybody knows,
software is never completely bugfree and can of course always be
improved, but as far as I can tell jEdit in its current state is stable
and a great tool. 

Manfred


-- 
Manfred Usselmann <uss...@ic...>
ICG IT Consulting GmbH, Kelkheim

Bugs item #1215990, was opened at 2005-06-06 14:24
Message generated for change (Settings changed) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1215990&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: editor core
Group: None
>Status: Closed
Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Paul N (vlion)
Assigned to: Nobody/Anonymous (nobody)
Summary: Menu location borked in OSX 10.4 + jEdit4.3

Initial Comment:
Hiya.

OSX 10.4 with jEdit 4.2final and 4.3(dev version on
main page)
The menu bar has jumped to the window, not the top bar
as it was.



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

Comment By: Alan Ezust (ezust)
Date: 2009-11-29 13:17

Message:
It also depends on what "Global options - Appearance - Swing Look and Feel"
you have. 
If you choose  "metal" instead of mac, then you'll get a regular menu bar
at the top of your main window, like in a normal desktop OS.


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

Comment By: kerik (kerik-sf)
Date: 2009-11-29 12:53

Message:
the new OSX plugin works !

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

Comment By: kerik (kerik-sf)
Date: 2009-11-29 12:53

Message:
the new OSX plugin works !

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

Comment By: kerik (kerik-sf)
Date: 2009-11-29 12:53

Message:
works for me, using the jEdit.app.
my setup : java 5 on OS X 10.4.11, jedit 4.3pre18

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

Comment By: Paul N (vlion)
Date: 2005-06-06 15:10

Message:
Logged In: YES 
user_id=793516

Update: OSX plugin won't load in 4.3;
Flipping the menu-bar flag in the plugin for 4.2 doesn't do
anything.


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

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

Bugs item #1215990, was opened at 2005-06-06 14:24
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1215990&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: editor core
Group: None
Status: Pending
Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Paul N (vlion)
Assigned to: Nobody/Anonymous (nobody)
Summary: Menu location borked in OSX 10.4 + jEdit4.3

Initial Comment:
Hiya.

OSX 10.4 with jEdit 4.2final and 4.3(dev version on
main page)
The menu bar has jumped to the window, not the top bar
as it was.



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

>Comment By: Alan Ezust (ezust)
Date: 2009-11-29 13:17

Message:
It also depends on what "Global options - Appearance - Swing Look and Feel"
you have. 
If you choose  "metal" instead of mac, then you'll get a regular menu bar
at the top of your main window, like in a normal desktop OS.


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

Comment By: kerik (kerik-sf)
Date: 2009-11-29 12:53

Message:
the new OSX plugin works !

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

Comment By: kerik (kerik-sf)
Date: 2009-11-29 12:53

Message:
the new OSX plugin works !

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

Comment By: kerik (kerik-sf)
Date: 2009-11-29 12:53

Message:
works for me, using the jEdit.app.
my setup : java 5 on OS X 10.4.11, jedit 4.3pre18

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

Comment By: Paul N (vlion)
Date: 2005-06-06 15:10

Message:
Logged In: YES 
user_id=793516

Update: OSX plugin won't load in 4.3;
Flipping the menu-bar flag in the plugin for 4.2 doesn't do
anything.


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

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

Bugs item #1415715, was opened at 2006-01-26 22:38
Message generated for change (Comment added) made by kerik-sf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1415715&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: minor bug
>Status: Pending
>Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Anders Montonen (antime)
Assigned to: Nobody/Anonymous (nobody)
Summary: OS X: mouse cursor changes to I-beam in menus

Initial Comment:
When the mouse cursor is highlighting a menu entry that
is covering the text area, it will change from the
arrow shape into the I-beam. Additionally, the mouse
cursor will sometimes disappear instead of changing
into the I-beam, but I have not been able to reliably
reproduce this. Moving the cursor out of the text area
restores it to normal.

jEdit 4.3pre3 on PPC OS X 10.4.4, Java 1.5.0_05
This does not happen in jEdit 4.3pre2 on WinXP, Java
1.5.0_03

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

>Comment By: kerik (kerik-sf)
Date: 2009-11-29 22:06

Message:
I get this behaviour also, but if it's in Java, then we can't fix it !


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

Comment By: Jon (infinitejobu)
Date: 2006-04-10 06:56

Message:
Logged In: YES 
user_id=1484536

I do not believe that this is a bug in jEdit.  I found a bug
report on Sun's website along with a test program that shows
the same behavior that jEdit's menus have.  It is Bug ID:
6391547.  

The link to the bug is here:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6391547.  

When I run the test program on WinXP Pro SP2 with Java
jdk/jre 1.5.0_06 the I-beam is not present.  When I run it
on Mac OS X 10.4.5 with Java versions 1.4.2_09 and 1.5.0_05
the I-beam is the cursor for the menu.  It is possible that
the most recent version of Java for Windows has fixed the
bug while the Java for Mac OS X has not.

Here is the test program that is included with the bug
report which reproduces the specified behavior:  

import java.awt.Dimension;
import java.awt.FileDialog;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;

import java.awt.event.MouseEvent;
import java.awt.event.MouseMotionAdapter;

import javax.swing.JFrame;
import javax.swing.JMenu;
import javax.swing.JMenuBar;
import javax.swing.JMenuItem;
import javax.swing.JTextField;

public class TestAWTDialog extends JFrame {
    private JMenuBar jMenuBar1 = new JMenuBar();

    private JMenu jMenu1 = new JMenu();

    private JMenuItem jMenuItem1 = new JMenuItem();

    private JMenuItem jMenuItem2 = new JMenuItem();

    private JTextField jTextField1 = new JTextField();

    public TestAWTDialog() {
        try {
            jbInit();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    private void jbInit() throws Exception {
        this.setJMenuBar(jMenuBar1);
        this.setDefaultCloseOperation(0);
        this.setSize(new Dimension(400, 300));
        this.setTitle("File->Open->Move your mouse onto
TextField");
        jMenu1.setText("File");
        jMenuItem1.setText("Open");
        jMenuItem1.addActionListener(new ActionListener() {
                    public void actionPerformed(ActionEvent e) {
                        jMenuItem1_actionPerformed(e);
                    }
                });
        jMenuItem2.setText("Exit");
        jMenuItem2.addActionListener(new ActionListener() {
                    public void actionPerformed(ActionEvent e) {
                        jMenuItem2_actionPerformed(e);
                    }
                });
        jMenu1.add(jMenuItem1);
        jMenu1.add(jMenuItem2);
        jMenuBar1.add(jMenu1);
        this.getContentPane().add(jTextField1, null);
    }

    private void jMenuItem2_actionPerformed(ActionEvent e) {
        System.exit(0);
    }

    private void jMenuItem1_actionPerformed(ActionEvent e) {
        FileDialog fd = new FileDialog(this);
        fd.setMode(FileDialog.LOAD);
        fd.setTitle("File dialog");
        fd.setVisible(true);
    }
    
    public static void main(String[] argv){
        TestAWTDialog dlg = new TestAWTDialog();
        dlg.setVisible(true);
    }

}



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

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

Hi,

I took a quick look at many bugs, and found out the following:
1. Many (I'd say roughly about 25%) of the bugs are mode-specific.
These are not part of the jEdit core, but instead of the mode files.
Some of them are probably fixed by now, but in any case they should
not be counted as jEdit bugs wrt the release process, I think.
2. Many other bugs are OS-X-specific, and although they are part of
the core, they are somewhat special, as they do not occur with other
operating systems, and I think they should also not block releases.
3. Some of the bugs are probably already fixed (though they were fixed
indirectly, for other issues or as part of usual maintenance, so the
one who fixed was not aware of the open bug report and didn't close
it). It would, however, require a non-neglectible effort to check the
bugs one by one and see which are fixed.

Therefore, the number of open bugs is not necessarily an indication of
the stability of jEdit, like Alan said.
Can someone create separate categories for mode-specific bugs and for
OS-X-specific bugs? Alternatively, is there a way to filter them out
when going over bugs?.
It would be great if users or developers could go over the existing
bugs and check which are fixed, which are not, and preferably rate
their priority. But this is a big task, given the number of bugs. I
don't have time to do this myself.

Other than that, many users still use 4.2 only because they consider
any 'pre' release to be less stable. I don't think I ever used 4.2 (I
think I joined jEdit in some 4.3pre<x> release, about 3 years ago),
but those who did should be able to tell which is more stable.

Shlomy


On Sun, Nov 29, 2009 at 8:03 PM, Alan Ezust <ala...@gm...> wrote:
>
>> Again, being in a "pre" state for too long is in no means a reason for
>> creating a realse that is called stable but is not. In its current state
>> jEdit is NOT worth being called stable in my opinion. There are still too
>> many bugs open for it, and there are continuously coming new ones in. That
>> is not what I call stable. One of the
>
> This will always be the case. But I think it's stable enough to replace
> 4.2final. Are you saying that the current version is not as stable or
> relatively bug-free as 4.2final? Because if so, then you are just wrong.
>
>>
>> criteria I posted to the mailing list already when we had the discussion
>> about a final release already was - and I think is still valid - that I
>> would like to see the amount of open bug reports to be decreased to an at
>> most two digit number and no bug older than, let's say 2 month, or 6 month
>> maybe. Except if there are good reasons like for 493747 e. g. which maybe
>> has to wait for a complete rewrite. Additionally the final release should be
>> released as pre (rc) release already with NO new major bugs against it
>> found. I really don't think that jEdit is ready for a stable release when
>> there are still bugs like 2905487 in it.
>
> We will release a bugfix when/if that bug is fixed. But you should post a
> stack trace otherwise it will never get fixed. And for that, you need to
> start up jEdit with a java console (use "java" instead of "javaw") and then
> do Ctrl+\ from the shell window when it locks up like that. Anyway, I did
> see a problem exiting once, but that was related to my particular settings
> and combo of plugins (and since I use a lot of unreleased versions of
> plugins, that happens from time to time).
>
>
>
>>
>>
>>>
>>> I think the fix will include some API changes, and likely with major
>>> restructuring of codes. If this is true, and the fix comes after 4.3.0,
>>> it will hardly go into 4.3.1 which is a patch release.
>>
>> What I mean is that after  matthieu first commits it, we will release a
>> 4.3.1 (or .2, whatever).
>> And after we've had a chance to test it a while, it will be released again
>> as 4.4.
>>
>> But then this would be 4.4rc1 as you change "pre" to "rc" which I not
>> really agree with at all. An RC is something you really plan to release as
>> is if no new issues are found.
>
> I am not going to release any "pre" or "rc" releases. As far as I'm
> concerned, it will just be dotted decimals from now on. And which one is
> "stable" is whatever we say on the website, who cares if it has a .0 at the
> end of its version or not?
>
>>
>> That is not the semantic of the pre releases which are beta releases for
>> people having an up-to-date snapshot of the code. 4.3.1 will be a release
>> that is almost identical to 4.3 and only contains very important bug-fixes
>> that are needed immediately. This is called a bug-fix release.
>
> Right. We haven't released one of those in a while either.
>
>
>> As written above it also is not ready to be called 4.3 as this would imply
>> that it is a stable release what it is NOT. But I agree still and always
>> did, that the next stable release is 4.3 as the pre-releases were pre (read
>> "before") releases of 4.3 which implies that they are followed by a 4.3
>> release.
>
> Well, I disagree with you there. If you don't want to release 4.3 (without a
> "pre" or a "rc" then we may need another release manager willing to do it).
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> --
> -----------------------------------------------
> jEdit Developers' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>
>

Bugs item #1439605, was opened at 2006-02-27 14:01
Message generated for change (Settings changed) made by kerik-sf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1439605&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Elliotte Rusty Harold (elharo)
>Assigned to: kerik (kerik-sf)
Summary: Remove installer.VariableGridLayout

Initial Comment:
The class installer.VariableGridLayout says "This is
copied from jEdit's org.gjt.sp.jedit.gui package."
There seems little reasoon to do this. Why not just
import that class from that package instead? 

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

Comment By: kerik (kerik-sf)
Date: 2009-02-08 21:01

Message:
The patch has been applied in rev. 14584
Only need to delete the file !

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

Comment By: kerik (kerik-sf)
Date: 2009-02-02 19:11

Message:
leaving it, as I can't commit the patch.

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

Comment By: kerik (kerik-sf)
Date: 2008-11-22 18:36

Message:
This class is no more needed if following patch is applied (moved to
GridBagLayout).
fix  [jedit-Patches-2327736] patch for [979086] installation is allowed
with blank path
(https://sourceforge.net/tracker/?func=detail&atid=300588&aid=2327736&group_id=588)

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

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: editor core
Group: None
Status: Pending
>Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Paul N (vlion)
Assigned to: Nobody/Anonymous (nobody)
Summary: Menu location borked in OSX 10.4 + jEdit4.3

Initial Comment:
Hiya.

OSX 10.4 with jEdit 4.2final and 4.3(dev version on
main page)
The menu bar has jumped to the window, not the top bar
as it was.



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

>Comment By: kerik (kerik-sf)
Date: 2009-11-29 21:53

Message:
the new OSX plugin works !

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

Comment By: kerik (kerik-sf)
Date: 2009-11-29 21:53

Message:
the new OSX plugin works !

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

Comment By: kerik (kerik-sf)
Date: 2009-11-29 21:53

Message:
works for me, using the jEdit.app.
my setup : java 5 on OS X 10.4.11, jedit 4.3pre18

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

Comment By: Paul N (vlion)
Date: 2005-06-07 00:10

Message:
Logged In: YES 
user_id=793516

Update: OSX plugin won't load in 4.3;
Flipping the menu-bar flag in the plugin for 4.2 doesn't do
anything.


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

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: editor core
Group: None
Status: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Paul N (vlion)
Assigned to: Nobody/Anonymous (nobody)
Summary: Menu location borked in OSX 10.4 + jEdit4.3

Initial Comment:
Hiya.

OSX 10.4 with jEdit 4.2final and 4.3(dev version on
main page)
The menu bar has jumped to the window, not the top bar
as it was.



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

>Comment By: kerik (kerik-sf)
Date: 2009-11-29 21:53

Message:
the new OSX plugin works !

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

Comment By: kerik (kerik-sf)
Date: 2009-11-29 21:53

Message:
works for me, using the jEdit.app.
my setup : java 5 on OS X 10.4.11, jedit 4.3pre18

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

Comment By: Paul N (vlion)
Date: 2005-06-07 00:10

Message:
Logged In: YES 
user_id=793516

Update: OSX plugin won't load in 4.3;
Flipping the menu-bar flag in the plugin for 4.2 doesn't do
anything.


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

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