From: Chris W. <ch...@qw...> - 2005-02-13 17:38:04
|
Hi Peter and all, Since I love J as a C editor, I've started using it for Perl as well. However, I like using Perl's extended regular expression syntax, and they don't work too well in J. In case you're not familiar with this syntax, it ignores white space and commants inside regular expressions, allowing them to be laid out more neatly (and with comments to explain them), like this: m{ ^bls. # bls: \s # (\S+) # brw-rw---- }x; Matching brackets aside, the regular expression can be delimited by any single character, such as 'm|foo|' or 'mqfooq'. Both are valid expressions in Perl. J's Perl mode is generally very good, but it doesn't like these expressions. For example, the following indents correctly: if ($line !~ m{ }x) { } # indenting OK here exit 0; However, inserting any text inside the extended regexp causes the indenting to break, so I guess that J hasn't parsed the code correctly (and the syntax highlighting seems to back this up): if ($line !~ m{ foo }x) { } # this shouldn't be out here! die; Single quotes don't work much better, and the syntax highlighting makes me suspect that it's still not parsed correctly: if ($line !~ m' foo 'x) { } # this shouldn't be out here! die; It seems to work better when the regexp isn't enclosed in an if statement, and is delimited by braces: m{ foo }x or die; # this is fine But it doesn't do well with quotes as delimiters: m' foo 'x or die; # this shouldn't be out here! die; How difficult would it be to fix this? Cheers, Chris. -- _ ___ __ _ / __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | |
From: Chris W. <ch...@qw...> - 2005-02-13 20:15:49
|
Hi Peter and all, I think I've spotted another bug with the Perl mode. Open an empty Perl buffer and enter just the following text: if ($i scalar @path - 1 and $perms =~ m|^-|) { } Now position the cursor at the start of "scalar" (before the "s") and press "=". The screen shows: if ($i =~ m|alar @path - 1 and $perms =~ m|^-|) { } i.e. the text appears to have been subtly corrupted by this innocent action! Pressing backspace reverts the text to normal. Only the "=" and "!" characters have this magical effect. Others work as expected. Pressing "=" a second time reveals that the string "=~ m|" appears to have been displayed instead of the buffer contents at those character positions. If the file is saved and examined on disk, it contains the expected text: if ($i ==scalar @path - 1 and $perms =~ m|^-|) { } Also, if one copies and pastes the line (pasting outside of J), the expected text is pasted. So it would appear to be a bug in the syntax highlighting or formatting code, not affecting the underlying buffer contents. Is this the bug that it appears to be, or am I doing something stupid? J 0.21.1 (thanks!). Cheers, Chris. -- _ ___ __ _ / __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | |
From: Peter G. <pe...@ar...> - 2005-02-14 16:50:49
|
On Sun, 13 Feb 2005 at 20:15:42 +0000, Chris Wilson wrote: > Hi Peter and all, > > I think I've spotted another bug with the Perl mode. Open an empty Perl > buffer and enter just the following text: > > if ($i scalar @path - 1 and $perms =~ m|^-|) { } > > Now position the cursor at the start of "scalar" (before the "s") and > press "=". The screen shows: > > if ($i =~ m|alar @path - 1 and $perms =~ m|^-|) { } > > i.e. the text appears to have been subtly corrupted by this innocent > action! Pressing backspace reverts the text to normal. > > Only the "=" and "!" characters have this magical effect. Others work as > expected. > > Pressing "=" a second time reveals that the string "=~ m|" appears to have > been displayed instead of the buffer contents at those character > positions. If the file is saved and examined on disk, it contains the > expected text: > > if ($i ==scalar @path - 1 and $perms =~ m|^-|) { } > > Also, if one copies and pastes the line (pasting outside of J), the > expected text is pasted. So it would appear to be a bug in the syntax > highlighting or formatting code, not affecting the underlying buffer > contents. > > Is this the bug that it appears to be, or am I doing something stupid? J > 0.21.1 (thanks!). Wow. Thanks for the detailed report! Your observation that only '=' and '!' triggered the bug was an important clue. This is fixed in CVS now. Since anonymous CVS is subject to unpredictable delays, I've also included the patch below. I'll try to put up a new snapshot later today. Thanks again for your help! -Peter Index: PerlFormatter.java =================================================================== RCS file: /cvsroot/armedbear-j/j/j/src/org/armedbear/j/PerlFormatter.java,v retrieving revision 1.2 retrieving revision 1.3 diff -r1.2 -r1.3 229c229 < if (match != null) { --- > if (match != null && match.getStartIndex() == 0) { |
From: Peter G. <pe...@ar...> - 2005-02-14 17:21:24
|
On Sun, 13 Feb 2005 at 17:43:02 +0000, Chris Wilson wrote: > Hi Peter and all, > > Since I love J as a C editor, I've started using it for Perl as well. > However, I like using Perl's extended regular expression syntax, and they > don't work too well in J. > > In case you're not familiar with this syntax, it ignores white space and > commants inside regular expressions, allowing them to be laid out more > neatly (and with comments to explain them), like this: > > m{ > ^bls. # bls: > \s # > (\S+) # brw-rw---- > }x; > > Matching brackets aside, the regular expression can be delimited by any > single character, such as 'm|foo|' or 'mqfooq'. Both are valid expressions > in Perl. > > J's Perl mode is generally very good, but it doesn't like these > expressions. For example, the following indents correctly: > > if ($line !~ m{ > > }x) { > > } > > # indenting OK here > exit 0; > > However, inserting any text inside the extended regexp causes the > indenting to break, so I guess that J hasn't parsed the code correctly > (and the syntax highlighting seems to back this up): > > if ($line !~ m{ > foo > }x) { > > } > > # this shouldn't be out here! > die; > > Single quotes don't work much better, and the syntax highlighting makes me > suspect that it's still not parsed correctly: > > if ($line !~ m' > foo > 'x) { > > } > # this shouldn't be out here! > die; > > It seems to work better when the regexp isn't enclosed in an if statement, > and is delimited by braces: > > m{ > foo > }x or die; > # this is fine > > But it doesn't do well with quotes as delimiters: > > m' > foo > 'x or die; > # this shouldn't be out here! > die; > > How difficult would it be to fix this? I don't really know. There are two big problems. The first is that I don't know Perl, apart from what I've learned in trying to do indentation and syntax highlighting for Perl mode. The second is that Perl's syntax is way too flexible for j's normal way of attacking these problems. There are lots of ways to do things in Perl, which of course is one of Perl's strengths, but getting an editor to support all those ways of doing things is a big job. Someone that knows both Perl and Java well might be able to hack on getCorrectIndentation() in PerlMode.java and fix the problems you've described. The trick, of course, is to do that without breaking things that work correctly now. I feel reasonably confident about undertaking that sort of thing in Lisp mode or Java mode, since I use j to work on Lisp and Java code every day, and I'd notice any breakage right away. But I don't _ever_ work on Perl code, and my level of skill with Perl is still at the stage where a lot of perfectly reasonable code looks like line noise to me, so I'm not going to dive into this project myself. Tested patches are always welcome! -Peter |
From: Randall R. <ra...@ra...> - 2005-02-14 17:59:04
|
On Feb 14, 2005, at 12:21 PM, Peter Graves wrote: > I feel reasonably confident about undertaking that sort of thing in > Lisp mode or Java mode, since I use j to work on Lisp and Java code > every day, and I'd notice any breakage right away. Oh, well, in that case... :) One thing that's has been a bit frustrating for me is J's string-highlighting. I often have code that contains strings with literal line breaks, which break J's parenthesis flashing and indentation. For example, code like (defun whatever () (let ((string "This is a short string, but we'll pretend that's it's long enough to want to break")) ...)) will indent correctly on the line *after* the string, but the lines of string don't indent the way code would, nor do they not indent at all (which would be correct behavior for some uses, though since I mostly work with HTML and SQL I wouldn't prefer that behavior), instead taking on the indentation of the line the string was started on. The parenthesis after a string ends, when it wasn't started on that line, no longer matches up with any parenthesis outside the string, but parenthesis *inside* a multi-line string do match up with parenthesis before the string starts. Further parenthesis do correctly match if they aren't on the same line as the end of a multi-line string, and code indents correctly after the line on which it ends. I haven't sent a patch yet because I haven't been upset enough by this to figure out enough Java to fix it, as I'm not a Java programmer, so far. If you wait long enough, I will eventually fix this myself and send a patch. :) In the meantime, thank you for such a great editor! -- Randall Randall "Are you hungry? I haven't eaten since later this afternoon." -- Aaron, _Primer_ |
From: Peter G. <pe...@ar...> - 2005-02-14 20:10:29
|
On Mon, 14 Feb 2005 at 12:58:56 -0500, Randall Randall wrote: > > On Feb 14, 2005, at 12:21 PM, Peter Graves wrote: > > I feel reasonably confident about undertaking that sort of thing in > > Lisp mode or Java mode, since I use j to work on Lisp and Java code > > every day, and I'd notice any breakage right away. > > Oh, well, in that case... :) > > One thing that's has been a bit frustrating for me is J's > string-highlighting. I often have code that contains > strings with literal line breaks, which break J's parenthesis > flashing and indentation. For example, code like > > (defun whatever () > (let ((string "This is a short string, but > we'll pretend that's it's long enough to want > to break")) > ...)) > > will indent correctly on the line *after* the string, > but the lines of string don't indent the way code would, > nor do they not indent at all (which would be correct > behavior for some uses, though since I mostly work with > HTML and SQL I wouldn't prefer that behavior), instead > taking on the indentation of the line the string was > started on. The parenthesis after a string ends, when > it wasn't started on that line, no longer matches up > with any parenthesis outside the string, but parenthesis > *inside* a multi-line string do match up with parenthesis > before the string starts. Further parenthesis do correctly > match if they aren't on the same line as the end of a > multi-line string, and code indents correctly after the > line on which it ends. Yes. Parentheses within comments trigger similarly amusing behavior, too. To begin with, I'm not really sure how a quoted string should be indented. (defun whatever () (let ((string "This is a short string, but we'll pretend...")) ..)) is one possibility, but you could also make a case for: (defun whatever () (let ((string "This is a short string, but we'll pretend...")) ..)) In each case, the string will end up with an embedded newline, but with the first approach, you'll also end up with a bunch of leading whitespace on the second line; how much whitespace you get will depend on the overall indentation of the surrounding code. On the other hand, if you've got: (defun whatever () (format t "This is a short string, but ~ we'll pretend...")) ..)) the #\~ at the end of the first line of the quoted string will make FORMAT ignore the newline and the leading whitespace on the next line, so in this situation you probably do want it indented as shown. Now, in the case of strings fed directly to FORMAT where there's an unescaped #\~ before the line break, j could (in a perfect world) recognize that situation and indent the string as shown in the last example above. But what is the correct behavior in the other case? On the other hand, parenthesis matching is simply broken in the presence of multiline quoted strings or comments containing parentheses. Quoted or commented-out parentheses should clearly be ignored. > I haven't sent a patch yet because I haven't been upset > enough by this to figure out enough Java to fix it, as I'm > not a Java programmer, so far. If you wait long enough, > I will eventually fix this myself and send a patch. :) Once in a while I do a little bit of work on the indentation code in LispMode.java, but mostly I put it off, because the long-term plan is to rewrite LispMode.java in Lisp, and I'd rather work on the Lisp version myself. It would probably just take a day or two to build up the scaffolding to be able to do getCorrectIndentation() in Lisp, but I've been trying to avoid distraction from my other duties... :) > In the meantime, thank you for such a great editor! Thanks for your comments! -Peter |
From: Randall R. <ra...@ra...> - 2005-02-14 21:56:03
|
On Feb 14, 2005, at 3:10 PM, Peter Graves wrote: > Yes. > > Parentheses within comments trigger similarly amusing behavior, too. > > To begin with, I'm not really sure how a quoted string should be > indented. > > (defun whatever () > (let ((string "This is a short string, but > we'll pretend...")) > ..)) > > is one possibility, but you could also make a case for: > > (defun whatever () > (let ((string "This is a short string, but > we'll pretend...")) > ..)) Indeed, which is why I mentioned that very thing in my original message. :) > In each case, the string will end up with an embedded newline, but with > the first approach, you'll also end up with a bunch of leading > whitespace on the second line; how much whitespace you get will depend > on the overall indentation of the surrounding code. [snip] > But what is the correct behavior in the other case? Personally, I would expect that behavior to be configurable in the prefs file. I agree that there are only two reasonable choices, and no way to decide a priori between them. -- Randall Randall <ra...@ra...> Property law should use #'EQ , not #'EQUAL . |
From: Peter G. <pe...@ar...> - 2005-02-16 14:39:55
|
On Mon, 14 Feb 2005 at 16:55:58 -0500, Randall Randall wrote: > Personally, I would expect that behavior to be configurable > in the prefs file. I agree that there are only two reasonable > choices, and no way to decide a priori between them. This is fixed in 0.21.0.3, which is now available: http://armedbear.org/j.zip (source) http://armedbear.org/j-jar.zip (just j.jar) The behavior is configurable via the new preference indentStrings, which is false by default; set it to true in ~/.j/prefs if you want your strings indented: LispMode.indentStrings = true Even when indentStrings is false, subsequent lines of a multiline string are indented anyway if the previous line ends with '~', so things like (format t "pretend this is a ~ very long string") work the way you'd expect them to. I don't actually bother to check for FORMAT. I think the '~' is deterministic enough, and sometimes FORMAT isn't right there, but you're constructing a string that will eventually get fed to FORMAT... Please let me know if there are still any issues in this area, or if I've broken anything. Thanks for your help! -Peter |
From: Randall R. <ra...@ra...> - 2005-02-16 19:43:32
|
On Feb 16, 2005, at 9:39 AM, Peter Graves wrote: > On Mon, 14 Feb 2005 at 16:55:58 -0500, Randall Randall wrote: >> Personally, I would expect that behavior to be configurable >> in the prefs file. I agree that there are only two reasonable >> choices, and no way to decide a priori between them. > > This is fixed in 0.21.0.3, which is now available: [snip] > Please let me know if there are still any issues in this area, or if > I've broken anything. As far as I can tell, everything is good. I really liked J before, but this update has made it much better for my pattern of usage; thank you! -- Randall Randall <ra...@ra...> "Are you hungry? I haven't eaten since later this afternoon." -- Aaron, _Primer_ |
From: Chris W. <ch...@qw...> - 2005-02-14 22:48:04
|
Hi Peter, On Mon, 14 Feb 2005, Peter Graves wrote: > Tested patches are always welcome! OK, I will see what I can do, but that may not be much :-) Cheers, Chris. -- _ ___ __ _ / __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | |