jedit-devel Mailing List for jEdit

Bugs item #2007149, was opened at 2008-06-30 14:42
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=2007149&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: Alan Ezust (ezust)
Assigned to: Matthieu Casanova (kpouer)
Summary: StatusBar BufferSet button: missing bufferlist refresh

Initial Comment:
The built-in buffer list (which you probably don't use since you are using buffertabs) needs to be refreshed after changing the buffsetset scope of the current view via the status bar button. Otherwise, I get a beanshell exception whenever I go to next or previous buffer. I need to manually reset textarea first. 

java.lang.NullPointerException
	at org.gjt.sp.jedit.EditPane.setBuffer(EditPane.java:140)
	at org.gjt.sp.jedit.EditPane.setBuffer(EditPane.java:127)
	at org.gjt.sp.jedit.EditPane.nextBuffer(EditPane.java:234)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)


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

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

Plugin Patches item #2006663, was opened at 2008-06-30 15:24
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997937&aid=2006663&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: halyavin (halyavin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix for [1992191]

Initial Comment:
I replace usage of com.microstar.xml API to org.xml.sax API in session plugin. I haven't dealt with XML much, so I am not sure why .dtd is needed for such files and is there a more correct way to handle it.

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

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

Plugin Bugs item #2002312, was opened at 2008-06-25 12:49
Message generated for change (Comment added) made by halyavin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=2002312&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: goebbe (goebbe)
Assigned to: Nobody/Anonymous (nobody)
Summary: BufferList - drawing conflict with Session-plugin

Initial Comment:
I tested a recent version of BufferList that I downloaded from the following link:
http://www.humyo.com/F/1256425-132191091 

Testing this version I discovered that the information about the number of open and unsaved buffers is now drawn at exactly the same place as the session-plugin.

The attached screenshot illustrates the described "problem" well. 

Perhaps one could dedicate some extra space within the BufferList window for this type of information? Or put this information to the bottom? 

Anyway - keep up the good work on BufferList! Your work is highly appreciated. 
Regards

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

>Comment By: halyavin (halyavin)
Date: 2008-06-30 14:23

Message:
Logged In: YES 
user_id=1600924
Originator: NO

Session plugin use BufferList window directly without any services (mainly
because they were written by the same author). I refactored component
layout of BufferList window and Session plugin can't find the correct place
for its components anymore. Now there is a several ways to solve the
problem and I can't decide which to use:
1. Introduce new service and make Session plugin use it. In this case
Session plugin must use the latest version of BufferList plugin and I must
release them simultaneously.
2. Introduce new service and make Session plugin use it, if service is
available. Then Session plugin must be released earlier than BufferList and
can use previous versions of BufferList plugin.
3. Revert the component layout of BufferList window. Then, I don't need to
change Session plugin, but direct usage is bad.

In the first 2 cases I have to release Session plugin without significant
changes :( and I am not a maintainer of it.

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

Comment By: goebbe (goebbe)
Date: 2008-06-30 12:45

Message:
Logged In: YES 
user_id=1050273
Originator: YES

This bug is still present with the latest .jar of BufferList that I
downloaded. 
Since the problem appears only with newer BufferList-plugins I suspect
that BufferList is the culprit, here.

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

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

Plugin Bugs item #2002312, was opened at 2008-06-25 08:49
Message generated for change (Comment added) made by goebbe
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=2002312&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: goebbe (goebbe)
Assigned to: Nobody/Anonymous (nobody)
Summary: BufferList - drawing conflict with Session-plugin

Initial Comment:
I tested a recent version of BufferList that I downloaded from the following link:
http://www.humyo.com/F/1256425-132191091 

Testing this version I discovered that the information about the number of open and unsaved buffers is now drawn at exactly the same place as the session-plugin.

The attached screenshot illustrates the described "problem" well. 

Perhaps one could dedicate some extra space within the BufferList window for this type of information? Or put this information to the bottom? 

Anyway - keep up the good work on BufferList! Your work is highly appreciated. 
Regards

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

>Comment By: goebbe (goebbe)
Date: 2008-06-30 08:45

Message:
Logged In: YES 
user_id=1050273
Originator: YES

This bug is still present with the latest .jar of BufferList that I
downloaded. 
Since the problem appears only with newer BufferList-plugins I suspect
that BufferList is the culprit, here.

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

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

Hi Shlomy,

Sunday, June 29, 2008, 11:05:34 AM, you wrote:


> Hi,
> I think some sort of timeout should be added to the regeneration of
> the dynamic context menu using the service, to ensure context menu
> regeneration won't take too much time due to slow plugins. I am
> writing this from experience - in Eclipse, there are plugins that
> contribute to the context menu with a mechanism similar to this
> service, that cause the context menu to show up after a very long
> delay, sometimes several seconds, and this can be very irritating,
> causing the user to stop using the plugin causing the slowness.
> So, it can be configurable or hard-coded, but better ensure that
> context menu generation doesn't take too long due to this service.
> Shlomy

I think that such plugins should have an option for quick regeneration
(like always add SVN items to popup menu for SVNPlugin) instead or
include own time restriction. Because if the plugin will not add items
due to time limit, it will be useless anyway. And you have to
create/synchronize with threads to check time limit what will make
context menu slow in all cases.
PS In eclipse, delays in popup menus are usually connected with lazy
initialization. This is affordable for me.
 Andrey Khalyavin                           mailto:hal...@la...

Plugin Bugs item #2006502, was opened at 2008-06-30 10:15
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=2006502&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: 2
Private: No
Submitted By: Matthieu Casanova (kpouer)
Assigned to: Marcelo Vanzin (vanza)
Summary: ProjectViewer bug when nosettings

Initial Comment:
Hi, when I start with no settings directory, ProjectViewer do not check if the settings directory is null so it creates a "null" folder to store it's files.

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

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

Plugin Bugs item #2006501, was opened at 2008-06-30 10:14
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=2006501&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: 2
Private: No
Submitted By: Matthieu Casanova (kpouer)
Assigned to: Shlomy Reinstein (shlomy)
Summary: CtagsInterface bug when nosettings

Initial Comment:
Hi, when I start with no settings directory, CtagsInterface do not check if the settings directory is null so it creates a "null" folder to store it's files.

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

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

Plugin Bugs item #2006460, was opened at 2008-06-30 09:06
Message generated for change (Settings changed) made by kpouer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=2006460&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: Duplicate
Priority: 5
Private: No
Submitted By: Voituk Vadim (voituk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Session plugin exception

Initial Comment:
Session 1.4.2 plugin exception depends of com.microstar.xml package.

10:04:24 PluginJAR: Error while starting plugin sessions.SessionsPlugin
10:04:24 PluginJAR: java.lang.NoClassDefFoundError: com/microstar/xml/XmlHandler
10:04:24 PluginJAR:  at sessions.SessionManager.<init>(SessionManager.java:99)
10:04:24 PluginJAR:  at sessions.SessionManager.getInstance(SessionManager.java:89)
10:04:24 PluginJAR:  at sessions.SessionsPlugin.start(SessionsPlugin.java:67)
10:04:24 PluginJAR:  at org.gjt.sp.jedit.PluginJAR.startPlugin(PluginJAR.java:1360)
10:04:24 PluginJAR:  at org.gjt.sp.jedit.PluginJAR.activatePlugin(PluginJAR.java:737)
10:04:24 PluginJAR:  at org.gjt.sp.jedit.PluginJAR.activatePluginIfNecessary(PluginJAR.java:807)
10:04:24 PluginJAR:  at org.gjt.sp.jedit.PluginJAR.load(PluginJAR.java:193)
10:04:24 PluginJAR:  at org.gjt.sp.jedit.pluginmgr.ManagePanel$PluginTableModel.setValueAt(ManagePanel.java:532)


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

>Comment By: Matthieu Casanova (kpouer)
Date: 2008-06-30 10:11

Message:
Logged In: YES 
user_id=285591
Originator: NO

Hi, it is dupe of 1992191

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

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

Plugin Bugs item #2006460, was opened at 2008-06-30 10:06
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=2006460&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: Voituk Vadim (voituk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Session plugin exception

Initial Comment:
Session 1.4.2 plugin exception depends of com.microstar.xml package.

10:04:24 PluginJAR: Error while starting plugin sessions.SessionsPlugin
10:04:24 PluginJAR: java.lang.NoClassDefFoundError: com/microstar/xml/XmlHandler
10:04:24 PluginJAR:  at sessions.SessionManager.<init>(SessionManager.java:99)
10:04:24 PluginJAR:  at sessions.SessionManager.getInstance(SessionManager.java:89)
10:04:24 PluginJAR:  at sessions.SessionsPlugin.start(SessionsPlugin.java:67)
10:04:24 PluginJAR:  at org.gjt.sp.jedit.PluginJAR.startPlugin(PluginJAR.java:1360)
10:04:24 PluginJAR:  at org.gjt.sp.jedit.PluginJAR.activatePlugin(PluginJAR.java:737)
10:04:24 PluginJAR:  at org.gjt.sp.jedit.PluginJAR.activatePluginIfNecessary(PluginJAR.java:807)
10:04:24 PluginJAR:  at org.gjt.sp.jedit.PluginJAR.load(PluginJAR.java:193)
10:04:24 PluginJAR:  at org.gjt.sp.jedit.pluginmgr.ManagePanel$PluginTableModel.setValueAt(ManagePanel.java:532)


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

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

Feature Requests item #2006386, was opened at 2008-06-30 08:08
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350588&aid=2006386&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: core
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Shlomy Reinstein (shlomy)
Assigned to: Nobody/Anonymous (nobody)
Summary: DynamicContextMenuService timeout

Initial Comment:
Generating the context menu may sometimes be very time-consuming (e.g. the context menu provided by SVN plugin in Eclipse). Please add a timeout to the dynamic context menu service, so that a plugin that takes a long time to generate its context menu will be ignored (for the specific context menu request) and not delay the entire context menu.
The timeout should preferably be configurable in the options, but a sensible hard-coded timeout is also fine.

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

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

Patches item #1608486, was opened at 2006-12-04 06:32
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300588&aid=1608486&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: texteditor
Group: None
>Status: Closed
Resolution: Rejected
Priority: 5
Private: No
Submitted By: Nils Nordman (nordman)
Assigned to: Alan Ezust (ezust)
Summary: Support for "thick" caret

Initial Comment:
I've attached a patch for a new configuration option, "thick caret" (in Global options -> Text area). When selected, this causes the caret to be painted slightly wider than the current default. Personally I believe it makes the caret easier to see (as well as better looking, but that might be because I'm used to it from other editors of course). 

What's with the -devel mailing list btw? Seems I'm unable to subscribe or send mail to it..

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

>Comment By: Alan Ezust (ezust)
Date: 2008-06-29 09:35

Message:
Logged In: YES 
user_id=935841
Originator: NO

Made the caret thicker, via recent patch # 2005829

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

Comment By: Alan Ezust (ezust)
Date: 2007-02-09 13:33

Message:
Logged In: YES 
user_id=935841
Originator: NO

The -devel mailing list is alive and well. Are you still having
difficulties getting onto it?

I tried your patch but it is not complete. Since it is a checkbox, it
should be combinable with the "Block" cursor mode too, but checking both
gives me a regular block caret without a thick outline.

Also, when I switch to overwrite, I'd expect the thick caret to have
effect there too. 

Please fix it and resubmit as an attachment to this tracker item.

thanks --alan




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

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

Patches item #1999448, was opened at 2008-06-21 07:08
Message generated for change (Settings changed) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300588&aid=1999448&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: Kazutoshi Satoda (k_satoda)
>Assigned to: Matthieu Casanova (kpouer)
Summary: More efficient and general fix for black hole bug

Initial Comment:
I found joining lines is very slow only when folding
mode is set to other than 'none'.

Reproduction recipe:
  (WARNING: This will cause vary long hang up.)
  - Open doc/CHANGES.txt in jEdit source tree.
  - Do [Expand All Folds] (C+e x).
    (without this, another bug happens.)
  - Do [Select All] (C+a).
  - Try [Join Lines] (C+j).

This patch will speed up this situation by minimizing
calls to buffer.getFoldLevel().

Also, this patch will expand the care about black hole
bug to support ...
  - multi line edit including folded line
  - more folding modes other than 'explicit'
  - modification at the middle of folded range.

I want approval from Matthieu who made the current
fixes for the bugs.

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

Comment By: Matthieu Casanova (kpouer)
Date: 2008-06-25 01:08

Message:
Logged In: YES 
user_id=285591
Originator: NO

Hi, I just tested the patch but there is a problem :

if I use explicit fold, with this buffer

{{{ hello

something

}}}

all folds are folded. I remove one "l" from hello. I think it should not
expand folds since the fold level is not changed

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

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

Patches item #2005829, was opened at 2008-06-29 04:55
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300588&aid=2005829&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: texteditor
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Bernhard Walle (bwalle)
>Assigned to: Alan Ezust (ezust)
Summary: Increase cursor width

Initial Comment:
Most other GUI editors use a line cursor with of two pixels while jEdit only use one pixel. I find one pixel hard to spot on the screen and would like to see it increased on jEdit.

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

>Comment By: Alan Ezust (ezust)
Date: 2008-06-29 09:27

Message:
Logged In: YES 
user_id=935841
Originator: NO

Committed revision 12972.
Thanks! --alan


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

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

On Sun, Jun 29, 2008 at 7:08 AM, Matthew Gilbert <gi...@vo...> wrote:
> Hi all,
>
> I added VoxSepll support for the dynamic menu last night and have a couple
> of suggestions:
>
> 1. It'd be great if the API could be changed to return an array of
> JMenuItems. That way you're not forced to create a submenu (likely I don't
> understand JMenuItems if that ability already exists).

Ok, I'm going to do that now.

> 2. Since menu items can now be added depending on context, I think the caret
> position of the click should be passed instead of just the JEditTextArea.
> When I right click on a miss-spelled word, I want to modify that word, not
> where the caret is in my document. Otherwise, you have to left click then
> right click.

I will do that do. This will cause a couple of breaking changes to the
interface, just to let you all know.


>
> What do you think? Thanks _matt
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> --
> -----------------------------------------------
> jEdit Developers' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>

Yes, that's a really good point. 

Dale


Shlomy Reinstein wrote:
> Hi,
> I think some sort of timeout should be added to the regeneration of
> the dynamic context menu using the service, to ensure context menu
> regeneration won't take too much time due to slow plugins. I am
> writing this from experience - in Eclipse, there are plugins that
> contribute to the context menu with a mechanism similar to this
> service, that cause the context menu to show up after a very long
> delay, sometimes several seconds, and this can be very irritating,
> causing the user to stop using the plugin causing the slowness.
> So, it can be configurable or hard-coded, but better ensure that
> context menu generation doesn't take too long due to this service.
> Shlomy
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
>   

For #1, I'd thought about that too, and it might be a better/more 
flexible plan.  You can do it with additions to the services.xml file, 
but that isn't very dynamic.

For #2, I think the original intent of this change was to support things 
like the spellcheck plugins that need to be able to react to a very 
detailed level of the current text area.  Personally, I've only tested 
this with adding a menu item for the SVN Plugin, but there I only care 
about the View, not the text area.  Jakub is modifying his ContextMenu 
plugin to work with the DynamicContextMenuService, but his plugin is 
really only concerned about the mode of the file, and not the finer 
details like cursor or caret position, or selected word and so on.

It sounds like we have these use cases:

1. The user wants certain actions available as a right-click popup 
globally, such as cut, copy, and paste.  This is the existing functionality.

2. A plugin wants to be able to provide a context menu based on the 
current view, e.g. the SVN Plugin.  In this case, the context menu is 
the same for all views and could be cached.

3. A plugin wants to be able to provide a context menu based on the 
current mode, e.g. the ContextMenu plugin.  In this case, the context 
menu is the same for all modes, and could be cached (the ContextMenu 
plugin does caching now).

4. A plugin wants to be able to provide a context menu based on the word 
at the current cursor or caret position, e.g. the spell check plugins.  
In this case, the context menu could change depending on the specific 
word at the current cursor or caret position.

Are there other use cases?

Thanks,

Dale




Matthew Gilbert wrote:
> Hi all,
>
> I added VoxSepll support for the dynamic menu last night and have a couple
> of suggestions:
>
> 1. It'd be great if the API could be changed to return an array of
> JMenuItems. That way you're not forced to create a submenu (likely I don't
> understand JMenuItems if that ability already exists).
> 2. Since menu items can now be added depending on context, I think the caret
> position of the click should be passed instead of just the JEditTextArea.
> When I right click on a miss-spelled word, I want to modify that word, not
> where the caret is in my document. Otherwise, you have to left click then
> right click.
>
> What do you think? Thanks _matt
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
>   

On Sun, 29 Jun 2008 16:08:44 +0200, Matthew Gilbert <gi...@vo...>
wrote:

> 1. It'd be great if the API could be changed to return an array of
> JMenuItems. That way you're not forced to create a submenu

+1

The ContextMenu plugin, which I'd like to update to use the new API,
usually adds more than one item to the text area's context menu.

-- 
Jakub

Hi all,

I added VoxSepll support for the dynamic menu last night and have a couple
of suggestions:

1. It'd be great if the API could be changed to return an array of
JMenuItems. That way you're not forced to create a submenu (likely I don't
understand JMenuItems if that ability already exists).
2. Since menu items can now be added depending on context, I think the caret
position of the click should be passed instead of just the JEditTextArea.
When I right click on a miss-spelled word, I want to modify that word, not
where the caret is in my document. Otherwise, you have to left click then
right click.

