Suggestion formatters should include pascal case

[douglasg14b]

Right now it's titled as hammer however pascal is the common definition.

Could be added in addition to?

[rntz]

anyone object to this? @pokey @knausj85 @splondike ? I guess the only principle it violates is that we shouldn't have duplicate names for formatters.

[pokey]

I'd be tempted to just pick one, and I'd also be tempted to make that one be "pascal", tho it's going to be rough for people who merge and all of a sudden "hammer" breaks. Argues for defining formatter spoken forms using csv default setup

[pokey]

But I have no strong objection to aliases in formatters

[splondike]

I think I like the idea of just having one way to do it; more commands -> more misrecognitions.

We could deprecate the hammer command with a notification balloon like we did for the 'M grid' command, but I'm not sure if it's worth retraining everyone's muscle memory?

@douglasg14b What do you think, is this more of an issue while you're learning knausj, or is it something that trips you up regularly as you've gotten more experienced? For me there are a lot of semi-arbitrary command words to memorise :).

[douglasg14b]

@splondike

I am a new user of course, however, the goal of not having duplicate commands, and not breaking commands, kind of sets in stone any and all ideas & implementations doesn't it?

If something has a more broadly known term, that isn't a conflict for speech recognition, it would be my opinion that that term would want to be used. There are a lot of arbitrary words and commands to learn, If possible, making them less arbitrary sounds beneficial.

In this case, I believe that Pascal is far more known than Hammer, however, that's what this discussion is for.

[splondike]

This is a little unrelated to this issue, but in my case it's not a prohibition, but a slight bias against new and duplicate commands. They have to present a reasonable amount of 'usefulness' before I think they should be included in this repository.

Having more (or duplicate) commands increases the chance of misrecognitions, collisions with other commands, makes documentation (like cheat sheets) longer, and gives us maintainers more things to think about (we have no way of knowing if a given command is being used or by how many people). This has meant in the past for example that I have pushed back around adding commands that would be very easy for somebody to put together in their personal setup, and would likely take almost the same time as learning whatever words we used for it. To exaggerate a bit, the bad end state I'm trying to avoid is we have 100s of globally scoped commands taking all the 'good' prefix words and offering functionality of marginal utility. And we don't know which if any are being used so we have to maintain them all. So that's why I have a bias (but not a prohibition).

Anyway, this case is a combination of that and also considering existing 'muscle memory'. We've probably got 10s or maybe 100s of people using 'hammer' already, so if we swapped it out we'd be asking them all to notice that and then retrain themselves. This is potentially fine if pascal is mnemonically more useful than hammer (it probably is, but I didn't know that was what this was called prior to this issue).

I think I'd be fine with either not doing this issue, or with making pascal the default and causing usage of hammer to display a notification balloon telling people to move to 'pascal' (like we did with M grid). It seems like douglasg14b and pokey would both find 'pascal' more pleasant mnemonically or aesthetically, so probably you represent a reasonable slice of users.

[douglasg14b]

@splondike

I believe you're highlighting what is both a growing pain and process issue. This thread has speculation that would be resolved by process precedent, I assume a process that typically hasn't been necessary and has been resolved on ad-hoc basis?

It sounds like there is a need for a strategy that covers both command proposal/change, as well as low-impact deprecation of changed/replaced/removed commands. A basic change process even? Helping users re-train on new commands is a solvable problem, and a deprecation period & tool assistance can definitely assist with that.

Your mention that having duplicate commands can interrupt cheat sheets is a good note. However, that's a tooling problem, not something that is insurmountable. Of course command collisions do become a problem that isn't so easy to solve for.

These are very valid concerns that you bring up and I think that these concerns deserve a good thought.

---

Note: This isn't arguing for or against my suggestion, you could almost think of this as a side effect of the conversation, just thinking from a project standpoint. The following is separate from the OP.

They have to present a reasonable amount of 'usefulness' before I think they should be included in this repository.

I don't really disagree, though there is serious hidden nuance here:

If every decision and command that exists in the repo has been evaluated with the same level of due diligence that you wish new commands are evaluated with then this makes sense. If they have not, which I bet is the case (no negative connotation here, that's just how projects grow), then only evaluating new propositions with a single-sided due diligence cements both good & bad decisions in stone.

Guaranteeing backwards compatibility for bad/off-the-cuff/ad-hoc..etc decisions seems like a poor maintenance strategy, and an even poorer growth/adoption strategy.

---

Side note, kind of a funny thought moment:

This is a decent example of where telemetry would be handy as you could figure out how many people are using what commands.

[pokey]

pokey would ... find 'pascal' more pleasant

No I'm sticking with "hammer" no matter the outcome here. Too deeply ingrained at this point 😅. Pretty sure @AndreasArvidsson is a "pascal" guy tho

[AndreasArvidsson]

Definitely pascal here since I use that terminology as long as I can remember.

[pokey]

Re backwards compatible spoken forms, fwiw in Cursorless we have machinery where we take a snapshot of the current default spoken forms when a user first installs Cursorless, in the form of csvs that the user is free to edit, and then if we change the default spoken forms, they'll keep the original ones. They will still get any new spoken forms going forward; they'll be appended to the end of their csvs. See https://github.com/cursorless-dev/cursorless-vscode/blob/main/docs/user/customization.md

It's similar to knausj csv support, but a bit more powerful because it can add new spoken forms

We might consider doing more like this in knausj in the future

[splondike]

@douglasg14b Yeah, discussing this is probably worthwhile. Since knausj_talon is pretty central to the current Talon experience I'd be in favour of discussing and codifying some aspects of how to maintain it. To keep the issues separated though, would you like to create a new issue about this governance topic?

FYI I'm going to be out of town for the rest of the week, so am unlikely to respond to things over the next few days.