Alan Ezust | 24 Apr 06:22 2014
Picon

[jedit:plugin-feature-requests] #240 Completion Plugin: better integration w/ core and SideKick

  • Description has changed:

Diff:

--- old +++ new <at> <at> -7,7 +7,7 <at> <at> 3- SideKick: a way to say for some modes, to use a different completion provider/service -4- SideKick: provide a completion service to Completion plugin? +4- SideKick: provide a proper completion service to Completion plugin, and remove entirely the completion UI from SideKick. The goal is to be able to bind a single shortcut to the Completion "complete" action, and it will use sidekick's completer in java mode and clangcompletion when in C++ mode, and also allow users to say "no completion at all" for a given edit mode.

[plugin-feature-requests:#240] Completion Plugin: better integration w/ core and SideKick

Status: open
Group:
Created: Sun Jul 17, 2011 06:13 PM UTC by Alan Ezust
Last Updated: Fri Apr 11, 2014 09:55 PM UTC
Owner: nobody

I would like to see these go into Completion plugin.

1- Completion: A way to choose which completion provider is used on a mode-by-mode basis.

2- Completion: Some way of integrating jEdit's built-in complete action so that
it is one of the choices of completion providers?

3- SideKick: a way to say for some modes, to use a different completion provider/service

4- SideKick: provide a proper completion service to Completion plugin, and remove entirely the completion UI from SideKick.

The goal is to be able to bind a single shortcut to the Completion "complete" action, and it will use sidekick's completer in java mode and clangcompletion when in C++ mode, and also allow users to say "no completion at all" for a given edit mode.

Sent from sourceforge.net because jedit-devel <at> lists.sourceforge.net is subscribed to https://sourceforge.net/p/jedit/plugin-feature-requests/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jedit/admin/plugin-feature-requests/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

------------------------------------------------------------------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
--

-- 
-----------------------------------------------
jEdit Developers' List
jEdit-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jedit-devel
Alan Ezust | 24 Apr 06:15 2014
Picon

[jedit:plugin-feature-requests] #335 Completion plugin: API and UI for displaying help (docs)

[plugin-feature-requests:#335] Completion plugin: API and UI for displaying help (docs)

Status: open
Group:
Created: Thu Apr 24, 2014 04:15 AM UTC by Alan Ezust
Last Updated: Thu Apr 24, 2014 04:15 AM UTC
Owner: nobody

This item is being moved out of sidekick's "future plans" because
eventually, we want to refactor all of sidekick's completion facilities into the Completion plugin. See related ticket:
https://sourceforge.net/p/jedit/plugin-feature-requests/240/

Sent from sourceforge.net because jedit-devel <at> lists.sourceforge.net is subscribed to https://sourceforge.net/p/jedit/plugin-feature-requests/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jedit/admin/plugin-feature-requests/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

------------------------------------------------------------------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
--

-- 
-----------------------------------------------
jEdit Developers' List
jEdit-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jedit-devel
Alan Ezust | 23 Apr 00:10 2014
Picon

[jedit:plugin-patches] #162 Console plugin extension. Allow Project Root Path shortcut in Error Pattern "filename".

Nice that it is getting smaller/simpler but I don't want to pay a runtime penalty if I don't use this feature. So it should check first if the string contains #p# before it does an extra beanshell eval.

[plugin-patches:#162] Console plugin extension. Allow Project Root Path shortcut in Error Pattern "filename".

Status: open
Group: 4.3
Labels: Console
Created: Wed Apr 16, 2014 02:29 PM UTC by lundril
Last Updated: Tue Apr 22, 2014 10:00 PM UTC
Owner: Alan Ezust

This patch is against Console-5.1.3.zip.

What it is about:

I build a C/C++ project with traditional "make".
The C/C++ compiler is called with relative paths.
So I get (for exmple) the following warning messages in the console output:

../../mod1/src/access/checkit.c:1381:23: warning: variable ‘excess’ set but not used

I use the following warning pattern to catch this:

../../([^\:]+)\:([^\:]+)\:. warning\:(.)

Now I have got several copies of the C/C++ project on my PC, but of course I only have got one Error Pattern to catch the warnings for the builds in all the different project directories.

So I want to be able to somehow replace the "../../" with my Project Root path in the Error Pattern matcher.

The following patch allows this by including <p> in your Error Pattern "filename".

For example like this:
filename: <p>/prja/$1

The <p> will be replaced by the Project Root path from the Project Viewer, when the project is build and the error and warning messages are collected in the Error List.

So for example the filename will be modified to:

/home/lundril/checkouts/copy_a/prja/mod1/src/access/checkit.c

because my Project Root is "/home/lundril/checkouts/copy_a".

This patch is intended as a basis for discussion.
TBD/Notes:

  • Maybe using <p> as magic tag to be replaced is not a good idea ?
    (because it is too close to XML tags ?).
    Note: Using $p does not seem to work, because this seems to conflict with
    the regex parser.
  • Maybe more/different tags might also make sense ?
  • Currently ErrorMatcher.matchLine() is modified to use the "expanded"
    filename (fileBackrefExp). Maybe it is better to instead further modify
    ErrorMatcher.match() around the call to MiscUtilities.constructPath() ?
    Maybe leads to cleaner code and completely avoids the
    fileBackrefExp declaration ?

Sent from sourceforge.net because jedit-devel <at> lists.sourceforge.net is subscribed to https://sourceforge.net/p/jedit/plugin-patches/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jedit/admin/plugin-patches/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

------------------------------------------------------------------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
--

-- 
-----------------------------------------------
jEdit Developers' List
jEdit-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jedit-devel
Alan Ezust | 23 Apr 00:00 2014
Picon

[jedit:plugin-patches] #162 Console plugin extension. Allow Project Root Path shortcut in Error Pattern "filename".

Console is supposed to be able to run without ProjectViewer (although it's been a while since I've tested it that way). And most of the PV code that is in Console was designed with an optional dependency in mind. An import at the top can cause problems, and other things can too. At the moment, Console doesn't work for me without ProjectViewer for a reason I have not yet determined.

[plugin-patches:#162] Console plugin extension. Allow Project Root Path shortcut in Error Pattern "filename".

Status: open
Group: 4.3
Labels: Console
Created: Wed Apr 16, 2014 02:29 PM UTC by lundril
Last Updated: Tue Apr 22, 2014 11:06 AM UTC
Owner: Alan Ezust

This patch is against Console-5.1.3.zip.

What it is about:

I build a C/C++ project with traditional "make".
The C/C++ compiler is called with relative paths.
So I get (for exmple) the following warning messages in the console output:

../../mod1/src/access/checkit.c:1381:23: warning: variable ‘excess’ set but not used

I use the following warning pattern to catch this:

../../([^\:]+)\:([^\:]+)\:. warning\:(.)

Now I have got several copies of the C/C++ project on my PC, but of course I only have got one Error Pattern to catch the warnings for the builds in all the different project directories.

So I want to be able to somehow replace the "../../" with my Project Root path in the Error Pattern matcher.

The following patch allows this by including <p> in your Error Pattern "filename".

For example like this:
filename: <p>/prja/$1

The <p> will be replaced by the Project Root path from the Project Viewer, when the project is build and the error and warning messages are collected in the Error List.

So for example the filename will be modified to:

/home/lundril/checkouts/copy_a/prja/mod1/src/access/checkit.c

because my Project Root is "/home/lundril/checkouts/copy_a".

This patch is intended as a basis for discussion.
TBD/Notes:

  • Maybe using <p> as magic tag to be replaced is not a good idea ?
    (because it is too close to XML tags ?).
    Note: Using $p does not seem to work, because this seems to conflict with
    the regex parser.
  • Maybe more/different tags might also make sense ?
  • Currently ErrorMatcher.matchLine() is modified to use the "expanded"
    filename (fileBackrefExp). Maybe it is better to instead further modify
    ErrorMatcher.match() around the call to MiscUtilities.constructPath() ?
    Maybe leads to cleaner code and completely avoids the
    fileBackrefExp declaration ?

Sent from sourceforge.net because jedit-devel <at> lists.sourceforge.net is subscribed to https://sourceforge.net/p/jedit/plugin-patches/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jedit/admin/plugin-patches/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

------------------------------------------------------------------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
--

-- 
-----------------------------------------------
jEdit Developers' List
jEdit-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jedit-devel
lundril | 22 Apr 13:06 2014
Picon

[jedit:plugin-patches] #162 Console plugin extension. Allow Project Root Path shortcut in Error Pattern "filename".

Ok here is another try, this time using BeanShell to get the project path.
That code is the same as what SystemShell.getVariableValue() uses.

This patch is now even shorter than before ;-).

Attachment: project_dir_in_error_pattern_4.patch (920 Bytes; text/x-patch)

[plugin-patches:#162] Console plugin extension. Allow Project Root Path shortcut in Error Pattern "filename".

Status: open
Group: 4.3
Labels: Console
Created: Wed Apr 16, 2014 02:29 PM UTC by lundril
Last Updated: Tue Apr 22, 2014 10:07 AM UTC
Owner: Alan Ezust

This patch is against Console-5.1.3.zip.

What it is about:

I build a C/C++ project with traditional "make".
The C/C++ compiler is called with relative paths.
So I get (for exmple) the following warning messages in the console output:

../../mod1/src/access/checkit.c:1381:23: warning: variable ‘excess’ set but not used

I use the following warning pattern to catch this:

../../([^\:]+)\:([^\:]+)\:. warning\:(.)

Now I have got several copies of the C/C++ project on my PC, but of course I only have got one Error Pattern to catch the warnings for the builds in all the different project directories.

So I want to be able to somehow replace the "../../" with my Project Root path in the Error Pattern matcher.

The following patch allows this by including <p> in your Error Pattern "filename".

For example like this:
filename: <p>/prja/$1

The <p> will be replaced by the Project Root path from the Project Viewer, when the project is build and the error and warning messages are collected in the Error List.

So for example the filename will be modified to:

/home/lundril/checkouts/copy_a/prja/mod1/src/access/checkit.c

because my Project Root is "/home/lundril/checkouts/copy_a".

This patch is intended as a basis for discussion.
TBD/Notes:

  • Maybe using <p> as magic tag to be replaced is not a good idea ?
    (because it is too close to XML tags ?).
    Note: Using $p does not seem to work, because this seems to conflict with
    the regex parser.
  • Maybe more/different tags might also make sense ?
  • Currently ErrorMatcher.matchLine() is modified to use the "expanded"
    filename (fileBackrefExp). Maybe it is better to instead further modify
    ErrorMatcher.match() around the call to MiscUtilities.constructPath() ?
    Maybe leads to cleaner code and completely avoids the
    fileBackrefExp declaration ?

Sent from sourceforge.net because jedit-devel <at> lists.sourceforge.net is subscribed to https://sourceforge.net/p/jedit/plugin-patches/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jedit/admin/plugin-patches/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

------------------------------------------------------------------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
--

-- 
-----------------------------------------------
jEdit Developers' List
jEdit-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jedit-devel
lundril | 22 Apr 12:07 2014
Picon

[jedit:plugin-patches] #162 Console plugin extension. Allow Project Root Path shortcut in Error Pattern "filename".

I am thinking that we can avoid adding the direct dependency
on projectviewer if we can somehow use something like a
bsh/getProjectRoot.bsh script instead of putting the PV classes
directly in ErrorMatcher.java.

I think I am still missing something here:
The code in ConsolePlugin.java, method runProjectCommand() right now reads:

// {{{ runProjectCommand() method private static void runProjectCommand(View view, String prop) { if (jEdit.getPlugin("projectviewer.ProjectPlugin") == null) { GUIUtilities.error(view, "console.pv.not-installed", null); return; } projectviewer.vpt.VPTProject project = projectviewer.ProjectViewer.getActiveProject(view); if (project == null) { GUIUtilities.error(view, "console.pv.no-active-project", null); return; }

which is the same kind of code as I used in the last

https://sourceforge.net/p/jedit/plugin-patches/_discuss/thread/4cbbec1c/91d7/attachment/svn_project_dir_in_error_pattern.patch

patch.
So I guess something about the runProjectCommand() method has to be different, because otherwise why does the proposed patch create more dependency on ProjectViewer, than what the runProjectCommand() method already does ?

[plugin-patches:#162] Console plugin extension. Allow Project Root Path shortcut in Error Pattern "filename".

Status: open
Group: 4.3
Labels: Console
Created: Wed Apr 16, 2014 02:29 PM UTC by lundril
Last Updated: Mon Apr 21, 2014 11:50 PM UTC
Owner: Alan Ezust

This patch is against Console-5.1.3.zip.

What it is about:

I build a C/C++ project with traditional "make".
The C/C++ compiler is called with relative paths.
So I get (for exmple) the following warning messages in the console output:

../../mod1/src/access/checkit.c:1381:23: warning: variable ‘excess’ set but not used

I use the following warning pattern to catch this:

../../([^\:]+)\:([^\:]+)\:. warning\:(.)

Now I have got several copies of the C/C++ project on my PC, but of course I only have got one Error Pattern to catch the warnings for the builds in all the different project directories.

So I want to be able to somehow replace the "../../" with my Project Root path in the Error Pattern matcher.

The following patch allows this by including <p> in your Error Pattern "filename".

For example like this:
filename: <p>/prja/$1

The <p> will be replaced by the Project Root path from the Project Viewer, when the project is build and the error and warning messages are collected in the Error List.

So for example the filename will be modified to:

/home/lundril/checkouts/copy_a/prja/mod1/src/access/checkit.c

because my Project Root is "/home/lundril/checkouts/copy_a".

This patch is intended as a basis for discussion.
TBD/Notes:

  • Maybe using <p> as magic tag to be replaced is not a good idea ?
    (because it is too close to XML tags ?).
    Note: Using $p does not seem to work, because this seems to conflict with
    the regex parser.
  • Maybe more/different tags might also make sense ?
  • Currently ErrorMatcher.matchLine() is modified to use the "expanded"
    filename (fileBackrefExp). Maybe it is better to instead further modify
    ErrorMatcher.match() around the call to MiscUtilities.constructPath() ?
    Maybe leads to cleaner code and completely avoids the
    fileBackrefExp declaration ?

Sent from sourceforge.net because jedit-devel <at> lists.sourceforge.net is subscribed to https://sourceforge.net/p/jedit/plugin-patches/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jedit/admin/plugin-patches/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

------------------------------------------------------------------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
--

-- 
-----------------------------------------------
jEdit Developers' List
jEdit-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jedit-devel
Kay | 22 Apr 03:43 2014
Picon
Picon

Accessibility of jEdit

Hello,
 
I'm contacting this list because I've a special problem to handle jEdit which is maybe a case for developers.
I have to use the VoiceOver screen reader to get access to the OS X operating system (Mavericks).
As a software developer I'm also interested in implementing java applications via jEdit. But I found out that the graphical user interface is not accessible, for example the buttons have no label on it and I can't interact with the screen. So I want to know whether it is possible to use jEdit with VoiceOver.
I already contacted Apple but they couldn't answer that question and only recommend me to contact you.
 
I want to amend that everybody can reproduce my problem by themselves.
The VoiceOver screen reader is installed on every Apple device. It can be activated and deactivated by pressing CMD+F5.
The screen reader runs in the background and has no effect on the regular work. But it shows in a separate window which parts of the GUI a visually impaired person is able to use.
Maybe this feature helps you to find out a solution.
 
I thank you in advance for your reply.
 
Kay
------------------------------------------------------------------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
--

-- 
-----------------------------------------------
jEdit Developers' List
jEdit-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jedit-devel
Alan Ezust | 22 Apr 01:50 2014
Picon

[jedit:plugin-patches] #162 Console plugin extension. Allow Project Root Path shortcut in Error Pattern "filename".

  • status: closed-rejected --> open

[plugin-patches:#162] Console plugin extension. Allow Project Root Path shortcut in Error Pattern "filename".

Status: open
Group: 4.3
Labels: Console
Created: Wed Apr 16, 2014 02:29 PM UTC by lundril
Last Updated: Mon Apr 21, 2014 11:47 PM UTC
Owner: Alan Ezust

This patch is against Console-5.1.3.zip.

What it is about:

I build a C/C++ project with traditional "make".
The C/C++ compiler is called with relative paths.
So I get (for exmple) the following warning messages in the console output:

../../mod1/src/access/checkit.c:1381:23: warning: variable ‘excess’ set but not used

I use the following warning pattern to catch this:

../../([^\:]+)\:([^\:]+)\:. warning\:(.)

Now I have got several copies of the C/C++ project on my PC, but of course I only have got one Error Pattern to catch the warnings for the builds in all the different project directories.

So I want to be able to somehow replace the "../../" with my Project Root path in the Error Pattern matcher.

The following patch allows this by including <p> in your Error Pattern "filename".

For example like this:
filename: <p>/prja/$1

The <p> will be replaced by the Project Root path from the Project Viewer, when the project is build and the error and warning messages are collected in the Error List.

So for example the filename will be modified to:

/home/lundril/checkouts/copy_a/prja/mod1/src/access/checkit.c

because my Project Root is "/home/lundril/checkouts/copy_a".

This patch is intended as a basis for discussion.
TBD/Notes:

  • Maybe using <p> as magic tag to be replaced is not a good idea ?
    (because it is too close to XML tags ?).
    Note: Using $p does not seem to work, because this seems to conflict with
    the regex parser.
  • Maybe more/different tags might also make sense ?
  • Currently ErrorMatcher.matchLine() is modified to use the "expanded"
    filename (fileBackrefExp). Maybe it is better to instead further modify
    ErrorMatcher.match() around the call to MiscUtilities.constructPath() ?
    Maybe leads to cleaner code and completely avoids the
    fileBackrefExp declaration ?

Sent from sourceforge.net because jedit-devel <at> lists.sourceforge.net is subscribed to https://sourceforge.net/p/jedit/plugin-patches/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jedit/admin/plugin-patches/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

------------------------------------------------------------------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
--

-- 
-----------------------------------------------
jEdit Developers' List
jEdit-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jedit-devel
Alan Ezust | 22 Apr 01:47 2014
Picon

[jedit:plugin-patches] #162 Console plugin extension. Allow Project Root Path shortcut in Error Pattern "filename".

Exactly, FileOpenerService only works for unambiguous filenames, while your patch does in fact set the correct path based on the project variable.
Glad to see that FileOpenerService almost solves your problem!

I am thinking that we can avoid adding the direct dependency on projectviewer if we can somehow reuse the bsh/getProjectRoot.bsh script instead of putting the PV classes directly in ErrorMatcher.java. If you can do that, then there is no trade-off to accepting your patch.

[plugin-patches:#162] Console plugin extension. Allow Project Root Path shortcut in Error Pattern "filename".

Status: closed-rejected
Group: 4.3
Labels: Console
Created: Wed Apr 16, 2014 02:29 PM UTC by lundril
Last Updated: Mon Apr 21, 2014 11:41 PM UTC
Owner: Alan Ezust

This patch is against Console-5.1.3.zip.

What it is about:

I build a C/C++ project with traditional "make".
The C/C++ compiler is called with relative paths.
So I get (for exmple) the following warning messages in the console output:

../../mod1/src/access/checkit.c:1381:23: warning: variable ‘excess’ set but not used

I use the following warning pattern to catch this:

../../([^\:]+)\:([^\:]+)\:. warning\:(.)

Now I have got several copies of the C/C++ project on my PC, but of course I only have got one Error Pattern to catch the warnings for the builds in all the different project directories.

So I want to be able to somehow replace the "../../" with my Project Root path in the Error Pattern matcher.

The following patch allows this by including <p> in your Error Pattern "filename".

For example like this:
filename: <p>/prja/$1

The <p> will be replaced by the Project Root path from the Project Viewer, when the project is build and the error and warning messages are collected in the Error List.

So for example the filename will be modified to:

/home/lundril/checkouts/copy_a/prja/mod1/src/access/checkit.c

because my Project Root is "/home/lundril/checkouts/copy_a".

This patch is intended as a basis for discussion.
TBD/Notes:

  • Maybe using <p> as magic tag to be replaced is not a good idea ?
    (because it is too close to XML tags ?).
    Note: Using $p does not seem to work, because this seems to conflict with
    the regex parser.
  • Maybe more/different tags might also make sense ?
  • Currently ErrorMatcher.matchLine() is modified to use the "expanded"
    filename (fileBackrefExp). Maybe it is better to instead further modify
    ErrorMatcher.match() around the call to MiscUtilities.constructPath() ?
    Maybe leads to cleaner code and completely avoids the
    fileBackrefExp declaration ?

Sent from sourceforge.net because jedit-devel <at> lists.sourceforge.net is subscribed to https://sourceforge.net/p/jedit/plugin-patches/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jedit/admin/plugin-patches/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

------------------------------------------------------------------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
--

-- 
-----------------------------------------------
jEdit Developers' List
jEdit-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jedit-devel
lundril | 22 Apr 01:41 2014
Picon

[jedit:plugin-patches] #162 Console plugin extension. Allow Project Root Path shortcut in Error Pattern "filename".

Not sure if replying via E-Mail works, so I just re-post it here:

Let me clarify what I meant. You have to CLICK on the error (even if it is
displaying the wrong filename) to see anything happen with
FileOpenerService.

Ahh. I should have found that out myself.
I just looked at the filenames but did not even try to click on them.

So clicking on them works (FastOpen pops up).
In case the filename is unambiguous (like the "hello.c" it just opens the right file, so that's fine.

But in the case of "srca/file.c", "srcb/file.c" this still is a problem:
Because FastOpen cannot decide which of these two files to open (since they
have the same basename), that basically means you have to select the right
file for each warning in these files. So to be more precise: If I have got
two warnings in "srca/file.c", then I have to use FastOpen for each of
these two warnings.

The patch I proposed just completely circumvents the problem by directly
providing the correct absolute path.
So on the one hand this means the ErrorList window shows the right path
and additionally it just works as expected.

So I would say FastOpen almost solves the problem.
I still think, the patch I proposed just does it in a lot more direct manner.

[plugin-patches:#162] Console plugin extension. Allow Project Root Path shortcut in Error Pattern "filename".

Status: closed-rejected
Group: 4.3
Labels: Console
Created: Wed Apr 16, 2014 02:29 PM UTC by lundril
Last Updated: Mon Apr 21, 2014 03:31 PM UTC
Owner: Alan Ezust

This patch is against Console-5.1.3.zip.

What it is about:

I build a C/C++ project with traditional "make".
The C/C++ compiler is called with relative paths.
So I get (for exmple) the following warning messages in the console output:

../../mod1/src/access/checkit.c:1381:23: warning: variable ‘excess’ set but not used

I use the following warning pattern to catch this:

../../([^\:]+)\:([^\:]+)\:. warning\:(.)

Now I have got several copies of the C/C++ project on my PC, but of course I only have got one Error Pattern to catch the warnings for the builds in all the different project directories.

So I want to be able to somehow replace the "../../" with my Project Root path in the Error Pattern matcher.

The following patch allows this by including <p> in your Error Pattern "filename".

For example like this:
filename: <p>/prja/$1

The <p> will be replaced by the Project Root path from the Project Viewer, when the project is build and the error and warning messages are collected in the Error List.

So for example the filename will be modified to:

/home/lundril/checkouts/copy_a/prja/mod1/src/access/checkit.c

because my Project Root is "/home/lundril/checkouts/copy_a".

This patch is intended as a basis for discussion.
TBD/Notes:

  • Maybe using <p> as magic tag to be replaced is not a good idea ?
    (because it is too close to XML tags ?).
    Note: Using $p does not seem to work, because this seems to conflict with
    the regex parser.
  • Maybe more/different tags might also make sense ?
  • Currently ErrorMatcher.matchLine() is modified to use the "expanded"
    filename (fileBackrefExp). Maybe it is better to instead further modify
    ErrorMatcher.match() around the call to MiscUtilities.constructPath() ?
    Maybe leads to cleaner code and completely avoids the
    fileBackrefExp declaration ?

Sent from sourceforge.net because jedit-devel <at> lists.sourceforge.net is subscribed to https://sourceforge.net/p/jedit/plugin-patches/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jedit/admin/plugin-patches/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

------------------------------------------------------------------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
--

-- 
-----------------------------------------------
jEdit Developers' List
jEdit-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jedit-devel
Jayawardan | 21 Apr 22:28 2014
Picon

[jedit:bugs] #3857 Duplicate buffer

[bugs:#3857] Duplicate buffer

Status: open
Group: severe bug
Created: Mon Apr 21, 2014 08:28 PM UTC by Jayawardan
Last Updated: Mon Apr 21, 2014 08:28 PM UTC
Owner: nobody

Version : 5.1.0 (this issue has been there in most previous versions)
Platform : Linux
Java version : jdk1.7.0_25-32 (this issue has been there in most previous versions)
Issue: jEdit opens the currently editing file in a new buffer.

How to reproduce:
Open a link (symbolic link) to a text file. It looks fine. Update something once.
Now remove the link, and recreate the link (with the same name) to a different text file.
Try updating and then find something in the open buffer. jEdit opens a duplicate buffer !

Sent from sourceforge.net because jedit-devel <at> lists.sourceforge.net is subscribed to https://sourceforge.net/p/jedit/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jedit/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

------------------------------------------------------------------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
--

-- 
-----------------------------------------------
jEdit Developers' List
jEdit-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jedit-devel

Gmane