improve keyboard shortcuts

[slartibart70]

Hi,
nice tool, btw!!!

Could we improve on the keyboard shortcuts, like e.g.

• / for immediately jumping into the search box
• ctrl-m ... this is simply a return in my shell and does not toggle the mode (i have to select it using the palette)
• gg, G to jump to begin/end to the list of services
• more vi commands? (scrolling with ctrl-f/ctrl-b, ctrl-e,ctrl-y) and different, non-vi-conflicting shortcuts to edit units?

And, regarding log-outputs in 'system' mode:
i need to run isd.Appimage as root to get rid of the status-messages reading (e.g. docker.service):
Warning: some journal files were not opened due to insufficient permissions

[welcome]

Thanks for opening your first issue here! 💖

[Martinligabue]

I'd add that pageup/down isn't bound, It could help the scrolling

[isd-project]

Please check out v0.2.0 :)
Page up/down has been added and now you can configure the keybindings.
I will add jump to search.
Ctrl+m is annoying. What terminal and shell are you running?

[slartibart70]

i'm already on 0.2.0
So, i can edit the ~/.config/isd/schema.json file?

But, find is still not mappable to sth. like / :-)

Regarding ctrl-m, i am using fedora41/konsole. But to me, ctrl-m was always an alternative for return in shells (i did no specific reconfiguration)

[isd-project]

So, i can edit the ~/.config/isd/schema.json file?

No, you should edit the YAML file, please have a look at the docs for details:

• https://isd-project.github.io/isd/customization/

But, find is still not mappable to sth. like / :-)

I will add jump to search.

Yeah, I will add it soon. :D

I will keep you updated via this issue tracker 👍

Terminal defaults are super hard just because there are so many edge cases and sooo many different "defaults".
But "change mode" should always work. So I will definitely change it if there are any popular overlaps

[slartibart70]

thanks for the update!!
(and no offence regarding the 'find' functionality, take your time :-)

[isd-project]

no offence regarding the 'find' functionality, take your time

No worries, none taken!
I am super excited that so many people (hopefully) find it useful! ❤️

[isd-project]

Hey, @slartibart70, I have added the support for jump to focus and changed the default for the mode switch to ctrl+t.
Did you have any other keyboard shortcut issues?

EDIT: Before I create a new release?

[slartibart70]

Hi,
you are quick! :-D

Besides the vi-support - which e.g. uses gg for jumping to the top-row - and i don't think we can use this combination right now with keyboard-shortcut redefines. This could also be part of an input-mode-setting (like, switching between 'typical' shortcuts with ctrl/alt/meta-something and vi-command compatibility)
But... put it on the whishlist, maybe for later.

The other thing bothering is the switch between rootful/rootless-instantiation of isd.
Like you said here:

In general, it is a good idea to never run commands/binaries with elevated privileges. isd is designed in such a way that you never have to run it with sudo. isd is able to automatically prefix the systemctl subprocess calls with sudo if necessary and may ask you for your password via the normal terminal password prompt.

we are still missing log-output (see first message) when isd is called as non-root and switching to 'system' mode due to missing permissions.
Why am i not generally asked for sudo-credentials when switching to 'system' mode? Wouldn't that help here?

[isd-project]

Yeah, these types of "double keypress shortcuts" aren't supported. :/

But... put it on the whishlist, maybe for later.

I will update the FAQ / documentation but I really would like to avoid "reinventing the pager wheel".
The main idea is that by simply pressing a quick enter you get a purpose-built tool exactly for this purpose that supports your favorite keybindings (or, in the worst-case, your editor). Maybe I will make a comparison video or something to better "promote" non-default pagers. Pagers are awesome!

we are still missing log-output (see first message) when isd is called as non-root and switching to 'system' mode due to missing permissions.

Yeah, also something that I need to add in the docs 😅
Essentially, the answer is no. You should allow your user to view logs by adding your user to the necessary group(s) and never use sudo for calling isd.

See the docs from systemd:

https://github.com/systemd/systemd/blob/19aadacf92ad86967ffb678e37b2ff9e83cb9480/README#L161-L176

[slartibart70]

You should allow your user to view logs by adding your user to the necessary group(s)

definitely sth. for FAQ,
didn't know about this

I really would like to avoid "reinventing the pager wheel"

the pager (less in my case) already supports vi-bindings. If you are happy using them, then the isd-UI is obviously different in usage. Here we could improve on aligning.
But, this is just a feature-request for later if you have spare time left over ...

[isd-project]

If you are happy using them, then the isd-UI is obviously different in usage. Here we could improve on aligning.