What do you think? Thanks _matt

Feature Requests item #1800610, was opened at 2007-09-23 16:12
Message generated for change (Comment added) made by pekarna
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350588&aid=1800610&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: core
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ondra (pekarna)
Assigned to: Nobody/Anonymous (nobody)
Summary: Syntax Highlighting to Have Unlimited Number of Token types

Initial Comment:
Hello,

I found the fixed number of token types in jEdit very restrictive and unpleasant. When I have some combined code (HTML + PHP + evt. JavaScript + CSS), jEdit colors everything in the similar colors. But having blocks written in different language looking different would be so nice...

I studied jEdit's highlighting definition syntax and figured out that this is not limited by the highlighting system, but by the number of token types.

I've tried jEdit long time ago, then it was quite user unfriendly, crashing and run slowly on my then computer. Now I've found that with plugins, it has all features I look for to switch from my favorite but old editor, HomeSite (which's developement has already ended), EXCEPT for the genial syntax coloring of HomeSite... I will put a screenshot at http://ondra.zizka.cz/temp/HomeSite_screenshot.png . (Intentionally synthetized mix of all languages together, what is bad practice).

So, my feature request is:

As far as the "parsing" system is capable of the feature I ask for, and even the mode files would not have to be rewritten, I guess this is only a matter of the following:

Let's not have fixed set of token types; instead, let's track all token types of each mode and let it be configurable similarly to shortcuts:
1) Separate color configuration for each mode, and
2) Global default color config for certain token types (comment, keyword1, operator), which would be applied if the specific mode setting would be "use default for this token type".

