I'm completely new to emacs (mostly used vim and eclipse/netbeans etc.) I was playing with multi-level nesting of C code and wrote a sample code in emacs to test how it indents codes where nesting is way too deep (not real life code though).
int foo()
{
if (something) {
if (anotherthing) {
if (something_else) {
if (oh_yes) {
if (ah_now_i_got_it) {
printf("Yes!!!\n");
}
}
}
}
}
}
This looked exactly like this as I typed in emacs and saved it. But opening it on a different text editor showed the actual text saved is this:
int foo()
{
if (something) {
if (anotherthing) {
if (something_else) {
if (oh_yes) {
if (ah_now_i_got_it) {
printf("Yes!!!\n");
}
}
}
}
}
}
So I was wondering is there any way in emacs to save the text the way it actually displays?
My current c-default-style is set to "linux".
EDIT:
Ok, I was using Notepad++/Vim to view the file saved by emacs and it showed that "wrong" indentation, but looks like, opening with good old notepad (or even doing a cat file.c) shows the correct indentation as displayed by emacs. Will try the other approaches mentioned here. Thanks!
Try using spaces instead of tabs for indentation. Add the following to your init.el:
(setq-default indent-tabs-mode nil)
This will make all buffers use spaces by default. You will want to add the following exception for makefiles:
(add-hook 'makefile-mode-hook (lambda () (setq indent-tabs-mode t)))
Related
I'm now using the bsd style in emacs. It's a style I started with years back after coming from learning pascal and I've decided will use over other styles for new projects.
However, there is two things that bug me with the emacs bsd style. It indents inline methods.
1) How do I stop it indenting like this?
i.e.
class A
{
A()
{
// do stuff
}
};
I want the brace to be on the same line as methods like this.
class A
{
A()
{
// do stuff
}
};
Looking around it appears like I need to set
c-set-offset substatement-open' 0)
But I don't know how to attach this to the bsd style in lisp. I gave it a go, but got parse errors on starting emacs.
2) How to make the tab key insert 4 spaces?
I just doubled checked my emacs setup and this does what you describe for me:
(setq c-default-style "bsd"
c-basic-offset 4)
Try this to insert spaces instead of tabs:
(setq tab-width 4)
(setq indent-tabs-mode nil)
I just started using Visual Studio Code. In my company they use Whitesmiths indentation style, but I cannot find a way to set it on VSC.
I'm programming in C, so I installed the C/C++ plugin. In this, the "Indent: Braces" option looks like the one for me, but it does not seem to work.
My json looks like this:
"C_Cpp.vcFormat.indent.braces": true,
"editor.detectIndentation": false,
"editor.tabSize": 3,
i set detect.Indentation to false, because i don't want it to interfere with indent.braces.
This is the user json. I did not modify the workspace nor the folder settings.
However, my code still looks like this
void main()
{
if(condition)
{
do something
}
else
{
whatever
}
}
while it should look like this
void main()
{
if(condition)
{
do something
}
else
{
whatever
}
}
what am I missing? Is there a way to set this from the VSC settings without using the plugin?
this post is for c# but it worked for me using the visual studio c++ formatter:
Visual Studio Code custom indentation style
my full .json file:
{
"[c]": {
"editor.defaultFormatter": "ms-vscode.cpptools"
},
"editor.autoClosingQuotes": "never",
"editor.autoClosingBrackets": "never",
"workbench.list.automaticKeyboardNavigation": false,
"workbench.settings.openDefaultKeybindings": true,
"update.enableWindowsBackgroundUpdates": false,
"update.mode": "manual",
"C_Cpp.formatting": "vcFormat",
"C_Cpp.vcFormat.indent.braces": true
}
PFE32 is an ancient editor that will indent in that style. The much newer Code::Blocks editor will handle it as well. Use Astyle to reformat to that style.
By the way, this is the style used with the original Whitesmith's tool chain. It was the first commercially available C compiler. This is the style that God uses when he writes in C. It is not ugly. It is correct, proper for the Backus-Naur definition of the language. It is pretty, just like me. ;-D
I'm creating a small C-program that needs to create multiple graphs. The dot for these graphs are in a string, so I'm using agmemread instead of agread (I want to avoid creating temporary files). However, it seems to break when calling agmemread more than once.
The following example outputs "error2", so it fails the second time when calling agmemread:
#include <gvc.h>
int main() {
Agraph_t *g1 = agmemread("graph testgraph {\n\n}");
if (!g1) {
printf("error1\n");
return 1;
}
agclose(g1);
Agraph_t *g2 = agmemread("graph testgraph {\n\n}");
if (!g2) {
printf("error2\n");
return 1;
}
agclose(g2);
return 0;
}
In a real life example, there would be some more code between these sections of course.
Do I need to free or close anything before calling agmemread the second time? Or is it a Bug of graphviz? I'm using graphviz: stable 2.30.1, devel 2.31.20130523.0446 on Mac OS X.
The same example with agread instead works like a charm.
This was a bug in agmemread(). The fix should appear in packages starting 18 June 2013. Thanks for reporting it.
Adding "\n" after the closing "}" of each graph solves the issue. I'm still investigating why this is required, syntactically.
We have a project using CDT in Eclipse. It's an old project that we just imported into Eclipse, and I want to ensure we start using static code analysis to find any weirdnesses.
The thing is, there are a bunch of lines that trigger warnings that we want to just ignore, with the main ones being fallthroughs within switch statements.
I know how to do this for lint, but what about for CDT? Is there a single-line comment that I can put right above the line?
Example: ("No break at the end of case")
case enChA:
nChannel++;
// I want to ignore this fallthrough
case enChB:
nChannel++;
// And this one...
case enChC:
nChannel++;
// And this one...
case enChD:
nChannel++;
// do some more stuff...
break;
You should try
//no break
before the next case.
These settings are located under Window -> Preferences -> C/C++ -> Code Analysis. You can customize the settings. For example if you pick No break at the end of case, you can define the comment that suppresses the warning. By default it's "no break". So coincidentally copy/pasting the warning message into the comment worked in your case:
As you can see the text doesn't have to be an exact match and it doesn't seem to be case sensitive either.
Referring to your follow-up question about unused variables: When you customize Unused variable in file scope you can define variable names that should be ignored:
There are two cryptic predefined exceptions "#(#)" and "$Id". Unfortunately I couldn't find any official documentation so I went looking into the source. It looks like the checker simply tests if a variable name contains() any of the specified exceptions. If it does, the warning is suppressed.
Outside of Eclipse CDT, there's the popular void-casting trick. If the compiler warns about an unused variable, cast it to void. This operation has no effect, so it's safe, but from the perspective of the compiler that variable is now used. I usually wrap it in a macro to make abundantly clear what I'm doing, e.g.
#define UNUSED(var) (void)(var)
void foobar()
{
int b; // not used.
UNUSED(b); // now it's used
}
Solved it.
I just added the text from the warning that I wanted to ignore to immediately above where the break would be.
Like this:
case enChC:
++nChannel;
//No break at the end of case
case enChD:
++nChannel;
As is has been said, in this specific case, it can be solved adding the comment:
//no break
or:
//no break at the end of case
What really matters is the (no break).
But also, it is required that you don't have more comments between the end of this case and the next one or it won't work. For example the next case will still result in a warning:
case enChC:
++nChannel;
//No break
//This second case decrease the value
case enChD:
++nChannel;
You have to upgrade to Eclipse Oxygen.3 (or.2).
Beginning with these versions warnings/markers can be suppressed by simply using "Quick Fix".
UPDATE 2021
Version: 2021-03 (4.19.0)
Build id: 20210312-0638
Assuming you have this switched on
window -> Preferences -> (Your code example) C/C++ -> Code Analysis -> No break at end of case
If you go to Customize Selected..., you will get "Comment text to suppress the problem [...]" which declares which data stream will actually only change the effect but still won't fix the problem.
The relevant line is in the file org.eclipse.cdt and looks like this :
org.eclipse.cdt.codan.internal.checkers.CaseBreakProblem.params={launchModes=>{RUN_ON_FULL_BUILD=>true,RUN_ON_INC_BUILD=>true,RUN_ON_FILE_OPEN=>false,RUN_ON_FILE_SAVE=>false,RUN_AS_YOU_TYPE=>true,RUN_ON_DEMAND=>true},suppression_comment=>"#suppress(\"No
break at end of case\")",no_break_comment=>"no
break",last_case_param=>false,empty_case_param=>false,enable_fallthrough_quickfix_param=>false}
Having this like in my example will work with the code below.
Note that the content of the comment does not matter, but it must contain an identical fragment corresponding to the settings contained in the Eclipse itself
Additionally, it is important to put the comment after the } character, unless it is a single argument case
Eclipse will still report the problem and this cannot be avoided in any way by having the bug report enabled in the settings, but it will no longer underline every line in the case
switch(next) {
case 0: {
if(true) {
//Do stuff...
} else {
break;
}
next = 1;
}
// ThiS Is The Line that CAUSE N"no break////////"
case 1: {
if(true) {
//Do stuff...
} else {
break;
}
next = 2;
}
case 2: {
if(true) {
//Wont do stuff...
//It will break here
break;
} else {
next = 3;
}
}
I present a photo that shows the effect in the eclipse itself.
I have encountered this question,and I just want to eliminate them.
I tried to add /* no break */,you should make sure it is added before the next "case".
This is the question I have encountered
This is the solution I useļ¼
I have to parse more than one file, with different rules for each case. That is: I need some rules to work when processing a file, and be disabled afterwards.
I could simple use a global variable to track the state of the program, and have my rules decide inside their body whether to do anything useful or not, like this:
%{
static int state;
%}
%%
{something} {
if (state == SOMETHING_STATE) ...
}
{something_else} {
if (state == SOMETHING_ELSE_STATE) ...
}
%%
I'm guessing there's a better way to do this, though. Is there?
You want start states -- basically lex has a builtin state variable and you can annotate rules as only firing in certain states
%s state1
%s state2
%s state3
%%
<state1>{something} { // this rule matches only in state1
// change to state2
BEGIN(state2); }
<state1,state3>{something_else} { // this rule matches in state1 or state 3 }
{more_stuff} { // this rule matches in all states }
You can find documentation on this in any lex or flex book, or in the online flex documentation
Assuming you're using something like Flex rather than the original lex, you can use start states. When you parse something that changes how you do the parsing, you enter a state to do that parsing, and you tag the appropriate rules with that state. When you parse whatever marks the end of that state, you go do another:
{state_signal} { BEGIN(STATE2); }
<STATE2>{something} { handle_something(); }
<STATE2>{state3_signal} { BEGIN(STATE3); }
<STATE3>{something} {handle_something2(); }
<STATE3>{whatever} { BEGIN(START); }
Using Flex and Yacc you can also build diferent individual parsers and tweak the makefile in order to compile them into a single executable. I believe you're only using Flex, but this should be possible too.
I can't precise exactly how to do it now, but i've already actually done it,quite some time ago, so if you look around you'll find a way. Basiccly you'll have to compile each parser with a diferent prefix (-P), and that will generate diferently named parse functions and diferently named global variables for the parsers to use.