You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(14) |
Jul
(21) |
Aug
(27) |
Sep
(35) |
Oct
(10) |
Nov
(26) |
Dec
(18) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(23) |
Feb
(4) |
Mar
(9) |
Apr
(9) |
May
(61) |
Jun
(51) |
Jul
(35) |
Aug
(33) |
Sep
(11) |
Oct
(70) |
Nov
(66) |
Dec
(109) |
2004 |
Jan
(21) |
Feb
(1) |
Mar
(10) |
Apr
(12) |
May
(14) |
Jun
(46) |
Jul
(31) |
Aug
(164) |
Sep
(51) |
Oct
(36) |
Nov
(36) |
Dec
(16) |
2005 |
Jan
(41) |
Feb
(31) |
Mar
(11) |
Apr
(15) |
May
(24) |
Jun
(42) |
Jul
(16) |
Aug
(13) |
Sep
(24) |
Oct
(64) |
Nov
(20) |
Dec
(6) |
2006 |
Jan
(39) |
Feb
(13) |
Mar
(19) |
Apr
(10) |
May
(12) |
Jun
(16) |
Jul
(2) |
Aug
(13) |
Sep
(13) |
Oct
(18) |
Nov
(6) |
Dec
(6) |
2007 |
Jan
(8) |
Feb
(51) |
Mar
(28) |
Apr
(5) |
May
(37) |
Jun
(20) |
Jul
(12) |
Aug
(22) |
Sep
(8) |
Oct
(24) |
Nov
(11) |
Dec
(7) |
2008 |
Jan
(33) |
Feb
(16) |
Mar
|
Apr
|
May
(2) |
Jun
(7) |
Jul
(4) |
Aug
(89) |
Sep
(141) |
Oct
(136) |
Nov
(81) |
Dec
(143) |
2009 |
Jan
(182) |
Feb
(100) |
Mar
(119) |
Apr
(91) |
May
(112) |
Jun
(32) |
Jul
(7) |
Aug
|
Sep
(4) |
Oct
(11) |
Nov
(5) |
Dec
(3) |
2010 |
Jan
(25) |
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2013 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Peter G. <pe...@ar...> - 2002-08-03 19:41:41
|
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 features a complete rewrite of getCorrectIndentation() for Java mode and its derivatives (C, C++, PHP and JavaScript). The new indentation code is much clearer (although I still wouldn't call it particularly clear) and a bit faster (~20%, but you probably won't notice it in practice), but the main thing is, it now handles correctly a few things the old code didn't handle at all. For example: for (int i = 0; i < 10; i++) if (a) something(); else somethingElse(); goAway(); Starting with this snapshot, "goAway();" gets lined up under "for", as it should be. With prior versions of j, it was placed under "else", which was just plain wrong. In addition, the extremely useful command "expand", mapped by default to Alt Space, now works better in modes like Lisp that differ from Java in the characters considered legal in an identifier. In prior versions of j, if you typed "ev" and then hit Alt Space in an attempt to expand "eval-when-compile" in Lisp mode, you'd get "eval" as your expansion; now you'll actually get "eval-when-compile", assuming, of course, that "eval-when-compile" already appears somewhere in the vicinity of your caret (or, to be more precise, somewhere in the current buffer). 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-02 16:45:50
|
> I'm going to be putting two feature requests into SourceForge a little > later today. One will be for code templates (type in a predefined stri= ng, > hit tab and it gets expanded into templated code/whatnot). = Take a look at JavaMode.insertComment() (you can run it with Alt X, "JavaMode.insertComment"). It basically inserts an arbitrary string (the value of the preference "JavaMode.insertCommentText", or a very basic Javadoc template if that preference isn't set), which might contain a '|' character; if it does, the '|' is removed and the caret is left where the '|' was. This method could easily be refactored into the basis for a generic code template facility. (It's currently a tad broken since it doesn't even try to indent the inserted text correctly; it's a very old proof of concept that never went any further.) There's also the command insertBraces, mapped by default to Ctrl Shift [ in Java mode (and its descendants). I use that one all the time myself... Code templates are also related to the "clip library" feature, which has been requested before. The reason I've never gotten around to it is that it requires a fair amount of UI to manage the templates (and/or clips), since they'd have to be user-customizable. You could probably do it with a dialog box or two, but it needs a good design. > The > other will be for code completion (at least in JavaMode). I've ambitio= usly > started looking at what needs to happen to get code completion going as= > an extension. It will probably end up being a throw-away prototype, bu= t > that's fine :) It's an interesting problem. Yeah. It's actually related to the problem of getting global tags to work exactly right, which is a problem I work on myself from time to time (most recently last week). There's already a fair amount of infrastructure in place for this, but still not quite enough... Both of these problems are easier if you restrict yourself to Java mode (and not its descendants too). They're also easier if you're an IDE and you require the user to define a "project". -Peter |
From: Peter G. <pe...@ar...> - 2002-08-01 18:06:44
|
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 introduces three new commands in C and C++ modes, one of which (iList) is a killer. These commands were inspired by similar features by Bram Moolenaar in vim, although j's implementation is quite different internally. Since the beginning of time, j has supported the concept of an include path for C and C++ modes. The idea is, you add lines like these to ~/.j/prefs: CMode.includePath =3D ../include:\ /usr/include:\ /usr/lib/gcc-lib/i386-linux/2.95.4/include CppMode.includePath =3D /usr/include:\ /usr/lib/gcc-lib/i386-linux/2.95.4/include:\ /usr/include/g++-3 Then, when you're working on a C file (for example), you can enter "stdarg.h" in the location bar, without any path prefix at all, and j will look in the C mode include path and find the file you're looking for, which is /usr/lib/gcc-lib/i386-linux/2.95.4/include/stdarg.h. If your include path is set up correctly, you can also put your caret anywhere at all on the line: #include <stdarg.h> and use gotoFile (Ctrl Shift G) to open stdarg.h in the aforementioned location, with no actual typing whatsoever. The new commands checkPath and listIncludes help you verify that you have your include path set up correctly. The command checkPath, not mapped by default but available via executeCommand (Alt X, "checkPath"), looks at all the #include lines in the current buffer and reports which included files can't be found in your include path (or in the current directory, if the filename is enclosed in quotes rather than in angle brackets). checkPath also recursively checks all the included files that it can find, and reports which (if any) of the files included by those files can't be found. listIncludes (Alt X, "listIncludes") is similar to checkPath, but it lists all the included files, not just the ones that can't be found. iList, mapped by default to Ctrl F6 in C and C++ modes, operates on the identifier at the current location of the caret. It creates a List Occurrences output buffer showing all occurrences of the identifier in question in the current buffer AND in any included files, in the order in which they occur. So, to take an example from the Linux kernel source, suppose your C mode include path is set up as in the example above and you're looking at this line in sched.c: #define MIN_TIMESLICE ( 10 * HZ / 1000) And you wonder what "HZ" is. If you put your caret on "HZ" and hit Ctrl F6, you'll get a List Occcurrences buffer that starts like this: Pattern: "HZ" Options: case sensitive, whole words only File: /usr/src/linux-2.4.19-pre10-ac2-A4/include/linux/sched.h 4:#include <asm/param.h> /* for HZ */ File: /usr/src/linux-2.4.19-pre10-ac2-A4/include/asm-i386/param.h 4:#ifndef HZ 5:#define HZ 100 =46rom which you can see that HZ is 100, as defined on line 5 of param.h.= The nice thing about iList is that all you have to do is set up your include path correctly. Without iList, you'd have to do the equivalent of grep in each of the directories in question, and then you still wouldn't be sure, since grep might find occurrences of the search string in files that your source file doesn't actually include. And without an automated tool like ilist (or listIncludes), it's often hard to see what files a source file does include, because include files tend to include other include files: Great fleas have little fleas upon their backs to bite 'em, And little fleas have lesser fleas, and so ad infinitum. [1] The new commands have one important limitation (shared by grep): they pay no attention to #ifdefs, so some of the included files that show up in the output lists may not actually be relevant to what you're doing because they may be excluded, in your compilation environment, by #ifdefs that j ignores. For this reason, the list that j gives you is likely to be a superset of the "real" list for your compilation environment. (But it should never be a subset.) As a concrete example, if you're looking at cross-platform source, checkPath will often complain that it can't find platform-specific system headers that might be required for a platform other than yours ("os_os2_cfg.h", for example). For this reason, iList silently ignores included files that are not present in your include path. checkPath and listIncludes still need a bit of work. In particular, you can't do much with the output buffers they generate. It would make sense to map Enter to some command that jumps to the corresponding location in the relevant included file, but that's not done yet. And I'm not entirely sure about the syntax highlighting. Feedback is welcome. Thanks for your support. -Peter [1] Augustus De Morgan, A Budget of Paradoxes (1872). |
From: Peter G. <pe...@ar...> - 2002-08-01 01:40:36
|
Tonight'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 588799, which rightly complained that the "Fields" section of the sidebar tag list in Java mode didn't handle multiple field declarations on the same line correctly, as in: private int x, y = 7, z; which is in fact a slightly more pathological example than the one Mike provided in the bug report. But j now handles even this case correctly, I do believe. In other news, the command htmlBold, mapped by default to Ctrl B in HTML mode, is now slightly smarter about figuring out what you want to enclose between <b> and </b> if you don't have anything selected. (Specifically, the current "word" is now declared over when a period or comma is reached, without enclosing said period or comma in the emboldened area.) Finally, web mode no longer bothers logging a NumberFormatException when it encounters the following bizarre snippet, found on freshmeat's current front page: <th width="%"> Sigh. Thanks for your support. -Peter |
From: Peter G. <pe...@ar...> - 2002-07-30 01:44:09
|
Tonight's 0.16.0+ development snapshot is up: http://armedbear.org/j.zip (source and documentation) http://armedbear.org/j-jar.zip (just j.jar) This is a release candidate for 0.16.1, the main new feature of which is named sessions. Thanks for your support. -Peter |
From: Peter G. <pe...@ar...> - 2002-07-28 19:28:56
|
This morning's 0.16.0+ development snapshot is up: http://armedbear.org/j.zip (source and documentation) http://armedbear.org/j-jar.zip (just j.jar) By request, this snapshot adds basic support for named sessions. J has always saved information about your editing session, so that by default, when you restart j, things come back more or less as you left them: the same buffers will be open (except for remote, transient and weird buffers), and the current location in each buffer will be the same. = The commands saveSession and loadSession, new in this snapshot, add support for named sessions. saveSession saves information about the current editing session in a named session file. If no named session is active yet, you will be prompted for a name for the current session; subsequent saves will go to that session file without further prompting. = loadSession loads a named session that you have previously saved, which then becomes the active named session as far as saveSession is concerned. All currently open buffers are closed before the new session is loaded. The "Name:" textfield, in the dialog that comes up when you do loadSession or saveSession, supports both history and completion; if you hit Tab when the textfield is empty you'll cycle through all the named session files in your collection. If a named session is active, you can save the current session under a new name by using executeCommand to invoke saveSession with the new name as an argument (e.g. Alt X, "saveSession foo"). If you do this, subsequent saves will go to the new session file ("foo") by default. = When a named session is active, the session name appears in the title bar of the top-level window, enclosed in brackets. = By default, the information in a named session file is only updated when you explicitly invoke saveSession. This allows you to exercise better control over the contents of named session files. If you'd like named session information to be updated automatically, add this line to ~/.j/prefs or C:\.j\prefs: = autosaveNamedSessions =3D true You can use "-session" on the command line to start j with a specific named session: = j -session foo or = java -jar j.jar -session foo When you start j without specifying a named session on the command line, the previous session is restored, but no named session is active until you do saveSession or loadSession. In the current implementation, only the buffer list is saved in the named session file. This means that command history (among other things) is global across named sessions. It would be nice to store command history in the named session files too, but I'd like to make sure the basic functionality is solid first. The folks who requested this feature were mainly interested in the buffer list (or so they claimed). Preliminary documentation about named sessions has been added to j's help system (F1, scroll down to "Sessions" and hit Enter). Of course, if you don't care about named sessions, you can ignore all of this and j will behave exactly as it always has. If you do try out the named sessions feature, please let me know what you think of it from a usability perspective. Named sessions (rather than documentation of the tag file functionality = as originally planned) will probably be the main focus of 0.16.1, which I hope to release by mid-week. Thanks for your support. -Peter |
From: Peter G. <pe...@ar...> - 2002-07-26 17:45:02
|
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 main visible change in this snapshot is that development snapshots are now versioned, after a fashion. Starting with this snapshot, if you download j.zip, unzip it, build the source and run the resulting binary, you'll get an extra line of version information in the about box and in ~/.j/log, like this: J 0.16.0+ (built Fri Jul 26 2002 10:06:35 PDT on merlin) (built from development snapshot created Fri Jul 26 2002 10:02:26 PDT) On the other hand, if you download j-jar.zip, unzip it and run the enclosed binary, you'll just get one line of version information: J 0.16.0+ (built Fri Jul 26 2002 10:06:35 PDT on merlin) The way this works is that j compares the build timestamp and the snapshot timestamp. If they're identical, you're running the binary that came from j-jar.zip, and the "built..." string is enough to identify the snapshot unambiguously. If the build timestamp is different from the snapshot timestamp, you must have built the binary yourself, so the second line is added to identify the snapshot that the source came from. There are two cases in which there won't be a snapshot timestamp: you're either running the code from an official release, in which case the version number is all that's needed to identify it, or you're working directly from CVS, in which case there's no hope for you at all. In any case, this change should make it a bit easier (or at least theoretically possible) to track down behavior that occurs in one 0.xx.x+ snapshot but not another, without adding any recurring overhead to the snapshot release process. This snapshot also contains a bugfix or two and a lot of cleaning up of the code related to the care, feeding and ruthless exploitation of tag files. Except for improved caching there's no new functionality in that area yet, and I still haven't written doc/tags.html, but the cleaning up was a necessary preliminary step. Thanks for your support. -Peter |
From: Peter G. <pe...@ar...> - 2002-07-24 16:38:02
|
> the following code is valid Apache::ASP code (for Perl) > > <html> > <head> > <title></title> > </head> > <body> > <% > for($i = 0; $i <= 10; $i++) { > %> > <b>hello, world:<%=$i%></b><br /> > <% > } > %> > </body> > </html> OK, so HTML mode could recognize "<%" and "%>" as beginning and ending a script section (so to speak). It wouldn't be too hard to teach the indentation code to put "%>" in the same column as "<%". But you probably also want to be able to do things like this: <% for($i = 0; $i <= 10; $i++) { %> <b>hello, world:<%=$i%></b><br /> <% ++i; } %> where the "++i;" line should be indented based on the Perl context, which was interrupted by the HTML snippet. So the braindead approach won't suffice... ;) BTW how do you know the embedded scripting is in Perl, rather than some other language? (I assume there is some tag that specifies this, but there's nothing like that in your example.) In any case, doing syntax highlighting and automatic indentation correctly in HTML mode based on the embedded Perl context is certainly possible. Unfortunately the right way to do this is to improve the currently non-existent architectural support for region-local modes (an HTML- mode buffer that has one or more Perl-mode regions, for example). The way HTML mode currently supports embedded JavaScript is not a good foundation for additional functionality. I've had region-local modes on my list for a while; they'd also be useful for Javadoc comments in Java source, for example, and HTML embedded in PHP. But this feature needs a design, and it's probably not a small task. Food for thought. -Peter |
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-07-22 14:35:28
|
> The new j script (j-0.16.0) that gets placed in /usr/local/bin > sets the classpath to the original src directory > (~/j-0.16.0/src) in order to be able to find all of the > "*.keywords" files, althought the SOP for installing is to delete > the src directory once installed. Couldn't you install (copy) > the "*.keywords" files to "/usr/local/share" or ~/.j/ or > something? Actually the script prepends the src directory to the classpath, so it (the src directory) comes right before j.jar. Historically, the reason for this is not the .keywords files, but rather to help folks like me who are working on j itself. The idea is that if you make a change to j's source and recompile it, your changed classes (in the source tree) will be picked up ahead of what's in /usr/local/share/j/j.jar, so you don't have to make a new jar and install it to test every small change. It's worked this way for years, way longer than the .keywords files have been around. What you're actually pointing out is a bug in the old make-based build system, which I've neglected in recent months. If you use the newer ant-based build system, you should be able to delete the src directory after j is installed and things should work just fine, but I never updated the make-based system to include the .keywords files in j.jar. I'll fix that later today. Sorry for the inconvenience. > As for slight improvements, when using the F9 key to compile > (or Ctrl-F9 to recompile), the compile buffer is not cleared > and still shows the result of the last compile, which, if it was > successful, is simply the compile time with a success > message. The problem is that unless or until the compile time > changes, there is no way of knowing whether the NEW > compile has been completed. Might I suggest simply deleting > the previous buffer when F9 is called? I see what you mean. The compile buffer is in fact cleared, but I'm not doing anything in particular to force it to repaint after it has been cleared, so you don't see that it has been cleared until the new compilation process emits a line of output. And apparently your normal compilation process keeps a low profile... ;) I'll fix that later today too. I think forcing a repaint after clearing the buffer should be enough, and it's cheaper and simpler than deleting and recreating the compilation buffer. > And last, small, nit-picking little thing in an otherwise fabulous > piece of work: Is there any way to add ("&&" on unix, for > example) a way of detecting a successful compile and > immediately launching the compliled app (eg. java -cp here > -- where here is foo.java / foo.class / foo (using substring to > get to class name from foo.class?) Well, as things stand, with F9 you can do something like: make && ls -l *.java and you'll get the output of "ls -l *.java" appended to the compilation buffer after the output of make (if make is successful). But it won't work with an interactive app (instead of something like ls), for a couple of reasons. The main one is that Java doesn't provide a controlling terminal, so if j launches a command-line app that prompts for input, the prompt appears in the xterm from which j was launched, which is odd at best and often disastrous. This problem is hard to get around in pure Java (actually it's impossible to get around in pure Java, as far as I know), which is why j uses jpty for things like shell buffers. But jpty isn't part of j's binary distribution, since it's not platform- independent, and there's also the issue of Windows, where jpty requires Cygwin and things get messy fast. A second problem (which could probably be fixed) is that the way a compilation buffer works is that it invokes /bin/sh with the compilation command you've entered, then it stays around, waiting for output from the compilation process, until the compilation process terminates. So it's a bit weird to do make && java -cp here if "java -cp here" launches, say, a Swing app, since you don't get the "compilation finished" message until the app in question eventually exits. But it does work, after a fashion (well, the "here" part doesn't work, but you can use an explicit classpath). Maybe this second problem could be fixed by introducing the concept of a "completion command" in addition to the current "compilation command"; if the compilation command succeeds, j then runs the completion command. But there's still the question of where the completion command's output goes, if there is any, if the compilation buffer is free to leave. Bottom line, I probably won't do anything about this in the near future, since I don't have a robust, platform-independent solution to the controlling terminal problem. Maybe the open source pure Java IDE guys have figured out all of these issues and I could study their code, but it seems like doing it right would be a pretty big project, and I don't want to do it wrong. Thanks for your comments! -Peter |
From: Peter G. <pe...@ar...> - 2002-07-19 19:59:52
|
New snapshot: http://armedbear.org/j.zip (source) http://armedbear.org/j-jar.zip (just j.jar) One of the projects for the next official release is to write the user documentation for the family of tag-related commands (F1, scroll down to "Tags and Tag Files", hit Enter, and you'll see it ain't there yet). J's support for tags in various modes has always been one of my favorite features, and it's long overdue for documentation. Before actually writing the documentation, I'm making a pass through the relevant code to clean it up and make things work a bit better. Starting with this snapshot, the tags code uses a smart output buffer (similar to a List Occurrences buffer) instead of a dialog box to let the user resolve ambiguities. This change applies most conspicuously to the completely undocumented command listMatchingTags. listMatchingTags, which is not mapped by default but available via Alt X, prompts for a string and then displays a list of the tags in the current directory (and mode) that match the string you enter. Sticking to Java for the moment, a tag is usually a method name. So if you're looking at j's source (for example), and you're in the src/org/armedbear/j subdirectory, and you do listMatchingTags and enter "save" at the "Tag:" prompt, you'll get a split window with a List Tags output buffer that will show you all the methods called "save" in the .java files in src/org/armedbear/j (there were twelve such methods at last count). The List Tags output buffer is, as mentioned, similar to a List Occurrences output buffer. You can use the cursor keys to scroll around, and if you hit Enter on the line corresponding to the method you're interested in, you'll go directly to its source in the other window. Keyboard focus stays in the List Tags buffer, but you can always hit Escape to make the List Tags buffer go away. There are two additional features in List Tags mode (as opposed to List Occurrences mode): The up and down cursor keys are mapped to tagUp and tagDown, respectively, so navigation using the up and down cursor keys always lands on interesting lines. Ctrl Enter (as opposed to Just Plain Enter) is mapped by default to jumpToTagAndKillList, which does what its name suggests; to wit, you'll go directly to the source of the method in question and the List Tags buffer will go away, leaving the edit window unsplit. You can use Ctrl Enter if you're sure you've found the tag you want in the list; if you're not sure, you can use Enter, possibly more than once, to audition the candidates, followed by Escape when you've found what you're looking for. (If these features are well received, at some point they will be backported to List Occurrences mode too.) You also get a List Tags buffer if you do findTag (Ctrl T) or findTagAtDot (Alt .) and j finds more than one tag that matches the specific or implied criteria of the search. For findTag and findTagAtDot, j first looks for a match in the current buffer; if there is at least one match, j looks no further. You can force j to do a global search (where global means the current directory) by doing listMatchingTags (discussed above) or listMatchingTagsAtDot (Alt ,), which looks for the string at the current location of the caret. In Java mode (only), findTagAtDot tries to be smart; if your caret is not exactly on a word that could plausibly be a method name, j will look for the nearest plausible method name on the current line and use that. (Currently, listMatchingTagsAtDot does not try to be smart, but if all goes well that will change as part of the current work.) As mentioned yesterday: You should delete all the files in your ~/.j/tagfiles (or C:\.j\tagfiles) subdirectory before using this snapshot. (There should be a file called "catalog" and some other files with 12- or 13- digit numbers as their filenames.) The tag file format has changed, and the new tag code won't work with the old files. The new code will regenerate the tag files in the new format as they are needed, but only if you delete the old ones first. Part of the current work will be to add versioning to the tag files so this will not be a problem in the future. In other news, the highlightBrackets and highlightMatchingBracket preferences are now mode-specific (actually they're buffer-specific, but that's a whole nother issue). This change was made so that these preferences can be off by default in modes where highlighting brackets doesn't really make sense, even if you've turned one or both of them on globally. I just got tired of seeing parentheses highlighted when I was reading Slashdot... ;) In the current snapshot I've fixed Web mode and List Tags mode, but there are other modes that still need fixing in this respect. If, on the other hand, you really like to see parentheses highlighted when you're reading Slashdot, you can set a Web-mode-specific preference which will override the Web-mode-specific default: WebMode.highlightBrackets = true Of course, to make any of this work you also need: enableWeb = true Thanks for your support. -Peter |
From: Peter G. <pe...@ar...> - 2002-07-18 18:43:05
|
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) This snapshot fixes (let's hope) the focus problem with Java 1.4.1 on Linux. With previous versions of j, focus would frequently (but not always) go astray after you dismissed a dialog box. For some reason, when a dialog box goes away, under some circumstances (but not always) focus is not returned to the Display object (which had it before and which wants it again), but instead given to the EditorFrame object (which doesn't want it at all). The fix is to install a focus listener on the EditorFrame and set focus to the Display object in focusGained(). Simple enough, and it seems to work correctly in the cases I've tested (but since the problem is intermittent, you never know). To the best of my knowledge, this problem only ever occurred with Java 1.4.1-beta on Linux. If the fix holds, 1.4.1-beta will move into the undisputed top slot for Java VMs on Linux, since it fixes at least a couple of bugs that are in both 1.4.0 and 1.4.0_01. In other news, you should delete all the files in your ~/.j/tagfiles (or C:\.j\tagfiles) subdirectory before using this release. (There should be a file called "catalog" and some other files with 12- or 13- digit numbers as their filenames.) The tag file format has changed in this snapshot, and the new tag code won't work with the old files. The new code will regenerate the tag files in the new format as they are needed, but only if you delete the old ones first. Thanks for your support. -Peter |
From: Peter G. <pe...@ar...> - 2002-07-18 15:13:55
|
> Hey Peter, > > I was looking through the code, and I came across an oddity > that very much seems like a bug: > > line 385-6 of KeyMap.java reads > if (keyChar == mapping.getKeyChar() && > keyCode == 0 && modifiers == 0) Good catch! No need to test keyCode == 0 && modifiers == 0 here, since we've tested the exact same thing in line 382. > when it seems that they should read > if (keyChar == mapping.getKeyChar() && > mapping.getKeyCode() == 0 && > mapping.getModifiers() == 0) > > to keep in line with the if condition on line 382 > if (keyCode == 0 && modifiers == 0) { But it turns out that this isn't what we want to do here, although this method is very hard to understand. It just took me half an hour to figure it out, and I wrote it... ;) First let's fix the method to remove the redundant test: public synchronized final KeyMapping lookup(char keyChar, int keyCode, int modifiers) { if (keyCode == 0 && modifiers == 0) { // Case 1. for (int i = mappings.size()-1; i >= 0; i--) { KeyMapping mapping = (KeyMapping) mappings.get(i); if (keyChar == mapping.getKeyChar()) return mapping; } } else { // Case 2. for (int i = mappings.size()-1; i >= 0; i--) { KeyMapping mapping = (KeyMapping) mappings.get(i); if (mapping.getKeyChar() == 0 && keyCode == mapping.getKeyCode() && modifiers == mapping.getModifiers()) return mapping; } } return null; } So there are two cases, Case 1 and Case 2, as marked. In case 1, the keyCode and modifiers arguments are zero. In this case, all we need to do is test the keyChar argument against the keyChar field of the mapping; we don't care about the other fields of the mapping. In case 2 , the keyCode and/or modifiers arguments are not zero. In this case, we want to test these two arguments against the corresponding fields of the mapping, but (and this is very important!) we don't want to test keyChar argument against the keyChar field of the mapping. We do require the keyChar field of the mapping to be zero, but because it's zero, it won't match the keyChar argument, which, in practice, normally won't be zero. The case 2 code path normally gets used when lookup() is called (through Editor.handleKeyEvent() and Editor.getKeyMapping()) from Dispatcher.java, line 242, the keyPressed() case. Case 2 wants mapping.getKeyChar() to be zero, because the mapping will have been constructed by the KeyMapping(int keyCode, int modifiers, String command) constructor, which explicitly sets this.keyChar to zero. The case 1 code path normally gets used when lookup() is called from Dispatcher.java, line 276, the keyTyped() case. Notice that Dispatcher.dispatchKeyTyped() passes the correct keyChar (which is what the case 1 code path tests) but explicitly passes zeros for keyCode and modifiers. That's why we don't need to test against keyCode and modifiers in case 1. > But, something that would make this bug irrelevant > is if you added the following function to > KeyMapping.java and rewrote KeyMap.lookup to take > advantage of it. > > /** > * Checks to see if the given key combo matches up with the > * key combo that this maps to a command. > * > * @param keyChar The key's character representation > * @param keyCode They key's integer representation > * @param modifiers Any modifiers that were pressed while the > * key was typed. > * @return Whether or not the given parameters match their > * equivalents in this. > */ > public final boolean equalsKey(char keyChar, int keyCode, int modifiers) { > return this.keyChar == keyChar && > this.keyCode == keyCode && > this.modifiers == modifiers; > } > > The modified KeyMap.lookup: > > public synchronized final KeyMapping lookup(char keyChar, int keyCode, > int modifiers) { > > for (int i = mappings.size()-1; i >= 0; i--) { > KeyMapping mapping = (KeyMapping)mappings.get(i); > if (mapping.equalsKey(keyChar, keyCode, modifiers)) { > return mapping; > } > } > > return null; > } Except this doesn't actually work, because in the case 2 code path, i.e. the keyPressed() case, equalsKey() wants the keyChar to match, when in fact we should ignore it. So maybe you could rewrite equalsKey() like this: public final boolean equalsKey(char keyChar, int keyCode, int modifiers) { if (keyCode == 0 && modifiers == 0) { if (keyChar == this.keyChar) return true; else return false; } else { if (this.keyChar == 0 && keyCode == this.keyCode && modifiers == this.modifiers) return true; else return false; } } Which would probably work (I haven't tested it, and I might well have made a silly mistake in the code, but you get the general idea). The only problem with this approach is that we do the "if (keyCode == 0 && modifiers ==0)" test for every mapping we consider; the lookup() function does the test once, outside the loop, which is (in theory, at least) faster. This is very old code, and my hardware when I wrote it wasn't very fast, and there was no HotSpot, so I was looking for every cycle (although obviously I didn't do a very good job, since I didn't catch the completely redundant test you found in case 1). > Hope this helps. I came across this because I was trying to write > the comment for Mode.getKeyMap() :) Yeah, it helps. I've removed the redundant test and added a couple of comments, in case there's a next time... ;) The patch is below. Thanks! -Peter ---- cut here ---- Index: KeyMap.java =================================================================== RCS file: /usr/local/cvsroot/j/src/org/armedbear/j/KeyMap.java,v retrieving revision 1.104 diff -u -r1.104 KeyMap.java --- KeyMap.java 22 Jun 2002 23:34:00 -0000 1.104 +++ KeyMap.java 18 Jul 2002 15:06:33 -0000 @@ -380,14 +380,18 @@ int modifiers) { if (keyCode == 0 && modifiers == 0) { + // This is the keyTyped() case. Ignore keyCode and modifiers; + // keyChar must match the mapping. for (int i = mappings.size()-1; i >= 0; i--) { KeyMapping mapping = (KeyMapping) mappings.get(i); - if (keyChar == mapping.getKeyChar() && - keyCode == 0 && modifiers == 0) + if (keyChar == mapping.getKeyChar()) return mapping; } } else { for (int i = mappings.size()-1; i >= 0; i--) { + // This is the keyPressed() case. keyCode and modifiers must + // match the mapping. mapping.getKeyChar() must be zero, but + // we ignore the keyChar argument. KeyMapping mapping = (KeyMapping) mappings.get(i); if (mapping.getKeyChar() == 0 && keyCode == mapping.getKeyCode() && |
From: Peter G. <pe...@ar...> - 2002-07-17 18:17:37
|
Bug 582929: I can't seem to get \n to behave the way I expect it to. When using \n as replacement text, j leaves replaces the matched text with "n". It also will not match "\n". = You're right; this doesn't work right out of the box. You need to enable experimental features by adding this line to ~/.j/prefs (or C:\.j\prefs): enableExperimentalFeatures =3D true Then you should get a "Multiline pattern (experimental)" checkbox in the Find and Replace dialogs. If you check this box (you have to check the "Regular expression" checkbox too), things should work as you expect. This feature should graduate from experimental status soon. Thanks for your support. -Peter |
From: Peter G. <pe...@ar...> - 2002-07-17 18:09:45
|
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) This snapshot fixes bug 582862, involving HTML mode: Keywords for JavaScript embedded in SCRIPT tags are not syntax highlighted anymore. I supect this is a result of the new custom keywords feature. = Yes indeed. Now fixed. Thanks for your support. -Peter |
From: Peter G. <pe...@ar...> - 2002-07-15 23:39:38
|
> >>I tried to add a keywords file for Shell-Scripts > >>without success. > > = > > What did you do exactly? > > I just added a file called 'ShellScriptMode.keywords' > into the source directory (src/org/armedbear/j) > > Then I ran 'ant all' and 'ant install' Well, in theory that should work, but it seems I forgot to convert ShellScriptMode.java to the new keyword design... This unfortunate omission is corrected in the very first 0.16.0+ development snapshot, now up: http://armedbear.org/j.zip (source) http://armedbear.org/j-jar.zip (just j.jar) Sorry for the inconvenience. -Peter |
From: Peter G. <pe...@ar...> - 2002-07-15 02:16:23
|
> ok. there is a problem with automatic indentation: > > class Test > > def initialize(test) > end > > def bla() > end = > <=3D=3D=3D = > I can't get this line to be in sync with the 'def bla()' > end This is fixed now. I've posted a new snapshot: http://armedbear.org/j.zip (source) http://armedbear.org/j-jar.zip (just j.jar) Thanks for pointing out this bug! Take care. -Peter |
From: Peter G. <pe...@ar...> - 2002-07-14 19:45:35
|
This morning's 0.15.3+ development snapshot is up: http://armedbear.org/j.zip (source) http://armedbear.org/j-jar.zip (just j.jar) This code is a release candidate for 0.16.0, which will be out in the next day or two if all goes well, which means you're running out of chances to report bugs against 0.15.3+. ;) The current snapshot makes a lot of improvements in Ruby mode, which is gradually shaking off its Python mode roots and getting some code of its own. Block comments delimited by "=begin" and "=end" get the right syntax highlighting now, regular expressions delimited by slashes are recognized correctly, and recognition of here documents is more precise. Automatic indentation (with the Tab key) works correctly for the most part (about 99% of the time on the source I've tested against, but that's mostly because I've tested against it). Ruby mode is another mode that I don't use in real life, so please let me know what's broken; I'll never notice otherwise. Code samples that illustrate the problem are worth 1000 words, maybe more. In web mode, the commands webBack, mapped by default to 'b', and webForward, mapped by default to 'f', work correctly again; history in web mode was broken temporarily by some recent changes. J's rendering of newlines in preformatted text is also much better now (you'd think that would be easy). Menu mnemonics work correctly now with Java 1.4.1-beta. Finally, the Java debugger classes have been moved from org.armedbear.j.debug to org.armedbear.j.jdb, where they should have been all along. Thanks for your support. -Peter |
From: Peter G. <pe...@ar...> - 2002-07-13 14:51:43
|
This morning's 0.15.3+ development snapshot is up: http://armedbear.org/j.zip (source) http://armedbear.org/j-jar.zip (just j.jar) This snapshot adds syntax highlighting support for here documents in Ruby mode, and removes support for triple-quoted strings (an artifact of Ruby mode's Python mode ancestry) since triple-quoted strings aren't legal in Ruby. This snapshot also fixes indentation in PHP mode in the presence of multi-line quoted strings (Samo's example). Files that start with "<?" followed by whitespace (as opposed to "<?xml", for example) now default to PHP mode, like files that start with "<?php". Finally, j now auto-indents the following code correctly in C mode (similar code should also be handled correctly in the other C-like modes): int main() { int i = 10; if (i) while (i) { printf("i=%d\n",i--); } return 0; } Thanks for your support. -Peter |
From: Peter G. <pe...@ar...> - 2002-07-12 19:16:27
|
This morning's 0.15.3+ development snapshot is up: http://armedbear.org/j.zip (source) http://armedbear.org/j-jar.zip (just j.jar) In prior versions, j was re-using a bunch of Java mode code for PHP mode, and as a result, didn't handle multi-line quoted strings correctly in PHP mode. This problem affected findMatchingChar, and it became a lot more conspicuous when you set highlightBrackets = true. Starting with this snapshot, PHP mode has its own syntax iterator, which should handle multi-line quoted strings much better. Samo's example now works correctly, at least as far as bracket highlighting is concerned. I haven't looked at indentation specifically, although it should benefit from the new syntax iterator too. Please let me know what I'm missing; I don't actually write PHP code myself, so I don't get any incidental opportunities to test PHP mode. J now recognizes automatically that files that start with "<?php" should be opened in PHP mode, regardless of their filename. In Lisp and Scheme modes, there was a very weird formatting problem if j encountered '#' not followed or preceded by '|' ("#|" being Lisp's answer to "/*"). This bug is now fixed. If you add a line to ~/.j/prefs to use custom keywords for a particular mode, it is now no longer necessary to restart j to pick up the new keywords. J does not, however, automatically detect the change if you modify the keywords file itself; until I get around to implementing a fileSaved event, the workaround is to make some meaningless change to ~/.j/prefs (e.g. space, backspace) and save it, which forces j to reset the keywords in all the active modes. Thanks for your support. -Peter |
From: Peter G. <pe...@ar...> - 2002-07-11 18:24:33
|
This morning's 0.15.3+ development snapshot is up: http://armedbear.org/j.zip (source) http://armedbear.org/j-jar.zip (just j.jar) By request, this snapshot adds support for custom keyword lists for the various modes. This feature is mainly useful for languages like Lisp and Scheme that have a variety of dialects, where you might want to use a custom keyword list that contains the keywords of the particular dialect you're using. To use a custom keyword list, first prepare the list itself. It should be an ordinary text file with one keyword per line. For an example of the format, take a look at src/org/armedbear/j/JavaMode.keywords (there is such a file for each mode, containing the default keyword list for that mode). After you have prepared your custom keyword list, add a line like this to ~/.j/prefs, pointing to the file you want to use: LispMode.keywords = /home/peter/lispkeywords With the current snapshot, it's necessary in most cases to restart j to pick up the new keywords. (Restarting might not be necessary if the mode in question has not yet been used in the current session.) In the near future I'll try to fix things so that restarting is not required. Internally, the foundation is in place for file-specific keyword lists, so (in theory, at least) you could have several files open at once using different versions of Lisp and use a different keyword set for each file. But this part of the feature isn't implemented yet, since it also depends on some changes that still need to be made in j's properties architecture, together with a completely different UI for the Properties dialog (Alt P) and support for embedding file- specific preferences as comments in the files themselves. BTW if you're using Lisp and/or Scheme you might want to try one of the new parenthesis-highlighting preferences: highlightMatchingBracket = true or my personal favorite: highlightBrackets = true The names of these preferences refer to "brackets", but they apply to parentheses and braces too; "highlightMatchingBraceBracketOrParenthesis" was just too long, even for me. Thanks for your support. -Peter |
From: Peter G. <pe...@ar...> - 2002-07-10 14:34:51
|
A new 0.15.3+ development snapshot is up: http://armedbear.org/j.zip (source) http://armedbear.org/j-jar.zip (just j.jar) > One more note on the feature. Would it be possible to have J > highlight both the matching and the matcher? I think that it > would make it a more complete visual cue. This is done. There are now two different preferences you can set: highlightMatchingBracket = true highlightBrackets = true If highlightBrackets is true, both the beginning and end character of the matching pair are highlighted. If highlightMatchingBracket is true and highlightBrackets is false, the matching character (only) is highlighted. If both highlightBrackets and highlightMatchingBracket are true, both characters are highlighted, as you'd expect. I think maybe we could lose the highlightMatchingBracket preference, since I agree with Mike that highlightBrackets = true provides a better visual cue, but since it's there and working I left it in. Both preferences are false by default, so by default there is no bracket matching at all (except for. Finally, I've updated color.matchingBracketBackground for the officially supported themes (Kodiak, AnokhaClassic, Dark and Freefloater) so that at least the bracket highlight is visible. In general, I've just re-used color.selectionBackground, which seems to work OK except for Dark (which gets red for now). Feel free to send me updates with better colors for the themes you maintain. Thanks. -Peter |
From: Peter G. <pe...@ar...> - 2002-07-04 15:16:33
|
This morning's 0.15.3+ development snapshot is up: http://armedbear.org/j.zip (source) http://amredbear.org/j-jar.zip (just j.jar) This snapshot introduces Ruby mode, written by Jens Luedicke, for all your .rb files. -Peter |
From: Peter G. <pe...@ar...> - 2002-07-04 03:00:40
|
Tonight's 0.15.3+ development snapshot is up: http://armedbear.org/j.zip (source) http://armedbear.org/j-jar.zip (just j.jar) In response to Feature Request 577186, you can now set things up so that, when your caret is on (or just past) a brace, bracket, or parenthesis, j will highlight the matching brace, bracket, or parenthesis (if possible). To enable this feature, add this line to ~/.j/prefs: highlightMatchingBracket = true And you may need to add a line like this to your theme (or ~/.j/prefs): color.matchingBracketBackground = 255 204 102 I've added a reasonable matching bracket background color to Kodiak and to j's default built-in theme (which are basically one and the same). I didn't do exactly what Mike suggested, and the other editors I looked at are all over the map when it comes to implementing this feature. J's current implementation allows you to specify a single background color which is used for brackets, braces and parentheses. Mike suggested color.braceMatch, color.bracketMatch, and color.parenMatch, which I assume are meant to be foreground rather than background colors. You could do it that way, but I think having a uniform way of highlighting the other end of the current scope (so to speak) presents a more useful visual cue than having different colors for the different characters. (Besides, it's hard enough to come up with one color that fits in a theme, let alone three.) And doing the foreground colors would make the implementation more complicated, so I'd like to see how folks like the background color approach first. If, after a while, there's some sort of consensus that we need to do the foreground colors, so be it. For what it's worth, most other editors use the background color approach; the only notable exception is jEdit, which draws a rectangle around the matching character. The other issue is just how to do the matching. As I've been reviled for doing on other occasions, I'm slavishly emulating xemacs here. (After all, highlighting matching parentheses is REALLY important to Lisp guys.) When the vertical bar caret is before (i.e. to the left of) an opening bracket (for example), j highlights the corresponding closing bracket. When the vertical bar caret is after (to the right of) the closing bracket, j highlights the corresponding opening bracket. The best argument I can find for this somewhat inconsistent approach is that if you're just typing along, when you type ')', for example, the act of typing the ')' will leave the corresponding '(' highlighted, so you can see at a glance what opening parenthesis you've just closed. Both xemacs and nedit take this approach with closing parentheses; nedit, to be consistent, also requires the caret to be after the opening parenthesis before it will highlight its match. jEdit tries to be permissive, which I normally like, but in this case I think being permissive gets confusing when you've got a lot of parentheses close together: if (find(getChar())) or some such. So j is not permissive and tries to work like xemacs. I'm open to your complaints. In the meantime I'm going to change the status of this Feature Request from "Open" to "Pending"; I'll close it when it becomes clear that everything is working correctly. Thanks for your support. -Peter |