Build system options selection panel in Sublime Text 2. (or how the bike was invented)
Idea and implementation: click the shortcut in SublimeText2, get a panel with a list of build options automatically generated from the file of the selected Build System, select the option you want and observe how the project’s build process is displayed directly in the Sublime Text 2 interface.
I will say right away that here I am sharing my invaluable experience in joint development of the ProjectBuild plug-in for Sublime Text 2, because as a result, only experience was gained, because, as it turned out, there was no need to implement this plug-in, and the whole process turned out to be an invention of the bicycle. Sadly, the experience is still priceless. The narration will be such that the "bicycle" will be said only at the end.
The result of the previously written article “Automating the Build of a Project in Sublime Text 2 using Ant” was the ability to call in Sublime Text 2 various build options of the selected Build System (using the example of Ant) using the assigned shortcut keys for them. (now I would also use the word “setting” in the topic of that post)
What I didn't like about this approach:
')
And then I tried the plugin ProjectBuild for Sublime Text 2 from snegovikufa, which was written to me in the comments. What I really liked was a drop-down panel with a list of commands. By selecting an item from the list provided, it was possible to run the corresponding command. All the settings of this plugin were stored in a separate file, access to which was from the menu of Sublime Text 2 itself, where it was possible to list the list of names and the corresponding commands. Simply put, this plugin could be configured to launch a “third-party program” directly from the interface of Sublime Text 2. And in particular, it could be used to run Ant with the names of the necessary targets. I screwed ProjectBuild to my AntProjectBuilder.sublime-build in the forehead. So this solved the second problem. We assign one shortcut (yes at least “Ctrl + Shift + B”), it forms the ProjectBuild plug-in panel in the Sublime Text 2 interface, where you can select and run the desired command in accordance with the ProjectBuild configuration.
But the plugin worked in such a way that, while calling the “third-party program,” although it did not block the interface of Sublime Text 2 itself, it left no trace of the success or failure of the call. For example, my command line was called, Ant worked on it, and it disappeared. In the console itself Sublime Text 2 traces left. And this was achieved only with the blocking of the Sublime Text 2 interface. That is, the command was called, the Sublime Text 2 interface hung, and after working out this process, they spat out all their output into the Sublime Text 2 console. The whole process was not “observed”.
And with this use, when ProjectBuild has to implement the functionality of the build mechanism of Sublime Text 2, the first problem was not solved - the explicit indication of options, and there was also excessive configuration. We had to configure ProjectBuild to create a list of options for the panel, although this list of options already exists directly in the "* .sublime-build" file of the selected Build System itself. I contacted snegovikufa , he quickly brought me up to date on how to work with GitHub, and I proceeded to change the plugin.
I was very pleased with this “accounting code” system (of course I am exaggerating), I have never worked with git before, but it took less than half an hour to deal with it, especially since there is an exhaustive git guide for both Linux and and for Windows users on GitHub itself. I wrote a working code, snegovikufa qualitatively reworked it on the subject of Python notation, and so on, correcting each other and writing off, got the result, licked the working result now in the dev branch Thing! My first impression, collaborative development and git (GitHub in particular) are made for each other.
There are official and unofficial documentation. At first, it seemed that the Sublime Text 2 API capabilities were not so great either, but they were quite enough. What was missing was implemented in Python. As I said earlier, I don’t know Python, but to develop the intended functionality of the plug-in I didn’t need much knowledge. Yes, and snegovikufa promptly corrected potentially incomprehensible moments for third parties. The only thing I wanted to find for the sake of interest, but I could not, is the list of all possible keys and Settings values ​​that exist in Sublime Text 2 by default, although it may have been looking poorly.
According to the format of the "* .sublime-workspace" file, the documentation states that this is JSON format, but it was found out that an error could be generated when json-parsing this file. The fact is that the json-key in its data may be empty, but this was ignored by the ProjectBuild plugin like this:
Even with Sublime Text 2 in the "* .sublime-build" file, a variable with "$ project_path" can be used, and I don’t understand why the developers of Sublime Text 2 did not provide for its (and other) use in shortcuts for shortcuts, where , for example, called "third-party" for Sublime programs. Maybe this is for security reasons, so that some plug-in with a triggered shortcut key doesn’t put something “itself” on the project, but still.
Now for ProjectBuild no config is needed. You just need to choose the Build System you need (a standard system or your own, like my “AntProjectBuilder.sublime-build”). Save the project in Sublime Text 2 in such a way that the project manifest file "* .sublime-workspace" is in one of its root folders. The ProjectBuild plugin tracks the presence of this file and its uniqueness, since information about the current Build System is taken from it. When changing the Build System in Sublime Text 2, do not forget to save the project so that the above file is updated. Click the keyboard shortcut assigned to ProjectBuild and see the panel with a list of build options. The list is generated automatically by the description of the variants of the Build System selected in Sublime Text 2 existing in the "* .sublime-build" file.
The problems indicated at the very beginning of the article were successfully solved: one shortcut is involved and it works with the build mechanism of Sublime Text 2 itself and in its interface without tight binding and explicit naming of the called build variants.
The plugin still has room for improvement, for example, platform-specific options are now ignored, which can be specified in the Build System file, but for me personally, so far enough is enough, and I need exactly what it is now.
In fact, it is difficult to say whose contribution is greater, and whether it is important if, as a result, the ProjectBuild plugin has become what it probably should have been. And what a sin to conceal, I feel an indescribable feeling of pride that here there was no such thing in the interface and functionality of Sublime Text 2, and now there is one, and that it is written in part by me. (here I did not know about the "bicycle", oh, woe is me, woe)
The old version of ProjectBuild will most likely be converted into a OneHotkey plugin for grouping commands into one keyboard shortcut, not necessarily building commands, but simply launching "third-party" programs for Sublime Text 2 programs, etc. and there the settings file, which used to be in ProjectBuild earlier and turned out to be superfluous for it, since it contained redundant information for the build mechanism, is already useful.
All the islands have long been open ... As it turned out, already initially in Sublime Text 2 you already have the option of calling the options panel of the current Build System, you just need to add a keyboard shortcut:
And this panel, however sad it would be to talk about it, is more convenient, since it does not tie you to the "* .sublime-workspace" file and demonstrates the assigned keyboard shortcuts for each option, if any. However, it does not support their sorting, and the plugin can be modified to order the options (although maybe again I don’t know what).
Probably all that can be squeezed out of all this is to go back to OneHotkey.
Thanks for attention.
I will say right away that here I am sharing my invaluable experience in joint development of the ProjectBuild plug-in for Sublime Text 2, because as a result, only experience was gained, because, as it turned out, there was no need to implement this plug-in, and the whole process turned out to be an invention of the bicycle. Sadly, the experience is still priceless. The narration will be such that the "bicycle" will be said only at the end.
Introduction
The result of the previously written article “Automating the Build of a Project in Sublime Text 2 using Ant” was the ability to call in Sublime Text 2 various build options of the selected Build System (using the example of Ant) using the assigned shortcut keys for them. (now I would also use the word “setting” in the topic of that post)
What I didn't like about this approach:
- Different Build Systems could have completely different names of their variants, and keyboard shortcuts were already explicitly tied to specific variant names, which could not be in another Build System. My assumption was that most developers don't often have to switch between multiple Build Systems, and the developer basically works with a single Build System. And if the developer wants, then change the shortcut keys again. But agree, it is a bit annoying. And this must be remembered. And in the sequel, also
- You need to remember all the shortcuts you assigned. It is clear that there are basic “F7”, “Ctrl + B”, “Ctrl + Shift + B” - but for each of your options there will be another combination. This means that you need to either redefine the shortcut key that already exists, or find the unused key, which would be convenient for both fingers and the brain. I tried to find convenient unoccupied ones, but I stopped on redefining. And this is also depressing, since it could potentially deprive you of the original capabilities of these combinations when they are redefined. And also to restrict later, when you need new shortcut keys for new plug-ins, and convenient ones have already been set up for calls to different build-options.
')
And then I tried the plugin ProjectBuild for Sublime Text 2 from snegovikufa, which was written to me in the comments. What I really liked was a drop-down panel with a list of commands. By selecting an item from the list provided, it was possible to run the corresponding command. All the settings of this plugin were stored in a separate file, access to which was from the menu of Sublime Text 2 itself, where it was possible to list the list of names and the corresponding commands. Simply put, this plugin could be configured to launch a “third-party program” directly from the interface of Sublime Text 2. And in particular, it could be used to run Ant with the names of the necessary targets. I screwed ProjectBuild to my AntProjectBuilder.sublime-build in the forehead. So this solved the second problem. We assign one shortcut (yes at least “Ctrl + Shift + B”), it forms the ProjectBuild plug-in panel in the Sublime Text 2 interface, where you can select and run the desired command in accordance with the ProjectBuild configuration.
But the plugin worked in such a way that, while calling the “third-party program,” although it did not block the interface of Sublime Text 2 itself, it left no trace of the success or failure of the call. For example, my command line was called, Ant worked on it, and it disappeared. In the console itself Sublime Text 2 traces left. And this was achieved only with the blocking of the Sublime Text 2 interface. That is, the command was called, the Sublime Text 2 interface hung, and after working out this process, they spat out all their output into the Sublime Text 2 console. The whole process was not “observed”.
And with this use, when ProjectBuild has to implement the functionality of the build mechanism of Sublime Text 2, the first problem was not solved - the explicit indication of options, and there was also excessive configuration. We had to configure ProjectBuild to create a list of options for the panel, although this list of options already exists directly in the "* .sublime-build" file of the selected Build System itself. I contacted snegovikufa , he quickly brought me up to date on how to work with GitHub, and I proceeded to change the plugin.
Offtopic on the process of reworking the plugin ProjectBuild
Github
I was very pleased with this “accounting code” system (of course I am exaggerating), I have never worked with git before, but it took less than half an hour to deal with it, especially since there is an exhaustive git guide for both Linux and and for Windows users on GitHub itself. I wrote a working code, snegovikufa qualitatively reworked it on the subject of Python notation, and so on, correcting each other and writing off, got the result, licked the working result now in the dev branch Thing! My first impression, collaborative development and git (GitHub in particular) are made for each other.
API Sublime Text 2 and Python
There are official and unofficial documentation. At first, it seemed that the Sublime Text 2 API capabilities were not so great either, but they were quite enough. What was missing was implemented in Python. As I said earlier, I don’t know Python, but to develop the intended functionality of the plug-in I didn’t need much knowledge. Yes, and snegovikufa promptly corrected potentially incomprehensible moments for third parties. The only thing I wanted to find for the sake of interest, but I could not, is the list of all possible keys and Settings values ​​that exist in Sublime Text 2 by default, although it may have been looking poorly.
According to the format of the "* .sublime-workspace" file, the documentation states that this is JSON format, but it was found out that an error could be generated when json-parsing this file. The fact is that the json-key in its data may be empty, but this was ignored by the ProjectBuild plugin like this:
... json.load (f, strict = False) Even with Sublime Text 2 in the "* .sublime-build" file, a variable with "$ project_path" can be used, and I don’t understand why the developers of Sublime Text 2 did not provide for its (and other) use in shortcuts for shortcuts, where , for example, called "third-party" for Sublime programs. Maybe this is for security reasons, so that some plug-in with a triggered shortcut key doesn’t put something “itself” on the project, but still.
The final plugin code
Spoiler
import sublime import sublime_plugin import json import sys import os class ProjectBuildCommand (sublime_plugin.TextCommand) : def run (self, edit = None) : # Save file if dirty if self.view.is_dirty () : self.view.run_command ('save') ############################################ # # .sublime-workspace # # # workspace_file = None root_folders = self.view.window ().folders () for dir_ in root_folders : for dir_item in os.listdir (dir_) : if dir_item.endswith ('.sublime-workspace') : if workspace_file == None : workspace_file = os.path.join (os.path.normpath(dir_), dir_item) else : self.showError ( 'Must be only one ".sublime-workspace" file in project root folder.\n' 'Plugin found %s and %s files.' % (workspace_file, os.path.join (dir_, dir_item))) return if workspace_file == None : self.showError ( 'There are no ".sublime-workspace" file in any root folder of project.') return self.debug(workspace_file) # ############################################ ############################################ # # Build System # with open (workspace_file) as f : try: workspace_json_data = json.load (f, strict = False) except Exception, e: self.showError ( 'File .sublime-workspace is empty or has incorrect json data') return if not 'build_system' in workspace_json_data : self.showError ( 'There are no "build_system" value in %s file.\n' 'Choose Build System and save project.' % workspace_file) return build_filename = workspace_json_data['build_system'] self.debug(build_filename) # ############################################ ############################################ # # Build System # # build_filename_fullpath = os.path.normpath( os.path.join(os.path.dirname(sublime.packages_path()),build_filename)) if not(os.path.isfile(build_filename_fullpath)): self.showError ( 'Plugin could not find Build System file: "%s".' % build_filename_fullpath) return self.debug(build_filename_fullpath) # ############################################ ############################################ # # JSON # with open (build_filename_fullpath) as f : try: json_data = json.load (f) except Exception, e: self.showError ( 'File %s is empty or has incorrect json data' % build_filename_fullpath) return # ############################################ ############################################ # # build- Build System # build_variants = [] if "cmd" in json_data: build_variants.append (['Default', " ".join (json_data["cmd"])]) for variant in json_data.get ("variants", {}) : build_variants.append ( [variant['name'], " ".join (variant['cmd'])]) # ############################################ ############################################ # # . # def run (selected) : if (selected >= 0) : self.execute_variant (build_variants[selected][0]) names = [name for name, args in build_variants] self.view.window ().show_quick_panel (names, run) # ############################################ def execute_variant (self, variant_name) : self.view.window ().run_command ("build", {"variant": variant_name}) def showError (self, err) : # Sublime API # , sublime.error_message ('ProjectBuild:\n\n%s' % err) def debug (self, message) : # change True to False or vice versa if (False): print message findings
Now for ProjectBuild no config is needed. You just need to choose the Build System you need (a standard system or your own, like my “AntProjectBuilder.sublime-build”). Save the project in Sublime Text 2 in such a way that the project manifest file "* .sublime-workspace" is in one of its root folders. The ProjectBuild plugin tracks the presence of this file and its uniqueness, since information about the current Build System is taken from it. When changing the Build System in Sublime Text 2, do not forget to save the project so that the above file is updated. Click the keyboard shortcut assigned to ProjectBuild and see the panel with a list of build options. The list is generated automatically by the description of the variants of the Build System selected in Sublime Text 2 existing in the "* .sublime-build" file.
The problems indicated at the very beginning of the article were successfully solved: one shortcut is involved and it works with the build mechanism of Sublime Text 2 itself and in its interface without tight binding and explicit naming of the called build variants.
The plugin still has room for improvement, for example, platform-specific options are now ignored, which can be specified in the Build System file, but for me personally, so far enough is enough, and I need exactly what it is now.
In fact, it is difficult to say whose contribution is greater, and whether it is important if, as a result, the ProjectBuild plugin has become what it probably should have been. And what a sin to conceal, I feel an indescribable feeling of pride that here there was no such thing in the interface and functionality of Sublime Text 2, and now there is one, and that it is written in part by me. (here I did not know about the "bicycle", oh, woe is me, woe)
The old version of ProjectBuild will most likely be converted into a OneHotkey plugin for grouping commands into one keyboard shortcut, not necessarily building commands, but simply launching "third-party" programs for Sublime Text 2 programs, etc. and there the settings file, which used to be in ProjectBuild earlier and turned out to be superfluous for it, since it contained redundant information for the build mechanism, is already useful.
Promised bike
All the islands have long been open ... As it turned out, already initially in Sublime Text 2 you already have the option of calling the options panel of the current Build System, you just need to add a keyboard shortcut:
{ "keys": ["f8"], "command": "show_overlay", "args": {"overlay": "command_palette", "text": "Build: "} } And this panel, however sad it would be to talk about it, is more convenient, since it does not tie you to the "* .sublime-workspace" file and demonstrates the assigned keyboard shortcuts for each option, if any. However, it does not support their sorting, and the plugin can be modified to order the options (although maybe again I don’t know what).
Probably all that can be squeezed out of all this is to go back to OneHotkey.
Thanks for attention.
Source: https://habr.com/ru/post/149829/
All Articles