search

honmaple / emacs-maple-minibuffer

Show minibuffer with another frame
GNU General Public License v3.0
78 stars 4 forks source link

`maple-minibuffer:parameters` not always honored #5

Open waymondo opened 4 years ago

waymondo commented 4 years ago

The default value of maple-minibuffer:parameters has left-fringe and right-fringe both set to 5, but the values are overridden by 0 when the frame is made: https://github.com/honmaple/emacs-maple-minibuffer/blob/master/maple-minibuffer.el#L124

It would be ideal that any parameters defined in maple-minibuffer:parameters were honored in preference over the sensible defaults.

honmaple commented 4 years ago

Well, I can't reproduce this issue, it's normal on my machine.

MattMicheletti commented 2 years ago

The default value of maple-minibuffer:parameters has left-fringe and right-fringe both set to 5, but the values are overridden by 0 when the frame is made: https://github.com/honmaple/emacs-maple-minibuffer/blob/master/maple-minibuffer.el#L124

It would be ideal that any parameters defined in maple-minibuffer:parameters were honored in preference over the sensible defaults.

I believe I can answer this question or rather explain why maple-minibuffer:parameters does indeed correctly work (i.e. there is no issue or bug here). Indeed, the context does appear strange when we look at the code as one might expect "the last thing declared or interpreted should win" (i.e. a LIFO order), however, this is NOT the case and it's logically explainable: ELisp alists treat entries in alists such that "the top most one wins". Essentially, when resolving to find an entry in an alist, ELisp resolves the search with respect to a FIFO order (i.e. "top one wins"). It finds the "first" entry that matches (according to declared order) and then stops searching (for details see the documentation on assoc(C-h f assoc RET), specifically the note "The value is actually the first element of ALIST whose car equals KEY." [Emacs Version] or "This function returns the first association for key in alist..." [Web Version]).

To apply that to the maple-minibuffer:parameters context, due to how the code is declared around Line 124 on the master branch, we can see that maple-minibuffer:parameters is spliced in "higher" or "nearer to the top" of the alist declaration as it is being created for make-frame to use later on (internally). Therefore, anything declared in maple-minibuffer:parameters will take precedence when retrieving keys from the alist provided to make-frame as maple-minibuffer:parameters at the front/top of the alist.

Some contextually relevant links: Drew gave, essentially the concise version of, the explanation of how keys can be "shadowed" in alists The Emacs documentation explains how the resolution of alist key retrieval is performed

A sample piece of (E)Lisp code that should show/demonstrate the concept (An online "fiddle" like interpreter example can be found here):

(let*
 (
  (my_alist `((hello . "Mr. Anderson") (world . "Earth") (editor . "Emacs")))
 )
 (print (prin1-to-string (assoc 'world my_alist))) ; => (world . "Earth")
 (setq my_alist `((world . "Mars") (hello . "Mr. Anderson") (world . "Earth") (editor . "Emacs")))
 (print (prin1-to-string (assoc 'world my_alist))) ; => (world . "Mars")
 (setq my_alist `((world . "Earth") (hello . "Mr. Anderson") (world . "Mars") (editor . "Emacs")))
 (print (prin1-to-string (assoc 'world my_alist))) ; => (world . "Earth")
)

I hope this helps explain the situation more so. I was initially confused and had a "gotcha" moment with it as well.

@honmaple This issue can be closed as "Not a bug".