sublime_text Sticky scrolling like Visual Studio or Emacs

Problem description

Would be nice to have sticky scrolling, like in emacs: https://github.com/tuhdo/semantic-stickyfunc-enhance or in the new visual studio code edition: https://www.youtube.com/watch?v=iM4Vhrk4irY

Preferred solution

having a new sublime option which enables sticky method signatures (or yaml nested keys)

Alternatives

no idea

Additional Information

No response

Aug 23 '22 12:08 h0jeZvgoxFepBQ2C

I'd cross reference, if I may, #399 and #5146, as I imagine code "contextualizing" and "outlining" share a core set of features and would benefit from being implemented together/coherently.

Aug 24 '22 04:08 maegul

VS Code now has this stabilized, and Xcode does it too (which is probably where everyone's recent interest in this came from).

Sep 15 '22 18:09 DragoonAethis

Yea ... and while a slickly implemented representation of "context" like this sticky headers would be cool, I'd just like to state that any form of information about the current context so long as it’s done decently would be a great improvement. It'd also be a generally helpful feature I'd say, just to emphasise that I personally am not too fussed about having every new feature from all the other editors.

This "sort of thing" comes, instead I think, from some basic design ideas/principles.

Sep 16 '22 03:09 maegul

I also like that idea, even though ideal functions should always fit on a screen.

Sublime Merge already has a feature to render such sticky headers exactly the way it was needed here.

If only the most recent context describing element is to be displayd, I could imagine such a feature to be based on scopes/syntax.

A tmPreference file could be used to define selectors for sticky lines. They are used to create a list of code blocks. The very next code block above the visible viewport is then displayed as header.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>name</key>
  <string>Sticky Scrolling</string>
  <key>scope</key>
  <string>source.c</string>
  <key>settings</key>
  <dict>
    <key>stickyLines</key>
    <array>
      <dict>
      	<!-- A selector to pick chunks of code for display in sticky headers -->
        <key>scope</key>
        <string>meta.function-call.identifier | meta.function-call.parameters</string>
        <!-- A pattern to do some cleanups, if needed (optional) -->
        <key>translation</key>
        <string><![CDATA[s/\s+/ /;]]></string>
      </dict>
    </array>
  </dict>
</dict>
</plist>

Sep 16 '22 08:09 deathaxe

While built-in solution would be nice, it should also be possible to override the sticky regions/lines from the API so that packages like LSP could take over and decide on its own which regions/lines should be sticky (LSP typically has a much better knowledge of such things).