From unknown Sat Aug 09 15:16:02 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#12785 <12785@debbugs.gnu.org> To: bug#12785 <12785@debbugs.gnu.org> Subject: Status: [octave-mod] Changed behaviour of octave-mark-block? Reply-To: bug#12785 <12785@debbugs.gnu.org> Date: Sat, 09 Aug 2025 22:16:02 +0000 retitle 12785 [octave-mod] Changed behaviour of octave-mark-block? reassign 12785 emacs submitter 12785 Mark Hepburn severity 12785 important thanks From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 02 03:49:49 2012 Received: (at submit) by debbugs.gnu.org; 2 Nov 2012 07:49:49 +0000 Received: from localhost ([127.0.0.1]:44120 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TUC0i-00059j-6X for submit@debbugs.gnu.org; Fri, 02 Nov 2012 03:49:49 -0400 Received: from eggs.gnu.org ([208.118.235.92]:48732) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TUBwO-000537-NL for submit@debbugs.gnu.org; Fri, 02 Nov 2012 03:45:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TUBtg-0004qp-Gr for submit@debbugs.gnu.org; Fri, 02 Nov 2012 03:42:33 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:51749) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TUBtg-0004qi-DA for submit@debbugs.gnu.org; Fri, 02 Nov 2012 03:42:32 -0400 Received: from eggs.gnu.org ([208.118.235.92]:49503) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TUBtf-00068p-DW for bug-gnu-emacs@gnu.org; Fri, 02 Nov 2012 03:42:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TUBte-0004qU-6z for bug-gnu-emacs@gnu.org; Fri, 02 Nov 2012 03:42:31 -0400 Received: from mail-ob0-f169.google.com ([209.85.214.169]:58192) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TUBte-0004qQ-1s for bug-gnu-emacs@gnu.org; Fri, 02 Nov 2012 03:42:30 -0400 Received: by mail-ob0-f169.google.com with SMTP id va7so3715769obc.0 for ; Fri, 02 Nov 2012 00:42:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=PRz4XZBZVgKzOR6PRmfLu73nTPOayNHLg4abLpe4Ys0=; b=FC2J5XnpHUOcZ5pXr3POK7UpeStnq9tBEcv11Sy5Iz+oGxtvLuhb+hnJNnXf0dopid njhPaRzWPAKG7XisV6DLIzqQGiLkYCk1XxGJjoUicPzPij7ZXnSPXS6IQwADGOVXwrO0 Wdg6GjhLTM2BtIUUd3n2NyrpYmdldkLsBKtLalpaV6m88lZg2UtysjLRig0zz57euDmt ToNFEZQVMJPdIRh9JFTjb4xMZlgOUEL9gLDPFIy1HWKgg8pKwCc2U5ccm79nQ2SCuIoN HC+x513SnpnSkdOn+RYsAlSyLPLOHucCun37I4jaP2+QT/m09gRopHYSm/BgvT3RAwND 5MJQ== MIME-Version: 1.0 Received: by 10.60.28.42 with SMTP id y10mr674962oeg.24.1351842148927; Fri, 02 Nov 2012 00:42:28 -0700 (PDT) Received: by 10.182.98.41 with HTTP; Fri, 2 Nov 2012 00:42:28 -0700 (PDT) Date: Fri, 2 Nov 2012 18:42:28 +1100 Message-ID: Subject: [octave-mod] Changed behaviour of octave-mark-block? From: Mark Hepburn To: bug-gnu-emacs@gnu.org Content-Type: multipart/alternative; boundary=e89a8f503b8414475c04cd7e4745 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -3.4 (---) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Fri, 02 Nov 2012 03:49:47 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.4 (---) --e89a8f503b8414475c04cd7e4745 Content-Type: text/plain; charset=ISO-8859-1 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 ) --e89a8f503b8414475c04cd7e4745 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

I'm wondering if the recent moder= nisation of octave-mod with emacs24 has
introduced an error; at l= east, it appears that the behaviour of
octave-mark-block is diffe= rent.

