RE: face-remap.el patch to resize window

[Drew Adams]

> > (No reason given.) Why?
> 
> Well the obvious reason is that it avoids hard-wiring 
> behavior which we believe to be to inflexible, and is
> a smaller change.

There is no inflexible, hard-wired behavior in the patch I sent. If the option
value is nil, nothing is done. If it is non-nil, then the window is resized.
Completely soft control, via a variable. User control, in fact -nothing is
softer. No hard-wiring, and nothing inflexible.

And my patch has 17% fewer lines than yours, if that's what you meant by
smaller. ;-)

> [The hook, after all, already exists; my patch mainly just 
> records a bit more information for it to use.]

These are each tiny patches. One adds a user variable and calls
`enlarge-window*' if the option value is non-nil. The other adds two internal
variables that record state and three alternative functions that call
`enlarge-window*'.

One makes text-scaling look at the option value and maybe change the window
size. The other provides window-sizing functions that you can add to the
text-scale hook. That's the only real difference, I think you'll agree.

I don't see either approach as unclean, inflexible, or hard-wired.

I see one approach that is user-friendly, with well-defined behavior that is
advertised to users clearly via a user option.

I see another approach that does nothing for users, unless they happen to read
the code, discover the potential hook functions, and add one of them to the
hook. And if a user wants to change the behavior, s?he needs to mess with
`add-hook' and `remove-hook' all over again.

> > I mentioned some disadvantages to using a hook.
> 
> Hmm, the only real disadvantage I can see
> is that hooks aren't well-supported by customize.

Not just Customize.

Hooks also do not facilitate on-the-fly addition/removal by users. A user cannot
get the equivalent of `set-variable' using hooks - s?he needs to fiddle with
some Lisp code (e.g. via `M-:').

And that includes making the behavior buffer-specific or updating a buffer-local
setting. With `set-variable', you just use a prefix arg to do that. With hooks,
you need to first use `remove-hook', then `add-hook', specifying the LOCAL flag
as appropriate.

The question is whether we really intend this for users. Using hooks instead is
somewhat of a copout IMO - making it seem like we did something. (E.g. to get
Drew off our backs. ;-) )

> [As for "buffer localness", hooks, after
> all, can also be buffer-local, or can examine a buffer-local 
> variable to determine their behavior.]

Sure, a user can always code something up. But _why_ make users do that, when
using an option is so much simpler for them?

You seem to suggests that your patch is easier for those working with the code
(though it's not). What about the users?

> > No one has mentioned any advantages.
> 
> See above:  Smaller; more flexible.
> Hooks (like other indirection mechanisms) are generally more flexible,

How is it smaller? More flexible for whom? Users?

> at some cost in user-friendliness and clarity.  So if there's very
> commonly desired behavior, sometimes it's good to hard-wire it

Apparently, code that examines a user option and reacts to it constitutes
"hard-wired" behavior, for you. That's a misleading designation.

Yes, you can add any behavior you want with a hook, so in that sense nothing
beats its flexibility - it does nothing, anything, and everything. The behavior
is undefined.

Yes, predefined behavior that reflects a user's intention through an option
value is, well, predetermined. IOW, it is well-defined. As you said, it has the
advantages of "user-friendliness and clarity".

> instead of telling people to use a hook or whatever (even if an 
> appropriate hook already exists).  However as I've mentioned,
> it's not clear to me that the described behavior in this case
> is generally useful/universal enough to hard-wire.

The point really seems to be that you're not convinced users should be offered
this behavior. ;-) But you're willing to provide the hook functions for it.
Sounds like that's as good as we're going to get.

It's still an improvement for users to have this possibility, no matter what
they need to do to use it. Please add the feature, one way or the other.