My environment is almost exactly identical to what you described, sark02, though honed over only 25 years. It's nice to know that I'm not alone.
The one difference is that I go for the bling: I use title bars. :-) More seriously, I find them useful for more quickly identifying which window has the focus after I've switched desktops (I have F1-F12 bound to switch to fvwm2 desktops 1 through 12) and for displaying status information: hostname, SSH key agent status, current working directory and an optional name for the window (typically "edit," "build," "doc" etc. which allows me to find it quickly in the window switch menu on those occasions where I use it). This allows me to keep my shell prompt very clean (just the exit code of the most recent command, if non-zero, followed by a `$`) and it's still easily visible near the prompt in most cases because my title bar is at the bottom of the window.
I use Thinkpad keyboards (both on laptops and in their stand-alone version) becuase the TrackPoint on the home row, while not as accurate as a mouse (which I often use in addition), makes it
very quick to change focus between windows. I also use the Japanese layout, which offers several extra keys; the ones on either side of the space bar I press with my thumbs and are bound to the window list menu (shifted for windows on all desktops), window ops menu (with many shortcuts for, e.g., moving a window to a specific position or another desktop, maximizing in the vertical direction only, setting window width or height to specific value, etc.) and "system" menu for starting applications and the like (used most often for opening new terminals, which takes just two keystrokes).
Some consideration of what I've ended up with in this area and discussion with proponents of tiling window managers has brought me to the conclusion that for most tiling window manager users the valuable part is not the tiling but having easy, short key sequences for managing the appearance/disappearance and location of windows. I now feel that a stacking WM, if given similar keystroke features, is clearly superior because (if configurable and configured correctly) it can give you all of that without forcing window size changes in order to change what you're viewing. It's often useful to be able to see a just bit of a large window (say, the left twenty characters of one scrolling a log file) without it wrapping the lines at a ridiculously short length; when you need to see the whole window you can just bring it to the top (two keystrokes), read what you need, and send it back to the bottom again when done.
You can find my fvwm and lots of other desktop/GUI config in the
cjsdesktop repo for my "dot-home" system.
___________________________________________________
This thread might be better termed "preferred desktop environment" if intended to be limited to that; on reading the title I'd assumed it was about what development tools one uses. In that area I avoid IDEs (they're too difficult to program in more than the most trivial ways, and tend to waste screen real-estate) and stick with vim and a Bash command line. My build/test scripts can get pretty sophisticated and generally offer specific options for easily selecting exactly what I want to test so that I can keep my edit/test cycle as short as possible. I'm a total convert to pytest for unit tests because they instrument the AST automatically to show you intermediate values and also automatically do "diffs" of large data structures, meaning you can just `assert` any expression and it will deal with taking it apart for you and showing you what bits in it were unexpected, avoiding specialized asert functions and manual work to do that. I even use pytest for unit testing assembly language; my framework (still in the early stages of development, but visible in my [url=https://github.com/0cjs/8bitdev]8bitdev[/ur] repo) allows me to load a binary into an emulator, deposit values using local or global symbols, call a subroutine with specific register values, and then examine and assert the results. Here's an example of a test fixture used to load the binary code and fourteen tests (via parametrization) of a routine that converts an ASCII digit to a binary number, setting the N flag to indicate a bad ASCII char:
Code:
@pytest.fixture
def M():
M = Machine()
M.load('.build/obj/bigint')
return M
@pytest.mark.parametrize('char, num', [
('0', 0), ('1', 1), ('8', 8), ('9', 9),
('A',10), ('a',10), ('F',15), ('f',15),
('G',16), ('g',16), ('Z',35), ('z',35),
('_', 40), ('\x7F', 40)
])
def test_convascdigit_good(M, char, num):
M.call(M.symtab.convascdigit, R(a=ord(char), N=1))
assert R(a=num, N=0) == M.regs
And here's an example of the output, after deliberately changing one of the tests above to have a wrong expected value:
Code:
$ ./Test src/bigint_test.py -k ascdigit_good
......F........ [100%]
=================================== FAILURES ===================================
_________________________ test_convascdigit_good[F-16] _________________________
src/bigint_test.py:25: in test_convascdigit_good
assert R(a=num, N=0) == M.regs
E assert 6502 pc=---- ...sp=-- n------- == 6502 pc=100F ...sp=FF nv--dizC
E At index 0 diff: None != 4111
E Full diff:
E - 6502 pc=---- a=10 x=-- y=-- sp=-- n-------
E + 6502 pc=100F a=0F x=00 y=00 sp=FF nv--dizC
1 failed, 14 passed, 48 deselected in 0.47s
Note that for the register set objects (constructed with `R` above) I implemented no special support for the test framework: just an equality comparision (ignoring any register/flag values on the left side that were set to `None`, shown as `-` above) and a pretty printer; pytest itself produced the nice diff between the two objects that lets you easily see how your actual values differ from your expected.
Hopefully people will find some of these ideas interesting!
___________________________________________________
Oh, and how did I find all of this? Relentlessly looking for and trying out small improvements over many, many years. If you can't find a problem with your system or ways of working that you can attempt to fix, that in itself is a major problem and will prevent you from ever achieving high productivity. Thinking "I'm not doing it right" is your best friend.
Login
Register
FAQ
Search
while I use vi/vim, I also use nano - but mostly in email (where I use a text client called Alpine, and Pine + pico before that). I've also written many little editors over the years and without really thinking about it they almost always come out in a very nano-like fashion. The latest was adapting one I wrote in C to run on my 6502 systems, and it runs very well over a serial line too and compiled to under 16KB of object code.