For example, in the following trivial octave code:

for i=3D1:n, something; end;

= If octave-mark-block is invoked with the cursor anywhere inside the
'for' token, it will fail ("unbalanced parentheses")= . =A0The 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. =A0The form
(and level (null (cadr level)))
se= ems 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 fo= r
similar cursor locations? =A0(Which may be the root cause I sup= pose)

Thank you for your time,
Mark.

=
Emacs =A0: GNU Emacs 24.1.1 (x86_64-pc-linux-gnu, GTK+ Version 2= .24.12)
=A0of 2012-09-23 on batsu, modified by Debian
P= ackage: Emacs version 24.1.1

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

--e89a8f503b8414475c04cd7e4745-- From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 17 02:03:45 2012 Received: (at control) by debbugs.gnu.org; 17 Nov 2012 07:03:45 +0000 Received: from localhost ([127.0.0.1]:50119 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZcRM-00044p-0k for submit@debbugs.gnu.org; Sat, 17 Nov 2012 02:03:45 -0500 Received: from mail-da0-f44.google.com ([209.85.210.44]:61831) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZcRJ-00044h-0N for control@debbugs.gnu.org; Sat, 17 Nov 2012 02:03:41 -0500 Received: by mail-da0-f44.google.com with SMTP id h15so1408716dan.3 for ; Fri, 16 Nov 2012 23:02:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:subject:date:message-id:mime-version:content-type; bh=laUB6ZIQlcEbT98YNC6nH3h6MdLRiPZWRMcRXpZ7N7g=; b=tUFKbHdfULijvUjDGY57MYVYVTu8FhbWCQXPlsI3GqHZ375i/1B61xknXcXXlOrgC+ C1qZnPLTceHtg/FSuYja+v9lY0/egQEzkSQQG2SItM1CFpSj0jHIep5/Vzre1iD5c/Tl NJ4yI4EUmoTRfjsuHUaix9WV8h/bw9Qwup9+3Hmr1Eaib58DpTncpDF6CQK+BdcWhJFs G+RSkrTNULZjx7RD9qLtt2Nwg6yHlGza8jC2tXM4VEt74viVd6uAHFj0ih0mpTiZlSU6 vGaOeoqbX8skD+o8z/rvDot0oe92RP5+QC3JxNMyVLR88+CQqZeA0k9Ai6Ag/CG+uXo0 OY4A== Received: by 10.68.239.9 with SMTP id vo9mr22282751pbc.83.1353135769726; Fri, 16 Nov 2012 23:02:49 -0800 (PST) Received: from ulysses (cm198.gamma83.maxonline.com.sg. [202.156.83.198]) by mx.google.com with ESMTPS id c1sm2373483pav.23.2012.11.16.23.02.47 (version=SSLv3 cipher=OTHER); Fri, 16 Nov 2012 23:02:48 -0800 (PST) From: Chong Yidong To: control@debbugs.gnu.org Subject: severity 12785 important Date: Sat, 17 Nov 2012 15:02:45 +0800 Message-ID: <877gpkbtka.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) severity 12785 important thanks From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 04 17:02:29 2012 Received: (at 12785) by debbugs.gnu.org; 4 Dec 2012 22:02:29 +0000 Received: from localhost ([127.0.0.1]:53757 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tg0ZR-0005zJ-0A for submit@debbugs.gnu.org; Tue, 04 Dec 2012 17:02:29 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:41762) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tg0ZP-0005zD-RR for 12785@debbugs.gnu.org; Tue, 04 Dec 2012 17:02:28 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG6Zu09soXOY/2dsb2JhbABEtBGBCIIVAQEEAVYjBQsLNBIUGA0kiBwFugmQRAOIQppxgViDBw X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="209087431" Received: from 108-161-115-152.dsl.teksavvy.com (HELO pastel.home) ([108.161.115.152]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 04 Dec 2012 17:02:23 -0500 Received: by pastel.home (Postfix, from userid 20848) id 57EB358C73; Tue, 4 Dec 2012 17:02:22 -0500 (EST) From: Stefan Monnier To: Mark Hepburn Subject: Re: bug#12785: [octave-mod] Changed behaviour of octave-mark-block? Message-ID: References: Date: Tue, 04 Dec 2012 17:02:22 -0500 In-Reply-To: (Mark Hepburn's message of "Fri, 2 Nov 2012 18:42:28 +1100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 12785 Cc: 12785@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.8 (/) > 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 04 18:23:32 2012 Received: (at 12785) by debbugs.gnu.org; 4 Dec 2012 23:23:32 +0000 Received: from localhost ([127.0.0.1]:53805 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tg1ps-0007ov-1V for submit@debbugs.gnu.org; Tue, 04 Dec 2012 18:23:32 -0500 Received: from mail-ob0-f172.google.com ([209.85.214.172]:50358) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tg1pp-0007ok-Cx for 12785@debbugs.gnu.org; Tue, 04 Dec 2012 18:23:30 -0500 Received: by mail-ob0-f172.google.com with SMTP id za17so4251082obc.3 for <12785@debbugs.gnu.org>; Tue, 04 Dec 2012 15:23:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kAbVO4dxFjKKljsX9UQ6NRq5vp3hsPyG0ZgNN7NKVec=; b=SP3Wmq97h/G+E6hSa+pOG1b3HdS6vUzGFiLfiORsKnuXI7kxKNDFrx00ddZSEX8FZ5 +CUhyh+hZnlhwf7a/6DbhTa9MZc0j3woTcOW+qxj7tEt5WBTXTDl+RGg91GcRmtfrklw xcFTYmi2sMFjX+aEsGF6TK/2+KS0tJs7y52GACm6fjC3X4lvgIkBixkPKJK1mWE7rJp+ jyXyiHVJ2/KqGfpA8qndYuixL4gKix9qYs+VK9qCOIdJMG4WyqmBC3bDgSSoQNvhJq/R Pz44g+DhqKHOXhmnxRHi8QZbHY6sxYLEJWaQcUg4HwIDUHwNvNNn9oN6xfrIHonm5p0n UD3A== MIME-Version: 1.0 Received: by 10.182.38.69 with SMTP id e5mr9372969obk.79.1354663402558; Tue, 04 Dec 2012 15:23:22 -0800 (PST) Received: by 10.182.67.168 with HTTP; Tue, 4 Dec 2012 15:23:22 -0800 (PST) In-Reply-To: References: Date: Wed, 5 Dec 2012 10:23:22 +1100 Message-ID: Subject: Re: bug#12785: [octave-mod] Changed behaviour of octave-mark-block? From: Mark Hepburn To: Stefan Monnier Content-Type: multipart/alternative; boundary=f46d04462f0ee6562304d00f2606 X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 12785 Cc: 12785@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) --f46d04462f0ee6562304d00f2606 Content-Type: text/plain; charset=ISO-8859-1 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 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/ --f46d04462f0ee6562304d00f2606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Thanks for your reply.

Rega= rding the "end|" case, the old mode wouldn't mark the block, = and I feel that's correct behaviour. =A0In the "|for" case as= I mentioned, the old mode _did_ mark the block (not the enclosing one), bu= t 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 so= me related code -- expand-region.el -- across both versions, but that has b= een resolved via other means anyway.

Cheers, Mark.=



On 5 December 2012 09:02, Stefan Monnier <monnier@iro.umontreal.c= a> wrote:
> for i=3D1:n, something; end;

> If octave-mark-block is invoked with the cursor anywhere inside the > 'for' token, it will fail ("unbalanced parentheses")= . =A0The 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). =A0But maybe indeed it's an accidental chang= e.

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

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


