haha you're right about replacing words by their antonyms! Though, I like querying antonyms, so for now, I just made a small hack to do this for my french backends. Implementing it for real would require quite some refactoring imo.
Moreover, I think your plugin is great but could benefit some improvements. Few things that came in mind right now :
splitrightinstead of forcing
<C-p>instead of 'n' and 'p' characters in a prompt
Anyhow, congratz! for your graduation :D :D I'm myself in the process of writing my PhD thesis in CS theory, and when motivation goes down, I 'sharpen my (vim) tools' ;)
So let me know if you're interrested in pull request, and/or talking further!
fix next and previous queries. The split gets on 1 line with a "--- More ---" prompt if I do 'n' then 'p'
Yes, Vim's messaging system is not ideal for frequent user interaction. But currently I don't have much idea on what can be done on it.
possibility to 'n' and 'p' to query next and previous backends in query mode and not only replacement mode
The query mode was kind of an after-thought. But what you proposed is a good idea. To achieve this, we should allow the key press on thesaurus buffer to control the
tq_framework's query session, and
tq_framework.session_terminate() only when user leave the buffer.
better algorithm for local thesaurus.txt queries (results are too long, how to truncate?)
A truncate mechanism already exists, actually, you can truncate the result based on two criteria, albeit neither of them ideal:
" This variable is for replacing candidate display. If value is -1, no " truncate of output is made upon number of definitions. Else, if number is n, " only synonyms of the first n word definitions were retained. if !exists("g:tq_truncation_on_definition_num") let g:tq_truncation_on_definition_num = -1 endif " This variable is for replacing candidate display. If value is -1, no " truncate of output is made upon number of synonyms from a single definition. " Else, if number is n, only first n synonyms of that definition will be " retained. if !exists("g:tq_truncation_on_syno_list_size") let g:tq_truncation_on_syno_list_size = -1 endif
Glad to know that you are wrapping up with your phD as well~ It's always exciting moving from one phase of life into another. Mine was in Physics. Though nowadays I am working on Applied Cryptography in a small Software company. So... although I do enjoy myself these days, the Doctor I got was a wrong kind, I think 😅. Hopefully you'll have a better time finding interesting opportunity in consistent of what you studied.
I think most of this plugin was created when I was spending most of my time writing. I made it to address my pain point of not being able to efficiently finding appropriate words while writing essays with Vim. As you are also spending most of your time writing nowadays, I believe you already have your assessment on addressing what problem can help you with your productivity the most. If you find some of the items you mentioned above addressing your pain point, please help with the feature development. PR is always welcomed~
@perelo Hi! So, I forked the repo and added a new backend for my own use: http://dictionaryapi.com (Merriam-Webster API). Is this something you would be interested in merging back into your repo? Here's the details of what the backend does:
This is the Merriam-Webster API and as such is a very high-quality back end. However, it does require registration on their website as a developer in order to gain access to the API Keys. They do explicitly state that it is free for non-commercial use up to 1,000 queries a day, which should be sufficient for most needs. Make sure you select the
Thesaurus api key, as that is what you will need in order for this backend to work.
In order to use this backend, add
g:tq_enabled_backend and set your api key to
This backend cannot work without an API key.
The DictionaryApi.com backend returns several categories of information in this order:
Also, if the word cannot be found, the API may sometimes return a list of word suggestions. These will be returned as
and allow you to choose a replacement from the list.
Also, the output is a little weird because you don't technically support anything but Synonyms. The output format ends up being something like:
Found as: Synonyms Synonyms: .... word list Found as: Related Synonyms: ... word list ...
I think it would probably look better if the
Synonyms: tag said
Select List: or
Word List: or something like that, but I didn't want to hack the rest of the project to change it.
@Ron89 My apologies. Please see my posts above if you have time. I didn't even realize til now that I had originally pinged the wrong person.
Also, I added a secondary option to the output format to break up synonyms only by the short definition. This may actually be the better default, as I think it aligns with your output format perfectly.
<leader>ca. Back-ends can optionally return antonyms by simply returning them as an additional list (identical to synonyms) in the query result. Those are then use only if
<leader>ca(bound to: ThesaurusQueryReplaceCurrentWordAntonym, a new function) is used.
@ahayman , hmm, I notice it's rather difficult for me to make comments on the exact location without a PR or sth. I think it is also a good practise to send in PR in order to merge in new feature.
Could you branch out the existing changes of your code into a dedicated feature branch, then send in PR into my testing branch? We can then communicate in detail from there. After we made all the necessary revision, I can merge in your changes in testing, trying it on my few devices. Then merge into master when it is stable.
caare used for changing the current word. Displaying the full list was made as an after thought. Come to think of it, showing both synonym and antonym really only make sense if you are just displaying the full thesaurus information without any changing goal in mind. So I think eventually if we want to do so, we should just change the behavior of
query, making it difficult to implement the change stated above. So, later if we want to do that, we probably need to refactor the code a bit.
dictionary_apibecause I thought it would avoid confusion. But you may be right; it does sound a bit generic. I'll look into renaming it
cainstead of listing all data was to avoid refactoring. While I've become somewhat familiar with the code, I'm far from being able to accomplish a refactor like that. It sounds like using
calines up with your approach, though, so I'll leave that alone.
[ word, synonyms, antonyms ]and search through it on a query. At the very least, I should add a configurable "limit". What I was concerned about was BackEnds that might return either synonyms or antonyms, but not both. In that case, for example, if the user searches for synonyms, the whole cache is updated for that word. Then, if they search for antonyms for that same word, it would return an empty array. Like I said, the caching is simple, but it worked for merriam-webster, and that was my initial use case. I think I'd need to update it for production, though.