Feature Request: user-customizable default referencing command
I use the wonderful cleveref package for all my referencing, almost always. I would like to be able to set \cref{<label>} as my default referencing command in consult-reftex. (This is related to #1, I could include a commit for both issue in a PR).
Ideally, how to use this default would also be e configurable. I probably use the \cref command for about 95% of my references, so it would be far quicker and more comfortable for me if consult-reftex defaulted to it without asking at all (rather than just presenting it as the default candidate when asking), and only asked for a reference command in the rare cases I want to specify a different one.
Of course, this won't be true of all users. Perhaps there could be a custom variable like consult-reftex-prompt-for-command, defaulting to t for 'prompt for a command', and if set to nil, not prompting. The behaviour could be reversed for a particular invocation with a prefix arg, or an embark action (of course, consult-reftex-insert-reference already uses a prefix arg for rescanning, so either we would have to use an embark action, or move rescanning into an embark action).
This is a good idea, please feel free to submit a PR. Is the idea to use a buffer-local variable as discussed in the Citar thread?
This is a good idea, please feel free to submit a PR.
Thanks! I'll have a crack at it soon.
Is the idea to use a buffer-local variable as discussed in the Citar thread?
Exactly. As briefly mentioned here (and ultimately includd in the PR) it is possible to allow custom variables to be safe as buffer-local (the mechanism is actually really powerful, you assign a predicate function to the :safe property of the var, and then it is treated as safe to assign locally whenever the predicate is true). As with citar, there would be a custom variable with a sensible default. The user sets their own default by customising the variable globally, and can change the default file/buffer/dir/project locally by altering the variable in the relevant way using the usual methods.
This should be a fairly simple follow-on to #9.
There's what I hope is a reasonable solution for this in #9.
Would you verify that the solution in e973a68 is sufficient for your use?