diff options
Diffstat (limited to '2021/talks/janitor.md')
| -rw-r--r-- | 2021/talks/janitor.md | 50 |
1 files changed, 50 insertions, 0 deletions
diff --git a/2021/talks/janitor.md b/2021/talks/janitor.md index 5fb6b78c..aa63e903 100644 --- a/2021/talks/janitor.md +++ b/2021/talks/janitor.md @@ -21,6 +21,56 @@ Because of a reckless former Emacs maintainer that shall # Discussion +Pad: + +- Q1: How did you narrow to two specific areas in a single buffer when + compering the two functions. I can be handy + - A:In this case I just split the window into 2. In other cases I + use \`M-x smerge-make-conflict\`. Oh wait, did you really mean + \"narrow\"? I don\'t use narrowing, I only use + outline-minor-mode (with reveal-mode to un-hide as I move) + - I will look into both work flows they look very handy. Thanks. +- Q2: Could you further elaborate on quoting functions with \#\'fun + (aka (function fun)) instead of \'fun (aka (quote fun))? + - A:Not sure what further elaboration you want (e.g. \"why?\" or + \"when?\") + - I would like why? Is it just style since Emacs understand both, + or not? + - The why is to be more explicit (i.e. a form of documentation, so + as a reader I can see that this refers to the function rather + than being just a use of a symbol for other purposes)). The + compiler knows about it and will hence give you a warning if you + refer this way to a function it\'s not aware of. There are also + corner cases where the two behave differently, mostly when + referring to a function defined via \`cl-flet\` or \`cl-labels\` + (or \`named-let\`, \...) + - Thanks! +- Q3: Stefan, you mentioned a lot of conventions, I really like to + read more about them: Where can I find a list of these conventions + (like \#\'function for functions )? Is there a page or info about + ELisp conventions used nowadays? + - A:Good question. We have several of them documented in the + ELisp reference manual (searching for \"convention\" should get + you there), but that only covers those conventions with which + Emacs maintainers agree. Others are much less clearly + formalized. I seem to remember someone collecting such + information and making a webpage out of it, but I can\'t + remember where nor who it was. + - Probably, + <https://github.com/alphapapa/emacs-package-dev-handbook> + - Thanks! I\'ll take a look at the reference manual and search for + this information. 👍 +- Q4: Stefan, that was really amazing to watch. After the changes you + made, how confident are you that the package still works as + intended? It seems as though there might be some room for errors + that the byte compiler wouldn\'t necessarily catch. + - A: I think for those three packages I\'m quite confident that + they should work as well as before. Not because the compiler + did not complain but because the changes were sufficiently + simple. Sadly in ELisp, I can\'t rely on the compiler to catch + errors. I can only use it ask it to point me to suspicious + code, and I know that it will miss some. + BBB: - I couldn't help but note that in the C world we are more and more making large-scale changes like this to the whole tree at once using tools like coccinelle. it feels like the regular structure of Lisp would lend itself to this very well... It feels like a better use of your time, is all :) |