Micro hangs on startup (black screen) in Termux environment when termux-api is installed

[nullpc]

On modern Android devices (Android 13/14, specifically tested on Poco M5), the micro editor hangs indefinitely on a black screen during the initialization phase if the termux-api package is installed in the environment. This appears to be a synchronous blocking call to the system clipboard that never receives a response from the Android OS.

Steps to Reproduce :

1. Install Termux on an Android 13+ device.
2. Install the micro editor: pkg install micro.
3. Install the termux-api package: pkg install termux-api.
4. Attempt to open any file or the editor itself: micro test.txt.

The terminal remains on a blank/black screen and does not respond to input.

Technical Diagnosis (Root Cause Analysis) : The issue is a Synchronous Blocking I/O hang. When termux-api is present, micro attempts to interface with the Android system clipboard. Due to Android's strict background execution limits and phantom process restrictions, the system call to the clipboard bridge does not return a value. Because micro does not have an internal timeout for this initialization step, the process enters a deadlock state, awaiting a response from the termux-api service that never arrives.

Workaround Found: Bypassing the system clipboard call by using the internal clipboard flag resolves the issue immediately: micro -clipboard internal [filename]

Environment :
Device: Poco M5 (Android 13/14)
Terminal: Termux
Editor Version: Latest available via pkg install (2.0.13+)
Dependency: termux-api installed.

Additional Context
Mentioning @termux for visibility, as this affects the user expericeen for developers using the Termux environment on modern Android versions. This bug appears to be an integration conflict between the editor's clboipard handling and the Termux-API bridge.

[Andriamanitra]

In my testing this happened only when I didn't have the Termux:API app installed (pkg install termux-api alone is not enough). I've ran into the same problem before when trying to use termux-api with other applications.

Even though in this case it's a mistake in the user's setup, we (or the upstream zyedidia/clipper?) may want to handle it more gracefully to improve user experience. I think a timeout would be preferable to hanging when the external command doesn't respond (even though timeouts sometimes cause their own issues: #3865 (comment)).

[JoeKar]

or the upstream zyedidia/clipper?

Yes, this should be handled within the clipper package.
We need to fork it then into the micro-editor organization for further modifications.
Looks like we should use CommandContext instead of Command and handle the execution in a generic way.
In case of a timeout we could use a fallback to the internal clipboard.

[niten94]

even though timeouts sometimes cause their own issues: #3865 (comment)

Yes, I think this can happen using external clipboard too when it's remote such as X11 forwarding on SSH. OSC 52 can be distinguished using EventClipboard on newer Tcell versions to somewhat address #3865, but it probably should be also possible to let Micro read without timeout.

Having no OSC 52 response cannot be easily distinguished from slow connnections. The situation and desired action would vary, so I think Micro should probably just cancel reading on keypress if delayed instead of timeout.

Yes, this should be handled within the clipper package.

Looks like we should use CommandContext instead of Command and handle the execution in a generic way.

I believe niten94/micro-clipper@cab6de9 could help since it reduces the risk of retaining one part using Command. The Custom clipboard should also be changed though, and I haven't thought how the API could be adjusted to my suggestion above.

[niten94]

Sorry, I shouldn't have decided to post a comment early in the morning. I was suggesting to wait until the clipboard responds without timeout instead, and allow the user to cancel it by pressing a key.

It's unlikely desired to use the clipboard if it takes a significant delay, so I now agree to simply add a timeout to Clipper. I think we could try to hard-code the timeout to 5 seconds for now.

The API would then require at least almost no changes.

When the fork is created, should I create a PR with niten94/micro-clipper@cab6de9 and niten94/micro-clipper@b44384c? (including slight changes)