jedit-devel Mailing List for jEdit

Plugin Central Submission item #3445860, was opened at 2011-11-29 22:50
Message generated for change (Comment added) made by elberry
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=625093&aid=3445860&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: Pending
Priority: 5
Private: No
Submitted By: Shlomy Reinstein (shlomy)
>Assigned to: Townsfolk (elberry)
Summary: CtagsSideKick 1.5

Initial Comment:
{{{ CtagsSideKick 1.5
    Source: Source code is in Git with the tag CtagsSideKick-1.5
    Announcement: Updates for using with jEdit 4.5
    Requires Java 1.6
    Requires jEdit 04.04.99.00
    Required plugins: 
        SideKick 1.3 (sidekick.SideKickPlugin)
    
    Short Description: CtagsSideKick provides a structure browser service for SideKick using exuberant ctags. Support exists for these languages: C, C++, Perl, Python, Bash, Java, JavaScript, Lisp, Make, PHP, Ruby, Scheme, SQL, YACC, XML, Ant, Cobol, Eiffel, AWK, Fortran, and Pascal.
    
    Long Description: <p>
CtagsSideKick provides a structure browser service for SideKick using exuberant ctags. Support exists for these languages: C, C++, Perl, Python, Bash, Java, JavaScript, Lisp, Make, PHP, Ruby, Scheme, SQL, YACC, XML, Ant, Cobol, Eiffel, AWK, Fortran, and Pascal.
</p>
<p> CtagsSideKick is based on the CodeBrowser plugin, but it can  group tags by namespace (e.g. grouping class members under their class), and provides icons representing the tag type (function/variable/...). These are especially useful when there are several tags of the same name in the buffer, which is common in object-oriented languages such as C++ and Java.
</p>

 }}}

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

>Comment By: Townsfolk (elberry)
Date: 2011-11-30 14:54

Message:
Same with this one. It's complaining about the documentation generation.
Please fix the build.xml file and reopen.

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

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

Plugin Central Submission item #3445817, was opened at 2011-11-29 20:37
Message generated for change (Comment added) made by elberry
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=625093&aid=3445817&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: Pending
Priority: 5
Private: No
Submitted By: Shlomy Reinstein (shlomy)
>Assigned to: Townsfolk (elberry)
Summary: MyDoggyPlugin 0.3

Initial Comment:
Paste the text below into the Plugin Central Submission Tracker at https://sourceforge.net/tracker/?group_id=588&atid=625093

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

{{{ MyDoggyPlugin 0.3
    Source: Source code is in Git with the tag MyDoggyPlugin-0.3
    Announcement: Small bug fixes
    Requires Java 1.5
    Requires jEdit 04.03.17.00
    
    Short Description: MyDoggyPlugin uses MyDoggy to manage the dockable windows in jEdit.
    
    Long Description: <p>
MyDoggyPlugin allows you to use the open-source docking framework named MyDoggy to manage the dockable windows in jEdit. This enables dockable windows to be dragged from one area to another, share the same docking area, and more.
</p>

 }}}

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

>Comment By: Townsfolk (elberry)
Date: 2011-11-30 14:50

Message:
Shlomy I'm having issues building because it's trying to generate the
documentation. since your plugin has pre-created documentation you need to
add:
<property name="docs-proc.target" value="none" />

To your build script. I tried to add it myself, but when I try to push my
changes up to git I'm getting an error:
fatal: The remote end hung up unexpectedly

Not sure what I'm doing wrong, so could you add that property to your
build.xml file and then recreate the tag?

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

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

Plugin Central Submission item #3445531, was opened at 2011-11-29 13:29
Message generated for change (Comment added) made by elberry
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=625093&aid=3445531&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: Pending
Priority: 5
Private: No
Submitted By: Matthieu Casanova (kpouer)
>Assigned to: Townsfolk (elberry)
Summary: SmartOpen 1.0.0

Initial Comment:
{{{ SmartOpen 1.0.0
    Source: https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/SmartOpen/tags/SmartOpen-1.0.0
    Announcement: Initial release
    Requires Java 1.6
    Requires jEdit 04.04.01.00
    Required plugins: 
        Common Controls 1.4 (CommonControlsPlugin)
        LucenePlugin 2.8 (gatchan.jedit.lucene.LucenePlugin)
        Project Viewer 3.2 (projectviewer.ProjectPlugin)
    
    Short Description: SmartOpen will help you open your files quickly
    
    Long Description: <b>SmartOpen</b> is another plugin that will help you to quickly open your files.<br/>
It can index files from the folders you want, or from ProjectViewer<br/>
	It supports search from any part of your filename, or camelcase search.<br>
	For example if you want a file named AbstractOptionPane.java you can search with
	<b>AOP</b> or <b>AOP</b>ane or <b>A</b>bs<b>Opr</b><b>P</b> and all combinations you want
 }}}

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

>Comment By: Townsfolk (elberry)
Date: 2011-11-30 14:36

Message:
Getting a bunch of compile time errors:
 [jp.javac]
/Users/elberry/development/projects/jedit/sandbox/SmartOpen-1.0.0/SmartOpen/src/com/kpouer/jedit/smartopen/SmartOpenToolbar.java:41:
cannot find symbol
 [jp.javac] symbol  : class ItemFinderPanel
 [jp.javac] location: class com.kpouer.jedit.smartopen.SmartOpenToolbar
 [jp.javac] 		itemFinderPanel = new ItemFinderPanel<String>(view,
itemFinder);
 [jp.javac] 		                      ^
 [jp.javac] 24 errors

I can see in the output that Ivy's downloading at least ProjectViewer:
[ivy:retrieve] 	[SUCCESSFUL ]
jedit-plugins#ProjectViewer;3.2.0!ProjectViewer.jar (3946ms)
[ivy:retrieve] :: resolution report :: resolve 7009ms :: artifacts dl
3968ms
	---------------------------------------------------------------------
	|                  |            modules            ||   artifacts   |
	|       conf       | number| search|dwnlded|evicted|| number|dwnlded|
	---------------------------------------------------------------------
	|      default     |   2   |   1   |   0   |   0   ||   2   |   1   |
	---------------------------------------------------------------------
[ivy:retrieve] :: retrieving :: jedit-plugins#Ancestor
[ivy:retrieve] 	confs: [default]
[ivy:retrieve] 	2 artifacts copied, 0 already retrieved (2102kB/61ms)

Perhaps the other two dependencies aren't part of the ivy config?

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

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

Plugin Feature Requests item #2093226, was opened at 2008-09-04 06:57
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=2093226&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: Petr Tuma (ceresek)
Assigned to: Dale Anson (daleanson)
Summary: Position Stack with Push & Pop position

Initial Comment:
Apart from having the "absolute" markers (with functions SET/UNSET and GOTO NEXT/PREV), it would be nice to have "stack" markers in the text (with functions PUSH POSITION/POP POSITION).

Usage:
 - While typing, I decide I need to look in some other place in the open window.
 - I press "PUSH POSITION", my current position is pushed on the marker stack.
 - I can now move around the text as necessary.
 - When I want to return to where I was, I press "POP POSITION".

The PUSH/POP would work like normal stack of positions.

Thanks for considering this :-)

Petr


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

>Comment By: Alan Ezust (ezust)
Date: 2011-11-30 14:08

Message:
This was in the Tags plugin which is no longer supported.


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

Comment By: Dale Anson (daleanson)
Date: 2011-11-30 13:52

Message:
Actually, I'm not sure what is the difference between the requested feature
and what Navigator already does. Right clicking on the Navigator buttons
shows a drop down of back/forward positions to jump directly to. The
Navigator dockable shows the both the back and forward positions and moving
to those positions directly is a mouse click. Is the request for
Navigator-like functionality, but rather than have Navigator automatically
track movement, allow the user to select the positions? If that is the
case, then perhaps MarkerSets is the better place for this.

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

Comment By: Jarek Czekalski (jarekczek)
Date: 2011-11-30 07:44

