("aoeuaoeuaoeu") ^ | point here Zajcev> In given situation if i press C-M-u (`backward-up-list') Zajcev> it gives "Unbalanced parentheses" error. For me such Zajcev> behaviour is quite surprizing, because i *see* balanced Zajcev> parentheses :) I can't reproduce in `XEmacs 21.5 (beta23) "daikon" (+Xft) [Lucid] (i686-pc-linux, Mule) of Mon Nov 7 2005 on tleepslib'. Can you reproduce with `xemacs -vanilla'? What version of S?XEmacs? -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

Zajcev Evgeny <zevlg(a)yandex.ru&gt; writes: Here is additional information: Richard Klinda wrote me in private email: | Okay, in gnus's *article buffer* it works, | I triple checked, but now as I am editing this email to you it doesn't | work in this buffer (I get "unbalanced parentheses" too). It works in | EmacsWiki documents too, doesn't work in *scratch*. Hehe, I'm sure | you'll figure this out.:) Ok, in modes where syntax for `"' is "(string quote) - C-M-u gives error, but why? Can I simple modify syntax entry for `"' to .(punctuation) in programming modes without breaking anything? Consider this picture nn("aoeui(aoeu)aoeu") ^ ^ | | (*) point here | | (**) point here For me, in modes where `"' is string quote, C-M-u should jump to open paren(after double n) in both situations (*) and (**). But if `"' is punctuation, then C-M-u should move point to open paren(after i) in (*) situation, and move point to open paren(after double nn) in (**) situation. Am i wrong and missing something? -- lg

Zajcev> Ok, in modes where syntax for `"' is "(string quote) - Zajcev> C-M-u gives error, but why? sjt> Because scanlists is a horrific hack. The problem is that sjt> basically the only way to be sure whether you're inside or sjt> outside of a string is to parse forward from the beginning of sjt> the buffer. And scan_lists (the internal function that handles all the parsing) doesn't even try. It simply assumes you've just moved on to a string delimiter from outside, and skips to the next one. So C-M-u has the following effects, where < and > denote beginning and end of buffer respectively, and ! is point: <xxxxxxx ("abcd!efgh")> ==> unbalanced parentheses # original report <"xxxxx" ("abcd!efgh")> ==> unbalanced parentheses # extra " doesn't help <"x ( x" ("abcd!efgh")> ==> <"x !( x" ("abcdefgh")> # dives into string! For now the answer has to be "don't use C-M-u inside a string." :-( Heuristics are not going to help much. <(" word ")> is obviously a list containing a single space-padded word, but there's no general heuristic to distinguish that from <(concat "func (" arg ");")>. I suspect that at some point in the distant past (cvs blame seems to say this hasn't changed in any significant respect since 21.2 at least, but of course cvs blame doesn't tell you about _deletions_), scan_lists did check that precondition. Then the code got eliminated because it's expensive and looked like a no-op. I think that the way to handle this is to always parse forward from a point known to be outside of a comment or string, and thus determine whether you are now inside a string (so you zip to the matching delimited) or outside (and resume list-oriented parsing). This can be made pretty efficient by caching known places. Note that because this kind of parsing always goes forward, you can always postpone parsing forward past where you are until you need it at no loss. Then any time a relevant text change takes place, you invalidate the cache past the point of the text change. This strategy can be refined in stages: 1. No cache---parse comments and strings from the beginning every time. 2. Cache and invalidate after point on every insertion or deletion. 3. Cache and invalidate after point on insertion or deletion of a delimiter. I need to go to sleep, but anybody who wants to look at how GNU Emacs does this would be a hero. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

Ben> dammit, why hasn't anyone written C code to properly maintain Ben> syntactic context for the entire buffer? It would be a massive pain in the ass to make it support font-lock, I should think. But simply trashing font-lock is not really an option. Also, Mule, as you know, trashes markers and things like that. Presumably the syntactic context would also be at risk. Ben> i'm also positive that this is a problem with well-known, Ben> published solutions; in fact, i wouldn't be at all surprised Ben> if there is freely available code to do this. rm -rf xemacs cvs checkout -d xemacs vim Something like that? ;-) -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

Ar an seachtú lá de mí na Nollaig, scríobh Stephen J. Turnbull: 21.4.17, (setq debug-on-error t), in a VM presentation buffer of your mail: Debugger entered--Lisp error: (error "Unbalanced parentheses") scan-lists(4765 -1 1) up-list(-1) backward-up-list(1) call-interactively(backward-up-list) 4765 is the cursor position you describe, -1 should tell scan-lists to scan backwards by one list, 1 says move before the parenthesis. scan-lists is in C, and I don’t have source code handy. -- I AM IN JAIL AND ALLOWED SEND ONLY ONE CABLE SINCE WAS ARRESTED WHILE MEASURING FIFTEEN FOOT WALL OUTSIDE PALACE AND HAVE JUST FINISHED COUNTING THIRTY EIGHT THOUSAND FIVE HUNDERED TWENTY TWO NAMES WHOS WHO IN MIDEAST.