FR: $CURRENT(word)$ interpretation

I have a hotkey (Alt+0) that uses the macro $CURRENT(word)$ to fetch the current word the caret is in and surround that word with delimiters. This proved surprisingly useful in fixing code lacking said delimiters, as SA does not delimit either declared or user-defined variables upon autocomplete, despite Always add delimiters set to Always add apostrophes ` `. But the way it works is also unexpectedly frustrating. When the caret is inside a word it works perfectly. It's the same if it is at the beginning or at the end of a word. The unpleasant part comes when words sit beside each other without any spaces between them. Yes, that sounds quite impossible, as anyone would consider that situation a single word. The problem is, SA considers semicolons, commas, periods, brackets, parentheses, exclamations marks, you name it, a word. In these cases, being at the beginning of a word has higher priority than being at the end of another word, which results in unwanted behavior.

For example, if the caret is at the location indicated by the pipe:

	Code:
	whatever\|;

hitting the hotkey on a MariaDB server will end up as:

	Code:
	whatever`;`

instead of:

	Code:
	`whatever`;

Not considering the semicolons and co. words would quickly solve this but would disable other, more creative uses of the $CURRENT(...)$ macro involving those "words". Perhaps being at the end of a word having higher priority than being at the start of another when deciding which of the words on the caret boundary to pick as a winner might provide a more versatile fix.

I'm happy to submit an enhancement request but I need your help with describing it in a formal way. What could solve issues here? If we add an optional parameter to $CURRENT(word)$, for example,

	Code:
	$CURRENT(word, letters)$ $CURRENT(word, digits)$ $CURRENT(word, letters+digits)$ $CURRENT(word, symbols)$ $CURRENT(word, all)$

and make letters recognize letters only, letters+digits recognize letters and digits, etc... would that do it?

Hmm, your idea of excluding/including stuff in the definition of a "word" is quite a bit better than what I originally suggested, so let's go with that instead. But let me ask a question. Would it be possible to add a regexp pattern as an additional option to $CURRENT(word)$? That would give users absolute control over what should be considered a word in a specific scenario. I'll totally understand if you say "no", I'm just curious about the extent of unexploited potential in that macro.

I only meant that particular macros and its behavior. I hope they don't somehow apply that behavioral change to the entire code base, in my opinion that would open a Pandora box. I have submitted an enhancement request ticket with number #SA0043956 for the above. If you want to add or change something, please let us know, I will update the ticket as required.

Would there be any way to add $CURRENT(statement)$ to that request?

Noted. I will add it to the ticket.

	Mindflux wrote:
	Would there be any way to add $CURRENT(statement)$ to that request?

Wonderful idea!

gemisigo wrote:

	Mindflux wrote:
	Would there be any way to add $CURRENT(statement)$ to that request?

Wonderful idea!

This has me wondering if $CURRENT(region)$ and some others would be useful too.