You can subscribe to this list here.
1999 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(32) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2000 |
Jan
(452) |
Feb
(435) |
Mar
(117) |
Apr
(265) |
May
(161) |
Jun
(276) |
Jul
(409) |
Aug
(522) |
Sep
(139) |
Oct
(306) |
Nov
(406) |
Dec
(217) |
2001 |
Jan
(237) |
Feb
(194) |
Mar
(266) |
Apr
(298) |
May
(266) |
Jun
(195) |
Jul
(427) |
Aug
(660) |
Sep
(808) |
Oct
(465) |
Nov
(260) |
Dec
(226) |
2002 |
Jan
(255) |
Feb
(322) |
Mar
(440) |
Apr
(327) |
May
(271) |
Jun
(263) |
Jul
(122) |
Aug
(346) |
Sep
(172) |
Oct
(282) |
Nov
(184) |
Dec
(166) |
2003 |
Jan
(325) |
Feb
(431) |
Mar
(431) |
Apr
(238) |
May
(320) |
Jun
(331) |
Jul
(289) |
Aug
(277) |
Sep
(223) |
Oct
(273) |
Nov
(218) |
Dec
(223) |
2004 |
Jan
(203) |
Feb
(321) |
Mar
(316) |
Apr
(18) |
May
(44) |
Jun
(149) |
Jul
(83) |
Aug
(216) |
Sep
(188) |
Oct
(136) |
Nov
(73) |
Dec
(117) |
2005 |
Jan
(101) |
Feb
(208) |
Mar
(153) |
Apr
(81) |
May
(85) |
Jun
(87) |
Jul
(100) |
Aug
(145) |
Sep
(57) |
Oct
(123) |
Nov
(73) |
Dec
(105) |
2006 |
Jan
(211) |
Feb
(134) |
Mar
(299) |
Apr
(223) |
May
(292) |
Jun
(426) |
Jul
(477) |
Aug
(415) |
Sep
(501) |
Oct
(460) |
Nov
(427) |
Dec
(302) |
2007 |
Jan
(467) |
Feb
(423) |
Mar
(356) |
Apr
(241) |
May
(357) |
Jun
(342) |
Jul
(373) |
Aug
(421) |
Sep
(491) |
Oct
(266) |
Nov
(236) |
Dec
(310) |
2008 |
Jan
(228) |
Feb
(344) |
Mar
(466) |
Apr
(410) |
May
(437) |
Jun
(303) |
Jul
(255) |
Aug
(451) |
Sep
(520) |
Oct
(379) |
Nov
(430) |
Dec
(261) |
2009 |
Jan
(352) |
Feb
(394) |
Mar
(279) |
Apr
(534) |
May
(245) |
Jun
(392) |
Jul
(510) |
Aug
(392) |
Sep
(237) |
Oct
(332) |
Nov
(302) |
Dec
(590) |
2010 |
Jan
(723) |
Feb
(650) |
Mar
(530) |
Apr
(307) |
May
(300) |
Jun
(450) |
Jul
(196) |
Aug
(233) |
Sep
(270) |
Oct
(288) |
Nov
(284) |
Dec
(331) |
2011 |
Jan
(336) |
Feb
(277) |
Mar
(133) |
Apr
(102) |
May
(50) |
Jun
(234) |
Jul
(174) |
Aug
(274) |
Sep
(355) |
Oct
(273) |
Nov
(895) |
Dec
(749) |
2012 |
Jan
(744) |
Feb
(498) |
Mar
(767) |
Apr
(412) |
May
(513) |
Jun
(596) |
Jul
(372) |
Aug
(515) |
Sep
(373) |
Oct
(246) |
Nov
(210) |
Dec
(232) |
2013 |
Jan
(162) |
Feb
(226) |
Mar
(209) |
Apr
(162) |
May
(84) |
Jun
(153) |
Jul
(91) |
Aug
(142) |
Sep
(151) |
Oct
(220) |
Nov
(176) |
Dec
(131) |
2014 |
Jan
(61) |
Feb
(83) |
Mar
(93) |
Apr
(274) |
May
(83) |
Jun
(46) |
Jul
(149) |
Aug
(61) |
Sep
(49) |
Oct
(93) |
Nov
(100) |
Dec
(164) |
2015 |
Jan
(93) |
Feb
(130) |
Mar
(44) |
Apr
(31) |
May
(85) |
Jun
(11) |
Jul
(47) |
Aug
(131) |
Sep
(117) |
Oct
(115) |
Nov
(73) |
Dec
(84) |
2016 |
Jan
(106) |
Feb
(88) |
Mar
(116) |
Apr
(160) |
May
(121) |
Jun
(74) |
Jul
(126) |
Aug
(141) |
Sep
(101) |
Oct
(38) |
Nov
(32) |
Dec
(6) |
2017 |
Jan
(33) |
Feb
(60) |
Mar
(112) |
Apr
(33) |
May
(24) |
Jun
(115) |
Jul
(24) |
Aug
|
Sep
(6) |
Oct
(147) |
Nov
(166) |
Dec
(118) |
2018 |
Jan
(53) |
Feb
(51) |
Mar
(4) |
Apr
(14) |
May
(28) |
Jun
(14) |
Jul
(18) |
Aug
(53) |
Sep
(27) |
Oct
(9) |
Nov
(2) |
Dec
(2) |
2019 |
Jan
(8) |
Feb
(7) |
Mar
(21) |
Apr
(17) |
May
(43) |
Jun
(45) |
Jul
(13) |
Aug
(32) |
Sep
(18) |
Oct
(41) |
Nov
(19) |
Dec
(60) |
2020 |
Jan
(9) |
Feb
(12) |
Mar
(26) |
Apr
(43) |
May
(67) |
Jun
(42) |
Jul
(4) |
Aug
(3) |
Sep
(73) |
Oct
(8) |
Nov
(19) |
Dec
(14) |
2021 |
Jan
(19) |
Feb
(9) |
Mar
(20) |
Apr
(25) |
May
(17) |
Jun
(9) |
Jul
(1) |
Aug
(21) |
Sep
(17) |
Oct
(12) |
Nov
(4) |
Dec
|
2022 |
Jan
(2) |
Feb
(1) |
Mar
(9) |
Apr
(5) |
May
(25) |
Jun
(9) |
Jul
(10) |
Aug
(3) |
Sep
(27) |
Oct
(6) |
Nov
(9) |
Dec
|
2023 |
Jan
|
Feb
|
Mar
(11) |
Apr
|
May
(13) |
Jun
(11) |
Jul
(11) |
Aug
(14) |
Sep
(17) |
Oct
(50) |
Nov
(5) |
Dec
(2) |
2024 |
Jan
(6) |
Feb
(20) |
Mar
(8) |
Apr
(15) |
May
(35) |
Jun
|
Jul
(7) |
Aug
(21) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
From: Alan E. <ez...@us...> - 2024-09-17 01:25:59
|
- **status**: open --> closed-fixed - **Comment**: Fixed in jEdit 5.7 --- **[bugs:#4125] Delete at the end of the line does not delete newline (java20, java21)** **Status:** closed-fixed **Group:** normal bug **Created:** Sun Jun 04, 2023 12:51 PM UTC by Alan Ezust **Last Updated:** Mon Sep 16, 2024 10:59 PM UTC **Owner:** Matthieu Casanova If I am at the end of a line and I hit delete, the newline char is not deleted anymore. Using jedit 5.6.0, openjdk 20 or 21 on kubuntu linux 22.04. Switching to openjdk 19 makes the problem go away. --- Sent from sourceforge.net because jed...@li... is subscribed to https://sourceforge.net/p/jedit/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jedit/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: dbareis <db...@us...> - 2024-09-16 22:56:20
|
I am having this issue on the stable 5.6.0 + Eclipse Adoptium Java 21.0.4 --- **[bugs:#4125] Delete at the end of the line does not delete newline (java20, java21)** **Status:** open **Group:** normal bug **Created:** Sun Jun 04, 2023 12:51 PM UTC by Alan Ezust **Last Updated:** Wed Feb 28, 2024 01:45 AM UTC **Owner:** Matthieu Casanova If I am at the end of a line and I hit delete, the newline char is not deleted anymore. Using jedit 5.6.0, openjdk 20 or 21 on kubuntu linux 22.04. Switching to openjdk 19 makes the problem go away. --- Sent from sourceforge.net because jed...@li... is subscribed to https://sourceforge.net/p/jedit/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jedit/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: Eric Le L. <ker...@us...> - 2024-08-24 13:02:20
|
Hi Marco, I don't know of any other implementation in progress. If you are willing to contribute to enhance it, you're welcome to join Damien's effort. See https://sourceforge.net/p/jedit/plugin-central-submission/1076/ for discussion. I'd say the multithreading/async handling is not as robust as it could be, as well as underspecified or not well understood LSP server behaviour (esp. python). Damien has used the java and go servers with better results. Cheers, --- **[plugin-feature-requests:#401] Language Server Protocol implementation for JEdit** **Status:** open **Group:** **Labels:** LSP implementation Language Server Protocol implementation **Created:** Thu Aug 08, 2024 12:57 PM UTC by marco milanesi **Last Updated:** Thu Aug 08, 2024 12:57 PM UTC **Owner:** nobody Hi! short question: do you know if someone is trying to implement at least Java "**Language Server Protocol**" (LSP) as JEdit Plugin ? instead using old JavaCC (or Antlr) that works bad with JDK-11... i've found this, but doesn't work properly : https://git.sr.ht/~damien/jedit-lsp thanks for any info greets --- Sent from sourceforge.net because jed...@li... is subscribed to https://sourceforge.net/p/jedit/plugin-feature-requests/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jedit/admin/plugin-feature-requests/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: tvojeho <tv...@us...> - 2024-08-17 03:35:31
|
--- **[plugin-bugs:#1927] SuperAbbrevs 2.0-pre8: fails in 5.7.0** **Status:** open **Group:** **Created:** Sat Aug 17, 2024 03:35 AM UTC by tvojeho **Last Updated:** Sat Aug 17, 2024 03:35 AM UTC **Owner:** nobody **Attachments:** - [activity_5.6.0.log](https://sourceforge.net/p/jedit/plugin-bugs/1927/attachment/activity_5.6.0.log) (55.9 kB; text/x-log) - [activity_5.7.0.log](https://sourceforge.net/p/jedit/plugin-bugs/1927/attachment/activity_5.7.0.log) (115.7 kB; text/x-log) Hi everyone, Since upgrading to jEdit version 5.6.0 and continuing into version 5.7.0, the SuperAbbrevs plugin (version 2.0-pre8) has encountered issues with template variables and later abbreviation management. Template Variable Replacement Failure (jEdit 5.6.0 and above): When using SuperAbbrevs in jEdit 5.6.0 or later, the plugin fails to replace the variables in the templates as expected. For example, the template private ${2:Type} ${1:field}; is supposed to dynamically replace ${2:Type} with "Type" and ${1:field} with "field", and toggle between these fields using the TAB key. Instead, the plugin inserts the template text directly without replacing the variables, i.e., private ${2:Type} ${1:field}; is typed as-is, without the variable selection functionality. Abbreviation Management (jEdit 5.7.0): Starting from jEdit 5.7.0, in addition to the issue with variable replacement, the plugin also exhibits a problem within the Plugin Options menu under Plugin Options > SuperAbbrevs > Abbreviations, it is no longer possible to add new abbreviations or modify existing ones. The interface is non-responsive for these action. Attachments I am attaching the log files from both jEdit versions 5.6.0 and 5.7.0 to assist in diagnosing the issues. Environment jEdit version: 5.6.0 Build: 2020-09-03 jEdit server: Master (17.8.2024 5:06:43) Java runtime version: 17.0.12+7-Ubuntu-1ubuntu222.04 OS name: Linux OS version: 6.5.0-45-generic OS arch: amd64 Active plugins: ActionHooks (0.6), BufferTabs (1.2.5), CandyFolds (1.2.3) Character Map (1.3.3), Color Chooser (0.1), Common Controls (1.7.4) Console (5.1.4), Context Menu (0.4), DirtyGutter (0.3b) Editor Scheme (1.8), ErrorList (2.4.0), Finish Him! (0.9) FlatLaf (0.46), FoldViewer (1.1), GnuRegexp (1.0.1) Info Viewer (1.6.3), JDiff Plugin (3.4.0), Jakarta Commons (0.9) LookAndFeel (2.4), MarkerSets (0.9), Menu Editor (0.5) MetalColor (1.1.0), Mouse Snap (0.1), OpenIt (1.6.0) Project Viewer (3.6), QuickNotepad (5.0), RecentBufferSwitcher (0.2) Scala Plugin (1.1.0), SuperAbbrevs (2.0-pre8), TaskList (2.6) Templates (5.0.3), TextTools (1.16), WhiteSpace (1.0.2) XSearch (1.9) jEdit version: 5.7.0 Build: 2024-08-03 jEdit server: Master (17.8.2024 5:01:55) Java runtime version: 17.0.12+7-Ubuntu-1ubuntu222.04 OS name: Linux OS version: 6.5.0-45-generic OS arch: amd64 Active plugins: ActionHooks (0.6), Antlr (4.10), BufferTabs (1.2.5) Character Map (1.3.3), Color Chooser (0.1), Common Controls (1.7.4) Console (5.1.4), Context Menu (0.4), DirtyGutter (0.3b) EclipseIcons (1.0), Editor Scheme (1.8), ErrorList (2.4.0) Finish Him! (0.9), FlatLaf (0.46), GnuRegexp (1.0.1) Info Viewer (1.6.3), JDiff Plugin (3.4.0), Jakarta Commons (0.9) Latest Version Check (1.5), LookAndFeel (2.4), MarkerSets (0.9) Menu Editor (0.5), MetalColor (1.1.0), Mouse Snap (0.1) OpenIt (1.6.0), Project Viewer (3.6), QuickNotepad (5.0) RecentBufferSwitcher (0.2), SQL (1.2), Scala Plugin (1.1.0) SideKick (1.8), SuperAbbrevs (2.0-pre8), TaskList (2.6) Templates (5.1.0), TextTools (1.16), WhiteSpace (1.0.3) XML (3.0.8), XSearch (1.9), XercesPlugin (2.11.0_1) --- Sent from sourceforge.net because jed...@li... is subscribed to https://sourceforge.net/p/jedit/plugin-bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jedit/admin/plugin-bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: Alan E. <ez...@us...> - 2024-08-16 17:08:54
|
- **status**: open --> closed-invalid - **Group**: Regressive (new to devel) --> minor bug - **Comment**: Closing as "invalid". This seems to be related to Java VM Configuration on MacOS and is not directly related to jEdit. --- **[bugs:#4135] Slow HyperSearch Performance on macOS with Large Files and Queries** **Status:** closed-invalid **Group:** minor bug **Created:** Sat May 25, 2024 12:31 AM UTC by Matthew Orzewalla **Last Updated:** Wed Aug 14, 2024 10:07 PM UTC **Owner:** nobody **Attachments:** - [activity.log](https://sourceforge.net/p/jedit/bugs/4135/attachment/activity.log) (17.4 kB; application/octet-stream) I have been observing slow hypersearch performanc on macOS for a while now, but wanted to wait for a preview of 5.7 to see if performance improved. >From what I can tell, it began with the switch to Java 11, but I'm not positive that is the root cause. The bug has been observed on both Intel Macs and ARM Macs Steps I use to reproduce: 1. Download the plain text copy of Death Valley in '49 from Project Gutenberg here: https://www.gutenberg.org/ebooks/12236.txt.utf-8 2. Install and start up a fresh version jEdit 5.7pre (no prexisting jEdit user directory) from the version posted in this thread: https://sourceforge.net/p/jedit/bugs/4123/. On my system java-version lists: openjdk version "21.0.2" 2024-01-16 LTS OpenJDK Runtime Environment Temurin-21.0.2+13 (build 21.0.2+13-LTS) OpenJDK 64-Bit Server VM Temurin-21.0.2+13 (build 21.0.2+13-LTS, mixed mode) 3. Open the text file (pg12236.txt from the download on my system) in jEdit 4. Perform a search with Ignore Case and HyperSearch selected of the word "death". The 106 results should be returned fairly quickly 5. Perform a search for the word "from". The 625 results will eventually be returned, but it beachballs my system for about 50 seconds. Performing a search for the word "the" beachballs my system for longer than I am willing to wait. I can perform a search of the same file for the word "the" on a Windows install of jEdit and return the 15,733 results in less than 3 seconds (the Windows About jEdit screen lists, "jEdit 5.5.0 server mode, using Oracle Corporation Java 1.8.0_391). I am uploading the activity.log file., but I didn't see anything indicating the slow performance within the file. Let me know if there is any other information I can provide that can help diagnose the root cause. At first I had thought that it had something to do with docking or undocking the HyperSearch window (with docked causing slow performance), but then I went back and did some dedicated testing and found that it is slow undocked as well. It also seems that if I do more searches and work my way up to larger returns that the slowness subsides, as if it is slow allocating memory to the process, but once that memory gets allocated it is no longer slow. Thank you for your help in this matter. --- Sent from sourceforge.net because jed...@li... is subscribed to https://sourceforge.net/p/jedit/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jedit/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: Alan E. <ez...@us...> - 2024-08-16 14:09:13
|
Thanks, Eric and Dale! > Thanks, Eric, I'd kind of forgotten about this one also. I'll look into it. This was sort of a one-off plugin for Alan, I'm guessing he's the only one actually using it. Actually, I have some coworkers who might use it too. --- **[plugin-central-submission:#1082] QDocSidekick** **Status:** closed-accepted **Group:** None **Created:** Wed May 22, 2024 03:17 AM UTC by Dale Anson **Last Updated:** Wed Jul 31, 2024 04:55 PM UTC **Owner:** Eric Le Lay {{{ QDocSideKick 1.0 Source: Source code is in SVN with the tag 1.0 Announcement: Initial release. Brand new plugin for working with QDoc files https://doc.qt.io/qt-6/01-qdoc-manual.html.. While the manual says "QDoc finds QDoc comments in .cpp files and in .qdoc files", this QDocSideKick plugin only works with .qdoc files. Requires Java 11 Requires jEdit 05.04.00.00 Short Description: QDocSideKick Long Description: <html> <p>SideKick for QDoc files</p> </html> }}} --- Sent from sourceforge.net because jed...@li... is subscribed to https://sourceforge.net/p/jedit/plugin-central-submission/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jedit/admin/plugin-central-submission/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: Matthew O. <le...@us...> - 2024-08-14 22:07:34
|
So the issue resides with the macOS java virtual machines. I had two JDK directories within /Library/Java/JavaVirtualMachines, one I installed to run jEdit, zulu-22.jdk (or temurin-22.jre, I tried them both), and one that was recommended by the Mathworks folks for running Matlab, amazon-corretto-11.jdk. If I remove the zulu/temurin directory such that only the amazon-corretto directory resides in the /Library/Java/JavaVirtualMachines, then jEdit hypersearch works as expected. I am not sure what is ultimately going on here. On other platforms, jEdit is fine with alternate vendors/newer versions of the JDK/JRE. But on macOS, those alternate vendors/newer versions are problematic. I don't think my Matlab installation altered any system settings, as I have tried jEdit 5.7 on a few different systems and only one has Matlab installed (this is also the only one with Java 11 installed). i alternately removed the amazon-corretto-11.jdk directory from /Library/Java/JavaVirtualMachines, leaving only zulu-22.jdk, but that configuration again produced the anomolous hypersearch behavior. --- **[bugs:#4135] Slow HyperSearch Performance on macOS with Large Files and Queries** **Status:** open **Group:** Regressive (new to devel) **Created:** Sat May 25, 2024 12:31 AM UTC by Matthew Orzewalla **Last Updated:** Wed Aug 14, 2024 09:25 PM UTC **Owner:** nobody **Attachments:** - [activity.log](https://sourceforge.net/p/jedit/bugs/4135/attachment/activity.log) (17.4 kB; application/octet-stream) I have been observing slow hypersearch performanc on macOS for a while now, but wanted to wait for a preview of 5.7 to see if performance improved. >From what I can tell, it began with the switch to Java 11, but I'm not positive that is the root cause. The bug has been observed on both Intel Macs and ARM Macs Steps I use to reproduce: 1. Download the plain text copy of Death Valley in '49 from Project Gutenberg here: https://www.gutenberg.org/ebooks/12236.txt.utf-8 2. Install and start up a fresh version jEdit 5.7pre (no prexisting jEdit user directory) from the version posted in this thread: https://sourceforge.net/p/jedit/bugs/4123/. On my system java-version lists: openjdk version "21.0.2" 2024-01-16 LTS OpenJDK Runtime Environment Temurin-21.0.2+13 (build 21.0.2+13-LTS) OpenJDK 64-Bit Server VM Temurin-21.0.2+13 (build 21.0.2+13-LTS, mixed mode) 3. Open the text file (pg12236.txt from the download on my system) in jEdit 4. Perform a search with Ignore Case and HyperSearch selected of the word "death". The 106 results should be returned fairly quickly 5. Perform a search for the word "from". The 625 results will eventually be returned, but it beachballs my system for about 50 seconds. Performing a search for the word "the" beachballs my system for longer than I am willing to wait. I can perform a search of the same file for the word "the" on a Windows install of jEdit and return the 15,733 results in less than 3 seconds (the Windows About jEdit screen lists, "jEdit 5.5.0 server mode, using Oracle Corporation Java 1.8.0_391). I am uploading the activity.log file., but I didn't see anything indicating the slow performance within the file. Let me know if there is any other information I can provide that can help diagnose the root cause. At first I had thought that it had something to do with docking or undocking the HyperSearch window (with docked causing slow performance), but then I went back and did some dedicated testing and found that it is slow undocked as well. It also seems that if I do more searches and work my way up to larger returns that the slowness subsides, as if it is slow allocating memory to the process, but once that memory gets allocated it is no longer slow. Thank you for your help in this matter. --- Sent from sourceforge.net because jed...@li... is subscribed to https://sourceforge.net/p/jedit/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jedit/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: Matthew O. <le...@us...> - 2024-08-14 21:25:56
|
The plot thickens... I open jEdit 5.7 from Terminal using the following command: /usr/bin/java -verbose -jar /Applications/Isabelle2024.app/contrib/jedit-20240425/jedit5.6.0-patched/jedit.jar and observe the anomolous hypersearch behavior. I open Isabelle2024 from Terminal using the following command: /Applications/Isabelle2024.app/contrib/jdk-21.0.3/arm64-darwin/zulu-21.jdk/Contents/Home/bin/java -verbose -jar /Applications/Isabelle2024.app/contrib/jedit-20240425/jedit5.6.0-patched/jedit.jar and do not observe the anomolous hypersearch behavior (as expected). I open jEdit 5.7 from Terminal pointing to the Isabelle2024 Java using the following command: /Applications/Isabelle2024.app/contrib/jdk-21.0.3/arm64-darwin/zulu-21.jdk/Contents/Home/bin/java -verbose -jar /Applications/jEdit.app/Contents/Java/jedit.jar and *also* do not observe the anomolous hypersearch behavior. So the issue seems to be how my system is handling the Java installation. Not sure what steps to try next. It would also be reassuring if someone were able to reproduce the behavior on their system. I am trying to be as vanilla as possible with the system configuration. --- **[bugs:#4135] Slow HyperSearch Performance on macOS with Large Files and Queries** **Status:** open **Group:** Regressive (new to devel) **Created:** Sat May 25, 2024 12:31 AM UTC by Matthew Orzewalla **Last Updated:** Wed Aug 14, 2024 08:18 PM UTC **Owner:** nobody **Attachments:** - [activity.log](https://sourceforge.net/p/jedit/bugs/4135/attachment/activity.log) (17.4 kB; application/octet-stream) I have been observing slow hypersearch performanc on macOS for a while now, but wanted to wait for a preview of 5.7 to see if performance improved. >From what I can tell, it began with the switch to Java 11, but I'm not positive that is the root cause. The bug has been observed on both Intel Macs and ARM Macs Steps I use to reproduce: 1. Download the plain text copy of Death Valley in '49 from Project Gutenberg here: https://www.gutenberg.org/ebooks/12236.txt.utf-8 2. Install and start up a fresh version jEdit 5.7pre (no prexisting jEdit user directory) from the version posted in this thread: https://sourceforge.net/p/jedit/bugs/4123/. On my system java-version lists: openjdk version "21.0.2" 2024-01-16 LTS OpenJDK Runtime Environment Temurin-21.0.2+13 (build 21.0.2+13-LTS) OpenJDK 64-Bit Server VM Temurin-21.0.2+13 (build 21.0.2+13-LTS, mixed mode) 3. Open the text file (pg12236.txt from the download on my system) in jEdit 4. Perform a search with Ignore Case and HyperSearch selected of the word "death". The 106 results should be returned fairly quickly 5. Perform a search for the word "from". The 625 results will eventually be returned, but it beachballs my system for about 50 seconds. Performing a search for the word "the" beachballs my system for longer than I am willing to wait. I can perform a search of the same file for the word "the" on a Windows install of jEdit and return the 15,733 results in less than 3 seconds (the Windows About jEdit screen lists, "jEdit 5.5.0 server mode, using Oracle Corporation Java 1.8.0_391). I am uploading the activity.log file., but I didn't see anything indicating the slow performance within the file. Let me know if there is any other information I can provide that can help diagnose the root cause. At first I had thought that it had something to do with docking or undocking the HyperSearch window (with docked causing slow performance), but then I went back and did some dedicated testing and found that it is slow undocked as well. It also seems that if I do more searches and work my way up to larger returns that the slowness subsides, as if it is slow allocating memory to the process, but once that memory gets allocated it is no longer slow. Thank you for your help in this matter. --- Sent from sourceforge.net because jed...@li... is subscribed to https://sourceforge.net/p/jedit/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jedit/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: Matthew O. <le...@us...> - 2024-08-14 20:18:15
|
Thanks Makarius. Given Björn's suggestion for replacing the jedit.jar file within the jEdit 5.7 app directory, I tried copying the Isabelle2024 jedit.jar from /Applications/Isabelle2024.app/contrib/jedit-20240425/jedit5.6.0-patched to /Applications/jEdit.app/Contents/Java, and next tried copying the entire jedit5.6.0-patched directory into the jEdit 5.7 Java directory. In both cases jEdit stalled searching for "the". So presumably the notable difference does not reside within the jEdit JAR file itself. --- **[bugs:#4135] Slow HyperSearch Performance on macOS with Large Files and Queries** **Status:** open **Group:** Regressive (new to devel) **Created:** Sat May 25, 2024 12:31 AM UTC by Matthew Orzewalla **Last Updated:** Wed Aug 14, 2024 05:41 PM UTC **Owner:** nobody **Attachments:** - [activity.log](https://sourceforge.net/p/jedit/bugs/4135/attachment/activity.log) (17.4 kB; application/octet-stream) I have been observing slow hypersearch performanc on macOS for a while now, but wanted to wait for a preview of 5.7 to see if performance improved. From what I can tell, it began with the switch to Java 11, but I'm not positive that is the root cause. The bug has been observed on both Intel Macs and ARM Macs Steps I use to reproduce: 1. Download the plain text copy of Death Valley in '49 from Project Gutenberg here: https://www.gutenberg.org/ebooks/12236.txt.utf-8 2. Install and start up a fresh version jEdit 5.7pre (no prexisting jEdit user directory) from the version posted in this thread: https://sourceforge.net/p/jedit/bugs/4123/. On my system java-version lists: openjdk version "21.0.2" 2024-01-16 LTS OpenJDK Runtime Environment Temurin-21.0.2+13 (build 21.0.2+13-LTS) OpenJDK 64-Bit Server VM Temurin-21.0.2+13 (build 21.0.2+13-LTS, mixed mode) 3. Open the text file (pg12236.txt from the download on my system) in jEdit 4. Perform a search with Ignore Case and HyperSearch selected of the word "death". The 106 results should be returned fairly quickly 5. Perform a search for the word "from". The 625 results will eventually be returned, but it beachballs my system for about 50 seconds. Performing a search for the word "the" beachballs my system for longer than I am willing to wait. I can perform a search of the same file for the word "the" on a Windows install of jEdit and return the 15,733 results in less than 3 seconds (the Windows About jEdit screen lists, "jEdit 5.5.0 server mode, using Oracle Corporation Java 1.8.0_391). I am uploading the activity.log file., but I didn't see anything indicating the slow performance within the file. Let me know if there is any other information I can provide that can help diagnose the root cause. At first I had thought that it had something to do with docking or undocking the HyperSearch window (with docked causing slow performance), but then I went back and did some dedicated testing and found that it is slow undocked as well. It also seems that if I do more searches and work my way up to larger returns that the slowness subsides, as if it is slow allocating memory to the process, but once that memory gets allocated it is no longer slow. Thank you for your help in this matter. --- Sent from sourceforge.net because jed...@li... is subscribed to https://sourceforge.net/p/jedit/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jedit/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: Makarius <mak...@us...> - 2024-08-14 19:30:52
|
On 14/08/2024 19:33, Matthew Orzewalla via jEdit-devel wrote: > > Just to be sure, I checked Isabelle2024 again and it returned the 15,733 > hypersearch results very quickly, as expected. > > Also, I tried to find mention of a patch to Isabelle that would affect > hyperseach here: https://isabelle-dev.sketis.net/source/isabelle > <https://isabelle-dev.sketis.net/source/isabelle>, but did not find anything > that stood out. Just a side remark concerning Isabelle/jEdit: * The main source of patches is here: https://isabelle-dev.sketis.net/source/isabelle/browse/default/src/Tools/jEdit/patches Patch file-names provide an idea of the purpose, and further details are in the repository changelog for these files. * The effective patch is automatically generated againts the original sources, e.g. see Isabelle2024/contrib/jedit-20240425/jedit5.6.0.patch Details are in the Isabelle/Scala program that produces the derivative version of jEdit: https://isabelle-dev.sketis.net/source/isabelle/browse/default/src/Pure/Admin/component_jedit.scala Concerning the HyperSearch question, I can't remember doing anything special wrt. jEdit 5.6, and I did not try 5.7 yet. Makarius --- **[bugs:#4135] Slow HyperSearch Performance on macOS with Large Files and Queries** **Status:** open **Group:** Regressive (new to devel) **Created:** Sat May 25, 2024 12:31 AM UTC by Matthew Orzewalla **Last Updated:** Wed Aug 14, 2024 05:41 PM UTC **Owner:** nobody **Attachments:** - [activity.log](https://sourceforge.net/p/jedit/bugs/4135/attachment/activity.log) (17.4 kB; application/octet-stream) I have been observing slow hypersearch performanc on macOS for a while now, but wanted to wait for a preview of 5.7 to see if performance improved. >From what I can tell, it began with the switch to Java 11, but I'm not positive that is the root cause. The bug has been observed on both Intel Macs and ARM Macs Steps I use to reproduce: 1. Download the plain text copy of Death Valley in '49 from Project Gutenberg here: https://www.gutenberg.org/ebooks/12236.txt.utf-8 2. Install and start up a fresh version jEdit 5.7pre (no prexisting jEdit user directory) from the version posted in this thread: https://sourceforge.net/p/jedit/bugs/4123/. On my system java-version lists: openjdk version "21.0.2" 2024-01-16 LTS OpenJDK Runtime Environment Temurin-21.0.2+13 (build 21.0.2+13-LTS) OpenJDK 64-Bit Server VM Temurin-21.0.2+13 (build 21.0.2+13-LTS, mixed mode) 3. Open the text file (pg12236.txt from the download on my system) in jEdit 4. Perform a search with Ignore Case and HyperSearch selected of the word "death". The 106 results should be returned fairly quickly 5. Perform a search for the word "from". The 625 results will eventually be returned, but it beachballs my system for about 50 seconds. Performing a search for the word "the" beachballs my system for longer than I am willing to wait. I can perform a search of the same file for the word "the" on a Windows install of jEdit and return the 15,733 results in less than 3 seconds (the Windows About jEdit screen lists, "jEdit 5.5.0 server mode, using Oracle Corporation Java 1.8.0_391). I am uploading the activity.log file., but I didn't see anything indicating the slow performance within the file. Let me know if there is any other information I can provide that can help diagnose the root cause. At first I had thought that it had something to do with docking or undocking the HyperSearch window (with docked causing slow performance), but then I went back and did some dedicated testing and found that it is slow undocked as well. It also seems that if I do more searches and work my way up to larger returns that the slowness subsides, as if it is slow allocating memory to the process, but once that memory gets allocated it is no longer slow. Thank you for your help in this matter. --- Sent from sourceforge.net because jed...@li... is subscribed to https://sourceforge.net/p/jedit/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jedit/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: Makarius <mak...@sk...> - 2024-08-14 19:30:51
|
On 14/08/2024 19:33, Matthew Orzewalla via jEdit-devel wrote: > > Just to be sure, I checked Isabelle2024 again and it returned the 15,733 > hypersearch results very quickly, as expected. > > Also, I tried to find mention of a patch to Isabelle that would affect > hyperseach here: https://isabelle-dev.sketis.net/source/isabelle > <https://isabelle-dev.sketis.net/source/isabelle>, but did not find anything > that stood out. Just a side remark concerning Isabelle/jEdit: * The main source of patches is here: https://isabelle-dev.sketis.net/source/isabelle/browse/default/src/Tools/jEdit/patches Patch file-names provide an idea of the purpose, and further details are in the repository changelog for these files. * The effective patch is automatically generated againts the original sources, e.g. see Isabelle2024/contrib/jedit-20240425/jedit5.6.0.patch Details are in the Isabelle/Scala program that produces the derivative version of jEdit: https://isabelle-dev.sketis.net/source/isabelle/browse/default/src/Pure/Admin/component_jedit.scala Concerning the HyperSearch question, I can't remember doing anything special wrt. jEdit 5.6, and I did not try 5.7 yet. Makarius |
From: Matthew O. <le...@us...> - 2024-08-14 17:41:17
|
Well that would have been easier. :P Since it was easy enough to do, I tried that method, but got the same result. Searching "death" or "from" works as expected (there are less than 1,000 occurrences), but searching "the" produces unresponsiveness. --- **[bugs:#4135] Slow HyperSearch Performance on macOS with Large Files and Queries** **Status:** open **Group:** Regressive (new to devel) **Created:** Sat May 25, 2024 12:31 AM UTC by Matthew Orzewalla **Last Updated:** Wed Aug 14, 2024 05:33 PM UTC **Owner:** nobody **Attachments:** - [activity.log](https://sourceforge.net/p/jedit/bugs/4135/attachment/activity.log) (17.4 kB; application/octet-stream) I have been observing slow hypersearch performanc on macOS for a while now, but wanted to wait for a preview of 5.7 to see if performance improved. >From what I can tell, it began with the switch to Java 11, but I'm not positive that is the root cause. The bug has been observed on both Intel Macs and ARM Macs Steps I use to reproduce: 1. Download the plain text copy of Death Valley in '49 from Project Gutenberg here: https://www.gutenberg.org/ebooks/12236.txt.utf-8 2. Install and start up a fresh version jEdit 5.7pre (no prexisting jEdit user directory) from the version posted in this thread: https://sourceforge.net/p/jedit/bugs/4123/. On my system java-version lists: openjdk version "21.0.2" 2024-01-16 LTS OpenJDK Runtime Environment Temurin-21.0.2+13 (build 21.0.2+13-LTS) OpenJDK 64-Bit Server VM Temurin-21.0.2+13 (build 21.0.2+13-LTS, mixed mode) 3. Open the text file (pg12236.txt from the download on my system) in jEdit 4. Perform a search with Ignore Case and HyperSearch selected of the word "death". The 106 results should be returned fairly quickly 5. Perform a search for the word "from". The 625 results will eventually be returned, but it beachballs my system for about 50 seconds. Performing a search for the word "the" beachballs my system for longer than I am willing to wait. I can perform a search of the same file for the word "the" on a Windows install of jEdit and return the 15,733 results in less than 3 seconds (the Windows About jEdit screen lists, "jEdit 5.5.0 server mode, using Oracle Corporation Java 1.8.0_391). I am uploading the activity.log file., but I didn't see anything indicating the slow performance within the file. Let me know if there is any other information I can provide that can help diagnose the root cause. At first I had thought that it had something to do with docking or undocking the HyperSearch window (with docked causing slow performance), but then I went back and did some dedicated testing and found that it is slow undocked as well. It also seems that if I do more searches and work my way up to larger returns that the slowness subsides, as if it is slow allocating memory to the process, but once that memory gets allocated it is no longer slow. Thank you for your help in this matter. --- Sent from sourceforge.net because jed...@li... is subscribed to https://sourceforge.net/p/jedit/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jedit/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: Matthew O. <le...@us...> - 2024-08-14 17:33:17
|
Okay. I found some options for starting jEdit 5.6 here: https://apple.stackexchange.com/questions/426713/how-to-help-the-jedit-application-find-java And chose to start jEdit via the terminal using the following command: /usr/bin/java -jar /Applications/jEdit.app/Contents/Java/jedit.jar 2> /dev/null & About jEdit... lists the following: jEdit 5.6.0 server-background mode, using Azul Systems, Inc. Java 22.0.2 For this configuration I do still get a beachball when searching for the word "the" (it lasts several minutes; I ended up force quitting the app). Just to be sure, I checked Isabelle2024 again and it returned the 15,733 hypersearch results very quickly, as expected. Also, I tried to find mention of a patch to Isabelle that would affect hyperseach here: https://isabelle-dev.sketis.net/source/isabelle, but did not find anything that stood out. Thanks. --- **[bugs:#4135] Slow HyperSearch Performance on macOS with Large Files and Queries** **Status:** open **Group:** Regressive (new to devel) **Created:** Sat May 25, 2024 12:31 AM UTC by Matthew Orzewalla **Last Updated:** Wed Aug 14, 2024 05:21 PM UTC **Owner:** nobody **Attachments:** - [activity.log](https://sourceforge.net/p/jedit/bugs/4135/attachment/activity.log) (17.4 kB; application/octet-stream) I have been observing slow hypersearch performanc on macOS for a while now, but wanted to wait for a preview of 5.7 to see if performance improved. >From what I can tell, it began with the switch to Java 11, but I'm not positive that is the root cause. The bug has been observed on both Intel Macs and ARM Macs Steps I use to reproduce: 1. Download the plain text copy of Death Valley in '49 from Project Gutenberg here: https://www.gutenberg.org/ebooks/12236.txt.utf-8 2. Install and start up a fresh version jEdit 5.7pre (no prexisting jEdit user directory) from the version posted in this thread: https://sourceforge.net/p/jedit/bugs/4123/. On my system java-version lists: openjdk version "21.0.2" 2024-01-16 LTS OpenJDK Runtime Environment Temurin-21.0.2+13 (build 21.0.2+13-LTS) OpenJDK 64-Bit Server VM Temurin-21.0.2+13 (build 21.0.2+13-LTS, mixed mode) 3. Open the text file (pg12236.txt from the download on my system) in jEdit 4. Perform a search with Ignore Case and HyperSearch selected of the word "death". The 106 results should be returned fairly quickly 5. Perform a search for the word "from". The 625 results will eventually be returned, but it beachballs my system for about 50 seconds. Performing a search for the word "the" beachballs my system for longer than I am willing to wait. I can perform a search of the same file for the word "the" on a Windows install of jEdit and return the 15,733 results in less than 3 seconds (the Windows About jEdit screen lists, "jEdit 5.5.0 server mode, using Oracle Corporation Java 1.8.0_391). I am uploading the activity.log file., but I didn't see anything indicating the slow performance within the file. Let me know if there is any other information I can provide that can help diagnose the root cause. At first I had thought that it had something to do with docking or undocking the HyperSearch window (with docked causing slow performance), but then I went back and did some dedicated testing and found that it is slow undocked as well. It also seems that if I do more searches and work my way up to larger returns that the slowness subsides, as if it is slow allocating memory to the process, but once that memory gets allocated it is no longer slow. Thank you for your help in this matter. --- Sent from sourceforge.net because jed...@li... is subscribed to https://sourceforge.net/p/jedit/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jedit/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: Björn K. <vam...@us...> - 2024-08-14 17:21:38
|
It should be enough if you take the `jedit` file of 5.7 and overwrite the one in 5.6 --- **[bugs:#4135] Slow HyperSearch Performance on macOS with Large Files and Queries** **Status:** open **Group:** Regressive (new to devel) **Created:** Sat May 25, 2024 12:31 AM UTC by Matthew Orzewalla **Last Updated:** Wed Aug 14, 2024 05:05 PM UTC **Owner:** nobody **Attachments:** - [activity.log](https://sourceforge.net/p/jedit/bugs/4135/attachment/activity.log) (17.4 kB; application/octet-stream) I have been observing slow hypersearch performanc on macOS for a while now, but wanted to wait for a preview of 5.7 to see if performance improved. >From what I can tell, it began with the switch to Java 11, but I'm not positive that is the root cause. The bug has been observed on both Intel Macs and ARM Macs Steps I use to reproduce: 1. Download the plain text copy of Death Valley in '49 from Project Gutenberg here: https://www.gutenberg.org/ebooks/12236.txt.utf-8 2. Install and start up a fresh version jEdit 5.7pre (no prexisting jEdit user directory) from the version posted in this thread: https://sourceforge.net/p/jedit/bugs/4123/. On my system java-version lists: openjdk version "21.0.2" 2024-01-16 LTS OpenJDK Runtime Environment Temurin-21.0.2+13 (build 21.0.2+13-LTS) OpenJDK 64-Bit Server VM Temurin-21.0.2+13 (build 21.0.2+13-LTS, mixed mode) 3. Open the text file (pg12236.txt from the download on my system) in jEdit 4. Perform a search with Ignore Case and HyperSearch selected of the word "death". The 106 results should be returned fairly quickly 5. Perform a search for the word "from". The 625 results will eventually be returned, but it beachballs my system for about 50 seconds. Performing a search for the word "the" beachballs my system for longer than I am willing to wait. I can perform a search of the same file for the word "the" on a Windows install of jEdit and return the 15,733 results in less than 3 seconds (the Windows About jEdit screen lists, "jEdit 5.5.0 server mode, using Oracle Corporation Java 1.8.0_391). I am uploading the activity.log file., but I didn't see anything indicating the slow performance within the file. Let me know if there is any other information I can provide that can help diagnose the root cause. At first I had thought that it had something to do with docking or undocking the HyperSearch window (with docked causing slow performance), but then I went back and did some dedicated testing and found that it is slow undocked as well. It also seems that if I do more searches and work my way up to larger returns that the slowness subsides, as if it is slow allocating memory to the process, but once that memory gets allocated it is no longer slow. Thank you for your help in this matter. --- Sent from sourceforge.net because jed...@li... is subscribed to https://sourceforge.net/p/jedit/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jedit/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: Matthew O. <le...@us...> - 2024-08-14 17:05:20
|
I am fairly certain the issue existed in jEdit 5.6 for macOS. I just now reinstalled 5.6 to confirm, but am running into the "This application required that Java 11 or later be installed on your computer" issue with a vanilla install. I will need to go find agan the steps needed to get 5.6 pointed to the Java 11 I have installed on the system. --- **[bugs:#4135] Slow HyperSearch Performance on macOS with Large Files and Queries** **Status:** open **Group:** Regressive (new to devel) **Created:** Sat May 25, 2024 12:31 AM UTC by Matthew Orzewalla **Last Updated:** Wed Aug 14, 2024 04:02 PM UTC **Owner:** nobody **Attachments:** - [activity.log](https://sourceforge.net/p/jedit/bugs/4135/attachment/activity.log) (17.4 kB; application/octet-stream) I have been observing slow hypersearch performanc on macOS for a while now, but wanted to wait for a preview of 5.7 to see if performance improved. >From what I can tell, it began with the switch to Java 11, but I'm not positive that is the root cause. The bug has been observed on both Intel Macs and ARM Macs Steps I use to reproduce: 1. Download the plain text copy of Death Valley in '49 from Project Gutenberg here: https://www.gutenberg.org/ebooks/12236.txt.utf-8 2. Install and start up a fresh version jEdit 5.7pre (no prexisting jEdit user directory) from the version posted in this thread: https://sourceforge.net/p/jedit/bugs/4123/. On my system java-version lists: openjdk version "21.0.2" 2024-01-16 LTS OpenJDK Runtime Environment Temurin-21.0.2+13 (build 21.0.2+13-LTS) OpenJDK 64-Bit Server VM Temurin-21.0.2+13 (build 21.0.2+13-LTS, mixed mode) 3. Open the text file (pg12236.txt from the download on my system) in jEdit 4. Perform a search with Ignore Case and HyperSearch selected of the word "death". The 106 results should be returned fairly quickly 5. Perform a search for the word "from". The 625 results will eventually be returned, but it beachballs my system for about 50 seconds. Performing a search for the word "the" beachballs my system for longer than I am willing to wait. I can perform a search of the same file for the word "the" on a Windows install of jEdit and return the 15,733 results in less than 3 seconds (the Windows About jEdit screen lists, "jEdit 5.5.0 server mode, using Oracle Corporation Java 1.8.0_391). I am uploading the activity.log file., but I didn't see anything indicating the slow performance within the file. Let me know if there is any other information I can provide that can help diagnose the root cause. At first I had thought that it had something to do with docking or undocking the HyperSearch window (with docked causing slow performance), but then I went back and did some dedicated testing and found that it is slow undocked as well. It also seems that if I do more searches and work my way up to larger returns that the slowness subsides, as if it is slow allocating memory to the process, but once that memory gets allocated it is no longer slow. Thank you for your help in this matter. --- Sent from sourceforge.net because jed...@li... is subscribed to https://sourceforge.net/p/jedit/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jedit/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: Alan E. <ez...@us...> - 2024-08-14 16:02:07
|
So just to confirm, you see this problem in jEdit 5.5 but not 5.7. What about jEdit 5.6? --- **[bugs:#4135] Slow HyperSearch Performance on macOS with Large Files and Queries** **Status:** open **Group:** Regressive (new to devel) **Created:** Sat May 25, 2024 12:31 AM UTC by Matthew Orzewalla **Last Updated:** Wed Aug 14, 2024 02:48 PM UTC **Owner:** nobody **Attachments:** - [activity.log](https://sourceforge.net/p/jedit/bugs/4135/attachment/activity.log) (17.4 kB; application/octet-stream) I have been observing slow hypersearch performanc on macOS for a while now, but wanted to wait for a preview of 5.7 to see if performance improved. >From what I can tell, it began with the switch to Java 11, but I'm not positive that is the root cause. The bug has been observed on both Intel Macs and ARM Macs Steps I use to reproduce: 1. Download the plain text copy of Death Valley in '49 from Project Gutenberg here: https://www.gutenberg.org/ebooks/12236.txt.utf-8 2. Install and start up a fresh version jEdit 5.7pre (no prexisting jEdit user directory) from the version posted in this thread: https://sourceforge.net/p/jedit/bugs/4123/. On my system java-version lists: openjdk version "21.0.2" 2024-01-16 LTS OpenJDK Runtime Environment Temurin-21.0.2+13 (build 21.0.2+13-LTS) OpenJDK 64-Bit Server VM Temurin-21.0.2+13 (build 21.0.2+13-LTS, mixed mode) 3. Open the text file (pg12236.txt from the download on my system) in jEdit 4. Perform a search with Ignore Case and HyperSearch selected of the word "death". The 106 results should be returned fairly quickly 5. Perform a search for the word "from". The 625 results will eventually be returned, but it beachballs my system for about 50 seconds. Performing a search for the word "the" beachballs my system for longer than I am willing to wait. I can perform a search of the same file for the word "the" on a Windows install of jEdit and return the 15,733 results in less than 3 seconds (the Windows About jEdit screen lists, "jEdit 5.5.0 server mode, using Oracle Corporation Java 1.8.0_391). I am uploading the activity.log file., but I didn't see anything indicating the slow performance within the file. Let me know if there is any other information I can provide that can help diagnose the root cause. At first I had thought that it had something to do with docking or undocking the HyperSearch window (with docked causing slow performance), but then I went back and did some dedicated testing and found that it is slow undocked as well. It also seems that if I do more searches and work my way up to larger returns that the slowness subsides, as if it is slow allocating memory to the process, but once that memory gets allocated it is no longer slow. Thank you for your help in this matter. --- Sent from sourceforge.net because jed...@li... is subscribed to https://sourceforge.net/p/jedit/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jedit/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: Alan E. <ez...@us...> - 2024-08-14 14:48:30
|
- **Group**: normal bug --> Regressive (new to devel) - **Comment**: --- **[bugs:#4135] Slow HyperSearch Performance on macOS with Large Files and Queries** **Status:** open **Group:** Regressive (new to devel) **Created:** Sat May 25, 2024 12:31 AM UTC by Matthew Orzewalla **Last Updated:** Sun Aug 11, 2024 09:29 PM UTC **Owner:** nobody **Attachments:** - [activity.log](https://sourceforge.net/p/jedit/bugs/4135/attachment/activity.log) (17.4 kB; application/octet-stream) I have been observing slow hypersearch performanc on macOS for a while now, but wanted to wait for a preview of 5.7 to see if performance improved. >From what I can tell, it began with the switch to Java 11, but I'm not positive that is the root cause. The bug has been observed on both Intel Macs and ARM Macs Steps I use to reproduce: 1. Download the plain text copy of Death Valley in '49 from Project Gutenberg here: https://www.gutenberg.org/ebooks/12236.txt.utf-8 2. Install and start up a fresh version jEdit 5.7pre (no prexisting jEdit user directory) from the version posted in this thread: https://sourceforge.net/p/jedit/bugs/4123/. On my system java-version lists: openjdk version "21.0.2" 2024-01-16 LTS OpenJDK Runtime Environment Temurin-21.0.2+13 (build 21.0.2+13-LTS) OpenJDK 64-Bit Server VM Temurin-21.0.2+13 (build 21.0.2+13-LTS, mixed mode) 3. Open the text file (pg12236.txt from the download on my system) in jEdit 4. Perform a search with Ignore Case and HyperSearch selected of the word "death". The 106 results should be returned fairly quickly 5. Perform a search for the word "from". The 625 results will eventually be returned, but it beachballs my system for about 50 seconds. Performing a search for the word "the" beachballs my system for longer than I am willing to wait. I can perform a search of the same file for the word "the" on a Windows install of jEdit and return the 15,733 results in less than 3 seconds (the Windows About jEdit screen lists, "jEdit 5.5.0 server mode, using Oracle Corporation Java 1.8.0_391). I am uploading the activity.log file., but I didn't see anything indicating the slow performance within the file. Let me know if there is any other information I can provide that can help diagnose the root cause. At first I had thought that it had something to do with docking or undocking the HyperSearch window (with docked causing slow performance), but then I went back and did some dedicated testing and found that it is slow undocked as well. It also seems that if I do more searches and work my way up to larger returns that the slowness subsides, as if it is slow allocating memory to the process, but once that memory gets allocated it is no longer slow. Thank you for your help in this matter. --- Sent from sourceforge.net because jed...@li... is subscribed to https://sourceforge.net/p/jedit/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jedit/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: Alan E. <ala...@gm...> - 2024-08-13 13:33:20
|
Looks like Sidekick 1.9 needs to be released. 1.8 came out in 2015 and there are a few changes since then. --Alan |
From: Matthew O. <le...@us...> - 2024-08-11 21:29:42
|
With the release of jEdit 5.7, I tried the process again. i installed jEdit 5.7 on Windows 10 using Temurin 21 (let me know if the details are needed; I am not in front of the Windows machine at the moment), and HyperSearch works as expected for the test file for searching "death", "from", or "the". I tested jEdit 5.7 on an ARM Mac using Temurin 22 (on Windows I did not realize that Temurin 22 was the latest release) and I am still observing a sustained beachball when searching "the". I did try turing off the Text Color and Background Color checkboxes within the HyperSearch Style Editor, and I think that may have sped up performance when searching "from", but the search still had issues searching the word "the". Since the original post, I noticed that Isabelle2024 was released here: https://isabelle.in.tum.de. When performing the same proceedure with the Isabelle2024 (jEdit 5.6 under the covers) HyperSearch works as expected (taking maybe a couple seconds to populate the HyperSearch results for "the"). Isabelle uses the Azul Systems Java 21 virtual machine built-in to the install. I tried changing the macOS Java vurtual machine to Azul Systems Java 21, but got the same anomolous result for jEdit 5.7. I would use Isabelle2024 going forward, but I do like the better macOS integration available in jEdit 5.7. :) --- **[bugs:#4135] Slow HyperSearch Performance on macOS with Large Files and Queries** **Status:** open **Group:** normal bug **Created:** Sat May 25, 2024 12:31 AM UTC by Matthew Orzewalla **Last Updated:** Sat May 25, 2024 12:31 AM UTC **Owner:** nobody **Attachments:** - [activity.log](https://sourceforge.net/p/jedit/bugs/4135/attachment/activity.log) (17.4 kB; application/octet-stream) I have been observing slow hypersearch performanc on macOS for a while now, but wanted to wait for a preview of 5.7 to see if performance improved. >From what I can tell, it began with the switch to Java 11, but I'm not positive that is the root cause. The bug has been observed on both Intel Macs and ARM Macs Steps I use to reproduce: 1. Download the plain text copy of Death Valley in '49 from Project Gutenberg here: https://www.gutenberg.org/ebooks/12236.txt.utf-8 2. Install and start up a fresh version jEdit 5.7pre (no prexisting jEdit user directory) from the version posted in this thread: https://sourceforge.net/p/jedit/bugs/4123/. On my system java-version lists: openjdk version "21.0.2" 2024-01-16 LTS OpenJDK Runtime Environment Temurin-21.0.2+13 (build 21.0.2+13-LTS) OpenJDK 64-Bit Server VM Temurin-21.0.2+13 (build 21.0.2+13-LTS, mixed mode) 3. Open the text file (pg12236.txt from the download on my system) in jEdit 4. Perform a search with Ignore Case and HyperSearch selected of the word "death". The 106 results should be returned fairly quickly 5. Perform a search for the word "from". The 625 results will eventually be returned, but it beachballs my system for about 50 seconds. Performing a search for the word "the" beachballs my system for longer than I am willing to wait. I can perform a search of the same file for the word "the" on a Windows install of jEdit and return the 15,733 results in less than 3 seconds (the Windows About jEdit screen lists, "jEdit 5.5.0 server mode, using Oracle Corporation Java 1.8.0_391). I am uploading the activity.log file., but I didn't see anything indicating the slow performance within the file. Let me know if there is any other information I can provide that can help diagnose the root cause. At first I had thought that it had something to do with docking or undocking the HyperSearch window (with docked causing slow performance), but then I went back and did some dedicated testing and found that it is slow undocked as well. It also seems that if I do more searches and work my way up to larger returns that the slowness subsides, as if it is slow allocating memory to the process, but once that memory gets allocated it is no longer slow. Thank you for your help in this matter. --- Sent from sourceforge.net because jed...@li... is subscribed to https://sourceforge.net/p/jedit/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jedit/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: marco m. <mi...@us...> - 2024-08-08 12:57:34
|
--- **[plugin-feature-requests:#401] Language Server Protocol implementation for JEdit** **Status:** open **Group:** **Labels:** LSP implementation Language Server Protocol implementation **Created:** Thu Aug 08, 2024 12:57 PM UTC by marco milanesi **Last Updated:** Thu Aug 08, 2024 12:57 PM UTC **Owner:** nobody Hi! short question: do you know if someone is trying to implement at least Java "**Language Server Protocol**" (LSP) as JEdit Plugin ? instead using old JavaCC (or Antlr) that works bad with JDK-11... i've found this, but doesn't work properly : https://git.sr.ht/~damien/jedit-lsp thanks for any info greets --- Sent from sourceforge.net because jed...@li... is subscribed to https://sourceforge.net/p/jedit/plugin-feature-requests/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jedit/admin/plugin-feature-requests/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: Björn K. <vam...@us...> - 2024-08-05 14:04:29
|
Hey Bobby, I'm sorry I missed your message. 5.7.0 is released since yesterday, so hopefully with that at least the startup problems should also be resolved for you. Let me know whether that works now for you. --- **[bugs:#4123] macOS Jedit cannot find Java engine** **Status:** closed-fixed **Group:** severe bug **Created:** Fri Mar 17, 2023 09:04 AM UTC by Rene Vincent Jansen **Last Updated:** Wed May 29, 2024 09:42 PM UTC **Owner:** Björn Kautler I installed Jedit (latest) from a macOS .dmg on Ventura 13.2.1. It complains it requires a Java 11 or higher; I have Java 19 on the path. --- Sent from sourceforge.net because jed...@li... is subscribed to https://sourceforge.net/p/jedit/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jedit/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: Björn K. <vam...@us...> - 2024-08-04 17:39:33
|
And it even comes with DirtyGutter disabled in its plugins menu. To work-around you really have to disable the whole plugin. --- **[plugin-bugs:#1711] DirtyGutter causes issues with FTP plugin** **Status:** open **Group:** **Created:** Tue May 07, 2013 05:28 PM UTC by Anonymous **Last Updated:** Sun Aug 04, 2024 05:34 PM UTC **Owner:** nobody When changing a line, jEdit is hanging a little because the DirtyGutter \(LCMPlugin\) is throwing an exception due to invalid slashes in the file path over sftp. Disabling the DirtyGutter plugin resolves this issue. My environment details: jEdit 5.1pre1 Java 1.7.0\_15 Windows 7 64bit here is the exception \(note the backslashes in the first line\): java.io.FileNotFoundException: \home\jmcmul01\scripts\jim.ksh \(The system cannot find the path specified\) at java.io.FileInputStream.open\(Native Method\) at java.io.FileInputStream.<init>\(FileInputStream.java:138\) at java.io.FileInputStream.<init>\(FileInputStream.java:97\) at org.gjt.sp.jedit.io.FileVFS.\_createInputStream\(FileVFS.java:519\) at lcm.LCMPlugin.readFile\(Unknown Source\) at lcm.providers.diff.DiffBufferHandler.doDiff\(Unknown Source\) at lcm.providers.diff.DiffBufferHandler.handleContentChange\(Unknown Source\) at lcm.providers.diff.DiffBufferHandler.contentInserted\(Unknown Source\) at org.gjt.sp.jedit.buffer.JEditBuffer.fireContentInserted\(JEditBuffer.java:2458\) at org.gjt.sp.jedit.buffer.JEditBuffer.contentInserted\(JEditBuffer.java:2790\) at org.gjt.sp.jedit.buffer.JEditBuffer.insert\(JEditBuffer.java:734\) at org.gjt.sp.jedit.buffer.JEditBuffer.insert\(JEditBuffer.java:678\) at org.gjt.sp.jedit.textarea.TextArea.replaceSelection\(TextArea.java:2076\) at org.gjt.sp.jedit.textarea.JEditTextArea.replaceSelection\(JEditTextArea.java:248\) at org.gjt.sp.jedit.textarea.TextArea.setSelectedText\(TextArea.java:2034\) at org.gjt.sp.jedit.textarea.TextArea.insertEnterAndIndent\(TextArea.java:4476\) at sun.reflect.NativeMethodAccessorImpl.invoke0\(Native Method\) at sun.reflect.NativeMethodAccessorImpl.invoke\(NativeMethodAccessorImpl.java:57\) at sun.reflect.DelegatingMethodAccessorImpl.invoke\(DelegatingMethodAccessorImpl.java:43\) at java.lang.reflect.Method.invoke\(Method.java:601\) at org.gjt.sp.jedit.bsh.Reflect.invokeMethod\(Reflect.java:134\) at org.gjt.sp.jedit.bsh.Reflect.invokeObjectMethod\(Reflect.java:80\) at org.gjt.sp.jedit.bsh.Name.invokeMethod\(Name.java:855\) at org.gjt.sp.jedit.bsh.BSHMethodInvocation.eval\(BSHMethodInvocation.java:75\) at org.gjt.sp.jedit.bsh.BSHPrimaryExpression.eval\(BSHPrimaryExpression.java:102\) at org.gjt.sp.jedit.bsh.BSHPrimaryExpression.eval\(BSHPrimaryExpression.java:47\) at org.gjt.sp.jedit.bsh.BSHBlock.evalBlock\(BSHBlock.java:130\) at org.gjt.sp.jedit.bsh.BSHBlock.eval\(BSHBlock.java:80\) at org.gjt.sp.jedit.bsh.BshMethod.invokeImpl\(BshMethod.java:362\) at org.gjt.sp.jedit.bsh.BshMethod.invoke\(BshMethod.java:258\) at org.gjt.sp.jedit.bsh.BshMethod.invoke\(BshMethod.java:186\) at org.gjt.sp.jedit.BeanShellFacade.runCachedBlock\(BeanShellFacade.java:225\) at org.gjt.sp.jedit.BeanShell.runCachedBlock\(BeanShell.java:431\) at org.gjt.sp.jedit.BeanShellAction.invoke\(BeanShellAction.java:73\) at org.gjt.sp.jedit.gui.InputHandler.invokeAction\(InputHandler.java:342\) at org.gjt.sp.jedit.gui.InputHandler.invokeAction\(InputHandler.java:307\) at org.gjt.sp.jedit.gui.DefaultInputHandler.handleKey\(DefaultInputHandler.java:196\) at org.gjt.sp.jedit.input.AbstractInputHandler.processKeyEventKeyStrokeHandling\(AbstractInputHandler.java:405\) at org.gjt.sp.jedit.gui.InputHandler.processKeyEvent\(InputHandler.java:151\) at org.gjt.sp.jedit.textarea.TextArea.processKeyEvent\(TextArea.java:4726\) at java.awt.Component.processEvent\(Component.java:6282\) at java.awt.Container.processEvent\(Container.java:2229\) at java.awt.Component.dispatchEventImpl\(Component.java:4861\) at java.awt.Container.dispatchEventImpl\(Container.java:2287\) at java.awt.Component.dispatchEvent\(Component.java:4687\) at java.awt.KeyboardFocusManager.redispatchEvent\(KeyboardFocusManager.java:1895\) at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent\(DefaultKeyboardFocusManager.java:762\) at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent\(DefaultKeyboardFocusManager.java:1027\) at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions\(DefaultKeyboardFocusManager.java:899\) at java.awt.DefaultKeyboardFocusManager.dispatchEvent\(DefaultKeyboardFocusManager.java:727\) at java.awt.Component.dispatchEventImpl\(Component.java:4731\) at java.awt.Container.dispatchEventImpl\(Container.java:2287\) at java.awt.Window.dispatchEventImpl\(Window.java:2719\) at java.awt.Component.dispatchEvent\(Component.java:4687\) at java.awt.EventQueue.dispatchEventImpl\(EventQueue.java:729\) at java.awt.EventQueue.access$200\(EventQueue.java:103\) at java.awt.EventQueue$3.run\(EventQueue.java:688\) at java.awt.EventQueue$3.run\(EventQueue.java:686\) at java.security.AccessController.doPrivileged\(Native Method\) at java.security.ProtectionDomain$1.doIntersectionPrivilege\(ProtectionDomain.java:76\) at java.security.ProtectionDomain$1.doIntersectionPrivilege\(ProtectionDomain.java:87\) at java.awt.EventQueue$4.run\(EventQueue.java:702\) at java.awt.EventQueue$4.run\(EventQueue.java:700\) at java.security.AccessController.doPrivileged\(Native Method\) at java.security.ProtectionDomain$1.doIntersectionPrivilege\(ProtectionDomain.java:76\) at java.awt.EventQueue.dispatchEvent\(EventQueue.java:699\) at java.awt.EventDispatchThread.pumpOneEventForFilters\(EventDispatchThread.java:242\) at java.awt.EventDispatchThread.pumpEventsForFilter\(EventDispatchThread.java:161\) at java.awt.EventDispatchThread.pumpEventsForHierarchy\(EventDispatchThread.java:150\) at java.awt.EventDispatchThread.pumpEvents\(EventDispatchThread.java:146\) at java.awt.EventDispatchThread.pumpEvents\(EventDispatchThread.java:138\) at java.awt.EventDispatchThread.run\(EventDispatchThread.java:91\) --- Sent from sourceforge.net because jed...@li... is subscribed to https://sourceforge.net/p/jedit/plugin-bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jedit/admin/plugin-bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: Björn K. <vam...@us...> - 2024-08-04 17:34:39
|
jEdit is not hanging for me, and I don't think the problem are the "invalid backslashes". >From what I see (I also get this exception on jEdit 5.7.0 with DirtyGutter 0.3b) I'd say the problem is that the plugin considers all buffers to be local, not considering the file system where the file actually coming from. --- **[plugin-bugs:#1711] DirtyGutter causes issues with FTP plugin** **Status:** open **Group:** **Created:** Tue May 07, 2013 05:28 PM UTC by Anonymous **Last Updated:** Fri Feb 05, 2016 12:57 PM UTC **Owner:** nobody When changing a line, jEdit is hanging a little because the DirtyGutter \(LCMPlugin\) is throwing an exception due to invalid slashes in the file path over sftp. Disabling the DirtyGutter plugin resolves this issue. My environment details: jEdit 5.1pre1 Java 1.7.0\_15 Windows 7 64bit here is the exception \(note the backslashes in the first line\): java.io.FileNotFoundException: \home\jmcmul01\scripts\jim.ksh \(The system cannot find the path specified\) at java.io.FileInputStream.open\(Native Method\) at java.io.FileInputStream.<init>\(FileInputStream.java:138\) at java.io.FileInputStream.<init>\(FileInputStream.java:97\) at org.gjt.sp.jedit.io.FileVFS.\_createInputStream\(FileVFS.java:519\) at lcm.LCMPlugin.readFile\(Unknown Source\) at lcm.providers.diff.DiffBufferHandler.doDiff\(Unknown Source\) at lcm.providers.diff.DiffBufferHandler.handleContentChange\(Unknown Source\) at lcm.providers.diff.DiffBufferHandler.contentInserted\(Unknown Source\) at org.gjt.sp.jedit.buffer.JEditBuffer.fireContentInserted\(JEditBuffer.java:2458\) at org.gjt.sp.jedit.buffer.JEditBuffer.contentInserted\(JEditBuffer.java:2790\) at org.gjt.sp.jedit.buffer.JEditBuffer.insert\(JEditBuffer.java:734\) at org.gjt.sp.jedit.buffer.JEditBuffer.insert\(JEditBuffer.java:678\) at org.gjt.sp.jedit.textarea.TextArea.replaceSelection\(TextArea.java:2076\) at org.gjt.sp.jedit.textarea.JEditTextArea.replaceSelection\(JEditTextArea.java:248\) at org.gjt.sp.jedit.textarea.TextArea.setSelectedText\(TextArea.java:2034\) at org.gjt.sp.jedit.textarea.TextArea.insertEnterAndIndent\(TextArea.java:4476\) at sun.reflect.NativeMethodAccessorImpl.invoke0\(Native Method\) at sun.reflect.NativeMethodAccessorImpl.invoke\(NativeMethodAccessorImpl.java:57\) at sun.reflect.DelegatingMethodAccessorImpl.invoke\(DelegatingMethodAccessorImpl.java:43\) at java.lang.reflect.Method.invoke\(Method.java:601\) at org.gjt.sp.jedit.bsh.Reflect.invokeMethod\(Reflect.java:134\) at org.gjt.sp.jedit.bsh.Reflect.invokeObjectMethod\(Reflect.java:80\) at org.gjt.sp.jedit.bsh.Name.invokeMethod\(Name.java:855\) at org.gjt.sp.jedit.bsh.BSHMethodInvocation.eval\(BSHMethodInvocation.java:75\) at org.gjt.sp.jedit.bsh.BSHPrimaryExpression.eval\(BSHPrimaryExpression.java:102\) at org.gjt.sp.jedit.bsh.BSHPrimaryExpression.eval\(BSHPrimaryExpression.java:47\) at org.gjt.sp.jedit.bsh.BSHBlock.evalBlock\(BSHBlock.java:130\) at org.gjt.sp.jedit.bsh.BSHBlock.eval\(BSHBlock.java:80\) at org.gjt.sp.jedit.bsh.BshMethod.invokeImpl\(BshMethod.java:362\) at org.gjt.sp.jedit.bsh.BshMethod.invoke\(BshMethod.java:258\) at org.gjt.sp.jedit.bsh.BshMethod.invoke\(BshMethod.java:186\) at org.gjt.sp.jedit.BeanShellFacade.runCachedBlock\(BeanShellFacade.java:225\) at org.gjt.sp.jedit.BeanShell.runCachedBlock\(BeanShell.java:431\) at org.gjt.sp.jedit.BeanShellAction.invoke\(BeanShellAction.java:73\) at org.gjt.sp.jedit.gui.InputHandler.invokeAction\(InputHandler.java:342\) at org.gjt.sp.jedit.gui.InputHandler.invokeAction\(InputHandler.java:307\) at org.gjt.sp.jedit.gui.DefaultInputHandler.handleKey\(DefaultInputHandler.java:196\) at org.gjt.sp.jedit.input.AbstractInputHandler.processKeyEventKeyStrokeHandling\(AbstractInputHandler.java:405\) at org.gjt.sp.jedit.gui.InputHandler.processKeyEvent\(InputHandler.java:151\) at org.gjt.sp.jedit.textarea.TextArea.processKeyEvent\(TextArea.java:4726\) at java.awt.Component.processEvent\(Component.java:6282\) at java.awt.Container.processEvent\(Container.java:2229\) at java.awt.Component.dispatchEventImpl\(Component.java:4861\) at java.awt.Container.dispatchEventImpl\(Container.java:2287\) at java.awt.Component.dispatchEvent\(Component.java:4687\) at java.awt.KeyboardFocusManager.redispatchEvent\(KeyboardFocusManager.java:1895\) at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent\(DefaultKeyboardFocusManager.java:762\) at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent\(DefaultKeyboardFocusManager.java:1027\) at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions\(DefaultKeyboardFocusManager.java:899\) at java.awt.DefaultKeyboardFocusManager.dispatchEvent\(DefaultKeyboardFocusManager.java:727\) at java.awt.Component.dispatchEventImpl\(Component.java:4731\) at java.awt.Container.dispatchEventImpl\(Container.java:2287\) at java.awt.Window.dispatchEventImpl\(Window.java:2719\) at java.awt.Component.dispatchEvent\(Component.java:4687\) at java.awt.EventQueue.dispatchEventImpl\(EventQueue.java:729\) at java.awt.EventQueue.access$200\(EventQueue.java:103\) at java.awt.EventQueue$3.run\(EventQueue.java:688\) at java.awt.EventQueue$3.run\(EventQueue.java:686\) at java.security.AccessController.doPrivileged\(Native Method\) at java.security.ProtectionDomain$1.doIntersectionPrivilege\(ProtectionDomain.java:76\) at java.security.ProtectionDomain$1.doIntersectionPrivilege\(ProtectionDomain.java:87\) at java.awt.EventQueue$4.run\(EventQueue.java:702\) at java.awt.EventQueue$4.run\(EventQueue.java:700\) at java.security.AccessController.doPrivileged\(Native Method\) at java.security.ProtectionDomain$1.doIntersectionPrivilege\(ProtectionDomain.java:76\) at java.awt.EventQueue.dispatchEvent\(EventQueue.java:699\) at java.awt.EventDispatchThread.pumpOneEventForFilters\(EventDispatchThread.java:242\) at java.awt.EventDispatchThread.pumpEventsForFilter\(EventDispatchThread.java:161\) at java.awt.EventDispatchThread.pumpEventsForHierarchy\(EventDispatchThread.java:150\) at java.awt.EventDispatchThread.pumpEvents\(EventDispatchThread.java:146\) at java.awt.EventDispatchThread.pumpEvents\(EventDispatchThread.java:138\) at java.awt.EventDispatchThread.run\(EventDispatchThread.java:91\) --- Sent from sourceforge.net because jed...@li... is subscribed to https://sourceforge.net/p/jedit/plugin-bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jedit/admin/plugin-bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: Eric Le L. <ker...@us...> - 2024-07-31 16:55:09
|
- **status**: pending --> closed-accepted - **Comment**: Released to [plugin central](https://plugins.jedit.org/plugins/?QDocSideKick) --- **[plugin-central-submission:#1082] QDocSidekick** **Status:** closed-accepted **Group:** None **Created:** Wed May 22, 2024 03:17 AM UTC by Dale Anson **Last Updated:** Sat Jul 20, 2024 02:54 PM UTC **Owner:** Eric Le Lay {{{ QDocSideKick 1.0 Source: Source code is in SVN with the tag 1.0 Announcement: Initial release. Brand new plugin for working with QDoc files https://doc.qt.io/qt-6/01-qdoc-manual.html.. While the manual says "QDoc finds QDoc comments in .cpp files and in .qdoc files", this QDocSideKick plugin only works with .qdoc files. Requires Java 11 Requires jEdit 05.04.00.00 Short Description: QDocSideKick Long Description: <html> <p>SideKick for QDoc files</p> </html> }}} --- Sent from sourceforge.net because jed...@li... is subscribed to https://sourceforge.net/p/jedit/plugin-central-submission/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jedit/admin/plugin-central-submission/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: Eric Le L. <ker...@us...> - 2024-07-20 14:54:31
|
Thanks Dale for the fixes. Indeed the example was already there and it is well parsed. I was able to build the plugin and can release as is, but could you consider including this fix so indented `\section1` works? Example: ~~~ /*! \section1 Basic Qt This is the first section. \section2 Getting Started This is the first subsection. \section3 Hello Qt This is the first subsubsection. \section3 Making Connections This is the second subsubsection. \section3 Using the Reference Documentation This is the third subsubsection. \section2 Creating Dialogs This is the second subsection. \section3 Subclassing QDialog This is the first subsubsection. ... \section1 Intermediate Qt This is the second section. \section2 Layout Management This is the second section's first subsection. \section3 Basic Layouts This is the first subsubsection. ... */ ~~~ In QDocSideKickParser.java, line 121 ~~~ - String section = lineText.substring(index, length); + String section = lineText.substring(index, index + length); ~~~ Thanks, --- **[plugin-central-submission:#1082] QDocSidekick** **Status:** pending **Group:** None **Created:** Wed May 22, 2024 03:17 AM UTC by Dale Anson **Last Updated:** Fri Jul 19, 2024 08:54 PM UTC **Owner:** Eric Le Lay {{{ QDocSideKick 1.0 Source: Source code is in SVN with the tag 1.0 Announcement: Initial release. Brand new plugin for working with QDoc files https://doc.qt.io/qt-6/01-qdoc-manual.html.. While the manual says "QDoc finds QDoc comments in .cpp files and in .qdoc files", this QDocSideKick plugin only works with .qdoc files. Requires Java 11 Requires jEdit 05.04.00.00 Short Description: QDocSideKick Long Description: <html> <p>SideKick for QDoc files</p> </html> }}} --- Sent from sourceforge.net because jed...@li... is subscribed to https://sourceforge.net/p/jedit/plugin-central-submission/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jedit/admin/plugin-central-submission/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |