lately I have been programming a lot with Elixir, and like in ruby, it is expected to write code using snake_case.
But this is starting to get really uncomfortable. Right now it hurts a bit, so I though it would be a good idea to bindunderscore to another key, in which I don't have to press shift.
Is there an easy way of doing that?
Or if you have another tip to avoid that it would be nice as well.
Related
I am new to Mathematica, have used RStudio before for R and like the feature for brackets' autocompletion. There are plenty of different brackets are used in Mathematica code and it is handy to have same feature there. May be I just missed where the setting for it is?
Go to Insert -> Typesetting to find the keyboard shortcuts for inserting matching [], () or {}. On OS X it's Option-Command-].
There's information on matching brackets in the documentation.
The good news is that this functionality is much less needed in Mathematica than in R. In Mathematica, instead of writing
f[g[h[x]]]
I like to write the completely equivalent but much more readable
f#g#h[x]
Instead of writing
lapply(arr, f)
we would write
f /# arr
in Mathematica. This is equivalent to Map[f, arr] but has no brackets.
It's worth putting in some time to learn how to use these weird looking operators effectively. While it's certainly possible to use them to make your code cryptic and unintelligible, when used correctly, they can improve readability significantly. It just requires experience and a little discipline. I recommend you look at https://mathematica.stackexchange.com/ to get used to the idiomatic use of these operators.
While learning Mathematica keep in mind that there is a subjective (or "cultural") element to "readability". You'll need to get used to the community standards and common idioms before all of this starts making sense. That's why I suggest reading Mathematica.SE.
Update: I forgot to mention the somewhat annoying [[ ... ]] notation for Part. Go to the bottom my Mathematica page to see how to set up keyboard shortcuts for inserting the equivalent but more readable 〚. esc [ esc also works but I find it too tedious.
In emacs, the syntactic analysis is surprisingly little.
For example, if I wish to indent parameter names differently than the types in a function declaration, like so:
void myfunction(
int
test
);
int is considered an arglist-intro, and test is considered as arglist-cont. However, if I add any more parameters, they'll all be considered arglist-cont, so indenting arglist-cont wouldn't do the desired effect.
So here's what I'm wondering: Is it possible to make my own syntactic analysis thingy for emacs so that it'll recognize and differentiate cases like this (this isn't the only case, by the way)? And if so, how?
Yes, of course you can write whatever you want. Emacs is free software, it comes with sources, so you can modify them as you wish.
However, please be aware that Emacs is quite widely used, including by some very smart hackers. This means that Emacs limitations usually (but, of course, not always!) have a good reason behind them (in your case, the reason is that the C syntax is quite complex). The implication is that doing what you want to do might be harder than you might be thinking. Not that it should discourage you, of course!
PS. You asked "is it possible to make my own syntactic analysis", not "how to do that" :-)
PPS. As for "how", you will have to start with cc-engine.el.
I know I risk asking a speculative question, however, inspired by this recent question I wonder which editor does the best job of syntax highlighting Perl. Being well aware of the difficulties (impossibilities) of parsing Perl I know there will not be a perfect case. Still I wonder if there is a clear leader in faithful representation.
N.B. I use gedit and it works fine, but with known issues.
Komodo Edit does a good job and also scans your modules (including those installed via CPAN) and does well at generating autocomplete data for them.
I'm a loyal vim user and rarely encounter anything odd with the native syntax.vim, except for these cases (I'll edit in more if/when I find them; others please feel free also):
!!expression is better written !!!!expression (everything after two ! is rendered as a comment quoted string; four ! brings everything back to normal)
m## or s### renders everything after the # as a comment; I usually use {} as a delimiter when avoiding / for leaning toothpick syndrome
some edge cases for $hash{key} where key is not a simple alphanumeric string - although it's safer to enclose such key names in '' anyway so as to not have to look up the exact cases for when a bareword is treated as a key name
I haven't used it, but Padre should be good since it's written in Perl. IIRC It uses PPI for parsing
jEdit...with the tweaks that I have amassed over the years. It's got the most customizable syntax highlighting I've ever seen.
I use Emacs in CPerl mode. I think it does a terrific job, although similar to Ether's answer, it's not perfect. What's more, I usually use Htmlize to publish highlighted code to the web. It's kind of annoying to use fancier forums like this one that do their own syntax highlighting, since it's not really any easier and the results aren't as good.
I'm bewildered by all the built-in Mathematica functions that purport to prevent evaluation in some way: Unevaluated, Defer, Hold, and over half a dozen of the form Hold*. The Mathematica documentation just explains each function in isolation without explaining why you would choose one or the other. Can anyone offer a coherent explanation of all these functions? The whole thing seems like a convoluted mess to me. Relating it all to Lisp macros might be a good place to start.
Most of the Mathematica language is amazingly well-designed but it seems like Wolfram really painted himself into a corner on this aspect. Or I could be missing something.
These are pretty tricky constructs, and it's tough to give clear explanations; they aren't as straightforward as Lisp macros (or, for that matter, the relationship between Lisp's QUOTE and EVAL). However, there's a good, lengthy discussion available in the form of notes from Robby Villegas's 1999 talk "Unevaluated Expressions" on Wolfram's website.
Defer is omitted from that talk, because it's new as of Mathematica 6.0. It's a lot like HoldForm, except that when it's output in a front-end (but not a bare kernel) it's stripped away, leaving an expression that can be used as input. This is very useful if you want to programmatically construct expressions that a user can edit and evaluate, say in a palette.
Depending on my mood I seem to waffle back and forth between wanting a Lisp-1 and a Lisp-2. Unfortunately beyond the obvious name space differences, this leaves all kinds of amusing function name/etc problems you run into. Case in point, trying to write some code tonight I tried to do (map #'function listvar) which, of course, doesn't work in CL, at all. Took me a bit to remember I wanted mapcar, not map. Of course it doesn't help when slime/emacs shows map IS defined as something, though obviously not the same function at all.
So, pointers on how to minimize this short of picking one or the other and sticking with it?
Map is more general than mapcar, for example you could do the following rather than using mapcar:
(map 'list #'function listvar)
How do I keep scheme and CL separate in my head? I guess when you know both languages well enough you just know what works in one and not the other. Despite the syntactic similarities they are quite different languages in terms of style.
Well, I think that as soon you get enough experience in both languages this becomes a non-issue (just with similar natural languages, like Italian and Spanish). If you usually program in one language and switch to the other only occasionally, then unfortunately you are doomed to write Common Lisp in Scheme or vice versa ;)
One thing that helps is to have a distinct visual environment for both languages, using syntax highlighting in some other colors etc. Then at least you will always know whether you are in Common Lisp or Scheme mode.
I'm definitely aware that there are syntactic differences, though I'm certainly not fluent enough yet to automatically use them, making the code look much more similar currently ;-).
And I had a feeling your answer would be the case, but can always hope for a shortcut <_<.
The easiest way to keep both languages straight is to do your thinking and code writing in Common Lisp. Common Lisp code can be converted into Scheme code with relative ease; however, going from Scheme to Common Lisp can cause a few headaches. I remember once where I was using a letrec in Scheme to store both variables and functions and had to split it up into the separate CL functions for the variable and function namespaces respectively.
In all practicality though I don't make a habit of writing CL code, which makes the times that I do have to all the more painful.