jedit-devel Mailing List for jEdit

Plugin Bugs item #3310814, was opened at 2011-06-02 20:11
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3310814&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: Works For Me
Priority: 5
Private: No
Submitted By: heimetli (heimetli)
Assigned to: Eric Le Lay (kerik-sf)
Summary: JEdit can't validate using DTD if there is an Umlaut in

Initial Comment:
I found the following bug in Editix: it can't validate the DTD when there is an Umlaut (e.g. ä) in the path.

Editix has exactly the same problem, but doesn't even display an error message, making it impossible to find the cause.

YES, I know that this is probably a Java problem, but you could at least display an error message which makes sense !

Platform: Windows XP, JEdit 4.2

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

>Comment By: SourceForge Robot (sf-robot)
Date: 2011-06-30 18:20

Message:
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: Eric Le Lay (kerik-sf)
Date: 2011-06-16 17:38

Message:
works with the latest releases

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

Comment By: Eric Le Lay (kerik-sf)
Date: 2011-06-05 18:51

Message:
Hi Heimtli,
you are using an old version of jEdit and an old version XML Plugin
(0.14).
Please consider updating to jEdit 4.3.2 and XML Plugin 2.8 and try again.
It should work, then.
The error in plugin manager should also vanish.
Regards,
Eric

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

Comment By: heimetli (heimetli)
Date: 2011-06-03 20:15

Message:
Hello Eric,

look at the pictures.

The DTD is in the same directory and the XML is valid !

Where is the Activity log ?

Add a new error: when a file with ü in the path is open, opening the
update tab in the plugin manager causes the error in the picture.

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

Comment By: Eric Le Lay (kerik-sf)
Date: 2011-06-03 19:23

Message:
hi, 
I can't reproduce your problem (Platform: Linux - ibm-jdk-1.6 - jedit
trunk).
What version of XML plugin do you have ? 2.8.0 ?
Could you describe a bit more what's your setting :
 - What's the path to the XML file you are editing ?
 - What's the path to the DTD ?
 - Is there something in the Activity log when you parse the file ?

Thanks,
Eric

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

Comment By: heimetli (heimetli)
Date: 2011-06-02 20:15

Message:
Sorry, of course it's JEDIT which has exactly the same problem.

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

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

Actually you were lucky that it worked at all.
Since some time SF changed the mirror system.
We didn't adapt to it and were lucky they had some failover.
This meant that mirrors that are not available anymore anyway gave an
error and mirrors that were still there worked, but were forwarded to
SOME mirror and thus not the configured one was used.

For those who are interested:

We constructed the downloadlinks like it was correct before the change:
http://<mirrorname>.dl.sourceforge.net/sourceforge/jedit-plugins/<name>-<version>.zip
For mirrors not present anymore this may fail.
For mirrors that are still present this forwards to:
http://downloads.sourceforge.net/sourceforge/jedit-plugins/<name>-<version>.zip?download&failedmirror=<mirrorname>.dl.sourceforge.net
Which in turn forwards to:
http://downloads.sourceforge.net/project/jedit-plugins/<name>/<version>/<name>-<version>.zip?download=&failedmirror=<mirrorname>.dl.sourceforge.net
Which finally forwards to:
http://<some_random_mirror>.dl.sourceforge.net/project/jedit-plugins/<name>/<version>/<name>-<version>.zip



I have no corrected the pluginlist generation script to construct the
correct new links and updated the mirror list to the current set of
Sourceforge supported mirrors. And whouhou, the plugin installation
speed is incredible, now that it doesn't need to follow 3 redirects and
uses some random mirror.

Regards
Vampire

Alan Ezust schrieb:
> How is it decided when a mirror is added or removed?
> I am having trouble reaching almost all of the US mirror sites for any
> plugins at all.
> All the european ones seem to work though.
>
>   
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security 
> threats, fraudulent activity, and more. Splunk takes this data and makes 
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2

How is it decided when a mirror is added or removed?
I am having trouble reaching almost all of the US mirror sites for any
plugins at all.
All the european ones seem to work though.

