jedit-devel Mailing List for jEdit

Plugin Bugs item #1498526, was opened at 2006-05-31 21:05
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=1498526&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
Submitted By: Manfred Braun (manfbraun)
Assigned to: Nobody/Anonymous (nobody)
Summary: clipper deletes empty lines

Initial Comment:
If one defines a new name/value pair, multiple 
entries for newlines "\n" are ignored inside the 
value. This leads to messy text in respect to 
parsing. I cannot find the source and I cannot 
program java.

Best regards,
Manfred

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

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

Its not possible. Try writing an extension to underline or highlight  
the text with a
custom background color.

On 31-May-06, at 9:43 AM, Philip Weaver wrote:

>
> I'm looking for the most direct way to alter the color of a range  
> of text in a buffer. I've looked at TextAreaPainter.PaintText and  
> I've tried to create my own TextArea extension to replace it, but  
> it doesn't seem to be possible because many elements are not  
> public. Is there any way to set any color for any range of text:  
> say like setAttributes() - beyond the token types which are already  
> defined?
>
> I was trying to alter the color of text directly because this  
> plugin is parsing the buffer contents itself and managing segments/ 
> elements (because they are very simple).
>
> Do I need to use the syntax package instead? Can you point me to a  
> plugin as an example which affects text coloration or some place in  
> the jEdit source which uses the token parser?
>
> Phil
>
>
>
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and  
> Risk!
> Fully trained technicians. The highest number of Red Hat  
> certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=107521&bid=248729&dat=121642
> -- 
> -----------------------------------------------
> jEdit Developers' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel

Plugin Central Submission item #1452598, was opened at 2006-03-17 18:59
Message generated for change (Comment added) made by kpouer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=625093&aid=1452598&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
Submitted By: Brad Mace (bemace)
Assigned to: Jeffrey Hoyt (jchoyt)
Summary: ColumnRuler 1.0.0

Initial Comment:
Column Ruler 1.0.0
Requirements:
	* JDK 1.5.0
	* jEdit 4.3pre4

Announcement:
	Updated for jEdit 4.3pre4, and works better with
multiple views/splits

Source:
	plugins/ColumnRuler
	tag: release-1_0_0

Short Description:
	Provides a ruler across the top of the text area which
marks off columns, and optional guides in the textarea.

Long Description:
	This plugin provides a ruler above the text area which
marks off columns. Hopefully it's obvious that this
only makes sense if you're using a fixed-width font
such as Courier.

	It also indicates the column where the caret is, the
wrap column (if using soft wrap), and when text is
selected, it highlights the columns of the current
selection and displays the selection size.

	The wrap mode for the current buffer can be set by
right-clicking the ruler, and the wrap column for a
buffer can be set by dragging the wrap marker.

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

>Comment By: Matthieu Casanova (kpouer)
Date: 2006-05-31 21:18

Message:
Logged In: YES 
user_id=285591

Hi, I have a problem with that plugin, I have a NPE when I
use it with 4.3pre4, don't you ?

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

Comment By: Jeffrey Hoyt (jchoyt)
Date: 2006-05-31 20:31

Message:
Logged In: YES 
user_id=396194

Released to Plugin Central.

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

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

Plugin Central Submission item #1452598, was opened at 2006-03-17 12:59
Message generated for change (Comment added) made by jchoyt
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=625093&aid=1452598&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
Submitted By: Brad Mace (bemace)
>Assigned to: Jeffrey Hoyt (jchoyt)
Summary: ColumnRuler 1.0.0

Initial Comment:
Column Ruler 1.0.0
Requirements:
	* JDK 1.5.0
	* jEdit 4.3pre4

Announcement:
	Updated for jEdit 4.3pre4, and works better with
multiple views/splits

Source:
	plugins/ColumnRuler
	tag: release-1_0_0

Short Description:
	Provides a ruler across the top of the text area which
marks off columns, and optional guides in the textarea.

Long Description:
	This plugin provides a ruler above the text area which
marks off columns. Hopefully it's obvious that this
only makes sense if you're using a fixed-width font
such as Courier.

	It also indicates the column where the caret is, the
wrap column (if using soft wrap), and when text is
selected, it highlights the columns of the current
selection and displays the selection size.

	The wrap mode for the current buffer can be set by
right-clicking the ruler, and the wrap column for a
buffer can be set by dragging the wrap marker.

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

Comment By: Jeffrey Hoyt (jchoyt)
Date: 2006-05-31 13:31

Message:
Logged In: YES 
user_id=396194

Released to Plugin Central.

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

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

Plugin Central Submission item #1498368, was opened at 2006-05-31 19:39
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=625093&aid=1498368&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
Submitted By: Martin Raspe (hertzhaft)
Assigned to: Nobody/Anonymous (nobody)
Summary: XQuerySidekick 0.1 initial release

Initial Comment:
XQuerySidekick 0.1

Requirements:
	* jdk 1.4.1
	* jEdit 4.2pre8
	* SideKick 0.5

Announcement:
	release 0.1
	initial Plugin Central release

Source:
	cvs.sourceforge.net: jedit/plugins/XQuerySidekick
	tag: release-0_1

Short Description:
	A simple sidekick parser for XQuery.

Long Description:
	This sidekick plugin parses XQuery source and analyzes
it, using regular expressions (an excentric programming
style will probably confuse the plugin).
	It uses the "enhanced" classes of the SideKick plugin.
I added a "xq" mode to the jEdit CVS.


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

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

Patches item #1483007, was opened at 2006-05-06 09:34
Message generated for change (Comment added) made by jchoyt
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300588&aid=1483007&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
Submitted By: Denis Koryavov (dkoryavov)
Assigned to: Nobody/Anonymous (nobody)
Summary: JDiffPlugin: Fix for Dual diff dialog.

Initial Comment:
This patch allows to update JDiffPlugin to the new
JEdit API.
After it is applied "Dual diff dialog" must work.

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

>Comment By: Jeffrey Hoyt (jchoyt)
Date: 2006-05-31 09:48

Message:
Logged In: YES 
user_id=396194

Probably my problem, but I can't get this patch to work. 
Can you upload the DualDiffDialog as you want it to be? 

Thanks,

Jeff

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

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

I will take a look. I did already look at the Highlighter plugin but  
it's not affecting text color painting.

I'm about to hone in on buffer.markTokens() and see where I get...

On May 31, 2006, at 9:30 AM, Jeffrey Hoyt wrote:

> Look at the JDiffPlugin - it does the background instead of the text
> color, but the premise is the same.  I was trying to do a CVS resolve
> conflict plugin and this got me started pretty well.    Plugin got
> beyond infant stage, but I did learn a lot.
>
> Jeff
>
> On 5/31/06, Philip Weaver <ph...@ph...> wrote:
>>
>> I'm looking for the most direct way to alter the color of a range of
>> text in a buffer. I've looked at TextAreaPainter.PaintText and I've
>> tried to create my own TextArea extension to replace it, but it  
>> doesn't
>> seem to be possible because many elements are not public. Is there any
>> way to set any color for any range of text: say like setAttributes() -
>> beyond the token types which are already defined?
>>
>> I was trying to alter the color of text directly because this plugin  
>> is
>> parsing the buffer contents itself and managing segments/elements
>> (because they are very simple).
>>
>> Do I need to use the syntax package instead? Can you point me to a
>> plugin as an example which affects text coloration or some place in  
>> the
>> jEdit source which uses the token parser?
>>
>> Phil
>>
>>
>>
>> -------------------------------------------------------
>> All the advantages of Linux Managed Hosting--Without the Cost and  
>> Risk!
>> Fully trained technicians. The highest number of Red Hat  
>> certifications in
>> the hosting industry. Fanatical Support. Click to learn more
>> http://sel.as-us.falkag.net/sel? 
>> cmd=lnk&kid=107521&bid=248729&dat=121642
>> --
>> -----------------------------------------------
>> jEdit Developers' List
>> jEd...@li...
>> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>>
>
>
> -- 
> They that give up essential liberty to obtain a little temporary
> safety deserve neither.
>
>
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and Risk!
> Fully trained technicians. The highest number of Red Hat  
> certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=107521&bid=248729&dat=121642
> -- 
> -----------------------------------------------
> jEdit Developers' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>

Look at the JDiffPlugin - it does the background instead of the text
color, but the premise is the same.  I was trying to do a CVS resolve
conflict plugin and this got me started pretty well.    Plugin got
beyond infant stage, but I did learn a lot.

Jeff

