2010-07-26 05:11:13 +0100 / enh / revision 1714
src/e/edit/Evergreen.java: undocumented hack-an-XML-file support for having the tags on the left. I tend to keep Find in Files windows up a long time, and I tend to position them on the right of my display. This has the unfortunate side-effect of hiding most of the tags. As long as we (unlike our ancestors) only support a single column of text windows, the right of the text column tends to be pretty empty, so maybe moving the tags to the left will – at the expense of some readjustment – let me have the best of both worlds. To try this, start and quit a version with this patch, then edit saved-state.xml to change "tagsPanelOnLeft" to "true". Restart, reposition the split pane manually, and quit again to save that change.
2010-04-03 17:20:42 +0100 / enh / revision 1713
src/e/edit/OpenQuicklyAction.java: if the clipboard contains an entire Java file, don't assume it's a filename because it starts with "/". I'm surprised I've never hit this before; I suppose most comments are indented, and we don't trim.
2010-03-21 18:19:57 +0000 / enh / revision 1712
src/e/edit/AdvisorHtmlPane.java:
src/e/edit/JavaDoc.java:
src/e/edit/ShowHideTagsAction.java: we now require Java 6.
2010-03-20 06:00:53 +0000 / enh / revision 1711
src/e/edit/GoToTagAction.java:
src/e/edit/ShowMisspellingsAction.java:
src/e/edit/SimplePatchDialog.java: these seem like likely candidates for similar widescreen treatment, even if they haven't been bothering me. Their labels didn't contain any useful information, so we may as well use that space for something more important.
2010-03-20 05:55:23 +0000 / enh / revision 1710
src/e/edit/FindInFilesDialog.java:
src/e/edit/OpenQuicklyDialog.java: let's not waste huge amounts of space in our two most content-packed dialogs. I'm constantly making these dialogs wider to cope with deep directory structures, then narrower again to see more of my code. It looks odd at first, because we're so used to the wasted space, but I wish this had dawned on me years ago...
2010-03-12 04:37:18 +0000 / enh / revision 1709
src/e/edit/TagReader.java: methods in Java interfaces are implicitly "abstract".
2010-01-25 18:20:12 +0000 / mad / revision 1708
src/e/edit/TagsUpdater.java: The reasons for case-insensitivity were useful and only available in Ed's email archive. I found the examples compelling but I don't much use the tags feature, so anyone else should feel encouraged to modify as they see fit.
2010-01-24 05:12:07 +0000 / enh / revision 1707
src/e/edit/TagsUpdater.java: improve sorting of tags to remain basically case-insensitive but to fall back to a deterministic case-sensitive order when two tags compare equal case-insensitively. The motivating examples was harmony's java.util.Formatter, which had transform_a, transform_A, transform_b, transform_B, transform_c, and transform_C (et cetera) where we'd potentially choose a different order for each pair (such as aAbBCc, instead of aAbBcC).
2010-01-22 05:46:24 +0000 / enh / revision 1706
src/e/edit/TagsUpdater.java: case-insensitive tag sorting hasn't bothered me in 5 years, but today I was editing Android's java.util.Formatter.java which has a method for each conversion type, and the order transform_a, transform_A, transform_b, transform_B, transform_C, transform_c was disturbing (I don't much care whether lowercase comes before uppercase, or the other way around, as long as it's consistent). The awkward thing is that this code was originally case-sensitive and r343 made it case-insensitive with the enlightening comment "sort tags case-insensitively". So if there was a reason, it's lost in the mists of time. This might motivate us to rediscover the reason, because it seems like a bad choice on the face of it.
2010-01-11 01:04:16 +0000 / enh / revision 1705
src/e/edit/AdvisorHtmlPane.java:
src/e/edit/Parameters.java: remove unnecessary semicolons found by ecj.
2010-01-11 01:00:54 +0000 / enh / revision 1704
src/e/edit/EditServer.java:
src/e/edit/ETextWindow.java:
src/e/edit/EvergreenTabbedPane.java:
src/e/edit/ExternalToolAction.java:
src/e/edit/Minibuffer.java:
src/e/edit/NewWorkspaceAction.java:
src/e/edit/PythonDocumentationResearcher.java:
src/e/edit/RubyDocumentationResearcher.java:
src/e/edit/WorkspaceResearcher.java: fix unused import warnings found by ecj.
2009-12-13 18:56:26 +0000 / enh / revision 1703
TODO: more jobs.
2009-12-13 18:56:01 +0000 / enh / revision 1702
src/e/edit/EvergreenPreferences.java: ignore IntelliJ's ".iml", ".ipr", and ".iws" droppings.
2009-10-13 04:16:24 +0100 / enh / revision 1701
src/e/edit/Workspace.java: don't set EVERGREEN_CURRENT_WORD or EVERGREEN_CURRENT_SELECTION if it would contain a NUL byte.
2009-10-13 04:02:14 +0100 / enh / revision 1700
src/e/edit/ExternalToolAction.java: we want to know about any kind of Exception, not just IOException. Real users won't know to look in the log.
2009-10-07 04:21:36 +0100 / enh / revision 1699
src/e/edit/Evergreen.java: revert r1698.
2009-10-06 22:38:32 +0100 / pcn / revision 1698
Enable user-accepted spellings.
2009-10-04 18:33:14 +0100 / enh / revision 1697
www/index.html: add credits.
2009-09-07 18:43:04 +0100 / enh / revision 1696
src/e/edit/Diffable.java: switch to the new FileUtilities.createTemporaryFile variant. We could use fileType, if set, to provide a more descriptive extension, but code that uses Diffable can't rely on fileType having been set, so there seems little point. (In fact, it seems like it would encourage error if the extension was often but not always meaningful.)
2009-08-10 00:17:00 +0100 / enh / revision 1695
src/e/edit/Diffable.java: make it possible to explicitly declare (and later query) the FileType for a Diffable.
src/e/edit/CompareSelectionAndClipboardAction.java:
src/e/edit/ETextWindow.java: supply the appropriate FileType when creating Diffables.
src/e/edit/SimplePatchDialog.java: and use the FileType to configure the PTextArea that's showing the patch. This ensures we get the appropriate spelling exceptions. We also get language-specific coloring; we didn't reliably get it previously because we were trying to guess the file type from the possibly-temporary filenames, which don't have a useful extension, and from the patch content, which isn't generally recognizable as the source language.
2009-08-09 23:35:50 +0100 / enh / revision 1694
src/e/edit/ETextWindow.java: PTextArea now handles language-specific spelling exceptions itself (using roughly this code).
src/e/edit/Advisor.java:
src/e/edit/JavaResearcher.java:
src/e/edit/ManPageResearcher.java:
src/e/edit/PerlDocumentationResearcher.java:
src/e/edit/PythonDocumentationResearcher.java:
src/e/edit/RubyDocumentationResearcher.java:
src/e/edit/WorkspaceResearcher.java: SpellingChecker has a new mechanism for providing extra spelling exceptions at runtime.
src/e/edit/StlDocumentationResearcher.java: there weren't any interesting words being added here (and most people won't have the documentation installed anyway), so let's not bother.
2009-08-09 21:22:35 +0100 / enh / revision 1693
lib/data/spelling-exceptions:
lib/data/spelling-exceptions-C++:
lib/data/spelling-exceptions-Java:
lib/data/spelling-exceptions-Perl:
lib/data/spelling-exceptions-Python: the lists of spelling exceptions are now available to all PTextArea users.
src/e/edit/ETextWindow.java: track the location change.
2009-08-03 07:10:15 +0100 / enh / revision 1692
src/e/edit/ETextWindow.java:
src/e/edit/FilePropertiesAction.java: fix a bug where we never did any configuration of plain-text files because we thought we'd already done it.
2009-08-03 07:01:01 +0100 / enh / revision 1691
src/e/edit/ETextWindow.java: synchronize access to the shared but non-thread-safe HashMap used for per-language spelling exceptions.
2009-08-03 06:56:12 +0100 / enh / revision 1690
src/e/edit/ETextWindow.java: add support for non-language-specific spelling exceptions.
lib/data/spelling-exceptions: and make a start at providing such a list.
2009-08-03 06:03:07 +0100 / enh / revision 1689
src/e/edit/WorkspaceFileList.java: mad points out that with no upper bound on the number of threads we'll create for updating file lists, we make life difficult for people with lots of workspaces. The original motivation of having one thread per workspace was so that one workspace's file system being slow wouldn't affect other workspaces. In practice, a small pool may well be sufficient.
2009-07-29 03:35:06 +0100 / mad / revision 1688
src/e/edit/SimplePatchDialog.java: As explained in, for example, http://en.wikipedia.org/wiki/Diff#Context_format, the diff format generated here is "unified diff", not "context diff".
2009-07-29 03:19:55 +0100 / mad / revision 1687
src/e/edit/Diffable.java: I should be able to close a file that has modifications but which has been renamed underneath Evergreen. I contemplated not caching the result but that would have required a code-comment that I couldn't find plausible wording for.
2009-07-28T17:12:09.821-0700 Evergreen: Exception occurred during event dispatching.
Associated exception:
java.lang.RuntimeException: java.io.FileNotFoundException: /home/martind/work/tiger/fsb/fsi/FSIReadCacheNotifierPoolSize.h (No such file or directory)
at e.util.StringUtilities.readFileAsCharArray(StringUtilities.java:44)
at e.util.StringUtilities.readFile(StringUtilities.java:32)
at e.edit.Diffable.content(Diffable.java:74)
at e.edit.SimplePatchDialog.makePatchView(SimplePatchDialog.java:118)
at e.edit.SimplePatchDialog.makeScrollablePatchView(SimplePatchDialog.java:34)
at e.edit.SimplePatchDialog.makeDialog(SimplePatchDialog.java:207)
at e.edit.SimplePatchDialog.showPatchBetween(SimplePatchDialog.java:199)
at e.edit.ETextWindow.showPatchAndAskForConfirmation(ETextWindow.java:437)
at e.edit.ETextWindow.closeWindow(ETextWindow.java:478)
at e.edit.ECloseButton.actionPerformed(ECloseButton.java:54)
at e.edit.EButton.mouseReleased(EButton.java:35)
at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:272)
at java.awt.Component.processMouseEvent(Component.java:6263)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3267)
at java.awt.Component.processEvent(Component.java:6028)
at java.awt.Container.processEvent(Container.java:2041)
at java.awt.Component.dispatchEventImpl(Component.java:4630)
at java.awt.Container.dispatchEventImpl(Container.java:2099)
at java.awt.Component.dispatchEvent(Component.java:4460)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4574)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4238)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4168)
at java.awt.Container.dispatchEventImpl(Container.java:2085)
at java.awt.Window.dispatchEventImpl(Window.java:2475)
at java.awt.Component.dispatchEvent(Component.java:4460)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
at e.debug.EventDispatchThreadHangMonitor.dispatchEvent(EventDispatchThreadHangMonitor.java:191)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
Caused by: java.io.FileNotFoundException: /home/martind/work/tiger/fsb/fsi/FSIReadCacheNotifierPoolSize.h (No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:106)
at e.util.ByteBufferUtilities.readFile(ByteBufferUtilities.java:23)
at e.util.StringUtilities.readFileAsCharArray(StringUtilities.java:37)
... 32 more
src/e/edit/SimplePatchDialog.java: With the above change, the patch presented is still wrong, even when useInternalDiff is changed to false. That's easily fixed, here, by the addition of -N. I'll have a look at that next but a cosmetic issue in this file is sticking in my craw and I want to address that first, in a separate check-in.
2009-07-28 05:39:23 +0100 / enh / revision 1686
src/e/edit/EvergreenPreferences.java: we don't want .eps any more than .ps, and .hprof (dumped Java profile data) isn't worth searching either.
2009-07-19 05:35:29 +0100 / enh / revision 1685
src/e/edit/SimplePatchDialog.java: make the hunk headers less bogus, and flip the switch to see how we get on.
2009-07-19 05:11:05 +0100 / enh / revision 1684
src/e/edit/SimplePatchDialog.java: make it easy to switch between diff implementations, and a first attempt at turning our raw diffs into context diffs. The hunk headers are wrong, but I think the rest is right.
2009-07-19 04:33:38 +0100 / enh / revision 1683
src/e/edit/Diffable.java: Class.toString returns "class package.ClassName", but I only wanted "package.ClassName" here (and spaces in filenames look like a bug).
2009-07-19 04:32:11 +0100 / enh / revision 1682
src/e/edit/SimplePatchDialog.java: fix the ability to run SimplePatchDialog stand-alone.
2009-07-15 01:40:34 +0100 / mad / revision 1681
src/e/edit/EditServer.java: Lose waitForWindowToDisappear to salma-hayek. I've renamed "out" to "err" where we're using it for errors, in case we can one day distinguish. In an unchecked-in version, I'd changed EWindow to Component, in the hope of being able to collapse this class with the copy I'm working on in Terminator, but there now seems so little left that the abstraction would cause more confusion than it would save in maintenance.
2009-07-14 23:38:51 +0100 / mad / revision 1680
src/e/edit/EditServer.java: Looking at this code with a view to sharing it with Terminator, I saw we inflicted a backtrace on the user even for unexpected exceptions that aren't bugs, like this one:
martind@whitewater:~$ edit ~/badger
"~/badger/" is a directory and so cannot be edited with Evergreen.
martind@whitewater:~$
Burying them in the log seems (fine by me and) our usual policy.
The exception handler in run() is the one with the non-null ex.getMessage(). The other, around invokeAndWait, is only required to do battle with checked exceptions. This handler will never actually be called, except in the face of a bug, so logging seems the right choice there too.
2009-07-14 22:59:58 +0100 / mad / revision 1679
src/e/edit/Evergreen.java: ~/badger/ is not "directories", plural. Clearly it is possible to edit a directory, albeit not with Evergreen.
2009-07-07 18:23:51 +0100 / mad / revision 1678
src/e/edit/ETextAction.java: chooseStopChars needs an ETextWindow, so getWordAtCaret does too. One of its callers can provide the focused text window as easily as it provides the focused text area.
src/e/edit/Workspace.java: The other has a better idea of the text window than can be deduced from the focus. This fixes checking-in an unsaved file, where the focus goes to the Cancel, Don't Save, Save All dialog.
Associated exception:
java.lang.NullPointerException
at e.edit.ETextAction.chooseStopChars(ETextAction.java:94)
at e.edit.ETextAction.getWordAtCaret(ETextAction.java:86)
at e.edit.Workspace.makeShellCommand(Workspace.java:456)
at e.edit.ExternalToolAction.actionPerformed(ExternalToolAction.java:59)
at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318)
at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
at javax.swing.AbstractButton.doClick(AbstractButton.java:357)
at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:1225)
at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:1266)
at java.awt.Component.processMouseEvent(Component.java:6263)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3267)
at java.awt.Component.processEvent(Component.java:6028)
at java.awt.Container.processEvent(Container.java:2041)
at java.awt.Component.dispatchEventImpl(Component.java:4630)
at java.awt.Container.dispatchEventImpl(Container.java:2099)
at java.awt.Component.dispatchEvent(Component.java:4460)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4574)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4238)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4168)
at java.awt.Container.dispatchEventImpl(Container.java:2085)
at java.awt.Window.dispatchEventImpl(Window.java:2475)
at java.awt.Component.dispatchEvent(Component.java:4460)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
at e.debug.EventDispatchThreadHangMonitor.dispatchEvent(EventDispatchThreadHangMonitor.java:191)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
2009-06-30 03:33:55 +0100 / mad / revision 1677
src/e/edit/Workspace.java: Lose canonicalizePath to FileUtilities, now I have what's arguably a slightly better name for it. This has the effect of setting these variables with Cygwin/Unix filenames rather than Windows/JVM filenames on that platform. This allows filenames which, in their Windows form but not their Unix form, contain spaces, to be passed successfully to external tools. Lest that seem an overly specific hack, it also stops us from using backslashes in bash-based tool invocations, which is clearly fraught with the potential for problems. "\martind" might be safe, but "\robert" wouldn't be.
2009-06-28 20:50:21 +0100 / mad / revision 1676
src/e/edit/CheckInChangesAction.java: I think ShellCommand already runs us in the directory we were changing into here. I could have added quotes so that the whole of "C:\Documents and Settings\martind" is passed as a single argument to cd, but then there's the matter of the backslashes. Anyone who changes directory in their .bashrc gets what they deserve, elsewhere if not here.
2009-06-25 04:24:33 +0100 / enh / revision 1675
www/bug-report.html: fix the domain name.
2009-06-25 04:20:56 +0100 / enh / revision 1674
www/bug-report.html: add an Evergreen-specific bug reporting page.
2009-06-24 05:47:24 +0100 / enh / revision 1673
src/e/edit/ShellCommand.java: update the doc comments.
2009-06-24 04:54:32 +0100 / enh / revision 1672
src/e/edit/ShellCommand.java: order the fields like the corresponding constructor parameters, and remove an unused method that prevented 'command' being final.
2009-06-24 04:50:07 +0100 / enh / revision 1671
src/e/edit/BuildAction.java:
src/e/edit/EErrorsWindow.java:
src/e/edit/ExternalToolAction.java:
src/e/edit/ExternalTools.java:
src/e/edit/ShellCommand.java:
src/e/edit/Workspace.java: decoupling, mainly to make ShellCommand and EErrorsWindow less Evergreen-specific.
www/manual.html: this patch removes the not-convincingly-useful requestsConfirmation option from external tools, a fact which needs documenting.
2009-06-23 03:57:23 +0100 / enh / revision 1670
src/e/edit/BuildAction.java: choosing the build tool relies on the focused text window, so do it before we risk popping up dialogs.
2009-06-18 06:15:45 +0100 / enh / revision 1669
src/e/edit/EvergreenPreferences.java: another uninteresting extension, courtesy of the Android 1.5 SDK.
2009-06-16 08:16:26 +0100 / enh / revision 1668
src/e/edit/EErrorsWindow.java: track API change.
2009-06-15 23:04:40 +0100 / enp / revision 1667
src/e/edit/ETextAction.java:
src/e/edit/Workspace.java: We still support Java 5.
2009-06-14 02:47:54 +0100 / enh / revision 1666
src/e/edit/ETitleBar.java: don't cache UI defaults any more than we need to.
2009-06-14 01:41:55 +0100 / enh / revision 1665
src/e/edit/EColumn.java: ensure *all* the components in the column have the same width. Don't leave out the last component.
2009-06-08 16:58:42 +0100 / enh / revision 1664
www/manual.html: document the recent changes to custom build tool configuration.
2009-06-08 16:52:04 +0100 / enh / revision 1663
www/index.html:
www/manual.html: it's been some time since Evergreen last insisted that a project root contain build instructions or be under revision control.
2009-06-08 16:45:26 +0100 / enh / revision 1662
src/e/edit/BuildAction.java: remove a half-comment that ran out of steam.
2009-06-08 04:26:53 +0100 / enh / revision 1661
src/e/edit/BuildAction.java:
src/e/edit/OpenMakefileAction.java:
src/e/edit/Parameters.java: unify the built-in build tool support (GNU Make, Ant) with the custom tool support.
lib/data/default.properties: the built-in tools are no longer hard-coded.
2009-06-08 03:00:41 +0100 / enh / revision 1660
src/e/edit/BuildAction.java: make things slightly less unclear.
2009-06-08 02:44:31 +0100 / enh / revision 1659
src/e/edit/ETextAction.java:
src/e/edit/FindInFilesAction.java:
src/e/edit/OpenQuicklyAction.java:
src/e/edit/Workspace.java: the code protecting "Open Quickly" from multi-line selections was broken when we added code to quote the selection (because it turned "\n" into "\\n"). "Find in Files" still did the right thing. Factor out the correct heuristic and share it between both.
2009-06-08 00:59:52 +0100 / enh / revision 1658
src/e/edit/EErrorsWindow.java: make the errors window non-editable so that users don't need to hold down control to follow links.
2009-06-07 21:40:18 +0100 / enh / revision 1657
src/e/edit/FindAndReplaceAction.java:
src/e/edit/FindInFilesDialog.java:
src/e/edit/Minibuffer.java:
src/e/edit/OpenQuicklyDialog.java: use ELabel rather than work around JLabel's empty-string behavior.
2009-06-07 17:42:18 +0100 / enh / revision 1656
src/e/edit/AdvisorHtmlPane.java: EStatusBar.clearStatusBar has an awkward name, and just this one caller.
2009-06-04 04:31:03 +0100 / enh / revision 1655
TODO: job done, modulo the suggestion of having it available from the keyboard, which seems an excessively wasteful use of such a precious resource.
2009-06-04 04:29:35 +0100 / enh / revision 1654
src/e/edit/ETextWindow.java:
src/e/edit/EvergreenPreferences.java: support for showing line numbers.
2009-05-31 21:11:47 +0100 / mad / revision 1653
bin/evergreen: Mirror the code in Terminator for reporting unhandled exceptions to the -users list.
2009-05-31 18:06:21 +0100 / enh / revision 1652
bin/evergreen: add --help and support the old synonyms for "new" and "close" because the latter, though more natural on menus in the GUI, seem quite unnatural on the command-line. Imitate the GUI in choosing a sensible default for a new workspace's name, rather than insisting the user supply one.
2009-05-30 18:07:47 +0100 / enh / revision 1651
bin/evergreen:
src/e/edit/Evergreen.java:
src/e/edit/EvergreenLaunchable.java: stop using e.util.Launcher, which has never gained us much, and which makes life slightly more awkward for tools as various as ps(1) and jvisualvm(1).
2009-05-25 05:05:16 +0100 / enh / revision 1650
src/e/edit/FindInFilesDialog.java: add missing "final"s.
2009-05-25 04:57:14 +0100 / enh / revision 1649
src/e/edit/FindInFilesDialog.java: add missing "@Override"s.
2009-05-25 04:29:37 +0100 / enh / revision 1648
src/e/edit/FindAndReplaceAction.java: add missing "@Override"s.
2009-05-25 04:28:08 +0100 / enh / revision 1647
src/e/edit/OpenQuicklyDialog.java: add missing "@Override".
2009-05-25 04:26:49 +0100 / enh / revision 1646
src/e/edit/TagsUpdater.java: add missing "@Override"s.
2009-05-25 04:24:08 +0100 / enh / revision 1645
src/e/edit/WorkspaceFileList.java: add missing "final".
2009-05-25 04:20:08 +0100 / enh / revision 1644
src/e/edit/Advisor.java: add missing "final".
2009-05-18 19:54:31 +0100 / mad / revision 1643
bin/evergreen: Tell invoke-java.rb to report errors when talking to the InAppServer.
2009-05-17 19:12:11 +0100 / enh / revision 1642
src/e/edit/CompareSelectionAndClipboardAction.java:
src/e/edit/Diffable.java:
src/e/edit/ETextWindow.java:
src/e/edit/SimplePatchDialog.java: add the notion of a "Diffable" to simplify calling code, and so you don't pay for what you don't use (writing out files to disk when they're already available on disk). Also move all patch dialog creation inside SimplePatchDialog (previously CompareSelectionAndClipboardAction relied on us but ETextWindow rolled its own).
2009-05-16 06:30:41 +0100 / enh / revision 1641
src/e/edit/ShowMisspellingsAction.java: the spelling checker is case sensitive (it likes "PTextArea" but not "ptextarea", for example), so for correct counts, our regular expression needs to be case-sensitive too.
2009-05-16 06:24:28 +0100 / enh / revision 1640
src/e/edit/TagsUpdater.java: avoid accidental collisions (not yet seen in practice, but possible).
2009-05-13 06:10:43 +0100 / enh / revision 1639
src/e/edit/TagReader.java: relieve TagReader of any responsibility for digesting.
src/e/edit/HtmlTagger.java: lose HtmlTagger's "digester".
src/e/edit/TagsUpdater.java: digest tags as the tagger (whether ctags or Java) gives them to us. This means we can ignore the filenames embedded in ctags' output files, meaning we don't need to leave temporary files lying around until we exit. It also means we can use the same mechanism for ctags and pure Java taggers, and that we can now avoid writing out duplicate copies of files that are already on disk (because we no longer care what filename gets embedded in any ctags output).
src/e/edit/FindInFilesDialog.java: track API change.
src/e/edit/TagType.java: give us access to something we can digest.
2009-05-11 04:51:41 +0100 / enh / revision 1638
TODO: various updates.
2009-05-11 04:39:01 +0100 / enh / revision 1637
src/e/edit/ETextAction.java:
src/e/edit/ShellCommand.java:
www/manual.html: set EVERGREEN_CURRENT_WORD and EVERGREEN_CURRENT_SELECTION environment variables when calling tools. The former allows new tools that couldn't be written before; the latter is simply a convenience (a command starting "<", ">", or "|" gets the selection on stdin).
2009-05-11 00:22:46 +0100 / enh / revision 1636
src/e/edit/ETextArea.java: ETextArea is now empty...
src/e/edit/AppropriateFontAction.java:
src/e/edit/AutoCompleteAction.java:
src/e/edit/ChangeFontAction.java:
src/e/edit/CloseWindowAction.java:
src/e/edit/CorrectIndentationAction.java:
src/e/edit/ETextAction.java:
src/e/edit/ETextWindow.java:
src/e/edit/EWindow.java:
src/e/edit/FilePropertiesAction.java:
src/e/edit/FindAction.java:
src/e/edit/FindAndReplaceAction.java:
src/e/edit/FixedFontAction.java:
src/e/edit/GoToLineAction.java:
src/e/edit/HtmlTagger.java:
src/e/edit/InsertInterfaceAction.java:
src/e/edit/OpenImportAction.java:
src/e/edit/ProportionalFontAction.java:
src/e/edit/RevertToSavedAction.java:
src/e/edit/ShowDocumentationAction.java:
src/e/edit/TagsPanel.java:
src/e/edit/TagsUpdater.java: ...and we can just use PTextArea directly.
2009-05-11 00:08:47 +0100 / enh / revision 1635
src/e/edit/ETextArea.java:
src/e/edit/ETextWindow.java: use the new PTextArea API rather than overriding.
2009-05-10 23:20:07 +0100 / enh / revision 1634
src/e/edit/ETextArea.java:
src/e/edit/ETextWindow.java: remove yet more of ETextArea.
2009-05-10 22:45:40 +0100 / enh / revision 1633
src/e/edit/NewFileAction.java: further tune the selection heuristic in the "New File" dialog.
2009-05-05 07:24:57 +0100 / enh / revision 1632
src/e/edit/ETextWindow.java: although I deliberately passed in the text area's font, the fact that ' ', '-', and '+' aren't necessarily the same width means that a patch is likely to be easier to read in a fixed font even if that's not what you were using to view the file.
2009-04-30 05:10:48 +0100 / enh / revision 1631
www/manual.html: update documentation.
2009-04-30 04:35:09 +0100 / enh / revision 1630
src/e/edit/ETextWindow.java:
src/e/edit/EvergreenMenuBar.java:
src/e/edit/SaveAsAction.java:
src/e/edit/Workspace.java: remove "Save As", which doesn't make much sense in a programmer's editor and can easily be synthesized from everyday operations on the rare occasions that something like it is needed.
2009-04-29 07:08:59 +0100 / enh / revision 1629
src/e/edit/SimplePatchDialog.java: use PTextArea to display patches in a style similar to Trac. We use the appropriate PTextArea stylers on the source itself, and color the background to show whether the lines are added, removed, or context. There's support for rendering intraline changes if the information is provided, but in this patch we still call diff(1). One unrelated change I've been meaning to make for some time is to clean up the temporary files as soon as we're finished with them, rather than waiting for the VM to exit.
src/e/edit/ETextWindow.java: I've made the SimplePatchDialog API make more sense, so the caller has to change.
lib/scripts/ediff.py: this script provides intraline change information. What it doesn't do is replace large runs of unchanged lines with the usual "@@ -a,b +c,d @@" lines, so for now we still call diff(1) instead.
2009-04-28 02:59:44 +0100 / enh / revision 1628
src/e/edit/FileIgnorer.java: track API change.
2009-04-26 04:04:32 +0100 / mad / revision 1627
src/e/edit/Evergreen.java: Today's changes prevented Evergreen on Windows from opening the files from saved-state.xml. That's because cygpathIfNecessary no longer calls parseUserFriendlyName, though it still contains the comment explaining why it mustn't be called with a ~\dir\file "user-friendly" name. Fortunately, today's changes also render this call unnecessary for our purpose here (allowing the Cygwin user to write "evergreen /etc/passwd" or similar), as anytime we go to open a file, we translate its name from Cygwin form to Windows form. This includes further down this function, where we transform the file name we're opening via fileFromString, then getCanonicalPath.
2009-04-26 00:57:31 +0100 / enh / revision 1626
src/e/edit/Evergreen.java:
src/e/edit/ExternalTools.java:
src/e/edit/Parameters.java: look for site-wide configuration in /usr/lib/ and /usr/local/.
www/manual.html: document this.
2009-04-26 00:27:58 +0100 / enh / revision 1625
src/e/edit/WorkspaceFileList.java: we used to rely on the workspace root having a trailing slash, but now we're using File, we can't.
2009-04-26 00:26:20 +0100 / enh / revision 1624
src/e/edit/Evergreen.java: track API change.
2009-04-26 00:03:21 +0100 / enh / revision 1623
src/e/edit/BuildAction.java:
src/e/edit/CheckForLintAction.java:
src/e/edit/ShellCommand.java:
src/e/edit/WorkspaceFileList.java: clean up remaining users of FileUtilities.parseUserFriendlyName.
2009-04-25 06:50:51 +0100 / enh / revision 1622
src/e/edit/EvergreenMenuBar.java: "Open Makefile" ought to be on the "File" menu...
src/e/edit/OpenMakefileAction.java: ...and have a mnemonic.
www/manual.html: update the documentation.
2009-04-22 05:04:22 +0100 / enh / revision 1621
src/e/edit/ExternalTools.java: ask the FileFinder for directories too, so that the FileAlterationMonitor gets to see them.
2009-04-22 04:07:24 +0100 / enh / revision 1620
src/e/edit/ExternalTools.java: add a new showOnPopUpMenu property to the tools files so users can specify which tools are important enough to warrant valuable pop-up menu space.
www/manual.html: document the changes.
src/e/edit/ETextWindow.java:
src/e/edit/EvergreenMenuBar.java: track the API changes.
src/e/edit/ExternalToolAction.java: lose the now-dead heuristic.
2009-04-21 05:42:20 +0100 / enh / revision 1619
src/e/edit/FileIgnorer.java:
src/e/edit/WorkspaceFileList.java: generalize FileIgnorer...
src/e/edit/ExternalTools.java: ...enough that we can use it here. The primary motivation being to avoid indexing ".svn" directories and the version-controlled files duplicated within.
2009-04-21 05:27:11 +0100 / enh / revision 1618
src/e/edit/FileIgnorer.java: "make" is a better name than "get" for an expensive method that always recomputes.
2009-04-21 05:09:25 +0100 / enh / revision 1617
src/e/edit/EvergreenMenuBar.java: replace two old hard-coded tools...
lib/data/tools/10.sort.tool:
lib/data/tools/20.sort-and-remove-duplicates.tool: ...with tool files...
src/e/edit/ExternalTools.java: ...that we read before the user-supplied ones.
get back to one method for finding resource files
src/e/edit/ETextWindow.java:
src/e/edit/Evergreen.java:
src/e/edit/GoToTagAction.java:
src/e/edit/JavaResearcher.java:
src/e/edit/NewFileAction.java:
src/e/edit/PythonDocumentationResearcher.java:
src/e/edit/RubyDocumentationResearcher.java:
src/e/edit/ShellCommand.java: get back to one method for finding resource files.
2009-04-21 05:03:27 +0100 / enh / revision 1616
lib/data/tools: new directory.
2009-04-21 04:29:39 +0100 / enh / revision 1615
www/manual.html: the documentation claimed to be in r1614.
2009-04-21 04:18:10 +0100 / enh / revision 1614
src/e/edit/ETextWindow.java:
src/e/edit/EvergreenMenuBar.java:
src/e/edit/ExternalTools.java: reimplement the notation for separators that I mistakenly assumed no-one was using, documenting it, and adding documentation for other aspects of the implementation that are meant to be relied upon by users.
2009-04-21 03:51:31 +0100 / enh / revision 1613
src/e/edit/CheckInChangesAction.java:
src/e/edit/ShellCommand.java:
www/manual.html: the path to "evergreen" seems like something that's potentially quite useful to our children, so make it available to all of them and document the new variable.
2009-04-21 00:44:37 +0100 / mad / revision 1612
src/e/edit/CheckInChangesAction.java: It's a pretty pickle when an application can't reliably find the script that launched it. In this case, my double clicks caused a SIGPIPE exception to be reported. The "evergreen" on the path will be last week's, which is still the version in /usr/bin. That fails, I presume because the port file has been renamed.
src/e/edit/Evergreen.java: Perhaps this should be in FileUtilities. I didn't see a property for "evergreen" so, for the moment, I've put it by the similar code for finding other files under the projectRoot. Perhaps all these methods can move at the same time.
2009-04-20 19:36:29 +0100 / mad / revision 1611
src/e/edit/ExternalTools.java: The file alteration monitor even works on non-existent directories. Oh me of little faith. All I needed to do was to tell the file alteration monitor about that directory even when it doesn't exist (though I still believe the removal of the conditional was a good change in its own right).
2009-04-20 18:25:29 +0100 / mad / revision 1610
src/e/edit/ExternalTools.java: To discover that the tools directory has appeared (or disappeared, which could be through renaming, in which case the underlying files won't have disappeared), we need to monitor its parent directory. Perhaps that's so general a principle that it belongs in FileAlterationMonitor? Even if we find no tools, we should replace the tools list and fire triggers. We can't scan or monitor a directory that doesn't exist but, other than that, the no-tools cases shouldn't be special.
2009-04-20 17:36:47 +0100 / mad / revision 1609
src/e/edit/ExternalTools.java: If the tools directory disappears, we should replace any existing tools list with the empty list. That's why I'm fixing this here, rather than with an initializer, even though the symptom I actually want to address is that Evergreen doesn't start today in the default configuration, dying with:
Associated exception:
java.lang.NullPointerException
at java.util.Collections$UnmodifiableCollection.<init>(Collections.java:994)
at java.util.Collections$UnmodifiableList.<init>(Collections.java:1147)
at java.util.Collections.unmodifiableList(Collections.java:1133)
at e.edit.ExternalTools.getTools(ExternalTools.java:55)
at e.edit.EvergreenMenuBar.makeToolsMenu(EvergreenMenuBar.java:144)
at e.edit.EvergreenMenuBar.<init>(EvergreenMenuBar.java:18)
at e.edit.Evergreen.updateMenuBar(Evergreen.java:807)
at e.edit.Evergreen.initMenuBar(Evergreen.java:797)
at e.edit.Evergreen.init(Evergreen.java:836)
at e.edit.Evergreen.getInstance(Evergreen.java:117)
at e.edit.EvergreenLaunchable.startGui(EvergreenLaunchable.java:15)
at e.util.Launcher$1.run(Launcher.java:28)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
at e.debug.EventDispatchThreadHangMonitor.dispatchEvent(EventDispatchThreadHangMonitor.java:191)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
Associated exception:
java.lang.NullPointerException
at java.util.Collections$UnmodifiableCollection.<init>(Collections.java:994)
at java.util.Collections$UnmodifiableList.<init>(Collections.java:1147)
at java.util.Collections.unmodifiableList(Collections.java:1133)
at e.edit.ExternalTools.getTools(ExternalTools.java:55)
at e.edit.EvergreenMenuBar.makeToolsMenu(EvergreenMenuBar.java:144)
at e.edit.EvergreenMenuBar.<init>(EvergreenMenuBar.java:18)
at e.edit.Evergreen.updateMenuBar(Evergreen.java:807)
at e.edit.Evergreen.initMenuBar(Evergreen.java:797)
at e.edit.Evergreen.init(Evergreen.java:836)
at e.edit.Evergreen.getInstance(Evergreen.java:117)
at e.edit.EvergreenLaunchable.startGui(EvergreenLaunchable.java:15)
at e.util.Launcher$1.run(Launcher.java:28)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
at e.debug.EventDispatchThreadHangMonitor.dispatchEvent(EventDispatchThreadHangMonitor.java:191)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
2009-04-19 19:13:56 +0100 / enh / revision 1608
src/e/edit/ETextWindow.java:
src/e/edit/Evergreen.java:
src/e/edit/EvergreenMenuBar.java:
src/e/edit/ExternalTools.java:
src/e/edit/ExternalToolsParser.java: rename ExternalToolsParser ExternalTools.
2009-04-19 19:11:45 +0100 / enh / revision 1607
src/e/edit/ETextWindow.java: hide an implementation detail.
2009-04-19 18:53:49 +0100 / enh / revision 1606
src/e/edit/ExternalToolsParser.java: reload the tools when they – or their directory structure – changes.
src/e/edit/ETextWindow.java:
src/e/edit/EvergreenMenuBar.java: track API change.
src/e/edit/Evergreen.java: update the menu bar when the tools change. (This is easier than updating just the "Tools" menu.)
2009-04-19 18:52:13 +0100 / enh / revision 1605
src/e/edit/Parameters.java: remove spurious empty line.
2009-04-19 17:52:44 +0100 / enh / revision 1604
src/e/edit/ExternalToolsParser.java: a problem with one tool file shouldn't affect the others.
2009-04-19 02:15:23 +0100 / enh / revision 1603
bin/evergreen:
src/e/edit/Evergreen.java: renaming "edit-server-port" to "evergreen-server-port" shouldn't be disruptive, but now's as good a time as any.
www/faq.html: the FAQ was already out of date.
2009-04-19 02:09:41 +0100 / enh / revision 1602
src/e/edit/Evergreen.java:
www/manual.html: since we're disrupting advanced users this weekend, let's slip in another disruptive change, and finally rename "edit.properties" to "evergreen.properties". I'm deliberately not going to move old configuration over because it's likely that most "edit.properties" files are junk from the days when we (stupidly) didn't distinguish user-editable configuration.
2009-04-19 02:05:44 +0100 / enh / revision 1601
src/e/edit/ExternalToolsParser.java: rather than reading external tools from properties, scan the ~/.e.edit.Edit/tools/ directory.
src/e/edit/ShellCommand.java: rename all the EDIT_ variables we add to children's environments EVERGREEN_.
src/e/edit/CheckInChangesAction.java:
src/e/edit/ExternalToolAction.java:
src/e/edit/ShowHistoryAction.java: track changes.
www/manual.html: update manual.
2009-04-19 00:55:03 +0100 / enh / revision 1600
src/e/edit/ShellCommand.java:
src/e/edit/StreamMonitor.java: make ShellCommand a little tidier.
2009-04-19 00:22:18 +0100 / enh / revision 1599
src/e/edit/StreamMonitor.java: fix a race condition where it was possible for 'task' to receive streamClosed before all calls to processLines had been made. SwingWorker.publish is asynchronous, and only after SwingWorker.get has returned can you be sure that SwingWorker.process has been invoked for everything you "published".
src/e/edit/ShellCommand.java: none of these changes are necessary parts of the fix, but they clean up a few of the messier bits of this horrible code. In particular, it's pretty non-obvious what order code runs in, and on which of the many threads that are involved.
2009-04-16 18:44:43 +0100 / mad / revision 1598
src/e/edit/Minibuffer.java: I wondered about binding the Find Next and Find Previous actions to the previously focused text area before calling the menu bar, then unbinding them after. A couple of weeks ago, Elliott made the different suggestion below. I think he's saying that we should pass the request directly to the previousFocusOwner, if it supports the keystroke. As far as I can see, PTextArea already has an ActionMap. Anyway, the suggestion:
looking closer, i think the right fix is to move PTextArea over to using
an ActionMap, and making generic cut/copy/paste actions that see if the
focused component has the relevant action in its ActionMap. we need to
agree on action names, but it looks like Swing is already consistent, so
if we just use the same names, i think we can have menu items that do the
right thing whether you've got a focused JTextField, JTable, or PTextArea.
(even JList, which might let us remove some manual InputMap hacking, since
JList has a "copy" in its ActionMap but nothing in its InputMap by
default, for reasons i've never understood.)
definitely a weekend job, but it'll leave us with something genuinely
useful in any Swing app.
2009-04-16 04:57:17 +0100 / enh / revision 1597
src/e/edit/JavaDoc.java:
src/e/edit/OpenImportAction.java:
src/e/edit/Parameters.java: what was an array, grandad?
2009-04-16 04:52:34 +0100 / enh / revision 1596
src/e/edit/Parameters.java: add support for an arbitrary number of properties files to be read in order.
src/e/edit/Evergreen.java: read from "lib/data/default.properties" ahead of the user's properties file.
src/e/edit/CheckForLintAction.java:
src/e/edit/OpenImportAction.java: move these two classes' defaults from code...
lib/data/default.properties: ...to data. Note that the path separator has changed to Java's usual ";" rather than using the platform default or the Unix default, in a perhaps futile attempt to be helpful to Windows users. (Unix users probably don't use ';' in path elements any more than they use ':'. locate(1) calls me a liar, but only in cases where filenames have come from URLs, and not anywhere likely to be useful to Evergreen.)
2009-04-16 03:21:48 +0100 / enh / revision 1595
src/e/edit/Parameters.java: move the reloading code into a nested class, and make sure the FileAlterationMonitor keeps track of all the files we included.
2009-04-15 17:31:20 +0100 / mad / revision 1594
src/e/edit/Minibuffer.java: Adapt to last night's salma-hayek r2961.
It's a bit difficult to test this, as we still have the relatively recent regression here, about which I'm half-expecting to see some reply, months down the road, when it pops out of Elliott's G1, whereby the text area isn't focused yet, so the Find Next and Find Previous actions aren't yet enabled.
But at least it now compiles.
2009-04-15 06:10:38 +0100 / enh / revision 1593
src/e/edit/FileIgnorer.java:
src/e/edit/WorkspaceFileList.java: use the new e.util.FileFinder.
2009-04-14 17:44:02 +0100 / mad / revision 1592
src/e/edit/NewFileAction.java: Remove toString relic.
2009-04-14 16:58:56 +0100 / mad / revision 1591
bin/evergreen-boilerplate-generator: Lose a support script...
lib/scripts/evergreen-boilerplate-generator: ... to its rightful home.
src/e/edit/NewFileAction.java: And adapt to its new location.
Its previous location, which was on the path, either through invoke-java.rb's deprecated subvertPath or via being installed in /usr/bin, was chosen to make it easy to delegate to the default boilerplate generator from the customized boilerplate generator used at Google. subvertPath's time is nearly up. I'm operating without it.
2009-04-12 17:43:29 +0100 / mad / revision 1590
src/e/edit/PythonDocumentationResearcher.java: Remove the explicit "python" I added last week that's no longer necessary on Windows.
src/e/edit/RubyDocumentationResearcher.java: Remove a similar one and a much older one that should equally be unnecessary.
2009-04-11 06:05:07 +0100 / enh / revision 1589
src/e/edit/Evergreen.java: ensure the status bar is available when Parameters first loads the properties from disk (even if it's not visible).
2009-04-11 06:02:04 +0100 / enh / revision 1588
src/e/edit/JavaResearcher.java: the number of unique words is every bit as interesting as the number of unique identifiers.
2009-04-11 05:58:16 +0100 / enh / revision 1587
src/e/edit/Parameters.java: explicitly say when we've reloaded the configuration, in case it isn't a visible change.
2009-04-10 07:08:27 +0100 / mad / revision 1586
src/e/edit/NewFileAction.java: The quoting of the boilerplate generator, which I've removed here, was preventing it being used except to specify a single executable. Thus no-one can have been making use of the shell, so they won't miss it. Cygwin bash won't find the boilerplate generator given a Windows path.
At the moment, we could remove the findOnPath call, because the default boilerplate generator is always on the path. (Then we could go via bash again.) We'd like to hide it being getScriptFilename instead. (Then we couldn't go via bash.) That involves moving the script. Hopefully everyone's had enough notice to adapt already.
I've also removed the dead code for the case, which can't happen unless someone's broken the installation, where we don't find a boilerplate generator.
2009-04-07 23:33:39 +0100 / mad / revision 1585
src/e/edit/EditServer.java: Use findSupportBinary rather than doing a path search, removing the final obstacle to removing our pollution of the path with the support binary directory.
2009-04-07 22:05:05 +0100 / mad / revision 1584
src/e/edit/Evergreen.java: This Cygwin abstraction wasn't ever really specific to Evergreen. Now it's moved so that it can be called, eventually, from ProcessUtilities.
2009-04-07 03:57:57 +0100 / enh / revision 1583
lib/data/javadoc-summary.txt.gz: update from JDK5 to JDK6.
2009-04-07 03:54:25 +0100 / enh / revision 1582
lib/data/javadoc-summary.txt:
lib/data/javadoc-summary.txt.gz: compress the JavaDoc summary (from 4MiB down to 500KiB).
src/e/edit/JavaResearcher.java: decompress it when we read it in.
2009-04-07 02:47:59 +0100 / enh / revision 1581
parse-javadoc.rb: fix the script to work with JDK6 JavaDoc on Debian-based systems. Also improve error reporting.
2009-04-05 02:20:22 +0100 / enh / revision 1580
src/e/edit/Parameters.java: split readPropertiesFile into initParameters and reloadParametersFile, the latter of which is automatically called by a FileAlterationMonitor whenever the file changes.
src/e/edit/Evergreen.java: track API change.
src/e/edit/ETextWindow.java: move code that needs to re-read a Parameter into preferencesChanged, where it will be called at least as often as necessary.
2009-04-05 01:16:38 +0100 / enh / revision 1579
src/e/edit/Parameters.java: support notification of listeners when the properties are re-read. We use the same interface as Preferences...
src/e/edit/Evergreen.java: ...so we can just use the same code path in response.
2009-04-05 01:09:01 +0100 / enh / revision 1578
src/e/edit/Evergreen.java: put properties and preferences together as "configuration".
2009-04-05 00:40:32 +0100 / enh / revision 1577
src/e/edit/Evergreen.java:
src/e/edit/EvergreenPreferences.java:
src/e/edit/OpenPropertiesFileAction.java: basic support for editing the user's properties file. An extra button in the preferences dialog seems like the least worst place.
2009-04-04 23:27:30 +0100 / enh / revision 1576
src/e/edit/GoToTagAction.java: revert the last change to this file, removing the comment that suggested the code was unused.
2009-04-04 22:49:11 +0100 / mad / revision 1575
src/e/edit/RubyDocumentationResearcher.java: Calling a script a binary is confusing, even though bin is an accepted home for many scripts. The technique already used here to explicitly specify the script interpreter could be used elsewhere to get around the hash-bang problem on Cygwin.
src/e/edit/PythonDocumentationResearcher.java: It's obvious what the interpreter should be here, for example.
src/e/edit/GoToTagAction.java: But the property here, although it's allegedly unused, demonstrates that the hash-bang interpretation really wants to move to ProcessUtilities. Then part of this change wants reverting, along with at least one previously extant explicit specification of the interpreter.
Although Cygwin bash doesn't like Windows path names, Cygwin Ruby and Python are both happy for their script filename argument to be given in Windows form. I see that, despite the lack of .rb, evergreen-boilerplate-generator, which is the script that started this discussion, is a Ruby script.
2009-04-04 22:19:07 +0100 / enh / revision 1574
src/e/edit/JavaDoc.java:
src/e/edit/JavaResearcher.java: I think the code in JavaResearcher is dormant (if not quite dead) but even if I'm not sure I can remove it, I can at least remove the (incorrect) duplication.
2009-04-04 22:16:08 +0100 / enh / revision 1573
src/e/edit/BuildAction.java:
src/e/edit/CheckForLintAction.java:
src/e/edit/ETextWindow.java:
src/e/edit/Evergreen.java:
src/e/edit/ExternalToolsParser.java:
src/e/edit/GoToTagAction.java:
src/e/edit/JavaResearcher.java:
src/e/edit/NewFileAction.java:
src/e/edit/OpenImportAction.java:
src/e/edit/Parameters.java: use distinct method names rather than overloading in Parameters.
2009-04-04 20:07:58 +0100 / enh / revision 1572
src/e/edit/ETextWindow.java: we need to set the margin ourselves now PTextArea can't get the settings from system properties.
2009-04-04 20:02:09 +0100 / enh / revision 1571
src/e/edit/Parameters.java: stop polluting the system properties so we can move towards being able to reload without having to restart.
2009-04-04 02:16:51 +0100 / enh / revision 1570
www/index.html:
www/manual.html: more documentation that should be in the documentation rather than the list of features.
2009-04-04 01:39:03 +0100 / mad / revision 1569
src/e/edit/EvergreenMenuBar.java: Lose makeMenu to salma-hayek, where it can be shared by Terminator.
2009-04-04 01:36:26 +0100 / enh / revision 1568
www/index.html: add a few more missing links to the documentation. Everything else missing a link is, I think, also missing documentation.
2009-04-04 01:30:07 +0100 / enh / revision 1567
www/index.html:
www/manual.html: move some documentation from the features list to the manual (while adding a link to the manual from the features list) and expand upon Evergreen's behavior with symbolic links.
2009-04-03 17:38:33 +0100 / enp / revision 1566
src/e/edit/Advisor.java:
src/e/edit/EErrorsWindow.java: Both moving and resizing a frame should count as modifying its bounds.
2009-04-01 19:53:16 +0100 / mad / revision 1565
src/e/edit/WorkspaceFileList.java: Following symlinks that lead outside the workspace could lead to our indexer getting stuck in an infinite loop. Although it was useful to Ed once, it's now getting in Elliott's way, as well you can imagine it might. Given that we can't remember or devise a use-case where this would be part of the right solution, out it comes, reverting r1060. r1060 was two days after r1058 broke Ed's link from Evergreen to ../salma-hayek, so he'll presumably spot any remaining need for the r1060 hack quite quickly.
Looking back at r1058, which excludes symlinks within the workspace from the index, I wonder if it wouldn't be more appropriate to include them, providing that the target is a regular file. As noted earlier today, we canonicalize filenames anyway, so having multiple symlinks to a file won't lead to our opening multiple viewers on the same file (although hard links would). The motivation for r1058 was a symlink to a directory, which caused a cycle. Before r1058, the symbolic link test had been in the same place since the initial Subversion import. (It moved from one file to another and was quite a pain to chase through, so I'm recording that here to save anyone else the bother.)
2009-04-01 18:47:27 +0100 / mad / revision 1564
src/e/edit/Workspace.java: My fear that r1548's change to EColumn.findWindowByFilename might have violated the now-documented caveat here was groundless...
src/e/edit/Evergreen.java: ... because of a side-effect of the call we use to follow symlinks in Workspace.findIfAlreadyOpen's only caller. No-one's going to change that but it's worth recording a third reason for using getCanonicalPath, as opposed to, say, checking that the filename refers to a link and then reading the link. (I realize that wouldn't be possible in Java 5.) I've put this reason second in the list as it's more important than the seemingly cosmetic reason that follows.
Perhaps the first caveat belongs in EColumn but, if the method there were still called findWindowByTitle, then it clearly wouldn't belong there, as EColumn now does do what it used to say on the tin.
2009-04-01 06:31:00 +0100 / enh / revision 1563
src/e/edit/EColumn.java: using endsWith here seems like a mistake, even though we've never known it cause trouble.
2009-03-29 07:13:37 +0100 / enh / revision 1562
src/e/edit/PerlDocumentationResearcher.java: encourage pod2html to leave its droppings somewhere no-one cares about — the platform's equivalent of /tmp.
2009-03-29 07:01:50 +0100 / enh / revision 1561
src/e/edit/ETitleBar.java: without a few pixels spacing, the title bleeds into the component surrounding the title bar (in the GTK+ LAF, for the selected window, where the text is white and the surrounding component is very light gray).
2009-03-29 06:51:03 +0100 / enh / revision 1560
src/e/edit/EWindow.java: don't imply that titles can be changed.
2009-03-29 06:50:31 +0100 / enh / revision 1559
src/e/edit/ETitleBar.java: there's no reason to put in a placeholder title when we already know the real title.
2009-03-29 06:47:43 +0100 / enh / revision 1558
src/e/edit/EColumn.java:
src/e/edit/ETextWindow.java:
src/e/edit/ETitleBar.java:
src/e/edit/EWindow.java: remove the concept of "title" from EWindow and ETextWindow. We deal in filenames, not titles.
2009-03-29 06:36:03 +0100 / enh / revision 1557
src/e/edit/EditWorkspaceAction.java:
src/e/edit/Evergreen.java:
src/e/edit/FindInFilesDialog.java:
src/e/edit/NewWorkspaceAction.java:
src/e/edit/SaveAllAction.java:
src/e/edit/Workspace.java: another step towards using the same terminology inside and out.
2009-03-29 06:27:38 +0100 / enh / revision 1556
src/e/edit/Evergreen.java:
src/e/edit/WorkspaceFileList.java: remove some of the more verbose but less useful logging. We log when a workspace scan finishes, and how long it took.
2009-03-29 06:24:42 +0100 / enh / revision 1555
src/e/edit/ETextWindow.java: BirdView expects line numbers to begin at 0, like PTextArea, but unlike much of Evergreen (which is often concerned with the line numbers humans use).
2009-03-29 06:00:53 +0100 / enh / revision 1554
bin/evergreen: no-one seems to like the old behavior where, on failing to open a file in an existing instance we start a new one.
2009-03-28 06:18:43 +0000 / enh / revision 1553
TODO: updates.
2009-03-28 06:04:43 +0000 / enh / revision 1552
src/e/edit/ShowManPageAction.java:
src/e/edit/EvergreenMenuBar.java: lose "Show Man Page"...
src/e/edit/AdvisorHtmlPane.java: ...add a search field to the advisor window...
src/e/edit/Advisor.java: ...and pop up an empty advisor window if the user presses F1 with no selection. (Previously we'd say that we had no documentation for "".)
src/e/edit/JavaResearcher.java:
src/e/edit/ManPageResearcher.java:
src/e/edit/PerlDocumentationResearcher.java:
src/e/edit/PythonDocumentationResearcher.java:
src/e/edit/RubyDocumentationResearcher.java:
src/e/edit/StlDocumentationResearcher.java:
src/e/edit/WorkspaceResearcher.java: stop passing ETextWindow to the researchers. Only the Java researcher even tried to make use of it, and it didn't do a good job.
2009-03-28 05:26:16 +0000 / enh / revision 1551
src/e/edit/ETextWindow.java: tell our BirdView what lines are selected.
2009-03-28 04:51:58 +0000 / enh / revision 1550
src/e/edit/ETextWindow.java: we don't really want to unconditionally force a repaint; we want to make sure that we're highlighting the match under the caret.
2009-03-28 04:10:16 +0000 / enh / revision 1549
src/e/edit/ETextWindow.java: repaint the bird view when the caret moves, so it can show you which match you're on.
2009-03-23 01:01:41 +0000 / enh / revision 1548
src/e/edit/EColumn.java:
src/e/edit/Workspace.java: Chris Reece reports that he created a new workspace and then used "New File" to create "dothing.py" and "DoThing.py", resulting in both files being indexed but only the former being open, and him left unable to open the latter without first closing the former. This code's case-insensitive decision about whether or not a file is already open was to blame. I'm still not sure the rest of findWindowByFilename is correct – the use of getTitle rather than getFilename seems suspicious, as does the use of endsWith rather than equals – but this is enough to fix Chris' reported bug.
2009-03-23 00:40:42 +0000 / enh / revision 1547
src/e/edit/Workspace.java: inline a one-line public method with a single caller in the same class.
2009-03-22 21:05:17 +0000 / enh / revision 1546
src/e/edit/EditServer.java: take advantage of ProcessUtilities.spawn's switch to varargs.
2009-03-22 00:48:17 +0000 / enh / revision 1545
bin/evergreen: we don't need to add EDIT_HOME to the environment...
src/e/edit/Evergreen.java:
src/e/edit/GoToTagAction.java:
src/e/edit/PythonDocumentationResearcher.java:
src/e/edit/RubyDocumentationResearcher.java: ...because we already set the system property "org.jessies.projectRoot", and can just use that instead.
2009-03-21 21:37:19 +0000 / enh / revision 1544
src/e/edit/EColumn.java:
src/e/edit/EErrorsWindow.java:
src/e/edit/ETextWindow.java:
src/e/edit/EvergreenMenuBar.java:
src/e/edit/FindFilesContainingSelectionAction.java:
src/e/edit/FindInFilesAction.java: give FindInFilesAction its rightful name.
2009-03-21 21:33:52 +0000 / enh / revision 1543
src/e/edit/ClearErrorsAction.java:
src/e/edit/EErrorsWindow.java:
src/e/edit/EvergreenMenuBar.java:
src/e/edit/KillErrorsAction.java: "kill errors" was long since renamed "clear errors".
2009-03-21 21:28:55 +0000 / enh / revision 1542
src/e/edit/CheckInChangesAction.java:
src/e/edit/CloseWorkspaceAction.java:
src/e/edit/CycleWorkspacesAction.java:
src/e/edit/EditWorkspaceAction.java:
src/e/edit/FindFilesContainingSelectionAction.java:
src/e/edit/KillErrorsAction.java:
src/e/edit/NewFileAction.java:
src/e/edit/OpenAction.java:
src/e/edit/OpenQuicklyAction.java:
src/e/edit/RescanWorkspaceAction.java: it's probably easier to find the menu item you need when you first start using Evergreen if all the ones that won't work without a workspace are disabled.
2009-03-21 21:18:29 +0000 / enh / revision 1541
src/e/edit/EvergreenMenuBar.java: although build, test, and rescan are the most frequent workspace activities, they're not the ones most frequently accessed from the menu; they're so frequent that any regular user will have learned to use the keyboard equivalents. Move the most frequently used menu items to the top of the menu.
2009-03-21 21:15:39 +0000 / enh / revision 1540
src/e/edit/Evergreen.java: the first time we're run, put the window in the center of the display. Also slightly simplify the introductory message. I did consider opening the dialog automatically, but fear that would make it harder to learn where the functionality lies, and would only make sense if the user wasn't expected to need it on a fairly regular basis.
2009-03-21 20:53:11 +0000 / enh / revision 1539
bin/evergreen:
src/e/edit/AddWorkspaceAction.java:
src/e/edit/EditServer.java:
src/e/edit/Evergreen.java:
src/e/edit/EvergreenMenuBar.java:
src/e/edit/NewWorkspaceAction.java:
www/manual.html: the other half of Ed's suggested renaming was that "Add Workspace" should become "New Workspace". There wasn't really anything wrong with "add", but it doesn't go as well with "close" as it did with "remove".
2009-03-13 06:32:01 +0000 / enh / revision 1538
src/e/edit/RescanWorkspaceAction.java: alt-r in "Open Quickly" or "Find in Files" shouldn't leave focus on the "Rescan" button. The button (and its mnemonic) are supposed to speed things up, not erect roadblocks!
2009-03-13 06:20:55 +0000 / enh / revision 1537
src/e/edit/CorrectIndentationAction.java:
src/e/edit/JoinLinesAction.java: fix two possible NullPointerExceptions (the enabled state of the menu items is only fixed up when you cause the menu to be shown, so the keyboard equivalents are generally always enabled for people who know Evergreen well enough to not need the menus).
2009-03-09 03:09:47 +0000 / enh / revision 1536
www/index.html:
www/main-window.png: have you any idea how small 800x600 is? This is slightly over, and thus too big for freshmeat.net, but took too much effort to throw away, especially since it's slightly better than the one that's small enough, and the Evergreen page has always lacked any picture of what Evergreen itself looks like. Not that 800x600 pixels can really give you an idea!
2009-03-07 04:16:04 +0000 / enh / revision 1535
src/e/edit/ESwitchButton.java:
src/e/edit/ShowCounterpartAction.java: teach anyone who sees the tool tip what the keyboard equivalent is.
2009-03-07 02:02:56 +0000 / mad / revision 1534
src/e/edit/Evergreen.java: My one niggle with nested workspaces is now trivially addressed, again without affecting the behavior of closeWorkspace for non-nested workspaces.
2009-03-07 01:55:06 +0000 / mad / revision 1533
src/e/edit/Evergreen.java: Now that ginger step-files no longer flit to the currently selected workspace when workspaceConfigurationDidChange, I assert that closeWorkspace can merge a nested workspace's files back into its parent workspace without affecting anyone who doesn't use nested workspaces.
src/e/edit/MergeWorkspaceAction.java: That saves maintaining and documenting a copy of CloseWorkspaceAction...
src/e/edit/EvergreenMenuBar.java:
src/e/edit/EvergreenTabbedPane.java: ... and polluting the UI with non-obvious and poorly named options...
... while letting me continue to enjoy the benefits of this palliative solution for the problems of EColumn's lack of scalability.
2009-03-06 07:42:06 +0000 / enh / revision 1532
src/e/edit/NewFileAction.java: the old behavior was to show just the directory containing the current file, and then to select that for overwriting. It seems more likely that you want to keep the directory, and it's even possible you want part of the name (because you've written your .h file and now you want to write a .cpp file, say). So show the whole filename, and select just the leafname.
2009-03-06 07:08:59 +0000 / enh / revision 1531
TODO: new job.
2009-03-05 17:08:31 +0000 / enh / revision 1530
www/index.html: outsource maintenance of the Acme link to Wikipedia; there's a strong possibility that the Bell Labs link has been changed more often than anyone's ever clicked on it, and although I found what it's currently changed to, that page's image links are broken. Wikipedia seems to link to a mirror, but also has links to the manual pages and related projects and so forth, so I think everyone wins if we just point to them.
2009-03-05 05:32:40 +0000 / enh / revision 1529
src/e/edit/Minibuffer.java: use DocumentAdapter.
2009-03-05 05:19:55 +0000 / enh / revision 1528
src/e/edit/ESwitchButton.java: add a tool tip showing what file the button would open.
2009-03-05 03:24:05 +0000 / enh / revision 1527
src/e/edit/InsertInterfaceAction.java:
src/e/edit/JavaDoc.java:
src/e/edit/JavaResearcher.java: switch JavaDoc.getClasses to collections.
2009-03-05 03:19:41 +0000 / enh / revision 1526
src/e/edit/Evergreen.java: switch Evergreen.getWorkspaces to collections.
2009-03-05 03:12:06 +0000 / enh / revision 1525
src/e/edit/TagReader.java: don't use an array where we don't need one.
2009-03-05 03:10:50 +0000 / enh / revision 1524
src/e/edit/Evergreen.java:
src/e/edit/SaveAllAction.java:
src/e/edit/Workspace.java: switch Workspace.getDirtyTextWindows to collections.
2009-03-05 02:54:15 +0000 / enh / revision 1523
src/e/edit/EColumn.java:
src/e/edit/Workspace.java: switch EColumn.getTextWindows and Workspace.getTextWindows to collections.
2009-03-04 06:16:10 +0000 / mad / revision 1522
src/e/edit/Workspace.java: When asked to reassess the best workspace for a file, don't move it if there's no better choice. This prevents files with no good home from flying to the selected workspace when that workspaceConfigurationDidChange, regardless of the substance of the change.
src/e/edit/Evergreen.java: Here we retain the previous default choice of the currently selected workspace if there is no better choice but only if the file being opened is not open on any workspace. This fixes the long standing serious bug whereby you could easily end up with the same file open on two workspaces (if the file didn't belong to either).
Someone else could probably write the array handling here in a less clunky style. The duplication of setSelectedComponent is mildly distressing too.
2009-03-04 05:03:07 +0000 / mad / revision 1521
src/e/edit/Evergreen.java: Reinstate Elliott's desired and reasonable wish for the behavior of Close Workspace, adding a new action that's...
src/e/edit/MergeWorkspaceAction.java: ... just like the old Close Workspace...
src/e/edit/EvergreenMenuBar.java:
src/e/edit/EvergreenTabbedPane.java: ... and is exposed in the same places.
I'd previously suggested that closing a nested workspace could silently merge it. That would be an expedient way out of the impasse but would be inconsistent. If the user action is supposed to connote closing all of the files too, then that's what it should always do. If the user (me) wants to move all the files on a workspace to the next best workspace, then that's something else.
I had been wondering whether the call to moveFilesToBestWorkspaces in closeWorkspace could leave the files where they were if there was no good workspace, so they'd be discarded with the workspace. I ran into a wall considering what would happen to files that have no good workspace when moveFilesToBestWorkspaces is called after an Edit Workspace. They shouldn't be closed. There's no connotation of closing when the workspace root directory is changed even, I would argue, when the file's path is no longer within the workspace.
I think there might be a tasteful way round that wall but I'll check this in anyway as it gets the code back to where no-one should be actively hurting.
2009-03-03 06:05:46 +0000 / enh / revision 1520
src/e/edit/TagsPanel.java: use GuiUtilities.createEmptyBorder.
2009-03-03 06:04:31 +0000 / enh / revision 1519
src/e/edit/ShowManPageAction.java: quote more consistently.
2009-03-03 05:49:45 +0000 / enh / revision 1518
src/e/edit/WorkspaceProperties.java: FilenameChooserField is now responsible for giving us paths with system-appropriate separators.
2009-03-03 05:35:05 +0000 / mad / revision 1517
src/e/edit/Evergreen.java: Revert Elliott's last change here, again. Elliott seems to have a new mental model of the workspace feature. He thinks that deviations between how the code behaves and his model says it should behave are bugs. They're not. There was a coherent model of workspaces, indeed, I would say that it was one of the distinguishing features of Evergreen. Changing the design, in particular here, has already caused me significant pain. It would be nice to see some effort at establishing a consensus before making such a significant design change.
2009-03-03 05:33:43 +0000 / enh / revision 1516
src/e/edit/EditServer.java: be more consistent about quoting, and report why we seem to be hanging (when given --block) rather than reporting when we're no longer blocked, which is self-evident.
2009-03-03 05:31:22 +0000 / enh / revision 1515
src/e/edit/EditServer.java: it's not the Unix way to report success.
2009-03-03 05:30:08 +0000 / enh / revision 1514
src/e/edit/EditServer.java: behave better when given the name of a non-existent workspace.
2009-03-03 05:26:26 +0000 / enh / revision 1513
bin/evergreen:
src/e/edit/CloseWorkspaceAction.java:
src/e/edit/EditServer.java:
src/e/edit/Evergreen.java:
src/e/edit/EvergreenMenuBar.java:
src/e/edit/EvergreenTabbedPane.java:
src/e/edit/RemoveWorkspaceAction.java:
www/manual.html: instead of the scary-sounding "Remove Workspace", Ed suggests "Close Workspace".
2009-03-03 05:17:33 +0000 / enh / revision 1512
src/e/edit/Evergreen.java: re-remove the lines removed in r1500 which I didn't realize until r1503 fixed one of the problems I was trying to fix: that closing a workspace with no unsaved changes didn't also close that workspace's files.
2009-03-03 04:28:48 +0000 / mad / revision 1511
src/e/edit/Evergreen.java: This call was mistakenly removed yesterday. It's caused similar trouble before. workspaceConfigurationDidChange cannot make this call to moveFilesToBestWorkspaces because the workspace on which we're calling that method has been removed from the workspace index. It has to be removed from the workspace index before we make this call, otherwise the call won't move any of the remaining files.
2009-03-03 01:42:55 +0000 / mad / revision 1510
src/e/edit/WorkspaceProperties.java: Elliott points out that, while the ordering was more natural but the behavior was functionally wrong, neglecting the very case that I addressed with my first check-in.
2009-03-03 01:33:29 +0000 / mad / revision 1509
src/e/edit/WorkspaceProperties.java: This seems a more natural ordering to the code, though it still feels fragile.
2009-03-03 01:00:56 +0000 / mad / revision 1508
src/e/edit/WorkspaceProperties.java: If the caller passes a name, then we shouldn't allow filenameChooserField.setPathname to overwrite it. If the user then uses the filenameChooser, all bets are off, but the initial value of should be as passed-in. This fixes Edit Workspace, which wasn't displaying the current workspace name but instead the last component of the root directory's path. It also fixes Add Workspace for a directory under an existing workspace root, where the code in AddWorkspaceAction intends to set a default workspace name that includes the parent workspace name. According to the salma-hayek r2905, Elliott never does that, so this change shouldn't affect him.
In my previous check-in, I erroneously wrote that my next fix would be in salma-hayek. This was the fix that I was referring to.
2009-03-03 00:41:42 +0000 / mad / revision 1507
src/e/edit/AddWorkspaceAction.java: salma-hayek r2905 renders this code dead but also solves the remaining problem here, documented in the comment, in a superior way. By passing properties.name as null by default, we're saying that the filenameChooserField gets to choose the workspace name from the root directory's name. When editing /tmp/make/src/Makefile, the user will clearly want to change the root directory from /tmp/make/src to /tmp/make, which will now happily optimize the workspace name. r2905 has also killed the first arm of the conditional here, without solving the problem I was addressing there, but the fix for that lies in salma-hayek.
2009-03-02 04:49:28 +0000 / enh / revision 1506
src/e/edit/Workspace.java: use the "this.x = newX;" style for all setters in this class.
2009-03-02 04:47:01 +0000 / enh / revision 1505
src/e/edit/Evergreen.java:
src/e/edit/Workspace.java: Phil made the sensible suggestion that Workspace (which is represented by a tab in the UI) configure its own tab. This relieves Evergreen of the responsibility, and lets us update the tab configuration as things change.
2009-03-02 02:34:57 +0000 / enh / revision 1504
src/e/edit/Evergreen.java: there aren't many dialogs in stuff I wrote myself that make me wonder "why are you asking me whether you should perform the harmless action I just asked of you?" every time I see them, but this was one. Lose it.
www/manual.html: update the documentation, which seems like the more logical place to explain exactly what "Remove Workspace" means. (After all, if you were scared that it might remove stuff from disk, you wouldn't have chosen it from the menu and hoped it would show you a comforting message, would you?) If this causes too much confusion/worry among users, we could say "forget" instead of "remove" in the UI too. It's an unusual verb for UI text, but perhaps the most appropriate one here.
2009-03-02 02:22:02 +0000 / enh / revision 1503
src/e/edit/Evergreen.java: remove a warning about a bug fixed by only iterating over the still-open workspaces, and add the check we really want: a check for unsaved changes.
2009-03-02 02:14:42 +0000 / enh / revision 1502
src/e/edit/Evergreen.java: inlining had made it clear that we were potentially calling workspaceConfigurationDidChange twice in quick succession when creating a new workspace.
2009-03-02 02:11:50 +0000 / enh / revision 1501
src/e/edit/Evergreen.java: there's no reason why you shouldn't be able to remove the last workspace. The first time Evergreen starts, there are no workspaces.
2009-03-02 02:10:06 +0000 / enh / revision 1500
src/e/edit/EditWorkspaceAction.java:
src/e/edit/Evergreen.java: all the places we were manually calling moveFilesToBestWorkspaces would call reorganizeWorkspacesAfterConfigurationChange soon after, which would make the call for us. Remove the manual calls. Rename reorganizeWorkspacesAfterConfigurationChange to workspaceConfigurationDidChange, which is shorter and has more precedent. Inline moveFilesToBestWorkspace into its only caller, to force new code to call the more functional higher-level method instead.
2009-03-02 01:54:20 +0000 / enh / revision 1499
TODO: these two jobs have been done for a while.
2009-03-02 01:54:02 +0000 / enh / revision 1498
www/manual.html: update the documentation.
2009-03-02 01:46:22 +0000 / enh / revision 1497
bin/evergreen:
src/e/edit/EditServer.java:
src/e/edit/Evergreen.java: add "evergreen --remove-workspace". I've inlined the misleadingly-named removeWorkspaceByName into createWorkspace, its only caller.
2009-03-02 01:04:24 +0000 / enh / revision 1496
bin/evergreen:
src/e/edit/EditServer.java: add support for "evergreen --add-workspace".
2009-02-21 19:51:16 +0000 / enh / revision 1495
src/e/edit/Evergreen.java: declare Evergreen as GPL 2 or later.
2009-02-13 19:04:28 +0000 / mad / revision 1494
lib/data/spelling-exceptions-C++: I don't see any reference to stdint.h or the types defined therein in the C++ Standard. uintptr_t is one particularly useful type defined therein, and one whose name we already include in this list.
2009-02-11 06:15:42 +0000 / enh / revision 1493
src/e/edit/ShellCommand.java: since we create two threads per process, distinguish them with different names.
2009-02-11 05:43:19 +0000 / enh / revision 1492
src/e/edit/BuildAction.java:
src/e/edit/GoToTagAction.java:
src/e/edit/NewFileAction.java:
src/e/edit/OpenImportAction.java: fix callers that appear to have been using Workspace.getCanonicalRootDirectory instead of Workspace.getRootDirectory out of superstition rather than need.
2009-02-11 01:35:51 +0000 / mad / revision 1491
src/e/edit/ShellCommand.java: A code-comment's probably due.
2009-02-11 01:33:33 +0000 / mad / revision 1490
src/e/edit/ShellCommand.java: Elliott's suggestion to work around SwingWorker's MAX_WORKER_THREADS limit by giving each of these tasks, which could take arbitrarily long, their own thread. If we're creating ShellCommands at a high enough rate that these dedicated threads become a problem, we'll probably run out of some other resource first anyway.
To test, kick of 10 (say) revisiontool instances and then try to Rescan in an Open Quickly window. From the Open Quickly dialog, you'd think the rescan had never terminated, until you close some of the revisiontool instances. Another sign that something's wrong is that the 11th instance of revisiontool's Command Output window remains empty instead of getting the usual:
2009-02-10T17:26:03.287-0800 RevisionTool: Java 1.6.0_10 (VM 11.0-b15, runtime 1.6.0_10-b33)
2009-02-10T17:26:03.288-0800 RevisionTool: Linux 2.6.18-4-amd64/amd64 x2
2009-02-10T17:26:03.464-0800 RevisionTool: Revision 548 (2889)
2009-02-10T17:26:03.464-0800 RevisionTool: Built 2009-02-10T09:19:37-08:00
One of these days, I will be able to delete all the debugging printfs I've littered throughout the Open Quickly code.
2009-01-29 05:19:01 +0000 / enh / revision 1489
www/manual.html: the File Properties dialog isn't documented, and I can't think of anything very useful to say about it, but I did notice some accidentally vague (and now misleading) text in the manual.
2009-01-29 05:16:14 +0000 / enh / revision 1488
src/e/edit/FilePropertiesAction.java: this looks so bad on Linux I'm ashamed to ship it, but it would have saved susiw some error-prone manual copying and it's easier (and less likely to accidentally get in the way) than my old idea of making the text in the title bars directly copyable.
TODO: job done, but maybe we'll be back.
2009-01-29 04:37:09 +0000 / enh / revision 1487
src/e/edit/ETextAction.java: it's not obvious why an ETextAction shouldn't require a text window to work on (and those subclasses that weren't overriding isEnabled were incorrectly enabled in that case).
src/e/edit/CheckForLintAction.java:
src/e/edit/ExternalToolAction.java:
src/e/edit/InsertInterfaceAction.java:
src/e/edit/RevertToSavedAction.java:
src/e/edit/SaveAllAction.java:
src/e/edit/ShowCounterpartAction.java: these were correct.
src/e/edit/CycleWorkspacesAction.java:
src/e/edit/FindFilesContainingSelectionAction.java:
src/e/edit/NewFileAction.java:
src/e/edit/OpenQuicklyAction.java: these shouldn't have been ETextActions.
src/e/edit/OpenImportAction.java: this threw NullPointerException if called when it shouldn't be.
2009-01-29 03:56:01 +0000 / enh / revision 1486
src/e/edit/FilePropertiesAction.java: turn two fields into the locals they should have been. (This bug won't have caused trouble because the dialog is only used as a modal dialog, but it's misleading, and an accident waiting to happen.)
2009-01-28 22:08:51 +0000 / mad / revision 1485
src/e/edit/TagType.java: Susi got this:
2009-01-28T11:57:17.818-0800 Evergreen: Problem creating backup file before saving "~/work/eaglecrest2/axalon/manager/web/templates/app/screens/protocols/ShareList.vm"
Associated exception:
java.lang.IllegalArgumentException: Illegal group reference
at java.util.regex.Matcher.appendReplacement(Matcher.java:706)
at java.util.regex.Matcher.replaceAll(Matcher.java:806)
at java.lang.String.replaceAll(String.java:2000)
at e.edit.TagType.describe(TagType.java:78)
at e.edit.TagReader$Tag.describe(TagReader.java:260)
at e.edit.TagReader$Tag.toString(TagReader.java:264)
at javax.swing.tree.DefaultMutableTreeNode.toString(DefaultMutableTreeNode.java:1229)
at javax.swing.JTree.convertValueToText(JTree.java:1139)
at javax.swing.tree.DefaultTreeCellRenderer.getTreeCellRendererComponent(DefaultTreeCellRenderer.java:331)
at e.edit.TagsPanel$TagsTreeRenderer.getTreeCellRendererComponent(TagsPanel.java:108)
at javax.swing.plaf.basic.BasicTreeUI$NodeDimensionsHandler.getNodeDimensions(BasicTreeUI.java:2693)
at javax.swing.tree.AbstractLayoutCache.getNodeDimensions(AbstractLayoutCache.java:475)
at javax.swing.tree.VariableHeightLayoutCache$TreeStateNode.updatePreferredSize(VariableHeightLayoutCache.java:1342)
at javax.swing.tree.VariableHeightLayoutCache$TreeStateNode.getXOrigin(VariableHeightLayoutCache.java:1125)
at javax.swing.tree.VariableHeightLayoutCache$TreeStateNode.getNodeBounds(VariableHeightLayoutCache.java:1108)
at javax.swing.tree.VariableHeightLayoutCache.getBounds(VariableHeightLayoutCache.java:202)
at javax.swing.plaf.basic.BasicTreeUI.getPathBounds(BasicTreeUI.java:511)
at javax.swing.JTree.getPathBounds(JTree.java:1642)
at e.gui.ETree.scrollPathToVisible(ETree.java:82)
at e.edit.TagsUpdater.selectTreeNode(TagsUpdater.java:200)
at e.edit.TagsUpdater.selectTagAtCaret(TagsUpdater.java:87)
at e.edit.TagsUpdater.access$200(TagsUpdater.java:15)
at e.edit.TagsUpdater$3.caretMoved(TagsUpdater.java:78)
at e.ptextarea.PTextArea.fireCaretChangedEvent(PTextArea.java:153)
at e.ptextarea.PTextArea.setSelectionWithoutScrolling(PTextArea.java:266)
at e.ptextarea.PTextArea.setSelection(PTextArea.java:233)
at e.ptextarea.PTextArea.select(PTextArea.java:227)
at e.edit.ETextWindow.writeToFile(ETextWindow.java:750)
at e.edit.ETextWindow.save(ETextWindow.java:685)
at e.edit.SaveAction.actionPerformed(SaveAction.java:18)
at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1849)
at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2169)
at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420)
at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258)
at javax.swing.AbstractButton.doClick(AbstractButton.java:302)
She was trying to save some kind of file that had been treated by Evergreen as XML. Extra debugging revealed that the "identifier" in question was:
2009-01-28T13:35:31.562-0800 Evergreen: identifier == #renderPageNavJavascript($shares)
The code fragment including that was:
<link href="/css/axalon.css" rel="styleSheet" type="text/css">
#renderPageNavJavascript($shares)
<div align="center">
Pattern.quote didn't help. I didn't try StringUtilities.regularExpressionFromLiteral though I believe it would have done the trick, because it would have changed other characters that shouldn't be changed. It might well be that none of them would ever have caused a problem but that still leaves a nasty taste in mouth from not revealing the intention. Hmm, shouldn't the method names "regularExpressionFromLiteral" and now "replacementStringFromLiteral" be verbized?
2009-01-27 19:28:07 +0000 / mad / revision 1484
src/e/edit/BuildAction.java: Fix backwards condition meaning that non-default build targets didn't work.
2009-01-26 03:09:32 +0000 / enh / revision 1483
src/e/edit/BuildAction.java:
src/e/edit/EvergreenMenuBar.java:
www/manual.html: implement and document a trivial "Build and Test Project" feature, to free me from one common case in which I still use the terminal. It may be that something more general would be useful, but "test" is an especially important target.
2009-01-22 05:55:09 +0000 / enh / revision 1482
src/e/edit/GoToTagAction.java:
src/e/edit/ShowMisspellingsAction.java: track API change.
2009-01-22 04:34:24 +0000 / enh / revision 1481
src/e/edit/GoToTagAction.java:
src/e/edit/ShowMisspellingsAction.java: use ComponentUtilities.setJListAction.
2009-01-18 22:44:40 +0000 / mad / revision 1480
src/e/edit/AddWorkspaceAction.java: I've been adding and removing workspaces a fair bit recently, mainly but not always as a work-around for having too many files open at once and not being at a convenient point to stop and work out which ones I can close. When I'm creating an overlapping workspace like this, the Add Workspace dialog could choose defaults for all three fields that would always be perfect. I never bother manually setting the build target on the "child" workspace to be the same as the "parent" and that's sure to cause me confusion at some point.
When I've done cd /tmp && apt-get source <package> && cd <package>-<tab> && sgrep <identifier> && evergreen <grep result>, the file ends up on some arbitrary workspace. I usually want to do more searches in the same package's source. Here, Add Workspace could populate the dialog with choices that would be perfect some of the time and easily edited the rest of the time. Yeah, typing /tmp isn't much hassle but the empty defaults has usually led me back to the terminal.
2009-01-18 20:19:46 +0000 / mad / revision 1479
bin/evergreen: Fix the reading of the JavaDoc summary on Windows. I thought I'd seen this working in an older version and that this had therefore been a regression at some point but further investigation suggests that it has always been broken but that you could previously successfully "research" a class whose name was under the caret. Now you can also "research" eg getenv.
2009-01-17 02:36:51 +0000 / enh / revision 1478
src/e/edit/EvergreenMenuBar.java: use JMenu.addSeparator more consistently.
2009-01-16 07:23:14 +0000 / enh / revision 1477
src/e/edit/TagsUpdater.java: this doesn't make much difference, but let's discourage the practice of direct manipulation of the action and input maps where it's unnecessary.
2009-01-04 22:45:23 +0000 / enh / revision 1476
src/e/edit/TagsPanel.java: mad suggests overriding getToolTipText in our tree cell renderer rather than calling setToolTipText, to delay getting the line text until we really need it (in light of the recent changes, not as an efficiency measure). This doesn't fix our underlying "we might be out of date" problem, but it makes it less likely to bite (you'd almost need to be in two places at once now, one modifying the text, the other causing the tool tip to be shown).
2009-01-04 20:29:00 +0000 / mad / revision 1475
src/e/edit/ETextWindow.java: Don't restore the caret position beyond the new end of the buffer. *At* the end, though, should be fine. If a buffer has length one, then the caret can be at offset zero or offset one. This doesn't entirely rid my test case of exceptions. With a file whose on-disk content is a single new line, I still see the like of the exception below. I haven't investigated that yet but this change feels like a step in the right direction.
2009-01-04T12:24:11.247-0800 Evergreen: Exception occurred during event dispatching.
Associated exception:
java.lang.IndexOutOfBoundsException: Index: 2, Size: 2
at java.util.ArrayList.RangeCheck(ArrayList.java:546)
at java.util.ArrayList.get(ArrayList.java:321)
at e.ptextarea.PLineList.validateStartPositions(PLineList.java:213)
at e.ptextarea.PLineList.getLine(PLineList.java:107)
at e.ptextarea.PTextArea.getLineStartOffset(PTextArea.java:531)
at e.ptextarea.PTextArea.getLineText(PTextArea.java:373)
at e.edit.TagsPanel$TagsTreeRenderer.getTreeCellRendererComponent(TagsPanel.java:122)
at javax.swing.plaf.basic.BasicTreeUI.paintRow(BasicTreeUI.java:1413)
at javax.swing.plaf.basic.BasicTreeUI.paint(BasicTreeUI.java:1203)
at apple.laf.AquaTreeUI.paint(AquaTreeUI.java:129)
at javax.swing.plaf.ComponentUI.update(ComponentUI.java:154)
at javax.swing.JComponent.paintComponent(JComponent.java:743)
at javax.swing.JComponent.paint(JComponent.java:1006)
at javax.swing.JComponent._paintImmediately(JComponent.java:4890)
at javax.swing.JComponent.paintImmediately(JComponent.java:4676)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:477)
at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:114)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:461)
at e.debug.EventDispatchThreadHangMonitor.dispatchEvent(EventDispatchThreadHangMonitor.java:191)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
2009-01-03 01:01:43 +0000 / enh / revision 1474
src/e/edit/HtmlTagger.java:
src/e/edit/TagsUpdater.java:
src/e/edit/TagType.java: add a primitive HTML tagger that I've been using for a while. It's pretty basic, but it's useful.
2009-01-03 00:57:09 +0000 / enh / revision 1473
src/e/edit/Workspace.java: remove dead code.
2009-01-03 00:55:52 +0000 / enh / revision 1472
src/e/edit/BuildAction.java:
src/e/edit/CheckForLintAction.java:
src/e/edit/EErrorsWindow.java:
src/e/edit/Evergreen.java:
src/e/edit/ExternalToolAction.java:
src/e/edit/KillErrorsAction.java:
src/e/edit/ShellCommand.java:
src/e/edit/StreamMonitor.java:
src/e/edit/Workspace.java: move to having more than one EErrorsWindow per Workspace, so you can do multiple things at once and keep the output separate.
2009-01-02 03:24:55 +0000 / enh / revision 1471
src/e/edit/Evergreen.java: 10 years. Quality!
bin/evergreen-boilerplate-generator: Talc has full GNU-style headers, and it's a pain keeping them up to date, and not obviously very useful. I don't know why I bothered with this one.
2009-01-01 18:27:36 +0000 / enh / revision 1470
www/manual.html: add another example external tool, which was something simonj actually asked how to do.
2008-12-31 23:39:10 +0000 / enh / revision 1469
src/e/edit/EvergreenTabbedPane.java: use the new TabbedPane.provideMenuItems API.
2008-12-31 23:21:14 +0000 / enh / revision 1468
www/manual.html: update the documentation now one more tab is accessible from the keyboard.
2008-12-31 23:06:41 +0000 / enh / revision 1467
src/e/edit/Evergreen.java: use TabbedPane.moveTab (which isn't necessary, but means we're future-proof if we start to use more of JTabbedPane's features in Evergreen, as we already do in Terminator), and move the code for reporting workspace root problems...
src/e/edit/EvergreenTabbedPane.java: ...to EvergreenTabbedPane.getToolTipTextAt, where we also ensure the warning's color is red. (Setting a tab's foreground color has no effect with the GTK+ LAF, and even for LAFs where it is visible, it's nice to have the actual problem made to stand out better.)
2008-12-31 22:19:59 +0000 / enh / revision 1466
src/e/edit/EvergreenMenuBar.java:
src/e/edit/EvergreenTabbedPane.java: share the code in e.gui.TabbedPane to remove some duplication and add support for an extra numbered tab (0, after 9, which was implemented in Terminator but previously considered "more work than it's probably worth" in Evergreen). Also fix a long-standing (but never investigated) bug caused by the potential early "return null" here, which would cause us to ignore any set tool tip text on tabs that didn't get assigned a keyboard equivalent.
2008-12-31 21:46:35 +0000 / enh / revision 1465
src/e/edit/Evergreen.java: rename "getWorkspaceIndexInTabbedPane" to "chooseIndexInTabbedPane" so that it's clearer we're not getting anything; we're actually providing a suggested future state.
2008-12-30 23:03:57 +0000 / mad / revision 1464
src/e/edit/Evergreen.java: But I need to moveFileToBestWorkspaces only after removing the workspace from the collection of workspaces, otherwise it will be the best workspace for its files.
2008-12-30 22:47:19 +0000 / mad / revision 1463
src/e/edit/Evergreen.java: Removing a workspace which contained open files would, since my previous batch of changes here, throw away Evergreen's state for those open files. That's because the moveFilesToBestWorkspaces iterates over getWorkspaces but getWorkspaces is implemented by iterating over the tabbedPane, from which we've already removed the workspace whose files we need to move.
2008-12-28 04:45:02 +0000 / enh / revision 1462
src/e/edit/NewFileAction.java: use the new overload of StringUtilities.writeFile that takes a List<String>, introduced after noting that the only other caller of writeFile(..., join(...)) had the same problem as was just fixed here.
2008-12-25 21:01:09 +0000 / mad / revision 1461
src/e/edit/NewFileAction.java: evergreen-boilerplate-generator's C++ header file generator generates a trailing new line, as it should, but this join throws it away. At some point, I had trouble displaying the differences between two versions of a header because a certain tool for examining such doesn't like '\ No newline at end of file' (and license issues mitigate against committing the fix for that). When saving manually, Evergreen resurrects the newline these days, so it would be hard for anyone to trip over this any more. But still.
2008-12-20 03:09:17 +0000 / mad / revision 1460
src/e/edit/Evergreen.java: Elliott wants to do the adding and removing differently but suggests that I write the sorting and leave that stuff, which he's thought about and which I don't understand the need for, to him.
2008-12-20 03:05:25 +0000 / mad / revision 1459
bin/evergreen: We store more than just preferences there, so the name Terminator uses for this variable is more appropriate, if a bit greybeardy. Provide EVERGREEN_DOT_DIRECTORY by analogy with TERMINATOR_DOT_DIRECTORY. I was surprised to find that we don't already offer this. I suggested it as a way of grouping related workspaces and, just afterwards, realized that it would make it easier for me to test Evergreen changes, like the ones I've been committing without testing because it takes so many minutes to index my workspaces.
2008-12-19 21:28:05 +0000 / mad / revision 1458
src/e/edit/Evergreen.java: Call moveFilesToBestWorkspaces from within fireTabbedPaneTabCountChange. Rename the latter, to a name that better indicates when it should have been called but which is still clunky, and publicize it, re-hiding moveFilesToBestWorkspaces...
src/e/edit/EditWorkspaceAction.java: ... so we need to call the new entry point instead, thus saving the edits the user just made. Lose the FIXME about tab ordering to the implementation of reorganizeWorkspacesAfterConfigurationChange.
2008-12-19 21:22:02 +0000 / mad / revision 1457
src/e/edit/Evergreen.java: Well, OK, another small step first. Comparison of removeWorkspaceByName and removeWorkspace suggests that there were two missing lines in the former. Add those, again to make the correctness of the next change clearer.
2008-12-19 21:19:36 +0000 / mad / revision 1456
src/e/edit/Evergreen.java: Move addWorkspaceToTabbedPane's call of fireTabbedPaneTabCountChange up to its only caller, to make the correctness of the next change clearer.
2008-12-19 06:38:55 +0000 / mad / revision 1455
src/e/edit/EditWorkspaceAction.java: There's another, similar infelicity here, but I'm too tired to try to fix it tonight.
2008-12-19 06:01:07 +0000 / mad / revision 1454
src/e/edit/Evergreen.java: Expose moveFilesToBestWorkspaces...
src/e/edit/EditWorkspaceAction.java: ... so that, when you edit the workspace to move the root directory up the hierarchy, your edited workspace can steal files from other workspaces. I haven't tested this.
I'm not sure this is The Right Way to do this. Previously, the Evergreen class mediated all actions which called moveFilesToBestWorkspaces, so perhaps editing a workspace should be mediated there too. Alternatively, perhaps Workspace.setRootDirectory should call up to Evergreen, which is, in some sense, its container and owner. That might conceivably cause the Workspace to be reentered part way through its constructor, which also uses setRootDirectory. It felt inelegant.
src/e/edit/Workspace.java: Remove some bogus trailing spaces which poked me in the eye as I was scrolling around.
2008-12-01 00:11:43 +0000 / enh / revision 1453
lib/data/spelling-exceptions-Ruby: automatically collecting keywords from the appropriate styler was one of the first improvements I made to checking code spelling; this file is no longer needed.
2008-11-28 04:11:38 +0000 / enh / revision 1452
lib/data/spelling-exceptions-Ruby:
lib/scripts/list-ruby-words.rb: looking at the source to Ruby 1.8, I found where the last few names were hiding.
2008-11-28 04:02:14 +0000 / enh / revision 1451
lib/scripts/list-ruby-words.rb: c.methods() basically gives us the "static" methods, but we want all methods.
2008-11-28 03:47:01 +0000 / enh / revision 1450
lib/scripts/list-ruby-words.rb: collect global variables too.
lib/data/spelling-exceptions-Ruby: stop hard-coding names we now get for free, and add one we've never had (but which I've always thought an ugly Perlism that nice people don't use anyway).
2008-11-28 02:25:23 +0000 / enh / revision 1449
lib/scripts/list-ruby-words.rb: add a script that uses reflection to come up with a list of Ruby identifiers...
lib/data/spelling-exceptions-Ruby: ...so we can lose most of our hard-coded list of spelling exceptions for Ruby...
src/e/edit/RubyDocumentationResearcher.java: ...and collect them when we start up instead.
2008-11-20 20:27:17 +0000 / mad / revision 1448
lib/data/spelling-exceptions-Ruby: I'd assumed that foreach was some deprecated synonym for each but it's actually a class method on Dir. I could still be persuaded that it's a bad idea.
$stderr.puts(), though, that's not a bad idea. And, if we're going to include $stderr, it would seem churlish to refuse $stdout and $stdin.
2008-11-08 17:35:33 +0000 / enh / revision 1447
src/e/edit/InsertInterfaceAction.java:
src/e/edit/JavaDoc.java:
src/e/edit/JavaResearcher.java:
src/e/edit/TagsUpdater.java: JDK7's javac now warns about use of raw types.
2008-10-16 02:43:29 +0100 / mad / revision 1446
src/e/edit/NewFileAction.java: Use quoting that's resistant to spaces and backslashes in the filenames, including the evergreen-boilerplate-generator filename. Both of those are almost certain to happen on Windows where this script will be installed under in a directory under "C:\Program Files\". This doesn't solve Nikos's problem, because bash won't execute 'C:\whatever'. Great.
There must be a better way of doing this quoting but this seems like a step in the direction of robustness on all platforms.
2008-10-15 05:30:06 +0100 / enh / revision 1445
www/index.html: explicitly link to the group.
2008-10-15 05:23:33 +0100 / enh / revision 1444
www/index.html: add back the now-missing decoration, and slip in a nice clear link to the manual.
2008-10-14 06:25:01 +0100 / enh / revision 1443
TODO: updates.
2008-10-14 05:05:18 +0100 / enh / revision 1442
www/manual.html: a stab in the dark at being a bit more helpful in explaining find/replace.
2008-09-30 05:10:21 +0100 / enh / revision 1441
src/e/edit/Evergreen.java: remove some dead code and data, and make a load of implementation-detail methods private.
2008-09-30 04:58:24 +0100 / enh / revision 1440
src/e/edit/FindInFilesDialog.java:
src/e/edit/OpenQuicklyDialog.java: there's no reason for these two methods to be public.
2008-09-20 03:44:46 +0100 / enh / revision 1439
lib/scripts/epydoc.py: remove cruft.
2008-09-20 03:43:55 +0100 / enh / revision 1438
bin/evergreen:
man/1/edit-and-block.1:
man/1/evergreen.1:
README: point users at the new evergreen-users group.
2008-09-14 01:14:01 +0100 / enh / revision 1437
src/e/edit/TagReader.java: the local 'filename' in processTagLine was unused, so make its group a non-capturing group, and renumber the later groups. Add missing "final"s.
2008-09-14 01:05:29 +0100 / enh / revision 1436
src/e/edit/JavaDoc.java: stop using a raw type.
2008-09-14 01:01:55 +0100 / enh / revision 1435
src/e/edit/FindAction.java: invoke static methods as such.
2008-09-14 00:59:22 +0100 / enh / revision 1434
src/e/edit/OpenQuicklyDialog.java: remove unused local.
2008-09-14 00:58:23 +0100 / enh / revision 1433
src/e/edit/OpenQuicklyDialog.java: remove unused inner class.
2008-09-14 00:54:27 +0100 / enh / revision 1432
src/e/edit/TagReader.java: remove unthrown exception from "throws" clause.
2008-09-14 00:53:27 +0100 / enh / revision 1431
src/e/edit/JavaResearcher.java: remove unread local.
2008-09-14 00:51:45 +0100 / enh / revision 1430
src/e/edit/TagsUpdater.java: remove unused imports.
2008-09-14 00:51:21 +0100 / enh / revision 1429
src/e/edit/TagsPanel.java: remove unused import, sort remaining imports.
2008-09-14 00:47:38 +0100 / enh / revision 1428
src/e/edit/ScrollToSelectionAction.java: remove unused import.
2008-09-14 00:47:15 +0100 / enh / revision 1427
src/e/edit/OpenImportAction.java: remove unused import.
2008-09-14 00:46:55 +0100 / enh / revision 1426
src/e/edit/EvergreenPreferences.java: remove unused import.
2008-09-14 00:46:39 +0100 / enh / revision 1425
src/e/edit/CheckForLintAction.java: remove unused import.
2008-09-14 00:46:07 +0100 / enh / revision 1424
src/e/edit/ChangeFontAction.java: remove unused import.
2008-09-10 21:03:00 +0100 / mad / revision 1423
src/e/edit/TagsUpdater.java: We depend on kidSortKeys only being updated in lock-step with the underlying Vector, so let's not pretend this is a publicly safe getter method. Perhaps a better name could be devised or perhaps it should be inlined into the one caller but privacy will be uncontroversial.
2008-09-10 20:59:01 +0100 / mad / revision 1422
src/e/edit/TagsUpdater.java: Elliott says:
i keep thinking "hey, why are we duplicating that? we know the kid's names". but really it's their sort keys or whatever you'd call them.
For me, it was really the "s" on "kids" that was catching me out.
2008-09-10 19:23:21 +0100 / mad / revision 1421
src/e/edit/TagsUpdater.java: Avoid inspecting the text area from the background, unsafely. Instead, pass it to...
src/e/edit/TagsPanel.java: ... the renderer, which is presumably running on the EDT.
src/e/edit/TagReader.java: The TagReader no longer needs to cache the toolTip.
If anything, this seems to have made the TagsUpdater stopwatch take longer on the stone1/.../soapC.cpp test case, but not outside the bounds of the possible noise. In any case, safety was the motivator here. Elliott said "the only reason i can think of for doing the text-getting on the wrong thread is that we were perhaps worried about the text changing without the tags updating. but since we re-tag whenever a newline is added or removed, that seems like a small window. and the current code, however well-intentioned, is unsafe (even though afaik, we've never had any trouble from it)". He's forgetting, I think, that it wasn't unsafe, I believe, until I removed the publish->process split, at his suggestion, just yesterday.
2008-09-10 17:55:11 +0100 / mad / revision 1420
src/e/edit/TagsUpdater.java: Make double sure that we don't ever generate identical sort keys. It probably doesn't matter with the current ArrayList insertion index generator but it might have done with the previous SortedTree and there's a proposal on the table to go back to a similar method.
Leave a note fingering the likely culprit for when this code rears its head again.
2008-09-10 17:41:04 +0100 / mad / revision 1419
src/e/edit/TagsUpdater.java: Elliott spots that the move the from publish->process to building the model in the background means that we're accessing the text area from a thread other than the EDT. We're only doing that to build the toolTip. The toolTip field is only used in one place - TagsTreeRenderer.getTreeCellRendererComponent. I imagine that's run on the EDT and could do the toolTip synthesis itself. Any reason not to? I didn't see one in the history.
2008-09-10 02:32:23 +0100 / mad / revision 1418
src/e/edit/TagsUpdater.java: Although this is still O(n*n) (doing n array insertions, each one copying perhaps 0.5n entries), it's a fairly clear winner over the headSet approach on my big stone1/.../soapC.cpp test. The killer argument, though, was that Elliott prefers dealing with the disguised boolean returned from binarySearch (along with the insertion index) than with the unprecedented headSet.
2008-09-10 02:22:04 +0100 / mad / revision 1417
src/e/edit/TagsUpdater.java: Using the esoteric headSet, we can work out indexOf our sort key without copying all the keys to an array each time for each tag. Sadly, that's no more efficient, at least in big-oh terms and in the JRE I'm using, than iterating over the set, incrementing a counter and returning when we've found a bigger element. Though this is still algorithmically unfortunate, it does knock nearly half off the TagsUpdater stopwatch time for my stone1/.../soapC.cpp test case.
2008-09-10 02:13:58 +0100 / mad / revision 1416
src/e/edit/TagsUpdater.java: After it tripped me up, I finally realized what Elliott meant - process() is called on the EDT with batches of the things passed to publish(). I'd assumed he was talking about done(). Unlike other similar classes, here we're updating a new model, one that Swing doesn't yet know about. Surely we don't need to update that on the EDT. Not doing so saves me about half of the stopwatch time on my big stone1/.../soapC.cpp and eliminates a number of the EDT hangs. We can do better but that's a good start, just by deleting code!
2008-09-03 04:07:26 +0100 / enh / revision 1415
src/e/edit/Advisor.java: addWordsTo was unnecessarily non-static...
src/e/edit/ETextWindow.java: ...which meant that this instantiates the Advisor the first time we open a file, long before it's actually necessary. (Bad design in turn means that instantiating the Advisor creates its heavyweight UI.)
2008-09-02 04:30:40 +0100 / enh / revision 1414
src/e/edit/AdvisorHtmlPane.java: it doesn't make sense for TextAdvice to be private and UrlAdvice public.
2008-09-02 04:24:35 +0100 / enh / revision 1413
src/e/edit/ETextWindow.java: add missing "final"s, use "private" instead of "protected" (since we have no subclasses), adhere to the usual naming conventions, and sort members into the usual order.
2008-09-02 04:15:14 +0100 / enh / revision 1412
src/e/edit/EColumn.java: EColumn.removeComponent hasn't caused trouble in forever, so remove the verbose logging.
2008-09-02 04:14:02 +0100 / enh / revision 1411
TODO: another possible change.
2008-09-02 04:09:52 +0100 / enh / revision 1410
src/e/edit/EColumn.java: inline the background painting to reduce the distraction. This code hasn't changed in forever, and the most likely future change is removal anyway.
2008-09-02 04:03:43 +0100 / enh / revision 1409
src/e/edit/EColumn.java: there's only one caller of GraphicsUtilities.paintPaper, and only one method in GraphicsUtilities. Let's not pretend it's ever likely to be used anywhere else.
2008-09-02 03:59:33 +0100 / enh / revision 1408
src/e/edit/EColumn.java: inline and simplify some code.
2008-09-02 03:48:09 +0100 / enh / revision 1407
src/e/edit/EColumn.java: factor out some more common duplication.
2008-09-02 03:32:57 +0100 / enh / revision 1406
src/e/edit/EColumn.java: factor out some common duplication.
2008-09-02 03:27:42 +0100 / enh / revision 1405
src/e/edit/EColumn.java: this makes it impossible to "squish" a window either by pushing another window up on top of it, by by pushing it down behind another window. That's the good news. The bad news is that this change makes it harder to fully compress a run of windows because refusal is binary: we either move a window or we don't. Having seen the results, I think it's obvious that what the user really wants is for us to move the "other" window as far as we can and then reevaluate how far we can move the current window.
2008-09-02 02:51:25 +0100 / enh / revision 1404
src/e/edit/EWindow.java: add missing "final" and remove dead cruft.
2008-09-02 02:40:26 +0100 / enh / revision 1403
src/e/edit/ETitleBar.java: add missing "final"s and give the superconstructor a BorderLayout rather than replacing the default FlowLayout later.
2008-09-02 02:03:21 +0100 / enh / revision 1402
src/e/edit/Advisor.java:
src/e/edit/EColumn.java:
src/e/edit/TagsPanel.java: avoid creating and then throwing away the default FlowLayout by giving the superconstructor the BorderLayout we want, rather than calling setLayout later.
2008-09-02 01:56:48 +0100 / enh / revision 1401
TODO: updates.
2008-09-01 21:10:11 +0100 / enh / revision 1400
src/e/edit/ETextWindow.java: fix a minor long-standing problem with the reporting of the selection size.
TODO: job done.
2008-09-01 20:29:14 +0100 / enh / revision 1399
src/e/edit/TagsUpdater.java: don't create the tags UI until we need it, and don't generate tags trees until we've created the UI. For my current Evergreen saved state, 59 out of 60 tag scans during start up were being thrown away. No big thing on my fast 4-core machine with everything on local disk, but creation of not-yet-needed UI was showing up stalling the EDT from time to time, and all the unnecessary tagging might be painful on slower machines/file systems. Note that the effectiveness of this change relies on the earlier change that ensures we don't give the focus to every file opened during start-up; the assumption is that if a file gets focus, that's meaningful.
2008-09-01 06:07:14 +0100 / enh / revision 1398
src/e/edit/Evergreen.java: give an intention-revealing name to the test for whether or not we've finished setting up...
src/e/edit/Workspace.java: ...and use it to avoid unnecessarily giving each file in turn the focus when starting up.
2008-09-01 05:14:10 +0100 / enh / revision 1397
src/e/edit/Evergreen.java: I was confused earlier about when the properties file was read. Since it's not really anything to do with the GUI preferences, separate it to make things obvious, and move this low level initialization earlier.
2008-09-01 04:09:23 +0100 / enh / revision 1396
src/e/edit/JavaResearcher.java: switch to the idiom used by ManPageResearcher to make it more obvious that the locking isn't broken, and to remove an unnecessary test from getSharedInstance. Output the time spent reading the "javadoc-summary.txt" file in a more useful form, and finally realize why it seems to take so long to read this file: we're waiting for a lock we don't need. (This may "explain" an old complaint of Ed's that his Evergreen took a long time to start because it spent ages reading this file, at least in that we can now say that, as we suspected, the real problem wasn't reading this file. We'll probably never know what the real problem was, though, unless it happens again.)
src/e/edit/Evergreen.java: remove the need to wait for the lock.
src/e/edit/ETextWindow.java: fix the other caller.
2008-09-01 03:47:11 +0100 / enh / revision 1395
src/e/edit/Advisor.java: rewrite the parallel researcher-initialization to (a) be correctly locked and (b) not manually mess with Threads and thread priorities.
2008-09-01 01:16:54 +0100 / enh / revision 1394
src/e/edit/Evergreen.java: initialize all researchers as early as possible...
src/e/edit/Advisor.java: ...all in parallel, all off the EDT.
src/e/edit/JavaResearcher.java: remove the special case for the JavaResearcher (which is by far the most expensive).
2008-08-25 04:01:23 +0100 / enh / revision 1393
src/e/edit/EvergreenMenuBar.java: we no longer need to add the mnemonic to the "Help" menu ourselves.
2008-08-25 00:21:12 +0100 / enh / revision 1392
src/e/edit/ShellCommand.java: track API change.
2008-08-25 00:15:29 +0100 / enh / revision 1391
src/e/edit/ShellCommand.java: track an API change.
2008-08-24 21:21:14 +0100 / enh / revision 1390
src/e/edit/ETextWindow.java: this knocks another second off the time to open a 40MiB text file on my fastest machine. I realize we've already scanned the entire content multiple times by this point, but I'd like to see the effect of all the savings we can get without merging phases before we start to think about, say, having PTextBuffer scan for merge conflict markers and Emacs modelines when trying to work out what kind of line endings it's dealing with.
2008-08-19 02:25:16 +0100 / enh / revision 1389
src/e/edit/FindInFilesDialog.java: mad wonders why he's no longer getting feedback on long searches. Luckily, it was no complicated problem involving the switch to SwingWorker 1.2; it was that I only updated one of the duration constants to be in seconds rather than milliseconds. (I'm sure TimeUnit would have seen more widespread use if it hadn't been an enum, and this kind of mistake would be much harder to make.)
2008-08-18 05:34:07 +0100 / enh / revision 1388
src/e/edit/ManPageResearcher.java: try harder to make a nice job of the SYNOPSIS section. I'm also talking to Rolf Howarth about http://www.squarebox.co.uk/users/rolf/download/manServer.shtml because it might make more sense for my effort to go into making that suitable for our purposes than fighting rman(1). manServer wouldn't offer any immediate improvement, but it produces better HTML and is more hackable (despite being in Perl).
2008-08-18 02:46:17 +0100 / enh / revision 1387
src/e/edit/ManPageResearcher.java: cope with TOCs that include subsections *and* searches that return multiple pages.
2008-08-18 02:30:46 +0100 / enh / revision 1386
src/e/edit/Advisor.java: try to minimize the number of places we add "<html>", both for simplicity and in the hope that we can consistently show a white background (rather than sometimes showing a gray one).
2008-08-18 02:16:10 +0100 / enh / revision 1385
src/e/edit/Advisor.java: ensure we admit to failure rather than pretending that we're still searching, and add information to the log that might help us reproduce the problem. Tested by deliberately breaking JavaDoc.findSourceFilenames to cause a failure similar to that fixed by r1382.
2008-08-17 22:20:04 +0100 / enh / revision 1384
bin/evergreen-boilerplate-generator: make things clearer by using "path" for paths, use File::SEPARATOR rather than assuming "/", and add support for the extra JUnit import boilerplate.
2008-08-17 22:07:56 +0100 / enh / revision 1383
src/e/edit/CheckForLintAction.java:
src/e/edit/EErrorsWindow.java:
src/e/edit/FindInFilesDialog.java:
src/e/edit/ShellCommand.java:
src/e/edit/StreamMonitor.java:
src/e/edit/TagsUpdater.java: track the incompatible (but good) change from varargs to List<T> in the SwingWorker API between the early version we were using and the version that became part of Java 6.
2008-08-17 21:43:06 +0100 / mad / revision 1382
src/e/edit/JavaDoc.java: File.separatorChar needs Pattern-quoting on Windows but, rather than quoting just that, the whole class name should be treated as wanting a literal match. The Java researcher otherwise just claims to be searching forever on Windows.
Caused by: java.util.regex.PatternSyntaxException: Illegal/unsupported escape sequence near index 7
\bjava\lang\String\.java$
^
at java.util.regex.Pattern.error(Pattern.java:1713)
at java.util.regex.Pattern.escape(Pattern.java:2177)
at java.util.regex.Pattern.atom(Pattern.java:1952)
at java.util.regex.Pattern.sequence(Pattern.java:1885)
at java.util.regex.Pattern.expr(Pattern.java:1752)
at java.util.regex.Pattern.compile(Pattern.java:1460)
at java.util.regex.Pattern.<init>(Pattern.java:1133)
at java.util.regex.Pattern.compile(Pattern.java:847)
at e.util.PatternUtilities.smartCaseCompile(PatternUtilities.java:28)
at e.edit.WorkspaceFileList.getListOfFilesMatching(WorkspaceFileList.java:87)
at e.edit.JavaDoc.findSourceFilenames(JavaDoc.java:179)
at e.edit.JavaResearcher.makeClassLink(JavaResearcher.java:331)
at e.edit.JavaResearcher.makeClassLink(JavaResearcher.java:319)
at e.edit.JavaResearcher.listClass(JavaResearcher.java:385)
at e.edit.JavaResearcher.access$400(JavaResearcher.java:10)
at e.edit.JavaResearcher$ClassDoc.getSummary(JavaResearcher.java:176)
at e.edit.JavaResearcher$ClassDoc.getClassSummary(JavaResearcher.java:155)
at e.edit.JavaResearcher$ClassDoc.access$300(JavaResearcher.java:145)
at e.edit.JavaResearcher.makeDefaultResult(JavaResearcher.java:137)
at e.edit.JavaResearcher.makeResult(JavaResearcher.java:132)
at e.edit.JavaResearcher.research(JavaResearcher.java:502)
at e.edit.Advisor$ResearchRunner.doInBackground(Advisor.java:117)
at e.edit.Advisor$ResearchRunner.doInBackground(Advisor.java:101)
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)
2008-08-17 20:44:06 +0100 / enh / revision 1381
src/e/edit/Advisor.java:
src/e/edit/JavaResearcher.java:
src/e/edit/ManPageResearcher.java:
src/e/edit/StlDocumentationResearcher.java: I noticed the other night that there was some pretty crufty old code here, but didn't want to expand an already over-large patch. Since one of the changes I almost made caused mad trouble on Cygwin, let's go through and remove all the low-hanging cruft. Specifically: use final more thoroughly, use enhanced "for" instead of Iterator<T>, don't over-constrain field types where it's not meaningful, don't bother trying to be clever in classes that will only be instantiated once anyway, and bubble code (and associated FIXME comments) up so researchers depend on Advisor rather than each other (and the FIXME is next to the code in question, rather than some of its callers).
2008-08-17 18:47:37 +0100 / mad / revision 1380
src/e/edit/StlDocumentationResearcher.java: Restore the ability to open C++ source files on non-Debian installations. Not necessarily the nicest way to fix it but I still don't have a strong enough opinion on how best to cope with Java's initialization of fields with null.
2008-08-17T10:36:06.563-0700 Evergreen: Opening "C:\cygwin\home\Carolyn\software.jessies.org\work\salma-hayek\native\all\setsid\setsid.cpp"
2008-08-17T10:36:06.573-0700 Evergreen: in ContentLoader exception handler
Associated exception:
java.lang.NullPointerException
at java.util.AbstractCollection.addAll(AbstractCollection.java:303)
at e.edit.StlDocumentationResearcher.addWordsTo(StlDocumentationResearcher.java:101)
at e.edit.Advisor.addWordsTo(Advisor.java:64)
at e.edit.ETextWindow.initSpellingExceptionsFor(ETextWindow.java:59)
at e.edit.ETextWindow.getSpellingExceptionsForLanguage(ETextWindow.java:276)
at e.edit.ETextWindow.initSpellingExceptionsForDocument(ETextWindow.java:285)
at e.edit.ETextWindow.reconfigureForFileType(ETextWindow.java:350)
at e.edit.ETextWindow.reconfigureForGuessedFileType(ETextWindow.java:341)
at e.edit.ETextWindow.fillWithContent(ETextWindow.java:327)
at e.edit.ETextWindow.<init>(ETextWindow.java:95)
at e.edit.Workspace.addViewerForFile(Workspace.java:181)
at e.edit.Evergreen.openFileNonInteractively(Evergreen.java:340)
at e.edit.Evergreen.openFile(Evergreen.java:216)
at e.edit.Evergreen.openFile(Evergreen.java:232)
at e.edit.OpenQuicklyDialog.openFileAtIndex(OpenQuicklyDialog.java:90)
at e.edit.OpenQuicklyDialog.openSelectedFilesFromList(OpenQuicklyDialog.java:195)
at e.edit.OpenQuicklyDialog$4.call(OpenQuicklyDialog.java:142)
at e.edit.OpenQuicklyDialog$4.call(OpenQuicklyDialog.java:140)
at e.forms.FormDialog.acceptDialog(FormDialog.java:402)
at e.forms.FormDialog$9.actionPerformed(FormDialog.java:445)
at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318)
at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
at javax.swing.AbstractButton.doClick(AbstractButton.java:357)
at javax.swing.plaf.basic.BasicRootPaneUI$Actions.actionPerformed(BasicRootPaneUI.java:191)
at javax.swing.SwingUtilities.notifyAction(SwingUtilities.java:1636)
at javax.swing.JComponent.processKeyBinding(JComponent.java:2849)
at javax.swing.KeyboardManager.fireBinding(KeyboardManager.java:267)
at javax.swing.KeyboardManager.fireKeyboardAction(KeyboardManager.java:216)
at javax.swing.JComponent.processKeyBindingsForAllComponents(JComponent.java:2926)
at javax.swing.JComponent.processKeyBindings(JComponent.java:2918)
at javax.swing.JComponent.processKeyEvent(JComponent.java:2812)
at java.awt.Component.processEvent(Component.java:5818)
at java.awt.Container.processEvent(Container.java:2058)
at java.awt.Component.dispatchEventImpl(Component.java:4413)
at java.awt.Container.dispatchEventImpl(Container.java:2116)
at java.awt.Component.dispatchEvent(Component.java:4243)
at java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1848)
at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(DefaultKeyboardFocusManager.java:697)
at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(DefaultKeyboardFocusManager.java:962)
at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:834)
at java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:661)
at java.awt.Component.dispatchEventImpl(Component.java:4285)
at java.awt.Container.dispatchEventImpl(Container.java:2116)
at java.awt.Window.dispatchEventImpl(Window.java:2440)
at java.awt.Component.dispatchEvent(Component.java:4243)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
at e.debug.EventDispatchThreadHangMonitor.dispatchEvent(EventDispatchThreadHangMonitor.java:191)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)
2008-08-17T10:36:43.245-0700 Evergreen: Exception while opening file
2008-08-17 18:31:32 +0100 / mad / revision 1379
src/e/edit/Evergreen.java: Fix Al Hagopian's problem where restarting Evergreen would fail to reopen the files that had previously been open, where Open Quickly would fail similarly and where clicking on filenames in Find in Files would do the same. Only clicking on the matching lines worked. The only reason this worked for me is that, on one Windows machine, I never edit under what Cygwin thinks of as my home directory and, on the other Windows machine that I run Evergreen on, HOME's drive specifier was in a different case to that used in the workspace definition and we were erroneously using a case sensitive comparison to determine when to do the tilde substitution (the bug I fixed yesterday).
2008-08-16 05:18:06 +0100 / enh / revision 1378
src/e/edit/Advisor.java:
src/e/edit/NumberResearcher.java: the NumberResearcher lives on the menu these days.
2008-08-16 05:08:51 +0100 / enh / revision 1377
src/e/edit/Advisor.java:
src/e/edit/ETextWindow.java:
src/e/edit/JavaResearcher.java:
src/e/edit/ManPageResearcher.java:
src/e/edit/NumberResearcher.java:
src/e/edit/PerlDocumentationResearcher.java:
src/e/edit/PythonDocumentationResearcher.java:
src/e/edit/RubyDocumentationResearcher.java:
src/e/edit/StlDocumentationResearcher.java:
src/e/edit/WorkspaceResearcher.java: generalize the system whereby researchers can add spelling exceptions to a PTextArea's spelling checker, and let the STL researcher join in.
2008-08-16 03:43:25 +0100 / enh / revision 1376
src/e/edit/Evergreen.java:
src/e/edit/FindInFilesDialog.java:
src/e/edit/JavaDoc.java:
src/e/edit/JavaResearcher.java:
src/e/edit/ManPageResearcher.java:
src/e/edit/OpenQuicklyDialog.java:
src/e/edit/StlDocumentationResearcher.java:
src/e/edit/WorkspaceFileList.java: switch to System.nanoTime, more consistent reporting via TimeUtilities.nsToString, and more consistent use of the "final long t0 ... final long t1" idiom when timing within a method. Some of these might usefully (also) be registered with Stopwatch.
2008-08-07 06:42:25 +0100 / enh / revision 1375
src/e/edit/ShowManPageAction.java: fix the error message if no man page is found, and improve the variable names to make similar errors less likely in future.
2008-08-07 06:35:12 +0100 / enh / revision 1374
src/e/edit/ShowManPageAction.java: a new action to let you see a man page you name in a dialog.
src/e/edit/EvergreenMenuBar.java: add it to the menu bar.
src/e/edit/Advisor.java: slightly improve some of the method names (for lack of a better plan; deeper improvements could certainly be made here), and break the zero-argument showDocumentation into its two halves (making the documentation window visible and finding content to put in it).
src/e/edit/ManPageResearcher.java:
src/e/edit/PerlDocumentationResearcher.java:
src/e/edit/PythonDocumentationResearcher.java:
src/e/edit/RubyDocumentationResearcher.java:
src/e/edit/StlDocumentationResearcher.java: track the API changes, and use Matcher.find instead of Matcher.matches in a few places where it's a trivial switch.
TODO: job done, sort of.
2008-08-06 06:32:04 +0100 / enh / revision 1373
bin/evergreen: tell e.gui.HelpMenu that Evergreen actually has a manual.
2008-08-06 06:07:46 +0100 / enh / revision 1372
src/e/edit/AddWorkspaceAction.java:
src/e/edit/EditWorkspaceAction.java:
src/e/edit/RemoveWorkspaceAction.java:
src/e/edit/RescanWorkspaceAction.java: mnemonics for the "Workspace" menu actions.
2008-08-06 05:50:54 +0100 / enh / revision 1371
src/e/edit/EvergreenMenuBar.java: add mnemonics to the "Documentation" menu.
2008-08-05 07:15:26 +0100 / enh / revision 1370
src/e/edit/CheckInChangesAction.java:
src/e/edit/ShowHistoryAction.java: mnemonics for the "SCM" menu.
2008-08-05 07:07:55 +0100 / enh / revision 1369
src/e/edit/CycleWindowsAction.java:
src/e/edit/CycleWorkspacesAction.java: use 'n' and 'p' as the mnemonics for next/previous window/workspace.
2008-08-05 05:32:08 +0100 / enh / revision 1368
src/e/edit/RevertToSavedAction.java:
src/e/edit/SaveAllAction.java: add mnemonics for the "File" menu items that tend to be disabled when you're not actually doing any work.
2008-08-05 05:25:15 +0100 / enh / revision 1367
src/e/edit/EvergreenMenuBar.java:
src/e/edit/FilePropertiesAction.java:
src/e/edit/OpenQuicklyAction.java: fix the mnemonics on the "File" menu, ignoring "Open...", which we want to discourage, and improving "File Properties..." in passing so that its dialog reminds you which file it corresponds to (and makes it slightly clearer that you're only affecting that one file).
2008-08-05 05:22:40 +0100 / enh / revision 1366
src/e/edit/GoToTagAction.java: use the same quoting and capitalization style as the rest of the application.
2008-08-05 05:09:00 +0100 / enh / revision 1365
TODO: job done.
2008-08-05 05:07:31 +0100 / enh / revision 1364
lib/scripts/find-tags.rb:
src/e/edit/GoToTagAction.java: it was stupid to reproduce the cigarette burn in the gtags.sh interface, and when I ended up wrapping gtags.sh with another script anyway, I realized we'd all be better off if I just covered over that flaw in one place, rather than introducing it everywhere. The first rule of error reporting is "grep(1) style is the One True Style".
2008-08-04 07:18:46 +0100 / enh / revision 1363
www/manual.html: document new free functionality.
2008-08-04 07:12:36 +0100 / enh / revision 1362
src/e/edit/ETextAction.java: change ETextAction to use the new GuiUtilities.configureAction method...
src/e/edit/AutoCompleteAction.java:
src/e/edit/BuildAction.java:
src/e/edit/ChangeFontAction.java:
src/e/edit/CheckForLintAction.java:
src/e/edit/CloseWindowAction.java:
src/e/edit/CompareSelectionAndClipboardAction.java:
src/e/edit/CorrectIndentationAction.java:
src/e/edit/CycleWindowsAction.java:
src/e/edit/CycleWorkspacesAction.java:
src/e/edit/ExpandWindowAction.java:
src/e/edit/ExternalToolAction.java:
src/e/edit/FilePropertiesAction.java:
src/e/edit/FindAction.java:
src/e/edit/FindAndReplaceAction.java:
src/e/edit/FindFilesContainingSelectionAction.java:
src/e/edit/GoToLineAction.java:
src/e/edit/GoToTagAction.java:
src/e/edit/InsertInterfaceAction.java:
src/e/edit/JoinLinesAction.java:
src/e/edit/NewFileAction.java:
src/e/edit/OpenImportAction.java:
src/e/edit/OpenMakefileAction.java:
src/e/edit/OpenQuicklyAction.java:
src/e/edit/RevertToSavedAction.java:
src/e/edit/SaveAction.java:
src/e/edit/SaveAsAction.java:
src/e/edit/ScrollToSelectionAction.java:
src/e/edit/ShowCounterpartAction.java:
src/e/edit/ShowDocumentationAction.java:
src/e/edit/ShowMisspellingsAction.java: ...and update the callers. I've not given all of them a mnemonic, and I also know that Evergreen has many Action subclasses that aren't subclasses of ETextAction. But this is a good place to stop for tonight.
2008-08-04 03:40:44 +0100 / enh / revision 1361
src/e/edit/EvergreenMenuBar.java:
www/manual.html: remove the largely useless (and somewhat confusingly-named) "Window" menu, using its menu items to beef up the previously underpopulated "View" menu. Also add top-level mnemonics, which Linux and Windows applications usually have, and which Mac OS' Java conveniently ignores automatically.
2008-08-04 03:01:44 +0100 / enh / revision 1360
lib/scripts/find-tags.rb: a simple script to find matching tags in a "tags" file. The hard work is actually done by look(1) for now.
src/e/edit/Advisor.java: lose getSearchTerm...
src/e/edit/ETextAction.java: ...to ETextArea, where we make it available to anyone who wants it.
src/e/edit/GoToTagAction.java: such as the new "Go to Tag" action, which needs...
src/e/edit/EvergreenMenuBar.java: ..adding to the menu bar...
src/e/edit/FileIgnorer.java: ...a special hack in so that "tags" files are ignored, if we're going to encourage people to leave them lying around...
www/manual.html: ...and documentation.
2008-08-04 00:40:55 +0100 / enh / revision 1359
www/manual.html: provide a link to the list of GTK+ stock icons, and call them by their proper name.
2008-08-04 00:34:41 +0100 / enh / revision 1358
src/e/edit/GoToLineAction.java: be more consistent about capitalization.
2008-08-03 23:15:29 +0100 / enh / revision 1357
src/e/edit/Evergreen.java: fix an old regression (addresses ending in a colon not selecting the whole line as they should) which has been annoying me for years, but which has somehow escaped being investigated until now.
2008-08-03 21:40:29 +0100 / enh / revision 1356
www/manual.html: split new "Navigation" and "Selection" sections out of the existing "Editing Text", since they're non-modifying operations and fairly extensive. Also rename "Editing Text" latter simply "Editing", since we don't currently make a distinction between editing "text" and anything else. Finally, change the anchor for "Basic Building" to correspond to the other "Basic X" sections' anchors. (The unfriendliness to linking that changing anchors represents makes me wonder whether human-readable anchors are a good idea after all. Maybe they should just be arbitrary character sequences, to remove all motivation to change them, and keep them short?)
2008-08-03 21:28:00 +0100 / enh / revision 1355
www/manual.html: since this always seems to have disappeared from my Bash history by the next time I need it, provide the commands needed to test changes in copy & pasteable form.
2008-08-03 00:34:06 +0100 / enh / revision 1354
src/e/edit/PythonDocumentationResearcher.java: there's no way pydoc_binary can be null, and no reason not to use the usual Java naming convention. (There's also no reason to add a FileUtilities.exists test here; it's not unreasonable to assume that scripts we've installed are still there.)
2008-08-02 21:58:19 +0100 / enh / revision 1353
sfind:
sgrep: remove these long-unused scripts (that weren't being installed anywhere useful by our installers anyway).
2008-08-02 20:34:12 +0100 / enh / revision 1352
src/e/edit/TagReader.java: slightly improve the JavaScript support, though we're limited by the fact that even the version of ctags in Subversion isn't very good at JavaScript (understandably). Still, there's no need to make it look worse than it actually is.
2008-08-02 20:27:05 +0100 / enh / revision 1351
src/e/edit/TagReader.java: fix an escaping bug; we mean the literal two-character string '\1', not ((char) 1). Not that this makes any difference, because we only use the kind 'S' to modify our understanding of the corresponding tag generated by normal means.
2008-08-02 19:18:41 +0100 / enh / revision 1350
src/e/edit/TagsUpdater.java: let's lose the pretty useless "Search Symbols" field. Any expanded go-to-tag functionality is unlikely to be related to this.
2008-07-28 02:09:22 +0100 / enh / revision 1349
www/index.html: add the missing apostrophe caused by switching from "evolution" to "evolved" mid-sentence. This whole thing still reads awkwardly. It might help us advertise if we knew what our real selling points were.
2008-07-28 02:05:40 +0100 / enh / revision 1348
www/index.html: I'm not sure this doesn't still over-labor the whole Acme heritage, but at least it gets rid of the "I" I've tried to avoid elsewhere, and more accurately reflects true Evergreen "philosophies".
2008-07-28 01:20:40 +0100 / enh / revision 1347
www/index.html: link to the manual, now we have one. The manual is currently just a reference (and a slightly incomplete one at that). Some of this material should probably move there. But we also probably need a tutorial ("tell me the minimum I need to know to get some work done"), and we still need a feature list, though its focus should perhaps change; stuff that's unique and distinguishing being most worthy of such valuable "elevator pitch" space.
2008-07-27 00:59:01 +0100 / enh / revision 1346
src/e/edit/EErrorsWindow.java:
src/e/edit/ETextWindow.java: although Evergreen had the base conversion functionality first, it's only been available in Terminator for some time now, leading to me pasting text from Evergreen into a terminal for the sole purpose of using Terminator's base conversion functionality. So let's try to cut out the useless extra steps.
TODO: job done, after a fashion. I don't know what the best way to provide this functionality is, but I do know that Terminator's implementation has been useful, and having nothing in Evergreen has been a slight handicap.
2008-07-25 21:33:57 +0100 / enh / revision 1345
src/e/edit/WorkspaceFileList.java: remove my idiosyncratic calling of a listener when it's first added. I've always felt this would be a useful part of the observer pattern: to tell the observer "this is the starting state", but it's not generally done, and you usually have to ensure your code would work correctly without it anyway. In this specific instance, it's responsible for a useless double-search the first time you open a workspace's Open Quickly or Find in Files dialog (each workspace gets its own dialog, but each workspace reuses the same one).
2008-07-24 05:23:03 +0100 / enh / revision 1344
www/manual.html: document the newly-configurable margins.
2008-07-24 04:35:00 +0100 / enh / revision 1343
src/e/edit/ETextWindow.java: fix an annoying little bug where we'd rewrite a file like "{\n}" as "{}" on save.
2008-07-24 04:21:29 +0100 / enh / revision 1342
src/e/edit/TagReader.java: ctags(1) doesn't support .proto files.
2008-07-19 01:55:32 +0100 / mad / revision 1341
src/e/edit/BuildAction.java: John Holtom points out that, if you kick a build off inadvertently high in the directory tree and then try to kill it by closing the errors window, you're doomed not to be able to kill that build via Evergreen. He'd have worked out the Stop icon eventually, if he'd been able to get back to it.
2008-07-16 06:14:06 +0100 / enh / revision 1340
src/e/edit/JoinLinesAction.java: somewhat arbitrary though it may seem, I think vi(1)-like behavior where if the current line doesn't already end in a space, we append one, works better.
2008-07-16 05:52:51 +0100 / enh / revision 1339
src/e/edit/OpenImportAction.java: we should treat paths starting with "~" as absolute too.
2008-07-16 05:33:39 +0100 / enh / revision 1338
www/manual.html: update the documentation to include the new configuration option.
2008-07-16 05:24:35 +0100 / enh / revision 1337
src/e/edit/OpenImportAction.java: split up the C++ and Ruby defaults, add empty defaults for all other file types, and make it possible to override any import path with a property.
2008-07-16 04:52:37 +0100 / enh / revision 1336
src/e/edit/FindInFilesDialog.java:
src/e/edit/OpenQuicklyDialog.java: rather than ensure we're on the EDT in two separate places...
src/e/edit/WorkspaceFileList.java: ...let's not unreasonably assume that our listeners always want to be called on the EDT. Also add some synchronization, since we're here.
2008-07-15 20:55:34 +0100 / mad / revision 1335
src/e/edit/FindInFilesDialog.java: The file alteration monitor can cause fileListStateChanged to be called from a timer thread. Copy some code from Open Quickly to avoid altering Swing objects when not running on the EDT. Perhaps a single copy of this code should be in the caller?
Frustratingly, I'm actually looking at this code because my Open Quickly is broken - the matches aren't being displayed after a Rescan completes in one workspace. The rescan button is re-enabled.
2008-07-14 05:46:24 +0100 / enh / revision 1334
TODO: updates.
2008-07-14 05:45:33 +0100 / enh / revision 1333
src/e/edit/OpenImportAction.java: another FIXME.
2008-07-14 05:32:31 +0100 / enh / revision 1332
src/e/edit/Parameters.java: cope with "<~mad/props" and the like, rather than just "</home/mad/props".
2008-07-14 05:25:01 +0100 / enh / revision 1331
www/manual.html: a user manual for Evergreen.
www/index.html: link to the manual, and remove the material that's now moved to the manual.
2008-07-14 04:24:38 +0100 / enh / revision 1330
www/faq.html: add a TOC to the Evergreen FAQ.
2008-07-14 00:27:51 +0100 / enh / revision 1329
man/1/edit-and-block.1: explain the specific motivation for edit-and-block.
2008-07-09 06:30:54 +0100 / enh / revision 1328
src/e/edit/EvergreenMenuBar.java:
src/e/edit/JoinLinesAction.java: add another vi-user's favorite, shift-j for 'join'.
2008-07-09 05:55:54 +0100 / enh / revision 1327
src/e/edit/OpenQuicklyDialog.java: avoid modifying the UI from a thread other than the EDT unless you want deadlock:
Found one Java-level deadlock:
=============================
"FileAlterationMonitor ~/Projects/evergreen2/":
waiting to lock monitor 0x000000004060e930 (object 0x00007f610373da28, a java.awt.Component$AWTTreeLock),
which is held by "AWT-EventQueue-0"
"AWT-EventQueue-0":
waiting to lock monitor 0x00000000402561b8 (object 0x00007f6103a1ad00, a e.edit.WorkspaceFileList),
which is held by "FileAlterationMonitor ~/Projects/evergreen2/"
Java stack information for the threads listed above:
===================================================
"FileAlterationMonitor ~/Projects/evergreen2/":
at java.awt.KeyboardFocusManager.clearMostRecentFocusOwner(KeyboardFocusManager.java:1807)
- waiting to lock <0x00007f610373da28> (a java.awt.Component$AWTTreeLock)
at java.awt.Component.disable(Component.java:1329)
at javax.swing.JComponent.disable(JComponent.java:3607)
at java.awt.Component.enable(Component.java:1318)
at java.awt.Component.setEnabled(Component.java:1281)
at javax.swing.JComponent.setEnabled(JComponent.java:2664)
at javax.swing.AbstractButton.setEnabled(AbstractButton.java:2084)
at e.edit.OpenQuicklyDialog.fileListStateChanged(OpenQuicklyDialog.java:167)
at e.edit.WorkspaceFileList.fireListeners(WorkspaceFileList.java:203)
at e.edit.WorkspaceFileList.access$100(WorkspaceFileList.java:10)
at e.edit.WorkspaceFileList$FileListUpdater.<init>(WorkspaceFileList.java:125)
at e.edit.WorkspaceFileList.updateFileList(WorkspaceFileList.java:74)
- locked <0x00007f6103a1ad00> (a e.edit.WorkspaceFileList)
at e.edit.WorkspaceFileList$1.fileTouched(WorkspaceFileList.java:111)
at e.util.FileAlterationMonitor.fireFileTouched(FileAlterationMonitor.java:73)
- locked <0x00007f6103a1ad40> (a e.util.FileAlterationMonitor)
at e.util.FileAlterationMonitor.checkFileTimes(FileAlterationMonitor.java:66)
- locked <0x00007f6103a1ad40> (a e.util.FileAlterationMonitor)
at e.util.FileAlterationMonitor.access$000(FileAlterationMonitor.java:11)
at e.util.FileAlterationMonitor$1.run(FileAlterationMonitor.java:24)
at java.util.TimerThread.mainLoop(Timer.java:550)
at java.util.TimerThread.run(Timer.java:500)
"AWT-EventQueue-0":
at e.edit.WorkspaceFileList.getFileIgnorer(WorkspaceFileList.java:46)
- waiting to lock <0x00007f6103a1ad00> (a e.edit.WorkspaceFileList)
at e.edit.EErrorsWindow$ErrorLinkStyler.isAcceptableMatch(EErrorsWindow.java:165)
at e.ptextarea.RegularExpressionStyleApplicator.applyStylingTo(RegularExpressionStyleApplicator.java:28)
at e.ptextarea.PTextArea.applyStyleApplicator(PTextArea.java:866)
at e.ptextarea.PTextArea.getLineSegments(PTextArea.java:828)
at e.ptextarea.PTextArea.getLineSegmentsForSplitLine(PTextArea.java:785)
at e.ptextarea.PTextArea.getLineSegmentsForSplitLine(PTextArea.java:771)
at e.ptextarea.PTextArea.getViewCoordinates(PTextArea.java:933)
at e.ptextarea.PColoredHighlight.paintHighlight(PColoredHighlight.java:53)
at e.ptextarea.PHighlight.paint(PHighlight.java:72)
at e.ptextarea.PTextAreaRenderer.paintHighlights(PTextAreaRenderer.java:150)
at e.ptextarea.PTextAreaRenderer.render(PTextAreaRenderer.java:69)
at e.ptextarea.PTextArea.paintComponent(PTextArea.java:990)
at javax.swing.JComponent.paint(JComponent.java:1041)
at javax.swing.JComponent.paintChildren(JComponent.java:878)
- locked <0x00007f610373da28> (a java.awt.Component$AWTTreeLock)
at javax.swing.JComponent.paint(JComponent.java:1050)
at javax.swing.JViewport.paint(JViewport.java:765)
at javax.swing.JComponent.paintChildren(JComponent.java:878)
- locked <0x00007f610373da28> (a java.awt.Component$AWTTreeLock)
at javax.swing.JComponent.paint(JComponent.java:1050)
at javax.swing.JComponent.paintToOffscreen(JComponent.java:5164)
at javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManager.java:302)
at javax.swing.RepaintManager.paint(RepaintManager.java:1145)
at javax.swing.JComponent._paintImmediately(JComponent.java:5112)
at javax.swing.JComponent.paintImmediately(JComponent.java:4922)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:740)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:696)
at javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:676)
at javax.swing.RepaintManager.access$700(RepaintManager.java:57)
at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1550)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:235)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:602)
at e.debug.EventDispatchThreadHangMonitor.dispatchEvent(EventDispatchThreadHangMonitor.java:191)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:275)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:200)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:185)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:177)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:138)
Impressive we've never hit this before.
2008-07-09 05:44:10 +0100 / enh / revision 1326
src/e/edit/ETextWindow.java: I've tried, but though I know the keystroke, by brain insists on looking for "Open Import" on the context menu first.
2008-07-09 05:40:02 +0100 / enh / revision 1325
src/e/edit/EvergreenMenuBar.java: add "Find Matching Bracket", and shuffle around a bit.
2008-07-09 04:45:13 +0100 / enh / revision 1324
src/e/edit/GotoAction.java:
src/e/edit/GoToLineAction.java: rename "GotoAction" "GoToLineAction", to match the text used in the UI.
src/e/edit/EvergreenMenuBar.java: track name change.
2008-07-04 03:40:34 +0100 / enh / revision 1323
src/e/edit/OpenImportAction.java: basic support for Ruby "require" statements.
2008-07-04 02:50:05 +0100 / enh / revision 1322
src/e/edit/OpenImportAction.java: use the whole of the current line if there's no selection.
2008-07-03 07:56:52 +0100 / enh / revision 1321
src/e/edit/OpenImportAction.java: make "Open Import" able to cope with a selected line as well as just a selected header name. Add the equivalent for Java, too. Enhance the file-finding code so that we interpret non-absolute paths as being rooted at the current workspace's root. Show the path used if we fail to find anything, to give the user more of a clue about what's wrong.
2008-07-02 07:44:42 +0100 / enh / revision 1320
src/e/edit/EvergreenMenuBar.java:
src/e/edit/OpenImportAction.java: more to-do comment than code, this still manages to be useful. When finished, I have a horrible feeling it will be another of those "why didn't we do this five years ago?" features. Oh well, better late than never.
TODO: job done. Well, job started.
2008-07-02 06:42:16 +0100 / enh / revision 1319
src/e/edit/EvergreenMenuBar.java: I think "|sort" and "|sort -u" are useful enough to enough people to deserve hard-coding their availability. I'm certainly tired of adding them everywhere I go.
TODO: jobs done.
2008-06-23 07:09:07 +0100 / enh / revision 1318
man/1/edit-and-block.1:
man/1/evergreen.1: fix hyphen/minus confusion.
2008-06-18 05:53:24 +0100 / enh / revision 1317
src/e/edit/WorkspaceFileList.java: a slight time optimization that was actually motivated by a desire to make the body of scanDirectory simpler.
2008-06-18 05:45:27 +0100 / enh / revision 1316
src/e/edit/WorkspaceFileList.java: neither FileUtilities.fileFromString nor File.toString are expensive operations (being just string manipulation), but there's no point converting back and forth, and the code's slightly simpler if we don't.
2008-06-18 05:36:15 +0100 / enh / revision 1315
src/e/edit/FileIgnorer.java: make private a method that's no longer needed elsewhere.
2008-06-18 05:33:59 +0100 / enh / revision 1314
src/e/edit/FileIgnorer.java: document the irrelevance of another potential micro-optimization site.
2008-06-18 05:27:14 +0100 / enh / revision 1313
src/e/edit/FileIgnorer.java: escape the literal "." in "autom4te.cache".
2008-06-18 05:04:04 +0100 / enh / revision 1312
src/e/edit/FileIgnorer.java: stop using File.isHidden. I've raised a bug suggesting a more efficient (and cleaner) implementation, but don't have a bug id yet. I'll come back and add it to the comment when I do.
2008-06-15 03:18:46 +0100 / enh / revision 1311
src/e/edit/FileIgnorer.java:
src/e/edit/WorkspaceFileList.java: add a few intention-revealing "final"s, make it clear that getIgnoredExtensions wasn't a getter by changing its name, make it clear that it doesn't modify the ignoredExtensions field by using Beck's idiomatic name "result", avoid calling File.getName twice on the same File (for a pathetic saving), and avoid calling File.isDirectory twice on the same File to save a poor but worthwhile 10% of the indexing time on a large (30,000 file) in-cache tree.
Also add a really important comment to nameEndsWithOneOf to stop me fiddling with that method now I've actually run the right test and found that it wouldn't make any difference if I worked out how to make it free.
At the moment, most of the cost of indexing turns out to be due to File.isHidden and – to a much greater extent – FileUtilities.isSymbolicLink. The former we could trivially lose without affecting Unix (the implementation is appallingly expensive, because it assumes we're on Windows and need to actually call getBooleanAttributes rather than just examine the name), but I don't know whether removing it would cause problems for Windows (though presumably the cost is even worse on Windows, where everything related to the file system is slow). As for testing for symbolic links, we could either write our own JNI (which would help with the other stuff too, since we could implement something more like stat(2) instead of asking for the same information one bit at a time), or wait for JDK7's nio improvements.
2008-06-10 05:35:15 +0100 / enh / revision 1310
src/e/edit/ETextWindow.java: fix a NullPointerException when closing an ETextWindow.
2008-06-09 22:05:35 +0100 / mad / revision 1309
TODO: The "echo" scripts do support per-project customization and in a sufficient way to allow user-specific per-project customization but not in a way that helps project-wide customization for projects that span site boundaries.
2008-06-09 06:51:42 +0100 / enh / revision 1308
src/e/edit/ETextWindow.java: ensure that the focus gets put back where it should when the user switches between tabs.
TODO: job done.
2008-06-09 06:03:47 +0100 / enh / revision 1307
TODO: other random notes I had lying around, and the removal of yet another duplicate.
2008-06-09 05:49:42 +0100 / enh / revision 1306
TODO: merge the old and new to-do items, removing duplicates, stuff that no longer makes sense, and a few more things that have already been done.
2008-06-09 02:19:47 +0100 / enh / revision 1305
TODO: remove stuff that's already been done.
2008-06-09 01:57:54 +0100 / enh / revision 1304
TODO: append the other to-do list. Lots of stuff in both lists is already done, but I'll come through in a later pass to do something about that.
2008-06-08 04:55:50 +0100 / enh / revision 1303
README: replace the out-of-date content with a copy of what we say about Terminator.
2008-06-08 04:50:20 +0100 / enh / revision 1302
bin/epydoc.py:
lib/scripts/epydoc.py: there's no reason to pollute users' /usr/bin/ with our helper script.
src/e/edit/PythonDocumentationResearcher.java: find the script in its new location.
2008-06-08 04:44:27 +0100 / enh / revision 1301
lib/scripts: add a new directory.
2008-06-07 06:24:24 +0100 / enh / revision 1300
src/e/edit/EditServer.java: FindBugs complains about the sloppy use of wait/notify here, so switch to CountDownLatch which does the right thing and takes fewer lines of code. (Although this code was wrong, it won't have caused problems in practice because (a) we don't have multiple waiters and (b) human reaction times aren't sufficient to let the notify occur before the wait.)
2008-06-07 05:35:11 +0100 / enh / revision 1299
src/e/edit/EditServer.java: FindBugs points out an unused field.
2008-06-07 05:33:09 +0100 / enh / revision 1298
src/e/edit/EvergreenTabbedPane.java:
src/e/edit/FindInFilesDialog.java: FindBugs complains about inner classes that could be static but aren't.
2008-06-06 06:59:33 +0100 / enh / revision 1297
src/e/edit/NewFileAction.java: remove the hard-coded boilerplate generation and replace it with code to call out to a user-supplied script.
bin/evergreen-boilerplate-generator: provide a script implementing our old functionality, plus similar functionality for Java (which we didn't previously offer).
2008-06-05 17:38:08 +0100 / mad / revision 1296
src/e/edit/FileIgnorer.java: Rename echo-local-non-source-directory-pattern as echo-local-directories-evergreen-should-not-index, having deliberately waited for today's "nightly" builds to finish. Well, at least the Windows and Linux ones. I'm not privy to the output of the Mac or Solaris builds, although I could always get off my chump and look at the file time stamps. Now I'm off to rename the script in the BlueArc "misc" area and create a script with the old name which will currently just call the script with the new name. In a few days, I'll add a line to the script with the old name to pop up some nag-ware, suggesting sudo aptitude update && sudo aptitude install ~norg.jessies.
www/index.html: Change the name here too. I'm too lazy to do anything else.
2008-06-05 03:34:27 +0100 / mad / revision 1295
Support a site-wide configuration script for ignored extensions. I know, it's my time I'm wasting by not consigning these non-source files to a non-source sub-directory. But it's taking me ages to get around to beating part of BlueArc's build system back into compliance with that rule (after someone else broke it) and searching the generated non-source files in question takes long enough to cause a logged warning.
src/e/edit/EErrorsWindow.java: Defer to the Workspace(FileList) for our FileIgnorer, so it gets to worry about when FileIgnorer's configuration should be cached and when it should be reassessed.
src/e/edit/WorkspaceFileList.java: We should definitely reassess the FileIgnorer configuration when the user asks us to rescan and it's cheap enough to reassess any time we decide to rescan ourselves. It might be nice to notice that the script that's at the head of the PATH has changed but that's more effort than it's worth. Anyway, the script is *not* cheap enough to reassess for each file that we index...
src/e/edit/FileIgnorer.java: ... which was why isIgnoredExtension used to cache once, on the first call. That caching meant that you had to restart Evergreen to get it to notice changes to the "Don't index" field of the preferences dialog. Now I'm adding another way to configure the ignored extensions list - another local script - so it becomes more important to get the caching right.
What to call the new script? "echo" and "local" seem non-controversially OK. Elliott wants to mention not-indexing instead of just "uninteresting" (in which context?) or "non-source" (they might be generated source that happens never to be interesting). I wanted to mention Evergreen, or to give some other indication that we mean "don't index in your programmer's editor".
Elliott's egging me on to change echo-local-non-source-directory-pattern to "echo-local-directories-evergreen-should-not-index". The BlueArc misc repository is currently locked, so that would be inconvenient today. But I do like the pluralization and I'm happy with relegating the fact that it's interpreted as a list of patterns to the documentation.
We're also talking about removing the preference of default extensions, in favor of hard-coding the list in the source. I imagine we'd just remove the documentation and the UI but keep the code for reading any existing preference.
www/index.html: Sketchily document the new feature and a not-widely-known and probably never used feature of the existing site-wide script (the way you can use `pwd` to produce per-workspace configuration). This wants a more invasive edit, perhaps tomorrow, when I rename the directory pattern script.
2008-05-23 03:30:53 +0100 / enh / revision 1294
src/e/edit/ETextWindow.java: update the status bar in yet another place where we touch disk and give the evil that is the network a chance to stop us in our tracks.
2008-05-21 06:26:48 +0100 / enh / revision 1293
src/e/edit/EvergreenTabbedPane.java: elsewhere, we use setToolTipTextAt, so we should make sure we include any manually-set text in our automatically-generated message.
2008-05-18 19:48:57 +0100 / enh / revision 1292
src/e/edit/ETextWindow.java: if you're writing to a slow file system, there's no reason to expect that saving the backup copy will be fast and only saving the "true" copy will be slow. Quite the opposite, in fact. So let's make sure we update the status message earlier. pcn argues for saving in background thread, but that would be dangerous in face of the C-S C-B "save and build" idiom. (If we implemented auto-saving backups, that should be done in the background; it's a regular annoyance to Emacs users that Emacs doesn't. But we don't.)
2008-05-18 19:17:03 +0100 / enh / revision 1291
lib/DEBIAN-control-Depends.txt: I thought we'd got rid of manpages-posix-dev weeks ago, because it's not available in some releases' repositories, it includes a bunch of dubious section 1 manpages as well as the useful sections 2 and 3 manpages, and the various UIs don't do anything sufficiently useful with "Recommends" or "Suggests" to make it worthwhile supporting anything less than "Depends".
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-Python: unfortunately for us, though Python does sometimes use underscores and camel-case, it often just runswordstogether like 1970's C; we'll have to find a better method of coming up with the huge number of spelling exceptions we're likely to need, but for now let's just keep a list.
2006-10-11 06:08:57 +0100 / enh / revision 1010
src/e/edit/Advisor.java: mad found that relative links in JavaDoc didn't work for him, and that turned out to be because he had Sun's documentation installed locally (and was using the file: scheme) where I was using documentation off the web (and was using the http: scheme). Tweak our heuristic to recognize file URLs with fragments (to use the RFC2396 terminology; they're also known as "anchors", "refs", or "references", but I'm not sure any term is in common use).
2006-10-08 03:38:47 +0100 / enh / revision 1009
www/index.html: use an SSI include for the downloads section.
2006-10-06 21:52:19 +0100 / enh / revision 1008
lib/data/spelling-exceptions-C++: add "func" as in "__func__".
2006-09-24 07:11:12 +0100 / enh / revision 1007
src/e/edit/TagReader.java: remove the hacky implementation for recognizing abstract methods in Java and replace it with something that uses functionality built-in to Exuberant ctags that I just came across in its source. This lets us work out of the box with builds that don't have regex support, such as the one Ubuntu ships.
2006-09-19 07:35:58 +0100 / enh / revision 1006
src/e/edit/Advisor.java: don't initialize the researchers in a thread started from the Advisor constructor, now the Advisor isn't constructed at start-up. We used to assume that the thread would have finished by the time we were asked for advice, but now – since the Advisor is created the first time we're asked for advice – that's an unrealistic assumption. Indeed, without this patch the first request for advice usually returns empty-handed because the researchers aren't ready.
2006-09-16 07:40:54 +0100 / enh / revision 1005
src/e/edit/ETextWindow.java: calling the text area "text" rather than "textArea", and the associated getter "getText" rather than "getTextArea" was a confusing mistake I should have rectified long ago.
src/e/edit/CompareSelectionAndClipboardAction.java:
src/e/edit/EWindow.java:
src/e/edit/FilePropertiesAction.java:
src/e/edit/FindAction.java:
src/e/edit/FindInFilesDialog.java:
src/e/edit/ShellCommand.java:
src/e/edit/TagsUpdater.java: track API change.
2006-09-16 07:24:11 +0100 / enh / revision 1004
src/e/edit/ETextWindow.java:
src/e/edit/ShellCommand.java: remove dead fields, make a couple of utility methods static, and inline getCurrentLineNumber into its only caller.
2006-09-10 07:36:32 +0100 / enh / revision 1003
src/e/edit/ETextWindow.java: use IndentationGuesser directly, and add placeholders for all the file types that don't have an indenter yet.
2006-09-03 18:42:29 +0100 / enh / revision 1002
src/e/edit/Evergreen.java: fix opening source from the documentation browser in the case where the workspace containing the source is specified using a ~-relative path.
2006-09-03 18:38:16 +0100 / enh / revision 1001
src/e/edit/AdvisorHtmlPane.java: implement web browser keyboard navigation with home, end, space, shift-space, page up, page down, up arrow, and down arrow.
2006-09-02 08:58:52 +0100 / enh / revision 1000
src/e/edit/Advisor.java: accept ':' when selecting a word for F1, so we can more easily give help on "std::string" and the like.
2006-09-02 08:11:24 +0100 / enh / revision 999
lib/DEBIAN-control-Depends.txt: list the packages that make us work much better.
2006-09-02 06:55:39 +0100 / enh / revision 998
src/e/edit/ManPageResearcher.java: on systems that don't have PolyglotMan, make sure we turn the ASCII output from man(1) into rough HTML. It's not worth making any real effort because PolyglotMan is the real solution, so make that plain too.
2006-09-01 20:12:31 +0100 / enh / revision 997
src/e/edit/AdvisorHtmlPane.java: fix links to Ruby documentation, which had been broken since I switched to HyperlinkEvent.getURL. I knew there was a reason why I'd deliberately used getDescription before, but thought it was just a matter of fixing my HREFs so that references to files started "file://".
2006-09-01 19:55:19 +0100 / enh / revision 996
src/e/edit/JavaDoc.java: cope with the situation where a user doesn't have the "java.advisor.doc" property configured; the Java documentation links have probably been missing for most people for quite some time now. Also generalize the existing Mac OS hack for well-known local JavaDoc installations, and add the location used by the new .deb packages for Sun's JDK. Further cope with the absence of the long-removed "url.prefixes" property; again, links to documentation on the web has probably been broken for most people for some time. Also fix the HREFs generated for local-file documentation; changing the documentation browser to use HyperlinkEvent.getURL instead of HyperlinkEvent.getDescription (to work better with real URLs) broke the dodgy HREFs we were using for files (which were just the pathname). Finally, use a slightly less inefficient way of checking whether a file exists on the web, and add a comment that we really ought to cache that information.
2006-09-01 07:19:53 +0100 / enh / revision 995
src/e/edit/AdvisorHtmlPane.java: lose HTML find functionality to salma-hayek.
2006-08-31 21:38:29 +0100 / enh / revision 994
src/e/edit/JavaDoc.java: fix the HREF in our generated links to source.
src/e/edit/Evergreen.java: handle non-HTML URLs ourselves.
src/e/edit/Advisor.java: arrange for HTML to be displayed in the documentation browser, but for links to source to be passed to the editor. This fixes the "[src]" links in our Java documentation, though I wonder if we shouldn't have gone with a made-up scheme such as "x-src:" instead, for clarity?
2006-08-31 07:29:13 +0100 / enh / revision 993
src/e/edit/AdvisorHtmlPane.java: add C-D and C-G ("Find Previous" and "Find Next") to the documentation browser.
2006-08-31 00:59:23 +0100 / enh / revision 992
src/e/edit/FileType.java: add another file type for assembler.
src/e/edit/ETextWindow.java: associate the new styler with the new file type.
2006-08-30 06:50:01 +0100 / enh / revision 991
src/e/edit/StlDocumentationResearcher.java: a new researcher for the STL documentation.
src/e/edit/AdvisorHtmlPane.java: add support for rendering HTML pages from URLs (in addition to the old support from HTML provided as a string), and for following links to other HTML pages.
src/e/edit/Advisor.java: use the new researcher, special-case http: and file: URLs when following links in our HTML pane, and make the window wider by default. Also some still commented-out changes to the "location bar".
2006-08-24 06:10:06 +0100 / enh / revision 990
src/e/edit/EvergreenLaunchable.java: open files given as arguments using invokeLater so they'll be opened after all the remembered files instead of before.
2006-08-21 23:31:27 +0100 / mad / revision 989
src/e/edit/ETextWindow.java: Don't search for the C++ dictionary in spelling-exceptions-C_PLUS_PLUS. A squiggly red line under deque was what made me notice this was broken.
2006-08-18 07:11:38 +0100 / enh / revision 988
src/e/edit/ETextWindow.java: pull the file-type guessing code out...
src/e/edit/FileType.java: ...into the new FileType class.
2006-08-17 17:56:58 +0100 / enh / revision 987
src/e/edit/FileType.java: a new enum to replace the String constants we've been using so far. There's plenty more to be done, but this is a long-overdue first step.
src/e/edit/ETextWindow.java: lose the String constants and the associated isX methods in favor of the new FileType enum and ==.
src/e/edit/FilePropertiesAction.java: a FileType is no longer its own name.
src/e/edit/InsertInterfaceAction.java:
src/e/edit/JavaResearcher.java:
src/e/edit/ManPageResearcher.java:
src/e/edit/PerlDocumentationResearcher.java:
src/e/edit/RubyDocumentationResearcher.java:
src/e/edit/TagReader.java: track API changes.
2006-08-15 07:40:50 +0100 / enh / revision 986
src/e/edit/AdvisorHtmlPane.java: add basic find functionality to the HTML component in the help browser.
2006-08-14 06:27:38 +0100 / enh / revision 985
src/e/edit/AdvisorHtmlPane.java: if there's one thing I hate in a text component, it's drag & drop editing. Exorcise that particular demon.
2006-08-14 02:54:02 +0100 / enh / revision 984
src/e/edit/JavaDoc.java: don't deliberately insert a line break between package and class names. It made sense when we were trying to stay narrow, but looks odd now.
src/e/edit/JavaResearcher.java: always show the non-private fields and static methods when showing the details of a class. (This makes up in part for the fact that we no longer offer JavaResearcher enough of the line to work out when we've typed "Class." or "new Class(", but we need to think about how to offer that kind of thing again in future.) Sort fields and methods alphabetically by name. Be more consistent with indentation (in the output, not the source).
2006-08-13 22:07:20 +0100 / enh / revision 983
src/e/edit/JavaResearcher.java: sort on method name, not signature.
2006-08-13 21:50:20 +0100 / enh / revision 982
src/e/edit/JavaResearcher.java: make the method signatures we output a little more suitable for pasting in to code. It's a pity class files don't usually contain argument names.
2006-08-09 02:22:54 +0100 / enh / revision 981
src/e/edit/EvergreenTabbedPane.java: correct a misleading comment.
2006-08-09 02:21:33 +0100 / enh / revision 980
src/e/edit/EvergreenTabbedPane.java: don't tell the user they can use imaginary keys to switch directly to high-indexed tabs.
2006-08-09 02:07:06 +0100 / enh / revision 979
src/e/edit/FindAction.java: lose the "current" regular expression to the individual text windows.
src/e/edit/ETextWindow.java: show the match count if the text window has a current regular expression, in which case 0 matches is interesting (though lately we didn't show anything in that case).
2006-08-08 22:59:05 +0100 / enh / revision 978
src/e/edit/ETextWindow.java: make use of PTextArea's new VHDL coloring ability.
2006-08-07 01:10:22 +0100 / enh / revision 977
src/e/edit/Workspace.java: mark the currently selected workspace when serializing.
src/e/edit/Evergreen.java: re-select the last selected workspace on restart. Also null out a couple of fields only used during start-up after they've been used.
2006-08-07 00:51:43 +0100 / enh / revision 976
src/e/edit/EvergreenTabbedPane.java: a new JTabbedPane subclass, similar to the one in Terminator, that uses tool tips to inform the user that they can jump directly to each tab using the keyboard. The tabbed pane configuration that used to be in the Evergreen class comes here too.
src/e/edit/Evergreen.java: lose the tabbed pane configuration, and gain a method to switch to a workspace by index.
src/e/edit/EvergreenMenuBar.java: catch alt+<number> keystrokes regardless of context, and use them to switch workspace.
2006-08-06 06:33:49 +0100 / enh / revision 975
src/e/edit/ETextWindow.java: I've been repeatedly confused by the fact that the status line doesn't correspond to the focused text, which is obviously silly.
2006-08-06 06:27:34 +0100 / enh / revision 974
src/e/edit/ETextWindow.java: pull the code to update the status line into a public method, and add an indication of the current number of find matches.
src/e/edit/FindAction.java: remove the old code for displaying the number of find matches, and call the general-purpose status line updating code instead.
2006-08-05 21:55:45 +0100 / enh / revision 973
src/e/edit/JavaResearcher.java: now we've got more space to present information, take advantage of it to show all a the superclasses of the class we're looking at. I've often found myself unnecessarily inconvenienced by the lack of this, having to go up one class at a time until I got the superclass I wanted. Also show all an interface's methods, including inherited ones. I think this was a mistake rather than a deliberate space-saving device.
2006-08-05 20:43:58 +0100 / enh / revision 972
src/e/edit/ShowCounterpartAction.java: add an action for switching to the counterpart so it can be done from the keyboard as well as by clicking on files' title bar icons.
src/e/edit/EvergreenMenuBar.java: add the new action to the "View" menu.
2006-08-04 22:24:11 +0100 / mad / revision 971
src/e/edit/FindInFilesDialog.java: Holto likes to leave his Find in Files windows lying around, which is a habit I wish I could get into. He got confused when I asked him to search for something in octopus that he'd previously searched for in quill. Which window was which?
We could use the workspace root or simply say "Find in octopus" but we ought to say something and the title is what the user's decided to call the workspace.
2006-08-04 08:06:59 +0100 / enh / revision 970
src/e/edit/RubyDocumentationResearcher.java: link up the information about included modules in Ruby class-level documentation. I've made some effort to make it look nice and be convenient to use, and it seems to work pretty well.
2006-08-04 02:30:28 +0100 / enh / revision 969
src/e/edit/RubyDocumentationResearcher.java: make links of the lists of class and instance methods in Ruby class-level documentation.
2006-08-03 22:18:05 +0100 / enh / revision 968
src/e/edit/PerlDocumentationResearcher.java: I may have given up on Perl, but I still have to maintain a number of Perl scripts at work, and the less I use Perl, the more I need its documentation. (The fact Perl never made any sense to me means it's instantly forgettable.)
src/e/edit/Advisor.java:
src/e/edit/RubyDocumentationResearcher.java: abstract out the code for finding a tool on the path that used to be used solely for ri(1).
src/e/edit/ETextWindow.java: the current use of String to represent programming languages won't last for ever, but that's too big a change to get bogged down in right now, so let's just add the missing isPerl method.
2006-08-03 06:21:20 +0100 / enh / revision 967
src/e/edit/Advisor.java: make access to the list of researchers thread-safe.
2006-08-03 06:05:51 +0100 / enh / revision 966
src/e/edit/AdvisorHtmlPane.java: increase the bottom border so we can scroll all of the text to a comfortable stop; it's not like we're wasting paper.
2006-08-01 19:04:16 +0100 / enh / revision 965
src/e/edit/AdvisorHtmlPane.java: Ed suggests a box for "pre" text, I've been finding the lack of a left margin disturbing, and it seems like we ought to use the user's configured fonts for man pages too.
2006-07-31 03:21:39 +0100 / enh / revision 964
src/e/edit/FindInFilesDialog.java: fix an old regression that meant we hadn't been reporting syntax errors in regular expressions entered in the "Find in Files" dialog.
2006-07-30 23:23:37 +0100 / enh / revision 963
src/e/edit/FindAction.java: don't overwrite the status bar text with the match count when we're only repeating the last find. It's possible that the caret/selection status should include the current number of matches, or that we should have explicit slots for these facts (rather than using the status bar text), but this addresses the most annoying problem with the current setup.
2006-07-30 20:45:29 +0100 / enh / revision 962
src/e/edit/Advisor.java: invoke the researchers' handleLink methods in a background thread for better responsiveness. The only thing the existing ones call that would be affected is JEditorPane.setText, which is safe, but that's worth a comment.
src/e/edit/WorkspaceResearcher.java: document the change.
2006-07-30 20:04:37 +0100 / enh / revision 961
src/e/edit/AdvisorHtmlPane.java: stop using the main Evergreen window's status bar, and get a status bar of our own. Drop the tool tips, which were a fairly distracting work-around to the problem of Evergreen's status bar being a long way from the advisor pane's old location.
2006-07-30 03:42:30 +0100 / enh / revision 960
src/e/edit/ETextWindow.java: show the number of lines selected, as well as the number of characters.
2006-07-30 02:58:56 +0100 / enh / revision 959
src/e/edit/InsertInterfaceAction.java: this action's desire to have the line up to the caret, functionality previously provided by Advisor, isn't obviously useful to Advisor, so pull the code out of Advisor and put it where it's wanted...
src/e/edit/Advisor.java: ...so we can replace the code in Advisor with code that just takes the word at the caret instead.
2006-07-29 21:30:21 +0100 / enh / revision 958
src/e/edit/EvergreenMenuBar.java: pull documentation out onto its own menu, and add convenient links to the GNU C Library and STL documentation.
2006-07-29 21:20:41 +0100 / enh / revision 957
src/e/edit/ShowDocumentationAction.java: stop misusing the GTK help icon on an action that doesn't offer help about the application.
2006-07-29 07:05:04 +0100 / enh / revision 956
src/e/edit/Advisor.java: look up (and format) documentation in the background, and show some basic progress information.
2006-07-29 06:13:19 +0100 / enh / revision 955
src/e/edit/Advisor.java: if the researchers don't come up with anything, we should say so explicitly, rather than just showing whatever documentation we found last time.
2006-07-29 06:12:22 +0100 / enh / revision 954
src/e/edit/ManPageResearcher.java: make sure we cope properly with non-existent man pages.
2006-07-29 05:55:08 +0100 / enh / revision 953
src/e/edit/ManPageResearcher.java: fix man pages on Mac OS, where rman(1) is much older and quite different. If any Mac user has a modern version installed in /usr/bin/, this might cause them trouble. But we'll cross that bridge when we come to it. How do Apple not manage to keep up with a program that was last updated in 2003?
2006-07-28 18:52:26 +0100 / mad / revision 952
www/index.html: Track source-dist .tgz to .tar.gz change.
2006-07-26 07:11:29 +0100 / enh / revision 951
src/e/edit/RubyDocumentationResearcher.java: add links from the top of an individual method's page to the defining class.
2006-07-26 05:15:24 +0100 / enh / revision 950
src/e/edit/ManPageResearcher.java: cope with nested lists in tables of contents, such as for Linux's localedef(1) man page.
2006-07-25 16:21:41 +0100 / enh / revision 949
lib/evergreen.desktop: Ed points out that we didn't change the case of the directories in the icon path when we changed the case of the directories themselves, so our menu item was getting a generic icon instead.
2006-07-25 07:06:36 +0100 / enh / revision 948
src/e/edit/ManPageResearcher.java: keeping the manual is now useless; we defer to man(1). On the other hand, it's still a good way of picking up non-English words that ought to be accepted in C programs.
2006-07-25 06:50:22 +0100 / enh / revision 947
src/e/edit/ManPageResearcher.java: go directly to a man page (rather than showing a link as a vestige of the old advisor system). Support arbitrary sections, properly distinguish between like-named pages in different sections, and use the freedesktop.org-suggested URI scheme.
2006-07-24 15:02:42 +0100 / enh / revision 946
src/e/edit/Advisor.java:
src/e/edit/RubyDocumentationResearcher.java: change the existing Advisor.showDocumentation(String) so that the argument is the HTML content, not a Chinese whisper (missing the information about the responsible researcher) of what we're looking for.
src/e/edit/ManPageResearcher.java: display man pages as HTML in the documentation browser window. Uses rman(1) if available to link to related pages.
2006-07-24 02:46:04 +0100 / enh / revision 945
src/e/edit/RubyDocumentationResearcher.java: improve our automatic linking of Ruby documentation, and document the main missing case.
2006-07-24 01:33:43 +0100 / enh / revision 944
src/e/edit/Evergreen.java: pull the advisor out of the main UI...
src/e/edit/Advisor.java: ...and give it its own window. Remove the arbitrary limit of 100 lines, because it caused problems (Ruby's Pathname class, for example, has more than 100 lines of documentation, as do many man pages) and wasn't particularly useful for its intended purpose because it didn't stop too many lines being generated by an errant researcher; it just threw them away after the event. Now the user has to explicitly ask for documentation, it's more likely that they want what we find, even if we find a lot of information.
src/e/edit/AdvisorHtmlPane.java: make the text far more readable by disallowing a horizontal scroll bar.
src/e/edit/ETextWindow.java:
src/e/edit/JavaResearcher.java: fix some thread-unsafe code that was causing trouble now the order of initialization is vastly different.
src/e/edit/RubyDocumentationResearcher.java:
src/e/edit/ShowDocumentationAction.java: fix links from within Ruby documentation to other Ruby documentation, broken by an earlier patch.
2006-07-23 20:20:30 +0100 / enh / revision 943
src/e/edit/ShowDocumentationAction.java: add a new "Show Documentation" action so the user must explicitly request documentation (previously referred to as "advice"). The old scheme seemed like a good idea, but didn't work out too well. On a trivial level, the implementation was never polished and could all too easily take up a lot of CPU time, but more fundamentally it meant that the computer was often unnecessarily unresponsive because it had incorrectly decided that you might be interested in something you weren't interested in while at the same time you were often forced to wait when you knew you wanted documentation but the computer hadn't guessed yet (or was still busy with a previous wrong guess). F1 is a little awkward for Apple laptop users, and it's a shame to waste the Help key on those keyboards that have them, but F1's widely known to mean "help", and is available on every keyboard I've seen (even if some are more convenient than others).
src/e/edit/EvergreenMenuBar.java: add the new option to the "Tools" menu.
src/e/edit/Advisor.java: remove the timer and caret listener. Use the currently-focused component instead, and work on demand.
src/e/edit/ETextWindow.java:
src/e/edit/Workspace.java: don't bother registering and unregistering text components with the advisor.
src/e/edit/AdvisorHtmlPane.java:
src/e/edit/Evergreen.java:
src/e/edit/InsertInterfaceAction.java: Advisor is now a singleton.
src/e/edit/WorkspaceResearcher.java: simplify the researcher's interface by removing an unused parameter.
src/e/edit/JavaResearcher.java:
src/e/edit/ManPageResearcher.java:
src/e/edit/NumberResearcher.java:
src/e/edit/RubyDocumentationResearcher.java: track API change and remove duplicate doc comments.
2006-07-18 06:42:19 +0100 / enh / revision 942
src/e/edit/ToolOutputDisposition.java: add a new output disposition for putting the output on the clipboard.
src/e/edit/ShellCommand.java: implement the CLIPBOARD and DIALOG output dispositions. There's no convenient way to request these yet, so I temporarily modified my ExternalToolsParser to use them.
2006-07-17 04:15:41 +0100 / enh / revision 941
src/e/edit/FindAction.java: remove duplication and improve performance (by avoiding turning the PTextArea's CharSequence into a String) using the changed PTextArea API.
2006-07-17 03:38:05 +0100 / enh / revision 940
src/e/edit/ExternalToolAction.java: external tool actions shouldn't be considered enabled if they need a focused text window but there isn't one.
2006-07-17 03:32:14 +0100 / enh / revision 939
src/e/edit/Evergreen.java: ensure that we read the "edit.properties" file early enough for custom tools to appear on the menu.
lib/data/edit.properties-sample: remove the default custom tool; this mechanism for specifying custom tools is deprecated and will be removed.
src/e/edit/ToolInputDisposition.java:
src/e/edit/ToolOutputDisposition.java: new enums for specifying what input a ShellCommand takes, and what happens to its output.
src/e/edit/ExternalToolsParser.java: a simple enhancement to the tool parser to use Acme/Perl-like specifications for the most common cases: "<date", "|sort", ">wc", and "uptime". Even when we have a proper UI, this will provide a convenient shorthand.
src/e/edit/ExternalToolAction.java: replace the unused ToolType enum with the more powerful ToolInputDisposition and ToolOutputDisposition enums. Lose the responsibility for choosing them. Take an ETextWindow for the purposes of implementing some of the new output dispositions. Update isContextSensitive to use a better heuristic.
src/e/edit/StreamMonitor.java: rather than have StreamMonitor know about all the different output dispositions, let it pass responsibility for the output back to ShellCommand; StreamMonitor just takes care of batching and threading.
src/e/edit/ShellCommand.java: implement (most of) the new input/output dispositions.
src/e/edit/BuildAction.java:
src/e/edit/CheckInChangesAction.java:
src/e/edit/ManPageResearcher.java:
src/e/edit/ShowHistoryAction.java: track API changes.
TODO: keep up with the times.
2006-07-12 03:43:07 +0100 / enh / revision 938
src/e/edit/ETextWindow.java: track the caret/selection and describe it in the status bar. I don't want this very often, but there have been times when it would have been handy. Most useful to me is the automatic counting of the selection. I'm embarrassed by the number of times I count manually (for which bad habit I have vi(1) to thank). I also use C-L to find out what line I'm on quite a bit too, though I couldn't off the top of my head say why I ever need that information.
2006-07-09 20:31:35 +0100 / enh / revision 937
src/e/edit/Workspace.java: make it possible to alter a Workspace's title or root directory after creation.
src/e/edit/EditWorkspaceAction.java: a new action giving a UI for altering a Workspace's title or root directory.
src/e/edit/AddWorkspaceAction.java: a slight simplification.
src/e/edit/Evergreen.java:
src/e/edit/EvergreenMenuBar.java: make the action available from the main "Workspace" menu and from each workspace's pop-up menu.
2006-06-19 22:59:04 +0100 / enh / revision 936
src/e/edit/Workspace.java: FormDialog will restore the focus to the original owner when the dialog is dismissed. If you want to override this behavior, you need to invokeLater your focus change so that it is performed at the appropriate juncture.
2006-06-18 18:16:16 +0100 / mad / revision 935
src/e/edit/FileIgnorer.java: BitKeeper leaves a top-level PENDING directory around if pulled changes include modifications to locally modified but uncommitted files. This presumably on the assumption that it would take less time to work out the syntax for applying the PENDING patch than it would to re-pull across the network. I've been using it for six years and the furthest I ever got gave me the suspicion that bk pull uses undocumented options to the other commands. So the directory's basically useless but gets left around.
2006-06-18 06:18:37 +0100 / enh / revision 934
src/e/edit/Workspace.java: remove a bogus hack in the hope that my last change to FormDialog has fixed the real problem. I wasn't able to repeat the problem on my dual G5 before, and I can't repeat it now either. But the problem was not specific to Mac OS, and it was not specific to Evergreen either, so even if this code had been the right way to fix the problem (which it wasn't), it wasn't in the right place.
2006-06-18 06:04:28 +0100 / enh / revision 933
src/e/edit/Workspace.java: use the new FileAlterationMonitor class to try to keep each workspace's file list up-to-date automatically.
src/e/edit/Evergreen.java: let the workspace know when its services are no longer required, so that it can shut down its file alteration monitor.
2006-06-18 05:57:52 +0100 / enh / revision 932
src/e/edit/FileIgnorer.java: we shouldn't index files in BitKeeper's RESYNC/ directories.
2006-06-14 02:56:34 +0100 / enh / revision 931
src/e/edit/ManPageResearcher.java: X11 man pages have capital letters in their sections.
2006-06-11 17:25:30 +0100 / enh / revision 930
src/e/edit/FileIgnorer.java: ignore Mercurial's droppings.
2006-05-31 06:08:51 +0100 / enh / revision 929
src/e/edit/Evergreen.java: I'd been meaning to add more information when refusing to quit for some time, but was spurred on by Xcode 2.3 mentioning the same in its release notes.
2006-05-31 01:06:50 +0100 / enh / revision 928
COPYING: update.
2006-05-30 22:02:11 +0100 / enh / revision 927
src/e/edit/ETextWindow.java: fix the capitalization (both Apple and GNOME agree on title capitalization for buttons) and go back to Chris' original suggestion for "Overwrite", which – until someone corrects me – I don't think is ambiguous or stress-inducing.
2006-05-30 19:46:28 +0100 / enh / revision 926
www/index.html: mention the name of the Debian Exuberant ctags package, because it's always surprised me that it's not just "ctags".
2006-05-30 19:27:42 +0100 / enh / revision 925
www/index.html: reading this page in the web browser, the link to our Mac OS ctags binary was obviously in the wrong place. Also try to make the "all platforms" section less ambiguous.
2006-05-30 19:20:15 +0100 / enh / revision 924
www/index.html: Exuberant ctags has been updated to include (amongst other things) my rewritten Ruby parser.
2006-05-26 10:42:52 +0100 / car / revision 923
src/e/edit/ETextWindow.java: A happy compromise on those button labels.
2006-05-25 10:15:21 +0100 / car / revision 922
src/e/edit/CheckInChangesAction.java: To paraphrase Martin, "edit^Wevergreen". Double-clicking patches displayed by CheckInTool once again takes focus back to the appropriate file:line in evergreen.
2006-05-25 09:59:53 +0100 / car / revision 921
src/e/edit/ETextWindow.java: Apple HIG agrees with me, and the source, that the labels on those action button should be verbs, not questions. The dialog title arguably could be a question, but the text in the panel expresses the question adequately. HIG's definition of verb would allow "Discard changes".
2006-05-23 07:44:15 +0100 / enh / revision 920
src/e/edit/ManPageResearcher.java: keep track of which section we pulled a man page from, for now just so we can show it in the link.
2006-05-22 23:40:32 +0100 / mad / revision 919
www/index.html: By which, in this case, I mean "completely untested". We build it so we may as well advertise it.
2006-05-22 07:03:35 +0100 / enh / revision 918
lib/data/man-summary.txt: remove the list of man pages present on one particular machine at one particular time...
src/e/edit/ManPageResearcher.java: ...in favor of scanning the machine we're actually running on. This only takes 0.5s on my dual G5.
2006-05-19 21:46:11 +0100 / mad / revision 917
www/index.html: I don't think we should refer to files by inconsistent names. The package title is "Evergreen" but the file is "evergreen.tgz".
2006-05-19 21:40:04 +0100 / pcn / revision 916
www/index.html: Make it easier to build Evergreen from source by pointing the tgz hyperlink to something which exists.
2006-05-19 09:32:51 +0100 / mad / revision 915
src/e/edit/Evergreen.java: No-one seems to be getting round to this. Explain why your workspaces are always thrown away on Windows.
2006-05-19 00:28:02 +0100 / mad / revision 914
lib/Evergreen.ico:
lib/evergreen.ico: I used to use PROJECT_NAME for the .ico file just because that was the easiest. Now the beneficial dictatorship has made an explicit decision to use MACHINE_PROJECT_NAME for files except where there's good reason otherwise.
www/index.html: Rename the links accordingly, including the one to the previously peculiarly named org.jessies.Evergreen.deb.
2006-05-18 22:38:19 +0100 / mad / revision 913
www/index.html: Everyone thinks this was adopting an unnecessarily antagonistic tone. We don't have to weaken the position to fix that. This makes it much clearer under what circumstances Evergreen is likely to get in your way. Those conditions aren't rare but you won't trip over them all the time.
2006-05-18 09:48:32 +0100 / mad / revision 912
www/index.html: Ed points out that we've created the Evergreen deb with a capital E because that part is under the control of universal.make which doesn't know about the downcasing. I expect we'll want to pull the "dehumanizing" project name transformation out of the packaging script so it can be shared. But this'll do for tonight-over-VNC.
2006-05-18 06:53:02 +0100 / mad / revision 911
www/index.html: I changed the .deb filename in the same way as I changed the package name.
2006-05-17 23:30:47 +0100 / mad / revision 910
www/index.html: A note on the InAppServer, inspired by XP's firewall's warning. Although I haven't actually verified that with Evergreen, only Terminator.
2006-05-17 22:51:49 +0100 / enh / revision 909
src/e/edit/Workspace.java: correct a misleading claim, even though I don't have a fix. (I'm unwilling to further spread the current hack.)
2006-05-17 03:26:25 +0100 / enh / revision 908
src/e/edit/ECloseButton.java: martind (who never seems to notice anything on menus) asked for a tool tip giving the close-window keyboard equivalent, which he seemingly didn't know about. It's one of my most-used keystrokes, and I can understand why someone wouldn't ever have tried the "File" menu's "Close" item: I'm not always certain what that means in any given application. A tool tip on the button makes the scope clear.
2006-05-17 02:58:05 +0100 / enh / revision 907
src/e/edit/TagsPanel.java:
src/e/edit/TagsUpdater.java: since Mac OS and Windows users are highly likely to see the "no Exuberant ctags" message, put some effort into polishing it.
2006-05-17 02:12:02 +0100 / enh / revision 906
src/e/edit/ECloseButton.java:
src/e/edit/ESwitchButton.java: defer the default foreground color choice to EButton...
src/e/edit/EButton.java: ...where we in turn defer it to our component hierarchy parent...
src/e/edit/ETitleBar.java: ...and set the foreground color for the buttons' JPanel to be the same as the color we're using for the title bar text. This makes the buttons visible on Windows, where they're otherwise black on dark blue. Also change the title bar font on Windows to match the window title font, to aid its visibility. Stick to the table header font on the other platforms, because we don't need such a heavy font there, and it's just distracting.
2006-05-16 04:47:07 +0100 / mad / revision 905
src/e/edit/Evergreen.java: Adapt to the salma-hayek generalization, keeping the previous behavior here - of listening on all addresses.
2006-05-15 01:52:22 +0100 / enh / revision 904
www/index.html: include our new header.
2006-05-15 01:19:00 +0100 / enh / revision 903
www/index.html: be more specific about what we're linking to, as on the other pages.
2006-05-15 01:11:57 +0100 / enh / revision 902
www/index.html: now we have sub-headings, there's less need to compress the Cygwin information, though it still seems like two paragraphs rather than three.
2006-05-15 01:07:00 +0100 / enh / revision 901
www/index.html: switch to the clearer style used on the salma-hayek page.
2006-05-15 01:00:07 +0100 / enh / revision 900
www/index.html: link to the newly-available nightly builds of "Evergreen.app" for Mac OS.
2006-05-15 00:35:18 +0100 / enh / revision 899
src/e/edit/TagsPanel.java:
src/e/edit/TagsUpdater.java: ensure we don't hide the error message if the tags panel is unable to function because it can't find Exuberant ctags. Mac OS still ships with an ancient /usr/bin/ctags.
2006-05-14 23:39:38 +0100 / enh / revision 898
edit.properties-sample:
lib/data/edit.properties-sample: move the default "edit.properties" somewhere where it'll get included in packages. Ideally, we want to lose this completely, but we're a long way off (because each line in there represents at least one job we need to do, plus there's the issue of abstracting out – or rewriting – a Preferences dialog like Terminator's).
bin/evergreen: track the location change.
2006-05-14 23:31:32 +0100 / mad / revision 897
www/index.html: Restructure the Downloads and Building from source sections to match Terminator's. I don't see an Evergreen.dmg, so I guess that isn't being built overnight. I've deleted the line about installing the packages listed by install-everything.sh, though that's still potentially a useful for resource for the list of packages required to build. Perhaps the list should be copied to salma-hayek's Building from source section, in preparation for install-everything's demise. Or perhaps just the line referring to it should go there.
I've removed the recommendation for using install-everything.sh. If we got any new BlueArc users, we'd probably start them straight on packages.
2006-05-14 23:30:25 +0100 / enh / revision 896
find-test.txt:
sample.txt:
test.txt:
trilang.utf: remove various example text files lying around. "trilang.utf" is superseded by Markus Kuhn's "UTF-8-demo.txt", linked to from the Terminator web page.
2006-05-13 00:27:18 +0100 / enh / revision 895
src/e/edit/ETextWindow.java: add more heuristics to initFileTypeByName, this time for the benefit of shell scripts.
2006-05-13 00:27:08 +0100 / mad / revision 894
lib/Evergreen.ico: Good grief. Apart from the absence of this file, Evergreen's Windows installer built and worked first time. As for Terminator, I just loaded the .png into Gimp and told it to save as Microsoft Windows ico. That was a bit easier than the Terminator port. :-)
2006-05-12 21:53:57 +0100 / mad / revision 893
Makefile: Enable the generation of a Windows installer for Evergreen. I'd quite like to generate this uuid automatically but it doesn't really seem worth the effort, given that it has to be checked-in. Maybe when the scm Mac OS installer quandary is resolved, it'll be clearer where this should live.
2006-05-10 17:34:08 +0100 / enh / revision 892
javadoc-summary.txt:
lib/data/javadoc-summary.txt:
manpages:
lib/data/man-summary.txt:
spelling-exceptions-C++:
lib/data/spelling-exceptions-C++:
spelling-exceptions-Java:
lib/data/spelling-exceptions-Java:
spelling-exceptions-Perl:
lib/data/spelling-exceptions-Perl:
spelling-exceptions-Ruby:
lib/data/spelling-exceptions-Ruby: move various data files under lib/ so they'll be copied into anything we distribute (unlike random files in the project root, which get ignored).
src/e/edit/Evergreen.java: cope with the new data-file location.
src/e/edit/ManPageResearcher.java: cope with an opportunistic rename.
2006-05-10 17:25:53 +0100 / enh / revision 891
lib/data: new directory.
2006-05-10 03:24:44 +0100 / enh / revision 890
src/e/edit/JavaResearcher.java:
src/e/edit/ManPageResearcher.java: cope more gracefully with missing files.
2006-05-10 03:07:53 +0100 / enh / revision 889
lib/evergreen.desktop: add a GNOME ".desktop" file.
2006-05-08 07:26:56 +0100 / enh / revision 888
bin/edit:
bin/evergreen: rename the start-up script.
bin/edit-and-block: and track the change.
2006-05-08 00:09:01 +0100 / mad / revision 887
src/e/edit/FindFilesContainingSelectionAction.java: I don't know how this debugging output hasn't got in my way before - it's been there since recorded history began.
2006-05-07 06:42:03 +0100 / enh / revision 886
www/index.html: update the link from "edit.tgz" to "Evergreen.tgz", even though the www-dist and source-dist don't seem to be working unless I run them manually at the moment.
2006-05-07 06:30:41 +0100 / enh / revision 885
bin/edit: we want to change the class names and the text presented to the user, but for now keep the existing configuration pathnames (which include the old class name).
lib/edit-128.png:
lib/edit.icns: rename.
lib/evergreen-128.png:
lib/Evergreen.icns: rename.
src/e/edit/Edit.java:
src/e/edit/Evergreen.java: rename.
src/e/edit/EditLaunchable.java:
src/e/edit/EvergreenLaunchable.java: rename.
src/e/edit/EditMenuBar.java:
src/e/edit/EvergreenMenuBar.java: rename.
src/e/edit/AddWorkspaceAction.java:
src/e/edit/Advisor.java:
src/e/edit/AdvisorHtmlPane.java:
src/e/edit/BuildAction.java:
src/e/edit/CycleWorkspacesAction.java:
src/e/edit/EditServer.java:
src/e/edit/EErrorsWindow.java:
src/e/edit/ETextWindow.java:
src/e/edit/ExternalToolAction.java:
src/e/edit/ExternalToolsParser.java:
src/e/edit/FilePropertiesAction.java:
src/e/edit/FindAction.java:
src/e/edit/FindAndReplaceAction.java:
src/e/edit/FindFilesContainingSelectionAction.java:
src/e/edit/FindInFilesDialog.java:
src/e/edit/GotoAction.java:
src/e/edit/InsertInterfaceAction.java:
src/e/edit/JavaDoc.java:
src/e/edit/JavaResearcher.java:
src/e/edit/KillErrorsAction.java:
src/e/edit/ManPageResearcher.java:
src/e/edit/NewFileAction.java:
src/e/edit/OpenAction.java:
src/e/edit/OpenMakefileAction.java:
src/e/edit/OpenQuicklyAction.java:
src/e/edit/OpenQuicklyDialog.java:
src/e/edit/RemoveWorkspaceAction.java:
src/e/edit/RescanWorkspaceAction.java:
src/e/edit/RubyDocumentationResearcher.java:
src/e/edit/SaveAllAction.java:
src/e/edit/SaveAsAction.java:
src/e/edit/SetBuildTargetAction.java:
src/e/edit/ShellCommand.java:
src/e/edit/ShowMisspellingsAction.java:
src/e/edit/SimplePatchDialog.java:
src/e/edit/TagsUpdater.java:
src/e/edit/Workspace.java: track renames.
2006-05-07 05:59:05 +0100 / enh / revision 884
bin/edit:
spelling-exceptions-C++:
src/e/edit/Advisor.java:
src/e/edit/CycleWindowsAction.java:
src/e/edit/EColumn.java:
src/e/edit/Edit.java:
src/e/edit/ETextWindow.java:
src/e/edit/JavaDoc.java:
src/e/edit/NewFileAction.java:
src/e/edit/OpenAction.java: rename "Edit" as "Evergreen" in string literals and comments.
2006-05-07 05:46:05 +0100 / enh / revision 883
edit.html: remove out-of-date documentation.
www/index.html: and tidy up (and change the product's name in) the current documentation.
2006-05-07 05:13:06 +0100 / enh / revision 882
README: the first step of the big rename, so we can see if everything works on the server.
2006-04-27 00:03:39 +0100 / enh / revision 881
src/e/edit/BuildAction.java: fix an infelicity that's been catching me out for a long time: if you ask Edit to build your project and it notices that there are unsaved modified files and asks you what to do, it was searching for build instructions starting from the project root rather than the directory containing the file that had the focus when you asked for the project to be built. For a big project with multiple levels of makefiles, this could be quite an inconvenience.
2006-04-26 06:38:06 +0100 / mad / revision 880
bin/edit: Losing the rescue clause to InAppClient is more of a saving for Edit. That's a good job because otherwise I probably would have ended up not creating the InAppClient if filename == nil. Yes, that definitely warrants a comment (or, preferably, code).
2006-04-26 05:50:01 +0100 / mad / revision 879
bin/edit: Back-out the FIFO code and lose the socket code to salma-hayek.
2006-04-26 05:34:50 +0100 / mad / revision 878
src/e/edit/Workspace.java: Fix a bug I introduced the other week, causing a seemingly harmless string index out of bounds exception or a bogus rescan if you open a file for which there is no suitable workspace.
2006-04-26 00:12:27 +0100 / mad / revision 877
bin/edit: Copy back the abstracted code from Terminator, making it closer to being ready for sharing.
2006-04-25 23:20:25 +0100 / mad / revision 876
bin/edit: There are many things which need tidying up here but this one stops anyone but Phil running this script.
2006-04-25 22:31:21 +0100 / pcn / revision 875
bin/edit: Changes to follow the change to InAppServer. We now need to check what kind of InAppServer is running (FIFO-based or Socket-based), and do the sensible thing.
2006-04-22 21:24:30 +0100 / enh / revision 874
src/e/edit/NewFileAction.java: continuing the recent theme of improving our behavior when something other than an ETextWindow has the focus, make "New File" default to the workspace root. Previously it could just as easily default to a directory in some other workspace.
2006-04-19 06:22:41 +0100 / enh / revision 873
src/e/edit/FileIgnorer.java: ignore SCM directories left around by Bazaar-NG.
2006-04-17 00:32:58 +0100 / enh / revision 872
src/e/edit/Workspace.java: fix a NullPointerException on start-up, where we can try to use the file list before it's been generated.
2006-04-16 23:06:53 +0100 / pcn / revision 871
src/e/edit/Workspace.java: Well, the comment says it all. The insertion of return characters into ever damned file I open on MacOS has wound me up too far. In breaking, I have written some nasty platform-specific hack for which I feel duly ashamed. Works better now, though.
2006-04-15 21:05:03 +0100 / pcn / revision 870
src/e/edit/BirdView.java: Now really delete the damned thing. I had to do that from the command line!
2006-04-15 21:04:04 +0100 / pcn / revision 869
src/e/edit/BirdView.java: Delete the old BirdView from where it was (it's gone into Salma Hayek now).
src/e/edit/ETextWindow.java: Change to use the new constructor, which takes a BirdsEye, rather than anything PTextArea-specific.
2006-04-15 07:41:41 +0100 / enh / revision 868
src/e/edit/ETextAction.java: getTextArea was a terrible name for getFocusedTextArea.
src/e/edit/AppropriateFontAction.java:
src/e/edit/AutoCompleteAction.java:
src/e/edit/ChangeFontAction.java:
src/e/edit/CorrectIndentationAction.java:
src/e/edit/FindAndReplaceAction.java:
src/e/edit/GotoAction.java:
src/e/edit/InsertInterfaceAction.java: track API change.
src/e/edit/ETextWindow.java: remove useless cast.
2006-04-15 07:29:03 +0100 / enh / revision 867
src/e/edit/ETextWindow.java: lose goToLine and centerOnSelection to PTextArea.
src/e/edit/BirdView.java: take a PTextArea instead of an ETextWindow now it offers everything we need.
src/e/edit/FindAndReplaceAction.java:
src/e/edit/FindInFilesDialog.java:
src/e/edit/GotoAction.java:
src/e/edit/TagsUpdater.java: track API changes.
2006-04-15 06:43:30 +0100 / enh / revision 866
src/e/edit/BuildAction.java:
src/e/edit/ETextAction.java:
src/e/edit/OpenMakefileAction.java: making OpenMakefileAction's behavior more like BuildAction's was a good idea; doing so by duplication wasn't. Remove the duplication.
2006-04-15 01:46:55 +0100 / mad / revision 865
spelling-exceptions-C++: I'm not sure this is the right section, but I think so.
2006-04-14 23:28:17 +0100 / pcn / revision 864
src/e/edit/BirdView.java: Correctly scale the highlit lines according to their vertical position after wrapping, rather than their position within the list of logical lines. This prevents unbalanced files (files with heavily-wrapped lines at one end and short lines at the other) from causing the bird-marks to go astray from where the user expects to see them.
2006-04-13 02:28:43 +0100 / enh / revision 863
src/e/edit/ETextWindow.java: remove useless verbosity.
2006-04-13 02:27:11 +0100 / enh / revision 862
src/e/edit/Edit.java: improve the implementation of a recent change, "If I right-click on one of the items in the tabbed pane, I expect the 'rescan' and 'remove workspace' actions to act on the tab I right-clicked on, not the 'current' workspace. Therefore changed to work that way." Missing from the original description of the change was the important point that this is really working around a Mac OS LAF bug. Sun's LAFs were already doing the right thing because they were changing tab before firing the listeners. Anyway, code that works everywhere is better than code that doesn't. Using integers as a way to refer to persistently refer to objects, though, is just crazy.
src/e/edit/RemoveWorkspaceAction.java:
src/e/edit/RescanWorkspaceAction.java: there's still duplication here (a WorkspaceAction superclass, probably), but this mops up the ugliness.
2006-04-13 02:06:28 +0100 / mad / revision 861
src/e/edit/ETextWindow.java: Open the newly Saved As file. This will now cause a workspace rescan, fixing the Open Quickly index so it contains the new file. When I was mulling over this in the morning, I was afraid that I'd start editing the wrong copy. But I'd probably do that anyway. As if I ever go up the screen as far as the File menu.
2006-04-13 02:02:39 +0100 / mad / revision 860
src/e/edit/Workspace.java: If we're already scanning, we don't want to restart the scan. That isn't necessarily what this code says, but this'll stop the NPE on startup.
2006-04-13 01:38:05 +0100 / mad / revision 859
src/e/edit/Workspace.java: A method to return the absolute pathnames given a workspace-relative path would be a more robust solution.
src/e/edit/FindInFilesDialog.java:
src/e/edit/JavaDoc.java:
src/e/edit/OpenQuicklyDialog.java: The calling code becomes simpler, if one character longer.
2006-04-13 01:31:44 +0100 / mad / revision 858
src/e/edit/NewFileAction.java: Move a special case...
src/e/edit/Workspace.java: ... to where it will be of more use. This means that Open (as opposed to Open Quickly) of a file that Edit hasn't seen will cause the workspace index to be updated. As will opening a file via the EditServer, though Chris didn't report that. It does nothing to help the Save As case (or the Save As semantics) which Chris also reported.
2006-04-13 01:24:51 +0100 / mad / revision 857
src/e/edit/FindInFilesDialog.java:
src/e/edit/JavaDoc.java:
src/e/edit/OpenQuicklyDialog.java: Remove the extra /s which make for sloppy log messages like:
2006-04-12T17:18:24.918-0700 Edit: Opening '~/work/misc//archive-scripts/shrc'
And, more importantly, confuse the reader of the source code.
src/e/edit/Workspace.java: A comment might help stop that mistake creeping back in. Clearly, it isn't obvious.
2006-04-12 23:28:24 +0100 / pcn / revision 856
src/e/edit/Edit.java:
src/e/edit/RemoveWorkspaceAction.java:
src/e/edit/RescanWorkspaceAction.java: If I right-click on one of the items in the tabbed pane, I expect the 'rescan' and 'remove workspace' actions to act on the tab I right-clicked on, not the 'current' workspace. Therefore changed to work that way.
2006-04-12 23:04:42 +0100 / pcn / revision 855
src/e/edit/OpenMakefileAction.java: If there's no current text area selected, search for a makefile from the workspace's root directory. This allows the makefile to be opened when no files are open, and when focus is in the errors or ctags windows.
2006-04-10 00:11:34 +0100 / enh / revision 854
src/e/edit/EErrorsWindow.java:
src/e/edit/ETextWindow.java: ensure that text windows (including the errors window) always have vertical scrollbars. On Mac OS, we should always have done this, but it's running Edit with the GTK LAF that's encouraged me to make the change because the very heavy GNOME scrollbars look really odd in a column where some of the windows don't have scrollbars. (The irony being that the GNOME HIG says scrollbars should be as-needed.) The scrollbar on the errors window adds an extra visual cue that it's a text window.
2006-04-09 23:42:52 +0100 / enh / revision 853
src/e/edit/AddWorkspaceAction.java:
src/e/edit/BuildAction.java:
src/e/edit/Edit.java:
src/e/edit/EErrorsWindow.java:
src/e/edit/ETextWindow.java:
src/e/edit/ExternalToolAction.java:
src/e/edit/FindAndReplaceAction.java:
src/e/edit/InsertInterfaceAction.java:
src/e/edit/ManPageResearcher.java:
src/e/edit/NewFileAction.java:
src/e/edit/SaveAllAction.java:
src/e/edit/Workspace.java: try harder to give errors and warnings that suit the Apple & GNOME convention.
2006-04-09 02:05:45 +0100 / enh / revision 852
www/index.html: include the new footer.
2006-04-07 05:10:30 +0100 / enh / revision 851
src/e/edit/RescanWorkspaceAction.java: a new action to rescan the current workspace.
src/e/edit/Edit.java: Improve the behavior of removeCurrentWorkspace so it's less prone to just removing your workspace, no questions asked. It's such a rare operation that it's worth asking confirmation. Add a pop-up menu to the workspace tabs containing the two most useful actions.
src/e/edit/EditMenuBar.java: add it to the menu bar.
src/e/edit/RemoveWorkspaceAction.java: the "current" in "Remove Current Workspace" looked odd.
2006-04-04 21:52:47 +0100 / mad / revision 850
bin/edit: Consistency with immediately preceding salma-hayek check-in.
2006-04-03 01:55:51 +0100 / enh / revision 849
bin/edit: we now set java.awt.Window.locationByPlatform automatically for all of our applications.
2006-03-23 07:39:31 +0000 / enh / revision 848
src/e/edit/ETextWindow.java: use the new Python coloring; no indenter yet, but maybe this will get the ball rolling...
2006-03-18 03:13:15 +0000 / enh / revision 847
src/e/edit/Edit.java: write more honest information about our start-up performance to the log, and simplify the threading after the frame is made visible. There's still plenty of work to do, but this improves the start-up experience for me on Linux.
2006-03-17 17:51:03 +0000 / mad / revision 846
src/e/edit/ManPageResearcher.java: "synchronized static"? The implementation optimization that stores the research in statics shouldn't be part of the interface. Having multiple statics is like having parallel arrays - it'd be nicer if the Research was a separate object. This is a small step in that direction.
src/e/edit/ETextWindow.java: ManPageResearcher.getSharedInstance will do the synchronization for us, ensuring that the research is ready by the time we want to use it.
This fixes a NullPointerException in addManPageWordsTo when Edit starts up and opens files before the ManPageResearcher init has completed. That's been afflicting one file per startup for me this week.
Associated exception:
java.lang.NullPointerException
at java.util.AbstractCollection.addAll(AbstractCollection.java:316)
at e.edit.ManPageResearcher.addManPageWordsTo(ManPageResearcher.java:64)
at e.edit.ETextWindow.initSpellingExceptionsFor(ETextWindow.java:75)
at e.edit.ETextWindow.getSpellingExceptionsForLanguage(ETextWindow.java:267)
at e.edit.ETextWindow.initSpellingExceptionsForDocument(ETextWindow.java:276)
at e.edit.ETextWindow.configureForGuessedFileType(ETextWindow.java:416)
at e.edit.ETextWindow.fillWithContent(ETextWindow.java:330)
at e.edit.ETextWindow.<init>(ETextWindow.java:111)
at e.edit.Workspace.addViewerForFile(Workspace.java:237)
at e.edit.Edit.openFileNonInteractively(Edit.java:261)
at e.edit.Edit.openFile(Edit.java:155)
at e.edit.Edit.openRememberedFiles(Edit.java:524)
at e.edit.Edit$6.run(Edit.java:772)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:461)
at e.debug.EventDispatchThreadHangMonitor.dispatchEvent(EventDispatchThreadHangMonitor.java:157)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
...
2006-03-17T09:11:16.762-0800 Edit: Learned of 4152 man pages in 1516ms.
2006-03-06 07:15:36 +0000 / enh / revision 845
src/e/edit/NewFileAction.java: I'd had complaints that "New File doesn't work", but no proper report, nor had I ever seen it myself. Until today. If you removed (or weren't provided with) the full path to the file, we created the file in the workspace root, but then tried to open exactly the ambiguous name we were given, rather than our chosen disambiguation. And the updated file list probably won't be ready to disambiguate, so you lose. This patch tries to open the exact file we created instead.
2006-03-05 19:02:16 +0000 / enh / revision 844
src/e/edit/ETextWindow.java: note a good source of information on mode lines, should we ever extend this code.
2006-02-28 20:12:20 +0000 / enh / revision 843
src/e/edit/OpenQuicklyDialog.java: give focus back to the filename field as soon as we start rescanning, so the user can try to do something useful while waiting for the scan to complete.
2006-02-27 02:08:51 +0000 / enh / revision 842
src/e/edit/Advisor.java:
src/e/edit/ETextWindow.java:
src/e/edit/JavaResearcher.java:
src/e/edit/ManPageResearcher.java: let the man page researcher provide a list of acceptable words to the spelling checker for C++ files, in the same way the JavaResearcher provides a list of words from JDK identifiers to the spelling checker for Java files. Also exclude Perl, SSL, and TCL man pages from our harvest.
manpages: re-generated.
spelling-exceptions-C++: remove a hack for words now available from man pages.
2006-02-27 01:20:58 +0000 / enh / revision 841
src/e/edit/ManPageResearcher.java: since we only index man pages from sections 2 and 3, we shouldn't display man pages of the same name from other sections. (In particular, write(1) has nothing to do with write(2).)
2006-02-27 01:12:31 +0000 / enh / revision 840
src/e/edit/FileIgnorer.java: make the test for filenames with extensions that imply they should be ignored public.
src/e/edit/EErrorsWindow.java: try harder to avoid uninteresting links, and to avoid including surrounding punctuation as part of the link. Pull the various cases out of ErrorLinkActionListener.actionPerformed into their own methods.
2006-02-26 23:21:01 +0000 / enh / revision 839
manpages: update the list of man pages. This was done on Mac OS 10.4.5, so it includes X11 and GL, but doesn't include Qt, which the old list did. We should generate this list on demand, and remove it from the repository.
2006-02-26 23:13:44 +0000 / enh / revision 838
src/e/edit/ManPageResearcher.java: the example script (which should be pulled out of here, and maybe combined with the current "parse-javadoc.rb" into some kind of "reindex-help.rb") didn't cope with spaces in paths, didn't understand the Apple "/Previous System/" convention, and wasn't removing duplicates.
2006-02-25 23:49:21 +0000 / enh / revision 837
edit.properties-sample:
src/e/edit/BuildAction.java: remove a never-used property, and remove the "make.command" property.
2006-02-25 23:40:04 +0000 / enh / revision 836
src/e/edit/JavaResearcher.java: don't output broken links if "java.advisor.doc" isn't set and the cached JavaDoc locations in "javadoc-summary.txt" don't exist on your machine. It would be better to get rid of "java.advisor.doc" and just have an action on the Tools menu to update "javadoc-summary.txt" by pointing "parse-javadoc.rb" at your local documentation. The fall-back for people who do nothing would be to use Sun's copy on the web. Probably automatically replacing the version number ("1.5.0" here) with the running version. I notice also that there's more link-generating code in our JavaDoc class that doesn't do anything like this. The two could usefully be merged.
2006-02-25 23:32:02 +0000 / enh / revision 835
javadoc-summary.txt: update the cached JavaDoc summary from 1.4.2 to 1.5.0_06. Also includes Apple's extension APIs.
2006-02-25 23:29:19 +0000 / enh / revision 834
parse-javadoc.rb: make the output more useful as shell input.
2006-02-25 23:11:25 +0000 / enh / revision 833
parse-javadoc.rb: don't include potentially out-of-date JavaDoc in the list of suggestions.
2006-02-15 04:32:35 +0000 / mad / revision 832
bin/edit: Delegate cygpath and -D knowledge to invoke-java.rb. 4 red, 2 blue.
2006-02-12 05:38:52 +0000 / mad / revision 831
bin/edit: invoke-java.rb now adds the appropriate directory to path for us. Even if we change that one day, invoke-java.rb now knows where these programs are, so it could tell the Java.
2006-02-11 07:15:46 +0000 / enh / revision 830
src/e/edit/FileIgnorer.java:
src/e/edit/ShellCommand.java: use ProcessUtilities.makeShellCommandArray.
2006-02-11 06:05:59 +0000 / enh / revision 829
src/e/edit/FindInFilesDialog.java: now we don't expandAll at the end of the search, we need to notify the tree model's listeners of updates as they happen.
2006-02-10 23:09:13 +0000 / enh / revision 828
src/e/edit/OpenQuicklyDialog.java: the "Open Quickly" dialog shouldn't grab the focus when a rescan finishes if Edit lost the focus in the meantime.
2006-02-10 02:28:54 +0000 / enh / revision 827
src/e/edit/FindInFilesDialog.java: Swing's tree model isn't thread safe, so synchronize on the tree view whenever we work on the model. Google says that "reload" and "nodeStructureChanged" cause the path from the root to the node to be collapsed. Google also strongly suggests that we have to tell the model to fire change notifications, and that we should be as specific as possible to avoid stupidity like the path being collapsed. So jump through the appropriate hoops to notify listeners when we insert a node. This seems to fix the repeatable problems I was having, even if it leaves me hating JTree just that little bit more...
2006-02-10 00:01:04 +0000 / enh / revision 826
src/e/edit/FindInFilesDialog.java: the recent change to show the matches tree as it's built caused performance problems and also resulted in annoying behavior on long searches where tree paths you'd already inspected and manually collapsed would reopen as new matches were found. (A more acute version of the old problem where causing a search to start again loses the existing collapsed state.) This patch puts the tree into the more efficient "large model" mode (which doesn't seem to make a great difference) and takes care to expand individual nodes as they're added (and only then). Also remove an extraneous ' ' in the status line if there were multiple matches, and make it clear that we show the number of matching lines, not the number of matches (if there are multiple matches on some lines).
2006-02-09 22:44:35 +0000 / mad / revision 825
edit.properties-sample: Use the new --working-directory argument to Terminator on Linux to finally, consistently and once again get a terminal in the right directory. Isn't Terminator good enough on Mac OS X and Windows to move this "tool" into the source code, further depleting the properties?
2006-02-09 22:42:26 +0000 / mad / revision 824
src/e/edit/ETextWindow.java: Fix Makefile recognition for Makefiles not at the top-level of a workspace. (Replacing the one inconsistent call of "equals".)
2006-02-09 19:36:05 +0000 / enh / revision 823
src/e/edit/FileIgnorer.java:
src/e/edit/ShellCommand.java: don't assume that Edit's $PATH corresponds to the user's login shell's $PATH. This isn't the case, for instance, when Edit's started from gnome-panel. Let the shell do the searching for us. Also add "autom4te.cache" to the list of directories we ignore by default.
2006-02-08 00:10:04 +0000 / enh / revision 822
src/e/edit/TagReader.java: record that a tag corresponds to a prototype before obliterating that information by noticing that it's a constructor or destructor. It turns out that we notice some constructors in Tag rather than CTag, so the code needs to move there. It would be better if ctags(1) provided this kind of information in a more uniform manner.
2006-02-04 02:39:04 +0000 / enh / revision 821
src/e/edit/EditMenuBar.java:
src/e/edit/ExpandWindowAction.java: neilb's started using Edit on a laptop, and (plausibly) claims that the C-`/C-~ keyboard navigation is spoiled by the inability to expand a newly-focused window. This might also address stuartb's reason for not switching.
2006-02-04 02:22:14 +0000 / enh / revision 820
src/e/edit/ETextWindow.java:
src/e/edit/FilePropertiesAction.java: add a read-only display of file type to the "File Properties" dialog.
2006-02-04 02:19:38 +0000 / enh / revision 819
src/e/edit/FindInFilesDialog.java: update the matches tree as we go, and use the same more-informative status text during as well as after the search (we keep the percentage while we're going, for the benefit of slow searches).
2006-02-04 00:37:07 +0000 / enh / revision 818
src/e/edit/TagReader.java: visually distinguish C++ prototypes by using the same rendering we use for "abstract" Java classes and methods.
2006-02-03 01:42:31 +0000 / enh / revision 817
src/e/edit/TagReader.java: remove dead code and teach C++ tags to treat static non-member functions as "private", so that their file-restricted scope is visible in the tags panel.
2006-02-03 01:30:35 +0000 / enh / revision 816
src/e/edit/TagReader.java: fix regular expressions that were using " " rather than "\b" (which is valid in a POSIX extended regular expression according to http://www.boost.org/libs/regex/doc/syntax_extended.html even if the linked-to Open Group document doesn't appear to back that up).
2006-02-02 06:51:54 +0000 / enh / revision 815
src/e/edit/Edit.java: use JFrameUtilities.setFrameIcon.
2006-02-01 23:07:03 +0000 / enh / revision 814
spelling-exceptions-C++: add more C++ <iomanip> identifiers.
2006-02-01 20:44:45 +0000 / enh / revision 813
spelling-exceptions-C++: add a few of the more important (to people like me) parts of C99 that aren't in C++2003. Specifically, it was strtoull I was after, but I thought I may as well include its friends and relatives.
2006-02-01 19:43:08 +0000 / enh / revision 812
spelling-exceptions-C++: update our "Standard Functions" list to the 2003 C++ standard. (Which still doesn't seem to include all of C99.)
2006-01-25 02:05:05 +0000 / mad / revision 811
spelling-exceptions-C++: Two more words from the collection of gruesome abbreviations that is <iostream> and "mutex". "mutex" ought to be in any computing dictionary but Outlook doesn't know it, google's definition highlighting doesn't know it and iamerican certainly doesn't (though they all know the similarly constructed "pixel"). Maybe we should look up this sort of abbreviation in wikipedia or foldoc, or have a list of globally reasonable "words" like "inode" and "spinlock". Perhaps I can provoke a discussion about that by adding "mutex" to the wrong file.
2006-01-24 22:27:08 +0000 / enh / revision 810
src/e/edit/ETextWindow.java: I've been dealing with a lot of merge conflicts lately, and automatic highlighting of conflict markers has made my life slightly less unpleasant.
2006-01-23 18:48:05 +0000 / enh / revision 809
src/e/edit/FindAction.java: susiw complained that C-F delete return only gets rid of the highlights until you next type something in the file, at which point they reappear. C-F esc was doing the right thing.
2006-01-22 18:46:53 +0000 / enh / revision 808
bin/edit: remove code that's broken in a multi-user environment.
2006-01-22 06:55:13 +0000 / enh / revision 807
bin/edit: remove duplication.
2006-01-20 21:40:56 +0000 / mad / revision 806
spelling-exceptions-C++: Elliott suggests doing the job properly for headers, like he already did for the rest of the spelling-exceptions here. Note the sop to installations without eg the cstddef header.
2006-01-20 20:36:50 +0000 / mad / revision 805
spelling-exceptions-C++: This one's been annoying me recently. I'd assumed there was something broken - that the header must have been in the list - until the patch just now showed it wasn't.
2006-01-20 20:28:50 +0000 / enh / revision 804
spelling-exceptions-C++: add a couple of header files I've just had call to use.
2006-01-14 20:49:05 +0000 / enh / revision 803
src/e/edit/CompareSelectionAndClipboardAction.java: searching for exceptions to my proposed heuristic that \b in a string literal is always an error, I found this string literal in a comment that contains exactly the error that keeps catching me out.
2006-01-14 02:52:10 +0000 / enh / revision 802
src/e/edit/ETextWindow.java: support for the new makefile text styler.
2006-01-09 01:37:05 +0000 / enh / revision 801
bin/edit:
src/e/edit/Edit.java: use the new support for a proper Mac about box and JOptionPane icons, and frame icons on other platforms.
2006-01-06 03:40:41 +0000 / mad / revision 800
src/e/edit/FindFilesContainingSelectionAction.java:
src/e/edit/FindFilesDialog.java:
src/e/edit/FindInFilesDialog.java:
src/e/edit/SaveMonitor.java:
src/e/edit/Workspace.java: Add the missing "In" to what is now FindInFilesDialog - affecting the filename, class name and variable names. Everyone thinks that would be a good idea. FindFilesContainingSelection sounds OK as is. This finishes Chris's earlier step in the right direction.
2006-01-05 10:46:04 +0000 / car / revision 799
Presumably this should either be called "Find Files" or "Find in Files",
not a mixture of the two. Though the object is called FindFiles, I
preferred the latter, though either would be accurate.
2006-01-04 22:31:13 +0000 / enh / revision 798
bin/echo-local-non-source-directory-pattern:
src/e/edit/FileIgnorer.java: only run the "echo-local-non-source-directory-pattern" script if it exists, and remove the broken default one from Edit's bin directory. It was causing me to miss the site-local script.
2006-01-04 07:06:42 +0000 / enh / revision 797
lib/edit-128.png: the 128x128 PNG icon.
2006-01-03 06:21:13 +0000 / enh / revision 796
bin/edit:
lib/edit.icns: use car's icons.
2006-01-03 06:16:57 +0000 / enh / revision 795
lib: new directory.
2006-01-01 22:42:14 +0000 / enh / revision 794
src/e/edit/Edit.java: update the copyright year.
2005-12-27 00:36:20 +0000 / enh / revision 793
src/e/edit/Edit.java:
src/e/edit/EditMenuBar.java: lose code to EMenuBar, which itself became simpler because there's no need for an initial traversal of the menu in modern Java. Which also means we can remove the two-stage menu bar construction, which won't have been necessary since 1.3, I think. I forget just how old Edit is, sometimes...
2005-12-22 20:23:11 +0000 / mad / revision 792
The BlueArc echo-local-non-source-directory-pattern script is in a different, site-wide repository. One of the requirements for finding the ignored-directory-pattern configuration was that it shouldn't necessarily require check-in privileges to the repositories to which it applies. Another was that it should "just work" for a BlueArc user, given we can make arbitrary hacks to their environment and add scripts to their PATH. I tried to be clear about that in choosing a name for the script but I'm not particularly impressed by the resulting name and it obviously didn't have the desired effect.
src/e/edit/FileIgnorer.java: Revert to searching for the script on the PATH.
bin/echo-local-non-source-directory-pattern: Provide a default implementation. Thanks to the change I just made to salma-hayek, this will be on the PATH, but lower down than the BlueArc script. That feels too fragile to me. Writing this comment, I see we have a FileUtilities.findOnPath which we could use instead of the default script. Or we could just hide the errors.
2005-12-22 07:54:03 +0000 / enh / revision 791
src/e/edit/Edit.java: fix the code that's supposed to open files in external applications to cope better with Linux, to handle the output streams of the process (this might have caused the program to block if it produced enough output), and to move the names of the various platforms' "open" commands into the code.
edit.properties-sample: remove the properties for the Mac OS and Win32 "open" commands, and extend the list of extensions that should be opened in external applications so I could test this. I wonder if all binary files should be handed over? Or all binary files should cause a dialog to ask what you want to do? Or we should have a built-in hex editor?
2005-12-22 07:36:49 +0000 / enh / revision 790
src/e/edit/Edit.java: Gustav Munkby found that without a "url.prefixes" property, Edit would defer to external applications for all files. Rather than fix that code, let's remove the property and recognize all possible URI schemes.
edit.properties-sample: remove a now-unused property.
2005-12-22 07:01:52 +0000 / enh / revision 789
src/e/edit/FileIgnorer.java: only try to run the "echo-local-non-source-directory-pattern" script if it exists.
2005-12-22 02:40:24 +0000 / mad / revision 788
bin/edit: Fix the smallest of Gustav Munkby's installation woes by installing the default edit.properties, if the preferences file doesn't exist, even if the preferences directory exists.
2005-12-21 04:59:23 +0000 / enh / revision 787
www/index.html: fix stupid HTML error. We should run tidy(1) or something.
2005-12-21 04:55:50 +0000 / enh / revision 786
www/index.html: use CSS.
2005-12-19 01:56:00 +0000 / enh / revision 785
edit.bat: delete rather than pretend to maintain this batch file; if we really want to support Win32, we want a proper WiX installer.
2005-12-19 00:28:26 +0000 / enh / revision 784
src/e/edit/JavaDoc.java: improve the default code for Mac OS to pick up the com.apple documentation.
edit.properties-sample: remove an unused property.
2005-12-17 07:17:26 +0000 / enh / revision 783
bin/edit: don't keep a file open and taking up one of the Java process' file descriptors.
2005-12-15 21:41:54 +0000 / enh / revision 782
src/e/edit/EditMenuBar.java: add "Help" menu. Yes, "Edit Website" and "Edit Change Log" are misleading.
2005-12-12 03:21:01 +0000 / enh / revision 781
bin/edit:
src/e/edit/ETextWindow.java: we can now use BugDatabaseHighlighter directly.
2005-12-05 05:40:31 +0000 / enh / revision 780
src/e/edit/ETextWindow.java: track API change.
2005-12-05 01:49:33 +0000 / mad / revision 779
spelling-exceptions-C++: Grr, I didn't restart Edit before committing the last change - and you have to restart Edit for spelling-exceptions changes to take effect. I had a look at what it would take to fix that, got most of the way and then threw it away. The set of spelling exceptions for a language wants to be in a language object, along with the ability to make a TextStyler and an Indenter, rather than in a parallel map/switch. Then the keywords want to be in the language rather than the styler.
2005-12-05 00:58:30 +0000 / mad / revision 778
spelling-exceptions-C++: Although it's only an optional standard type (huh, que, what?) and new to C99, uintptr_t's a great idea. I must not spell it "uinptr_t" and Edit will tell me when I do but my noticing depends on it not wiggly-lining at me when I get it right.
2005-12-05 00:10:25 +0000 / enh / revision 777
src/e/edit/BuildAction.java:
src/e/edit/CloseWindowAction.java:
src/e/edit/CorrectIndentationAction.java:
src/e/edit/EditMenuBar.java:
src/e/edit/FilePropertiesAction.java:
src/e/edit/FindAction.java:
src/e/edit/FindAndReplaceAction.java:
src/e/edit/GotoAction.java:
src/e/edit/NewFileAction.java:
src/e/edit/OpenQuicklyAction.java:
src/e/edit/RevertToSavedAction.java:
src/e/edit/SaveAction.java:
src/e/edit/SaveAsAction.java: associate the appropriate GNOME stock icons with our actions.
2005-12-01 17:26:48 +0000 / enh / revision 776
src/e/edit/JavaDoc.java: Ed's comment that the support for ignoring directories dates from when he had .class files in the same directory as .java files (which no-one does any more) also let us get rid of this.
2005-12-01 17:16:16 +0000 / mad / revision 775
src/e/edit/FileIgnorer.java: I'm still not following the JavaDoc file ignoring email thread as well as I'd like but, if I've got the right end of the stick, I think the directories.uninterestingNames code can come out. I'd said:
>> we need to find out what Ed's intention was
>> with JavaDoc.java's call of FileUtilities.isIgnoredDirectory.
And Ed replied:
> class files used to be compiled into the same directory as the source, which
> included CVS directories.
>
> not any more though.
I won't do anything with the JavaDoc stuff itself. Elliott seemed to have a proto-plan for a larger change.
2005-12-01 00:42:45 +0000 / mad / revision 774
src/e/edit/FileIgnorer.java: Try to run the script I just pushed to BlueArc's $MISC repository, to get the BlueArc-specific directory ignore patterns. Append the default patterns, one per line. One Thing Per Line is, of course, The One True Way partly because it helps you find why someone added a particular pattern. I'm still reading the edit.properties directory.uninterestingNames property for the minute, in an effort not to break Ed and Phil's setups. I don't think it'll get in the way of BlueArc users (we only ever add stuff to that pattern) although it'd be nice to get rid of the cruft.
edit.properties-sample: Remove the no longer necessary BlueArc cruft from the "sample".
2005-11-30 23:54:13 +0000 / mad / revision 773
src/e/edit/FileIgnorer.java: Pull the file and directory ignoring code out of salma-hayek. It currently has two users in Edit - the workspace scanner and something to do with the JavaDoc stuff - and none elsewhere. The FileIgnorer is now an object rather than a bunch of static methods. It's constructor takes the root directory, so the class has an opportunity to load settings particular to a workspace. I've yet to use the parameter: small steps.
src/e/edit/JavaDoc.java: Change to use FileIgnorer instead of FileUtilities. The lifetime of the FileIgnorer is currently one call to findPackagesIn. I don't know if that's the best choice.
src/e/edit/Workspace.java: Change to use FileIgnorer instead of FileUtilities. Remove the nameEndsWithOneOf(ignoredExtensions) check as FileUtilities was already doing that in its isIgnored check. Hopefully that was just half-migrated code and not some cunningly deliberate duplication of effort. The lifetime of the FileIgnorer is one workspace scan. That means that rescanning the workspace will reload the locally ignored directories pattern when I've added that feature to FileIgnorer. That will save me an extra Edit restart every few months.
2005-11-30 22:12:53 +0000 / mad / revision 772
edit.properties-sample: salma-hayek's (not edit's, though I think it's only used by edit) getUninterestingDirectoryPattern hard-codes the ignored names .deps, .svn, BitKeeper, CVS and SCCS. BlueArc's TARGET_MACHTYPE gets a potential -icc suffix where previously there was only -eabi. The . after linux_libc-2 wasn't supposed to be a wildcard.
2005-11-28 00:24:07 +0000 / enh / revision 771
src/e/edit/Edit.java: remove a hack that's been annoying me for ages by causing the main frame to jump from an incorrect initial position to the position it's supposed to have. Any claimed speed-up is irrelevant given the need to rewrite all this code for correctness so we can start up with windows exactly how we left them.
2005-11-28 00:19:14 +0000 / enh / revision 770
src/e/edit/Edit.java: use something more like the FSF-recommended text that we use in Terminator.
2005-11-28 00:15:29 +0000 / enh / revision 769
src/e/edit/ETextWindow.java: experience teaches the existing heuristic was wrong.
2005-11-28 00:02:58 +0000 / enh / revision 768
src/e/edit/Edit.java:
src/e/edit/Workspace.java: having to work around the expense of scanning the user's home directory was a self-inflicted problem. Rather than create a dummy workspace, explain to the user that they'll have to create one. And now always index a workspace. If the user doesn't want us to do so, they shouldn't ask. Plenty of code assumes that Edit.getCurrentWorkspace never returns null, which is no longer true. I'll find time to fix that when someone's paying me to work on Edit.
2005-11-27 23:33:41 +0000 / mad / revision 767
edit.properties-sample: Keep maintaining the BlueArc ignore list in the wrong place.
2005-11-26 03:05:54 +0000 / enh / revision 766
src/e/edit/Workspace.java: it turns out that we've long had a sensible work-around for the problem of workspaces that don't have a makefile or revision-control directory at their top level (because they've come from a .tgz, for example), but it was broken by mistakenly using "user.dir" where we meant "user.home". This means that my "workspace" for blog posts and my "workspace" for the JDK src.zip now work, but that the equivalent JDK "workspace" at work (which is under /usr/local/) still doesn't.
2005-11-26 01:56:15 +0000 / enh / revision 765
src/e/edit/ETextWindow.java: fix a real spelling mistake, and two near misses.
2005-11-25 00:55:56 +0000 / enh / revision 764
src/e/edit/ETextWindow.java: let the styler know if we're looking at Objective-C++.
2005-11-24 22:02:30 +0000 / enh / revision 763
src/e/edit/AdvisorHtmlPane.java: remove dead code.
2005-11-24 20:50:29 +0000 / enh / revision 762
src/e/edit/AdvisorHtmlPane.java: a hovered-over link should show the target as a tool tip.
2005-11-24 20:44:54 +0000 / enh / revision 761
src/e/edit/Advisor.java:
src/e/edit/AdvisorHtmlPane.java: put the Advisor in charge of handling links, and have the Advisor delegate to its WorkspaceResearcher instances (or fall back to Edit.openFile).
src/e/edit/WorkspaceResearcher.java: the new API.
src/e/edit/ManPageResearcher.java:
src/e/edit/RubyDocumentationResearcher.java: handlers for "man:" and "ri:" schemes.
src/e/edit/JavaResearcher.java:
src/e/edit/NumberResearcher.java: track API change.
2005-11-23 06:59:54 +0000 / enh / revision 760
src/e/edit/Advisor.java:
src/e/edit/AdvisorHtmlPane.java:
src/e/edit/EHtmlPane.java: give the advisor's content pane a more realistic name.
2005-11-23 06:52:26 +0000 / enh / revision 759
src/e/edit/EHtmlPane.java: a nicer font for Mac users.
2005-11-23 01:55:25 +0000 / enh / revision 758
src/e/edit/EditMenuBar.java: whoever put the menu items to cycle through workspaces above the ones to add/remove a workspace wasn't thinking.
2005-11-23 00:01:20 +0000 / enh / revision 757
src/e/edit/FindFilesDialog.java: fix a spelling mistake in the comment (there's an intermittent problem with our spelling checker on Mac OS), ensure we poke the tree from the EDT, and actually toggle the "root visible" property because Mac OS seems under some circumstances to not cause the layout cache to be flushed unless there's a real change. I guess this could be true of any custom LAF, though it's hard to see how it could avoid the cache flush if there is a change (unless it notices that it's changed back again before it next repaints, but hopefully no-one will go to those lengths!).
2005-11-22 21:05:21 +0000 / enp / revision 756
src/e/edit/JavaDoc.java: Fix a log-file-filling bug that's been annoying me for a while.
2005-11-21 06:05:28 +0000 / mad / revision 755
src/e/edit/FilePropertiesAction.java: Allow the user to change the charset encoding. The input UI could more usefully be a combo box with a list containing ASCII (for programs which must be ASCII), ISO-8859-1 (for the majority of legacy stuff), UTF-8 (for almost everything) and perhaps Windows code pages and something relating to little-endian and big-endian UCS-2 (or whatever it's called). Text's adequate as an interim, though, given that we validate it. A more interesting question is what to make the output UI: how to present encoding failures. Being able to step through the encoding failures as if they were Find matches might be useful. That suggests that the attemptEncoding method signature would want to change but, given the current lack of UI, the current signature seems reasonable at the moment.
My motivation here was to save octopus/sib/fc/Oui.cpp in UTF-8 so that it would (as it turned out) compile cleanly with a new version of icc. I didn't know about iconv(1) at the time and Markus Kuhn's normally helpful page just left me drowning in esoterica. I did later try pasting the 400KiB source file into a new buffer but that locked up the EDT for, say, 15 minutes, re-indenting the pasted version, before I gave up on it and killed Edit.
Having written the code, though, it seems odd not to let the user change the charset property, at least now we can determine that it's a non-lossy change.
2005-11-21 02:03:40 +0000 / enh / revision 754
src/e/edit/RubyDocumentationResearcher.java: on 2005-03-01 mad couldn't work out how to get the documentation for "IO.read"; this patch rewrites references to Ruby methods as links with a made-up "ri:" scheme...
src/e/edit/EHtmlPane.java: ...which we support here...
src/e/edit/Advisor.java: ...with the help of a slight interface change here.
2005-11-21 01:42:47 +0000 / enh / revision 753
HtmlAdvice.rb: remove dead code. We've used ri(1)'s "-f html" ever since I sent my important changes to the ri maintainer.
2005-11-20 08:11:15 +0000 / enh / revision 752
src/e/edit/FindFilesDialog.java: fix a minor but annoying issue with the tree showing find matches.
2005-11-19 14:37:20 +0000 / enp / revision 751
src/e/edit/TagsUpdater.java: Always make sure the tags are showing, even if they haven't changed. Otherwise, if the tags parsing took longer than the (arbitrary, half-second) progress bar timer delay, and they're unchanged, then the tags panel will just show the progress bar.
2005-11-18 03:02:20 +0000 / enh / revision 750
src/e/edit/JavaResearcher.java: more tidying.
2005-11-18 02:59:25 +0000 / enh / revision 749
src/e/edit/AutoCompleteAction.java:
src/e/edit/JavaDoc.java: remove redundant casts.
2005-11-18 01:33:01 +0000 / enh / revision 748
src/e/edit/JavaDoc.java: I wanted tool tips showing where the links linked to, but it looks like JEditorPane and the Swing HTML support doesn't offer that. The changes I made make this code far clearer, though, so I'll keep them. No, I don't know what I was thinking when I wrote the original. Especially the duplicate code finishing each branch of an if statement.
src/e/edit/JavaResearcher.java: it's useful to have links to the source for classes referred to when talking about methods. The ClassAndPackage class introduced here might (if promoted or simply moved) be a good way to clean up a lot of the existing code.
2005-11-17 22:47:21 +0000 / mad / revision 747
bin/edit: invoke-java.rb now takes care of this more carefully than we were doing here.
2005-11-16 21:37:17 +0000 / mad / revision 746
bin/edit: Lose our penultimate cygpath to invoke-java.rb.
2005-11-15 18:43:10 +0000 / enh / revision 745
src/e/edit/JavaDoc.java: rip out the old finding/linking of source code based on a source path and replace it with code that searches all the workspaces. So now there's one mechanism (adding a workspace) to both make source available to the user and to the computer. This also helps blur the distinction between user classes and JDK classes.
src/e/edit/EErrorsWindow.java: if the user clicks on a source file in a Java stack trace, find it with the new mechanism.
src/e/edit/JavaResearcher.java: change the advisor window over to using the new mechanism. I hadn't seen a source link in years, but now I have them for pretty much everything, with no configuration required.
2005-11-13 23:50:45 +0000 / enh / revision 744
bin/edit: use "invoke-java.rb" to slightly reduce duplication.
2005-11-10 03:13:41 +0000 / enh / revision 743
src/e/edit/AutoCompleteAction.java:
src/e/edit/CycleWindowsAction.java:
src/e/edit/Minibuffer.java:
src/e/edit/OpenQuicklyDialog.java: tidy up a few over-uses of SwingUtilities.getAncestorOfClass.
2005-11-10 03:00:45 +0000 / enh / revision 742
src/e/edit/EditMenuBar.java: Windows says "Exit", everyone else says "Quit". I've been seeing a lot of this menu item lately, and it's been annoying me.
2005-11-09 02:53:27 +0000 / enh / revision 741
src/e/edit/EErrorsWindow.java:
src/e/edit/ShellCommand.java:
src/e/edit/StreamMonitor.java:
src/e/edit/Workspace.java: remove reportErrors entirely, since we already offer direct access to the EErrorsWindow, remove drawHorizontalRule since it only has one caller, and change that caller to pass a String[] so we can remove the questionable use of varargs.
2005-11-09 02:42:04 +0000 / enh / revision 740
src/e/edit/TagsPanel.java:
src/e/edit/TagsUpdater.java: report tag-related problems in the tags panel itself.
2005-11-09 01:30:46 +0000 / mad / revision 739
A long unchecked-in change to speed up the output of multiple errors. I had a test case which output perhaps 100 000 lines of "error" message and took 560s to do so. With a previous version of this change (and presumably with this version) it went down to 3s. The original motivation was a couple of occasions when a source file was saved while gcc was compiling it, causing gcc to produce a line of errors perhaps for every character in the file or some similar degree of madness. I think that the example which prodded me into doing this took all night to complete.
src/e/edit/StreamMonitor.java: Hand the errors over in one go rather than piecemeal, so the errors window can amortize the cost of updating if it so chooses.
src/e/edit/EErrorsWindow.java:
src/e/edit/Workspace.java: Accept more than one line of error output at once, renaming identifiers as appropriate.
src/e/edit/ShellCommand.java:
src/e/edit/TagsUpdater.java: We thought about various names for reportError/reportErrors without coming to a good answer. Elliott noted that the tags updater's errors would be more likely to be spotted if reported in the tags window and that the horizontal rule could be implemented as data rather than code. So perhaps these will disappear at some point.
src/e/edit/ETextWindow.java: Already dead code.
2005-11-08 05:09:10 +0000 / enh / revision 738
bin/edit:
src/e/edit/Edit.java:
src/e/edit/EditServer.java: track InAppServer API change.
2005-11-08 00:27:37 +0000 / enh / revision 737
src/e/edit/Workspace.java: since the "Find in Files" dialog is non-modal, you can ask for more than one instance at once. In which case, we can't have an implementation that assumes zero or one instances without having later instances break existing ones.
2005-11-07 18:05:27 +0000 / enp / revision 736
src/e/edit/FindAction.java: StringUtilities.pluralize includes the value in the
string it returns, and we don't want it added twice: "Found 1 1 matches for ..."
2005-11-07 17:55:33 +0000 / enp / revision 735
src/e/edit/BuildAction.java: We spat on Ant's grave on the second of March 2004,
in favour of make (salma-hayek revision 9), so when looking for a build file we
should select a Makefile in preference to a build.xml file. This helps me at
work where they want to use Ant but I don't, so I've got a Makefile instead,
and also a trivial Makefile one directory deeper that just says "cd .. && make".
Now I can bin that, and build the target of my choice.
2005-11-07 04:03:26 +0000 / enh / revision 734
src/e/edit/FindAction.java:
src/e/edit/FindFilesDialog.java:
src/e/edit/OpenQuicklyDialog.java: use StringUtilities.pluralize.
2005-11-06 21:46:29 +0000 / enp / revision 733
src/e/edit/Advisor.java:
src/e/edit/FindAndReplaceAction.java:
src/e/edit/FindFilesDialog.java:
src/e/edit/TagsUpdater.java: Where we use thread pools, give them names.
src/e/edit/ETextWindow.java: Give the thread pool a name, and share it between
all instances of ETextWindow. Only one window at a time updates its watermark,
as it gains focus.
2005-11-06 10:32:32 +0000 / enp / revision 732
src/e/edit/EErrorsWindow.java: The filename matching pattern also matches lines
in a Java stack trace. Make these links work, if the java source is available.
src/e/edit/JavaDoc.java: Return the filename of a classes source code, if such
a file exists on any of the configured java source paths.
2005-11-06 07:04:07 +0000 / enp / revision 731
src/e/edit/EErrorsWindow.java: Make links without any trailing colon-delimited
address work. With no colon, String.substring(-1) would throw an exception.
2005-11-05 19:05:05 +0000 / enp / revision 730
src/e/edit/JavaDoc.java: Make it possible to put a user-friendly name in the
list of source locations.
2005-11-05 17:14:04 +0000 / enp / revision 729
src/e/edit/Advisor.java: A better way to ensure there's only one task running
at a time. If the researchers took a long time it might be worth killing them,
but they shouldn't be taking a long time.
src/e/edit/TagsUpdater.java: Do the same, to make sure only one tags panel is
updated at a time. If the Executor executes the tasks in the order it gets them,
this should help to ensure that when starting Edit with some files open, the
tags panel contents correspond to the ETextWindow opened last, rather than the
one whose TagsUpdater finished last.
2005-11-05 15:52:09 +0000 / enp / revision 728
src/e/edit/Advisor.java: Use a thread pool that caches threads and reuses them.
According to the docs, "These pools will typically improve the performance of
programs that execute many short-lived asynchronous tasks."
Kill the running research task, if any, before starting another.
2005-11-05 15:32:22 +0000 / enp / revision 727
src/e/edit/TagsUpdater.java: Revert inadvertent change.
2005-11-05 15:24:00 +0000 / enp / revision 726
src/e/edit/TagsUpdater.java: Make TreeModelBuilder a SwingWorker. Moves all of
the work out of the EDT, instead of scanning the tags in another thread and
building the TreeModel in the EDT.
Move the temporaryFile and tagsDigests fields to the containing class, because
we use a new TreeModelBuilder every time and these values need to be persistent.
2005-11-03 18:29:01 +0000 / enp / revision 725
src/e/edit/EErrorsWindow.java: Don't search past the point the user clicked.
2005-11-03 18:25:47 +0000 / enp / revision 724
src/e/edit/EErrorsWindow.java: Patterns match the entire input sequence by
default, so without enabling MULTILINE the pattern can only match when there's
nothing but a "make: Entering directory" announcement in the errors window.
2005-11-03 05:52:13 +0000 / mad / revision 723
bin/edit: Check-in my resolution of the conflict with Elliott's unpushed path-setting patch. Ah, so that's the reason I was still seeing the dumb error messages from the Linux setsid rather than our more explanatory ones. Is it worth caching target_os()? Perhaps.
2005-11-03 05:25:30 +0000 / mad / revision 722
bin/edit: invoke-java.rb doesn't (yet) let us specify additional classpath directories or specify addition -D arguments to the JVM but it does let us share the definition of cygpath() and that's a worthwhile saving.
I don't think cygpath() will do the right thing if we pass it a path containing ; instead of :. Perhaps that should change (that's one of the things about cygpath which made me think it will want future maintenance) but we should change all the callers if we're going to do that.
2005-11-03 05:17:19 +0000 / mad / revision 721
src/e/edit/EColumn.java: Move the StackOverflow work-around to a place where it catches the stack overflows which were stopping Edit from loading and saving all my saved-state. I don't think it's catching everything but it's catching enough to keep me working.
2005-10-31 03:21:39 +0000 / enh / revision 720
src/e/edit/ETextWindow.java: a few notes on further work.
2005-10-31 03:13:36 +0000 / enh / revision 719
src/e/edit/ETextWindow.java: martind made me realize that most of the Ruby standard library needs to be recognized by filename, and that my earlier hack was therefore insufficient. This patch lets Edit do the right thing when the filename is wrong without sacrificing the ability to recognize all Ruby files.
2005-10-29 02:29:45 +0100 / enh / revision 718
TODO: job done.
2005-10-29 02:24:16 +0100 / enh / revision 717
src/e/edit/TagsPanel.java: Some LAFs have selection backgrounds that are too dark for black and gray, so avoid setting the foreground on selected nodes.
2005-10-29 00:32:29 +0100 / enh / revision 716
src/e/edit/Workspace.java: write each window's y-coordinate to the XML saved state, plus support for opening a window at a given y-coordinate.
src/e/edit/EColumn.java: support for adding a window at a given y-coordinate and overriding the heuristic placement.
src/e/edit/Edit.java: read XML saved state that may or may not contain y-coordinates. Private API (the InitialFile class) is used to carry around the filename and (optional) y-coordinate. This might – if we can find a decent name – be a good candidate for splitting out and moving more of the "open" logic into. For now, it's a crufty implementation detail complete with overloading and non-private fields.
2005-10-28 21:59:56 +0100 / enh / revision 715
src/e/edit/FindAndReplaceAction.java: I don't think the pattern should be colored red to indicate a problem with it just because there are more matches than we're prepared to show. That's just confusing.
2005-10-27 23:15:17 +0100 / enh / revision 714
src/e/edit/Edit.java: I needed to open a file with colons in the name, thanks to markusl not being as ISO as everybody's friend Markus Kuhn, giving rise to filenames such as "titanfs1-fsm_console-2005-10-27-09:47:47.txt". The new heuristic won't work for grep(1) matches in files whose names contain colons, but it's a trivial quick fix that lets me get back to work...
2005-10-24 01:55:15 +0100 / enh / revision 713
src/e/edit/ETextWindow.java: only set user-configurable settings in the constructor so we don't revert the user's configuration changes while they're still editing.
2005-10-24 01:45:55 +0100 / enh / revision 712
src/e/edit/EErrorsWindow.java:
src/e/edit/ETextWindow.java: an attempt to switch to protected access and using @Override pointed out that this is all cruft. When I write my own language, you'll have to be explicit about whether you're overriding or introducing a new method.
2005-10-24 01:31:20 +0100 / enh / revision 711
src/e/edit/ETextWindow.java: use the PBashTextStyler if we're looking at a shell script. Remove the assumption that if a filename ends ".rb" it implies a Ruby script; (a) because we have a misnamed shell script and (b) because Ruby can be unambiguously determined by the file's hash bang line. Make the checks for perl(1) and ruby(1) hash bang lines more specific, even though I'm not aware of this having caused any trouble yet.
2005-10-23 07:07:48 +0100 / enh / revision 710
src/e/edit/ETitleBar.java: fix our appearance on the Java 6 GTK+ LAF.
2005-10-19 22:52:01 +0100 / enh / revision 709
src/e/edit/Edit.java: since we keep regressing on this, let's see if a comment will help. Probably not, but at least I can say I tried.
2005-10-19 22:39:41 +0100 / enh / revision 708
src/e/edit/Edit.java: Jikes is dead, and I've never seen another program broken in this way, and I don't think we have any Win32 users at the moment anyway, so lose this hack.
2005-10-19 22:36:29 +0100 / enh / revision 707
src/e/edit/Edit.java: be more lenient in what we accept so that "edit" works on grep(1) matches such as "file.cpp:123:void some_function() {", and don't get confused by the "void" that seems to be part of the address.
2005-10-19 22:25:03 +0100 / enh / revision 706
src/e/edit/FindFilesDialog.java: because we now mirror the directory structure in the match tree, it's no longer a valid optimization to assume that the child count of the match tree's root is equal to the number of matching files. So revert to using a separate count, rather than have to traverse the tree. This fixes Edit's claim that there's always exactly one matching file.
2005-10-18 22:56:46 +0100 / enh / revision 705
src/e/edit/OpenQuicklyAction.java: if I've selected "structures.make", I want to search for that literal string, and don't expect to also match "structures/Makefile". (Arguably, most of the time when one types '.' into the Open Quickly dialog, one really does want a literal '.' because they're so common in filenames. But that's a trickier problem as long as we do support regular expressions.)
2005-10-10 07:26:58 +0100 / enh / revision 704
www/index.html: add a note about Exuberant ctags, and links to pre-built Mac OS and Solaris binaries.
Why do I say "darwin" but not "SunOS" (or, for that matter, "Darwin")? We probably want another round of name fixes at some point, until we actually have the proper "-$(uname)-$(arch)" suffixes. To which end, it's worth noting that "amd64" appears to be i86pc, though from what I've seen Sun appears to have at least three different names for (variants of?) the same architecture.
2005-10-06 20:11:32 +0100 / enh / revision 703
src/e/edit/OpenQuicklyAction.java: if the user selects an absolute path, possibly with a line number, because they're going through a list of grep-like output, it's unfriendly of us to fail to find anything in the Open Quickly dialog. My first thought was to strip the repository root if we find it as a prefix, but just opening the exact address we've been given seems like Doing The Right thing. It's certainly making my life easier right now.
2005-10-03 02:48:51 +0100 / enh / revision 702
src/e/edit/Workspace.java: give EErrorsWindow the Workspace it corresponds to, rather than a bogus title.
src/e/edit/EErrorsWindow.java: ditch the old broken attempt to resolve non-absolute names in favor of a new broken attempt that at least defers work until the user clicks, at which point we can put as much effort in as we like.
2005-10-03 02:05:19 +0100 / enh / revision 701
src/e/edit/SimplePatchDialog.java: if diff(1) fails when we first run it, try again without using any GNU extensions. This fixes the Solaris 10 out-of-box experience. Hopefully Solaris 11 will switch to GNU diff...
2005-10-03 01:48:24 +0100 / enh / revision 700
src/e/edit/SimplePatchDialog.java: Solaris' diff(1) isn't GNU diff. Without this patch, it's not at all obvious what's gone wrong.
2005-10-01 01:54:40 +0100 / mad / revision 699
bin/edit: Keep track of the sample properties file we used to default the user's initial properties. This will let us (manually) find anything which the user has customized, so we can update those things they haven't changed.
2005-09-26 01:50:04 +0100 / enh / revision 698
src/e/edit/FindAction.java: use "smart case" for C-F find, but ensure that when we search for the current selection, we do take case into account, even if it's all-lowercase.
2005-09-24 18:52:32 +0100 / enh / revision 697
src/e/edit/FindFilesDialog.java:
src/e/edit/Workspace.java: use PatternUtilities to implement "smart case", and use it more widely. Also fix the long-broken automatic search in a file opened from the "Find in Files" dialog for the regular expression that caused it to appear in the dialog.
2005-09-21 04:11:45 +0100 / mad / revision 696
.cvsignore: Another obsolete .cvsignore file comes to light.
2005-09-21 01:09:22 +0100 / mad / revision 695
.: Rename generated to .generated and lose the obsolete jar file.
2005-09-21 01:02:38 +0100 / mad / revision 694
bin/edit: setsid and BringProcessToFront move as a result of the generated->.generated rename.
2005-09-20 02:59:37 +0100 / enh / revision 693
src/e/edit/ETextWindow.java: factor out the code to guess a file's type from its content, and call it when we save as well as when we load. This means that when you first save a script, for example, it will become colored and switch to an appropriate indenter without you having to close and re-open the file (assuming we couldn't tell from its name what it was).
2005-09-18 21:28:17 +0100 / enh / revision 692
edit.properties-sample:
src/e/edit/ChangeFontAction.java: given the amount of trouble we've gone to in GuiUtilities to choose the best monospaced font on the system, it's disappointing that Edit should make such a bad default choice on Solaris because of a hard-coded font name.
2005-09-17 22:56:24 +0100 / mad / revision 691
bin/edit: Use the new uname replacement. We're asking at least two different questions here - "what's the name of the directory the make rules have created?" and "what is the OS we're running on?". I could have faffed about choosing different names for the same value according to which question I thought was being asked at each call site. It didn't seem worth it to me, until we've got a reason to distinguish them, but I'm open to persuasion.
2005-09-14 07:11:46 +0100 / enh / revision 690
src/e/edit/FindAction.java: fix a silly bug when you invoke "Find" again while you're already in that mode.
2005-09-14 06:58:39 +0100 / enh / revision 689
src/e/edit/StreamMonitor.java: comment.
2005-09-14 06:56:40 +0100 / enh / revision 688
src/e/edit/ETextWindow.java:
src/e/edit/StreamMonitor.java:
src/e/edit/TagsUpdater.java:
src/e/edit/Workspace.java: remove the unused 'context' parameter.
src/e/edit/ShellCommand.java: ...and make sure that the final part of the build output is done on the EDT.
2005-09-14 06:48:59 +0100 / enh / revision 687
src/e/edit/ShellCommand.java:
src/e/edit/StreamMonitor.java: this code has always been wrong, but it was today that it first bit me hard enough to hurt. Switch to SwingWorker mainly for its coalescing of multiple calls to publish, even though running a hack with EventQueue.invokeLater in Workspace.reportError at work didn't seem to harm performance for the intended use of build output.
2005-09-13 23:26:46 +0100 / mad / revision 686
.: Stop "make dist" from cluttering checkintool.
2005-09-12 02:41:06 +0100 / enh / revision 685
src/e/edit/FindFilesContainingSelectionAction.java: unlike the check on "Open Quickly", the check for "Find in Files" while the workspace is being scanned was broken by code that assumed the workspace had been scanned running before the check.
src/e/edit/FindFilesDialog.java: add a node to the tree for every directory on each matching file's path. As expected, this does waste rather a lot of vertical space. But it does let us ignore whole subtrees much more easily than we could before.
2005-09-11 18:50:27 +0100 / enh / revision 684
src/e/edit/FindAndReplaceAction.java: I needed more than 100 matches the other day. This isn't a good solution to the problem, but it let me keep working.
2005-09-11 18:44:19 +0100 / enh / revision 683
bin/edit:
src/e/edit/EditServer.java: use salma-hayek's BringProcessToFront on Mac OS so the "edit" script causes Edit to come to the front when it's asked to open a file from a shell (or CheckInTool).
2005-09-03 21:36:42 +0100 / enh / revision 682
src/e/edit/Edit.java: only cater to Mac OS' LAF when on Mac OS. Improve a comment to make clear the benefit Linux gets from what was originally a Mac OS-specific improvement.
2005-09-03 21:20:48 +0100 / enh / revision 681
src/e/edit/Edit.java: use the new StopIcon.makeStopButton method, and put an appropriate gap between the progress bar and the stop button.
2005-08-31 02:24:49 +0100 / enh / revision 680
src/e/edit/TagsUpdater.java: leaving the original indentation on the line just makes the tool-tip harder to read.
2005-08-29 17:13:20 +0100 / enh / revision 679
src/e/edit/ETextWindow.java: unbreak the normal case, use the more usual style for log messages, provide a better label in the failure case, and make the failure case more clearly the exception rather than the rule.
2005-08-29 16:47:42 +0100 / mad / revision 678
src/e/edit/ETextWindow.java: Allow files which are modified in memory but deleted on disk to be discarded.
2005-08-28 18:22:46 +0100 / enh / revision 677
src/e/edit/FindAndReplaceAction.java: switch to the new SwingWorker.
2005-08-28 18:18:30 +0100 / enh / revision 676
src/e/edit/FindFilesDialog.java: correct the access of doInBackground.
2005-08-28 18:15:23 +0100 / enh / revision 675
src/e/edit/Workspace.java: add missing @Override annotations and correct the access of doInBackground.
2005-08-28 18:01:31 +0100 / enh / revision 674
src/e/edit/Workspace.java: switch the file list updating code over to the new SwingWorker. Also move all the code into the FileListUpdater class. There may be an argument for having something like them in FileUtilities or some new FileTreeWalker class, but there's no argument for having them in Workspace.
2005-08-28 07:49:47 +0100 / enh / revision 673
src/e/edit/FindFilesDialog.java: this at least makes sure the tree is repainted if we find a definition after the tree has been displayed. Unfortunately, JTree seems to cache the node widths, so the wider text gets truncated. I'm not sure how to make it do the right thing.
2005-08-28 06:35:06 +0100 / enh / revision 672
src/e/edit/FindFilesDialog.java: look for definitions in the matching files using a newFixedThreadPool. This isn't correct, because I've added no mechanism to deal with the fact that the file-finding might end (and the UI be redrawn) before all the definition-finding is finished. But it is much faster, especially for a small workspace like Edit's own, because we don't hold up the search each time we find a file containing a match.
2005-08-28 06:07:53 +0100 / enh / revision 671
src/e/edit/FindFilesDialog.java: a few minor tweaks that slightly improve performance. Shaves 0.5s off the time to search the Java 5 src.zip on Mac OS (which was nearly 7s before).
2005-08-28 05:38:36 +0100 / enh / revision 670
src/e/edit/FindFilesDialog.java: use Java 6's SwingWorker instead of our own nasty mess, hacked up over many years. Also make use of Executors.newSingleThreadExecutor; how did we ever live without this? I've taken the opportunity to tidy up some of the naming, and throw out the "we don't trust our cancel implementation" output, and send the timing output to the log. (I've also submitted a bug to Sun about their "canceled" versus "cancelled" confusion.)
bin/edit: make the SwingWorker classes available at run-time.
2005-08-26 07:02:16 +0100 / enh / revision 669
src/e/edit/ETitleBar.java: I noticed at work today that the "switch to counterpart" buttons weren't getting drawn as soon as the windows appeared. This was trivially reproduced at home, though with the bizarre revelation that if you wait long enough, they will appear. (I can't explain that.) Anyway, in goes the usual invalidate/validate/repaint hack. While looking at this problem, I finally understood why the focus ring wasn't right on Mac OS: the JScrollPane isn't listening for focus changes, but it will paint differently depending on whether its subcomponent has the focus or not. So all we need to do is make sure it gets repainted.
src/e/edit/ETextWindow.java: also while looking at the same problem, I realized that we were creating and destroying a Thread for every document mutation. I'm not sure why we were invoking updateWatermarkAndTitleBar from textBecameDirty, but it doesn't seem like a particularly good idea. Also, switch to using a single-thread Executor to further reduce the impact of the checking.
2005-08-25 01:49:17 +0100 / enh / revision 668
src/e/edit/ETextWindow.java:
src/e/edit/ETitleBar.java:
src/e/edit/ExternalToolAction.java: check for a file's counterpart on the same thread as we do the watermark checks (but, primarily, "on any thread but the EDT"). I notice we repaint the title bar for each text change, rather than each switch between "dirty" and "clean". This explains what I saw ages ago with QuartzDebug, I think, and might be of interest to those editing on laptops.
2005-08-23 05:05:39 +0100 / enh / revision 667
src/e/edit/ETextWindow.java: on a fast dual-processor machine it was possible for the watermark-updating thread started when the text area's change listeners are fired to run before we set lastModifiedTime. So a newly-read file looks to be out of date (because lastModifiedTime defaults to 0) until you click on it, at which point it's re-checked and found to have a last-modified time equal to the field's since-set value.
2005-08-19 06:46:48 +0100 / enh / revision 666
src/e/edit/ShellCommand.java: use "setsid", if we can find it.
bin/edit: try to put salma-hayek's "setsid" on the path.
src/e/edit/Edit.java: track API change.
2005-08-18 01:32:40 +0100 / enh / revision 665
src/e/edit/Edit.java: use the higher-level code for sending signals to Process instances that's already in ProcessUtilities.
2005-08-18 01:20:37 +0100 / mad / revision 664
src/e/edit/EColumn.java: Previously, I'd emailed:
If you have the size of Edit window that I have (which is most of a 1600x1200 display) and you have ~30 open files in a workspace, then you get this on startup:
2005-08-09T11:07:34.115-0700 Edit: Exception occurred during event dispatching.
Associated exception:
java.lang.StackOverflowError
at e.edit.EColumn$TextsPanel.getComponentIndex(EColumn.java:248)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:295)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:317)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:317)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:317)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:317)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:317)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:317)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:317)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:317)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:317)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:317)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:317)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:317)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:317)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:317)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:317)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:317)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:317)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:317)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:317)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:317)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:317)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:317)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:317)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:317)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:317)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:317)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:333)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:333)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:333)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:333)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:333)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:333)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:333)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:333)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:333)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:333)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:333)
at e.edit.EColumn$TextsPanel.moveTo(EColumn.java:333)
And, more severely, your Edit state will be silently thrown away on shutdown. So, even if you close the files, you can't get out of the state without manually editing the saved-state.xml file.
I just ran into this again when I made the Edit window smaller and foolishly quit. The "fix" is crude and leads to lots of exception messages on startup but it's simple and effective and fixes a nasty problem.
2005-08-17 23:47:14 +0100 / enh / revision 663
bin/e: simonj points out that not only is this unused, it doesn't even work.
2005-08-15 04:26:28 +0100 / enh / revision 662
src/e/edit/JavaDoc.java: (Sun 6179468) File.toURL should be deprecated.
2005-08-15 04:09:58 +0100 / enh / revision 661
src/e/edit/Edit.java:
src/e/edit/EditServer.java:
src/e/edit/EErrorsWindow.java:
src/e/edit/ETextWindow.java:
src/e/edit/ShellCommand.java:
src/e/edit/TagsUpdater.java:
src/e/edit/Workspace.java: use the EventQueue invoke* methods directly.
2005-08-15 02:31:22 +0100 / enh / revision 660
src/e/edit/SimplePatchDialog.java: use transparent colors so that we don't obscure other highlights, the selection in particular.
2005-08-15 01:39:56 +0100 / enh / revision 659
src/e/edit/SimplePatchDialog.java: switch to PTextArea for patch display. Also add a convenience method to provide a scrollable patch view, since that's what all the callers want.
src/e/edit/ETextWindow.java: track API change.
2005-08-15 01:16:33 +0100 / enh / revision 658
src/e/edit/FindAction.java: track API change.
2005-08-11 02:02:28 +0100 / enh / revision 657
src/e/edit/ETextWindow.java: if we read emacs' retarded address format, we have to output its retarded address format too.
2005-08-11 01:55:08 +0100 / enh / revision 656
src/e/edit/ETextWindow.java: fix getAddress to cope with non-empty selections.
2005-08-11 01:47:07 +0100 / enh / revision 655
src/e/edit/ETextWindow.java: remove an empty static initializer. Why isn't this an error?
2005-08-11 01:44:58 +0100 / enh / revision 654
src/e/edit/Edit.java: include the trailing ':' in the address, so the code in ETextWindow can recognize that we want to select the whole line.
2005-08-09 19:28:50 +0100 / enh / revision 653
src/e/edit/EErrorsWindow.java: remove code for testing control-character rendering which was accidentally checked in as part of a very large change to an unclean clone.
2005-08-04 19:15:57 +0100 / enh / revision 652
src/e/edit/ETextArea.java: fix the build, and at the same time make it a little more likely to break if an incompatible change is made to PTextArea (we were somewhat lucky that pcn's change was one of the few possible breakages that the compiler could detect).
2005-08-01 03:38:47 +0100 / enh / revision 651
src/e/edit/OpenQuicklyDialog.java: add the form elements to the real FormPanel, not a temporary one. (Incorrect tracking of a recent API change.)
2005-08-01 02:07:33 +0100 / enh / revision 650
src/e/edit/AddWorkspaceAction.java:
src/e/edit/ETextWindow.java:
src/e/edit/ExternalToolAction.java:
src/e/edit/FilePropertiesAction.java:
src/e/edit/FindAndReplaceAction.java:
src/e/edit/FindFilesDialog.java:
src/e/edit/NewFileAction.java:
src/e/edit/OpenQuicklyDialog.java:
src/e/edit/SetBuildTargetAction.java:
src/e/edit/ShowMisspellingsAction.java:
src/e/edit/SimplePatchDialog.java: track e.forms API change.
2005-07-23 19:45:29 +0100 / enh / revision 649
src/e/edit/Workspace.java: use EFileDialog for both open and save as dialogs, so we always get the best of AWT/Swing.
2005-07-22 06:09:48 +0100 / enh / revision 648
src/e/edit/ETextWindow.java: a file that has been deleted since being read in is not out-of-date. It does not exist, and must be handled as such.
2005-07-20 03:23:43 +0100 / enh / revision 647
src/e/edit/ShellCommand.java:
src/e/edit/StreamMonitor.java: never subclass Thread.
2005-07-17 00:59:36 +0100 / enh / revision 646
src/e/edit/InsertInterfaceAction.java: fix up and improve the old Java interface inserter. Recognize more cases where we can be helpful, offer a keyboard equivalent, generate slightly more useful output, and behave better in face of errors. Also switch to a more modern coding style.
src/e/edit/EditMenuBar.java: stick it on the menu bar.
src/e/edit/JavaResearcher.java: InsertInterfaceAction no longer uses JavaResearcher's NEW_PATTERN, so it can become private.
2005-07-17 00:04:25 +0100 / enh / revision 645
src/e/edit/BirdView.java:
src/e/edit/BuildAction.java:
src/e/edit/Edit.java:
src/e/edit/ETextWindow.java:
src/e/edit/FindAction.java:
src/e/edit/FindAndReplaceAction.java:
src/e/edit/FindFilesDialog.java:
src/e/edit/JavaDoc.java:
src/e/edit/NewFileAction.java:
src/e/edit/OpenQuicklyDialog.java:
src/e/edit/StreamMonitor.java:
src/e/edit/TagsUpdater.java: modernize exception handling.
2005-07-16 22:50:50 +0100 / enh / revision 644
src/e/edit/FindAction.java: I keep finding myself wondering, when I see "Found 0 matches", what exactly Edit was looking for. This may indicate a deeper problem, but the surface problem is that we don't say what we're looking for. Fix that.
2005-07-16 19:54:43 +0100 / enh / revision 643
src/e/edit/AddWorkspaceAction.java: both Phil and I have adopted the coping strategy of using the fields in this dialog out-of-order, so maybe it's best to just reorder the fields? (Making the name-guessing more intelligent and distinguishing user-entered names from machine-generated ones might be better still, but it's a lot more work.)
2005-07-16 19:50:58 +0100 / enh / revision 642
src/e/edit/AddWorkspaceAction.java: switch to a loop like the one for the Find/Replace dialog, where we keep bringing the same dialog back up with the same values if we couldn't complete the action. If we do complete successfully, don't bother remembering the workspace name, because it's unlikely that the next added workspace will want the same name, and we'd hope to invent a name from the directory name anyway.
2005-07-13 12:02:30 +0100 / mad / revision 641
src/e/edit/EditServer.java: Fix the EditServer so it doesn't always:
java.lang.NullPointerException
at e.edit.EditServer$Opener.run(EditServer.java:56)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:461)
at e.debug.EventDispatchThreadHangMonitor.dispatchEvent(EventDispatchThreadHangMonitor.java:133)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
Also, print the exception's stack trace down the pipe. This was useful in getting to the bottom of the problem. There are lots of ex.getMessage and lots of ex.printStackTrace in the source. Perhaps printing the stack trace to the log would be more conventional. out.println(ex.getMessage()) on a null pointer exception just said "null". I don't know if that means it returned null or "null". Either way, it's not very useful here.
2005-07-12 17:33:11 +0100 / enh / revision 640
src/e/edit/NewFileAction.java: car suggests that rather than throw a NullPointerException because File.getParentFile returns null, giving a non-absolute path to "New File" should create a file in the workspace root.
2005-07-12 17:22:45 +0100 / enh / revision 639
src/e/edit/BuildAction.java: car suggests "neither-nor".
2005-07-12 16:21:46 +0100 / enh / revision 638
src/e/edit/TagsUpdater.java: mention the most likely problem if we can't read the tags.
2005-07-09 21:51:41 +0100 / enh / revision 637
src/e/edit/Edit.java: simplify the setting of the initial window bounds.
2005-07-09 20:21:08 +0100 / enh / revision 636
src/e/edit/Edit.java: change all the static methods to instance methods, and insist that everyone use getInstance. Bring all the field declarations to the top of the file. Add code to rewrite the saved state when a workspace is added or removed (this was the original motivation for this whole patch). Open remembered files via invokeLater to avoid a deadlock introduced by the move away from static methods.
src/e/edit/AddWorkspaceAction.java:
src/e/edit/BuildAction.java:
src/e/edit/CycleWorkspacesAction.java:
src/e/edit/EditServer.java:
src/e/edit/EErrorsWindow.java:
src/e/edit/EHtmlPane.java:
src/e/edit/ETextWindow.java:
src/e/edit/ExternalToolAction.java:
src/e/edit/FilePropertiesAction.java:
src/e/edit/FindAction.java:
src/e/edit/FindAndReplaceAction.java:
src/e/edit/FindFilesContainingSelectionAction.java:
src/e/edit/FindFilesDialog.java:
src/e/edit/GotoAction.java:
src/e/edit/InsertInterfaceAction.java:
src/e/edit/JavaResearcher.java:
src/e/edit/KillErrorsAction.java:
src/e/edit/ManPageResearcher.java:
src/e/edit/NewFileAction.java:
src/e/edit/OpenAction.java:
src/e/edit/OpenMakefileAction.java:
src/e/edit/OpenQuicklyAction.java:
src/e/edit/OpenQuicklyDialog.java:
src/e/edit/RemoveWorkspaceAction.java:
src/e/edit/SaveAllAction.java:
src/e/edit/SaveAsAction.java:
src/e/edit/SetBuildTargetAction.java:
src/e/edit/ShellCommand.java:
src/e/edit/ShowMisspellingsAction.java:
src/e/edit/SimplePatchDialog.java:
src/e/edit/TagsUpdater.java:
src/e/edit/Workspace.java: track API change.
2005-07-07 07:07:36 +0100 / enh / revision 635
src/e/edit/WatermarkViewPort.java: modernize the coding style; improve the documentation.
2005-07-07 07:02:07 +0100 / enh / revision 634
src/e/edit/WatermarkViewPort.java: when property changes cause repaints has always been confusing. As far as I can tell, the rule is "if they were in AWT, repaint; otherwise do fire a PropertyChangeEvent". So although setBackground was causing repaints (if the color was actually different), setOpaque wasn't, under any circumstances. Previously we were getting away without an explicit repaint because we were running in response to a focus change, and were about to repaint anyway.
2005-07-04 21:34:04 +0100 / enh / revision 633
src/e/edit/ETextWindow.java: a recent change to compare against the on-disk contents exacerbated the problem of doing this checking on the event dispatch thread. The old checks had the potential to be slow; the new check often was (in an NFS-over-WAN situation). At the cost of potentially having the watermark lag behind the focus, this patch prevents the watermark update from hanging the UI.
2005-06-30 17:37:46 +0100 / enh / revision 632
src/e/edit/EditServer.java: add a new "open-and-block" verb that waits for the window to be closed before closing the connection.
bin/edit:
bin/edit-and-block: add a "--block" option to the "edit" script, and add a new "edit-and-block" script for use with the $EDITOR environment variable. This lets you use Edit to edit your crontab. (There may be other applications, but I don't have any. "bk resolve", though visually confusing, waits for you to give it the "C" command anyway. And I haven't used "cvs commit", the other place I've wanted this functionality, since a couple of hours in to writing SCM.)