Infrastructural complexity. [Was: Blunderbuss ".dir-locals.el" raises everything in its path!!]

[Alan Mackenzie]

Hi, everybody!

On Thu, Jul 16, 2009 at 02:38:35PM -0400, Stefan Monnier wrote:
> >> I think `message' should be improved to collect all messages coming
> >> in quick succession and display all of them appended to the echo area.

> > Certainly not as the default behavior. Perhaps as an alternative behavior.

> > There is lots of code, I'm sure, that depends on one message supplanting a
> > previous message. That is, the user is _supposed_ to see only the latest
> > message, not a concatenation of the last several messages.

> Agreed, it needs to be a new function.

> Maybe we could create a new function (notify-user MSG &rest ARGS) which
> would return immediately but display something in the echo area (or at
> the end of the minibuffer) for (at least?) notify-user-time seconds.

> Several successive calls to it would just queue up messages that are
> later displayed in turn (probably with some sort of "compaction"
> feature so repeated messages don't bore the user to death).

> Maybe it should be integrated/combined with the display-warning
> facility.

I think I have to step in and ask what are we doing and why.

<Rant mode>

The suggested functionality would be fine and dandy, but who really cares
about queueing up successive messages for pretty display?  How many
not-yet users would say "here's something neat I really want to learn
Emacs for!"?

It would add complexity to Emacs, and I suggest the increase in
flexibility is not enough to justify this.  I hope I'm not sounding too
cynical, but I started this thread almost defeated by complexity which
seems questionable.  Each little added facility feels compelling at the
time it's made, but somehow all the little bits gradually mutate into a
monster.  I ought to know, I'm maintaining CC Mode.  ;-(

Here's what seems to have happened with CC Mode style variables:
1/- Styles in CC Modes are a great idea.
2/- But some users still want to put "(setq c-basic-offset 3)" at the top
  level.
3/- Some users have been setting c-basic-offset in `c-mode-hook', and
  want to carry on doing so.
4/- File local variables are great.
5/- But surely users should be able to set a CC Mode style in file local
  variables.
6/- (Just recently) A project should be able to set "directory local"
  variables.
7/- But hey, we should be able to set a CC Mode style directorily
  locally.
8/- .....

Bit by bit, another "good idea" gets added in.  Where does all this stop?
Who needs all this complexity?  The interaction of all these features has
gone past the point where my poor little brain can confortably grasp
them, and I think Stefan's admitted the same for him.  Do any users
really, really care about all this flexibility?  Are we enhancing a world
beating editor, or are we really just contemplating our collective
navals?

Tracking down all the ways a CC Mode style variable can be initialised
stop being fun for me quite some while ago.  I'd love to get rid of some
of the complexity.

Why are we spending time talking about "intelligent" queueing up of
different categories of message?  Why aren't we, say, getting ECB
integrated instead?  Why aren't we writing refactoring functions?  Why
aren't we writing an ODF word processor mode?  You know, Open Office
Writer, using key sequences taken from Microsoft Word, just isn't nice to
use.

Just as an aside, I've been working on several difficult CC Mode problems
the last few weeks; difficult, but interesting and essential.  The
distraction to fix this little frippery hasn't been welcome, even though
the buggy code is largely in my area.

When considering new "infrastructure" features (as contrasted with
"feature" features, such as new modes like ECB), could we, perhaps,
change the focus from "is this useful?" to "is this something we can't
manage without?"

</Rant mode>

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).