jedit-devel Mailing List for jEdit

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Dale Anson (daleanson)
Assigned to: Shlomy Reinstein (shlomy)
Summary: Switching docking frameworks requires a jEdit restart

Initial Comment:
>From email to the developer list:

> Switching between "original" and "MyDoggy" and back requires a jEdit
> > restart.  Not a big deal, but the docs should probably say so.
> >

Yes, that's right. Please - tracker item, even though this was my
original intention to specify this in the documentation.
In the future I may remove this limit. There is no real reason that
switching between framework requires a restart, it's just some more
code to write that I didn't feel was important enough for now.



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

>Comment By: Shlomy Reinstein (shlomy)
Date: 2008-12-31 23:04

Message:
Added a note to the docs in SVN rev. 14270.

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

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

Bugs item #1974620, was opened at 2008-05-27 13:42
Message generated for change (Comment added) made by shlomy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1974620&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: editor core
Group: minor bug
>Status: Closed
>Resolution: Fixed
Priority: 2
Private: No
Submitted By: Shlomy Reinstein (shlomy)
Assigned to: Shlomy Reinstein (shlomy)
Summary: Cannot use C+e C+BACK_QUOTE for close-docking-area

Initial Comment:
The following is printed many times to the jEdit console, regardless of what I do in jEdit:

[error] KeyEventTranslator: Invalid key stroke: C+e C+BACK_QUOTE

This is the shortcut for "close-docking-area". I tracked this down to a bug in the DockableWindowManager.KeyHandler which does not know how to handle shortcuts of length > 1 ("C+e C+BACK_QUOTE" in this case). It invokes KeyEventTranslator.parseKey() with this shortcut, and the later throws the following exception:
java.lang.NoSuchFieldException: VK_e C+BACK_QUOTE

Need to change KeyHandler to handle sequences of length 2 and more.

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

>Comment By: Shlomy Reinstein (shlomy)
Date: 2008-12-31 14:38

Message:
Fixed in SVN rev. 14268.

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

Comment By: Alan Ezust (ezust)
Date: 2008-08-19 08:45

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

nevermind, I see it myself now too.
on linux, jedit 4.3pre16 (svn).


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

Comment By: Alan Ezust (ezust)
Date: 2008-08-13 22:19

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

This seems to be fixed now. Setting to pending.


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

Comment By: Shlomy Reinstein (shlomy)
Date: 2008-05-27 15:27

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

Lowered the priority since it seems the shortcut is working. It's just the
message that should be eliminated in the console.

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

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

Plugin Feature Requests item #2478027, was opened at 2008-12-31 02:21
Message generated for change (Comment added) made by shlomy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=2478027&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Alan Ezust (ezust)
Assigned to: Shlomy Reinstein (shlomy)
Summary: CtagsInterface and VFS

Initial Comment:
this might be a pain to implement, but I was thinking how nice it would be to add the src.zip from jdk directly instead of unziping it and adding the unzipped directory. 

If ctagsinterface used the VFS to get all the files, then it could work with archive:/ and sftp:/ file paths, that would be very cool.


Keep in mind, this is also the intent of ProjectViewer 3.0. 


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

>Comment By: Shlomy Reinstein (shlomy)
Date: 2008-12-31 05:38

Message:
I planned to add VFS support in CtagsInterface for the reasons you
mentioned here. The implementation should not be very difficult; my main
concern is that VFS support may cause CtagsInterface to be somewhat slow.
Hence, I'll make this optional when I add support for it, or, better, if
possible, detect whether VFS is needed for each tag origin and use direct
access if not.

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

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

Plugin Feature Requests item #2478027, was opened at 2008-12-30 16:21
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=2478027&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Alan Ezust (ezust)
Assigned to: Shlomy Reinstein (shlomy)
Summary: CtagsInterface and VFS

Initial Comment:
this might be a pain to implement, but I was thinking how nice it would be to add the src.zip from jdk directly instead of unziping it and adding the unzipped directory. 

If ctagsinterface used the VFS to get all the files, then it could work with archive:/ and sftp:/ file paths, that would be very cool.


Keep in mind, this is also the intent of ProjectViewer 3.0. 


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

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

Plugin Bugs item #2477624, was opened at 2008-12-30 21:47
Message generated for change (Comment added) made by shlomy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=2477624&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Alan Ezust (ezust)
Assigned to: Shlomy Reinstein (shlomy)
Summary: CtagsInterface context menu in tag preview dockable

Initial Comment:
The textarea pane of the preview dockable should have a context menu: "copy (Ctrl-C)" to copy to the system clipboard.

Another idea: the context menu for both panes should have "Open in Editor" which when selected, would open that file in jEdit and bring the cursor there.



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

>Comment By: Shlomy Reinstein (shlomy)
Date: 2008-12-31 00:10

Message:
Make that 14261 - including the Ctrl-C for copying.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2008-12-30 23:51

Message:
Implemented in SVN rev. 14260.

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

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

Plugin Bugs item #2477624, was opened at 2008-12-30 21:47
Message generated for change (Comment added) made by shlomy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=2477624&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Alan Ezust (ezust)
Assigned to: Shlomy Reinstein (shlomy)
Summary: CtagsInterface context menu in tag preview dockable

Initial Comment:
The textarea pane of the preview dockable should have a context menu: "copy (Ctrl-C)" to copy to the system clipboard.

Another idea: the context menu for both panes should have "Open in Editor" which when selected, would open that file in jEdit and bring the cursor there.



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

>Comment By: Shlomy Reinstein (shlomy)
Date: 2008-12-30 23:51

Message:
Implemented in SVN rev. 14260.

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

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

For me, when I set the right directory of the unsaved buffer, it also
highlighted the error in the buffer.

