RE: [External] : Supplying DOC string in a `defun' using `defvar'

[Drew Adams]

> > From my point of view, the docstring should have 
> > nothing to do with either dynamic or lexical binding.
> 
> No, but

I guess (hope) that your "No, but" really means "Yes,
but", and that you agree that it _should_ indeed have
nothing to do with dynamic or lexical binding.

> it's a new language feature, so it makes sense that 
> you need to use the new dialect for it be available.

I don't see how that makes sense at all.  It doesn't
follow logically that every "new language feature"
must work _only_ with the lexical binding dialect
turned ON.

As you say, the "lexical" dialect supports both
lexical and dynamic binding.

And other things being equal, a new feature should,
likewise, support both lexical and dynamic binding.

But it doesn't follow that a new feature shouldn't
work with the "dynamic" dialect, when no lexical
bindings are involved.

Regardless of the "dialect" used (i.e., whether
var `lexical-binding' is nil or non-nil), there's
nothing in the example used in this thread that
makes use of any lexical bindings (beyond the
binding of local variable `x'):

 (defvar my-doc "Whatever...")  
 (defun my-fun (x)
   (:documentation my-doc)
   (+ x 42))

That lexical binding is available in Emacs Lisp now
is a good thing.  That both it and dynamic binding
should be available from now on is a good thing.
And turning on such support for both by default will
also be a good thing, when that happens.

But that users should be required to explicitly turn
it on now in a buffer where you evaluate such an
example (which shouldn't need and doesn't make use
of lexical bindings) makes no sense at all, to me.
But please let me know what I'm missing about this.

At least such a requirement doesn't follow from
the fact that `:documentation' is "a new language
feature" ... unless you can show that this new
feature somehow requires lexical binding support
even for such an example.

The question, I think, is why shouldn't using
`:documentation' work regardless of whether lexical
binding is turned on for the current buffer?

> You get to choose for every ELisp file which
> dialect it uses.

Emacs turning on the "lexical" dialect (a misnomer)
by default, so that both lexical and binding are
supported out of the box, will be welcome.

Until then, "get to choose" should really mean
_get_ to choose.  It shouldn't mean that in order
to use such a "new feature" you _must_ explicitly
turn on the "lexical" dialect, even when no lexical
binding is involved.

For now, the default is the "dynamic" dialect (also
a misnomer, as you pointed out).  For now, new
features that don't inherently require the use of
lexical binding should _just work_ for both
"dialects".

Unless I'm missing something...  Does this new
feature (`:documentation') inherently require the
"lexical" dialect?  Is such an example, which
makes no use of lexical bindings, inherently
incompatible with the "dynamic" dialect?