jedit-devel Mailing List for jEdit

Bugs item #2846022, was opened at 2009-08-28 06:31
Message generated for change (Comment added) made by eyebex
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2846022&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: normal bug
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Michael Clark (iiridayn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fails on Windows 7 install with latest JRE

Initial Comment:
Jedit fails (stable and development versions) with latest version of Java JRE, SDK as downloaded from http://java.sun.com/javase/downloads/index.jsp (note: https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_Developer-Site/en_US/-/USD/ViewProductDetail-Start?ProductRef=jdk-6u16-oth-JPR@CDS-CDS_Developer ,  and https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_Developer-Site/en_US/-/USD/ViewProductDetail-Start?ProductRef=jre-6u16-oth-JPR@CDS-CDS_Developer ).

The binary installer fails to detect Java.  The .jar installer fails to create any directory in "C:\Program Files\", exiting with a note to check permissions.

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

>Comment By: Sebastian Schuberth (eyebex)
Date: 2009-09-30 23:01

Message:
I believe to have fixed the binary Windows installer. Would you mind trying
this *unofficial* installer:

http://threekings.tk/tmp/jedit4.3pre18install-unofficial.exe

Please report back if it works for you. You do not need to go through the
whole setup, just see if it comes past the Java check, i.e. if the
fullscreen installer comes up.

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

Comment By: Michael Clark (iiridayn)
Date: 2009-09-27 03:41

Message:
I was probably also on x64 packages.,

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

Comment By: Lee Griffiths (poddster)
Date: 2009-09-22 16:00

Message:
I can confirm this issue. The windows7 in my case was 64bit, and the JRE
was 64bit also. I also had the JDK installed.

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

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

Bugs item #2356913, was opened at 2008-11-28 22:52
Message generated for change (Comment added) made by eyebex
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2356913&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: Simon Dahlbacka (sdahlbac)
Assigned to: Nobody/Anonymous (nobody)
Summary: MSI installer: java not detected on Win x64

Initial Comment:
I have 64-bit jre6 installed on a Vista x64 machine (in a location other than c:\program files\)

When I try to install using jedit4.3pre16install.exe the installer ends prematurely with the following message:
---------------------------
Setup
---------------------------
Setup was unable to find an installed Java Runtime Environment or Java Development Kit of version 1.4, or higher.
You must have installed at least JDK or JRE 1.4 to continue setup.
Please install one from http://java.sun.com and restart setup.
---------------------------
OK   
---------------------------


If I use the .jar installer I can run the software successfully (but all shortcuts are missing ..)

This implies that the installer is broken.

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

>Comment By: Sebastian Schuberth (eyebex)
Date: 2009-09-30 23:00

Message:
I believe to have fixed this. Would you mind trying this *unofficial*
installer:

http://threekings.tk/tmp/jedit4.3pre18install-unofficial.exe

Please report back if it works for you. You do not need to go through the
whole setup, just see if it comes past the Java check, i.e. if the
fullscreen installer comes up.

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

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

Plugin Bugs item #2855020, was opened at 2009-09-09 02:23
Message generated for change (Settings changed) made by daleanson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=2855020&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: David Dionis (ddionis)
Assigned to: Dale Anson (daleanson)
Summary: Option Pane added again when clicking apply

Initial Comment:
Go to the Plugin options.
Select "JavaSideKick" in the tree on the left.
On the right panel change some settings. (I changed the Method throw types Checkbox)
Click on apply.
Then the Option Pane will appear again (and is there twice). (On the right will appear a scrollbar where you can scroll down)
Each time "Apply" is clicked and something was changed there will be added another instance of the Options Panel.

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

>Comment By: Dale Anson (daleanson)
Date: 2009-09-30 14:38

Message:
Fixed in revision 16257.  I was able to reproduce this by using the Nimbus
LAF and get it fixed.

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

Comment By: David Dionis (ddionis)
Date: 2009-09-30 13:54

Message:
activity.log does not give any hints as far as I can see. But I just
noticed something weird.
It happens only if look and feel is set to Nimbus. Metal L&F seems ok.
Have you tried
Nimbus?

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

Comment By: Dale Anson (daleanson)
Date: 2009-09-28 11:08

Message:
I am unable to reproduce this at all.  Do you see anything in your
activity.log file that might point to the problem?

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

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

Plugin Bugs item #2855020, was opened at 2009-09-09 10:23
Message generated for change (Comment added) made by ddionis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=2855020&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: David Dionis (ddionis)
Assigned to: Dale Anson (daleanson)
Summary: Option Pane added again when clicking apply

Initial Comment:
Go to the Plugin options.
Select "JavaSideKick" in the tree on the left.
On the right panel change some settings. (I changed the Method throw types Checkbox)
Click on apply.
Then the Option Pane will appear again (and is there twice). (On the right will appear a scrollbar where you can scroll down)
Each time "Apply" is clicked and something was changed there will be added another instance of the Options Panel.

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

Comment By: David Dionis (ddionis)
Date: 2009-09-30 21:54

Message:
activity.log does not give any hints as far as I can see. But I just
noticed something weird.
It happens only if look and feel is set to Nimbus. Metal L&F seems ok.
Have you tried
Nimbus?

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

Comment By: Dale Anson (daleanson)
Date: 2009-09-28 19:08

Message:
I am unable to reproduce this at all.  Do you see anything in your
activity.log file that might point to the problem?

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

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

I've seen an NPE there from time to time also, but I can't reproduce it.

On Wed, Sep 30, 2009 at 11:50 AM, Dale Anson <da...@gr...> wrote:

> On Wed, Sep 30, 2009 at 9:58 AM, Matthieu Casanova
> <cho...@gm...> wrote:
> > But in that code, the fields are used as parameters, so filling the
> keyword
> > field at line 294 is used to highlight tokens, removing that will lead to
> > bugs.
> > For the NPE at line 294, do you know if it is because of context being
> null
> > or context.rules ?
>
> I don't know.  I didn't look into it far enough.  I supposed, though,
> if I'm the only one seeing this issue, that means I've got something
> wrong somewhere.
>
>

Maybe you use an edit mode that cause the problem ?

2009/9/30 Dale Anson <da...@gr...>

> On Wed, Sep 30, 2009 at 9:58 AM, Matthieu Casanova
> <cho...@gm...> wrote:
> > But in that code, the fields are used as parameters, so filling the
> keyword
> > field at line 294 is used to highlight tokens, removing that will lead to
> > bugs.
> > For the NPE at line 294, do you know if it is because of context being
> null
> > or context.rules ?
>
> I don't know.  I didn't look into it far enough.  I supposed, though,
> if I'm the only one seeing this issue, that means I've got something
> wrong somewhere.
>
>
> >
> > 2009/9/30 Dale Anson <da...@gr...>
> >>
> >> This happens when editing java files.  I am using head of svn, my
> >> current build is from revision 16233.  I haven't really looked into
> >> the code, but removing line 294 seems fix the situation.  I was hoping
> >> someone would be familiar enough with that code to know if it's
> >> supposed to be like that.  I'll poke around some more when I have
> >> time.
> >>
> >> Thanks,
> >>
> >> Dale
> >>
> >>
> >> On Wed, Sep 30, 2009 at 1:19 AM, Shlomy Reinstein <sre...@gm...>
> >> wrote:
> >> > Without knowing the code, just a brief look shows me this is a
> >> > mode-specific issue that is probably related to delegation of mode
> >> > attributes. So, in which mode does it happen? Maybe something's wrong
> >> > with the mode file?
> >> >
> >> > Shlomy
> >> >
> >> > On Wed, Sep 30, 2009 at 9:03 AM, Matthieu Casanova
> >> > <cho...@gm...> wrote:
> >> >> Hi, I don't know exactly, but  I suppose those keywords are used in
> >> >> handleRule, don't you think ?
> >> >>
> >> >> 2009/9/29 Dale Anson <da...@gr...>
> >> >>>
> >> >>> In TokenMarker.java, there are these lines starting at line 292:
> >> >>>
> >> >>> 292:            LineContext tempContext = context;
> >> >>> 293:            context = context.parent;
> >> >>> 294:            keywords = context.rules.getKeywords();
> >> >>> 295:            boolean handled = handleRule(rule,true);
> >> >>> 296:            context = tempContext;
> >> >>> 297:            keywords = context.rules.getKeywords();
> >> >>>
> >> >>>
> >> >>> Does anyone know why the line at 294 is there at all?  The value for
> >> >>> 'keywords' is replaced in line 297 and it isn't used in between.
>  I'm
> >> >>> getting null pointer exceptions from line 294 fairly often.  Just
> >> >>> hitting the "Enter" button while typing in the text area causes it,
> >> >>> then there is a beanshell error dialog and the cursor goes to the
> >> >>> wrong place, there are painting issues, and so on.  I've removed
> line
> >> >>> 294 in my local copy, and things seem to be working better so far.
> >> >>> I'm not familiar with this piece of code at all, so I don't know if
> >> >>> context.rules on line 294 should ever be null.
> >> >>>
> >> >>> Thanks,
> >> >>>
> >> >>> Dale
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> ------------------------------------------------------------------------------
> >> >>> Come build with us! The BlackBerry&reg; Developer Conference in SF,
> CA
> >> >>> is the only developer event you need to attend this year. Jumpstart
> >> >>> your
> >> >>> developing skills, take BlackBerry mobile applications to market and
> >> >>> stay
> >> >>> ahead of the curve. Join us from November 9&#45;12, 2009. Register
> >> >>> now&#33;
> >> >>> http://p.sf.net/sfu/devconf
> >> >>> --
> >> >>> -----------------------------------------------
> >> >>> jEdit Developers' List
> >> >>> jEd...@li...
> >> >>> https://lists.sourceforge.net/lists/listinfo/jedit-devel
> >> >>
> >> >>
> >> >>
> >> >>
> ------------------------------------------------------------------------------
> >> >> Come build with us! The BlackBerry&reg; Developer Conference in SF,
> CA
> >> >> is the only developer event you need to attend this year. Jumpstart
> >> >> your
> >> >> developing skills, take BlackBerry mobile applications to market and
> >> >> stay
> >> >> ahead of the curve. Join us from November 9&#45;12, 2009. Register
> >> >> now&#33;
> >> >> http://p.sf.net/sfu/devconf
> >> >> --
> >> >> -----------------------------------------------
> >> >> jEdit Developers' List
> >> >> jEd...@li...
> >> >> https://lists.sourceforge.net/lists/listinfo/jedit-devel
> >> >>
> >> >>
> >> >
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> >> is the only developer event you need to attend this year. Jumpstart your
> >> developing skills, take BlackBerry mobile applications to market and
> stay
> >> ahead of the curve. Join us from November 9&#45;12, 2009. Register
> >> now&#33;
> >> http://p.sf.net/sfu/devconf
> >> --
> >> -----------------------------------------------
> >> jEdit Developers' List
> >> jEd...@li...
> >> https://lists.sourceforge.net/lists/listinfo/jedit-devel
> >
> >
>

On Wed, Sep 30, 2009 at 9:58 AM, Matthieu Casanova
<cho...@gm...> wrote:
> But in that code, the fields are used as parameters, so filling the keyword
> field at line 294 is used to highlight tokens, removing that will lead to
> bugs.
> For the NPE at line 294, do you know if it is because of context being null
> or context.rules ?

I don't know.  I didn't look into it far enough.  I supposed, though,
if I'm the only one seeing this issue, that means I've got something
wrong somewhere.


>
> 2009/9/30 Dale Anson <da...@gr...>
>>
>> This happens when editing java files.  I am using head of svn, my
>> current build is from revision 16233.  I haven't really looked into
>> the code, but removing line 294 seems fix the situation.  I was hoping
>> someone would be familiar enough with that code to know if it's
>> supposed to be like that.  I'll poke around some more when I have
>> time.
>>
>> Thanks,
>>
>> Dale
>>
>>
>> On Wed, Sep 30, 2009 at 1:19 AM, Shlomy Reinstein <sre...@gm...>
>> wrote:
>> > Without knowing the code, just a brief look shows me this is a
>> > mode-specific issue that is probably related to delegation of mode
>> > attributes. So, in which mode does it happen? Maybe something's wrong
>> > with the mode file?
>> >
>> > Shlomy
>> >
>> > On Wed, Sep 30, 2009 at 9:03 AM, Matthieu Casanova
>> > <cho...@gm...> wrote:
>> >> Hi, I don't know exactly, but  I suppose those keywords are used in
>> >> handleRule, don't you think ?
>> >>
>> >> 2009/9/29 Dale Anson <da...@gr...>
>> >>>
>> >>> In TokenMarker.java, there are these lines starting at line 292:
>> >>>
>> >>> 292:            LineContext tempContext = context;
>> >>> 293:            context = context.parent;
>> >>> 294:            keywords = context.rules.getKeywords();
>> >>> 295:            boolean handled = handleRule(rule,true);
>> >>> 296:            context = tempContext;
>> >>> 297:            keywords = context.rules.getKeywords();
>> >>>
>> >>>
>> >>> Does anyone know why the line at 294 is there at all?  The value for
>> >>> 'keywords' is replaced in line 297 and it isn't used in between.  I'm
>> >>> getting null pointer exceptions from line 294 fairly often.  Just
>> >>> hitting the "Enter" button while typing in the text area causes it,
>> >>> then there is a beanshell error dialog and the cursor goes to the
>> >>> wrong place, there are painting issues, and so on.  I've removed line
>> >>> 294 in my local copy, and things seem to be working better so far.
>> >>> I'm not familiar with this piece of code at all, so I don't know if
>> >>> context.rules on line 294 should ever be null.
>> >>>
>> >>> Thanks,
>> >>>
>> >>> Dale
>> >>>
>> >>>
>> >>>
>> >>> ------------------------------------------------------------------------------
>> >>> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
>> >>> is the only developer event you need to attend this year. Jumpstart
>> >>> your
>> >>> developing skills, take BlackBerry mobile applications to market and
>> >>> stay
>> >>> ahead of the curve. Join us from November 9&#45;12, 2009. Register
>> >>> now&#33;
>> >>> http://p.sf.net/sfu/devconf
>> >>> --
>> >>> -----------------------------------------------
>> >>> jEdit Developers' List
>> >>> jEd...@li...
>> >>> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
>> >> is the only developer event you need to attend this year. Jumpstart
>> >> your
>> >> developing skills, take BlackBerry mobile applications to market and
>> >> stay
>> >> ahead of the curve. Join us from November 9&#45;12, 2009. Register
>> >> now&#33;
>> >> http://p.sf.net/sfu/devconf
>> >> --
>> >> -----------------------------------------------
>> >> jEdit Developers' List
>> >> jEd...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>> >>
>> >>
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9&#45;12, 2009. Register
>> now&#33;
>> http://p.sf.net/sfu/devconf
>> --
>> -----------------------------------------------
>> jEdit Developers' List
>> jEd...@li...
>> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>
>

But in that code, the fields are used as parameters, so filling the keyword
field at line 294 is used to highlight tokens, removing that will lead to
bugs.
For the NPE at line 294, do you know if it is because of context being null
or context.rules ?

2009/9/30 Dale Anson <da...@gr...>

> This happens when editing java files.  I am using head of svn, my
> current build is from revision 16233.  I haven't really looked into
> the code, but removing line 294 seems fix the situation.  I was hoping
> someone would be familiar enough with that code to know if it's
> supposed to be like that.  I'll poke around some more when I have
> time.
>
> Thanks,
>
> Dale
>
>
> On Wed, Sep 30, 2009 at 1:19 AM, Shlomy Reinstein <sre...@gm...>
> wrote:
> > Without knowing the code, just a brief look shows me this is a
> > mode-specific issue that is probably related to delegation of mode
> > attributes. So, in which mode does it happen? Maybe something's wrong
> > with the mode file?
> >
> > Shlomy
> >
> > On Wed, Sep 30, 2009 at 9:03 AM, Matthieu Casanova
> > <cho...@gm...> wrote:
> >> Hi, I don't know exactly, but  I suppose those keywords are used in
> >> handleRule, don't you think ?
> >>
> >> 2009/9/29 Dale Anson <da...@gr...>
> >>>
> >>> In TokenMarker.java, there are these lines starting at line 292:
> >>>
> >>> 292:            LineContext tempContext = context;
> >>> 293:            context = context.parent;
> >>> 294:            keywords = context.rules.getKeywords();
> >>> 295:            boolean handled = handleRule(rule,true);
> >>> 296:            context = tempContext;
> >>> 297:            keywords = context.rules.getKeywords();
> >>>
> >>>
> >>> Does anyone know why the line at 294 is there at all?  The value for
> >>> 'keywords' is replaced in line 297 and it isn't used in between.  I'm
> >>> getting null pointer exceptions from line 294 fairly often.  Just
> >>> hitting the "Enter" button while typing in the text area causes it,
> >>> then there is a beanshell error dialog and the cursor goes to the
> >>> wrong place, there are painting issues, and so on.  I've removed line
> >>> 294 in my local copy, and things seem to be working better so far.
> >>> I'm not familiar with this piece of code at all, so I don't know if
> >>> context.rules on line 294 should ever be null.
> >>>
> >>> Thanks,
> >>>
> >>> Dale
> >>>
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> >>> is the only developer event you need to attend this year. Jumpstart
> your
> >>> developing skills, take BlackBerry mobile applications to market and
> stay
> >>> ahead of the curve. Join us from November 9&#45;12, 2009. Register
> >>> now&#33;
> >>> http://p.sf.net/sfu/devconf
> >>> --
> >>> -----------------------------------------------
> >>> jEdit Developers' List
> >>> jEd...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/jedit-devel
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> >> is the only developer event you need to attend this year. Jumpstart your
> >> developing skills, take BlackBerry mobile applications to market and
> stay
> >> ahead of the curve. Join us from November 9&#45;12, 2009. Register
> now&#33;
> >> http://p.sf.net/sfu/devconf
> >> --
> >> -----------------------------------------------
> >> jEdit Developers' List
> >> jEd...@li...
> >> https://lists.sourceforge.net/lists/listinfo/jedit-devel
> >>
> >>
> >
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> --
> -----------------------------------------------
> jEdit Developers' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>

My guess is that the only person who is really familiar with that code is
Slava.

On Wed, Sep 30, 2009 at 8:06 AM, Dale Anson <da...@gr...> wrote:

> This happens when editing java files.  I am using head of svn, my
> current build is from revision 16233.  I haven't really looked into
> the code, but removing line 294 seems fix the situation.  I was hoping
> someone would be familiar enough with that code to know if it's
> supposed to be like that.  I'll poke around some more when I have
> time.
>
> Thanks,

This happens when editing java files.  I am using head of svn, my
current build is from revision 16233.  I haven't really looked into
the code, but removing line 294 seems fix the situation.  I was hoping
someone would be familiar enough with that code to know if it's
supposed to be like that.  I'll poke around some more when I have
time.

Thanks,

Dale


On Wed, Sep 30, 2009 at 1:19 AM, Shlomy Reinstein <sre...@gm...> wrote:
> Without knowing the code, just a brief look shows me this is a
> mode-specific issue that is probably related to delegation of mode
> attributes. So, in which mode does it happen? Maybe something's wrong
> with the mode file?
>
> Shlomy
>
> On Wed, Sep 30, 2009 at 9:03 AM, Matthieu Casanova
> <cho...@gm...> wrote:
>> Hi, I don't know exactly, but  I suppose those keywords are used in
>> handleRule, don't you think ?
>>
>> 2009/9/29 Dale Anson <da...@gr...>
>>>
>>> In TokenMarker.java, there are these lines starting at line 292:
>>>
>>> 292:            LineContext tempContext = context;
>>> 293:            context = context.parent;
>>> 294:            keywords = context.rules.getKeywords();
>>> 295:            boolean handled = handleRule(rule,true);
>>> 296:            context = tempContext;
>>> 297:            keywords = context.rules.getKeywords();
>>>
>>>
>>> Does anyone know why the line at 294 is there at all?  The value for
>>> 'keywords' is replaced in line 297 and it isn't used in between.  I'm
>>> getting null pointer exceptions from line 294 fairly often.  Just
>>> hitting the "Enter" button while typing in the text area causes it,
>>> then there is a beanshell error dialog and the cursor goes to the
>>> wrong place, there are painting issues, and so on.  I've removed line
>>> 294 in my local copy, and things seem to be working better so far.
>>> I'm not familiar with this piece of code at all, so I don't know if
>>> context.rules on line 294 should ever be null.
>>>
>>> Thanks,
>>>
>>> Dale
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
>>> is the only developer event you need to attend this year. Jumpstart your
>>> developing skills, take BlackBerry mobile applications to market and stay
>>> ahead of the curve. Join us from November 9&#45;12, 2009. Register
>>> now&#33;
>>> http://p.sf.net/sfu/devconf
>>> --
>>> -----------------------------------------------
>>> jEdit Developers' List
>>> jEd...@li...
>>> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
>> http://p.sf.net/sfu/devconf
>> --
>> -----------------------------------------------
>> jEdit Developers' List
>> jEd...@li...
>> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>>
>>
>

Without knowing the code, just a brief look shows me this is a
mode-specific issue that is probably related to delegation of mode
attributes. So, in which mode does it happen? Maybe something's wrong
with the mode file?

Shlomy

On Wed, Sep 30, 2009 at 9:03 AM, Matthieu Casanova
<cho...@gm...> wrote:
> Hi, I don't know exactly, but  I suppose those keywords are used in
> handleRule, don't you think ?
>
> 2009/9/29 Dale Anson <da...@gr...>
>>
>> In TokenMarker.java, there are these lines starting at line 292:
>>
>> 292:            LineContext tempContext = context;
>> 293:            context = context.parent;
>> 294:            keywords = context.rules.getKeywords();
>> 295:            boolean handled = handleRule(rule,true);
>> 296:            context = tempContext;
>> 297:            keywords = context.rules.getKeywords();
>>
>>
>> Does anyone know why the line at 294 is there at all?  The value for
>> 'keywords' is replaced in line 297 and it isn't used in between.  I'm
>> getting null pointer exceptions from line 294 fairly often.  Just
>> hitting the "Enter" button while typing in the text area causes it,
>> then there is a beanshell error dialog and the cursor goes to the
>> wrong place, there are painting issues, and so on.  I've removed line
>> 294 in my local copy, and things seem to be working better so far.
>> I'm not familiar with this piece of code at all, so I don't know if
>> context.rules on line 294 should ever be null.
>>
>> Thanks,
>>
>> Dale
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9&#45;12, 2009. Register
>> now&#33;
>> http://p.sf.net/sfu/devconf
>> --
>> -----------------------------------------------
>> jEdit Developers' List
>> jEd...@li...
>> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> --
> -----------------------------------------------
> jEdit Developers' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>
>

Hi, I don't know exactly, but  I suppose those keywords are used in
handleRule, don't you think ?

2009/9/29 Dale Anson <da...@gr...>

> In TokenMarker.java, there are these lines starting at line 292:
>
> 292:            LineContext tempContext = context;
> 293:            context = context.parent;
> 294:            keywords = context.rules.getKeywords();
> 295:            boolean handled = handleRule(rule,true);
> 296:            context = tempContext;
> 297:            keywords = context.rules.getKeywords();
>
>
> Does anyone know why the line at 294 is there at all?  The value for
> 'keywords' is replaced in line 297 and it isn't used in between.  I'm
> getting null pointer exceptions from line 294 fairly often.  Just
> hitting the "Enter" button while typing in the text area causes it,
> then there is a beanshell error dialog and the cursor goes to the
> wrong place, there are painting issues, and so on.  I've removed line
> 294 in my local copy, and things seem to be working better so far.
> I'm not familiar with this piece of code at all, so I don't know if
> context.rules on line 294 should ever be null.
>
> Thanks,
>
> Dale
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> --
> -----------------------------------------------
> jEdit Developers' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>

Just pressing enter causes exceptions for you?  In svn head?


On Tue, Sep 29, 2009 at 4:03 PM, Dale Anson <da...@gr...> wrote:
> In TokenMarker.java, there are these lines starting at line 292:
>
> 292:            LineContext tempContext = context;
> 293:            context = context.parent;
> 294:            keywords = context.rules.getKeywords();
> 295:            boolean handled = handleRule(rule,true);
> 296:            context = tempContext;
> 297:            keywords = context.rules.getKeywords();
>
>
> Does anyone know why the line at 294 is there at all?  The value for
> 'keywords' is replaced in line 297 and it isn't used in between.  I'm
> getting null pointer exceptions from line 294 fairly often.  Just
> hitting the "Enter" button while typing in the text area causes it,
> then there is a beanshell error dialog and the cursor goes to the
> wrong place, there are painting issues, and so on.  I've removed line
> 294 in my local copy, and things seem to be working better so far.
> I'm not familiar with this piece of code at all, so I don't know if
> context.rules on line 294 should ever be null.
>
> Thanks,
>
> Dale
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> --
> -----------------------------------------------
> jEdit Developers' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>



-- 
Daniel Johnson de...@gm...

In TokenMarker.java, there are these lines starting at line 292:

292:		LineContext tempContext = context;
293:		context = context.parent;
294:		keywords = context.rules.getKeywords();
295:		boolean handled = handleRule(rule,true);
296:		context = tempContext;
297:		keywords = context.rules.getKeywords();


Does anyone know why the line at 294 is there at all?  The value for
'keywords' is replaced in line 297 and it isn't used in between.  I'm
getting null pointer exceptions from line 294 fairly often.  Just
hitting the "Enter" button while typing in the text area causes it,
then there is a beanshell error dialog and the cursor goes to the
wrong place, there are painting issues, and so on.  I've removed line
294 in my local copy, and things seem to be working better so far.
I'm not familiar with this piece of code at all, so I don't know if
context.rules on line 294 should ever be null.

Thanks,

Dale

Feature Requests item #2869506, was opened at 2009-09-29 08:23
Message generated for change (Settings changed) made by shlomy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350588&aid=2869506&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: Shlomy Reinstein (shlomy)
>Assigned to: Shlomy Reinstein (shlomy)
Summary: Toggle Header Source macro: Support for proiect viewer

Initial Comment:
The "Toggle Header Source" macro will be a lot more helpful if it can search for the header/source in the project and not just in the current directory. Many projects have a directory structure in which the headers are located in a different directory than the source. (e.g. 'src' and 'inc').

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

>Comment By: Shlomy Reinstein (shlomy)
Date: 2009-09-29 22:52

Message:
Committed to SVN trunk.

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

Comment By: Alan Ezust (ezust)
Date: 2009-09-29 16:53

Message:
Good suggestion.
However, for the meantime, if you already have the file open, it will
switch to it for you even if it is in a different directory.



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

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

Feature Requests item #2869506, was opened at 2009-09-28 23:23
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350588&aid=2869506&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: Shlomy Reinstein (shlomy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Toggle Header Source macro: Support for proiect viewer

Initial Comment:
The "Toggle Header Source" macro will be a lot more helpful if it can search for the header/source in the project and not just in the current directory. Many projects have a directory structure in which the headers are located in a different directory than the source. (e.g. 'src' and 'inc').

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

>Comment By: Alan Ezust (ezust)
Date: 2009-09-29 07:53

Message:
Good suggestion.
However, for the meantime, if you already have the file open, it will
switch to it for you even if it is in a different directory.



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

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

Feature Requests item #2869506, was opened at 2009-09-29 08:23
Message generated for change (Tracker Item Submitted) made by shlomy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350588&aid=2869506&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: Shlomy Reinstein (shlomy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Toggle Header Source macro: Support for proiect viewer

Initial Comment:
The "Toggle Header Source" macro will be a lot more helpful if it can search for the header/source in the project and not just in the current directory. Many projects have a directory structure in which the headers are located in a different directory than the source. (e.g. 'src' and 'inc').

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

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

Patches item #2023939, was opened at 2008-07-22 00:02
Message generated for change (Comment added) made by shlomy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300588&aid=2023939&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: texteditor
Group: None
Status: Closed
Resolution: Rejected
Priority: 5
Private: No
Submitted By: Matthew Gilbert (voxmea)
Assigned to: Kazutoshi Satoda (k_satoda)
Summary: Adds special handling to the C syntax for "#if 0"

Initial Comment:
Comments-out all code between #if 0 and #endif.

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

>Comment By: Shlomy Reinstein (shlomy)
Date: 2009-09-29 08:14

Message:
The Configurable Fold Handler can definitely turn them into folds, I use it
all the time. I use the following regexp as fold-start string:
\{|^\s*#\s*if|/\*
and the following regexp as fold-end string: \}|^\s*#\s*end|\*/

Hope this is helpful.

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

Comment By: Alan Ezust (ezust)
Date: 2009-09-28 21:58

Message:
I wonder if it is possible to make the Configurable Fold Handler turn those
conditional #ifdefs into folds...


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

Comment By: Kazutoshi Satoda (k_satoda)
Date: 2008-08-19 16:51

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

> Can syntax changes be made by a plugin?
It depends on what change you want. Please ask on jedit-devel or post a
feature request if you have concrete idea. (Note that trackers are not
good to make Q&A or discussion.)

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

Comment By: Matthew Gilbert (voxmea)
Date: 2008-08-13 23:29

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

Ah, I didn't consider nested endifs. Yeah, this won't work. Thanks for the
help with HASH_CHAR. Can syntax changes be made by a plugin?

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

Comment By: Kazutoshi Satoda (k_satoda)
Date: 2008-08-13 22:15

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

Sorry, I meant to write "I don't think it is good ...".

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

Comment By: Kazutoshi Satoda (k_satoda)
Date: 2008-08-13 22:11

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

Thank you for the patch. But the evaluation is Rejected. Following is
the reason.

I don't think it is not good to support only "#if 0" because it gives
false impression that jEdit is evaluating the CPP conditions. Without
clear and strong motivation to do that, it won't be accepted.

And also this patch has some technical problems.

First problem is HASH_CHAR="#if 0". This rejects anything but "#if 0"
literally, for example, "#if  0" (two spaces) doesn't match.
http://www.jedit.org/users-guide/mode-rule-span-regexp.html
But this is easy to fix. HASH_CHAR="#" is a solution.

Second problem is that, in contrast of the range comment /* ... */,
#if directive can be nested. Thus, simple SPAN_REGEXP doesn't match
its behavior. This looks a bit difficult to solve. Another special rule
set, say "CPP_SKIPPED", may be required.

Last problem is care about #else, #elif, #if 1 ... #else. Looks too
difficult for now, at least for me.

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

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

Plugin Feature Requests item #2869057, was opened at 2009-09-28 10:44
Message generated for change (Settings changed) made by vanza
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=2869057&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: 7
Private: No
Submitted By: Alan Ezust (ezust)
>Assigned to: Nobody/Anonymous (nobody)
>Summary: HelperLauncher: provide FSB and PV context menu item

Initial Comment:
ProjectViewer has its own set of helpers to launch for certain file types.
It adds a context menu to the PV dockable. 
It should add the same menu item to the File System Browser too.

What is that helperlauncher for anyway? It seems to be yet another mapping of file types to programs. Why do we need both? Can't we put that mapping in the core?


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

>Comment By: Marcelo Vanzin (vanza)
Date: 2009-09-28 20:27

Message:
Well, once someone does it in HelperLauncher, I'll remove the code from
PV...

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

Comment By: Alan Ezust (ezust)
Date: 2009-09-28 17:22

Message:
Marcelo, you just described the ideal solution.


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

Comment By: Marcelo Vanzin (vanza)
Date: 2009-09-28 16:57

Message:
Ok, someone needs to make a decision. helperlauncher seems to be pretty
old. but the description mentions things that PV's version doesn't do.

In fact, I'd rather keep all this functionality in that separate plugin
and remove all the code in PV - since this is not really something
project-specific, and I actually never use that functionality in PV.

Then helperlauncher can provide both FSB and PV extensions.

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

Comment By: Alan Ezust (ezust)
Date: 2009-09-28 13:00

Message:
Dale: yes, I meant the open with... context menu item.


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

Comment By: Dale Anson (daleanson)
Date: 2009-09-28 12:21

Message:
Alan, are you asking about the "Open with..." menu item on the PV context
menu?  If so, I'd also like that added to FSB.  It would be great to be
able to open a zip or jar file in an external app to see the contents.

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

Comment By: Alan Ezust (ezust)
Date: 2009-09-28 11:22

Message:
So one idea is to have PV use HelperLauncher for its mapping, so there is
only one mapping.
Another idea is to move HelperLauncher into core and have PV use that.
And another idea is to have PV offer the FSB context menu item directly.
I'm not sure which one is best.



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

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

Plugin Feature Requests item #2869057, was opened at 2009-09-28 10:44
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=2869057&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: 7
Private: No
Submitted By: Alan Ezust (ezust)
Assigned to: Marcelo Vanzin (vanza)
Summary: ProjectViewer vs HelperLauncher: FSB context menu item

Initial Comment:
ProjectViewer has its own set of helpers to launch for certain file types.
It adds a context menu to the PV dockable. 
It should add the same menu item to the File System Browser too.

What is that helperlauncher for anyway? It seems to be yet another mapping of file types to programs. Why do we need both? Can't we put that mapping in the core?


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

>Comment By: Alan Ezust (ezust)
Date: 2009-09-28 17:22

Message:
Marcelo, you just described the ideal solution.


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

Comment By: Marcelo Vanzin (vanza)
Date: 2009-09-28 16:57

Message:
Ok, someone needs to make a decision. helperlauncher seems to be pretty
old. but the description mentions things that PV's version doesn't do.

In fact, I'd rather keep all this functionality in that separate plugin
and remove all the code in PV - since this is not really something
project-specific, and I actually never use that functionality in PV.

Then helperlauncher can provide both FSB and PV extensions.

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

Comment By: Alan Ezust (ezust)
Date: 2009-09-28 13:00

Message:
Dale: yes, I meant the open with... context menu item.


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

Comment By: Dale Anson (daleanson)
Date: 2009-09-28 12:21

Message:
Alan, are you asking about the "Open with..." menu item on the PV context
menu?  If so, I'd also like that added to FSB.  It would be great to be
able to open a zip or jar file in an external app to see the contents.

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

Comment By: Alan Ezust (ezust)
Date: 2009-09-28 11:22

Message:
So one idea is to have PV use HelperLauncher for its mapping, so there is
only one mapping.
Another idea is to move HelperLauncher into core and have PV use that.
And another idea is to have PV offer the FSB context menu item directly.
I'm not sure which one is best.



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

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

Plugin Feature Requests item #2869057, was opened at 2009-09-28 10:44
Message generated for change (Comment added) made by vanza
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=2869057&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: 7
Private: No
Submitted By: Alan Ezust (ezust)
Assigned to: Marcelo Vanzin (vanza)
Summary: ProjectViewer vs HelperLauncher: FSB context menu item

Initial Comment:
ProjectViewer has its own set of helpers to launch for certain file types.
It adds a context menu to the PV dockable. 
It should add the same menu item to the File System Browser too.

What is that helperlauncher for anyway? It seems to be yet another mapping of file types to programs. Why do we need both? Can't we put that mapping in the core?


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

>Comment By: Marcelo Vanzin (vanza)
Date: 2009-09-28 16:57

Message:
Ok, someone needs to make a decision. helperlauncher seems to be pretty
old. but the description mentions things that PV's version doesn't do.

In fact, I'd rather keep all this functionality in that separate plugin
and remove all the code in PV - since this is not really something
project-specific, and I actually never use that functionality in PV.

Then helperlauncher can provide both FSB and PV extensions.

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

Comment By: Alan Ezust (ezust)
Date: 2009-09-28 13:00

Message:
Dale: yes, I meant the open with... context menu item.


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

Comment By: Dale Anson (daleanson)
Date: 2009-09-28 12:21

Message:
Alan, are you asking about the "Open with..." menu item on the PV context
menu?  If so, I'd also like that added to FSB.  It would be great to be
able to open a zip or jar file in an external app to see the contents.

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

Comment By: Alan Ezust (ezust)
Date: 2009-09-28 11:22

Message:
So one idea is to have PV use HelperLauncher for its mapping, so there is
only one mapping.
Another idea is to move HelperLauncher into core and have PV use that.
And another idea is to have PV offer the FSB context menu item directly.
I'm not sure which one is best.



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

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

Plugin Feature Requests item #2869057, was opened at 2009-09-28 10:44
Message generated for change (Settings changed) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=2869057&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: 7
Private: No
Submitted By: Alan Ezust (ezust)
Assigned to: Marcelo Vanzin (vanza)
Summary: ProjectViewer vs HelperLauncher: FSB context menu item

Initial Comment:
ProjectViewer has its own set of helpers to launch for certain file types.
It adds a context menu to the PV dockable. 
It should add the same menu item to the File System Browser too.

What is that helperlauncher for anyway? It seems to be yet another mapping of file types to programs. Why do we need both? Can't we put that mapping in the core?


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

>Comment By: Alan Ezust (ezust)
Date: 2009-09-28 13:00

Message:
Dale: yes, I meant the open with... context menu item.


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

Comment By: Dale Anson (daleanson)
Date: 2009-09-28 12:21

Message:
Alan, are you asking about the "Open with..." menu item on the PV context
menu?  If so, I'd also like that added to FSB.  It would be great to be
able to open a zip or jar file in an external app to see the contents.

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

Comment By: Alan Ezust (ezust)
Date: 2009-09-28 11:22

Message:
So one idea is to have PV use HelperLauncher for its mapping, so there is
only one mapping.
Another idea is to move HelperLauncher into core and have PV use that.
And another idea is to have PV offer the FSB context menu item directly.
I'm not sure which one is best.



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

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

Patches item #2023939, was opened at 2008-07-21 14:02
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300588&aid=2023939&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: texteditor
Group: None
Status: Closed
Resolution: Rejected
Priority: 5
Private: No
Submitted By: Matthew Gilbert (voxmea)
Assigned to: Kazutoshi Satoda (k_satoda)
Summary: Adds special handling to the C syntax for "#if 0"

Initial Comment:
Comments-out all code between #if 0 and #endif.

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

>Comment By: Alan Ezust (ezust)
Date: 2009-09-28 12:58

Message:
I wonder if it is possible to make the Configurable Fold Handler turn those
conditional #ifdefs into folds...


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

Comment By: Kazutoshi Satoda (k_satoda)
Date: 2008-08-19 06:51

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

> Can syntax changes be made by a plugin?
It depends on what change you want. Please ask on jedit-devel or post a
feature request if you have concrete idea. (Note that trackers are not
good to make Q&A or discussion.)

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

Comment By: Matthew Gilbert (voxmea)
Date: 2008-08-13 13:29

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

Ah, I didn't consider nested endifs. Yeah, this won't work. Thanks for the
help with HASH_CHAR. Can syntax changes be made by a plugin?

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

Comment By: Kazutoshi Satoda (k_satoda)
Date: 2008-08-13 12:15

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

Sorry, I meant to write "I don't think it is good ...".

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

Comment By: Kazutoshi Satoda (k_satoda)
Date: 2008-08-13 12:11

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

Thank you for the patch. But the evaluation is Rejected. Following is
the reason.

I don't think it is not good to support only "#if 0" because it gives
false impression that jEdit is evaluating the CPP conditions. Without
clear and strong motivation to do that, it won't be accepted.

And also this patch has some technical problems.

First problem is HASH_CHAR="#if 0". This rejects anything but "#if 0"
literally, for example, "#if  0" (two spaces) doesn't match.
http://www.jedit.org/users-guide/mode-rule-span-regexp.html
But this is easy to fix. HASH_CHAR="#" is a solution.

Second problem is that, in contrast of the range comment /* ... */,
#if directive can be nested. Thus, simple SPAN_REGEXP doesn't match
its behavior. This looks a bit difficult to solve. Another special rule
set, say "CPP_SKIPPED", may be required.

Last problem is care about #else, #elif, #if 1 ... #else. Looks too
difficult for now, at least for me.

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

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

Feature Requests item #2868804, was opened at 2009-09-28 21:21
Message generated for change (Comment added) made by k_satoda
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350588&aid=2868804&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: richard boaz (richard-boaz)
Assigned to: Nobody/Anonymous (nobody)
Summary: #if 0 directive

Initial Comment:
As previously requested, it would be nice if jedit would automatically recognize the "#if 0" CPP directive used to comment out large blocks of C-code.

This was previously requested under Artifact ID # 2023939, but was rejected for various reasons.

I am re-requesting this because:
1) this functionality is readily available in gedit; if there, why not in jedit?
2) the previous rejection noted that this is CPP processing, which is true, but I'm not sure I see the point.  It is a CPP directive that means "code does not exist", much like the comment directive /*...*/ means to the compiler that "code does not exist".  Why is there a perceived difference between what the first pass and the second pass of the compiler does when the effect is the same, code has been commented out and the editor should tag it as such and draw accordingly.
3) that there can be embedded #if statements is also true, and?  count the #if and corresponding #endif's and comment out everything between #if 0 and its corresponding #endif.