Regards,
Ondra ika

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

>Comment By: Ondra (pekarna)
Date: 2008-06-29 15:08

Message:
Logged In: YES 
user_id=1053064
Originator: YES

I tried jEdit after a long time, and I see that still there is no support
for multiple language files (HTML+PHP, e.g.).
Current system makes such files very confusing and almost unreadable.

- equal signs for HTML attributes have the same color as operators - very
ugly
- PHP delimiter has the same color as the HTML tags - makes them almost
invisible, although they should be most visible (see the attachments)
- comments have the same color in PHP and in HTML - confusing when quickly
scanning the file
and more...


Is there any plugin that could widen the variety of language tokens, or
better, provide a non-trivial syntax highlighting, which could color files
with multiple languages?

Thanks, Ondra

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

Comment By: Ondra (pekarna)
Date: 2008-06-29 15:08

Message:
Logged In: YES 
user_id=1053064
Originator: YES

I tried jEdit after a long time, and I see that still there is no support
for multiple language files (HTML+PHP, e.g.).
Current system makes such files very confusing and almost unreadable.

- equal signs for HTML attributes have the same color as operators - very
ugly
- PHP delimiter has the same color as the HTML tags - makes them almost
invisible, although they should be most visible (see the attachments)
- comments have the same color in PHP and in HTML - confusing when quickly
scanning the file
and more...


Is there any plugin that could widen the variety of language tokens, or
better, provide a non-trivial syntax highlighting, which could color files
with multiple languages?

Thanks, Ondra

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

Comment By: Ingo Tomahogh (itowi)
Date: 2008-03-14 11:17

Message:
Logged In: YES 
user_id=1889436
Originator: NO

Just another suggestion for how to handle mixed language files:
In PHPedit, only one language is highlited at a time (depending on where
the caret is) while all other parts of the filed are 'dimmed' (grey text on
white background). This could translate to jEdit as follows:

1. Introduce one other token type for the 'dimmed' text (or associate a
text style for 'dimmed' display with each language)
2. Optionally display anything that is delegated to another mode file than
the one for the current caret position in the (its?) 'dimmed' style (the
alternative being the old behavior of highliting all of the text)
3. Have separate mode files for each language, i.e., don't mix (some of)
HTML, PHP, JavaScript and CSS into one mode file (which would seem to me
like a cleaner solution anyway)

This would seem to require little changes to the current implementation
while still enabling a clear distinction between the different languages.

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

Comment By: Ondra (pekarna)
Date: 2007-10-01 01:28

Message:
Logged In: YES 
user_id=1053064
Originator: YES

Yes, that closes to the state I am willing for. I think that current
number of all token types would suffice for each separate language. And if
not, one could create second mode file for the same language and delegate
to the tokens defined there. However, I am not sure whether that would be
easier to implement than the "unlimited" tokens solution. I wish I had time
to get familiar with jEdit's core.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2007-09-29 22:15

Message:
Logged In: YES 
user_id=1477607
Originator: NO

I think the following would do just what you ask:

1. Rename the global, fixed set of tokens to have generic, meaningless
names, like "token1", "token2", ...
2. Letting each mode file assign a meaning (mode-specific name) to each
token type. E.g. html could assign "MARKUP1", "MARKUP4" to token types
"TOKEN5" ... "TOKEN8", while c++ could assign "Variable" to "TOKEN5",
"function" to "TOKEN6" and so on.
3. Enabling mode-specific token type styles. E.g. HTML could have TOKEN1
mapped to yellow text, while PHP could have TOKEN1 mapped to red text.
4. The Syntax highlighting option pane would have a mode combo-box
allowing you to select a mode, so you'll see the token type names and
styles defined for that mode and be able to customize them for that mode
(and include a "Use default settings" check-box which is set by default,
like Global Options -> Editing).
5. When rules are delegated to another mode file (e.g. when one language
is embedded in a buffer of another one), the styles of the delegated mode
will be used for its rules. So tokens handled by the PHP mode file will use
PHP styles, no matter if they exist in a PHP buffer or in an HTML buffer
with embedded PHP.

Am I right?


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

Comment By: Ondra (pekarna)
Date: 2007-09-28 14:26

Message:
Logged In: YES 
user_id=1053064
Originator: YES

First, that is not the only difference, either I've chosen bad example, or
you looked badly.

