Printing alist pairs to a dedicated buffur

Printing alist pairs to a dedicated buffur

[Heime]

I want to print the value pairs of an alist named tema-vodilac.

Although I can insert tema-vodilac: using

(insert (concat "\n" "tema-vodilac:\n"))

I cannot print the value pairs to the tema buffer

(defun tema-alist ()
  "Display the content of the association list ALIST."
  (interactive)

  (with-current-buffer (get-buffer-create "tema")
    (goto-char (point-max))
    (insert (concat "\n" "tema-vodilac:\n"))
    (dolist (pair tema-vodilac)
      (insert (format "\n %d  %s \n" (cdr pair) (car pair)))) ))

Re: Printing alist pairs to a dedicated buffur

[Manuel Giraud via Users list for the GNU Emacs text editor]

Heime <heimeborgia@protonmail.com> writes:

> I want to print the value pairs of an alist named tema-vodilac.
>
> Although I can insert tema-vodilac: using
>
> (insert (concat "\n" "tema-vodilac:\n"))
>
> I cannot print the value pairs to the tema buffer
>
> (defun tema-alist ()
>   "Display the content of the association list ALIST."
>   (interactive)
>
>   (with-current-buffer (get-buffer-create "tema")
>     (goto-char (point-max))
>     (insert (concat "\n" "tema-vodilac:\n"))
>     (dolist (pair tema-vodilac)
>       (insert (format "\n %d  %s \n" (cdr pair) (car pair)))) ))

Hi,

I don't understand.  With tema-vodilac defined like this:

(defvar tema-vodilac '((a . 2) (b . 1)))

Your command works for me.
-- 
Manuel Giraud

Re: Printing alist pairs to a dedicated buffur

[Heime]

Sent with Proton Mail secure email.

On Saturday, April 20th, 2024 at 1:24 AM, Manuel Giraud via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> wrote:

> Heime heimeborgia@protonmail.com writes:
> 
> > I want to print the value pairs of an alist named tema-vodilac.
> > 
> > Although I can insert tema-vodilac: using
> > 
> > (insert (concat "\n" "tema-vodilac:\n"))
> > 
> > I cannot print the value pairs to the tema buffer
> > 
> > (defun tema-alist ()
> > "Display the content of the association list ALIST."
> > (interactive)
> > 
> > (with-current-buffer (get-buffer-create "tema")
> > (goto-char (point-max))
> > (insert (concat "\n" "tema-vodilac:\n"))
> > (dolist (pair tema-vodilac)
> > (insert (format "\n %d %s \n" (cdr pair) (car pair)))) ))
> 
> 
> Hi,
> 
> I don't understand. With tema-vodilac defined like this:
> 
> (defvar tema-vodilac '((a . 2) (b . 1)))
>  
> Your command works for me. > -- > Manuel Giraud

When I use message, all is good, but not with insert to the buffer.

(cdr pair) and (car pair) are not getting printed in the tema buffer,
but they get printed in the messages buffer.

Re: Printing alist pairs to a dedicated buffur

[Heime]

Sent with Proton Mail secure email.

On Saturday, April 20th, 2024 at 7:26 AM, Heime <heimeborgia@protonmail.com> wrote:

> 
> 
> 
> 
> 
> Sent with Proton Mail secure email.
> 
> 
> On Saturday, April 20th, 2024 at 1:24 AM, Manuel Giraud via Users list for the GNU Emacs text editor help-gnu-emacs@gnu.org wrote:
> 
> > Heime heimeborgia@protonmail.com writes:
> > 
> > > I want to print the value pairs of an alist named tema-vodilac.
> > > 
> > > Although I can insert tema-vodilac: using
> > > 
> > > (insert (concat "\n" "tema-vodilac:\n"))
> > > 
> > > I cannot print the value pairs to the tema buffer
> > > 
> > > (defun tema-alist ()
> > > "Display the content of the association list ALIST."
> > > (interactive)
> > > 
> > > (with-current-buffer (get-buffer-create "tema")
> > > (goto-char (point-max))
> > > (insert (concat "\n" "tema-vodilac:\n"))
> > > (dolist (pair tema-vodilac)
> > > (insert (format "\n %d %s \n" (cdr pair) (car pair)))) ))
> > 
> > Hi,
> > 
> > I don't understand. With tema-vodilac defined like this:
> > 
> > (defvar tema-vodilac '((a . 2) (b . 1)))
> > 
> > Your command works for me. > -- > Manuel Giraud
> 
> 
> When I use message, all is good, but not with insert to the buffer.
> 
> (cdr pair) and (car pair) are not getting printed in the tema buffer,
> but they get printed in the messages buffer.

This is how I am filling my alist named tema-lugar


(defun tema-mark (kfrz)
  "Associate line number at cursor position with key phrase KFRZ."
  (interactive "sString: ")

  (let ( (lnum (line-number-at-pos)) )

    (setq-local tema-lugar
                 (append tema-lugar
                          (list (cons kfrz lnum)))) ))

Re: Printing alist pairs to a dedicated buffur

[Manuel Giraud via Users list for the GNU Emacs text editor]

Heime <heimeborgia@protonmail.com> writes:

> This is how I am filling my alist named tema-lugar
>
>
> (defun tema-mark (kfrz)
>   "Associate line number at cursor position with key phrase KFRZ."
>   (interactive "sString: ")
>
>   (let ( (lnum (line-number-at-pos)) )
>
>     (setq-local tema-lugar
>                  (append tema-lugar
>                           (list (cons kfrz lnum)))) ))

Hi,

Maybe your error comes from this `setq-local'.  I have used `defvar'
which will create a global (i.e. visible everywhere in Emacs) variable.
`setq-local' or `defvar-local' are used for *buffer-local* variables.
Buffer-local variables are visible only from the buffer they were
created.

In your previous command, the first thing you did was to switch to
another buffer that knows nothing about tema-lugar.  I suggest you to
read "(elisp) Buffer-Local Variables".

HTH
-- 
Manuel Giraud

Re: Printing alist pairs to a dedicated buffur

[Emanuel Berg]

Manuel Giraud via Users list for the GNU Emacs text editor wrote:

>> This is how I am filling my alist named tema-lugar
>>
>>
>> (defun tema-mark (kfrz)
>>   "Associate line number at cursor position with key phrase KFRZ."
>>   (interactive "sString: ")
>>
>>   (let ( (lnum (line-number-at-pos)) )
>>
>>     (setq-local tema-lugar
>>                  (append tema-lugar
>>                           (list (cons kfrz lnum)))) ))
>
> Maybe your error comes from this `setq-local'. I have used
> `defvar' which will create a global (i.e. visible everywhere
> in Emacs) variable. `setq-local' or `defvar-local' are used
> for *buffer-local* variables. Buffer-local variables are
> visible only from the buffer they were created.

Don't use `defvar' if it can be avoided as that creates global
dynamic/special variables, `setq' creates global
static/lexical variables which isn't much better - unless
there is a variable by that name present, then that is used
instead. That kind of `setq' use is not wrong, actually it
is good.

But yes, variables in Emacs are complicated and one problem is
that so much is dependent on the situation while the commands
look the same.

Anyway here is an interesting case, a combination of a for and
while loop, and we see the kind of good `setq' use I mean,
which do not create a global variable but sets an existing
one, "lst", instead.

(defun count-list (lst)
  (cl-loop
     with res = ()
     for l in lst while lst do
     (push (list (cl-count l lst) l) res)
     (setq lst (cl-remove l lst))
     finally return (cl-sort res #'>= :key #'car) ))

;; (count-list '(a b c d e a b c d a b c a b a))
;; -> ((5 a) (4 b) (3 c) (2 d) (1 e))

-- 
underground experts united
https://dataswamp.org/~incal

Re: Printing alist pairs to a dedicated buffur

[Heime]

On Saturday, April 20th, 2024 at 9:55 PM, Manuel Giraud <manuel@ledu-giraud.fr> wrote:

> Heime heimeborgia@protonmail.com writes:
> 
> > This is how I am filling my alist named tema-lugar
> > 
> > (defun tema-mark (kfrz)
> > "Associate line number at cursor position with key phrase KFRZ."
> > (interactive "sString: ")
> > 
> > (let ( (lnum (line-number-at-pos)) )
> > 
> > (setq-local tema-lugar
> > (append tema-lugar
> > (list (cons kfrz lnum)))) ))
> 
> 
> Hi,
> 
> Maybe your error comes from this `setq-local'. I have used` defvar'
> which will create a global (i.e. visible everywhere in Emacs) variable.
> `setq-local' or` defvar-local' are used for buffer-local variables.
> Buffer-local variables are visible only from the buffer they were
> created.
> 
> In your previous command, the first thing you did was to switch to
> another buffer that knows nothing about tema-lugar. I suggest you to
> read "(elisp) Buffer-Local Variables". -> Manuel Giraud

Correct I have defined the alist with setq-local for information about the current
buffer.  And I want to print the contents of the alist to a buffer named "tika".

Re: Printing alist pairs to a dedicated buffur

[Heime]

On Sunday, April 21st, 2024 at 4:37 AM, Heime <heimeborgia@protonmail.com> wrote:

> On Saturday, April 20th, 2024 at 9:55 PM, Manuel Giraud manuel@ledu-giraud.fr wrote:
> 
> > Heime heimeborgia@protonmail.com writes:
> > 
> > > This is how I am filling my alist named tema-lugar
> > > 
> > > (defun tema-mark (kfrz)
> > > "Associate line number at cursor position with key phrase KFRZ."
> > > (interactive "sString: ")
> > > 
> > > (let ( (lnum (line-number-at-pos)) )
> > > 
> > > (setq-local tema-lugar
> > > (append tema-lugar
> > > (list (cons kfrz lnum)))) ))
> > 
> > Hi,
> > 
> > Maybe your error comes from this `setq-local'. I have used` defvar'
> > which will create a global (i.e. visible everywhere in Emacs) variable.
> > `setq-local' or` defvar-local' are used for buffer-local variables.
> > Buffer-local variables are visible only from the buffer they were
> > created.
> > 
> > In your previous command, the first thing you did was to switch to
> > another buffer that knows nothing about tema-lugar. I suggest you to
> > read "(elisp) Buffer-Local Variables". -> Manuel Giraud
> 
> Correct, the alist was defined with setq-local for information about the current
> buffer. And I want to print the contents of the alist to a buffer named "tema".

Have come up with the following solution using an intermediate function that
passes the alist as argument.  Can I do this in a more straightforward manner ?

(defun tema-catapult (lugar)
  "Display the content of the association list LUGAR to the tema
buffer.  Because `tema-lugar' was defined with `defvar-local'."

  (with-current-buffer (get-buffer-create "tema")
    (insert (format "%s\n" "tema-lugar:"))
    (dolist (pair lugar)
      (insert (format  "%s %d\n" (car pair) (cdr pair))))) )

(defun tema-alist ()
  "Display the content of the association list tema-lugar."
  (interactive)
  (tema-catapult tema-lugar))

Re: Printing alist pairs to a dedicated buffur

[Yuri Khan]

On Sun, 21 Apr 2024 at 00:24, Heime <heimeborgia@protonmail.com> wrote:

> Have come up with the following solution using an intermediate function that
> passes the alist as argument.  Can I do this in a more straightforward manner ?
>
> (defun tema-catapult (lugar)
>   "Display the content of the association list LUGAR to the tema
> buffer.  Because `tema-lugar' was defined with `defvar-local'."
>
>   (with-current-buffer (get-buffer-create "tema")
>     (insert (format "%s\n" "tema-lugar:"))
>     (dolist (pair lugar)
>       (insert (format  "%s %d\n" (car pair) (cdr pair))))) )
>
> (defun tema-alist ()
>   "Display the content of the association list tema-lugar."
>   (interactive)
>   (tema-catapult tema-lugar))

Works? Good enough. You might want to name the helper function as a
private one, with a double dash somewhere in the name.

Alternatively, you can replace a helper function with a let:

    (defun tema-alist ()
      (interactive)
      (let ((lugar tema-lugar))
        (with-current-buffer (get-buffer-create "tema")
          …do whatever using the local ‘lugar’ variable…)))

Re: Printing alist pairs to a dedicated buffur

[Heime]

Sent with Proton Mail secure email.

On Thursday, April 25th, 2024 at 6:48 PM, Emanuel Berg <incal@dataswamp.org> wrote:

> Manuel Giraud via Users list for the GNU Emacs text editor wrote:
> 
> > > This is how I am filling my alist named tema-lugar
> > > 
> > > (defun tema-mark (kfrz)
> > > "Associate line number at cursor position with key phrase KFRZ."
> > > (interactive "sString: ")
> > > 
> > > (let ( (lnum (line-number-at-pos)) )
> > > 
> > > (setq-local tema-lugar
> > > (append tema-lugar
> > > (list (cons kfrz lnum)))) ))
> > 
> > Maybe your error comes from this `setq-local'. I have used` defvar' which will create a global (i.e. visible everywhere
> > in Emacs) variable. `setq-local' or` defvar-local' are used
> > for buffer-local variables. Buffer-local variables are
> > visible only from the buffer they were created.
> 
> 
> Don't use `defvar' if it can be avoided as that creates global dynamic/special variables,` setq' creates global
> static/lexical variables which isn't much better - unless
> there is a variable by that name present, then that is used
> instead. That kind of `setq' use is not wrong, actually it is good. 

So it is actually good, but then still make a commotion about it.
This way of commenting in not productive at all.

> But yes, variables in Emacs are complicated and one problem is that 
> so much is dependent on the situation while the commands look the 
> same. Anyway here is an interesting case, a combination of a for 
> and while loop, and we see the kind of good` setq' use I mean,
> which do not create a global variable but sets an existing
> one, "lst", instead.
> 
> (defun count-list (lst)
> (cl-loop
> with res = ()
> for l in lst while lst do
> (push (list (cl-count l lst) l) res)
> (setq lst (cl-remove l lst))
> finally return (cl-sort res #'>= :key #'car) ))
> 
> 
> ;; (count-list '(a b c d e a b c d a b c a b a))
> ;; -> ((5 a) (4 b) (3 c) (2 d) (1 e))

My defvar is used to store values that I need to access 
when I am working on a buffer.  I can add to it as I modify
the buffer, or delete from it.  I cannot see why all this 
fuss not to use global variables.

RE: [External] : Re: Printing alist pairs to a dedicated buffur

[Drew Adams]

> Don't use `defvar' if it can be avoided
> as that creates global dynamic/special
> variables,

By that logic, don't use defun because
it creates global dynamic functions.

Or defadvice or defalias or defcustom
or defconst or defface or defgeneric or
defgroup or defmacro or defmethod or
defstruct or deftheme or ...  They all
create global, dynamic bindings.

Try to use Emacs (or Haskell or ...
pretty much anything else, for that
matter) without using global, dynamic
bindings.  Then tell us about your
adventure. ;-)

