New tips February 2010
Script discussion pages
This month, the vim.org/scripts site added a new link to each script. The link for script 1234 originally was to a wiki page with title Script-1234. The link now is to Script:1234. See the Script comment guidelines for more information.
Following are the script discussion pages created so far this month:
- Script:1234 • Script:1528 • Script:1879 • Script:2204 • Script:2606 • Script:2662 • Script:2775 • Script:2845 • Script:2899 • Script:2918 • Script:2949
I have shown the above links, with a site notice linking to this page, so that anyone looking for the original Script-1234 page will be notified about the new title. Another way to find the correct wiki page, is to visit the page for the script at vim.org/scripts and click the link to this wiki. I probably will not update the above list since any page created now should be at the correct location. All script discussion pages are listed here. Please discuss at my talk. JohnBeckett 01:34, February 15, 2010 (UTC)
New tips created in Februrary 2010
This page is an archive listing tips created in February 2010. Please do not edit this page because discussion has finished. If you have any comments, edit the appropriate tip page.
| Proposed new tip | Current consensus |
|---|---|
| Restore the last used mode when switching tabpages | Kept as VimTip1648 |
| Append output of an external command | Kept as VimTip467 (merged after rewriting) |
| Auctex-style environment creation in LaTeX | Kept as VimTip1647 |
| Quick command in insert mode | Kept as VimTip1646 |
| Read (but not write) file in new tab | Merged to VimTip1347 |
Restore the last used mode when switching tabpages
This page was created in June 2008 and somehow missed being flagged as a "tip" so I am adding it for processing with the February 2010 new tips. JohnBeckett 07:14, January 25, 2011 (UTC)
Keep. I like it (though I won't use it), and it adds another decent "using tabs as workspaces" tip to our Tabs category. –Fritzophrenic 03:59, February 14, 2011 (UTC)
Append output of an external command
I have history merged tip 467 to the title of the proposed tip:
- VimTip467 was Vim windows displaying output inside vim window.
- "VimTip467" and "Vim windows displaying output inside vim window" both redirect to the new tip.
- The new tip has its original title: Append output of an external command.
- History of old and new tips are at the new tip.
- I removed Category:Usage as not particularly helpful, and added Category:Getting started per Fritzophrenic's suggestion.
JohnBeckett 08:39, April 16, 2011 (UTC)
Delete per normal process. This tip does not explain the problem it is solving, and has no perceivable advantage over the builtin methods (:redir, :r, system(), etc.). The example it gives is overly complex for the task of appending external output, and is just a complicated way to do something that Vim can do internally with strftime(). --Fritzophrenic 05:12, June 24, 2010 (UTC)
- I agree although I might subvert the deletion by merging a small amount of the tip to one of the see also tips. No doubt this tip served a purpose, but the code is too particular for the date example, which can be better handled, as noted in the tip. I would probably have a different view if there were a realistic example using some other external program that provides a function not handled by Vim. I have tagged the tip to alert anyone watching the page. JohnBeckett 07:47, July 4, 2010 (UTC)
Erm
I suggest that one of the individuals suggesting deletion write some script that demonstrates the theory using a different system command than "date". Then I would be happy to see the tip deleted if still desired, since then I would know that someone has learned something.
The points given do not reflect that the individuals proposing deletion actually understand the tip. Regarding: This tip does not explain the problem it is solving: I actually did explain in the part where I stated "Vim does not have backticks". This is self-explanatory for *nix shell coders. The persons using Vim with a background in sh or in things like make that borrow from sh (the Bourne Shell) do understand.
- I disagree that "Vim does not have backticks" is a good enough problem statement. The problem you are trying to solve, if I understand correctly, is that you want to append output of a shell command to an existing line, possibly with some additional parsing/acting upon the output of the shell command. In a shell script, you could use backticks in a solution, but in Vim, you instead need the system() function. The rest of the tip complicates things so much that you can hardly tell what the solution to the real problem is, with all the extra stuff. This is made worse by the fact that the "extra stuff" is little more than a re-implementation using a system command of an existing Vim function. Perhaps the tip can be salvaged, but it certainly needs a much simpler example to be useful. Using "echo" instead of "date" perhaps. A more involved example is sometimes useful after the trivial example, but in this case I think the more involved example should provide something useful on its own, not a re-implementation of a built-in function. Maybe something like retrieving the revision number from a version control system or something. For a good example of what I mean, look at VimTip1549, which starts with a clear statement of the problem that is being solved (user wants to start an asynchronous process, but also see or use the results in Vim). It then goes into a very simple example to demonstrate basic concepts, with a thorough explanation of how it works. Only then does tip go into an involved example using these concepts to do something actually useful, and it explains all the extra stuff that gets added. --Fritzophrenic 06:01, September 15, 2010 (UTC)
I suggest that overzealous deletion motions reflect cultural narrowness of viewpoint rather than good housekeeping tactics. I know that I looked far and wide for how to do this before I posted what I'd worked out here.
Allow me to ask point-blank: if even 3 or 4 people are helped by this tip in the next 2 years, what was the harm of leaving it?
--Perlsomian 01:36, September 15, 2010 (UTC)
- I think that even if you help 3 or 4 people with the current example, they will need to spend a lot of time deciphering what is going on, what the real problem is, and what the core of the solution is. I think a better example may help, but it will probably be a very simple tip at that point, one that basically says "you can use the system() command to get shell output as a string", that could probably be merged elsewhere (and the original title kept as a redirect). I think that a much larger number of people will find the tip, get frustrated with the difficulty in understanding the point of the tip or what the code is doing, and either move on or stop using the wiki. I think that people are unlikely to find the tip by searching, and if they do, it will likely not be relevant, leading to frustration. I think that people finding this tip in a "random page per day" practice will simply sigh at the waste of their time when they finally understand what the tip is doing and move on to a new random page.
- Forgive me if I seem overly harsh. In general, I argue for keeping any new content in one way or another. Obviously somebody found the content useful. But, the original tip as far as I can tell was a (very clever!) workaround for an understandable lack of knowledge about the presence of a specific Vim command. I had a similar problem myself with one of my first tips, which tried to recreate the setreg() function on old Vim versions, without realizing that I could just use :let. Again, maybe this tip can be salvaged, but without some work its main message (using system() to get a string you can use or parse) will probably end up getting merged somewhere else. Or am I still missing the point of the tip? --Fritzophrenic 06:01, September 15, 2010 (UTC)
- @Perlsomian: Sorry for the conflict but as you can see we are way behind our maintenance of the site. The problem is that Fritzophrenic and myself both care about the tips, but don't have sufficient time at the moment to catch up (but we will). There are so many dubious old tips that we have decided to be very careful about new tips, and even if we disregard the comments above, the fact remains that the current proposed tip has a problem because it presents a script that is really only useful for appending a timestamp to the current line, whereas the wiki should promote the proper usage of strftime(). We have the two tips mentioned in 'see also', and the comments. All that needs to be fixed to provide a straight forward set of information, without duplication. I can imagine that appending a timestamp to a line could be handy (in which case, strftime() should be used), and replacing a line with the output of a program (using the line as input) is occasionally useful (filter with :!), but is there a useful example of appending the output of a program to the current line? JohnBeckett 09:03, September 15, 2010 (UTC)
I think I changed my mind. The way to get output from an external command into Vim is not common knowledge among beginning or even some intermediate Vim users. Doing a search for "external command" shows we have virtually no tips that address this topic. I suggest keeping this tip, but ditching the current example entirely. I hope to take a swing at this in the next few days. Something like this:
- Intro: users may want to get output of external command into their buffer
- note that Vim has built-in commands for a lot of things, like glob() or strftime()
- link to Insert_current_date_or_time as an example of what you can do with the techniques in this tip
- section 1: using :r ! to get the output in the buffer
- section 2: using system() to get the output into a script so you can parse it, or into the expression register to use it
- section 3: using :{range}!cmd to replace lines
--Fritzophrenic 03:59, October 22, 2010 (UTC)
- Obviously I haven't gotten to this yet. I still think we need an "external command output" tip and this is still a candidate in my mind. --Fritzophrenic 19:10, November 29, 2010 (UTC)
Auctex-style environment creation in LaTeX
Tentative keep. If we can find a good merge target, ok. I'd like an explanation added to the tip (both of functionality and of implementation), especially of the -complete=custom part, which is probably the only interesting bit (other than the drop-in script, of course). Put in Category:Automated Text Insertion at the very least. --Fritzophrenic 05:12, June 24, 2010 (UTC)
Quick command in insert mode
This is dodgy (teaching people to stay in insert mode with irritating abbreviations to perform normal-mode commands – irritating because of the delays after typing the first character). Any opinions? I could be persuaded to keep it for those who like the somewhat cute idea, or even to delete it. JohnBeckett 08:10, May 19, 2010 (UTC)
I don't know what to do with this either. It's a novel idea; most people go for mappings in insert mode that aren't insertable text. I'd mention this up front, and delete the section on file commands. The only real content is the idea...maybe we can merge one or two mappings to Short mappings for common tasks. If we keep it in full, we should add to the intro to link to tips about avoiding the <ESC> key, and mention the CTRL-O and related commands. --Fritzophrenic 05:12, June 24, 2010 (UTC)
I think we should keep this as a separate tip. It's too klunky to merge I think. I've taken a stab at the fixes mentioned above...feel free to edit some. --Fritzophrenic 21:04, July 10, 2010 (UTC)
I vote for keep, if that's not clear. --Fritzophrenic 04:10, October 22, 2010 (UTC)
Read (but not write) file in new tab
Merged to VimTip1347 (Introduction to using tab pages). JohnBeckett 08:10, May 19, 2010 (UTC)
Fritzophrenic: You suggested merging this to Quick tips for using tab pages, with the following:
cabbrev tabv tab sview +setlocal\\ nomodifiable
I thought Introduction to using tab pages was better (your tip was much more primitive when you suggested the above; let me know if you don't like the merge). Also, I found that your code above should have only one backslash. I decided to use the original code because your improved version above has the defect that it does not provide file name completion. The abbreviation in the original tip finishes with the :view command, so file name completion works. JohnBeckett 08:10, May 19, 2010 (UTC)
Good call on the single backslash. I'm not sure whether that was a typo, or what.
I'm confused when you say my code doesn't allow command-line completion. If I type :tab sview +setlocal\ nomodifiable C:\<Tab>, I get command-line completion of all directories residing on the C: root.
--Fritzophrenic 17:08, May 19, 2010 (UTC)
- Hmmm. I just tried it again and you are right (i.e. it works well). I really thought I had tried both versions of the command and seemed to be in a state where one did completion and one didn't ... probably just SNAFU. Anyway, I have put your version in the tip now. JohnBeckett 22:31, May 19, 2010 (UTC)