summaryrefslogblamecommitdiffstats
path: root/2021/talks/janitor.md
blob: ab903616b745a0a37dcebe16659cc841904c0716 (plain) (tree)
1
2
3
4
5
6
7
8
9
10









                                                                                 
 
 

                                                                  






                                                                          

            




                                                                         

                                                                      

                                                                      



                                                                    





                                                                        
                                                                        
                                                                  

                                                                    


                                                                      
                                                                   

                                                                    
                                                                     


                                                                     
                                                               


                                                                     
                                                                       



                                                                       

                                                                    

                                                                      
                                                                       


                                                                    





















































                                                                                                                                                                                                                                                                                                                                                       



















                                                                                                                                                                                                                                                                                                                                           







                                                                          
                                                             
 
                                                             
[[!meta title="A day in the life of a janitor"]]
[[!meta copyright="Copyright © 2021 Stefan Monnier"]]
[[!inline pages="internal(2021/info/janitor-nav)" raw="yes"]]

<!-- You can manually edit this file to update the abstract, add links, etc. --->


# A day in the life of a janitor
Stefan Monnier



[[!inline pages="internal(2021/info/janitor-schedule)" raw="yes"]]

Because of a reckless former Emacs maintainer that shall
  better stay unnamed, ELisp has seen a fair bit of churn in the last 10
  years, making it necessary to clean up "old" code [in order to open up
  the road for yet more recklessness? ].
  In this documentary we will follow a famous janitor in his every day job
  dealing with the aftermath of the cl-lib / lexical-binding party.

# 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 :)
- anyway, thanks for de-terrifying lexical-binding conversion in particular -- I think I might start pitching in there (I assumed it was a lot more paranoid and proof-based than this, which it seems like something I could do!)
  - what do you mean you don't search the entire space dominated by every funcall for uses of each var :)
  - God knows what crazy things users have done with either hooks or advice, and what vars they implicitly depend on :/
- Curious, is the Emacs you showed also your personal config, or one just for the video?
  - Understandable, I'd do the same.  I was curious to see what your real config looked like though :)
- oh that reminds me, thanks for pcase, it's amazing :)
- Oh that's fast. Compare to Linux: 16 years and counting (!) for the -rt patches...
- What's your opinion about tree-sitter? Is it possible to see something like paredit but for  non-lisp language?
- I suppose you can just ask "how old is this?" and it's the ancient stuff that is hardest to convert
- Hi Stefan, thank you for this very insightful talk, full of tacit knowledge. I've learned much also from your HOPL talk (and paper). Is there a world in which you could consider doing other short informal videos just to show your thinking and pass on such tacit knowledge to those that would be interested in getting into emacs-devel per se.
- May I ask a silly question?  I'm curious about your style of signing your mailing list messages, i.e. "Stefan 'who foo bar baz'"  Where did that originate?  :)
  - I enjoy it, the list needs levity like that :)
- (Also, I for one liked that you didn't use specialized tools, for precisely those reasons that it makes it more accessible to those just starting.)
- Would it be too off-topic to ask about ELPA?  I was thinking that it would be helpful to have a way to list packages on the site by last-updated time
- Is it possible to see metaobject protocol support in elisp?
- What features of the language/platform do you see as higher priority for future development? i.e. I'm looking for package pages that use the HTML-formatted readme from the patches we worked on, but I don't know which pages have been updated recently, so it's hard to find them :)
- could download counts be done?  Would that require the Savannah folks to code?
- Do you install packages from melpa?
- Stefan: Are you using native-comp already?
- Do you use Org much?
- Do you use magit?
- What are some of the improvements coming in future Emacs versions you're looking forward to?
- What's your opinion about Po Lu's recent patchs about GStreamer?
- Have you ever met any of the other Emacs maintainers or developers in person?
- How do you hack on installed packages? I mean installed packages are not a git cloned repo. But I want to commit changes and to see an immediate effect in a running Emacs. What is suggested workflow for this?
- What's Lars like in real life?  He seems like a fun person :)
  - oh is he tall?
- From your academic/research work, are there things you would like the elisp language or platform to evolve towards, even if medium-long term? Or is the long term path a different language(s) altogether?
- Do you personally use paredit?
- Do you lean toward Scheme-style macros rather than CL ones?
- What non-lisp languages are you looking at that we could possibly inspire from, if any?
- I'd like to see something like a with-gensyms macro to make them easier to use.  Dima Akater also has some ideas (and code) for enhancing defmacro in a similar way
- (hehe, yes i meant mostly  typed functional programming languages)
- Can namespaces solve some macro issues?
- are there technical difficulties in preserving that source code data associated with symbols and sexps?  or could something like defstructs be used simply to do that in a primitive way?
-so almost like a parallel macro/elisp implementation then?
- doesn't adding code/data distinction break homoiconicity?
- Could a Clojure-like metadata approach to extend the data be useful for this, and if so doable?
- fat cons cells sounds useful, could maybe be used to do CL-style VALUES too?
- even more tedious than janitorial work I suppose :)
- BTW, Stefan, I forget, are you Canadian/Quebecois, or do you just happen to live and work there?  :)
  - ah, so you are French?
- thought of another simple question to bombard you with :)  Do you mostly run Emacs from master, or other versions?
  - Stefan Monnier: I basically only use my own version, which tracks `master` with a bunch of local experimental & cosmetic changes
- elisp looks very much like a procedural language. Do you like it this way or maybe you wish it moving towards more functional/Scheme style?
  - Stefan Monnier: ELisp is halfway between imperative and functional, and I think it works rather well this way.  The usual style has evolved towards a more functional style.
  - Stefan Monnier: The ELisp implementation sadly isn't good enough to support a truly functional style, currently.
- Stefan Monnier: I tend to edit code as I read it, so my local changes probably accumulate to 1MB or so of patch, but most of it is purely cosmetic changes which I "should" push to master but can't be bothered to.

IRC:

- Question: Is there a place where these conventions and compilers checks are listed? A web page, an info perhaps? 
- Wow, I think you are going to have to know a LOT on Emacs development, versions, Elisp details, ... to do that kind of work.
  - One very helpful thing anyone can do is just confirm bug reports and add reproduction steps if they are missing.
- The double-dash is a convention for an func intended to be called internally only?
  - Yes.  `pacakge-foo` is public, `package--foo` is internal.
- mindless tree-wide transforms like this are what coccinelle is for. why are emacs maintainers still doing this by hand? you'd think lisp would be well-suited for expressing semantic patches to lisp... :/ this ceases to seem interesting when you've seen cocci do ten thousand transforms like this across a 500MiB tree in 20s or so
  - Does cocci work on elisp?
    - no, but the *idea* should work there, and Lisp is so regular in structure that something like coccinelle is the sort of thing lisp boosters say is really easy in lisp. but nooo, none exists that I know of :( (coccinelle itself is written in ocaml :) )
    - https://coccinelle.gitlabpages.inria.fr/website/
- There's a monstrous heap of regexps that match most reasonable compiler output.  I wrapped an ancient MS-DOS compiler for an obsolete language in a script that invokes it inside DOSBox and echos the output‚ and it Just Worked with compilation mode.
  - Wow, that's awesome! Yes, lots of the "historic" parts of emacs are amazing.
- if folks are interested in the lexical dynamic transition: https://hopl4.sigplan.org/details/hopl-4-papers/13/Evolution-of-Emacs-Lisp

Feedback:

- OK, this blows my mind in a sense that I realize that I really don't have an idea of coding Elisp.
- This talk is great. There should be more like that online, so more people learn to help with "janitorial" work

# Outline

-   ~20 minutes
    Here really, I'm not sure how much time this will take.  I put 20
    minutes because I think I might be able to fill that and I think more
    than that could turn too boring.  I intend to make it a "live coding"
    kind of thing, without anything like an outline: it's basically "make"
    followed by fixing the warnings.


[[!inline pages="internal(2021/captions/janitor)" raw="yes"]]

[[!inline pages="internal(2021/info/janitor-nav)" raw="yes"]]