2008-04-19 19:36:49 +0100 / enh / revision 1290

lib/DEBIAN-control-Depends.txt: most developers' systems will already have manpages-dev, though you didn't get them by default on Ubuntu last time I installed from scratch, and I rarely come across a system with the POSIX man pages where I didn't put them there myself.

2008-04-19 18:58:33 +0100 / enh / revision 1289

src/e/edit/ManPageResearcher.java: if there are multiple man pages with the same title, we probably want to see both. Or, at least, we aren't in a position to choose the "correct" one. So stop picking the first page, and process them all.

2008-04-18 06:25:53 +0100 / enh / revision 1288

src/e/edit/ManPageResearcher.java: add some more weird section names to those we ignore. Also keep hold of the list of unique man page names, and make use of it.

2008-04-18 06:19:17 +0100 / enh / revision 1287

src/e/edit/StlDocumentationResearcher.java: STL documentation is only shown for C++ files, so we can afford to assume that "vector" is std::vector and so on, for the benefit of those who're "using std;". "string" will get you the man page for <string> as well as the STL std::string documentation, but that's okay.

2008-04-18 05:33:28 +0100 / enh / revision 1286

src/e/edit/Advisor.java: the intention was always that multiple researchers could return answers to the same question. In practice, only the first would be seen because the HTML renderer is going to stop when it comes to the "</body></html>".

2008-04-18 05:11:49 +0100 / enh / revision 1285

src/e/edit/AdvisorHtmlPane.java: switching to HtmlPane would be a big change, but borrowing some of its improvements is easy. (Yes, some man pages contain exotic quoting.)

2008-04-16 04:48:06 +0100 / enh / revision 1284

src/e/edit/FindInFilesDialog.java: what do unchecked casts mean? Run-time ClassCastExceptions! Remove a "clever" premature optimization based on the incorrect premise that we only ever compare MatchingFile with MatchingFile and String with String. Imagine a directory that contains files with matches but also contains subdirectories that in turn contain files with matches. That first directory has MatchingFile children and String children, and we need to sort them. There's quite a tradition of sorting directories first, but we're not big on tradition, so let's start with our usual assumption that case-insensitive alphabetical order is the most convenient for humans. (My assumption is that the directories-first guess made sense when navigating a file system with ls(1) and "cd", but makes no sense at all if you're jumping straight to where you want to be, which is Evergreen's aim.)

2008-04-07 02:32:29 +0100 / enh / revision 1283

src/e/edit/FindInFilesDialog.java: fix the ordering of match results by replacing the assumption that they come back in order with code to insert them in sorted order regardless of how they appear.

2008-03-16 21:41:00 +0000 / enh / revision 1282

src/e/edit/EvergreenPreferences.java: Android's equivalents of .class and .jar files are no more interesting than .class or .jar files.

2008-02-27 05:07:10 +0000 / enh / revision 1281

src/e/edit/CheckForLintAction.java: new notes.

2008-02-27 05:00:20 +0000 / enh / revision 1280

lib/DEBIAN-control-Depends.txt: remove the dependency on pychecker. I seem to have multiple versions installed, and they conflict with each other at run-time in some strange Python way. We don't depend on the other lint checkers we have built-in support for, so we don't need to depend on this. As I said in a code comment, the error message will tell the user what's missing.

2008-02-25 06:08:36 +0000 / enh / revision 1279

src/e/edit/BuildAction.java: add basic support for build tools other than GNU Make and Ant. (Strictly speaking, one such build tool per installation.)

2008-02-25 01:01:36 +0000 / enh / revision 1278

src/e/edit/CheckForLintAction.java: make sure we've worked out (and made a note of) which file we're going to check before we risk popping up a dialog that will cause us to move the selection, resulting in the frustrating claim that the user needs to select a file to be checked. Also fix the copy & paste error whereby the unsaved-files dialog talked about "building" rather than "checking for lint".

2008-02-24 00:55:13 +0000 / enh / revision 1277

src/e/edit/ETextWindow.java: add a get-out for users with a coding standard that doesn't get on well with IndentationGuesser's guessing. (That is, an option to have the indentation set in the preferences taken as gospel, as with most other editors.)

2008-02-24 00:09:59 +0000 / enh / revision 1276

src/e/edit/EvergreenPreferences.java: I managed to open a shared library this week. That was annoying.

2008-02-23 01:01:25 +0000 / mad / revision 1275

src/e/edit/ShellCommand.java: This code's moved to invoke-java.rb for the benefit of Terminator.

2008-02-18 00:32:10 +0000 / enh / revision 1274

bin/epydoc.py: try harder when not given a fully-qualified name. Grovel about in Python's internals to try to dig up what the user's looking for. This works well for modules, but not for classes. Sometimes I think I still haven't seen Python itself, just the midden its creators left behind.

2008-02-17 21:13:56 +0000 / enh / revision 1273

bin/epydoc.py: implement the missing option to pydoc(1) that outputs stand-alone HTML to stdout. I've no idea why that isn't already there; it would be even less code than this to implement it in pydoc.py itself.

src/e/edit/PythonDocumentationResearcher.java: a basic "researcher" for the Python documentation.

src/e/edit/Advisor.java: activate it, and tell Evergreen that we want the fully-qualified names.

2008-02-17 05:42:34 +0000 / enh / revision 1272

src/e/edit/EvergreenPreferences.java: add a preference for "Hide mouse when typing", like Terminator.

src/e/edit/Evergreen.java: rather than have Evergreen know what aspects of ETextWindow may need to take preferences into account, just pass the notification on to ETextWindow...

src/e/edit/ETextWindow.java: ...so ETextWindow can update everything it needs to, and call the same code in its constructor (which would have to be duplicated if Evergreen were still responsible).

2008-02-17 04:26:21 +0000 / enh / revision 1271

src/e/edit/Evergreen.java:
src/e/edit/EvergreenPreferences.java: comment out remaining references to the BACKGROUND_COLOR and FOREGROUND_COLOR global preferences until PTextArea is better able to make use of them. At the moment, having half the code means that changing other, fully-implemented, preferences can upset the colors.

2008-02-17 04:23:15 +0000 / enh / revision 1270

src/e/edit/ETextWindow.java:
src/e/edit/EvergreenPreferences.java: add a global option to trim whitespace from the ends of lines when saving.

2008-02-16 21:37:45 +0000 / enh / revision 1269

src/e/edit/ExternalToolsParser.java: add support for arbitrary (non-stock) icons, and factor out the keyboard-equivalent and icon code into their own methods.

2008-02-16 21:02:09 +0000 / enh / revision 1268

src/e/edit/ExternalToolsParser.java: allow an ExternalTool to specify a stock icon that it would like to have associated with it.

2008-02-16 20:45:18 +0000 / enh / revision 1267

src/e/edit/CheckForLintAction.java:
src/e/edit/TagReader.java: FileType is no longer an enum.

2008-02-12 06:50:23 +0000 / enh / revision 1266

src/e/edit/CheckForLintAction.java: reading my notes, I notice I meant to use "ruby -wc" for slightly more thorough checking.

2008-02-10 02:19:13 +0000 / enh / revision 1265

lib/DEBIAN-control-Depends.txt: as usual, it's not really true that Evergreen "Depends" on these, but "Recommends" and "Suggests" are too weak. We do want the user to have these installed.

2008-02-10 02:13:29 +0000 / enh / revision 1264

src/e/edit/CheckForLintAction.java:
src/e/edit/EvergreenMenuBar.java: add basic built-in support for a few of the more common lint-checking tools, specifically Perl and Ruby's built-in syntax checkers, the external pychecker(1) tool for Python and tidy(1) for HTML/XML.

www/index.html: document how the user can override or supplement Evergreen's built-in set of lint checkers.

2008-02-10 02:02:52 +0000 / enh / revision 1263

www/index.html: improve clarity.

2008-02-10 01:56:00 +0000 / enh / revision 1262

www/index.html: fix broken HTML.

2008-02-10 01:54:28 +0000 / enh / revision 1261

www/index.html: document some useful existing configuration possibilities.

2008-02-10 00:28:20 +0000 / enh / revision 1260

src/e/edit/ETextWindow.java:
src/e/edit/EvergreenMenuBar.java:
src/e/edit/ExternalToolsParser.java: although I simplified matters slightly the other day, making the subclasses handle keyboard equivalents was fundamentally useless. If we configure the Action appropriately, we have less code, better locality of concerns, and fix the bug whereby tools would have their keyboard equivalent shown on the main menu but not on the pop-up menus.

2008-02-08 04:40:52 +0000 / enh / revision 1259

src/e/edit/EvergreenPreferences.java: we don't want to index compiled Python bytecode.

2008-02-06 06:03:54 +0000 / enh / revision 1258

src/e/edit/ETextWindow.java:
src/e/edit/EvergreenMenuBar.java:
src/e/edit/ExternalToolsParser.java: pass the whole of the user's keyboard equivalent specification through to addItem, rather than just the first character. Switch to a new heuristic for deciding on the appropriate modifiers for the user's keyboard equivalent. The new heuristic isn't right, but it's better than the old assumption. In particular, the user can now assign an ExternalTool to an unmodified function key (though not to a modified one, and it's still possible to collide with built-in keyboard equivalents). The code comments contain an even fuller explanation of the situation and its problems.

2008-02-06 04:22:35 +0000 / enh / revision 1257

src/e/edit/ExternalToolsParser.java: add another kind of tool, one that takes no input but produces errors window output. This isn't ideally convenient because the errors window doesn't stay up unless your command exits with a non-zero status, and if you do exit with a non-zero status, your command's output will be followed by an ugly message claiming that it failed. I'll live with it for a while before deciding what to do.

2008-02-05 21:39:46 +0000 / mad / revision 1256

src/e/edit/Evergreen.java: Defer to cygpath to canonicalize paths at open-time, in particular ones coming from the errors window, so that /cygdrive/d/ will be converted to d:\, in the hope that Stephen Parker will be able to click on his errors. I've put the call after the existing processPathRewrites, in case anyone's using the existing feature to do anything clever on Cygwin. I've inserted an isWindows check, which I don't have any particularly good justification for. I did come up with a suggestion while trying to write a comment for it. I've left in the code for whoever comes along to tidy-up (although I think I've done a tasteful job and the feature appears both to work, to be cheap enough and to be useful).

2008-01-27 21:56:09 +0000 / enh / revision 1255

src/e/edit/ETextWindow.java: improve our error reporting if something goes wrong while creating the backup file before saving. Extend the "ensure there's a newline at the end of the file" behavior to all FileTypes apart from PLAIN_TEXT; I only need to extend this to MAKE and PYTHON, but can't (yet) think of a reason why it shouldn't apply to every computer language. Also add code to remove runs of trailing newlines (though that seems to be a mistake made by Emacs and jEdit users rather than our users).

2008-01-24 22:52:13 +0000 / mad / revision 1254

src/e/edit/FindFilesContainingSelectionAction.java: Stephen Parker points out that Windows pathnames include regular expression meta-characters - File.SEPARATOR being backslash. I don't see this on the rare occasions that I run Evergreen on Windows because, at the moment, I only have one workspace and it contains fewer than 1000 source files.

2008-01-18 19:27:44 +0000 / enh / revision 1253