Why?  because this is a very standard manner of blocking out large chunks of C code.  That jedit does not recognize this is a shame and a shortcome of its C-code syntax highlighting functionality.

And, because gedit does have this, I really don't see why it wouldn't be handled just because the functionality comes with "issues" ('#if  0' with two blanks, e.g.).

Please re-consider this request, and when doing so, recall that an application's functionality follows standard usage, not the other way around.

thanks, and thanks for a great program!

richard boaz

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

>Comment By: Kazutoshi Satoda (k_satoda)
Date: 2009-09-29 04:31

Message:
> 2) the previous rejection noted that this is CPP processing, which is
true,
> but I'm not sure I see the point.

Let me rephrase the point.
(See this link to patch #2023939 for "the previous rejection"):
https://sourceforge.net/support/tracker.php?aid=2023939

I don't think it is a good idea to support only "#if 0" because it gives
false impression that jEdit is evaluating the CPP conditions. In fact,
jEdit syntax engine will hardly be able to evaluate CPP conditions.
For example, "#if SIZE < LIMIT", "#if !defined(SOME_CONFIG)", ...

With such false impression, users will likely feel odd finding many
other conditions which are obviously known to be false *in their minds*
are not colored in jEdit as they think.
For example, "#if FALSE", "#if 1 ... #else" (between #else and #endif),
"#ifdef __GNUC__" (for VC++ users), "#ifdef _MSC_VER" (for gcc users),
...
I think this is bad.

Other issues, for nested conditionals or two blanks, are not for the
idea itself. I know that it is possible to implement the both only in
the mode file.

> Why? because this is a very standard manner of blocking out large
chunks
> of C code.

Personally, I don't think so. If you are using a version control tool
(I believe this is a *standard* of modern C programs), you should simply
remove them.


FYI:
VC++ does color conditional blocks only for compiled sources. This is a
best solution in IDE, but not in the scope of a text editor.
Emacs have cpp-highlight-buffer that seems not to have the above concern
since all configurations are explicitly supplied from user for each
expression. This will be a possible solution.

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

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

Plugin Feature Requests item #2869057, was opened at 2009-09-28 11:44
Message generated for change (Comment added) made by daleanson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=2869057&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: Marcelo Vanzin (vanza)
Summary: ProjectViewer vs HelperLauncher: FSB context menu item

Initial Comment:
ProjectViewer has its own set of helpers to launch for certain file types.
It adds a context menu to the PV dockable. 
It should add the same menu item to the File System Browser too.

What is that helperlauncher for anyway? It seems to be yet another mapping of file types to programs. Why do we need both? Can't we put that mapping in the core?


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

>Comment By: Dale Anson (daleanson)
Date: 2009-09-28 13:21

Message:
Alan, are you asking about the "Open with..." menu item on the PV context
menu?  If so, I'd also like that added to FSB.  It would be great to be
able to open a zip or jar file in an external app to see the contents.

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

Comment By: Alan Ezust (ezust)
Date: 2009-09-28 12:22

Message:
So one idea is to have PV use HelperLauncher for its mapping, so there is
only one mapping.
Another idea is to move HelperLauncher into core and have PV use that.
And another idea is to have PV offer the FSB context menu item directly.
I'm not sure which one is best.



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

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