Priming the line with tab

[lmorg]

This has strange behavior when the text is a tab character.

Originally posted by @tim-hardcastle in #12

Sorry @tim-hardcastle, I nearly missed this issue.

Are you able to add a little more detail about this behavior?
Also is there any particular reason you're adding a tab rather than spaces?

I could easily add some code to convert \t to inside the primer function. But just want to check you weren't expecting some other behavior

[tim-hardcastle]

The problem is that it puts the cursor at the start of the line rather than the end of the line when you prime it with a tab, and then when you start typing the cursor advances one character at a time, so it's always lagging behind where you're actually typing.

Spaces aren't so good as automatic indents, because one space isn't enough for indentation, it just looks weird, but more than one means that when you outdent you have to delete a number of spaces, when if you had tabs you could just be deleting one tab.

[lmorg]

Hi, I appreciate it's been a while since my response. I've been giving this problem some thought.

The core problem with tabs is they're mapped to autocomplete.

Are you using autocomplete? If not, then we could treat tabs as regular characters. But it would mean autocomplete (or at least the binding to [tab] would be disabled.

Or if you were expecting autocomplete to still work, then maybe we use spaces as the primer but have some code in readline that says "if you hit backspace and there's just spaces padding, then automatically delete 2/4/8 (definable) spaces instead of one"?

That latter approach would be very easy to implement and wouldn't break any existing functionality. But it is a bit of a kludge.

If we did go with the latter, the readline code could even be smart enough to automatically convert tab primers with n spaces too.

[tim-hardcastle]

Sorry, I've been busy too and missed your message when it came.

I'm not using autocomplete yet, but I plan to. (What I have done is syntax highlighting and that worked great, it looks just the same in the terminal as in VSCode.)

I think what you call a "kludge" is in fact sensible. Indenting and unindenting are surely things that people other than me will want to do. You could make it less kludgy and more general, perhaps, by making it so that we can specify an arbitrary list of strings that are deletable with a single delete?

Thanks for the time you've put into this.

[lmorg]

Sorry for the slow response, I've been across a few projects the last few weeks. However I'll get this update written in the next few days.

I should be able to expose an option to provide a list of characters to "combine" for multi-character deletes.

This feels like something that should be solvable with the SyntaxCompletion API but looking at that (and with the benefit of hindsight) I think the API I've exposed there is pretty terrible :(

[tim-hardcastle]

Yay!

I've added bracket-matching to my app using AddEvent, and handled what to do when it returns ErrCtrlC. Everything looks very nice.