Guys, I want to announce here that this plugin will no longer support thesaurus.com because it has taken legal action against its upstream Python project "thesaurus". Here is the email the author of that project sent to me few weeks ago.
The fated day has arrived. Earlier today as I was enjoying a lecture on undecidability, I got an email: “Infringement of Dictionary.com’s Intellectual Property Rights”. Thought you should know.
They want me to cease-and-desist by May 3rd. I don’t really know what happens to the forks at that point… I’m going to first try purging the master branch and replacing it with a README that explains the situation. This way, users can still click on the forks and find one to use. If the old code is still accessible somehow from my root url, I’ll probably have to delete the whole thing and then recreate the project at the same url, again with just a README.
I recommend this guy’s fork: https://github.com/ryh95/thesaurus . He’s added asyncio support and logging. Probably doesn’t work on Python 2.
Sigh. The world needs more Piratpartiets. One good thing might come of this— this lawyer’s going to get the best damn response imaginable. He’s going to think he accidentally emailed a crackhead poet.
Thanks for your support,
Robert Dominguez
https://robertism.com
_datamuse_api_wrapper()
in backends/datamuse_com_lookup.py
have a query_method
argument to search for antonym
s or suggest
ions. I also added this argument for the french support with synonymo.fr but how can we use this ? Only synonyms are looked up. It would be great if :Thesaurus word
would display the definition along the synonyms, and if nothing found, suggestions.
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 :
splitbelow
and splitright
instead of forcing belowright
split<C-n>
and <C-p>
instead of 'n' and 'p' characters in a promptg:tq_language
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 dictionary_api_com
to g:tq_enabled_backend
and set your api key to g:tq_dictionary_api_key
, ex:
let g:tq_dictionary_api_key='cxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxa'
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 Unknown word
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.
cs
and ca
are 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 :Thesaurus
.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_api
because I thought it would avoid confusion. But you may be right; it does sound a bit generic. I'll look into renaming it merriam_webster
.
ca
instead 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 ca
lines 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.
merriam-webster
for clarity.