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

[Stefan Monnier]

>>> 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.

We could do that, yes, but unless we regularly flush the comment-start
value we got, it will then keep using the first value found even on
chunks using another language.

>> 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.

comment-use-syntax was less ambitious: it was mostly about using
forward-comment.  It does try to build some of the vars from the
syntax-table, but mostly because comment-end-skip was new in
newcomment.el and I needed the code to work with old packages ;-)

But yes, comment-start could sometimes also be set from the
syntax-table.  I might accept a patch for it, tho I'm not completely
sure how useful that would be.

>> 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

That's not unambiguous: the C syntax-table specifies several comment
syntaxes (/*..*/ and //..\n) and so does the Pascal syntax table (even
more combinations, IIRC).  So comment-start-skip can be built from the
syntax-table since it needs to match "any comment starter", but
comment-start is more problematic since it would need to choose whose
comment syntax to favor.

> 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.

But if it's not a major mode used over the whole file, when do you flush
the comment-start value you computed?


        Stefan