Ability to opt out of overlays

[vemv]

@yuhan0 wrote:

clj-refactor's use of multiple-cursors and interactive overlays often interact in unpredictable ways with Evil and/or undo-fu, corrupting the undo history.

There's a defcustom for multiple-cursors, however not for overlays which don't seem crucial for the provided features.

Looks like it can go through a defcustom? (default: enabled)

[magnars]

What overlays are these?

[vemv]

From what I checked out, all of them are related to cljr--highlight

[magnars]

Yes, seems like it's just meant to be a helpful indicator. A defcustom seems like a good idea. 👍

[yuhan0]

I had a closer look at the code and tried out some commands but couldn't find the behaviour I remembered from a few years ago, where some extract-function or extract-let feature caused highlighted overlays in multiple locations to update simultaneously.

Once after aborting this command it caused the undo-tree history to be corrupted so badly I had to revert to a earlier saved version.

But the use of overlays in cljr--highlight shouldn't be an issue at all, I may have mistaken some other package for it and generally stayed away from the more advanced refactorings since then. A defcustom for it doesn't seem necessary.

It may also have been the use of yas snippets in add-require etc? I recall the "tabstops" behaviour being quite confusing (for someone like me who doesn't use snippets) but can't recall if it ever led to undo history corruption.

Sorry for the confusing report :/

[bbatsov]

Can someone share some screenshots? That would make it clearer what we're trying to solve here.

[vemv]

@yuhan0: yes, yasnippet is used in various other functionality. Personally I never use those features.

Instead my usage in this area boils down to:

• cljr-slash, which doesn't use snippets or overlays
  • e.g. a/ -> a core.async require is inserted
• cljr-add-missing-libspec, which also doesn't use snippets or overlays
  • adds a :refer or :import.

Because it's more than possible to have productive workflow without using the more 'invasive' libs, this issue seems good to close.

Feel free to reopen in some other shape!

[vemv]

btw as you might have heard, the mentioned ops are much faster starting with the 3.x series of the middleware