Sublime Forum

**FHTheron** · November 12, 2017, 9:20pm

Just wanted to show some non-arithmetic use of Arithmetic I’ve used the Inline Python plugin for this for a long time and having it with a result preview in the command palette is pretty nice, thank you. I would suggest calling the command Evaluate if it will always be able to do this generic python type of eval

I often need to move small groups of bits to weird offsets for hardware development (registers with specific bit fields) and being able to type a binary literal is often much nicer than figuring out how it looks in hex.

**OdatNurd** · November 13, 2017, 2:21am

I assume it’s already been noticed elsewhere, but I’m seeing the same behaviour with an unmodified Adaptive theme (although Default works); the preview seems to always render in black text, so in Adaptive with the Monokai theme, it’s essentially black on dark gray and unreadable.

**FichteFoll** · November 13, 2017, 3:12am

Quick note that the arithmetic command is also available in a similar fashion via Insert Nums, which uses a custom syntax for inserting a sequence of numbers, supporting piping of the currently selected text and stop expressions (allows to generate exactly n lines, for example).

**videni** · November 13, 2017, 5:23am

hi, guys , I sincerely ask for the Simple Chinese input method in Ubuntu gnome fcitx, all Chinese Linux users are waiting for this feature, 3rd party solution is not perfect for current situation, Can we propose this feature ahead of your agenda?

**wtgee** · November 13, 2017, 4:42am

New command palette doesn’t seem to do fuzzy matching very well. Specifically, whereas before I could type “add” to get “Git: Add Current File”, now it seems to match very stupidly and not learn what is, arguably, my most frequently entered command. Not really sure it’s a bug so much as a (mild) complaint. Should I expect it to be learning my commands?

**wtgee** · November 13, 2017, 5:14am

That sounds more irate than I am. I’m super satisfied with all the development going into sublime lately and think the developers are doing a great job!

**rchl** · November 13, 2017, 12:11pm

Is fix for high cpu usage, that was mentioned in changelog, related to painting? I’ve switched from DA UI theme because it seemed to trigger high CPU usage.

**mugukamil** · November 13, 2017, 12:46pm

I have also issues with jade/pug syntax…

**wbond** · November 13, 2017, 3:18pm

We don’t ship Jade/Pug in the default packages, so it would probably be best to start by reporting the issue to the syntax developer and they can do a little debugging to see if something in core broke the syntax.

**mugukamil** · November 13, 2017, 3:48pm

you right man, sorry about it.

**wbond** · November 13, 2017, 4:23pm

In terms of the 85% width of the command palette, that was done on purpose for two reasons:

The preview mode with input params and an HTML preview requires a set width to render the minihtml document inside of
Command palette commands with multiple inputs append them after the command name in the text area. There isn’t a way to know how many there will be, or how long they will be, so we need to provide a reasonable max width as the default.

We’ll discuss how best to handle extremely large windows.

**deathaxe** · November 13, 2017, 4:53pm

Maybe the width should be defined by something like max_chars * char_width to let the width adapt to a maximum amount of supported characters to render. So users with large displays and smaller fonts might see a smaller command pallet.

In general I prefer the new fixed width. It wouldn’t feel very well, if the width changed each time a new input handler is committed or the list of items are updated. Cutting off long list items / paths wouldn’t be too nice, too.

**addons_zz** · November 13, 2017, 5:13pm

Why just not dynamically increase the width as required?

Almost on 100% of the use cases of the command palette, I do not require it to be more larger and the old size on build 3143.

Being this big is only useful to hide the window’s code behind it, i.e., it is not useful at all.

If you cannot implement an dynamically adjustable command palette, then add a setting to control the default window width, instead of hard code 85%, then I can set it to something like 32%.

Command palette commands with multiple inputs append them after the command name in the text area. There isn’t a way to know how many there will be, or how long they will be, so we need to provide a reasonable max width as the default.

You can use the same feature as Windows File Explore does when the width does not fit on those 32% I set:

The preview mode with input params and an HTML preview requires a set width to render the minihtml document inside of

I do know exactly what is this, it seems it should be this:

Which is something I am not using or planing to for now. Then setting the maximum width as 32% or let it be just like on build 3153 is much better.

**wbond** · November 13, 2017, 5:18pm