It _can_ be "avoided" entirely.  But no
one does so.

> `setq' creates global static/lexical variables

Not true.

This is what CLTL2 says about setq in Common
Lisp, which uses lexical binding by default,
for variables:

  "The variables are represented as symbols, 
   of course, and are interpreted as 
   referring to static or dynamic instances 
   according to the usual rules. Therefore 
   setq may be used for assignment of both 
   lexical and special variables."

https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node79.html

And Elisp isn't even "as lexical" as Common
Lisp yet.  As (elisp) "Scoping Rules for
Variable Bindings" says:

  "By default, the local bindings that Emacs 
   creates are "dynamic bindings".
   ...
   The dynamic binding was (and still is)
   the default in Emacs for many years, but 
   lately Emacs is moving towards using 
   lexical binding in more and more places, 
   with the goal of eventually making that 
   the default."

IOW, Elisp hopes to eventually do what Common
Lisp does - and has done - for 40 years.

RE: [External] : Re: Printing alist pairs to a dedicated buffur

[Heime]

On Friday, April 26th, 2024 at 3:55 AM, Drew Adams <drew.adams@oracle.com> wrote:

> > Don't use `defvar' if it can be avoided
> > as that creates global dynamic/special
> > variables,
> 
> 
> By that logic, don't use defun because
> it creates global dynamic functions.
> 
> Or defadvice or defalias or defcustom
> or defconst or defface or defgeneric or
> defgroup or defmacro or defmethod or
> defstruct or deftheme or ... They all
> create global, dynamic bindings.
 
