emacs-devel
[Top][All Lists]
Advanced

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

RE: Emacs 26.1 release branch created


From: Drew Adams
Subject: RE: Emacs 26.1 release branch created
Date: Mon, 25 Sep 2017 19:52:22 -0700 (PDT)

> (let ((text-quoting-style 'grave))
>   (message "(setq coding-system '%S)"
>            (find-operation-coding-system 'write-region "x")))
> 
> is incorrect, because it changes the quoting style not just for the
> message, but also for the internals of find-operation-coding-system,
> internals that are unrelated to the message and which will behave
> contrary to user preference.

So don't do that.  Just because you _can_ try to evaluate
`(cons 42)', that doesn't mean it is usually a great idea
to do so.

> The let-binding approach is appropriate only for simple cases
> where you know all the code that will be executed inside the 'let',

On the contrary (see RMS URL below).  It is especially
useful where you do NOT know all of the code that will
be executed within the dynamic extent of the `let' -
BUT where you are sure that you want all of that code
to respect such a binding.

That's the point.  The point of control is at the
`(let...)': it's there that you express your intent
wrt `text-quoting-style'.

If you don't know the extent over which you want a
setting of that variable to last in some context
then perhaps you shouldn't be using it.  Or dig in
and find an appropriate place for it.  It's about
what you want: where and when you want the setting
to hold.

The point is that you _can_ use it to control a
given extent of processing - even processing that
you don't know in detail or whose code you cannot
change.

That's the power of using `let' here: control the
extent of a given quote-behavior setting.

> and know that you want to override user preference

Gee, I thought you didn't look at `text-quoting-style'
as expressing a user preference, and so didn't want
it to be a user option.  Now it's a user preference
all of a sudden?  Hoorah.

> for all of the code. It is inflexible and error-prone
> compared to the easier-to-use '(message "%s" ...)'

Binding the variable is _more_ flexible, not less.
Whether it is also more error prone as a result of that
I won't argue.  It's true that to use `let' you need to
know what `let' does and pay attention to that.  Use it
wrong and errors can result.

> style that Emacs has used for decades.

Uh, let-binding dynamic variables is as old as the hills.
It's older than Emacs (and that's saying something).

> This is not a close call: we should document what has
> worked rather than try to promote an experimental
> alternative that has no significant technical advantages.

Ah, so you too prefer tried-and-true `let'? ;-)

The `let' approach is more flexible and more powerful.
It gives you more control over the scope (extent, really).
Do it where/when it makes sense to do it.  At least you
have a choice, and it is _easy_ to choose the extent of
its coverage.

Your ability to create straw-man examples of _bad_ uses
of `let' - inappropriate extent - shows nothing, except
that you are able to create bad uses of `let'.

The difference is not at all about "simple" vs "complex"
cases.  (I disagree with you and John about this.)  `let'
is appropriate for _both_ simple and complex cases - it
is simply more flexible.  Do with it what you will.

And yes, as it is more flexible you can certainly shoot
yourself in the foot with it.  This is Lisp.

https://www.gnu.org/software/emacs/emacs-paper.html#SEC15



reply via email to

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