emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: turning on minor modes from hooks


From: Drew Adams
Subject: RE: turning on minor modes from hooks
Date: Sat, 29 Aug 2009 20:01:08 -0700

> >> Stephen has long advocated that non-interactive invocation of mode
> >> commands should always turn on the mode instead of toggling.
> >
> > So interactively a nil arg will toggle, but in Lisp a nil 
> > arg will turn it on? And just why is that a great idea?
> 
> Er, because it works the command work "as expected" in all contexts,
> instead of in just one.

Er, and why would one "expect" a nil arg to work differently between Lisp and
interactive use?

And why would one "expect" the _particular_ behavior difference you define?

> >> I agree with that:  I think the vast majority of uses in code 
> >> do not use the toggling anyway, and while there probably are
> >> a few uses which would be broken by such a change, I think
> >> there would be far _more_ currently-incorrect uses
> >
> > In libraries or in user init files?
> 
> Mostly in user init files -- uses in libraries mostly won't 
> be affected, as they tend to explicitly specify the argument,
> and explicitly set or reset the mode, not toggle it.

I already agreed that most Lisp uses are not for toggling. I don't agree that
toggling in Lisp is so rare that it should be ignored. Especially if no real
advantage to doing so is given.

> > The latter, maybe, at least until they
> > discover that it doesn't do what they thought. That doesn't 
> take long...
> 
> That's exactly the problem -- it _does_ take long for a user to
> discover, 

We disagree. I think people discover this _very_ quickly. I've seen it happen on
help-gnu-emacs and Emacs Wiki. It's certainly easier to discover than how
`quote' works or `setq' or `setcdr'. It's easier to discover than how `add-hook'
works (to come closer to home).

I haven't noticed any great misunderstanding in this regard. The only
misunderstanding I've seen is early and ephemeral, and only from people who
never even looked at the doc string.

> because the default state for most modes is "off", and so
> toggling _usually_ does the right thing.

We disagree. Toggling can only turn it on every other time the mode is entered
(in a given buffer or, if a global minor mode, everywhere).

> Inadvertent use of the toggling behavior tends to result in
> obscure and hard to locate bugs

Bugs? I thought you were talking about a user's use of add-hook in an init file.

By "bug", I think of faulty Elisp code somewhere - is it the inappropriate
add-hook that you have in mind by "bug"?

What kind of "obscure and hard to locate bugs" are created by such inappropriate
use in a user's init file?

> (because it "usually" works right, 

Disagree.

> and only fails in the rare case where the mode happens to
> be already turned on for some reason).

Why is that a rare case? Do you never toggle a mode? If so, each time it is
turned on, the hook applies and toggles the other mode. I don't see that such
toggling "usually works right", if the expectation is that the mode be turned
on.

> >> that would be _fixed_ by such a change (where someone uses
> >> (add-hook 'foo-hook 'ack-mode) not realizing that it really
> >> toggles instead of turning on).
> >
> > "Not realizing" is the key phrase. This is not about being 
> > unable to understand, I think. It's about ordinary ignorance.
> > It's about things not being the way some newbies expect,
> > without reading the doc.
> 
> Yes.  Of course the doc should be good, but it's pretty clear that in
> practice, it's not enough -- people don't always read the 
> doc, or don't read it carefully enough, or aren't experienced
> enough to understand all the ramifications of what they're reading
> (the latter can be addressed to some extent by careful wording,
> but it's almost impossible to do reach all users).

The doc can always be improved, of course.

The question is about the users you have in mind here. In what I've seen, the
users who have misunderstood about the nil arg have nearly always been those who
didn't read the doc - at all. Once it was pointed out to them, things were
clear. The behavior and the doc were clear - they just needed to be pointed out.

As you said, you will never get all users to always consult the doc first. But
that's the case for nearly every facet of Emacs Lisp. "Misunderstanding" that
comes *only* from not consulting the doc does not imply that the design is wrong
or needs changing. Far from it. If we took that approach, we'd throw out 99.99%
of the design.

Think of the number (increasing, it seems) of people who send the simplest
questions to help-gnu-emacs, rather than taking a quick look at a doc string. We
should not change the design of Emacs just because they didn't bother to check
the doc first. That would be ridiculous.

Hey, some people are lazy. More frequently, out of ignorance they think it's
easier to ask help-gnu-emacs than to ask Emacs. They don't yet know about `C-h
f' and Info and apropos...

That doesn't mean that the design is wrong, just because they didn't guess right
the first time.

Misunderstanding that comes from poorly written doc is a different story - the
fix for that is to improve the doc.

Misunderstanding that comes from a poor design is yet another story. In such
cases, users cannot understand the behavior because it is inherently
contradictory or nonsensical. That is not the case here.

The UI (including the code interface) is consistent, clear, simple, and
understandable. Users who misunderstand the nil arg do so, in my experience,
*only* because they never looked at the doc (e.g. doc string). I've never seen
anyone not understand once the behavior was pointed out. This is not hard to
get.

> Thus it's really really useful if we can have _both_ good docs _and_
> commands that work intuitively.  Belt and braces, etc, etc.

I don't see that the current design is unintuitive. Of course, one can argue
anything one likes in terms of "intuitive" and "natural" - we won't get far with
such labels.

Please show what is contradictory (for example) in the current design. Show what
is difficult to understand (once one has read the description). Show anything
inherently difficult about the current behavior. Saying it is "unintuitive" just
isn't persuasive.

> > This is a YAGNI feature, at best, and a bug-producer and code
> > complexifier, at worst.
> 
> I think you're wrong.  It will cause some bugs, but it will 
> fix far more.

Describe one kind of software bug that it will fix. I pointed out a couple kinds
of problems it will introduce. Surely you can come up with one kind that it will
fix.

I'm talking bugs here, not an inappropriate add-hook in an init file. (If you
really must count that, OK, count it as one bug.)

But what kinds of programming bugs will this fix? You already admitted that the
add-hook gotcha is not a problem in code (libraries) - it's just a newbie
init-file thing. So how is this going to help with Elisp programming - what
kinds of bugs ("far more") will it fix?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]