Second, HomeSite uses similar model of syntax hl - external files
describing the syntax (compiled into an executable). Coloring depends on
the parser, not HomeSite. The fact I am pointing at is that HomeSite can
have unlimited number of tokens, thus the attributes like "onclick" could
be parsed as JavaScript.

Third, different styles according to the language would be a workaround;
having the same set of tokens for all languages in the world is (imho)
generally bad idea, as the languages themselves do not have the same
tokens. Eg., for HTML, it would result in using different token types for
different tags. Having just one MARKUP is just too less. And for other
languages, more MARKUPs will remain unused.

Fourth, what do you mean by "language"? If you ever opened the mode files,
you could see that the languages are mixed together in one file and
currently can not be differentiated, as they have just a name and no
namespace. And if you mean "different mode files", that would not solve the
HTML + PHP + ... mixed file coloring. The same is true for different
background color for each edit mode - HTML and PHP are in the same file.

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

Comment By: Matthieu Casanova (kpouer)
Date: 2007-09-26 09:06

Message:
Logged In: YES 
user_id=285591
Originator: NO

Hi, I'm sorry but I don't agree with you, I looked at the screenshots, and
the difference between jEdit and Homesite is that in Homesite the html tags
very basic syntax highlight. 
Homesites seems to choose a color for each tag and use this color for the
entire tag and it's attributes.
I don't think we should have different tokens for different languages. But
it may be possible to have different style for the same token according to
the language.
Another idea, I don't know if it would be easy to do :
add a background color when delegating to another edit mode.

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

Comment By: Ondra (pekarna)
Date: 2007-09-26 03:18

Message:
Logged In: YES 
user_id=1053064
Originator: YES

For the case someone would implement some of functionality described, I
should be able to rewrite the PHP mode file to test with.

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

Comment By: Ondra (pekarna)
Date: 2007-09-26 03:03

Message:
Logged In: YES 
user_id=1053064
Originator: YES

Continuing the discussion here to provide arguments for implementing this
in one place.

Yes, jEdit can handle multiple languages gracefully.

And no, I think that current set of token types do *not* suffice:

Originally, jEdit (as it seemed to me) was originally intended to edit
single-language files, mainly Java and ocassionally the others. And the
idea was, that the programmer likes all the languages look the same, e.g.
operators in red, keywords in blue, etc.

Then, after implementing very precious syntax highlighting system and few
tweaks of it, it become able to parse multiple-language files, like the
HTML + PHP + CSS + JavaScript quartet. And at this moment, having all
languages look the same turned to be great disadvantage - sources are hard
to scan and navigate through. Just try to open some mixed PHP file in jEdit
and compare it with the attached image. I also attach the screenshot of
jEdit. Notice how ugly the code is, compared to HomeSite's hilite.

The main problem is that the token types are not differentiate by language
- what leads to situation, when ALL HTML tags are simply said to be
"MARKUP", what is absolutely insufficient, and also the PHP delimiters,
which should be the most visible part of document, have the very same look!
And other things, like all HTML arguments being colored the same way as PHP
strings using LITERAL<n>, and so on and so on.

Having token types differentiate by language would allow nice syntax
highlighting and for web editing, jEdit would become my "weapon of choice"
:)

And, about the global stuff:  That would be possible, using the KISS-like
string matching. Then:
PHP::String could define LITERAL1 as its default (definition in the mode
file, of course).
PHP::LineComment, PHP::BlockComment, JavaScript::LineComment,
JavaScript::BlockComment, and HTML::Comment could define COMMENT1 as their
default. CSS::BlockComment could use other, in example.

That's almost whole my idea. Very simple in principle and I guess it would
not take that much effort to implement it, as far as I had some affairs
with syntax highlighting programming on several occasions. Better do it
now, before too many plugins will have to be modified after such change ;-)
File Added: jEdit_screenshot.png

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2007-09-24 12:27

Message:
Logged In: YES 
user_id=1477607
Originator: NO

Sorry, I was completely mistaken in the last part. It turns out jEdit has
support for mixed-language buffers which is quite nice. I still think that
the number of tokens is sufficient, unless a single language requires more
token types for itself. I think that jEdit cannot define global semantics
to the fixed set of token types - the semantics is set by the mode files,
and each mode files can use the token types for whatever semantics it
wishes. That's why I suggested to enable mode-specific names for the token
types which indicate the sematics of the types for the mode (to go along
with mode-specific styles for the token types).


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

Comment By: Shlomy Reinstein (shlomy)
Date: 2007-09-24 11:36

Message:
Logged In: YES 
user_id=1477607
Originator: NO

My discussions were not public. I actually suggested that each mode file
defines the token types it uses, and that jEdit collects the token types
from the mode files and enables their customization in the Global Options
dialog. At least some of the token types have hard-coded semantics, so the
token types can't be purely defined in the mode files.

The plugin is currently very limited and only provides a user friendly way
to customize the existing token type styles. In its current, limited
version, it will only be available after the next release of jEdit
(4.3pre11 or something like that). Thanks for your suggestion to help,
maybe we can work together on this. I suggest to continue the discussion
you started in the community site.

