unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#12785: [octave-mod] Changed behaviour of octave-mark-block?
@ 2012-11-02  7:42 Mark Hepburn
  2012-12-04 22:02 ` Stefan Monnier
  0 siblings, 1 reply; 5+ messages in thread
From: Mark Hepburn @ 2012-11-02  7:42 UTC (permalink / raw)
  To: 12785

[-- Attachment #1: Type: text/plain, Size: 1302 bytes --]

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
 )

[-- Attachment #2: Type: text/html, Size: 1832 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#12785: [octave-mod] Changed behaviour of octave-mark-block?
  2012-11-02  7:42 bug#12785: [octave-mod] Changed behaviour of octave-mark-block? Mark Hepburn
@ 2012-12-04 22:02 ` Stefan Monnier
  2012-12-04 23:23   ` Mark Hepburn
  0 siblings, 1 reply; 5+ messages in thread
From: Stefan Monnier @ 2012-12-04 22:02 UTC (permalink / raw)
  To: Mark Hepburn; +Cc: 12785

> 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.

For the "|for" case I think the behavior makes sense (it will try to
mark the enclosing block).  But maybe indeed it's an accidental change.

For the "f|or" and "fo|r" cases, indeed the smie primitives assume the
cursor is not within a token, so they get all confused.  Shouldn't be
too hard to fix.

What should be the behavior when point is at "end|"?  Should it mark
this block or the enclosing one?


        Stefan





^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#12785: [octave-mod] Changed behaviour of octave-mark-block?
  2012-12-04 22:02 ` Stefan Monnier
@ 2012-12-04 23:23   ` Mark Hepburn
  2012-12-05  5:30     ` Stefan Monnier
  0 siblings, 1 reply; 5+ messages in thread
From: Mark Hepburn @ 2012-12-04 23:23 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 12785

[-- Attachment #1: Type: text/plain, Size: 1383 bytes --]

Hi,

Thanks for your reply.

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.

In my case I was trying to get the same behaviour in some related code --
expand-region.el -- across both versions, but that has been resolved via
other means anyway.

Cheers, Mark.



On 5 December 2012 09:02, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> > 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.
>
> For the "|for" case I think the behavior makes sense (it will try to
> mark the enclosing block).  But maybe indeed it's an accidental change.
>
> For the "f|or" and "fo|r" cases, indeed the smie primitives assume the
> cursor is not within a token, so they get all confused.  Shouldn't be
> too hard to fix.
>
> What should be the behavior when point is at "end|"?  Should it mark
> this block or the enclosing one?
>
>
>         Stefan
>



-- 
Where the hell is Mark:
http://blog.everythingtastesbetterwithchilli.com/

[-- Attachment #2: Type: text/html, Size: 2128 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#12785: [octave-mod] Changed behaviour of octave-mark-block?
  2012-12-04 23:23   ` Mark Hepburn
@ 2012-12-05  5:30     ` Stefan Monnier
  2012-12-05 12:04       ` Mark Hepburn
  0 siblings, 1 reply; 5+ messages in thread
From: Stefan Monnier @ 2012-12-05  5:30 UTC (permalink / raw)
  To: Mark Hepburn; +Cc: 12785-done

> 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))
 






^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#12785: [octave-mod] Changed behaviour of octave-mark-block?
  2012-12-05  5:30     ` Stefan Monnier
@ 2012-12-05 12:04       ` Mark Hepburn
  0 siblings, 0 replies; 5+ messages in thread
From: Mark Hepburn @ 2012-12-05 12:04 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 12785-done

Thanks.

On 5 December 2012 16:30, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> 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))
>
>



-- 
Where the hell is Mark:
http://blog.everythingtastesbetterwithchilli.com/





^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2012-12-05 12:04 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-11-02  7:42 bug#12785: [octave-mod] Changed behaviour of octave-mark-block? Mark Hepburn
2012-12-04 22:02 ` Stefan Monnier
2012-12-04 23:23   ` Mark Hepburn
2012-12-05  5:30     ` Stefan Monnier
2012-12-05 12:04       ` Mark Hepburn

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).