GNU bug report logs - #12785
[octave-mod] Changed behaviour of octave-mark-block?

Previous Next

Full log

View this message in rfc822 format

From: Mark Hepburn <mark.hepburn <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 12785 <at> debbugs.gnu.org
Subject: bug#12785: [octave-mod] Changed behaviour of octave-mark-block?
Date: Wed, 5 Dec 2012 10:23:22 +1100

[Message part 1 (text/plain, inline)]

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 <at> 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/

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.