Sublime Forum

An official/conventional `replace` command?

#1

Hi!

I’ve made a few plugins, and most of the time, when I need to replace a some text in a file, because of the edit thing, I’m oblige to create a text command that takes a list and a string, and run the .replace(edit, region, text) for me.

Here it is:

import sublime
import sublime_plugin

class ReplaceCommand(sublime_plugin.TextCommand):
    def run(self, edit, region, text):
        if len(region) != 2:
            raise ValueError('ReplaceCommand: a region like should be a list with 2 items. Got {0}'.format(region))
        self.view.replace(edit, sublime.Region(region[0], region[1]), text)

But, to make sure I’m using the right command and that I am not over writing anything, I prefix it with something. And I’m getting sick of it. I’ve got at least 5 commands that does exactly the same thing. (what I just told you :D)

So, here’s what comes out of it:

@jps Could you make a command that comes in the default package, with this gist for example (basically, takes a list, a text, and replace)? And it would have to come on st3 and st2 (otherwise it’s going to be even more annoying)

I’ll see if John agrees, but if not, here’s what I’d like to do:

Create kind of a convention: nobody creates a command called ReplaceCommand

And then, we have the choice:

  • add a file in our packages that would automatically create the file with the command (in the $packages directory I guess). Here’s the file that’d do it
  • just add in our README a part saying: if you haven’t done it for an other package, create a file called <convention_name>.py and paste this content in it.
  • create a “package” with one file with the command, and add it in our dependencies.

I guess the last solution (or the very first one ;)) is the best one, but it feels a bit weird to create a package for one file command…

I’m pretty sure some of you are wondering why we don’t just create this file in every package. The problem is that they’re going to overwrite themselves, and if someone changes it, and its package is load last, then every other package are going to get an unexpected behaviour.

If John doesn’t agree, there is in every case a convention to take. So, please let me (us) know your opinion, so we could stop dealing with this issue.

Thanks for reading,

2 Likes
#2

I don’t think the build-in packages would be the right place for that, because it would only available from a specific version upwards (and even more anoying as you said).
It may be better to add a special package (e.g. PackageUtils), which bundles such commands und is always installed by PackageControl. I don’t think Package Control depencies can define commands?

0 Likes
#3

I think that’s the good solution. @wbond Do you that’d be a good idea??

The question mark confuses me…

0 Likes
#4

You might be able to define commands, I’m not 100% sure though. If your container folder and module folder share the same name (as I did with mdpopups) I don’t think you can because it creates a conflict (kind of wish I didn’t do that in retrospect). But if your container folder is different than your module folder, you might be able to. I don’t know for sure as I haven’t tried it yet, but it seems like this would work.

I think Sublime also has an insert command in the latest ST you can call.

0 Likes
#5

I do like the idea of a built-in replace command. As it would be trivial to add, I can’t think of a reason not to add it.

0 Likes
#6

They can since they’re pretty much implemented as standard packages, but I’ve got a feeling this is an abuse of what the dependency mechanism was intended for. OTOH, this may be the only way to get support for ST2, since I don’t imagine either jps or wbond have much interest in creating a new ST2 release even for something as trivial as this.

0 Likes
#7

@r-stein, while it may be temporarily annoying, I think it is a good idea to fix now for the future.

I’ve come to the position that I can only support old versions up to a specific point. Around public betas, I start deprecating old support. People may have their reasons to stay on really old versions of Sublime, but at some point, I have to clean up my code.

2 Likes
#8

As @facelessuser mentioned, the insert command exists. To use it with arbitrary regions, you need to change the view’s selections and then call the command. However, because the content might have changed, you wouldn’t be able to restore the old selection from the old regions, so you’d have to store the old selection with View.add_regions, which is automatically adjusted, and later retrieve that for restoring.

That’s quite a lot of boilerplate for replacing text, but ideally you would be using a TextCommand for text manipulation to begin with.

By the way, at some point st3 received the ‘append’ command, which always adds content at the end of the view.

Regarding adding a dependency, you might want to check out sublime_lib.edit in PackageDev, which is a tweaked version of the edit.py script that has been floating around for a while now. It’s more flexible than the original. I did intend to add sublime_lib as a dependency but never got around to stripping it down to what is needs to be since there is a lot of stuff in it currently.

(on mobile so no links)

3 Likes
#9

I don’t have an opinion about this at the current time, and am focusing on other things at the moment.

I wouldn’t expect a new release for any version of Sublime when the desired feature can be trivially implemented in a couple of lines of Python in any package.

I agree. Any new development/features of Package Control will end up being for ST3 only. The number of ST2 users is continuing to dwindle, and there is no reason to bend over backwards to support such an old codebase with such different package mechanics.

1 Like