Comments (23)
I like that! It's like a customizable cheat-sheet for pter, but inside pter.
from pter.
Oh, that's a good one! Does this this work? Or should the sections still have headers and be more clearly separated?
Edit: ah, too early; didn't follow your suggestion and just started hacking. And then of course even forgot to add the new file 🤦 Anyway, should work now.
from pter.
With a bit of scripting, I now have a rofi-based cheat sheet for pter, awesome! https://i.imgur.com/cW1wG0b.png
from pter.
Have a look at this commit; does this solve the problem with the trailing newline?
from pter.
Tested, problem solved, thank you!
from pter.
Dang, no you’re right! I missed that these two had been part of this issue! I want these to be in 3.16.
from pter.
I could have sworn :
was at ö
, but it’s been a while!
On topic though I’m afraid to keep track of which user-defined key binding is the first (and for that matter whether a keybinding is user-defined, even if it is the same as the default) is not easily fixable without breaking corner cases (mainly because the keybindings are a dictionary, so bindings are there or they are not…). Or, well, like you did, with lots of duplication of information.
I’m not sure how to solve this cleanly yet. 🤔 Gotta give it a bit more time to mull it over.
If I can’t come up with a good solution until tomorrow, I’ll just take your fix 🤷
from pter.
nano
isn't bad. It's vim
on my side, so pretty much the same just with more sunk-cost-fallacy attached 🤷
from pter.
Speaking of cheat sheets, perhaps it'd be helpful to add a CLI param to dump the Help screen to stdout (only without the section titles). Something like what tmux list-keys
does.
With tmux, I feed its output to rofi
(with some simple parsing), which gives me a searchable cheat sheet for all keybindings: https://i.imgur.com/AMuIf4R.png
A possible format (fields separated by tabs, spaces are just for readability here):
Create task \t create-task \t n
Create task \t create-task \t <f2>
Edit task \t edit-task \t e
Edit task \t edit-task \t <f4>
from pter.
Works great, except we need to strip the trailing \r
from output :) Otherwise less
and other CLI tools go crazy.
In terms of columns/sections/etc, I think the output format is perfect for now. Let me play with it for a while and get back to you if I have any improvement ideas!
from pter.
@vonshednob The external cheat sheet works well, but I think it would still be useful to implement 1) and 2) from the original comment. Or at least implement 1) (configurable Helpbar).
It's still faster to quickly glance at your Helpbar as opposed to switching contexts to an external cheat sheet. I think these features complement rather than replace each other. What do you say?
P.S. It's by no means a blocker, so I'm all for removing the 3.16 milestone tag but keeping this issue open for the future.
from pter.
Showing user-defined keybindings first was easier than expected.
from pter.
The new code grabs the first custom keybinding from user config, perfect!
But can pter filter out default keybindings ONLY if they are not set in the user config?
That way, if a user needs a hint for a default keybinding, they can set it explicitly before other user-defined ones in the configuration file.
from pter.
Hm, I’d rather not have all keybindings vanish just because a user has modified one keybinding. Most users will not do any changes in the configuration except the one thing that really bugs them.
Maybe a configuration option to only show custom keybindings in the help bar? 🤔
from pter.
So if I set something like help-custom-keys-only
to yes
, pter would (A) only show an action in Helpbar for which a custom keybinding has been defined? Or (B), pter would alternatively show a default keybinding for a Helpbar action for which no custom keybinding has been defined?
(A) + (B) would be ideal, but even (A) alone would be great. My use case is probably not the commonest one, so I don't mind defining all the keybindings explicitly if needed.
(I'm assuming the Helpbar would still use the first user-defined keybinding, as in the current git HEAD.)
from pter.
Let’s pin examples to this, because it becomes a bit tricky 😅
Let’s take the two actions jump-to
and edit-task
. Default binding is :
and e
.
Right now if a user sets a new keybinding, e.g. ^G
to jump-to
, the help bar would show [^G] jump-to
and [e] edit task
. That’s option (B), if I get you right?
I can imagine a configuration option help-shows
that can be set to prefer-custom
(which is this described behaviour).
If help-shows
is set to only-custom
, in this example the help bar would only show [^G] jump-to
.
The real tricky problem (and I do not see how I could solve that easily) is what happens if the user writes in their configuration file e = edit-note
. Technically that’s a custom key binding, but it matches the default. So it’s not a change. But it is a custom thing 😩
from pter.
Examples are helpful. yes! So let me back up and explain one of my use cases properly. I don't think I've done that well.
I write todos and notes in several languages, e.g. in English and German. Here's a sample German keyboard layout:
Note for example the :
key. It's in a different spot compared to the US English layout. Where the US layout has a colon, the German one has ä
.
Here comes the important part: For productivity, it's critical to be able to use a single-key binding and not think of the keyboard layout! Pter has amazing keyboard support, so it lets me create multiple sets of keybindings:
<colon> = jump-to
ä = jump-to
So far so good. I can hit the same physical key and call the right action regardless of layout.
Now, which key hint should be shown in the Helpbar? To my mind, pter should always prefer a custom keybinding over the default one. If a user sets a keybinding, they must prefer it!
In addition (and this is the tricky part you referred to earlier), the user-set keybinding should be shown even if it matches the default one.
In my example above, German is a secondary language and I don't always remember where ä
is. If I think "colon", my fingers jump to the right key in the English layout, but not necessarily in German. So the Helpbar should pick up <colon> = jump-to
(because it comes first in my config and I put it there for a reason) and show : Jump to item
. If I change the order of bindings in the config, the Helpbar should always pick the first user-defined one.
So to summarize, the behavior I would call ideal is this:
- The Helpbar actions are defined by
help-actions
-- ☑️ done - If no
help-actions
are set by user, fall back to default actions -- ☑️ done - If there's a user-set keybinding for the action, the Helpbar should always prefer it -- whatever it is, even if it looks the same as the default one -- ❗ partially done, key hint for a custom binding is currently being removed if it matches the default
- If there are multiple user-set keybindings for an action, show the first one in Helpbar -- ☑️ done
- If there's no user-set keybinding for an action, show the default binding hint -- ☑️ done
- If there's no user-set OR default keybinding for an action, don't show the action -- ☑️ done
Currently, pter mostly works as expected, but because of item number 3 I'm getting ä Jump to item
in my Helpbar, which is NOT helpful at all 😆 So I put together an ugly local workaround patch to get the old behavior back, hopefully temporarily :)
Maybe a configuration option to only show custom keybindings in the help bar?
I think I may have misunderstood this idea originally. Right now I don't see the need for this option, but if a separate config option would help get the "arguably ideal behavior" above, I'm all for it!
from pter.
For the record, I'm attaching the quick and dirty patch I'm using that seems to get the job done. It only deals with task list keybindings for now, though.
from pter.
Yeah, I thought about changing the data structure for the bindings, but the change seemed too invasive and frankly I don't know the codebase well enough not to introduce new bugs... Also perhaps pter needs a unit test for the keybindings feature as it's become more complex.
from pter.
I had the same idea about the changed data structure for keybindings, but it feels a bit like confusing the purposes too much.
The unit tests for the keybindings is a good idea; just really tricky with them being so tightly integrated into the user interface. Some refactoring would do the code a lot of good, but who has the time?
from pter.
In terms of refactoring, do you prefer any kind of code style? Maybe introducing the black linter would be a baby step in the right direction that wouldn't take a lot of time. With black, all code from all PRs/contributions would always be formatted the same.
I don't have a meaningful Python IDE configured right now (working on it) but I remember using black in the past and it helped refactoring and collaboration.
from pter.
Yeah, I totally use an IDE and not just two terminals in a trenchcoat 😅
No idea what black is, but I mostly just try to follow the usual PIP style and try to keep the lines shorter than 120 character 🤷 .
Unfortunately pter grew very quickly in the beginning and could have used some more following these rules and: decluttering. Like moving all actions into classes with an execute
function that tasks a task. Or decoupling the UI from the curses screens to make a transition to some other terminal driver easier.
from pter.
Black is opinionated, but I did like it: https://github.com/psf/black
Yeah, I totally use an IDE and not just two terminals in a trenchcoat
Good for you, I'm using nano
right now, I need to stop! :)
from pter.
Related Issues (20)
- Commands to increase/decrease due dates HOT 11
- Distraction-free task editing/creation HOT 3
- Patch for help screen HOT 5
- Mouse-wheel scrolling broken after editing a task externally HOT 38
- Patch to fix caret key issues HOT 1
- Patch to improve line editing some more HOT 6
- Patch: UI proofreading/minor editing HOT 7
- Patch to invert completion highlighting HOT 2
- Regression: pter crashes when choosing a filename to save the task to HOT 1
- Distraction-free mode should show task list on "jump-to" action HOT 6
- Bug: chained keybindings do not seem to work on the Help screen HOT 20
- What does "N" (edit note) do? HOT 6
- Request: Add filename in task format? HOT 13
- Add file name completion when searching HOT 8
- Bug: Editor keybindings not dumped? HOT 2
- Centralised archive with multiple todo.txt file HOT 1
- Support for different sources of tasks
- qpter not finding PyQt5 under python3 (No longer easily available under pip install) HOT 4
- new qpter issue (at least on my end!) HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pter.