On 5/31/06, Philip Weaver <ph...@ph...> wrote:
>
> I'm looking for the most direct way to alter the color of a range of
> text in a buffer. I've looked at TextAreaPainter.PaintText and I've
> tried to create my own TextArea extension to replace it, but it doesn't
> seem to be possible because many elements are not public. Is there any
> way to set any color for any range of text: say like setAttributes() -
> beyond the token types which are already defined?
>
> I was trying to alter the color of text directly because this plugin is
> parsing the buffer contents itself and managing segments/elements
> (because they are very simple).
>
> Do I need to use the syntax package instead? Can you point me to a
> plugin as an example which affects text coloration or some place in the
> jEdit source which uses the token parser?
>
> Phil
>
>
>
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and Risk!
> Fully trained technicians. The highest number of Red Hat certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
> --
> -----------------------------------------------
> jEdit Developers' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>


-- 
They that give up essential liberty to obtain a little temporary
safety deserve neither.

I'm looking for the most direct way to alter the color of a range of 
text in a buffer. I've looked at TextAreaPainter.PaintText and I've 
tried to create my own TextArea extension to replace it, but it doesn't 
seem to be possible because many elements are not public. Is there any 
way to set any color for any range of text: say like setAttributes() - 
beyond the token types which are already defined?

I was trying to alter the color of text directly because this plugin is 
parsing the buffer contents itself and managing segments/elements 
(because they are very simple).

Do I need to use the syntax package instead? Can you point me to a 
plugin as an example which affects text coloration or some place in the 
jEdit source which uses the token parser?

Phil

Plugin Central Submission item #1498119, was opened at 2006-05-31 13:28
Message generated for change (Comment added) made by vampire0
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=625093&aid=1498119&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: Deleted
Priority: 5
Submitted By: Martin Raspe (hertzhaft)
Assigned to: Nobody/Anonymous (nobody)
Summary: JavaScriptSidekick 0.4

Initial Comment:
JavaScriptSidekick 0.4

Requirements:
	* jdk 1.4.1
	* jEdit 4.2pre8
	* SideKick 0.5
	* ErrorList 1.3.1

Source:
	cvs.sourceforge.net: jedit/plugins/JavaScriptSidekick
	tag: release-0_4

Short Description:
	A simple sidekick parser for Javascript.

Long Description:
	This sidekick plugin parses Javascript source and
analyzes it, 
	using regular expressions (an excentric programming
style will 
	probably confuse the plugin).
	It makes use of newly added classes to the SideKick
plugin 0.5.

Changes:
	changed parser regex patterns to make the plugin more
compatible with namespace/package emulation in
JavaScript (thanks David Padgett)


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

>Comment By: Björn Kautler (vampire0)
Date: 2006-05-31 14:50

Message:
Logged In: YES 
user_id=918212

Dupe of
https://sourceforge.net/tracker/?func=detail&atid=625093&aid=1498099&group_id=588

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

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

Plugin Central Submission item #1498119, was opened at 2006-05-31 13:28
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=625093&aid=1498119&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
Submitted By: Martin Raspe (hertzhaft)
Assigned to: Nobody/Anonymous (nobody)
Summary: JavaScriptSidekick 0.4

Initial Comment:
JavaScriptSidekick 0.4

Requirements:
	* jdk 1.4.1
	* jEdit 4.2pre8
	* SideKick 0.5
	* ErrorList 1.3.1

Source:
	cvs.sourceforge.net: jedit/plugins/JavaScriptSidekick
	tag: release-0_4

Short Description:
	A simple sidekick parser for Javascript.

Long Description:
	This sidekick plugin parses Javascript source and
analyzes it, 
	using regular expressions (an excentric programming
style will 
	probably confuse the plugin).
	It makes use of newly added classes to the SideKick
plugin 0.5.

Changes:
	changed parser regex patterns to make the plugin more
compatible with namespace/package emulation in
JavaScript (thanks David Padgett)


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

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

Plugin Central Submission item #1498099, was opened at 2006-05-31 12:50
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=625093&aid=1498099&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
Submitted By: Martin Raspe (hertzhaft)
Assigned to: Nobody/Anonymous (nobody)
Summary: JavaScriptSidekick 0.4

Initial Comment:
JavaScriptSidekick 0.4

Requirements:
	* jdk 1.4.1
	* jEdit 4.2pre8
	* SideKick 0.5
	* ErrorList 1.3.1

Source:
	cvs.sourceforge.net: jedit/plugins/JavaScriptSidekick
	tag: release-0_4

Short Description:
	A simple sidekick parser for Javascript.

Long Description:
	This sidekick plugin parses Javascript source and
analyzes it, 
	using regular expressions (an excentric programming
style will 
	probably confuse the plugin).
	It makes use of newly added classes to the SideKick
plugin 0.5.

Changes:
	changed parser regex patterns to make the plugin more
compatible with namespace/package emulation in
JavaScript (thanks David Padgett)


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

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

Patches item #1469996, was opened at 04/13/06 11:20
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300588&aid=1469996&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: Accepted
Priority: 5
Submitted By: Ernst de Vries (ejdevries)
Assigned to: Alan Ezust (ezust)
Summary: switching buffers from a macro confuses textarea

Initial Comment:
I tried this with a clean jedit 4.3pre3 install:
1) Open several files in jedit
2) Run the 'Buffer switcher' macro in the Files menu
and select another file.

Now the textArea is confused: the caret is no longer
visible when using the up/down keys, the line number is
no longer updated, and the textArea does not scroll
anymore.

Reloading the buffer will revert the textArea to its
normal state.

The bug can also be reproduced by running a macro
containing the function jEdit.openFile.

I've seen this problem in 4.3pre2/3 in Linux (AMD 64)
with JDK 1.5, and win2k with JDK 1.5.


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

>Comment By: SourceForge Robot (sf-robot)
Date: 05/30/06 19:20

Message:
Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

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

Comment By: Alan Ezust (ezust)
Date: 05/16/06 11:18

Message:
Logged In: YES 
user_id=935841

Macros need to be rewritten to end/begin a new compoundEdit
whenever they switch buffers. Buffer_Switcher and
TogglerHeaderSource have both been patched. The
documentation has been updated accordingly. Committed to CVS. 

Other macros that change buffers still need to be patched.

Feel free to try this version:
http://lazarus.oddiofile.com:81/workspace/jEditCVS/jedit.jar



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

Comment By: Alan Ezust (ezust)
Date: 05/15/06 12:35

Message:
Logged In: YES 
user_id=935841

ignore previous comment. I can reproduce under windows too.

Also, it's just just openFile, but also
editPane.nextBuffer() and editPane.prevBuffer() - in
general, anything that causes the editPane to change its
buffer from a macro.


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

Comment By: Alan Ezust (ezust)
Date: 05/15/06 10:22

Message:
Logged In: YES 
user_id=935841

Some more info: I can reproduce this on linux but not under
windows.



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

Comment By: Alan Ezust (ezust)
Date: 05/15/06 09:04

Message:
Logged In: YES 
user_id=935841

I can call jedit.openFile() from the beanshell console and
it does NOT reproduce this problem.

So there is something very different about code executed by
macros versus code executed from the beanshell console.

Furthermore, I can get a "good textarea" back by splitting
my view, going to the newly created editpane, and then
"unsplit all".



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

Comment By: Alan Ezust (ezust)
Date: 05/15/06 08:49

Message:
Logged In: YES 
user_id=935841

correction, I can reproduce it, and furthermore, it seems
that reloading the buffer does NOT make the problem go away. 

The only way I can make the problem go away is by creating
antoher view and killing this one.

I can call jEdit.openFile() from the beanshell console and
it does not cause this problem. It is definitely specific to
the way openFile gets called from a macro.



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

Comment By: Alan Ezust (ezust)
Date: 05/15/06 06:33

Message:
Logged In: YES 
user_id=935841

I've also noticed a problem like this, but it is not 100%
preproducible. I notice it only happens when I am switching
between certain files, and not others. 

I'm not sure what it is that these files have in common, but
it seems to happen more on large files than small ones. In
particular, after a recent buffer switch using
ToggleHeaderSource, I noticed that the textarea's
PhysLastLine seems to be the same as the visible last line.



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

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

Plugin Central Submission item #1497331, was opened at 2006-05-30 08:21
Message generated for change (Comment added) made by kpouer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=625093&aid=1497331&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
Submitted By: Matthieu Casanova (kpouer)
Assigned to: Matthieu Casanova (kpouer)
Summary: PHPParser-1.2.3