On Tue, Dec 30, 2008 at 10:10 PM, Eric Berry <el...@gm...> wrote:
> K. Nevermind. It is actually working.
>
> I can see the error in ErrorList, it just wasn't being highlighted in the
> buffer itself.
>
> The log message mislead me:
> [quote]
> [debug] EditBus:
> ErrorSourceUpdate[source=null,what=ERROR_ADDED,errorSource=errorlist.DefaultErrorSource[ScriptEnginePlugin],error=/Untitled-1:0:javax.script.ScriptException:
> groovy.lang.MissingPropertyException: No such property: blah for class:
> Script2]
> [/quote]
>
> Sorry.
>
> However, the error still isn't being highlighted in the buffer itself.
>
> On Tue, Dec 30, 2008 at 10:23 AM, Eric Berry <el...@gm...> wrote:
>>
>> Hmm.. This isn't quite the same thing.
>>
>> If you create a new empty buffer (CTRL+N), then run your command in
>> Console, and use ErrorList to show you the error, you'll notice that you get
>> a second "Untitled-1" buffer which points to a new file under the current
>> directory of Console.
>>
>>
>>
>> On Tue, Dec 30, 2008 at 10:09 AM, Shlomy Reinstein <sre...@gm...>
>> wrote:
>>>
>>> Not sure if this answers your question, but I tried the following:
>>> 1. Wrote an 'echo' command with a dummy Perl error pattern in the
>>> Console window, with "Untitled-1" as the filename.
>>> 2. The console echoed the dummy Perl error pattern, coloring it as an
>>> error, passing it to ErrorList.
>>> 3. ErrorList showed the error.
>>> 4. Clicking the error in the ErrorList brought me to the right line in
>>> the untitled buffer. Also, the error was highlighted in the untitled
>>> buffer.
>>>
>>> Here's the scenario in the console:
>>>
>>> C:\Program Files\jEdit> echo dfjkd at Untitled-1 line 15. kjd
>>> dfjkd at Untitled-1 line 15. kjd
>>> Process echo exited with code 0.
>>>
>>> Shlomy
>>>
>>> On Tue, Dec 30, 2008 at 7:42 PM, Eric Berry <el...@gm...> wrote:
>>> > So, I'm assuming then that this just isn't possible. ErrorList only
>>> > works on
>>> > buffers where the buffer's file has been persisted to disk?
>>> >
>>> > On Fri, Dec 19, 2008 at 7:34 PM, Eric Berry <el...@gm...> wrote:
>>> >>
>>> >> Hi all,
>>> >>    I'm working on adding ErrorList support to the ScriptEngine
>>> >> plugins. I
>>> >> noticed that when I use getPath on an "untitled" buffer, it returns
>>> >> /Untitled[num]. When I create a new DefaultError and add it to the
>>> >> ErrorSource, I see in the activity.log that the error was reported,
>>> >> but the
>>> >> buffer doesn't show the error message.
>>> >>
>>> >> Is there a way to tell ErrorList to highlight errors in the current
>>> >> buffer
>>> >> regardless of if they've been persisted to disk yet?
>>> >>
>>> >> Thanks,
>>> >> Eric
>>> >>
>>> >> --
>>> >> Learn from the past. Live in the present. Plan for the future.
>>> >> 11101000
>>> >> http://www.townsfolkdesigns.com/blogs/elberry
>>> >
>>> >
>>> >
>>> > --
>>> > Learn from the past. Live in the present. Plan for the future.
>>> > 11101000
>>> > http://www.townsfolkdesigns.com/blogs/elberry
>>> >
>>> >
>>> > ------------------------------------------------------------------------------
>>> >
>>> > --
>>> > -----------------------------------------------
>>> > jEdit Developers' List
>>> > jEd...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/jedit-devel
>>> >
>>> >
>>
>>
>>
>> --
>> Learn from the past. Live in the present. Plan for the future.
>> 11101000
>> http://www.townsfolkdesigns.com/blogs/elberry
>
>
>
> --
> Learn from the past. Live in the present. Plan for the future.
> 11101000
> http://www.townsfolkdesigns.com/blogs/elberry
>

K. Nevermind. It is actually working.

I can see the error in ErrorList, it just wasn't being highlighted in the
buffer itself.

The log message mislead me:
[quote]
[debug] EditBus:
ErrorSourceUpdate[source=null,what=ERROR_ADDED,errorSource=errorlist.DefaultErrorSource[ScriptEnginePlugin],error=/Untitled-1:0:javax.script.ScriptException:
groovy.lang.MissingPropertyException: No such property: blah for class:
Script2]
[/quote]

Sorry.

However, the error still isn't being highlighted in the buffer itself.

On Tue, Dec 30, 2008 at 10:23 AM, Eric Berry <el...@gm...> wrote:

> Hmm.. This isn't quite the same thing.
>
> If you create a new empty buffer (CTRL+N), then run your command in
> Console, and use ErrorList to show you the error, you'll notice that you get
> a second "Untitled-1" buffer which points to a new file under the current
> directory of Console.
>
>
>
>
> On Tue, Dec 30, 2008 at 10:09 AM, Shlomy Reinstein <sre...@gm...>wrote:
>
>> Not sure if this answers your question, but I tried the following:
>> 1. Wrote an 'echo' command with a dummy Perl error pattern in the
>> Console window, with "Untitled-1" as the filename.
>> 2. The console echoed the dummy Perl error pattern, coloring it as an
>> error, passing it to ErrorList.
>> 3. ErrorList showed the error.
>> 4. Clicking the error in the ErrorList brought me to the right line in
>> the untitled buffer. Also, the error was highlighted in the untitled
>> buffer.
>>
>> Here's the scenario in the console:
>>
>> C:\Program Files\jEdit> echo dfjkd at Untitled-1 line 15. kjd
>> dfjkd at Untitled-1 line 15. kjd
>> Process echo exited with code 0.
>>
>> Shlomy
>>
>> On Tue, Dec 30, 2008 at 7:42 PM, Eric Berry <el...@gm...> wrote:
>> > So, I'm assuming then that this just isn't possible. ErrorList only
>> works on
>> > buffers where the buffer's file has been persisted to disk?
>> >
>> > On Fri, Dec 19, 2008 at 7:34 PM, Eric Berry <el...@gm...> wrote:
>> >>
>> >> Hi all,
>> >>    I'm working on adding ErrorList support to the ScriptEngine plugins.
>> I
>> >> noticed that when I use getPath on an "untitled" buffer, it returns
>> >> /Untitled[num]. When I create a new DefaultError and add it to the
>> >> ErrorSource, I see in the activity.log that the error was reported, but
>> the
>> >> buffer doesn't show the error message.
>> >>
>> >> Is there a way to tell ErrorList to highlight errors in the current
>> buffer
>> >> regardless of if they've been persisted to disk yet?
>> >>
>> >> Thanks,
>> >> Eric
>> >>
>> >> --
>> >> Learn from the past. Live in the present. Plan for the future.
>> >> 11101000
>> >> http://www.townsfolkdesigns.com/blogs/elberry
>> >
>> >
>> >
>> > --
>> > Learn from the past. Live in the present. Plan for the future.
>> > 11101000
>> > http://www.townsfolkdesigns.com/blogs/elberry
>> >
>> >
>> ------------------------------------------------------------------------------
>> >
>> > --
>> > -----------------------------------------------
>> > jEdit Developers' List
>> > jEd...@li...
>> > https://lists.sourceforge.net/lists/listinfo/jedit-devel
>> >
>> >
>>
>
>
>
> --
> Learn from the past. Live in the present. Plan for the future.
> 11101000
> http://www.townsfolkdesigns.com/blogs/elberry
>



-- 
Learn from the past. Live in the present. Plan for the future.
11101000
http://www.townsfolkdesigns.com/blogs/elberry

Plugin Bugs item #2477624, was opened at 2008-12-30 11:47
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=2477624&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: Shlomy Reinstein (shlomy)
Summary: CtagsInterface context menu in tag preview dockable

Initial Comment:
The textarea pane of the preview dockable should have a context menu: "copy (Ctrl-C)" to copy to the system clipboard.

Another idea: the context menu for both panes should have "Open in Editor" which when selected, would open that file in jEdit and bring the cursor there.



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

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

Hmm.. This isn't quite the same thing.

If you create a new empty buffer (CTRL+N), then run your command in Console,
and use ErrorList to show you the error, you'll notice that you get a second
"Untitled-1" buffer which points to a new file under the current directory
of Console.



On Tue, Dec 30, 2008 at 10:09 AM, Shlomy Reinstein <sre...@gm...>wrote:

> Not sure if this answers your question, but I tried the following:
> 1. Wrote an 'echo' command with a dummy Perl error pattern in the
> Console window, with "Untitled-1" as the filename.
> 2. The console echoed the dummy Perl error pattern, coloring it as an
> error, passing it to ErrorList.
> 3. ErrorList showed the error.
> 4. Clicking the error in the ErrorList brought me to the right line in
> the untitled buffer. Also, the error was highlighted in the untitled
> buffer.
>
> Here's the scenario in the console:
>
> C:\Program Files\jEdit> echo dfjkd at Untitled-1 line 15. kjd
> dfjkd at Untitled-1 line 15. kjd
> Process echo exited with code 0.
>
> Shlomy
>
> On Tue, Dec 30, 2008 at 7:42 PM, Eric Berry <el...@gm...> wrote:
> > So, I'm assuming then that this just isn't possible. ErrorList only works
> on
> > buffers where the buffer's file has been persisted to disk?
> >
> > On Fri, Dec 19, 2008 at 7:34 PM, Eric Berry <el...@gm...> wrote:
> >>
> >> Hi all,
> >>    I'm working on adding ErrorList support to the ScriptEngine plugins.
> I
> >> noticed that when I use getPath on an "untitled" buffer, it returns
> >> /Untitled[num]. When I create a new DefaultError and add it to the
> >> ErrorSource, I see in the activity.log that the error was reported, but
> the
> >> buffer doesn't show the error message.
> >>
> >> Is there a way to tell ErrorList to highlight errors in the current
> buffer
> >> regardless of if they've been persisted to disk yet?
> >>
> >> Thanks,
> >> Eric
> >>
> >> --
> >> Learn from the past. Live in the present. Plan for the future.
> >> 11101000
> >> http://www.townsfolkdesigns.com/blogs/elberry
> >
> >
> >
> > --
> > Learn from the past. Live in the present. Plan for the future.
> > 11101000
> > http://www.townsfolkdesigns.com/blogs/elberry
> >
> >
> ------------------------------------------------------------------------------
> >
> > --
> > -----------------------------------------------
> > jEdit Developers' List
> > jEd...@li...
> > https://lists.sourceforge.net/lists/listinfo/jedit-devel
> >
> >
>



-- 
Learn from the past. Live in the present. Plan for the future.
11101000
http://www.townsfolkdesigns.com/blogs/elberry

Not sure if this answers your question, but I tried the following:
1. Wrote an 'echo' command with a dummy Perl error pattern in the
Console window, with "Untitled-1" as the filename.
2. The console echoed the dummy Perl error pattern, coloring it as an
error, passing it to ErrorList.
3. ErrorList showed the error.
4. Clicking the error in the ErrorList brought me to the right line in
the untitled buffer. Also, the error was highlighted in the untitled
buffer.

Here's the scenario in the console:

C:\Program Files\jEdit> echo dfjkd at Untitled-1 line 15. kjd
dfjkd at Untitled-1 line 15. kjd
Process echo exited with code 0.

Shlomy

On Tue, Dec 30, 2008 at 7:42 PM, Eric Berry <el...@gm...> wrote:
> So, I'm assuming then that this just isn't possible. ErrorList only works on
> buffers where the buffer's file has been persisted to disk?
>
> On Fri, Dec 19, 2008 at 7:34 PM, Eric Berry <el...@gm...> wrote:
>>
>> Hi all,
>>    I'm working on adding ErrorList support to the ScriptEngine plugins. I
>> noticed that when I use getPath on an "untitled" buffer, it returns
>> /Untitled[num]. When I create a new DefaultError and add it to the
>> ErrorSource, I see in the activity.log that the error was reported, but the
>> buffer doesn't show the error message.
>>
>> Is there a way to tell ErrorList to highlight errors in the current buffer
>> regardless of if they've been persisted to disk yet?
>>
>> Thanks,
>> Eric
>>
>> --
>> Learn from the past. Live in the present. Plan for the future.
>> 11101000
>> http://www.townsfolkdesigns.com/blogs/elberry
>
>
>
> --
> Learn from the past. Live in the present. Plan for the future.
> 11101000
> http://www.townsfolkdesigns.com/blogs/elberry
>
> ------------------------------------------------------------------------------
>
> --
> -----------------------------------------------
> jEdit Developers' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>
>

So, I'm assuming then that this just isn't possible. ErrorList only works on
buffers where the buffer's file has been persisted to disk?

On Fri, Dec 19, 2008 at 7:34 PM, Eric Berry <el...@gm...> wrote:

> Hi all,
>    I'm working on adding ErrorList support to the ScriptEngine plugins. I
> noticed that when I use getPath on an "untitled" buffer, it returns
> /Untitled[num]. When I create a new DefaultError and add it to the
> ErrorSource, I see in the activity.log that the error was reported, but the
> buffer doesn't show the error message.
>
> Is there a way to tell ErrorList to highlight errors in the current buffer
> regardless of if they've been persisted to disk yet?
>
> Thanks,
> Eric
>
> --
> Learn from the past. Live in the present. Plan for the future.
> 11101000
> http://www.townsfolkdesigns.com/blogs/elberry
>



-- 
Learn from the past. Live in the present. Plan for the future.
11101000
http://www.townsfolkdesigns.com/blogs/elberry

Hi,

I noticed that jEdit handles dragging objects from external sources
(e.g. other applications) to the text area. It handles dragging of
files by opening a buffer on these files, and also dragging of
uri-lists and text.
When text is dropped on the text area, jEdit treats it as text only if
the drag source was jEdit itself. If the text was dragged from
external sources (e.g. another editor), it tries to refer to the
dropped text (one line at a time) as a file / url path and open the
file / url. Is there a reason for this? Why not treat it as text in
both cases? E.g. if I want to copy a block of text from my Visual
Studio process to jEdit, I won't be able to do it by dragging because
jEdit will ignore it (since it's not a list of url's).

Shlomy

Bugs item #2321838, was opened at 2008-11-21 19:20
Message generated for change (Comment added) made by shlomy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2321838&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Kazutoshi Satoda (k_satoda)
Assigned to: Shlomy Reinstein (shlomy)
Summary: Dropped file is unexpectedly opened in both of split panes

Initial Comment:
With jEdit 4.3pre16, having a couple of editpane, which
the both have editpane-scope bufferset, when a file is
dropped to inactive one, the file is opened in both.

I expect it should open the file in the dropped pane,
and nothing happens on the other pane. If the file is
dropped to active one, it works as expected.

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

>Comment By: Shlomy Reinstein (shlomy)
Date: 2008-12-30 14:55

Message:
Matthieu, just to make it clear - there are 3 different types (flavors) of
objects that can be dropped on the text area: File (importFile method),
Text (importText method), and UriList. You handled the UriList type, this
bug is about the File type.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2008-12-30 13:14

Message:
Fixed in SVN rev 14255.

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

Comment By: Matthieu Casanova (kpouer)
Date: 2008-12-06 19:52

Message:
That's very strange, I reproduce the bug on some OS but not on my Ubuntu.
In fact when I try to drop it, the focus changes to the editpane on which
my mouse is

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2008-11-23 15:28

Message:
On Windows XP, with options: Edit-pane scope, new buffersets contain
current buffer only, if I drop a file to the first edit pane (the one from
which the other was split), it appears on both edit panes. If I drop to the
second edit pane (the newer one), it appears only in it.

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

Comment By: Matthieu Casanova (kpouer)
Date: 2008-11-23 15:22

Message:
That's strange, I just tried again, dropping the file on any of the
editPanes and it works perfectly.
I'm on an Ubuntu 8.10, I'll try monday on a Windows to see if it is
different.
Can someone else try ?

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

Comment By: Kazutoshi Satoda (k_satoda)
Date: 2008-11-23 06:06

Message:
I think the addition of a new method is good, but I couldn't confirm
the fix at r14093 (Windows XP, JDK 6u10). The behavior is still same as
reported. Could you see the behavior is fixed?

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

Comment By: Matthieu Casanova (kpouer)
Date: 2008-11-22 22:33

