Smartenter
I've been busy with a number of (unfortunately more important) things, and haven't really put much effort into z in the past few days. I did put a bit more thought into smartenter, however, and have come to the conclusion that I must put it on hold for now. As much as I would like to polish it up, one thing stands in my way that would make z a better investment in my time - command history. If I code z correctly, it should be able to behave much like smartenter does now, but I probably still won't make much use of it.
The problem is really a fundamental issue with fish. I wouldn't call it a problem with fish, just an issue. A fundamental principal which is preventing me from moving forward with my script, the sort of script that will rarely ever come up. Because, generally speaking, we just want our enter keys to execute whatever we've typed on the line. Fish is, by design, fairly minimalist in a lot of senses. It doesn't replicate *nix builtins with its own builtins. It doesn't allow for much configuration, it merely gets the defaults right for (I would guess) 99% of use cases. This is what makes fish an amazing shell, but also makes it so that I can't write my (admittedly strange) function.
Because, you see, (and I have never tried this in any other shell, mind you) command history is stored inside an environmental variable, $history. It's automatically updated on an 'execute' command, which is only ever evoked by a keypress. Now, smartenter reads the command line and sets it to some little variable, executed later using 'eval.' In a perfect world, I could just 'set history $history $command,' but unfortunately, $history is read-only. This makes perfect sense, in general you don't want to muck with the command history, and you certainly don't want to do so by accident. Still, I'd love it if fish had a switch for 'set' that would allow one to write over a read-only environmental variable. At my own risk, of course!
I've run into a few other fish quirks during this whole process, which I already mentioned in my previous posts. Namely, odd behavior calling (so far, just dc) via 'eval.' Also, some hassles with regard to what calls what (trying to run (builtin?) functions via eval, for instance, seems to fail). This all adds up to some generally weird behavior behind what I still believe is a very useful proof-of-concept. Yet, the quirks, the bugs, whatever… they make it so that currently I can't really conceive mapping smartenter to enter, and in fact would prefer to map it to opt-enter, or instead just use my ctrl-a binding until I get z perfected. I will try to make contact with the developer of fish, see if I can't pick his brain a little. But ultimately, the reason that fish is failing me is also the reason that I love fish 99% of the time. Regardless, hopefully the next time I speak of Unix job control, the topic at hand will be a working version of z.