src/e/edit/Evergreen.java: Evergreen has changed in 2008, so update the copyright date. Also give ourselves some minimal credit, and fix the start date. 2004 was definitely too late, because the pre-CVS-ChangeLog file has entries going back to 2002. We definitely started work on Evergreen (formerly "Edit", formerly "Roadrunner", a pun on "wily" which was itself a pun on "acme") while I was at GeneData, which I left in mid-2001. Sadly, archive.org doesn't have archives of my web pages from the relevant period, but Ed and I think we started around the time Matthew Wilcox left, which his web page (http://www.wil.cx/matthew/) says was 1999. I'm pretty sure we were still using Java 1.1, and were looking forward to Java 1.2 (Ed had to write a custom bitmap font renderer because Java's font rendering at the time was so slow). Sun's list of release dates (http://java.sun.com/j2se/codenames.html) puts 1.2 at December 1998, but it will have taken a while before we switched, and we may well have been waiting for an IRIX JVM.

2008-01-18 01:20:43 +0000 / enh / revision 1252

src/e/edit/Evergreen.java:
src/e/edit/EvergreenMenuBar.java: e.util.Preferences can do the preferences menu item stuff itself now.

2008-01-03 00:04:53 +0000 / enh / revision 1251

src/e/edit/Evergreen.java: Marsell P-K reports that I've not added a working preferences dialog on Mac OS. This fixes that for now, but longer term I should, as I'd already suspected, make it harder to get this wrong.

2007-12-26 21:59:01 +0000 / enh / revision 1250

src/e/edit/EvergreenPreferences.java: an e.util.Preferences subclass so we can use the new general-purpose preferences implementation.

src/e/edit/EvergreenMenuBar.java: add a new Edit > Preferences... menu if we're not on Mac OS.

src/e/edit/Evergreen.java: switch to the new code for reading/writing preferences, add support for Mac OS' "Preferences..." menu item on the application menu, remove the "external application" cruft which wasn't seeing any use, and make our Preferences object accessible to other classes.

src/e/edit/ChangeFontAction.java:
src/e/edit/EErrorsWindow.java:
src/e/edit/ETextWindow.java:
src/e/edit/FileIgnorer.java: track API changes and fix up code that assumed preferences don't change at run-time.

src/e/edit/Workspace.java: make the text windows accessible so that we can update them when preferences change (which currently seems simpler than adding/removing listeners).

src/e/edit/Parameters.java: having no "edit.properties" is no longer a fatal condition, and as time progresses should become the norm. Note that some hidden preferences ("path.rewrite.*", external tool configuration, "java.advisor.classpath", and "java.advisor.doc") are still only configurable via system properties, so this class is still necessary. A generalized version of Mailer's Add/Edit/Remove dialog would be a better solution for the external tool configuration, but I don't have a plan for the other uses.

bin/evergreen:
lib/data/edit.properties-sample: there's no need to create a default "edit.properties" any longer.

TODO: job done.

www/faq.html: update the documentation, including some points unrelated to this patch but which have been stuck behind it.

2007-12-24 06:22:56 +0000 / enh / revision 1249

src/e/edit/TagsPanel.java: I've been annoyed by the "(Ctags doesn't support Plain Text.)" and "(Ctags doesn't support XML.)" messages. I'm not sure whether the answer is to stop reporting any such cases (which was pretty much the old behavior) or to have exceptions for these two very common cases, or to tweak the output so it isn't as annoying. My first attempt is to tweak the output so it isn't as annoying, making it blend in with its surroundings.

2007-12-23 18:34:21 +0000 / enh / revision 1248

src/e/edit/Advisor.java: hook the "Evergreen Documentation Browser" window into the same mechanism we use to store/restore FormDialog locations and sizes.

2007-12-22 22:37:52 +0000 / enh / revision 1247

src/e/edit/Advisor.java: work around GNOME's annoying breakage of toFront (though it's high time Sun entered the arms race; the chances of the GNOME developers catching a clue in the near future are slim indeed).

2007-12-02 03:16:14 +0000 / enh / revision 1246

src/e/edit/TagsUpdater.java: discussion earlier in the week settled on making it clear when (we believe) the problem is that Ctags doesn't support a language, rather than that Ctags failed, or we failed to understand Ctags' output, or Ctags' output contained no tags, all of which were possible interpretations of the old message.

2007-11-28 05:21:42 +0000 / enh / revision 1245

www/index.html: show the picture before the description, and improve on one particularly awkward sentence.

2007-11-28 05:19:54 +0000 / enh / revision 1244

www/index.html: flesh out the description of the tags panel, now publicly referred to as the symbols tree.

2007-11-27 06:46:31 +0000 / enh / revision 1243

src/e/edit/TagReader.java: tell Ctags what we think the file's type is, rather than trying to arrange the temporary file name so that it guesses the same as we did. This works better if a file's type changes (because you're rewriting a script from Perl to Ruby, say), avoids the possibility of disagreement, and – as in simonj's complaint – means that we can cope with, say, a Ruby script with no extension (where before we'd have lied to Ctags and said it was a .txt file).

src/e/edit/TagsUpdater.java: don't try to make temporary files with appropriate extensions, and don't bother calling Ctags on languages we don't think it supports (because even if it does, we won't understand its response). Try harder to ensure that the user actually sees any error messages we output, and – until we have a better idea – show "(No symbols available.)" for file types Ctags doesn't support.

src/e/edit/ETextWindow.java: if Evergreen's idea of the file's type changes, we need to get Ctags to take another look at it.

2007-11-27 05:50:32 +0000 / enh / revision 1242

src/e/edit/AdvisorHtmlPane.java: martind pointed out that /usr/share/icons/gnome/16x16/actions/ was empty on his Debian box. I think the only reason for using hard-coded paths was because I'd been working on Mailer and using non-stock icons and just carried the bad habit across. Using stock icons obtained from the GTK+ library itself fixes things for everyone. This particular implementation has the side-effect of using the next size of icon up, but there was no particular reason to use the smallest ones anyway.

2007-11-26 23:14:14 +0000 / mad / revision 1241

src/e/edit/AdvisorHtmlPane.java: Remove the double negative to fix the manually drawn forward arrow so it doesn't look like a triangle between these three x characters:

    x
x
x

There's still a bounding box issue but at least it's clearer now that these are buttons.

2007-11-24 03:31:43 +0000 / enh / revision 1240

src/e/edit/WatermarkViewPort.java: use the view's background color here, rather than assuming it's white. Also add a missing "final".

2007-11-23 05:23:07 +0000 / enh / revision 1239

lib/data/edit.properties-sample: remove another no-longer used property.

2007-11-23 05:22:11 +0000 / enh / revision 1238

src/e/edit/Parameters.java: gain this class from salma-hayek, as a first step towards eradicating it.

2007-11-23 03:12:18 +0000 / enh / revision 1237

src/e/edit/ETextWindow.java: track API change.

2007-11-23 02:19:06 +0000 / enh / revision 1236

src/e/edit/EvergreenMenuBar.java: add a local link for the Apple HIG, fix the remote link for the GNOME HIG, and add local and remote links for the Java 6 API documentation.

2007-11-22 05:23:28 +0000 / enh / revision 1235

src/e/edit/Advisor.java: avoid deadlock when a source link is clicked on.

2007-11-21 23:48:41 +0000 / enh / revision 1234

src/e/edit/Evergreen.java: lose various bits of XML-related code to XmlUtilities.

2007-11-21 22:53:21 +0000 / enh / revision 1233

src/e/edit/Evergreen.java: lose writeAtomicallyTo to StringUtilities.

2007-11-17 05:28:36 +0000 / enh / revision 1232

src/e/edit/AdvisorHtmlPane.java: add a "forward" button to go with the "back" button.

2007-11-17 04:38:16 +0000 / enh / revision 1231

src/e/edit/EvergreenMenuBar.java:
src/e/edit/JavaDoc.java: update to point to Java 6 documentation.

2007-11-16 06:14:34 +0000 / enh / revision 1230

src/e/edit/WatermarkViewPort.java: Phil fixed the caller to not pass null, but didn't remove this (incorrect) code intended to cope with seriousMessage being null.

2007-11-16 05:53:35 +0000 / enh / revision 1229

src/e/edit/WatermarkViewPort.java: use darker colors for watermarks now the text isn't so dense.

2007-11-14 07:47:38 +0000 / pcn / revision 1228

src/e/edit/ETextWindow.java:
src/e/edit/WatermarkViewPort.java: Paint watermarks at a 45 degree angle, as an image (drawing text directly would cause wiggling during mouse selection). This interferes with the actual program text far less, and looks nice :-)

2007-11-14 04:05:19 +0000 / enh / revision 1227

src/e/edit/EColumn.java:
src/e/edit/WatermarkViewPort.java: don't use Class.cast unless it's actually necessary.

2007-11-12 19:46:11 +0000 / mad / revision 1226

src/e/edit/RubyDocumentationResearcher.java: Fix OOBE when researching "FileUtils":

Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: -1
            at java.lang.String.substring(String.java:1938)
            at e.edit.RubyDocumentationResearcher.rewriteIncludeListAsLinks(RubyDocumentationResearcher.java:63)
            at e.edit.RubyDocumentationResearcher.research(RubyDocumentationResearcher.java:22)

2007-11-12 06:27:48 +0000 / mad / revision 1225

Makefile: Use the newly preferred path for simple.make.

2007-11-04 18:52:18 +0000 / mad / revision 1224

src/e/edit/AdvisorHtmlPane.java: Chris could install JDK6 for his Solaris nightly build if he wanted to but I don't have that luxury on this MacBook. This is the "solution" we've adopted elsewhere, though we've rarely needed it.

2007-11-03 23:33:00 +0000 / enh / revision 1223

src/e/edit/AdvisorHtmlPane.java: annoyingly, a custom icon doesn't work with the GTK+ LAF: the button acts as if the icon was zero-sized. So I'll keep (for now, at least) my quick hack if it looks like it's going to work, otherwise I'll use a new custom icon.

2007-11-03 22:58:21 +0000 / enh / revision 1222

src/e/edit/AdvisorHtmlPane.java: mad points out that initKeyBindings no longer needs a parameter.

2007-11-03 22:56:41 +0000 / enh / revision 1221

src/e/edit/Advisor.java:
src/e/edit/AdvisorHtmlPane.java: add a tool bar to the documentation browser, and make it clear when we're making changes that shouldn't go into the history. Also enable/disable the "go back" Action as the history changes, and fix a bug I introduced translating mad's Stack-using patch to ArrayList, mistaking his use of "peek" as a C++-ism. The tool bar button's icon only works on standard GNOME installations. I'll come back soon with a custom icon.

2007-11-03 22:20:13 +0000 / enh / revision 1220

src/e/edit/AdvisorHtmlPane.java: a slightly simplified variant of a patch from mad to add a history and bind backspace to "go back". I'll follow up with a tool bar with a "back" button.

2007-10-31 22:40:15 +0000 / enh / revision 1219

src/e/edit/KillErrorsAction.java:
src/e/edit/ShellCommand.java:
src/e/edit/StreamMonitor.java: pass through to EErrorsWindow information about whether we're giving it text from standard out or standard error. Internal errors count as standard error. I've also improved some of the names to be more specific.

src/e/edit/EErrorsWindow.java: stop auto-scroll on error. This stops scrolling after the first "chunk" of error text, which is often just one line. That's not really what we want, but this is a proof of concept more than anything else. If it turns out to be annoying, it doesn't have to stay. (At least one person has asked for this functionality to come back recently.) Really, we'd like to be able to color the error text differently, but PTextArea's not really set up for that.

2007-10-31 01:37:13 +0000 / mad / revision 1218

lib/data/spelling-exceptions-C++: os << oss.rdbuf() doesn't work if oss is a std::ostringstream but does if it's a std::stringstream. We shouldn't be persecuting std::stringstream here.

2007-10-23 06:58:49 +0100 / enh / revision 1217

src/e/edit/Evergreen.java: improve the wording for the "Remove Workspace" dialog even further.

2007-10-20 19:53:32 +0100 / enh / revision 1216

src/e/edit/Evergreen.java: make it clearer that "remove workspace" doesn't touch disk, which is more ambiguous now...

src/e/edit/WorkspaceProperties.java: ..."add workspace" can optionally create the directory for you if it doesn't already exist (optionally because you might just have typed it wrong). Also choose a sensible default name based on the root, for those cases where the user just types a root directory. (If they chose a root directory with the "Browse..." button, we already visibly did this for them, but if they just typed in the path themselves, we silently gave the workspace the empty title.)

2007-10-17 05:53:55 +0100 / enh / revision 1215

www/faq.html: include the Cygwin FAQ item.

2007-10-14 02:00:58 +0100 / mad / revision 1214

src/e/edit/EErrorsWindow.java: The hack's not seeming like a bad idea, but we shouldn't continue to say that our builds always "exit 0" now that I've fixed that pipefail problem.

2007-10-13 23:01:49 +0100 / enh / revision 1213

src/e/edit/BuildAction.java:
src/e/edit/EErrorsWindow.java:
src/e/edit/Evergreen.java:
src/e/edit/ShellCommand.java: remove the indeterminate progress bar shown during builds, because the presence/absence of the build output window is a much stronger visual indication of whether or not we're building. Move the "kill" button from the main window into the errors window. Lose all the special border fiddling that used to be necessary, and tighten the main window's status bar.

2007-10-12 19:50:25 +0100 / enh / revision 1212

src/e/edit/WorkspaceProperties.java: automatically normalize user-entered pathnames to match their system's native file separator to avoid ugly mixed-separator pathnames and to avoid the need for special cases in code that thinks it's doing the right thing by only referring to File.separator, but is likely broken for mixed-separator pathnames.

2007-10-12 19:29:51 +0100 / enh / revision 1211

src/e/edit/FileIgnorer.java: benchmarking suggests that the current implementation is actually the fastest without getting excessively clever with regular expressions (which seems error-prone for little benefit), so stick with nameEndsWithOneOf and just remove the unused overload.

2007-10-12 18:51:43 +0100 / enh / revision 1210

src/e/edit/Evergreen.java:
src/e/edit/FileIgnorer.java:
src/e/edit/JavaDoc.java: use Parameters.getArrayOfSemicolonSeparatedElements, which contains the best of all the idioms here.

2007-10-12 18:41:34 +0100 / enh / revision 1209

src/e/edit/Evergreen.java:
src/e/edit/FileIgnorer.java:
src/e/edit/JavaDoc.java: bring over error- and inefficiency-prone code from salma-hayek that's only used in Evergreen and should be reimplemented here.

2007-10-12 18:25:54 +0100 / enh / revision 1208

src/e/edit/Evergreen.java: Stephen Parker points out that we can be fooled by Windows drive letters if they're at the start of a path that uses Unix rather than Windows file separators. We'd take them to be URI schemes, and hand over the "URI" to the system, which isn't fooled, and which (in his case) meant that Evergreen would open files in Visual Studio.

2007-10-11 07:20:25 +0100 / enh / revision 1207

src/e/edit/ShellCommand.java: now the build output window is automatically cleared when a build starts, there's no particular use for the line separating builds (0 or 1 items don't much need separating). I did think it might be useful in making it clear that the build really is finished, but the fact that the build window disappears is clue enough for successful builds, and I think the failure message will be enough for failed builds (at least when our build system again lets us know it failed, which mad plans on fixing when he returns). He actually complained about this output as more than just an eyesore; he pointed out that (for reasons we've never investigated) Terminator and the two SCM utilities exit in a very leisurely manner. With SCM this can mean that you've closed the window, gone off to do something else, and have the build output window pointlessly bother you with the uninteresting fact that SCM has finally got round to exiting.

2007-10-11 07:10:02 +0100 / enh / revision 1206

src/e/edit/EErrorsWindow.java: bind Esc and C-K to "Clear Errors" when the errors window itself has focus.

2007-10-05 17:32:18 +0100 / enh / revision 1205

src/e/edit/ShellCommand.java: hack a bad interaction between GNOME and small displays. Funnily enough, the code was accidentally like this during initial development, but the flickering annoyed me enough to track it down and remove it, and window overlapping wasn't a serious problem on my 30" display. At work, though, this has been crippling.

2007-10-05 07:25:11 +0100 / enh / revision 1204

src/e/edit/BuildAction.java:
src/e/edit/EColumn.java:
src/e/edit/FindInFilesDialog.java:
src/e/edit/ShowDocumentationAction.java:
src/e/edit/TagsUpdater.java:
src/e/edit/WorkspaceFileList.java: remove unused fields, locals, and methods.

2007-10-04 06:36:06 +0100 / enh / revision 1203

src/e/edit/Advisor.java:
src/e/edit/AppropriateFontAction.java:
src/e/edit/CompareSelectionAndClipboardAction.java:
src/e/edit/CycleWorkspacesAction.java:
src/e/edit/EButton.java:
src/e/edit/ETextWindow.java:
src/e/edit/Evergreen.java:
src/e/edit/EvergreenMenuBar.java:
src/e/edit/EWindow.java:
src/e/edit/FilePropertiesAction.java:
src/e/edit/FindAction.java:
src/e/edit/FixedFontAction.java:
src/e/edit/MinibufferUser.java:
src/e/edit/NumberResearcher.java:
src/e/edit/OpenQuicklyDialog.java:
src/e/edit/ProportionalFontAction.java:
src/e/edit/ShowCounterpartAction.java:
src/e/edit/ShowDocumentationAction.java:
src/e/edit/SimplePatchDialog.java:
src/e/edit/StlDocumentationResearcher.java:
src/e/edit/TagsPanel.java:
src/e/edit/TagType.java:
src/e/edit/Workspace.java:
src/e/edit/WorkspaceFileList.java: remove unused imports.

2007-10-03 05:01:18 +0100 / enh / revision 1202

src/e/edit/FindInFilesDialog.java:
src/e/edit/OpenQuicklyDialog.java: mad points out that if you open the "Open Quickly" dialog while a rescan is in progress, you don't see the "Rescan in progress..." message. "Find in Files" unsurprisingly has the same problem. Fix them both, and another "Open Quickly" visual glitch caused by doing things in the wrong order.

2007-09-26 00:39:57 +0100 / mad / revision 1201

src/e/edit/EErrorsWindow.java: Slow builds perhaps conspire with sawfish to make this wrinkle more obvious than it is with quick builds and/or compiz.

2007-09-24 03:50:22 +0100 / enh / revision 1200

www/faq.html: I've updated our precompiled Mac OS Exuberant Ctags binary to version 5.7, so the instructions need to change.

2007-09-24 03:22:19 +0100 / enh / revision 1199

www/faq.html: Solaris users have two choices for their Exuberant Ctags binary.

2007-09-22 02:32:23 +0100 / enh / revision 1198

src/e/edit/EColumn.java:
src/e/edit/Workspace.java: move maintenance of the workspace tab's title into Workspace, and make it more robust if we add new places that add/remove components from EColumn (not that I plan to).

2007-09-22 01:47:12 +0100 / enh / revision 1197

src/e/edit/EColumn.java: fix the warning now I again understand the code better.

2007-09-22 01:38:39 +0100 / enh / revision 1196

man/1/edit-and-block.1:
man/1/evergreen.1: manual pages for the two commands provided by Evergreen.

2007-09-22 01:37:46 +0100 / enh / revision 1195

man/1: new directory.

2007-09-22 01:36:56 +0100 / enh / revision 1194

man: new directory.

2007-09-22 00:58:15 +0100 / enh / revision 1193

src/e/edit/EditServer.java:
src/e/edit/Evergreen.java:
src/e/edit/NewFileAction.java:
src/e/edit/SaveAllAction.java:
src/e/edit/ShellCommand.java:
src/e/edit/WorkspaceFileList.java: it might be easier to quote like 'this' than like "this" in source, but the former looks weird.

2007-09-21 21:12:39 +0100 / enh / revision 1192

src/e/edit/EColumn.java: turn the EColumn into just its bottom component, losing the split pane with the EErrorsWindow as the top component.

src/e/edit/Workspace.java: cope with the change by just using the EColumn directly as the workspace's entire UI. Workspace still has an EErrorsWindow, though, because – although I don't think it's particularly useful myself – I'd like to move back to supporting multiple builds at once.

src/e/edit/EErrorsWindow.java: EErrorsWindow is now a free-standing JFrame. The frame uses the Evergreen icon, and stores/restores its location. The text area defaults to a traditional terminal's size. The frame shows itself whenever it's written to, and hides itself if the last-started task exits with success. The frame gains its own status bar...

src/e/edit/ShellCommand.java: ...and ShellCommand now uses the EErrorsWindow status bar rather than the main Evergreen one. It also needs to send taskDidStart/taskDidExit notifications to EErrorsWindow.

src/e/edit/KillErrorsAction.java: I can't imagine any circumstances under which this null check was ever necessary, so simplify the code. I may be back to remove KillErrorsAction entirely, because it's not obviously very useful now.

2007-09-21 21:03:15 +0100 / enh / revision 1191

src/e/edit/Evergreen.java: track API change.

2007-09-21 18:00:30 +0100 / enh / revision 1190

lib/DEBIAN-control-Depends.txt: our dependency on ri(1) (which is really a "Recommends") should be here, not salma-hayek.

2007-09-20 18:09:13 +0100 / enh / revision 1189

src/e/edit/EColumn.java: remove the unnecessary @author and HTML formatting. (We need to get round to having AUTHORS files and finishing the "Credits" button in the about dialog.)

2007-09-20 17:51:24 +0100 / enh / revision 1188

src/e/edit/EColumn.java: remove an unused field.

2007-09-20 17:41:26 +0100 / enh / revision 1187

src/e/edit/ShowHideTagsAction.java: "symbols" is less of an implementation detail than "tags", and probably more meaningful to more people. I hope "tree" might help people understand which bit it is we're talking about too, in the absence of some kind of menu-item rollover action where we shade out the rest of the UI and let just the tags panel shine through (which I think would be the best solution, but not the best use of my time).

src/e/edit/FindInFilesDialog.java: improve a tags-related error message (even though no-one but us will see it).

src/e/edit/Evergreen.java: we don't have a simple way to upgrade old XML files (the availability of which would be a convincing selling point for that nonsense), so I'll have to leave the stored configuration with the ambiguous name, but there's no reason for the identifier in the source to be "splitPaneDividerLocation" instead of "tagsPanelSplitPaneDividerLocation".

2007-09-19 01:06:22 +0100 / enh / revision 1186

src/e/edit/ETextWindow.java: automatically ensure C# files end in a newline too.

2007-09-19 01:00:03 +0100 / enh / revision 1185

src/e/edit/EErrorsWindow.java: cope with errors from the Microsoft-like C# compiler.

2007-09-09 03:23:58 +0100 / enh / revision 1184

src/e/edit/AddWorkspaceAction.java:
src/e/edit/Evergreen.java:
src/e/edit/Workspace.java: the newly uniform interface to creating or modifying a workspace is a good improvement, but it would be even better if the underlying code were uniform enough to not just ignore your choice of build target if you make that choice when creating a workspace. Make all workspace creation/opening code use a WorkspaceProperties rather than a String trio (or, as in the previously problematic code, duet).

2007-09-03 23:10:19 +0100 / enh / revision 1183

src/e/edit/TagReader.java: Alex Graveley suggests that it's not particularly useful to be subject to the whims of the user's update-alternatives(1) choice of ctags, so add the Debian name for the Exuberant Ctags binary.

2007-08-29 05:29:40 +0100 / enh / revision 1182

src/e/edit/OpenQuicklyDialog.java: EHistoryTextField doesn't work well here. It's too unwieldy to call up the history, there's a bug it can reset the match list selection when the focus is in the match list (which is exceedingly annoying if it happens just as you go to hit return), and in the GTK+ LAF, editable combo boxes' text is currently (in Java 6 and Java 7) rendered without insets, flush to the left of the component's bounding box, hiding the first character under the border. Something like the minibuffer's history would probably be a better choice.

2007-08-29 05:14:22 +0100 / enh / revision 1181

src/e/edit/Minibuffer.java: simplify things by looking at key-pressed events rather than key-released events. This means we don't have to ignore the key-release corresponding to the key-press that called us up, and means that we can check the text field's input map to see if it wants to handle a keystroke first, so that C-C in the text field copies from the text field rather than the text, and so on. The one negative consequence of handling key-pressed events is that we have to ignore the press of 'control' (or whatever's the platform's modifier) that inevitably precedes the composed press of control and a non-dead key.

2007-08-27 00:14:00 +0100 / enh / revision 1180

src/e/edit/Minibuffer.java: replace the special-case handling of two keyboard equivalents with general-purpose code that searches the menu bar. Be more consistent about consuming events.

src/e/edit/FindAction.java:
src/e/edit/MinibufferUser.java: remove cruft.

src/e/edit/GotoAction.java: remove cruft and add a fix from FindAction that hadn't been applied here.

src/e/edit/Evergreen.java: be more specific about what kind of frame we use so callers don't need to cast.

2007-08-25 17:24:44 +0100 / enh / revision 1179

www/index.html: document another cool but subtle feature.

2007-08-25 17:19:35 +0100 / enh / revision 1178

src/e/edit/FindAndReplaceAction.java: Marsell P-K ("Tom") points out that this hard-to-get-right code is still wrong; replacing something with nothing actually rendered as if we'd replace with a single space. Maybe mangling the output rather than mangling the input will be more robust. (Of all Swing's stupid decisions, the decision to make an empty label zero-height causes me the most hassle.)