Out of curiosity, which bindings are you missing?
I must admit that I only use j,k,h,l and maybe page up/down (ok and gg and G).

I am also planning on limiting the scope of the systemctl shortcuts only to the Selection widget, which would allow "re-using" keybindings in the preview window. Though, in my local tests, I am also hesitant because I have already "accidentally" stopped a unit by not paying attention what I was focusing.

Maybe a more general question, do you appreciate the default keybindings for systemctl commands? Or do you think that a user should configure it on their own?

[slartibart70]

It's more like conflicts between vi-bindings an isd.
Like, ctrl-e/ctrl-y (scrolling line-wise) does sth. different in isd. (configurable, yes)
Or, scrolling half-page (ctrl-u/ctrl-d)

This is typically only a problem for hardcore-vi user, but as we have 'hjkl' as movement in the UI i am tempted to use the others as well - with unexpected side effects :-)

[isd-project]

I see. I am currently researching what "defaults" are safe to use from a terminal/shell perspective.
Sadly, I cannot enforce my preferred terminal and shell onto users 😅
Currently, I am inclined to map systemctl actions to different keybindings just to make sure that users
"explicitly" trigger them.

[isd-project]

Hey, thank you again for raising this issue so "early".
TUI keybindings are a deeper rabbit hole than I would've imagined.
And I believe it is important to fix these "unexpected" shortcuts before people get used to it and potentially causing damage by accidentally stopping units.

In essence, I will add a "quick select" menu/modal for systemctl actions that opens with a "safe" keybinding and then executes the desired action with the next keypress/selection.

So ctrl+o open modal -> o -> Stops unit

I will still try to support "direct" actions since I am a big fan of them, but they will probably be disabled by default, especially since they require adapting to the terminal emulator used.

Thank you for your feedback!

[stevenwalton]

Some of these keyboard shortcuts don't work very well if you're using a different keyboard. For example, I ssh into my machine from my macbook and run isd, and nothing really works. alt is a fairly uncommon pattern.

I'm highly in favor of vim bindings. I commonly see this mean h,j,k,l but real utility is in things like gg (top) G (bottom) H,M,L for high, middle, low, <c-f> and <c-b> for page scrolling forward and backwards.

I'd also make sure to check that <c-[> is properly mapped to ESC as this is a unix default.

I know things can be overwritten with ~/.config/isd/schema.json but it's also worth noting that this is all on a single line... rich can handle this trivially so I think it would be worth implementing wherever that's happening. Or if json.dumps is being used that supports that too. That would make a lot of this easier for users.

[isd-project]

@stevenwalton The overlap issues should be resolved in v0.3.0

Regarding the customization:

~/.config/isd/schema.json [...] That would make a lot of this easier for users.

You are looking at the wrong file. schema.json is only the schema for the config.yaml file.
I have updated the documentation accordingly to be more explicit about it: https://isd-project.github.io/isd/customization/

[slartibart70]

The new release 0.3.0 is very nice! Thanks!

[isd-project]

Sorry for pinging you @slartibart70.
I am considering adding the other navigations as well but would like to get some input from an "hardcore" vim user :D

According to https://stackoverflow.com/a/11235237:

• Ctrl-y Moves screen up one line
• Ctrl-e Moves screen down one line
• Ctrl-u Moves cursor & screen up ½ page
• Ctrl-d Moves cursor & screen down ½ page
• Ctrl-b Moves screen up one page, cursor to last line
• Ctrl-f Moves screen down one page, cursor to first line

Which ones do you expect to use most of the time?
How important is cursor position?
For example, in the unit selection window, I would consider simply binding ctrl-e to down, although it is strictly speaking something different. Similarly, I would also be inclined to map page up/down to ctrl-b/ctrl-f and again ignoring the cursor position.

Would you appreciate that these keybindings are set by default, or would you rather have no "incorrect" keybindings?

I assume there are many other applications that partially support vim keybindings, though I have never used these "more advanced" features of vim, so I would appreciate your input 🙏

[stevenwalton]

I can say what I use the most is <C-f> and <C-b>. I tend not to use the half or line moves because I end up using cursor placements for that (H, M, L). For example, if I want to move the screen up one like I'll type Hk. I almost never use the others. They might save one key press but they're harder to reach or might be overloaded. I do use the z commands (zt, zb, and z.) for screen movements. (z. is the same as zz) This is a similar form to the same movements and you can probably tell that Mzt is similar to <C-d>, but without the chance of closing a terminal.

How important is cursor position?

That's the whole chimichanga right there!
Though contextually, I'd be fine with what you're suggesting.

