help-gnu-emacs
[Top][All Lists]
Advanced

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

Re: [SOLVED with `eval']: Why I cannot use this variable in macro call f


From: Jean Louis
Subject: Re: [SOLVED with `eval']: Why I cannot use this variable in macro call from function?
Date: Thu, 10 Jun 2021 09:56:04 +0300
User-agent: Mutt/2.0.7+183 (3d24855) (2021-05-28)

* Robert Thorpe <rt@robertthorpeconsulting.com> [2021-06-10 05:12]:
> I just want to say a couple of things about this.
> 
> I think you should read the Emacs lisp manual more.  Or maybe even
> another book on Lisp.  Understanding of scope is important.  So are
> macros and quoting if you're using them.
> 
> For the snippet of code that Tomas gives I get the same result:
> >  (let ()
> >    (let ((x 42))
> >      (eval '(progn (setq x 43) (message "in eval: x is %S" x)))
> >      (message "inner let: x is %S" x))
> >    (message "outer let: x is %S" x))
> 
> Gives:
> 
> > in eval: x is 43
> > inner let: x is 42
> > outer let: x is 43
> > "outer let: x is 43"
> 
> I don't get any errors.

With `emacs -Q' I get no errors in *scratch*, now I can see that. I
can see that my *scratch* was changing lexical bindings. When I invoke
it in a new emacs-lisp-mode buffer there is error under dynamic
bindings, and no error under lexical bindings. 

IMHO everybody should learn more and so I do. Obviously I did not
find the way. Whoever has read more than me, then I am asking to
give me references.

> However, I think that your problem doesn't really require any of
> that complexity.  I think it can be done with an Alist.
> 
> Why not save all of your histories into one alist?  Instead of an alist
> you could use a hash.  I don't see why you have to create a set of new
> global variables to solve the problem.

Definitely good idea and now I was thinking there is some description
pointing to it and have looked into `completing-read' and
`read-from-minibuffer' and found nothing, I have to provide a variable
or cons with variable to those functions. It is good idea definitely,
but show me the practical way how to use alist or hash in those
functions.

> You have a function that creates one of those variables.  Why not
> replace it with a function that enters the information in a global
> alist?  Then you only need one global variable.  Then when you need to
> call "completing-read" use an assoc to find the sub-list to use.o

Your ideas go to the root or to depth of the problem. But how
practically to do that? I don't want to change those functions, I
want to pass something to them which will have dynamic names or
arguments. I could assign a single global buffer-local variable
that keeps the name of the edited column, and the function passed
could then find that variable and fetch from alist.

But how?

(read-from-minibuffer PROMPT &optional INITIAL-CONTENTS KEYMAP READ
HIST DEFAULT-VALUE INHERIT-INPUT-METHOD)

Fifth arg HIST, if non-nil, specifies a history list and optionally
  the initial position in the list.  It can be a symbol, which is the
  history list variable to use, or a cons cell (HISTVAR . HISTPOS).
  In that case, HISTVAR is the history list variable to use, and
  HISTPOS is the initial position for use by the minibuffer history
  commands.  For consistency, you should also specify that element of
  the history as the value of INITIAL-CONTENTS.  Positions are counted
  starting from 1 at the beginning of the list.  If HIST is the symbol
  ‘t’, history is not recorded.

It works this way:

(let ((history '("One" "Two" "Three")))
  (read-from-minibuffer "Tell me: " nil nil nil 'history))

Not this way:

(let ((history (lambda () '("One" "Two" "Three"))))
  (read-from-minibuffer "Tell me: " nil nil nil 'history))

Or this way:

(let ((history '("One" "Two" "Three")))
  (read-from-minibuffer "Tell me: " nil nil nil '(history . 1)))

and I guess it is similar situation here:

(completing-read PROMPT COLLECTION &optional PREDICATE REQUIRE-MATCH
INITIAL-INPUT HIST DEF INHERIT-INPUT-METHOD)

, if non-nil, specifies a history list and optionally the initial
  position in the list.  It can be a symbol, which is the history list
  variable to use, or it can be a cons cell (HISTVAR . HISTPOS).  In
  that case, HISTVAR is the history list variable to use, and HISTPOS
  is the initial position (the position in the list used by the
  minibuffer history commands).  For consistency, you should also
  specify that element of the history as the value of INITIAL-INPUT.
  (This is the only case in which you should use INITIAL-INPUT instead
  of DEF.)  Positions are counted starting from 1 at the beginning of
  the list.  The variable ‘history-length’ controls the maximum length
  of a history list.  If HIST is the symbol ‘t’, history is not
  recorded.

Question is how practically?

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/



reply via email to

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