Plugin Bugs item #3277545, was opened at 2011-04-06 15:06
Message generated for change (Settings changed) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3277545&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Cedric PELTIER (pcedric)
Assigned to: Matthieu Casanova (kpouer)
Summary: PHPParserPulugin don't handle antislashed u

Initial Comment:
This is a low priority problem: Insert the following code into a php file and it will not be parsed anymore:

echo '\u';

or

// \u

Tested with version 1.3.1 and the latest 1.3.2.

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

>Comment By: SourceForge Robot (sf-robot)
Date: 2011-06-29 14:20

Message:
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: Matthieu Casanova (kpouer)
Date: 2011-06-15 13:30

Message:
Hi, I fixed something in trunk version 1.3.3, the next nightly built should
fix the bug, but since I don't use php often, I hope there are no
regression, could you check it ?

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

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

Bugs item #3338833, was opened at 2011-06-28 01:59
Message generated for change (Comment added) made by rschwenn
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=3338833&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: editor core
Group: minor bug
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: zimbrana ()
Assigned to: Matthieu Casanova (kpouer)
Summary: jEdit +line:xyz has issues

Initial Comment:
Running 'jedit fred.txt +line:10' etc from the command-line only works if the file fred.txt is not already open.

The correct behaviour is for the command-line command, that sets the line number, the jedit functionality that remembers on which line the carat was already on.


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

>Comment By: Robert Schwenn (rschwenn)
Date: 2011-06-28 23:36

