Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Selection is not pinned to text #9

Open
dolik-rce opened this issue Jan 12, 2024 · 8 comments
Open

Selection is not pinned to text #9

dolik-rce opened this issue Jan 12, 2024 · 8 comments
Assignees
Labels
bug Something isn't working

Comments

@dolik-rce
Copy link
Contributor

When I select some text in the terminal, the selection stays in the same area when the buffer scrolls.
It doesn't happen when I scroll using mouse wheel, only when new text is added to the buffer.

I'd expect the selection either to disappear when the buffer moves or to keep moving with it. Current situation is that I select something and there is a chance that it will move away before I can copy it. And even worse, I might copy something completely different than I wanted.

Simple steps to reproduce: Select something, then press Enter few times.

@ismail-yilmaz ismail-yilmaz self-assigned this Jan 13, 2024
@ismail-yilmaz ismail-yilmaz added the bug Something isn't working label Jan 13, 2024
@dolik-rce
Copy link
Contributor Author

This seems to work correctly now, I can't reproduce it anymore.

Did you do some intentional changes that might have affected this? Perhaps the wrongly exported variables? It must have been something since friday, because I ran in to it at work.

@dolik-rce
Copy link
Contributor Author

I found one corner case, where this still happens: If I open a file in less, select something and then scroll. The selection stays at the same place, so something completely different is selected after scroll. This might also happen in other programs using same mode of rendering I guess.

For comparison, libVTE keeps the selection "pinned to text" when scrolling down, but it disappears immediately on scroll up, probably because whole screen is redrawn. This behavior makes little more sense to me.

@dolik-rce dolik-rce reopened this Jan 22, 2024
@ismail-yilmaz
Copy link
Owner

ismail-yilmaz commented Jan 22, 2024

I was going to comment on this... Yes, this is a problem and I know the reason and I'll try to come up with a solution ASAP. The reason is TerminalCtrl keeps track of the row/col (nothing unique or updated). And that is the reason of the faulty behavior. When the screen scrolls or changes it does not update accordingly. That needs to be changed.

@dolik-rce
Copy link
Contributor Author

I've finally figured out why it suddenly started working for me 🙁 It mostly works fine if I try it on my local machine. But for work I use profile which runs ssh directly and then it doesn't work. I'm not sure what is the difference, in both cases it effectively runs bash, the $TERM value is the same, all other Bobcat configuration is the same too (I think).

@ismail-yilmaz
Copy link
Owner

ismail-yilmaz commented Jan 27, 2024

I've finally figured out why it suddenly started working for me 🙁 It mostly works fine if I try it on my local machine. But for work I use profile which runs ssh directly and then it doesn't work. I'm not sure what is the difference, in both cases it effectively runs bash, the $TERM value is the same, all other Bobcat configuration is the same too (I think).

It can depend on many things on SSH but the reason for the TerminalCtrl's behaviour is the same: On default buffer with scrollback (history) buffer on, when the buffer hits it s upper limit (default is1024) it starts to drop lines and this invalidates the position (anchor) of the selection. It needs to be updated accordingly (this is also how I fixed the finder's highlight position). On other scenarios (alternate buffer and/or raw mode) apps can overwrite the existing lines. In that case the lines are invalidated, thus we need to cancel the selection.

The fix is in the queue but not pushed yet.

@ismail-yilmaz
Copy link
Owner

I've finally figured out why it suddenly started working for me 🙁 It mostly works fine if I try it on my local machine. But for work I use profile which runs ssh directly and then it doesn't work. I'm not sure what is the difference, in both cases it effectively runs bash, the $TERM value is the same, all other Bobcat configuration is the same too (I think).

One solution could to be to add a selection attribute to the cells. This way, not only the selection will be permanent, but also the mutating operations (clear, erase) can invalidate the selected section automatically.

@dolik-rce
Copy link
Contributor Author

One solution could to be to add a selection attribute to the cells. This way, not only the selection will be permanent, but also the mutating operations (clear, erase) can invalidate the selected section automatically.

Yes, that sounds like a good way to do it. It might also solve some other problems (e.g. I noticed that the highlight sometimes stays on the screen after a command is pasted).

Also, it could allow to only select cells with some content. In current implementation, you can select empty space on the screen. But it can't be copied, because it contains nothing, not even whitespace:
screen_1709324691

@ismail-yilmaz
Copy link
Owner

ismail-yilmaz commented Mar 1, 2024

One solution could to be to add a selection attribute to the cells. This way, not only the selection will be permanent, but also the mutating operations (clear, erase) can invalidate the selected section automatically.

Yes, that sounds like a good way to do it. It might also solve some other problems (e.g. I noticed that the highlight sometimes stays on the screen after a command is pasted).

Also, it could allow to only select cells with some content. In current implementation, you can select empty space on the screen. But it can't be copied, because it contains nothing, not even whitespace: screen_1709324691

Actually, that is intended. :) While TerminalCtrl is not at all an xterm clone, it tries to mimic xterm's behavior very closely. And that's how xterm (and some other terminals such as Konsole, mintty, urxvt, etc.) does it.

I think this issue (pin) is the most severe problem TerminalCtrl has now. So I'll better find a solution to it asap.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants