jedit-devel Mailing List for jEdit

Hi, 

<rant>
I don't have much spare time available to code at home. 
I want to write Sidekick. 
I have now spent four evenings trying to get jEdit to 
a point where I can code on it. 
I guess I have  missed the link 'newbies start here' or something. 

I have been using nothing but Maven for a long time, 
this project shows why. 

I now have some half cobbled together thing that 
is failing to build the XML plugin because it cannot find 

org/apache/commons/net/ftp/FTPClientConfig 
though I have put /dist/jedit2/jEdit/jars/commons-net-1.4.0.jar 
in the build.

I am sure you all know and love the setup you have, and I am 
sure you are all pretty proud of your in-depth knowledge of Ant, 
but to me there is just an enormous barrier to entry. 

On a maven project two lines cut'n'pasted off the website and 
you are coding. 

Maven is a build system, Ant is a programming language: 
lose Ant. 
</rant>

Sorry for the above, but could someone please point me to the 
zero config option?

Surely the build should just work from checkout?

cheers
tim

Kazutoshi Satoda wrote:
> I'll commit this in a few days if no one objects. Any comments,
> suggestions, or corrections are very welcome.

Done in r14123. Please apply further changes to this file.
-- 
k_satoda

Plugin Patches item #2343134, was opened at 2008-11-25 07:19
Message generated for change (Settings changed) made by sjakob
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997937&aid=2343134&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: Nick Clarke (memorius)
Assigned to: Steve Jakob (sjakob)
Summary: Templates: fix Enter key handling in dockable

Initial Comment:
Patch for Templates plugin - fix keyboard handling in dockable panel.

With this patch, the Enter key now applies the selected template if it's a leaf node, or expands the current node if it's a folder, instead of inserting a newline in the text area.

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

Comment By: Steve Jakob (sjakob)
Date: 2008-11-30 11:13

Message:
Since the ENTER key is the only key being handled by the dockable, I
removed the KeyListener-based implementation and used a key binding
instead. This results in the same functionality as provided by Nick's
patch.

Changed in revision 14121.

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

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

Plugin Patches item #2343134, was opened at 2008-11-25 07:19
Message generated for change (Comment added) made by sjakob
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997937&aid=2343134&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: Nick Clarke (memorius)
Assigned to: Steve Jakob (sjakob)
Summary: Templates: fix Enter key handling in dockable

Initial Comment:
Patch for Templates plugin - fix keyboard handling in dockable panel.

With this patch, the Enter key now applies the selected template if it's a leaf node, or expands the current node if it's a folder, instead of inserting a newline in the text area.

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

Comment By: Steve Jakob (sjakob)
Date: 2008-11-30 11:13

Message:
Since the ENTER key is the only key being handled by the dockable, I
removed the KeyListener-based implementation and used a key binding
instead. This results in the same functionality as provided by Nick's
patch.

Changed in revision 14121.

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

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

