Syntax highlight in Vim

[ilSignorCarlo]

Hi,
I like the Vim editor and I'd like to use it efficiently with ChucK.

On the wiki page I've seen there is a syntax file to download (Ck.vim). I've followed intructions, but it doesn't seem to work.

I have Vim 7.1.
I put the file in this directory:
copy this file into /usr/share/vim/vim71/syntax

Then it says to add the following line in /usr/share/vim/filetype.vim,

au BufNewFile,BufRead *.ck setf ck

I didn't have such file, so I created it. But nothing happened.

I still see the code black on white, which is my default colour scheme. There is no auto indentation.

Any idea?

Thanks,
Carlo

[Yellow Onion]

[ilSignorCarlo]

[Yellow Onion]

I'm kinda new to vim my self, but I would probably try turning on C-style indending

[Slinky]

[zynthetix]

IMHO, the vim editor is the opposite of efficiency when used in context of the modern computer. It's an editor that was designed for and rooted in computers that did not have mice, windowing systems, or even computer monitors in some cases (teletypes in the ed days).

If you're on Windows, I'd recommend trying notepad++ or even gVim.

If you're on a unix-like system such an OSX or Linux, I highly recommend the acme editor from Bell-labs. All of those pesky commands and modes from vim are amazingly replaced with simple use of the mouse.
You can get it by installing the plan9 tools:
http://swtch.com/plan9port/

As for syntax highlighting, if you're familiar with photography, you know that black-and-white photographs enable the human mind to focus more the subject of the photograph since there is no color to distract the mind with.

Due to a similar effect, I recommend trying to code without syntax highlighting. You will be able to catch small errors better since the code will be more readable. It will also be less hard on your eyes for longer hours of time.

Also, a friendly disclaimer, but I am not looking to get into an editor/holy war here with anybody. Use what you feel like using. The prior statements are just my opinion after using lots of different tools and workstations extensively for a day job, etc.

[Slinky]

[zynthetix]

This is what acme looks like in full screen mode. I am running it on OSX, note that you can't see the menu / dock when in full screen mode.

Acme is split into 2 columns. You can make windows within these columns and treat them as text editors or terminals. This is sort of like split windows in Vim. I usually work with code in the left column and directories and terminals on the right column.

Every piece of text visible can be clicked on and executed using different mouse buttons. There is no equivalent to this in other editors. Right clicking opens folders or files or finds the next occurrence of the text you clicked. Middle clicking any text executes it as if you typed it on the terminal.

To give you an idea of the work flow , the top right window is the first one that was open (as specified in a my rc file). The contents of this window is a listing of the directory you see specified in the header of the window. From there, I right clicked on 'audio_midi_test.py' in the directory listing. That opened the window you see in the left column. I also right clicked on the text 'test.py', which opened the window below it in the right column.

After that, I wrote the words "python" and "wav_test1.wav" around the text "test.py". (It is the highlighted text.) I then highlighted it with my middle mouse button (which executes text) and it ran created the terminal window in the bottom right corner and ran "python test.py wav_test1.wav".

I'm not sure my explanation is very thorough or good. There are some good tutorials in the documentation in my plan9 link above. It would take some reading to get familiar with acme, but it requires a fraction of the reading and memorization that an editor like Vim or Emacs does.

---

Picture 2.png
Description:
Filesize:	96.4 KB
Viewed:	429 Time(s)
This image has been reduced to fit the page. Click on it to enlarge.

---

[zynthetix]

to better illustrate, here is a comparison of Vim and acme ways of doing things off the top of my head:


Vim - moving around:
h, j, k, l, w, b, $, ^, arrow keys, etc.

acme - moving around:
click where you want to be with the mouse

Vim - page up / down:
ctrl-d, ctrl-u, ctrl-e, etc.

acme - page up / down:
up and down arrows, scroll wheel


Vim - split pane:
<esc>:sp

Acme - split pane:
Middle click the word 'New' anywhere you can see it or type it

Vim - switch between panes:
Ctrl-WW

Acme - switch between panes
hover your mouse cursor to the pane you want

Vim - execute shell command
<esc>!r <command>

Acme - execute shell command
type and middle click any text you want to run on the shell

Vim - copy and paste text:
set mark (ma), move to location (see above), set another mark (mo), <esc>:'a,'od, move to location, paste text (p). Alternatively, you could use visual mode, but I'm not getting into that.

Acme - copy and paste text:
drag select text, then middle click. You have cut the text. Click where you want to paste the text and press right mouse button at the same time. You have pasted the text.

This list goes on and on. It's amazing how a mouse and 3-6 different ways of clicking on things replace dozens of esoteric text and key commands.

[Kassen]

I do find that for programs I use a lot (sound editors, text editors, web browsers....) I'll slowly shift from using the mouse a lot to gradually using more and more keyboard shortcuts; while programming I only very rarely use the mouse, in SoundForge I sometimes use it, on the web I still use it a lot.

