Closed kat-co closed 1 year ago
Uhm, it is weird I cannot reproduce this. Definitely those functions are fragile and badly named.
The idea behind them is that we want plists or alists that have all consistent keys.
This because from ((:a a :b b))
I can easily identify the headers of the table to be "a" and "b".
What happens if you run:
(--> '((:buffer "Playground" :size 201)
(:buffer " *Minibuf-1*" :size 0)
(:buffer "Show Tutorials" :size 3510)
(:buffer "*scratch*" :size 187)
(:buffer "moldable-emacs.el" :size 47852)
(:buffer " *Minibuf-0*" :size 0)
(:buffer "*Messages*" :size 34483)
(:buffer " *code-conversion-work*" :size 11)
(:buffer " *Echo Area 0*" :size 0)
(:buffer " *Echo Area 1*" :size 0)
(:buffer "*Compile-Log*" :size 0)
(:buffer "*Warnings*" :size 328)
(:buffer "*direnv*" :size 0)
(:buffer "core.el" :size 42803)
(:buffer "contrib.el" :size 16916)
(:buffer " *org-src-fontification:emacs-lisp-mode*" :size 90)
(:buffer " *helm candidates:Emacs Commands history*" :size 7)
(:buffer " *helm candidates:Emacs Commands*" :size 192024)
(:buffer "*helm M-x*" :size 2276)
(:buffer "*Completions*" :size 305)
(:buffer "EvalSexp" :size 0))
me-alist-to-plist
)
?
It is suspicious your mapcar(#f(compiled-function (it) #<bytecode 0x10c26e1>) (:buffer "Playground" :size 201))
because it seems it is going in the else branch here https://github.com/ag91/moldable-emacs/blob/f3fe8e3/molds/core.el#L179, which should not happen.
That gives an error for me too.
This is as close to a 100% assertion I can make that the issue is not on my end:
katco says: guix environment -C --pure -ETERM --no-cwd --ad-hoc emacs emacs-moldable-emacs -- emacs --batch --eval "(require 'moldable-emacs)" --eval "(me-alist-to-plist '((:a "A")))"
Loading /gnu/store/amsqdqzp1s0nmy185l9py4vd9hvqbihi-emacs-moldable-emacs-0.0.0-1.822965d/share/emacs/site-lisp/moldable-emacs-0.0.0-1.822965d/moldable-emacs-autoloads...
Loading /gnu/store/g3m09phwjc4anjq4j8gz14chsk5gwqjz-emacs-dash-2.19.1/share/emacs/site-lisp/dash-2.19.1/dash-autoloads...
Loading /gnu/store/dz7495gb19jhxk10yvcf3dxzhvkgxsrz-emacs-s-1.12.0/share/emacs/site-lisp/s-1.12.0/s-autoloads...
Loading /gnu/store/dvdrlq6f9gs43axk7js1c337qmm51ih3-emacs-async-1.9.4/share/emacs/site-lisp/async-1.9.4/async-autoloads...
Wrong type argument: sequencep, :a
What this is doing is starting a container with
TERM
environmental variableand evaling (me-alist-to-plist '((:a "A")))
.
Mmm, can I run that with the scm file of the PR as well?
Anyway, quick attempt: can you try to rerun the test redefining me-alist-to-plist like this
(defun me-alist-to-plist (alist)
"Convert ALIST to a `plist'."
(let ((keys (ignore-errors (--map (intern (concat ":" it)) (car alist)))))
(if (and keys (ignore-errors (= (length (car alist)) (length (-filter #'stringp (car alist))))))
(--map (-flatten (-zip-lists keys it)) (cdr alist))
alist)))
I suspect that the if-let* has a different semantic than on my system. I actually don't know where I get that macro from, so I tried to remove it (this is just an ugly implementation to see if we can patch up your error)
Mmm, can I run that with the scm file of the PR as well?
Yes, if you have Guix installed, you can run guix environment -C --pure -ETERM --no-cwd --ad-hoc emacs --load=./guix.scm -- emacs --batch --eval "(require 'moldable-emacs)" --eval "(me-alist-to-plist '((:a "A")))"
With the function redefined as is in your comment, it works!
For clarity, I would still ask you to reconsider the terminology in some of the variables, comments, and function names. Not only because of the inputs, but because of the outputs. In this case, what's returned from me-alist-to-plist
appears not not to be a plist, but a list of plists.
I can't give any more guidance on that until I get a little more familiar with things.
It looks like it's a macro defined in subr-x
. So it would just require a (require 'subr-x)
I think.
For clarity, I would still ask you to reconsider the terminology in some of the variables, comments, and function names. Not only because of the inputs, but because of the outputs. In this case, what's returned from me-alist-to-plist appears not not to be a plist, but a list of plists.
I can't give any more guidance on that until I get a little more familiar with things.
Guidance appreciated. This also requires I book some time for refactoring things. I will need to revisit those functions anyway, because detecting/converting Org Tables seems too expensive with the default functions available in Emacs.
It seems I have addressed these points in previous changes
I was working my way through the tutorial, and I get to the step where you are supposed to turn the list of buffers into a bar-chart. This fails for me, so I tried running
ElispListToOrgTable
with the following data:I get this stack-trace:
I think this is an issue somewhere in this function:
https://github.com/ag91/moldable-emacs/blob/da95af66005664d88f159931837776694ab479e2/moldable-emacs.el#L127-L132
But I also think there is probably other issues with this mold:
(assoc 'a '((a 1) (b 2 3 4 5)))
:given
precondition is really checking for is that there is a list of uniform plists. These types of lists would implicitly form an alist, but not in the way I think this mold means it. I.e.=>
(:buffer "Playground" :size 201)
.Traditionally, Lisps have consed additional values onto an alist because
assoc
style functions will stop once they find the first match. This is how alists are updated.Therefore, I think it may be incorrect and misleading to call a function named
me-alist-to-plist
since this is not really an alist despite being in an alist shape, and this may be why there's an error.I haven't continued digging into what shape of list
me-insert-flat-org-table
expects.