2007-08-25 00:40:13 +0100 / enh / revision 1177

src/e/edit/EvergreenMenuBar.java:
src/e/edit/SetBuildTargetAction.java: remove the old "Set Build Target..." menu item...

src/e/edit/AddWorkspaceAction.java:
src/e/edit/EditWorkspaceAction.java:
src/e/edit/WorkspaceProperties.java: ...in favor of putting it in the workspace properties.

2007-08-25 00:34:26 +0100 / enh / revision 1176

src/e/edit/AddWorkspaceAction.java:
src/e/edit/EditWorkspaceAction.java:
src/e/edit/WorkspaceProperties.java: factor out the duplication between the implementations of "Add Workspace..." and "Edit Workspace...".

2007-08-25 00:10:39 +0100 / enh / revision 1175

src/e/edit/OpenQuicklyDialog.java: use EHistoryTextField to remember recent accepted search terms. If this is a successful experiment, there are other dialogs which can be similarly enhanced.

2007-08-25 00:08:36 +0100 / enh / revision 1174

www/index.html: elaborate slightly on our interpretation of regular expressions as regards case-sensitivity, and mention our parallel search, which is a major time saver for me.

2007-08-24 18:28:00 +0100 / enh / revision 1173

www/faq.html: UL looks awful and I'm not going to waste time on CSS, so switch to one P per "item".

www/index.html: break up an overly-long paragraph and add some more useful hints.

2007-08-24 18:22:17 +0100 / enh / revision 1172

www/faq.html:
www/index.html: a couple of documentation improvements suggested by Marsell P-K ("Tom").

2007-08-24 01:04:58 +0100 / enh / revision 1171

src/e/edit/Evergreen.java: Marsell P-K ("Tom") reminds me that I never meant to sort workspaces case-sensitively.

2007-08-21 19:45:24 +0100 / enh / revision 1170

src/e/edit/FindInFilesDialog.java: reinstate a special case I deliberately removed in order to understand the motivation for it. Now it has an accompanying comment.

2007-08-21 06:25:32 +0100 / enh / revision 1169

src/e/edit/FindInFilesDialog.java: replace the old cancellation mechanism, which was meant for a single search thread, with a scheme suitable for the new multiple-thread implementation.

2007-08-20 17:11:53 +0100 / enh / revision 1168

src/e/edit/FindInFilesDialog.java: maintain Java 5 compatibility for Mac OS' sake. I don't know whether to be pleased or disappointed Apple are a year late with their own OS too, not just their Java 6 implementation.

2007-08-20 02:42:08 +0100 / enh / revision 1167

src/e/edit/FindInFilesDialog.java: search files in parallel. This doesn't cost a significant amount for small workspaces, and makes a big difference on large ones. The SwingWorker's background thread now just submits each file as a separate task, and waits for the threads executing those tasks to finish.

2007-08-16 06:10:50 +0100 / enh / revision 1166

src/e/edit/Minibuffer.java: remove a work-around for a bug that no longer exists, and which itself is susceptible to NullPointerExceptions.

2007-08-16 02:34:53 +0100 / enh / revision 1165

src/e/edit/OpenQuicklyDialog.java: log whenever we do an "Open Quickly" search, to see if we can track down johnh's problem.

2007-08-13 05:30:04 +0100 / enh / revision 1164

src/e/edit/OpenQuicklyDialog.java: I'm sure I had a reason at the time why I didn't change the font in this dialog when I changed the others, and I think that reason was "the content isn't code", but I've come to think that it was a mistake. Especially because, realistically speaking, the user's configured font is ideal: they can change it without affecting other applications, and the sensible value to change it to is the smallest text they're comfortable with, and – even when we're not strictly showing code – "smallest text the user's comfortable with" is exactly what we want.

2007-08-13 04:27:44 +0100 / enh / revision 1163

src/e/edit/Evergreen.java: Geoff Winkless points out that a new user's "Show Tags" menu item doesn't correspond with reality. Fix that by setting the default in the right place, and fix a similar minor problem (a harmless NullPointerException for new users) by only initializing the "remembered files opener" when we know there's at least one workspace.

2007-08-13 04:16:05 +0100 / enh / revision 1162

src/e/edit/SimplePatchDialog.java: Geoff Winkless points out that if you've never used Evergreen before, patches show up infinitesimally small until you enlarge the containing window. Fix that by supplying a more sensible default size.

2007-07-24 04:50:29 +0100 / enh / revision 1161

lib/evergreen.ico: conversion of the 128x128 icon via GIMP.

2007-07-21 04:44:03 +0100 / enh / revision 1160

lib/evergreen-128.png:
lib/evergreen-32.png:
lib/evergreen-512.png:
lib/Evergreen.icns: new icons from Sébastien Pierre.

2007-07-09 01:00:33 +0100 / enh / revision 1159

www/index.html: since we're unlikely to manage to keep the list of supported languages updated, make it clear that it's incomplete.

2007-07-09 00:59:15 +0100 / enh / revision 1158

src/e/edit/TagType.java: don't let unknown tags cause NullPointerExceptions. Just showing the identifier is a perfectly reasonable default behavior.

2007-07-05 17:55:34 +0100 / enh / revision 1157

www/index.html: the panel think that "can" is sufficient to make it clear that this is an optional and relatively unusual style of use.

2007-07-05 17:50:08 +0100 / enh / revision 1156

www/index.html: Chris articulates the main case where clicking on the bird's-eye view is useful, and maybe it's worth mentioning that in the closest we come to documentation.

2007-07-05 17:13:48 +0100 / enh / revision 1155

src/e/edit/ShowMisspellingsAction.java: Geoff Winkless points out that an empty list when there are no misspellings is confusing, and looks like a bug.

2007-07-04 21:05:53 +0100 / enh / revision 1154

src/e/edit/FindInFilesDialog.java:
src/e/edit/OpenQuicklyDialog.java: fix a couple more dialogs where page up/page down could be redirected to a more appropriate component.

src/e/edit/FindAndReplaceAction.java: and another, though this requires more extensive changes. This could probably be improved further, to not build a new form each time round.

2007-07-04 19:41:12 +0100 / enh / revision 1153

www/index.html: clarify the "heuristic" heuristic, update the "Open Quickly" screenshot, and add a section (and screenshot) for "Find in Files".

www/find-in-files.png: new screenshot.

www/open-quickly.png: updated screenshot.

2007-07-04 19:20:18 +0100 / enh / revision 1152

src/e/edit/FindInFilesDialog.java: use the configured font in the "Find in Files" dialog too.

2007-07-04 18:21:48 +0100 / enh / revision 1151

www/index.html: Geoff Winkless got the wrong end of the stick about our find functionality from reading the web page, so make an effort to clarify and expand upon what was there.

2007-06-26 07:10:03 +0100 / enh / revision 1150

src/e/edit/TagType.java: Olivier reminds me that MessageFormat should be consigned to the dustbin of history. I was thinking of switching to String.printf, but that's overkill for this, and String.replaceAll makes things a lot clearer and simpler.

2007-06-26 06:14:08 +0100 / enh / revision 1149

src/e/edit/TagType.java: give structs and unions the same icon as classes and enums.

2007-06-25 05:56:58 +0100 / enh / revision 1148

src/e/edit/TagsPanel.java: increase the usefulness of the tags panel for GNOME users by using the configured editor font instead of GNOME's absolutely enormous default font. (I first tried a variety of ways of shrinking the existing font, but that's fraught with portability problems, and none of my ideas were as straightforward as "use the font the user's already gone out of their way to select".) Note also that we're no longer caching any fonts here.

2007-06-24 19:41:43 +0100 / enh / revision 1147

src/e/edit/TagReader.java: treat global variables like fields and unions like structs when sorting. Treat file-scope identifiers as private for the purposes of coloring. Use || instead of | in a context where it's correct but looks strange.

src/e/edit/TagType.java: add two new shapes, "diamond" and "hash", and use the latter for macro definitions. (It's a bit C-centric, but meaningful shapes are hard to come by!) Use the "triangle" that we've always used for fields for global variables too.

src/e/edit/TagsPanel.java: always set an icon on the tree cell renderer, and let the icon decide whether or not to draw anything. This moves the null test so the code's more obviously correct. The Shape draw/fill code gets even worse to cope with the new "hash". Each Shape probably needs a "canFill" boolean, and we should either draw or fill (but never both) based on that and tag.isAbstract.

2007-06-10 18:42:11 +0100 / enh / revision 1146

src/e/edit/ETextArea.java: for some reason, i've been pasting a lot of text with linefeed line endings lately. As if having to manually reformat wasn't annoying enough, PTextArea copes poorly with embedded linefeeds. This patch only addresses the manual reformatting by doing it automatically.

2007-06-08 06:34:49 +0100 / enh / revision 1145

src/e/edit/FindInFilesDialog.java: tidy imports, and include the time taken by a search.

2007-06-08 06:32:53 +0100 / enh / revision 1144

src/e/edit/NewFileAction.java: it's not just '.' that's invalid in a generated constant name. My particular example contained a '-', but let's outlaw everything that isn't obviously acceptable.

2007-06-04 03:50:34 +0100 / enh / revision 1143

src/e/edit/TagReader.java:
src/e/edit/TagType.java: use the less confusing Java terminology of "enum type" and "enum constant", and add support for Exuberant ctags' forthcoming extra tags for Java enum types.

2007-05-24 06:49:10 +0100 / enh / revision 1142

www/index.html: set all the variables at the start, so I can use them in the #included fragments without worrying whether or not they've been set by that point.

2007-05-21 06:30:08 +0100 / enh / revision 1141

src/e/edit/ETextWindow.java: now PTextArea keeps track of the FileType, we shouldn't duplicate that here.

2007-05-21 00:59:18 +0100 / enh / revision 1140

src/e/edit/EWindow.java: remove dead code.

2007-05-20 17:51:09 +0100 / enh / revision 1139

src/e/edit/EvergreenMenuBar.java: track API change.

2007-05-20 07:30:56 +0100 / enh / revision 1138

src/e/edit/Evergreen.java: track web server case change.

2007-05-20 07:27:35 +0100 / enh / revision 1137

src/e/edit/EvergreenMenuBar.java: track API change. (And a recent case change on our web server.)

2007-05-20 07:09:51 +0100 / enh / revision 1136

src/e/edit/TagsUpdater.java:
www/faq.html:
www/index.html: be consistent in our capitalization of "Exuberant Ctags" (which I've checked with the Exuberant Ctags website), and link to that website in the "Where can I get Exuberant Ctags" section of the FAQ.

2007-05-20 06:37:03 +0100 / enh / revision 1135

www/index.html: "cross-platform" is fundamental to jessies.org.

2007-05-20 06:16:52 +0100 / enh / revision 1134

www/index.html: Rob Pike's "Acme: A User Interface for Programmers" paper seems to have moved, so follow it.

2007-05-20 01:24:35 +0100 / enh / revision 1133

www/index.html: use the new navigation bar.

2007-05-20 00:14:27 +0100 / enh / revision 1132

www/index.html: until the unlikely day that someone writes a tutorial and a user guide, include the "notes" where we mention the corresponding feature.

2007-05-20 00:10:56 +0100 / enh / revision 1131

www/index.html: fix an incorrect close tag.

2007-05-20 00:10:03 +0100 / enh / revision 1130

www/index.html: use the Terminator-style "Features" list.

2007-05-19 22:52:41 +0100 / enh / revision 1129

www/faq.html:
www/index.html: pull FAQ-like stuff into an explicit FAQ.

2007-05-06 18:34:02 +0100 / enh / revision 1128

src/e/edit/CheckInChangesAction.java:
src/e/edit/ShowHistoryAction.java: search for our scripts rather than assuming they're on the path, so Evergreen.app and SCM.app automatically work together without the user having to fix anything.

2007-05-01 22:29:58 +0100 / mad / revision 1127

Makefile: http://software.jessies.org/Evergreen/ now says:

svn checkout http://software.jessies.org/svn/evergreen/trunk/ evergreen

But anyone building a .deb (for example) from that would (without this change) build an installer with the wrongly capitalized name in its description. In the case of (at least) the Windows installer, it would affect the case of the desktop shortcut.

We could all check-out with a consistent case... or we could just make it work anyway.

2007-04-30 16:23:40 +0100 / enh / revision 1126

src/e/edit/FindInFilesDialog.java: mad pointed out a bad Log.warn message in revision 1080, so fix it (the last one in this patch), and bring the others into line. Remove the commented-out near-duplicate of the last one now the last one's correct and only one line further away if it's needed again.

2007-04-28 22:43:12 +0100 / mad / revision 1125

src/e/edit/FileIgnorer.java: Ah, so *that's* why .generated's contents is polluting my workspace file list on Windows. File.isHidden looks for the leading "." on unix but not on Windows. We already had an explicit test for the "." but we were testing the wrong thing. Changing it to the right part of the path shouldn't affect the rest of this method, which only cares about the end of the string.

2007-04-28 06:34:13 +0100 / enh / revision 1124

bin/evergreen: use report_exceptions.

2007-04-28 06:18:30 +0100 / enh / revision 1123

bin/evergreen: remove output to stdout that isn't obviously useful, isn't likely to ever be seen by anyone, and is likely to choke "rubyw.exe" on Cygwin.

2007-04-27 18:15:22 +0100 / mad / revision 1122

bin/evergreen: We can revert to plain exit(), now show_uncaught_exception() knows to ignore SystemExit exceptions.

2007-04-26 22:44:27 +0100 / car / revision 1121

www/index.html: aspell is already shipped with Solaris, as /usr/bin/aspell.

2007-04-26 21:30:13 +0100 / car / revision 1120

www/index.html: Our Exuberant Ctags package is now available via Blastwave, so Solaris x86 users, at least, should be able to get everything out of one box or another.

2007-04-24 03:40:38 +0100 / mad / revision 1119

src/e/edit/TagsUpdater.java: Only look for suffixes in the final component of the filename. This stops spurious exceptions, for me, from crontab -e which, for me, tries to open files like:

2007-04-23T19:39:21.454-0700 Evergreen: Opening '/tmp/crontab.kMo9Hb/crontab'

And was throwing the like of:

2007-04-21T14:09:08.435-0700 Evergreen: Couldn't make tags
Associated exception:
java.io.IOException: No such file or directory
at java.io.UnixFileSystem.createFileExclusively(Native Method)
at java.io.File.checkAndCreate(File.java:1704)
at java.io.File.createTempFile(File.java:1793)
at java.io.File.createTempFile(File.java:1830)
at e.edit.TagsUpdater$TreeModelBuilder.scanTags(TagsUpdater.java:295)
at e.edit.TagsUpdater$TreeModelBuilder.doInBackground(TagsUpdater.java:244)
at e.edit.TagsUpdater$TreeModelBuilder.doInBackground(TagsUpdater.java:208)
at org.jdesktop.swingworker.SwingWorker$1.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at org.jdesktop.swingworker.SwingWorker.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)

2007-04-22 02:18:27 +0100 / enh / revision 1118

src/e/edit/Workspace.java: neilb had a frustrating few minutes trying to open a file on local disk while the NFS server hosting an unrelated workspace was rebooted for upgrade, so let's cache canonical path when we set the workspace's root:

  2007-04-20T17:40:16.838-0700 Evergreen: (hang #6) event dispatch thread stuck processing event for 1059 ms:
     java.io.UnixFileSystem.canonicalize0(Native Method)
     java.io.UnixFileSystem.canonicalize(UnixFileSystem.java:157)
     java.io.File.getCanonicalPath(File.java:531)
     e.edit.Workspace.getCanonicalRootDirectory(Workspace.java:103)
     e.edit.Evergreen.normalizeWorkspacePrefix(Evergreen.java:368)
     e.edit.Evergreen.openFileNonInteractively(Evergreen.java:309)
     e.edit.Evergreen.openFile(Evergreen.java:218)
     e.edit.Evergreen.openFile(Evergreen.java:234)
     e.edit.OpenQuicklyDialog.openFileAtIndex(OpenQuicklyDialog.java:86)
     e.edit.OpenQuicklyDialog.openSelectedFilesFromList(OpenQuicklyDialog.java:191)
     e.edit.OpenQuicklyDialog$4.call(OpenQuicklyDialog.java:136)
     e.edit.OpenQuicklyDialog$4.call(OpenQuicklyDialog.java:135)
     e.forms.FormDialog.acceptDialog(FormDialog.java:414)
     e.forms.FormDialog$9.actionPerformed(FormDialog.java:458)
     javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1849)
     javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2169)
     javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420)
     javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258)
     javax.swing.AbstractButton.doClick(AbstractButton.java:302)
     javax.swing.plaf.basic.BasicRootPaneUI$Actions.actionPerformed(BasicRootPaneUI.java:190)
     javax.swing.SwingUtilities.notifyAction(SwingUtilities.java:1571)
     javax.swing.JComponent.processKeyBinding(JComponent.java:2772)
     javax.swing.KeyboardManager.fireBinding(KeyboardManager.java:255)
     javax.swing.KeyboardManager.fireKeyboardAction(KeyboardManager.java:204)
     javax.swing.JComponent.processKeyBindingsForAllComponents(JComponent.java:2849)
     javax.swing.JComponent.processKeyBindings(JComponent.java:2841)
     javax.swing.JComponent.processKeyEvent(JComponent.java:2735)
     java.awt.Component.processEvent(Component.java:5278)
     java.awt.Container.processEvent(Container.java:1966)
     java.awt.Component.dispatchEventImpl(Component.java:3968)
     java.awt.Container.dispatchEventImpl(Container.java:2024)
     java.awt.Component.dispatchEvent(Component.java:3803)
     java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1826)
     java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(DefaultKeyboardFocusManager.java:677)
     java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(DefaultKeyboardFocusManager.java:934)
     java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:806)
     java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:641)
     java.awt.Component.dispatchEventImpl(Component.java:3841)
     java.awt.Container.dispatchEventImpl(Container.java:2024)
     java.awt.Window.dispatchEventImpl(Window.java:1778)
     java.awt.Component.dispatchEvent(Component.java:3803)
     java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
     e.debug.EventDispatchThreadHangMonitor.dispatchEvent(EventDispatchThreadHangMonitor.java:191)
     java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)
     java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
     java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
     java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
     java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
  2007-04-20T17:43:47.664-0700 Evergreen: (hang #6) event dispatch thread unstuck after 211885 ms.

src/e/edit/BuildAction.java: this code needs to be removed, but we'll still provide a perfectly good error message.

src/e/edit/Evergreen.java: this exception-ignoring cruft can be removed.

2007-04-21 21:17:49 +0100 / enh / revision 1117

www/index.html: reformat to one sentence per line. Update the section about where we'll look for Exuberant ctags now we try harder.

2007-04-20 07:39:38 +0100 / enh / revision 1116

src/e/edit/TagReader.java: Kees Jongenburger tells us that Gentoo calls Exuberant ctags "exuberant-ctags", and car's new Exuberant ctags package for Solaris calls it "ectags" because the already-installed GNU ctags has taken "ctags". Most other systems let Exuberant ctags be *the* "ctags", though, so still default to that.

2007-04-20 06:45:57 +0100 / car / revision 1115

src/e/edit/FindAndReplaceAction.java: If sufficient meat has been removed from the buffer that the old caret position is out of bounds, the user gets an error message saying "Couldn't Replace" despite the fact that the replace was successful. This is a fix.

This is a simplistic solution, and it's wrong – the caret shouldn't jump to the end just because the buffer's shorter than it was. However, it's a better way to fail than to throw a dialog and confuse the user.

2007-04-18 07:01:31 +0100 / enh / revision 1114

src/e/edit/Advisor.java: I'm still not sure of the appropriate interface, but for now make the whole ETextWindow available to researchers...

src/e/edit/WorkspaceResearcher.java: ...in their "research" methods.

src/e/edit/JavaResearcher.java: that lets me reinstate all of the long-broken functionality in the JavaResearcher, slightly more intelligently than it was before it was broken. We should now document selected classes or methods, and do something sensible inside a constructor's opening parenthesis or after the dot after a class name. I've long since realized that we probably need to make some distinctions between "show me the documentation" and "remind me of the parameter types" and so on, but in this patch I'm just trying to get back to where we used to be (plus a few easy improvements).

src/e/edit/ManPageResearcher.java:
src/e/edit/NumberResearcher.java:
src/e/edit/PerlDocumentationResearcher.java:
src/e/edit/RubyDocumentationResearcher.java:
src/e/edit/StlDocumentationResearcher.java: track API change.

2007-04-17 07:56:08 +0100 / enh / revision 1113

src/e/edit/EvergreenMenuBar.java: move "File Properties..." to the right menu (though I'm keeping the slightly redundant name because there's a "Workspace Properties..." to come), and move "Build Project" to a more appropriate menu. There are more changes necessary, but these are the things that are moving without otherwise changing.

2007-04-17 07:47:22 +0100 / enh / revision 1112

src/e/edit/AutoCompleteAction.java: make it possible to use the auto-complete window with the mouse. This shouldn't be very useful in practice, but it does mean that Linux users have a way of getting rid of the window until we work around the wrong-headed "focus stealing prevention" nonsense.

2007-04-17 07:02:03 +0100 / enh / revision 1111

src/e/edit/AutoCompleteAction.java: the current default GNOME window manager (turd of Satan that it is) takes Alt-Escape for itself, so use Alt-Space like IDEA and Visual Studio if we're not on Mac OS. This still doesn't fix completion for GNOME because the current default GNOME window manager (giant malodorous turd of Satan that it is) sticks its retarded "focus stealing prevention" in the way.

2007-04-13 06:32:44 +0100 / car / revision 1110

lib/SunOS/preinstall: Build a big ugly PATH from a number of sensible sources. If /usr/bin/ruby doesn't exist, trawl the big ugly PATH to find the first ruby, install a symbolic link. Otherwise, exit, thus aborting package install.

2007-04-13 06:29:21 +0100 / car / revision 1109

lib/SunOS: Somewhere to keep install scripts.

2007-04-11 20:19:36 +0100 / enh / revision 1108

bin/evergreen: exit quietly, without raising an exception.

2007-04-11 09:44:44 +0100 / mad / revision 1107

src/e/edit/Evergreen.java: openRememberedWorkspaces called addWorkspace called createWorkspace called (a different overloading of) addWorkspace and made my head spin. As usual, when there's a clash, I've tried to pick better names for both. "openWorkspace" is consistent with the status bar message and the calling method.

I'm wondering which code should be responsible for turning the tab red when the root directory doesn't exist, because it's not in the right place at the moment.

2007-04-11 05:06:05 +0100 / enh / revision 1106

bin/evergreen: say who we are.

2007-04-10 06:46:44 +0100 / enh / revision 1105

bin/evergreen: comment a bug that caused johnh to have great difficulty with "crontab -e" this morning.

2007-04-10 06:45:00 +0100 / enh / revision 1104

bin/evergreen: shove all the code into a class, fix the indentation to be four spaces, and use the new launch script style I've already applied to Terminator.

2007-04-02 05:23:13 +0100 / enh / revision 1103

src/e/edit/Evergreen.java: replace the fixed-length "long enough" sleep with simplistic code to wait for the event queue to clear.

2007-03-20 05:50:27 +0000 / enh / revision 1102

src/e/edit/AddWorkspaceAction.java:
src/e/edit/AutoCompleteAction.java:
src/e/edit/BuildAction.java:
src/e/edit/CloseWindowAction.java:
src/e/edit/CompareSelectionAndClipboardAction.java:
src/e/edit/CorrectIndentationAction.java:
src/e/edit/EditWorkspaceAction.java:
src/e/edit/EvergreenMenuBar.java:
src/e/edit/FilePropertiesAction.java:
src/e/edit/FindAction.java:
src/e/edit/FindAndReplaceAction.java:
src/e/edit/GotoAction.java:
src/e/edit/InsertInterfaceAction.java:
src/e/edit/KillErrorsAction.java:
src/e/edit/NewFileAction.java:
src/e/edit/OpenAction.java:
src/e/edit/OpenMakefileAction.java:
src/e/edit/RemoveWorkspaceAction.java:
src/e/edit/RescanWorkspaceAction.java:
src/e/edit/RevertToSavedAction.java:
src/e/edit/SaveAction.java:
src/e/edit/SaveAllAction.java:
src/e/edit/SaveAsAction.java:
src/e/edit/SetBuildTargetAction.java:
src/e/edit/ShowCounterpartAction.java:
src/e/edit/ShowDocumentationAction.java: use configureAction where we can, and tidy up some useless static final string fields.

2007-03-10 06:09:39 +0000 / enh / revision 1101

src/e/edit/EErrorsWindow.java: make "Check in Changes..." available from the errors window's pop-up menu.

src/e/edit/EColumn.java: make "Open Quickly...", "Find in Files...", and "Check in Changes..." available from an empty workspace.

2007-03-08 07:00:14 +0000 / enh / revision 1100

src/e/edit/ETextWindow.java: each time I've seen these regular expressions lately, I've thought "that's a long-winded way of writing a character class". So use a character class. Note that this matches long sequences than it used to: "<<<<<<<" is no longer a special case when it comes to allowing commentary. I don't think this is any use, but I don't think it does any harm, and I think it makes for a clearer regular expression.

2007-03-08 06:43:31 +0000 / enh / revision 1099

src/e/edit/WorkspaceFileList.java: favor contains over indexOf.

2007-03-07 23:58:10 +0000 / mad / revision 1098

src/e/edit/ETextWindow.java: Now these regular expressions include ^, we need (?m) or findInText (which ends up in smartCaseCompile) won't match anything unless the conflict marker is at the start of the document.

2007-03-06 07:03:55 +0000 / enh / revision 1097

src/e/edit/Evergreen.java:
src/e/edit/TagsPanel.java: use BorderFactory where possible.

2007-03-06 06:29:20 +0000 / enh / revision 1096

src/e/edit/TagsUpdater.java: this code has been begging for a Stopwatch.

2007-03-06 06:15:26 +0000 / enh / revision 1095

src/e/edit/Evergreen.java:
src/e/edit/JavaDoc.java:
src/e/edit/JavaResearcher.java:
src/e/edit/ManPageResearcher.java:
src/e/edit/StlDocumentationResearcher.java:
src/e/edit/WorkspaceFileList.java: upgrade the easy cases to use System.nanoTime/TimeUtilities.nsToString.

2007-03-05 06:56:02 +0000 / enh / revision 1094

src/e/edit/TagsUpdater.java: pass the original file's character set encoding name through...

src/e/edit/TagReader.java: ...so that we can read the tags correctly (assuming ctags(1) didn't mangle them).

src/e/edit/FindInFilesDialog.java: fake this case.

2007-03-04 01:37:26 +0000 / enh / revision 1093

src/e/edit/Evergreen.java:
src/e/edit/Workspace.java: remember the last-focused file on each workspace across restarts.

2007-03-04 01:14:24 +0000 / enh / revision 1092

src/e/edit/Evergreen.java: I actually didn't use the solution from java.util.prefs.XmlSupport because it was uglier than this one, and equally implementation-dependent. Way to go, XML weenies!

2007-03-04 01:04:16 +0000 / enh / revision 1091

src/e/edit/Evergreen.java: fix indentation of our XML saved-state file. An ugly API backed up by weak documentation conspire to make this non-obvious, and most examples on the web incorrect.

2007-03-03 07:26:52 +0000 / enh / revision 1090

src/e/edit/ShowHideTagsAction.java: make sure the check box menu item has the right text.

2007-03-03 07:22:39 +0000 / enh / revision 1089

src/e/edit/EvergreenMenuBar.java:
src/e/edit/ShowHideTagsAction.java: the fact that Action's "selected" pseudo-property isn't available until Java 6 (which isn't out for Mac OS yet) makes implementing Mac OS-like behavior (of changing the menu item text) more important than I realized.

2007-03-03 03:00:29 +0000 / enh / revision 1088

src/e/edit/ETextWindow.java: neilb has complained several times this week that Evergreen doesn't highlight all wiggle(1) merge conflict markers. (This is the nearest anyone's come to telling me they like the feature!)

2007-03-02 17:16:55 +0000 / mad / revision 1087

src/e/edit/ShowHideTagsAction.java: Bodge the Java 5 build.

2007-03-02 07:18:48 +0000 / enh / revision 1086

src/e/edit/ShowHideTagsAction.java:
src/e/edit/EvergreenMenuBar.java: Sébastien Pierre provided a patch for a menu item to show/hide the tags panel...

src/e/edit/Evergreen.java: ...which in the original here only made the split pane accessible. I'd been meaning to store and restore the split pane divider position for a long time, though, so this seemed like a perfect opportunity to round off Sébastien's patch (by persisting the tags panel's shown/hidden state) and add the occasionally-requested minor feature. That in turn led to further tidying up of the way we set up our initial state, in particular gathering up the growing collection of fields representing the desired initial state into a new object.

2007-02-28 07:58:59 +0000 / enh / revision 1085

src/e/edit/ChangeFontAction.java: Sébastien Pierre sends us a fix for the breakage I caused in revision 692, where I improved the default fixed font, but made it impossible to configure an alternative if you didn't like the default.

2007-02-26 04:16:17 +0000 / enh / revision 1084

src/e/edit/ETextWindow.java: update the tags as a side-effect of fillWithContent, the specific bug I'm fixing being that "Revert to Saved" wasn't causing the tags to update.

src/e/edit/TagsUpdater.java: we were updating tagsDigest at a point where we might still throw away our newly-built tags because, when it came to show them, we didn't have the latest sequence number. But if the thread with the latest sequence number checked the digest after we'd updated it, it would decide that the tags hadn't changed, because tagsDigest no longer corresponds with the displayed tags. So we must update tagsDigest only if we update the displayed tags. This was probably the root cause of many of the problems we've been seeing lately with tags not getting updated.

2007-02-25 06:58:25 +0000 / enh / revision 1083

src/e/edit/AdvisorHtmlPane.java: fix a more subtle use of System.err.

2007-02-22 07:21:15 +0000 / mad / revision 1082

TODO: The TODO file's always the last to get even cosmetic fixes.

2007-02-22 07:09:56 +0000 / mad / revision 1081

src/e/edit/Evergreen.java: I'm not sure where my c:\cygwin\Projects workspace got its path from but we didn't canonicalize the drive letter to a capital, so Evergreen (on this new installation) was failing to parse its saved addresses as if I'd never made the drive letter hack.

2007-02-22 07:08:18 +0000 / mad / revision 1080

src/e/edit/FindInFilesDialog.java: Stop Find in Files from always failing with an "Unexpected internal error" on Windows. The stack trace was crucial to finding the problem, so leave the necessary Log.warn line in the source, albeit commented-out because it also gets invoked whenever the user makes a syntax error. The Log.warn below it looks wrong.

2007-02-22 05:52:14 +0000 / enh / revision 1079

src/e/edit/EvergreenMenuBar.java: HelpMenu now gets the application name from Log.

2007-02-22 05:34:52 +0000 / enh / revision 1078

src/e/edit/FindAndReplaceAction.java: Chris Reece reports yet another place where JLabel's crazy idea that it should be zero-height if it's displaying the empty string causes us grief. (Strictly, this is slightly different from usual in that this is with HTML content, so the JLabel is being given something like "<html><font color=blue></color></html>" rather than "", but it doesn't seem to make any difference to our old enemy JLabel.) Chris was matching "^ $" and replacing with "", causing the replacement list's rows to be squished. Searching for " *$" in a file with zero-length lines would have had a similar effect in the matches list. Use the usual solution of substituting " " for "" before letting JLabel get its retarded mitts on the string.

2007-02-21 06:34:02 +0000 / enh / revision 1077

src/e/edit/AdvisorHtmlPane.java:
src/e/edit/EditServer.java:
src/e/edit/ETextWindow.java:
src/e/edit/Evergreen.java:
src/e/edit/InsertInterfaceAction.java:
src/e/edit/JavaDoc.java: comment out/remove/redirect debugging output.

2007-02-20 01:30:45 +0000 / enh / revision 1076

src/e/edit/OpenQuicklyDialog.java: specify missing type parameter.

2007-02-20 01:03:12 +0000 / enh / revision 1075

src/e/edit/WatermarkViewPort.java: fix a trivial caller of FontMetrics.stringWidth (see Sun bug 4248641).

2007-02-19 20:25:07 +0000 / enh / revision 1074

src/e/edit/Evergreen.java: remove useless code.

2007-02-18 06:48:51 +0000 / enh / revision 1073

src/e/edit/FindAndReplaceAction.java:
src/e/edit/FindInFilesDialog.java:
src/e/edit/OpenQuicklyDialog.java: track API change.

2007-02-18 06:15:35 +0000 / enh / revision 1072

src/e/edit/TagsUpdater.java: car points out that there's no way to go from the tags panel to the text using the keyboard. Bind both of the obvious "do something" keys.

2007-02-16 05:18:47 +0000 / car / revision 1071

lib/evergreen-128.png:
lib/Evergreen.icns:
lib/evergreen.ico: Prettier icons.

lib/evergreen-512.png: And a big one, just for Elliott.

2007-02-13 03:56:50 +0000 / enh / revision 1070

src/e/edit/OpenQuicklyDialog.java: use SwingWorker to set up the list model off the EDT.

2007-02-12 23:06:42 +0000 / mad / revision 1069

src/e/edit/ShellCommand.java: Fix building from Evergreen on Cygwin which has been broken since I switched it to use bash --login as the shell, if available, rather than cmd.exe. We piggy-back off someone else's work-around for the, well let's just say "odd", Cygwin /etc/profile.

2007-02-11 20:02:20 +0000 / enh / revision 1068

www/index.html: make the ctags instructions clearer.

2007-02-08 07:19:37 +0000 / enh / revision 1067

src/e/edit/Evergreen.java:
src/e/edit/EvergreenMenuBar.java: track API changes.

2007-02-07 01:42:47 +0000 / mad / revision 1066

src/e/edit/Evergreen.java: Greedily match a Windows drive specification, so that we parse our own saved-state.xml files correctly and reload open files on starting rather than complaining that "C" doesn't exist. Perhaps there's a more tasteful way of doing this, or perhaps it's worth a code comment, but this is at least tested.

2007-02-05 06:37:15 +0000 / enh / revision 1065

src/e/edit/TagReader.java: the code to run ctags(1) had always been wrong in that it wasn't closing the child's streams, but it's only started causing me trouble recently, and even then seemingly only on Ubuntu.

src/e/edit/FindInFilesDialog.java:
src/e/edit/TagsUpdater.java: while I'm poking about with this code, rather than construct a new tree model for an unchanged set of tags, only to throw it away, don't even construct it if we know we're going to throw it away.

2007-02-03 06:44:05 +0000 / enh / revision 1064

src/e/edit/Evergreen.java: bump copyright date.

2007-02-03 06:43:15 +0000 / enh / revision 1063

src/e/edit/Evergreen.java: remove debugging output.

src/e/edit/Workspace.java: fix a source of NullPointerExceptions, remove useless synchronization, and improve documentation.

2007-02-03 06:16:49 +0000 / enh / revision 1062

src/e/edit/Evergreen.java: speed start-up by only opening those files that are going to be visible. Basically, we keep a list of workspaces-to-be, each of which has a list of files-to-be. We create all the workspaces early on, because we need them to populate the tabbed pane. But only as a workspace gets selected do we actually load its files.

src/e/edit/Workspace.java: this class is now responsible for setting the tabbed pane tab titles, add has to add the number of actually loaded files to the number of pending files to work out what number goes in parentheses in the title.

src/e/edit/EColumn.java: this class now tells the workspace to update the tab title, rather than doing it itself. We also have to make sure we set the width of newly-added components; we always did in the heuristic case (which is what you'd use if you were adding files after the application has started) but used to get away without doing it in the non-heuristic case, for some reason, and now we don't. Perhaps because before we were added before the tab was first shown (and maybe it stretched us to fit when it was shown?) but now we're added after it's already showing?

src/e/edit/JavaResearcher.java: make it easy for the start-up code to spin initialization of this class off onto a separate thread.

2007-02-01 06:18:53 +0000 / enh / revision 1061

src/e/edit/TagReader.java: I've been having trouble on Ubuntu lately where Evergreen uses up all available file descriptors for pipes, leading to an inability to run "ctags" (java.io.Exception: error=24, Too many open files). This doesn't address the underlying problem, whatever it is, but it does mean I don't slowly fill /tmp with zero-length files while the situation persists.

2007-02-01 04:25:16 +0000 / mad / revision 1060

src/e/edit/WorkspaceFileList.java: Fix Ed's problem caused by my change here the other day without breaking what I fixed. He has a symlink to a directory like ../salma-hayek from within a workspace root like Evergreen. Now we follow such symlinks without following symlinks within the workspace, which would give us duplicate paths to the same file and (potentially) cycles.

2007-02-01 01:51:48 +0000 / mad / revision 1059

Makefile: To avoid hiding universal.make's history with a Subversion "rename", we must now include a different filename.

2007-01-30 03:01:55 +0000 / mad / revision 1058

src/e/edit/WorkspaceFileList.java: The isSymbolicLink call had been inside the check for isDirectory since isSymbolicLink bogusly returned true for files with symbolic links on their paths. If the isSymbolicLink had been where I've now put it and your workspace was underneath a symbolic link (as many of mine have historically been) then the file list would have been entirely empty. Shortly after the Subversion import, however, isSymbolicLink's bogosity tripped me up in another way and I came up with a (blog-worthy?) fix.

Now I've just tripped over the call being in the wrong place. For reasons possibly due to a temporary hack I put in BlueArc's makerules, I have the following symlink:

/home/martind/work/parrot/libs/eventlog/generated/new/generated -> .

I'm surprised that Evergreen coped gracefully with that. I saw no exceptions and had no cause all day to think that the file list had been truncated (so maybe it was and maybe it wasn't). The file list did, however, include some very long file names.

I have explicitly tested this using a workspace whose root directory is a symbolic link. The first time we apply the isSymbolicLink test is on the contents of the root directory, so we never check the file type of the workspace root itself.

2007-01-27 23:12:47 +0000 / enh / revision 1057

src/e/edit/ETextWindow.java: fix bug database link highlighting, which had been broken since I fixed switching file type on the fly.

2007-01-23 02:19:17 +0000 / enh / revision 1056

src/e/edit/ETextWindow.java: remove just the final extension from the filename whose counterpart we're looking for. Removing all the extensions means we can't find the counterpart for something like "hello.world.cpp".

2007-01-22 03:33:48 +0000 / enh / revision 1055

www/index.html: put the heading back.

2007-01-22 03:19:24 +0000 / enh / revision 1054

www/index.html: remove another piece of boilerplate.

2007-01-22 03:18:08 +0000 / enh / revision 1053

www/index.html: remove boilerplate.

2007-01-18 05:10:58 +0000 / enh / revision 1052

src/e/edit/GotoAction.java: car points out that our range checking was wrong here, because it was assuming lines numbered from 0 rather than 1. We also weren't rejecting non-positive numbers as we ought. While I'm here, make more of an effort to say things only once.

2007-01-16 06:51:59 +0000 / enh / revision 1051

src/e/edit/Evergreen.java: another minor improvement while I'm still psyching myself up for a big rewrite of the start-up process — go straight to the right workspace, and stay there. It doesn't make us start up any faster, but it does make us look more like we know what we're doing.

2007-01-15 06:59:41 +0000 / enh / revision 1050

src/e/edit/Evergreen.java: make it possible for various bits of background work to wait until we've finished starting up (other than doing their work).

src/e/edit/TagsUpdater.java: wait, defer some work until we know we need to do it, and also add logic to discard work if we realize that the demand for it has passed because the results would be out of date.

src/e/edit/WorkspaceFileList.java: wait.

2007-01-15 04:19:07 +0000 / enh / revision 1049

src/e/edit/Evergreen.java: martind inadvertently pointed out that we weren't actually finishing the GNOME start up notification, and were relying on the timeout. (I didn't realize this until just now, while looking at the code.)

2007-01-10 06:38:32 +0000 / enh / revision 1048

src/e/edit/OpenQuicklyDialog.java: track API change.

2006-12-25 20:25:24 +0000 / enh / revision 1047

src/e/edit/Advisor.java: enp asked that the help window close if the user hits escape, just like it was a dialog. Although it's a little odd for a window to behave like a dialog, in this context it doesn't seem like there's any possibility for ambiguity in the user's request; what else could pressing escape mean? It seems unlikely that anyone who doesn't want this behavior would trip over it.

2006-12-24 07:28:06 +0000 / enh / revision 1046

src/e/edit/Evergreen.java:
src/e/edit/SaveAllAction.java: while we're here, "Save All" only makes sense if you've got some dirty texts. (This also means there's now a cheap way to see if there's anything dirty on any workspace, without manually going through them all.)

2006-12-24 06:57:01 +0000 / enh / revision 1045

src/e/edit/ETextWindow.java:
src/e/edit/RevertToSavedAction.java: disable "Revert to Saved" when there's nothing to revert.

2006-12-22 21:03:48 +0000 / enh / revision 1044

src/e/edit/RescanWorkspaceAction.java: pull the code for the "Rescan" button out of OpenQuicklyDialog, and make the menu item's icon match the button icon.

src/e/edit/FindInFilesDialog.java: add a "Rescan" button to "Find in Files".

src/e/edit/OpenQuicklyDialog.java: make "Open Quickly" non-modal, like "Find in Files".

2006-12-22 17:54:43 +0000 / enh / revision 1043

www/index.html: add a document type and character encoding.

2006-12-22 17:50:37 +0000 / enh / revision 1042

www/index.html: add short descriptions of images for non-graphical browsers.

2006-12-22 17:45:08 +0000 / enh / revision 1041

www/index.html: fix an error Evergreen can now spot.

2006-12-20 03:04:35 +0000 / enh / revision 1040

src/e/edit/FindInFilesDialog.java: my recent changes reintroduced the old problem where we'd have two dialogs on the display, with the fields from the first ripped out for use in the second. It's an easy confusion to make when you have a class called FindInFilesDialog that isn't actually a dialog: you need to look at how it's implemented as well as how it's used if you want to make sure it's safe. So: don't rebuild the UI every time so we always use the same (real, native) dialog, and let our forms implementation take care of how to "showNonModal" a dialog that's already showing (by bringing it to the front).

2006-12-19 01:40:24 +0000 / enh / revision 1039

src/e/edit/Workspace.java: I believed that there was zero-or-one FindInFilesDialog and zero-or-one OpenQuicklyDialog for each Workspace. I was right about the OpenQuicklyDialog. This bug meant that the longer you used today's build, the more background searches you'd be collecting, and the slower it would get until you had to restart.

src/e/edit/FindInFilesDialog.java: but first I wandered down a bit of a blind alley trying to work out what was broken about FindInFilesDialog itself. In part because of something martind had complained about, which was the serialization of find requests, where you couldn't (for example) run multiple finds concurrently. This hid today's real problem, and I think that the separate (and per-Evergreen) thread pool for definition finding is sufficient protection against bringing the user's machine to its knees. So remove that restriction, and tidy some of this code up a bit.

2006-12-18 19:07:37 +0000 / mad / revision 1038

www/index.html: Remove forbidden link end tag.

2006-12-18 04:01:09 +0000 / enh / revision 1037

src/e/edit/WorkspaceFileList.java: remove isFileListUnsuitableFor, because that's not the kind of UI experience we want. Make other methods safe for use in a world where the file list can disappear because we're re-scanning.

src/e/edit/OpenQuicklyDialog.java:
src/e/edit/FindFilesContainingSelectionAction.java: track API changes.

src/e/edit/FindInFilesDialog.java: make "Find in Files" behave more like "Open Quickly".

2006-12-17 06:17:46 +0000 / enh / revision 1036

src/e/edit/OpenQuicklyDialog.java: bring the code in line with the comment. I think the comment was correct, and I assumed that toFront would get me the focus back (which is often not the case on Linux thanks to GNOME's "focus stealing prevention" which seems to cause more problems than it solves).

2006-12-17 06:15:00 +0000 / enh / revision 1035

src/e/edit/WorkspaceFileList.java: add a means for interested objects to be notified as the file list becomes invalid and valid.

src/e/edit/OpenQuicklyDialog.java: change "Open Quickly" to use the new interface. This keeps its "Rescan" button working and also means that you can open "Open Quickly" before the file list for a workspace is available, and it will be as if you'd hit "Rescan".

2006-12-17 00:58:30 +0000 / enh / revision 1034

src/e/edit/OpenQuicklyDialog.java: use the appropriate GNOME icon for the "Rescan" button.

2006-12-17 00:48:35 +0000 / enh / revision 1033

src/e/edit/Workspace.java: pull the file list code out...

src/e/edit/WorkspaceFileList.java: ...into a new class.

src/e/edit/FindFilesContainingSelectionAction.java:
src/e/edit/FindInFilesDialog.java:
src/e/edit/JavaDoc.java:
src/e/edit/OpenQuicklyDialog.java:
src/e/edit/RescanWorkspaceAction.java: track API change.

src/e/edit/AddWorkspaceAction.java:
src/e/edit/EditWorkspaceAction.java:
src/e/edit/Evergreen.java: these three callers were all unnecessary because the file list was being implicitly updated by surrounding code that was either constructing Workspace instances or calling setRootDirectory.

2006-12-12 23:30:45 +0000 / enh / revision 1032

src/e/edit/Evergreen.java: my previous "quick fix" to the saving-atomically-on-CIFS problem was broken because the FileOutputStream was not being closed in time (or at all, explicitly). So rip that cruft out and replace it with a new method that should move to StringUtilities when it's had more real-life testing, or when we next need to save text atomically. The current implementation is based on the ETextWindow save code.

2006-12-12 21:47:50 +0000 / mad / revision 1031

src/e/edit/Evergreen.java: Code that's strictly incorrect (albeit an adequate approximation) deserves a comment. We might be able to write this a better way (perhaps by trying the rename without the delete first) but we'll want to find out why the rename is failing on Windows even when the destination file has been deleted. Elliott went away to look at the source...

2006-12-12 20:20:01 +0000 / mad / revision 1030

src/e/edit/Evergreen.java: File.renameTo returns a boolean rather than throwing an exception. We've no idea (yet) why this happens:

2006-12-12T12:17:16.563-0800 Evergreen: Failed to rename c:\Documents and Settings\martind\.e.edit.Edit\saved-state.xml2 to c:\Documents and Settings\martind\.e.edit.Edit\saved-state.xml

But at least we now know it is failing.

2006-11-29 07:24:33 +0000 / enh / revision 1029

src/e/edit/Evergreen.java: be a little more helpful when the user is trying to quit with unsaved changes.

2006-11-26 06:51:19 +0000 / enh / revision 1028

src/e/edit/EvergreenMenuBar.java: flesh out the "Documentation" menu with some of the most useful on-line documentation.

2006-11-24 06:10:22 +0000 / enh / revision 1027

src/e/edit/Evergreen.java: add our contact address to the about box.

src/e/edit/EvergreenMenuBar.java: add an explicit link to the regular expression documentation from our "Documentation" menu.

src/e/edit/FindAndReplaceAction.java:
src/e/edit/FindInFilesDialog.java: add more direct links to the regular expression documentation from our dialogs that use regular expressions. Also bring regular expression syntax errors next to the fields they apply to in the "Find in Files" dialog.

2006-11-13 02:50:04 +0000 / enh / revision 1026

src/e/edit/FileType.java: lose FileType to salma-hayek.

src/e/edit/InsertInterfaceAction.java:
src/e/edit/TagReader.java: track change.

2006-11-13 02:44:23 +0000 / enh / revision 1025

src/e/edit/ETextWindow.java: lose the PTextArea configuration...

src/e/edit/FileType.java: ...to FileType, which saves us a bunch of repetition and makes it easier to add new file types in future.

2006-11-12 21:16:28 +0000 / enh / revision 1024

src/e/edit/Evergreen.java: cheap (but untested) work-around for the problem where Evergreen can't save its state when run on Windows.

2006-11-12 18:50:22 +0000 / enh / revision 1023

src/e/edit/Evergreen.java: we weren't constraining the main window to the screen. I think our dialogs are already okay.

2006-11-10 22:50:18 +0000 / enh / revision 1022

src/e/edit/Evergreen.java: lose code to salma-hayek.

2006-11-09 05:10:00 +0000 / enh / revision 1021

src/e/edit/FileType.java: we can detect arbitrary XML-based formats by content, which is probably better than listing all the alternatives.

2006-11-08 17:35:35 +0000 / mad / revision 1020

src/e/edit/FileType.java: The WiX installer files are XML. I'd love it if Evergreen took care of the indentation and I wouldn't care how it indented. Well, having the whole thing on one line would be inconvenient to edit but you know what I mean.

2006-11-08 17:26:42 +0000 / enh / revision 1019

src/e/edit/FileType.java: add a new blanket "XML" file type for XML-like files.

src/e/edit/ETextWindow.java: use our new styler for XML files.

2006-11-07 01:01:08 +0000 / enh / revision 1018

src/e/edit/Evergreen.java: although the current implementation is the same, keep system properties distinct from application preferences.

2006-11-07 00:36:46 +0000 / mad / revision 1017

I had some HTML to edit which contained some pre-formatted C++. I needed the indentation to be preserved when I pasted in a large update. The guesser was guessing "C++". One approach would have been to make some token effort at supporting HTML but allowing the user to override our guess also seems like a worthwhile facility.

src/e/edit/ETextWindow.java: Turn word wrapping off when changing away from PLAIN_TEXT. Select the appropriate styler when changing to PLAIN_TEXT. Select the default indenter for file types where we don't yet have an indenter. Make it possible to change to a file type other than that chosen by the file type guesser.

src/e/edit/FileType.java: Reimplement valueOf as "fromName", undoubtedly less tastefully, but using the friendly names. Similarly clumsily, supply a sorted collection of all the friendly names for use in initializing a combo box...

src/e/edit/FilePropertiesAction.java: ... for use when replacing fileTypeField with a combo box to let the user override that choice. Sadly or otherwise, we revert to the guessed type when the user saves. Remove obsolete, unused charsetStringField, dating from before that choice was a combo box.

2006-11-04 02:01:55 +0000 / enh / revision 1016

src/e/edit/FindAndReplaceAction.java: "tool tip" is two words.

2006-11-04 01:57:32 +0000 / enh / revision 1015

src/e/edit/FindAndReplaceAction.java: make use of the FormDialog API change to keep the dialog up if there's an error when the user clicks "Replace", rather than having to re-open the dialog.

2006-11-04 01:48:33 +0000 / enh / revision 1014

src/e/edit/ETextWindow.java: warn if the user tries to save a file containing characters that can't be encoded with the file's current character encoding.

2006-11-04 01:29:50 +0000 / enh / revision 1013

src/e/edit/FindInFilesDialog.java: track API change.

src/e/edit/FilePropertiesAction.java: offer alternative character encodings in a combo box rather than a text field, in the hope that will make it more obvious that you can change the encoding. We only offer those ones we're capable of reliably detecting if asked to read them back in! We now give a warning if you try to change to a character encoding that can't represent every character currently in your document. Additionally, we should either prevent you from entering characters that can't be encoded, or – perhaps better – warn at save time that we can't save without mangling your document. (We should also offer some help in fixing the problem characters.)

2006-10-21 07:39:28 +0100 / enh / revision 1012

src/e/edit/EvergreenTabbedPane.java:
src/e/edit/FindAndReplaceAction.java:
src/e/edit/TagsPanel.java: use the known-safe "<html><body>" instead of just "<html>" when giving HTML to Swing. The find/replace functionality was what brought this problem to my attention: lines that started "//" or "/*" weren't rendering properly. The pre-CVS ChangeLog suggests I've been here before and fixed (and regressed) this, submitted a bug to Sun that was closed as "not a bug", written a blog post (http://elliotth.blogspot.com/2006/10/using-html-in-swing-components.html) and come back to fix all my code in the hope that I'll remember that "<html><body>" is the safe idiom, even if just "<html>" is more common.

2006-10-11 07:00:20 +0100 / enh / revision 1011

lib/data/spelling-exceptions-Pytho