bug#9148: Make `comment-normalize-vars' more syntax-aware

[Štěpán Němec]

On Tue, 02 Aug 2011 21:03:54 +0200
Stefan Monnier wrote:

>> The point is that you can define a major mode with different syntax
>> tables in different parts of the text (using the syntax-table text
>> property), but instead of using that information to determine
>> comment-start and the other variables, `comment-normalize-vars' still
>> relies on `comment-start' being hard-coded (which doesn't really make
>> sense in a buffer with multiple comment syntaxes), even when
>> `comment-use-syntax' is set and the syntax-table information is
>> sufficient.
>
> But this is part of a much larger problem (multiple major modes in the
> same buffer).

Maybe, but the specific change to `comment-normalize-vars' (gather the
appropriate value for `comment-start' from the syntax-table at point
instead of prompting the user when `comment-use-syntax' is set) I
proposed would seem easy enough and fix this very problem.

> Basically you're suggesting to use the syntax-table property as a way to
> specify the major mode used in each part and then teach newcomment.el to
> never use buffer-local variables but only the syntax-table around
> point.

More precisely and less ambitiously, I'm suggesting to do what
`comment-use-syntax' seems to be claiming already (that's also why I
still consider this a bug, not an enhancement request) -- to rely on
syntax-table instead of the regexp variables when manipulating comments.

> It might be a good idea, but it's a non-trivial change (and still
> leaves open the question of how to specify that I want //...\n for the
> C chunks and (*...*) for the Pascal chunks).

I don't understand. Again: the case I've described, the comment syntax
is unambiguously specified for every part of the buffer using the
syntax-table (either the buffer-local value, or the text property
value). The C chunks have the C syntax table as its value, the Pascal
chunks have the Pascal syntax table as its value (if there is such a
thing -- I don't use C or Pascal; in my specific case it was JavaScript
on one hand and a VimL[1]-like custom syntax with double quote comment
start and end-of-line comment end on the other).

The only thing that's needed to fix this very use case is make
`comment-normalize-vars' set `comment-start' from the syntax-table when
`comment-use-syntax' is set, instead of forcing me to advise it and do
it myself. It'd still be ugly, but not more ugly than it already is now,
and certainly better than using advice.


[1] The "language" used for Vim scripting.

-- 
Štěpán