I am working on a project that is using the multiline node package. This allows us to create multi-line strings inside of multi-line comment tags.
The problem I am encountering is related to the grunt-jasmine-node-coverage node package.
Normally running istanbul, you can pass in the flag --preserve-comments and it won't strip out comments while processing the coverage information, otherwise it will default to false.
So far I have not been able to find a workaround for passing in this flag in the grunt-jasmine-node-coverage configuration. Is what I am trying to accomplish currently possible?
Related
I tried to create an internal link to a heading in a jupyter notebook, using the following. The various answers on SO, such as here don't seem to be working as expected in my notebook. The code below creates a link, but nothing happens when trying to access the link.
[Link to section](#section)
... Some text ...
## Section
An alternative method suggested here does work as expected.
<a href='#section'>Link to section</a>
... Some Text ....
<a id='section'></a>
## Section
Is there a mistake in the first section of code?
Update
After researching the suggestions by Waylan, I came across this example for ipython. Just adding dashes, without using lowercase seems to work.
[Link to section](#section)
becomes
[Link to section](#Section)
There are a couple different factors which could be at play here.
Non-Standard Markdown
The Markdown rules do not specify that the outplay should include an id attribute. However, many implementations create one for you. Some do so out-of-the-box and others only if a specific extension is enabled. You will need to check the documentation for the implementation you are using to see if such a feature is supported and what you need to do to enable it. If such a feature is not available, then the only option is to manually define the ids using raw HTML.
Slug creation method
As there is no standard rule, each implementation which adds the feature does so using their own non-standard method for creating the slug (value of the id attribute). For example, some handle capitalization and/or whitespace differently. You will need to check the documentation for the implementation you are using to find the method used. Alternatively, you could run a draft of the document through the Markdown parser and check for an id attribute and simply use the value. This ensures it will match without needing to know the method used. You may need to use your browser's "view source" feature to determine what id, if any, was assigned to the header.
I was wondering if it is possible to get a list of windows in Tk, and destroy specific ones. I am working in R using the tcltk interface, and am calling a function written by someone else a long time ago (that I cannot edit) which is producing additional windows that I don't want.
From the documentation here, it seems that new Toplevel windows are children of .TkRoot by default. I know that Python has a winfo_children method, which I was thinking of trying to call on .TkRoot but I don't think that method is implemented in the tcltk library. I tried using tcl("winfo", "children", .TkRoot) but I am getting an error: [tcl] bad window path name "{}" (I'm not familiar with actual tcl, so I'm probably messing this command up).
Additionally, if there is a way to call winfo children, what's the best way to process the result to identify specific windows and then destroy them?
Looking at the R sources, I see that you should be doing:
tkwinfo("children", .TkRoot)
Except that I think that won't work either, as .TkRoot doesn't have a corresponding widget on the Tk side of things. Instead, use the string consisting of a single period (.) as the root of the search; that's the name for the initial window on the Tcl side of things. And I suspect that you'll just get back a raw Tcl list of basic Tk widget names without the R wrapping as I just can't see where that conversion is applied…
Be aware that the results may include widgets that you don't expect, and that you need to call it on every window recursively if you want to find everything.
With symfony console commands you can prefix/group each one by putting in the setName("group:command"), and this is great.
myown
myown:cool
myown:foo
myown:bar
But the problem is that some external dependencies dont use this format. Ex: Phinx Migrations.
Since I'm importing an dependency that has a console command called migrate, I dont want for it to show without prefix/group. Not just because I might have another command called migrate or just for readability. I don't event know if we have 2 with same command name which one will show (need to check).
My question is: Is there any away for me to force a group commands from an external depencency to be inside an prefix/group?
You can achieve that, I wouldn't recommend but that would be the approach:
Create a compiler Pass which removes the definitions of the Commands you don't like
Register again all those commands while setting the names you like
If you need information on compiler passes:
https://symfony.com/doc/current/components/dependency_injection/compilation.html#components-di-compiler-pass
Maybe there's an easier way which I'm not aware, but for now that's my answer to you, I can't post all the code because that would be a lot of code and if you do it maybe you can update with the solution.
Good luck
In Symfony I see various commands for generating empty classes,bundles, entities etc.
I searched to generate a empty class for the creation process of custom console commands. But I couldn't.
May I know whether any commands are available in Symfony to generate empty classes for creating custom console command ?
If not, May I know whether it was restricted for any reasons ?
Note: Currently Now, I copied the codes from the symfony.com and edited accordingly.
There is no such command but you can write one by yourself if you like. I would not use it myself i think because generating an empty class is not much work to do.
I would like to add a new language (called 'kiwi') into the Brackets code editor which is based on C++. It uses the exact same rules but has additional keywords.
I've already done the part of adding the additional keywords with separate syntax highlighting directly on the clike.js file but i don't really like directly modifying the def for C++
Can someone explain to me how I can achieve this? I don't really understand the difference between using def() and CodeMirror.defineMIME(). If this new language will take cpp/hpp input files, how will the editor switch from C++ -> kiwi?
Thanks in advance
Patching your local copy of the code, as you've done, might be perfectly fine for your needs. (And if you run from a Git copy of the source, it's easy to pull down updates without losing your local diffs).
If you want to do it a "cleaner" way, you can write a Brackets extension to define the new language - this way the change is easily shareable with others, and updating Brackets is even easier.
The way you'd do this roughly follows the Defining a new language docs:
Write an extension to package up your code that will define the new language (below)
The CM mode "clike" is already loaded, so you don't need to worry about that
Call CodeMirror.defineMIME() to set up a clike configuration with the right list of keywords - using a new mimetype name of your choosing. (Looking at the def() code in clike.js, I don't think the extra stuff it does is especially relevant for Brackets).
Call LanguageManager.defineLanguage() to tell Brackets about your new language mode (and what file extensions map to it, etc.). You should be able to mostly copy how the C++ mode is defined here - except with your new MIME name instead.
You should read CodeMirror documentation to find out about writing your modes.
But in short you can define your own type of clike language, by using CodeMirror.defineMIME().
You also asked what's the difference between def() and CodeMirror.defineMIME(). If you look at the code you can see that def() function is calling CodeMirror.defineMIME() at the end, so I believe it is just a more readable way of defining the type.
Also it seems that it's impossible to define more than one language on the same extension type (not 100% sure).