I too, BTW, recommend Notepad++ which I found supports that exact development in usage very well at every stage so there is no real disagreement there. I do feel that keyboard shortcuts only look "esoteric" if you need to learn a few dozen at once (I'm looking at you here, Emacs), when you can simply look up one every time you notice you use that command often I found I hardly noticed the learning curve. That's just a note on my own usage, not some great universal truth. I'm not interested in editor wars at all either though I do like to hear about the advantages of different ones (and have actually been trying to get into terminal-mode Emacs because I do suspect it might end up being faster for me in the end).

[Antimon]

Acme looks interesting. I personally feel that we need to advance beyond the mouse before I'll start to forget about keyboard shortcuts - the mouse is to much of an extra roadblock between my brain and the computer. I have great hopes for touch screen, once it becomes more cheap and generally available.

/Stefan

[Slinky]

The Acme concept sure looks interesting. And I like the very minimal window manager theme, looks something like Ion or Ratpoison.

But to me the mouse really gets in the way. It breaks my focus and "flow" of using the computer. It's like a minor context switch in task processing, something like someone interrupting ever so often. That's why I like Vim. It's second nature by now. Copy-pasting is esc-v-move cursor to the end of the area-y-move cursor to new place-p. By the time I take my hands off the keyboard and grab the mouse, I'm basically done with copying and almost with pasting.

The focus-issue is also why I can't use high-contrast screen when coding, dark backgrounds with syntax highlighting work best for me. But that's just me.

Anyway, I say: let each use the tool they are most efficient with! "The best tool for the job" is the key. And how does one find these new tools? Through discussions about editors etc., those are often quite heated ones, but that must not always be the case

[zynthetix]

In response to the "mouse getting in the way," I know exactly where you guys are coming from. I increased my productivity on the keyboard a lot by learning the Dvorak keymap in addition to the Qwerty keymap for touch-typing. I also hacked a lot of the scripting language called "autohotkey" over the past couple years to speed up my productivity with macros.

Despite all of that, I gave acme a shot. I ran out of major things to learn from unix and it's tools, so I decided to really dig into it's successor. After all, I reason that the guys who either directly made these editors or heavily inspired them might have a good shot at improving the concepts after some 30+ years of using them.

Here is what they have to say about their new tools requiring mouse use:
http://netlib.bell-labs.com/wiki/plan9/Mouse_vs._keyboard/index.html

Here is an exceprt:

[Kassen]

Interesting, but I'm sceptical. To me these texts seem to ignore that in practice mouse operations will be interspersed between regular typing. It also seems to focus on word processors; not text editors. Personally I never print anything and leave layout to professionals so I have no use for word processors at all. I'm doubly sceptical about this because it's apparently the result of Apple's research into interfaces. I recognise that many people like Apple's interfaces but for me they simply don't work.

I'm especially sceptical about graphical interfaces for musical applications. I find I can listen to music in more detail with my eyes closed which was one reason to abstain from using graphical feedback at all in my own sequencer but before that I was already using things like wave editors with my eyes closed, using hotkeys. With the mouse you will always have to look at the screen, making you listen in a different way.

Interestingly on a different page ( http://www.asktog.com/columns/035SquanAdv.html ) the same guy says;

[Inventor]

Hmmm, I'm not going to jump into the fray of whatever this thread is about, I just wanted to chime in and say that I like vim a lot. I use it to edit HTML and Perl source, and it's to me kind of nostalgic. I like it if only for the nostalgia of it. For ChucK I use miniAudicle though. Now back to whatever this thread is about... (I should have read it but hey, it's late and I'm tired)...

[Kassen]

Last night I thought about the linked articles some more.

This finding (about replacing "|" with "e") is really quite interesting. One thing I tried is how long the same replacement would take me. For a screen worth of text, using just the keyboard to navigate the menu of the standard Gnome Texteditor that's under 10 seconds. Of course I cheated and used the build in search&replace.

I know that's not "fair" but it does point out that this test is rather synthetic, it's really quite rare to have to replace many instances of a single character with a another single character. Most notably; entering a single character many times over can easily be done with a single finger on the keyboard. I wonder what would happen if instead of that the test would involve the need to enter a short function, including characters that need modifiers to type and indentation. If we do assume that it takes 2 seconds to locate the mouse, how many does it take to move the hand back?

I also noted that this test only compared between using the cursor keys and the mouse yet didn't go into page-up/down keys, the influence of the keyboard repeat-rate/delay settings or "jump to line" commands. For larger files, if we know what line we want to jump to (for example because of a error we got) I find it quite hard to believe that the mouse will be faster.

He rightly points out that higher level commands will take more mental overhead as well, taking some time off their usefulness but clearly that's sometimes a fair trade, for example in the case of a command to replace hundreds of letters with a different character.