=A0 =A0 =A0 =A0 Stefan



-- Where the hell is Mark:
http://blog.everythingtastesbetterwithchi= lli.com/
--f46d04462f0ee6562304d00f2606-- From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 05 00:30:56 2012 Received: (at 12785-done) by debbugs.gnu.org; 5 Dec 2012 05:30:56 +0000 Received: from localhost ([127.0.0.1]:54077 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tg7ZQ-0000lQ-IL for submit@debbugs.gnu.org; Wed, 05 Dec 2012 00:30:56 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:21085) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tg7ZO-0000lI-RK for 12785-done@debbugs.gnu.org; Wed, 05 Dec 2012 00:30:55 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAG6Zu09soXOY/2dsb2JhbABEsEiDSYEIghUBAQQBViMFCws0EhQYDSSIHAW6CZBEA4hCmnGBWIMH X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="209105691" Received: from 108-161-115-152.dsl.teksavvy.com (HELO pastel.home) ([108.161.115.152]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 05 Dec 2012 00:30:48 -0500 Received: by pastel.home (Postfix, from userid 20848) id 0F7AE58C73; Wed, 5 Dec 2012 00:30:47 -0500 (EST) From: Stefan Monnier To: Mark Hepburn Subject: Re: bug#12785: [octave-mod] Changed behaviour of octave-mark-block? Message-ID: References: Date: Wed, 05 Dec 2012 00:30:47 -0500 In-Reply-To: (Mark Hepburn's message of "Wed, 5 Dec 2012 10:23:22 +1100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 12785-done Cc: 12785-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.0 (/) > 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)) From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 05 07:05:10 2012 Received: (at 12785-done) by debbugs.gnu.org; 5 Dec 2012 12:05:10 +0000 Received: from localhost ([127.0.0.1]:54397 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TgDiu-0004Dj-HD for submit@debbugs.gnu.org; Wed, 05 Dec 2012 07:05:10 -0500 Received: from mail-ia0-f172.google.com ([209.85.210.172]:45608) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TgDis-0004Dc-1A for 12785-done@debbugs.gnu.org; Wed, 05 Dec 2012 07:05:07 -0500 Received: by mail-ia0-f172.google.com with SMTP id z13so3997951iaz.3 for <12785-done@debbugs.gnu.org>; Wed, 05 Dec 2012 04:04:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=k/+ktePB9bMGWZ2DhqP4NxqNHU25hOWFVn4ln60+J3M=; b=xS0ySEBSYrQY0D8E9h/7qGqSQGLwy1F0c6LgFg+YYtsKAX8IDO4R6K59Ccx1vp6RjG F/RuYlftlY+xSP0V5PSosaR6sq+T5ey14CFmiK4Jc6rncBYcsuuqysWcsITgnSrHXIKC 7zF9fXQ8YY5LkOTZ4eegl4CL3alTJKexHgRNT+INA7hk9pPIGmZiYXL6l0zTuYLiD3in cKFCXdBDcEutlYIyKwNHrV14RbZZSuBpbxXBmb+sZZHISmwa735MLqrLnojyBB3tOs3g GTAGo+BH8rbnrZULqgxDdCZxC2nEqKASMbWD76qyA1MD3Sed6yYgXsCOCzcbqYlLjTnI kkxw== MIME-Version: 1.0 Received: by 10.50.197.169 with SMTP id iv9mr1591519igc.32.1354709097094; Wed, 05 Dec 2012 04:04:57 -0800 (PST) Received: by 10.64.81.50 with HTTP; Wed, 5 Dec 2012 04:04:56 -0800 (PST) In-Reply-To: References: Date: Wed, 5 Dec 2012 23:04:56 +1100 Message-ID: Subject: Re: bug#12785: [octave-mod] Changed behaviour of octave-mark-block? From: Mark Hepburn To: Stefan Monnier Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 12785-done Cc: 12785-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.7 (/) Thanks. On 5 December 2012 16:30, Stefan Monnier 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/ From unknown Sat Aug 09 15:16:02 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 02 Jan 2013 12:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator