:syntax Off(kyleisom.net)
kyleisom.net
:syntax Off
http://www.kyleisom.net/blog/2012/10/17/syntax-off/
32 comments
> If you follow this reasoning I think you'd also have to shun line breaks and indentation.
Not quite. As I'm sure you know, written languages have evolved over time in order to meet the needs of readers and writers alike. That includes capital/lowercase, roman style (i.e. non-script) lettering, spaces, leading and paragraph indentation (thanks to printers), etc. It isn't helpful to blindly latch on to seemingly cute analogies, but in this case I think it's a pretty fair comparison. I imagine others who don't use highlighting all the time would agree that it's a happy or at least comfortable middle ground. I'm a little sleepy-eyed now and shouldn't still be typing, so sorry if my tone reflects negatively. I think the response below (corwinstephen) brings up the same thing, except if you like highlighting then your middle ground leans further towards an explicit, notated style.
Not quite. As I'm sure you know, written languages have evolved over time in order to meet the needs of readers and writers alike. That includes capital/lowercase, roman style (i.e. non-script) lettering, spaces, leading and paragraph indentation (thanks to printers), etc. It isn't helpful to blindly latch on to seemingly cute analogies, but in this case I think it's a pretty fair comparison. I imagine others who don't use highlighting all the time would agree that it's a happy or at least comfortable middle ground. I'm a little sleepy-eyed now and shouldn't still be typing, so sorry if my tone reflects negatively. I think the response below (corwinstephen) brings up the same thing, except if you like highlighting then your middle ground leans further towards an explicit, notated style.
Further, if you write a list of instructions (say, a recipe), you will likely follow a convention that puts each instruction on a separate line, and might make use of indentation to further delineate sub-instructions.
> ... capital/lowercase, roman style (i.e. non-script) lettering, spaces ...
I think this are poor man's syntax hi-lighting. Or at least physical world implementation of syntax hi-lighting. After all, you don't want to carry a lots of colors pen in order to write.
But if computer can do it for us, why not?
I think this are poor man's syntax hi-lighting. Or at least physical world implementation of syntax hi-lighting. After all, you don't want to carry a lots of colors pen in order to write.
But if computer can do it for us, why not?
Agreed. Plus, I think he's way off base when he says that syntax highlighting is equivalent to emphasizing certain parts of speech in traditional prose. It's not. The prose equivalent of not including syntax highliting would be not including and paragraphs, capital letters, commas, apostrophes, periods, bold, italics, or underlines. You're left with something that contains the same information, but is harder to understand.
Also, it bugs me when people try to compare code and prose. Just because they're both typed as text using keys on a keyboard doesn't mean they're in any way related. Calling them analogous is like trying to compare building a house and buying a car. Yeah, they're both life investments, but that doesn't mean you use any of the same strategies between them. Money aside, they're unrelated.
Also, it bugs me when people try to compare code and prose. Just because they're both typed as text using keys on a keyboard doesn't mean they're in any way related. Calling them analogous is like trying to compare building a house and buying a car. Yeah, they're both life investments, but that doesn't mean you use any of the same strategies between them. Money aside, they're unrelated.
> After all, natural language doesn't put each sentence on a separate line, or indent clauses. It flows in uninterrupted prose with paragraph breaks being the only distinguishing horizontal or vertical formatting.
Code is closer to poetry than prose. Line breaks and stanzas are very important, there.
Code is closer to poetry than prose. Line breaks and stanzas are very important, there.
>When I read a book, I don’t want parts of speech highlighted in different colours. What I want to do is to read the book, to take in the information.
I actually think this would be a great idea and it would probably prevent me from having to reread paragraphs every now and then because I thought the wrong person was talking.
I actually think this would be a great idea and it would probably prevent me from having to reread paragraphs every now and then because I thought the wrong person was talking.
Yea color coding character's speech would allow for some interesting changes in structure, for example, you could have characters interrupt another without breaking the line making it much more fluid.
Although I think the article as a whole is insightful, I really don't agree with the book analogy. Most of the time, one reads a book in a very linear fashion - left to right, top down, hopefully with little interruption. With code, I find myself having to jump around a lot more - to find where something has been declared, or to look up a subroutine, etc. This means there is a lot more searching for the relevant text in programming than in reading a book, and syntax highlighting helps my eyes identify these parts on a line or a block a lot more quickly.
However, I can see how turning off syntax highlighting could help one learn to keep more code in their head at once, so they don't have to jump around as much, but to me, it's not worth it.
However, I can see how turning off syntax highlighting could help one learn to keep more code in their head at once, so they don't have to jump around as much, but to me, it's not worth it.
I tried this before. I used to write all of my code without syntax highlighting -- for years. Once I switching to highlighting, my errors decreased, my productivity increased, and I was a lot happier. To each his own I suppose.
Interesting. Both what Kyle talks about, and also the fact that I've never thought of not having syntax highlighting before. It's just been a built in assumption.
I opened vim and cycled through syntax on, syntax off a few times, and thought about what I think about when I see it. After this short experiment, I think that most of what I use syntax highlighting for is just to add texture to the code. The pattern of indentations and syntax highlighting gives the code shape.
So when I scroll, or scan the code, I've got another a set of visual anchors in addition to the structure given by indentation. It makes me feel more comfortable. Past that, for me, the syntax highlighting is just noise.
Makes me wonder how to increase the feeling of visual structure in the code without introducing visual noise...
I opened vim and cycled through syntax on, syntax off a few times, and thought about what I think about when I see it. After this short experiment, I think that most of what I use syntax highlighting for is just to add texture to the code. The pattern of indentations and syntax highlighting gives the code shape.
So when I scroll, or scan the code, I've got another a set of visual anchors in addition to the structure given by indentation. It makes me feel more comfortable. Past that, for me, the syntax highlighting is just noise.
Makes me wonder how to increase the feeling of visual structure in the code without introducing visual noise...
Something I've found useful is to highlight (in bold) the definitions of variables & types, but not their uses; and to otherwise have very little highlighting: http://david.rothlis.net/code_presentation/distracting_synta...
This just made me think that highlighting would be way more interesting if you could change the scheme on the fly. An editor could have 5-10 highlighting schemes—not different colors, but different kinds of information shown (because let's face it, highlighting is valuable information).
Examples I just thought up:
* Variable-scoping-level highlighting—variables in the same scope highlighted the same color.
* "String only"—highlight only strings and literals. Check for language bugs.
* grep-only highlighting—define a set of things to grep for quickly and highlight them.
* block-focused—highlight code blocks so you get an idea of the overall structure of your program.
* No-highlighting: if you really want a moment of clarity on your code. There is absolutely no reason to give up the information highlighting provides 100% of the time, but I could see it being useful sometimes when you need to focus.
And countless more. If I could switch with a quick keyboard shortcut to a highlighting scheme appropriate for any given programming task, it would be phenomenal. I could see it being useful for all kinds of things, and helping to show more information from the compiler than syntax highlighting does already, in a better way. It would be instant visual information, and there's no reason to limit it to syntax like we do currently.
Hmm. Sublime Text Plugin perhaps?
Examples I just thought up:
* Variable-scoping-level highlighting—variables in the same scope highlighted the same color.
* "String only"—highlight only strings and literals. Check for language bugs.
* grep-only highlighting—define a set of things to grep for quickly and highlight them.
* block-focused—highlight code blocks so you get an idea of the overall structure of your program.
* No-highlighting: if you really want a moment of clarity on your code. There is absolutely no reason to give up the information highlighting provides 100% of the time, but I could see it being useful sometimes when you need to focus.
And countless more. If I could switch with a quick keyboard shortcut to a highlighting scheme appropriate for any given programming task, it would be phenomenal. I could see it being useful for all kinds of things, and helping to show more information from the compiler than syntax highlighting does already, in a better way. It would be instant visual information, and there's no reason to limit it to syntax like we do currently.
Hmm. Sublime Text Plugin perhaps?
> Variable-scoping-level highlighting—variables in the same scope highlighted the same color.
I played with this idea in the syntax highlighting of the code samples in this article: http://david.rothlis.net/c/compilation_model/#chapter005
but would you want all variables at the same scope in the same colour? Different colours for each variable, with the darkness/lightness indicating the scope?
> grep-only highlighting—define a set of things to grep for quickly and highlight them.
Emacs has this with the "highlight-regexp" command. To be honest I don't use it that much. What I do like is highlighting all matches whenever you're doing a "find in file" (though unlike highlight-regexp, the highlighting disappears as soon as you exit the search). I probably use this more because I use search all the time (who doesn't), whereas I tend to forget that "highlight-regexp" even exists.
> block-focused—highlight code blocks so you get an idea of the overall structure of your program.
A few examples of how this might look: http://web.archive.org/web/20080723220126/http://lemonodor.c...
> No-highlighting
In Emacs the "font-lock-mode" command will toggle all highlighting; and you can specify the "level" of highlighting you want by setting the "font-lock-maximum-decoration" variable (you could set up a specific key to toggle this variable). I think these levels were originally intended for performance reasons, so they're cumulative (enabling level 3 also brings in all the highlighting from levels 1 & 2) rather than individually-toggleable features.
I only bring up Emacs because that's what I'm familiar with, and because I'd like more people to experiment with these types of things in Emacs. But perhaps Sublime Text would be a better platform for such experiments, for some people; I don't know.
I played with this idea in the syntax highlighting of the code samples in this article: http://david.rothlis.net/c/compilation_model/#chapter005
but would you want all variables at the same scope in the same colour? Different colours for each variable, with the darkness/lightness indicating the scope?
> grep-only highlighting—define a set of things to grep for quickly and highlight them.
Emacs has this with the "highlight-regexp" command. To be honest I don't use it that much. What I do like is highlighting all matches whenever you're doing a "find in file" (though unlike highlight-regexp, the highlighting disappears as soon as you exit the search). I probably use this more because I use search all the time (who doesn't), whereas I tend to forget that "highlight-regexp" even exists.
> block-focused—highlight code blocks so you get an idea of the overall structure of your program.
A few examples of how this might look: http://web.archive.org/web/20080723220126/http://lemonodor.c...
> No-highlighting
In Emacs the "font-lock-mode" command will toggle all highlighting; and you can specify the "level" of highlighting you want by setting the "font-lock-maximum-decoration" variable (you could set up a specific key to toggle this variable). I think these levels were originally intended for performance reasons, so they're cumulative (enabling level 3 also brings in all the highlighting from levels 1 & 2) rather than individually-toggleable features.
I only bring up Emacs because that's what I'm familiar with, and because I'd like more people to experiment with these types of things in Emacs. But perhaps Sublime Text would be a better platform for such experiments, for some people; I don't know.
I write a lot of code on whiteboards or paper as well, but I could not bear to part with syntax highlighting. When you're off the machine, a missing quote or semi-color won't cause the whole thing to come crashing down. The same can't be said for when you're actually typing things.
As the author already mentioned, strings are really annoying to work with when you don't have syntax highlighting for them. I would group comments in the same category. It's difficult to see where they begin and end without the visual cues provided by syntax highlighting. That can quickly become a disaster.
I did try out going through code just now without syntax highlighting. New and short programs weren't bad at all, but going through files with hundreds of lines quickly became a challenge. This might work for the author, but it's not for me (nor, I suspect, for most people). Colors and font styling make it easy to get a grasp of what's going on. Taking that away does reduce noise, but cuts down far more on signal.
As the author already mentioned, strings are really annoying to work with when you don't have syntax highlighting for them. I would group comments in the same category. It's difficult to see where they begin and end without the visual cues provided by syntax highlighting. That can quickly become a disaster.
I did try out going through code just now without syntax highlighting. New and short programs weren't bad at all, but going through files with hundreds of lines quickly became a challenge. This might work for the author, but it's not for me (nor, I suspect, for most people). Colors and font styling make it easy to get a grasp of what's going on. Taking that away does reduce noise, but cuts down far more on signal.
I imagine that it has a lot to do with the language too. Things like Perl, Ruby or even shell scripts have a lot of syntax that benefits from syntax highlighting (I'd say most of them related to strings and string interpolation), while C maybe doesn't.
This is how that page looks like on my computer
http://i.imgur.com/x8kqM.png
Windows 7, Chrome 24.0.1312.2 dev-m
http://i.imgur.com/x8kqM.png
Windows 7, Chrome 24.0.1312.2 dev-m
for the article's author: try this before choosing a font, PLEASE: https://browserlab.adobe.com/ (yeah, it needs an adobe account that you can make in 2min, with no cc, but it's free if you don't exceed a daily usage quota)
...not everybody is using safari on a mac (and I eagerly await the days when people will start using fonts that are only readable on safari on a mac with retina display...)
...not everybody is using safari on a mac (and I eagerly await the days when people will start using fonts that are only readable on safari on a mac with retina display...)
I actually checked it in Xombrero on OpenBSD with no issue. To be honest, I hadn't expected anyone to read the article outside of people in the IRC channel, where practically no one is running Windows.
Yet another case of chrome's bad rendering.
The font used: http://www.google.com/webfonts/specimen/IM+Fell+English
Why would anyone try and use bad typewriter font imitation on a website is beyond me.
The font used: http://www.google.com/webfonts/specimen/IM+Fell+English
Why would anyone try and use bad typewriter font imitation on a website is beyond me.
Erm. It seems like the problem is not with Chrome's rendering but with the site owner's font selection.
It's not just Chrome.
I get just as awful a rendering on Firefox ESR 10.0.5 on Win7-64.
I get just as awful a rendering on Firefox ESR 10.0.5 on Win7-64.
More like Windows' bad rendering. It looks fine in my Chrome on OS X. A bit of a lame font but readable and not all flaky like the Windows screenshot linked by the original commenter.
Chrome renders fonts differently than other browsers in Windows 7. Possibly for speed reasons? Both the latest FF and IE9 look decent.
It's more historical at this point. Chrome doesn't use DirectWrite because it uses Skia on Windows. At the time, the choice was between GDI+ and Skia, and Skia was much faster. But DirectWrite on Vista and 7 is extremely fast (it's GPU-accelerated, unlike the Skia backend Chrome uses).
Looks fine in my win7/FF16 arrangement
[deleted]
It's his font choice. I don't agree with it either, but at least it's intentional.
Edit: Perhaps not. The font looks better on the link provided in the sibling comment.
Edit: Perhaps not. The font looks better on the link provided in the sibling comment.
Yep, seems to be having trouble on Chrome stable too.
I remember when I first started to program I used Notepad.exe to write the source in. It was all I knew at the time and it worked. The day I discovered a text editor that did syntax highlighting was amazing, finally I could see at a quick glance any obvious errors in my code as well as the structural elements. This is far too ingrained in my workflow to consider removing it but I may give it a try. When I do write plaintext I usually do it in a light colorscheme (Solarized Light) and it does read more like a book.
The author makes the argument that removing highlighting forces you to be more careful with the code you write. Removing three of my fingers would also force me to be more careful, but I'll take everything I can get to make me more productive.
The author makes the argument that removing highlighting forces you to be more careful with the code you write. Removing three of my fingers would also force me to be more careful, but I'll take everything I can get to make me more productive.
To each their own, but I'm having real trouble imagining that this could actually be helpful!
I'm sure it's possible to get used to, but I doubt I'm the only one that remembers when they first turned syntax highlighting on, and the difference it made to my productivity then.
I'm sure it's possible to get used to, but I doubt I'm the only one that remembers when they first turned syntax highlighting on, and the difference it made to my productivity then.
I'm always surprised when I meet folks who prefer not using syntax highlighting. At some point the surprise will go away, but for now it's still pretty darned rare. The first person I met who expressed a strong preference for no syntax highlighting was Matt Trout (mst here at HN), who is certainly productive enough to provide a compelling argument in favor of it.
I might even try it again one of these days.
I might even try it again one of these days.
I find it interesting that mst isn't into syntax highlighting as his main language (Perl) has string interpolation. Making sure that variables embedded in a string stand out can be important:
"Number of Records: $numrec\n"
"Number of Records: \$numrec\n"
"Number of Records: ${\ get_number_of_records() }\n"
"Number of Records: \${\ get_number_of_records() }\n"
my $string = <<" HEREDOC";
my $name = "Thompson";
HEREDOC
Perl is also my primary language, and it is partly why I like highlighting. It may state something about the opinions of the programmer; perhaps that complex interpolations in strings, among other things, might be a code smell they don't like, and avoid. Having no highlighting would remind you not to do that sort of thing.
I think the sigils alone are sufficient to flag variables in strings...but when things get complicated and span multiple lines, it can become ugly and difficult to work with. But, I'm not convinced this is the most useful function of highlighting in perl (again, because the sigils already provide visual clues)...it think it's more useful in pointing out unclosed parens, brackets, quotes, etc., and letting you know your syntax is wonky.
That said, it may be laziness on my part. I find it soothing to have highlighting enabled, and I get nervous when it's not, as I'm never quite sure I've got the syntax right until I check it.
I think the sigils alone are sufficient to flag variables in strings...but when things get complicated and span multiple lines, it can become ugly and difficult to work with. But, I'm not convinced this is the most useful function of highlighting in perl (again, because the sigils already provide visual clues)...it think it's more useful in pointing out unclosed parens, brackets, quotes, etc., and letting you know your syntax is wonky.
That said, it may be laziness on my part. I find it soothing to have highlighting enabled, and I get nervous when it's not, as I'm never quite sure I've got the syntax right until I check it.
It has been on my mind to write an Ask HN about syntax highlighting since I have seen a shift in people the last 15 years from preferring no syntax highlighting to preferring the Angry Fruit Salad[1] kind of highlighting.
Personally, I like limited syntax highlighting: I only highlight strings, comments and sometimes keywords (in Common Lisp). It lets me quickly separate the code in useful chunks and also highlights a common source of errors that I make (made): forgetting to close strings.
Here's a screenshot: http://imgur.com/rx053 (My Vim color scheme isn't quite there yet: the colors are too bright.)
[1] http://www.catb.org/jargon/html/A/angry-fruit-salad.html
Personally, I like limited syntax highlighting: I only highlight strings, comments and sometimes keywords (in Common Lisp). It lets me quickly separate the code in useful chunks and also highlights a common source of errors that I make (made): forgetting to close strings.
Here's a screenshot: http://imgur.com/rx053 (My Vim color scheme isn't quite there yet: the colors are too bright.)
[1] http://www.catb.org/jargon/html/A/angry-fruit-salad.html
I agree with the author that turning syntax off is like reading a book. When I read in English, I don't want to be bombarded with color or style changes that aren't completely necessary. I appreciate their function as an aid to recognizing patterns, but I've read enough so that I can glance at the entire page and recognize all the patterns I want in a few seconds. Now, when it comes to reading books in a foreign language (e.g. japanese or mandarin) it can be a tremendous aid while you're learning because it helps you make sense of where the breaks are in something that might otherwise take a considerable amount of time to break down bit by bit. As soon as you start getting used to it the patterns become obvious on their own, and the visual aids just become a layer of noise.
My main exception is comments, or footnotes on the side. At a quick glance it's very helpful to skim through a file and see what's documented or, if it's a text/config where each section break is.
Edit: after skimming the other comments here it seems that the preference for highlighting is more to do with error checking than anything (pairing enclosures, etc.). If that's the main concern then why not zap the rest and use syntax the same way you'd use spell? I don't use highlighting for much but I might just drop that into my vimrc tomorrow to play around with it. I would rather see glaring red blocks where there are mistakes than a minor variation in my digital bowl of lucky charms.
My main exception is comments, or footnotes on the side. At a quick glance it's very helpful to skim through a file and see what's documented or, if it's a text/config where each section break is.
Edit: after skimming the other comments here it seems that the preference for highlighting is more to do with error checking than anything (pairing enclosures, etc.). If that's the main concern then why not zap the rest and use syntax the same way you'd use spell? I don't use highlighting for much but I might just drop that into my vimrc tomorrow to play around with it. I would rather see glaring red blocks where there are mistakes than a minor variation in my digital bowl of lucky charms.
Syntastic for vim.
It's an interesting idea.
I've actually gone the opposite way recently. In the past, I'd only have code highlighting. Different parts of the syntax would be rendered as different colors--nothing surprising.
However, recently I've been writing a lot of Haskell and OCaml. At least in Emacs, both Haskell and OCaml have an additional option to syntax highlighting with color: your code can also be highlighted with symbols. That is, parts of the syntax are not only displayed in a different color but actually displayed as a Unicode character rather than ASCII. As a moderately contrived example, something like
I find the second snippet far easier to read than the first, especially if I'm just scanning over the code.
This is also a very good reason for using a typeface like Deja Vu Sans Mono: it can support all the symbols I could ever want. It's also very readable.
I personally find this, combined with syntax highlighting, extremely useful for reading code. Actually, thinking about this, I've found syntax highlighting even more useful for Haskell and OCaml than other languages, probably because they have very minimalist syntax. I really like the syntax, but the color does make the overall structure of any given function much more evident, which is nice.
Coincidentally, for the same readability reasons as above, I'm significantly warming up to Unicode identifiers. I think something like:
As an aside, the expression
However, if you're just scanning over the code, it might be easy to miss the backticks. Happily, in Emacs, operators get highlighted in a different color from normal identifiers. This includes things in backticks. So the `union` gets highlighted in a different color, making it obvious it's being used in an infix position.
I've actually gone the opposite way recently. In the past, I'd only have code highlighting. Different parts of the syntax would be rendered as different colors--nothing surprising.
However, recently I've been writing a lot of Haskell and OCaml. At least in Emacs, both Haskell and OCaml have an additional option to syntax highlighting with color: your code can also be highlighted with symbols. That is, parts of the syntax are not only displayed in a different color but actually displayed as a Unicode character rather than ASCII. As a moderately contrived example, something like
\ a b c -> a >= b && b <= c || a /= c
λ a b c → a ≥ b ∧ b ≤ c ∨ a ≢ c
I find the second snippet far easier to read than the first, especially if I'm just scanning over the code.
This is also a very good reason for using a typeface like Deja Vu Sans Mono: it can support all the symbols I could ever want. It's also very readable.
I personally find this, combined with syntax highlighting, extremely useful for reading code. Actually, thinking about this, I've found syntax highlighting even more useful for Haskell and OCaml than other languages, probably because they have very minimalist syntax. I really like the syntax, but the color does make the overall structure of any given function much more evident, which is nice.
Coincidentally, for the same readability reasons as above, I'm significantly warming up to Unicode identifiers. I think something like:
set1 `union` set2
set1 ∪ set2
set1 \cup set2
As an aside, the expression
set1 `union` set2
union set1 set2
However, if you're just scanning over the code, it might be easy to miss the backticks. Happily, in Emacs, operators get highlighted in a different color from normal identifiers. This includes things in backticks. So the `union` gets highlighted in a different color, making it obvious it's being used in an infix position.
I've become very used to this in Mathematica. That takes it a little further: Matrices look like matrices, greek letters are actual greek letters and division writes the parts as you'd see on paper - numerator over denominator. Any kind of mathematical code is vastly more readable this way. The way you access symbols is easy too: hit esc, type a short mnemonic, then hit esc again, for example esc-pi-esc gives you pi. Best of all, it's all stored as human-readable plaintext source under the covers. The display is just a convenience.
Can't wait for unicode identifiers and this kind of expression composition in general purpose languages like objc.
Can't wait for unicode identifiers and this kind of expression composition in general purpose languages like objc.
Languages like Scala have this sort of support for unicode built-in - many operators have Unicode aliases and it is possible for you to designate your own Unicode-named functions as well. There are some nice examples of meaningful syntactic sugar, like ⇒ for lambdas, ← for enumerators, and → for tuple building (all of which have =>, <-, and -> as ASCII equivalents).
The Fortress language (recently discontinued) really pushed the boundaries of using mathematical notation in a programming language. The "mathematical" version looked like the pseudo-code examples many CS textbooks use.
Lots of examples here
http://stephane.ducasse.free.fr/Teaching/CoursAnnecy/0506-Ma...
Lots of examples here
http://stephane.ducasse.free.fr/Teaching/CoursAnnecy/0506-Ma...
Rust's syntax file for vim (and I assume emacs) does the same thing per default. It's quite nice, except when you rely on X's copy paste, which going to blindly copy the unicode characters.
> in Emacs, both Haskell and OCaml [...] can also be highlighted with symbols
And not just Haskell and OCaml: See for example https://github.com/drothlis/pretty-symbols
(though of course Haskell and OCaml might be much more suited to this kind of visualisation -- in python, say, you just get λ ≠ ≥ ≤).
And not just Haskell and OCaml: See for example https://github.com/drothlis/pretty-symbols
(though of course Haskell and OCaml might be much more suited to this kind of visualisation -- in python, say, you just get λ ≠ ≥ ≤).
This is amazing! Any idea if this is possible in vim?
Without changing the order of symbols, you can at least display some symbols as unicode with vanilla Vim. Here's an extract of my Lisp Vim config, which replaces lambda by λ :
set conceallevel=2
syntax keyword lispFunc lambda conceal cchar=λThe best way I know to do it for Haskell is to use haskellConceal ( http://www.vim.org/scripts/script.php?script_id=3200 ), it display unicode characters but left the underlying ASCII untouched.
There seems to be a plugin called unicode-haskell[1] for Vim. However, as I am obviously not a Vim user, I don't really know anything about it.
[1]: https://github.com/frerich/unicode-haskell
[1]: https://github.com/frerich/unicode-haskell
Thanks this is exactly what I need, should make coding in functional languages a lot more readable. Actually it appears GHC supports the use of unicode characters for operators via packages and an extension[1], if it wasn't for your post I would not have discovered this, cheers!
[1]: http://www.haskell.org/haskellwiki/Unicode-symbols
[1]: http://www.haskell.org/haskellwiki/Unicode-symbols
I wouldn't recommend using that one. There is a newer plugin [1] that uses "after" in combination with conceal syntax to achieve the same effect but without buffer hacks on load/save.
[1] https://github.com/vim-scripts/Haskell-Conceal
[1] https://github.com/vim-scripts/Haskell-Conceal
Haskell-Conceal also works a lot better than unicode-haskell: it doesn't erroneously turn "\n" into "λn", and it replaces :: with a single-glyph equivalent so that signature and definition line up nicely.
Having said that, I still prefer <- and -> to ← and →, at least on screen: those Unicode arrowheads are too small on all the fixed-width fonts I've ever seen.
Having said that, I still prefer <- and -> to ← and →, at least on screen: those Unicode arrowheads are too small on all the fixed-width fonts I've ever seen.
Those arrows are indeed pesky. In my fixed-width fonts (at least at the font size I'm using), → (->) and ⇒ (=>) look the same.
Seems I should've refreshed before posting (now deleted)! As you can see from the plugin file, applying the maps isn't all that complicated, though it certainly would be nice to have it built in. I'm not an emacs user, but I seem to recall using this feature before... anyone know if TextMate had this implemented?
[deleted]
Combining :abbr and conceal could indeed reduce quite a lot of verbosity from JavaScript for instance.
This:
> set1 ∪ set2
Looks good until someone confuses it with:
> set1 u set2
Having two characters that are similar enough to be confusing is bound to cause problems.
> set1 ∪ set2
Looks good until someone confuses it with:
> set1 u set2
Having two characters that are similar enough to be confusing is bound to cause problems.
Interesting. I've done a fair amount of coding without syntax highlighting, particularly on live web servers (gasp) without my vimrc.
What I find is that I don't really rely on syntax highlighting for find my way around the code or understanding it. I rely on it to tell me when I didn't properly close a string literal, or a comment, or fat-fingered a keyword. So, I generally enable it when I can, and find that it makes me more productive.
What I find is that I don't really rely on syntax highlighting for find my way around the code or understanding it. I rely on it to tell me when I didn't properly close a string literal, or a comment, or fat-fingered a keyword. So, I generally enable it when I can, and find that it makes me more productive.
When you read a book you do not need to be consciously aware of the syntax (unless it is either patently bad or extraordinarily original). When you are programming, most of the time you are dealing with syntax more than meaning...
In the end, what the logicians of the XXth century taught us is that logic (read maths/cs/...) is just syntax (from the formal point of view, mind you).
In the end, what the logicians of the XXth century taught us is that logic (read maths/cs/...) is just syntax (from the formal point of view, mind you).
Perhaps when you're writing code, you are using it as a crutch. (I'm not one to know, really)
However, I certainly feel when I am reading someone elses' code, it is not a crutch but a tool. The highlighting helps me see an unfamiliar program's structure just a little more easily, which is nice when you're absorbing a couple hundred lines with sparse comments.
However, I certainly feel when I am reading someone elses' code, it is not a crutch but a tool. The highlighting helps me see an unfamiliar program's structure just a little more easily, which is nice when you're absorbing a couple hundred lines with sparse comments.
While I read a book I take notice of headers providing logical partitioning, page headings & numbers for orientation. On paper text may also be set with bolder font, or with emphasis added. It helps, when done properly. Same with syntax highlighter. I don't want to re-read entire screen of code every time I need to make a change in this general area. I want to have mental model "indexed" upon the looks of code. This can of course be done on "plain" code, but it's slower and I can only hold my attention for so long each day -- why waste it, especially if I need to specifically disable some features of my software? And lastly -- code is not a book. I will read a book once, maybe twice if I really like it (my max being 8 repeats), but there is never time to read it again. While code? I will be read it for the rest of my life, as far as I can tell... I will not enjoy reading everything for a 1000th time, that much I know.
May just be the case of a bad luck or not fidgeting enough with trying to find a colorscheme to one's taste. I have several colorschemes - not ideal, but decent enough to love and use - that I switch between depending on room lightning and language.
Book comparison is far-fetched imo. Code is not just a regular text, it's a very structured text, and reader of a structured text benefits from structure hints (expressed via color and identification), while writer of such a text benefits even more from on-the-go error checking. Looking through a dictionary without any bolds, italics and structure, just paragraphs and paragraphs of text, would be a waste of time and a pain to the eyes. And this is what I tend to do about 95% of time when 'writing' code - looking at it.
I would recommend searching for a less contrast or vibrant colorschemes like popular Solarized (too low contrast for me actually) or Tomorrow themes.
Book comparison is far-fetched imo. Code is not just a regular text, it's a very structured text, and reader of a structured text benefits from structure hints (expressed via color and identification), while writer of such a text benefits even more from on-the-go error checking. Looking through a dictionary without any bolds, italics and structure, just paragraphs and paragraphs of text, would be a waste of time and a pain to the eyes. And this is what I tend to do about 95% of time when 'writing' code - looking at it.
I would recommend searching for a less contrast or vibrant colorschemes like popular Solarized (too low contrast for me actually) or Tomorrow themes.
There are more options than just "monochrome" and "syntax highlighting": For example, Xcode 4 assigns all identifiers taken from the current project a greenish colour whereas everything else (system headers/frameworks) are shades of violet. I just wish it would understand that CocoaPods are not project code :(
Another example, TextMate highlights some syntax errors much more than it highlights syntax- type "else if" in a Ruby file and it's bright red. How is that not useful?
My love for syntax highlighting probably goes hand in hand with my love for natural language operators. "if foo and bar then qux" is much harder to parse without colours than "if (foo && bar) qux". Does anyone use a monochrome editor and natural language wherever possible?
Another example, TextMate highlights some syntax errors much more than it highlights syntax- type "else if" in a Ruby file and it's bright red. How is that not useful?
My love for syntax highlighting probably goes hand in hand with my love for natural language operators. "if foo and bar then qux" is much harder to parse without colours than "if (foo && bar) qux". Does anyone use a monochrome editor and natural language wherever possible?
I used to not like syntax highlighting, but then I started writing more complex, lengthier code in a variety of languages.
Instant feedback for error checking aside (which is incredibly useful) I like the "texture" syntax highlighting adds to the code.
Indentation is great for organizing code into individual chunks, but if it's all the same color, I find that it still starts to feel a little overwhelming when the code starts getting long. Colors help create a visual flow and, at the very least, break up the monotony, thus prevent the "wall of text" effect.... which is fine for a book, but source code isn't a book. It doesn't function like a book, you don't interact with it like you do a book, so it really shouldn't look like a book.
Instant feedback for error checking aside (which is incredibly useful) I like the "texture" syntax highlighting adds to the code.
Indentation is great for organizing code into individual chunks, but if it's all the same color, I find that it still starts to feel a little overwhelming when the code starts getting long. Colors help create a visual flow and, at the very least, break up the monotony, thus prevent the "wall of text" effect.... which is fine for a book, but source code isn't a book. It doesn't function like a book, you don't interact with it like you do a book, so it really shouldn't look like a book.
I started out writing code in Emacs, with highlighting turned on. I loved it and couldn't deal with an editor that didn't have highlighting. At some point, I started using Acme a lot for working on Plan 9. I ended up doing a bunch of work on a variety of Unix boxes, and it was simpler to just use Vi without highlighting than to set it up everywhere. I got used to not having it, and realized I was pretty happy without it.
Plus, it always seems that whether I have light-on-dark or dark-on-light terminals set up, one of the colors is so off that e.g. strings become essentially invisible (dark blue text on black background) and it's easier to just shut off highlighting than to fix the highlighting.
Plus, it always seems that whether I have light-on-dark or dark-on-light terminals set up, one of the colors is so off that e.g. strings become essentially invisible (dark blue text on black background) and it's easier to just shut off highlighting than to fix the highlighting.
Interestingly there is something like syntax highlighting in natural language too. One example is that all nouns in German are capitalised which helps a lot in the context of ambiguity. To give you an idea of a case in which it actually might help:
A point that could be made is that (written) language evolved for a long time and the concept of "syntax highlighting" is embedded in at least some of them. Probably because it has proven useful.
The complex houses married and single soldiers and their families.
The Complex houses married and single Soldiers and their Families.
A point that could be made is that (written) language evolved for a long time and the concept of "syntax highlighting" is embedded in at least some of them. Probably because it has proven useful.
First hardcore developers where shifting from IDE's to vi and emacs. Now hardcore developers are turning off syntax coloring? What' next?
Hardcore developers will start using ed. It allows you to focus on one line at once, with none of the distracting "context" of screen editors.
[deleted]
I did the same several weeks ago at work. I turned off syntax highlighting in XCode for doing objective-c coding. More specifically, I created a theme with all the same color: http://dl.dropbox.com/u/68874506/Screenshots/xcodeterm.png
I'm used to coding in terminal screen sessions, and using an IDE is a bit too shiny for my liking so I created my own terminal for XCode :) Now when I look at my co-worker's color-coded ruby code in Sublime Text it looks like a bunch of unreadable rainbows.
Colors are pretty, but since I turned them off I found that I haven't missed them. They turned out to be distracting, and I can't remember a situation where the colors helped me scan the code faster to help me find something. One color means I now treat all tokens equally.
I'm used to coding in terminal screen sessions, and using an IDE is a bit too shiny for my liking so I created my own terminal for XCode :) Now when I look at my co-worker's color-coded ruby code in Sublime Text it looks like a bunch of unreadable rainbows.
Colors are pretty, but since I turned them off I found that I haven't missed them. They turned out to be distracting, and I can't remember a situation where the colors helped me scan the code faster to help me find something. One color means I now treat all tokens equally.
Can I suggest trying a light grey font on that dark background, or even better (in my experience) black on white or very mild yellow (see Acme). In my experience, when I use green on black too long, I see purple when I look away.
What I found an interesting development in syntax highlighting is "semantic highlighting". Some IDEs support this by integrating directly with a compiler (such as clang).
At a primitive level it allows, for example, coloring nams of variables either by type, or by source (local/field/static field), same with function names (ie, is it a function, method, a static method, etc). See for example: http://doc.qt.digia.com/qtcreator/creator-highlighting.html.
But I'm sure much more is possible. Semantic highlighting could help understand the (non-local) semantic structure of the code, and allow finding mismatches between what the user intends and what he has specified.
At a primitive level it allows, for example, coloring nams of variables either by type, or by source (local/field/static field), same with function names (ie, is it a function, method, a static method, etc). See for example: http://doc.qt.digia.com/qtcreator/creator-highlighting.html.
But I'm sure much more is possible. Semantic highlighting could help understand the (non-local) semantic structure of the code, and allow finding mismatches between what the user intends and what he has specified.
http://www.linusakesson.net/programming/syntaxhighlighting/i... here is another one advocating the same thing.
I write code with syntax highlighting turned off. Syntax highlighting has always given me the shits - it's noisy and distracting and I don't need it anyway.
The only time I :syntax on is if I get a parse error and can't find the culprit quickly, and it's probably a problem with string being constructed incorrectly (I mostly work with PHP so something like 'and that's that';). In that case having the syntax highlighter to tell me where the string interpolation goes awry is very useful, but I turn it off again once the problem is fixed :)
The only time I :syntax on is if I get a parse error and can't find the culprit quickly, and it's probably a problem with string being constructed incorrectly (I mostly work with PHP so something like 'and that's that';). In that case having the syntax highlighter to tell me where the string interpolation goes awry is very useful, but I turn it off again once the problem is fixed :)
This idea strikes me as appalling, but I'm trying it. I turned off syntax in vim just to see what it was like. I toggled back and forth a couple of times and found the syntax highlighting valuable, but without syntax highlighting it was still readable.
Now I've turned off syntax highlighting in vim and zsh and my irc client. Just to see what it's like. Will try it for a few days.
Now I've turned off syntax highlighting in vim and zsh and my irc client. Just to see what it's like. Will try it for a few days.
The choice of font for the blog's body text doesn't lend the author any credibility on this topic.
For what it's worth, I tried both syntax highlighted and not - and the former results in a measurable improvement in productivity. I believe experimenting with tweaking one's tools is worthwhile in most cases.
For what it's worth, I tried both syntax highlighted and not - and the former results in a measurable improvement in productivity. I believe experimenting with tweaking one's tools is worthwhile in most cases.
I have wondered for some time whether syntax highlighting really adds anything. Intuitively, it ought to . . . but has anyone ever tested this rigorously? I'll give it some anecdotal testing tomorrow and see if I regret it.
See this code:
<%= render partial: 'user, collection: @user.followed_users %>
Ah, my editor has separate error highlighting, so I don't have to forgo that immediate feedback to turn off syntax highlighting.
at least for me, it makes code a lot more pleasant to read. there is the instant feedback for minor syntax errors, of course, but even apart from that the pleasantness aspect is more than enough to justify it.
Lol. That can come only from someone who actually uses vim when something like Emacs exists.
http://ycombinator.com/newsguidelines.html
Please avoid introducing classic flamewar topics unless you have something genuinely new to say about them.
Please avoid introducing classic flamewar topics unless you have something genuinely new to say about them.
Clean code is all about structure. Anything that help show structure, symmetry, hierarchy, or other patterns is bringing your reader one step closer to understanding. The difference between a keyword and an identifier is part of the program's structure. Coloring it makes it visual.
Also, properly-implemented syntax highlighting is essentially a very short feedback loop with the compiler that shows you how your code is actually being parsed. Short feedback loops make creativity easier (this is the basis of a lot of Bret Victor's work).
I agree with the author that "paying attention to what the code is doing instead of the individual elements" is important, but I don't think you have to turn off syntax highlighting to achieve this. At least I don't personally. If the colors are distracting, one idea might be to make them more muted so that they don't demand as much attention. But to me there's no going back from being able to see visually that you forgot to close a string or parenthesis, or include a proper line continuation for your macro.