Message:
This looks very much like the way I use marker sets, patched. I have
markers numbered 0-9. When I set a new marker with a shortcut 0, it removes
previous with that number. So if MarkerSets had a special set called Stack
it would be almost done. Only a counter would be needed to know which is
the current shortcut. And the operations Push/Pop would fire methods that
are in MarkerSetsPlugin with a correct number: the top of the stack.

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

Comment By: Dale Anson (daleanson)
Date: 2011-11-30 06:20

Message:
Navigator sounds like the right place. 

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

Comment By: Alan Ezust (ezust)
Date: 2011-11-29 21:01

Message:
I want to implement this but I am having a hard time deciding whether it
should go in markersets or navigator.


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

Comment By: Petr Tuma (ceresek)
Date: 2008-09-04 11:08

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

Thanks for pointing this out ! I did try the Navigator plugin, but it does
not do quite the same thing, since it is not possible to explicitly place a
marker - instead, it just collects the positions in the text, which are not
always where one would place a marker explicitly. Back some time ago, I
have used an editor with the position stack, and (at least as far as I can
remember :-), it was more handy than what the Navigator plugin does.


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

Comment By: Alan Ezust (ezust)
Date: 2008-09-04 08:06

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

Have you tried the Navigator plugin? That's all it does.


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

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

Feature Requests item #918301, was opened at 2004-03-17 13:03
Message generated for change (Comment added) made by kpouer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350588&aid=918301&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: Tyler Ward (vertigre)
Assigned to: Matthieu Casanova (kpouer)
Summary: poor performance with large text files and soft wrap

Initial Comment:

Jedit does a tolerable job of opening medium size text
files, but is no match for UltraEdit with large files.
if there was a way to easily open very large files,
that would be very nice. 

This is the algorithm I reccomend, though it's just a
though. 

1) If the file size is over a set limit, go into large
file mode. 

2) In large file mode, on opening a file, scan through
it for newlines and record the position of each newline.

3) Count the lines (number of newlines found) and load
up an area around the current text display window, this
can be done by seeking to the appropriate spot in the
file. For instance, if someone scrolls 2/3 of the way
down a million line file, then you need to load in
lines around line 670,000, and you conveniently know
the offset into the file of the line, because you made
a table of it. So you pick your spot, then load in a
few thousand lines above and below, using that as the
display. Whenever the user gets too close to the edge,
refresh it. 


This is a big task, but something that jedit should
consider if it is going to become the ultimate text
editor. 


-Tyler




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

>Comment By: Matthieu Casanova (kpouer)
Date: 2011-11-30 13:58

Message:
Yes, this property means that the edit mode is not context insensitive
(jEdit do not have to calculate syntax highlight of line n-1 before
calculating syntax highlight of line n.
This is very important because with a large buffer when you go to the
latest line jEdit have to highlight the entire buffer if the context is
sensitive.

What jEdit does when a buffer is very large is to suggest to switch to
context insensitive if the edit mode do not already have this option.


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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 12:16

Message:
it is commented out - does this property drive the large buffer dialog?

  <PROPS>
    <PROPERTY NAME="wordBreakChars" VALUE=",+-=&lt;&gt;/?^&amp;*&nbsp;" />
    <!-- <PROPERTY NAME="contextInsensitive" VALUE="true"/> -->
  </PROPS>

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

Comment By: Matthieu Casanova (kpouer)
Date: 2011-11-30 11:51

Message:
Does your text.xml file contains this ?

<PROPS>
		<PROPERTY NAME="contextInsensitive" VALUE="true" />
	</PROPS>


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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 11:41

Message:
the edit mode was 'txt' - as I stated in catalog in mode folder for
handling *.txt files.

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

Comment By: Matthieu Casanova (kpouer)
Date: 2011-11-30 11:30

Message:
but what was the edit mode used by your file when you opened it ?

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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 11:24

Message:
Ah, it seems that this is my doing then; when I first started using jedit,
I made a copy of 'text' mode, customized the syntax highlighting and
renamed it as 'txt' mode which I use as default for text files. 

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

Comment By: Matthieu Casanova (kpouer)
Date: 2011-11-30 11:23

Message:
In fact you're right, there is a bug

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

Comment By: Matthieu Casanova (kpouer)
Date: 2011-11-30 11:06

Message:
I don't understand. If the edit mode is text, the dialog do not appear.

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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 09:39

Message:
Speaking of the large file mode, is there a way to switch off this feature?
Seeing that the simple text mode highlighting does not slow the file
loading, it is practically useless for text files to show this warning.

tvojeho

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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 09:34

Message:
Yes, that could help in some cases, unfortunately for me most of the time I
need to use the soft wrap. At least I have the time to make coffee while
opening the larger files ;)

tvojeho

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

Comment By: Alan Ezust (ezust)
Date: 2011-11-30 09:25

Message:
Perhaps the "large file mode" should also have an option to disable
soft-wrap and not just highlighting.


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

Comment By: Alan Ezust (ezust)
Date: 2011-11-30 09:18

Message:
Soft wrap is expensive, there is no doubt about it. 

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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 09:06

Message:
Hi, I am not sure how much delay the Sidekick is causing because I am not
using this plugin, but for me the biggest problem is soft wordwrap. I am
running jEdit 5.0 pre version on Win7 on a laptop 2.2 GHz AMD cpu with 4 GB
RAM, Sun java 1.6.0_29 and opening a 4 MB text file with soft wrap is a
chore. 

I tried how much difference the syntax highlighting mode makes, and it
seems not much.

Time for text to load:
Word wrap soft, full syntax highlight...1 min 55 secs
Word wrap soft, context insensitive syntax highlight...1 min 54 secs
Word wrap none, full syntax highlight...0 min 5 secs
Word wrap none, context insensitive syntax highlight...0 min 4 secs

Regards, tvojeho

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

Comment By: Alan Ezust (ezust)
Date: 2011-11-29 22:55

Message:
jEdit 4.5pre1 now has a large-file mode that kicks in and allows you to
pick a faster syntax highlighting mode.
This still doesn't prevent sidekick from doing its thing but that's another
issue people are looking at now.




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

Comment By: Matthieu Casanova (kpouer)
Date: 2009-11-02 05:26

Message:
moved to feature requests

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

Comment By: rletzler (rletzler)
Date: 2009-11-01 20:21

Message:
jEdit also gives no feedback about progress beyond telling us that 1 i/o
operation is in progress, so it is difficult to tell whether it is hard at
work opening a huge file or has frozen up.  Some kind of prominent percent
done text or thermometer display would be quite useful.

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

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

Plugin Feature Requests item #2093226, was opened at 2008-09-04 06:57
Message generated for change (Comment added) made by daleanson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=2093226&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: Petr Tuma (ceresek)
Assigned to: Dale Anson (daleanson)
Summary: Position Stack with Push & Pop position

Initial Comment:
Apart from having the "absolute" markers (with functions SET/UNSET and GOTO NEXT/PREV), it would be nice to have "stack" markers in the text (with functions PUSH POSITION/POP POSITION).

Usage:
 - While typing, I decide I need to look in some other place in the open window.
 - I press "PUSH POSITION", my current position is pushed on the marker stack.
 - I can now move around the text as necessary.
 - When I want to return to where I was, I press "POP POSITION".

The PUSH/POP would work like normal stack of positions.

Thanks for considering this :-)

Petr


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

>Comment By: Dale Anson (daleanson)
Date: 2011-11-30 13:52

Message:
Actually, I'm not sure what is the difference between the requested feature
and what Navigator already does. Right clicking on the Navigator buttons
shows a drop down of back/forward positions to jump directly to. The
Navigator dockable shows the both the back and forward positions and moving
to those positions directly is a mouse click. Is the request for
Navigator-like functionality, but rather than have Navigator automatically
track movement, allow the user to select the positions? If that is the
case, then perhaps MarkerSets is the better place for this.

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

Comment By: Jarek Czekalski (jarekczek)
Date: 2011-11-30 07:44

Message:
This looks very much like the way I use marker sets, patched. I have
markers numbered 0-9. When I set a new marker with a shortcut 0, it removes
previous with that number. So if MarkerSets had a special set called Stack
it would be almost done. Only a counter would be needed to know which is
the current shortcut. And the operations Push/Pop would fire methods that
are in MarkerSetsPlugin with a correct number: the top of the stack.

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