Message:
For me it works in all cases, except jEdit isn't running yet when the
command is invoked (see Bug #2978040). Tested with:

jEdit 4.3.3 and 4.4.1
SUN JRE 1.6.0_24
Windows XP SP3


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

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

Plugin Feature Requests item #3257914, was opened at 2011-03-29 09:35
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=3257914&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: Alan Ezust (ezust)
>Assigned to: Eric Le Lay (kerik-sf)
Summary: XML and Hyperlinks plugin

Initial Comment:
Hyperlinks plugin allows you to turn parts of the text editor into clickable hyperlinks.

It would be nice if the XML plugin, once it has parsed an XML document, would make the
<xref linkend="IDREF"> as well as <xi:include href="URLLREF"> into clickable hyperlinks that would open the document in jEdit's editor, at the right place. 

I think only attribute value should be hyperlinked, not the entire element.



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

>Comment By: Alan Ezust (ezust)
Date: 2011-06-28 09:59

Message:
assigning to eric le lay. Please ask kpouer for help from the hyperlinks
side.


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

Comment By: Alan Ezust (ezust)
Date: 2011-03-29 13:14

Message:
The URLs in an xi:include can be relative paths without any ./ or http://
prefix. Which is why they are not currently picked up by the hyperlinks
plugin.

We need to use the context of the element to decide whether it is a url to
look at.
You can look at jEdit trunk users-guide for examples of <xi:includes as
well as <xref linkend= for testing. 
(as well as simpler example docs in the xml plugin testcases directory).


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

Comment By: Matthieu Casanova (kpouer)
Date: 2011-03-29 13:03

Message:
Very good idea, if the xi:include contains an url (like http://something)
the Hyperlinks plugin should already work, for the idref there is a little
more work, I can help the one who will try to implement that, it is really
easy to do I think.

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

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

Bugs item #3323868, was opened at 2011-06-21 13:39
Message generated for change (Comment added) made by vampire0
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=3323868&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: None
Group: minor bug
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Ben Golding (bengolding)
>Assigned to: Björn Kautler (vampire0)
Summary: jedit script should use ${JAVA_HOME}

Initial Comment:
Bug in launcher shell script (Linux only affected).

$JAVA_HOME should be ${JAVA_HOME}   (2 instances)
$DEFAULT_JAVA_HOME should be ${DEFAULT_JAVA_HOME}

I believe this is in line with best practices and avoids a potential issue if the user sets e.g. $JAVA or $DEFAULT

-----
jEdit 4.4.1
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
RedHat Enterprise Linux 4.0 U8

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

>Comment By: Björn Kautler (vampire0)
Date: 2011-06-28 03:00

Message:
Hi Ben,

if a user sets $JAVA this doesn't influence the script at all (just tried
it to be sure).
The problem if not using {} is the other way around, like further down in
the jEdit launch script.
If you write "-Xmx$JAVA_HEAP_MAX_SIZEM" bash searches for
JAVA_HEAP_MAX_SIZEM and no substring of it, that is why there {} are used
and it actually is "-Xmx${JAVA_HEAP_MAX_SIZE}M".

But just in case there are other shells that behave differently I changed
the usages to include the {}.
Anyway thanks for your report which just made me see that the Java
installer actually dynamically creates a completely different *nix launcher
script than we use usually. I also fixed this now.

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

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

Bugs item #3338833, was opened at 2011-06-27 23:59
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=3338833&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: editor core
Group: minor bug
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: zimbrana ()
Assigned to: Matthieu Casanova (kpouer)
Summary: jEdit +line:xyz has issues

Initial Comment:
Running 'jedit fred.txt +line:10' etc from the command-line only works if the file fred.txt is not already open.

The correct behaviour is for the command-line command, that sets the line number, the jedit functionality that remembers on which line the carat was already on.


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

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

Awesome! Will you be putting in a release request fairly soon?

Dale



On Sun, Jun 26, 2011 at 12:20 PM, Eric Le Lay <
ker...@us...> wrote:

> Hi all,
>
> I've been working on JUnitPlugin, to let it run junit-4
> (annotation-driven) tests.
> It's at the point where everything more or less works and I committed
> the changes.
>
> Also, by packaging the Fest testing framework in a jar and dropping it
> in .jedit/jars with its dependencies,
> one can run unit tests for jEdit plugins (e.g. XMLPlugin) inside an
> existing jEdit instance.
>
> - run these 2 commands in Beanshell :
> System.setProperty("test_data", "PATH_TO_TEST_DATA_DIRECTORY")
> org.gjt.sp.jedit.testframework.TestUtils.setStandaloneMode(false)
>
> - add the test/classes directory to junit claspath in current project
> (ProjectViewer)
>
> - you should be able to pick a test in junit dockable and run it...
>
> Cheers,
> Eric
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> --
> -----------------------------------------------
> jEdit Developers' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>

Hi all,

I've been working on JUnitPlugin, to let it run junit-4
(annotation-driven) tests.
It's at the point where everything more or less works and I committed
the changes.

Also, by packaging the Fest testing framework in a jar and dropping it
in .jedit/jars with its dependencies,
one can run unit tests for jEdit plugins (e.g. XMLPlugin) inside an
existing jEdit instance.

- run these 2 commands in Beanshell :
System.setProperty("test_data", "PATH_TO_TEST_DATA_DIRECTORY")
org.gjt.sp.jedit.testframework.TestUtils.setStandaloneMode(false)

- add the test/classes directory to junit claspath in current project
(ProjectViewer)

- you should be able to pick a test in junit dockable and run it...

Cheers,
Eric

Plugin Bugs item #3216494, was opened at 2011-03-16 15:52
Message generated for change (Comment added) made by kerik-sf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3216494&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: https://www.google.com/accounts ()
Assigned to: Eric Le Lay (kerik-sf)
Summary: CPU 100% when parsing XML with SchemaLocation

Initial Comment:
When I try to process the attached XML file using the XML and Sidekick plugin the CPU goes to %100.  This occurs just after being prompted to download the schema from the website.  If I remove the SchemaLocation property the application does not use 100% of CPU and completes processing.

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

>Comment By: Eric Le Lay (kerik-sf)
Date: 2011-06-26 19:57

Message:
it's due to a recursive if element.
XSDSchemaToCompletion tries to unfold it indefinitely.
II had a similar pb with rng schemas.
minimal test-data added in r19632

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

Comment By: Eric Le Lay (kerik-sf)
Date: 2011-06-16 20:02

Message:
interesting : there's something in the XSD which makes the plugin spin...
location of the xsd: http://nant.sf.net/release/0.85/nant.xsd


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

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

Sorry, please forget it. I rebuilt jEdit and now everything works okay.
Probably some inconsistent build. Don't know what could have caused this,
but I don't have time to check now.

Shlomy

On Sun, Jun 26, 2011 at 9:33 AM, Shlomy Reinstein <sre...@gm...>wrote:

> Hi,
>
> I am using the trunk version of jedit, and encountered a new bug that
> didn't exist before: If you run Hypersearch, then save the buffer, the
> hypersearch results no longer work (i.e. no longer jump to the right
> location in the code).
> Any idea when this bug was introduced? It seems like the buffer positions
> stored in the hypersearch results are wrong after saving the buffer.
>
> Thanks,
> Shlomy
>

Hi,

I am using the trunk version of jedit, and encountered a new bug that didn't
exist before: If you run Hypersearch, then save the buffer, the hypersearch
results no longer work (i.e. no longer jump to the right location in the
code).
Any idea when this bug was introduced? It seems like the buffer positions
stored in the hypersearch results are wrong after saving the buffer.

Thanks,
Shlomy

I tried your suggestion and immediately see nicer text in the window icons,
so I applied it to trunk. Thanks!
Nevermind about filing the patch.

Hi,

On Sat, Jun 25, 2011 at 1:17 PM, Makarius <mak...@sk...> wrote:

> This is a small amendment to a small visual glitch in jEdit and Java 6.
>
> When I got first exposed to jEdit some years ago, I still had Java 5 on
> most machines.  Java 6 made the anti-aliased text display look very bad,
> especially on Linux and Windows.  The fractional font metrics option
> turned out to be the reason for that, and it is better switched off for
> the main text area.
>
> Despite that, the icons of the dockable window manager remain blurred on
> most platforms.  Just last week I learned about the meaning of
> FontRenderContext and its remaining occurrence with fractional metrics in
> PanelWindowContainer.RotatedTextIcon.
>
> So what I propose, now that jedit-4.4.1 assumes Java 6 uniformly, is to do
> it like this:
>
> --- 4.4.1/jEdit/org/gjt/sp/jedit/gui/PanelWindowContainer.java  2011-06-21
> 01:28:56.000000000 +0200
> +++ 4.4.1/jEdit-patched/org/gjt/sp/jedit/gui/PanelWindowContainer.java
> 2011-06-22 16:18:43.000000000 +0200
> @@ -646,7 +646,7 @@
>                        this.font = font;
>
>                        FontRenderContext fontRenderContext
> -                               = new FontRenderContext(null,true,true);
> +                               = new FontRenderContext(null,true,false);
>                        glyphs =
> font.createGlyphVector(fontRenderContext,text);
>                        width = (int)glyphs.getLogicalBounds().getWidth() +
> 4;
>                        //height =
> (int)glyphs.getLogicalBounds().getHeight();
>
>
Please submit a patch to the jedit-patches tracker about this.


>
> This should improve the first visual encounter to jEdit, since the
> dockable icons come out crisp and clear, as in the older screenshots from
> http://www.jedit.org/index.php?page=screenshots that were still on Java 5.
> (Minor disadvantage is that the rotate font might get scaled non-uniformly
> in x and y direction.)
>
>
> One might also go as far as discouraging the "fractional metrics" option
> for Text Area options.  The tooltip sounds too positive about it: "for
> better smooth of text display".  When users try that it might take them
> quite long to rediscover the problem.
>

Actually, it's the label that says that in parantheses,
but the tooltip actually says "not recommended with subpixel antialiasing".
I am the one who put the tooltip there, because I agree with you about that.

Also, if you try 4.5 you'll notice that there are more subpixel antialiasing
modes supported.

PS: Regarding your other comments about the jEdit text area, I am not really
familiar with those classes so I can't comment right now, but I am very
happy to see that there are other developers out there who are looking at
ways to improve some of this legacy code. Please submit other patches to the
patches tracker and after you've had a few accepted, you can join the
project and even commit directly to the trunk.

Regards,


Alan Ezust

This is a small amendment to a small visual glitch in jEdit and Java 6.

When I got first exposed to jEdit some years ago, I still had Java 5 on 
most machines.  Java 6 made the anti-aliased text display look very bad, 
especially on Linux and Windows.  The fractional font metrics option 
turned out to be the reason for that, and it is better switched off for 
the main text area.

Despite that, the icons of the dockable window manager remain blurred on 
most platforms.  Just last week I learned about the meaning of 
FontRenderContext and its remaining occurrence with fractional metrics in 
PanelWindowContainer.RotatedTextIcon.

So what I propose, now that jedit-4.4.1 assumes Java 6 uniformly, is to do 
it like this:

--- 4.4.1/jEdit/org/gjt/sp/jedit/gui/PanelWindowContainer.java	2011-06-21 
01:28:56.000000000 +0200
+++ 4.4.1/jEdit-patched/org/gjt/sp/jedit/gui/PanelWindowContainer.java 
2011-06-22 16:18:43.000000000 +0200
@@ -646,7 +646,7 @@
  			this.font = font;

  			FontRenderContext fontRenderContext
-				= new FontRenderContext(null,true,true);
+				= new FontRenderContext(null,true,false);
  			glyphs = font.createGlyphVector(fontRenderContext,text);
  			width = (int)glyphs.getLogicalBounds().getWidth() + 4;
  			//height = (int)glyphs.getLogicalBounds().getHeight();


This should improve the first visual encounter to jEdit, since the 
dockable icons come out crisp and clear, as in the older screenshots from 
http://www.jedit.org/index.php?page=screenshots that were still on Java 5. 
(Minor disadvantage is that the rotate font might get scaled non-uniformly 
in x and y direction.)


One might also go as far as discouraging the "fractional metrics" option 
for Text Area options.  The tooltip sounds too positive about it: "for 
better smooth of text display".  When users try that it might take them 
quite long to rediscover the problem.


 	Makarius

Patches item #3332052, was opened at 2011-06-25 15:58
Message generated for change (Tracker Item Submitted) made by hunteke
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300588&aid=3332052&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: general
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kevin Hunter (hunteke)
Assigned to: Nobody/Anonymous (nobody)
Summary: Additional mode for CPlex LP files

Initial Comment:
Please find attached a patch (against r19629) to add CPlex LP files to jEdit's default set of known modes.

Here are some quick references for those who may not know what a linear program (LP) or CPLex (solver) are:

http://en.wikipedia.org/wiki/Optimization_(mathematics)
http://en.wikipedia.org/wiki/CPLEX
http://lpsolve.sourceforge.net/5.0/CPLEX-format.htm
http://en.wikibooks.org/wiki/GLPK/Interoperability

Perhaps ironically, when implementing this sucker, the more helpful source of information was the GLPK code.  Go open source.

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

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

As explained before, I have my own version of token marking and text 
painting (now for jedit-4.4.1).  The following is about some fine points 
of text and caret painting that I've noticed when implementing this in 
Scala: 
http://isabelle.in.tum.de/repos/isabelle/file/bf7400573617/src/Tools/jEdit/src/text_area_painter.scala

Since I don't know much Java, I need to explain things in terms of Scala. 
I hope this can be understood informally as "pseudo-code" for a 
corresponding Java program, for people who are not working regularly with 
Scala.


* Generally, the architecture of TextAreaPainter is easy to extend: there 
are several layers, and the jEdit default setup uses just the same 
mechanisms that are available to plugins as well (operations around 
TextAreaExtension).  Two small things have required some workarounds on my 
side, though.

(1) Inner classes TextAreaPainter.PaintText and
   TextAreaPainter.PaintCaret are private, which means in order to
   remove them one needs to play untyped tricks with reflection:

   private def pick_extension(name: String): TextAreaExtension =
   {
     text_area.getPainter.getExtensions.iterator.
       filter(x => x.getClass.getName == name).toList
     match {
       case List(x) => x
       case _ => error("Expected exactly one " + name)
     }
   }

   private val orig_text_painter =
     pick_extension("org.gjt.sp.jedit.textarea.TextAreaPainter$PaintText")


   This might look like a slight abuse of TextAreaPainter.getExtensions.
   If TextAreaPainter would make the standard extensions publicly
   available as objects, one could remove them in a statically
   typed way.


(2) The object caretExtension (class PaintCaret) is removed/added at each
   propertiesChanged event, since it might jump between layers:
   BLOCK_CARET_LAYER vs. CARET_LAYER.  (Does anybody know the reasons for
   these different layers of thin line vs. rectangle caret?  I reckon that
   one could always paint over or under the text layer, say.)

   This means I could not remove the standard caret extension reliably.
   Instead I added my own extensions just before and after the usual caret
   layers to mask its effect via clipping on the gfx context.  (If any
   other plugin installs anything tere, it will be masked as well.)
   I also had to ignore the blink feature, because that field is private.

   BTW, the deeper reason why I wanted my own caret painter is this: using
   alternative font styles (notably sub- and superscript), I wanted to have
   precise visual feedback cerning the character metrics of the caret
   position, not just a static line or rectangle (block caret).  It also
   helps for non-proportional fonts, especially long mathematical arrows.

   So the caret painting moved into my text painter, using
   java.awt.font.TextAttribute.SWAP_COLORS on suitable
   java.text.AttributedString.  Clipping ensures that the standard
   caret does not interfere with it.


(3) Precise line boundary.  Painting with exotic font styles or reverse
   text has lead to some surprises concerning default Java font metrics.
   The basic model of TextArea painting seems to be that each line can be
   re-painted independently, so they must be disjoint in the gfx view.
   Some small overshots or undershots would produce ugly residual spots
   when moving the caret between lines, for example.  (I have also seen
   this with official jEdit text painting and OpenJDK 6, with its lack of
   proper Graphics2D.)

   So what I did is to have the line text painter introduce a temporay clip
   for the precise line height according to jEdit:

   gfx.clipRect(x0, y + line_height * i, Integer.MAX_VALUE, line_height)
   ...
   gfx.drawString(...)

   See also
   http://isabelle.in.tum.de/repos/isabelle/file/bf7400573617/src/Tools/jEdit/src/text_area_painter.scala#l275
   for the greater context of this code.


   So one might consider fine-tuning of the standard TextArea painter:

     * Either do the clipping only for TextAreaPainter.PaintText
       individually.  (It might be actually relevant in jedit-4.4.1 with
       its new font substitution scheme, since alien fonts with slightly
       different metrics may be painted over the original line layout in
       unexpected ways.)

     * Or do the clipping uniformly for the default implementation of
       TextAreaExtension.paintScreenLineRange, just before and after the
       invocation of the user-provided implementations of paintInvalidLine
       and paintValidLine.

       This would leave the general paintScreenLineRange entry point open
       for advanced plugins, but the default would keep away these worries
       from clients.

Anyway, I think TextArea with its flexible layered painting mechanism is 
one of the assets of jEdit.  At a very early stage of the project, I had a 
student trying to make anything like that with Netbeans, but he failed 
miserably on all the private/final stuff in their slightly over-engineered 
architecture.  I am much more comfortable with the jEdit code base now.


 	Makarius

Feature Requests item #3328961, was opened at 2011-06-25 03:02
Message generated for change (Settings changed) made by ru1234
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350588&aid=3328961&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: Mikhail Serov (ru1234)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Default character encoding per path/server regex

Initial Comment:
I work with many remote servers which often have files in different encodings so it's not enough just one global default encoding in this case.
It would be nice to have a possibility to define default encodings for particular severs.
(see also http://community.jedit.org/?q=node/view/4766)

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

Comment By: Mikhail Serov (ru1234)
Date: 2011-06-25 05:44

Message:
ezust, you're right, particularly about line separator (I forgot about it).

>From other hand, different charsets are rare when on the same machine. It
is much more hot for remote servers, so I would put "path/server" in the
topic.


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

Comment By: Alan Ezust (ezust)
Date: 2011-06-25 05:39

Message:
Perhaps "path regex" makes more sense than "server" since server only means
something when you are using the FTP plugin.
A mapping of path regexes to encodings would be quite convenient. 
Perhaps that should also include line separator character.




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

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

Feature Requests item #3328961, was opened at 2011-06-25 03:02
Message generated for change (Comment added) made by ru1234
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350588&aid=3328961&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: Mikhail Serov (ru1234)
Assigned to: Nobody/Anonymous (nobody)
Summary: Default character encoding per path regex

Initial Comment:
I work with many remote servers which often have files in different encodings so it's not enough just one global default encoding in this case.
It would be nice to have a possibility to define default encodings for particular severs.
(see also http://community.jedit.org/?q=node/view/4766)

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

Comment By: Mikhail Serov (ru1234)
Date: 2011-06-25 05:44

Message:
ezust, you're right, particularly about line separator (I forgot about it).

>From other hand, different charsets are rare when on the same machine. It
is much more hot for remote servers, so I would put "path/server" in the
topic.


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

Comment By: Alan Ezust (ezust)
Date: 2011-06-25 05:39

Message:
Perhaps "path regex" makes more sense than "server" since server only means
something when you are using the FTP plugin.
A mapping of path regexes to encodings would be quite convenient. 
Perhaps that should also include line separator character.




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

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

Feature Requests item #3328961, was opened at 2011-06-24 16:02
Message generated for change (Settings changed) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350588&aid=3328961&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: Mikhail Serov (ru1234)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Default character encoding per path regex

Initial Comment:
I work with many remote servers which often have files in different encodings so it's not enough just one global default encoding in this case.
It would be nice to have a possibility to define default encodings for particular severs.
(see also http://community.jedit.org/?q=node/view/4766)

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

>Comment By: Alan Ezust (ezust)
Date: 2011-06-24 18:39

Message:
Perhaps "path regex" makes more sense than "server" since server only means
something when you are using the FTP plugin.
A mapping of path regexes to encodings would be quite convenient. 
Perhaps that should also include line separator character.




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

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

Feature Requests item #3328961, was opened at 2011-06-25 03:02
Message generated for change (Tracker Item Submitted) made by ru1234
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350588&aid=3328961&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: Mikhail Serov (ru1234)
Assigned to: Nobody/Anonymous (nobody)
Summary: Default character encoding per server

Initial Comment:
I work with many remote servers which often have files in different encodings so it's not enough just one global default encoding in this case.
It would be nice to have a possibility to define default encodings for particular severs.
(see also http://community.jedit.org/?q=node/view/4766)

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

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

Plugin Bugs item #3325344, was opened at 2011-06-23 13:34
Message generated for change (Tracker Item Submitted) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3325344&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: Marcelo Vanzin (vanza)
Summary: ProjectViewer ignores view titles

Initial Comment:
If I have multiple views and I give them names
  (view - set view title) then projectviewer should use those names to decide which
projects to open in each view when starting up. Currently, it seems to get it reversed.




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

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

Feature Requests item #3324954, was opened at 2011-06-23 07:58
Message generated for change (Comment added) made by bogomips
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350588&aid=3324954&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: BogoMips (bogomips)
Assigned to: Nobody/Anonymous (nobody)
Summary: case-insensitive replace

Initial Comment:
been a jedit user daily for 11 years now!

Feature I'd particularly like is per http://cbloomrants.blogspot.com/2011/06/06-04-11-keep-case.html

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

>Comment By: BogoMips (bogomips)
Date: 2011-06-23 08:07

Message:
I imagine it being a checkbox in the find-replace dialog; its not necessary
for this to work in conjunction with regex replacement - they can be
mutually exclusive

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

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

Feature Requests item #3324954, was opened at 2011-06-23 07:58
Message generated for change (Tracker Item Submitted) made by bogomips
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350588&aid=3324954&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: BogoMips (bogomips)
Assigned to: Nobody/Anonymous (nobody)
Summary: case-insensitive replace

Initial Comment:
been a jedit user daily for 11 years now!

Feature I'd particularly like is per http://cbloomrants.blogspot.com/2011/06/06-04-11-keep-case.html

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

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