I've installed the package control "evernote plugin"and view in browser for Sublime3. When I passed the code to evernote, Sublime3 come out an alert as follows.
Evernote complained:
The contents of the note are not valid.
The inline HTML tag 'iostream' is not allowed in Evernote notes.
Retry?
My code is as follows.
#include <iostream>
using namespace std;
int main ()
{
// declaring variables:
int a, b;
int result;
// process:
a = 5;
b = 2;
a = a + 1;
result = a - b;
// print out the result:
cout << result;
// terminate the program:
return 0;
}
How can I cope with it?
From the sublime-evernote package wiki:
Raw HTML
Take extra care in not using prohibited elements (see here).
Evernote will complain if you use unsupported elements (such as <style>) or unsupported attributes (such as class or id).
If you wish to have the code within a raw html block interpreted as Markdown, specify a markdown="1" attribute for the outermost element:
<div markdown="1">
**Note**:
This is important!
</div>
Source: https://github.com/bordaigorl/sublime-evernote/wiki/Supported-Markdown#raw-html
You have to use
<iostream>
Otherwise it will be interpreted by Markdown as literal HTML (and passed as such to Evernote)
-- update--
You can deal with this problem by reinstall the sublime-evernot.I have tried, and it works well!
clone this repository with
$ git clone --recursive http://github.com/bordaigorl/sublime-evernote.git
in
Windows: %APPDATA%/Roaming/Sublime Text 3/Packages/
OSX: ~/Library/Application Support/Sublime Text 3/Packages/
Linux: ~/.Sublime Text 3/Packages/
https://github.com/timlockridge/SublimeEvernote
sublime-evernote supports Fenced Code Blocks of GitHub as mentioned in its wiki. Quoting the wiki:
Fenced code blocks GitHub style are supported. If a language is specified, pygments is used to highlight the code.
So the correct way to send code is to include it within a block of triple backticks. Quoting the Github help link for fenced code blocks:
You can create fenced code blocks by placing triple backticks ``` before and after the code block. We recommend placing a blank line before and after code blocks to make the raw formatting easier to read.
You can add an optional language identifier to enable syntax highlighting in your fenced code block.
We use Linguist to perform language detection and syntax highlighting. You can find out which keywords are valid in the languages YAML file.
As mentioned above, you can also specify the language after the backticks. For example, for your code, you need to enclose it within:
```c++
```
After enclosing it like this, send it to evernote, and it will appear with proper syntax highlighting.
Related
Will dynamic translation work for such a code:
const QString myText = tr("%1 Hello World").arg(someVar);
I have few doubts:
1: Will the translation entry be generated for above code (when running lupdate). If yes, will the "%1" argument part be ignored?
2: Is the above code correct ? Should the dynamic part be translated separately before using it in the argument with tr. Provided we know all possible value of someVar
When your run lupdate, you will see this in your .ts file:
<source>%1 Hello World</source>
The translator will need to know they can just ignore the '%1' part.
If someVar is a number, there is no need to do anything else. If it's a string, it will need to be translated separately.
I would like to use Doxygen for documenting my Arduino code. For this I need the *.ino-files in my project to be treated like *.c-files and be parsed with the C code parser in Doxygen. I think there was a setting somwhere for this mapping but I can't find it anymore.
My settings so far:
FILE_PATTERNS = [...] *.ino
Oh, I think I already found the option. It is located under "Project" in doxywizard, "EXTENSION_MAPPING". These are the options that seem to be working for me now:
FILE_PATTERNS = [...] *.ino
EXTENSION_MAPPING = ino=c
And the tag that gets me every time: A #file-tag has to be added to the top of the file, otherwise it is ignored by Doxygen. Like so:
/**#file sketch_1.ino */
Whenever I use the autocomplete for atom it doesn't include the brackets. For example if i start typing "print" I hit enter and it enters print but doesn't include the brackets.
The default Python snippets only supports the print keyword, not the print() function. Since I haven't found another package that does, you're problably best off adding a snippet (Atom > Open Your Snippets) such as:
'.source.python':
'print()':
'prefix': 'print-function'
'body': 'print($1)'
The prefix will trigger the snippet defined in the body, in case prefer to call it differently.
In sketch documentation it's stated that dot and braces notations can be mixed with each other. It's even an example available:
[[context.document currentPage] deselectAllLayers];
Unfortunately, this code doesn't work in sketch and produce error if executed by "run custom script" command:
SyntaxError: Unexpected identifier 'currentPage'. Expected either a closing ']' or a ',' following an array element..
Plugin “untitled script”, line 2.
» [context.document currentPage]; «Error in command untitled script Script at path (null) does not contain a handler function named: onRun
Script executed in 0.023666s
This can be avoided by adding additional ( and ):
[[(context.document) currentPage] deselectAllLayers];
Why this happens? Is it any documentation available how exactly braces and dot notation can be mixed? Is it some error or expected behaviour?
It seems to me it's an error, but in Sketch documentation. Besides this case you showed, I couldn't find any other example where dot and braces notations are used together in the same statement, without parentheses.
The documentation page about Selections, for instance, tells that you'd use the following code to unselect everything:
var doc = context.document
[[doc currentPage] deselectAllLayers]
Follow this link and look under Clearing the selection header: http://bohemiancoding.com/sketch/support/developer/02-common-tasks/01.html
Even their example plugins don't mix both notations, as you can see here: https://github.com/BohemianCoding/ExampleSketchPlugins/blob/master/Hello%20World/Hello%20World.sketchplugin/Contents/Sketch/script.cocoascript.
In that example, context.document is also assigned to a new variable before being used within braces.
I inherited an ADA program where the source file names and package file names don't follow the default naming convention. ADA is new to me, so I may be missing something simple, but I can't see it in the GNAT Pro User's Guide. (This similar question didn't help me.)
Here are a couple of examples:
File Name: C_Comm_Config_S.Ada
Package Name: Comm_Configuration
File Name: D_Bus_Buffers_S.Ada
Package Name: Bus_Buffers
I think I have the _S.Ada and _B.Ada sorted out, but I can't find anything in the program source or build files that show the binding between the Package Name and the rest of the File Name.
When I compile a file that doesn't use any other packages, I get a warning: file name does not match unit name... This appears to be from the prefix of C_ or D_, in this particular case.
Also, I'm not clear if the prefixes C_ and D_ have any special meaning in the context of ADA, but if it does, I'd like to know about it.
So I appear to have two issues, the Prefix of C_ or D_ and in some cases the rest of the file name doesn't match the package.
You could use gnatname: see the User’s Guide.
I copied subdirectories a/ and d/ from the ACATS test suite to a working directory and created a project file p.gpr:
project p is
for source_dirs use ("a", "d");
end p;
and ran gnatname with
gnatname -P p -d a -d d \*.ada
which resulted in an edited p.gpr and two new files, p_naming.gpr and p_source_list.txt. These are rather long, but look like
p.gpr:
with "p_naming.gpr";
project P is
for Source_List_File use "p_source_list.txt";
for Source_Dirs use ("a", "d");
package Naming renames P_Naming.Naming;
end P;
p_naming.gpr:
project P_Naming is
for Source_Files use ();
package Naming is
for Body ("d4a004b") use "d4a004b.ada";
for Body ("d4a004a") use "d4a004a.ada";
for Body ("d4a002b") use "d4a002b.ada";
...
for Body ("aa2010a_parent.boolean") use "aa2010a.ada" at 4;
for Body ("aa2010a_parent") use "aa2010a.ada" at 3;
for Spec ("aa2010a_parent") use "aa2010a.ada" at 2;
for Spec ("aa2010a_typedef") use "aa2010a.ada" at 1;
...
for Body ("a22006d") use "a22006d.ada";
for Body ("a22006c") use "a22006c.ada";
for Body ("a22006b") use "a22006b.ada”;
end Naming;
end P_Naming;
The for Body ("aa2010a_parent") use "aa2010a.ada" at 3; is used when there’s more than one unit in the source file.
p_source_list.txt:
a22006b.ada
a22006c.ada
a22006d.ada
a27003a.ada
a29003a.ada
...
d4a002b.ada
d4a004a.ada
d4a004b.ada
When building, for example, test d4a004b, you have to use the file name and suffix:
gnatmake -P p d4a004b.ada
The Ada standard does not say anything about source file naming conventions. As it appears that you use GNAT, I assume that you mean the "GNAT default naming convention".
You can tell GNAT about alternatively named files in a Naming package inside your project files.
A simple example:
project OpenID is
...
package Naming is
for Implementation ("Util.Log.Loggers.Traceback")
use "util-log-loggers-traceback-gnat.adb";
for Implementation ("Util.Serialize.IO.XML.Get_Location")
use "util-serialize-io-xml-get_location-xmlada-4.adb";
end Naming;
end OpenID;