Dear Albert, >> > (despite occasional indentation glitches with maxima-mode). >> >> What are the glitches? If you know how to fix them offhand, let me >> know, otherwise I'll give it a shot. > > Unfortunately I do not know how to fix them. Two minor problems I > noted recently with maxima-indent-style set to 'perhaps-smart: > > (1) ,---- > | split_product(expr, x) := > | block([inflag: true], > | if atom(expr) > | then > | if expr = x > | then [ 1, expr, 1, 1] > | else [ expr, 1, 1, 1] > | else ... > `---- > > is indented as > > ,---- > | split_product(expr, x) := > | block([inflag: true], > | if atom(expr) > | then > | if expr = x > | then [ 1, expr, 1, 1] > | else [ expr, 1, 1, 1] > | else ... > `---- > > , and pressing TAB on either of the last two lines elicits the message > > ,---- > | cond: Wrong type argument: integer-or-marker-p, nil > `---- That was a silly mistake on my part. maxima.el hadn't taken into account commas being list separators, for one thing. Worse, it didn't deal well (or at all) with nested if..then..elses. I've made an attempt to get it to work with nested if..then..elses now... > (2) In the following, the last line is indented according to the > semicolon in the string in the line above: > > ,---- > | arInt(expr, x) := > | block( > | assert(symbolp(x), > | "Integration variable is `", x, > | "', should be a symbol; consider BLOCK or KILL."), > | mapOver(lambda([term], arIntProd(term, x)), "+", expr)) $ > `---- > > This is probably related to maxima-find-next-nonnested-close-char, > but it probably doesn't pay to parse everything just in order to > get the indentation right. The problem was that maxima searches (used by maxima-find-next-nonnested-close-char) didn't ignore characters in strings. Here's a copy of maxima.el which (I hope) fixes these problems. (It works, at least, for the examples you gave.) I'm going to play with it some to make sure it works and doesn't introduce more problems before I commit it, though. Regards, Jay
Attached file: maxima.el.gz