bwhmather

To add to this, experienced users will often start typing without looking based on what they trust the eventual state of the UI will be. Moving the cursor immediately makes it explicit that this should work.

This is following a more important rule which is "Never make keyboard input timing dependent!" I'm looking at you new Windows start menu and VS Code quick open.

You are not wrong! That certainly looks like the intention.

I'm also the happy owner of a StarLite Mk IV. The perfect travel laptop. Thin, light, fanless, excellent keyboard and touchpad, matt screen, rock solid chassis, good battery life. I'm dreading the day when it finally breaks as there's nothing comparable on the market today. I wish they could do another run.

Very different niche from the StarFighter but StarLabs make excellent machines.

I use this script, saved as `rerun`, to automatically re-execute a command whenever a file in the current directory changes:

    #!/usr/bin/sh

    while true; do
        reset;
        "$@";
        inotifywait -e MODIFY --recursive .
    done

For example, if you invoke `rerun make test` then `rerun` will run `make test` whenever you save a file in your editor.

Have pushed fix as version 0.10.0. Thank you very much for reporting.

I'll try to add some better ones over the weekend. This should be a start.

It is a bit backwards, but in exchange you get predictability

With backwards sorting you know that, unless there is a cycle, you can always scroll up from a call site to find the definition or down from a definition to see where it is used. With forwards sorting you can scroll down to find a definition, unless the function was imported, or used as a decorator somewhere, or called by something that was used as a decorator, or used in some other way that I haven't thought of.

My personal experience is that this predictability is hugely useful. It almost entirely obviates the need for jump-to-definition within a module, and gives modules a very obvious shape and structure.

Will do. Examples directory isn't terribly helpful as documentation as it mostly contains real code with problematic syntax (and compatible licensing) that tripped up ssort when I ran it on a copy of my pip cache. I will move it into tests to avoid confusion

Implementation details at the top. Python is a scripting language so modules are actually evaluated from top to bottom. Putting high level logic up top is nice when you just have functions, which defer lookup until they are called, but you quickly run into places (decorators, base classes) where it doesn't work and then you have to switch. Better to use the same convention everywhere. You quickly get used to reading a module from bottom to top.

isort only sorts imports. ssort will sort all other statements within a module so that they go after any other statements they depend on. The two are complementary and I usually run both.

One thing worth mentioning is that the `git blame` ignore file trick doesn't work as well with ssort as it does with black because the changes ssort makes tend to be much less local.