bug#1756: awk-mode: An empty line is not a paragraph separator (should be)

[Alan Mackenzie]

Hi, Teemu,

On Wed, Jan 07, 2009 at 06:32:56PM +0200, Teemu Likonen wrote:
> Alan Mackenzie (2009-01-06 16:15 +0000) wrote:

> >> After "C-c . awk RET" it changes to this:

> >>     "[ \t]*\\(\\(#+\\)[ \t]*\\)?$\\|^\f"
> >                    ^^

> >> Even though I chose to override the style settings "#*" changes to "#+".

> > I don't think this is a bug.  You asked for "awk" style to be set on
> > the buffer, and this is exactly what you got.

> Well, I asked that, but I had also explicitly asked to override style
> settings (through the customize interface). My opinion is that the
> current behavior is so confusing that it's either a bug or simply wrong
> design decision.

It's very confusing.  I get confused, even though I maintain it and I
wrote the bit of the manual that describes it.  I honestly believe the
current functionality is "over-engineered", simply too feature-rich for
the job it does.  However, it's there and (?lots of) people would
complain loudly if any features were abolished.

The style-variables each have a global default, a value in the current
style and a buffer local value in each buffer (which could be either of
the two previous values).  In turn, the style is either an explicitly
selected style or the default style.  Additionally, this all interacts
with the customisation facility, which has no notion of buffer local
variables.  I admit, starting from scratch, nobody would design it this
way.

The other thing, I don't think it matters too much exactly how the style
system works.  What is bad is when it confuses people, or creates
expectations which won't be satisfied.  (See below.)

> I don't mean to complain too loudly, though. See below.

Complaining loudly is OK on this mailing list.  :-)

> > I am guessing that the cause is in the fine CC Mode manual, [...]

> > [...] perhaps it would be better if amended something like this:

> >     When you initialize the buffer, the settings are made in the
> >     following order.  So if you make conflicting settings in several of
> >     these ways, the way that takes precedence is the one that appears
> >     latest in the list(2):

> >         Style
> >         Top-level command or "customization interface"
> >         Hook
> >         File Style

> >     ---------- Footnotes ----------
> >     (2) If you later call `c-set-style' (C-c .), all the style variables
> >     will get set to the style you select.

> > What do you think?

> Well, my real opinion first: User's explicit "override style settings"
> setting should just do that: override style settings no matter what
> style changes the user does while editing the buffer.

OK, this is the text in the M-x customize-variable screen.

> For example, user may want to choose certain custom comment prefix
> settings and, while editing the code, she may want to experiment with
> different style settings or convert the code from one style to another.
> Logically, if she wants to get comment prefix settings from a
> pre-defined style she chooses "Use style settings"
> (c-comment-prefix-regexp). If she wants to use her own comment prefix
> she chooses "Override style settings". I think this is the most
> intuitive behaviour. Currently user can only override style settings
> for the initial style state.

This could be implemented in `c-set-style', [by looking at the global
value of c-comment-prefix-regexp, and using this value rather than the
style's value if the global value isn't 'set-from-style].  Feel free to
ignore the bit in the brackets if it doesn't make much sense!

But this would mean that c-set-style would not do exactly what it says.
With all due respect, I think this would be at least as un-intuitive as
the current mechanism.  Of course, I could create a new option saying
which of these is to be preferred, but that would add even more confusion
into the mix.

> But if you choose to maintain the current behaviour anyway, then I'd say
> that the changes you suggested for the documentation are very good. I'd
> also suggest to change the documentation of c-comment-prefix-regexp
> variable so that it tells how the variable effects in the practice.

Agreed.  This also applies to the other style variables.  What I think is
buggy at the moment is that:
o - `customize-variable' doesn't say "Global default value" anywhere.
o - "Override style settings" is confusing.  Maybe "Set explicit value"
  would be better.

> Anyway, the empty-line bug is the main thing. If that bug in Awk mode
> gets fixed (you already did with that patch) then there shouldn't be
> much need for changing comment prefixes in the first place. So I'm
> really more on the "thank you" side than on "complaining" side. :-)

Cheers!  I've committed the patch to the Emacs repostory (which will
become the future Emacs-23).

But it would still be nice to get `customize-variable' working nicely
with CC Mode.

-- 
Alan Mackenzie (Nuremberg, Germany).