What about
hi default CursorIM term=reverse ctermbg=green ctermfg=yellow
\ gui=bold guibg=green guifg=yellow
I don't have a help tag but see line 4087 of syntax.txt (2011 Apr 06 for
Vim 7.3).
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
78. You find yourself dialing IP numbers on the phone.
Well, the 'default' part is explained at :help :hi-default which applies
not just to :hi-link, which is closest to it, and which the examples
demonstrate, but it also applies to :hi with settings (as [default] is
present in the syntax description, and there is a cross-reference to
:help :highlight-default, a little bit below :help :colo).
However, it doesn't really help in this case. CursorIM, being a built-in
highlight group, never has "no settings" or "doesn't exist", unless you
explicitly do :hi clear CursorIM or :hi CursorIM NONE. So using
"default" to define CursorIM will be useless unless you expect your user
to do one of those two things above if they want to get your default
highlighting.
Ben.
I don't do anything with it, and yet:
:hi CursorIM
E411: highlight group not found: CursorIM
The same happens with "vim -N -u NONE" or with "vim -u
/usr/local/share/vim/vim73/vimrc_example.vim" with or without --noplugin.
Best regards,
Tony.
--
Sodd's Second Law:
Sooner or later, the worst possible set of circumstances is
bound to occur.
Interesting. When I tested, I just did :hi clear, which evidently
doesn't actually clear things fully as I thought it would. Perhaps this
is a bug.
The result, though, is yes, that your approach using "default" will
work, at least for CursorIM, though not for other standard highlight
groups which are defined with defaults.
Ben.
work, at least for CursorIM, though not for other standard highlight
The result, though, is yes, that your approach using "default" will
groups which are defined with defaults.
Ben.
If you had checked my first reply, you would have found at line 4087 of
syntax.txt,
:hi[ghlight] [default] {group-name} {key}={arg} ..
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
81. At social functions you introduce your husband as "my domain server."
Yeah, well at that line in my syntax.txt (dated the same as yours,
IIRC--I believe I checked against a date you provided), I find
> the default value.
Which is related, I guess, but not so helpful as the line you quoted
above. :-)
Smiles,
Ben.
Are you sure? My syntax.txt is dated April 6 (as shown on line 1),
however the corresponding changeset (0877b8d6370e) was only committed on
April 28, together with a number of other runtime files changes. The
only patch later than that was 7.3.170 (changesets 64c3402df964 and
08c36bef2004), and it affects only src/testdir/Make_vms.mms (plus
src/version.c and .hgtags).
>
>> the default value.
That line is 11 lines lower here.
>
> Which is related, I guess, but not so helpful as the line you quoted
> above. :-)
>
> Smiles,
>
> Ben.
>
>
>
Best regards,
Tony.
--
Zero Defects, n.:
The result of shutting down a production line.
Nope. I mustn't have checked after all (or perhaps only na�vely checked
the month and not the day). Mine is dated April 1.
Ben.
Take two: naïvely. Something gone wrong with encoding....
Ben.
Somehow the post (in 8bit Latin1) to which I'm replying here (in UTF-8)
had "naïvely" with a correct i-diaeresis (0xEF in Latin1), but the next
one (in 8bit UTF-8) quoted it as "naďvely" (with 0xC4 0x8F = U+010F
SMALL LATIN LETTER D WITH CARON) then printed it correctly below the
quote (0xC3 0xAF = U+00EF). I don't know what happened when you tried to
read your own message. Maybe you tried to view it in ISO-8859-2 since in
that encoding, 0xEF means d-caron.
Best regards,
Tony.
--
Maier's Law:
If the facts don't conform to the theory, they must be disposed
of.
Corollaries:
(1) The bigger the theory, the better.
(2) The experiment may be considered a success if no more than
50% of the observed measurements must be discarded to
obtain a correspondence with the theory.
Google Groups messed it up. It left here as:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
naïvely
but then arrived from the list as:
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
na=C4=8Fvely
I have no idea how they could have got the conversion so wrong, when it is so
beautifully declared, but there you go. Computers! Pfff!
Ben.
That has been mentioned before. See the thread starting at:
http://groups.google.com/group/vim_use/msg/282220b092f894f5
and
http://groups.google.com/group/vim_use/msg/1d2384d110b4fc1b
It seems, Google groups is broken. Not only does it usually not display
umlauts (it leaves them out in German groups and makes it sometimes
really hard to read), it also mangles them when processing the mails.
I used to use footnotes in my mails. But google groups mangled them so
badly, that I don't use it in this list anymore.
regards,
Christian
I think it's OK if the mail is sent in UTF-8. If it's sent in some other
encoding, Google Groups tries to convert it to UTF-8 and botches it up.
But if it is in UTF-8 to start with, it's OK. I guess this means if you
go into your mail client settings and set your default encoding to be
UTF-8, you will probably rarely have problems (and most correspondents
will be using software capable of reading UTF-8 these days, too, so you
shouldn't lose much communicability).
Ben.
Hm. I read Google Groups (except vim_mac where I use "Abridged Email"
and, if necessary, the Google Groups web interface) by setting them to
"Email" then getting that mail from the gmail.com POP3 server by means
of a "classical" email client (I use SeaMonkey; Thunderbird or probably
Opera or Outlook Express would work just as well).
That "first" "na�ve" message of yours arrived here with
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
and correct 8-bit Latin1 content; so it seems that in my case, Google
left the message well enough alone even though it transited via both
googlegroups.com and gmail.com
Maybe one of the mail routers on the way to you does not declare itself
8bit-capable and the one before that botches the conversion to
quoted-printable? Yet ISO-8859-1 to UTF-8 and 8bit to quoted-printable
ought to be both rather trivial. Oh well, one distracted programmer is
enough to get any number of stupid computers to botch the simplest of
jobs (I know, I used to be a programmer myself) so testcases are needed
even for the silliest errors.
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
82. AT&T names you Customer of the Month for the third consecutive time.
I suspect that since you were CCed, you received a copy of the message
directly at Gmail, and the mangled one that went through Groups was
discarded (as Gmail recognises duplicate messages and at the very least
collapses them, I believe). Or did you see both copies, and were they
the same? Maybe check the Received headers to double-check the message
went through groups, not directly to Gmail, if that distinction is easy
to make (it should be, I think).
The same might happen to this message. At this stage in composition,
Thunderbird is showing latin1 as the encoding; if it indeed goes out
like that, this message can serve as another test case.
Ben.
No, I got only one copy. Let me see what its Received-lines say...
(latest first, remember?)
> Received: by 10.229.42.5 with SMTP id q5cs286259qce;
> Sun, 1 May 2011 16:55:34 -0700 (PDT)
> Received: by 10.42.159.199 with SMTP id m7mr2726351icx.78.1304294133974;
> Sun, 01 May 2011 16:55:33 -0700 (PDT)
> Return-Path: <mail_ben...@yahoo.com.au>
> Received: from nm27.bullet.mail.ac4.yahoo.com (nm27.bullet.mail.ac4.yahoo.com [98.139.52.224])
> by mx.google.com with SMTP id ec14si4843850icb.122.2011.05.01.16.55.32;
> Sun, 01 May 2011 16:55:32 -0700 (PDT)
> Received-SPF: neutral (google.com: 98.139.52.224 is neither permitted nor denied by best guess record for domain of mail_ben...@yahoo.com.au) client-ip=98.139.52.224;
> Authentication-Results: mx.google.com; spf=neutral (google.com: 98.139.52.224 is neither permitted nor denied by best guess record for domain of mail_ben...@yahoo.com.au) smtp.mail=mail_ben...@yahoo.com.au; dkim=pass (test mode) header.i=@yahoo.com.au
> Received: from [98.139.52.196] by nm27.bullet.mail.ac4.yahoo.com with NNFMP; 01 May 2011 23:55:31 -0000
> Received: from [98.139.52.184] by tm9.bullet.mail.ac4.yahoo.com with NNFMP; 01 May 2011 23:55:31 -0000
> Received: from [127.0.0.1] by omp1067.mail.ac4.yahoo.com with NNFMP; 01 May 2011 23:55:31 -0000
> X-Yahoo-Newman-Id: 771643....@omp1067.mail.ac4.yahoo.com
> Received: (qmail 22636 invoked from network); 1 May 2011 23:55:31 -0000
Ah, so you're right: this seems to be the copy that went straight from
Yahoo to Gmail, and the one that transited through GoogleGroups never
made it into my Inbox, even though the "To: vim...@googlegroups.com"
triggered my mail filters to get this message out of Inbox and into the
Vim List folder.
Best regards,
Tony.
--
"Somewhere", said Father Vittorini, "did Blake not speak of the
Machineries of Joy? That is, did not God promote environments, then
intimidate these Natures by provoking the existence of flesh, toy men
and women, such as are we all? And thus happily sent forth, at our
best, with good grace and fine wit, on calm noons, in fair climes, are
we not God's Machineries of Joy?"
"If Blake said that", said Father Brian, "he never lived in Dublin."
-- R. Bradbury, "The Machineries of Joy"
Of course, it goes without saying that Groups broke with tradition and
didn't mangle that one. Maybe only some Groups servers have the bug, or
it's something more complicated that triggers it. How annoying.
> Ah, so you're right: this seems to be the copy that went straight from
> Yahoo to Gmail, and the one that transited through GoogleGroups never
> made it into my Inbox, even though the "To: vim...@googlegroups.com"
> triggered my mail filters to get this message out of Inbox and into
> the Vim List folder.
Well, that at least explains why you didn't see the problem the first
time around, even if we don't know when exactly Groups breaks....
Ben.
I asked someone, and he says that it looks like the problem is caused by
yahoo.com.au. Perhaps it depends on the way you route the message?
--
hundred-and-one symptoms of being an internet addict:
65. The last time you looked at the clock it was 11:30pm, and in what
seems like only a few seconds later, your sister runs past you to
catch her 7am school bus.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
I won't say it's not Yahoo, but that seems unlikely to me, because it
has happened with mail from other origins, and I can't think of anything
that would cause Yahoo to do an encoding conversion when communicating
with some remote servers and not others (or indeed at all). I give my
mail to Yahoo using SMTP, so no browser issues are in play, and Yahoo
doesn't even seem to do content filtering to append an ad (amazing!),
but even if it did, it would be hard to explain why character set
conversion would happen for some destinations and not others. AFAIK,
nothing a destination mail server could report would cause an origin
server to do a character set conversion. Transfer encoding, yes, but not
character set. It seems more likely that some of Groups' jiggerypokery
has a bug in it; after all, groups does a lot more than just deliver
mail--it prepares it for web archives and so on as well, and character
set issues definitely come into play there, so need to be dealt with.
Not sure how we can track this down further. It only happens sometimes,
so it may be that only some of Yahoo's or Groups' servers are affected.
Na�vely,
Ben.