Paste into Window micro misformats the pasted values

[DavidMcGaha]

Description of the problem or steps to reproduce

On Windows, using Windows Terminal in Powershell, pasted lines are mis-formatted compared to format when copied or when pasted into other apps including WSL/Linux micro

Specifications

Commit hash:
OS: Windows
Terminal: Windows Terminal/Powershell

Version: 2.0.14
Commit hash: 04c5770
Compiled on August 27, 2024

[JoeKar]

Looks like it misses the carriage return ( resp. \r).
Maybe it has something to do with #3303, but I'm unsure here.

[fbd-ss]

Can confirm, copy paste has been an issue for a long time. Maybe a bit more testing before release

[JoeKar]

Can confirm, copy paste has been an issue for a long time. Maybe a bit more testing before release

None of the maintainer has Windows as primary OS.
Especially the Windows variant still has some real major issues.
We try to sort them out, but this is nothing we can solve in short term due to limited free time for maintenance.

Issues which seem to be related with this "staircase" effect are:

• Pasting causes text to seemingly cascade to the right #1343
• Windows terminal: Copying data (with click or ctrl-c/ctrl-shift-c) pastes as a single string in other output. #1926
• copy/paste got step shape result #2396

There are more, but I'm unsure if they really describe the same situation.

What makes me wonder a bit about this situation is, that the issue seems to exist a very long time already, but no Windows user took the time to take a deep dive into micro's code to help and support?
It is easy to complain, but hard to offer its own free time.

There is definitely some help wanted.

Things to check/reproduce:

• Does the same behavior take place in case autoindent and/or smartpaste is disabled?
• Which behavior takes place in case the setting is changed as mentioned in copy/paste newline issue in WSL/Windows Terminal #2388...everything as one-line?

[Neko-Box-Coder]

I don't remember this happening to me when using Windows, I have "keepautoindent": true, and "smartpaste": false,

[niten94]

I think I was able to know why formatting changes, but I do not know a good way to fix it.

The indentation probably changes because autoindent is enabled and text is pasted using key press events. Bracketed paste is not enabled on Windows in the fork and upstream of Tcell, and Ctrl-v is handled by default in Windows Terminal settings.

Bracketed paste seems to be supported on Windows Terminal, but there may be other environments or terminal emulators where the control sequence is displayed because it isn't supported.

There are a lot of issues and questions about using the clipboard, so I think > help copypaste could be rewritten to be able to read easily like other help topics. A link in README.md also needs to be added.

[fbd-ss]

I never noticed before, but when on a local network, the crazy indent doesn't happen. But when over tailscale, 90% of the time it will do it.

[niten94]

What is the OS of the machine on the local network and machine accessed using Tailscale where you used Micro, and terminal emulator (like Windows Terminal) you used when accessing both?

In summary, my previous comment was about paste input not distinguished with regular key input, because bracketed paste is not enabled in the Windows version of Micro.

Micro also uses the method that is set in clipboard option to paste if it receives Ctrl-v by default, but Ctrl-v is binded in default Windows Terminal settings so Micro receives pasted content instead. I just noticed that setting clipboard to terminal isn't currently supported on Windows too.

Edit: I'm sorry that my tone wasn't somewhat good. I wasn't in a good mood a bit but I should have not posted at such times. I have tried to rewrite both comments. These can also be done as a workaround on Windows for now:

• temporarily enabling paste option when pasting (> set paste on|off)
• using Paste action in micro
  • local session or remote GUI access: setting clipboard option to external
  • Micro on non-Windows platforms (like ssh, probably WSL too): setting clipboard to terminal
  • Windows Terminal
    • binding keys like Alt-v with Paste in micro (bindings.json or > bind Alt-v Paste)
    • removing Ctrl-v binding in Windows Terminal settings

[elzik]

Things to check/reproduce:

• Does the same behavior take place in case autoindent and/or smartpaste is disabled?

I have the indenting issue on Windows. Using this sample text one my clipboard:

- Alpha
	- One
	- Two
	- Three
	- Four
	- Five
- Beta
	- One
	- Two
	- Three
	- Four
	- Five

I get the following resulting text in micro after pasting with default options set in settings.json:

- Alpha
	- One
		- Two
			- Three
				- Four
					- Five
					- Beta
						- One
							- Two
								- Three
									- Four
										- Five

Then if I try various options based on autoindent and smartpaste.

autoindent Value	smartpaste Value	Pastes Correctly?
false	false	✅
false	true	✅
true	false	❌
true	true	❌

So, it seems that this is related to autoindent; by setting only this to false in settings.json, I no longer see the issue. But obviously, I now have to manually indent every line as I type.

For me, I would like autoindent to be in operation when I typed but not when I paste from the clipboard.

[Andriamanitra]

For me, I would like autoindent to be in operation when I typed but not when I paste from the clipboard.

As a workaround you could bind Ctrl+v to do a sequence of actions like this:

{
    "Ctrl-v": "command:setlocal autoindent off,Paste,command:setlocal autoindent on"
}

[Neko-Box-Coder]

@elzik

Please refer back to @niten94 's temporary solution, in particular

• temporarily enabling paste option when pasting (> set paste on|off)

• using Paste action in micro

  • local session or remote GUI access: setting clipboard option to external

  • Micro on non-Windows platforms (like ssh, probably WSL too): setting clipboard to terminal

  • Windows Terminal

    • binding keys like Alt-v with Paste in micro (bindings.json or > bind Alt-v Paste)
    • removing Ctrl-v binding in Windows Terminal settings

