Cypress, React and Emacs backup/lock files

 So I'm dealing with some javascript lately, and it took me a while to figure out that some of the javascript tooling ("cypress open", or "yarn start" a react app) fails to refresh correctly (in fact exits with an exception) every time you modify a file that it is watching.

So, if autorefresh is "on", you can't touch any file.  Not good.

Found out that the cause of those failures are both emacs lockfiles and backup files. They are created in the source directories, and then, js tries to load them, or to examine them somehow, and js falls flat on its face.

(setq make-backup-files nil  

         create-lockfiles nil)  

That should do it.

Show other revisions of a file with magit

Magit proper offers magit-find-file and magit-find-file-other-window, that ask you for both revision and file. At least they autocomplete with sane defaults. 

The thing is my usecase is 99% "current-file in previous-branch in a split window".

As easy as

(defun rgc/magit-find-file-dwim ()
  (interactive)
  (magit-find-file-other-window (magit-get-previous-branch) (buffer-file-name)))

You get a nice command to open the current file from the previous branch you visited in your repo. 

Often, next immediate  command is m-x ediff-buffers RET. (yeah, maybe adding that would make it even more dwim).

If you'd want to do it in the command line, something like 

    git show branch:file

Would do, but you'd have to type both branch and filename.

 

Current file name on emacs's shell-command

When I came from vim to emacs, I wanted to get my ":!perl %" command in emacs. I found that by default, there was no symbol bound to current-file-name in the shell-command minibuffer.

One of my first emacs hacks was this snippet (git blame says I added it in 2013)

The other day, in some reddit thread, I found shell-command+, which does this and a bit more. Super cool that it also uses '%', inheriting the vi tradition. And I can retire now my old code.

Speaking of '%', did you know that typing '%' in your firefox address bar will narrow the completions to currently open tabs?  A-MA-ZING. More cool shortcuts here.

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:

 

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 :)

org, roam, zettelkasten links.

Here we have a couple of links talking about the new wave on PIM, bookmarking, concept-linking.

It used to be the case that each one of us had a smilar but not quite the same system. But it seems that zettelkasten, and roam are getting some gravitational pull so people are joining them.

Usual links are org-roam, zettelkasten, and another link to zettelkasten-in-plain-org

An emacs' Feature Development

So, in https://lists.gnu.org/archive/html/emacs-devel/2020-10/msg00691.html there's a proposal for an optimization in emacs, adding empty-directory-p so that elisp users don't have to (null (directory-files dir-name nil 'nodots t))).

And it makes sense to have a faster way. The person that proposed this improvement proposed a solution too. And it was a good one!

Then, Eli proposed something else. Some alternative implementation that:

• Allows to solve the problem at hand, 
• Reuses existing code by adding a 'limit' to directory-files
• Easier to implement
• Makes the implementation more stratified. You can still create empty-dir-p by calling directory-files
• in case of passing that limit count to directory-files, we still get a list of files instead of a boolean. It's richer information, in case we need it.
  

After that, the conversation goes on by trying to figure out if the partial list of files will be useful at some point, or it's adding indeterminism and no value, and finding a balance on simplicity and usefulness. 

All in all, a very good end-to-end conversation about a feature, its implications and its implementations with its corner cases and usability. Every time I see these conversations happening I feel this joy... I love when they happen in my team.

PS: Needless to say, this is a "simple" feature compared to bigger and more complex discussions going on in emacs-devel (which are hard problems that have no perfect solutions). But it's a good case study and there's something to be learned there about approaches, discussions, and building together.

Thanks to everyone involved!

tangling files with org-mode

I've been inspecting this repo https://github.com/kinnala/nixpkgs, and it was the first time I looked at the org tangling. Quite simple to do so:

Mostly using ":mkdirp yes :tangle path", is like doing a "cat block >>path". And you use (org-babel-tangle) as the exporter

#+begin_src elisp :mkdirp yes :tangle ~/.emacs
(org-babel-tangle)
#+end_src

Recreational vimming

