3 ms·

I agree that's how things are today. I get where you're coming from and I'm certainly not trying to take this away from you. My experience has taught me that t

• vidarh 5y ago
  > My experience has taught me that tools become better the more people use them and are able to participate in their creation and maintenance. The more user friendly a tool is, the more users you'll have. Personally, I think a tool can be very user friendly and still powerful enough for advanced users. I've taken the approach that rather than try to shoehorn my use into a full app, I aim for my text editor to be as small as possible, by reusing external tools whenever possible, as I do agree with you that it's worthwhile to have as much as possible of the code used by other people. But at the same time I realised there are editors smaller than my old Emacs config. So e.g. my editor relies on bspwm to split panes, and on rofi (or anything that can take a list of things to choose from and return the chosen thing) to select files or themes or buffers, Rouge for syntax highlighting, and anything that I can make generic enough I'm splitting into gems (the editor itself is written in Ruby). The way I see it, I want the editor to be a tiny little core that's mostly configuring other components. Currently it's about ~2.6kloc, but much of that is code that can be split out or will disappear as I clean some things up. I don't want it to get much bigger than that - preferably it'll get smaller. > I used a very similar setup to yours before I started Zellij! The reason I started the project was in order to be able to formalize such a setup (for me it was implemented as a soup of bash scripts which I dreaded moving to another machine, not to mention handing to another user). The big limiting factor for me with something like Zellij over my current setup would be having it work alongside e.g. Chrome and the occasional other gui app. > One of the things we want to do with Zellij is port it to the web and maybe even in the future to use it as a sort of "backend" to power tiling window managers. I'd be totally open to do this in a standardized way if maintainers of other tiling managers are game. If you provide a mechanism that allows a client to split panes already, then maybe the easiest starting point is for someone to just pick a config location/format tools can look for a command line to do splits in. E.g. on bspwm, the command given to split horizontally might simply be sh -c 'bspc node -p east ; exec #{cmd}' &. On i3wm, the same would be i3-msg 'split horizontal; exec #{cmd}'. Currently my editor just blindly executes "split-horizontal re --buffer numeric-id-of-the-buffer", and I have a "split-horizontal" script in my ~/bin. It'd be trivial enough to have it read a config file to find out what command to execute instead.