bug#703: Octave comments in emacs

[Rosen Diankov]

Hi all,

Coming from Matlab, I feel much more comfortable if the single quotes
were treated like double quotes (transposing is not as important), and
if the comments were aligned to the start of the next line (like the
// in C++). Given that a lot of people use Octave as a free
alternative to Matlab, I think a lot would expect the same formatting
rules as the matlab editor.

At least it would be great to expose these options to the user like
'octave-auto-indent' instead of having people hunt through
octave-mod.el to get the behavior they want.

Rosen,

2008/8/20 Kurt Hornik <Kurt.Hornik@wu-wien.ac.at>:
>>>>>> Chong Yidong writes:
>
>> Hi Kurt,
>> Could you take a look at this bug report?
>
>> http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=697
>> http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=703
>
>> Thanks.
>
> Sure.
>
> I am not quite sure I understand what the issue is.
>
> Octave mode has never provided syntax support for single quoted strings
> because there is no way (short of actually parsing the code) of telling
> these apart from single quotes used for transposition.
>
> The comment style provided by Octave mode is the same as for Lisp mode,
> so a single comment char is aligned at the comment column.
>
> Best
> -k
>
>> 2008/8/11 Rosen Diankov <rdiankov@cs.cmu.edu>:
>
>>> The % also messes up formatting when seen in strings, ie
>>> 'my value: %d'
>>>
>>> For some reason, the octave syntax does not recognize that single
>>> quotes are strings (it might be because the transpose character is
>>> also ' and it is hard to differentiate between a string and the
>>> transposing).
>>>
>>> In any case, writing the above example will treat the % as a comment.
>>> The indenting engine will skip the closing parenthesis )... resulting
>>> in all the rest of the indents looking like garbage.
>>>
>> ....
>>>
>>> In calculate-octave-indent, just delete the entire expression
>>>
>>> ((looking-at "\\s<\\S<")
>>> (setq icol (list comment-column icol)))
>>>
>>> that forces comments to comment-column (which is 32). Was there a
>>> reason for this?
>
>