Built-in terminal emulator quirk - part 1

[ghost]

I can't select text beyond the visible viewport. I need to copy the output from the build system printed in the terminal emulator to report it to the upstream project. However, my mouse can't move past the visible viewport. I tried selecting from top to bottom and from bottom to top, but it didn't work.

[ghost]

@SpartanJ This is the most important issue for me. I can set other matters aside as minor, but not this one. Do you have a solution yet?

[SpartanJ]

Check the latest commit. It should work now. To select the range basically use the the mouse wheel to go up and down and keet the left mouse button down all the time. ctrl+shift+c is for copy (or right mouse button -> Copy). It was not copying the whole range, functionally I haven't changed anything, I can later implement to auto scroll when mouse is down and out of the terminal boundaries.

2025-12-18.10-45-21.noaudio.mp4

[ghost]

Check the latest commit. It should work now. To select the range basically use the the mouse wheel to go up and down and keet the left mouse button down all the time.

I don't know that I could do it like this! After years of using different terminal emulators, I never needed to since I could just select text like in Word or Notepad. BTW, this is inconvenient for me, as I can only hold one mouse button at a time, but this requires me to hold both the left mouse button and the mouse wheel.

ctrl+shift+c is for copy (or right mouse button -> Copy).

I always use right mouse button -> Copy to be sure that it will always work.

It was not copying the whole range, functionally I haven't changed anything, I can later implement to auto scroll when mouse is down and out of the terminal boundaries.

Yes, exactly this. Other terminal emulators do this by default. Please implement it. Thank you.

[SpartanJ]

Added.

[ghost]

I don’t know how serious this bug could be, but here’s what happened: I tried to build a large C++ project (CopperSpice to be clear), which produces a lot of output on the screen. After several minutes, the compilation failed with exit code 1. By that point, the output had already filled the screen well beyond the scrollback limit.

When the screensaver triggered, I stepped away for coffee. Upon returning, I tried to use the middle mouse button to scroll up and see where the compilation failed. However, scrolling was completely broken. I couldn’t move either up or down. The screen flickered heavily, and instead of scrolling through the build output, it jumped into shell history.

Update: If you persist in trying to scroll up (as I did), eventually the flickering stops. But you can only scroll within the currently visible viewport, not beyond it. This is far below the configured scrollback limit. Scrolling down again takes you back into shell history, and scrolling up repeats the same flickering behavior with the viewport as the hard limit.

I’m not sure if this issue is related to your latest commit, but I always use the latest nightly build.

[ghost]

Things get worse if I open a new terminal tab and then switch back to the previous tab. After bypassing the flickering, I can scroll up only a few lines at most.

[SpartanJ]

I've never seen that, next time could you please capture some screenshots or better a video? This is hard to comprehend without a visual representation.

tried to use the middle mouse button to scroll up

Hopefully you men the mouse wheel, because otherwise you just pasted your clipboard contents.

[ghost]

It's the mouse wheel.

[ghost]

@SpartanJ How can I disable the middle mouse button from traversing shell history?

[ghost]

That's not a bug, it pasted your selection (normal behavior in terminals). Although ecode does not behave exactly like most terminals in that sense, most terminals will keep the last selection buffer and paste always the last selection (not from clipboard). I should change it to the standard behavior.

I have never selected the text Updating 1491ca3..4ddd60c! Please read my comment again. I have never selected it. I have no idea why the middle mouse choose that text to paste instead of what I have copied from the web browser. This is a fresh start of ecode -t. No text has ever been selected at all.

[ghost]

most terminals will keep the last selection buffer and paste always the last selection (not from clipboard).

I know the behavior you are describing and I have utilized all the time on other terminal emulators. For example: select portion of the previously entered command and middle mouse to paste it, this way, I don't have to delete the part of the command I don't want like when I use the shell history to get the previous command.

But this is not the case on ecode.

[SpartanJ]

if no selection was present ecode just fallbacks to the clipboard contents, it's not like ecode is just getting data from the thin air

[SpartanJ]

Many improvements to the paste operation has been added, it now behaves like most popular terminals and uses primary selection and clipboard depending on the shortcut, commit here.

[ghost]

if no selection was present ecode just fallbacks to the clipboard contents, it's not like ecode is just getting data from the thin air

I'm sure the text Updating 1491ca3..4ddd60c was not in the clipboard. The content in the clipboard is what I copied from the web browser, which I confirmed by pressing Ctrl+Shift+V. Maybe this is an instance of memory corruption. Whether it’s caused by the software or the hardware, I don’t know. Let’s put it aside for now, and I’ll let you know if I experience it again.