Talk:Working with CSV files

Name of tip

I'm wondering about the title "Navigate large CSV files more easily". It's not just large CSV files where this is handy, and I generally try to avoid weasel words like "more easily".

What do you think about renaming it to "Working with CSV files"? Any other ideas? --JohnBeckett 02:00, 13 July 2008 (UTC)

I would support changing the name to "Working with CSV Files". I think it captures the features of this tip better. Also it leaves room for future improvements. -- lpr612

I have renamed it. --JohnBeckett 12:02, 19 July 2008 (UTC)

Featured tip

Congratulations folks! The tip is magnificent, although if the script gets much longer it will need to be made a plugin on vim.org (I'm resisting the tempatation to make it handle tab delimiters, which wouldn't be too hard now we have GetExpr()).

I'm going to feature this on the Main Page, probably in August. --JohnBeckett 02:00, 13 July 2008 (UTC)

---

Yep, this tip has progressed very well, and it now has a quality that would warrant uploading to vim.org. The big disadvantage of vim.org is that only a single owner is able to upload new versions, and if that owner goes away, nobody can contribute any more. Here on the Wiki, everyone can collaborate on a script, and there doesn't need to be a single owner. How should this be handled? Maybe there could be one vim.org login VimTipsUser, with password and rules and guidelines posted somewhere here in the Wiki, that can then be used by anyone from the Wiki community to upload new versions to vim.org?! (Assuming the vim.org owners are okay with posting such an open login to their site, and the potential for spam and vandalism.)

What do you think? Have other tips from here already made the move to a vim.org script (without a single owner/adopter)? -- Inkarkat 11:04, 13 July 2008 (UTC)

---

That's an attractive idea. I vaguely recall (but have forgotten the details) that in recent months there was a tip that someone developed into a script on vim.org. In the past, that has happened several times. However, as you point out, the script then suffers bit rot because usually the author moves on to other things and no maintenance occurs.

We have no system for collaborative access to vim.org. At the moment, I'm inclined to leave things the way they are until we get a case where someone really wants to proceed. We could have a public name/password, or we could have a page explaining that there is a well-known account, and if someone wants it they can email [list of 3 or 4 users here]. For email, I would be inclined to NOT publish any email addresses (even if obfuscated). Instead, rely on the Wikia procedure whereby there is an "email this user" link (that requires the sender to have a Wikia account, and the recipient to have supplied an email address; the sender does not see that address unless the recipient replies).

Also, I'm somewhat selfishly wanting to keep this tip here, at least for the moment. In general, I wouldn't want to have that long script on a tip and a maintained plugin on vim.org. So, if you really want to make a plugin with yourself as the initial maintainer, let's sort out the details. Otherwise, let's wait until this tip has developed even further.

