On Sun, 25 Sept 2022 at 19:15, Quiliro Ordóñez <[email protected]> wrote: > (...)
Hi Quiliro! First: > I cannot update to 20220924. Are you sure it is in ELPA yet? Ouch! It is not! I'll try to debug that... > I do not use Python because I think it is a language which is just a fad > which will die. But I think that there are many people that could be > attracted to eev because it has useful Python hacks. I use Python very little, and I don't like it. But I think that adding more Python support to eev will attract good karma... > For both talks, I suggest to open with a 2 sentence description of what > eev is. And then an explanation of the results which are expected from > using the tool you are about to present. These introductions should be > understood by anyone, regardless of the experience they have with Emacs > or eev. The problem is that even after all these years I still don't have a good short description of what eev is _that makes sense to most people_, and I am still trying to understand why some ideas that are totally obvious to me are so hard for other people... Here's one example. A few weeks ago I posted this here: https://lists.gnu.org/archive/html/eev/2022-09/msg00000.html The discussion on Reddit had a few more comments from both the OP and me. Here is my last comment there (so far): You have some good points. I think that I need to stress in the docs that the workflow that I described is only worth the pain when we really, really, REALLY want to keep "executable notes" of how to obtain a certain window configuration... I prefer this (defun q2 () (interactive) (find-3a '(find-fline "~/2022.2-quadros/") '(find-fline "~/2022.2-C2/Makefile") '(find-fline "~/2022.2-C3/Makefile"))) to a macro because it is easier to read, easier to edit, and easier to adapt to other tasks than a macro. I have a bunch of things like this (setq last-kbd-macro (kbd "M-h M-2 (find-fline SPC \" 2<delete> M-z : C-y <left> \" <delete> SPC\n M-z : C-y DEL SPC \" <delete> M-z = C-y 3<left> C-k \") C-a <down> RET")) saved in my notes, but usually they become hard to read very quickly... while the function q2 above is something that I know that I will have to execute hundreds of times in 2022.2 (an academic semester) with M-x q2, and that when 2022.2 ends and 2023.1 start I will just have to modify it a bit... but most people would prefer to do that by using something like ace-window than by writing small programs in Lisp. Most people don't understand why I prefer to keep "executable notes of everything that I do" in a format that I find easy to read, to edit, and to reuse, even when that takes much longer than just installing a package and learning a few new keybindings... maybe their notion of "fun" is opposite to mine. =S > I do think that key bindings for eev should all share the same prefix > keybinding. It would make it easier to identify it. Maybe another idea > would be to use C-c as is used in org-mode. I am not sure about the way > to solve it, but I have difficulty remembering how to do things in eev. > Maybe you have better ideas. Here's how I've handled that since the 90s - in a slightly modernized version. Suppose that your cheat sheet about things that your are currently learning is in a file called ~/LEARNING. Then run this, (defun le () (interactive) (find-fline "~/LEARNING")) (defun ll () (interactive) (find-2a nil '(le))) (defun eejump-26 () (le)) (defun eejump-27 () (ll)) and ta-da: now `M-x le' and `M-2 M-6 M-j' open ~/LEARNING in the current window, and `M-x ll' and `M-2 M-7 M-j' open ~/LEARNING in the window at the right. Does that make sense? Does it look convenient? Or clumsy? Cheers - and more news about kla soon... [[]], E.
