Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

handle other mw API dictionaries #28

Open
mooseyboots opened this issue Apr 21, 2023 · 6 comments
Open

handle other mw API dictionaries #28

mooseyboots opened this issue Apr 21, 2023 · 6 comments

Comments

@mooseyboots
Copy link

it would be nice to make this package more generic with regard to the mw API. ie also handle the "collegiate" dictionary.

the issue is that this would involve switching to API v3 and json.

i may have some time to work on it soon.

@mooseyboots mooseyboots changed the title handle other API dictionaries handle other mw API dictionaries Apr 21, 2023
@mooseyboots
Copy link
Author

i made a start on my fork here: https://codeberg.org/martianh/mw.el.

for now only short definitions are supported, as the full defs require a lot of parsing.

@agzam
Copy link
Owner

agzam commented Apr 24, 2023

This is a commendable effort. Admittedly, I have been putting off updating it to utilize the JSON API for far too long. After all, why fix something that isn't broken? It's worth noting that when I initially wrote the package, MW did not yet have the JSON API. Therefore, any contributions or pull requests that enhance the package would be greatly appreciated.

@mooseyboots
Copy link
Author

would you like me to just PR what i've done? if you look at what i've added, it uses aio for async, rather than request. i just feel more comfortable not writing callback-structured code... but that makes the package a bit frankenstein...

yeah i understand JSON is newer than your package. when i looked up the API it made me pretty amazed that they're still supporting XML. maybe it'll just stick around. but unforch the dictionary only supports JSON.

@agzam
Copy link
Owner

agzam commented Apr 24, 2023

it uses aio for async, rather than request.

That should be fine, although if I have to do it at some point, I would prefer using deferred and request-deferred. The aio approach is also acceptable, I just haven’t personally used it, therefore I have no opinion of one vs. another.

@mooseyboots
Copy link
Author

I updated the readme file and did some further cleaning up.

Have you looked at a local diff of my fork? Otherwise should I PR the whole develop branch here?

@mooseyboots
Copy link
Author

i've added a full-defs branch to my fork, which aims to handle full dictionary definitions, not just the shortdefs fields.

the org tree structure isn't correct yet, but most of the basic details from the API are implemented. (the API data structure is a real nightmare.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants