jedit-devel Mailing List for jEdit

Plugin Bugs item #3023385, was opened at 2010-06-30 09:26
Message generated for change (Comment added) made by kog13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3023385&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: None
Priority: 5
Private: No
Submitted By: Damien (kog13)
Assigned to: Nobody/Anonymous (nobody)
Summary: Console waits on standard input (C only)

Initial Comment:
I have a basic C program like this:

#include <stdio.h>

int main() {
    char name[20];
    printf("name: ");
    fgets(name, 20, stdin);
    printf("hello, %s\n", name);
    return 0;
}

When this program is run in the console's system shell, no output is displayed until some input is given. So it first appears as if the program is doing nothing, but after typing something in and hitting enter, the rest of the program runs, displaying prompts for input only after the input is already given.

>From what I've noticed, java and c++ programs don't have the same problem. It's only when I compile and try to run a straight C program that it does this.

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

>Comment By: Damien (kog13)
Date: 2010-06-30 15:19

Message:
Never mind, this isn't an issue with console, but with C itself. It won't
flush the output until the buffer fills or the process terminates.

If I can find a way to force C to hand over its input immediately, I'll
make a patch for it, but this doesn't count as a bug.

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

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

Bugs item #2894057, was opened at 2009-11-08 09:48
Message generated for change (Comment added) made by eyebex
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2894057&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: installer
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: red.october (godfall)
Assigned to: Nobody/Anonymous (nobody)
Summary: Can't increase max. heap size beyond 1584MB on Windows 7 x64

Initial Comment:
When installing jEdit 4.3pre18 on Windows 7 64-bit, the jEdit shortcut uses the WOW64 version of javaw.exe (e.g., C:\Windows\SysWOW64\javaw.exe), and by default sets the maximum heap memory to be 192MB.  If I try to change the max. heap memory to be higher than 1584MB, an error message pops up stating:
"Could not create the Java virtual machine".

I assumed this to be a problem of 32-bit vs. 64-bit, so I modified the shortcut to use the 64-bit version of javaw.exe (e.g., C:\Program Files\Java\jdk1.6.0_16\bin\javaw.exe) and this solved the problem.  I think it would make more sense for jEdit to use the 64-bit version of javaw.exe by default on 64-bit OS's.

Cheers,
red.october

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

>Comment By: Sebastian Schuberth (eyebex)
Date: 2010-06-30 16:54

Message:
@godfall: You seem to have both the 64-bit and 32-bit versions of Java
installed. You're right, due to bug #1849762 jEdit is preferring
"GetSysWow64Dir()\javaw.exe" over "GetSystemDir()\javaw.exe" (even in the
current version 4.3.2). But I don't think we need this work-around anymore.
I'll discuss with k_satoda.

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

Comment By: Sebastian Schuberth (eyebex)
Date: 2010-06-30 16:37

Message:
This should have been fixed since jEdit 4.3.1, also see bugs #2356913 and
#2846022.

@godfall: Can you confirm the current jEdit 4.3.2 does not have this
issue?

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

Comment By: red.october (godfall)
Date: 2009-11-08 17:23

Message:
It would make sense that the two binaries are copies of each other in the
case you described, since both the JDK/JRE and the OS are 32-bit.  I'm
using Windows 7 64-bit, so I don't think your issue is relevant.  WOW64 is
a Windows mechanism for allowing 32-bit applications to work on a 64-bit
OS.  Based on some Google searches, it would appear that the error message
means that the JVM could not set the max. heap memory to the specified
value (the value of 1584MB may be system-specific).  This seems consistent
with the behaviour I've seen.  

So I'm saying it doesn't seem to make sense (I would go so far as to say
it is a bug) for jEdit, by default, to select the compatibility version of
the javaw.exe on a system running a 64-bit JDK/JRE with a 64-bit OS.  This
is not what the user expects, and produces problems.

In any case, I checked the two versions of javaw.exe on my system and they
are different sizes.  Using a diff tool, I also verified that their
contents are completely different.

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

Comment By: Robert Schwenn (rschwenn)
Date: 2009-11-08 14:30

Message:
When a SUN JRE/JDK is installed properly on WinXP (32-bit), the actual
javaw.exe resides in C:\Windows\System32\ as a second copy. So, maybe the
two javaw.exe files You mentioned are identical. Could You verify this,
please?

Just a few days ago I found a strange issue, where the launching behavior
of jEdit depends on the path to javaw.exe (tracker item #2890966).


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

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

Bugs item #2894057, was opened at 2009-11-08 09:48
Message generated for change (Comment added) made by eyebex
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2894057&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: installer
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: red.october (godfall)
Assigned to: Nobody/Anonymous (nobody)
Summary: Can't increase max. heap size beyond 1584MB on Windows 7 x64

Initial Comment:
When installing jEdit 4.3pre18 on Windows 7 64-bit, the jEdit shortcut uses the WOW64 version of javaw.exe (e.g., C:\Windows\SysWOW64\javaw.exe), and by default sets the maximum heap memory to be 192MB.  If I try to change the max. heap memory to be higher than 1584MB, an error message pops up stating:
"Could not create the Java virtual machine".

I assumed this to be a problem of 32-bit vs. 64-bit, so I modified the shortcut to use the 64-bit version of javaw.exe (e.g., C:\Program Files\Java\jdk1.6.0_16\bin\javaw.exe) and this solved the problem.  I think it would make more sense for jEdit to use the 64-bit version of javaw.exe by default on 64-bit OS's.

Cheers,
red.october

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

>Comment By: Sebastian Schuberth (eyebex)
Date: 2010-06-30 16:37

Message:
This should have been fixed since jEdit 4.3.1, also see bugs #2356913 and
#2846022.

@godfall: Can you confirm the current jEdit 4.3.2 does not have this
issue?

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

Comment By: red.october (godfall)
Date: 2009-11-08 17:23

Message:
It would make sense that the two binaries are copies of each other in the
case you described, since both the JDK/JRE and the OS are 32-bit.  I'm
using Windows 7 64-bit, so I don't think your issue is relevant.  WOW64 is
a Windows mechanism for allowing 32-bit applications to work on a 64-bit
OS.  Based on some Google searches, it would appear that the error message
means that the JVM could not set the max. heap memory to the specified
value (the value of 1584MB may be system-specific).  This seems consistent
with the behaviour I've seen.  

So I'm saying it doesn't seem to make sense (I would go so far as to say
it is a bug) for jEdit, by default, to select the compatibility version of
the javaw.exe on a system running a 64-bit JDK/JRE with a 64-bit OS.  This
is not what the user expects, and produces problems.

In any case, I checked the two versions of javaw.exe on my system and they
are different sizes.  Using a diff tool, I also verified that their
contents are completely different.

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

Comment By: Robert Schwenn (rschwenn)
Date: 2009-11-08 14:30

Message:
When a SUN JRE/JDK is installed properly on WinXP (32-bit), the actual
javaw.exe resides in C:\Windows\System32\ as a second copy. So, maybe the
two javaw.exe files You mentioned are identical. Could You verify this,
please?

Just a few days ago I found a strange issue, where the launching behavior
of jEdit depends on the path to javaw.exe (tracker item #2890966).


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

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

Bugs item #1732278, was opened at 2007-06-06 20:19
Message generated for change (Comment added) made by eyebex
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1732278&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: installer
Group: minor bug
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Elliotte Rusty Harold (elharo)
>Assigned to: Sebastian Schuberth (eyebex)
Summary: GPL does not require agreement

Initial Comment:
The license agreement screen in the installer is unnecessary. You are not required to accept the GPL in order to install or use a GPL-covered program. As the GPl itself states:


You are not required to accept this License, since you have not
signed it.  However, nothing else grants you permission to modify or
distribute the Program or its derivative works.  These actions are
prohibited by law if you do not accept this License.  Therefore, by
modifying or distributing the Program (or any work based on the
Program), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Program or works based on it.


It is only the normally prohibited act of redistributing the program that requires acceptance of the license agreement, and that acceptance is indicated merely by performing such an act. The clickthrough license screen should be removed.


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

>Comment By: Sebastian Schuberth (eyebex)
Date: 2010-06-30 16:28

Message:
Fixed in trunk rev. 18162.

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

Comment By: Harald Korneliussen (haraldko)
Date: 2007-07-31 10:00

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

How about letting it stand, but let the reject button work just as fine,
possibly with a warning that you are not allowed to redistribute? :-P

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

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

Plugin Bugs item #3023385, was opened at 2010-06-30 09:26
Message generated for change (Tracker Item Submitted) made by kog13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3023385&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: Damien (kog13)
Assigned to: Nobody/Anonymous (nobody)
Summary: Console waits on standard input (C only)

Initial Comment:
I have a basic C program like this:

#include <stdio.h>

int main() {
    char name[20];
    printf("name: ");
    fgets(name, 20, stdin);
    printf("hello, %s\n", name);
    return 0;
}

When this program is run in the console's system shell, no output is displayed until some input is given. So it first appears as if the program is doing nothing, but after typing something in and hitting enter, the rest of the program runs, displaying prompts for input only after the input is already given.

>From what I've noticed, java and c++ programs don't have the same problem. It's only when I compile and try to run a straight C program that it does this.

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

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

Bugs item #2997027, was opened at 2010-05-05 11:43
Message generated for change (Settings changed) made by eyebex
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2997027&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: installer
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Willfon (willfon)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Silent install Windows 7 fails (update InnoSetup to fix)

Initial Comment:
I've created an inf file for silent install:
  jedit431installer.exe /SAVEINF=c:\temp\jedit431installer.inf
which I use for silent install:
  jedit431installer.exe  /LOADINF=c:\temp\jedit431install.inf /VERYSILENT /NOCANDY /LOG=c:\temp\jedit431.log /NORESTART

This fails rather silently with the current log:

2010-05-05 11:23:12.630   Log opened. (Time zone: UTC+02:00)
2010-05-05 11:23:12.630   Setup version: Inno Setup version 5.3.5 (u)
2010-05-05 11:23:12.630   Original Setup EXE: c:\temp\jEdit431\jedit431install.exe
2010-05-05 11:23:12.630   Setup command line: /SL5="$4240048,2490018,151552,c:\temp\jEdit431\jedit431install.exe" /LOADINF=c:\temp\jEdit431\jedit431install.inf /VERYSILENT /NOCANDY /LOG=c:\temp\jedit431.log /NORESTART
2010-05-05 11:23:12.630   Windows version: 6.01.7600  (NT platform: Yes)
2010-05-05 11:23:12.630   64-bit Windows: Yes
2010-05-05 11:23:12.630   Processor architecture: x64
2010-05-05 11:23:12.630   User privileges: Administrative
2010-05-05 11:23:12.645   64-bit install mode: Yes
2010-05-05 11:23:12.661   Created temporary directory: C:\Windows\TEMP\is-GPPGO.tmp
2010-05-05 11:23:12.661   (SysWow64Dir) found javaw.exe: C:\Windows\SysWOW64\javaw.exe
2010-05-05 11:23:12.770   Starting the installation process.
2010-05-05 11:23:12.770   Exception message:
2010-05-05 11:23:12.770   Message box (OK):
                          Not implemented.


Googling for the error message I find:
http://www.bullzip.com/phpBB/viewtopic.php?f=5&t=7334
which states that this is a bug in an old innosetup mentioned here:
http://www.jrsoftware.org/isdl.php


Could you please create a new install file using the patched innosetup?


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

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

Bugs item #3023175, was opened at 2010-06-29 22:36
Message generated for change (Comment added) made by daleanson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=3023175&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: Marcelo Vanzin (vanza)
Assigned to: Nobody/Anonymous (nobody)
Summary: Custom mode properties not sticking

Initial Comment:
This used to work in earlier 4.4pre builds, so it must be some recent change that broke it. Try this:

. create a file called "test.mk" with some random makefile stuff in it, e.g.:

ifeq ($(FOO),bar)
        $(warning Foo!)
endif

all:
        $(error d'oh!)

.PHONY: all

. go to Global Options -> Editing, choose the makefile mode, disable "Use default settings", change file name glob to "{*makefile,*.mk} ".

. close jEdit; look at properties file and see this:

mode.makefile.filenameGlob = {*makefile,*.mk}                                                                                                                                                                       

. start jEdit, .mk file is not highlighted as "makefile". Close jEdit, and you see this in the properties file:

mode.makefile.filenameGlob=*makefile                                                                                                                                                                              

I used to be able to just do a "Reload edit modes" after making the changes to get the new settings to apply. 

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

>Comment By: Dale Anson (daleanson)
Date: 2010-06-30 07:27

Message:
Maybe this will help narrow down the change -- I had jEdit from revision
17840 and was unable to reproduce the problem.  I updated to revision 18161
and now I see the problem.

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

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

Bugs item #3023175, was opened at 2010-06-29 21:36
Message generated for change (Tracker Item Submitted) made by vanza
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=3023175&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: Marcelo Vanzin (vanza)
Assigned to: Nobody/Anonymous (nobody)
Summary: Custom mode properties not sticking

Initial Comment:
This used to work in earlier 4.4pre builds, so it must be some recent change that broke it. Try this:

. create a file called "test.mk" with some random makefile stuff in it, e.g.:

ifeq ($(FOO),bar)
        $(warning Foo!)
endif

all:
        $(error d'oh!)

.PHONY: all

. go to Global Options -> Editing, choose the makefile mode, disable "Use default settings", change file name glob to "{*makefile,*.mk} ".

. close jEdit; look at properties file and see this:

mode.makefile.filenameGlob = {*makefile,*.mk}                                                                                                                                                                       

. start jEdit, .mk file is not highlighted as "makefile". Close jEdit, and you see this in the properties file:

mode.makefile.filenameGlob=*makefile                                                                                                                                                                              

I used to be able to just do a "Reload edit modes" after making the changes to get the new settings to apply. 

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

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

Hi all, I just submitted a patch that adds a textarea option to
increase the spacing between lines of text. If you want to try it out,
attched are 2 patches that fix the Highlight and VoxSpell plugins to
draw correctly with extra spacing. Thanks _matt

Patches item #3023134, was opened at 2010-06-29 22:19
Message generated for change (Tracker Item Submitted) made by voxmea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300588&aid=3023134&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: Matthew Gilbert (voxmea)
Assigned to: Nobody/Anonymous (nobody)
Summary: Adds textarea option to increase spacing between lines

Initial Comment:
Adds a new textarea option to increase the spacing between lines of text. For some, this greatly improves readability (especially with certain fonts).

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

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

Well, this builds fine:

docbook.xsl=/usr/share/sgml/docbook/xsl-stylesheets-1.75.2
docbook.catalog=/usr/share/sgml/docbook/xsl-ns-stylesheets-1.75.2/catalog.xml

This does not:

docbook.xsl=/usr/share/sgml/docbook/xsl-ns-stylesheets-1.75.2
docbook.catalog=/usr/share/sgml/docbook/xsl-ns-stylesheets-1.75.2/catalog.xml


Many errors such as:
[exec] Request for title of element with no title: section
(id="plugin-implement-actions")

BUILD FAILED
/home/scratch/robin/jedit/trunk/build.xml:505: The following error
occurred while executing this line:
/home/scratch/robin/jedit/trunk/build.xml:435: exec returned: 11


I couldn't find anything in /usr/share/xml that looked likely:

/usr/share/xml $ ls -R docbook*
docbook:
simple  slides

docbook/simple:
1.1

docbook/simple/1.1:
sdbcent.mod  sdocbook.css         sdocbookref-custom.dtd
sdbhier.mod  sdocbook-custom.dtd  sdocbookref.dtd
sdbpool.mod  sdocbook.dtd         sinclist.mod

docbook/slides:
3.4.0

docbook/slides/3.4.0:
browser  catalog.xml  graphics  schema  VERSION  xsl

docbook/slides/3.4.0/browser:
ChangeLog           slides-plain.css       xbLibrary.js
CTOCWidget.js       slides-table.css       xbStyle-css.js
overlay.js          slides-w3c.css         xbStyle.js
slides.css          ua.js                  xbStyle-nn4.js
slides-default.css  xbCollapsibleLists.js  xbStyle-not-supported.js
slides-frames.css   xbDebug.js
slides.js           xbDOM.js

docbook/slides/3.4.0/graphics:
active     blank.gif  ChangeLog    inactive  pointer.png  toc
arrow.gif  blank.png  hidetoc.gif  plus.gif  showtoc.gif

docbook/slides/3.4.0/graphics/active:
arr-next.png      but-next.png    nav-home.png  nav-up.png
arr-prev.png      but-prev.png    nav-next.png  w3c-next.png
but-fforward.png  but-rewind.png  nav-prev.png  w3c-prev.png
but-info.png      ChangeLog       nav-toc.png   w3c-toc.png

docbook/slides/3.4.0/graphics/inactive:
but-fforward.png  but-prev.png    nav-home.png  nav-toc.png   w3c-prev.png
but-info.png      but-rewind.png  nav-next.png  nav-up.png    w3c-toc.png
but-next.png      ChangeLog       nav-prev.png  w3c-next.png

docbook/slides/3.4.0/graphics/toc:
bullet.png  ChangeLog  closed.png  open.png

docbook/slides/3.4.0/schema:
ChangeLog  dtd  relaxng

docbook/slides/3.4.0/schema/dtd:
ChangeLog  slides-custom.dtd  slides.dtd  slides-full.dtd  slides.mod

docbook/slides/3.4.0/schema/relaxng:
calstblx.rnc     dbnotnx.mod.rnc  docbookx.rng      slides.mod.rnc
calstblx.rng     dbnotnx.mod.rng  htmltblx.mod.rnc  slides.mod.rng
ChangeLog        dbpoolx.mod.rnc  htmltblx.mod.rng  slides.rnc
dbhierx.mod.rnc  dbpoolx.mod.rng  slides-full.rnc   slides.rng
dbhierx.mod.rng  docbookx.rnc     slides-full.rng

docbook/slides/3.4.0/xsl:
ChangeLog  fo  html  htmlhelp  keynote  svg  xhtml

docbook/slides/3.4.0/xsl/fo:
ChangeLog  plain-titlepage.xml  plain-titlepage.xsl  plain.xsl

docbook/slides/3.4.0/xsl/html:
ChangeLog    flat.xsl      jscript.xsl  param.xsl   slides-common.xsl  w3c.xsl
css.xsl      frames.xsl    param.html   param.xweb  tables.xsl
default.xsl  graphics.xsl  param.xml    plain.xsl   vslides.xsl

docbook/slides/3.4.0/xsl/htmlhelp:
ChangeLog  htmlhelp.xsl

docbook/slides/3.4.0/xsl/keynote:
ChangeLog  default.xsl  xsltsl

docbook/slides/3.4.0/xsl/keynote/xsltsl:
ChangeLog  date-time.xsl  markup.xsl  node.xsl    string.xsl  uri.xsl
cmp.xsl    example.xsl    math.xsl    stdlib.xsl  svg.xsl

docbook/slides/3.4.0/xsl/svg:
ChangeLog  default.xsl

docbook/slides/3.4.0/xsl/xhtml:
ChangeLog    flat.xsl      html2xhtml.xsl  plain.xsl          vslides.xsl
css.xsl      frames.xsl    jscript.xsl     slides-common.xsl  w3c.xsl
default.xsl  graphics.xsl  param.xsl       tables.xsl

docbook5:
schema  stylesheet

docbook5/schema:
dtd  rng  sch  xsd

docbook5/schema/dtd:
5.0

docbook5/schema/dtd/5.0:
catalog.xml  docbook.dtd

docbook5/schema/rng:
5.0

docbook5/schema/rng/5.0:
catalog.xml  docbook.rnc  docbook.rng  docbookxi.rnc  docbookxi.rng

docbook5/schema/sch:
5.0

docbook5/schema/sch/5.0:
catalog.xml  docbook.sch

docbook5/schema/xsd:
5.0

docbook5/schema/xsd/5.0:
catalog.xml  docbook.xsd  xlink.xsd  xml.xsd

docbook5/stylesheet:
upgrade

docbook5/stylesheet/upgrade:
db4-upgrade.xsl


On Fri, Jun 25, 2010 at 5:47 PM, Alan Ezust <ala...@gm...> wrote:
> Hrm. I'm getting strange errors now too.
> It seems the docbook toolchain has evolved a bit since the docs were
> last updated.
> Ticket # 3021478 when it is closed will make the doc building process easier.
> It's something i wanted to do myself when I had the time. But if someone else
> wants to do it first, by all means!
>
>
> On Fri, Jun 25, 2010 at 8:46 AM, Alan Ezust <ala...@gm...> wrote:
>> ok, the xsl-ns-stylesheets package seems to have combined the schema
>> catalog info as well as the stylesheets into one package. Which means
>> you don't need to use those old sgml stylesheets anymore, but instead
>> try to use the one that is under /usr/share/xml/something...
>>
>> It might still work with the old ones, but chances are using the
>> stylesheets that come with the same package as the catalog will be the
>> optimal solution.
>>
>>
>>
>> On Fri, Jun 25, 2010 at 1:56 AM, Robin Neatherway <nea...@gm...> wrote:
>>> Good call Alan.
>>>
>>> This builds without error:
>>> docbook.catalog=/usr/share/sgml/docbook/xsl-ns-stylesheets-1.75.2/catalog.xml
>>>
>>> For this, a Fedora user needs to install the `docbook5-style-xsl` package.
>>>
>>> Let's update the README to reflect that, hopefully it'll save someone
>>> else some time later on.
>>>
>>>
>>> Robin
>>>
>>>
>>> On Thu, Jun 24, 2010 at 9:41 PM, Alan Ezust <ala...@gm...> wrote:
>>>> I think that xsl-ns-stylesheets-1.75.2 might work too, actually. You
>>>> might want to try it and let us know which works best for your
>>>> platform and we will update the build.properties.sample to reflect
>>>> that.
>>>>
>>>>
>>>> On Thu, Jun 24, 2010 at 12:21 PM, Robin Neatherway <nea...@gm...> wrote:
>>>>> Apologies to Alan, here comes another dupe -- I also forgot to change
>>>>> the reply field.
>>>>>
>>>>>
>>>>> I have installed all the docbook and docbook5 packages. Perhaps this
>>>>> older version of docbook is not packaged for Fedora anymore?
>>>>>
>>>>> /usr/share/sgml/docbook/xsl-ns-stylesheets-1.75.2/catalog.xml
>>>>> /usr/share/xml/docbook/slides/3.4.0/catalog.xml
>>>>> /usr/share/xml/docbook5/schema/dtd/5.0/catalog.xml
>>>>> /usr/share/xml/docbook5/schema/rng/5.0/catalog.xml
>>>>> /usr/share/xml/docbook5/schema/sch/5.0/catalog.xml
>>>>> /usr/share/xml/docbook5/schema/xsd/5.0/catalog.xml
>>>>>
>>>>>> On Thu, Jun 24, 2010 at 6:23 PM, Alan Ezust <ala...@gm...> wrote:
>>>>>>> Do not use the "catalog" file. use the "catalog.xml" file instead.
>>>>>>> I just fixed the build.properties.sample to reflect that.
>>>>>>> The old "catalog" file without a file extension is DTD based and it
>>>>>>> seems the current versions of xsltproc when processing things using an
>>>>>>> XSD do not work with these old catalog files anymore.
>>>>>>>
>>>>>>> #debian location:
>>>>>>> docbook.catalog=/usr/share/xml/docbook/schema/dtd/4.4/catalog.xml
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Jun 24, 2010 at 9:39 AM, Robin Neatherway <nea...@gm...> wrote:
>>>>>>>>> The README explicitly says you need 4.4. Besides that it works fine even
>>>>>>>>> with 4.5 despite that error message as you said yourself. Also the
>>>>>>>>> documentation itself is defined as being written in 4.4 what you can see at
>>>>>>>>> the top of those files where the doc type is defined. :-)
>>>>>>>>
>>>>>>>> The README says you need 4.4. In most software, saying you need
>>>>>>>> version X is the same as saying you need version >= X. This is often
>>>>>>>> because the instructions are written when version X is current, and
>>>>>>>> are not updated when version X+1 is released.
>>>>>>>>
>>>>>>>>> The paths are maybe different, but the filenames are not, are they? If the
>>>>>>>>> filenames are not different, a simple filename search should help finding
>>>>>>>>> the correct locations for your OS. You can also tell me where those files
>>>>>>>>> are on Fedora if there are more or less fixed positions if you use the
>>>>>>>>> package manager like in Debian, then I will include those examples in the
>>>>>>>>> build.properties.sample file.
>>>>>>>>
>>>>>>>> In fact they are even different filenames unless I have made a big
>>>>>>>> mistake. I did of course try searching for the filenames mentioned in
>>>>>>>> build.properties.sample after installing the Fedora docbook packages.
>>>>>>>>
>>>>>>>> docbook.xsl=/usr/share/sgml/docbook/xsl-stylesheets
>>>>>>>> docbook.catalog=/usr/share/sgml/docbook/xml-dtd-4.4-1.0-48.fc12/catalog
>>>>>>>>
>>>>>>>> Perhaps now you can appreciate my difficulty?
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>>>>>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>>>>>>> lucky parental unit.  See the prize list and enter to win:
>>>>>>>> http://p.sf.net/sfu/thinkgeek-promo
>>>>>>>> --
>>>>>>>> -----------------------------------------------
>>>>>>>> jEdit Developers' List
>>>>>>>> jEd...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>>>> lucky parental unit.  See the prize list and enter to win:
>>>>> http://p.sf.net/sfu/thinkgeek-promo
>>>>> --
>>>>> -----------------------------------------------
>>>>> jEdit Developers' List
>>>>> jEd...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>>>>>
>>>>
>>>
>>
>

Plugin Bugs item #3022454, was opened at 2010-06-28 11:44
Message generated for change (Settings changed) made by daleanson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3022454&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: Eric Le Lay (kerik-sf)
>Assigned to: Dale Anson (daleanson)
Summary: PMDPlugin 3.2 ignores buffer encoding

Initial Comment:
It uses the platform's encoding and it will then fail on accented character constants.
(tested on winxp and mac os x)

Please find attached a file demonstrating that.
 - Open it with utf-8 encoding (make sure that accented characters show up correctly)
 - invoke pmd-check-current-buffer
Error log : 
19:38:32 [AWT-EventQueue-0] [error] PMDJEditPlugin: Error while processing /Users/elelay/Desktop/TestClass.java:
19:38:32 [AWT-EventQueue-0] [error] PMDJEditPlugin: Error while processing /Users/elelay/Desktop/TestClass.java
19:38:32 [AWT-EventQueue-0] [error] PMDJEditPlugin: net.sourceforge.pmd.ast.TokenMgrError: Lexical error at line 8, column 32.  Encountered: "\u00a9" (169), after : "\'\u221a"
19:38:32 [AWT-EventQueue-0] [error] PMDJEditPlugin: net.sourceforge.pmd.PMDException: Error while processing /Users/elelay/Desktop/TestClass.java
19:38:32 [AWT-EventQueue-0] [error] PMDJEditPlugin:  at net.sourceforge.pmd.PMD.processFile(PMD.java:132)
19:38:32 [AWT-EventQueue-0] [error] PMDJEditPlugin:  at net.sourceforge.pmd.PMD.processFile(PMD.java:75)
19:38:32 [AWT-EventQueue-0] [error] PMDJEditPlugin:  at net.sourceforge.pmd.PMD.processFile(PMD.java:210)
19:38:32 [AWT-EventQueue-0] [error] PMDJEditPlugin:  at net.sourceforge.pmd.jedit.PMDJEditPlugin.instanceCheck(PMDJEditPlugin.java:206)
19:38:32 [AWT-EventQueue-0] [error] PMDJEditPlugin:  at net.sourceforge.pmd.jedit.PMDJEditPlugin.check(PMDJEditPlugin.java:263)

Cause:
net/sourceforge/pmd/jedit/PMDJEditPlugin.java, line 216
should use buffer.getProperty("encoding") instead of System.getProperty("file.encoding")

Work-around:
in the beanshell console, invoke System.setProperty("file.encoding","UTF-8")

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

>Comment By: Dale Anson (daleanson)
Date: 2010-06-28 11:55

Message:
Nice bug report, thanks!

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

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

Plugin Bugs item #3022454, was opened at 2010-06-28 19:44
Message generated for change (Tracker Item Submitted) made by kerik-sf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3022454&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: Eric Le Lay (kerik-sf)
Assigned to: Nobody/Anonymous (nobody)
Summary: PMDPlugin 3.2 ignores buffer encoding

Initial Comment:
It uses the platform's encoding and it will then fail on accented character constants.
(tested on winxp and mac os x)

Please find attached a file demonstrating that.
 - Open it with utf-8 encoding (make sure that accented characters show up correctly)
 - invoke pmd-check-current-buffer
Error log : 
19:38:32 [AWT-EventQueue-0] [error] PMDJEditPlugin: Error while processing /Users/elelay/Desktop/TestClass.java:
19:38:32 [AWT-EventQueue-0] [error] PMDJEditPlugin: Error while processing /Users/elelay/Desktop/TestClass.java
19:38:32 [AWT-EventQueue-0] [error] PMDJEditPlugin: net.sourceforge.pmd.ast.TokenMgrError: Lexical error at line 8, column 32.  Encountered: "\u00a9" (169), after : "\'\u221a"
19:38:32 [AWT-EventQueue-0] [error] PMDJEditPlugin: net.sourceforge.pmd.PMDException: Error while processing /Users/elelay/Desktop/TestClass.java
19:38:32 [AWT-EventQueue-0] [error] PMDJEditPlugin:  at net.sourceforge.pmd.PMD.processFile(PMD.java:132)
19:38:32 [AWT-EventQueue-0] [error] PMDJEditPlugin:  at net.sourceforge.pmd.PMD.processFile(PMD.java:75)
19:38:32 [AWT-EventQueue-0] [error] PMDJEditPlugin:  at net.sourceforge.pmd.PMD.processFile(PMD.java:210)
19:38:32 [AWT-EventQueue-0] [error] PMDJEditPlugin:  at net.sourceforge.pmd.jedit.PMDJEditPlugin.instanceCheck(PMDJEditPlugin.java:206)
19:38:32 [AWT-EventQueue-0] [error] PMDJEditPlugin:  at net.sourceforge.pmd.jedit.PMDJEditPlugin.check(PMDJEditPlugin.java:263)

Cause:
net/sourceforge/pmd/jedit/PMDJEditPlugin.java, line 216
should use buffer.getProperty("encoding") instead of System.getProperty("file.encoding")

Work-around:
in the beanshell console, invoke System.setProperty("file.encoding","UTF-8")

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

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

Feature Requests item #3022440, was opened at 2010-06-28 12:07
Message generated for change (Tracker Item Submitted) made by kog13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350588&aid=3022440&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: Damien (kog13)
Assigned to: Nobody/Anonymous (nobody)
Summary: Default Bufferset Scope

Initial Comment:
I think the default bufferset scope should be set to view, not global. Most programs create distinctions between windows, and having one program's window affect another one is pretty rare. This can cause confusion when global is set as default, and those who prefer a global bufferset are more likely to know what it is and how to change it.

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

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

Plugin Feature Requests item #3022432, was opened at 2010-06-28 11:47
Message generated for change (Tracker Item Submitted) made by kog13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=3022432&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: Damien (kog13)
Assigned to: Nobody/Anonymous (nobody)
Summary: Console: compile and run current project

Initial Comment:
I'm working on making a number of changes to ProjectBuilder, which was intended to be my original solution to compiling and running projects instead of buffers (ant over javac, for example). But it seemed rather limited and inaccessible, so my upcoming changes to the plugin will have it be more template-oriented, where actions such as build and run will be more accessible for users and versatile for template-writers, but limits the ability to compile and run a project that isn't defined by a template.

As a solution, I suggest that 'compile current project' and 'run current project' actions be implemented in Console, with compilers and interpreters being chosen in a project's properties dialog. Console already has an optional dependency on ProjectViewer, and the actions themselves would be almost identical to the existing compile and run commands, but based on active project rather than edit mode. So, for example, a java project can still be compiled even if the user is currently editing an xml file. And it would be easy enough to do a check for ProjectViewer in each of these actions, so it can remain an optional dependency and not hinder the ability to use Console without ProjectViewer.

Ultimately, the solution I tried to implement in ProjectBuilder was incredibly limited compared to Console's existing commando system, which is something I would like to expose on a per-project basis.

I know that Console is currently in a state of between-maintainers, so I can volunteer to do the actual work of implementing my idea, but I wanted to make my intentions clear and get some feedback.

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

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

Patches item #2820969, was opened at 2009-07-13 21:20
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300588&aid=2820969&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: Closed
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Milutin Jovanovi (mikij)
Assigned to: Eric Le Lay (kerik-sf)
Summary: SOCKS proxy accessing wrong property

Initial Comment:
My first ever patch, so here it goes...

When initializing, jEdit searches for wrong property "socks.enabled" instead of "firewall.socks.enabled". Therefore, SOCKS proxy was never getting enabled. BTW, properties window correctly sets "firewall.socks.enabled" property, so it is only the case that property usage is wrong.

BTW, I strongly suggest not using magic strings, but rather public static final strings for all property names...

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

>Comment By: SourceForge Robot (sf-robot)
Date: 2010-06-28 02: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: 2010-06-13 08:56

Message:
committed in r18054
Thanks for your patch !

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

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

Bugs item #2929304, was opened at 2010-01-10 16:29
Message generated for change (Comment added) made by shlomy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2929304&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: search and replace
Group: None
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Shlomy Reinstein (shlomy)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'Find' button disable when searching in selection

Initial Comment:
Sometimes, when a range of text is selected (single range selection mode), the 'Find' button in the Search & Replace dialog is disabled, so I cannot search the selection. The button becomes enabled when I switch to buffer search (instead of selection search).
Attached a screenshot that shows this.

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

>Comment By: Shlomy Reinstein (shlomy)
Date: 2010-06-27 23:53

Message:
I think so, yes. The reason is that using "Find" will select the text that
it found, causing the previously selected text (in which you searched) to
be deselected, so you won't be able to do "find next" within the
previously-selected text. Therefore, only hypersearch is reasonable in this
case.

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

Comment By: Anshal Shukla (goodfella1408)
Date: 2010-06-27 23:49

Message:
If the HyperSearch check box is selected in "Search And Replace" (in
Selection search ) , the Find button becomes enabled again.The jedit user
guide mentions this as the default behavior.Chapter 5>Search And
Replace>Searching For Text >line5 says,

"If the selection spans a line break, the Search in Selection and
HyperSearch buttons will be pre-selected, and the search string field will
be initially blank. "

Does this mean that Selection search was expected to work in the
HyperSearch  mode only, previously?

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

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

Bugs item #2929304, was opened at 2010-01-10 19:59
Message generated for change (Comment added) made by goodfella1408
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2929304&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: search and replace
Group: None
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Shlomy Reinstein (shlomy)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'Find' button disable when searching in selection

Initial Comment:
Sometimes, when a range of text is selected (single range selection mode), the 'Find' button in the Search & Replace dialog is disabled, so I cannot search the selection. The button becomes enabled when I switch to buffer search (instead of selection search).
Attached a screenshot that shows this.

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

Comment By: Anshal Shukla (goodfella1408)
Date: 2010-06-28 02:19

Message:
If the HyperSearch check box is selected in "Search And Replace" (in
Selection search ) , the Find button becomes enabled again.The jedit user
guide mentions this as the default behavior.Chapter 5>Search And
Replace>Searching For Text >line5 says,

"If the selection spans a line break, the Search in Selection and
HyperSearch buttons will be pre-selected, and the search string field will
be initially blank. "

Does this mean that Selection search was expected to work in the
HyperSearch  mode only, previously?

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

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

Bugs item #2960128, was opened at 2010-02-27 17:17
Message generated for change (Comment added) made by goodfella1408
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2960128&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: keyboard / mouse
Group: minor bug
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Marco Bright Caminati (marco-caminati)
Assigned to: Nobody/Anonymous (nobody)
Summary: Jedit steals keyboard focus from window manager.

Initial Comment:
Start jedit afresh. Press Alt-v (view menu unrolls). Press F12. From now on, jedit preys all keystrokes
from window manager (except direct xorgs Ctrl-Alt-Fn or Ctrl-Alt-backspace keypresses).
You have either to use mouse or press Ctrl-q (without necessarily completing quitting afterwards)
to  get out of this. This is annoying for mouse-intolerant people.

Environment:
Linux slax 2.6.27.27
xorg server 1.4.2
Window Managers: tested both with Fluxbox 1.0.0 and KDE 3.5.10
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
jedit 4.3.1 stable

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

Comment By: Anshal Shukla (goodfella1408)
Date: 2010-06-28 01:37

Message:
added a patch for resolving this -  Artifact : 3022084.
Please read the "Matches" in point 6 in the comment below as "Markers"

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

Comment By: Anshal Shukla (goodfella1408)
Date: 2010-06-28 01:20

Message:
I did my testing on jedit 4.4 pre 1-

1. Start jEdit
2. Press Alt-v. The View menu expands.
3. Press F12. The main text area gets the focus and that the
View menu is still expanded.
4. There is no way to close the View menu.
5.Notice that keyboard shortcuts like ctrl+shift+back,ctrl+c,ctrl+v (for
selecting text, copying and pasting ) etc are still working in the text
area.
6.Press Alt+M .The Matches menu expands and view menu (from step 3)
closes.But we cannot navigate in the Matches menu and the focus still rests
with the text area.

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

Comment By: Dale Anson (daleanson)
Date: 2010-02-28 01:49

Message:
I also have F12 set to the default "Toggle Docked Areas".  My testings are
on some version of jEdit after 4.3 final, but not the latest from svn and I
have a pile of plugins installed.

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

Comment By: Marco Bright Caminati (marco-caminati)
Date: 2010-02-28 00:11

Message:
@shlomy: F12 is the default action "Toggle Docked Areas".
By the way, my testings are done on a freshly download and untarred jedit,
on a rebooted pc (which, here on slax, means a maiden machine).

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

Comment By: Dale Anson (daleanson)
Date: 2010-02-27 22:08

Message:
I see the same problem, and it is annoying.  Here's a little more detail on
how to reproduce:

1. Start jEdit
2. Press Alt-v.  See the View menu expand.
3. Press F12.  See that the main text area gets the focus and that the
View menu is still expanded.
4. Notice there is no way to close the View menu, or do anything else for
that matter, other than type in the main text area.  The only way out that
I can find is to click the mouse button.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2010-02-27 18:02

Message:
What's F12? In jEdit, all shortcuts are customizable. If F12 is mapped to a
jEdit action, you can find it easily by opening the action bar (usually
Ctrl+Enter) and checking the history items to find the action name.

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

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

Patches item #3022084, was opened at 2010-06-28 01:31
Message generated for change (Tracker Item Submitted) made by goodfella1408
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300588&aid=3022084&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: Anshal Shukla (goodfella1408)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patch for Bug 2960128

Initial Comment:
Added a new method closeAllMenus() in View.java which is invoked from  DockableWindowManager.toggleDockAreas().This closes the pop up menu (if it is open) when F12 key(for toggling dock areas) is pressed .Also this facilitates proper focus traversal to the menu bar thereafter.

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

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

Bugs item #2960128, was opened at 2010-02-27 17:17
Message generated for change (Comment added) made by goodfella1408
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2960128&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: keyboard / mouse
Group: minor bug
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Marco Bright Caminati (marco-caminati)
Assigned to: Nobody/Anonymous (nobody)
Summary: Jedit steals keyboard focus from window manager.

Initial Comment:
Start jedit afresh. Press Alt-v (view menu unrolls). Press F12. From now on, jedit preys all keystrokes
from window manager (except direct xorgs Ctrl-Alt-Fn or Ctrl-Alt-backspace keypresses).
You have either to use mouse or press Ctrl-q (without necessarily completing quitting afterwards)
to  get out of this. This is annoying for mouse-intolerant people.

Environment:
Linux slax 2.6.27.27
xorg server 1.4.2
Window Managers: tested both with Fluxbox 1.0.0 and KDE 3.5.10
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
jedit 4.3.1 stable

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

Comment By: Anshal Shukla (goodfella1408)
Date: 2010-06-28 01:20

Message:
I did my testing on jedit 4.4 pre 1-

1. Start jEdit
2. Press Alt-v. The View menu expands.
3. Press F12. The main text area gets the focus and that the
View menu is still expanded.
4. There is no way to close the View menu.
5.Notice that keyboard shortcuts like ctrl+shift+back,ctrl+c,ctrl+v (for
selecting text, copying and pasting ) etc are still working in the text
area.
6.Press Alt+M .The Matches menu expands and view menu (from step 3)
closes.But we cannot navigate in the Matches menu and the focus still rests
with the text area.

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

Comment By: Dale Anson (daleanson)
Date: 2010-02-28 01:49

Message:
I also have F12 set to the default "Toggle Docked Areas".  My testings are
on some version of jEdit after 4.3 final, but not the latest from svn and I
have a pile of plugins installed.

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

Comment By: Marco Bright Caminati (marco-caminati)
Date: 2010-02-28 00:11

Message:
@shlomy: F12 is the default action "Toggle Docked Areas".
By the way, my testings are done on a freshly download and untarred jedit,
on a rebooted pc (which, here on slax, means a maiden machine).

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

Comment By: Dale Anson (daleanson)
Date: 2010-02-27 22:08

Message:
I see the same problem, and it is annoying.  Here's a little more detail on
how to reproduce:

1. Start jEdit
2. Press Alt-v.  See the View menu expand.
3. Press F12.  See that the main text area gets the focus and that the
View menu is still expanded.
4. Notice there is no way to close the View menu, or do anything else for
that matter, other than type in the main text area.  The only way out that
I can find is to click the mouse button.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2010-02-27 18:02

Message:
What's F12? In jEdit, all shortcuts are customizable. If F12 is mapped to a
jEdit action, you can find it easily by opening the action bar (usually
Ctrl+Enter) and checking the history items to find the action name.

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

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

Patches item #2993213, was opened at 2010-04-27 13:39
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300588&aid=2993213&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: docs
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Robert Schwenn (rschwenn)
Assigned to: Alan Ezust (ezust)
Summary: documentation for scrolling out of date

Initial Comment:
The documentation for scrolling ( http://www.jedit.org/users-guide/scrolling.html ) hasn't been updated according to changed behavior, which is noted in Detailed Change Log (Version 4.3pre17 -> Miscellaneous):  "Page-scrolling changed to CTRL+SHIFT+scroll instead of SHIFT+scroll due to Java on Mac".

It should also be documented that "SHIFT+scroll" now performs a horizontal scrolling.


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

>Comment By: Alan Ezust (ezust)
Date: 2010-06-27 07:58

Message:
Committed 18153

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

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

Patches item #3015899, was opened at 2010-06-14 06:13
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300588&aid=3015899&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: goebbe (goebbe)
Assigned to: Alan Ezust (ezust)
Summary: Clean up for SAS-edit mode

Initial Comment:
The latest version of the SAS-edit mode still uses the old "exclude_match" tag.
The attached patch (diff) fixes this issue. 

@Alan Ezust:  
This I what I made out of: 
https://sourceforge.net/tracker/?func=detail&atid=300588&aid=2926121&group_id=588
Not sure if this is now "valid" xml. I looked into the activity-log in order to find problems. 
This is my first patch ever - and the first time I use SVN - so please feel free to suggest a better usage. 



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

>Comment By: Alan Ezust (ezust)
Date: 2010-06-27 07:52

Message:
Committed 18152


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

Comment By: goebbe (goebbe)
Date: 2010-06-22 00:59

Message:
@Alan Ezust: 
I did the following: 
svn update
Than I copied the new sas.xml into the trunk  and I did: 
svn diff > sas.xml.diff

Your comments form 2010-06-14 suggest that part of this patch has already
been applied: e.g. deleting the "EXCLUDE_MATCH" tags. 
However, looking at the diff it seems that these changes have never made
it to the repository.
Probably, I misunderstood how svn works. :-)  

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

Comment By: Alan Ezust (ezust)
Date: 2010-06-21 10:19

Message:
sorry, I'm having trouble applying your patch. please also attach the final
.xml file to this ticket so I can make sure I have it right.


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

Comment By: goebbe (goebbe)
Date: 2010-06-21 05:28

Message:
@Alan Ezust:
The attached patch should fix the remaining problems. 

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

Comment By: goebbe (goebbe)
Date: 2010-06-15 01:06

Message:
@ezust
Thanks a lot for the pointers! I did not know the Jedit-XML plugin. 
Probably the 3 errors should pint a warning in the activity log - as it
was the case with the "exclude_match"? 
The attached patch should now be "valid" XML.  (hopefully)  

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

Comment By: Alan Ezust (ezust)
Date: 2010-06-14 11:55

Message:
Much better, now there only 3 errors left according to xml sidekick
lines 342, 422, 438:
Attribute AT_WORD_START must be declared for KEYWORD2.


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

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

  As a follow-up, I've tried to convert Dale's template to DocBook.
The result will be available in the next XML plugin daily, or here for 
the impatients:
   http://cotcotpot.free.fr/dropbox/XMLPlugin.html

On the plus side:
     - I didn't have to touch the existing user-guide.xml
        (I added the version number and splitted one long pre-formatted 
line, but it was optional)
     - it is easy to adopt good looking pieces of html manuals (the 
title banner, the section banner) incrementally
     - each plugin may have it's own customization, starting from 
build-support/user-guide.xsl
     - it's only a couple of hours work
     - some good-looking templates are available on the web
       (freebsd 
http://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/,
        gnome : 
http://library.gnome.org/devel/gdp-handbook/stable/intro.html.en#about)

On the minus side:
     - it may be tedious to trace the XSL templates of DocBook
     - a lot of docbook constructions used throughout the various user 
manuals may be unsupported (nothing is broken, though)

Le 19/06/10 18:29, Damien Radtke a écrit :
> I had some annoyances setting it up initially on Linux, but as long as 
> the packages are installed it's just a matter of making sure the 
> correct locations are selected. Still probably the easiest OS to do 
> that on.
>
> I'm not particularly for or against docbook one way or the other, as 
> long as it leads to a readable format for documentation.
>
> On a tangent, the documentation for Beauty and JavaSideKick looks way 
> better than that for any other plugin. Personally, I'd be for making 
> that style the "official" docbook style, since it's easier on the eyes 
> and just all-around looks better.
>

Bugs item #3015262, was opened at 2010-06-12 19:23
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=3015262&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: normal bug
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Damien (kog13)
Assigned to: Matthieu Casanova (kpouer)
Summary: 'view' is sometimes undefined using BeanShell.runScript()

Initial Comment:
I have a custom beanshell script that is run when a button is pressed by calling BeanShell.runScript(), and every now and then it shows a dialog box saying that 'view' is undefined (which is used in the script). It's really inconsistent, as often simply pressing the button again will make it work, but here's the exception it throws:


2:16:13 PM [AWT-EventQueue-0] [message] BeanShell: Running script /home/damien/.jedit/plugins/projectbuilder.ProjectBuilderPlugin/templates/Java_Application/bsh/dist.bsh
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell: Sourced file: /home/damien/.jedit/plugins/projectbuilder.ProjectBuilderPlugin/templates/Java_Application/bsh/dist.bsh : Undefined argument: view  : at Line: 19 : in file: runAntTarget : ( view , "Ant" , "+" + buildfile ) 
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at org.gjt.sp.jedit.bsh.BSHArguments.getArguments(BSHArguments.java:67)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at org.gjt.sp.jedit.bsh.BSHMethodInvocation.eval(BSHMethodInvocation.java:69)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at org.gjt.sp.jedit.bsh.BSHPrimaryExpression.eval(BSHPrimaryExpression.java:102)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at org.gjt.sp.jedit.bsh.BSHPrimaryExpression.eval(BSHPrimaryExpression.java:47)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at org.gjt.sp.jedit.bsh.BSHBlock.evalBlock(BSHBlock.java:130)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at org.gjt.sp.jedit.bsh.BSHBlock.eval(BSHBlock.java:80)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at org.gjt.sp.jedit.bsh.BSHBlock.eval(BSHBlock.java:46)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at org.gjt.sp.jedit.bsh.BSHIfStatement.eval(BSHIfStatement.java:48)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at org.gjt.sp.jedit.bsh.BSHBlock.evalBlock(BSHBlock.java:130)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at org.gjt.sp.jedit.bsh.BSHBlock.eval(BSHBlock.java:80)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at org.gjt.sp.jedit.bsh.BSHBlock.eval(BSHBlock.java:46)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at org.gjt.sp.jedit.bsh.BSHIfStatement.eval(BSHIfStatement.java:48)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at org.gjt.sp.jedit.bsh.BSHBlock.evalBlock(BSHBlock.java:130)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at org.gjt.sp.jedit.bsh.BSHBlock.eval(BSHBlock.java:80)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at org.gjt.sp.jedit.bsh.BshMethod.invokeImpl(BshMethod.java:362)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at org.gjt.sp.jedit.bsh.BshMethod.invoke(BshMethod.java:258)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at org.gjt.sp.jedit.bsh.BshMethod.invoke(BshMethod.java:186)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at org.gjt.sp.jedit.bsh.Name.invokeLocalMethod(Name.java:914)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at org.gjt.sp.jedit.bsh.Name.invokeMethod(Name.java:801)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at org.gjt.sp.jedit.bsh.BSHMethodInvocation.eval(BSHMethodInvocation.java:75)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at org.gjt.sp.jedit.bsh.BSHPrimaryExpression.eval(BSHPrimaryExpression.java:102)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at org.gjt.sp.jedit.bsh.BSHPrimaryExpression.eval(BSHPrimaryExpression.java:47)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at org.gjt.sp.jedit.bsh.Interpreter.eval(Interpreter.java:644)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at org.gjt.sp.jedit.BeanShell._runScript(BeanShell.java:331)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at org.gjt.sp.jedit.BeanShell.runScript(BeanShell.java:240)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at projectbuilder.actions.BeanshellToolbar$1.actionPerformed(Unknown Source)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:236)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at java.awt.Component.processMouseEvent(Component.java:6263)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at javax.swing.JComponent.processMouseEvent(JComponent.java:3267)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at java.awt.Component.processEvent(Component.java:6028)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at java.awt.Container.processEvent(Container.java:2041)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at java.awt.Component.dispatchEventImpl(Component.java:4630)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at java.awt.Container.dispatchEventImpl(Container.java:2099)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at java.awt.Component.dispatchEvent(Component.java:4460)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4574)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4238)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4168)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at java.awt.Container.dispatchEventImpl(Container.java:2085)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at java.awt.Window.dispatchEventImpl(Window.java:2478)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at java.awt.Component.dispatchEvent(Component.java:4460)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
2:16:13 PM [AWT-EventQueue-0] [error] BeanShell:  at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)

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

>Comment By: SourceForge Robot (sf-robot)
Date: 2010-06-27 02: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: Shlomy Reinstein (shlomy)
Date: 2010-06-12 19:32

Message:
Currently, 'view' is only defined if you passed a view to "runScript". If
you passed "null" as the view, then it won't be defined.
Scripts are supposed to either be associated with a view (and then the
'view' parameter must not be null), or otherwise be unrelated to any view
and not try to refer to the 'view' parameter.
If that's a problem, it can be fixed, but most likely the problem is that
you pass a null view to 'runScript'.

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

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