Wait a sec..., did I just ask for paredit-convolute-sexp?

So, After years of lisping, and using paredit (feeling that paredit is not for me, and realizing that "if paredit is not for you, you have to become the person who paredit is for", and becoming that person), I found a need for a command I wish it existed, and turns out it did.

After getting used to paredit, you just love it and miss it in non-lisps. But there is this paredit command that is basically a big question mark. You read about it when you were learning paredit, it didn't make sense then, and you moved on with your life, barfing, raising, and splicing sexps.

So it just clicked today, (now that I'm back to lisp (clojure)). I was thinking "there should be a way to do this", and then remembered there are a few paredit commands that I didn't find use for when I learned about them. And Bingo! It's just one of them!: paredit-convolute-sexp.

So the situation where it's useful is when you want to "swap" 2 "wrapping macros".  By "wrapping macros" I mean any macro or special form that expects a body. Such forms are "let", "binding", "with-redefs", "db/transaction"... you know, all those.

And by "swapping", I mean changing who wraps who. Here's a before/after 

See? Instead of a "let" wrapping a "binding", we get "binding" wrapping a "let".

If the binding forms (the pairs in square brackets) live in the same line as the special form function (like the previous example), and if you would be using evil, you would just swap the lines with ddp and reindent. 

But if the binding forms live in different lines, it's not as straightforward anymore.   I hope you know where I'm going now...

Well, paredit-convolute-sexp helps in those situations. Your only task is to put the cursor in inner expression, exactly in the place where you want the split to happen: before the first form that belongs to the &body. Then you press M-? (now, I think I even "see" why the shortcut). And magic happens.

The movement and the results are weird to explain, but with proper examples, it is easier to get a feel for it. Just try it in different positions with code with lots of nesting.

Fast feedback loop with emacs (Lua)

Here's a long overdue post about emacs fiddling. All this belongs to my previous job time, during the past 3 years doing Lua.

One of the major test frameworks in Lua is Busted. It uses an rspec-inspired syntax and the cli accepts flags to filter the tests you want to run, by file and regular expression.

To iterate as fast as I could, I'd want to lock on a particular test, and be able to run that same test for a while. That's super useful while hacking on a feature or fixing a single test.

So the solution I came with was to use our beloved emacs, to find the current test the cursor is on, and remember it in a global variable. Of course, I want it in the most dwim-y way, so the same binding does "the right thing" most of the times.

Here's the decision making proces, that starts calling rgc-run-test (bound to f7):

rgc-run-test

If I'm in a *_spec.lua file, the process sets a global var with the current file path. The process also looks for the closest previous line to my cursor that looks like a test definition and sets another variable with the string of the test. To recognize the test definition, I match the lines against "it(", "describe(", or "it_content_types(". I use 'rx' library for that, which is pretty cool, check that out if you're doing complex regexes in elisp.

rgc-test-shell

After that, we find a buffer with a shell.

If there's none currently open, I create one, using the right parameters (so it lands on the correct directory).

An extra nicety is that I call 'highlight-regexp' with a string that will highlight any debug line.

You can enable (add-hook 'shell-mode-hook 'compilation-shell-minor-mode), making all shell buffers to run compilation-shell-minor-mode. That means that every line that looks like a path/to/source.file:line becomes clickable. That means that you can navigate to the source:line from a stacktrace.

With this, you can press F7 in a test file, and this snippet will make sure that a shell is in the right place (opening an existing one if it's already there) and will run the current test. 

But, many times, you are not just editing the test, but you're touching the code. No problem. F7 remembers the latest test you run when you were in a test file, so it will run that same test in case you're not in a test file.

When things seem to be solved, you then want to run the tests in that same file, but not restricting it to that single test, but run the whole file, to make sure you didn't mess up anything else. C-u F7 will do just that.

rgc-test-flags

Last cool thing. Sometimes I want to lock extra flags for the tests, rgc-test-flags is a quick way to overload the flags and keep them around for the next runs also.

ffap

Also, sometimes, the test errors in lua are marked like 'path/to/file @ 98'.  This makes find-file-at-point miss the line number.  But yeah, emacs. you defadvice find-file-at-point, with an extra case and off you go.

 That's it

I know this whole thing is quite hackish, and there's a lot to chew in just 50 lines, but this was so useful to me that I wanted to share before I forgot about it (changed job recently so I'm not using this snippet anymore)

It's this kind of workflows that the holistic approach of emacs allow for. And we love it so much :)

Here's the gist of it:

 

Interesting new-old takes on git

It seems there are a few things going on lately on the git subspace.

For one, ppl are talking about the mail flow vs Pull Request flow. It's interesting how people go back and forth on those: https://blog.brixit.nl/git-email-flow-versus-github-flow/

 Here's an interesting take at git flows again. Git plan focuses on writing the commit message before doing the commits. Maybe it's something to fix the issue/pr dicothomy?: https://github.com/synek/git-plan

And an experience report of using squash+merge for couple of years. That's interesting because it's what we are using at work, and even though I'm skeptical about its advantages, it's nice to see how people perceive the effects of squash+merge: https://blog.dnsimple.com/2019/01/two-years-of-squash-merge/

And a bonus of HN thread with some git helpers using fzf: https://news.ycombinator.com/item?id=26634419

a few cli tools

 New job, new tooling, and reinventing the same trick again and again :)

