Perhaps the focus on tiling wms is a justification for not having tabbing/splitting support built in.
Also, given xorg-dev dependency I assume that if one is on wayland, they are better off using alacritty.
Perhaps the focus on tiling wms is a justification for not having tabbing/splitting support built in.
Also, given xorg-dev dependency I assume that if one is on wayland, they are better off using alacritty.
I can copy around 500 lines of logs this way. Quick and dirty.
Other than that IDK.
And about the tabbing and splitting. I got tired of all the terminal emulators I like not supporting it, and some contexts not supporting paging, and not having a nice way to review a long running process, and took the dive to learn tmux.
Tmux. A terrible solution to a bunch of stupid problems. Highly recommend.
I'm clearly not smart enough to do it without having to think about the process every time
cat file.txt | pbcopy
This adds the contents of file.txt to your clipboard.What could they do instead? There's so many trivial solutions. A clipboard named pipe for instance, or at least something that operates like one. Read is paste, write is copy. That's a very 1970 style fix that could have been done 35 years ago. Then anything that can read and write from a file can interface the clipboard, opening up a whole new array of applications without setting aside "highlighting text" as having some special magical power.
Also having multiple clipboards is trivial, just have more of these special files. You can even set one aside if say some crazy old Xt application someone is still running only works with copy-on-select for some reason
A clipboard history is super trivial as well, just set up a pipe...
There's so many more unixy ways this could have been done. It's so dumb how it works. Heck dbus would be a less insane fix
reading yoru entirely comment, I am not entirely sure if you mean changing how it's implemented or if you really would like to get rid of the user interface it has.
Because copy-on-select along with middle-click-to-paste is like ... the best thing. Tiny bits of data stuck that follow your cursor is the most information-at-my-fingertip feeling that I can get out of these machines.
I've hated this feature for 25 years. I run up against the design flaws of this limitation alone usually multiple times a day. From websites that try to have some funky JavaScript convenience (including nearly impossible to use things like medium) to applications that want to select the entire thing and destroy the clipboard as I'm trying to put something in. UX limitations and bad design make it utterly useless constantly.
The whole paradigm is broken. From applications that just select the entire document when you're one pixel off the line of selection, as if anyone has ever asked for that, to application interoperability with anything more than text, parity with windows OLE from around 1993, being still a total pipe dream. Drag and drop is still totally dependent on what toolkit the two programs you're using was written in.
That's nonsense! It'd be like a world where I can't pipe say output from python as input to a bash script because they were implemented in different languages and people would be like "welp. That sounds right. I don't see a problem here"
Also the world of programmers have decided they can go around randomly selecting shit to try to make my life dealing with clipboards easier even though it just makes it utterly unusable. I'm not going to go on a crusade to personally win that fight on a program by program basis. It'd be so much better to have flexibility on how clipboards work
Things could be amazing but instead we defend it being terrible.
Here's an example. Imagine where I can not only do basic asks like drag from inkscape to figma but also have something I'll call a "transport station" where I can drag things into a dock to share them with colleagues who can receive them and then put it into their application of choice, in a non-destructive, non-disruptive way that maintains the flow of productivity. Sound like a smooth and fantastic collaboration tool? I agree.
I've tried to make this, there's lots of fundamental problems that ought not exist. That's the power an unbroken clipboard could have.
What do you do with computers where you don't viscerally feel these limitations daily?
I will grant you that the situation concerning copy/paste as a whole is "not great", I have certainly run into issues before. But this interaction where selecting a word either by dragging a mouse along some text, double or triple clicking to select and then being able to paste this text somewhere else just by pressing the middle-mouse button is just really god computing.
Crucially: This is a very local interaction that does not interact with my clipboard at all. Which lets me copy two things at the same time. I use this all the time for copying/pasting username/password combos.
But that reminds me - the correct way to do this is setting up my password manager to do it for me...
I am interested in the "transport station" you described. I am currently trying to find a way to seamlessley working on multiple computers at the same time, and a shared clipboard like that would be really iteresting. Also to synchronize to my phones' clipboard. Do you have some already written notes on the issues that you ran into ?
No problem copying a few MBs of output this way (100,000 lines for instance).
Learn what’s possible in Vi mode from the key_bindings section of the alacritty.yml config, largely the ones with `mode: Vi` and similar. You’ve got the usual things like hjkl navigation, Ctrl+B and Ctrl+F to go Backwards and Forwards a page, / to search, all that sort of stuff. (Though I will note that ? to search backwards doesn’t work, because Alacritty is using winit’s currently utterly insufficient keyboard API for its bindings, see <https://github.com/alacritty/alacritty/issues/5251>.) Also in alacritty.yml, scrolling.history defines how many lines are kept in the buffer (defaults to 10,000).
- Doesn't do any kind of tabs, or split view, or switching between different "buffers", under the assumption that you use your window manager for that stuff
- Always fills the entire window with the contents of the terminal, regardless of what size the window is (e.g. non-integer multiple of size of a character cell), and doesn't draw its own window decorations
- Launches very quickly
- Generally has a flat, minimalist aesthetic. Uses (ideally configurable) keyboard shortcuts instead of a toolbar, menu bar, or right-click menu, and is configurable by editing a file.
Some terminals are like this already, and I don't know how well Darktile lives up to it. But it's a very different design direction from, say, GNOME Terminal.