GNU bug report logs - #14457
24.3; buggy forward-sexp in octave mode?

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Leo Liu <sdl.web <at> gmail.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#14457: closed (24.3; buggy forward-sexp in octave mode?)
Date: Sat, 08 Jun 2013 03:38:02 +0000

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

Your message dated Sat, 08 Jun 2013 11:36:47 +0800
with message-id <m1txl9qnn4.fsf <at> gmail.com>
and subject line Re: bug#14457: 24.3; buggy forward-sexp in octave mode?
has caused the debbugs.gnu.org bug report #14457,
regarding 24.3; buggy forward-sexp in octave mode?
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
14457: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14457
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Leo Liu <sdl.web <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3; buggy forward-sexp in octave mode?
Date: Fri, 24 May 2013 11:07:02 +0800

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

1. Open the attached file
2. Move point to end of the word 'otherwise'
3. M-: (forward-sexp -1)

Is this correct behaviour? I noticed this via
smie-highlight-matching-block-mode.

Leo

[unimplemented.m (text/plain, attachment)]

[Message part 5 (message/rfc822, inline)]

From: Leo Liu <sdl.web <at> gmail.com>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 14457-done <at> debbugs.gnu.org
Subject: Re: bug#14457: 24.3; buggy forward-sexp in octave mode?
Date: Sat, 08 Jun 2013 11:36:47 +0800

On 2013-05-25 14:59 +0800, Stefan Monnier wrote:
> Both behaviors make sense.  Note that elseif/else behaves just like
> case/otherwise: if will stop at the previous matching elseif.
>
> For indentation purpose it's better if it doesn't jump
> too far, which is why octave-mode currently behaves this way.
> The reason why it's better is:
> - faster indentation since we parse less of the buffer.
> - more local decision means that the behavior is easier to understand
>   for the user.
> - also means that it better takes into account choices of the user: if
>   the user decides to place his "case" at some other indentation, only
>   the first "case" after "switch" will disagree with the user, all the
>   other ones will simply align under the first.
>
> Ideally, this behavior would also allow to use C-M-t to transpose two
> cases, just like you can do with the usual infix operators/separators,
> but currently this doesn't work (and it can't be done with "otherwise").

I have noticed with your last change to smie, 'case' 'elseif' are now
nicely highlighted. So I agree with your points and consider this done ;)

Leo

Previous Next

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