Bugs item #2364587, was opened at 2008-11-30 16:18
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2364587&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: minor bug
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Shlomy Reinstein (shlomy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Small dot appears in or near gutter when mouse is on gutter

Initial Comment:
When the mouse pointer hovers over the gutter area, a small dot appears near it, sometimes inside the gutter and sometimes in the text area just near the gutter.
This does not always happen, but it happens most of the time. Normally if you just move your mouse along the gutter area, you will notice it appearing and disappearing, but it is always somewhere near the mouse pointer. See attached screenshot (the screenshot does not include the mouse pointer, but at the time it was hovering a little bit to the right and below the dot).

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

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

Dale Anson wrote:
> Kazutoshi Satoda wrote:
>> Dale Anson wrote:
>>> Of course, if the intent of the relative position is to track the 
>>> position of the vertical scrollbar, then I've got this wrong. :) 
>>
>> I think so.
> Why do you think so?  I couldn't find any documentation about this in 
> either the code or the help file that would indicate either way.

I thought the code was right because it had been worked as scroll
position for years while always visible for everyone on the status bar.
If it were wrong, the person who implemented it must have noticed the
bug by just running jEdit.

However, I agree with the following part.
>  Actually, the scroll bar itself shows its own 
> relative position, so I think a status bar widget to show the same thing 
> is redundant.
(snip)
> Either way, the current implementation is inconsistent.  "Bot" follow 
> the caret position, "Top" follows the scroll bar.

Then, I propose reverting r14040 as an incomplete change first, and
submitting a patch with a specification to see if someone objects or not
about the change.

If it is going to show the relative caret position, I think "Top"/"Bot"
will be no longer good indication; just "0%"-"100%" would be enough.
More of that, I think showing the whole length would be more useful than
showing the percentage; ... "line,column (caret/length)" comes in my
mind.
-- 
k_satoda

Plugin Central Submission item #2353603, was opened at 2008-11-27 05:18
Message generated for change (Comment added) made by elberry
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=625093&aid=2353603&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
Priority: 5
Private: No
Submitted By: Matthieu Casanova (kpouer)
Assigned to: Townsfolk (elberry)
Summary: Ancestor 1.0.4

Initial Comment:
{{{ Ancestor 1.0.4
    Source: https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/Ancestor/tags/Ancestor-1.0.4
    Announcement: Fixed bug : If the file was renamed the bar was not updated (Patch #2343308 from Nick Clarke)
    Requires Java 1.5
    Requires jEdit 04.03.11.00
    
    Short Description: Ancestor plugin is a small toolbar with buttons to browser quickly all parents folders of the current buffer
    
    Long Description: Ancestor plugin is a small toolbar with buttons to browser quickly all parents folders of the current buffer
 }}}

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

>Comment By: Townsfolk (elberry)
Date: 2008-11-29 23:27

Message:
released to plugin central.

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

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

Plugin Central Submission item #2353603, was opened at 2008-11-27 05:18
Message generated for change (Settings changed) made by elberry
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=625093&aid=2353603&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: Matthieu Casanova (kpouer)
>Assigned to: Townsfolk (elberry)
Summary: Ancestor 1.0.4

Initial Comment:
{{{ Ancestor 1.0.4
    Source: https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/Ancestor/tags/Ancestor-1.0.4
    Announcement: Fixed bug : If the file was renamed the bar was not updated (Patch #2343308 from Nick Clarke)
    Requires Java 1.5
    Requires jEdit 04.03.11.00
    
    Short Description: Ancestor plugin is a small toolbar with buttons to browser quickly all parents folders of the current buffer
    
    Long Description: Ancestor plugin is a small toolbar with buttons to browser quickly all parents folders of the current buffer
 }}}

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

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

Plugin Central Submission item #2347923, was opened at 2008-11-25 18:31
Message generated for change (Comment added) made by elberry
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=625093&aid=2347923&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: Pending
Priority: 5
Private: No
Submitted By: Jesse Pavel (jpavel)
>Assigned to: Townsfolk (elberry)
Summary: CamelComplete updated for compatibility with jEdit 4.3pre16

Initial Comment:
{{{ CamelComplete 2.7.2
    Source: Source code is in SVN with the tag release-2_7_2
    Announcement: CamelComplete updated for compatibility with jEdit 4.3pre16
    Requires Java 1.5
    Requires jEdit 04.03.12.00
    
    Short Description: This plugin provides for code-completion in a CamelCase or regex_separated_identifier style.
    
    Long Description: 
<pre>

This plugin provides a "CamelComplete Word" command for jEdit. This can
expand abbreviations into their full words as shown by these examples,
which show identifiers and their abbreviations:

    SwingUtilities -> SU
    GtkMessageBox -> GMB
    IOException -> IOE

The plugin also comes with a Regular Expression parser, so that you can
break words apart using a regexp. This is useful for C and Lisp, among
others.

    Regexp: [_-]

    gtk_check_menu_item_set_inconsistent -> gcmisi
    gtk_menu_item_new -> gmin
    multi-define-syntax -> mds
    
In its default, Simple Mode, the plugin will work with CamelCase and
underscore-separated words. Almost anything is configurable using its
Advanced Mode.

</pre>
 }}}

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

>Comment By: Townsfolk (elberry)
Date: 2008-11-29 23:13

Message:
If the plugin has been updated to work with 4.3pre16, please update the
required jEdit version number to match. Then retag the release and I'll
release it.

Thanks.

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

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

Plugin Central Submission item #2343929, was opened at 2008-11-25 07:19
Message generated for change (Comment added) made by elberry
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=625093&aid=2343929&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
Priority: 5
Private: No
Submitted By: Matthew Gilbert (voxmea)
Assigned to: Townsfolk (elberry)
Summary: VoxSpell relase-1.0.4

Initial Comment:

{{{ VoxSpell 1.0.4
    Source: SVN tag release-1.0.4 (https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/VoxSpell/tags/release-1.0.4).
    Announcement: Changelog:
        
        New Features
        ------------
        
        - The top 3 replacement suggestions are added to the context menu.
        
        Bug Fixes
        ---------
        
        - Due to a timing issue, a null pointer exception could be generated when drawing the underline.
        
    Requires Java 1.5
    Requires jEdit 04.03.15.00
    
    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>
 }}}

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

>Comment By: Townsfolk (elberry)
Date: 2008-11-29 23:11

Message:
released to plugin central.

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

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

Plugin Central Submission item #2343929, was opened at 2008-11-25 07:19
Message generated for change (Settings changed) made by elberry
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=625093&aid=2343929&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: Townsfolk (elberry)
Summary: VoxSpell relase-1.0.4

Initial Comment:

{{{ VoxSpell 1.0.4
    Source: SVN tag release-1.0.4 (https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/VoxSpell/tags/release-1.0.4).
    Announcement: Changelog:
        
        New Features
        ------------
        
        - The top 3 replacement suggestions are added to the context menu.
        
        Bug Fixes
        ---------
        
        - Due to a timing issue, a null pointer exception could be generated when drawing the underline.
        
    Requires Java 1.5
    Requires jEdit 04.03.15.00
    
    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=2343929&group_id=588

Alan Ezust wrote:
> "bot" was showing when the bottom was visible, 
Actually, it wasn't.  "Bot" was showing well before the bottom was visible.
> and "top" was showing
> when the top was visible. Otherwise, it shows you what percent of the
> document the text area is displaying, relative to the whole document
>   
> It's not about the caret position.
>   
It seems to me it should be.  The rest of this widget is about the caret 
position, it shows offset of the caret from the start of the file, the 
line number containing the caret, and the offset of the caret from the 
start of the line in two different ways.   It seems wrong to have the 
5th number represent something unrelated to the caret position in the 
file.  The scroll bar itself shows relative offset of the visible 
portion of the file.

I'll fix it so it is showing "Bot" when the bottom line is actually 
visible, if that is the consensus of everyone.  That will at least be 
consistent with "Top".

Thanks,

Dale


> On Sat, Nov 29, 2008 at 7:35 AM, Dale Anson <da...@gr...> wrote:
>   
>> I almost never use vim, so I don't know what it does.  It seems to me
>> the display of the relative position was wrong, "Bot" was showing well
>> before the caret was at the bottom of the file.  As far as I can tell,
>> this part of the status bar is about caret information.  In this case,
>> the relative position of the caret should be the same as the relative
>> position of the scroll bar, although position calcuation for the thumb
>> of the scroll bar is likely much coarser than the line position
>> calculation for the caret.
>>
>> In fact, looking at this again, I don't think "Top" is right either.  It
>> doesn't make sense to me that the caret is on line 25 of a file and the
>> relative position still says "Top".  "Top" should be displayed when the
>> caret is on the first line, and "Bot" when the caret is on the last line.
>>
>> Of course, if the intent of the relative position is to track the
>> position of the vertical scrollbar, then I've got this wrong. :)
>>
>> Dale
>>
>>
>> Kazutoshi Satoda wrote:
>>     
>>> dal...@us... wrote:
>>>       
>>>> Log Message:
>>>> -----------
>>>> fix for 2220033
>>>>         
>>> (snip)
>>>       
>>>> +                else if (firstLine == 0)
>>>> +                {
>>>> +                    buf.append("Top");
>>>> +                }
>>>> +                else if (currLine == textArea.getLastPhysicalLine())
>>>> +                {
>>>> +                    buf.append("Bot");
>>>> +                }
>>>>         
>>> (snip)
>>>       
>>>> -            else if (firstLine == 0)
>>>> -            {
>>>> -                buf.append("Top");
>>>> -            }
>>>> -            else if (firstLine + visible >= lineCount)
>>>> -            {
>>>> -                buf.append("Bot");
>>>> -            }
>>>>         
>>> Why did you change the condition to show "Bot"?
>>>
>>> I think it was right, as imitation of what Vim shows. It had shown "Top"
>>> and "Bot" for the scroll position, not the caret position.
>>>       
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> --
>> -----------------------------------------------
>> jEdit Developers' List
>> jEd...@li...
>> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>>
>>     

Plugin Bugs item #2360096, was opened at 2008-11-29 23:49
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=2360096&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: Robert Schwenn (rschwenn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Console Commando: Beanshell error for TOGGLE_ENTRY GUI eleme

Initial Comment:
When I invoke a commando which has a TOGGLE_ENTRY element for the GUI, I get the following beanshell error:

Sourced file: inline evaluation of: ``commandoTOGGLE_ENTRY(view,pane,ns,label,var,options);'' : Unknown class: Primitive : at Line: 10 : in file: commandoTOGGLE_ENTRY : new Primitive ( true ) 


jEdit 4.3pre15
Console Plugin 4.3.8
SUN JRE 1.6.0_10
WinXP SP3


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

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

"bot" was showing when the bottom was visible, and "top" was showing
when the top was visible. Otherwise, it shows you what percent of the
document the text area is displaying, relative to the whole document.
It's not about the caret position.

On Sat, Nov 29, 2008 at 7:35 AM, Dale Anson <da...@gr...> wrote:
> I almost never use vim, so I don't know what it does.  It seems to me
> the display of the relative position was wrong, "Bot" was showing well
> before the caret was at the bottom of the file.  As far as I can tell,
> this part of the status bar is about caret information.  In this case,
> the relative position of the caret should be the same as the relative
> position of the scroll bar, although position calcuation for the thumb
> of the scroll bar is likely much coarser than the line position
> calculation for the caret.
>
> In fact, looking at this again, I don't think "Top" is right either.  It
> doesn't make sense to me that the caret is on line 25 of a file and the
> relative position still says "Top".  "Top" should be displayed when the
> caret is on the first line, and "Bot" when the caret is on the last line.
>
> Of course, if the intent of the relative position is to track the
> position of the vertical scrollbar, then I've got this wrong. :)
>
> Dale
>
>
> Kazutoshi Satoda wrote:
>> dal...@us... wrote:
>>> Log Message:
>>> -----------
>>> fix for 2220033
>> (snip)
>>> +                else if (firstLine == 0)
>>> +                {
>>> +                    buf.append("Top");
>>> +                }
>>> +                else if (currLine == textArea.getLastPhysicalLine())
>>> +                {
>>> +                    buf.append("Bot");
>>> +                }
>> (snip)
>>> -            else if (firstLine == 0)
>>> -            {
>>> -                buf.append("Top");
>>> -            }
>>> -            else if (firstLine + visible >= lineCount)
>>> -            {
>>> -                buf.append("Bot");
>>> -            }
>>
>> Why did you change the condition to show "Bot"?
>>
>> I think it was right, as imitation of what Vim shows. It had shown "Top"
>> and "Bot" for the scroll position, not the caret position.
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> --
> -----------------------------------------------
> jEdit Developers' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>

Plugin Feature Requests item #2359358, was opened at 2008-11-29 18:24
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=2359358&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: Robert Schwenn (rschwenn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Console: search Commando files in a second directory

Initial Comment:
I wished, that Console would search user-defined Commando files not only in jEdit's settings directory but also in a second directory. 

This could be a hard coded directory under jEdit home or maybe configurable. At least for maintaining a jEdit installation in a LAN this would be really a good thing.


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

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

Plugin Patches item #2343134, was opened at 2008-11-25 07:19
Message generated for change (Settings changed) made by sjakob
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997937&aid=2343134&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: Nick Clarke (memorius)
>Assigned to: Steve Jakob (sjakob)
Summary: Templates: fix Enter key handling in dockable

Initial Comment:
Patch for Templates plugin - fix keyboard handling in dockable panel.

With this patch, the Enter key now applies the selected template if it's a leaf node, or expands the current node if it's a folder, instead of inserting a newline in the text area.

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

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

Plugin Patches item #2343147, was opened at 2008-11-25 07:25
Message generated for change (Settings changed) made by sjakob
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997937&aid=2343147&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: Nick Clarke (memorius)
Assigned to: Steve Jakob (sjakob)
Summary: Templates: fix tree collapse every editbus msg in dockable

Initial Comment:
Patch for Templates plugin, against 4.1.1 release sources.

This fixes the handleMessage method in the dockable panel, which due to an apparent typo was reloading the template list for every editbus message; this makes the displayed template tree collapse, and presumably hurts performance.

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

Comment By: Steve Jakob (sjakob)
Date: 2008-11-29 12:14

Message:
Patch applied (revision 14113).

Thanks for the patch Nick.

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

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

Plugin Patches item #2343147, was opened at 2008-11-25 07:25
Message generated for change (Comment added) made by sjakob
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997937&aid=2343147&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: Nick Clarke (memorius)
Assigned to: Steve Jakob (sjakob)
Summary: Templates: fix tree collapse every editbus msg in dockable

Initial Comment:
Patch for Templates plugin, against 4.1.1 release sources.

This fixes the handleMessage method in the dockable panel, which due to an apparent typo was reloading the template list for every editbus message; this makes the displayed template tree collapse, and presumably hurts performance.

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

Comment By: Steve Jakob (sjakob)
Date: 2008-11-29 12:14

Message:
Patch applied (revision 14113).

Thanks for the patch Nick.

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

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

Kazutoshi Satoda wrote:
> Dale Anson wrote:
>> Of course, if the intent of the relative position is to track the 
>> position of the vertical scrollbar, then I've got this wrong. :) 
>
> I think so.
Why do you think so?  I couldn't find any documentation about this in 
either the code or the help file that would indicate either way.
>
> Before your change, "Top"/"Bot" could be shown while the caret is at
> the middle of file, if I drag the vertical scroll box.
This is true, and wrong behaviour, I think.
>
> Now, if I drag the vertical scroll box without moving the caret, I can't
> tell what the indicator is showing.
It is showing the relative position of the caret within the buffer.  The 
scroll bar thumb shows the relative position of the visible section of 
the buffer.
>
> If you want the indicator which shows the relative *caret* position,
> I think adding it as another status bar widget is the right way.
Shouldn't it be the other way around?  That is, a new widget to show the 
relative position of the scroll bar?  The current widget is about the 
position of the caret.  Actually, the scroll bar itself shows its own 
relative position, so I think a status bar widget to show the same thing 
is redundant.

Either way, the current implementation is inconsistent.  "Bot" follow 
the caret position, "Top" follows the scroll bar.

Matthieu Casanova wrote:
> The committers is not a very clear notion since any plugin developper can
> technically commit to jEdit's core itself if he don't want to respect the
> guidelines.

I see. It may be a problem. But I think the wording in the draft is fine
because it is in the jEdit core source tree, and has the title "Release
procedure of jEdit". Changing the title to "... of jEdit core" may be a
bit better.

> So to summarize, the same group of people will be allowed to commit to the
> trunk as before, then another developper of the same team will review the
> commit and merge it to the release branch.
> And all other developpers will continue to submit patches on the tracker
> isn't it ?

Right.

> Do you think it is possible to try your release process, and after a while
> maybe change it if it doesn't work as expected ?

Yes, of course. This proposal/draft also has come as such, finding the
old trunk-only procedure doesn't work as we want. Since it will be
documented in the repository, the change will be more easy and future
developers can learn from the history.
-- 
k_satoda

Dale Anson wrote:
> Of course, if the intent of the relative position is to track the 
> position of the vertical scrollbar, then I've got this wrong. :) 

I think so.

Before your change, "Top"/"Bot" could be shown while the caret is at
the middle of file, if I drag the vertical scroll box.

Now, if I drag the vertical scroll box without moving the caret, I can't
tell what the indicator is showing.

If you want the indicator which shows the relative *caret* position,
I think adding it as another status bar widget is the right way.

-- 
k_satoda

On Sat, Nov 29, 2008 at 4:36 PM, Kazutoshi Satoda <k_s...@f2...>wrote:

> Matthieu Casanova wrote:
>
>> At this time the core team can commit to the trunk, and anyone can send
>> patches on the trackers and those patches are reviewed by core
>> developpers.
>>
> (snip)
>
>> Who will be allowed to commit to the trunk ?
>>
>
> Don't worry. The new procedure won't change the rule on the trunk.
> However, I want you to write more good log messages, and more care about
> code readability, to reduce possible cost of review/merge process.
>
> I meant "committers" as such wrote in guidelines/README.jEdit.
> https://jedit.svn.sourceforge.net/svnroot/jedit/guidelines/README.jEdit
>
> I don't know what you mean by "core team", "core developpers" if they
> are different from the "committers".
>

by core team I mean the developpers that are allowed to commit on the core.
The committers is not a very clear notion since any plugin developper can
technically commit to jEdit's core itself if he don't want to respect the
guidelines.
So to summarize, the same group of people will be allowed to commit to the
trunk as before, then another developper of the same team will review the
commit and merge it to the release branch.
And all other developpers will continue to submit patches on the tracker
isn't it ?
In fact I'm not sure if it will work well or not because I'm not sure
everybody will take time to review commits. But without testing it we will
never know.
Do you think it is possible to try your release process, and after a while
maybe change it if it doesn't work as expected ?

Matthieu

Matthieu Casanova wrote:
> At this time the core team can commit to the trunk, and anyone can send
> patches on the trackers and those patches are reviewed by core developpers.
(snip)
> Who will be allowed to commit to the trunk ?

Don't worry. The new procedure won't change the rule on the trunk.
However, I want you to write more good log messages, and more care about
code readability, to reduce possible cost of review/merge process.

I meant "committers" as such wrote in guidelines/README.jEdit.
https://jedit.svn.sourceforge.net/svnroot/jedit/guidelines/README.jEdit

I don't know what you mean by "core team", "core developpers" if they
are different from the "committers".
-- 
k_satoda

I almost never use vim, so I don't know what it does.  It seems to me 
the display of the relative position was wrong, "Bot" was showing well 
before the caret was at the bottom of the file.  As far as I can tell, 
this part of the status bar is about caret information.  In this case, 
the relative position of the caret should be the same as the relative 
position of the scroll bar, although position calcuation for the thumb 
of the scroll bar is likely much coarser than the line position 
calculation for the caret. 

In fact, looking at this again, I don't think "Top" is right either.  It 
doesn't make sense to me that the caret is on line 25 of a file and the 
relative position still says "Top".  "Top" should be displayed when the 
caret is on the first line, and "Bot" when the caret is on the last line. 

Of course, if the intent of the relative position is to track the 
position of the vertical scrollbar, then I've got this wrong. :) 

Dale


Kazutoshi Satoda wrote:
> dal...@us... wrote:
>> Log Message:
>> -----------
>> fix for 2220033
> (snip)
>> +                else if (firstLine == 0)
>> +                {
>> +                    buf.append("Top");
>> +                }
>> +                else if (currLine == textArea.getLastPhysicalLine())
>> +                {
>> +                    buf.append("Bot");
>> +                }
> (snip)
>> -            else if (firstLine == 0)
>> -            {
>> -                buf.append("Top");
>> -            }
>> -            else if (firstLine + visible >= lineCount)
>> -            {
>> -                buf.append("Bot");
>> -            }
>
> Why did you change the condition to show "Bot"?
>
> I think it was right, as imitation of what Vim shows. It had shown "Top"
> and "Bot" for the scroll position, not the caret position.

I went ahead and removed both the commented out code and the associated 
comment.  As you mention, the comment is already in the svn log, which 
really is good enough.

Dale


Kazutoshi Satoda wrote:
> Hi Dale,
>
> dal...@us... wrote:
>> -            cursor = Cursor.getPredefinedCursor(Cursor.TEXT_CURSOR);
>> +
>> +            // removed next line for bug 1968223, "wrong mouse 
>> pointer in view 1".
>> +            // Calling visit(SetCursorVisitor) sets the cursor on 
>> the editPane,
>> +            // and setting the text cursor on the editPane is 
>> incorrect since this
>> +            // will cause the text cursor to be set on the 
>> bufferswitcher, and the
>> +            // gutter and scrollbars of the text area.  Using the 
>> default cursor
>> +            // is the right thing to do, this will set the proper 
>> cursor on the
>> +            // subcomponents.
>> +            ///cursor = Cursor.getPredefinedCursor(Cursor.TEXT_CURSOR);
>> +
>>              visit(new SetCursorVisitor(cursor));
>
> Why did you leave the wrong code as a comment?
>
> I think it should be just removed. The log message looks good enough.