Regarding token types: I don't think we are limited by the number of token
types. jEdit defines 17 token types, do you know of a language that
requires more?
Regarding delimiters between languages: This is not a matter of token
types. The concept is that a buffer is opened in an edit mode (a single
edit mode). I don't know if jEdit currently handles several languages in
the same buffer, as far as I know it does not (correct me if I'm wrong...),
and if this is the case, a massive change is required in jEdit to support
that and I doubt this will ever happen due to the complexity. However, I
think it can be done, to some extent, in a plugin. I suggest to discuss
this along with the other requested features on the community site until we
reach some decision.


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

Comment By: Ondra (pekarna)
Date: 2007-09-23 18:03

Message:
Logged In: YES 
user_id=1053064
Originator: YES

Ah... and was that discussion public?

And, if jEdit core devs decide to keep limited number of token types,
could they at least add some? That shouldn't be that hard. My suggestion is
below. I know that such solution is not much systemic, but better than
nothing.

When do you assume that plugin could be ready for use? I would love to
help, but yet I do not know anything about jEdit plugins writing. If you
had some task that common Java programmer could do, tell me.


Suggested token types:

Most important: DELIMITER for delimiters between different languages (E.G.
HTML / PHP <? ?>, C++ / embeded SQL, etc.) Such delimiters are the very
important when editing combined code.

Also imporant: MARKUP2 - MARKUP8 for different colors for different
XML/HTML tags - having the same colors for all tags is really ugly. See the
attachment for an example of nice colored HTML and you simply must agree
that such coloring is much prettier and much more lucid.

FUNCTION2 (e.g. for PHP built-in functions)
FUNCTION3 (e.g. for JavaScript -||-)
FUNCTION4 (e.g. for CSS selectors)


OPERATOR2 (e.g. for PHP's @ operator, which is kind of exceptional).
OPERATOR3 (e.g. for PHP's . operator, which usualy appears between strings
and should be more visible).

KEYWORD 5 to 8 - each language has it's own keywords and it's own
highlighting style (or should have)...



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

Comment By: Shlomy Reinstein (shlomy)
Date: 2007-09-23 16:36

Message:
Logged In: YES 
user_id=1477607
Originator: NO

I don't think we are limited by the number of tokens, although I agree
that in principle there is no reason to limit the number of tokens.
I've had a few discussions with some of the developers about syntax
highlighting. I, too, suggested to do all that you ask in this feature
request, and more. However, since the jEdit core is fairly complex already,
I've written a plugin named SyntaxHelper. Currently, this plugin only makes
it easy to configure the style of each token, by showing you the syntax
highlighting option pane in a dockable window and letting it follow the
caret and show you the style of the token under the caret. Unfortunately,
it depends on the latest jEdit development version and can't be released
until jEdit 4.3pre11 (or 4.3final) comes out.
A future plan for this plugin is to enable mode-specific token styles and
names. That is, each mode will be able to bind its own names for the
existing token types, which will be more meaningful for the mode, and also
suggest default styles for these token types. Users will be able to
customize the global defaults as well as the mode-specific styles for each
token type using the plugin. I don't want to introduce more complexity into
jEdit for something that can easily be done in a plugin. I also thought of
some revolutionary idea, where the plugin will let the user pick an
arbitrary editor window on the screen (of some other editor) and "import"
the style settings from that editor by querying the OS for the text style
where possible (or apply some AI technique, but this gets out of scope for
a SyntaxHelper plugin :-) and use it for the token type that jEdit would
map this text to. But both of these are long-term plans.


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

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

Feature Requests item #1800610, was opened at 2007-09-23 16:12
Message generated for change (Comment added) made by pekarna
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350588&aid=1800610&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: core
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ondra (pekarna)
Assigned to: Nobody/Anonymous (nobody)
Summary: Syntax Highlighting to Have Unlimited Number of Token types

Initial Comment:
Hello,

I found the fixed number of token types in jEdit very restrictive and unpleasant. When I have some combined code (HTML + PHP + evt. JavaScript + CSS), jEdit colors everything in the similar colors. But having blocks written in different language looking different would be so nice...

I studied jEdit's highlighting definition syntax and figured out that this is not limited by the highlighting system, but by the number of token types.

I've tried jEdit long time ago, then it was quite user unfriendly, crashing and run slowly on my then computer. Now I've found that with plugins, it has all features I look for to switch from my favorite but old editor, HomeSite (which's developement has already ended), EXCEPT for the genial syntax coloring of HomeSite... I will put a screenshot at http://ondra.zizka.cz/temp/HomeSite_screenshot.png . (Intentionally synthetized mix of all languages together, what is bad practice).

So, my feature request is:

As far as the "parsing" system is capable of the feature I ask for, and even the mode files would not have to be rewritten, I guess this is only a matter of the following:

Let's not have fixed set of token types; instead, let's track all token types of each mode and let it be configurable similarly to shortcuts:
1) Separate color configuration for each mode, and
2) Global default color config for certain token types (comment, keyword1, operator), which would be applied if the specific mode setting would be "use default for this token type".

Regards,
Ondra ika

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

>Comment By: Ondra (pekarna)
Date: 2008-06-29 15:08

Message:
Logged In: YES 
user_id=1053064
Originator: YES

I tried jEdit after a long time, and I see that still there is no support
for multiple language files (HTML+PHP, e.g.).
Current system makes such files very confusing and almost unreadable.

- equal signs for HTML attributes have the same color as operators - very
ugly
- PHP delimiter has the same color as the HTML tags - makes them almost
invisible, although they should be most visible (see the attachments)
- comments have the same color in PHP and in HTML - confusing when quickly
scanning the file
and more...


Is there any plugin that could widen the variety of language tokens, or
better, provide a non-trivial syntax highlighting, which could color files
with multiple languages?

Thanks, Ondra

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

Comment By: Ingo Tomahogh (itowi)
Date: 2008-03-14 11:17

Message:
Logged In: YES 
user_id=1889436
Originator: NO

Just another suggestion for how to handle mixed language files:
In PHPedit, only one language is highlited at a time (depending on where
the caret is) while all other parts of the filed are 'dimmed' (grey text on
white background). This could translate to jEdit as follows:

1. Introduce one other token type for the 'dimmed' text (or associate a
text style for 'dimmed' display with each language)
2. Optionally display anything that is delegated to another mode file than
the one for the current caret position in the (its?) 'dimmed' style (the
alternative being the old behavior of highliting all of the text)
3. Have separate mode files for each language, i.e., don't mix (some of)
HTML, PHP, JavaScript and CSS into one mode file (which would seem to me
like a cleaner solution anyway)

This would seem to require little changes to the current implementation
while still enabling a clear distinction between the different languages.

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

Comment By: Ondra (pekarna)
Date: 2007-10-01 01:28

Message:
Logged In: YES 
user_id=1053064
Originator: YES

Yes, that closes to the state I am willing for. I think that current
number of all token types would suffice for each separate language. And if
not, one could create second mode file for the same language and delegate
to the tokens defined there. However, I am not sure whether that would be
easier to implement than the "unlimited" tokens solution. I wish I had time
to get familiar with jEdit's core.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2007-09-29 22:15

Message:
Logged In: YES 
user_id=1477607
Originator: NO

I think the following would do just what you ask:

1. Rename the global, fixed set of tokens to have generic, meaningless
names, like "token1", "token2", ...
2. Letting each mode file assign a meaning (mode-specific name) to each
token type. E.g. html could assign "MARKUP1", "MARKUP4" to token types
"TOKEN5" ... "TOKEN8", while c++ could assign "Variable" to "TOKEN5",
"function" to "TOKEN6" and so on.
3. Enabling mode-specific token type styles. E.g. HTML could have TOKEN1
mapped to yellow text, while PHP could have TOKEN1 mapped to red text.
4. The Syntax highlighting option pane would have a mode combo-box
allowing you to select a mode, so you'll see the token type names and
styles defined for that mode and be able to customize them for that mode
(and include a "Use default settings" check-box which is set by default,
like Global Options -> Editing).
5. When rules are delegated to another mode file (e.g. when one language
is embedded in a buffer of another one), the styles of the delegated mode
will be used for its rules. So tokens handled by the PHP mode file will use
PHP styles, no matter if they exist in a PHP buffer or in an HTML buffer
with embedded PHP.

Am I right?


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

Comment By: Ondra (pekarna)
Date: 2007-09-28 14:26

Message:
Logged In: YES 
user_id=1053064
Originator: YES

First, that is not the only difference, either I've chosen bad example, or
you looked badly.

Second, HomeSite uses similar model of syntax hl - external files
describing the syntax (compiled into an executable). Coloring depends on
the parser, not HomeSite. The fact I am pointing at is that HomeSite can
have unlimited number of tokens, thus the attributes like "onclick" could
be parsed as JavaScript.

Third, different styles according to the language would be a workaround;
having the same set of tokens for all languages in the world is (imho)
generally bad idea, as the languages themselves do not have the same
tokens. Eg., for HTML, it would result in using different token types for
different tags. Having just one MARKUP is just too less. And for other
languages, more MARKUPs will remain unused.

Fourth, what do you mean by "language"? If you ever opened the mode files,
you could see that the languages are mixed together in one file and
currently can not be differentiated, as they have just a name and no
namespace. And if you mean "different mode files", that would not solve the
HTML + PHP + ... mixed file coloring. The same is true for different
background color for each edit mode - HTML and PHP are in the same file.

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

Comment By: Matthieu Casanova (kpouer)
Date: 2007-09-26 09:06

Message:
Logged In: YES 
user_id=285591
Originator: NO

Hi, I'm sorry but I don't agree with you, I looked at the screenshots, and
the difference between jEdit and Homesite is that in Homesite the html tags
very basic syntax highlight. 
Homesites seems to choose a color for each tag and use this color for the
entire tag and it's attributes.
I don't think we should have different tokens for different languages. But
it may be possible to have different style for the same token according to
the language.
Another idea, I don't know if it would be easy to do :
add a background color when delegating to another edit mode.

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

Comment By: Ondra (pekarna)
Date: 2007-09-26 03:18

Message:
Logged In: YES 
user_id=1053064
Originator: YES

For the case someone would implement some of functionality described, I
should be able to rewrite the PHP mode file to test with.

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

Comment By: Ondra (pekarna)
Date: 2007-09-26 03:03

Message:
Logged In: YES 
user_id=1053064
Originator: YES

Continuing the discussion here to provide arguments for implementing this
in one place.

Yes, jEdit can handle multiple languages gracefully.

And no, I think that current set of token types do *not* suffice:

Originally, jEdit (as it seemed to me) was originally intended to edit
single-language files, mainly Java and ocassionally the others. And the
idea was, that the programmer likes all the languages look the same, e.g.
operators in red, keywords in blue, etc.

Then, after implementing very precious syntax highlighting system and few
tweaks of it, it become able to parse multiple-language files, like the
HTML + PHP + CSS + JavaScript quartet. And at this moment, having all
languages look the same turned to be great disadvantage - sources are hard
to scan and navigate through. Just try to open some mixed PHP file in jEdit
and compare it with the attached image. I also attach the screenshot of
jEdit. Notice how ugly the code is, compared to HomeSite's hilite.

The main problem is that the token types are not differentiate by language
- what leads to situation, when ALL HTML tags are simply said to be
"MARKUP", what is absolutely insufficient, and also the PHP delimiters,
which should be the most visible part of document, have the very same look!
And other things, like all HTML arguments being colored the same way as PHP
strings using LITERAL<n>, and so on and so on.

Having token types differentiate by language would allow nice syntax
highlighting and for web editing, jEdit would become my "weapon of choice"
:)

