Bug#253188: [Pkg-octave-devel] Re: Bug#253188: octave2.1: Keyword end confuses octave-mode.el

John W. Eaton "John W. Eaton" <jwe@bevo.che.wisc.edu>, 253188@bugs.debian.org
Tue, 15 Mar 2005 00:14:33 -0500


On  4-Mar-2005, Rafael Laboissiere <rafael@debian.org> wrote:

| * John W. Eaton <jwe@bevo.che.wisc.edu> [2004-06-07 15:18]:
| 
| > On  7-Jun-2004, Dirk Eddelbuettel <edd@debian.org> wrote:
| > 
| > | On Mon, Jun 07, 2004 at 03:19:10PM -0400, D. Goel wrote:
| > | > Package: octave2.1
| > | > Version: 2.1.57-2
| > | > Severity: wishlist
| > | > 
| > | > When i use a keyword end when referring to matrix entries, example,
| > | > data(2:end), octave-mode.el takes that "end" to end the block and
| > | > spoils the indentation going forward.
| > | > 
| > | > Perhaps the block-end-regexp could use [^:]end instead of end ...
| > | 
| > | Fair point. Could you possibly prepare a patch?
| > 
| > You will also need to pay attention to things like "(end" or ",end"
| > except the latter is valid in contexts other than indexing
| > expressions, so doing it right will probably require more than a
| > regexp.
| > 
| > Also, this should only be a problem with "end", since the other endXXX
| > keywords can't be confused.  That's another good reason to use the
| > more specific keywords when writing Octave code.
| 
| I am trying to clean up the bug record for the octave package in Debian and
| I am resurecting this old discussion.  I agree with John that the problem
| cannot be easily fixed with a mere regexp.  Also, I agree that people
| writing Octave code should stick to the endXXX keywords.  
| 
| Therefore, I have a concrete proposal to "fix" the problem reported here
| once and forever. The patch attached below drops "end" from the
| octave-end-keywords variable, keeping it in octave-reserved-words though.
| Furthermore, it drops "end" from the list of closing statements in
| octave-block-match-alist.
| 
| I hope this patch will be suitable upstream.

I applied your patch.

Note that Emacs also includes the code for Octave mode, so we should
probably try to stay in sync with it as well.

Thanks,

jwe