> I can't see how this is functionally significantly different than EasyMotion[1] or Sneak[2].
from the readme:
> it maps possible futures, and shows you which key(s) you will need to press before you actually need to do that.
In the preview gif it's showing the matched hintkeys LIVE as you search.
I think this is actually a huge different in UX. I'm using the emacs equivalent in avy, avy-goto-char-timer[1], and that small pause between searching and acting (typing the hints) makes the experience jarring enough that I don't want end up using goto-char-timer in motions that much (only for jumping across windows and panes)
With no delay between <leap key> and <hint key>, the UX of d<leap key><hint key> is much smoother
If you type two keys and have to "select a label" as the README says, then you have to parse the screen to see what actually happened so you can decide what to do next. That seems to be what the parent commenter is saying slows one down.
This doesn't seem significantly different from, say, /<c1><c2><CR> and then hitting n to go to the next match until you've found what you want. It's only one more character than this project is claiming to require (the extra <CR>). With hlsearch enabled it also shows you matches as you type.
You don't scan the screen looking for labels. You are looking directly where you want to be and a label should appear over the place you want to go. That is the label you type to jump, you will never even notice the others or scan them.
My understanding is that the "parsing the screen" step is slightly pipelined with the "typing the keys" step, as the labels you have to read/pick between show up after you've typed the first character of the pair — so in the ~300ms it takes you to type the second character, you've already become aware of the labels, and are well on your way to parsing them.
This UX does not break my flow (it doesn't require focus/conscious thought):
1. Press <leap key> + <where to go key> while looking at the place I want to jump to
2. Hints are shown instantaneously (while I'm still looking at the place). Press <hint keys>. I'm there.
Been doing this for about a decade, it works nicely. Def recommend stows `--no-folding` flag (which prevents it from symlinking directories, just files)
The recurse center is a special place. I attended Jan-Mar 2020, before yeeting myself out of NYC (because wow, what a time).
It helped re-instill my faith in creative computing and reminded me that on the other side of the text there are people on keyboards doing the thing. I spent most of my time there messing with emacs (shoutout Eric+Zach @ emacs-nyc!), collaborating, and giving small talks on things like mpd and colemak -- you really are encouraged to share whatever you want (I remember someone's tutorial about home cultivated yogurt that was really cool).
My time there helped set the "hacker spirit" tone of my sabbatical (which I took with a goal of pivoting to being a hired clojure programmer), and drove me to write and share much more, one post of which even ended up here![1]
There is a lot of communication that comes for "free" with the physical space -- I was much more active in the zulip chat after my RC batch than I ever was during my time there. They have done a good job mimicking the physical experience in a virtual setting now though, and have iterated nicely on what makes a virtual experience different than the physical.
If you're curious about attending and can take the time, would recommend! (there's no cost): https://www.recurse.com/apply
hey all -- if anyone is looking for a modern hp calc lineup equivalent, I've been super satisfied with the HP15c clone I got from https://www.swissmicros.com/products a few years back. I was rather disappointed with the 2013 HP15c limited edition re-release. Hope this throws anyone feeling looking for something in $current_year on the right track.
It's very comfy. The client is close to the shell, and you can have both automatic and manual tiling modes. When there is some feature you like that the author did not account for, you can query the state of the world in json and make decisions based on that.
A comment here mentions herbstluftwm, which came before BSPWM and I would even call a sister WM -- Baskerville even announced BSPWM on the Herbstluftwm mailing list when it was initially released[2]. I would say BSPWM has less to think about than in the other window manager (everything is a node vs climbing frames with nested layouts). It can be thought of as a kit for building what you want, even. For instance, I use a tag-based workflow[3], where I toggle the hidden flag of nodes, and keep only one desktop.
WRT the windows being kept as nodes in a binary tree, this is useful because you can then climb the tree and perform balances and rotations within a subselection of the whole thing. You can also use the tree datastructure to enforce layout, like here[1], a DWM-like stacking layout.
With monocle mode, you can add fake padding for fullscreen windows, allowing you to have comfy fullscreen stuff that still accounts for a panel presence. With an external rules script, you can make decisions about what to do with windows as they appear, allowing dynamic layouts and decision making.
I'm sure at the end of the day, you can get what you need with any window manager if you drill far enough (year of the linux desktop is here, if you are willing to read the source). BSPWM has been a nice base for flexible workflow types for me. I will also share screenshots I've taken over the years here: https://notes.neeasade.net/rice.html (all bspwm past mid 2014).
Thanks for posting about this. Sharing urls/files/text/etc to termux is something I never thought about doing. I usually end up sharing urls to the gmail app and just sending it to my todo@ e-mail to go through later. I like your idea of sharing to a script in termux better though.
Is your script available somewhere? Is it just a simple "echo org-stuff >> capture.org"?
Looking at how insanely fast competent line staff are with terminal interfaces like in retail POS settings, I sometimes wonder if Emacs would be fast enough to keep up with them. If so, instead of using a browser as the base UI framework, would a terminal-screened Emacs (that is, in console mode or perhaps inside xterm, and not the graphical Emacsen) with an appropriate text UI library be feasible?
It can't possibly be worth the effort unless the text UI in the code is the only presentation layer, I'd imagine. But if you have to go down that route, it might be faster and easier than rolling your own termcap-based text UI, especially with all the elisp goodness within. The only extensive text UI I knew of was Vermont Views' product, which has since disappeared off the Net and was closed source anyways. There are some open source libraries, but none with nearly the power that came with that closed source offering, and all still quite low level.
I love emacs but I just can't get the terminal/shell options it provides to work as smoothly as I can with a proper terminal emulator. What would be perfect is if you could duplicate a terminal buffer for stdout/stderr but have the command line/stdin be in the mini buffer so as to leverage helm or ivy. To me, this would be nirvana.
from the readme:
> it maps possible futures, and shows you which key(s) you will need to press before you actually need to do that.
In the preview gif it's showing the matched hintkeys LIVE as you search.
I think this is actually a huge different in UX. I'm using the emacs equivalent in avy, avy-goto-char-timer[1], and that small pause between searching and acting (typing the hints) makes the experience jarring enough that I don't want end up using goto-char-timer in motions that much (only for jumping across windows and panes)
With no delay between <leap key> and <hint key>, the UX of d<leap key><hint key> is much smoother
[1] https://github.com/abo-abo/avy#avy-goto-char-timer