Initial Comment:
PHPParser-1.2.3
PHPParserplugin
version 1.2.3
CVS Tag : v1_2_3
Requires:
jEdit 4.2
ErrorListPlugin 1.4
SideKickPlugin 0.4

Bugs fixed

better modifier parsing 
a bug fixed in code analysis of try statements 
some bugs fixed in dockable panel 
1458668 fixed (< while ($a) : ?>blabla<?endwhile;?> 
1432935 fixed 
1489533 fixed (const keyword) 
Syntax like
TR_TreeAction::getInstance('containers')->isRoot(5); fixed 
several fields declared in the same likes is now
allowed in php 5   


Description
PHPParserPlugin is a php parser that will highlight
your syntax errors and help you navigate in your source

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

>Comment By: Matthieu Casanova (kpouer)
Date: 2006-05-30 20:42

Message:
Logged In: YES 
user_id=285591

Released to Plugin Central.

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

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

Well, for Java, it seems to sort of work like the go to matching bracket, 
but not quite.  For xml files, it seems to do the same thing as for html 
files, that is, move to the matching tag.


On Tue, 30 May 2006, Alan Ezust wrote:

> Cool! I hadn't noticed that. It's almost what I want. I guess really,
> sidekick needs one more action to "toggle" ebtween the goto next and
> goto previous, and then it would be like a go to matching asset
> action.
>
> I wonder what it does in other languages... It would be nice if it did
> useful things in each mode...
>
>
> On 5/30/06, Dale Anson <da...@gr...> wrote:
>>  Crud.  I just checked in the 'go to matching tag' functionality to
>>  HtmlSideKick (my version, not the one in XML plugin) and then realized
>>  that this functionality is alreay provided by SideKick itself.  The 'go to
>>  previous asset' and 'go to next asset' together provide the same
>>  functionality as 'go to matching tag', at least for html files.
>>
>>  Dale
>> 
>>
>>  On Tue, 30 May 2006, Dale Anson wrote:
>> 
>> >  I have a feeling that you've got 2 different html sidekicks going -- the 
>> >  one
>> >  that is included in the XML plugin that Slava wrote and the HtmlSideKick 
>> >  that
>> >  I wrote.  The 'go to matching tag' feature does NOT work in the one I 
>> >  wrote,
>> >  but probably does in the one that Slava wrote.  I expect I'll have the 
>> >  same
>> >  feature in my version today.
>> > 
>> >  And the bit about the timers in XML plugin for the code completion -- I 
>> >  bet
>> >  this is a hold-over.  I think Slava wrote the XML plugin first, then
>> >  abstracted the SideKick parts later.  SideKick should be the one 
>> >  providing
>> >  the timers, not the XML plugin.
>> > 
>> >  Dale
>> > 
>> > 
>> >  On Mon, 29 May 2006, Alan Ezust wrote:
>> > 
>> > >   Goto Matching Tag seems to work already, since it is an action I have
>> > >   bound to a shortcut which seems to work from both HTML and XML modes.
>> > > 
>> > >   The complete closing tag would of course be an option, which it is
>> > >   already from the XML plugin.
>> > > 
>> > > 
>> > >   On 5/29/06, Dale Anson <da...@gr...> wrote:
>> > > >    Forwarding to jedit dev list for followup...
>> > > > 
>> > > >    Alan, about the "complete closing tag" for html -- do you think 
>> > > >    that
>> > > >    should always be the case?  It clearly makes sense for xhtml, but 
>> > > >    I'm
>> > > >    not
>> > > >    sure about html 4.x.
>> > > > 
>> > > >    The "go to matching tag" makes sense, that is code that is in XML 
>> > > >    now,
>> > > >    do
>> > > >    you think it should be generalized to SideKick itself?
>> > > > 
>> > > >    Dale
>> > > 
>> > > 
>> > 
>> > 
>> >  -------------------------------------------------------
>> >  All the advantages of Linux Managed Hosting--Without the Cost and Risk!
>> >  Fully trained technicians. The highest number of Red Hat certifications 
>> >  in
>> >  the hosting industry. Fanatical Support. Click to learn more
>> >  http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
>> >  --
>> >  -----------------------------------------------
>> >  jEdit Developers' List
>> >  jEd...@li...
>> >  https://lists.sourceforge.net/lists/listinfo/jedit-devel
>> > 
>> > 
>> 
>>
>>  -------------------------------------------------------
>>  All the advantages of Linux Managed Hosting--Without the Cost and Risk!
>>  Fully trained technicians. The highest number of Red Hat certifications in
>>  the hosting industry. Fanatical Support. Click to learn more
>>  http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
>>  --
>>  -----------------------------------------------
>>  jEdit Developers' List
>>  jEd...@li...
>>  https://lists.sourceforge.net/lists/listinfo/jedit-devel
>> 
>
>
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and Risk!
> Fully trained technicians. The highest number of Red Hat certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
> -- 
> -----------------------------------------------
> jEdit Developers' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>
>

Cool, thanks. I just committed changes to the users-guide.xml so the
next release of sidekick will explain how it is done better (and also
have working hyperlinks to the API docs).

On 5/30/06, Dale Anson <da...@gr...> wrote:
> Here are some notes about implementing code completion with SideKick:
>

Cool! I hadn't noticed that. It's almost what I want. I guess really,
sidekick needs one more action to "toggle" ebtween the goto next and
goto previous, and then it would be like a go to matching asset
action.

I wonder what it does in other languages... It would be nice if it did
useful things in each mode...


On 5/30/06, Dale Anson <da...@gr...> wrote:
> Crud.  I just checked in the 'go to matching tag' functionality to
> HtmlSideKick (my version, not the one in XML plugin) and then realized
> that this functionality is alreay provided by SideKick itself.  The 'go to
> previous asset' and 'go to next asset' together provide the same
> functionality as 'go to matching tag', at least for html files.
>
> Dale
>
>
> On Tue, 30 May 2006, Dale Anson wrote:
>
> > I have a feeling that you've got 2 different html sidekicks going -- the one
> > that is included in the XML plugin that Slava wrote and the HtmlSideKick that
> > I wrote.  The 'go to matching tag' feature does NOT work in the one I wrote,
> > but probably does in the one that Slava wrote.  I expect I'll have the same
> > feature in my version today.
> >
> > And the bit about the timers in XML plugin for the code completion -- I bet
> > this is a hold-over.  I think Slava wrote the XML plugin first, then
> > abstracted the SideKick parts later.  SideKick should be the one providing
> > the timers, not the XML plugin.
> >
> > Dale
> >
> >
> > On Mon, 29 May 2006, Alan Ezust wrote:
> >
> >>  Goto Matching Tag seems to work already, since it is an action I have
> >>  bound to a shortcut which seems to work from both HTML and XML modes.
> >>
> >>  The complete closing tag would of course be an option, which it is
> >>  already from the XML plugin.
> >>
> >>
> >>  On 5/29/06, Dale Anson <da...@gr...> wrote:
> >> >   Forwarding to jedit dev list for followup...
> >> >
> >> >   Alan, about the "complete closing tag" for html -- do you think that
> >> >   should always be the case?  It clearly makes sense for xhtml, but I'm
> >> >   not
> >> >   sure about html 4.x.
> >> >
> >> >   The "go to matching tag" makes sense, that is code that is in XML now,
> >> >   do
> >> >   you think it should be generalized to SideKick itself?
> >> >
> >> >   Dale
> >>
> >>
> >
> >
> > -------------------------------------------------------
> > All the advantages of Linux Managed Hosting--Without the Cost and Risk!
> > Fully trained technicians. The highest number of Red Hat certifications in
> > the hosting industry. Fanatical Support. Click to learn more
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
> > --
> > -----------------------------------------------
> > jEdit Developers' List
> > jEd...@li...
> > https://lists.sourceforge.net/lists/listinfo/jedit-devel
> >
> >
>
>
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and Risk!
> Fully trained technicians. The highest number of Red Hat certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
> --
> -----------------------------------------------
> jEdit Developers' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>

Crud.  I just checked in the 'go to matching tag' functionality to 
HtmlSideKick (my version, not the one in XML plugin) and then realized 
that this functionality is alreay provided by SideKick itself.  The 'go to 
previous asset' and 'go to next asset' together provide the same 
functionality as 'go to matching tag', at least for html files.

Dale


On Tue, 30 May 2006, Dale Anson wrote:

> I have a feeling that you've got 2 different html sidekicks going -- the one 
> that is included in the XML plugin that Slava wrote and the HtmlSideKick that 
> I wrote.  The 'go to matching tag' feature does NOT work in the one I wrote, 
> but probably does in the one that Slava wrote.  I expect I'll have the same 
> feature in my version today.
>
> And the bit about the timers in XML plugin for the code completion -- I bet 
> this is a hold-over.  I think Slava wrote the XML plugin first, then 
> abstracted the SideKick parts later.  SideKick should be the one providing 
> the timers, not the XML plugin.
>
> Dale
>
>
> On Mon, 29 May 2006, Alan Ezust wrote:
>
>>  Goto Matching Tag seems to work already, since it is an action I have
>>  bound to a shortcut which seems to work from both HTML and XML modes.
>>
>>  The complete closing tag would of course be an option, which it is
>>  already from the XML plugin.
>> 
>>
>>  On 5/29/06, Dale Anson <da...@gr...> wrote:
>> >   Forwarding to jedit dev list for followup...
>> > 
>> >   Alan, about the "complete closing tag" for html -- do you think that
>> >   should always be the case?  It clearly makes sense for xhtml, but I'm 
>> >   not
>> >   sure about html 4.x.
>> > 
>> >   The "go to matching tag" makes sense, that is code that is in XML now, 
>> >   do
>> >   you think it should be generalized to SideKick itself?
>> > 
>> >   Dale
>> 
>> 
>
>
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and Risk!
> Fully trained technicians. The highest number of Red Hat certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
> -- 
> -----------------------------------------------
> jEdit Developers' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>
>

Here are some notes about implementing code completion with SideKick:

First, you must have a parser that extends SideKickParser.  Override the 
method 'supportsCompletion()' to return true.  This signals SideKick that 
completions are possible for the mode(s) your sidekick supports.

Also in your SideKickParser, override the 'complete(EditPane, int)' method 
to return a completion.  SideKick handles the calling of this method and 
will pass in a reference to the current EditPane and the current caret 
position.  This method needs to return a SideKickCompletion or null if no 
completion is possible.

The constructor for SideKickCompletion accepts a list (or array) of 
possible values, these are the values that are displayed in the dropdown. 
This is an abstract class, so you'll need to derive a specific 
implementation.  You may want to override the 'insert(int)' method to 
support language specifics, like "dot" completion.

How you actually create the completion depends on the specific language 
and support classes, and the information provided by the parser for the 
current file.  I needed to modify the parser for JavaSideKick to parse 
inside of methods for local variable declarations to be able to provide 
completion for those, I wasn't gathering them intially since these weren't 
necessary for creating the tree stucture.

Hope this helps!

Dale



On Mon, 29 May 2006, Alan Ezust wrote:

> I'd like to write some docs for how to write sidekick completions.  I
> don't fully understand how it works though. I have a couple of
> questions, and any additional info would be appreciated.
>
>
> It seems that XML completions are triggered by a timer. Where in the
> code is that timer event set up?
>
> How do you specify that your plugin offers completions for a
> particular mode? Could someone please summarize this for me?
>
>
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and Risk!
> Fully trained technicians. The highest number of Red Hat certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
> -- 
> -----------------------------------------------
> jEdit Developers' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>
>

I have a feeling that you've got 2 different html sidekicks going -- the 
one that is included in the XML plugin that Slava wrote and the 
HtmlSideKick that I wrote.  The 'go to matching tag' feature does NOT work 
in the one I wrote, but probably does in the one that Slava wrote.  I 
expect I'll have the same feature in my version today.

And the bit about the timers in XML plugin for the code completion -- I 
bet this is a hold-over.  I think Slava wrote the XML plugin first, then 
abstracted the SideKick parts later.  SideKick should be the one providing 
the timers, not the XML plugin.

Dale


On Mon, 29 May 2006, Alan Ezust wrote:

> Goto Matching Tag seems to work already, since it is an action I have
> bound to a shortcut which seems to work from both HTML and XML modes.
>
> The complete closing tag would of course be an option, which it is
> already from the XML plugin.
>
>
> On 5/29/06, Dale Anson <da...@gr...> wrote:
>>  Forwarding to jedit dev list for followup...
>>
>>  Alan, about the "complete closing tag" for html -- do you think that
>>  should always be the case?  It clearly makes sense for xhtml, but I'm not
>>  sure about html 4.x.
>>
>>  The "go to matching tag" makes sense, that is code that is in XML now, do
>>  you think it should be generalized to SideKick itself?
>>
>>  Dale
>
>

Bugs item #1495846, was opened at 2006-05-27 13:03
Message generated for change (Comment added) made by icspl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1495846&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: severe bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Keith Harris (icspl)
Assigned to: Nobody/Anonymous (nobody)
Summary: repaint doesnt work properly

Initial Comment:
java -version
java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build
1.5.0_06-b05)
Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed
mode, sharing)