This time, a few things on console stuff:

• https://github.com/okbob/pspg
• https://github.com/rcoh/angle-grinder
• https://github.com/jpmens/jo
  

2 emacs lisp curiosities

So some guy wrote a story about emacs being used in some air traffic control system, because elisp. :) And another user (unrelated) showed off this amazing cl-loop in emacs. 

 2 elispy things that got me smiling this weekend :)

"When all you have is a Lisp ...

...everything looks like a recursive merge of trees"

It's been a little more than a month at Metabase, and doing Clojure is giving me again those deep recursive thoughts of seeing every problem as a recursive merge of trees.

I've looked at this python deep merge of dictionaries I used for some project at my previous $JOB.

And there are DSLs everywhere (sometimes, more than I think are needed).

And there's Specter, and Meander (https://www.reddit.com/r/Clojure/comments/loz77v/just_came_across_specter_mind_blown/ ) that use the code-is-data approach.

And just getting familiar with edn, that even it is very simple and minimal. It is malleable enough to be processed. 

I'm also working on a clojure version of gojira, that of course uses some tree merging.

Shell Oneliner Compression

I'm back to Lisp. Now, Clojure. For real. But this post is about zsh

Part of my relearning of clojure is to read and watch everything clojure that crosses my path. And I discovered https://github.com/clojure-cookbook/clojure-cookbook , which seems super useful.  But I have too many open tabs and books already. So I thought I'd do a 'Tip Of The Day' like thing, and I'd pop a different page every day.

 Relevant files have .asciidoc  extension. And the ones with content start with a number. The other ones are index pages or headers/footers.

Here's a version of what I typed. and it worked (at the second try!)


random-clojure() {
   e $(ls ~/clojure-cookbook/**/*asciidoc(.) | awk -F/ '$NF ~ /^[0-9]/' | shuf -n1 | xargs realpath)
}

Quite a lot of things going on there, so I'm gonna explain the oneliner, because there's a lot of compression there.

• e. e is my shellscript that opens files in emacs, moving to the line, and massaging input. in this case, it's the same as emacs, vi, $EDITOR.
• ~/clojure-cookbook/**/*asciidoc(.). This one expands recursively files that contain 'asciidoc'. excluding directories. '**/' means 'recursively' in zsh, and the '(.)' globbing is for files only.
• awk. '-F/' makes slash a field separator. Then, we pick the latest field, and we regex match it with '/^[0-9]/', beginning with a number. Cool!
• shuf -n1 picks a line at random
• xargs realpath. As we'll be running this function from all kinds of directories, expand the file path to an absolute path. as realpath asks for a parameter, we either nest the whole thing or use the xargs trick.

 

While writing this, I noticed that the whole thing is much simpler than that:

 e $(ls ~/clojure-cookbook/**/[0-9]*asciidoc(.)|shuf -n1| xargs realpath)