And, about the global stuff:  That would be possible, using the KISS-like
string matching. Then:
PHP::String could define LITERAL1 as its default (definition in the mode
file, of course).
PHP::LineComment, PHP::BlockComment, JavaScript::LineComment,
JavaScript::BlockComment, and HTML::Comment could define COMMENT1 as their
default. CSS::BlockComment could use other, in example.

That's almost whole my idea. Very simple in principle and I guess it would
not take that much effort to implement it, as far as I had some affairs
with syntax highlighting programming on several occasions. Better do it
now, before too many plugins will have to be modified after such change ;-)
File Added: jEdit_screenshot.png

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2007-09-24 12:27

Message:
Logged In: YES 
user_id=1477607
Originator: NO

Sorry, I was completely mistaken in the last part. It turns out jEdit has
support for mixed-language buffers which is quite nice. I still think that
the number of tokens is sufficient, unless a single language requires more
token types for itself. I think that jEdit cannot define global semantics
to the fixed set of token types - the semantics is set by the mode files,
and each mode files can use the token types for whatever semantics it
wishes. That's why I suggested to enable mode-specific names for the token
types which indicate the sematics of the types for the mode (to go along
with mode-specific styles for the token types).


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

Comment By: Shlomy Reinstein (shlomy)
Date: 2007-09-24 11:36

Message:
Logged In: YES 
user_id=1477607
Originator: NO

My discussions were not public. I actually suggested that each mode file
defines the token types it uses, and that jEdit collects the token types
from the mode files and enables their customization in the Global Options
dialog. At least some of the token types have hard-coded semantics, so the
token types can't be purely defined in the mode files.

The plugin is currently very limited and only provides a user friendly way
to customize the existing token type styles. In its current, limited
version, it will only be available after the next release of jEdit
(4.3pre11 or something like that). Thanks for your suggestion to help,
maybe we can work together on this. I suggest to continue the discussion
you started in the community site.

