I'm just getting started learning the D language, and I'm curious whether a .nanorc file with syntax highlighting rules for D is available. Nothing turns up with a quick google search.
I've just made one, for you and me (since I don't believe that anyone else in the world uses nano for D :-)
Have a look: https://github.com/vinesworth/d-nanorc
Mostly incomplete list of tools that support D (feel free to edit, its a wiki)
IDEs
Editors
Related
I'd thinking about creating my own Terminal Emulation library, and I'd like to start by trying to get the latest standard for ANSI terminals. I know there are a lot resources out there, but I'd like to read the actual standard if I can.
If the standard costs "a lot of money" (for me, more than $25) to acquire, what's the next best (most complete) description I can find?
I think I found what I'm looking for.
According to WikiPedia's ANSI escape code, the standard adopted was ECMA-48, the document is available at www.ecma-international.org Ecma-048.pdf
I searched plenty of sources but havent found anything yet.
I'm trying to create an AST (in Java) for a input file written in C. I found ANTLR and it works with the "official" C-Grammar from the ANTLR examples. Nevertheless, I read about editing grammar for the syntax-tree with e.g. "^" to mark roots etc.
When I set the output at the C.g to output=AST an empty graph is printed (some dot gibberish). Also I can't find any of that mentioned tree symbols in the grammar.
So I need to asume, that grammar doesn't support AST-generation.
Is there any working C grammar that has syntax for a AST in it? I need to find a solution in a proper time, and I wanted to check all available ressources bevor starting to edit the given grammar (what I guess will be an awful lot of work).
Thanks for you time,
Simon
I have a sizable vim script (a .vim file, in viml syntax). I'd like to check (but not execute!) the file for simple syntax errors.
How do I accomplish this?
I just want a very rough syntax check. Something along the lines of perl -c or pyflakes.
Here is a syntax checker for VimL.
https://github.com/syngan/vim-vimlint/
I don't think (I'm relatively sure, as much as one can be) one exists. VimL is an internal language of Vim (and only Vim), and there aren't many tools developed for it.
I tried searching on vim.org and several other places, with no luck. Not suprising, because I've never heard of one either.
So you're either stuck with running the script, or switching to an outside language like Python, Perl or Ruby.
https://github.com/osyo-manga/vim-watchdogs
vim-watchdogs, apparently, is a syntax checker for vim, it says that it supports many languages, including vimL
if you use vundle, you can just drop this into your vimrc:
Plugin 'git://github.com/osyo-manga/vim-watchdogs.git'
..and then run:
:PluginInstall
..to set it up (vundle is a very nifty plugin manager) If you have syntastic, you might want to be careful and disable it first, and then see if it is an adequate replacement (since it says it supports all those languages anyway).
It is a safe bet that when you have multiple syntax checkers going, you will need to put your "dogs on a leash", so to speak; by configuring one to check languages that the other one does not, and vice-versa. If you do not, there will be at best collisions, duplications, or misdirections. At worst, you will have all of the above and more.
Make sure that you always backup your ~/.vim directory (or your VIMRUNTIME directory if you install things on a global level), you will be glad you did. Hope that helped you or someone else out, good luck! Sorry you had to wait 7.5 months for a response, heh :)
There's now a second option: vim-lint (as opposed to vimlint)
I am new to mac, and am in the process of getting my computer setup with all the programs I need, one of them being Haskell.
To my surprise, the Haskell platform for OS X is not like in Windows (where there is an GUI editor built on the platform installation - winGHiC). After looking a lot around, I found this editor TextMate which is supposed to be compatible with Haskell but am finding it quite complex to setup the Haskell Bundle for it.
I have already downloaded and installed the following:
Haskell Platform for Mac OS X
Xcode 3.4 (Haskell Prerequisite)
TextMate
haskell.tmbundle files (mentioned above)
Is anyone familiar on how to get it working? It will mean a lot to me a detailed stepwise explanation, like I said, I has been only 1 day since I used OS X for the first time.
Thanks a bunch.
Well it's good work that you have found that the tmbundle is on Github these days.
You should be able to find the inbuilt options by clicking Bundles, then Haskell. There are fairly few in the standard Haskell.tmbundle. The most obviously useful one is ... load file command-shift-r or command-R. If you have written a module with ending .hs or .lhs, it ... opens it in ghci.
(There was some talk of an integrated terminal in TextMate II, but who knows? One annoying feature of a non-integrated terminal is that one is tempted to 'reload' by clicking command-R rather than by doing :r inside ghci; in certain frenzies it will develop that I have 15 copies of Terminal open.)
Many of the nice features are just general TextMate things, determined by the language description, so it might be good to read a general description of TextMate niceties. For example, if several lines are highlighed, then command-/ comments them out with --s; or, if they are already commented, uncomments them. I had hacked together something to do this, long before I realized it was already there, not having studied the manual closely enough.
Everything has keybindings, of course, and it is very easy to add your own to run little scripts and insert little snippets, much more so than in Emacs, say.
Under Bundles click Bundle Editor and examine the text for different kinds of things.
So, for example, to make a tab trigger to start a language extension pragma {-#LANGUAGE ... #-} where the cursor is in the space ...make a copy of a Snippet and substitute
{-#LANGUAGE ${1}#-}
selecting Activation: Tab Trigger, and (say) LANG as the trigger.
One nice thing is that they are all shell scripts, or else (like this one) partial shell scripts with some TextMate variables around, and you can pretty much write them in your own preferred language. (For the Haskell bundle I don't have any Haskell ones to speak of any more, but for other bundles I do.)
The syntax highlighting is surprisingly sound, but trips over a few fancy extensions, e.g. "PackageImports" , GADT syntax, markup for the Haddock documentation system, and some other oddities. I have hacked my own, but I find the format of the syntax files pretty unintelligible, so it's no use sending you a copy. The Haskell.tmbundle has been emended by some knowledgeable Haskellers in the last two or three years. The person who first made it was just learning Haskell, and hadn't e.g. composed Haddocked modules, but on the other hand, he seems fortunately to have been very skilled and to have had an intimate knowledge of the TextMate machinery.
Notice by the way that TextMate stores the emendations you make in the Bundle Editor in a rather strange way. The bundles that come with TextMate, e.g. C, Ruby, HTML, LaTeX, etc. are in /Applications/Textmate.app/.../Bundles. The ones you install are in /Library/Application\ Support/TextMate/Bundles. When you make emendations through the Bundle Editor, they are stored in your local ~/Library/Application\ Support/TextMate/Bundles. It sort of makes sense but it's a little complicated, and impedes public improvement of the Haskell bundle. (The one bundle I share with people, not the Haskell one, I keep in the lattermost, outermost directory under git revision, so the original and my emendations are together.)
The "Lookup on Hoogle" keybinding/option acts on highlighted terms; here's a replica for the hayoo website, which can search for uses of a type-signature
echo "<meta http-equiv=\"refresh\" content=\"0;
http://holumbus.fh-wedel.de/hayoo/hayoo.html?query=${TM_SELECTED_TEXT:=$TM_CURRENT_WORD}\">"
If you cabal install hoogle, then you can make a local call to hoogle with a script like so:
hoogle --w --n=100 '${TM_SELECTED_TEXT:=$TM_CURRENT_WORD}'
choosing Save: Nothing, Input: Selected Text, Or: Word, Output: Show as HTML
Other emendations I have made are mostly trivial, like a tab trigger snippet for `{-#LANGUAGE ... #-} or else eccentricities of my own.
One thing worth mentioning that I managed to integrate is the typeof executable from Hackage, cabal install typeof, which runs to ghci for an inferred type signature. I have a key binding to show the inferred type as displayed bit of html, but also to insert it. It's a bit delicate but here is the text for the displayer of types
#!/bin/bash
word=${TM_SELECTED_TEXT:-$TM_CURRENT_WORD}
module="${TM_FILEPATH}"
echo $word | typeof $module
choosing Input: Selected Text, Or: Line ; Output: Show as Tool Tip, Activation : Key Equivalent (then choose a keybinding , mine is control-option-command-j) Similarly, for type insertion via typeof make a new C (command file) heading and include this:
#!/bin/bash
word=${TM_SELECTED_TEXT:-$TM_CURRENT_WORD}
module="${TM_FILEPATH}"
echo $word | typeof $module | typeof_wordorder
# typeof_wordorder is the following hack compiled
# in my local ~/bin
# module Main where
# main = interact reword where
# reword :: String -> String
# reword xs =
# xs ++ (head . words . concat . lines $ xs)
Here typeof and typeof_worderorder are Haskell executables, the first cabal-installed, the second is the above commented idiocy, compiled in my local ~\bin to get around some escaping nonsense. Here you should choose Output : Insert as Snippet
Sorry, I'm just thinking of random things. You should keep posting questions under this heading, as I think it would be worthwhile to see how one might trip up, but also what hacks our cleverer Haskeller friends may have thought of. I keep meaning to put a 'fork' of my tmbundle on github, but it's not too thrilling, and the organization of Bundle directories forever defeats me.
A recent question about StyleCop alerted me to the use of tools to enforce coding style. I would feel very annoyed if I were required to run one of these tools while I was developing. Do people really find them useful? Why or why not?
Everyone that has answered so far has indicated that they think that style/formatting rules are useful, and I am in 100% agreement with that. But what about using a tool for enforcement, rather than a style guide and regular code reviews? Have people found that useful in practice? Why or why not?
Yes, it's very helpful - particularly in large projects. It means you can go to anyone else's code, and it won't look alien to you. This means that people are more portable across projects, which gives a lot more flexibility - both for the person and the company.
The downside is that a lot of time can be spent arguing over which style to use.
There is a difference between a Coding style and a Formatting style.
A coding style enforces good practices.
the body of a 'IF' statement must be wrapped in opening and closing curly brackets
A formatting style is how the code looks.
where the '{' comes in an 'IF' statement.
In a team environment;
a good formatting tool will allow all the developers to see the code the way they want to see the code.
a good style tool will insure all the code follows the same guidelines
I like the concept of StyleCop, although I don't really care for a lot of the rules. Style is just so subjective that I find myself struggling to firmly decide if it should be part of our process or not. I really would prefer to see the team with a unified style, though, which is why I am so torn.
Obviously, the flip-side of the equation, with a tool like FxCop (or Code Analysis for fellow TFS users) is more based on practices, so the decision becomes more technical than personal and stylistic.
If style refers to formatting (like '{' must be at the end or at the beginning of a line), it can be very annoying, especially if merges are involves and if that style is not strictly enforced for all developers.
If style refers to 'good practice" (like the body of a 'if' statement must be wrapped in opening and closing curly brackets), it can be actually very useful.
I think in a large team, a uniform coding style is essential. Having some standard helps with maintainability, in that a new developer can be brought on to maintain old code, with minimal learning curve.
As far as enforcing styling differences (such as where the '{' comes) can be very easily be accomplished by automated tools, without imposing on the development process too much. Eclipse and Visual Studio both have a very rich set of options to format your code automatically based on a large set of options.
Restrictions on programming or formatting style might help reducing friction in a team of more than one person.
Restrictions on language features (especially using only a subset of C#) can help you concentrate on the problem domain instead of having to deal with an overwhelming number of concepts. This does matter if your software has to be robust and thoroughly understandable.
Regards,
tamberg
If you are using a version control system, it can get very ugly if every developer reformats the code towards his own preferences whenever he touches a file. In a place where the developers don't have the necessary communication skills, Wikipedia-like edit-wars can ensue if each developer passive-aggressively sticks to "his" standard.
Overall, manual reformatting also leads to more conflicts on checkins if two people work on the same file.
So if you are using a VCS, I'd even recommend enforcing formatting rules. Enforcing style rules can lead to better code quality.