vim: Filetype-based key-mapping fails - html

I'm trying to get vim to send an html file to the browser with a function key. There are examples around including here on SO, but none of the variations I tried worked. Finally, just as I write this question, I remove the filetype condition from the code below and it works. So we know where the problem is, although I don't see how. And I still want to want the key to work differently for different types of files.
autocmd FileType html noremap <F5> :update<Bar>silent !start "C:\Program Files (x86)\Opera\opera.exe" "file://%:p"<cr>

If you define a mapping based on filetype, you should use noremap <buffer> ...; otherwise, it will be defined globally, and also be available in non-HTML buffers afterwards.
The mapping itself looks correct; verify that the filetype is indeed properly detected; :setl ft? should yield html.
Instead of the autocmd, I'd rather use Vim's abstractions and put the file in ~/.vim/after/ftplugin/html.vim. This will then also define the mapping for HTML-derived filetypes (like e.g. htmldjango, which source the filetype settings). But that's a matter of preference.
Note that there are plugins that can do this (in a more robust and more general way), e.g. shell for the current buffer and openbrowser for arbitrary URLs.

Related

How to adjust page size while publishing?

Software: Octave v7.1.0
There seems to be no option of defining the page size while doing publish ("FILE", "pdf") . The manual for pdf is: 11.11.1 docs.octave/.../Publish.
It's kinda surprising as it's a one word addition to the output TeX file : a4paper. I can do this manually each time I publish but being able to specify it somehow within the publish function would be awesome.
Surprisingly, there are plenty options for specifying page size in figures and images. Search for papertype at: 15.3.3.2 docs.octave/.../Figure-Properties
I searched with "Matlab" and found this page, and it fetched the results for "Matlab Report Generator" mlreportgen which seems a different thing.
I'd be interested to listen about other ways of doing it automatically too (like adding that word in TeX file via shell scripting and text string manipulation maybe).
As directed by #cris-luengo in the pointer comment to the linked manual, one solution can be to edit (or create) the function files (to used by the publish function) with the desired changes to specify the paper size.
The function files location can be found by:
opening the function file in octave gui and then proceeding from there:
edit (fullfile (fileparts (which ("publish")), "private", "__publish_html_output__.m"))
or, executing the following in octave REPL/command line:
fullfile (fileparts (which ("publish")), "private")
There, among other files, 2 files will be:
__publish_html_output__.m
__publish_latex_output__.m
Edit the _latex_ containing file to add ,a4paper (or other predefined size in latex) alongwith 10pt in the line '\documentclass[10pt]{article}',, optionally with a comment in a proceeding newline as a reminder that you added it, something like: '% Modification: specify a4paper',
If pdf format were directly specified as a new function file, then I'd have preferred to modify its copy and calling that directly in publish(), but since the publish pdf eventually calls publish latex, so, the only option at hand in this method seems to edit the original publish latex function file itself.

How to convince VS code to accept # as comment in JSON files?

We have special files that contain JSON data mixed with # comments.
I figured I need to enhance Code's json.settings file with:
"files.associations": {
"*.ourextension": "jsonc"
}
but then I discovered that jsconc is about JSON data with // comments.
Is there a convenient way to get VS code to accept # comments in JSON data?
Edit: VS code recognizes the jsconc language, it gives me this error message:
And it also accepts // comments:
adding the // got me a green first line, and now the second line gets the first error (because starting with #).
If you use the Change Language mode command (or click on the language indicator on the status bar) you can select "jsonc JSON with Comments".
I think this is only auto-detected when the extension is .jsonc.
NB. JSON with comments uses JavaScript style single line comments: from a \\, outside a string literal, to the end of line.
To support some different comment indicator would require a new language mode (and an extension to add it).
A distinct non-answer: it might be possible to add a such a new language definition, but it would require quite a bit of work. I also had a quick look if I could simply change the corresponding config json file for jsonc that ships with VS code, but that file is rather complex, and would probably be overridden with the next VS code update.
Thus a straight forward workaround. Two scripts to replace one command style with the other:
#!/bin/sh
# a helper script that turns all # into //
# with the syntax that works for sed on MAC OS
for file in "$#"
do
sed -i '' -e 's,#,//,g' $file
done
Not exactly convenient, but fast and robust, given our specific requirements.