Regarding token types: I don't think we are limited by the number of token
types. jEdit defines 17 token types, do you know of a language that
requires more?
Regarding delimiters between languages: This is not a matter of token
types. The concept is that a buffer is opened in an edit mode (a single
edit mode). I don't know if jEdit currently handles several languages in
the same buffer, as far as I know it does not (correct me if I'm wrong...),
and if this is the case, a massive change is required in jEdit to support
that and I doubt this will ever happen due to the complexity. However, I
think it can be done, to some extent, in a plugin. I suggest to discuss
this along with the other requested features on the community site until we
reach some decision.


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

Comment By: Ondra (pekarna)
Date: 2007-09-23 18:03

Message:
Logged In: YES 
user_id=1053064
Originator: YES

Ah... and was that discussion public?

And, if jEdit core devs decide to keep limited number of token types,
could they at least add some? That shouldn't be that hard. My suggestion is
below. I know that such solution is not much systemic, but better than
nothing.

When do you assume that plugin could be ready for use? I would love to
help, but yet I do not know anything about jEdit plugins writing. If you
had some task that common Java programmer could do, tell me.


Suggested token types:

Most important: DELIMITER for delimiters between different languages (E.G.
HTML / PHP <? ?>, C++ / embeded SQL, etc.) Such delimiters are the very
important when editing combined code.

Also imporant: MARKUP2 - MARKUP8 for different colors for different
XML/HTML tags - having the same colors for all tags is really ugly. See the
attachment for an example of nice colored HTML and you simply must agree
that such coloring is much prettier and much more lucid.

FUNCTION2 (e.g. for PHP built-in functions)
FUNCTION3 (e.g. for JavaScript -||-)
FUNCTION4 (e.g. for CSS selectors)


OPERATOR2 (e.g. for PHP's @ operator, which is kind of exceptional).
OPERATOR3 (e.g. for PHP's . operator, which usualy appears between strings
and should be more visible).

KEYWORD 5 to 8 - each language has it's own keywords and it's own
highlighting style (or should have)...



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

Comment By: Shlomy Reinstein (shlomy)
Date: 2007-09-23 16:36

Message:
Logged In: YES 
user_id=1477607
Originator: NO

I don't think we are limited by the number of tokens, although I agree
that in principle there is no reason to limit the number of tokens.
I've had a few discussions with some of the developers about syntax
highlighting. I, too, suggested to do all that you ask in this feature
request, and more. However, since the jEdit core is fairly complex already,
I've written a plugin named SyntaxHelper. Currently, this plugin only makes
it easy to configure the style of each token, by showing you the syntax
highlighting option pane in a dockable window and letting it follow the
caret and show you the style of the token under the caret. Unfortunately,
it depends on the latest jEdit development version and can't be released
until jEdit 4.3pre11 (or 4.3final) comes out.
A future plan for this plugin is to enable mode-specific token styles and
names. That is, each mode will be able to bind its own names for the
existing token types, which will be more meaningful for the mode, and also
suggest default styles for these token types. Users will be able to
customize the global defaults as well as the mode-specific styles for each
token type using the plugin. I don't want to introduce more complexity into
jEdit for something that can easily be done in a plugin. I also thought of
some revolutionary idea, where the plugin will let the user pick an
arbitrary editor window on the screen (of some other editor) and "import"
the style settings from that editor by querying the OS for the text style
where possible (or apply some AI technique, but this gets out of scope for
a SyntaxHelper plugin :-) and use it for the token type that jEdit would
map this text to. But both of these are long-term plans.


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

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

Patches item #2005829, was opened at 2008-06-29 13:55
Message generated for change (Settings changed) made by bwalle
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300588&aid=2005829&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: texteditor
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Bernhard Walle (bwalle)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Increase cursor width

Initial Comment:
Most other GUI editors use a line cursor with of two pixels while jEdit only use one pixel. I find one pixel hard to spot on the screen and would like to see it increased on jEdit.

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

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

Patches item #2005829, was opened at 2008-06-29 13:55
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300588&aid=2005829&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: texteditor
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Bernhard Walle (bwalle)
Assigned to: Nobody/Anonymous (nobody)
Summary: Increase cursor with

Initial Comment:
Most other GUI editors use a line cursor with of two pixels while jEdit only use one pixel. I find one pixel hard to spot on the screen and would like to see it increased on jEdit.

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

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

Hi,
I think some sort of timeout should be added to the regeneration of
the dynamic context menu using the service, to ensure context menu
regeneration won't take too much time due to slow plugins. I am
writing this from experience - in Eclipse, there are plugins that
contribute to the context menu with a mechanism similar to this
service, that cause the context menu to show up after a very long
delay, sometimes several seconds, and this can be very irritating,
causing the user to stop using the plugin causing the slowness.
So, it can be configurable or hard-coded, but better ensure that
context menu generation doesn't take too long due to this service.
Shlomy

Feature Requests item #2003560, was opened at 2008-06-26 15:48
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350588&aid=2003560&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
Private: No
Submitted By: Alan Ezust (ezust)
Assigned to: Alan Ezust (ezust)
Summary: DynamicContextMenuService

Initial Comment:
It would be nice if plugins could offer as a jEdit service, something derived from class DynamicContextMenuService. I have not decided exactly what this interface should be yet, but I have some ideas.

Currently, jEdit regens the context menu whenever the properties are changed. This is not often enough.

The context menu should be regenned each time the context menu is requested by the user. 

Further, when the context menu is genned, jedit core should look for all services offered that contain additional menus and display them (or not) in the context menu depending on whether the editpane is in the right state, or the cursor is over a particular word, etc.

Plugins that offer this service need info about the EditPane (such as caret position, buffer mode, etc), so the ctor of the DynamicContextMenuService needs to include the EditPane, and there must be a getEditPane() method in the base class.





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

>Comment By: Alan Ezust (ezust)
Date: 2008-06-28 15:32

Message:
Logged In: YES 
user_id=935841
Originator: YES

Committed # 12960.
Now it's a JEditTextArea, you can get a view from that.
thanks again for your help. let me know if anything else needs to be
fixed.


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

Comment By: Dale Anson (daleanson)
Date: 2008-06-28 13:24

Message:
Logged In: YES 
user_id=187628
Originator: NO

Well... the TextArea change made sense until I tried to retrofit the
DynamicContextMenuService class I'd installed in the SVNPlugin.  I wasn't
actually using the EditPane other than as a way to get a reference to the
View.  TextArea has no such reference, nor does it have a reference to it's
EditPane.  JEditTextArea however, does.  Isn't there a one-to-one
relationship between EditPane and TextArea anyway?  Or am I overlooking
some way to get the View from the TextArea? 

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

Comment By: Alan Ezust (ezust)
Date: 2008-06-28 12:31

Message:
Logged In: YES 
user_id=935841
Originator: YES

I incorporated your patch, but I also changed the interface to it uses a
TextArea instead of an EditPane,
because it  is in the TextArea where we need to update the context menus.

see svn#12959.


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

Comment By: Alan Ezust (ezust)
Date: 2008-06-28 10:05

Message:
Logged In: YES 
user_id=935841
Originator: YES

Good idea, doing it at the guiutilties level.
I was also thinking of changing the interface of the
DynamicContextMenuService so instead of return a JMenuItem, it gets passed
a JPopupMenu that it can modify or not, inserting the menu items directly.
Which do you think is better? returning a JMenuItem and letting the core
deicde where to put it,  or having the plugin do the modification of a
JPopupMenu?


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

Comment By: Dale Anson (daleanson)
Date: 2008-06-28 09:00

Message:
Logged In: YES 
user_id=187628
Originator: NO

Attached dcms_2.patch
File Added: dcms_2.patch

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

Comment By: Dale Anson (daleanson)
Date: 2008-06-28 08:58

Message:
Logged In: YES 
user_id=187628
Originator: NO

Alan, I made some changes that seem to work well, at least for the SVN
Plugin.  I've attached another patch.  This patch assumes your
DynamicContextMenuService class exists and assumes your original patch has
not been applied to either EditPane.java or GUIUtilities.java.  I changed
the API in GUIUtilities somewhat.  It's backward compatible, but the main
change is I added a couple of new methods for loading the popup menu that
accept an EditPane as a parameter.  If the EditPane parameter is not null,
this tells GUIUtilities to load any menu items defined by
DynamicContextMenuServices.  If it is null, which is the case for backward
compatibility, then the menu items defined by DynamicContextMenuServices
are not loaded.  I did this because otherwise a plugin that called
GUIUtilities.loadPopupMenu(String name) to create its own menu would also
get the service-defined menu items even if they are not pertinent.

So the basic rule I came up with is if you want the service-defined menu
items to be provided by GUIUtilities, you have to pass in a reference to an
EditPane.  Otherwise, you don't get them.  The attached patch adjusts
EditPane to pass in a reference to itself, so the service-defined menu
items will be added to the popup.

I discovered a problem, though, and it's the ContextMenu plugin.  I didn't
realize I had it loaded and it took me a while to figure out it was
rebuilding the context menu after the EditPane and replacing it minus the
service-provided menu items.  The ContextMenu plugin will need some work to
play nicely with these changes, but it doesn't look like a lot of work.



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

Comment By: Alan Ezust (ezust)
Date: 2008-06-27 07:12

Message:
Logged In: YES 
user_id=935841
Originator: YES

What I committed is not 100% finished yet. There may still be some bugs.
If you want to try making it work with the svn plugin and perhaps help me
resolve the outstanding issues, that would be appreciated.


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

Comment By: Dale Anson (daleanson)
Date: 2008-06-26 21:45

Message:
Logged In: YES 
user_id=187628
Originator: NO

Did you mean to close this?  I'm getting it all to compile, and getting
the service to work from the SVN Plugin.  Things aren't quite right,
though.  I can get the menu item to appear in the text area context menu,
but the actions don't work.  For the SVN Plugin, the added menu item
provides a pull out menu, and none of the actions on the pull out menu
work.  In the ProjectViewer context menu I now have 2 pull out menu items,
probably because one is added by the service and one I'm still adding
directly.  In this context menu, the pull out menu items work, the other
does not. 

I noticed too that there appears to be an empty menu item in all cases. 
It is clickable, but doesn't do anything.  It's late, I'll look at this
some more tomorrow, but thanks, Alan, this looks real close and is a great
addition.


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

Comment By: Alan Ezust (ezust)
Date: 2008-06-26 21:19

Message:
Logged In: YES 
user_id=935841
Originator: YES

Committed svn rev# 12937.
This one compiles.


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

Comment By: Dale Anson (daleanson)
Date: 2008-06-26 20:38

Message:
Logged In: YES 
user_id=187628
Originator: NO

I got around the line 90 problem like this for now:

menu.add(dcms.createMenu(null);

We still need to figure out how to get a reference to an EditPane for that
line.

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

Comment By: Dale Anson (daleanson)
Date: 2008-06-26 20:32

Message:
Logged In: YES 
user_id=187628
Originator: NO

Yeah, I know about that being busy part, I've been meaning to work on the
unit tests for a couple of weeks now, but just haven't had the time.

I can't get your patch to compile.  I'm looking into it now.  The problem
is on line 90 of the patch, it's missing a ; at the end of the line, but
the bigger problem is on that same line 

menu.add(dcms.createMenu(pane);

it references "pane", but there is no pane in scope.


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

Comment By: Alan Ezust (ezust)
Date: 2008-06-26 18:04

Message:
Logged In: YES 
user_id=935841
Originator: YES

Here is the idea... What do you think about it?

File Added: dcms.patch

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

Comment By: Alan Ezust (ezust)
Date: 2008-06-26 16:15

Message:
Logged In: YES 
user_id=935841
Originator: YES

The DynamicContextMenuService does not exist yet.

It's something I'm thinking about now. I think I will slide it in before
pre15 comes out.
When it's available, we can use the Subversion Plugin (and the VoxSpell
plugin) as guinea pigs for offering derived types as jEdit services.

Sorry I didn't respond when you brought it up earlier, my head was buried
in other things.


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

Comment By: Dale Anson (daleanson)
Date: 2008-06-26 16:11

Message:
Logged In: YES 
user_id=187628
Originator: NO

This is an excellent idea -- I think.  You're talking about the text area
context menu, right?  Assuming so, I added a "Subversion" item to it
whenever the SVN Plugin is loaded.  What I've done feels like a kludge. 
Essentially, I've set up the SVNPlugin class to derive from EBPlugin, then
on every message it receives, it rebuilds the context menu for that text
area and inserts a new item for the Subversion menu and submenu.  I'm sure
that if anyone else wanted to do the same thing in another plugin there
would be problems.  I'd asked on the dev list before I did this, but didn't
really get a response about the right way to do it.  

I've got the latest jEdit code from subversion, but I don't find the
DynamicContextMenuService you reference.  Is it part of a plugin, or what?
 

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

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

Feature Requests item #2003560, was opened at 2008-06-26 15:48
Message generated for change (Comment added) made by daleanson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350588&aid=2003560&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
Private: No
Submitted By: Alan Ezust (ezust)
Assigned to: Alan Ezust (ezust)
Summary: DynamicContextMenuService

Initial Comment:
It would be nice if plugins could offer as a jEdit service, something derived from class DynamicContextMenuService. I have not decided exactly what this interface should be yet, but I have some ideas.

Currently, jEdit regens the context menu whenever the properties are changed. This is not often enough.

The context menu should be regenned each time the context menu is requested by the user. 

Further, when the context menu is genned, jedit core should look for all services offered that contain additional menus and display them (or not) in the context menu depending on whether the editpane is in the right state, or the cursor is over a particular word, etc.

Plugins that offer this service need info about the EditPane (such as caret position, buffer mode, etc), so the ctor of the DynamicContextMenuService needs to include the EditPane, and there must be a getEditPane() method in the base class.





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

>Comment By: Dale Anson (daleanson)
Date: 2008-06-28 13:24

Message:
Logged In: YES 
user_id=187628
Originator: NO

Well... the TextArea change made sense until I tried to retrofit the
DynamicContextMenuService class I'd installed in the SVNPlugin.  I wasn't
actually using the EditPane other than as a way to get a reference to the
View.  TextArea has no such reference, nor does it have a reference to it's
EditPane.  JEditTextArea however, does.  Isn't there a one-to-one
relationship between EditPane and TextArea anyway?  Or am I overlooking
some way to get the View from the TextArea? 

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

Comment By: Alan Ezust (ezust)
Date: 2008-06-28 12:31

Message:
Logged In: YES 
user_id=935841
Originator: YES

I incorporated your patch, but I also changed the interface to it uses a
TextArea instead of an EditPane,
because it  is in the TextArea where we need to update the context menus.

see svn#12959.


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

Comment By: Alan Ezust (ezust)
Date: 2008-06-28 10:05

Message:
Logged In: YES 
user_id=935841
Originator: YES

Good idea, doing it at the guiutilties level.
I was also thinking of changing the interface of the
DynamicContextMenuService so instead of return a JMenuItem, it gets passed
a JPopupMenu that it can modify or not, inserting the menu items directly.
Which do you think is better? returning a JMenuItem and letting the core
deicde where to put it,  or having the plugin do the modification of a
JPopupMenu?


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

Comment By: Dale Anson (daleanson)
Date: 2008-06-28 09:00

Message:
Logged In: YES 
user_id=187628
Originator: NO

Attached dcms_2.patch
File Added: dcms_2.patch

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

Comment By: Dale Anson (daleanson)
Date: 2008-06-28 08:58

Message:
Logged In: YES 
user_id=187628
Originator: NO

Alan, I made some changes that seem to work well, at least for the SVN
Plugin.  I've attached another patch.  This patch assumes your
DynamicContextMenuService class exists and assumes your original patch has
not been applied to either EditPane.java or GUIUtilities.java.  I changed
the API in GUIUtilities somewhat.  It's backward compatible, but the main
change is I added a couple of new methods for loading the popup menu that
accept an EditPane as a parameter.  If the EditPane parameter is not null,
this tells GUIUtilities to load any menu items defined by
DynamicContextMenuServices.  If it is null, which is the case for backward
compatibility, then the menu items defined by DynamicContextMenuServices
are not loaded.  I did this because otherwise a plugin that called
GUIUtilities.loadPopupMenu(String name) to create its own menu would also
get the service-defined menu items even if they are not pertinent.

So the basic rule I came up with is if you want the service-defined menu
items to be provided by GUIUtilities, you have to pass in a reference to an
EditPane.  Otherwise, you don't get them.  The attached patch adjusts
EditPane to pass in a reference to itself, so the service-defined menu
items will be added to the popup.

I discovered a problem, though, and it's the ContextMenu plugin.  I didn't
realize I had it loaded and it took me a while to figure out it was
rebuilding the context menu after the EditPane and replacing it minus the
service-provided menu items.  The ContextMenu plugin will need some work to
play nicely with these changes, but it doesn't look like a lot of work.



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

Comment By: Alan Ezust (ezust)
Date: 2008-06-27 07:12

Message:
Logged In: YES 
user_id=935841
Originator: YES

What I committed is not 100% finished yet. There may still be some bugs.
If you want to try making it work with the svn plugin and perhaps help me
resolve the outstanding issues, that would be appreciated.


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

Comment By: Dale Anson (daleanson)
Date: 2008-06-26 21:45

Message:
Logged In: YES 
user_id=187628
Originator: NO

Did you mean to close this?  I'm getting it all to compile, and getting
the service to work from the SVN Plugin.  Things aren't quite right,
though.  I can get the menu item to appear in the text area context menu,
but the actions don't work.  For the SVN Plugin, the added menu item
provides a pull out menu, and none of the actions on the pull out menu
work.  In the ProjectViewer context menu I now have 2 pull out menu items,
probably because one is added by the service and one I'm still adding
directly.  In this context menu, the pull out menu items work, the other
does not. 

I noticed too that there appears to be an empty menu item in all cases. 
It is clickable, but doesn't do anything.  It's late, I'll look at this
some more tomorrow, but thanks, Alan, this looks real close and is a great
addition.


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

Comment By: Alan Ezust (ezust)
Date: 2008-06-26 21:19

Message:
Logged In: YES 
user_id=935841
Originator: YES

Committed svn rev# 12937.
This one compiles.


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

Comment By: Dale Anson (daleanson)
Date: 2008-06-26 20:38

Message:
Logged In: YES 
user_id=187628
Originator: NO

I got around the line 90 problem like this for now:

menu.add(dcms.createMenu(null);

We still need to figure out how to get a reference to an EditPane for that
line.

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

Comment By: Dale Anson (daleanson)
Date: 2008-06-26 20:32

Message:
Logged In: YES 
user_id=187628
Originator: NO

Yeah, I know about that being busy part, I've been meaning to work on the
unit tests for a couple of weeks now, but just haven't had the time.

I can't get your patch to compile.  I'm looking into it now.  The problem
is on line 90 of the patch, it's missing a ; at the end of the line, but
the bigger problem is on that same line 

menu.add(dcms.createMenu(pane);

it references "pane", but there is no pane in scope.


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

Comment By: Alan Ezust (ezust)
Date: 2008-06-26 18:04

Message:
Logged In: YES 
user_id=935841
Originator: YES

Here is the idea... What do you think about it?

File Added: dcms.patch

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

Comment By: Alan Ezust (ezust)
Date: 2008-06-26 16:15

Message:
Logged In: YES 
user_id=935841
Originator: YES

The DynamicContextMenuService does not exist yet.

It's something I'm thinking about now. I think I will slide it in before
pre15 comes out.
When it's available, we can use the Subversion Plugin (and the VoxSpell
plugin) as guinea pigs for offering derived types as jEdit services.

Sorry I didn't respond when you brought it up earlier, my head was buried
in other things.


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

Comment By: Dale Anson (daleanson)
Date: 2008-06-26 16:11

Message:
Logged In: YES 
user_id=187628
Originator: NO

This is an excellent idea -- I think.  You're talking about the text area
context menu, right?  Assuming so, I added a "Subversion" item to it
whenever the SVN Plugin is loaded.  What I've done feels like a kludge. 
Essentially, I've set up the SVNPlugin class to derive from EBPlugin, then
on every message it receives, it rebuilds the context menu for that text
area and inserts a new item for the Subversion menu and submenu.  I'm sure
that if anyone else wanted to do the same thing in another plugin there
would be problems.  I'd asked on the dev list before I did this, but didn't
really get a response about the right way to do it.  

I've got the latest jEdit code from subversion, but I don't find the
DynamicContextMenuService you reference.  Is it part of a plugin, or what?
 

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

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