Feature Suggestions (General)

[Thom1729]

This issue is for feature suggestions that don't have their own issue (yet). This allows us to brainstorm fearlessly without creating a ton of issues for lightly-considered ideas.

---

All proposals summarized (constantly updated):

• [x] A file-like output panel abstraction. → #3
• [x] Predefined IntEnums and IntFlags for Sublime's constants. → #9
  • [x] A backported enum library. → #4
• [x] A buffered view abstraction that provides convenience features while avoiding API calls. → #10
• [ ] An edit batching system that defers, orders, and sanity-checks modifications.
• [ ] A pile of general utility functions for working with scopes and data structures.
• [x] A better way to listen for changes to specific settings. → #2
• [ ] An easier-to-use manager for phantoms.
• [x] A mapping to convert ST and Python text encoding names (via) → #23
• [ ] Something general to defer actions from on_modified_async until the user stopped typing for a certain amount of time. (@FichteFoll wrote a decorator for this on the forum.)

[Thom1729]

Things I'd like:

• A file-like output panel abstraction.
• A backported enum library.
• Predefined IntEnums and IntFlags for Sublime's constants.
• A buffered view abstraction that provides convenience features while avoiding API calls.
• An edit batching system that defers, orders, and sanity-checks modifications.
• A pile of general utility functions for working with scopes and data structures.
• A better way to listen for changes to specific settings.
• An easier-to-use manager for phantoms.

[FichteFoll]

I believe the current OutputPanel abstraction of https://github.com/SublimeText/PackageDev/blob/d22a77646b3b3e9ab06f81ab0b6037ea17ef2380/plugins_/lib/sublime_lib/view/output_panel.py can copied over almost entirely (while keeping in mind that the functions used might need to be adjusted to how this will be structured).

I created #2 for settings.

[Thom1729]

I've created #3 for the output panel.

[FichteFoll]

More things I'd like to see:

• [ ] Enum-like grouping of flags to be used in various API calls, such as View.add_regions. Either using the enum Package Control dependency or vendoring it. (already mentioned)
• [x] A mapping to convert ST and Python text encoding names (via)
• [ ] Something general to defer actions from on_modified_async until the user stopped typing for a certain amount of time. I wrote something like this in a gist a few years ago using threads, which is more reliable than sublime.set_timeout_async, but probably uses more resources.

[ngppgn]

I hope this is the proper place to leave suggestions (and that someone doesn't slap me if this is already in the built-in Sublime Text API) but something that would very well complement the new_window function would be a way to call and use a file picker (for example, to have custom functionality for selecting a file and setting up a window and project based on that).

Edit: please tell me if this is already possible (or absolutely impossible) and wether I should open a new issue instead.

[FichteFoll]

You mean a file picker provided by the os? That's not possible with the current api (excluding direct os calls via ctypes).

[ngppgn]

I see. Is there instead any python-based implementation of a file picker that we could 'plug-in'? I recently saw a sublime extension opening a colorpicker so that drove my hopes high (but then again, I know next to nothing about UI programming). Where should I look for this?

[FichteFoll]

I don't know if any, but that doesn't mean there isn't. Your unlikely to find it within st plugins, though, and I suspect having more luck in a pypi package.

Your gonna be looking at using ctypes to run OS-level api (or some library's for Linux), I. E. the win32api, cocoa and gtk3, most likely.

An alternative implementation could be using a quick panel or input panel to ask for a plaintext file path but provide a few helpers like completion for file or folder names.

[rwols]

It'd be nice to have a circular OutputPanel -- one that maintains at most N lines and removes old lines when new lines are printed.

[rwols]

It'd be nice to have an idempotent creator function for panels. Like a classmethod called get_or_create that will return the panel if it already exists, and otherwise create it.

Such a classmethod should have a callable argument that allows the caller to set up the panel when it is first created (and if the panel already exists, the callable is not invoked).

[FichteFoll]

Could you describe a use case for OutputPanel.get_or_create?

[rwols]

@FichteFoll

https://github.com/tomv564/LSP/blob/24ffd7f49130e41aecf76715ee78dd55696702df/plugin/diagnostics.py#L130-L132

We want the diagnostics panel created if it doesn't yet exist, and otherwise just get the existing one.

[rwols]

There should also be a BufferedOutputPanel class. Every call to OutputPanel.print now invokes the command "insert", {"characters": a_tiny_line}. Running multiple of those in succession creates janky or flickering panels for some users.

[FichteFoll]

My main concern regarding the suggested method was the callback part, but your function does not seem to use that and I was wondering what kind of setup you would need to do.

I would rather indicate in the return value whether the panel existed already to prevent indirection. What do you think of the following?

    @classmethod
    def find_or_create(cls, window: sublime.Window, name: str, *, **kwargs) -> Tuple[OutputPanel, bool]:
        panel = window.find_output_panel(name)
        if panel:
            return panel, False
        else
            return cls(window, name, **kwargs), True

Regarding the buffer, when should that be flushed? Periodically? On line breaks? The former would require a separate thread.

[rwols]

It should flush when the underlying stream is closed, or when someone manually calls flush. Most uses (for me, it seems) are temporarily creating an OutputPanel and doing a bunch of prints. As a first implementation it should not be too clever.

I suppose it could also be an option like force_writes and follow_cursor instead of a separate class. Have buffered=False by default, but users may override it.

So, I would propose a simple strategy of saving all write calls to a List[str] and flushing that in flush() with a single large "insert", {"characters": "".join(self._buffer)}. Using this strategy would allow code like this:

with OutputPanel(window, "foo", buffered=True, force_writes=True) as stream:
    stream.clear()
    for x in ("a", "b", "c"):
        stream.print(x)

Instead we still have to write code like this:

render = []
for x in ("a", "b", "c"):
    render.append(x)
with OutputPanel(window, "foo", force_writes=True) as stream:
    stream.clear()
    stream.print("\n".join(render))

I am not sure what the behavior of tell and others should be when buffering is involved, though.

[FichteFoll]

Imo we should close this issue and split the individual remaining items into separate issues, so they 1) aren't lost and 2) can be talked about in isolation. This issue was mostly made for the initial implementation before the first release where we only talked about ideas and suggestions lightly (like the OP suggests).

@rwols, if you could post your two suggestions as separate issues, that would be much appreciated. I'll go through the list of other ideas with @Thom1729 at a later point in time.

[rwols]

Sounds good to me. I'll make separate issues.

[FichteFoll]

Added a reference to a debounced decorator I just wrote and shared on the forum instead of the previous very cumbersome thread version.