When browsing files in the Sublime sidebar, I would like to quickly access the commands available in the context menu via shortcuts. E.g. Delete file, rename file/folder, new file/folder.
(FYI: super+N is not an ideal solution for creating new files - it isn't context aware and will usually choose an inappropriate default location).
You can enable command logging by inserting the following into the console sublime.log_commands(True). This will give you the commands and arguments being executed. You can then create a key binding with the appropriate command. My guess is the commands will use some sort of path, so you may need to write a small plugin to inject the correct paths for the various commands.
For new file creation specifically, you may want to take a look at AdvancedNewFile. Disclaimer - I'm the current maintainer of the plugin. I've tried to make it a more flexible than it originally was, with regards to specifying where to create the file. Though if you do decide to use it and have feature request, feel free to create an issue about it.
Related
I have the next configuration for a build system in PhpStorm:
And it works ok, but I have a problem... my build script needs to receive the name of the file I'm running it on, so, if I build a PHP file, it will run phpcs on it, but if I'm building a CSS or JS file, it will run gulp... with Sublime Text that is possible, is it possible with PhpStorm?
There are no macros support for Run/Debug Configurations -- they are made so they do not depend on a context (currently opened file in editor). In other words -- they are pretty static and all file names/paths are basically hard coded.
For what you are describing (build script).. you need to use External Tools functionality (which can have all of that and made specifically for such tasks). Once created, you can assign custom shortcut to any External Tools entry (check Settings/Preferences | Keymap for that) so it's more convenient to use it.
If you want such script to be called on every file save automatically -- then use File Watchers -- pretty much external tools that will be called for you automatically (once per each file modified).
Since you are doing this for a build script -- maybe you should try to use dedicated (and therefore more appropriate in general) tools? For example: Gulp / Grunt .. or even Phing.
Create external tool:
https://www.jetbrains.com/phpstorm/help/external-tools.html
You can assign hotkey to execute your build command.
I did some research on MediaWiki hooks.
To the best of my knowledge, the only hook for adding/updating database tables is https://www.mediawiki.org/wiki/Manual:Hooks/LoadExtensionSchemaUpdates.
However, I need a hook that fires on installing a new extension. How do I achieve that? I'd like to execute a CREATE TABLE statement only once - when the extension is installed. Installing an extension doesn't require a MediaWiki update, which is why the above hook does not suit my needs.
EDIT
To clarify: I'm developing an extension that requires access to a custom table in the database. That's why I need to execute the CREATE TABLE statement whenever this extension is installed.
First: As you have noticed, there is no such hook. You will need to do the check for installed extensions by a cron job (if it's your server), or on, say, each 100th request to the wiki, using the job queue (if you are doing this in an extension).
From there, you have a few options, depending on if you need to catch every single extension, or just most of them:
Check for registered extensions, with something like: $registry = ExtensionRegistry::getInstance();$extensions = $registry->loaded();This will work extensions using the new style. For older versions, check the global variable $wgExtensionCredits for registered extensions. Note that nothing prevents an extensions from running without registering. In fact, there are a lot of extensions like that.
Parse LocalSettings.php, and check for old and new style extension loading with a regex. Very dirty, but it's actually the way e.g. the maintainance script getConfiguration.php does it. You need to check for lines like this:wfLoadExtension( 'FooBar' );and this:wfLoadExtensions( ['Foo', 'Bar'] );and this:require_once "$IP/extensions/Foo/Bar.php"; Note however that it is possible to use other directories for extensions, and that modern skins in fact behave like extensions too.
If you need to track a certain family of extensions, and you can make sure they all use Composer, the parse $IP/composer.json for installed extensions.
I did some more research (https://www.mediawiki.org/wiki/Manual:Update.php#Details) and found out that the LoadExtensionSchemaUpdates hook is exactly what I am looking for.
# Schema updates for update.php
$wgHooks['LoadExtensionSchemaUpdates'][] = 'fnMyHook';
function fnMyHook( DatabaseUpdater $updater ) {
$updater->addExtensionTable( 'tablename',
__DIR__ . '/table.sql' );
return true;
}
When running $ php update.php for the first time after installing the extension, the script executes the CREATE TABLE statement. Then, for consecutive executions, the update script just notes that the table already exists.
I want to reexecute some targets when the configuration changes.
Consider this example:
I have a configuration variable (that is either read from environment variables or a config.local file):
CONF:=...
Based on this variable CONF, I assemble a header file conf.hpp like this:
conf.hpp:
buildConfHeader $(CONF)
Now, of course, I want to rebuild this header if the configuration variable changes, because otherwise the header would not reflect the new configuration. But how can I track this with make? The configuration variable is not tied to a file, as it may be read from environment variables.
Is there any way to achieve this?
I have figured it out. Hopefully this will help anyone having the same problem:
I build a file name from the configuration itself, so if we have
CONF:=a b c d e
then I create a configuration identifier by replacing the spaces with underscores, i.e.,
null:=
space:= $(null) #
CONFID:= $(subst $(space),_,$(strip $(CONF))).conf
which will result in CONFID=a_b_c_d_e.conf
Now, I use this $(CONFID) as dependency for the conf.hpp target. In addition, I add a rule for $(CONFID) to delete old .conf files and create a new one:
$(CONFID):
rm -f *.conf #remove old .conf files, -f so no error when no .conf files are found
touch $(CONFID) #create a new file with the right name
conf.hpp: $(CONFID)
buildConfHeader $(CONF)
Now everything works fine. The file with name $(CONFID) tracks the configuration used to build the current conf.hpp. If the configuration changes, then $(CONFID) will point to a non-existant .conf file. Thus, the first rule will be executed, the old conf will be deleted and a new one will be created. The header will be updated. Exactly what I want :)
There is no way for make to know what to rebuild if the configuration changed via a macro or environment variable.
You can, however, use a target that simply updates the timestamp of conf.hpp, which will force it to always be rebuilt:
conf.hpp: confupdate
buildConfHeader $(CONF)
confupdate:
#touch conf.hpp
However, as I said, conf.hpp will always be built, meaning any targets that depend upon it will need rebuilt as well. A much more friendly solution is to generate the makefile itself. CMake or the GNU Autotools are good for this, except you sacrifice a lot of control over the makefile. You could also use a build script that creates the makefile, but I'd advise against this since there exist tools that will allow you to build one much more easily.
I would like to put some of my app config data in php.ini
I tried just to add new values there and then get them with ini_get
I get nothing displayed.
Do I need to define new entries in an extension?
I know I can create a config file/ini file and easily parse it with PHP, But I want to avoid that.
I do that as I assume it is being loaded once per process.
I do not give here the big big picture, as I want to keep it as much as possible only a technical question, sadly, this platform does not allow debates.
I do need it inside the php.ini
Have you looked at get_cfg_var( config_var )?
http://www.php.net/manual/en/function.get-cfg-var.php
I believe this is for retrieving custom variables from e.g. the servers php.ini file
Don't use php.ini to configure your application, it's not the right place (as the name says, it's intended to configure php, not any application using it).
If you want to use ini files for your application's configuration, have a look at parse_ini_file()
I am writing a WIX installer and I have a following requirement:
During installation, I need to pass an absolute path to a file (lets call it A) included in my installer to a COM component, which already exists on the hard drive and is a part of another program. I have already written an appropriate Custom Action which expects a path to the file A. I don't want to include A as a file installed in the Program Files folder and removed during the uninstallation process. Instead, I would like to put A only temporary on the hard drive, call my Custom Action which will cause the COM component to use the content of A, and then remove A from disk. Is there an easy way to accomplish this goal?
I have tried to utilize the Binary Table and store A there, however I don't know how to reference A using absolute path. I know I could put A outside of MSI file but I would like to keep every file installer needs in a single MSI.
Any help would be appreciated.
Deleting a file that MSI installed means that MSI will consider it "broken" and try to auto-repair it if called on to do so. That happens automatically in several cases (e.g., advertised shortcuts and COM registration) so I'd recommend against it. Leave the file there instead -- it's done its job and there's no harm in leaving it there.
I would take this approach.
Install the file "A" into any directory. Run your custom action needed to update the COM component. Then run another custom action or modify the currently written one to remove the file after it is no longer in use. This would leave no trace of the file "A" and if you schedule the custom action to only run during the install you won't have to worry about it on uninstall.