https://wiki.abuissa.net/api.php?action=feedcontributions&user=172.69.64.254&feedformat=atomrazwiki - User contributions [en]2024-03-29T08:01:33ZUser contributionsMediaWiki 1.39.5https://wiki.abuissa.net/index.php?title=Straddling_between_environments&diff=554Straddling between environments2023-03-18T09:50:17Z<p>172.69.64.254: Created page with "I mess around a lot in different environments that compete for mindshare: macos versus windows versus ubuntu, vim versus emacs. I find that over time I integrate the best of a..."</p>
<hr />
<div>I mess around a lot in different environments that compete for mindshare: macos versus windows versus ubuntu, vim versus emacs. I find that over time I integrate the best of all environments in one environment (usually the most flexible one, like emacs).<br />
<br />
One example of this approach working is https://github.com/noctuid/evil-guide - it is a guide about using vi keybindings in emacs, and it has a lot of sensible configurations enumerated. Similarly spacemacs takes the best of emacs and vim, and even has nice opinionated shortcuts like lowercase s to surround, whereas in vim the default is S. But lowercase s is redundant with c so spacemacs opts to use c for replace-and-insert and s for surround.<br />
<br />
Operating systems is a bit trickier, but it forces standard compliance; or at least the awareness of differences between operating systems. MacOS has terrible window management, for example; windows has good window management but bad keyboard shortcuts. Ubuntu has really bad defaults but great customizeability.<br />
<br />
But honesetly it's a bother that there is all this fragmentation sometimes. Apple is the champ of taking their ecosystem really far in a given direction and eschewing backwards compatibility for performance, form, and function. Windows has decent backwards compatibility guarantees but tons of competing APIs, like autohotkey 1 versus autohotkey 2 (at least autohotkey 1 still works; for a while the latest macos which I compulsively upgraded to had no karabiner and I spent hours trying to replicate my setup in hammerspoon and lost a lot of functionality until karabiner-elements came out (which had a different syntax and a different feature set)).<br />
<br />
Ubuntu and linux in general is a mixed bag; some things work really well, like service management and command line tooling, unsurprisingly. Hardware support is full of pitfalls, for example I noticed my framework computer waking up after I closed it, so the screen was open even though the computer was physically shut. Wifi doesn't work with the intel wifi chip on debian (this is not debian's fault, I respect their stance towards free software). Simple things like the trackpad scroll speed are wildly erratic, and depend on things like whether an application is configured to run under x or wayland.<br />
<br />
Phones exhibit this disparity to an extreme; you're either in Apple's walled garden or out in the wolves with rudimentary phone software and a lack of third-party app development, Second party app development, now, that's you!!</div>172.69.64.254https://wiki.abuissa.net/index.php?title=Keyboard_%22shortcuts%22_for_textareas&diff=553Keyboard "shortcuts" for textareas2023-03-18T09:38:12Z<p>172.69.64.254: Created page with "I do a lot of editing in textareas (like now) and I want keyboard shortcuts much like editors. Many keyboard shortcuts are built in to every text input, so learning them can b..."</p>
<hr />
<div>I do a lot of editing in textareas (like now) and I want keyboard shortcuts much like editors. Many keyboard shortcuts are built in to every text input, so learning them can be useful for such times.<br />
<br />
Basic ones include arrow keys, though these aren't very ergonomic and they move slowly. To move the cursor faster, hold control, then left and right move by words and up / down go to the start / end of the line.<br />
<br />
Backspace deletes backwards of course; delete deletes forwards. Like with arrows, holding control makes backspace and delete delete by words.<br />
<br />
Holding shift and then pressing arrow keys creates a selection. Once you have a selection you can delete it, copy it, cut it etc.<br />
<br />
Undo is control+z and redo is control+shift+z.<br />
<br />
To to to the start of a line, I don't use the control up / down (because I just discovered it now; I might use it actually). Instead I use up arrow then right arrow. End of line is similar: down arrow then left arrow, or just down arrow if you're at the end of the input.<br />
<br />
Editors have keyboard shortcuts like transpose characters and transpose words. I created a firefox extension for transposing characters which uses control+t; I don't find I transpose words much.<br />
<br />
Pressing tab moves the focus to the next input, and pressing space presses the currently focused button. Control+return sometimes submits the form; shift+enter sometimes creates a new line when pressing return would submit (such as in messaging applications).</div>172.69.64.254https://wiki.abuissa.net/index.php?title=Blog:_2023-03-12&diff=536Blog: 2023-03-122023-03-12T11:41:45Z<p>172.69.64.254: Created page with "Link roll up... seems scattered-thoughts.net and I have a lot in common: pinephone, about a decade of software, writing own editor https://www.scattered-thoughts.net/writing/..."</p>
<hr />
<div>Link roll up... seems scattered-thoughts.net and I have a lot in common: pinephone, about a decade of software, writing own editor<br />
<br />
https://www.scattered-thoughts.net/writing/pinephone-first-steps/<br />
https://www.scattered-thoughts.net/writing/focus-intro/<br />
https://slack.engineering/taking-php-seriously/#.v643zvbw3 - this one I already read but it's a good read, I'll include it<br />
https://www.scattered-thoughts.net/writing/reflections-on-a-decade-of-coding/</div>172.69.64.254https://wiki.abuissa.net/index.php?title=Idea:_some_kind_of_automation_to_test_vim_/_emacs&diff=534Idea: some kind of automation to test vim / emacs2023-03-12T11:01:22Z<p>172.69.64.254: </p>
<hr />
<div>Would be nice to be able to say<br />
<br />
"opening vim, pressing v$y should copy the first line onto the clipboard." Then I can make changes and still see that it works...<br />
<br />
One way to do this is to use tmux. But let's start by just modeling this in python.<br />
<br />
def test_editor(executable: emacs | vim, keystrokes=""): ...<br />
<br />
or<br />
<br />
def test_vimrc(keystrokes, input_text, expected_text, config):<br />
vim_session = open_vim(config)<br />
<br />
vim_buffer = prepare_buffer(vim_session, input_text)<br />
<br />
assembled_vim_command = "i" + input_text + "<esc>" + keystrokes<br />
<br />
result = run_keystrokes(vim_buffer, assembled_vim_command)<br />
<br />
assert result == expected_text<br />
<br />
def test_default_vimrc(keystrokes, input_text, expected_text):<br />
test_vimrc(keystrokes, input_text, expected_text, open("~/.vimrc").read())<br />
<br />
<br />
test_vimrc(keystrokes="-", input_text="1\n2", output_text="2\n1", config="nnoremap - ddp")<br />
<br />
A more involved example:<br />
<br />
def test_trim_whitespace_on_save():<br />
config = """<br />
augroup trimwhitespace<br />
autocmd!<br />
autocmd BufWritePre * call TrimWhitespace()<br />
augroup END<br />
"""<br />
test_my_vimrc(keystrokes="o<cr>", input_text="just a line", output_text="just a line", config=config)<br />
<br />
It would be useful to have some canned source files:<br />
<br />
sample_python = """<br />
def main():<br />
print("hello world")<br />
<br />
if __name__ == "__main__":<br />
main()<br />
"""<br />
<br />
Maybe they could even have some syntactic issue that a vim editing session would fix.<br />
<br />
But more realistically, I'd want to even assert that the view is the same. Fortunately, commandline editors produce VT100 escape sequences which can be spooled then played to display a buffer.<br />
<br />
Ideally, even different editors would produce the same final escape sequence paint result; this would require totally removing any modeline etc. Or at least making the modeline completely editor-independent.<br />
<br />
A workflow to make a test could be thus: start recording. Open editor, do keystrokes, stop recording. Save the inputs and final rendering of the editor to a file. Then whenever anything changes, playing the same inputs would produce a different rendering. This allows making tests easily, since you don't have to write code for all the interactions, and test end-to-end. Cool!</div>172.69.64.254