Syntax sugar question

Syntax sugar question

[Ergus]

Hi:

Following something mentioned before I would like to repeat a question
that IMO is so simple that there may be a reason why it is not
implemented in this way.

Why the minor modes variables are only t or nil?

At the moment when we want to configure certain behavior we need to set
an extra custom or create a secondary mode like:

(setq myvar 'something)
(mymode-name 1)

or

(mymode-name 1)
(mymode-name-auxiliar 1)

and of course in the code we need to check both and add the extra config
in the init file for the user.

Some modes need that myvar will be set before because in the minor-mode
  function there is code like:

```
(if mymode-name 
     (if (eq myvar 'something)
         bla
        foo)
    elsething)
```

So finally the question is:

Does it makes sense to add the possibility in define-minor-mode and
related functions in order to do:

(mymode-name 'something)

So mymode-name will be 'something, myvar will disappear and the above
code could become simpler either using cond and or pcase and a single
nesting level condition?

In principle this won't break backward compatibility and may improve
readability and simplify several conditions.

Does it makes sense?

Best,
Ergus

Re: Syntax sugar question

[Stefan Monnier]

> Why the minor modes variables are only t or nil?

Because that's how they've been defined.  There's nothing magical about
minor modes, so you can definitely define something that looks and acts
very much like a minor mode but doesn't limit itself to boolean values.

Whether the `define-minor-mode` macro should offer a way to do that is
hence a UI design question.  I can see the benefit of what you propose,
but I also see the benefit of sticking to this simple model.

[ I don't understand the choice of "Subject:" here, I must say.
  What do minor modes have to do with syntactic sugar?  ]


        Stefan

Re: Syntax sugar question

[Nikolay Kudryavtsev]

Be aware that you can do (foo-mode -1) to disable foo-mode, so the 
current behavior already has some complexity.

Syntactically if we start allowing parameter passage during the mode 
command, why stop at 1? Why not allow arbitrary number of params? I 
think the current design is fine as it is forcing every mode to work out 
of box. If people would start passing params, there would eventually be 
modes that would only work if you have a legit parameter declaration.