Make updateScroller() open on iOS#537
Conversation
Manual workflow_dispatch that merges migueldeicaza/SwiftTerm@main into a dated branch and opens a PR against main, mirroring the pattern used in muxy-app/ghostty.
Add sync-upstream workflow
Allow downstream subclasses to override the auto-scroll-to-bottom behavior that fires on every new line of output, so apps can implement 'sticky scrollback' (don't follow output when the user has scrolled up) without having to intercept feed() or fight the view's contentOffset resets.
|
I do not mind opening up, but the question is: how is this being used in practice, because we probably should fix the root cause rather than relying on folks doing a hack. I know there are a couple of attempts in PRs to prevent this from happening in one scenario (AI models constantly updating the text when you are trying to scroll), and the issue with those PRs is that they are not quite correct (I left some comments on them). So by encouraging people to override this and manually handle this, they will repeatedly miss-implement and break the state of their own usage, which is my concern. |
|
I don't find it a hack honestly, In fact, making it possible to be more flexible in the same time avoiding any breakling changes |
|
But you did not answer my question: |
2 participants
Allow subclasses to override the auto-scroll-to-bottom behavior so apps can implement sticky scrollback (don't follow
output when the user has scrolled up). All other relevant view methods are already open; this matches them.