help with help, comments, and interactions with Unix (the :! construction)
David
for even more years. However, I am new to this usergroup and I hope
that I am not repeating ground that has been repeatedly covered
already in the recent past. I did try searching the archives, maybe
ineptly, and had no success.
Every time I try to use :help I become frustrated. I have just spent a
couple of hours trying in vain to find out some elementary things. I
tried :help comment. I was indeed able to learn what the default
comment symbol was, but only by paying careful attention, because this
passage was clearly written for someone who already knew that the
comment symbol is a double quote mark.
Q1. Where is the article that explains to a beginner that the default
comment symbol is a double quote mark?
Q2. How should I have proceeded to find that section of help?
Q3. Suppose there are 25 sections of help that discuss comment
symbols. Is there a convenient way to find them all? And how could I
conveniently work through them systematically?
Q4. Does the format *:comment* have a particular significance? It must
have, because one finds it everywhere in the help files. What is less
apparent is what it means and whether one can use it to jump to a
suitable topic.
In sample vimrc files on the web, I found entries as follows:
set comments+=b:\"
set comments+=n::
Q5. How could I find out what += means here? I mean by using vim help,
not by asking this news group. I tried :help += and obtained an
article on the use of :let, which I do not consider relevant.
Q6. What is the meaning of += here?
Q7. What is the meaning of the b: and n: in this context?
Here is the problem I started with at the beginning of my 2 hours of
frustration:
I tried Unix>vim>following_command
:.!date " and here I put a comment
and received error messages.
The problem is not, as I mistakenly thought, with the comment symbol,
but, as you experts undoubtedly realise instantly, with the fact that
vim is feeding back the whole line
date " and here I put a comment
to the Unix shell for interpretation. This brings me to my final
question:
Q8. Is there any way of telling vim not to feed the whole line to the
Unix shell, but only the initial part? I tried shielding the comment
part by inserting a | as shown to me by the vim online help response
to :help comment, but it didn't work. (This all occurs in something I
am trying to automate in a source file of vim commands, and that's why
I do want to include a comment. I suppose I could give up and put the
comment elsewhere, where vim would find it less puzzling, but a human
reader would find it more puzzling.)
Thanks very much for your patience if you have managed to stick with
me this far, and many thanks in advance for any help. Apologies for
asking so many questions, but it might have been much more irritating
if I had used 8 postings for my 8 questions. If there are any
responders, I would be grateful if you could say which of my 8
questions you are answering.
Thanks once again for any help.
David
Gary Johnson
> Every time I try to use :help I become frustrated. I have just spent a
> couple of hours trying in vain to find out some elementary things. I
> tried :help comment. I was indeed able to learn what the default
> comment symbol was, but only by paying careful attention, because this
> passage was clearly written for someone who already knew that the
> comment symbol is a double quote mark.
> Q1. Where is the article that explains to a beginner that the default
> comment symbol is a double quote mark?
I finally found it here:
:help vim-script-intro
and then searched for "comment". I can understand your frustration.
> Q2. How should I have proceeded to find that section of help?
I don't know. After trying the "obvious" places, as you did, I
decided to look in whatever section covered writing configuration
(e.g., .vimrc) or script files.
I finally did find the definitive help topic on this:
:help :"
or
:help :quote
Unfortunately, that topic can only be found if you already know that
" is used for vim comments. I found it by knowing that : begins
every help topic on ex commands and that " is used within ex
commands.
> Q3. Suppose there are 25 sections of help that discuss comment
> symbols. Is there a convenient way to find them all? And how could I
> conveniently work through them systematically?
If you want to find all the help keywords containing "comment", type
:help comment
then type Ctrl-D for a list of matches. This is mentioned near the
top of
:help
and under
:help help
as are other techniques. For example, you can execute ":help" then
:tag /comment
and traverse the resulting list of tags. You can use ":helpgrep" to
search the help files for a pattern and traverse the resulting
quickfix list.
> Q4. Does the format *:comment* have a particular significance? It must
> have, because one finds it everywhere in the help files. What is less
> apparent is what it means and whether one can use it to jump to a
> suitable topic.
Those are help tags. They are the targets of jumps. The tags you
can jump to are surrounded by || as described at the top of ":help".
Unfortunately, recent releases of vim seem to highlight the * and |
characters used for help tags with the Ignore highlight group for
the sake of "readability", so you may not see them and may have to
rely on other highlighting cues to recognize them.
>
> In sample vimrc files on the web, I found entries as follows:
> set comments+=b:\"
> set comments+=n::
> Q5. How could I find out what += means here? I mean by using vim help,
> not by asking this news group. I tried :help += and obtained an
> article on the use of :let, which I do not consider relevant.
That's because that help command took you to the first article in
the help tags list containing "+=". If you had typed
:help +=
followed by Ctrl-D, would have seen the ":set+=" tag as well. If
you had known about Ctrl-D, that is. Or you could have gone for
:help :set
and scrolled down a bit to find the entry discussing +=.
> Q6. What is the meaning of += here?
:help :set+=
> Q7. What is the meaning of the b: and n: in this context?
:help comments
would refer you to
:help format-comments
which explains those.
>
> Here is the problem I started with at the beginning of my 2 hours of
> frustration:
> I tried Unix>vim>following_command
>
> :.!date " and here I put a comment
>
> and received error messages.
> The problem is not, as I mistakenly thought, with the comment symbol,
> but, as you experts undoubtedly realise instantly, with the fact that
> vim is feeding back the whole line
>
> date " and here I put a comment
>
> to the Unix shell for interpretation. This brings me to my final
> question:
> Q8. Is there any way of telling vim not to feed the whole line to the
> Unix shell, but only the initial part? I tried shielding the comment
> part by inserting a | as shown to me by the vim online help response
> to :help comment, but it didn't work. (This all occurs in something I
> am trying to automate in a source file of vim commands, and that's why
> I do want to include a comment. I suppose I could give up and put the
> comment elsewhere, where vim would find it less puzzling, but a human
> reader would find it more puzzling.)
You could use a shell comment instead of a vim comment, escaping the
# so that vim didn't expand it as the alternate file name, e.g.,
!date \# put comment here
You could instead use :exe to execute the !date command and follow
that with a vim comment, but I think that would be even less
readable.
>
> Thanks very much for your patience if you have managed to stick with
> me this far, and many thanks in advance for any help. Apologies for
> asking so many questions, but it might have been much more irritating
> if I had used 8 postings for my 8 questions. If there are any
> responders, I would be grateful if you could say which of my 8
> questions you are answering.
The customary technique for replying to questions in mailing lists
and newsgroups is to quote the questions and to reply to each
question immediately below the quoted question, as I have done here.
Most experienced users will follow this custom.
I hope that's been helpful. There are other ways to search the help
files and others may discuss those. I tried to stay away from
techniques I don't use myself and those that might rely on my
customizations.
Regards,
Gary
Dominique Pelle
To those good answers, I would add that ":helpgrep" can be very useful.
For example...
:helpgrep comment
... then type use the quickfix commands to go through all matches
such as ":cn" (to go the next match) or if there are many matches
it can be more convenient to do ":copen" to open up a window with
all the results of ":helpgrep". You can then move the cursor in the
window of ":copen" and type <Enter> on a given match to go that
that location.
You can learn more by reading: ":help help" and ":help helpgrep".
Hope that helps.
-- Dominique
sc
>
[snip]
> Q1. Where is the article that explains to a beginner that the default
> comment symbol is a double quote mark?
i tried
:helpgrep comment
and the first hit indicated comments in vim scripting are
created with the double quote -- this was not a link to 'how
to script', which maybe you are looking for, which i believe
is in usr_41.txt -- if you search that module with
/^COMMENTS
you will find the section you wanted
searching vim help does take some getting used to -- so how
were you supposed to find usr_41.txt? perhaps
:help
with no arguments to take you to the main/first help page,
then follow the link to the table of contents and reading
til you find "Write a Vim script"
> Q2. How should I have proceeded to find that section of help?
see above
> Q3. Suppose there are 25 sections of help that discuss comment
> symbols. Is there a convenient way to find them all? And how could I
> conveniently work through them systematically?
learn to use the :helpgrep command -- it is arguably more
useful than :help, for which you almost have to know exactly
what you need before you can find it
read
:help helpgrep
to learn about :cn and :cp
read
:help :help
to learn about prefixes to :help arguments, for example
:help i_CTRL-O
takes you to help for the insert mode command <C-O>
> Q4. Does the format *:comment* have a particular significance? It must
> have, because one finds it everywhere in the help files. What is less
> apparent is what it means and whether one can use it to jump to a
> suitable topic.
>
> In sample vimrc files on the web, I found entries as follows:
> set comments+=b:\"
> set comments+=n::
the += syntax adds values to the {lhs}, for example
:set guioptions+=T
will add the toolbar to the top of the gVim window, where
:set guioptions=T
will set guioptions to include ONLY the toolbar
> Q5. How could I find out what += means here? I mean by using vim help,
> not by asking this news group. I tried :help += and obtained an
> article on the use of :let, which I do not consider relevant.
let and set are both very relevant here, they are where +=
is used
> Q6. What is the meaning of += here?
> Q7. What is the meaning of the b: and n: in this context?
the b: is for setting options that are local to the current
buffer
:help b:
will take you to an explanation of buffer-variables in the
eval.txt help module -- scroll up to see them all -- in this
context n: is not a variable prefix
:help 'comments'
shows what we are looking at is not related to vim
scripting, rather how formatting and syntax define comments
for languages you may be editing
i must go now, perhaps others can carry on with your other
questions
sc
fritzophrenic
expand some on one of your questions:
On Nov 23, 10:52 am, David <David.B.A.Epst...@googlemail.com> wrote:
> Here is the problem I started with at the beginning of my 2 hours of
> frustration:
> I tried Unix>vim>following_command
>
> :.!date " and here I put a comment
>
> and received error messages.
> The problem is not, as I mistakenly thought, with the comment symbol,
> but, as you experts undoubtedly realise instantly, with the fact that
> vim is feeding back the whole line
>
> date " and here I put a comment
>
> to the Unix shell for interpretation. This brings me to my final
> question:
> Q8. Is there any way of telling vim not to feed the whole line to the
> Unix shell, but only the initial part? I tried shielding the comment
> part by inserting a | as shown to me by the vim online help response
> to :help comment, but it didn't work. (This all occurs in something I
> am trying to automate in a source file of vim commands, and that's why
> I do want to include a comment.
command. Incidentally, all of these commands are also commands which
you cannot string together with a | character. See :help :bar for the
full list. If you keep reading, you can see that the easiest way to
get around this, allowing you to use | or " with the commands in this
list, is to put the command in a string and execute it with
the :execute command (:help :execute). For example, your problem would
be solved like this:
:execute ".!date" " and here I put a comment
> I suppose I could give up and put the
> comment elsewhere, where vim would find it less puzzling, but a human
> reader would find it more puzzling.)
>
above the line to which it refers. This additionally allows for longer
comments when you constrain yourself to a certain line length.
Chris Bannister
> The customary technique for replying to questions in mailing lists
> and newsgroups is to quote the questions and to reply to each
> question immediately below the quoted question, as I have done here.
> Most experienced users will follow this custom.
Also trimming unnecessary text, otherwise you just get bottom posters;
just as bad as "outlook style" top posters.
If by "customary technique", you mean "usual", then my experience on
this list is quite different.
--
Chris.
======
I contend that we are both atheists. I just believe in one fewer god
than you do. When you understand why you dismiss all the other
possible gods, you will understand why I dismiss yours.
-- Stephen F Roberts
bill lam
> Also trimming unnecessary text, otherwise you just get bottom posters;
> just as bad as "outlook style" top posters.
IMO top posting is better than bottom posting because it saves
typing or mouse drag to reach the answer.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩303 李商隱 嫦娥
雲母屏風燭影深 長河漸落曉星沈 嫦娥應悔偷靈藥 碧海青天夜夜心
Teemu Likonen
> On Tue, 25 Nov 2008, Chris Bannister wrote:
>> Also trimming unnecessary text, otherwise you just get bottom
>> posters; just as bad as "outlook style" top posters.
>
> IMO top posting is better than bottom posting because it saves typing
> or mouse drag to reach the answer.
Top-posting, when I don't know the context, and bottom-posting with long
passages of quoted text are both the kind of messages which I usually
just skip in a microsecond. I read about 35 mailing lists or newsgroups
and my reading algorithm is something like this:
if message(current) != easy_to_parse
call show(message(next))
elseif message(current) != interesting
call show(message(next))
else
call read(message(current))
endif
John Beckett
> IMO top posting is better than bottom posting because it
> saves typing or mouse drag to reach the answer.
OMG - Who started this!?
The question is not "which is better?", but "what is sensible?". If local custom is
to bottom-post, then that is the most sensible for everyone. Of course the "which is
better?" question is one of those religious issues that people will never agree on.
AFAIK all regular contributors here use the "bottom post" style. Until three or four
weeks ago, the vast majority of casual posters did the same, either from preference
or politeness.
It's recently (last couple of weeks, I think) that anarchy has broken out.
John
Raúl Núñez
On Tue, 25 Nov 2008 17:40:34 +0800, bill lam dixit:
> On Tue, 25 Nov 2008, Chris Bannister wrote:
> > Also trimming unnecessary text, otherwise you just get bottom
> > posters; just as bad as "outlook style" top posters.
>
> IMO top posting is better than bottom posting because it saves
> typing or mouse drag to reach the answer.
If you toppost:
- Don't quote. It doesn't make sense, since the reply is *before* the
quoted text, and the conversation would be read unordered. In short:
the quoted text won't be ever read.
- If you quote, you will be breaking the normal reading order (top to
bottom) and if anyone wants to follow the conversation, he will have
to read the bottom part before. If two topposters are having a
conversation the mess would be incredible. Namely, the message would
have to be read from botton to top. Very unnatural.
- You're not saving time. You're getting extra time for yourself by not
quoting properly thanks to the extra time the readers will take to
read your reply. That's not polite.
- ¿You save time by not scrolling down? Well, that's you, because I want
to read the original message if I wasn't following the conversation
from the start, so I have to scroll down *and* scroll up again.
- You will screwing non-top-posters if they want to reply to your
topposted message, because they no longer can quote properly unless
they do a lot of hard work edition (easier with Vim, but that's not
the point).
- You will be supporting humongous quoted texts. If everybody topposts,
they leave the ENTIRE replied message quoted below their answer. This
means that the conversation is harder to follow.
If you want even more reasons to avoid topposting, Google about it. I
think that weren't for crappy email clients like Outlook, no topposting
would have happened ever. Crappy programs lead to crappy habits.
Raúl "DervishD" Núñez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
We are waiting for 13 Feb 2009 23:31:30 +0000 ...
Raúl Núñez
On Tue, 25 Nov 2008 12:26:44 +0200, Teemu Likonen dixit:
> Top-posting, when I don't know the context, and bottom-posting with
> long passages of quoted text are both the kind of messages which I
> usually just skip in a microsecond. I read about 35 mailing lists or
> newsgroups and my reading algorithm is something like this:
>
> if message(current) != easy_to_parse
> call show(message(next))
> elseif message(current) != interesting
> call show(message(next))
> else
> call read(message(current))
> endif
Exactly! Topposted and bottomposted messages are much harder to parse,
read and follow. Except for a couple of exceptions I won't mention here,
I directly delete topposted and bottomposted messages which fill more
than a screen. I have too little time and too many interests...
Raúl Núñez
On Tue, 25 Nov 2008 21:31:43 +1100, John Beckett dixit:
> bill lam wrote:
> > IMO top posting is better than bottom posting because it
> > saves typing or mouse drag to reach the answer.
>
> OMG - Who started this!?
Unfortunately, GMail is as bad as Outlook regarding quoting, and invites
to bad quoting habits. It's not a matter of "top vs. bottom posting",
the problem is that people enable quoting in GMail/Outlook and answer
directly on top, without ever thinking about trimming or deleting the
quoted text. It's not that they toppost, it's that they don't care about
quoting. It's not a quoting style option, it's just laziness.
> It's recently (last couple of weeks, I think) that anarchy has broken
> out.
More and more people use GMail and Outlook, and even if they used better
email clients, probably they would do exactly the same: quote the entire
old message (including the signature and any legal disclaimer, of
course) and write their answer in the exact point where the cursor is
left by the mail user agent: on top or bottom.
I've answered in this thread just in case somebody thought that being
lazy when replying email is polite, not because I really care: as Temmu
said, I don't waste my time reading such emails. People are free to
write as they want, and I'm free to happily delete the email I receive.
Raúl Núñez
On Tue, 25 Nov 2008 11:48:35 +0100, Raúl Núñez de Arenas Coronado dixit:
> Temmu said, I don't waste my time reading such emails. People are
Sorry for miswriting your name: is "Teemu", not "Temmu". Imagine this
correction topposted...
bill lam
>
> OMG - Who started this!?
Certainly not me. IIRC I did not ever top post on vim_use.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩275 劉方平 月夜
更深月色半人家 北斗闌干南斗斜 今夜偏知春氣暖 蟲聲新透綠窗沙
Teemu Likonen
> bill lam wrote:
>> IMO top posting is better than bottom posting because it
>> saves typing or mouse drag to reach the answer.
> [...] question is one of those religious issues that people will never
> agree on.
Perhaps it's like that (religious) in here but among some, hmm... more
advanced communities, like Linux kernel, Debian GNU/Linux, Emacs, Git
developers etc., this question never needs to be discussed. Basically
everybody trims their messages and quotations to be easily readable, and
the context of a message can be seen with a quick glance. This is not
because they just happen to have the same "religion". It's because they
have a long experience in communicating effectively in the Internet (and
other networks and bulletin boards systems before that).
Gene Kwiecinski
And something I always think but *hope* it never needs to be said,
'though unfortunately it *does*, is that if I get to a post or email
that's just plain garbage, whether it has 400 lines of quote and 2 lines
of reply at the bottom, or it's just lazily top-quoted despite it
originating as a bottom-quoted post, or has html turned on with some
garish "formatting" via indents and left-margin lines, or has some
retina-searing blinding-white background... I just delete the post
unread.
If the sender is too lazy or rude to not go through the minimal effort
to make his email/post readable, then it's simply not worth *my* effort
to even read it, let alone reply.