as much as i love nvim and understand people who love emacs, there are people who want that big gui thing. for those i’d recommend VSCodium if they feel like they really can’t live without VSCode or Gram for those who got to like Zed.
I was anti GUI for years. Having learnt to program on a tiny green and black 40x24 CRT on my old MSX back in the 80s. I remember being made fun of by fellow students and co workers alike for doing almost everything in the terminal. This included huge projects with complex file trees and lots of files.
But as time went on, I started to appreciate the GUI more and more. And these days I’m all for using a GUI for a lot of things.
Especially in IDEs that can do a lot of things with short keyboard shortcuts. I now have multiple monitors, including a large 32" primary. I always have stacks upon stacks of windows open and manage them efficiently. There’s always at least a couple of terminals hanging out and of course most IDEs also have terminal windows baked in. But all of the extra visual tools help me out a lot.
Almost the exact opposite for me. Used to hog GUIs and hated keyboard shortcuts with a passion, but then I came across Niri, fell in love with the idea, and the whole scrolling window manager thing made my productivity explode. I can’t use traditional desktop environments anymore. Tried to go back and literally can’t.
and the whole scrolling window manager thing…tmux wasn’t that far behnd
I remember one time reflecting on how many layers I have at which one can expand workspace.
Linux virtual terminals. By default, Debian runs 7 login sessions on seven virtual terminals and sticks the GUI (Wayland/Xorg) on the eighth. So Control-Alt-F1 through Control-Alt-F7 will get me a Linux terminal. I can stick more programs on more virtual terminals with openvt. That’s the first layer.
Okay, so on virtual terminal 8, I’ve got Wayland running. On that, I’m running Sway. That has an infinite number of workspaces that can be created. Currently, I only have bindings set up for 10 (and I use nonstandard bindings for them, Super-q N to switch to the Nth workspace) because I didn’t find myself actually using named workspaces. This is the second layer.
Within a workspace, I can have Wayland windows. Say I can have two or three windows reasonably visible. This can be expanded whenever opening a window; for example, Super-t to open a new virtual terminal emulator window. This is the third layer.
One of the most common windows I use is a virtual terminal emulator, foot. That can run a program. I typically have it running tmux, which can have its own list of concurrently-running terminal programs (I use Control-O as the tmux meta key). This is the fourth layer.
I often use emacs. Emacs has multiple “frames”; one can “clone” the current frame with C-x5 c. When run in a terminal, this basically acts like another tmux-like layer where one shows one frame at a time. This is the fifth layer.
Inside an emacs frame, one can have multiple emacs windows (analogous to what is typically called “panes” in other software) showing various things at the same time. One can open a new window with C-x2 or C-x3, cycle with C-x o. This is the sixth layer.
Emacs has a list of buffers, any one of which can be shown in a given emacs window. A “buffer” is vaguely analogous to “an open file” in some other programs, but could also be showing a terminal emulator or similar. One can switch with C-xb. This is the seventh layer.
Say I’m running a terminal emulator in one running bash (M-x term RET RET). bash has its own job control; one can suspend a running program and bring bash to the fore with Control-Z, list running jobs with jobs, then resume a suspended job in the background with $ bg %1 to background the first or bring a job to the foreground with $ fg %1. This isn’t quite the same thing as the other layers, since the screen state isn’t maintained for separate programs and restored, but it can reasonably allow one to run simultaneous things and follow each. This is the eighth layer.
Noping the heck outta that. All I want is better top-level organisation, you just described what I’d call an anti-pattern in my book.
I wouldn’t nest things that deep through so many different tools/framework/layers that can’t talk to one another. That’s just asking for trouble. You’d waste one of two things: time searching or focus for memorising and recall, you lose something either way. And in the case of the latter you’re bound to forget and start wasting time to search over time anyway.
as much as i love nvim and understand people who love emacs, there are people who want that big gui thing. for those i’d recommend VSCodium if they feel like they really can’t live without VSCode or Gram for those who got to like Zed.
I was anti GUI for years. Having learnt to program on a tiny green and black 40x24 CRT on my old MSX back in the 80s. I remember being made fun of by fellow students and co workers alike for doing almost everything in the terminal. This included huge projects with complex file trees and lots of files.
But as time went on, I started to appreciate the GUI more and more. And these days I’m all for using a GUI for a lot of things.
Especially in IDEs that can do a lot of things with short keyboard shortcuts. I now have multiple monitors, including a large 32" primary. I always have stacks upon stacks of windows open and manage them efficiently. There’s always at least a couple of terminals hanging out and of course most IDEs also have terminal windows baked in. But all of the extra visual tools help me out a lot.
Almost the exact opposite for me. Used to hog GUIs and hated keyboard shortcuts with a passion, but then I came across Niri, fell in love with the idea, and the whole scrolling window manager thing made my productivity explode. I can’t use traditional desktop environments anymore. Tried to go back and literally can’t.
Tmux wasn’t that far behind.
I remember one time reflecting on how many layers I have at which one can expand workspace.
Linux virtual terminals. By default, Debian runs 7 login sessions on seven virtual terminals and sticks the GUI (Wayland/Xorg) on the eighth. So Control-Alt-F1 through Control-Alt-F7 will get me a Linux terminal. I can stick more programs on more virtual terminals with
openvt. That’s the first layer.Okay, so on virtual terminal 8, I’ve got Wayland running. On that, I’m running Sway. That has an infinite number of workspaces that can be created. Currently, I only have bindings set up for 10 (and I use nonstandard bindings for them, Super-q N to switch to the Nth workspace) because I didn’t find myself actually using named workspaces. This is the second layer.
Within a workspace, I can have Wayland windows. Say I can have two or three windows reasonably visible. This can be expanded whenever opening a window; for example, Super-t to open a new virtual terminal emulator window. This is the third layer.
One of the most common windows I use is a virtual terminal emulator,
foot. That can run a program. I typically have it running tmux, which can have its own list of concurrently-running terminal programs (I use Control-O as the tmux meta key). This is the fourth layer.I often use emacs. Emacs has multiple “frames”; one can “clone” the current frame with
C-x 5 c. When run in a terminal, this basically acts like another tmux-like layer where one shows one frame at a time. This is the fifth layer.Inside an emacs frame, one can have multiple emacs windows (analogous to what is typically called “panes” in other software) showing various things at the same time. One can open a new window with
C-x 2orC-x 3, cycle withC-x o. This is the sixth layer.Emacs has a list of buffers, any one of which can be shown in a given emacs window. A “buffer” is vaguely analogous to “an open file” in some other programs, but could also be showing a terminal emulator or similar. One can switch with
C-x b. This is the seventh layer.Say I’m running a terminal emulator in one running
bash(M-x term RET RET).bashhas its own job control; one can suspend a running program and bring bash to the fore with Control-Z, list running jobs withjobs, then resume a suspended job in the background with$ bg %1to background the first or bring a job to the foreground with$ fg %1. This isn’t quite the same thing as the other layers, since the screen state isn’t maintained for separate programs and restored, but it can reasonably allow one to run simultaneous things and follow each. This is the eighth layer.Noping the heck outta that. All I want is better top-level organisation, you just described what I’d call an anti-pattern in my book.
I wouldn’t nest things that deep through so many different tools/framework/layers that can’t talk to one another. That’s just asking for trouble. You’d waste one of two things: time searching or focus for memorising and recall, you lose something either way. And in the case of the latter you’re bound to forget and start wasting time to search over time anyway.