I am using the Mac OS X terminal.
Most of the default color schemes I try in vim use terrible red colors for my JavaScript code.
Most of the code appears red. Does anyone know how to set the colors for JavaSript files in vi?
Whatever you do with custom syntax files and colorschemes will be useless if you don't tweak the color settings of Terminal.app and/or switch to iTerm2 or MacVim.
Most colorschemes are made for the GUI versions of vim or for vim running in a terminal that supports 256 colors.
Terminal.app only supports 16 colors and the basic colors are horrible, you can tweak them with TerminalColoreopard but you still have only a very limited palette to work with when tweaking your colorscheme.
So, that's one part of the problem.
Another one is probably that your document's filetype is set to html which prevents you to have good JS syntax highlighting and proper omni completion. You can change that by typing :set ft=html.javascript.
The last part of your problem is that you use inline JavaScript.
--- EDIT ---
It's 2016, now, and Terminal.app has no problem whatsoever displaying 256 colors so there's no need for that "TerminalColoreopard" hack anymore.
--- ENDEDIT ---
I've modified 2 files to fit my javascript workflow.
Yi Zhao's Javascript syntax: I've added AJAX, DOM keywords, methods and others.
ir_black: I called it Nazca, and it has some lines combined with with my syntax makes the js files look a lot better than the stock syntax.
Please check them out, they are not perfect but if you can fix it, add more features, please share.
UPDATE: Modification to your colorscheme is no longer required since the new version of the script hilinks all the new introduced highlights to existing keywords. Follow it in github
This question is a lot like this one:
Javascript syntax highlighting in vim
Related
So I've come across some interesting JS comment syntax in the past (e.g. /*! for minifiers, * on new lines in block comments, encapsulated string literals, etc) but recently I've been seeing more of //* to start off comments.
After trying it out in my editor, I discovered many popular themes actually highlight these comments in special colors to stand out to the user. Naturally I use it to signal more important notes and method specifications, but I'm wondering what the actual usage of //* comments is. Does it actually signal anything to some software (like a minifier?) or is it safe to use as a stylistic choice?
Here is an example of what I mean:
// normal comment
//* would be some accent color in many editors
FWIW this does not occur with slash-star (/*) block comments, but there is an accent color present on new lines within the block comment that begin with *, although this is more of a standard styling choice so I don't believe they are related.
It is just to highlight an important note
https://marketplace.visualstudio.com/items?itemName=aaron-bond.better-comments
I understand JavaScript. But I know what the red, yellow and purple colorized text means in ATOM.
I guess those are grouped by specific JavaScript data but I'm not sure.
Do the colorized codes have any other meaning beside readability?
I would like to get some articles to learn about those if I could.
Thanks
(I didn’t change anything. From the picture this is the default code colors when you downloaded and start ATOM for the first time.)
Yes, it is purely aesthetical and doesn't change a thing in your actual code. It just makes it easier to read while you're programming.
The keyword here is syntax highlighting. There are many color schemes out there to help you getting a faster overview over your code.
You can also change the color palette in ATOM's settings if needed.
I am working on a WYSIWYG editor. As it has to include just some basic functions I want to do it myself and avoid problems. Now it is working perfectly but I want to add a functionality in order to unbold, unitalic...
I know that with execCommand it is an automatic thing, but it does not work in the same way in all browsers so... my idea was the next: When pressing BOLD button, check the environment of the string, and...
If the selection is Between the open and close <b> tags, like <b>ab||selected||cd</b> replace selected with </b>selected<b>.
If the selection starts or finishes with the <b> tag, like <b>ab||selected||</b> replace it by </b>selected<b> (and then strip out all <b></b> groups.)
If the selection starts and finishes with the <b> tag, like <b>||selected||</b> replace it by </b>selected<b> (and then strip out all <b></b> groups.)
But... how can I get into a var the <b>content</b> string when just having the caret/selection IN content? It might be possible...
UPDATE
It is curious that the replacement is always the same. So, should I really get what I am asking for, or just replace it in this way, always?
I am working on a WYSIWYG editor. As it has to include just some basic
functions I want to do it myself and avoid problems. Now it is working
perfectly but I want to add a functionality in order to unbold,
unitalic...
Do not write your own WYSIWYG editor.
Do you really want to "avoid problems"? Then use one of existing good editors (there're only 2... maybe 3 in fact). Creating editor is extremely hard task for which you need a lot of time (I mean... few years), a lot of knowledge and patience (a lot of too :P).
I can myself write that "I am working on a WYSIWYG editor". For more than half of the year I'm a core developer of one of these "good editors". And during this period I implemented only one feature - very important and very complex, but one of tens/hundreds of them.
That problem you have... I don't even want to start answering. It sounds like a piece of cake, but it isn't. It's a piece of brick that can kill you when fall on your head :). I'll only start enumerating important parts of the impl: Selection + range implementations, because native differ and are buggy (~5k LOC + min Nk LOC for tests). Then you need the proper styles handling (applying and removing) impl (min 1k LOC + tests), because you have to take care about styles spanning on many blocks (like entire table bolded) and different selections containing parts or entire styles etc. And you have to avoid native execCommand, because they will break your content. Then you should also think about updating toolbar buttons states and, to make your impl bullet proof, handling different style tags (e.g. pasted). And that's only the tip of an iceberg - you'll have styles handling, but hundreds of other things broken. Things that big editors have fixed.
Anyway - learn config options for one of main editors and customize it as you want. This will take you a few hours, not a few years.
by simple I mean, having buttons:
bold,
italic,
numbered list
bullet point list
indent left
indent right
spell check (obviously supported by ready made js component)
by custom I mean: having custom icons - so really just custom design
no frameworks, written from scratch, lightweight, compatible with major browsers
this is one of the main components of the webapp, so it has to be super lightweight, that's why I don't want frameworks
Unless you are targeting one browser, editors are immensely complicated components to get to work cross browser. There's no reason to do it yourself, unless you want to learn.
Use one of the many available that allow customization:
tinymce,
fckeditor,
wysihat,
others
Writing an editor that works cross-platform can be difficult, but, you should create your own framework as you do it, as it is a large project.
If you just want custom icons, that will depend on how long it takes you to make them, but, to get some basic functionality isn't that hard, probably less than 40 hrs of work if you know what you are doing.
In Unix writing your own shell used to be a rite of passage, in javascript it may be writing your own editor. :)
Where it gets tricky is if I have
<b>some text</b><i>more text</i>
and I decide to remove the tags from this text, then how to fix it will get tricky.
If you want to use only css then it gets to be more of a problem as you are grouping text from span tags, and fixing css classes, while the user is continuing to make changes.
I am dealing with this currently as I want an editor that works in XHTML2.0, and it is not a trivial issue, much harder than it is to do in a desktop application.
I would suggest getting it to work on Firefox 3 and Safari first, then, once it is working, go back and add in the code to get it to work on IE8, and if you want IE7, since MS is pushing IE8 out as a critical update now.
Don't.
Go get something else (any of those Jason mentioned, or e.g. what SO itself uses, WMD). Swap out its images. The end.
Seriously you don't want to write your own editor unless you have a very good reason for it functionally, not just what it looks like.
Read through the first chapters of the emacs tutorial, and you will see that there is not anything like a "simple" editor. But google will give you lots of easy customizable editors.
I'm looking for examples of processing.js working in Internet Explorer via ExplorerCanvas or similar.
It can be done! There are some gotchas, however. The page htxt links to is fine, as far as it goes, but please note the following:
1) Both script and canvas elements must have id attributes. The init function uses these attribute id's to associate a given script with a given canvas. I found the simplified init function easier to understand than the official one. You will want to master the official one if you have multiple canvases on one page.
2) If you use internet-style color designations, like #23ff9a, watch out! IE 8 wants all upper case hexadecimal color numbers from Processing.js/canvas. Write #23FF9A! This is what the documentation shows, so it shouldn't be a complete surprise. The error is a sometime thing, which makes it crazy to figure out. Mostly, larger numbers (for lighter colors) with lots of f's seem to be afflicted. White, #ffffff, is OK, but #ff00ff is not. Firefox and Safari are case-insensitive in this regard. The documentation says you can use an alternate hex notation with alpha channel (the CC) that looks like 0xCC006699. This didn't work for me; maybe it's on the to-do list.
3) The .equals() method on strings is missing! Andor Salga, one of the Seneca College crew working on Processing.js, wrote a simple boolean stringsEqual(str1, str2) function you can see here. This will do until the matter is definitively fixed.
4) It's not true that stroke() doesn't work with excanvas.js. It does. However, if your Processing.js code has even one little syntax error (I can't really categorize which kinds, but trying to use .equals() will do it) your routine will probably fail silently in IE8, whereas, in Safari or Firefox, your rectangles may lose their outlines, i.e. stroke() will quit working. IE on Vista, and Safari on the Mac, have both exhibited stronger syntax checking than Safari or Firefox on Vista, which will blow by certain errors and render a defective graphic.
5) Text, invoked using the text() function, renders in Firefox (in an unchangeable font of Firefox's choosing), but, as far as I can tell, not in IE8 or Safari. The Glyph Method is suggested here. The code is in place, but getting the fonts looks like a problem. Inkscape looks pretty impenetrable to me. As far as I can tell, what is needed is a lot like old pen-plotter fonts - a vector path with pen-up and pen-down commands between runs of nodes. Turns out FSF/GNU has some that might be massaged into the right format without too much trouble. I don't know where the format is defined, but it's probably over at W3C somewhere. The approach with real potential for presentable fonts is the IE/VML wing of Cufon. See How does it work? I really want this last link in the chain, but I could use some help.
Processing.js is one whale of a project that deserves our support. It has enormous potential. I would encourage you to pitch in if you are able.
The sparklines example on the processing.js exhibition page uses ExplorerCanvas. It seems like it's just a drop-in solution, no extra coding necessary.
This page describes how to get processing.js + excanvas working together.
It basically involves writing your own onload init method that IE can understand.