Menu
▾
▴
jedit-devel
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
(13) |
Oct
(33) |
Nov
(7) |
Dec
(12) |
| 2025 |
Jan
(3) |
Feb
(26) |
Mar
(14) |
Apr
(9) |
May
(1) |
Jun
(9) |
Jul
(1) |
Aug
(5) |
Sep
(6) |
Oct
(1) |
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
(5) |
2
(7) |
|
3
(6) |
4
(8) |
5
(14) |
6
(11) |
7
(10) |
8
(2) |
9
(4) |
|
10
(5) |
11
(2) |
12
(21) |
13
(11) |
14
(26) |
15
(11) |
16
(3) |
|
17
(5) |
18
(28) |
19
(17) |
20
(19) |
21
(7) |
22
(2) |
23
(1) |
|
24
|
25
(1) |
26
(4) |
27
(4) |
28
(3) |
29
(4) |
30
(4) |
|
31
|
|
|
|
|
|
|
|
From: SourceForge.net <no...@so...> - 2009-05-30 19:30:34
|
Plugin Central Submission item #2798882, was opened at 2009-05-30 16:39 Message generated for change (Comment added) made by seryakov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=625093&aid=2798882&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: Vlad Seryakov (seryakov) Assigned to: Nobody/Anonymous (nobody) Summary: ScalacPlugin 1.0.0 Initial Comment: {{{ Scalac 1.0.0 Source: Source code is in SVN svn://www.crystalballinc.com/Scalac Binary: ftp://www.crystalballinc.com/pub/vlad/ScalacPlugin.jar Announcement: Requires Java 1.5 Requires jEdit 04.03.07.00 Required plugins: console.ConsolePlugin 4.3.8 errorlist.ErrorListPlugin 1.7 Short Description: Scala Plugin for compilation of Scala files inside the editor without invoking external scalac compiler Long Description: <html> The ScalacPlugin is embedded Scala compiler that runs inside jEdit's JVM which results in faster compilation times because no external jvm is called. It is integrated with Console and ErrorList plugins to handle output and error navigation. </html> }}} ---------------------------------------------------------------------- >Comment By: Vlad Seryakov (seryakov) Date: 2009-05-30 19:30 Message: New source code location is http://bitbucket.org/vseryakov/scalac-jedit/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=625093&aid=2798882&group_id=588 |
|
From: SourceForge.net <no...@so...> - 2009-05-30 16:40:24
|
Plugin Central Submission item #2798882, was opened at 2009-05-30 16:39 Message generated for change (Settings changed) made by seryakov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=625093&aid=2798882&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: Vlad Seryakov (seryakov) Assigned to: Nobody/Anonymous (nobody) >Summary: ScalacPlugin 1.0.0 Initial Comment: {{{ Scalac 1.0.0 Source: Source code is in SVN svn://www.crystalballinc.com/Scalac Binary: ftp://www.crystalballinc.com/pub/vlad/ScalacPlugin.jar Announcement: Requires Java 1.5 Requires jEdit 04.03.07.00 Required plugins: console.ConsolePlugin 4.3.8 errorlist.ErrorListPlugin 1.7 Short Description: Scala Plugin for compilation of Scala files inside the editor without invoking external scalac compiler Long Description: <html> The ScalacPlugin is embedded Scala compiler that runs inside jEdit's JVM which results in faster compilation times because no external jvm is called. It is integrated with Console and ErrorList plugins to handle output and error navigation. </html> }}} ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=625093&aid=2798882&group_id=588 |
|
From: SourceForge.net <no...@so...> - 2009-05-30 16:39:09
|
Plugin Central Submission item #2798882, was opened at 2009-05-30 16:39 Message generated for change (Tracker Item Submitted) made by seryakov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=625093&aid=2798882&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: Vlad Seryakov (seryakov) Assigned to: Nobody/Anonymous (nobody) Summary: Scala embedded compiler plugin Initial Comment: {{{ Scalac 1.0.0 Source: Source code is in SVN svn://www.crystalballinc.com/Scalac Binary: ftp://www.crystalballinc.com/pub/vlad/ScalacPlugin.jar Announcement: Requires Java 1.5 Requires jEdit 04.03.07.00 Required plugins: console.ConsolePlugin 4.3.8 errorlist.ErrorListPlugin 1.7 Short Description: Scala Plugin for compilation of Scala files inside the editor without invoking external scalac compiler Long Description: <html> The ScalacPlugin is embedded Scala compiler that runs inside jEdit's JVM which results in faster compilation times because no external jvm is called. It is integrated with Console and ErrorList plugins to handle output and error navigation. </html> }}} ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=625093&aid=2798882&group_id=588 |
|
From: SourceForge.net <no...@so...> - 2009-05-30 03:16:09
|
Bugs item #2798694, was opened at 2009-05-29 22:16 Message generated for change (Tracker Item Submitted) made by kevinmoore63 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2798694&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: macros Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kevin Moore (kevinmoore63) Assigned to: John Gellene (jgellene) Summary: NullPointerException when use macro, Open Selection Initial Comment: When running under xp, , highlight a valid file path and name, use a keyboard shortcut for file macro, Open Selection, I get the below error. Note, the file is opened successfully. Kevin Moore java.lang.NullPointerException at org.gjt.sp.jedit.buffer.JEditBuffer.markTokens(JEditBuffer.java:1304) at org.gjt.sp.jedit.textarea.ChunkCache.lineToChunkList(ChunkCache.java:782) at org.gjt.sp.jedit.textarea.ChunkCache.updateChunksUpTo(ChunkCache.java:659) at org.gjt.sp.jedit.textarea.ChunkCache.getLineInfo(ChunkCache.java:256) at org.gjt.sp.jedit.textarea.ChunkCache.getScreenLineOfOffset(ChunkCache.java:84) at org.gjt.sp.jedit.textarea.TextArea._finishCaretUpdate(TextArea.java:4876) at org.gjt.sp.jedit.textarea.BufferHandler.transactionComplete(BufferHandler.java:338) at org.gjt.sp.jedit.buffer.JEditBuffer.fireTransactionComplete(JEditBuffer.java:2352) at org.gjt.sp.jedit.buffer.JEditBuffer.endCompoundEdit(JEditBuffer.java:2105) at org.gjt.sp.jedit.Macros$Macro.invoke(Macros.java:446) at org.gjt.sp.jedit.gui.InputHandler.invokeAction(InputHandler.java:352) at org.gjt.sp.jedit.gui.InputHandler.invokeAction(InputHandler.java:317) at org.gjt.sp.jedit.gui.DefaultInputHandler.handleKey(DefaultInputHandler.java:197) 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:4545) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.KeyboardFocusManager.redispatchEvent(Unknown Source) at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(Unknown Source) at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(Unknown Source) at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(Unknown Source) at java.awt.DefaultKeyboardFocusManager.dispatchEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Window.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.EventQueue.dispatchEvent(Unknown Source) at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.run(Unknown Source) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2798694&group_id=588 |
|
From: Romain F. <rom...@db...> - 2009-05-29 14:41:24
|
Alan Ezust wrote: > I was planning on adding something like that to the ssh console but > never got around to it. I thought that perhaps "jcterm" would have > some code I could reuse, which is why I added it to the svn repo of > sshconsole. > If you've done it already for another console, chances are you've > solved some problems i have not even thought about. Great. I'll play with this and send you some more concrete proposal. > But keep in mind, console also has to parse the output for errorList also. As long as the output does not contain escape sequences, the behaviour would be the same. For the moment, the plan only includes foreground and background escape sequences. > --alan > > > > On Fri, May 29, 2009 at 3:05 AM, Romain Francois > <rom...@db... <mailto:rom...@db...>> wrote: > > Thinking this through, it could be an opportunity to use jedit's text > area in the console, which would give extra features like folding of > commands, ... > > Romain Francois wrote: > > Hello, > > > > I would like to add support for colors in the console plugin by > > supporting escape sequences patterns, such as xterm [1]. > > > > Currently, printing goes go a JTextPane. I propose to extend this so > > that a specific class (extending JTextPane) is used and takes > care of > > the printing. This could retrieve implementations through the > service > > mechanism, and I would expect the default implementation to > reflect the > > current behaviour, but additional implementations could implement > > recognition of escape sequences. > > > > I have already done it for another project's console [2] and > would like > > to port this to jedit. > > > > Romain > > > > [1] http://frexx.de/xterm-256-notes/ > > [2] > > > http://romainfrancois.blog.free.fr/index.php?post/2009/05/28/xterm256-support-in-biocep > > > > -- > Romain Francois > Independent R Consultant > +33(0) 6 28 91 30 30 > http://romainfrancois.blog.free.fr > > > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity > professionals. Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp as they present alongside digital heavyweights like > Barbarian > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com > -- > ----------------------------------------------- > jEdit Developers' List > jEd...@li... > <mailto:jEd...@li...> > https://lists.sourceforge.net/lists/listinfo/jedit-devel > > -- Romain Francois Independent R Consultant +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr |
|
From: Alan E. <ala...@gm...> - 2009-05-29 14:27:09
|
I was planning on adding something like that to the ssh console but never got around to it. I thought that perhaps "jcterm" would have some code I could reuse, which is why I added it to the svn repo of sshconsole. If you've done it already for another console, chances are you've solved some problems i have not even thought about. But keep in mind, console also has to parse the output for errorList also. --alan On Fri, May 29, 2009 at 3:05 AM, Romain Francois <rom...@db... > wrote: > Thinking this through, it could be an opportunity to use jedit's text > area in the console, which would give extra features like folding of > commands, ... > > Romain Francois wrote: > > Hello, > > > > I would like to add support for colors in the console plugin by > > supporting escape sequences patterns, such as xterm [1]. > > > > Currently, printing goes go a JTextPane. I propose to extend this so > > that a specific class (extending JTextPane) is used and takes care of > > the printing. This could retrieve implementations through the service > > mechanism, and I would expect the default implementation to reflect the > > current behaviour, but additional implementations could implement > > recognition of escape sequences. > > > > I have already done it for another project's console [2] and would like > > to port this to jedit. > > > > Romain > > > > [1] http://frexx.de/xterm-256-notes/ > > [2] > > > http://romainfrancois.blog.free.fr/index.php?post/2009/05/28/xterm256-support-in-biocep > > > > -- > Romain Francois > Independent R Consultant > +33(0) 6 28 91 30 30 > http://romainfrancois.blog.free.fr > > > > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. > Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp as they present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com > -- > ----------------------------------------------- > jEdit Developers' List > jEd...@li... > https://lists.sourceforge.net/lists/listinfo/jedit-devel > |
|
From: Romain F. <rom...@db...> - 2009-05-29 10:06:33
|
Thinking this through, it could be an opportunity to use jedit's text area in the console, which would give extra features like folding of commands, ... Romain Francois wrote: > Hello, > > I would like to add support for colors in the console plugin by > supporting escape sequences patterns, such as xterm [1]. > > Currently, printing goes go a JTextPane. I propose to extend this so > that a specific class (extending JTextPane) is used and takes care of > the printing. This could retrieve implementations through the service > mechanism, and I would expect the default implementation to reflect the > current behaviour, but additional implementations could implement > recognition of escape sequences. > > I have already done it for another project's console [2] and would like > to port this to jedit. > > Romain > > [1] http://frexx.de/xterm-256-notes/ > [2] > http://romainfrancois.blog.free.fr/index.php?post/2009/05/28/xterm256-support-in-biocep > -- Romain Francois Independent R Consultant +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr |
|
From: Romain F. <rom...@db...> - 2009-05-29 09:07:13
|
Hello, I would like to add support for colors in the console plugin by supporting escape sequences patterns, such as xterm [1]. Currently, printing goes go a JTextPane. I propose to extend this so that a specific class (extending JTextPane) is used and takes care of the printing. This could retrieve implementations through the service mechanism, and I would expect the default implementation to reflect the current behaviour, but additional implementations could implement recognition of escape sequences. I have already done it for another project's console [2] and would like to port this to jedit. Romain [1] http://frexx.de/xterm-256-notes/ [2] http://romainfrancois.blog.free.fr/index.php?post/2009/05/28/xterm256-support-in-biocep -- Romain Francois Independent R Consultant +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr |
|
From: SourceForge.net <no...@so...> - 2009-05-28 23:17:47
|
Patches item #2570229, was opened at 2009-02-06 08:02 Message generated for change (Comment added) made by k_satoda You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300588&aid=2570229&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: docs Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Matthew Gilbert (voxmea) >Assigned to: Kazutoshi Satoda (k_satoda) Summary: Adds description of new word complete option Initial Comment: Adds description of new word complete option that enables search all open buffers for completions. ---------------------------------------------------------------------- >Comment By: Kazutoshi Satoda (k_satoda) Date: 2009-05-29 08:17 Message: Committed in r15360 with the actual code change (patch #2569381). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300588&aid=2570229&group_id=588 |
|
From: SourceForge.net <no...@so...> - 2009-05-28 23:17:36
|
Patches item #2569381, was opened at 2009-02-06 04:03 Message generated for change (Settings changed) made by k_satoda You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300588&aid=2569381&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: texteditor Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Matthew Gilbert (voxmea) Assigned to: Kazutoshi Satoda (k_satoda) Summary: Adds option to search all open buffers to complete word Initial Comment: Adds option to search all open buffers to build the completion list. My guess was that the TextArea options pane was the most logical place for the option, but I'm open to suggestions. ---------------------------------------------------------------------- >Comment By: Kazutoshi Satoda (k_satoda) Date: 2009-05-29 08:17 Message: Very sorry for long delay. Committed in r15360 with the small fixes in my previous comment, and the doc update (patch #2570229). ---------------------------------------------------------------------- Comment By: Seph M. Soliman (scarlac) Date: 2009-05-27 18:26 Message: +1 for this feature ---------------------------------------------------------------------- Comment By: Matthew Gilbert (voxmea) Date: 2009-05-27 03:35 Message: I've been using this change for many months now and have not once noticed a performance consequence (again with many open buffers). Another request to have this committed. Thanks! _matt ---------------------------------------------------------------------- Comment By: Matthew Gilbert (voxmea) Date: 2009-03-14 01:23 Message: I've been using this patch for a while now with a large number of buffers open (> 50 frequently) and found no noticeable performance penalty. Any chance getting this committed? Thanks ---------------------------------------------------------------------- Comment By: Matthew Gilbert (voxmea) Date: 2009-02-06 07:04 Message: Sorry about the copy-paste errors. Thanks for fixing. I'll submit another patch with updated docs. ---------------------------------------------------------------------- Comment By: Kazutoshi Satoda (k_satoda) Date: 2009-02-06 06:43 Message: Thank you for quick fix. I'll replace my change with this patch, and start testing in real work. Some small issues: - The explicit fold for getVisibleBuffers() lacks the end. - The overrided visit(EditPane) can be reduced to just one line. buffers.add(editPane.getBuffer()); HashSet avoids duplicates by itself. ... and, it'll be perfect if you update the docs. I found the corresponding section in doc/users-guide/text-edit.xml. ---------------------------------------------------------------------- Comment By: Matthew Gilbert (voxmea) Date: 2009-02-06 05:59 Message: Thanks for the suggestions. I believe this fixes everything. As for performance... the option defaults to off. I could add some documentation on the option with a warning that this could impact performance with a large number of buffers open. File Added: complete_word_2.diff ---------------------------------------------------------------------- Comment By: Kazutoshi Satoda (k_satoda) Date: 2009-02-06 05:08 Message: Great. I have had a local change which just replaces the behavior to use all buffers for almost a year. The reason not having submitted it as a patch was because I'm not sure about possible performance problem, and if there really is such problem, it may require a new option, which I feel difficult to craft. As for your patch, I have some suggestion. I hate code duplication, really. Instead of duplicating the code, I suggest like the following: Collection<Buffer> sourceBuffers = jEdit.getBooleanProperty("completeFromAllBuffers") ? Arrays.asList(jEdit.getBuffers()) : getVisibleBuffers(); for (Buffer b: sourceBuffers) ... The method getVisibleBuffers() is a new private method which returns Set<Buffer> buffers in the current code. java.util.Arrays is used without import. I know this has no problems, but importing it is more convetional. Added log "visting buffer ..." seems unnecessary. The "return;" after "if(buffers.contains(b))" is mis-indented. But these lines will be removed if the first suggestion is applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300588&aid=2569381&group_id=588 |
|
From: Xavier C. <fen...@ya...> - 2009-05-28 14:27:23
|
Hi, I'm developing a commercial application which has a swing based administration console. While looking for an editor component which supports syntax highlighting, JEdit's new embeddable textarea package came to notice. After some testing, we found it perfectly suitable for our purpose - it supports all the syntax modes we currently need, has compact size to be deployed with JNLP, and very well designed API to program with. Only problem was that it follows the same license with the rest of the JEdit components. And as it's not viable for us to distribute our client source code under GPL, we're stuck right before we could start. I've found there's an older (and maybe unmaintained?) package called jedit syntax which was released under MIT license. If the intention behind the new build-textarea target was to promote embeded use of JEdit in other applications, maybe dual licensing of textarea package or the jar file under more unrestrictive license like LGPL would be better achieving its cause? It seems I'm not the only one struck with this problem, as I found these posts in the archive : http://sourceforge.net/mailarchive/message.php?msg_id=642d62060809031112i34e7ac24h764c5a7871dd3b31%40mail.gmail.com http://sourceforge.net/mailarchive/message.php?msg_id=b9a02fc0807171919y1d62200dk1d3f42b7a1a54187%40mail.gmail.com Thanks! Xavier |
|
From: SourceForge.net <no...@so...> - 2009-05-27 16:20:14
|
Bugs item #2797321, was opened at 2009-05-27 04:32 Message generated for change (Comment added) made by daleanson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2797321&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: documentation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jakub Holý (malyvelky) Assigned to: Nobody/Anonymous (nobody) Summary: Appendices not listed in Help contents Initial Comment: The Help of jEdit is nice but its Contents doesn't list the appendices. Thus whenever I want to go to "Appendix E. Regular Expressions" I have to use Search to get it. ---------------------------------------------------------------------- >Comment By: Dale Anson (daleanson) Date: 2009-05-27 10:20 Message: You can find them on the "Contents" tab. They are under "jEdit 4.3 User's Guide". They don't specifically say "Appendix" in the tree, but all 5 are listed: Keyboard Shortcuts, The Activity Log, History Text Fields, Glob Patterns, and Regular Expressions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2797321&group_id=588 |
|
From: SourceForge.net <no...@so...> - 2009-05-27 14:59:32
|
Plugin Central Submission item #2797421, was opened at 2009-05-27 18:59 Message generated for change (Tracker Item Submitted) made by leshij You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=625093&aid=2797421&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: Denis Dzenskevich (leshij) Assigned to: Nobody/Anonymous (nobody) Summary: ElementMatcher 0.1 Initial Comment: {{{ ElementMatcher 0.1 Source: Source code is in SVN: https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/ElementMatcher/tags/release-0.1 Announcement: Requires Java 1.6 Requires jEdit 04.03.16.00 Required plugins: CommonControlsPlugin 0.9.5 Short Description: Hyperlinks, emails, filenames and other text fragments recognizer Long Description: <html> <body> <h1>ElementMatcher plugin</h1> Plugin allows highlighting and executing actions on various text fragments (elements) like hyperlinks, filenames and so on. Currently supported elements are hyperlinks, email addresses, file and directory names (for now only absolute pathnames on Windows), RFC numbers and XML scheme URNs. Functionality is somewhat interleaves with "Hyperlinks" plugin, however, the latter highlights links only when you point on it and does not parse entire files. </body> </html> }}} ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=625093&aid=2797421&group_id=588 |
|
From: SourceForge.net <no...@so...> - 2009-05-27 10:32:49
|
Bugs item #2797321, was opened at 2009-05-27 10:32 Message generated for change (Tracker Item Submitted) made by malyvelky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2797321&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: documentation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jakub Holý (malyvelky) Assigned to: Nobody/Anonymous (nobody) Summary: Appendices not listed in Help contents Initial Comment: The Help of jEdit is nice but its Contents doesn't list the appendices. Thus whenever I want to go to "Appendix E. Regular Expressions" I have to use Search to get it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2797321&group_id=588 |
|
From: SourceForge.net <no...@so...> - 2009-05-27 09:26:09
|
Patches item #2569381, was opened at 2009-02-05 20:03 Message generated for change (Comment added) made by scarlac You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300588&aid=2569381&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: texteditor Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthew Gilbert (voxmea) Assigned to: Kazutoshi Satoda (k_satoda) Summary: Adds option to search all open buffers to complete word Initial Comment: Adds option to search all open buffers to build the completion list. My guess was that the TextArea options pane was the most logical place for the option, but I'm open to suggestions. ---------------------------------------------------------------------- Comment By: Seph M. Soliman (scarlac) Date: 2009-05-27 11:26 Message: +1 for this feature ---------------------------------------------------------------------- Comment By: Matthew Gilbert (voxmea) Date: 2009-05-26 20:35 Message: I've been using this change for many months now and have not once noticed a performance consequence (again with many open buffers). Another request to have this committed. Thanks! _matt ---------------------------------------------------------------------- Comment By: Matthew Gilbert (voxmea) Date: 2009-03-13 17:23 Message: I've been using this patch for a while now with a large number of buffers open (> 50 frequently) and found no noticeable performance penalty. Any chance getting this committed? Thanks ---------------------------------------------------------------------- Comment By: Matthew Gilbert (voxmea) Date: 2009-02-05 23:04 Message: Sorry about the copy-paste errors. Thanks for fixing. I'll submit another patch with updated docs. ---------------------------------------------------------------------- Comment By: Kazutoshi Satoda (k_satoda) Date: 2009-02-05 22:43 Message: Thank you for quick fix. I'll replace my change with this patch, and start testing in real work. Some small issues: - The explicit fold for getVisibleBuffers() lacks the end. - The overrided visit(EditPane) can be reduced to just one line. buffers.add(editPane.getBuffer()); HashSet avoids duplicates by itself. ... and, it'll be perfect if you update the docs. I found the corresponding section in doc/users-guide/text-edit.xml. ---------------------------------------------------------------------- Comment By: Matthew Gilbert (voxmea) Date: 2009-02-05 21:59 Message: Thanks for the suggestions. I believe this fixes everything. As for performance... the option defaults to off. I could add some documentation on the option with a warning that this could impact performance with a large number of buffers open. File Added: complete_word_2.diff ---------------------------------------------------------------------- Comment By: Kazutoshi Satoda (k_satoda) Date: 2009-02-05 21:08 Message: Great. I have had a local change which just replaces the behavior to use all buffers for almost a year. The reason not having submitted it as a patch was because I'm not sure about possible performance problem, and if there really is such problem, it may require a new option, which I feel difficult to craft. As for your patch, I have some suggestion. I hate code duplication, really. Instead of duplicating the code, I suggest like the following: Collection<Buffer> sourceBuffers = jEdit.getBooleanProperty("completeFromAllBuffers") ? Arrays.asList(jEdit.getBuffers()) : getVisibleBuffers(); for (Buffer b: sourceBuffers) ... The method getVisibleBuffers() is a new private method which returns Set<Buffer> buffers in the current code. java.util.Arrays is used without import. I know this has no problems, but importing it is more convetional. Added log "visting buffer ..." seems unnecessary. The "return;" after "if(buffers.contains(b))" is mis-indented. But these lines will be removed if the first suggestion is applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300588&aid=2569381&group_id=588 |
|
From: SourceForge.net <no...@so...> - 2009-05-26 21:53:23
|
Patches item #2569381, was opened at 2009-02-05 14:03 Message generated for change (Settings changed) made by voxmea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300588&aid=2569381&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: texteditor Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthew Gilbert (voxmea) >Assigned to: Kazutoshi Satoda (k_satoda) Summary: Adds option to search all open buffers to complete word Initial Comment: Adds option to search all open buffers to build the completion list. My guess was that the TextArea options pane was the most logical place for the option, but I'm open to suggestions. ---------------------------------------------------------------------- Comment By: Matthew Gilbert (voxmea) Date: 2009-05-26 14:35 Message: I've been using this change for many months now and have not once noticed a performance consequence (again with many open buffers). Another request to have this committed. Thanks! _matt ---------------------------------------------------------------------- Comment By: Matthew Gilbert (voxmea) Date: 2009-03-13 12:23 Message: I've been using this patch for a while now with a large number of buffers open (> 50 frequently) and found no noticeable performance penalty. Any chance getting this committed? Thanks ---------------------------------------------------------------------- Comment By: Matthew Gilbert (voxmea) Date: 2009-02-05 17:04 Message: Sorry about the copy-paste errors. Thanks for fixing. I'll submit another patch with updated docs. ---------------------------------------------------------------------- Comment By: Kazutoshi Satoda (k_satoda) Date: 2009-02-05 16:43 Message: Thank you for quick fix. I'll replace my change with this patch, and start testing in real work. Some small issues: - The explicit fold for getVisibleBuffers() lacks the end. - The overrided visit(EditPane) can be reduced to just one line. buffers.add(editPane.getBuffer()); HashSet avoids duplicates by itself. ... and, it'll be perfect if you update the docs. I found the corresponding section in doc/users-guide/text-edit.xml. ---------------------------------------------------------------------- Comment By: Matthew Gilbert (voxmea) Date: 2009-02-05 15:59 Message: Thanks for the suggestions. I believe this fixes everything. As for performance... the option defaults to off. I could add some documentation on the option with a warning that this could impact performance with a large number of buffers open. File Added: complete_word_2.diff ---------------------------------------------------------------------- Comment By: Kazutoshi Satoda (k_satoda) Date: 2009-02-05 15:08 Message: Great. I have had a local change which just replaces the behavior to use all buffers for almost a year. The reason not having submitted it as a patch was because I'm not sure about possible performance problem, and if there really is such problem, it may require a new option, which I feel difficult to craft. As for your patch, I have some suggestion. I hate code duplication, really. Instead of duplicating the code, I suggest like the following: Collection<Buffer> sourceBuffers = jEdit.getBooleanProperty("completeFromAllBuffers") ? Arrays.asList(jEdit.getBuffers()) : getVisibleBuffers(); for (Buffer b: sourceBuffers) ... The method getVisibleBuffers() is a new private method which returns Set<Buffer> buffers in the current code. java.util.Arrays is used without import. I know this has no problems, but importing it is more convetional. Added log "visting buffer ..." seems unnecessary. The "return;" after "if(buffers.contains(b))" is mis-indented. But these lines will be removed if the first suggestion is applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300588&aid=2569381&group_id=588 |
|
From: SourceForge.net <no...@so...> - 2009-05-26 19:42:09
|
Patches item #2569381, was opened at 2009-02-05 14:03 Message generated for change (Comment added) made by voxmea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300588&aid=2569381&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: texteditor Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthew Gilbert (voxmea) Assigned to: Nobody/Anonymous (nobody) Summary: Adds option to search all open buffers to complete word Initial Comment: Adds option to search all open buffers to build the completion list. My guess was that the TextArea options pane was the most logical place for the option, but I'm open to suggestions. ---------------------------------------------------------------------- Comment By: Matthew Gilbert (voxmea) Date: 2009-05-26 14:35 Message: I've been using this change for many months now and have not once noticed a performance consequence (again with many open buffers). Another request to have this committed. Thanks! _matt ---------------------------------------------------------------------- Comment By: Matthew Gilbert (voxmea) Date: 2009-03-13 12:23 Message: I've been using this patch for a while now with a large number of buffers open (> 50 frequently) and found no noticeable performance penalty. Any chance getting this committed? Thanks ---------------------------------------------------------------------- Comment By: Matthew Gilbert (voxmea) Date: 2009-02-05 17:04 Message: Sorry about the copy-paste errors. Thanks for fixing. I'll submit another patch with updated docs. ---------------------------------------------------------------------- Comment By: Kazutoshi Satoda (k_satoda) Date: 2009-02-05 16:43 Message: Thank you for quick fix. I'll replace my change with this patch, and start testing in real work. Some small issues: - The explicit fold for getVisibleBuffers() lacks the end. - The overrided visit(EditPane) can be reduced to just one line. buffers.add(editPane.getBuffer()); HashSet avoids duplicates by itself. ... and, it'll be perfect if you update the docs. I found the corresponding section in doc/users-guide/text-edit.xml. ---------------------------------------------------------------------- Comment By: Matthew Gilbert (voxmea) Date: 2009-02-05 15:59 Message: Thanks for the suggestions. I believe this fixes everything. As for performance... the option defaults to off. I could add some documentation on the option with a warning that this could impact performance with a large number of buffers open. File Added: complete_word_2.diff ---------------------------------------------------------------------- Comment By: Kazutoshi Satoda (k_satoda) Date: 2009-02-05 15:08 Message: Great. I have had a local change which just replaces the behavior to use all buffers for almost a year. The reason not having submitted it as a patch was because I'm not sure about possible performance problem, and if there really is such problem, it may require a new option, which I feel difficult to craft. As for your patch, I have some suggestion. I hate code duplication, really. Instead of duplicating the code, I suggest like the following: Collection<Buffer> sourceBuffers = jEdit.getBooleanProperty("completeFromAllBuffers") ? Arrays.asList(jEdit.getBuffers()) : getVisibleBuffers(); for (Buffer b: sourceBuffers) ... The method getVisibleBuffers() is a new private method which returns Set<Buffer> buffers in the current code. java.util.Arrays is used without import. I know this has no problems, but importing it is more convetional. Added log "visting buffer ..." seems unnecessary. The "return;" after "if(buffers.contains(b))" is mis-indented. But these lines will be removed if the first suggestion is applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300588&aid=2569381&group_id=588 |
|
From: SourceForge.net <no...@so...> - 2009-05-26 18:02:24
|
Bugs item #2796976, was opened at 2009-05-26 18:01 Message generated for change (Tracker Item Submitted) made by seryakov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2796976&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: None Priority: 5 Private: No Submitted By: Vlad Seryakov (seryakov) Assigned to: Nobody/Anonymous (nobody) Summary: X11 geometry does not restore Initial Comment: It used to work in pre16, but in pre17 every time i start jedit, it resize to 917x720 despite the fact that view.width and view.height in properties are saved from previous session ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2796976&group_id=588 |
|
From: SourceForge.net <no...@so...> - 2009-05-26 17:32:45
|
Patches item #2796960, was opened at 2009-05-26 17:32 Message generated for change (Tracker Item Submitted) made by seryakov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300588&aid=2796960&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: texteditor Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Vlad Seryakov (seryakov) Assigned to: Nobody/Anonymous (nobody) Summary: X11 WMCLASS Initial Comment: To set X11 window class to jedit which will make it more window manager friendly // Set X11 WMCLASS to some meaningful value if (OperatingSystem.isX11()) { try { Toolkit xToolkit = Toolkit.getDefaultToolkit(); java.lang.reflect.Field awtAppClassNameField = xToolkit.getClass().getDeclaredField("awtAppClassName"); awtAppClassNameField.setAccessible(true); awtAppClassNameField.set(xToolkit, System.getProperty("x11.class", "jedit")); } catch(Exception e) { System.err.println("error setting WMCLASS"); e.printStackTrace(); } } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300588&aid=2796960&group_id=588 |
|
From: Dale A. <da...@gr...> - 2009-05-25 19:06:41
|
Just a side note, the Copy/Paste Detector is included with the PMD plugin, so you can run this from within jEdit rather than as an external tool. Dale Kazutoshi Satoda wrote: > FYI, running PMD's Copy/Paste Detector (CPD) on jEdit core gives many > more code duplications to hunt. > http://pmd.sourceforge.net/cpd.html > > |
|
From: Vadim V. <vad...@gm...> - 2009-05-23 10:02:24
|
Kazutoshi, >> Thus, please be conservative, at first. Ok, i`ve got the main idea. Thanks. -- Voituk Vadim vad...@gm... ICQ#944328 Skype: voituk On Fri, May 22, 2009 at 22:00, Kazutoshi Satoda <k_s...@f2...> wrote: > Thus, please be conservative, at first. |
|
From: SourceForge.net <no...@so...> - 2009-05-22 22:37:18
|
Bugs item #2795635, was opened at 2009-05-22 17:37 Message generated for change (Tracker Item Submitted) made by mcswell You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2795635&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: keyboard / mouse Group: minor bug Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mike Maxwell (mcswell) Assigned to: Nobody/Anonymous (nobody) Summary: Alt key in Windows Initial Comment: Alt key behavior under Windows (at least XP, Vista) does not match the behavior of the Alt key in other Windows applications. In particular, if the cursor is in the text are, then pressing and releasing the Alt key (without typing any other key) should, but does not, put the focus on the menu bar. Once the focus is in the menu bar, if you then type an F, E, S, M, O, V, M, P or H--i.e. the underlined letters for each of the main menu options--that menu should drop down. Typing any other key when the focus is in the menu bar should return the focus to the text area, without any action (in particular, the typed key should not be inserted into the text; maybe it should beep at you). This should not break any other current behavior of jEdit. For example, pressing the Alt key and typing F, then releasing the Alt key (and the F key) should also put you into the File menu. It should also not interfere with any shortcuts the user may have defined that use Alt keys. I.e. the focus-the-menu should happen *only* when the Alt key is pressed and released with no other intermediate action. See also the thread in the mailing list dated 22 May 2009 entitled "Alt key". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2795635&group_id=588 |
|
From: Kazutoshi S. <k_s...@f2...> - 2009-05-22 19:00:41
|
Vadim Voituk wrote: > Ok, i`ll remove this code duplication - will replace this code > duplication itself, by replacing with delegation. > I like code optimizations and refactoring too ;) > And i`ll be glad to participate in jEdit Core development. Thanks. I'm looking forward to your good work. FYI, running PMD's Copy/Paste Detector (CPD) on jEdit core gives many more code duplications to hunt. http://pmd.sourceforge.net/cpd.html > Is there any way to perform the full-text search among all jEdit code > (core/trunk+plugins/trunk+etc)? I don't know, except checking out (or exporting) them from the repository, which you probably know and don't want to do. > It`ll be very usefull to see what plugins/macros are use the > particular method/class/etc. > Also i`ll help us a lot to separate "core code" and "plugin API code" > (do remember this discussion?) I think you should not rely on the actual use of method/class/etc to determine which one should be kept. All non-private method/class/etc should be kept since it can be used in some private macros or plugins which are not published. Thus, please be conservative, at first. If you find some breaking change is worth doing, I think you should consult on jedit-devel first. -- k_satoda |
|
From: Dale A. <da...@gr...> - 2009-05-21 22:16:35
|
You can check out many plugins from the jEdit svn repository, but not all plugins keep their code there. There are still some older, but still valid, plugins in jEdit's cvs repository, and there are other plugins that keep their code in other completely separate repositories. So you can probably get the code for many, perhaps even most, plugins, but probably not all of them without some work. Dale On Thu, May 21, 2009 at 2:45 PM, Vadim Voituk <vad...@gm...>wrote: > Hi, Kazutoshi > > Ok, i`ll remove this code duplication - will replace this code > duplication itself, by replacing with delegation. > I like code optimizations and refactoring too ;) > And i`ll be glad to participate in jEdit Core development. > > Is there any way to perform the full-text search among all jEdit code > (core/trunk+plugins/trunk+etc)? > It`ll be very usefull to see what plugins/macros are use the > particular method/class/etc. > Also i`ll help us a lot to separate "core code" and "plugin API code" > (do remember this discussion?) > > -- > Voituk Vadim > > > On Wed, May 20, 2009 at 21:42, Kazutoshi Satoda <k_s...@f2...> > wrote: > > Vadim Voituk wrote: > >> > >> I`ve noticed a code duplication in jEdit core (see below) > >> > >> I think it`lll be better to leave org.gjt.sp.util.StringList > >> implementation only, and replace the org.gjt.sp.jedit.TextUtils with > >> delegation. > > > > Thank you for pointing this out. I love eliminating code duplication. > > > > Since you could commit r15316 to jEdit/trunk, could you please try this > > by yourself as well? > > > > The way will be, actual code change, building it, testing it, verifying > > the diff, and writing a good log message. > > > > I'm glad if you are interested in becoming a new core developer. We need > > many more helps. > > -- > > k_satoda > > > > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. > Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://www.creativitycat.com > -- > ----------------------------------------------- > jEdit Developers' List > jEd...@li... > https://lists.sourceforge.net/lists/listinfo/jedit-devel > |
|
From: Vadim V. <vad...@gm...> - 2009-05-21 20:45:14
|
Hi, Kazutoshi Ok, i`ll remove this code duplication - will replace this code duplication itself, by replacing with delegation. I like code optimizations and refactoring too ;) And i`ll be glad to participate in jEdit Core development. Is there any way to perform the full-text search among all jEdit code (core/trunk+plugins/trunk+etc)? It`ll be very usefull to see what plugins/macros are use the particular method/class/etc. Also i`ll help us a lot to separate "core code" and "plugin API code" (do remember this discussion?) -- Voituk Vadim On Wed, May 20, 2009 at 21:42, Kazutoshi Satoda <k_s...@f2...> wrote: > Vadim Voituk wrote: >> >> I`ve noticed a code duplication in jEdit core (see below) >> >> I think it`lll be better to leave org.gjt.sp.util.StringList >> implementation only, and replace the org.gjt.sp.jedit.TextUtils with >> delegation. > > Thank you for pointing this out. I love eliminating code duplication. > > Since you could commit r15316 to jEdit/trunk, could you please try this > by yourself as well? > > The way will be, actual code change, building it, testing it, verifying > the diff, and writing a good log message. > > I'm glad if you are interested in becoming a new core developer. We need > many more helps. > -- > k_satoda > |