Show Invisibles and Multiple Selections / Cursors

[amxmln]

Hi! First of all, I love this project and am very much looking forward to integrating it into a couple ideas of mine. Thank you for building something like this! 😊

I have two feature requests that I’d like to make:

1. An option for showing "invisibles", i.e. space and tab characters, usually as little dots and arrows (see "Invisible characters" option in VS Code) -> Perhaps this could be supported by adding the characters only to the "overlay" and not the textarea?
2. Support for multiple cursors / selections like in the "big" code editors—I realise this will be probably quite complex and might be beyond the scope of the project, but since I didn’t see an issue for it yet, I figured I might as well ask. 😉

Keep up the awesome work and thank you for your time and effort!

[FIameCaster]

An option for showing "invisibles", i.e. space and tab characters, usually as little dots and arrows (see "Invisible characters" option in VS Code) -> Perhaps this could be supported by adding the characters only to the "overlay" and not the textarea?

There's actually a Prism plugin called Show invisibles that does this. It works by modifying grammars, which is not possible here. Adding these dots and arrows as an overlay instead is a great idea! The VSCode extension only shows these invisibles when they're selected. It looks rather messy when they're always shown, so I think we should do the same. The extension would have to update the overlay every time the selection changes. It would likely not have amazing performance when lots of text is selected, but it should be fast enough.

Support for multiple cursors / selections like in the "big" code editors—I realise this will be probably quite complex and might be beyond the scope of the project, but since I didn’t see an issue for it yet, I figured I might as well ask. 😉

Yup, this would likely require re-implementing the browser's native cursor and selection handling. I don't see this happening.

[amxmln]

Ah yes, I stumbled over that plugin myself, but it really does look messy. 😅 I think just showing spaces and tabs would be enough and personally I like having them visible all the time, so maybe that could be configurable? Especially since making them available only within the selection might come with a performance cost. 🤔

RE multiple cursors: completely understandable, that’s what we have CodeMirror et al. for. 👍

[FIameCaster]

personally I like having them visible all the time, so maybe that could be configurable

Making that configurable with a boolean argument would not be an issue.

Especially since making them available only within the selection might come with a performance cost.

Having them visible all the time would improve performance when changing the selection since then they won't have to be updated. Simultaneously, it would perform worse when typing since then there usually won't be any text selected.

[panoply]

Though not part of PCE itself, extending language grammars will allow you to capture invisibles. Definitely not advisable, considering it will result in perf hits doing it on the grammar level, but worth noting it is not impossible even in the current state.

https://github.com/user-attachments/assets/3b698799-eb53-4c54-bf20-8dcf48c4e745

[FIameCaster]

I added the showInvisibles extension in the most recent 3.4.0 beta. It's used in the autocomplete demo if you want to try it.

By default, the invisibles are only shown in selected text as showing them all the time led to worse performance overall. The extension takes a boolean argument to always show them.

I tried using a mask-image to style the invisibles, but this had poor performance, so I switched to clip-path instead.

[amxmln]

Thanks for the update! I might be doing something wrong, I couldn’t get the invisibles to show up in the example you linked—but I had a look at the code.

What if instead of using clip-paths, you used Unicode characters like the official Prism invisibles plugin? 🤔

[FIameCaster]

I couldn’t get the invisibles to show up in the example you linked

Oops, I somehow sent the wrong link. Here's the correct one: https://stackblitz.com/edit/vitejs-vite-tjcjyl?file=src%2Fautocomplete.ts

What if instead of using clip-paths, you used Unicode characters like the official Prism invisibles plugin?

Can't imagine that yielding better performance, plus it's less customizable.

[amxmln]

Now it’s working! Looking great. Do you have any figures regarding how much this impacts performance? Especially when showing them for the entire document?

Can't imagine that yielding better performance, plus it's less customizable.

If it doesn’t impact performance, then the clip-paths are just fine!

Thank you so much for adding this so quickly! The experimental autocomplete looks pretty mind-blowing as well! I’m very impressed.

[FIameCaster]

If it doesn’t impact performance, then the clip-paths are just fine!

Only the mask images were bad due to having to paint the SVGs most likely. The clip paths performed much better.

Do you have any figures regarding how much this impacts performance? Especially when showing them for the entire document?

Typing performance is roughly halved when they're always shown. It also adds more elements to the DOM, slowing down the entire website. When changing the selection, always showing them also performs worse unless most of the document is selected.

[amxmln]

That’s quite the price. 😅 Thank you for adding the feature nonetheless. 👍

Feel free to close this issue whenever it suits you, I’m not sure if you usually keep them open until a new release is out.

[FIameCaster]

Safari and Chrome didn't render masks or clip paths on inline elements properly, so I had to add display: inline-block. Unfortunately that caused another issue. Tab characters can have a different width depending on which column they start in, but with display: inline-block they always have the same width.

Basically, I switched to Unicode characters in pseudo-elements; → for tabs and · for space. It works without issue and performs about the same as clip-paths. I did prefer the look of the previous tabs, but it's obviously more important that it works properly.