From: Peter G. <pe...@ar...> - 2002-07-22 16:48:06
|
This morning's 0.16.0+ development snapshot is up: http://armedbear.org/j.zip (source) http://armedbear.org/j-jar.zip (just j.jar) The old make-based build system now puts the .keywords files into j.jar, so you don't really need the j source tree any more after you do "make install". (The ant-based build system has handled this correctly all along.) When compilation buffers are re-used, they are now emptied and repainted in an empty state before the next compilation is started, in order to clear the output from the previous compilation. Tag files are now versioned, and the code that loads them now automatically deletes obsolete tag files and queues the directories in question to be re-tagged. (The actual re-tagging is done on idle time, so if findTag fails, wait a few seconds and try again.) Unfortunately, this change is not retroactive, so if you go back to 0.16.0 (or earlier) after using the current snapshot, you'll need to manually delete all the files in the ~/.j/tagfiles subdirectory, since the old tag file code can't use the new versioned tag files. Your computer won't explode if you try to use the old code with the new tag files, but findTag and friends won't work beyond the current buffer. No big deal, just don't go back... ;) Thanks for your support. -Peter |
From: Peter G. <pe...@ar...> - 2002-08-02 18:41:49
|
This morning's 0.16.1+ development snapshot is up: http://armedbear.org/j.zip (source and documentation) http://armedbear.org/j-jar.zip (just j.jar) This snapshot fixes bug 588827: When creating an array inline, J does not handle the indentation of the lines properly: Object[] arr = new Object[] { new Object(), new Object(), new Object(), new Object() }; J now handles this case correctly, as well as the following variant thereof: String array[] = { "this", "is", "a", "test" }; In addition, in Java mode, htmlInsertTag is now mapped by default to Ctrl Shift comma, as it is in HTML mode, to facilitate the insertion of HTML tags (<code> etc.) in Javadoc comments. Thanks for your support. -Peter |
From: Peter G. <pe...@ar...> - 2002-08-19 17:43:06
|
This morning's 0.16.2+ development snapshot is up: http://armedbear.org/j.zip (source and documentation) http://armedbear.org/j-jar.zip (just j.jar) This snapshot fixes a few minor bugs not related to mail: - In Java mode in 0.16.2, if there were multiple interface names following "implements", all but the last were incorrectly added to the tag list as fields. Fixed. - The Java tagger in 0.16.2 reported the visibility of public, private, or protected methods incorrectly if the method in question immediately followed a field declaration with an initializer, e.g. private static Stack markers = new Stack(); public void pushPosition() { } In this situation pushPosition() would be incorrectly reported to have package (rather than public) visibility. Fixed. - cvsCommit didn't refresh the display properly when the CVS checkin buffer went away if the window wasn't split at the time. Fixed. And finally, in a mail-related improvement, sortByThread now handles messages better when their subject begins with "Re: Re:" (or "Re:Re: Re:", etc.); j now strips all occurrences of "re:", regardless of case, with or without trailing whitespace, when trying to find the parent message. sortByThread is still not perfect, but it's getting better... The current plan is to release 0.17.0 in the next few days, prior to embarking on mailbox-specific properties, which might take a while. Thanks for your support. -Peter |
From: Peter G. <pe...@ar...> - 2002-08-27 20:28:09
|
This morning's 0.16.3+ development snapshot is up: http://armedbear.org/j.zip (source and documentation) http://armedbear.org/j-jar.zip (just j.jar) This snapshot features a much faster and more accurate version of sortByThread (which, BTW, is misnamed, but that's not important now). It's about 30 times faster than the version in 0.16.3, and it does a much better job of the actual threading, per the imapext-thread Internet Draft. By request, the indentation increment for threaded messages is now 2 instead of 1. At the top level, the first orphan message in a sibling set is now indicated by a '-' followed by a space at the beginning of the subject column. (Orphan messages are messages that have a parent, but whose parent is not actually in the mailbox.) Evolution promotes such messages to the top level and treats their siblings as their children, but this approach is not strictly correct. The "- " prefix is probably not the last word in the rendering of this situation... ;) On a brighter note, J does correctly recognize that Re: [V4L] Re: [RFC] alternative kernel multimedia API and Re: [livid-gatos] [RFC] alternative kernel multimedia API represent the same base subject, which is more than can be said of either Mutt or Evolution, but maybe they have their reasons... Finally, in JavaScript mode findTagAtDot now ignores the arity of the expression at dot, since you really can't trust arity in JavaScript. Thanks for your support. -Peter |
From: Peter G. <pe...@ar...> - 2002-09-03 18:11:19
|
This morning's 0.16.3+ development snapshot is up: http://armedbear.org/j.zip (source and documentation) http://armedbear.org/j-jar.zip (just j.jar) This snapshot finishes a bit of cleanup to remove unnecessary repaints in the sidebar tree, both in Java mode and in directory buffers. In addition, this morning's snapshot fixes a NullPointerException in FTP directory buffers (and possibly elsewhere too) introduced yesterday by an earlier version of the self-same cleanup code. -Peter |
From: Peter G. <pe...@ar...> - 2002-09-16 20:28:39
|
This morning's snapshot is up: http://armedbear.org/j.zip (source) http://armedbear.org/j-jar.zip (just j.jar) 1. J's p4 wrapper command now supports "%" as an alias for the full path of the file in the current buffer. So now you can do things like p4 filelog -l % instead of having to type in the filename. 2. When you return to a set of paired buffers, the correct buffer now gets focus. (In previous snapshots the primary buffer got focus in most cases, whether it deserved it or not.) 3. incrementalFind no longer succumbs to a NullPointerException in web or mail buffers that contain an image. 4. Multiline /*...*/ comments in Java mode are now less likely to confuse the indentation of subsequent lines. 5. J is now 100% GIF-free. Plus fixes for many of the bugs introduced in recent snapshots... ;) Thanks for your support. -Peter |
From: Peter G. <pe...@ar...> - 2002-10-30 21:46:23
|
This morning's 0.17.0+ development snapshot is up: http://armedbear.org/j.zip (source) http://armedbear.org/j-jar.zip (just j.jar) Lisp mode now does automatic indentation (the Tab key is your friend). This is still work in progress, but j seems to be right at least 90% of the time, according to some definition of right (there's a bit of disagreement out there about the fine details of Lisp indentation). Lisp shell mode has been added, if you've got jpty. A Lisp shell buffer is basically an ordinary shell buffer that knows it's running a Lisp interpreter, so it does parenthesis matching and automatic indentation on the text you type into it. To start up a Lisp shell, do Alt X, "lisp <path>", replacing "<path>" with the name of your Lisp interpreter, e.g.: lisp /usr/bin/lisp or lisp clisp or lisp rep You don't need to provide a full pathname if the program in question is in your PATH. If you just do Alt X, "lisp", j will look for a program named "lisp" in your PATH and use that. Like normal shell buffers, Lisp shells support history with Ctrl P and Ctrl N, and the Tab key is mapped to indentLineOrRegion. As mentioned, you need jpty to use shell buffers of any sort. If you're running Linux, all you have to do to build jpty is set jpty=yes in build.properties before running ant, then copy src/jpty/jpty somewhere in your PATH when the build finishes. Thanks for your support. -Peter |
From: Peter G. <pe...@ar...> - 2002-11-04 16:50:33
|
This morning's 0.17.0+ development snapshot is up: http://armedbear.org/j.zip (source) http://armedbear.org/j-jar.zip (just j.jar) With previous versions of j, if a file in the backup directory (which is ~/backup by default) is read-only on disk, writeBackup() fails on the next attempt to write to that file, which causes save() to fail. Starting with this snapshot, writeBackup() now deletes the read-only file in the backup directory and tries again, if copyFile() fails the first time and the target file in the backup directory exists and is not writable. Since the current user should always have write rights to the backup directory, this approach should work, and it will prevent inconvenience if a file in the backup directory ends up being read- only... =2E..which could have happened because of another buglet fixed in this snapshot. In previous versions, j would write the backup file before checking to make sure the actual target of the save was writable. If the target was in fact 0444 (for example), j would write the backup file and make the backup file 0444, to match the permissions of the original file, then discover that the target was not writable and at that point give up, leaving a read-only file in the backup directory. Starting with this snapshot, save() errors out right away if the target file is not writable, i.e. before making any attempt to do the backup, so this odd situation should not arise in the future. Thanks for your support. -Peter |
From: Peter G. <pe...@ar...> - 2002-11-23 20:00:13
|
This morning's 0.17.2+ development snapshot is up: http://armedbear.org/j.zip (source) http://armedbear.org/j-jar.zip (just j.jar) This snapshot adds three new commands: forwardSexp, backwardSexp, and downList, mapped to Ctrl Alt F, Ctrl Alt B, and Ctrl Alt D in Lisp mode. These functions do what their names suggest. I've started to add support for multi-line history in command interpreter buffers (i.e. shell buffers and the like). This is necessary so Lisp shells can do history by defun or sexp, as God intended, rather than by line of text. I believe the new functionality is working correctly, but I've temporarily reset undo/redo after the shell buffer history commands shellPreviousInput (Ctrl P) and shellNextInput(Ctrl N) to work around a long-standing bug in undo/redo delete region (to wit, a blythe disregard of markers in the region in question). This shouldn't affect you at all unless you use the shell buffer history commands, and even then it should be no more than a slight inconvenience. Thanks for your support. -Peter -- "Television cameras make me look ten pounds heavier. Therefore I make a point of never eating television cameras." |
From: Peter G. <pe...@ar...> - 2002-11-26 01:42:02
|
This morning's 0.17.2+ development snapshot is up: http://armedbear.org/j.zip (source) http://armedbear.org/j-jar.zip (just j.jar) This snapshot adds a couple of new commands in Lisp mode: evalDefunLisp, mapped by default to Ctrl Alt E, and evalRegionLisp, mapped by default to Ctrl Alt R. These commands send the current defun or the current selected region (respectively) in a Lisp mode source buffer to the first Lisp shell j finds in its collection. (Currently, if you're running multiple Lisp shells simultaneously, there's no way to control which one gets used. I suppose I should put up a dialog and prompt the user in that situation.) The new commands are available on Unix platforms only, since they require a Lisp shell, which in turn requires jpty, which in turn is only available if you build j from source (put "jpty=yes" in your build.properties file). You can invoke a Lisp shell with Alt X, "lisp", optionally specifying the location of the Lisp executable as an argument (e.g. Alt X, "lisp /usr/bin/lisp", or Alt X, "lisp rep", if the rep executable is in your PATH). For best results, clisp should be invoked with the -I flag (Alt X, "lisp clisp -I"). If you don't specify any particular Lisp, j will use whatever lisp is in your PATH (i.e., Alt X, "lisp" is equivalent to Alt X, "lisp lisp"). The new commands have been tested on Linux with clisp, cmucl, sbcl, and rep. In addition, the C mode tagger now recognizes functions defined with the SCM_DEFINE macro, used in the guile source (it's similar to the DEFUN macro used in the emacs/xemacs/rep source, which j has recognized for a long time). Thanks for your support. -Peter |
From: Peter G. <pe...@ar...> - 2002-12-07 19:41:55
|
This morning's 0.17.2+ development snapshot is up: http://armedbear.org/j.zip (source) http://armedbear.org/j-jar.zip (just j.jar) This snapshot repairs j's support for anonymous FTP, which was broken by a recent (post-0.17.2) change. Filename completions (and the new completion list feature) should work much better now over SSH. (Completions are still not supported for FTP, although there's no fundamental reason why they couldn't be.) Thanks for your support. -Peter |
From: Peter G. <pe...@ar...> - 2002-12-29 18:30:34
|
This morning's 0.17.2+ development snapshot is up: http://armedbear.org/j.zip (source) http://armedbear.org/j-jar.zip (just j.jar) 1. The most noticeable new thing in this snapshot is that by default, the caret now blinks. You can make it stop by adding this line to ~/.j/prefs: blinkCaret = false 2. A number of bugs in the new openFile completion list code have been fixed. (One known bug remains, but you're not very likely to hit it.) For the most interesting effect, you might want to add this line to ~/.j/prefs: selectCompletion = true (It's false by default.) 3. Getting ready for j's new extension language, I've completely rewritten the Lisp mode formatter. The default list of "keywords" (which in this context is a confusing term) in LispMode.keywords now supports ANSI Common Lisp, and ANSI Common Lisp only, rather than the previous hodgepodge. After all, no one in his right mind uses j to edit Emacs Lisp... ;) There are 978 symbols in the COMMON-LISP package, but only 395 in LispMode.keywords. Some of the omissions are by design, but I'm sure there are some that should be corrected, too. Please feel free to complain if I've left out your favorite symbol. Symbols representing official Common Lisp functions (e.g. "list") are now highlighted as keywords only when they are the first element of their containing form (and only when the containing form itself isn't quoted). So, for example, "list" is highlighted in "(list 1 2 3)", but not in "(member x list)", which is as it should be. There are still some cases where things aren't quite perfect; "list" is erroneously highlighted in "(let ((list x)) ...)", for example. Work in progress... There are four new syntactic elements (quoting here from Kodiak): LispMode.color.substitution = 153 0 153 LispMode.color.punctuation = 102 102 102 LispMode.color.parenthesis = 102 102 102 LispMode.color.secondaryKeyword = 0 102 153 "substitution" is used for symbols preceded by "," or ",@" within a backquoted expression. "punctuation" is used for backquote itself, and for "," and ",@". "parenthesis" is used for parentheses. "secondaryKeyword" is used for lambda-list keywords ("@optional", "@rest", etc.) and symbols preceded by ':' (i.e. symbols in the keyword package). I've updated Kodiak, AnokhaClassic and Freefloater to support the new syntactic elements. Sensible fallbacks are in place, so you shouldn't notice anything particularly amiss if you use a different theme, but the new syntactic elements won't be highlighted in the new way. (The real point of color.parenthesis, BTW, is to let you choose a color that makes the parentheses -less- conspicuous...) Thanks for your support. -Peter |
From: Peter G. <pe...@ar...> - 2003-01-02 20:13:26
|
This morning's 0.17.2+ development snapshot is up: http://armedbear.org/j.zip (source) http://armedbear.org/j-jar.zip (just j.jar) This snapshot fixes a few bugs: 1. Since the recent change to support TIME_STYLE=[long-]iso, the syntax highlighting (among other things) in directory buffers was getting confused by lines like this, where the user and group were numbers: -rw-r--r-- 1 1003 1003 266 Dec 22 2000 foo.bar This is now fixed. 2. In plain text mode (and in Lisp shells, and maybe in a few other odd situations), hitting Enter with a selection active in the current buffer would lead to an assertion failure. (This was not a problem in most programming modes, where Enter is mapped to newlineAndIndent rather than newline.) This is now fixed. 3. In local directory buffers, trying to open a directory that you don't have permission to open now elicits an informative error message, rather than an empty listing of the unreadable directory. (You'll still get an empty listing for an unreadable remote directory, since there's no way to tell from a distance that it's going to end up being unreadable.) 4. In some situations with previous versions of j, if you tried to open a file that exists but is unreadable because you don't have permission to read it, j would get confused and ask if you wanted to create the file in question (which was almost certainly not what you wanted to do, and, in any case, not likely to work). This should no longer occur. If all goes well I'd like to release 0.18.0 early next week. I suspect there may still be some bugs in the new openFile completion list code, however, so please let me know if you notice any lingering anomalies, there or elsewhere. Thanks for your support. -Peter |
From: Peter G. <pe...@ar...> - 2003-02-04 16:57:03
|
This morning's snapshot is up (j 0.18.0.12, lisp 0.0.0.8): http://armedbear.org/j.zip (source) http://armedbear.org/j-jar.zip (just j.jar) This snapshot continues the refactoring and cleanup of the buffer initialization and mode-selection code, in particular, the methods Buffer.initialize() and Buffer.getDefaultMode(), which are still a mess, but slightly less so than before. Thanks for your support. -Peter |
From: Peter G. <pe...@ar...> - 2003-03-11 15:32:55
|
This morning's development snapshot (j 0.18.0.23, lisp 0.0.0.16) is up: http://armedbear.org/j.zip (source) http://armedbear.org/j-jar.zip (just j.jar) Starting with this snapshot, j's look and feel defaults to "Aqua" on Mac OS X, just as if you'd put this line in ~/.j/prefs: lookAndFeel = Aqua Please let me know if this causes any problems. RFC2047 encoding of the sender's name is now preserved when you reply to a mail message. This snapshot is still inching towards the 0.18.1 release, which I was hoping to get out this week, but since Java 1.4.1 for OS X was released just yesterday, it might be better to wait a few days and see if anything comes up. Lisp in this snapshot runs 6495 tests in the GCL ANSI test suite and passes 5250 of them. Actually running the test suite requires a bit of not-yet-checked-in code (to support extended LOOP), but I'm trying to get to the point where it will be possible to run the tests right out of the box (both j's box and the test suite's box, that is). It seems like that might be the milestone for a 0.0.1.0 Lisp release. (Everyone needs a goal.) Thanks for your support. -Peter |