Because from a user experience, having the width jump around and your text/input jump around feels jarring.

As core and plugins start using the new API, you very likely will.

It isn’t that we can’t, but that we think it would be a bad idea/experience.

This is a public API, and we are very confident that there will be a number of packages starting to use this in the near term, plus I am sure we will be using this more in the core now that it is available.

Like I mentioned previous, we are going to discuss the width issue on very large screens.

Some of this will just be getting used to the UI change. Every time that a UI you use regularly gets changed it feels wrong at first. Generally after a few days to a week things seem to settle down.

**deathaxe** · November 13, 2017, 5:38pm

Nearly all packages requiring some input or at least those providing extra quick panels to list values can and should use it. I already thought about using that for my Skins package and change the Theme-Menu-Switcher, too. Both are very good examples for the value the new API adds to ST.

I am pretty sure this feature will find a couple of friends in the near future as one could create a dynamically created command line with user input out of it.

**addons_zz** · November 13, 2017, 6:08pm

You are correct, if the size is changing very often could be bad, like expanding and shrinking. But this could be solved by not shrinking it, after expanding, so when I enter on Arithmetic mode, the size would not be shrinked to fit only this:

But kept on the maximum size it was required to be since it was opened. For example,

When I open the command palette, its size is calculated to WIDTH as it was on build 3153.
Then if I enter on some special mode which has a narrower width, its width is kept WIDTH
But if the special mode requires WIDTH bigger than the original WIDTH, its width is expanded to WIDTH2
If the special mode does not requires more such increased width, it width is not shrinked and is kept to WIDTH2
If the special mode requires more than WIDTH2, then its with is increase to WIDTH3.
If the special mode does not requires more such increased width WIDTH3, its WIDTH3 is kept.
…

Can you add a setting to enable dynamically increase the size without shrinking it? This setting would be disabled by default, then who do not like a standard big size can experiment with it.

**deathaxe** · November 13, 2017, 5:50pm

@jps, @wbond: How about using the folder_exclude_patterns in the View Package File command?

A package developer might have a couple of packages as VCS repositories installed. The list currently shows all files, even all the database files located under .git folders or .hg, … Maybe even some cache paths like .mypy_cache, … .

Using the folder_exclude_patterns could help to keep the list clean.

I also played with the file_exclude_patterns but using fnmatch slows down list creation drastically.

Here is an example of the file with global folder excludes applied:

import sublime
import sublime_plugin

class ResourceNameInputHandler(sublime_plugin.ListInputHandler):
    def name(self):
        return "name"

    def placeholder(self):
        return "Name"

    def list_items(self):
        settings = sublime.load_settings("Preferences.sublime-settings")
        folder_exclude = [f + '/' for f in settings.get("folder_exclude_patterns", [])]
        file_exclude = settings.get("file_exclude_patterns", [])

        items = []
        for f in sublime.find_resources(''):
            if f.startswith("Packages/") and not any(fe in f for fe in folder_exclude):
                items.append(f[len("Packages/"):])
        return items


class ViewResourceCommand(sublime_plugin.WindowCommand):
    def run(self, name):
        self.window.run_command("open_file", {"file": "${packages}/" + name})

    def input(self, args):
        if "name" not in args:
            return ResourceNameInputHandler()
        else:
            return None

**addons_zz** · November 13, 2017, 5:57pm

Perhaps then, the command palette size:

Could always be set to 85%, when it enter on some special mode like Arithmetic, but kept its original size as on build 3153 when it is first opened.
Be kept on 85% size when exiting the Arithmetic mode, to respecting the do not shrink policy.

If you think it would be bad for the user, just let the user decides the behavior by settings.

This would solve the problem of having the command palette hiding the code 100% of the times it is opened. Therefore it would only hide the code when some special mode requires wider width.

**wbond** · November 13, 2017, 6:34pm

There isn’t an arithmetic mode. The new command palette doesn’t close and reopen, but instead allows a continuous flow of command -> input*. If you play around with Arithmetic, you can see that if you backspace with no input, it removes the Arithmetic selection and returns to the command palette.

**Surya** · November 13, 2017, 6:55pm

In the default Monokai theme the result of arithmetic operation is black making it invisible.

Dev Build 3154