I have a few vim tutorials if that helps. (still need to write the advanced one) Getting up to speed on vim is much easier than most people think, but I also think it is easy to get the wrong mindset from the start.

Other important moves are a bit more subtle, like knowing the difference between w and W (or b and B). $, 0 (I strongly prefer 0w over ^ because reach), these are far less important because it is navigating within a line. Some users strongly prefer numerical movements like 10k for 10 lines down. But things like searching are also important to vim users. So don't undermine how much a vim user is going to type / to jump to a location rather than use movement keys, and spam n for next (N to search in other direction. Note ? is reverse direction of /) or use things like * to search a single word (less important here, stating for helping explain the mindset). But given that, it would make sense to then do things like begin editing a file with i, binding that to call systemctl edit. Basically we're lazy and don't want to lift our hands off the keyboard. So the most "vim friendly" things to do for things that can't be one-to-one mapped is make the action easy to use without big movements (like requiring moving wrists). Making it fine to use ctrl and shift and it is better to combine those keys than to do something like make them reach for the middle of the keyboard (coming back to my hatred of ^ lol. This is is why people hate pressing esc and will remap it to caps lock, but they're wrong (;)) because <C-[> takes no keymapping).

Note: <C-f> == ctrl + f

[slartibart70]

Sorry for pinging you @slartibart70. I am considering adding the other navigations as well but would like to get some input from an "hardcore" vim user :D

Hi,
as stevenwalton already indicated, there's more to navigation in vim.
But, for me i was just stumbling over myself in using shortcuts being intended for other purposes :-)
Yes, simple navigation commands would be nice:

Ctrl-y Moves screen up one line
Ctrl-e Moves screen down one line
Ctrl-u Moves cursor & screen up ½ page
Ctrl-d Moves cursor & screen down ½ page
Ctrl-b Moves screen up one page, cursor to last line
Ctrl-f Moves screen down one page, cursor to first line

I wouldn't bother that much about cursor positioning (there are other commands for this in vim which clearly need not be present in isd) but more on the unexpected side effects when using typical vim-shortcuts.

Regarding the 'defaults': why not offering both?
Adjustable via config/commandline-param for example so we have non-vim sensible defaults and vim-compatible shortcuts?
Don't put vim above all, it's a veeery nice editor but others are nice as well....

[isd-project]

Regarding the 'defaults': why not offering both?

I mean, more than 90% of the keyboard shortcuts are (and always will be) configurable. I am a big fan of allowing users to configure the tool to their preferences.

I am a helix user myself and prefer it over Vim, but then again, I do believe that having Vim keybindings on "by default" (in addition to the "classic" keybindings) is a solid choice. Especially considering who (probably?) the target audience of the tool is.

I wouldn't bother that much [...] but more on the unexpected side effects when using typical vim-shortcuts.

I 100% agree. This is why I pushed this issue to the top of list and fixed it 👍

But then, from what I've gathered, a solid compromise would be what I have initially suggested:

For example, in the unit selection window, I would consider simply binding ctrl-e to down, although it is strictly speaking something different. Similarly, I would also be inclined to map page up/down to ctrl-b/ctrl-f and again ignoring the cursor position.

Though, then again, having ctrl-e behave the same as j and down might be unexpected?

I do believe that "defaults are king". And as you said, if I provide jkl,, then it would be nice to also provide some other typical vim-like bindings. However, I do not want to re-invent the wheel. If anybody wants to "really" navigate the logs, they should open it with their preferred editor/pager. This is a clear line that I want to draw for the project. My gut feeling is that "correct cursor" navigation with H,Ctrl-d etc would cross this line. But before walking down this path, I wanted to have some perspective from both of you, actual true vim users.

[stevenwalton]

I think what would be nice is to have pre-defined configurations (I think this is what @slartibart70 is suggesting). Like how in bash (or zsh) you can turn on vim-mode and there's many programs that let you choose emacs bindings or vim bindings. They act as starting points for users and this might also make it easier for these groups to contribute as well as ensure that they don't step on each other.

but more on the unexpected side effects when using typical vim-shortcuts.

I think this is my general complaint with many implementations of vim mode too. And fwiw, I agree with <C-d> not being a good binding. It has too many overloads already.

actual true vim users

I respect this a lot, but also want to make sure we recognize an important point. The people that are drawn to vim, emacs, and the like are mainly drawn by the ability to make the tools work in the ways that they want. You take a hundred vim users and you'll see 120 different ways to use vim lol. Good defaults, but everything should be customizable and flexible. Which, as you note, you already seem to share in this philosophy, but I just wanted to make it explicit and state my support for this development style.