Sublime Forum

FileDiff plugin, and an etiquette question

#1

I’m announcing my plugins in order of their popularity on Package Control. #1 spot goes to zenburn, which I’m glad to see. #2 is FileDiffs. This is not surprising, because I think it offers many of the TextMate “diff” commands, but with the ST2 spin.


The commands it provides are:

  • Diff file with Clipboard

  • Diff Selections

  • Diff file with Saved

  • Diff file with File in Project…

  • Diff file with Open Tab…

If you have selected some text, “Diff file” changes to “Diff selection”. “Diff selections” is only available when there are exactly two selections in the current view. “Diff file with Open Tab” will show a picker for the open tabs (unless there are just two open, it will just pick the other tab). Diff file with File in Project uses the fuzzy finder.

The diff is calculated using python’s difflib library, using the unified_diff command. I had some headaches getting unicode to diff correctly, so bear with me if your files aren’t decoding correctly. AFAIK, it only supports UTF8. If you need to diff two files with different encodings, try using “Diff file with Open Tab”. It uses sublime text to fetch the content, so it should deal with the encoding transparently.

Next, my question about etiquette. In writing plugins, my first audience (me!) gets special consideration. I add key mappings that are intuitive to me, and add them to a Defaults (OSX).sublime-keymap file. I also create Windows and Linux versions, just for consistency. The keymap file for FileDiff looks like this:


  { "keys": "ctrl+shift+d"], "command": "file_diff_menu" }
]

When I publish these plugins, I have very mixed feelings about including these keymap files. What I like is that these files show the commands and options the package provides. What I don’t like is that hit all users will agree with my keymappings.

Is there a standard in place for including or excluding keymap files? Or what to name example files?

0 Likes

#2

As I already said in an issue on github,your keybinding hide the standard keybinding for duplicate_line in Windows and Linux.
It’s not the first time I hit this issue with installed plugins.

Not including a default keybindings file could be a solution, however if an update of a plugin add new functionality with new keybindings, there a great chance that user completely miss it. And users need some work to update manually their user keybinding files. Quite difficult to manage when you have dozen plugins installed.

The problem is that when a plugin define a keybinding that hide another one, you have only 2 choice:
-Delete the keybinding from the plugin -> update of plugin set it again.
-Redefine the keybinding in the user folder.

None of these solutions look great and they add useless complexity to the management of plugins.

Actually, I prefer the keybinding not included in the plugin, only as example in the readme. But I suppose basic users will not be happy with this solution.

Maybe there is something to do with the Package Control plugin:
Add the keybindings in a special file that is used by Package Control to create or update a user keybindings file. And if the keybinding already exists and is commented, don’t do anything.

0 Likes

#3

I think your best bet is to include the diff commands on the Command Palette (via a .sublime-commands file, see Packages/Default/Default.sublime-commands for an example), that way you won’t need to add any key bindings for it.

0 Likes

#4

Yes, this plugin has already a sublime-commands file.

But for some plugins (actually probably not this one), it doesn’t make sense to not have keybindings.
Do you think it could be possible for ST2 to generate a report of all keybindings (even hidden ones) in a standardized form ?
Something like:
keybinding,context,command

This way it would be easy to find conflicts, and it could be useful to make some kind of auto generated keybindings list.

0 Likes

#5

If bindings had unique identifiers it would go along way to solving a lot of the pain points. Disable/Override via uuid etc. Disable is an achilles heel of the current system for alt+gr users.

Jon’s been back and forth on a GUI for configuration. The current system is relatively useable and you wouldn’t want to add much more implementation complexity to it without simplifying the interface somehow.

I’m wondering if it’d be possible to do something with a scratch buffer/add_regions/Region.(meta|xpos)/folding interface?

Doesn’t have hidden ones but:
http://gmh.akalias.net/bindings-list.jpg

http://gmh.akalias.net/editprefs.gif

I’ve got a plugin but it uses helper libs ported from ST1 that aren’t cross platform, not to mention that Sublime doesn’t have site-packages support. I plan on sharing it when I got the time to deal with those issues …

0 Likes

#6

Having an unique ID for each keybinding could possibly the best solution, but like you say add complexity to the configuration.
Maybe the unique ID could be calculated with “relative path to the plugin folder”+“keybinding filename”+“complete keybinding”:
Ex:
“Default” + “Default (Windows).sublime-keymap” + “{ “keys”: “f2”], “command”: “next_bookmark” }”

It doesn’t be as flexible as an UID, because you couldn’t modify the keybinding or move it to another file without actually create a new UID, but this way you could disable (skip) a specific keybinding.

Do you mean folding unique IDs in the sublime-keymap json and possibly generate it automatically to hide them from user view ?

[quote=“castles_made_of_sand”]
Doesn’t have hidden ones but:
http://gmh.akalias.net/bindings-list.jpg
I’ve got a plugin but it uses helper libs ported from ST1 that aren’t cross platform, not to mention that Sublime doesn’t have site-packages support. I plan on sharing it when I got the time to deal with those issues …[/quote]

Look great !!! If hidden ones could be shown, it will make me cry :smiley:

0 Likes

#7

Hiding them yes. Folding them, no. Will get back to you on the details. I had some notes/code from ST1 but I think I may have lost em all in a hard drive crash last year. If sublime was able to report modified regions in the on_modified callback and set specific regions as readonly then there’s all sorts of robust view based interfaces you could create, quite easily.

Still, things don’t need to be foolproof to be useful. People don’t throw their hands up and say “It’s hopeless” because you can cut off your hand with a power saw. There’s always validation if prevention isn’t possible to implement. However, there’s usually a way if you look long enough.

Another option would be to just copy/paste some binding to User and any binding, anywhere in the stack below, that matches (bar the “disable” key) would be disabled?

But as well as disabling theres also the issue of inter package conflicts caused by Default/A-Z/User collation of bindings.

Anyway, I really should be doing something else atm :smile: A.D.D!

0 Likes

#8

Ooh! That plugin would be so useful!

On another note, I really like the way TextMate handles this problem, by displaying a pop-up menu with all the commands if multiple commands use the same key binding. Not only does that make it easy for the user to see what’s going on and select the correct command, it also simplifies for plug-in developers since you can select logical shortcuts without having to worry about clashes. So, for instance, all plug-ins that provide a Help command can bind it to shift+ctrl+h and the editor will do “the right thing” when that key combination is pressed.

0 Likes

#9

In my plugin, I added a double key press for items, for example Ctrl + Shift + t, Ctrl + Shift + l for listing todo’s - there is less noise in that space, although I suspect it will fill up quickly. Maybe if sublime keymappings had some kind of include system where you could could request the default key settings or blacklist items

0 Likes

#10

There’s definitely merit to that huh. However, there’s some properties of having a stack and taking the first matching binding as Sublime does that would be nice to maintain and I suspect crucial even for things like Vintage.

Maybe some bindings could have some metadata attached that meant continue and collate like TextMate? Maybe that would be a good default even and instead you’d attach some metadata to indicate searching should stop if that binding matched. You’d have to have a think about a sensible default I guess.

I’m guessing Jon won’t be relooking at this stuff until ST3.

0 Likes

#11

[quote=“castles_made_of_sand”]
I’ve got a plugin but it uses helper libs ported from ST1 that aren’t cross platform, not to mention that Sublime doesn’t have site-packages support. I plan on sharing it when I got the time to deal with those issues …[/quote]

  • 100^^ And if you can, please include the hidden ones (to find conflicting ones that we can eliminate).

I love ST 2 more and more each day but managing keybindings causes me headaches :laughing:

Regards,
Highend

0 Likes

#12

define:hidden

What I understood as hidden was the bindings/commands on OSX (possibly linux?) that are inherited from the system.

The plugin basically just shows all the bindings that are declared in JSON so it may already do what you want. It’s definitely handy for finding conflicts.

0 Likes

#13

There are no hidden bindings, except for a couple of hard coded things such as escape cancelling a drag in progress.

On OS X, there are is a concept of Cocoa sending down higher level commands such as “moveToBeginningOfLine”, which have system defaults (hcs.harvard.edu/~jrus/Site/S … dings.html), and can be customised by the user for all applications via editing DefaultKeyBinding.dict.

On all systems, IMEs can reserve certain key bindings that shouldn’t be overridden, such as Ctrl+Alt+ on Windows (see blogs.msdn.com/b/oldnewthing/arc … 01121.aspx).

Because of the above, it’s not always possible to query ‘if the user presses key combination X, what’s going to happen?’.

0 Likes

#14

[quote=“castles_made_of_sand”]define:hidden

What I understood as hidden was the bindings/commands on OSX (possibly linux?) that are inherited from the system.

The plugin basically just shows all the bindings that are declared in JSON so it may already do what you want. It’s definitely handy for finding conflicts.[/quote]

Hidden is probably not the right term, maybe overriden ?
I mean keybindings that are defined more than one times, so the lower priority one is never triggered.

So it look your plugin already have this feature, very nice.
I’m more and more anxious to see it in action :smiley:

0 Likes

#15

[quote]Hidden is probably not the right term, maybe overriden ?
I mean keybindings that are defined more than one times, so the lower priority one is never triggered.[/quote]

Yes, this is a better definition of what I meant. Or it other words: All keybindings from ST 2 itself and from all plugins regardless if they try to overwrite existing ones (either from other plugins or ST 2).

I would (literally) die for such a plugin :smiley:

0 Likes

#16

Just a note that I really appreciate your FileDiffs plugin. Was one thing I missed from TM. Also a vote for this method of just having an Example.sublime-keymap, it worked great.

0 Likes

#17

Hi, I love you plugin. Especially the Selection diff function. Good job.

Now, I have one little question. Is there a way to show the exact chars that are different? Like highlight them with a different color or something. Now it just tells you that the lines are different.

Other than this, works awesome.

0 Likes