Re: 'end' odds & ends

[dsebald]

> address@hidden wrote:
>
>>>| Now, the second detail about 'end'.  The emacs lisp file doesn't
>>>| recognize 'end' except as the end of a conditional or loop.
>>> Therefore,
>>>| it claims a mismatch and loses track of indentation.  (I know zilch
>>>| about Lisp.)  Anyone familiar with Lisp know if this is an easy fix?
>>> Or
>>>| might there be something tricky about it?
>>>
>>>Yes, it is somewhat tricky to decide whether end is being used inside
>>>an index expression.  What rule would you use (need not be stated in
>>>Lisp)?  Once you've decided that, the fix is to either modify
>>>octave-block-end-regexp appropriately, or, if the rule can't be stated
>>>in a regexp, to replace occurrences of
>>>
>>>  (looking-at octave-block-end-regexp)
>>>
>>>with the function that can determine whether we are looking at the end
>>>of a block and that is not confused by other uses of "end".
>>>
>>>
>>
>>Yes, but can't the meaning be discerned from the fact that "end" used as
>>an index always has a round parentheses about it?  Parentheses around an
>>end wouldn't be valid when "end" means end of a loop or conditional.
>>
>>Dan
>>
>>
>>
> It doesn't necessarily. I have used the following to extract the first
> and last elements from a vector:
> a([1,end]);
> Or, suppose you wanted to do a cylic shift of a vector:
> a=a([end,1:end-1]);
> So, there are a lot of exceptions you could cook up ...

Well, I'd argue that both those examples you gave have round parentheses
around the "end" statements.  Analogous to "if", as opposed to "if and
only if", I'm not requiring there be nothing else inside of those round
parentheses.  Expanding the definition, can you now think of a case where
"end" used as an index will not have parentheses around it?

Dan