Struggling with a basic Macro

Hi folks,

I’m struggling getting a basic macro off the ground. I did read the user-guides and ref manuals, but I’m sure I’m missing something really basic.

So from uhk-agent-macro-gpt-prompt/macros.md at main · TransitNow/uhk-agent-macro-gpt-prompt · GitHub, I tried to make one for triple backticks.

Images:

But when I long-press “`” on QWM layout it just inserts one back tick (instead of the intended behaviour of 3 ticks at open and close and leaving me in the centre to instead code)
Is there anything else to be done than binding to the correct key? What am I missing?

Thank you in advance!

Apologies. I think I found the answer here - Hold key to trigger macro isn't working (literally using the same macro as me - :face_with_open_eyes_and_hand_over_mouth: )

The trick was to enable Advanced Resolution Strategy, as in:


to:

Is this necessary for all Macros?

The “simple” resolution strategy is really what is says, simple. It doesn’t even support timeouts, so cannot detect a long hold etc.

Practically all slightly more advanced macros that use ifPrimary/ifSecondary etc. would probably rely on the advanced strategy.

Please search this forum for ifHold. There should be somewhere a dev build that supports it, so that you don’t have to abuse secondary roles for hold behavior…

Also, see here: How many single key modifier/combination possible? - #6 by maexxx

Without installing a new firmware build, would this macro be equivalent to ifHold?

(hold for 500 ms for b, tap for a)

delayUntilReleaseMax 500
ifPlaytime 499 final holdKey b
tapKey a

No. This one doesn’t stop time, so if you tap c inbetween, you get cb, not bc.

OK, but for the use case of @ambareeshsrja16 I guess it would work fine. As far as I understood, the wish was for holding down ` for a triple-backtick section.

delayUntilReleaseMax 300
ifNotPlaytime 299 final tapKey graveAccentAndTilde
tapKeySeq graveAccentAndTilde graveAccentAndTilde graveAccentAndTilde enter enter graveAccentAndTilde graveAccentAndTilde graveAccentAndTilde up

Is there a reason for the simple strategy and not just making advanced the standard or even only option?

Yeah, I feel very much the same. We regularily now get questions where the answer is simply “switch to the advanced strategy”.

Yeah, but the correct answer to most of the questions is use ifHold and stop abusing secondary roles rather than switch to advanced secondary role strategy.

@kareltucek For a lot of cases you are probably correct.

Unfortunately, as far as I understand, firmware for ifHold hasn’t been released yet (official release).

Also, isn’t ifHold just syntactic sugar? I like that it’s very clear what it does, but aren’t solutions with ifPlaytime or ifSecondary advancedStrategy equally effective?

Maybe I am misreading your statements. I feel you are almost wanting people to refrain from using ifSecondary advancedStrategy. Do you see a problem with it? What would be lost if the simpleStrategy was removed and advancedStrategy would be the standard?

Unfortunately, as far as I understand, firmware for ifHold hasn’t been released yet (official release).

Alas.

Also, isn’t ifHold just syntactic sugar?

No. It has a different purpose than either of those.

but aren’t solutions with ifPlaytime

No. ifPlaytime doesn’t stop time. It does an entirelly different thing.

ifSecondary advancedStrategy equally effective?

Secondary roles are intended for an entirelly different purpose. By configuring it to behave similar to ifHold, you are loosing ability to invoke secondary roles.

I understand that it’s technically different.

For the use case that the user just wants to check that a key has been held down for long (without any typing in between), and based on that wants some special action, I would argue that it does the job (and doesn’t trigger any bad side effects).

True. That’s specific to that key then. You can still use secondary roles on other keys for ‘real’ secondary role functions.

I agree with you that ifSecondary shouldn’t be used just for timeouts / long holds. That’s a misuse; it’s not its purpose.

I think until a firmware supporting ifHold is released, delayUntilReleaseMax combined with ifPlaytime will work fine for the use cases of most users (when they want to detect a single key - without interruptions, without secondary functions - being held down vs. being tapped).

Yes, that surely will.