Doxygen FULL_PATH_NAMES does not generate full paths in file names

I have two libraries libA and libB.
libA contains a file Action.h
libB contains a file action.h
I want to generate doxygen documentation in the same output directory for both libraries. This directory is to be used in Windows, for which action.html and Action.html is unfortunately considered to be the same file. To prevent this clash, I wish to render the generated files unique by prepending their path names to them.
Therefore, I set FULL_PATH_NAMES to YES.
I expect to see something like libA_Action.html and libB_action.html when I generate the documentation, but I don't! I still see Action.html and action.html. Its as if the FULL_PATH_NAMES parameter does nothing at all. Do I also need to set some other parameter in the Doxyfile to make the FULL_PATH_NAMES parameter work correctly?
You're probably running doxygen twice - one time for each library. If that is the case, doxygen isn't aware of the fact that it might clash with an output from another run, so when it find an existing file, it assumes that it is leftover from a previous run, and overrides it.
Setting FULL_PATH_NAMES doesn't help, as doxygen has no idea that multiple libraries exist, so, as far as doxygen is concerned, the prefix is identical to all files, so even when you adding a force it, it adds nothing (That's probably a bug).
The solution to your problem is setting both libraries as inputs to the same doxygen project.
You can do it by setting INPUT to multiple folders in the configuration file:
INPUT = ...bla\Lib1 \
...bla\Lib2

How to get the current Skin's file path in Mediawiki?

In MediaWiki skin definitions, the BaseTemplate that gets extended has several attributes for creating links to other pages in the wiki, but I've got a situation where I need the path to the skin's directory, to pull some images used to create the UI. By default, that would just be /skins/mySkin/images/foo.png, by default but if someone changes the $wgStylePath variable, or renames the skin, that would be an issue. Is there an existing variable that has that URL build out, hidden somewhere in the BaseTemplate methods?
Yes, the SkinTemplate class, which contains the code to set up the template variables before executing the template, provides access to $wgStylePath via the 'stylepath' template variable.
When you subclass SkinTemplate to define your skin's main class, you are also expected to override the $stylename member variable, which specifies the subdirectory under which your skin's own stylesheets and images reside. (This would usually be the same as the name of your skin in lower case, but it doesn't have to be; it's perfectly fine to have, say, two related skins using images from the same directory.) This is also made available as a template variable, surprisingly named 'stylename'. So one way to specify an image path in your template would be something like:
<?php $this->text('stylepath') ?>/<?php $this->text('stylename') ?>/images/foo.png
Another way, (formerly) used e.g. by the Vector skin, is to use the getSkinStylePath() method from the Skin class (which is the superclass of SkinTemplate; it's kind of messy and tangled for historical reasons, but basically you can pretty much treat them as one class split into two files).
Update: As of MediaWiki 1.36, getSkinStylePath() has been deprecated. The recommended alternative, according to the release notes, is to "replace usages with the direct path to the resources."
To use it, you pass in the name of the file as a parameter, and the method automatically prepends $wgStylePath and $stylename to it (and appends $wgStyleVersion as a query string). Note that this is not a template method, so you have to escape and print the returned URL yourself:
<?php echo htmlspecialchars( $this->getSkin()->getSkinStylePath( 'images/foo.png' ) ) ?>
There's also a getCommonStylePath() method which does exactly the same thing, except that it uses the string "common" instead of $stylename.
Apparently this is the new way:
$this->getSkin()->getConfig()->get( 'StylePath' ) . '/SkinName/images/foo.png';
Source: https://phabricator.wikimedia.org/T270754

How to tell the PhpStorm IDE that a constant exists?

The IDE (PS-117.65) is complaining that some of constants aren't defined.
I've defined them in a loop in another file. Can I put a doc comment at the top of this file to inform it about the constants? The usual /** #var and #global syntax doesn't seem to work for constants.
There is no known to me PHPDoc comment to do that.
But you can "fake" them -- create some const.php file and place it anywhere in a project (you can even place it in separate folder outside the project and attach it as External Library or as separate Content Root).
In this file -- define those constants with in a normal way: define("CONST_NAME", "value"); The "value" part can be anything (as long as types are matching -- useful for inspections/code analysis) -- it really depends where those constant will be used (e.g. if they are used in include/require statements, then it may be beneficial to have some real (or close to it) values there).