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)
Related
Looking for more R-ish ways of implementing a "for" loop with "subset", that will lend itself to implementation in R Markdown
I have a large dataset, that can be summarised as:
StudentID, Unit, TutorialID, SemesterID, Mark, Grade
I have written the following code, which seems to work OK. This reflects my background as an imperative programmer of long ago (and the fact that I am self-taught in R). Partly, I am curious as to how to write the "sequential application of a group of functions" to "successive subsets" in a way that is more R-ish.
ListOfUnits <- unique (Dataset$Unit)
for (val in ListOfUnits) {
EachUnit <- subset(Dataset, Unit == val)
boxplot(Mark ~ TutorialID, ylim=c(0,100), data=EachUnit,outline=TRUE,main=val)
aggregate(x= EachUnit$Mark, by = list(EachUnit$Campus), FUN=mean, na.rm=TRUE)
aggregate(x= EachUnit$Mark, by = list(EachUnit$Campus), FUN=sd, na.rm=TRUE)
if (nrow(count(EachUnit$TutorialID)) >= 2) {
# Here I have code to run an ANOVA and the Tukey HSD test for any difference
# between means among tutorial groups, culminating in
bar.group(pp$groups,ylim=c(0,100),density=400,border="black",main=val)
}
else {
}
}
I have also tried my hand at creating an R Markdown script to genearte a report on the multitude of units that exist. What seemed a promising approach involves knitr::knit_expand(file = "file_location" ... early efforts seemed to be good, but when I included "for" or "if" statements in either the 'parent' or 'child' file, it either generated errors or did not run as expected.
My conclusion is that the basic routine is insufficiently "R-ish", hence the question above.
But an immediate follow-on question is "how to achieve the above in R Markdown, so as to produce a report"?
Thank you
The following prototype does the job:
Unit_Statistics <- function(Unit) {
boxplot(Mark ~ Campus, ylim=c(0,100),data=Unit,outline=TRUE,main=Unit$Unit[1])
}
bitbucket <- Dataset %>% group_by(Unit) %>% do(Stats=Unit_Statistics(.))
Reading through https://docs.perl6.org/language/packages#Package-qualified_names it outlines qualifying package variables with this syntax:
Foo::Bar::<$quux>; #..as an alternative to Foo::Bar::quux;
For reference the package structure used as the example in the document is:
class Foo {
sub zape () { say "zipi" }
class Bar {
method baz () { return 'Þor is mighty' }
our &zape = { "zipi" }; #this is the variable I want to resolve
our $quux = 42;
}
}
The same page states this style of qualification doesn't work to access &zape in the Foo::Bar package listed above:
(This does not work with the &zape variable)
Yet, if I try:
Foo::Bar::<&zape>; # instead of &Foo::Bar::zape;
it is resolves just fine.
Have I misinterpreted the document or completely missed the point being made? What would be the logic behind it 'not working' with code reference variables vs a scalar for example?
I'm not aware of differences, but Foo::Bar::<&zape> can also be modified to use {} instead of <>, which then can be used with something other than literals, like this:
my $name = '&zape';
Foo::Bar::{$name}()
or
my $name = 'zape';
&Foo::Bar::{$name}()
JJ and Moritz have provided useful answers.
This nanswer is a whole nother ball of wax. I've written and discarded several nanswers to your question over the last few days. None have been very useful. I'm not sure this is either but I've decided I've finally got a first version of something worth publishing, regardless of its current usefulness.
In this first installment my nanswer is just a series of observations and questions. I also hope to add an explanation of my observations based on what I glean from spelunking the compiler's code to understand what we see. (For now I've just written up the start of that process as the second half of this nanswer.)
Differences (if any) between Package::<&var> vs &Package::var?
They're fundamentally different syntax. They're not fully interchangeable in where you can write them. They result in different evaluations. Their result can be different things.
Let's step thru lots of variations drawing out the differences.
say Package::<&var>; # compile-time error: Undeclared name: Package
So, forget the ::<...> bit for a moment. P6 is looking at that Package bit and demanding that it be an already declared name. That seems simple enough.
say &Package::var; # (Any)
Quite a difference! For some reason, for this second syntax, P6 has no problem with those two arbitrary names (Package and var) not having been declared. Who knows what it's doing with the &. And why is it (Any) and not (Callable) or Nil?
Let's try declaring these things. First:
my Package::<&var> = { 42 } # compile-time error: Type 'Package' is not declared
OK. But if we declare Package things don't really improve:
package Package {}
my Package::<&var> = { 42 } # compile-time error: Malformed my
OK, start with a clean slate again, without the package declaration. What about the other syntax?:
my &Package::var = { 42 }
Yay. P6 accepts this code. Now, for the next few lines we'll assume the declaration above. What about:
say &Package::var(); # 42
\o/ So can we use the other syntax?:
say Package::<&var>(); # compile-time error: Undeclared name: Package
Nope. It seems like the my didn't declare a Package with a &var in it. Maybe it declared a &Package::var, where the :: just happens to be part of the name but isn't about packages? P6 supports a bunch of "pseudo" packages. One of them is LEXICAL:
say LEXICAL::; # PseudoStash.new(... &Package::var => (Callable) ...
Bingo. Or is it?
say LEXICAL::<&Package::var>(); # Cannot invoke this object
# (REPR: Uninstantiable; Callable)
What happened to our { 42 }?
Hmm. Let's start from a clean slate and create &Package::var in a completely different way:
package Package { our sub var { 99 } }
say &Package::var(); # 99
say Package::<&var>(); # 99
Wow. Now, assuming those lines above and trying to add more:
my Package::<&var> = { 42 } # Compile-time error: Malformed my
That was to be expected given our previous attempt above. What about:
my &Package::var = { 42 } # Cannot modify an immutable Sub (&var)
Is it all making sense now? ;)
Spelunking the compiler code, checking the grammar
1 I spent a long time trying to work out what the deal really is before looking at the source code of the Rakudo compiler. This is a footnote covering my initial compiler spelunking. I hope to continue it tomorrow and turn this nanswer into an answer this weekend.
The good news is it's just P6 code -- most of Rakudo is written in P6.
The bad news is knowing where to look. You might see the doc directory and then the compiler overview. But then you'll notice the overview doc has barely been touched since 2010! Don't bother. Perhaps Andrew Shitov's "internals" posts will help orient you? Moving on...
In this case what I am interested in is understanding the precise nature of the Package::<&var> and &Package::var forms of syntax. When I type "syntax" into GH's repo search field the second file listed is the Perl 6 Grammar. Bingo.
Now comes the ugly news. The Perl 6 Grammar file is 6K LOC and looks super intimidating. But I find it all makes sense when I keep my cool.
Next, I'm wondering what to search for on the page. :: nets 600+ matches. Hmm. ::< is just 1, but it is in an error message. But in what? In token morename. Looking at that I can see it's likely not relevant. But the '::' near the start of the token is just the ticket. Searching the page for '::' yields 10 matches. The first 4 (from the start of the file) are more error messages. The next two are in the above morename token. 4 matches left.
The next one appears a quarter way thru token term:sym<name>. A "name". .oO ( Undeclared name: Package So maybe this is relevant? )
Next, token typename. A "typename". .oO ( Type 'Package' is not declared So maybe this is relevant too? )
token methodop. Definitely not relevant.
Finally token infix:sym<?? !!>. Nope.
There are no differences between Package::<&var> and &Package::var.
package Foo { our $var = "Bar" };
say $Foo::var === Foo::<$var>; # OUTPUT: «True»
Ditto for subs (of course):
package Foo { our &zape = { "Bar" } };
say &Foo::zape === Foo::<&zape>;# OUTPUT: «True»
What the documentation (somewhat confusingly) is trying to say is that package-scope variables can only be accessed if declared using our. There are two zapes, one of them has got lexical scope (subs get lexical scope by default), so you can't access that one. I have raised this issue in the doc repo and will try to fix it as soon as possible.
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.
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)))
I use a custom syntax highlighting theme for C in emacs, but I'm missing the possibility of highlighting function calls. For example:
int func(int foo)
{
return foo;
}
void main()
{
int bar = func(3);
}
Is there any way to highlight the call to "func" in this example?
It doesn't matter if macros are highlighted too. Keywords like if, switch or sizeof should not match.
Thanks!
The order of entries in the keyword list is significant. So if you put your entries after the ones that highlight keywords and function declarations, these won't be matched.
(font-lock-add-keywords 'c-mode
'(("\\(\\w+\\)\\s-*\("
(1 rumpsteak-font-lock-function-call-face)))
t)
Alternatively, you can use a function instead of a regexp as the MATCHER. Overkill for your question if you've stated your requirements exactly, but useful in harder cases. Untested (typed directly in the browser, in fact, so I don't even guarantee balanced parentheses).
(defun rumpsteak-match-function-call (&optional limit)
(while (and (search-forward-regexp "\\(\\w+\\)\\s-*\(" limit 'no-error)
(not (save-match-data
(string-match c-keywords-regexp (match-string 1))))
(not (save-excursion
(backward-char)
(forward-sexp)
(c-skip-whitespace-forward)
(or (eobp) (= ?\{ (char-after (point)))))))))
(font-lock-add-keywords 'c-mode
'((rumpsteak-match-function-call
(1 rumpsteak-font-lock-function-call-face))))
(font-lock-add-keywords 'c-mode
'(("\\<\\([a-zA-Z_]*\\) *(" 1 font-lock-keyword-face)))
in your .emacs. Replace font-lock-keyword-face by the one you want (M-X list-faces-display to get a list of predefined one).
You can try Ctrl-s for searching or Ctrl-r for searching backward. Emacs will highlight your function for you.