summaryrefslogtreecommitdiffstats
path: root/2020
diff options
context:
space:
mode:
Diffstat (limited to '2020')
-rw-r--r--2020/info/30.md42
-rw-r--r--2020/info/32.md32
2 files changed, 28 insertions, 46 deletions
diff --git a/2020/info/30.md b/2020/info/30.md
index e568ce30..1d54ac13 100644
--- a/2020/info/30.md
+++ b/2020/info/30.md
@@ -19,46 +19,32 @@ URL: <https://github.com/akermu/emacs-libvterm>
<!-- from the pad --->
-
# Questions
-
## Q5: Does/will this work with 'emacs -nw'?
+Yes, it does.
-yes, it does
-
-
-## Q4: Thats a nice looking prompt, do you have it on a git repo we could see, or something of that manner? Thanks, I use bash right now so I didn't know it was the default on the others.
-
-It is not the default, but it is available easily with oh-my-zsh or similar on fish. I think the prompt is this:
+## Q4: Thats a nice looking prompt, do you have it on a Git repo we could see, or something of that manner? Thanks, I use Bash right now so I didn't know it was the default on the others.
+It is not the default, but it is available easily with oh-my-zsh or
+similar on fish. I think the prompt is this:
<https://github.com/sindresorhus/pure>
-
## Q3: Is there a plan to avoid the initial compilation step?
+Not any time soon. You will have to compile vterm the first time you
+start it.
-Not any time soon. You will have to compile vterm the first time you start it.
-
-
-## Q2: What are differences between Eshell and Vterm?
-
-performance
-
-Vterm is like xterm but in Emacs, eshell is like bash but in Emacs.
+## Q2: What are differences between Eshell and vterm?
+Performance. vterm is like xterm but in Emacs, Eshell is like Bash but
+in Emacs.
<https://github.com/akermu/emacs-libvterm#given-that-eshell-shell-and-ansi-term-are-emacs-built-in-why-should-i-use-vterm>
-
-## Q1: could you put your testing scripts up somewhere?
-
-256colors: <https://pastebin.com/j6HF5q8T>
-
-title: <https://pastebin.com/SByKdJM2>
-
-I cannot pastebin the 1MB of data, I pasted a sample of it: <https://pastebin.com/n1T3aUff>
-
+## Q1: Could you put your testing scripts up somewhere?
+- 256colors: <https://pastebin.com/j6HF5q8T>
+- title: <https://pastebin.com/SByKdJM2>
+- I cannot pastebin the 1MB of data, I pasted a sample of it:
+ <https://pastebin.com/n1T3aUff>
# Notes
-
-
<https://github.com/akermu/emacs-libvterm>
diff --git a/2020/info/32.md b/2020/info/32.md
index afabb47d..cc63fa0b 100644
--- a/2020/info/32.md
+++ b/2020/info/32.md
@@ -22,31 +22,27 @@ Elisp tools like generic functions, structs, and objects.
<!-- from the pad --->
-
# Questions
-
## Q3: Have you done any other projects using EIEIO and/or defstruct?
-
-"Right, EBDB is super deep into EIEIO, and was kind of written as a project for learning it, and the new gnus-search library is a more restrained usage. The search engines are defclasses, and much of the code is shared, which works quite well."
+Right, EBDB is super deep into EIEIO, and was kind of written as a
+project for learning it, and the new gnus-search library is a more
+restrained usage. The search engines are defclasses, and much of the
+code is shared, which works quite well.
-## Q2: Is there may activity on maintenance of gnus today? (and is Lars involved/aware of this work?)
-
-"Yes, there's still development going on. I don't think Lars is very focused on Gnus right now, but I run all changes by him first. He fixes bugs, but as far as I know, I'm the only one adding features right now, which is a terrifying thought."
-
+## Q2: Is there may activity on maintenance of Gnus today? (and is Lars involved/aware of this work?)
+Yes, there's still development going on. I don't think Lars is very
+focused on Gnus right now, but I run all changes by him first. He
+fixes bugs, but as far as I know, I'm the only one adding features
+right now, which is a terrifying thought.
## Q1: How much of this 90's funny code :) can be replaced and how much will have to stay forever?
-
-Eventually I think we can get most of it out of there. I was
-
-happy to be able to replace obarrays-as-hashtables with real
-
-hashtables, though that was a very painful process
-
+Eventually I think we can get most of it out of there. I was happy to
+be able to replace obarrays-as-hashtables with real hashtables, though
+that was a very painful process
# Notes
-
-
-Famous last words: "Sometimes the only thing that's worse than not knowing why something doesn't work is not knowing why it does work."
+Famous last words: "Sometimes the only thing that's worse than not
+knowing why something doesn't work is not knowing why it does work."