emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#12785: closed ([octave-mod] Changed behaviour of o


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#12785: closed ([octave-mod] Changed behaviour of octave-mark-block?)
Date: Wed, 05 Dec 2012 05:31:02 +0000

Your message dated Wed, 05 Dec 2012 00:30:47 -0500
with message-id <address@hidden>
and subject line Re: bug#12785: [octave-mod] Changed behaviour of 
octave-mark-block?
has caused the debbugs.gnu.org bug report #12785,
regarding [octave-mod] Changed behaviour of octave-mark-block?
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
12785: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12785
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: [octave-mod] Changed behaviour of octave-mark-block? Date: Fri, 2 Nov 2012 18:42:28 +1100
Hi all,

I'm wondering if the recent modernisation of octave-mod with emacs24 has
introduced an error; at least, it appears that the behaviour of
octave-mark-block is different.

For example, in the following trivial octave code:

for i=1:n, something; end;

If octave-mark-block is invoked with the cursor anywhere inside the
'for' token, it will fail ("unbalanced parentheses").  The following
situations all fail in the recent version, but succeed in the older
version: |for, f|or, fo|r.

Assuming this is in error I'm not sure how to fix it, I'm sorry.  The form
(and level (null (cadr level)))
seems a bit suspicious as there are no null entries in smie-grammar for
me, so that would be equivalent to just level.

It also looks like backward-up-list (-> up-list) might be incorrect for
similar cursor locations?  (Which may be the root cause I suppose)

Thank you for your time,
Mark.

Emacs  : GNU Emacs 24.1.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.12)
 of 2012-09-23 on batsu, modified by Debian
Package: Emacs version 24.1.1

current state:
==============
(setq
 octave-blink-matching-block t
 octave-block-offset 2
 octave-comment-char 35
 octave-continuation-offset 4
 octave-continuation-string "\\"
 octave-send-echo-input t
 octave-send-line-auto-forward t
 octave-send-show-buffer t
 )


--- End Message ---
--- Begin Message --- Subject: Re: bug#12785: [octave-mod] Changed behaviour of octave-mark-block? Date: Wed, 05 Dec 2012 00:30:47 -0500 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)
> Regarding the "end|" case, the old mode wouldn't mark the block, and I feel
> that's correct behaviour.  In the "|for" case as I mentioned, the old mode
> _did_ mark the block (not the enclosing one), but I agree that marking the
> enclosing block is probably preferable and more consistent.

Indeed, the code tried to reproduce this "mark the block after point
instead of the enclosing one" but had a bug in it.
I've fixed the "starting within a token" problem as well as the above
check (so the inner `for' will be marked if you're right in front of it).


        Stefan


=== modified file 'lisp/progmodes/octave-mod.el'
--- lisp/progmodes/octave-mod.el        2012-09-17 05:41:04 +0000
+++ lisp/progmodes/octave-mod.el        2012-12-05 05:21:07 +0000
@@ -794,11 +794,14 @@
   "Put point at the beginning of this Octave block, mark at the end.
 The block marked is the one that contains point or follows point."
   (interactive)
+  (if (and (looking-at "\\sw\\|\\s_")
+           (looking-back "\\sw\\|\\s_" (1- (point))))
+      (skip-syntax-forward "w_"))
   (unless (or (looking-at "\\s(")
               (save-excursion
                 (let* ((token (funcall smie-forward-token-function))
                        (level (assoc token smie-grammar)))
-                  (and level (null (cadr level))))))
+                  (and level (not (numberp (cadr level)))))))
     (backward-up-list 1))
   (mark-sexp))
 



--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]