Another option: It is possible to upload binary files to the wiki. So, we could upload a zip (or text file, or whatever), and provide a link for a download. This procedure uses the "Image" feature of the wiki (whereby it is possible to upload images). I'm not sure what Wikia thinks of this, but I could easily find out (I don't think they would mind), and I have noticed it elsewhere (we haven't done it). --JohnBeckett 00:28, 14 July 2008 (UTC)

Talk pages on this wiki

Just so everyone knows, we normally try to avoid using talk pages to comment on tips. Instead, if you see something that should be noted in a tip (an improvement, a defect, a question about the tip), please just add to the Comments section at the bottom (use a line consisting of only ---- to give a horizontal rule to separate each comment). We find that generally is easier for editors and readers (if there may be a problem in a tip, a reader should see the comment raising the problem, without needing to examine the talk page as well).

Note also that here we don't keep comments (we just want tips without too many distractions). As soon as a comment is dealt with, it should be deleted (although if a newcomer has a comment, I would generally keep the comment for at least a week, with some sort of reply to indicate why the comment was not applicable). Likewise, unless this discussion keeps going, I'll probably recommend deletion of this talk page in a couple of months (if there's nothing of long-term value remaining on it).

This is the first time that we have had a real reason for holding a discussion on the talk page of a tip, so go wild with any suggestions! --JohnBeckett 02:00, 13 July 2008 (UTC)

Highlighting within status line

Question: Is it possible to highlight the column header on the status line to be the same color as the highlighted column? It is some small convenience, I think it would be nice to have although what we have now is pretty good already.

Yes, it's possible (after all). Good (though tiny) point! I've added it to the code; in the status line, the column heading is now highlighted the same way as the current column. -- Inkarkat 20:32, 20 July 2008 (UTC)

Sorting by column

When I get some quality time, I might try and better understand lpb612's amazing regexs. I suspect that some minor tweaks would give a pattern that you could use so :sort would sort based on the fields in a column! --JohnBeckett 12:02, 19 July 2008 (UTC)

Please see the main page. There is a new section explaining the regex. -- Lpb612 06:06, 20 July 2008 (UTC)

This feature has been added. See the main page. I used a function instead of a simple :sort call, because sort call with the "skip" feature (ie. sort /pattern/) can probably do correct sorting in most cases, by skip the first n-1 columns, but then the text in all remaining columns are ordered, instead of just the n-th column.

A "delete column" feature has also been added.

--Lpb612 20:40, 20 July 2008 (UTC)

Search within column (original)

I have added a new feature: search within column. See the introduction before the script.

Lpb612 03:19, 18 July 2008 (UTC)

More magnificent magic! --JohnBeckett 09:09, 19 July 2008 (UTC)

---

Hi lpb612: Please check following. [Update: These comments are obsolete -- see next section.]

I notice that :SC 2=john works very nicely, but it doesn't highlight the hits (I use :set hlsearch). The following line used instead of the current line seems to fix this issue. I used 'normal' (not 'normal!') so that the mapping for 'n' is used.

command! -nargs=1 SC execute <SID>SearchCol("<args>") | normal n

--JohnBeckett 12:25, 19 July 2008 (UTC)

---

I've corrected the scope of the command to command! -buffer. -- Inkarkat 20:34, 20 July 2008 (UTC)

Search within column (new)

I have implemented a new version of csv.vim:

• Expands undo_ftplugin so more changes are undone, including removal of the autocommands. That means set ft= really does turn off highlighting.
• Uses 'normal n' in the SC command so the first search highlights hits (if 'hlsearch' is set).
• Uses matchadd() rather than :match so a priority can be assigned to the highlight. That allows search hits to be highlighted in the current column (and leaves the :match command available for the user).

My code needs checking (there are a couple of things I'm not sure about)! Please fix any issues you find, or if it's ok let me know here.

[RESPONSE] I checked the new version with matchadd. It works where matchadd is provided (new version of vim?). But it seems that not all VIM 7.1 has matchadd. Another solution, as you (JohnBeckett) mentioned is the following: use "2match Keyword" instead of "match Keyword" in the s:Highlight function, and add

execute 'match Search /\c' . @/ . '/'

at the end of SearchCol function. This way, the SC search has a higher priority than "Keyword" match. Thanks JohnBeckett for both pointing out the problem, and also providing (two!) solutions. Update: Now I have added both methods to the code so that if matchadd is missing there is no warning message, and still highlighting search is correctly done--- Lpb612 06:13, 20 July 2008 (UTC)

I guess everyone knows that you can use the 'history' tab on the wiki to see old versions. If you click the date for a particular version, that version if opened. If wanted, you can edit the old version and copy out all the wikitext to a local file. That's a good way to compare two versions, although the wiki difference tool on the history page is surprisingly good and is often all that you need. Be careful not to save an old version unless you want to wipe out changes since that time. --JohnBeckett 04:21, 20 July 2008 (UTC)

[RESPONSE] The b:undo_ftplugin didn't execute anything after the :call matchdelete() on plain VIM 7.0, because (I think) the | binds stronger than the :sil!, and so if matchdelete() fails, the following commands aren't executed, and the mappings aren't undone. I fixed that, and also added the 2match none undo for plain VIM 7.0. I also removed the nnoremap <buffer>n n, which is a no-op, isn't it?! At least, highlighting also works for me without this. -- Inkarkat 20:29, 20 July 2008 (UTC)

---

[DISCUSSION]I think the

nnoremap <silent> <buffer> n n

should not be removed. Otherwise, there will be a "Press Enter" message for a long regular expression. Try a CSV file with many columns (e.g, 5 or 6) and try to search in the last few columns, you should be able to notice the problem. The trick is the <silent> part, which suppresses the message. -- 12.202.152.182 00:36, 21 July 2008 (UTC)

I agree with lpb612, and have restored the mappings for n and N. BTW, if you use a secure computer (which only you access), you can select the "remember me on this computer" option when you log on. I think you then only need to log on once a month, and it won't log you off after a timeout.

Thanks Inkarkat for fixing undo_ftplugin and more. --JohnBeckett 06:07, 21 July 2008 (UTC)