and let us know if the problem still exists. I personally rebind it to "Alt-v" but rebinding windows terminal "Ctrl-v" might be a better choice.

As to @JoeKar 's comment

...
There are more, but I'm unsure if they really describe the same situation.

What makes me wonder a bit about this situation is, that the issue seems to exist a very long time already, but no Windows user took the time to take a deep dive into micro's code to help and support? It is easy to complain, but hard to offer its own free time.

I use micro on both Windows and Linux and unfortunately I personally use Alt instead of Ctrl for everything so never really encountered this issue. I am happy to test/implement/help (with my limited free time) if there's any need.

The problem is that there isn't really a "good" solution that I can think of, since the Windows powershell/terminal will "intercept" the "ctrl-v" keybind and replace it with the clipboard content as mentioned by @niten94 .

Technically, the problem is the colliding keybinds between micro and the terminal, which does exists even with Linux terminal when using ctrl, for example "ctrl-h".

The solutions I can think of are:

1. Mentioning this windows issue in README, ideally with admonition
2. Set autoindent to default to false on Windows, unless explicitly set in settings.json
   a. A one-time warning prompt on Windows when this setting is turned on would be good.
3. Adding a hack to measure wpm and temporarily turn off autoindent (or enable the paste mode) if an inhumanly high wpm is detected for more than a threshold amount of time period.

3 might be a bit hacky but I think it would "workaround" this issue, and might even benefit other use cases such as pasting via SSH without OSC 52.

Additionally, I think we should also do a check to see how many of the default bindings are being "intercepted" by default, on Windows Powershell, old school command prompt, and windows terminal with raw command.

[elzik]

@Andriamanitra

As a workaround you could bind Ctrl+v to do a sequence of actions like this:

{
"Ctrl-v": "command:setlocal autoindent off,Paste,command:setlocal autoindent on"
}

Thanks but this doesn't seem to help, presumably because Windows Terminal has the Ctrl-v binding.

@Neko-Box-Coder

Please refer back to @niten94 's temporary solution

Thanks, I have a better understanding of this now and just using the Alt-v binding for Paste seems to work the best for me. This seems to be one of those "simple" problems where the root cause and fix is complex. It should be solvable; other similar editors such as edit appear to paste as expected whilst still providing auto-indent functionality - I am not sure if there is anything to be learned from them.

[Neko-Box-Coder]

@elzik

It should be solvable; other similar editors such as edit appear to paste as expected ...

Yeah, I have tested it on Windows terminal, it is working as you said. Interesting...

When you do pasting multi-line text on micro, or programs other than Edit, it should have a pop up asking if you want to continue pasting the text or not in Windows terminal. And I don't see the same behavior in Edit.

Are you observing the same behavior?

@JoeKar

The ctrl-v problem only happens on Windows Terminal, but not other variants (powershell, command prompt, etc.)

After staring at microsoft's edit code for quite a bit of time, my guess would be to do with the input mode set in

https://github.com/microsoft/edit/blob/main/src/sys/windows.rs#L202

vs

https://github.com/micro-editor/tcell/blob/master/console_win.go#L271

Specifically, the ENABLE_VIRTUAL_TERMINAL_INPUT flag maybe.

The other (quite annoying) things are

1. setlocal paste on|off gives me Invalid Option. Only set paste on|off can actually set it. (Meaning it will format settings.json everytime you want to do pasting`
2. Even when paste is set to on, it still doesn't help. The staircase still exists which is caused by the auto-indent.
   a. It is fine on Linux though, but I guess most of the terminals on Linux support bracketed paste anyway.

[elzik]

@Neko-Box-Coder

When you do pasting multi-line text on micro, or programs other than Edit, it should have a pop up asking if you want to continue pasting the text or not in Windows terminal. And I don't see the same behavior in Edit.

Are you observing the same behaviour?

Yes, I am.

I don't know Rust, but I also took a look at edit's source, and there does seem to be code aimed at overriding the default Windows Terminal behaviour and distinguishing text added to the buffer from keystrokes vs a paste operation. In mod.rs it there is a paste function which always calls the write function with raw = true:

https://github.com/microsoft/edit/blob/7ece8c5a389ed9ef33402d6ebaff4e835ff23375/src/buffer/mod.rs#L2049

What this seems to do in the write function is skip this bit of code when raw = true removing any auto-indentation when pasting from the clipboard:

https://github.com/microsoft/edit/blob/7ece8c5a389ed9ef33402d6ebaff4e835ff23375/src/buffer/mod.rs#L2123

if !raw && !self.indent_with_tabs {
    let end = memchr2(b'\t', b'\t', line, line_off);
    plain = &line[line_off..end];
}

As I say, I don't know Rust, so I may be way off here.

[JoeKar]

@JoeKar

The ctrl-v problem only happens on Windows Terminal, but not other variants (powershell, command prompt, etc.)

After staring at microsoft's edit code for quite a bit of time, my guess would be to do with the input mode set in

https://github.com/microsoft/edit/blob/main/src/sys/windows.rs#L202

vs

https://github.com/micro-editor/tcell/blob/master/console_win.go#L271

Specifically, the ENABLE_VIRTUAL_TERMINAL_INPUT flag maybe.

In micro we're using the "legacy" branch.
Still we've to port zyedidia/tcell#26 somehow or backport the upstreams change into legacy or bring our micro-related modifications on top of the currents upstream master within the master branch of our tcell fork.
I'm unsure if this is related, most probably not...