Comment By: Dale Anson (daleanson)
Date: 2011-11-30 06:20

Message:
Navigator sounds like the right place. 

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

Comment By: Alan Ezust (ezust)
Date: 2011-11-29 21:01

Message:
I want to implement this but I am having a hard time deciding whether it
should go in markersets or navigator.


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

Comment By: Petr Tuma (ceresek)
Date: 2008-09-04 11:08

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

Thanks for pointing this out ! I did try the Navigator plugin, but it does
not do quite the same thing, since it is not possible to explicitly place a
marker - instead, it just collects the positions in the text, which are not
always where one would place a marker explicitly. Back some time ago, I
have used an editor with the position stack, and (at least as far as I can
remember :-), it was more handy than what the Navigator plugin does.


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

Comment By: Alan Ezust (ezust)
Date: 2008-09-04 08:06

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

Have you tried the Navigator plugin? That's all it does.


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

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

Plugin Bugs item #3446299, was opened at 2011-11-30 10:29
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3446299&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: Invalid
Priority: 5
Private: No
Submitted By: don Rhummy (donrhummy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Updater incorrectly has 4.5pre1 as "Latest Official Release"

Initial Comment:
a "pre" release should NEVER be considered an official release. But the updater plugin updates to 4.5pre1 when you choose the source "Latest Official Release". This is incorrect.

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

>Comment By: Alan Ezust (ezust)
Date: 2011-11-30 13:29

Message:
If you want updater to continue delivering versions to you from the 4.4.x
branch, choose the "daily build" of the "stable branch" which will give you
4.4.3 + any bugfixes that get merged into it.


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

Comment By: Alan Ezust (ezust)
Date: 2011-11-30 10:56

Message:
4.5pre1 was released officially. You did not get a daily build. 

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

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

Feature Requests item #918301, was opened at 2004-03-17 13:03
Message generated for change (Comment added) made by tvojeho
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350588&aid=918301&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: Tyler Ward (vertigre)
Assigned to: Matthieu Casanova (kpouer)
Summary: poor performance with large text files and soft wrap

Initial Comment:

Jedit does a tolerable job of opening medium size text
files, but is no match for UltraEdit with large files.
if there was a way to easily open very large files,
that would be very nice. 

This is the algorithm I reccomend, though it's just a
though. 

1) If the file size is over a set limit, go into large
file mode. 

2) In large file mode, on opening a file, scan through
it for newlines and record the position of each newline.

3) Count the lines (number of newlines found) and load
up an area around the current text display window, this
can be done by seeking to the appropriate spot in the
file. For instance, if someone scrolls 2/3 of the way
down a million line file, then you need to load in
lines around line 670,000, and you conveniently know
the offset into the file of the line, because you made
a table of it. So you pick your spot, then load in a
few thousand lines above and below, using that as the
display. Whenever the user gets too close to the edge,
refresh it. 


This is a big task, but something that jedit should
consider if it is going to become the ultimate text
editor. 


-Tyler




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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 12:16

Message:
it is commented out - does this property drive the large buffer dialog?

  <PROPS>
    <PROPERTY NAME="wordBreakChars" VALUE=",+-=&lt;&gt;/?^&amp;*&nbsp;" />
    <!-- <PROPERTY NAME="contextInsensitive" VALUE="true"/> -->
  </PROPS>

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

Comment By: Matthieu Casanova (kpouer)
Date: 2011-11-30 11:51

Message:
Does your text.xml file contains this ?

<PROPS>
		<PROPERTY NAME="contextInsensitive" VALUE="true" />
	</PROPS>


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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 11:41

Message:
the edit mode was 'txt' - as I stated in catalog in mode folder for
handling *.txt files.

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

Comment By: Matthieu Casanova (kpouer)
Date: 2011-11-30 11:30

Message:
but what was the edit mode used by your file when you opened it ?

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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 11:24

Message:
Ah, it seems that this is my doing then; when I first started using jedit,
I made a copy of 'text' mode, customized the syntax highlighting and
renamed it as 'txt' mode which I use as default for text files. 

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

Comment By: Matthieu Casanova (kpouer)
Date: 2011-11-30 11:23

Message:
In fact you're right, there is a bug

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

Comment By: Matthieu Casanova (kpouer)
Date: 2011-11-30 11:06

Message:
I don't understand. If the edit mode is text, the dialog do not appear.

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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 09:39

Message:
Speaking of the large file mode, is there a way to switch off this feature?
Seeing that the simple text mode highlighting does not slow the file
loading, it is practically useless for text files to show this warning.

tvojeho

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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 09:34

Message:
Yes, that could help in some cases, unfortunately for me most of the time I
need to use the soft wrap. At least I have the time to make coffee while
opening the larger files ;)

tvojeho

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

Comment By: Alan Ezust (ezust)
Date: 2011-11-30 09:25

Message:
Perhaps the "large file mode" should also have an option to disable
soft-wrap and not just highlighting.


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

Comment By: Alan Ezust (ezust)
Date: 2011-11-30 09:18

Message:
Soft wrap is expensive, there is no doubt about it. 

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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 09:06

Message:
Hi, I am not sure how much delay the Sidekick is causing because I am not
using this plugin, but for me the biggest problem is soft wordwrap. I am
running jEdit 5.0 pre version on Win7 on a laptop 2.2 GHz AMD cpu with 4 GB
RAM, Sun java 1.6.0_29 and opening a 4 MB text file with soft wrap is a
chore. 

I tried how much difference the syntax highlighting mode makes, and it
seems not much.

Time for text to load:
Word wrap soft, full syntax highlight...1 min 55 secs
Word wrap soft, context insensitive syntax highlight...1 min 54 secs
Word wrap none, full syntax highlight...0 min 5 secs
Word wrap none, context insensitive syntax highlight...0 min 4 secs

Regards, tvojeho

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

Comment By: Alan Ezust (ezust)
Date: 2011-11-29 22:55

Message:
jEdit 4.5pre1 now has a large-file mode that kicks in and allows you to
pick a faster syntax highlighting mode.
This still doesn't prevent sidekick from doing its thing but that's another
issue people are looking at now.




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

Comment By: Matthieu Casanova (kpouer)
Date: 2009-11-02 05:26

Message:
moved to feature requests

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

Comment By: rletzler (rletzler)
Date: 2009-11-01 20:21

Message:
jEdit also gives no feedback about progress beyond telling us that 1 i/o
operation is in progress, so it is difficult to tell whether it is hard at
work opening a huge file or has frozen up.  Some kind of prominent percent
done text or thermometer display would be quite useful.

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

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

Bugs item #1633460, was opened at 2007-01-11 10:51
Message generated for change (Comment added) made by vampire0
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1633460&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: web site
Group: None
Status: Pending
Resolution: Out of Date
Priority: 5
Private: No
Submitted By: John Zoetebier (johnzoet)
Assigned to: Björn Kautler (vampire0)
Summary: Cannot register at http://community.jedit.org

Initial Comment:
Tried to registerto http://community.jedit.org with many different email addresses.
Nothing is working !
Do not receive an email ever.
Also, cannot login with my Drupal account

Error on web site :

warning: fsockopen(): unable to connect to drupal.org:80 in /home/groups/j/je/jedit-community/htdocs/includes/xmlrpc.inc on line 410.






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

>Comment By: Björn Kautler (vampire0)
Date: 2011-11-30 12:03

Message:
You can just request a new passsword for the accounts you created back then
and get a new password mailed to your email address.

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

Comment By: Björn Kautler (vampire0)
Date: 2011-11-30 12:02

Message:
Indeed, registration works since a long time.
Before I fixed it mail sending was not possible.
Drupal ID logins will never work as long as the site is hosted on SF as
they don't allow outbound connections. afair I deactivated Drupal ID logins
for that reason.

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

Comment By: Alan Ezust (ezust)
Date: 2011-11-29 20:52

Message:
I think it works now. re-open if it doesn't.

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

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

Bugs item #1633460, was opened at 2007-01-11 10:51
Message generated for change (Comment added) made by vampire0
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1633460&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: web site
Group: None
Status: Pending
Resolution: Out of Date
Priority: 5
Private: No
Submitted By: John Zoetebier (johnzoet)
Assigned to: Björn Kautler (vampire0)
Summary: Cannot register at http://community.jedit.org

Initial Comment:
Tried to registerto http://community.jedit.org with many different email addresses.
Nothing is working !
Do not receive an email ever.
Also, cannot login with my Drupal account

Error on web site :

warning: fsockopen(): unable to connect to drupal.org:80 in /home/groups/j/je/jedit-community/htdocs/includes/xmlrpc.inc on line 410.






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

>Comment By: Björn Kautler (vampire0)
Date: 2011-11-30 12:02

Message:
Indeed, registration works since a long time.
Before I fixed it mail sending was not possible.
Drupal ID logins will never work as long as the site is hosted on SF as
they don't allow outbound connections. afair I deactivated Drupal ID logins
for that reason.

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

Comment By: Alan Ezust (ezust)
Date: 2011-11-29 20:52

Message:
I think it works now. re-open if it doesn't.

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

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

Feature Requests item #918301, was opened at 2004-03-17 13:03
Message generated for change (Comment added) made by kpouer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350588&aid=918301&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: Tyler Ward (vertigre)
Assigned to: Matthieu Casanova (kpouer)
Summary: poor performance with large text files and soft wrap

Initial Comment:

Jedit does a tolerable job of opening medium size text
files, but is no match for UltraEdit with large files.
if there was a way to easily open very large files,
that would be very nice. 

This is the algorithm I reccomend, though it's just a
though. 

1) If the file size is over a set limit, go into large
file mode. 

2) In large file mode, on opening a file, scan through
it for newlines and record the position of each newline.

3) Count the lines (number of newlines found) and load
up an area around the current text display window, this
can be done by seeking to the appropriate spot in the
file. For instance, if someone scrolls 2/3 of the way
down a million line file, then you need to load in
lines around line 670,000, and you conveniently know
the offset into the file of the line, because you made
a table of it. So you pick your spot, then load in a
few thousand lines above and below, using that as the
display. Whenever the user gets too close to the edge,
refresh it. 


This is a big task, but something that jedit should
consider if it is going to become the ultimate text
editor. 


-Tyler




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

>Comment By: Matthieu Casanova (kpouer)
Date: 2011-11-30 11:51

Message:
Does your text.xml file contains this ?

<PROPS>
		<PROPERTY NAME="contextInsensitive" VALUE="true" />
	</PROPS>


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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 11:41

Message:
the edit mode was 'txt' - as I stated in catalog in mode folder for
handling *.txt files.

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

Comment By: Matthieu Casanova (kpouer)
Date: 2011-11-30 11:30

Message:
but what was the edit mode used by your file when you opened it ?

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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 11:24

Message:
Ah, it seems that this is my doing then; when I first started using jedit,
I made a copy of 'text' mode, customized the syntax highlighting and
renamed it as 'txt' mode which I use as default for text files. 

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

Comment By: Matthieu Casanova (kpouer)
Date: 2011-11-30 11:23

Message:
In fact you're right, there is a bug

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

Comment By: Matthieu Casanova (kpouer)
Date: 2011-11-30 11:06

Message:
I don't understand. If the edit mode is text, the dialog do not appear.

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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 09:39

Message:
Speaking of the large file mode, is there a way to switch off this feature?
Seeing that the simple text mode highlighting does not slow the file
loading, it is practically useless for text files to show this warning.

tvojeho

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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 09:34

Message:
Yes, that could help in some cases, unfortunately for me most of the time I
need to use the soft wrap. At least I have the time to make coffee while
opening the larger files ;)

tvojeho

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

Comment By: Alan Ezust (ezust)
Date: 2011-11-30 09:25

Message:
Perhaps the "large file mode" should also have an option to disable
soft-wrap and not just highlighting.


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

Comment By: Alan Ezust (ezust)
Date: 2011-11-30 09:18

Message:
Soft wrap is expensive, there is no doubt about it. 

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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 09:06

Message:
Hi, I am not sure how much delay the Sidekick is causing because I am not
using this plugin, but for me the biggest problem is soft wordwrap. I am
running jEdit 5.0 pre version on Win7 on a laptop 2.2 GHz AMD cpu with 4 GB
RAM, Sun java 1.6.0_29 and opening a 4 MB text file with soft wrap is a
chore. 

I tried how much difference the syntax highlighting mode makes, and it
seems not much.

Time for text to load:
Word wrap soft, full syntax highlight...1 min 55 secs
Word wrap soft, context insensitive syntax highlight...1 min 54 secs
Word wrap none, full syntax highlight...0 min 5 secs
Word wrap none, context insensitive syntax highlight...0 min 4 secs

Regards, tvojeho

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

Comment By: Alan Ezust (ezust)
Date: 2011-11-29 22:55

Message:
jEdit 4.5pre1 now has a large-file mode that kicks in and allows you to
pick a faster syntax highlighting mode.
This still doesn't prevent sidekick from doing its thing but that's another
issue people are looking at now.




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

Comment By: Matthieu Casanova (kpouer)
Date: 2009-11-02 05:26

Message:
moved to feature requests

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

Comment By: rletzler (rletzler)
Date: 2009-11-01 20:21

Message:
jEdit also gives no feedback about progress beyond telling us that 1 i/o
operation is in progress, so it is difficult to tell whether it is hard at
work opening a huge file or has frozen up.  Some kind of prominent percent
done text or thermometer display would be quite useful.

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

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

Feature Requests item #918301, was opened at 2004-03-17 13:03
Message generated for change (Comment added) made by tvojeho
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350588&aid=918301&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: Tyler Ward (vertigre)
Assigned to: Matthieu Casanova (kpouer)
Summary: poor performance with large text files and soft wrap

Initial Comment:

Jedit does a tolerable job of opening medium size text
files, but is no match for UltraEdit with large files.
if there was a way to easily open very large files,
that would be very nice. 

This is the algorithm I reccomend, though it's just a
though. 

1) If the file size is over a set limit, go into large
file mode. 

2) In large file mode, on opening a file, scan through
it for newlines and record the position of each newline.

3) Count the lines (number of newlines found) and load
up an area around the current text display window, this
can be done by seeking to the appropriate spot in the
file. For instance, if someone scrolls 2/3 of the way
down a million line file, then you need to load in
lines around line 670,000, and you conveniently know
the offset into the file of the line, because you made
a table of it. So you pick your spot, then load in a
few thousand lines above and below, using that as the
display. Whenever the user gets too close to the edge,
refresh it. 


This is a big task, but something that jedit should
consider if it is going to become the ultimate text
editor. 


-Tyler




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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 11:41

Message:
the edit mode was 'txt' - as I stated in catalog in mode folder for
handling *.txt files.

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

Comment By: Matthieu Casanova (kpouer)
Date: 2011-11-30 11:30

Message:
but what was the edit mode used by your file when you opened it ?

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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 11:24

Message:
Ah, it seems that this is my doing then; when I first started using jedit,
I made a copy of 'text' mode, customized the syntax highlighting and
renamed it as 'txt' mode which I use as default for text files. 

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

Comment By: Matthieu Casanova (kpouer)
Date: 2011-11-30 11:23

Message:
In fact you're right, there is a bug

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

Comment By: Matthieu Casanova (kpouer)
Date: 2011-11-30 11:06

Message:
I don't understand. If the edit mode is text, the dialog do not appear.

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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 09:39

Message:
Speaking of the large file mode, is there a way to switch off this feature?
Seeing that the simple text mode highlighting does not slow the file
loading, it is practically useless for text files to show this warning.

tvojeho

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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 09:34

Message:
Yes, that could help in some cases, unfortunately for me most of the time I
need to use the soft wrap. At least I have the time to make coffee while
opening the larger files ;)

tvojeho

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

Comment By: Alan Ezust (ezust)
Date: 2011-11-30 09:25

Message:
Perhaps the "large file mode" should also have an option to disable
soft-wrap and not just highlighting.


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

Comment By: Alan Ezust (ezust)
Date: 2011-11-30 09:18

