jedit-devel Mailing List for jEdit

Feature Requests item #2696564, was opened at 2009-03-20 17:02
Message generated for change (Comment added) made by ehtyar
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350588&aid=2696564&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: Ehtyar (ehtyar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Text Block Selection via Gutter Right-Click

Initial Comment:
As per my first request here: http://community.jedit.org/?q=node/view/4151, I'd like to request the context menu not popup when the user right-clicks on the gutter to better facilitate selection of a text block.

Thanks guys, Ehtyar.

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

>Comment By: Ehtyar (ehtyar)
Date: 2009-04-01 10:22

Message:
Hi guys. Sorry for neglecting this, I didn't expect such a response.

As has been mentioned, selecting from the beginning of a line is terribly
inefficient. Not to mention, when you get to the end of the block you wish
to select, you either have to drag your mouse right to end of the last line
of block, or copy the newline from the beginning of line after.

This is purely a convenience feature.

Another thing I've since noticed is that the right click only selects once
you start dragging. It would be very handy to have a right click on the
gutter select the current line immediately without the necessity to drag at
all, which makes it easy to select beyond the single line if selecting only
the one line was your intention.

Thanks, Ehtyar.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-04-01 07:46

Message:
Can you attach a screenshot with the slim gutter?
In jEdit, you can also select lines by dragging the mouse in the small
area between the gutter and the beginning of the text - there are a few
pixels of space, I guess exactly for this purpose.

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

Comment By: Robert Schwenn (rschwenn)
Date: 2009-04-01 07:16

Message:
Of course the line numbers can be disabled in UltraEdit, too. And like in
jEdit the related gutter will become slim in this case. But in every case
there are two gutters.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-04-01 03:28

Message:
I noticed that in jEdit, the line numbers, if shown in the gutter, also
affect folding. Even if you don't click directly on the fold icons, but
instead on the line numbers next to them, the folds are expanded or
collapsed. While this can be changed, there's always the option of not
showing any line numbers at all, in which case the gutter contains only the
folding and the markers, in the same small area.
What happens with UltraEdit when you don't show line numbers? Is there a
possibility for that? Does the gutter get smaller?

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

Comment By: Robert Schwenn (rschwenn)
Date: 2009-03-28 05:29

Message:
I just had a look at UltraEdit. There are two "gutters" with different
colors: one for line numbers, markers and text selecting and another for
folding. So You can select lines of text with left-click (and drag) as in
other text processors.

But why not use right-click for selecting text lines? Nobody needs a
right-click menu in the gutter, I think.


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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-03-28 03:58

Message:
There is some point here - marking a sequence of text lines by dragging in
the text area is not easy. The space between the gutter and the beginning
of the text, which is used for selecting an entire line, is very small and
hard to use. The gutter is a lot wider, I think this is the reason for this
request.

It should be easier to mark a sequence of lines with the mouse.

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

Comment By: Robert Schwenn (rschwenn)
Date: 2009-03-21 08:17

Message:
I've never had the desire to right-click the gutter :-).
Why do You?


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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-03-20 19:53

Message:
- Why do you want to select text blocks from the gutter? Why not just do
the selection from the text area itself? (e.g. putting the caret at the
first column, and either using the keyboard or dragging the mouse)
- I also do not find it useful to have the context menu shown for
right-clicks in the gutter, but you and I are just two users. What do
others think?

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

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

Bugs item #2723959, was opened at 2009-03-31 14:21
Message generated for change (Tracker Item Submitted) made by elberry
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2723959&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: editor core
Group: Regressive (new to devel)
Status: Open
Resolution: None
Priority: 6
Private: No
Submitted By: Townsfolk (elberry)
Assigned to: Nobody/Anonymous (nobody)
Summary: Deleted file doesn't show as dirty buffer.

Initial Comment:
Unchanged, but deleted files are not appearing as dirty buffers as they did previously.

Steps to reproduce:
Create a file and save it.
Now delete the file through normal OS methods.
Go back to jEdit - you get the "File changed on disk" dialog. Click "close".
Notice that the buffer is not marked dirty.

Everything behaves as if it is non-existent on the filesystem - eg. Saving the file at this point brings up the file dialog to chose the save location. The buffer is just not marked as dirty as it was in previous versions.


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

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

Feature Requests item #2696564, was opened at 2009-03-20 08:02
Message generated for change (Comment added) made by shlomy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350588&aid=2696564&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: Ehtyar (ehtyar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Text Block Selection via Gutter Right-Click

Initial Comment:
As per my first request here: http://community.jedit.org/?q=node/view/4151, I'd like to request the context menu not popup when the user right-clicks on the gutter to better facilitate selection of a text block.

Thanks guys, Ehtyar.

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

>Comment By: Shlomy Reinstein (shlomy)
Date: 2009-03-31 23:46

Message:
Can you attach a screenshot with the slim gutter?
In jEdit, you can also select lines by dragging the mouse in the small
area between the gutter and the beginning of the text - there are a few
pixels of space, I guess exactly for this purpose.

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

Comment By: Robert Schwenn (rschwenn)
Date: 2009-03-31 23:16

Message:
Of course the line numbers can be disabled in UltraEdit, too. And like in
jEdit the related gutter will become slim in this case. But in every case
there are two gutters.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-03-31 19:28

Message:
I noticed that in jEdit, the line numbers, if shown in the gutter, also
affect folding. Even if you don't click directly on the fold icons, but
instead on the line numbers next to them, the folds are expanded or
collapsed. While this can be changed, there's always the option of not
showing any line numbers at all, in which case the gutter contains only the
folding and the markers, in the same small area.
What happens with UltraEdit when you don't show line numbers? Is there a
possibility for that? Does the gutter get smaller?

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

Comment By: Robert Schwenn (rschwenn)
Date: 2009-03-27 21:29

Message:
I just had a look at UltraEdit. There are two "gutters" with different
colors: one for line numbers, markers and text selecting and another for
folding. So You can select lines of text with left-click (and drag) as in
other text processors.

But why not use right-click for selecting text lines? Nobody needs a
right-click menu in the gutter, I think.


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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-03-27 19:58

Message:
There is some point here - marking a sequence of text lines by dragging in
the text area is not easy. The space between the gutter and the beginning
of the text, which is used for selecting an entire line, is very small and
hard to use. The gutter is a lot wider, I think this is the reason for this
request.

It should be easier to mark a sequence of lines with the mouse.

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

Comment By: Robert Schwenn (rschwenn)
Date: 2009-03-20 23:17

Message:
I've never had the desire to right-click the gutter :-).
Why do You?


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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-03-20 10:53

Message:
- Why do you want to select text blocks from the gutter? Why not just do
the selection from the text area itself? (e.g. putting the caret at the
first column, and either using the keyboard or dragging the mouse)
- I also do not find it useful to have the context menu shown for
right-clicks in the gutter, but you and I are just two users. What do
others think?

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

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

Feature Requests item #2696564, was opened at 2009-03-20 07:02
Message generated for change (Comment added) made by rschwenn
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350588&aid=2696564&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: Ehtyar (ehtyar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Text Block Selection via Gutter Right-Click

Initial Comment:
As per my first request here: http://community.jedit.org/?q=node/view/4151, I'd like to request the context menu not popup when the user right-clicks on the gutter to better facilitate selection of a text block.

Thanks guys, Ehtyar.

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

>Comment By: Robert Schwenn (rschwenn)
Date: 2009-03-31 22:16

Message:
Of course the line numbers can be disabled in UltraEdit, too. And like in
jEdit the related gutter will become slim in this case. But in every case
there are two gutters.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-03-31 18:28

Message:
I noticed that in jEdit, the line numbers, if shown in the gutter, also
affect folding. Even if you don't click directly on the fold icons, but
instead on the line numbers next to them, the folds are expanded or
collapsed. While this can be changed, there's always the option of not
showing any line numbers at all, in which case the gutter contains only the
folding and the markers, in the same small area.
What happens with UltraEdit when you don't show line numbers? Is there a
possibility for that? Does the gutter get smaller?

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

Comment By: Robert Schwenn (rschwenn)
Date: 2009-03-27 19:29

Message:
I just had a look at UltraEdit. There are two "gutters" with different
colors: one for line numbers, markers and text selecting and another for
folding. So You can select lines of text with left-click (and drag) as in
other text processors.

But why not use right-click for selecting text lines? Nobody needs a
right-click menu in the gutter, I think.


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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-03-27 17:58

Message:
There is some point here - marking a sequence of text lines by dragging in
the text area is not easy. The space between the gutter and the beginning
of the text, which is used for selecting an entire line, is very small and
hard to use. The gutter is a lot wider, I think this is the reason for this
request.

It should be easier to mark a sequence of lines with the mouse.

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

Comment By: Robert Schwenn (rschwenn)
Date: 2009-03-20 22:17

Message:
I've never had the desire to right-click the gutter :-).
Why do You?


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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-03-20 09:53

Message:
- Why do you want to select text blocks from the gutter? Why not just do
the selection from the text area itself? (e.g. putting the caret at the
first column, and either using the keyboard or dragging the mouse)
- I also do not find it useful to have the context menu shown for
right-clicks in the gutter, but you and I are just two users. What do
others think?

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

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

Plugin Feature Requests item #2723116, was opened at 2009-03-31 11:57
Message generated for change (Settings changed) made by hertzhaft
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=2723116&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: 2
Private: No
Submitted By: Ben Golding (bgolding)
>Assigned to: Martin Raspe (hertzhaft)
Summary: PerlSideKick should allow filtering predeclarations

Initial Comment:
jEdit 4.3pre16 / Windows XP + SP3 / Sun JRE 1.6.0_11
------------
File --> New in Mode --> perl
Enter the following:
  sub foo();
  sub foo() { }
Save as "foo.pl"
Open Sidekick. The subroutine foo appears twice, because it is predeclared.
------------
This is by design, I guess. However I always predeclare all perl subroutines, which allows to avoid some warnings when using mutual recursion etc. Then the sidekick gets cluttered.

So I would like to add an option to filter out the extra entries for predeclarations.

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

>Comment By: Martin Raspe (hertzhaft)
Date: 2009-03-31 18:38

Message:
Yes, it's by design, as subroutines with the same name can be in different
"package" sections in the same file. I'll look into the code to see if the
subroutine regex can be changed to disregard  predeclarations.

Martin

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

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

Feature Requests item #2696564, was opened at 2009-03-20 08:02
Message generated for change (Comment added) made by shlomy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350588&aid=2696564&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: Ehtyar (ehtyar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Text Block Selection via Gutter Right-Click

Initial Comment:
As per my first request here: http://community.jedit.org/?q=node/view/4151, I'd like to request the context menu not popup when the user right-clicks on the gutter to better facilitate selection of a text block.

Thanks guys, Ehtyar.

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

>Comment By: Shlomy Reinstein (shlomy)
Date: 2009-03-31 19:28

Message:
I noticed that in jEdit, the line numbers, if shown in the gutter, also
affect folding. Even if you don't click directly on the fold icons, but
instead on the line numbers next to them, the folds are expanded or
collapsed. While this can be changed, there's always the option of not
showing any line numbers at all, in which case the gutter contains only the
folding and the markers, in the same small area.
What happens with UltraEdit when you don't show line numbers? Is there a
possibility for that? Does the gutter get smaller?

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

Comment By: Robert Schwenn (rschwenn)
Date: 2009-03-27 21:29

Message:
I just had a look at UltraEdit. There are two "gutters" with different
colors: one for line numbers, markers and text selecting and another for
folding. So You can select lines of text with left-click (and drag) as in
other text processors.

But why not use right-click for selecting text lines? Nobody needs a
right-click menu in the gutter, I think.


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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-03-27 19:58

Message:
There is some point here - marking a sequence of text lines by dragging in
the text area is not easy. The space between the gutter and the beginning
of the text, which is used for selecting an entire line, is very small and
hard to use. The gutter is a lot wider, I think this is the reason for this
request.

It should be easier to mark a sequence of lines with the mouse.

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

Comment By: Robert Schwenn (rschwenn)
Date: 2009-03-20 23:17

Message:
I've never had the desire to right-click the gutter :-).
Why do You?


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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-03-20 10:53

Message:
- Why do you want to select text blocks from the gutter? Why not just do
the selection from the text area itself? (e.g. putting the caret at the
first column, and either using the keyboard or dragging the mouse)
- I also do not find it useful to have the context menu shown for
right-clicks in the gutter, but you and I are just two users. What do
others think?

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

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

Hi, all

During last time i`m spending mush of time using jEdit with PHP mode.
So i`ve found that the current php editing mode doesn`t have some
keywords/function (for example json_* or __DIR__).

Is it possible to grant me access to this file inside SVN to add such
minor changes without tracker requests?

I`ve already access to plugin/FTP  & plugins/RecentBufferSwitcher code
repositories but can`t commit the edit modes.


-- 
Voituk Vadim
vad...@gm...
ICQ#944328
Skype: voituk

Plugin Feature Requests item #2723116, was opened at 2009-03-31 10:57
Message generated for change (Settings changed) made by bgolding
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=2723116&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: 2
Private: No
Submitted By: Ben Golding (bgolding)
Assigned to: Nobody/Anonymous (nobody)
Summary: PerlSideKick should allow filtering predeclarations

Initial Comment:
jEdit 4.3pre16 / Windows XP + SP3 / Sun JRE 1.6.0_11
------------
File --> New in Mode --> perl
Enter the following:
  sub foo();
  sub foo() { }
Save as "foo.pl"
Open Sidekick. The subroutine foo appears twice, because it is predeclared.
------------
This is by design, I guess. However I always predeclare all perl subroutines, which allows to avoid some warnings when using mutual recursion etc. Then the sidekick gets cluttered.

So I would like to add an option to filter out the extra entries for predeclarations.

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

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

Plugin Feature Requests item #2723116, was opened at 2009-03-31 10:57
Message generated for change (Tracker Item Submitted) made by bgolding
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=2723116&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: Ben Golding (bgolding)
Assigned to: Nobody/Anonymous (nobody)
Summary: PerlSideKick should allow filtering predeclarations

Initial Comment:
jEdit 4.3pre16 / Windows XP + SP3 / Sun JRE 1.6.0_11
------------
File --> New in Mode --> perl
Enter the following:
  sub foo();
  sub foo() { }
Save as "foo.pl"
Open Sidekick. The subroutine foo appears twice, because it is predeclared.
------------
This is by design, I guess. However I always predeclare all perl subroutines, which allows to avoid some warnings when using mutual recursion etc. Then the sidekick gets cluttered.

So I would like to add an option to filter out the extra entries for predeclarations.

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

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

On Tue, Mar 31, 2009 at 5:32 AM, Marcelo Vanzin
<va...@us...> wrote:
> On Mon, Mar 30, 2009 at 1:50 PM, Shlomy Reinstein <sre...@gm...> wrote:
>> One thing about the OptionsService - why not use ordinary OptionPane
>> objects for the service? Currently, for a simple option pane, I need
>> to write two classes: One for the implementation of OptionsService,
>> and the other is the actual option pane.
>
> For two reasons:
>
> (i) Service instances are "singletons". So if I instantiate you
> service, I'll always be using the same instance.

Right, I forgot about that.

> This has the following side-effects:
>
> - I need a new method in OptionPane and another in OptionGroup to
> notify the service about what is being edited at the time it's used.

Right. The project being edited was previously retrieved by a static
function in ProjectOptions, so the current way it better. Initially I
didn't notice it and it took me a few minutes to realize that the
service actually gets the project as parameter... The pvdebug classes
do not make any use of the project - maybe it's better to add some
usage there, just for reference.

> (ii) is more about preference, but I think the issues in (i) make this
> approach desirable. It also makes it pretty sample to do what I did
> for the VersionControlService (which provides its own option panes by
> just extending OptionsService).

I didn't notice you've made such changes already to a concrete plugin
that makes use of the project options API. I thought that pvdebug was
the only reference, so I looked there. I think It's better to add some
content in it.

> On the flip side, by writing the OptionsService implementation you
> don't need to write java code under weirdly-named properties in the
> plugin's property file, which is something I never liked.

I agree.
All in all, the changes I had to do were pretty small, it's only the
time it took me to find out how to change it exactly that annoyed me a
little. Maybe I should have tracked the PV commits and not be
surprised by this.

Shlomy

On Mon, Mar 30, 2009 at 1:50 PM, Shlomy Reinstein <sre...@gm...> wrote:
> One thing about the OptionsService - why not use ordinary OptionPane
> objects for the service? Currently, for a simple option pane, I need
> to write two classes: One for the implementation of OptionsService,
> and the other is the actual option pane.

For two reasons:

(i) Service instances are "singletons". So if I instantiate you
service, I'll always be using the same instance. This has the
following side-effects:

- I need a new method in OptionPane and another in OptionGroup to
notify the service about what is being edited at the time it's used.
- The memory used by the UI of your option pane will not be
automatically  collected after the UI is disposed, since the instance
won't go away.
- I can't have two instances of the panes with different data being
shown (not that it's possible to have two option dialogs open right
now, but still).

(ii) This is more cosmetic than functional, since I don't think the
code enforces it: but even though all implementations would just
extend from OptionPane or OptionGroup, I need different service names
for the different option panes; I can't just use
"org.gjp.sp.jedit.OptionPane" to define a PV-specific service, I think
it's reasonable to assume that jEdit owns that namespace and plugins
should not use it to extend their own functionality. So I have to
create a phony name that doesn't match an existing class or interface,
which looks weird to me.

(ii) is more about preference, but I think the issues in (i) make this
approach desirable. It also makes it pretty sample to do what I did
for the VersionControlService (which provides its own option panes by
just extending OptionsService).

On the flip side, by writing the OptionsService implementation you
don't need to write java code under weirdly-named properties in the
plugin's property file, which is something I never liked.


-- 
Marcelo Vanzin
mmv...@gm...
"Life's too short to drink cheap beer."

Bugs item #2688352, was opened at 2009-03-16 10:04
Message generated for change (Settings changed) made by kpouer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2688352&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: Closed
Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Matthieu Casanova (kpouer)
Assigned to: Nobody/Anonymous (nobody)
Summary: @LongLink file ?

Initial Comment:
Hi, using the 4.3pre16 java installer I got a file named
@LongLink

that contained

doc/api/org/gjt/sp/jedit/gui/class-use/DockableWindowManagerImpl.DockableWindowConfig.PerspectiveHandler.html 


I'm on Windows and use JDK 1.6

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

Comment By: kerik (kerik-sf)
Date: 2009-03-16 19:31

Message:
Hi,
this has already been reported in ticket 
[2327520] java installer : filename truncated if too long
https://sourceforge.net/tracker/?func=detail&aid=2327520&group_id=588&atid=100588

I'm waiting for license advices before doing anything...

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

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

One thing about the OptionsService - why not use ordinary OptionPane
objects for the service? Currently, for a simple option pane, I need
to write two classes: One for the implementation of OptionsService,
and the other is the actual option pane.

I'm all for the service mechanism, but I think this small overhead
could be removed. For example, there can be one service for option
panes and another for option groups.

Shlomy

On Mon, Mar 30, 2009 at 8:23 AM, Marcelo Vanzin
<va...@us...> wrote:
> I just wanted to give people who write plugins that depend on
> ProjectViewer a heads up about the latest API changes.
>
> As of rev #14866, a lot has changed that will probably affect other
> plugins (if they weren't yet affected by the changes to events and
> other parts of the API). Mainly, the way plugins can provide option
> panes to be shown when a user edits a project has changed - it now
> uses a service (think services.xml) instead of the jEdit-style
> properties.
>
> You can look at the debug plugin (pvdebug subdirectory in PV's
> sources) for an example of how to use it.
>
> As of this change, I think I've finished all the API changes I wanted
> to make to ProjectViewer, along with all the features I wanted to
> implement. So if you have the chance to compile and test the trunk
> version, and also send feedback about the API itself, that would be
> great. Just remember that the trunk version requires jEdit 4.3pre17 (I
> needed to make a slight change to jEdit's API to implement one feature
> I wanted...).
>
> --
> Marcelo Vanzin
> mmv...@gm...
> "Life's too short to drink cheap beer."
>
> ------------------------------------------------------------------------------
> --
> -----------------------------------------------
> jEdit Developers' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>

I just wanted to give people who write plugins that depend on
ProjectViewer a heads up about the latest API changes.

As of rev #14866, a lot has changed that will probably affect other
plugins (if they weren't yet affected by the changes to events and
other parts of the API). Mainly, the way plugins can provide option
panes to be shown when a user edits a project has changed - it now
uses a service (think services.xml) instead of the jEdit-style
properties.

You can look at the debug plugin (pvdebug subdirectory in PV's
sources) for an example of how to use it.

As of this change, I think I've finished all the API changes I wanted
to make to ProjectViewer, along with all the features I wanted to
implement. So if you have the chance to compile and test the trunk
version, and also send feedback about the API itself, that would be
great. Just remember that the trunk version requires jEdit 4.3pre17 (I
needed to make a slight change to jEdit's API to implement one feature
I wanted...).

-- 
Marcelo Vanzin
mmv...@gm...
"Life's too short to drink cheap beer."

Plugin Bugs item #2687829, was opened at 2009-03-15 10:32
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=2687829&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alan Ezust (ezust)
Assigned to: Nobody/Anonymous (nobody)
>Summary: XSearch: replace in project - modified buffers

Initial Comment:
Before buffersets, when I did a multifile replace, I'd see each of the changed files opened and dirty in my buffer list. 

It seems that is no longer the case.

Not directly related, but I would expect to see the results shown in the hypersearch pane, but they are not.



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

>Comment By: Alan Ezust (ezust)
Date: 2009-03-29 17:05

Message:
ok, i guess the bug is in XSearch then, but last time I checked, it seems
XSearch is doing the same thing as the regular search dialog when it opens
files... but i could be wrong. I guess I will have to double check I know
there is some duplicated code from an older version of jedit in that
plugin.

But replace in project is not the only way that I find that sometimes PV
thinks a file is open when I dont' see it open in the bufferlist until I
click on it. When I come up with a good testcase to demonstrate i will open
another bug report though.




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

Comment By: Marcelo Vanzin (vanza)
Date: 2009-03-28 13:19

Message:
PV just calls SearchDialog.showSearchDialog(); it has no control about what
buffers are opened, how, where or when. jEdit's search system is the code
that opens files (or in your case Xsearch).

I can't see how this can possibly be a PV bug.

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

Comment By: Alan Ezust (ezust)
Date: 2009-03-28 10:47

Message:
Oh and here is another thing: projectviewer shows them as open in the PV
dockable, while it does not show up in any of the buffer lists. Not even
the global one!
So I think this is a bug in PV.


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

Comment By: Alan Ezust (ezust)
Date: 2009-03-28 10:35

Message:
The bug is that some of the buffers that are modified are not added to the
bufferset of the current view, so I can't see them as "modified buffers"
until I exit jEdit, at which point I see them in the list of "buffers
modified - what do you want to do about it?" list of files. And so there is
now way to see those changed files.

I should mention, I am also using XSearch plugin, so maybe this is only
reproducible with PV trunk and XSearch.

Also, I see this on windows.


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

Comment By: Marcelo Vanzin (vanza)
Date: 2009-03-20 22:16

Message:
What is the bug here? It seems that it's doing what it's supposed to do:
buffers open up as dirty; since it's a search & replace, you get no search
results.

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

Comment By: Alan Ezust (ezust)
Date: 2009-03-19 15:47

Message:
Sorry, this is a bug in ProjectViewer's "Search in Project Root", not in
jEdit core.


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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-03-19 15:46

Message:
The replacements do not show in the hypersearch results even for a single
file search. I guess they were never meant to be shown there. Maybe because
it's replace rather than search.

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

Comment By: Townsfolk (elberry)
Date: 2009-03-19 15:29

Message:
I too am seeing the files opened and dirty, and I also do not see the
results in HyperSearch, even though I've checked the HS box.

I'm using the normal search dialog ([CTRL|CMD] + F) and setting it to
search all buffers.

I tested this in 4.3pre16, and 4.2final, with the same results.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-03-19 15:10

Message:
The first part works fine for me; I see the modified files open dirty in my
buffer tabs (also in buffer switcher).
I do not see the results shown in the hypersearch pane, though; are you
sure they used to?


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

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

Hi,

I would like to add a code completion feature in CtagsInterface, that
will allow the user to complete any prefix from the tag database.
The completion can be a simple string (identifier completion), or a
parametrized one, like functions with parameters. For example, suppose
the following function is in the tag database:
  getProperty(String propName, String defaultValue)

And you type:
  getPro
and invoke the "code completion" action of CtagsInterface, it should
expand to the above function, and automatically select the "String
propName" text, so when you type in it, whatever you type replaces the
parameter declaration. Then, clicking <tab> should move to the next
parameter, and so on.

There is a wonderful plugin, named SuperAbbrevs, that allows
user-configurable abbreviations like the above examples, and more. I
have a few questions:
1. Is SuperAbbrevs suited for usage by CtagsInterface as I described above?
2. Do you think there's any problem with making SuperAbbrevs a
dependency of CtagsInterface?
3. How do you suggest to use SuperAbbrevs by CtagsInterface? I guess
it's not feasible to generate all possible abbreviations in advance.
But once the user used code-completion on some function, should the
abbreviation remain, or should it be discarded (i.e. temporary each
time just for a single invocation)?

Furthermore, code completion requires some window to present the
available completions. Is there a good library / abstract completion
window or dialog that I can use to let the user select from the
possible completions? I saw the basic one defined by jEdit, but it is
really too basic. SideKick provides a better one, but I don't like
ctagsInterface to depends on SideKick.

Thanks,
Shlomy

Kevin Hunter wrote:
> At 4:53pm -0400 on Thu, 26 Mar 2009, Romain Francois wrote:
>   
>> but this does not work because MARK_PREVIOUS does not know about 
>> DELEGATE. Is there another way I can achieve it ?
>>     
>
> Have you looked at the jEdit documentation on mode writing?
>   
yes
> http://www.jedit.org/users-guide/writing-modes.html
>
> Or, specifically, have you tried SEQ or SEQ_REGEXP?
>   
I am probably misreading something. With the code below:

<code>
stop <- function( ... ){
    print ("bla" )
}
f <- function( x ){
    stop( "ouch" )
}
</code>

I am interested in highlighting the first instance of "stop" in a way, 
and the second in another, because it is a function call. So the 
MARK_PREVIOUS seems to be the way to go for separating the token i am 
interested in (stop) and the opening bracket, except I want to further 
analyze the token to dispatch the content to a KEYWORD of my choice, so 
the idea was to delegate its interpretation to another ruleset 
containing the keywords.

If I do a <SEQ DELEGATE="kw">stop</SEQ> then how is the "kw" ruleset 
going to know about whether there is a bracket after or not.

I guess I could match stop[^\(]( with SEQ_REGEXP and then flush away the 
bracket in the kw ruleset, but it seems both inelegant and inefficient 
to me.

> http://www.jedit.org/users-guide/mode-rule-seq.html
> http://www.jedit.org/users-guide/mode-rule-seq-regexp.html
>
> Kevin
>   


-- 
Romain Francois
Independent R Consultant
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr

At 4:53pm -0400 on Thu, 26 Mar 2009, Romain Francois wrote:
> but this does not work because MARK_PREVIOUS does not know about 
> DELEGATE. Is there another way I can achieve it ?

Have you looked at the jEdit documentation on mode writing?

http://www.jedit.org/users-guide/writing-modes.html

Or, specifically, have you tried SEQ or SEQ_REGEXP?

http://www.jedit.org/users-guide/mode-rule-seq.html
http://www.jedit.org/users-guide/mode-rule-seq-regexp.html

Kevin

Plugin Bugs item #2687829, was opened at 2009-03-15 10:32
Message generated for change (Comment added) made by vanza
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=2687829&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alan Ezust (ezust)
Assigned to: Nobody/Anonymous (nobody)
Summary: ProjectViewer2.9:replace in project root - modified buffers

Initial Comment:
Before buffersets, when I did a multifile replace, I'd see each of the changed files opened and dirty in my buffer list. 

It seems that is no longer the case.

Not directly related, but I would expect to see the results shown in the hypersearch pane, but they are not.



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

>Comment By: Marcelo Vanzin (vanza)
Date: 2009-03-28 13:19

Message:
PV just calls SearchDialog.showSearchDialog(); it has no control about what
buffers are opened, how, where or when. jEdit's search system is the code
that opens files (or in your case Xsearch).

I can't see how this can possibly be a PV bug.

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

Comment By: Alan Ezust (ezust)
Date: 2009-03-28 10:47

Message:
Oh and here is another thing: projectviewer shows them as open in the PV
dockable, while it does not show up in any of the buffer lists. Not even
the global one!
So I think this is a bug in PV.


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

Comment By: Alan Ezust (ezust)
Date: 2009-03-28 10:35

Message:
The bug is that some of the buffers that are modified are not added to the
bufferset of the current view, so I can't see them as "modified buffers"
until I exit jEdit, at which point I see them in the list of "buffers
modified - what do you want to do about it?" list of files. And so there is
now way to see those changed files.

I should mention, I am also using XSearch plugin, so maybe this is only
reproducible with PV trunk and XSearch.

Also, I see this on windows.


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

Comment By: Marcelo Vanzin (vanza)
Date: 2009-03-20 22:16

Message:
What is the bug here? It seems that it's doing what it's supposed to do:
buffers open up as dirty; since it's a search & replace, you get no search
results.

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

Comment By: Alan Ezust (ezust)
Date: 2009-03-19 15:47

Message:
Sorry, this is a bug in ProjectViewer's "Search in Project Root", not in
jEdit core.


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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-03-19 15:46

Message:
The replacements do not show in the hypersearch results even for a single
file search. I guess they were never meant to be shown there. Maybe because
it's replace rather than search.

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

Comment By: Townsfolk (elberry)
Date: 2009-03-19 15:29

Message:
I too am seeing the files opened and dirty, and I also do not see the
results in HyperSearch, even though I've checked the HS box.

I'm using the normal search dialog ([CTRL|CMD] + F) and setting it to
search all buffers.

I tested this in 4.3pre16, and 4.2final, with the same results.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-03-19 15:10

Message:
The first part works fine for me; I see the modified files open dirty in my
buffer tabs (also in buffer switcher).
I do not see the results shown in the hypersearch pane, though; are you
sure they used to?


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

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

Plugin Central Submission item #2719116, was opened at 2009-03-28 16:30
Message generated for change (Comment added) made by kpouer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=625093&aid=2719116&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
Priority: 5
Private: No
Submitted By: Marcos Topa (marcostopa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Hyperlinks 2 v1.0.0

Initial Comment:
Hyperlinks 2 is a modification of the Hyperlinks plugin. It opens hyperlinks with jEdit or with an external application like a web browser (configured in the plugin options), by pressing CTRL+click.
All the important work was done by Matthieu Casanova, the author of the original Hyperlinks plugin - I just added the external application support.
I only tested it on Windows, but it should work on Linux/Unix - I'm not sure about other OSes.

Hope you enjoy it.

Marcos Topa

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

>Comment By: Matthieu Casanova (kpouer)
Date: 2009-03-28 21:18

Message:
Hi, in fact credits was not the problem. But I think having two plugins
that do this job cannot work, and a new service plugin would do exactly the
same thing, it would be easy to convert your work into this service

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

Comment By: Marcos Topa (marcostopa)
Date: 2009-03-28 21:14

Message:
Hi everyone.

I'm sorry, I should have spoken to you first about this. My intention was
not, in any way, to take credit for your work.

That said - about this service you talked about in your comment - I will
look into it when I have the time. As soon as I have something to submit, I
will.

Regards,

Marcos

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

Comment By: Matthieu Casanova (kpouer)
Date: 2009-03-28 19:31

Message:
In fact there is no need to extend the plugin (if you are talking about
extending a class), the plugin works with services so it is only necessary
to write a new service, it is very easy to do

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

Comment By: Alan Ezust (ezust)
Date: 2009-03-28 18:23

Message:
It might be even better to make it an extension of hyperlinks and
infoviewer and use whatever the user wanted as the chosen browser defined
in infoviewer plugin options.


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

Comment By: Matthieu Casanova (kpouer)
Date: 2009-03-28 17:51

Message:
Hi, I'm sorry this plugin must not be released like this. If you want to
open links in an external application you can create an Hyperlink service
that do that (there are examples in the RFC plugins), but copying another
plugin is not a good solution here.
You could submit this hyperlink service as a plugin or as a patch for the
current plugin

Matthieu

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

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

Plugin Central Submission item #2719116, was opened at 2009-03-28 15:30
Message generated for change (Comment added) made by marcostopa
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=625093&aid=2719116&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
Priority: 5
Private: No
Submitted By: Marcos Topa (marcostopa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Hyperlinks 2 v1.0.0

Initial Comment:
Hyperlinks 2 is a modification of the Hyperlinks plugin. It opens hyperlinks with jEdit or with an external application like a web browser (configured in the plugin options), by pressing CTRL+click.
All the important work was done by Matthieu Casanova, the author of the original Hyperlinks plugin - I just added the external application support.
I only tested it on Windows, but it should work on Linux/Unix - I'm not sure about other OSes.

Hope you enjoy it.

Marcos Topa

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

Comment By: Marcos Topa (marcostopa)
Date: 2009-03-28 20:14

Message:
Hi everyone.

I'm sorry, I should have spoken to you first about this. My intention was
not, in any way, to take credit for your work.

That said - about this service you talked about in your comment - I will
look into it when I have the time. As soon as I have something to submit, I
will.

Regards,

Marcos

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

Comment By: Matthieu Casanova (kpouer)
Date: 2009-03-28 18:31

Message:
In fact there is no need to extend the plugin (if you are talking about
extending a class), the plugin works with services so it is only necessary
to write a new service, it is very easy to do

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

Comment By: Alan Ezust (ezust)
Date: 2009-03-28 17:23

Message:
It might be even better to make it an extension of hyperlinks and
infoviewer and use whatever the user wanted as the chosen browser defined
in infoviewer plugin options.


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

Comment By: Matthieu Casanova (kpouer)
Date: 2009-03-28 16:51

Message:
Hi, I'm sorry this plugin must not be released like this. If you want to
open links in an external application you can create an Hyperlink service
that do that (there are examples in the RFC plugins), but copying another
plugin is not a good solution here.
You could submit this hyperlink service as a plugin or as a patch for the
current plugin

Matthieu

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

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

Plugin Central Submission item #2719116, was opened at 2009-03-28 16:30
Message generated for change (Comment added) made by kpouer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=625093&aid=2719116&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
Priority: 5
Private: No
Submitted By: Marcos Topa (marcostopa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Hyperlinks 2 v1.0.0

Initial Comment:
Hyperlinks 2 is a modification of the Hyperlinks plugin. It opens hyperlinks with jEdit or with an external application like a web browser (configured in the plugin options), by pressing CTRL+click.
All the important work was done by Matthieu Casanova, the author of the original Hyperlinks plugin - I just added the external application support.
I only tested it on Windows, but it should work on Linux/Unix - I'm not sure about other OSes.

Hope you enjoy it.

Marcos Topa

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

>Comment By: Matthieu Casanova (kpouer)
Date: 2009-03-28 19:31

Message:
In fact there is no need to extend the plugin (if you are talking about
extending a class), the plugin works with services so it is only necessary
to write a new service, it is very easy to do

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

Comment By: Alan Ezust (ezust)
Date: 2009-03-28 18:23

Message:
It might be even better to make it an extension of hyperlinks and
infoviewer and use whatever the user wanted as the chosen browser defined
in infoviewer plugin options.


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

Comment By: Matthieu Casanova (kpouer)
Date: 2009-03-28 17:51

Message:
Hi, I'm sorry this plugin must not be released like this. If you want to
open links in an external application you can create an Hyperlink service
that do that (there are examples in the RFC plugins), but copying another
plugin is not a good solution here.
You could submit this hyperlink service as a plugin or as a patch for the
current plugin

Matthieu

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

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

Plugin Bugs item #2687829, was opened at 2009-03-15 10:32
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=2687829&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alan Ezust (ezust)
Assigned to: Nobody/Anonymous (nobody)
Summary: ProjectViewer2.9:replace in project root - modified buffers

Initial Comment:
Before buffersets, when I did a multifile replace, I'd see each of the changed files opened and dirty in my buffer list. 

It seems that is no longer the case.

Not directly related, but I would expect to see the results shown in the hypersearch pane, but they are not.



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

>Comment By: Alan Ezust (ezust)
Date: 2009-03-28 10:47

Message:
Oh and here is another thing: projectviewer shows them as open in the PV
dockable, while it does not show up in any of the buffer lists. Not even
the global one!
So I think this is a bug in PV.


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

Comment By: Alan Ezust (ezust)
Date: 2009-03-28 10:35

Message:
The bug is that some of the buffers that are modified are not added to the
bufferset of the current view, so I can't see them as "modified buffers"
until I exit jEdit, at which point I see them in the list of "buffers
modified - what do you want to do about it?" list of files. And so there is
now way to see those changed files.

I should mention, I am also using XSearch plugin, so maybe this is only
reproducible with PV trunk and XSearch.

Also, I see this on windows.


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

Comment By: Marcelo Vanzin (vanza)
Date: 2009-03-20 22:16

Message:
What is the bug here? It seems that it's doing what it's supposed to do:
buffers open up as dirty; since it's a search & replace, you get no search
results.

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

Comment By: Alan Ezust (ezust)
Date: 2009-03-19 15:47

Message:
Sorry, this is a bug in ProjectViewer's "Search in Project Root", not in
jEdit core.


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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-03-19 15:46

Message:
The replacements do not show in the hypersearch results even for a single
file search. I guess they were never meant to be shown there. Maybe because
it's replace rather than search.

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

Comment By: Townsfolk (elberry)
Date: 2009-03-19 15:29

Message:
I too am seeing the files opened and dirty, and I also do not see the
results in HyperSearch, even though I've checked the HS box.

I'm using the normal search dialog ([CTRL|CMD] + F) and setting it to
search all buffers.

I tested this in 4.3pre16, and 4.2final, with the same results.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-03-19 15:10

Message:
The first part works fine for me; I see the modified files open dirty in my
buffer tabs (also in buffer switcher).
I do not see the results shown in the hypersearch pane, though; are you
sure they used to?


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

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

Plugin Bugs item #2687829, was opened at 2009-03-15 10:32
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=2687829&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alan Ezust (ezust)
Assigned to: Nobody/Anonymous (nobody)
Summary: ProjectViewer2.9:replace in project root - modified buffers

Initial Comment:
Before buffersets, when I did a multifile replace, I'd see each of the changed files opened and dirty in my buffer list. 

It seems that is no longer the case.

Not directly related, but I would expect to see the results shown in the hypersearch pane, but they are not.



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

>Comment By: Alan Ezust (ezust)
Date: 2009-03-28 10:35

Message:
The bug is that some of the buffers that are modified are not added to the
bufferset of the current view, so I can't see them as "modified buffers"
until I exit jEdit, at which point I see them in the list of "buffers
modified - what do you want to do about it?" list of files. And so there is
now way to see those changed files.

I should mention, I am also using XSearch plugin, so maybe this is only
reproducible with PV trunk and XSearch.

Also, I see this on windows.


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

Comment By: Marcelo Vanzin (vanza)
Date: 2009-03-20 22:16

Message:
What is the bug here? It seems that it's doing what it's supposed to do:
buffers open up as dirty; since it's a search & replace, you get no search
results.

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

Comment By: Alan Ezust (ezust)
Date: 2009-03-19 15:47

Message:
Sorry, this is a bug in ProjectViewer's "Search in Project Root", not in
jEdit core.


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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-03-19 15:46

Message:
The replacements do not show in the hypersearch results even for a single
file search. I guess they were never meant to be shown there. Maybe because
it's replace rather than search.

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

Comment By: Townsfolk (elberry)
Date: 2009-03-19 15:29

Message:
I too am seeing the files opened and dirty, and I also do not see the
results in HyperSearch, even though I've checked the HS box.

I'm using the normal search dialog ([CTRL|CMD] + F) and setting it to
search all buffers.

I tested this in 4.3pre16, and 4.2final, with the same results.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-03-19 15:10

Message:
The first part works fine for me; I see the modified files open dirty in my
buffer tabs (also in buffer switcher).
I do not see the results shown in the hypersearch pane, though; are you
sure they used to?


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

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

Plugin Central Submission item #2719116, was opened at 2009-03-28 08:30
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=625093&aid=2719116&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
Priority: 5
Private: No
Submitted By: Marcos Topa (marcostopa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Hyperlinks 2 v1.0.0

Initial Comment:
Hyperlinks 2 is a modification of the Hyperlinks plugin. It opens hyperlinks with jEdit or with an external application like a web browser (configured in the plugin options), by pressing CTRL+click.
All the important work was done by Matthieu Casanova, the author of the original Hyperlinks plugin - I just added the external application support.
I only tested it on Windows, but it should work on Linux/Unix - I'm not sure about other OSes.

Hope you enjoy it.

Marcos Topa

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

>Comment By: Alan Ezust (ezust)
Date: 2009-03-28 10:23

Message:
It might be even better to make it an extension of hyperlinks and
infoviewer and use whatever the user wanted as the chosen browser defined
in infoviewer plugin options.


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

Comment By: Matthieu Casanova (kpouer)
Date: 2009-03-28 09:51

Message:
Hi, I'm sorry this plugin must not be released like this. If you want to
open links in an external application you can create an Hyperlink service
that do that (there are examples in the RFC plugins), but copying another
plugin is not a good solution here.
You could submit this hyperlink service as a plugin or as a patch for the
current plugin

Matthieu

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

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