bug#16526: 24.3.50; scroll-conservatively & c-mode regression

[Stefan Monnier]

> IIUC now any call to `forward-comment' with a negative argument will
> automatically go to BOB unless it's already there.

Actually, that should not always be the case, no.

> How else could it determine that it's not called from a position
> within a comment?

In general, that is true, but back_comment tries to be more clever, e.g,
when it scans backward over code like

   /* toto */
   blabla
   /* titi */

it should not need to scan further than the end of line 1, since the
"*/" there will tell it that the "/*" on line 3 can't be within
another comment and is hence the one-true comment starter that matches
the "*/" on line 3.

Of course, reality is more complex because there are also strings and
//...\n comments, but at least back_comment tries to avoid scanning from
BOB when it can.  I think it even tries hard enough to consciously
prefer performance over correctness, so that it will incorrectly handle

   // hello /* there
   bogus code */

and will jump to "/*" thinking it jumped over a comment.

> In any case, please provide an option say
> `c-open-paren-in-column-0-is-defun-start' which people can set to avoid
> those scans.  The doc-string should mention that things like Michael's
> commented out code are handled correctly iff this option is nil and that
> long delays while working with c-mode can be sometimes avoided by
> setting this option to t.  The default value could be obviously nil.

Another option is to put a syntax-table property on those rare
open-paren-in-column-0-inside-comment-or-string, so that
open-paren-in-column-0-is-defun-start still works properly.


        Stefan


PS: And yes, back_comment should somehow make use of syntax-ppss-cache to
avoid scanning from BOB.