> Try to use Emacs (or Haskell or ...
> pretty much anything else, for that
> matter) without using global, dynamic
> bindings. Then tell us about your
> adventure. ;-)

So why make such comments to others ?  It is not amusing at all.
 
> It can be "avoided" entirely. But no
> one does so.
> 
> > `setq' creates global static/lexical variables
> 
> 
> Not true.
> 
> This is what CLTL2 says about setq in Common
> Lisp, which uses lexical binding by default,
> for variables:
> 
> "The variables are represented as symbols,
> of course, and are interpreted as
> referring to static or dynamic instances
> according to the usual rules. Therefore
> setq may be used for assignment of both
> lexical and special variables."
> 
> https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node79.html
> 
> And Elisp isn't even "as lexical" as Common
> Lisp yet. As (elisp) "Scoping Rules for
> Variable Bindings" says:
> 
> "By default, the local bindings that Emacs
> creates are "dynamic bindings".
> ...
> The dynamic binding was (and still is)
> the default in Emacs for many years, but
> lately Emacs is moving towards using
> lexical binding in more and more places,
> with the goal of eventually making that
> the default."
> 
> IOW, Elisp hopes to eventually do what Common
> Lisp does - and has done - for 40 years.

Re: [External] : Re: Printing alist pairs to a dedicated buffur

[Emanuel Berg]

Drew Adams wrote:

>> `setq' creates global static/lexical variables
>
> Not true.