Both jedit 4.3Pre3 and jedit 4.4Pre4 exhibit the same
preoblem.  deleting the .jEdit file doesnt seem to help
as I try each version, 

Then I delete .jedit and try again going through som
standard setup and it works perfectly

Keith Harris
ic...@tp...

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

>Comment By: Keith Harris (icspl)
Date: 2006-05-30 19:21

Message:
Logged In: YES 
user_id=592936

On my acer laptop running Windows XP if I open the catalog
file I get instant repaint problem.  Wiping the mouse
accross the toolbar area causes the toolbar to repaint.  I
can then close catalog (of modes) and jedit returns to normal.

Opening catalog on office desktop doesnt cause the problem
but it doesnt see the catalog file as an xml file, but as
text.( There is a problem in parsing the doxygen.xml file.)
as well as the xml file type not using &lt or &gt

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

Comment By: Keith Harris (icspl)
Date: 2006-05-27 19:08

Message:
Logged In: YES 
user_id=592936

Windows XP professional

and the problem would seem to have been the same as 
[ 1373551 ] Editor not repainting in 4.3pre3

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

Comment By: Matthieu Casanova (kpouer)
Date: 2006-05-27 18:47

Message:
Logged In: YES 
user_id=285591

Hi, what is the problem exactly ? What OS ?

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

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