Message:
Fixed in the trunk. The problem was that we open the files with
jEdit.openFile(view ...) and when using a view the file is added to the
active textArea by default. So I added methods to open files in an EditPane
in jEdit.
It could cause source incompatibility for those who open files with null
argument for the view (but I think the binary compatibility is not broken
so I don't think it is a big problem).

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

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

Feature Requests item #2476086, was opened at 2008-12-30 01:25
Message generated for change (Comment added) made by rschwenn
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350588&aid=2476086&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: ddoctor (ddoctor)
Assigned to: Nobody/Anonymous (nobody)
Summary: Default Configuration

Initial Comment:
Hi,

Whenever I install JEdit, I always do the following. I'd like to suggest they are the default options:

1. Set system look & feel (Windows).
2. Turn on line numbering (it is a "programmer's" text editor, after all)
3. Turn off "End of line markers"
4. Turn off "Wrap guide"
5. Install and turn on the "buffer tabs" plugin - the selector at the top is awful.

This may be personal preference but I really think these tweaks make JEdit much more friendly. 

Cheers,

DDoc

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

>Comment By: Robert Schwenn (rschwenn)
Date: 2008-12-30 13:49

Message:
I think, You're talking about different things:

1. Shlomy's wizard primarily could help beginners and people who install
jEdit occasionally to get some basic settings they like (and an overview
about them).

2. People who often install jEdit from scratch may consider to create
their own set of default options:
You only have to find the concerning settings in the ~/properties file and
copy or move them into a new file named however.props. When placing
however.props into the %JEDIT_HOME%/properties directory, all these
settings are applied for all users of this installation. And they will be
overridden with personal settings of the ~/properties file.

It's a bit work for the first time - but it's worth! 



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

Comment By: Shlomy Reinstein (shlomy)
Date: 2008-12-30 05:03

Message:
Here's a reference to one of these past discussions:
https://sourceforge.net/mailarchive/message.php?msg_id=1a0773920709161459j578920e3k9b32759b8aa0bf67%40mail.gmail.com

Just so you can get an impression of what I wrote below...

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2008-12-30 04:49

Message:
... and, if we reach an agreement to have that wizard, I volunteer to
develop this "first time" wizard myself. I just need to collect a list of
those "commonly changed" options for the wizard. I will used past
discussions in addition to the suggestion options here for that, and anyone
else is welcome to add such options.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2008-12-30 04:46

Message:
The default options have been discussed more than once in the past. It is
highly a matter of personal preference, so it's difficult to reach an
agreement.

What I'd suggest, instead of changing the defaults - is some sort of
"first time" wizard, which will show combo-boxes to select the values for
various "commonly changed" options, possibly with a simple explanation, and
preferably with direct visual feedback that demonstrates what each of the
possible values does (e.g. make the wizard have a split window, where one
side shows the options, and the other shows a text area with some
predefined text, and each value selection for an option shows what the
value will look like in the text area).

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

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

Bugs item #2321838, was opened at 2008-11-21 19:20
Message generated for change (Comment added) made by shlomy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2321838&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Kazutoshi Satoda (k_satoda)
>Assigned to: Shlomy Reinstein (shlomy)
Summary: Dropped file is unexpectedly opened in both of split panes

Initial Comment:
With jEdit 4.3pre16, having a couple of editpane, which
the both have editpane-scope bufferset, when a file is
dropped to inactive one, the file is opened in both.

I expect it should open the file in the dropped pane,
and nothing happens on the other pane. If the file is
dropped to active one, it works as expected.

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

>Comment By: Shlomy Reinstein (shlomy)
Date: 2008-12-30 13:14

Message:
Fixed in SVN rev 14255.

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

Comment By: Matthieu Casanova (kpouer)
Date: 2008-12-06 19:52

Message:
That's very strange, I reproduce the bug on some OS but not on my Ubuntu.
In fact when I try to drop it, the focus changes to the editpane on which
my mouse is

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2008-11-23 15:28

Message:
On Windows XP, with options: Edit-pane scope, new buffersets contain
current buffer only, if I drop a file to the first edit pane (the one from
which the other was split), it appears on both edit panes. If I drop to the
second edit pane (the newer one), it appears only in it.

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

Comment By: Matthieu Casanova (kpouer)
Date: 2008-11-23 15:22

Message:
That's strange, I just tried again, dropping the file on any of the
editPanes and it works perfectly.
I'm on an Ubuntu 8.10, I'll try monday on a Windows to see if it is
different.
Can someone else try ?

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

Comment By: Kazutoshi Satoda (k_satoda)
Date: 2008-11-23 06:06

Message:
I think the addition of a new method is good, but I couldn't confirm
the fix at r14093 (Windows XP, JDK 6u10). The behavior is still same as
reported. Could you see the behavior is fixed?

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

Comment By: Matthieu Casanova (kpouer)
Date: 2008-11-22 22:33

Message:
Fixed in the trunk. The problem was that we open the files with
jEdit.openFile(view ...) and when using a view the file is added to the
active textArea by default. So I added methods to open files in an EditPane
in jEdit.
It could cause source incompatibility for those who open files with null
argument for the view (but I think the binary compatibility is not broken
so I don't think it is a big problem).

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

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Accepted
Priority: 5
Private: No
Submitted By: VladimirR (vladimirr)
Assigned to: Shlomy Reinstein (shlomy)
Summary: [1936518] File/Directory properties dialog

Initial Comment:
Here's the patch for a File/Directory properties dialog.
It adds the "properties" entry to the context menu of the file browser, which opens a dialog showing the file's/directory's name, path, date of last modification, size, and accesibility, for a single file/directory or the path and total size of the multiple selected items.
Please feel free to comment this patch, since it's for a scool project, and we need some feedback.


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

>Comment By: Shlomy Reinstein (shlomy)
Date: 2008-12-30 12:16

Message:
Fixed this already in SVN rev 14254. When right-clicking a directory in the
top pane, the properties item now shows the information for that directory
instead of the selected files in the bottom pane.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2008-12-30 10:26

Message:
Right, the properties entry only shows when 1 or more files are selected at
the bottom pane. I think that's incorrect - the properties entry should, in
my opinion, refer to the items for which the context menu was invoked. If
the context menu is invoked for a directory in the top pane, the properties
entry should refer to the directory in the top pane that was
right-clicked.


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

Comment By: Zoltan Balog (ali_g)
Date: 2008-12-30 10:12

Message:
Sorry, but the properties entry only shows (as vladimirr posted it) at the
following condition:
- the properties entry only shows up in the context menu, when there's at
least one selected item.
But the directory problem weird.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2008-12-30 08:43

Message:
Note that this patch only works on the selected files, it doesn't work on
the selected directory. If files are not selected at the bottom pane of the
VFS browser, the 'properties' context menu won't be available when
right-clicking a directory in the top pane. And worse, if files are
selected in the bottom pane, then right-clicking a directory in the top
pane and selecting 'properties' will show the properties of the files in
the bottom pane, not the properties of the directory in the top pane for
which the context menu was invoked.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2008-12-30 08:30

Message:
Committed to SVN rev. 14253. Thanks a lot!

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

Comment By: VladimirR (vladimirr)
Date: 2008-11-26 22:18

Message:
I've uploaded the fixed patch, with the next changes:
- the properties entry only shows up in the context menu, when there's at
least one selected item
- the string properties have been moved to the jedit_gui.props file
- the typo has been fixed

About the checkboxes:
It would require Java6 to be able to change the readablity/writeablity to
both ways (java <6 only allows to invoke rights), that's why the checkboxes
are read-only.
Also, you're able to obtain the information about modification date and
filesize, even if you have no access to the file. I guess, this happens,
becouse you read those from the file sytem, and not the file itself (i was
able to see the size, and date for /etc/shadow as a limited user).

File Added: FilePropertiesDialog_v2.patch

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

Comment By: Zoltan Balog (ali_g)
Date: 2008-11-25 11:14

Message:
Thanks to observe our "mini" project and your advices. The bug will fix as
soon as possible (maybe at this moment) and we will discuss the checkbox,
what you mentioned.

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

Comment By: Dale Anson (daleanson)
Date: 2008-11-25 08:07

Message:
I see a few problems:

When right-clicking on a directory in the top half of the file browser,
then choosing "Properties" from the context menu, I get a bean shell error:
java.lang.ArrayIndexOutOfBoundsException: 0
	at
org.gjt.sp.jedit.gui.FilePropertiesDialog.<init>(FilePropertiesDialog.java:51)
	at
org.gjt.sp.jedit.browser.VFSBrowser.fileProperties(VFSBrowser.java:864)
...

The string properties in FilePropertiesDialog should be moved to
jedit_gui.props so that others can localize for their language.  Also,
Attribute is misspelled as Atribute.

I'm curious about the "Readable" and "Writable" checkboxes.  Would you
ever be able to show properties for a file that is not readable?  Neither
of these checkboxes are clickable, should at least the "Writable" checkbox
function so the user can change this value?

Otherwise, this looks good, the coding standard follows the jEdit standard
and the patch applied without error.

Thanks!


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

Comment By: Norbert Tóth (totka)
Date: 2008-11-23 21:42

Message:
I took 3 screenshots from this feature: 
* Context menu: http://img113.imageshack.us/my.php?image=contexttk6.png

* If you select one file, you see this FileProperties window:
http://img510.imageshack.us/my.php?image=filepropvw6.png
With editing the name's textfield and click on the OK button, you can
rename the file.

* If you select more files, you see this FileProperties windows:
http://img45.imageshack.us/my.php?image=filespropjn8.png



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

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Accepted
Priority: 5
Private: No
Submitted By: VladimirR (vladimirr)
Assigned to: Shlomy Reinstein (shlomy)
Summary: [1936518] File/Directory properties dialog

Initial Comment:
Here's the patch for a File/Directory properties dialog.
It adds the "properties" entry to the context menu of the file browser, which opens a dialog showing the file's/directory's name, path, date of last modification, size, and accesibility, for a single file/directory or the path and total size of the multiple selected items.
Please feel free to comment this patch, since it's for a scool project, and we need some feedback.


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

>Comment By: Shlomy Reinstein (shlomy)
Date: 2008-12-30 10:26

Message:
Right, the properties entry only shows when 1 or more files are selected at
the bottom pane. I think that's incorrect - the properties entry should, in
my opinion, refer to the items for which the context menu was invoked. If
the context menu is invoked for a directory in the top pane, the properties
entry should refer to the directory in the top pane that was
right-clicked.


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

Comment By: Zoltan Balog (ali_g)
Date: 2008-12-30 10:12

Message:
Sorry, but the properties entry only shows (as vladimirr posted it) at the
following condition:
- the properties entry only shows up in the context menu, when there's at
least one selected item.
But the directory problem weird.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2008-12-30 08:43

Message:
Note that this patch only works on the selected files, it doesn't work on
the selected directory. If files are not selected at the bottom pane of the
VFS browser, the 'properties' context menu won't be available when
right-clicking a directory in the top pane. And worse, if files are
selected in the bottom pane, then right-clicking a directory in the top
pane and selecting 'properties' will show the properties of the files in
the bottom pane, not the properties of the directory in the top pane for
which the context menu was invoked.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2008-12-30 08:30

Message:
Committed to SVN rev. 14253. Thanks a lot!

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

Comment By: VladimirR (vladimirr)
Date: 2008-11-26 22:18

Message:
I've uploaded the fixed patch, with the next changes:
- the properties entry only shows up in the context menu, when there's at
least one selected item
- the string properties have been moved to the jedit_gui.props file
- the typo has been fixed

About the checkboxes:
It would require Java6 to be able to change the readablity/writeablity to
both ways (java <6 only allows to invoke rights), that's why the checkboxes
are read-only.
Also, you're able to obtain the information about modification date and
filesize, even if you have no access to the file. I guess, this happens,
becouse you read those from the file sytem, and not the file itself (i was
able to see the size, and date for /etc/shadow as a limited user).

File Added: FilePropertiesDialog_v2.patch

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

Comment By: Zoltan Balog (ali_g)
Date: 2008-11-25 11:14

Message:
Thanks to observe our "mini" project and your advices. The bug will fix as
soon as possible (maybe at this moment) and we will discuss the checkbox,
what you mentioned.

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

Comment By: Dale Anson (daleanson)
Date: 2008-11-25 08:07

Message:
I see a few problems:

When right-clicking on a directory in the top half of the file browser,
then choosing "Properties" from the context menu, I get a bean shell error:
java.lang.ArrayIndexOutOfBoundsException: 0
	at
org.gjt.sp.jedit.gui.FilePropertiesDialog.<init>(FilePropertiesDialog.java:51)
	at
org.gjt.sp.jedit.browser.VFSBrowser.fileProperties(VFSBrowser.java:864)
...

The string properties in FilePropertiesDialog should be moved to
jedit_gui.props so that others can localize for their language.  Also,
Attribute is misspelled as Atribute.

I'm curious about the "Readable" and "Writable" checkboxes.  Would you
ever be able to show properties for a file that is not readable?  Neither
of these checkboxes are clickable, should at least the "Writable" checkbox
function so the user can change this value?

Otherwise, this looks good, the coding standard follows the jEdit standard
and the patch applied without error.

Thanks!


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

Comment By: Norbert Tóth (totka)
Date: 2008-11-23 21:42

Message:
I took 3 screenshots from this feature: 
* Context menu: http://img113.imageshack.us/my.php?image=contexttk6.png

* If you select one file, you see this FileProperties window:
http://img510.imageshack.us/my.php?image=filepropvw6.png
With editing the name's textfield and click on the OK button, you can
rename the file.

* If you select more files, you see this FileProperties windows:
http://img45.imageshack.us/my.php?image=filespropjn8.png



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

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Accepted
Priority: 5
Private: No
Submitted By: VladimirR (vladimirr)
Assigned to: Shlomy Reinstein (shlomy)
Summary: [1936518] File/Directory properties dialog

Initial Comment:
Here's the patch for a File/Directory properties dialog.
It adds the "properties" entry to the context menu of the file browser, which opens a dialog showing the file's/directory's name, path, date of last modification, size, and accesibility, for a single file/directory or the path and total size of the multiple selected items.
Please feel free to comment this patch, since it's for a scool project, and we need some feedback.


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

Comment By: Zoltan Balog (ali_g)
Date: 2008-12-30 09:12

Message:
Sorry, but the properties entry only shows (as vladimirr posted it) at the
following condition:
- the properties entry only shows up in the context menu, when there's at
least one selected item.
But the directory problem weird.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2008-12-30 07:43

Message:
Note that this patch only works on the selected files, it doesn't work on
the selected directory. If files are not selected at the bottom pane of the
VFS browser, the 'properties' context menu won't be available when
right-clicking a directory in the top pane. And worse, if files are
selected in the bottom pane, then right-clicking a directory in the top
pane and selecting 'properties' will show the properties of the files in
the bottom pane, not the properties of the directory in the top pane for
which the context menu was invoked.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2008-12-30 07:30

Message:
Committed to SVN rev. 14253. Thanks a lot!

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

Comment By: VladimirR (vladimirr)
Date: 2008-11-26 21:18

Message:
I've uploaded the fixed patch, with the next changes:
- the properties entry only shows up in the context menu, when there's at
least one selected item
- the string properties have been moved to the jedit_gui.props file
- the typo has been fixed

About the checkboxes:
It would require Java6 to be able to change the readablity/writeablity to
both ways (java <6 only allows to invoke rights), that's why the checkboxes
are read-only.
Also, you're able to obtain the information about modification date and
filesize, even if you have no access to the file. I guess, this happens,
becouse you read those from the file sytem, and not the file itself (i was
able to see the size, and date for /etc/shadow as a limited user).

File Added: FilePropertiesDialog_v2.patch

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

Comment By: Zoltan Balog (ali_g)
Date: 2008-11-25 10:14

Message:
Thanks to observe our "mini" project and your advices. The bug will fix as
soon as possible (maybe at this moment) and we will discuss the checkbox,
what you mentioned.

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

Comment By: Dale Anson (daleanson)
Date: 2008-11-25 07:07

Message:
I see a few problems:

When right-clicking on a directory in the top half of the file browser,
then choosing "Properties" from the context menu, I get a bean shell error:
java.lang.ArrayIndexOutOfBoundsException: 0
	at
org.gjt.sp.jedit.gui.FilePropertiesDialog.<init>(FilePropertiesDialog.java:51)
	at
org.gjt.sp.jedit.browser.VFSBrowser.fileProperties(VFSBrowser.java:864)
...

The string properties in FilePropertiesDialog should be moved to
jedit_gui.props so that others can localize for their language.  Also,
Attribute is misspelled as Atribute.

I'm curious about the "Readable" and "Writable" checkboxes.  Would you
ever be able to show properties for a file that is not readable?  Neither
of these checkboxes are clickable, should at least the "Writable" checkbox
function so the user can change this value?

Otherwise, this looks good, the coding standard follows the jEdit standard
and the patch applied without error.

Thanks!


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

Comment By: Norbert Tóth (totka)
Date: 2008-11-23 20:42

Message:
I took 3 screenshots from this feature: 
* Context menu: http://img113.imageshack.us/my.php?image=contexttk6.png

* If you select one file, you see this FileProperties window:
http://img510.imageshack.us/my.php?image=filepropvw6.png
With editing the name's textfield and click on the OK button, you can
rename the file.

* If you select more files, you see this FileProperties windows:
http://img45.imageshack.us/my.php?image=filespropjn8.png



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

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Accepted
Priority: 5
Private: No
Submitted By: VladimirR (vladimirr)
Assigned to: Shlomy Reinstein (shlomy)
Summary: [1936518] File/Directory properties dialog

Initial Comment:
Here's the patch for a File/Directory properties dialog.
It adds the "properties" entry to the context menu of the file browser, which opens a dialog showing the file's/directory's name, path, date of last modification, size, and accesibility, for a single file/directory or the path and total size of the multiple selected items.
Please feel free to comment this patch, since it's for a scool project, and we need some feedback.


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

>Comment By: Shlomy Reinstein (shlomy)
Date: 2008-12-30 08:43

Message:
Note that this patch only works on the selected files, it doesn't work on
the selected directory. If files are not selected at the bottom pane of the
VFS browser, the 'properties' context menu won't be available when
right-clicking a directory in the top pane. And worse, if files are
selected in the bottom pane, then right-clicking a directory in the top
pane and selecting 'properties' will show the properties of the files in
the bottom pane, not the properties of the directory in the top pane for
which the context menu was invoked.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2008-12-30 08:30

Message:
Committed to SVN rev. 14253. Thanks a lot!

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

Comment By: VladimirR (vladimirr)
Date: 2008-11-26 22:18

Message:
I've uploaded the fixed patch, with the next changes:
- the properties entry only shows up in the context menu, when there's at
least one selected item
- the string properties have been moved to the jedit_gui.props file
- the typo has been fixed

About the checkboxes:
It would require Java6 to be able to change the readablity/writeablity to
both ways (java <6 only allows to invoke rights), that's why the checkboxes
are read-only.
Also, you're able to obtain the information about modification date and
filesize, even if you have no access to the file. I guess, this happens,
becouse you read those from the file sytem, and not the file itself (i was
able to see the size, and date for /etc/shadow as a limited user).

File Added: FilePropertiesDialog_v2.patch

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

Comment By: Zoltan Balog (ali_g)
Date: 2008-11-25 11:14

Message:
Thanks to observe our "mini" project and your advices. The bug will fix as
soon as possible (maybe at this moment) and we will discuss the checkbox,
what you mentioned.

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

Comment By: Dale Anson (daleanson)
Date: 2008-11-25 08:07

Message:
I see a few problems:

When right-clicking on a directory in the top half of the file browser,
then choosing "Properties" from the context menu, I get a bean shell error:
java.lang.ArrayIndexOutOfBoundsException: 0
	at
org.gjt.sp.jedit.gui.FilePropertiesDialog.<init>(FilePropertiesDialog.java:51)
	at
org.gjt.sp.jedit.browser.VFSBrowser.fileProperties(VFSBrowser.java:864)
...

The string properties in FilePropertiesDialog should be moved to
jedit_gui.props so that others can localize for their language.  Also,
Attribute is misspelled as Atribute.

I'm curious about the "Readable" and "Writable" checkboxes.  Would you
ever be able to show properties for a file that is not readable?  Neither
of these checkboxes are clickable, should at least the "Writable" checkbox
function so the user can change this value?

Otherwise, this looks good, the coding standard follows the jEdit standard
and the patch applied without error.

Thanks!


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

Comment By: Norbert Tóth (totka)
Date: 2008-11-23 21:42

Message:
I took 3 screenshots from this feature: 
* Context menu: http://img113.imageshack.us/my.php?image=contexttk6.png

* If you select one file, you see this FileProperties window:
http://img510.imageshack.us/my.php?image=filepropvw6.png
With editing the name's textfield and click on the OK button, you can
rename the file.

* If you select more files, you see this FileProperties windows:
http://img45.imageshack.us/my.php?image=filespropjn8.png



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

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

Feature Requests item #1936518, was opened at 2008-04-07 11:15
Message generated for change (Comment added) made by shlomy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350588&aid=1936518&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Shlomy Reinstein (shlomy)
>Assigned to: Shlomy Reinstein (shlomy)
Summary: File/Directory properties dialog

Initial Comment:
Add "Properties" to the context menu of the File Browser, showing the file/directory properties of the selected item (e.g. date, size, path).

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

>Comment By: Shlomy Reinstein (shlomy)
Date: 2008-12-30 08:31

Message:
Committed the related patch to SVN.

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

Comment By: VladimirR (vladimirr)
Date: 2008-11-16 18:04

Message:
A patch (2296738) has been submitted to this feature request.

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

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: VladimirR (vladimirr)
>Assigned to: Shlomy Reinstein (shlomy)
Summary: [1936518] File/Directory properties dialog

Initial Comment:
Here's the patch for a File/Directory properties dialog.
It adds the "properties" entry to the context menu of the file browser, which opens a dialog showing the file's/directory's name, path, date of last modification, size, and accesibility, for a single file/directory or the path and total size of the multiple selected items.
Please feel free to comment this patch, since it's for a scool project, and we need some feedback.


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

>Comment By: Shlomy Reinstein (shlomy)
Date: 2008-12-30 08:30

Message:
Committed to SVN rev. 14253. Thanks a lot!

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

Comment By: VladimirR (vladimirr)
Date: 2008-11-26 22:18

Message:
I've uploaded the fixed patch, with the next changes:
- the properties entry only shows up in the context menu, when there's at
least one selected item
- the string properties have been moved to the jedit_gui.props file
- the typo has been fixed

About the checkboxes:
It would require Java6 to be able to change the readablity/writeablity to
both ways (java <6 only allows to invoke rights), that's why the checkboxes
are read-only.
Also, you're able to obtain the information about modification date and
filesize, even if you have no access to the file. I guess, this happens,
becouse you read those from the file sytem, and not the file itself (i was
able to see the size, and date for /etc/shadow as a limited user).

File Added: FilePropertiesDialog_v2.patch

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

Comment By: Zoltan Balog (ali_g)
Date: 2008-11-25 11:14

Message:
Thanks to observe our "mini" project and your advices. The bug will fix as
soon as possible (maybe at this moment) and we will discuss the checkbox,
what you mentioned.

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

Comment By: Dale Anson (daleanson)
Date: 2008-11-25 08:07

Message:
I see a few problems:

When right-clicking on a directory in the top half of the file browser,
then choosing "Properties" from the context menu, I get a bean shell error:
java.lang.ArrayIndexOutOfBoundsException: 0
	at
org.gjt.sp.jedit.gui.FilePropertiesDialog.<init>(FilePropertiesDialog.java:51)
	at
org.gjt.sp.jedit.browser.VFSBrowser.fileProperties(VFSBrowser.java:864)
...

The string properties in FilePropertiesDialog should be moved to
jedit_gui.props so that others can localize for their language.  Also,
Attribute is misspelled as Atribute.

I'm curious about the "Readable" and "Writable" checkboxes.  Would you
ever be able to show properties for a file that is not readable?  Neither
of these checkboxes are clickable, should at least the "Writable" checkbox
function so the user can change this value?

Otherwise, this looks good, the coding standard follows the jEdit standard
and the patch applied without error.

Thanks!


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

Comment By: Norbert Tóth (totka)
Date: 2008-11-23 21:42

Message:
I took 3 screenshots from this feature: 
* Context menu: http://img113.imageshack.us/my.php?image=contexttk6.png

* If you select one file, you see this FileProperties window:
http://img510.imageshack.us/my.php?image=filepropvw6.png
With editing the name's textfield and click on the OK button, you can
rename the file.

* If you select more files, you see this FileProperties windows:
http://img45.imageshack.us/my.php?image=filespropjn8.png



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

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

Patches item #2106987, was opened at 2008-09-12 00:37
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300588&aid=2106987&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: Victor Engmark (engmark)
>Assigned to: Alan Ezust (ezust)
Summary: vCard mode

Initial Comment:
It looks like there's some interest in a vCard mode (see request 1934498), so I'm hoping to branch the iCalendar mode file to make one that supports vCard 2 & 3. I'd be very grateful for any (generated or hand-written) test vCards.

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

>Comment By: Alan Ezust (ezust)
Date: 2008-12-29 20:33

Message:
Are they both .ics file extensions? If not, what is the recommended file
name globs for each of these two types (ics and vcard)? I thought they were
the same up to now.





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

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: general
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Victor Engmark (engmark)
Assigned to: Alan Ezust (ezust)
Summary: iCalendar mode

Initial Comment:
This mode file subdivides the iCalendar file into a tree and treats each portion mostly separate (some keywords are shared by sections). It does not cover all conceivable keywords, but it works fine with files generated by Mozilla Sunbird 0.7 in 4.3pre12.

Keyword usage:
BEGIN / END lines become KEYWORD1.
Other keywords at the start of a line become KEYWORD2, except for non-standard ones (X-*), which become INVALID*.
KEY=value pairs left of the colon are treated as KEYWORD3/LITERAL3.
Similar pairs on the right side become KEYWORD4/LITERAL4.
Simple text on the right side becomes LITERAL4.

Hoping to develop a more complete file from http://www.kanzaki.com/docs/ical/, but it could take a while.

* I don't think these are strictly invalid in an iCal file, but it's useful to differentiate them from the standard ones.

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

>Comment By: Alan Ezust (ezust)
Date: 2008-12-29 20:31

Message:
Committed revision 14252.
Sorry it took so long! --alan


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

Comment By: Victor Engmark (engmark)
Date: 2008-09-12 00:39

Message:
Good idea, by the way, ezust - Can you submit the file to request #2106987?
Thanks!

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

Comment By: Victor Engmark (engmark)
Date: 2008-09-12 00:25

Message:
vCards are not a subset of iCalendar (see
http://tools.ietf.org/html/rfc2445), but there are lots of similarities, so
it shouldn't be too hard to branch this syntax file and adapt it to vCard.

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

Comment By: Alan Ezust (ezust)
Date: 2008-09-11 18:46

Message:
Are vcards also icalendar format? I have another test case :-)

File Added: std.vcf

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

Comment By: Victor Engmark (engmark)
Date: 2008-05-14 01:46

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

Fixed that "X-" keywords should be able to contain lower case letters, and
included the "SEQUENCE" keyword. Works with std.ics and notes.ics. Any more
test cases?
File Added: ical.xml

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

Comment By: Alan Ezust (ezust)
Date: 2008-05-07 12:52

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

please test with the attached files.


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

Comment By: Alan Ezust (ezust)
Date: 2008-05-07 12:50

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

File Added: std.ics

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

Comment By: Alan Ezust (ezust)
Date: 2008-05-07 12:49

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

File Added: notes.ics

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

Comment By: Victor Engmark (engmark)
Date: 2008-05-06 03:13

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

File Added: ical.xml

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

Comment By: Victor Engmark (engmark)
Date: 2008-05-06 02:42

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

The current file should work with TODO and journal entries. For further
bugs, can you add a test case?

I haven't been able to find a sufficiently well structured document to
easily create a complete definition file, so there are still omissions and
/ or errors in the current file. If anyone finds an XML schema or similar
document with a complete iCalendar definition, that would be very welcome.
File Added: ical.xml

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

Comment By: Alan Ezust (ezust)
Date: 2008-04-26 17:22

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

it seems to be coloring fine some BEGIN:VEVENT and BEGIN:VALARM, but
doesn't recognize BEGIN:VJOURNAL and BEGIN:VTODO
Would you mind revisiting this and making it more complete?

--alan


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

Comment By: Victor Engmark (engmark)
Date: 2008-04-04 07:23

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

Minor fixes:
- Added some keywords and literals from
http://www.kanzaki.com/docs/ical/.
- Sorting literals so they appear just below the keyword they belong to.
File Added: ical.xml

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

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

Patches item #1905574, was opened at 2008-03-02 07:10
Message generated for change (Settings changed) made by shlomy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300588&aid=1905574&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: encorejane (encorejane)
>Assigned to: Shlomy Reinstein (shlomy)
Summary: Search whole word option

Initial Comment:
This patch contains mostly gui updates to the Search Dialog and the Search Bar. It adds the option to search for whole word, by simple using \b \b and searching it as a regex.

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

Comment By: Shlomy Reinstein (shlomy)
Date: 2008-12-30 06:23

Message:
This sounds like a nice option, however I think this option should be
mutually exclusive with the regexp option, so that the user can either
choose to search for a regexp or search for a whole word but not both. A
while who searches for a regexp can easily add the "\b" around the word
where suitable, adding this automatically to a regexp is sort-of
'dangerous'.

This patch allows both to be used at the same time.

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

Comment By: Matthieu Casanova (kpouer)
Date: 2008-03-08 22:40

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

Hi, I would be happy to try your patch, but could you try to do a patch
that do not reorganize methods order or join splitted lines ?

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

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