Significantly expand formatters and formatter help commands #1999
Conversation
I often find myself trying to see just the words for a particular type of formatter. This is clearly missing in terms of the word formatters, and while it does not matter significantly in terms of the prose and code formatters it is still nice to be able to see a separation there.
This introduces three new formatters: LEADING_SPACE: " word" TRAILING_PERIOD: "word." LEADING_PERIOD: ".word" These new formatters enable a large list of new commands that can help with common tasks, such as continuing a sentence without having to say space, finishing sentences, starting a new sentence when you are at the period, and more.
This change includes many new formatters for the word and prose categories the play around with spaces, capitalization, and periods. The purpose of these formatters is to that the user doesn't need to break their flow to say the additional few words of space and period. I have found in my own personal workflow that I was often wishing for these commands, and now that I am used to them it has significantly sped up common tasks. Talon also often misheard space, so that solves that issue. Wherever possible I tried to map word formatters to prose formatters. E.g., `walk` and `hike` are trailing space formatters for word and prose respectively. I want to call out a few duplicate formatters. `trot` = `throw`, `gallop` = `hurl` I thought that `throw` and `hurl` can better matched the motion naming whereas `trot` and `gallop` randomly introduced horse words. Nonetheless I did not want to remove `trot` for current users, so I also added `gallop` for an equivalence. I also introduced `begin` as an alternative to `sentence` as talon frequently misheard sentence.
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
| gui.text(f"List: {selected_list} ({page_info})") | ||
|
|
||
| # Extract description from list declaration, i.e. mod.list(..., desc=...)) | ||
| if (desc := registry.decls.lists[selected_list].desc) is not None: |
There was a problem hiding this comment.
Your pull request seems to have removed the help code that gets the list description from the registry and displays it. Can you put that back?
There was a problem hiding this comment.
On second thought, you might want to wait until you get feedback from the maintainers before making additional changes.
|
Personally, I am not a fan of the new formatters - at least, not mixing them in with the existing ones. Just looking at them, I found it difficult to distinguish between their subtle differences, and there are a lot of them. The cost of adding a bunch of new formatters is not actually zero, because it significantly adds to the sense of overwhelm that (especially newer) users get when they look at the available formatter list. There are already a decent number to learn. Possibly more importantly, it doesn't look like any of them save more than 1-3 'keystrokes', which is in contrast to formatters which save 1-2 per word. This is especially the case for the trailing ones, which would be better served as custom phrase enders. I don't think it is that much more difficult to say "say xyz spacer" instead of "gallop xyz", or "space say xyz" rather than "hike xyz", so IMO it isn't worth the cost Perhaps this could be added as a separate file with an optional tag to enable it? At least for the ones that actually save significant time |
|
Counterpoint: my version of "hike" broke a few months ago and I've been procrastinating fixing it. I'd love to see it in upstream. I find "space say xyz" noticeably more cognitively burdensome than "hike xyz". |
|
We did not get to this pull request in today's backlog session as we largely focused on the wiki. I am not sure if having so many formatters in community would make sense or not, but I find myself gradually expanding my personal set of formatter commands for the sake of convenience. Making common tasks one less word adds up over time. I think having an extended set available would help more advanced users. I am curious. What is the advantage for you for having these as part of the formatter system instead of as separate commands? |
|
Talon has an accepted way of formatting strings in a particular manner. You can always make a new place to do the same thing but it is cognitively easier for a person to understand and find where a thing is if it is all in one place. While I was learning I frequently used the help command to list out the different formatters and even still do so on occasion. Perhaps that is a sign that this is a little bit too much cognitive overhead at startup, but I have found it helping out significantly over the long run. I also agree that the differences can be subtle; I did try to make the list ordered such that it is easier to see the differences when you actually call out the help commands. |
|
From the community backlog session — our discussion has largely echoed the one that occurred on this PR already. We agree with @BlueDrink9 about formatters that would be better as phrase enders. In my experience learning Talon grammars, I do much better when I can compose things together rather than having to learn lots of different shortcuts. I understand that everyone's brain might not work the same way. I would recommend that you split out the infrastructure changes from the additional formatters into an additional PR so we can evaluate them separately as I think they may be a little less controversial. One thing I noticed was the pattern of |
This change includes many new formatters for the word and prose categories the play around with spaces, capitalization, and periods. The purpose of these formatters is to that the user doesn't need to break their flow to say the additional few words of space and period. I have found in my own personal workflow that I was often wishing for these commands, and now that I am used to them it has significantly sped up common tasks. Talon also often misheard space, so that solves that issue. Wherever possible I tried to map word formatters to prose formatters. E.g., `walk` and `hike` are trailing space formatters for word and prose respectively. I want to call out a few duplicate formatters. `trot` = `throw`, `gallop` = `hurl` I thought that `throw` and `hurl` can better matched the motion naming whereas `trot` and `gallop` randomly introduced horse words. Nonetheless I did not want to remove `trot` for current users, so I also added `gallop` for an equivalence. I also introduced `begin` as an alternative to `sentence` as talon frequently misheard sentence.
nriley
left a comment
nriley
left a comment
There was a problem hiding this comment.
From the community backlog session — thank you for splitting out the infrastructural changes from the individual formatters. This is looking pretty good if you could address the issues where you may have inadvertently reverted some changes that had happened to the formatter help code since you started working on this.
| return formatters_help_demo | ||
|
|
||
| def get_prose_formatter_words() -> dict: | ||
| """Returns words currently used as prose, and a demonstration string using those formatters""" |
There was a problem hiding this comment.
| """Returns words currently used as prose, and a demonstration string using those formatters""" | |
| """Returns words currently used as prose formatters, and a demonstration string using those formatters""" |
| return formatters_help_demo | ||
|
|
||
| def get_word_formatter_words() -> dict: | ||
| """In returns words currently used as word formatters.""" |
There was a problem hiding this comment.
| """In returns words currently used as word formatters.""" | |
| """Returns words currently used as word formatters.""" |
| gui.text(f"List: {selected_list} ({page_info})") | ||
|
|
||
| # Extract description from list declaration, i.e. mod.list(..., desc=...)) | ||
| if (desc := registry.decls.lists[selected_list].desc) is not None: |
| if type(operator) == str: | ||
| text = ": " + operator | ||
| # If a documentation string is available, use that | ||
| elif doc_string := getattr(operator, "__doc__", None): | ||
| text = ": " + doc_string | ||
| # Otherwise display the operator name from list |
There was a problem hiding this comment.
Please revert this change, thanks.
5 participants
This change includes many new formatters for the word and prose
categories the play around with spaces, capitalization, commas,
and periods. In addition I have introduced new help commands to bring up the individual lists for
code, prose, word formatters since it has become bloated to just see all of the code and prose together.
I acknowledge that this is a rather significant expansion, so if there is
disagreement about the new formatters I think the help commands
are still useful on their own and can be split off into a separate request.
The purpose of these formatters is to that the user doesn't need to
break their flow to make these additional specifications.
I have found in my own personal workflow that I was often wishing for
these commands, and now that I am used to them it has significantly
sped up common tasks. Talon also often misheard space, so that
solves that issue.
Wherever possible I tried to map word formatters to prose formatters.
E.g.,
walkandhikeare trailing space formatters for word and proserespectively.
I want to call out a few duplicate formatters.
trot=throw,gallop=hurlI thought that
throwandhurlcan better match the motionnaming whereas
trotandgalloprandomly introduced horse words.Nonetheless I did not want to remove
trotfor current users,so I also added
gallopfor an equivalence.I also introduced
beginas an alternative tosentenceas talon frequently misheard sentence.