Raise default max signal queue size to 1024

[shironakoushi]

Summary

• see fix(clipboard): make clipbboard signal batching opt-in for backward compatibility #215 (comment)

Most players who encounter the 256-line paste limit will simply be left confused and start looking around for the reason why their paste doesn’t work. Simply increase the default 256-line limit to 1024 would be a solution.

Checklist

• I have tested this PR in DevEnv
• I have tested this PR in Fullpack
• This PR is in compliance with the GTNH AI Policy
• This PR requires another PR in order to merge

[hxync]

I think the previous behavior of adding a config option for this was not a good idea. First, in the official documentation https://ocdoc.cil.li/component:signals, the description of this signal is as follows:

"This signal is queued by keyboards when a user pastes text from the clipboard (Shift+Ins or middle mouse button). Note that the maximum length of the text that can be pasted is limited (can be changed in the config)."

Here it only mentions the length limit, and there is no description at all about splitting by line.

Meanwhile, in OpenOS there are only two places that respond to the clipboard signal. One is in the edit library, where edit.lua#L641 correctly splits the clipboard signal by line.

The other is in the cursor library, where cursor.lua#L147 also correctly splits the clipboard signal by line.

Moreover, the paste behavior of io.read, io.stdin:read, and term.read is all implemented by the cursor library, and it correctly responds to the single-line read behavior of term.read({nowrap=true}) (nowrap also defaults to true).

I think reading input through the interfaces provided by OpenOS is standard behavior. Even for a user-implemented UI that includes input functionality, one can call tty.setViewport to set the input area, then use term.setCursor to move the cursor to the starting position, and then use term.read to read. As for text editors, the implementation of the edit library will undoubtedly be referenced by people.

In my view, the official API documentation has never mentioned this, and the OpenOS implementation has no design specifically for it. Therefore, I think this is a bug rather than an intentional design, and the original fix was reasonable.

[hinyb]

I think the previous behavior of adding a config option for this was not a good idea. First, in the official documentation https://ocdoc.cil.li/component:signals, the description of this signal is as follows:

"This signal is queued by keyboards when a user pastes text from the clipboard (Shift+Ins or middle mouse button). Note that the maximum length of the text that can be pasted is limited (can be changed in the config)."

Here it only mentions the length limit, and there is no description at all about splitting by line.

Meanwhile, in OpenOS there are only two places that respond to the clipboard signal. One is in the edit library, where edit.lua#L641 correctly splits the clipboard signal by line.

The other is in the cursor library, where cursor.lua#L147 also correctly splits the clipboard signal by line.

Moreover, the paste behavior of io.read, io.stdin:read, and term.read is all implemented by the cursor library, and it correctly responds to the single-line read behavior of term.read({nowrap=true}) (nowrap also defaults to true).

I think reading input through the interfaces provided by OpenOS is standard behavior. Even for a user-implemented UI that includes input functionality, one can call tty.setViewport to set the input area, then use term.setCursor to move the cursor to the starting position, and then use term.read to read. As for text editors, the implementation of the edit library will undoubtedly be referenced by people.

In my view, the official API documentation has never mentioned this, and the OpenOS implementation has no design specifically for it. Therefore, I think this is a bug rather than an intentional design, and the original fix was reasonable.

I appreciate you looking into the official docs and OpenOS source code. However, in a 13-year-old mod, undocumented behavior essentially becomes the API contract.
Even if OpenOS can handle \n perfectly, many players have written their own raw event.pull("clipboard") scripts, custom GUIs, and even entirely custom OSes (like MineOS) over the years. Because the clipboard event has never emitted a newline character before, many of these community scripts naturally assume they don't need to parse \n. If we change it now, their layouts and logic will silently break.
At this point, whether this behavior started as a bug or an intentional design doesn't really matter anymore. As the original dev pointed out, users rely on this exact behavior.

[shironakoushi]

I definitely understand the concern about existing community code, and that was also why I was previously willing to compromise and keep batch clipboard cutting disabled by default.

At the same time, I wonder if we should also consider the longer-term evolution of OpenComputers. Python 3, for example, was released in 2008, and Python 2 was officially discontinued 12 years later. Of course, I’m not suggesting that the two situations are directly comparable, but it does make me wonder how much compatibility we should expect to preserve indefinitely for behavior that was never formally documented.

OpenComputers itself is now around 13 years old. I think it’s worth leaving some room for the API and its underlying mechanisms to evolve as well. As the project grows, the amount and complexity of information being communicated through signals may also grow, and there may eventually be limitations that the older behavior simply cannot accommodate very well.

I certainly don’t want to disregard the existing community or break things unnecessarily. I just wonder whether continuing to preserve every historical behavior is necessarily the best approach in the long run. If we’ve confirmed that the newline does not conflict with OpenOS or the standard library, I’m finding it increasingly difficult to justify keeping the new behavior disabled by default.

Perhaps it would be reasonable to treat this as a small compatibility transition rather than something that needs to be preserved indefinitely.

[shironakoushi]

However, I think it’s still worth keeping in mind that 1024 is ultimately only a workaround. In practice, it’s difficult to imagine users of any reasonably capable operating system accepting that it simply cannot handle more than 1024 lines by default. I suspect that for the vast majority of users, such a limitation would simply make the operating system feel incomplete or inadequate, regardless of the technical reasons behind it.

If there are still concerns or further points to discuss, perhaps we could merge this PR (1024-line limit) for now and continue the discussion in a separate PR, possibly one that enables batch clipboard by default.

[hinyb]

However, I think it’s still worth keeping in mind that 1024 is ultimately only a workaround. In practice, it’s difficult to imagine users of any reasonably capable operating system accepting that it simply cannot handle more than 1024 lines by default. I suspect that for the vast majority of users, such a limitation would simply make the operating system feel incomplete or inadequate, regardless of the technical reasons behind it.

If there are still concerns or further points to discuss, perhaps we could merge this PR (1024-line limit) for now and continue the discussion in a separate PR, possibly one that enables batch clipboard by default.

I agree with moving forward, but honestly, I still feel changing the default behavior isn't worth the risk. Since many script authors have left the community, any broken code will likely stay broken forever. Multiple line paste just doesn't offer enough benefits to justify forcing a breaking change by default, especially when server owners can easily enable it in the config.
Also, in my opinion, the clipboard is really just for quick snippets, and 1024 lines easily covers that. I doubt most players will ever hit that limit. For massive scripts, OpenOS already has pastebin and wget. It doesn't mean the OS is incomplete. Breaking backward compatibility for a rare use case is simply a bad idea.