When I have to do some sort of development or file editing inside a container, I usually have vim there but not emacs. docker-tramp is very useful but sometimes I just want to edit there.
The .vimrc I have in my container has only one line (I can't function without it):

imap jk 

Let's say I'm editing a lua script. After I've saved and c-z and run the file several times, I realize what I want is to have is:

:nore ,rr :!lua %

Then I can test it much quicker. But I realize I'm always :w before,rr. Colon, up, and modify the line to:

:nore ,rr :w:!lua %

Accidentally I quit vim and realize I have to set that again, so I go to my vimrc and add this:

nore ,rr :w:!lua %
nore ,vimrc :e ~/.vimrc
nore ,so :source ~/.vimrc

With this I have a pretty nice way to iteratively finetune my config. After some lua editing, the only thing I need to do often (and not provided by the excellent vim default functionality) is to comment and uncomment code.

nore ,cc :s/^/--/
nore ,cu :s/^\( *\)--/\1/

This gives normal and visual comment/uncomment functionality, and enough interactivity to build your ad-hoc shortcuts as you go.
This is an example that just happened yesterday, and the nice thing is that it grows and flows from 0. I couldn't get to this amount of functionality from an emacs -Q in such a small time. It has such a different feeling to configuring emacs. It reminds me of my Perl days, it's fun and quick. And the language is very orthogonal, with very few abstractions. It's the APL of text editing.

This is my take on this reddit thread. 

Simplicity is its own reward

This is 3 top level hackers discussing about a patch that Stefan proposed to an already solved problem (I guess originally by Daniel, or someone else, but Daniel is anyway the father of the pdump feature).

Amazingly classy and to the point. All 3. I'm learning so much reading this maillist. And still a lot to learn.

Bravo, and thanks.


Stefan Monnier: >> Any objection?
>
Eli Zaretskii: > What are the advantages?  The original problem is solved, and
> everybody agreed that having a dead buffer in the pdumped area is
> nothing we should bother about.
>

Daniel Colascione: With Stefan's patch, Emacs is simpler. Simplicity is its own reward.

Original thread: https://lists.gnu.org/archive/html/emacs-devel/2020-03/msg00922.html

TRAMP with docker is awesome

There's this recent post in reddit where the author shows how to chain tramp connections. And it's great indeed!

What I'm using TRAMP more often for is to login to containers.

Using docker-tramp, I usually browse into a docker and start dired there. But then, I can open a shell (or eshell if there's no bash) there.

And, for example, if you run a postgres container, why not opening a `sql-postgres` buffer?.

Just:

docker run -e POSTGRES_PASSWORD=a -e POSTGRES_USER=rgrau -ti --rm postgres

and when dired-ing through tramp, m-x sql-postrgres using the appropriate params.  Tada!

Neat, ain't it?

Happy hacking, and stay safe.

spicing up your prompt

I've been using this very silly overloading of the prompt for some time, and even though it's dead simple, it gets to cheer me up sometimes.

On every emacs startup, and every 24 hours, you get  a different message on your prompt when 'm-x'.

Happy hacking,

Latest Awesome Emacs Developments

In the last month or so, a great wealth of new Emacs stuff has been developing in both core and community.

We know that in free software projects (communities, that is) some branches might take a long time to develop, but some others

tree-sitter: Integrating this project opensourced by github. This could mean a new way of syntax highlight that doesn't drag, smarter indentation, and completions. Eli mentioned it in the emacs mail list and people are looking into it.

Yet another jitter, by Andrea Corrallo.  Another approach to make emacs' elisp code run faster.  There have already been many attempts to this (Guilemacs, "El Compilador", and others). Will this be the one?  From the highest level perspective, I like "el compilador" the most, because it's kinda smalltalkish, but hey,... I don't have the knowledge to hack on any of those, so whatever the wizards pick, I'm good with it. Also, see mailing list.

SystemE : Replace Systemd with runit? nope, geekier.

Emacs Application Framework because you can also have proper gui controls.
 
Animations in elisp (text)

OM. higher level org parsing

doct declarative org-capture templates.

Emacsconf 2019!

Emacsconf last Saturday was a blast! I planned to attend for a couple of talks and ended up staying the whole day!

Quite interesting talks, made by passionate contributors, cutting BS to 0, and somehow the talks were broad enough to take something from each one of them.

Even digressions in the irc channels were also interesting. Of course, the tribe that joins a saturday on an irc channel and a video streaming of emacs stuff for 9 hours, we're more than ok to discuss about window managers, programming languages, and all sorts of emacsy geekyness not entirely related with the talks. There was a very good vibe there.

A couple of talks focused more on the meaning of emacs as an FSF flagship, and the political meaning of the project. Very important to note that in a gathering of emacsers. I sometimes forget that emacs is as much of a software artifact than a political statement.

Jitsi behaved ok for 70% of the time, but the first 30% was a bit worrisome.  Connection dropping and audio cutting was a bit frustrating. The organizers did a great job solving those (I can imagine the stress), and they had the "recorded lightning talks" card up their sleeve.  Kudos to them, and to JohnW who got most of the jitsi difficulties in his turn :/.  Luckily he was calm and patient enough to flyby those hiccups and the message went through ok.

Annnnd the closing keynote.  That one gave some food for thought...  Better html support, different implementation language (learning from Remacs?) different extension language, looking at vscode in depth, attracting contributors, bug reporting....

Thank you everyone involved in one way or another. Organizers, speakers and attendees.  I had a great Saturday :)

Migrating from vim (proficent) to emacs

In HN's thread about 26.3 being released (Congrats!), there's this guy  explaining that being already quite confortable with vim, it's too much of a commitment to move to emacs.

I remember the frustration when coming to emacs from an advanced vimmer POV: no "yyp"? no ":%s/foo/bar"? imap? But here's what I answered him:

As this is not an overnight conversion and you are quite proficent with vim already, my advice is to:

- Get used to type "emacs file.txt" instead of "vim file.txt" in your console.
- Have a function in emacs that opens the current file in vim for those moments where you just want your trusted environment. Writing it by yourself is a good focused learning experience.
This way you'll decide (and balance) how much you want to learn every day, and little by little you'll find yourself using that function less and less.

And I think this goes very well with my other "bootstrap your emacs lisp learning".

It's the same approach to most of my development (and life) efforts.  It's a function of how bad do you need it, how fast do you want it, the compound interest of starting early, and how much it slows you down (or blocks you for doing other things).

ncdu vs dired-du-mode

ncdu a very nice utility that does what you probably want to do when you do 'du -sh *'  repeatedly in different directories.

ncdu allows for navigating through the directory structure seeing sizes and disk usage percentages of files and subdirectories. Also, has vi-friendly keybindings.

Of course, there's a way to do a very similar thing in emacs, which is using `dired-du-mode`. Take a look at the "c-x c-h" keybind to toggle human friendly numbers, and m-x dired-du-count-size to aggregate the sizes of all marked files.

preview files/links without changing the focus

I realized today that there's a consistent way (although not very intuitive to me) to peek (preview) a destination of a clickable thing without opening it. 

It's "C-o".  Of course, it is very useful for browsing and exploring purposes.  Just try it in dired, occur, ibuffer, rg, and probably many more.

In most of those modes "o" "opens" a buffer on the destination and gives the focus to it, so I guess "C-o" makes sense, it's just I'm so used to hit RET that I never think of "C-o".

Anyway, I hope you find this one helpful

emacs 26.2 as a birthday present

Emacs 26.2 has been released in April 12th, matching my 36th birthday, 

Appart from this coincidence, it's the first emacs release that has any code of mine, which makes me extremely happy. I only contributed 2 tiny bugfixes, but nonetheless I'm very happy about it :D

emms ftw

I never got into the Emacs MultiMedia System, but just read that it has support for streaming radios so I gave it a try. And you know what?  It's awesome.  I'm adding all the radios I have in my radios repo.

But you already knew that.

Only a few concepts/commands:
- m-x emms-streams RET
- m-x emms RET
- c-+ + + +
- m-x emms-add-dired RET

Enough to get by and start using it.