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: <na...@rv...> - 2000-04-18 00:53:32
|
I have noticed that in jedit 2.4pre6 there is a problem with buffertabs not updating the untitled buffers to the new name once saved. jedit 2.4pre6 jdk1.2.2 win98 --------------------------------------------------------- "Clothes make the man, naked people have little or no influence on society" --Mark Twain-- Nathan Tenney Computer Specialist K-SAR Video Productions Utah State University na...@rv... |
From: mike d. <md...@st...> - 2000-04-17 02:32:06
|
On Mon, 17 Apr 2000, Slava Pestov wrote: > I probably forgot to include the manifest. Dammit. no, it executed, but it hung at some point during the Swing initialization. maybe it's a JDK problem (Blackdown 1.2.2 rc4) -md |
From: Slava P. <sp...@gj...> - 2000-04-17 02:29:59
|
mike dillon wrote: > i just installed 2.4pre6 from the installer and i had a number of > problems: > > 1) it would not install as an executable JAR. i had to use 'java > -classpath ... install'. I probably forgot to include the manifest. Dammit. > 2) i chose to install without the Firewall plugin, but the Firewall source > code was still installed. That's cos the firewall sources are part of the jedit-source fileset. I'll move them to a jedit-firewall-source fileset. Slava |
From: mike d. <md...@st...> - 2000-04-16 18:09:47
|
hi- i just installed 2.4pre6 from the installer and i had a number of problems: 1) it would not install as an executable JAR. i had to use 'java -classpath ... install'. 2) i chose to install without the Firewall plugin, but the Firewall source code was still installed. -md |
From: mike d. <md...@st...> - 2000-04-16 06:05:50
|
On Sun, 16 Apr 2000, Slava Pestov wrote: > The options dialog box takes an unacceptably long time to load. > I think it can be made much faster if option panes are created > lazily when they are first selected in the tree, not all at once. > This could be accomplished with an 'init' method in the OptionPane > interface that is called the first time an option pane is > selected. > > Do you guys think this is a good idea? yes. this is a good idea. i was thinking about it myself. the size of the option panes might be a problem, but all similar GUIs i've seen solve the problem by simply resizing on siwtch if the chosen pane has a preferred size larger than the current pane area. -md |
From: Slava P. <sp...@gj...> - 2000-04-16 05:49:23
|
Hello everybody, The options dialog box takes an unacceptably long time to load. I think it can be made much faster if option panes are created lazily when they are first selected in the tree, not all at once. This could be accomplished with an 'init' method in the OptionPane interface that is called the first time an option pane is selected. Do you guys think this is a good idea? Slava |
From: <rma...@ie...> - 2000-04-16 05:20:15
|
** Reply to message from Slava Pestov <sp...@gj...> on Sun, 16 Apr 2000 14:38:10 +1000 > Robert Mahoney wrote: > > > > Whoa, you guys are just too fast to keep up with. I've been modifying the > > next_page and prev_page functions to allow scrolling to cursor and before I can > > even get to the prev_page function, you release pre5! Talk about a moving > > target! > > Well, unfortunately you're going to have to change your code again after pre6 > is released, since I've moved the actions out of InputHandler and into the > org.gjt.sp.jedit.actions package. Doh! I'll wait until that is released before I send you the code. > > > This change adds a checkbox on the Editor option pane and modifies the > > following files: > > Why a checkbox? Do you really think people might want to disable this? I just figured to do that to be on the safe side in case people liked the old way of paging. > > > Hopefully I'll get the time to finish it in the next couple of days. What is > > the proper format for the changes and to whom do I send it? > > Send me a unified diff. If you don't know what a unified diff, just send me > the changed files. I don't know what a unified diff is, but I am willing to learn! Bob -- Please note new email addr and change any references of rma...@ne... to rma...@ie... |
From: Jason G. <jg...@cs...> - 2000-04-16 05:14:20
|
> > CodeAid 0.2.5 uses EditBus Error framework. > So you will get highlighted errors. > Thanks, Andre, for maintaining and improving this tool! > > Unfortunately, many of these are actually not errors (it was worse > before though)! I've already corrected a few bugs concerning error > reporting but there's still a lot of work. > I must admit that the error reporting as I left it was pretty shoddy. The main focus for me was the code completion part of it. The error reporting at the time was really just ment to be a kind of proof-of-concept. Keep up the good work! -Jason |
From: Slava P. <sp...@gj...> - 2000-04-16 04:41:42
|
Robert Mahoney wrote: > > Whoa, you guys are just too fast to keep up with. I've been modifying the > next_page and prev_page functions to allow scrolling to cursor and before I can > even get to the prev_page function, you release pre5! Talk about a moving > target! Well, unfortunately you're going to have to change your code again after pre6 is released, since I've moved the actions out of InputHandler and into the org.gjt.sp.jedit.actions package. > This change adds a checkbox on the Editor option pane and modifies the > following files: Why a checkbox? Do you really think people might want to disable this? > Hopefully I'll get the time to finish it in the next couple of days. What is > the proper format for the changes and to whom do I send it? Send me a unified diff. If you don't know what a unified diff, just send me the changed files. Slava |
From: Slava P. <sp...@gj...> - 2000-04-16 04:39:47
|
Andre Kaplan wrote: > I wanted to ask you first if it would be better to add this to the > existing TextTools plugin rather than have one new other plugin. TextTools serves a different purpose; it is a collection of text manipulation commands. Release it on it's own. > The paintHighlight method is not optimized. I'm doing a call to > JEditTextArea.offsetToX for each space or tab and I guess it can be > inefficient though for me performances are acceptable on my PC. > I'm wondering if it would be better to rewrite offsetToX to match my own > needs but I would depend more on JEditTextArea's internals. > Furthermore, Whitespace needs to be user-configurable. Not only that, but you also call GUIUtilities.parseColor(), which is also a bit slow. I think you can make it faster by only calling offsetToX() at the start and end of each *whitespace run*. Eg, if I have three tabs, instead of calling it for each tab, you should only call it at the start and end of the three tabs. > BTW, for those who are interested, I've also revived the old > BufferSelector from the cemetary of plugins. > To remind you, the BufferSelector was discussed in a recent thread about > BufferTabs. > Some people wanted to see how it looked like. Now it's possible again. I think the tabs will stay for now, since I've solved the focus issue. They look better too :-) Slava |
From: <rma...@ie...> - 2000-04-16 04:23:09
|
Whoa, you guys are just too fast to keep up with. I've been modifying the next_page and prev_page functions to allow scrolling to cursor and before I can even get to the prev_page function, you release pre5! Talk about a moving target! This change adds a checkbox on the Editor option pane and modifies the following files: jedit\textarea\InputHandler.java jedit\View.java jedit\jedit_gui.props jedit\options\EditorOptionPane.java Hopefully I'll get the time to finish it in the next couple of days. What is the proper format for the changes and to whom do I send it? Bob -- Please note new email addr and change any references of rma...@ne... to rma...@ie... |
From: Andre K. <ak...@vi...> - 2000-04-16 03:37:41
|
Slava, > Why don't you put this on plugin central? I wanted to ask you first if it would be better to add this to the existing TextTools plugin rather than have one new other plugin. The paintHighlight method is not optimized. I'm doing a call to JEditTextArea.offsetToX for each space or tab and I guess it can be inefficient though for me performances are acceptable on my PC. I'm wondering if it would be better to rewrite offsetToX to match my own needs but I would depend more on JEditTextArea's internals. Furthermore, Whitespace needs to be user-configurable. BTW, for those who are interested, I've also revived the old BufferSelector from the cemetary of plugins. To remind you, the BufferSelector was discussed in a recent thread about BufferTabs. Some people wanted to see how it looked like. Now it's possible again. Andre. |
From: Slava P. <sp...@gj...> - 2000-04-16 03:07:55
|
Andre, Why don't you put this on plugin central? Slava |
From: mike d. <md...@st...> - 2000-04-16 03:04:01
|
On Sun, 16 Apr 2000, Slava Pestov wrote: > Ok, you win. I've added the default-specifying form now. cool. i hope everyone else finds this to be a useful addition to the API. -md |
From: Slava P. <sp...@gj...> - 2000-04-16 03:00:15
|
mike dillon wrote: > whatever. i still disagree. i just think it makes it easier on the > programmer to have the option of specifying a default instead of relying > on all boolean properties to default to false in the case of > error. remember, this interface is not only used in the jEdit core, but > also by plugins, which may not always have valid defaults in their props > files. Ok, you win. I've added the default-specifying form now. Slava |
From: Slava P. <sp...@gj...> - 2000-04-16 02:56:33
|
Andre Kaplan wrote: > Yes, it's no use having twice the same code. And anything that can > simplify CodeAid is welcome. > > CodeAid 0.2.5 uses EditBus Error framework. > So you will get highlighted errors. > > Unfortunately, many of these are actually not errors (it was worse > before though)! > I've already corrected a few bugs concerning error reporting but there's > still a lot of work. CodeAid is really starting to shape up now. Here is my wishlist: - There should be an option to only display member/signature popups a short delay after the '.' or '(' is typed. Then while typing quickly, you wouldn't get distracted by flashing popups, and you could still see a member list by typing '.' and waiting a short while. - A graphical interface to cdb creation, and automatic updating when the format changes -- similar to JIndex. - I believe that currently, it only gets syntax info from the current buffer and the data base. Instead, it should parse all open Java files. - Finish the class browser. If you implement these I will be really happy :-) Slava |
From: Andre K. <ak...@vi...> - 2000-04-16 02:08:44
|
Slava Pestov wrote: > I have a suggestion for CodeAid. Right now, it has it's own error > list code. However, it should be changed to use the standard EditBus > ErrorSource stuff; not only will this remove code duplication, but > it will also mean that errors will be highlighted in-place in the > buffer. Yes, it's no use having twice the same code. And anything that can simplify CodeAid is welcome. CodeAid 0.2.5 uses EditBus Error framework. So you will get highlighted errors. Unfortunately, many of these are actually not errors (it was worse before though)! I've already corrected a few bugs concerning error reporting but there's still a lot of work. Andre. |
From: mike d. <md...@st...> - 2000-04-16 01:34:08
|
On Sun, 16 Apr 2000, Slava Pestov wrote: > As far as I know all the <PROPERTY> tag either should default to false > (eg, noTabs, bracketDoubleIndent) or have valid defaults in the > properties (indentOnEnter, etc). whatever. i still disagree. i just think it makes it easier on the programmer to have the option of specifying a default instead of relying on all boolean properties to default to false in the case of error. remember, this interface is not only used in the jEdit core, but also by plugins, which may not always have valid defaults in their props files. -md |
From: Slava P. <sp...@gj...> - 2000-04-16 01:25:31
|
mike dillon wrote: > for almost all this stuff, it shouldn't matter anyways because the > relevant properties are all jEdit internal (and should thus never be > missing or have invalid values), but it becomes more of an issue for > properties passed in from XML files in PROPERTY tags. As far as I know all the <PROPERTY> tag either should default to false (eg, noTabs, bracketDoubleIndent) or have valid defaults in the properties (indentOnEnter, etc). Slava |
From: mike d. <md...@st...> - 2000-04-16 01:20:46
|
On Sun, 16 Apr 2000, Slava Pestov wrote: > What parts of the code actually depend on the default being true? 2 examples from View.java: Default is false: gutter.setCollapsed("yes".equals(jEdit.getProperty( "view.gutter.collapsed"))); Default is true: gutter.setLineNumberingEnabled(!"no".equals(jEdit.getProperty( "view.gutter.lineNumbers"))); for almost all this stuff, it shouldn't matter anyways because the relevant properties are all jEdit internal (and should thus never be missing or have invalid values), but it becomes more of an issue for properties passed in from XML files in PROPERTY tags. -md |
From: Slava P. <sp...@gj...> - 2000-04-16 00:33:17
|
mike dillon wrote: > i saw the new getBooleanProperty and setBooleanProperty in jEdit.java and > while i like the idea, i think it needs to be improved a little. the main > problem i see is that the default value is always false. if the property > is not set, then it is always false. this is not correct behavior, and a > number of places where custom code was replaced with getBooleanProperty > rely on the default being true. What parts of the code actually depend on the default being true? Slava |
From: mike d. <md...@st...> - 2000-04-15 20:06:15
|
On Sat, 15 Apr 2000, Slava Pestov wrote: > A year ago from now the current release was jEdit 1.5, I think. If > even releasing that as PD seems too much (but I don't think it is, > jEdit 1.5's syntax was pretty crappy, and this was before the text > area rewrite, etc) we could lobotomize the package by removing all > token markers except for Java, for example. i think that putting that code in the public domain would be a nice gesture. i do not think that vetting the code would be necessary either. the fact that this stuff is prior to the text area rewrite is cool too because folks will be able to use it with the vanilla JTextArea. go for it. -md |
From: mike d. <md...@st...> - 2000-04-15 20:00:15
|
hi- i saw the new getBooleanProperty and setBooleanProperty in jEdit.java and while i like the idea, i think it needs to be improved a little. the main problem i see is that the default value is always false. if the property is not set, then it is always false. this is not correct behavior, and a number of places where custom code was replaced with getBooleanProperty rely on the default being true. so, i suggest that we add another getBooleanProperty with an extra parameter for the default. this method will return true for "true", "yes", and "on", false for "false", "no", and "off", and the default otherwise. then the current getBooleanProperty could be rewritten to call the other one with a default of false. public boolean getBooleanProperty(String key, boolean default); public boolean getBooleanProperty(String key) { return getBooleanProperty(key, false); } -md |
From: Slava P. <sp...@gj...> - 2000-04-15 09:18:15
|
Peter VG wrote: > There really isn't any merging. The syntax info is just there, if a > syntax highlighter wants to use it, it does, if not, it doesn't. > I think syntax highlighting can actually be faster and more accurate > if it had syntax info. If you're computing syntax data for indenting, > it doesn't cost anything more to use it for highlighting. Not true. Indenting is only done when the user presses 'Enter' and/or 'Tab', and can be as slow as maybe even 1/4 sec. Highlighting is done when a file is loaded (*all* lines are tokenized on file load), when the user makes any changes, and when their dog barks. A 1/4 sec delay on every key is unacceptable. Also the token info from syntax highlighting is much more simplistic. For example, as far as java.xml is concerned, a { and + is the same thing; a Token.OPERATOR. > I'm not sure I understand this. What do you mean 'search backwards'? I don't > know how regex and incremental search are connected in jEdit. Backwards search is just what the name says, searching backwards in the buffer. Right now 'find next' only scans from the caret to the end; there should also be a 'find previous' that scans from the caret to the start of the buffer, but without the necessary support in gnu.regexp that is impossible. Slava |
From: Slava P. <sp...@gj...> - 2000-04-15 09:10:13
|
Dirk Moebius wrote: > > Slava Pestov wrote: > > I think I will do this in pre5. Dirk -- is the Firewall on plugin central > > the most recent one? If not, could you send me the most recent version? > > It is the latest version. > > (Sorry for answering so late -- got no time to check my mail > recently...) Ok, I will include it with 2.4pre6. Slava |