As you know -

unless there already is another variable with that name, and
such as that can be present in many forms (`let' bindings,
formal parameters etc) including dynamic/special variables and
if so it remains dynamic/special with `setq' but otherwise
it'll be static/lexical.

> As (elisp) "Scoping Rules for Variable Bindings" says:
>
>   "By default, the local bindings that Emacs 
>    creates are "dynamic bindings".
>    ...
>    The dynamic binding was (and still is)
>    the default in Emacs for many years [...]

Emacs is de facto static/lexical.

  $ cd ~/src/emacs

  $ ls **/*.el | wc -l
  2312

  $ head **/*.el | grep -I "lexical-binding" | wc -l
  2285

There are certain interesting special cases, let's return to
those some other time.

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: Printing alist pairs to a dedicated buffur

[Emanuel Berg]

Heime wrote:

>> Try to use Emacs (or Haskell or ... pretty much anything
>> else, for that matter) without using global, dynamic
>> bindings. Then tell us about your adventure. ;-)
>
> So why make such comments to others ? It is not amusing
> at all.

It is very possible without dynamic/special variables. One can
use for example lexical let-closures:

;;; -*- lexical-binding: t -*-

(let ((clist '#1=(1 2 3 4 5 6 . #1#)))
  (defun next-six ()
    (unless (special-variable-p 'clist)
      (pop clist) )))

(declare-function next-six nil) ; for the byte compiler not to complain

;; (next-six)

As you see, the variable can be used just as a global variable
but is in fact not dynamic/special.

There are options and maybe some other use cases for
dynamic/special global variables but in general code
absolutely not have to rely on global variables, be them
dynamic/special or static/lexical in scope.

-- 
underground experts united
https://dataswamp.org/~incal

RE: [External] : Re: Printing alist pairs to a dedicated buffur

[Drew Adams]

> >> `setq' creates global static/lexical variables
> >
> > Not true.
> 
> As you know -
> unless there already is another variable with that name, and
> such as that can be present in many forms (`let' bindings,
> formal parameters etc) including dynamic/special variables and
> if so it remains dynamic/special with `setq' but otherwise
> it'll be static/lexical.

Yes, you understand `let', and using `setq'
inside `let', correctly.

(And in that regard, Elisp `let' is like CL
`let'.  But Elisp also has buffer-local etc.)

> > As (elisp) "Scoping Rules for Variable Bindings" says:
> >
> >   "By default, the local bindings that Emacs
> >    creates are "dynamic bindings".
> >    ...
> >    The dynamic binding was (and still is)
> >    the default in Emacs for many years [...]
> 
> Emacs is de facto static/lexical.

No, it's not.  Not yet.

>   $ cd ~/src/emacs
>   $ ls **/*.el | wc -l
>   2312
>   $ head **/*.el | grep -I "lexical-binding" | wc -l
>   2285

That just shows that most Elisp files provided
with Emacs have `lexical-binding' = t.

Dynamic binding is still the default in Elisp.
The doc is correct about that.
___


Let us know, when you use lexical binding for
_all_ your defuns, as well as for defface and
all the rest. ;-)

Re: [External] : Re: Printing alist pairs to a dedicated buffur

[Emanuel Berg]

Drew Adams wrote:

> That just shows that most Elisp files provided with Emacs
> have `lexical-binding' = t.

Yes - most :)

> Dynamic binding is still the default in Elisp. The doc is
> correct about that.

Yes, but isn't that a practical measure so that legacy code
won't break? Optimally all files will have the "-*-
lexical-binding: t -*-" directive first, then lexical binding
can be the default and that line won't be needed.

After that one can have the advantages of lexical binding in
general but one can still have dynamic/special variables for
options and other possible use cases, so there is no loss in
that respect.

There are also some interesting border cases where the
endpoints seems to meat, for example this

;; Provide an easy hook to tell if we are running with floats or not.
;; Define pi and e via math-lib calls (much less prone to killer typos).
(defconst float-pi (* 4 (atan 1)) "The value of Pi (3.1415926...).")
(with-suppressed-warnings ((lexical pi))
  (defconst pi float-pi
    "Obsolete since Emacs-23.3.  Use `float-pi' instead."))
(make-obsolete-variable 'pi 'float-pi "23.3")
(internal-make-var-non-special 'pi)

Lines 28-35 in
/usr/local/share/emacs/30.0.50/lisp/emacs-lisp/float-sup.el

Yeah, what should one make of it?

But now the discussion is about dynamic vs lexical scope, what
I said refered to global variables. Why have them with
`defvar', and why have them with `setq'? Often there is no
need for them to be global, that just creates problems.

-- 
underground experts united
https://dataswamp.org/~incal

Re: Printing alist pairs to a dedicated buffur

[Emanuel Berg]

Heime wrote:

>> Don't use `defvar' if it can be avoided as that creates
>> global dynamic/special variables,` setq' creates global
>> static/lexical variables which isn't much better - unless
>> there is a variable by that name present, then that is used
>> instead. That kind of `setq' use is not wrong, actually it
>> is good.
>
> So it is actually good, but then still make a commotion
> about it. This way of commenting in not productive at all.

`setq' to set variables is good, to create global variables
with it is often not necessary and for the compiler not to
warn you also have to use `defvar', that is totally confusing.

(defvar global-lexical)
(setq global-lexical 10)
(special-variable-p 'global-lexical) ; nil

Also setq is error-prone as make a typo, the intended variable
with not be set but instead a global one will be created.
But the byte compiler will warn you about that if it happens.

Another solution would be one function to set available
variables, and one to create global ones. The "set available"
one would signal if such a variable isn't present, the global
one if there were already such a variable. But again, this is
what makes Lisp interesting.

> My defvar is used to store values that I need to access when
> I am working on a buffer. I can add to it as I modify the
> buffer, or delete from it. I cannot see why all this fuss
> not to use global variables.

Certainly they are there if you want to use them (pun).
Lisp is a maximalist language, anything and everything
included. Some people think global variables are okay, other
people think they should be avoided if there isn't any good
reason to have them.

Why is a static/lexical global variable better than
a dynamic/special? Good question, we must write some Elisp to
test what happens if that name collides with other source.

I wrote some Elisp that would show another option approach, so
one would always have `let' for static/lexical variables to
facilitate coding, and another construct for options to set
the behavior of whatever was enclosed. Now I don't really
understand it anymore 100%, but I yank it here [last] for your
viewing pleasure :)

But it will be the way it is now, this is just endless
theorizing because Lisp is very powerful, but also very
complicated compared to other languages.

;;; -*- lexical-binding: t -*-
;;
;; this file:
;;   https://dataswamp.org/~incal/emacs-init/vars-opts.el

(require 'cl-lib)

(defun check-binders (binds)
  (cl-loop
    for (n _) in binds
    with no-opt
    do (unless (special-variable-p n)
         (push (symbol-name n) no-opt) )
    finally (when no-opt
              (error "No option%s: %s"
                     (if (< 1 (length no-opt))
                         "s"
                       "")
                     (mapconcat #'identity (reverse no-opt) ", ") ))))

(defmacro opts (binds &rest body)
  (declare
    (indent 1)
    (debug let) )
  (check-binders binds)
  `(let ,binds ,@body) )

;; (opts ((fill-column 1)
;;        (a 0) )
;;   u) ; No option: a
;;
;; (defvar dynavar 2000)
;;
;; (opts ((dynavar 3000)
;;        (fill-column 1)
;;        (a 0)
;;        (y 2) )
;;   y) ; No options: a, y
;;
;; (opts ((dynavar 3000)
;;        (fill-column 10) )
;;   (delete-char 2)
;;   (fill-paragraph) ) ; eval me

(provide 'vars-opts)

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: Printing alist pairs to a dedicated buffur

[Emanuel Berg]

Drew Adams wrote:

> That just shows that most Elisp files provided with Emacs
> have `lexical-binding' = t.

Another approach that has been discussed is why care about the
"default" at all?

How many functions are there where this really matters?
What about we just identify those, and split them into two
pairs with explicit reference to the scope?

So instead of `let' we would have `dlet' that is always
dynamic/special (we have it already BTW), then one `let' that
is static/lexical by default but keeps dynamic/special
variables that way if they are already that way, and then one
"slet" (or "llet") which is always static/lexical?

The benefit of that would be not the least that it would be
much easier to explain what this is all about, since one
wouldn't care about exactly that, what it is "all" about,
instead one would have a bunch of functions and for each one
would have a docstring "This function works like this ...".

The other benefit would be one could drop the directives which
are ugly.

There is another example which isn't `let' where this also
matters, I don't remember it right now. But are there more
examples than that? Maybe, but not a lot!

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: Printing alist pairs to a dedicated buffur

[Emanuel Berg]

Drew Adams wrote:

> Let us know, when you use lexical binding for _all_ your
> defuns, as well as for defface and all the rest. ;-)

What does it really mean to have a global
static/lexical variable?

See this, the `let' which is lexical evaluates to (3 4), not
(3 2) - ?

;;; -*- lexical-binding: t -*-
;;
;; this file:
;;   https://dataswamp.org/~incal/emacs-init/globals.el

(defvar global-special 1)

(defvar global-lexical)
(setq global-lexical 2)

(defun test-vars ()
  (when (and (special-variable-p 'global-special)
        (not (special-variable-p 'global-lexical)) )
    (list global-special global-lexical) ))

(let ((global-special 3)
      (global-lexical 4) )
  (test-vars) )

;; (test-vars)

(provide 'globals)

-- 
underground experts united
https://dataswamp.org/~incal

RE: [External] : Re: Printing alist pairs to a dedicated buffur

[Drew Adams]

> > Dynamic binding is still the default in Elisp. The doc is
> > correct about that.
> 
> Yes, but isn't that a practical measure so that legacy code
> won't break? 

Yes.  Emacs isn't "Move fast & break things",
because it cares about its users.  Users are
Emacs.

Legacy code - of which there's a _ton_, likely
multiple times the code delivered with Emacs.
Including code used in industry and government.

Don't just think "my code".  Most Emacs users
don't frequent mailing lists or other forums
about Emacs.  And not all Elisp code is by or
even for individual users.

And besides legacy code: legacy _habits_,
i.e., people.  In a word, history.
___

I said it before: what Emacs is now aiming for
wrt lexical binding of variables by default,
i.e., except for those declared "special", is
what Common Lisp has had from the start - 40
years ago.

And CL was the result of long discussions by
most of the world's Lisp experts, familiar
with the history of Lisp and the existing
Lisp implementations.

(It's true that U.S. experts participated
more than Europeans or others, alas.  The
world was even more parochial back then
than it is now.)

This is by way of saying that there's nothing
new about the behavior of lexical and dynamic
binding (and about their coexistance) in a
programming language or environment.  The
gotchas and foibles were well known.  Scheme
existed, for example, and its designers were
among those who designed Common Lisp.

Likewise, the problems with applicative-order
evaluation (eval all args, before evaling the
function body after their substitution) were
well known.  (Google "funarg problem".)

E.g., Lisp uses applicative order, as opposed
to normal order, which is used by Haskell etc.
Real (i.e., pure) lazy functional programming
was also already a thing back then, though
not so widely known.

Elisp will get to where Common Lisp has been,
wrt lexical & dynamic binding.  But it's not
there yet.

Keep in mind that Elisp is not only a general
programming language (but it's also that).

It's an interactive editing (and A, B, C,...)
environment.  Know not only the advantages of
lexical binding, in general, but also those
of dynamic binding - and particularly in an
interactive, editing context.

For that, I recommend RMS's points about why
dynamic binding is _useful_ for Emacs users:

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

And my point here was also to remind you that
binding is not only about variables, and you
cannot practically use Emacs without taking
advantage of its dynamic binding of options,
named functions, faces, and on and on and on.

You might not think about that.  Imagine, if
you had to pass your preferred value of some
user option or face explicitly as an argument
into thousands of functions, instead of it
being global.  _All_ user options.  The very
notion of a user option disappears.

I'll say it again:

  Let us know, when you use lexical binding
  for _all_ your defuns, as well as for
  defface and all the rest. ;-)

Face it:

Global definitions and dynamic binding are
your friends, just as much as locally-scoped
definitions and lexical binding.  You just
need to know which friend to call in any
given context, for favor or fun.

RE: [External] : Re: Printing alist pairs to a dedicated buffur

[Heime]

On Saturday, April 27th, 2024 at 3:55 AM, Drew Adams <drew.adams@oracle.com> wrote:

> > > Dynamic binding is still the default in Elisp. The doc is
> > > correct about that.
> > 
> > Yes, but isn't that a practical measure so that legacy code
> > won't break?
> 
> 
> Yes. Emacs isn't "Move fast & break things",
> because it cares about its users. Users are
> Emacs.
> 
> Legacy code - of which there's a ton, likely
> multiple times the code delivered with Emacs.
> Including code used in industry and government.
> 
> Don't just think "my code". Most Emacs users
> don't frequent mailing lists or other forums
> about Emacs. And not all Elisp code is by or
> even for individual users.
> 
> And besides legacy code: legacy habits,
> i.e., people. In a word, history.
> ___
> 
> I said it before: what Emacs is now aiming for
> wrt lexical binding of variables by default,
> i.e., except for those declared "special", is
> what Common Lisp has had from the start - 40
> years ago.
> 
> And CL was the result of long discussions by
> most of the world's Lisp experts, familiar
> with the history of Lisp and the existing
> Lisp implementations.
> 
> (It's true that U.S. experts participated
> more than Europeans or others, alas. The
> world was even more parochial back then
> than it is now.)
> 
> This is by way of saying that there's nothing
> new about the behavior of lexical and dynamic
> binding (and about their coexistance) in a
> programming language or environment. The
> gotchas and foibles were well known. Scheme
> existed, for example, and its designers were
> among those who designed Common Lisp.
> 
> Likewise, the problems with applicative-order
> evaluation (eval all args, before evaling the
> function body after their substitution) were
> well known. (Google "funarg problem".)
> 
> E.g., Lisp uses applicative order, as opposed
> to normal order, which is used by Haskell etc.
> Real (i.e., pure) lazy functional programming
> was also already a thing back then, though
> not so widely known.
> 
> Elisp will get to where Common Lisp has been,
> wrt lexical & dynamic binding. But it's not
> there yet.
> 
> Keep in mind that Elisp is not only a general
> programming language (but it's also that).
> 
> It's an interactive editing (and A, B, C,...)
> environment. Know not only the advantages of
> lexical binding, in general, but also those
> of dynamic binding - and particularly in an
> interactive, editing context.
> 
> For that, I recommend RMS's points about why
> dynamic binding is useful for Emacs users:
> 
> https://www.gnu.org/software/emacs/emacs-paper.html#SEC15
> 
> And my point here was also to remind you that
> binding is not only about variables, and you
> cannot practically use Emacs without taking
> advantage of its dynamic binding of options,
> named functions, faces, and on and on and on.
> 
> You might not think about that. Imagine, if
> you had to pass your preferred value of some
> user option or face explicitly as an argument
> into thousands of functions, instead of it
> being global. All user options. The very
> notion of a user option disappears.
> 
> I'll say it again:
> 
> Let us know, when you use lexical binding
> for all your defuns, as well as for
> defface and all the rest. ;-)
> 
> Face it:
> 
> Global definitions and dynamic binding are
> your friends, just as much as locally-scoped
> definitions and lexical binding. You just
> need to know which friend to call in any
> given context, for favor or fun.

In summary, all the talk criticising my use of Global 
definitions was nonsense from the start.  Then one wonders
how developers are not invited for parties !!!

Re: [External] : Re: Printing alist pairs to a dedicated buffur

[Yuri Khan]

On Fri, 26 Apr 2024 at 23:59, Heime <heimeborgia@protonmail.com> wrote:

> In summary, all the talk criticising my use of Global
> definitions was nonsense from the start.  Then one wonders
> how developers are not invited for parties !!!

Drew and Emanuel are discussing things two or three stories above your
current level of understanding. They both know when global special
variables are useful and when harmful. At your level, you should heed
the advice of limiting both the scope and lifetime of your variables
to only the necessary minimum.

Re: [External] : Re: Printing alist pairs to a dedicated buffur

[Heime]

On Saturday, April 27th, 2024 at 5:27 AM, Yuri Khan <yuri.v.khan@gmail.com> wrote:

> On Fri, 26 Apr 2024 at 23:59, Heime heimeborgia@protonmail.com wrote:
> 
> > In summary, all the talk criticising my use of Global
> > definitions was nonsense from the start. Then one wonders
> > how developers are not invited for parties !!!
> 
> 
> Drew and Emanuel are discussing things two or three stories above your
> current level of understanding. They both know when global special
> variables are useful and when harmful. At your level, you should heed
> the advice of limiting both the scope and lifetime of your variables
> to only the necessary minimum.

Discussing and arguing among yourselves much above the OP level is beyond
the scope of right when helping a question posed by the OP.