Revisit integrations with eshell/vterm/etc using *fields*

[mentalisttraceur]

trafficstars

Building on what I documented over in evil#852, I'd like to raise the idea that instead of defining alternatives to evil-{change,delete}{,-line} and so on for modes with partially read-only lines, it might be easier/cleaner/simpler to hook/wrap those modes to make sure the field property is being added correctly.

In brief: ielm is a lot like eshell, vterm, and so on. But 0, dd, cc, and so on automagically work as expected out-of-the-box in IELM , because of fields.

IELM puts the field property on its prompt, which is the native Emacs way to say "this is a separate things of text, don't traverse/edit it as if it's one with the adjacent text".

Evil (by design rather than accident, I hope) respects Emacs fields.

So for example, if we just make sure to add a field property to the Eshell prompt (and update its rear-nonsticky property to include field, or to just be t to cover everything), then we don't need rebind/redefine anything in Evil.

The same goes for vterm, term, etc, etc, etc.

There are some quirky edge cases, but if someone wanted to explore this, they might find that solving those edge cases would require less work than half-reimplementing/half-pasting evil-{change,delete}{,-line} and so on.

[jojojames]

Sounds interesting but based off what I've read here, it seems like the changes would be in the core libraries and not in evil? Is that right?

[mentalisttraceur]

it seems like the changes would be in the core libraries and not in evil?

Ideally yes, at least in the Eshell case.

But I'm assuming people generally install evil-collection when they don't want to figure out how to integrate Evil and a mode, let alone figure out how to contribute a patch upstream.

So I think in some cases evil-collection could help by automatically setting some configs or installing hooks (or, in cases where fixing the mode would trample over user config, providing helper functions so that people can apply the necessary customization to those modes in a way that composes correctly with their config, but with a one-liner rather than having to know and maintain all the boilerplate).

If I have time I'd like to write an example later of what I think that looks like for eshell.