So I wrote a little function for how I use eat.
In eat, you can have multiple terminal buffers open, and they are differentiated by incrementing numbers. The official way to open an additional buffer is to run eat with a prefix argument like C-u M-x eat. I wrote my little function to do this for me, because I don't use prefix arguments/C-u anywhere else and just couldn't remember it.
So this function checks the buffer list for existing eat buffers. If there is one with a number at the end, it takes this number, increments it by one and then opens a new eat buffer with this incremented number. If there is just one without a number, it opens a new buffer with the number one, since the first buffer is created without a number per default. If there is no eat buffer at all, it just calls eat to create one. This is the function:
(defun eat-more ()
"Open a new terminal"
(interactive)
(if (match-buffers "\*eat\*")
(if (string-match ".*<.>" (prin1-to-string (last (match-buffers "\*eat\*"))))
(eat (funcall eat-default-shell-function) (+ (string-to-number (substring (prin1-to-string (last (sort (match-buffers "\*eat\*")))) -4 -3)) 1))
(eat (funcall eat-default-shell-function) 1))
(eat)))
This works as intended, but the line getting and incrementing the buffer number looks really awkward. So my question is: How could I improve that to make it more readable without changing the logic completely?
There are probably shorter ways to do this by just calling eat with a prefix argument in the function itself, or something like that. But I am interested in interacting with the buffer list and all this nested string slicing and converting feels off. The actual eat function is defined here in eat.el Do you have any suggestions?
meshtastic very quickly runs into problems with congestion. at around 100 users in a local mesh it becomes super unreliable and in urban areas it is really hard to use. meshcore (a separate network) tries to fix some of that, but is still tied to lora devices and super low bandwidth.
reticulum is not as mature yet, but its protocol is completely transport agnostic, meaning you can mesh almost anything from bluetooth and local wifi to lora, fibreoptic cables, packet radio and telegraph lines. and most importantly: it is a whole new networking stack, not just a single app like meshtastic/meshcore