Goto Matching Tag seems to work already, since it is an action I have
bound to a shortcut which seems to work from both HTML and XML modes.

The complete closing tag would of course be an option, which it is
already from the XML plugin.


On 5/29/06, Dale Anson <da...@gr...> wrote:
> Forwarding to jedit dev list for followup...
>
> Alan, about the "complete closing tag" for html -- do you think that
> should always be the case?  It clearly makes sense for xhtml, but I'm not
> sure about html 4.x.
>
> The "go to matching tag" makes sense, that is code that is in XML now, do
> you think it should be generalized to SideKick itself?
>
> Dale

Plugin Central Submission item #1497331, was opened at 2006-05-30 08:21
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=625093&aid=1497331&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
Submitted By: Matthieu Casanova (kpouer)
Assigned to: Matthieu Casanova (kpouer)
Summary: PHPParser-1.2.3

Initial Comment:
PHPParser-1.2.3
PHPParserplugin
version 1.2.3
CVS Tag : v1_2_3
Requires:
jEdit 4.2
ErrorListPlugin 1.4
SideKickPlugin 0.4

Bugs fixed

better modifier parsing 
a bug fixed in code analysis of try statements 
some bugs fixed in dockable panel 
1458668 fixed (< while ($a) : ?>blabla<?endwhile;?> 
1432935 fixed 
1489533 fixed (const keyword) 
Syntax like
TR_TreeAction::getInstance('containers')->isRoot(5); fixed 
several fields declared in the same likes is now
allowed in php 5   


Description
PHPParserPlugin is a php parser that will highlight
your syntax errors and help you navigate in your source

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

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

I'd like to write some docs for how to write sidekick completions.  I
don't fully understand how it works though. I have a couple of
questions, and any additional info would be appreciated.


It seems that XML completions are triggered by a timer. Where in the
code is that timer event set up?

How do you specify that your plugin offers completions for a
particular mode? Could someone please summarize this for me?

On 5/29/06, Alan Ezust <ala...@gm...> wrote:
> It seems that XML completions are triggered by a timer. Where in the
> code is that timer event set up?

I think i can clarify this  question a bit more.
It seems that the complete() method is called by timer event, which is
set up by SideKickActions. My question is, why is it that this timer
event is set up from the XML plugin, and what is it that I need to add
to the HTMLSideKick so that it also calls the timer event that calls
complete after a certain delay?