First a tangent (on publicity, project direction, and VIM)

[alerque]

First a tangent. As I remarked in the python repo, the ideal thing to come out of this is {cli, lib, unixtool} x {cmos, nyt, ap, ...} x {en, sp, fr, tr, ...} x ... that is well-maintained, with emphasis on the CLI/unixtool. I think you are an ideal person/project to spearhead this if your interest lies there, given your package background, choice of rust (popular, suitable for lib), and existing support for a second language (Turkish). The style logic is secondary, and people have the wrong idea about it anyway. Coming online in waves is fine. Some have said it is ill-defined, which is true and not. Putting these guidelines into code is an opportunity to define it. It may interact with existing linguistic libraries, it may need new ones. It may be an opportunity to employ ML techniques.

NVIM is going to take over but VIM will hang around for a long time. To that end something that works with both is best. That likely means a Vimscript wrapper around the CLI. Maintaining this may or may not be in your scope. With CLI integration you can use something like

vnoremap <silent> <leader>T "zd:call setreg("z",system("clibinary",@z),"b")<CR>"zP
nnoremap <silent> <leader>T ^vg_"zd:call setreg("z",system("clibinary",@z),"b")<CR>"zp

IMO the luarocks solution, while slick, is probably doing too much work. This thing should live as a unix tool. Is it in scope for an nvim plugin to install a unix tool? I would say no.

I also suggest devoting 1/3 of the time you choose to spend on this to outreach until it becomes self-sustaining. I'm your first fork. If you do all this and nobody knows about it it's for naught.

Originally posted by @kevinlawler in #21 (comment)

[alerque]

First a tangent. As I remarked in the python repo, the ideal thing to come
out of this is {cli, lib, unixtool} x {cmos, nyt, ap, ...} x {en, sp, fr, tr, ...} x ... that is well-maintained, with emphasis on the CLI/unixtool.

I definitely agree this is the way to go, and having looked around the Rust/Python/Lua/Javascript/Perl ecosystems there is a very fragmented set of libraries (and practically no cli tools) that implement some style or language or another, but essentially no attempts to combine these.

Given my personal use cases were for a { cli, rust crate, lua rock, nvim plugin } × { tr, en } it was quite apparent that there was nothing out there for me. Once my own personal need matrix was covered it was an obvious move to flesh it out to add Python, multiple style guides, etc.

The style logic is secondary, and people have the wrong idea about it anyway.
Coming online in waves is fine. Some have said it is ill-defined, which is
true and not. Putting these guidelines into code is an opportunity to define
it.

To some extent this is true, although editing publications that strictly adhear to NYT or CMOS or AP isn't excatly a change to influence those style guides. That's another reason I think other guides like DaringFireball's have become more popular: they were published by programmers not legacy book editors and hence the implementation drove the guideline at least a little bit.

It may interact with existing linguistic libraries, it may need new ones.

Calling on Rust crates to identify parts of speech, proper names, acronyms, etc. is certainly something we can consider if necessary and if it can be done without bloating things too much. I don't think calling on things not written in Rust to back the algorithm is going to be too viable, which is why I can't just pull in this Javascript French. Re-implementing it shouldn't be too hard, but just standing on shoulders isn't possible the same way it was for English.

It may be an opportunity to employ ML techniques.

Color me not very interested.

NVIM is going to take over but VIM will hang around for a long time. To that
end something that works with both is best.

Yes, like I said I'm open for both. Having native Lua dependencies and using API calls in Neovim is much cleaner than what VIM needs so it suited me to start there, but I'm not opposed to making way for VIM too.

That likely means a Vimscript wrapper around the CLI. Maintaining this may or
may not be in your scope.

I think that's probably fair. That or using VIM's Python bindings. I know some plugins already work that way somehow but I haven't looked into it closely in a while. It's been a long time since I ditched VIM.

With CLI integration you can use something like

vnoremap <silent> <leader>T "zd:call setreg("z",system("clibinary",@z),"b")<CR>"zP
nnoremap <silent> <leader>T ^vg_"zd:call setreg("z",system("clibinary",@z),"b")<CR>"zp

This should be pretty easy to setup as a VIM plugin and just assume folks have the CLI tool. I'm certainly open to PRs either to document this binding option or wrap it in a little vimscript plugin.

IMO the luarocks solution, while slick, is probably doing too much work.

I needed the LuaRocks module anyway for publishing projects. The NeoVIM plugin was a walk in the park after that was done.

This thing should live as a unix tool.

It does.

Is it in scope for an nvim plugin to install a unix tool? I would say no.

Nope, definitely not.

But is is in scope for a Neovim plugin to install a Lua Rock (most newish plugin managers are supporting this and the Neovim development team is pushing for it).

For VIM (or anti-LuarRocks Neovim folks) we can just ask users to have the CLI tool available.

I also suggest devoting 1/3 of the time you choose to spend on this to outreach until it becomes self-sustaining. I'm your first fork. If you do all this and nobody knows about it it's for naught.

You're right I probably should, but I've always hated the PR end of things. At the end of the day I built this for my own use and I do get that out of it.

I suspect the best promotion is to keep enabling more use cases, e.g. a Visual Studio Code plugin, a Typst package, a CTAN package for LaTeX, etc. At least that's where I'd be most motivated to put effort, but then again I am terrible about PR so why am I talking?