Message:
Soft wrap is expensive, there is no doubt about it. 

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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 09:06

Message:
Hi, I am not sure how much delay the Sidekick is causing because I am not
using this plugin, but for me the biggest problem is soft wordwrap. I am
running jEdit 5.0 pre version on Win7 on a laptop 2.2 GHz AMD cpu with 4 GB
RAM, Sun java 1.6.0_29 and opening a 4 MB text file with soft wrap is a
chore. 

I tried how much difference the syntax highlighting mode makes, and it
seems not much.

Time for text to load:
Word wrap soft, full syntax highlight...1 min 55 secs
Word wrap soft, context insensitive syntax highlight...1 min 54 secs
Word wrap none, full syntax highlight...0 min 5 secs
Word wrap none, context insensitive syntax highlight...0 min 4 secs

Regards, tvojeho

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

Comment By: Alan Ezust (ezust)
Date: 2011-11-29 22:55

Message:
jEdit 4.5pre1 now has a large-file mode that kicks in and allows you to
pick a faster syntax highlighting mode.
This still doesn't prevent sidekick from doing its thing but that's another
issue people are looking at now.




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

Comment By: Matthieu Casanova (kpouer)
Date: 2009-11-02 05:26

Message:
moved to feature requests

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

Comment By: rletzler (rletzler)
Date: 2009-11-01 20:21

Message:
jEdit also gives no feedback about progress beyond telling us that 1 i/o
operation is in progress, so it is difficult to tell whether it is hard at
work opening a huge file or has frozen up.  Some kind of prominent percent
done text or thermometer display would be quite useful.

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

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

Feature Requests item #918301, was opened at 2004-03-17 13:03
Message generated for change (Comment added) made by kpouer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350588&aid=918301&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: Tyler Ward (vertigre)
Assigned to: Matthieu Casanova (kpouer)
Summary: poor performance with large text files and soft wrap

Initial Comment:

Jedit does a tolerable job of opening medium size text
files, but is no match for UltraEdit with large files.
if there was a way to easily open very large files,
that would be very nice. 

This is the algorithm I reccomend, though it's just a
though. 

1) If the file size is over a set limit, go into large
file mode. 

2) In large file mode, on opening a file, scan through
it for newlines and record the position of each newline.

3) Count the lines (number of newlines found) and load
up an area around the current text display window, this
can be done by seeking to the appropriate spot in the
file. For instance, if someone scrolls 2/3 of the way
down a million line file, then you need to load in
lines around line 670,000, and you conveniently know
the offset into the file of the line, because you made
a table of it. So you pick your spot, then load in a
few thousand lines above and below, using that as the
display. Whenever the user gets too close to the edge,
refresh it. 


This is a big task, but something that jedit should
consider if it is going to become the ultimate text
editor. 


-Tyler




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

>Comment By: Matthieu Casanova (kpouer)
Date: 2011-11-30 11:30

Message:
but what was the edit mode used by your file when you opened it ?

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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 11:24

Message:
Ah, it seems that this is my doing then; when I first started using jedit,
I made a copy of 'text' mode, customized the syntax highlighting and
renamed it as 'txt' mode which I use as default for text files. 

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

Comment By: Matthieu Casanova (kpouer)
Date: 2011-11-30 11:23

Message:
In fact you're right, there is a bug

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

Comment By: Matthieu Casanova (kpouer)
Date: 2011-11-30 11:06

Message:
I don't understand. If the edit mode is text, the dialog do not appear.

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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 09:39

Message:
Speaking of the large file mode, is there a way to switch off this feature?
Seeing that the simple text mode highlighting does not slow the file
loading, it is practically useless for text files to show this warning.

tvojeho

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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 09:34

Message:
Yes, that could help in some cases, unfortunately for me most of the time I
need to use the soft wrap. At least I have the time to make coffee while
opening the larger files ;)

tvojeho

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

Comment By: Alan Ezust (ezust)
Date: 2011-11-30 09:25

Message:
Perhaps the "large file mode" should also have an option to disable
soft-wrap and not just highlighting.


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

Comment By: Alan Ezust (ezust)
Date: 2011-11-30 09:18

Message:
Soft wrap is expensive, there is no doubt about it. 

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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 09:06

Message:
Hi, I am not sure how much delay the Sidekick is causing because I am not
using this plugin, but for me the biggest problem is soft wordwrap. I am
running jEdit 5.0 pre version on Win7 on a laptop 2.2 GHz AMD cpu with 4 GB
RAM, Sun java 1.6.0_29 and opening a 4 MB text file with soft wrap is a
chore. 

I tried how much difference the syntax highlighting mode makes, and it
seems not much.

Time for text to load:
Word wrap soft, full syntax highlight...1 min 55 secs
Word wrap soft, context insensitive syntax highlight...1 min 54 secs
Word wrap none, full syntax highlight...0 min 5 secs
Word wrap none, context insensitive syntax highlight...0 min 4 secs

Regards, tvojeho

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

Comment By: Alan Ezust (ezust)
Date: 2011-11-29 22:55

Message:
jEdit 4.5pre1 now has a large-file mode that kicks in and allows you to
pick a faster syntax highlighting mode.
This still doesn't prevent sidekick from doing its thing but that's another
issue people are looking at now.




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

Comment By: Matthieu Casanova (kpouer)
Date: 2009-11-02 05:26

Message:
moved to feature requests

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

Comment By: rletzler (rletzler)
Date: 2009-11-01 20:21

Message:
jEdit also gives no feedback about progress beyond telling us that 1 i/o
operation is in progress, so it is difficult to tell whether it is hard at
work opening a huge file or has frozen up.  Some kind of prominent percent
done text or thermometer display would be quite useful.

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

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

Feature Requests item #918301, was opened at 2004-03-17 13:03
Message generated for change (Comment added) made by tvojeho
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350588&aid=918301&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: Tyler Ward (vertigre)
Assigned to: Matthieu Casanova (kpouer)
Summary: poor performance with large text files and soft wrap

Initial Comment:

Jedit does a tolerable job of opening medium size text
files, but is no match for UltraEdit with large files.
if there was a way to easily open very large files,
that would be very nice. 

This is the algorithm I reccomend, though it's just a
though. 

1) If the file size is over a set limit, go into large
file mode. 

2) In large file mode, on opening a file, scan through
it for newlines and record the position of each newline.

3) Count the lines (number of newlines found) and load
up an area around the current text display window, this
can be done by seeking to the appropriate spot in the
file. For instance, if someone scrolls 2/3 of the way
down a million line file, then you need to load in
lines around line 670,000, and you conveniently know
the offset into the file of the line, because you made
a table of it. So you pick your spot, then load in a
few thousand lines above and below, using that as the
display. Whenever the user gets too close to the edge,
refresh it. 


This is a big task, but something that jedit should
consider if it is going to become the ultimate text
editor. 


-Tyler




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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 11:24

Message:
Ah, it seems that this is my doing then; when I first started using jedit,
I made a copy of 'text' mode, customized the syntax highlighting and
renamed it as 'txt' mode which I use as default for text files. 

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

Comment By: Matthieu Casanova (kpouer)
Date: 2011-11-30 11:23

Message:
In fact you're right, there is a bug

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

Comment By: Matthieu Casanova (kpouer)
Date: 2011-11-30 11:06

Message:
I don't understand. If the edit mode is text, the dialog do not appear.

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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 09:39

Message:
Speaking of the large file mode, is there a way to switch off this feature?
Seeing that the simple text mode highlighting does not slow the file
loading, it is practically useless for text files to show this warning.

tvojeho

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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 09:34

Message:
Yes, that could help in some cases, unfortunately for me most of the time I
need to use the soft wrap. At least I have the time to make coffee while
opening the larger files ;)

tvojeho

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

Comment By: Alan Ezust (ezust)
Date: 2011-11-30 09:25

Message:
Perhaps the "large file mode" should also have an option to disable
soft-wrap and not just highlighting.


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

Comment By: Alan Ezust (ezust)
Date: 2011-11-30 09:18

Message:
Soft wrap is expensive, there is no doubt about it. 

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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 09:06

Message:
Hi, I am not sure how much delay the Sidekick is causing because I am not
using this plugin, but for me the biggest problem is soft wordwrap. I am
running jEdit 5.0 pre version on Win7 on a laptop 2.2 GHz AMD cpu with 4 GB
RAM, Sun java 1.6.0_29 and opening a 4 MB text file with soft wrap is a
chore. 

I tried how much difference the syntax highlighting mode makes, and it
seems not much.

Time for text to load:
Word wrap soft, full syntax highlight...1 min 55 secs
Word wrap soft, context insensitive syntax highlight...1 min 54 secs
Word wrap none, full syntax highlight...0 min 5 secs
Word wrap none, context insensitive syntax highlight...0 min 4 secs

Regards, tvojeho

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

Comment By: Alan Ezust (ezust)
Date: 2011-11-29 22:55

Message:
jEdit 4.5pre1 now has a large-file mode that kicks in and allows you to
pick a faster syntax highlighting mode.
This still doesn't prevent sidekick from doing its thing but that's another
issue people are looking at now.




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

Comment By: Matthieu Casanova (kpouer)
Date: 2009-11-02 05:26

Message:
moved to feature requests

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

Comment By: rletzler (rletzler)
Date: 2009-11-01 20:21

Message:
jEdit also gives no feedback about progress beyond telling us that 1 i/o
operation is in progress, so it is difficult to tell whether it is hard at
work opening a huge file or has frozen up.  Some kind of prominent percent
done text or thermometer display would be quite useful.

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

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

Feature Requests item #918301, was opened at 2004-03-17 13:03
Message generated for change (Comment added) made by kpouer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350588&aid=918301&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: Tyler Ward (vertigre)
Assigned to: Matthieu Casanova (kpouer)
Summary: poor performance with large text files and soft wrap

Initial Comment:

Jedit does a tolerable job of opening medium size text
files, but is no match for UltraEdit with large files.
if there was a way to easily open very large files,
that would be very nice. 

This is the algorithm I reccomend, though it's just a
though. 

1) If the file size is over a set limit, go into large
file mode. 

2) In large file mode, on opening a file, scan through
it for newlines and record the position of each newline.

3) Count the lines (number of newlines found) and load
up an area around the current text display window, this
can be done by seeking to the appropriate spot in the
file. For instance, if someone scrolls 2/3 of the way
down a million line file, then you need to load in
lines around line 670,000, and you conveniently know
the offset into the file of the line, because you made
a table of it. So you pick your spot, then load in a
few thousand lines above and below, using that as the
display. Whenever the user gets too close to the edge,
refresh it. 


This is a big task, but something that jedit should
consider if it is going to become the ultimate text
editor. 


-Tyler




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

>Comment By: Matthieu Casanova (kpouer)
Date: 2011-11-30 11:23

Message:
In fact you're right, there is a bug

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

Comment By: Matthieu Casanova (kpouer)
Date: 2011-11-30 11:06

Message:
I don't understand. If the edit mode is text, the dialog do not appear.

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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 09:39

Message:
Speaking of the large file mode, is there a way to switch off this feature?
Seeing that the simple text mode highlighting does not slow the file
loading, it is practically useless for text files to show this warning.

tvojeho

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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 09:34

Message:
Yes, that could help in some cases, unfortunately for me most of the time I
need to use the soft wrap. At least I have the time to make coffee while
opening the larger files ;)

tvojeho

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

Comment By: Alan Ezust (ezust)
Date: 2011-11-30 09:25

Message:
Perhaps the "large file mode" should also have an option to disable
soft-wrap and not just highlighting.


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

Comment By: Alan Ezust (ezust)
Date: 2011-11-30 09:18

Message:
Soft wrap is expensive, there is no doubt about it. 

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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 09:06

Message:
Hi, I am not sure how much delay the Sidekick is causing because I am not
using this plugin, but for me the biggest problem is soft wordwrap. I am
running jEdit 5.0 pre version on Win7 on a laptop 2.2 GHz AMD cpu with 4 GB
RAM, Sun java 1.6.0_29 and opening a 4 MB text file with soft wrap is a
chore. 

I tried how much difference the syntax highlighting mode makes, and it
seems not much.

Time for text to load:
Word wrap soft, full syntax highlight...1 min 55 secs
Word wrap soft, context insensitive syntax highlight...1 min 54 secs
Word wrap none, full syntax highlight...0 min 5 secs
Word wrap none, context insensitive syntax highlight...0 min 4 secs

Regards, tvojeho

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

Comment By: Alan Ezust (ezust)
Date: 2011-11-29 22:55

Message:
jEdit 4.5pre1 now has a large-file mode that kicks in and allows you to
pick a faster syntax highlighting mode.
This still doesn't prevent sidekick from doing its thing but that's another
issue people are looking at now.




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

Comment By: Matthieu Casanova (kpouer)
Date: 2009-11-02 05:26

Message:
moved to feature requests

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

Comment By: rletzler (rletzler)
Date: 2009-11-01 20:21

Message:
jEdit also gives no feedback about progress beyond telling us that 1 i/o
operation is in progress, so it is difficult to tell whether it is hard at
work opening a huge file or has frozen up.  Some kind of prominent percent
done text or thermometer display would be quite useful.

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

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

Feature Requests item #918301, was opened at 2004-03-17 13:03
Message generated for change (Comment added) made by kpouer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350588&aid=918301&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: Tyler Ward (vertigre)
Assigned to: Matthieu Casanova (kpouer)
Summary: poor performance with large text files and soft wrap

Initial Comment:

Jedit does a tolerable job of opening medium size text
files, but is no match for UltraEdit with large files.
if there was a way to easily open very large files,
that would be very nice. 

This is the algorithm I reccomend, though it's just a
though. 

1) If the file size is over a set limit, go into large
file mode. 

2) In large file mode, on opening a file, scan through
it for newlines and record the position of each newline.

3) Count the lines (number of newlines found) and load
up an area around the current text display window, this
can be done by seeking to the appropriate spot in the
file. For instance, if someone scrolls 2/3 of the way
down a million line file, then you need to load in
lines around line 670,000, and you conveniently know
the offset into the file of the line, because you made
a table of it. So you pick your spot, then load in a
few thousand lines above and below, using that as the
display. Whenever the user gets too close to the edge,
refresh it. 


This is a big task, but something that jedit should
consider if it is going to become the ultimate text
editor. 


-Tyler




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

>Comment By: Matthieu Casanova (kpouer)
Date: 2011-11-30 11:06

Message:
I don't understand. If the edit mode is text, the dialog do not appear.

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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 09:39

Message:
Speaking of the large file mode, is there a way to switch off this feature?
Seeing that the simple text mode highlighting does not slow the file
loading, it is practically useless for text files to show this warning.

tvojeho

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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 09:34

Message:
Yes, that could help in some cases, unfortunately for me most of the time I
need to use the soft wrap. At least I have the time to make coffee while
opening the larger files ;)

tvojeho

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

Comment By: Alan Ezust (ezust)
Date: 2011-11-30 09:25

Message:
Perhaps the "large file mode" should also have an option to disable
soft-wrap and not just highlighting.


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

Comment By: Alan Ezust (ezust)
Date: 2011-11-30 09:18

Message:
Soft wrap is expensive, there is no doubt about it. 

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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 09:06

Message:
Hi, I am not sure how much delay the Sidekick is causing because I am not
using this plugin, but for me the biggest problem is soft wordwrap. I am
running jEdit 5.0 pre version on Win7 on a laptop 2.2 GHz AMD cpu with 4 GB
RAM, Sun java 1.6.0_29 and opening a 4 MB text file with soft wrap is a
chore. 

I tried how much difference the syntax highlighting mode makes, and it
seems not much.

Time for text to load:
Word wrap soft, full syntax highlight...1 min 55 secs
Word wrap soft, context insensitive syntax highlight...1 min 54 secs
Word wrap none, full syntax highlight...0 min 5 secs
Word wrap none, context insensitive syntax highlight...0 min 4 secs

Regards, tvojeho

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

Comment By: Alan Ezust (ezust)
Date: 2011-11-29 22:55

Message:
jEdit 4.5pre1 now has a large-file mode that kicks in and allows you to
pick a faster syntax highlighting mode.
This still doesn't prevent sidekick from doing its thing but that's another
issue people are looking at now.




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

Comment By: Matthieu Casanova (kpouer)
Date: 2009-11-02 05:26

Message:
moved to feature requests

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

Comment By: rletzler (rletzler)
Date: 2009-11-01 20:21

Message:
jEdit also gives no feedback about progress beyond telling us that 1 i/o
operation is in progress, so it is difficult to tell whether it is hard at
work opening a huge file or has frozen up.  Some kind of prominent percent
done text or thermometer display would be quite useful.

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

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

Plugin Bugs item #3446296, was opened at 2011-11-30 10:27
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3446296&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: Pending
>Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: don Rhummy (donrhummy)
Assigned to: Nobody/Anonymous (nobody)
Summary: No way to downgrade after update from updater

Initial Comment:
In previous version of updater, choosing to update to the latest release incorrectly updated me to 4.5pre1. Now there is no way to get back to 4.4.2. There should be a clean way to downgrade without losing your settings. (Within reason, obviously downgrading to 3.x version wouldn't be supported, but within the same major version, it should be)

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

>Comment By: Alan Ezust (ezust)
Date: 2011-11-30 10:57

Message:
downgrading is not a supported operation. you need to manually get the
older installer and install it yourself.


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

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

Plugin Bugs item #3446299, was opened at 2011-11-30 10:29
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3446299&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: don Rhummy (donrhummy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Updater incorrectly has 4.5pre1 as "Latest Official Release"

Initial Comment:
a "pre" release should NEVER be considered an official release. But the updater plugin updates to 4.5pre1 when you choose the source "Latest Official Release". This is incorrect.

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

>Comment By: Alan Ezust (ezust)
Date: 2011-11-30 10:56

Message:
4.5pre1 was released officially. You did not get a daily build. 

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

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

Plugin Bugs item #3446299, was opened at 2011-11-30 10:29
Message generated for change (Tracker Item Submitted) made by donrhummy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3446299&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: don Rhummy (donrhummy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Updater incorrectly has 4.5pre1 as "Latest Official Release"

Initial Comment:
a "pre" release should NEVER be considered an official release. But the updater plugin updates to 4.5pre1 when you choose the source "Latest Official Release". This is incorrect.

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

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

Plugin Bugs item #3446296, was opened at 2011-11-30 10:27
Message generated for change (Tracker Item Submitted) made by donrhummy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3446296&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: don Rhummy (donrhummy)
Assigned to: Nobody/Anonymous (nobody)
Summary: No way to downgrade after update from updater

Initial Comment:
In previous version of updater, choosing to update to the latest release incorrectly updated me to 4.5pre1. Now there is no way to get back to 4.4.2. There should be a clean way to downgrade without losing your settings. (Within reason, obviously downgrading to 3.x version wouldn't be supported, but within the same major version, it should be)

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

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

Feature Requests item #1540879, was opened at 2006-08-15 12:31
Message generated for change (Comment added) made by jarekczek
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350588&aid=1540879&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: v4.3
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Vadim Pesochinskiy (vpesochi)
Assigned to: Nobody/Anonymous (nobody)
Summary: filtered - selective Line Editing

Initial Comment:
Hi!

I wanted to submit this feature request earlier posted
by Pierre Métras at
http://marc.theaimsgroup.com/?l=jedit-users&m=98960814101033&w=2

I found this feature very useful in SlickEdit.
Interface can be just opening a "search" dialog box
with text feild to enter a regular expression filter.
In his example below you would just enter without
quotes "blue|product". 

I hope you will give it some consideration. Thanks.

"This is one of KEDIT's most popular features. The
selective editing facility lets you focus on a subset
of the lines in a file, such as all lines containing a
particular string. You can have KEDIT display only this
subset of your file, and you can perform editing
operations that affect only this subset. You can then
return to viewing and working with the entire file,
with the lines in the selected subset (as modified by
your editing) remaining in their original position in
the file. "

For instance, you have a file that contains a list of
products, with their manufacturer, color and material
(that's a flat database, to make the example easier,
but such cases happen in source code too). You want to
change the manufacturer's name of the blue products, if
they are not in plastic, and all products if they are
in leather..

With KEDIT, the operations are:
- "all /blue"        This displays only the blue
products and folds the other lines.
- "less/plastic"    Removes the plastic products from
the display - "more/leather" Add the leater products to
the display (unfold the "leather" lines that were
folded" Then you work in the resulting display and do a
serach/replace only on the visible lines. And "all" to
restore the full view.

No need for regular expressions here: what you see is
what you edit.

Imagine folding and bookmarks combined. You can place
(or remove) bookmarks on certain lines that match a
criteria you give. Then you are able to fold
the edit buffer on all the lines that don't have a
bookmark. And then, you can apply operations (search,
replace, Uppercase, macros...) only on the visible
lines (in other words, you apply an operation on lines
with a bookmark).
Please comment as I haven't the courage to try version
3.1 as my 3.0 final works well (now) with my usual
puggins..."

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

>Comment By: Jarek Czekalski (jarekczek)
Date: 2011-11-30 09:49

Message:
In editor I used before it was in search toolbar. There was an option "fold
lines". Yes, I was using it sometimes. Where to locate it in jedit, maybe
in hypersearch results pane.

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

Comment By: Vadim Pesochinskiy (vpesochi)
Date: 2006-08-15 12:35

Message:
Logged In: YES 
user_id=1576437

This feature is somewhat similar to the last request in
http://sourceforge.net/tracker/index.php?func=detail&aid=1535445&group_id=588&atid=350588

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

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

Searching mailing list without ability to search on title only is 
useless in many cases. That's why a third-party archivizer is required. 
I submitted a request for migration, but it lasts months sometimes. 
Fortunately they fixed an issue in old nabble and currently their 
archive is up-to-date and searchable.

Jarek

W dniu 11/30/2011 03:51 AM, Vampire pisze:
> I didn't even know it has to be started explicitly.
> Btw., do you know you can also search in the official List archives and
> Trackers via Advanced Search on SF?
> Have a look at
> http://sourceforge.net/search/?group_id=588&type_of_search=mlists
>
> Regards
> Vampire
>
> Jarek Czekalski schrieb:
>> Hi
>>
>> I began to like nabble's abilities to search our lists and trackers in
>> the same time. But recently they experience some problems and searching
>> is not possible:
>> http://nabble-support.1.n2.nabble.com/FYI-old-nabble-com-is-down-tp7006464p7006464.html
>>
>> There are also minor problems with topic threading, like these:
>> http://nabble-support.1.n2.nabble.com/Bug-Forum-topics-threading-incorrectly-tp7023500p7023500.html
>>
>> Peter from Nabble suggests in the last thread to migrate to new nabble,
>> nabble 2 or whatever its name is. If you don't oppose I'll try to
>> initiate the migration in a few days. Of course if a person emerges who
>> started the nabble archivizer I will bow back.
>>
>> Regards
>> Jarek
>>
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>>

Feature Requests item #918301, was opened at 2004-03-17 13:03
Message generated for change (Comment added) made by tvojeho
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350588&aid=918301&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: Tyler Ward (vertigre)
Assigned to: Matthieu Casanova (kpouer)
Summary: poor performance with large text files and soft wrap

Initial Comment:

Jedit does a tolerable job of opening medium size text
files, but is no match for UltraEdit with large files.
if there was a way to easily open very large files,
that would be very nice. 

This is the algorithm I reccomend, though it's just a
though. 

1) If the file size is over a set limit, go into large
file mode. 

2) In large file mode, on opening a file, scan through
it for newlines and record the position of each newline.

3) Count the lines (number of newlines found) and load
up an area around the current text display window, this
can be done by seeking to the appropriate spot in the
file. For instance, if someone scrolls 2/3 of the way
down a million line file, then you need to load in
lines around line 670,000, and you conveniently know
the offset into the file of the line, because you made
a table of it. So you pick your spot, then load in a
few thousand lines above and below, using that as the
display. Whenever the user gets too close to the edge,
refresh it. 


This is a big task, but something that jedit should
consider if it is going to become the ultimate text
editor. 


-Tyler




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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 09:39

Message:
Speaking of the large file mode, is there a way to switch off this feature?
Seeing that the simple text mode highlighting does not slow the file
loading, it is practically useless for text files to show this warning.

tvojeho

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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 09:34

Message:
Yes, that could help in some cases, unfortunately for me most of the time I
need to use the soft wrap. At least I have the time to make coffee while
opening the larger files ;)

tvojeho

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

Comment By: Alan Ezust (ezust)
Date: 2011-11-30 09:25

Message:
Perhaps the "large file mode" should also have an option to disable
soft-wrap and not just highlighting.


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

Comment By: Alan Ezust (ezust)
Date: 2011-11-30 09:18

Message:
Soft wrap is expensive, there is no doubt about it. 

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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 09:06

Message:
Hi, I am not sure how much delay the Sidekick is causing because I am not
using this plugin, but for me the biggest problem is soft wordwrap. I am
running jEdit 5.0 pre version on Win7 on a laptop 2.2 GHz AMD cpu with 4 GB
RAM, Sun java 1.6.0_29 and opening a 4 MB text file with soft wrap is a
chore. 

I tried how much difference the syntax highlighting mode makes, and it
seems not much.

Time for text to load:
Word wrap soft, full syntax highlight...1 min 55 secs
Word wrap soft, context insensitive syntax highlight...1 min 54 secs
Word wrap none, full syntax highlight...0 min 5 secs
Word wrap none, context insensitive syntax highlight...0 min 4 secs

Regards, tvojeho

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

Comment By: Alan Ezust (ezust)
Date: 2011-11-29 22:55

Message:
jEdit 4.5pre1 now has a large-file mode that kicks in and allows you to
pick a faster syntax highlighting mode.
This still doesn't prevent sidekick from doing its thing but that's another
issue people are looking at now.




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

Comment By: Matthieu Casanova (kpouer)
Date: 2009-11-02 05:26

Message:
moved to feature requests

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

Comment By: rletzler (rletzler)
Date: 2009-11-01 20:21

Message:
jEdit also gives no feedback about progress beyond telling us that 1 i/o
operation is in progress, so it is difficult to tell whether it is hard at
work opening a huge file or has frozen up.  Some kind of prominent percent
done text or thermometer display would be quite useful.

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

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

Feature Requests item #918301, was opened at 2004-03-17 13:03
Message generated for change (Comment added) made by tvojeho
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350588&aid=918301&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: Tyler Ward (vertigre)
Assigned to: Matthieu Casanova (kpouer)
Summary: poor performance with large text files and soft wrap

Initial Comment:

Jedit does a tolerable job of opening medium size text
files, but is no match for UltraEdit with large files.
if there was a way to easily open very large files,
that would be very nice. 

This is the algorithm I reccomend, though it's just a
though. 

1) If the file size is over a set limit, go into large
file mode. 

2) In large file mode, on opening a file, scan through
it for newlines and record the position of each newline.

3) Count the lines (number of newlines found) and load
up an area around the current text display window, this
can be done by seeking to the appropriate spot in the
file. For instance, if someone scrolls 2/3 of the way
down a million line file, then you need to load in
lines around line 670,000, and you conveniently know
the offset into the file of the line, because you made
a table of it. So you pick your spot, then load in a
few thousand lines above and below, using that as the
display. Whenever the user gets too close to the edge,
refresh it. 


This is a big task, but something that jedit should
consider if it is going to become the ultimate text
editor. 


-Tyler




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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 09:34

Message:
Yes, that could help in some cases, unfortunately for me most of the time I
need to use the soft wrap. At least I have the time to make coffee while
opening the larger files ;)

tvojeho

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

Comment By: Alan Ezust (ezust)
Date: 2011-11-30 09:25

Message:
Perhaps the "large file mode" should also have an option to disable
soft-wrap and not just highlighting.


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

Comment By: Alan Ezust (ezust)
Date: 2011-11-30 09:18

Message:
Soft wrap is expensive, there is no doubt about it. 

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

Comment By: tvojeho (tvojeho)
Date: 2011-11-30 09:06

Message:
Hi, I am not sure how much delay the Sidekick is causing because I am not
using this plugin, but for me the biggest problem is soft wordwrap. I am
running jEdit 5.0 pre version on Win7 on a laptop 2.2 GHz AMD cpu with 4 GB
RAM, Sun java 1.6.0_29 and opening a 4 MB text file with soft wrap is a
chore. 

I tried how much difference the syntax highlighting mode makes, and it
seems not much.

Time for text to load:
Word wrap soft, full syntax highlight...1 min 55 secs
Word wrap soft, context insensitive syntax highlight...1 min 54 secs
Word wrap none, full syntax highlight...0 min 5 secs
Word wrap none, context insensitive syntax highlight...0 min 4 secs

Regards, tvojeho

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

Comment By: Alan Ezust (ezust)
Date: 2011-11-29 22:55

Message:
jEdit 4.5pre1 now has a large-file mode that kicks in and allows you to
pick a faster syntax highlighting mode.
This still doesn't prevent sidekick from doing its thing but that's another
issue people are looking at now.




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

Comment By: Matthieu Casanova (kpouer)
Date: 2009-11-02 05:26

Message:
moved to feature requests

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

Comment By: rletzler (rletzler)
Date: 2009-11-01 20:21

Message:
jEdit also gives no feedback about progress beyond telling us that 1 i/o
operation is in progress, so it is difficult to tell whether it is hard at
work opening a huge file or has frozen up.  Some kind of prominent percent
done text or thermometer display would be quite useful.

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

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

Bugs item #3172647, was opened at 2011-02-04 04:14
Message generated for change (Comment added) made by vampire0
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100588&aid=3172647&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: None
Status: Open
Resolution: Remind
Priority: 5
Private: No
Submitted By: Marco Bright Caminati (marco-caminati)
Assigned to: Matthieu Casanova (kpouer)
Summary: Long menus hidden off screen

Initial Comment:
I have a wealth of macros in HOME/macros/foo/
When I try to choose a macro from jedit menu (F10) under Macros/foo/, the submenus extremely long and tops off the screen, making first macro entries not visible. I can circumvent the problem by resizing or moving down jedit window before opening that menu, so that it tops off jedit window but not screen estate, but this is awkward.
This could be regarded as phenomenologically similar to 590430 and 569803.
Probably one would expect such long menus to auto-wrap or auto-split as seen with "File/Reload with Encoding".
It's strange how in the latter case menu extends downward with respect to upper root menu, while in this buggy case it extends upwards. Maybe this is related to the bug?

Environment specs/details:
Jedit 4.3.2 on Java 1.7.0-internal. OS:
Linux box 2.6.33.3-tinycore #2012 SMP Wed May 12 17:05:42 EEST 2010 i686 GNU/Linux




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

Comment By: Björn Kautler (vampire0)
Date: 2011-11-30 09:30

Message:
We always have the more menu at the bottom if we spill over after the
user-specified spill-over amount. Also I wouldn't say don't put folders to
more menu, but just do the menu split according to the spill-over amount
like is done for any other menu. If you want to see more entries per level,
then you can just increase the spill-over amount. :-)

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

Comment By: Alan Ezust (ezust)
Date: 2011-06-15 10:41

Message:
Please roll back rev# 19380 or fix it.
Long menus look worse now than they did before due to placement of macro
folders in the "more" menu, as well as the placement of the "more" menu
(why not put it on top instead of on the bottom of the menu?)



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

Comment By: Robert Schwenn (rschwenn)
Date: 2011-06-09 11:12

Message:
@Marco Bright Caminati:
Maybe there should be some kind of auto-splitting the menu, but the macros
folder (and thereby the menu) is under Your control. Are You aware of the
possibility to cascade Your menu via further levels of subfolders?

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

Comment By: Alan Ezust (ezust)
Date: 2011-06-09 08:06

Message:
Please leave the folders at the top of the menu, putting only individual
macros in the "more" menu.


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

Comment By: Matthieu Casanova (kpouer)
Date: 2011-02-21 06:05

Message:
fixed in rev 19380

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

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