I’m trying to implement configurable key bindings in tt. Boy, is parsing the key names into tcell.EventKeys a horrible thing. This type consists of three information:

  1. maybe a predefined compound key sequence, like Ctrl+A
  2. maybe some modifiers, such as Shift, Ctrl, etc.
  3. maybe a rune if neither modifiers are present nor a predefined compound key exists

It’s hardcoded usage results in code like this:

func (t *TreeView[T]) InputHandler() func(event *tcell.EventKey, setFocus func(p tview.Primitive)) {
    return t.WrapInputHandler(func(event *tcell.EventKey, setFocus func(p tview.Primitive)) {
        switch event.Key() {
        case tcell.KeyUp:
            t.moveUp()
        case tcell.KeyDown:
            t.moveDown()
        case tcell.KeyHome:
            t.moveTop()
        case tcell.KeyEnd:
            t.moveBottom()
        case tcell.KeyCtrlE:
            t.moveScrollOffsetDown()
        case tcell.KeyCtrlY:
            t.moveScrollOffsetUp()
        case tcell.KeyTab, tcell.KeyBacktab:
            if t.finished != nil {
                t.finished(event.Key())
            }
        case tcell.KeyRune:
            if event.Modifiers() == tcell.ModNone {
                switch event.Rune() {
                case 'k':
                    t.moveUp()
                case 'j':
                    t.moveDown()
                case 'g':
                    t.moveTop()
                case 'G':
                    t.moveBottom()
                }
            }
        }
    })
}

This data structure is just awful to handle and especially initialize in my opinion. Some compound tcell.Keys are mapped to human-readable names in tcell.KeyNames. However, these names always use - to join modifiers, e.g. resulting in Ctrl-A, whereas tcell.EventKey.Name() produces +-delimited strings, e.g. Ctrl+A. Gnaarf, why this asymmetry!? O_o

I just checked k9s and they’re extending tcell.KeyNames with their own tcell.Key definitions like crazy: https://github.com/derailed/k9s/blob/master/internal/ui/key.go Then, they convert an original tcell.EventKey to tcell.Key: https://github.com/derailed/k9s/blob/b53f3091ca2d9ab963913b0d5e59376aea3f3e51/internal/ui/app.go#L287 This must be used when actually handling keyboard input: https://github.com/derailed/k9s/blob/e55083ba271eed6fc4014674890f70c5ed6c70e0/internal/ui/tree.go#L101

This seems to be much nicer to use. However, I fear this will break eventually. And it’s more fragile in general, because it’s rather easy to forget the conversion or one can get confused whether a certain key at hand is now an original tcell.Key coming from the library or an “extended” one.

I will see if I can find some other programs that provide configurable tcell key bindings.

​ Read More
In-reply-to » @lyse

@movq@www.uninformativ.de Sorry, I meant the builtin module:

$ python3 -m pep8 file.py
/usr/lib/python3/dist-packages/pep8.py:2123: UserWarning: 

pep8 has been renamed to pycodestyle (GitHub issue #466)
Use of the pep8 tool will be removed in a future release.
Please install and use `pycodestyle` instead.

  $ pip install pycodestyle
  $ pycodestyle ...

I can’t seem to remember the name pycodestyle for the life of me. Maybe that’s why I almost never use it.

​ Read More
In-reply-to » Since I used so much Rust during the holidays, I got totally used to rustfmt. I now use similar tools for Python (black and isort).

@movq@www.uninformativ.de @prologic@twtxt.net That’s what I like about Go, too. However, every now and then I really dislike the result, e.g. when removing spaces from a column layout. Doesn’t happen often, but when it does, I hate it.

I think I should have a look at Python formatters, too. Pep8 is deprecated, I think, it’s been some time that I looked at it.

​ Read More