I am using uncrustify and atom-beautify in atom.io to format my C++ code according to google styling guide. I am using CPPlint to verify whether the code is formatted correctly. I am using the config file from https://gist.githubusercontent.com/philectron/1a1e1ccb06d5643cd61d85fc5ecaf429/raw/8813567b8f7dd49003228e19c3d10719b49995a1/uncrustify-preferences.cfg. But after beautifying, cpplint is reporting the following problems.
"At least two spaces is best between code and comments [whitespace/comments]" is not enforced and I am getting this error in multiple places. The answer for this question at Uncrustify - How do I align trailing comments by two-space gap? is not working.
"protected: should be indented +1 space inside." I am getting the same error for private and public as well.
If this is not the right way, how can I beautify and lint inside atom.io.
Well maybe I wasn't clear enough in the last answer or you haven't read it carefully enough. Here is another try.
Uncrustify has spacing and aligning functions. Aligning functions are applied after the spacing functions (at least in the case of the trailing comments).
If you have align_right_cmt_span set to greater than zero the aligning functions will also be applied on trailing comments.
The option align_right_cmt_gap is than enabled, even if it is set to zero, which it is by default even if you do not specify it. It seems that it is now only active if it is not zero. Additionally to that problem you have align_right_cmt_at_col set to 1.
I am not using CPPlint, atom-beautify or the google styling guide. So if you want help, upload some code examples: input code, output code, expected code.
Related
In Kumar's answer to "How to wrap code/text in Jupyter notebooks" he provides a screenshot of Jupyter's word-wrapping options. These options are documented in the pull request Add wordWrapColumn and bounded line wrapping modes by AlbertHilb · jupyterlab/jupyterlab. Unfortunately all these settings don't seem to automatically add new lines, they just determine where the wrapping happens visually.
For now my workaround is to add a ruler (see python 3.x - ipython3 notebook vertical margin/marker line at 80 characters - Stack Overflow) and manually wrap.
I'm saving my content in the the MyST format, which makes version control much easier. Hence the question (users saving to JSON wouldn't need this).
I have searched for a setting within the mvbasic extension within VSCode but I may have hit a dead end. I am new to using VSCode with the rocket mvbasic extension and still in the learning process, so please bear with me.
Our development for the most part has always been directly on the server using the editor within it to code and develop on a Unix/Aix platform with Unidata. Some of our code has array assignments with CHAR(253)/CHAR(254) characters within them. See the link to the image that shows how its done. Now I didn't do this code, the original software developer did this many many years ago and we just aren't going to go and change it all.
How code looks on actual server
The issue is when pulling the code to edit in VSCode, the extension is changing it, and I uploaded it back and didn't pay attention and it was implemented in our production incorrectly, which created a few bugs.
ALIST="H�V�P�R�M�D"
How code looks in VSCode
How code looks after uploaded back to server from VSCode
Easy to fix, no biggie, but now to my question.
Does anyone have this issue, or has a direction to point me into that maybe I need to create a setting to keep the characters in the correct ASCII format so that this doesn't happen again by mistake?
VSCode defaults to the sane choice for character encoding in 2022: utf-8, but sometimes you have to deal with legacy stuff.
https://code.visualstudio.com/docs/editor/codebasics#_file-encoding-support
If you click on the UTF-8 in the bottom right corner you can choose "Reopen with Encoding":
After that, you can select a different encoding. I chose DOS (CP437) at a guess and literal MV characters are displayed as superscript 2 (²), and for me I can save to the server and confirm those characters remain as #VM after a round trip (though for my terminal emulator they appear as } which is useful).
You can edit preferences and set "files.encoding": "cp437". One other thing that can be helpful if your programs don't have a standard extension (like .bas) as most don't is to set the default mode to basic so most of what you're editing will identify as MVbasic, and you can do a quick CTRL-K M to switch to any other modes if you're just pasting in something else like SQL.
Some useful links - the Rocket forums are helpful and the folks there are always super nice
https://community.rocketsoftware.com/forums/multivalue?CommunityKey=521bce2e-71d5-4d32-b560-dfa95e950eb5
The MV Extensions Community extension is a good group and always has been helpful when I've had issues. I've made some small contributions - they're very open. I prefer this extension, but honestly haven't done a deep comparison.
https://github.com/mvextensions
I'm sharing a small but annoying issue that sometimes pops up when I'm using shortcuts to insert operators while working on a markdown file in R : the operator either does not get written, or even worse gets written on another file.
So let's say I am working on the file "report.rmd", and I want to insert the pipe operator using Ctrl+Maj+M, or the assignment operator using "Alt+-", and I have the file "test.R" opened. Well, I therefore type the aforementioned shortcuts and...nothing happens on my markdown file. But some nice operators that had nothing to do there get written on my test.R file.
The only way I found to solve this problem is to close and reopen RStudio (restarting unfortunately doesn't solve the issue).
While this is quite a minor problem, it's incredibly annoying. Did it ever happen to anyone of you, and if so do you know where it comes from and how to solve it?
Edit:
Although I am still running into this issue (without being able to reproduce it consistently) I came into a somewhat lighter solution. Instead of restarting R, simply closing all tabs (closing just the problematic one doesn't work) solves the problem. I hope this helps narrowing down the possible origins of the problem.
Short Answer
re-define the key combo to Ctrl+Shift+ \ , assuming this does not create a conflict
Background
I've had a similar problem for a while, too. In my case, the shortcut never works. I can not find the source. I even found a conflict with Ctrl+Shift+M assigned to 2 Editor functions.
Image:Screen Capture 2 conflicting hotkey assignments
However, a simple key reassignment of the one that is not the pipe operator ("Expand to Matching")
Image:screen capture showing the hotkey conflict solveddidn't solve the issue in my case.
Solution
Here's what did the job for me
I managed to assign a different combo (that hasn't been assigned yet) and that is comfortable enough in the sense of its location on the keyboard
go to Tools → Modify Keyboard Shortcuts...
In the filter box, write "Pipe"
Direct the cursor to the text box showing the current shortcut, and press the new combo (e.g. Ctrl+Shift+ \ ), then Enter.
Remember to hit Apply
Make sure the new Combo isn't a duplicate of another command, by going back to step 1 and sorting the list by Shortcut, then scrolling down to find your new one. if there is an ovelap, consider changing one of them.
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've encountered a Oracle Form which has a strange behavior. It seems that it looses the spanish character "ñ" when converting it from Oracle 10gR2 to Oracle 11gR1. This only seems to happen in Text Field Prompts. The rest of the elements in the form seem to display the characters properly. Any suggestions as to what might cause this or what to check to fix it? I've already have checked that the fonts installed support this character and that the NLS related settings look ok.
Well, after a whole day trying to determine what the problem was, it seems that the simplest answer was the right one: The original developer for this form seemed to want to assure that the character was displayed properly and he had a bad setup, so he was setting the text using the SET_ITEM_PROPERTY function, and using the CHR function to escape the character. Something like the following:
SET_ITEM_PROPERTY('BLOCK.PASS_FIELD', PROMPT_TEXT, 'Contrase'||CHR(241)||'a: ');
That for the prompts for the fields which were titled "Contraseña: " in their properties.
In the current set up, it works, but on this new environmet, we are using an UTF8 encoding and the code for the letter "ñ" changes completely. Just for the sake of completeness the code in utf8 would be CHR(50097). But I suggest it would be better just to ask your DBA or SYSADMIN to fix the NLS settings so you can just use the prompt or field properties and don't have to get this "creative" and make other dev waste too much time.
It never ocurred to me to check for this, because the properties seemed to be set up correctly, but a simple test of creating a new field with the same properties finally showed me that the problem was specific to the 4 fields which were already created and searching for code-based attribute changes led me to find this was the issue. So I leave this answer here in the hope that someone else saves a few hours of his time and checks for the simple answer first.