Auto complete wordlist: possible write "#word" to trigger but Fastkeys inserting "word" (without #)?

Discussion, questions and support.
cadudesun
Posts: 84
Joined: Jun 6th, ’15, 03:28

Post by cadudesun » May 2nd, ’19, 01:36

Hi,

I'd appreciate your help.

I have auto complete wordlists with words that I don't want appearing in the pop-up menu always.

Then I thought to insert a prefix (e.g. # or $ or %) before the word (i.e #word), in order the pop-up menu just appears when "#word" is typed, but when inserting Fastkeys would ignore the #, just inserting "word".

Is it possible? How?

Thanks for the assistance!
Carlos
User avatar
Marko
Posts: 1016
Joined: Mar 2nd, ’13, 21:02

Post by Marko » May 3rd, ’19, 03:38

This is currently not possible. Could you use a manual auto complete instead?
cadudesun
Posts: 84
Joined: Jun 6th, ’15, 03:28

Post by cadudesun » May 3rd, ’19, 16:18

Thanks for replying Marko!

Actually, I've been fighting with manual auto complete using "raw" words for a while.

The problem is that I have wordlists handling three languages (Portuguese, Italian and English). Besides common words, I have also wordlists with code syntax and app commands. It turns to be very unproductive, difficult to choose/select from those wordlists from the same pop-up auto complete window.

As workaround, I tried to set some words starting with _ (underline). So the words with prefix _ appear just when really requested. The problem is that I need to manually delete the _, what became also unproductive.

Then I post this topic, having in mind to find out more efficient workflows with auto complete from wordlists.

Maybe one year ago (even before), I have experienced in Fastkeys to insert the prefix # before the word (i.e #word), having Fastkeys removing # when the word is inserted. Maybe there isn't this option anymore? Or maybe I'm wrong, confused about this possibility.

Anyway, exemplifying the use, I could have all words in Portuguese (my main language, which I typed most) without prefix. Then foreign language words (Italian and English) with prefix #. And code syntax and app commands with prefix $.

Would there be any workaround for now, or even you could consider a Fastkeys improvement in a forthcoming release, that could perform this workflow?

Best,
Carlos
User avatar
Marko
Posts: 1016
Joined: Mar 2nd, ’13, 21:02

Post by Marko » May 4th, ’19, 18:42

Hi Carlos, the prefix is only available in Text Expander (Preferences/Text Expander). We will think what might be the solution for your scenario.
User avatar
Marko
Posts: 1016
Joined: Mar 2nd, ’13, 21:02

Post by Marko » May 12th, ’19, 17:36

Possible solution would be to introduce option for the user to specify the prefix characters to be removed from the beginning of the word. For example
In case of prefix characters: #_$
#, _ and $ would be automatically removed if they appear at the beginning of the word.

Any comments are appreciated.
cadudesun
Posts: 84
Joined: Jun 6th, ’15, 03:28

Post by cadudesun » May 13th, ’19, 19:32

Hi Marko,

Thanks for addressing this functionality!

If possible, please consider removing the characters per each auto complete list, which would allow amazing flexibility.

See a prototype in the attached image.

Image
User avatar
Marko
Posts: 1016
Joined: Mar 2nd, ’13, 21:02

Post by Marko » May 15th, ’19, 18:21

Not sure this is needed, I see no advantage vs my solution. Why would you need a setting for each item/list?
cadudesun
Posts: 84
Joined: Jun 6th, ’15, 03:28

Post by cadudesun » May 15th, ’19, 22:34

Are you thinking about a global setting?
User avatar
Marko
Posts: 1016
Joined: Mar 2nd, ’13, 21:02

Post by Marko » May 16th, ’19, 07:07

Yes, you would define a list of prefixes in Preferences/Auto Complete. Whenever any of listed prefixes would appear as a first character of the word, it would be removed.
cadudesun
Posts: 84
Joined: Jun 6th, ’15, 03:28

Post by cadudesun » May 18th, ’19, 13:16

Hi Marko,

Regarding the global setting "list of prefixes in Preferences/Auto Complete. Whenever any of listed prefixes would appear as a first character of the word, it would be removed".

Considering my use case, I think a global setting would limit the potential of the forthcoming functionality.
I do think that prefixes (# $ _) managed per wordlist would bring more benefit, delivering a functionality that will fit any user case.
Taking the same examples I posted previously, this is why a global setting would limit my workflow:

I have wordlists handling three languages (Portuguese, Italian and English). Besides common words, I have also wordlists with code syntax and app commands. With the new functionality, I could have all words in Portuguese (my main language) without prefix. Then foreign language words (Italian and English) with prefix #. And code syntax and app commands with prefix $.

Up to this point, it sounds the global setting would solve the scenarios, but not.
I have lists with prefix # that I would like keeping working because the words are true tags (#1now, #2soon, #follow, #reply, etc.). I insert tags like that even in Microsoft Word (prefix # is very important for searching). It would be difficult to choose globally: for the sake of improving my foreign language lists (Italian and English) with prefix #, should I reject my tagging workflow?
With FastKeys providing the functionally per each wordlist, I could have my tagging list keeping #, also going ahead improving my different languages wordlists, removing #.
I could illustrate similar cases with the prefixes $ and _

Further reflexion:
- I'm referring to thousands of words, so dealing with Text Expander to fill the gaps of a global Wordlist setting wouldn't fit. And because of the huge amount of words, I think at least these three prefixes are needed for achieving enough flexibility (# $ _).
- For managing plenty of words, Wordlist are really powerful because you can keep a text editor with tabs (e.g. Notepad++) having all lists opened at same time, in a way you can add, remove, change, and sort words in light speed.
- Emphasizing a point already comment, FastKeys delivering a prefix control per list will fit any user case, for the present and future time. IMHO it would be outstanding, complete flexibility for the sake of efficiency and productivity.

The best with FastKeys development!
Carlos
Post Reply