Sublime Forum

Did the API for `view.find_all` change with `fmt` now being `format`?


See issue on GitHub here. Relevant docs are here.

The argument used to be named fmt. Now, as of dev build 4133, only format is accepted. Oddly minor and annoying breaking change … am I missing something?


Another undocumented API change?

It looks like the staff is going to refactor and for docs and types annotation. So there can be some typos during refactoring.



Right … I figured as much.

I’m not on the discord (I really don’t like it) … would it help to bring it up there?



The staff reads github.

1 Like


Note the parameter has always been documented as format, but the code was incorrectly fmt. As such it was assumed no one was relying on the argument name and it was changed to match the documentation. The same goes for all of the other argument names.


  • show_quick_panel has had it’s on_select argument removed or changed to on_done (this is in dev build 4133 for me).

I guess this naming change can break a lot. As there are many on_xxx callbacks, people will prefer using named arguments show_quick_panel(on_select=my_on_select_callback) over something like show_quick_panel(None, None, my_on_select_callback).

After all, obviously, ST staff uses it in core and it breaks ST now.



Well, if the code was incorrectly fmt, “relying”, as you say, includes using keyword/named arguments. I relied on LSP and pyright, and then the code itself, to infer the argument to use and presumed it was the documentation that was wonky (which, honestly, I don’t think was an unfair presumption … the sublime API and plugin development always seemed to be happy to have little “secrets” like this).

Honestly, I don’t think this is a fair presumption for python. And, unless there’s a list of such instances (I haven’t looked), I’d consider this a pretty ugly breaking change to leave undocumented … unless I’m the only one using named arguments with the API.

Is there a version number from which these changes are being made?



either 4132 (took down) or 4133.

1 Like


Agreed. I do wonder if I’m the only one trying hard to use named arguments!

Surely if the documented name of the parameter was wrong, and so could never have been used in anyone’s code, then changing the documentation to match the code would be the more sensible change than a breaking change in the code to match the inaccurate documentation.

An exception might be if the argument name (in the code) was so atrociously unhelpful that a breaking change was worth it in the long run.

But otherwise, you could keep the slightly more helpful descriptive word in the documentation while also just accurately documenting the actual name of the argument while not making any breaking changes to the API.

1 Like