RE: VimWiki - Poll on wiki hosting
-Original Message- From: Sebastian Menge [mailto:[EMAIL PROTECTED] Sent: 23 May 2007 10:03 To: vim@vim.org Subject: VimWiki - Poll on wiki hosting [...] But I don't see any structure in the 1500 tips. Neither now nor later. Well, say they could be thought of belonging loosely to different 'categories' (folding, highlighting, mapping, ...). I don't know if it can be equaled to chapters, sections, paragraphs, probably not, but some structure would surely eventually help in browsing, searching, etc. Hopefully that can be changed later if people think with me it would be useful. That's the reason why tips are separated from the manual! Correct, tips should be separated from the manual IMHO. Regarding the ads on wikia: The guys there told me that ads will be reduced much in space soon. And I even noticed ads on vim.org ... :-) I like that smiley! Now for the vote: Please review the arguments before voting. I hope you can find all major arguments in the full quote at the bottom of this mail. Perhaps a word of Bram would be helpful !? Now here's the link to the poll: http://snappoll.com/poll/194388.php I would have rephrased the 'I don't care' option to something like you guys, who know what you are talking about, choose the solution you believe fits the bill well, can be maintained if needed and is reasonably easy to implement. With this in mind I will vote 'I don't care', which doesn't mean I don't care :-)! I propose to close the vote on Friday, May 25th, 12:00 +0200 (MEZ aka CET). Good suggestion. Cheers and thanks for your involvement in this! ---Zdenek Am Dienstag, den 15.05.2007, 21:06 +0200 schrieb Martin Krischik: Am Dienstag 15 Mai 2007 schrieb Sebastian Menge: Am Montag, den 14.05.2007, 21:49 +0200 schrieb Martin Krischik: Now refresh my mind: Why did we choose advertising ridden wikea over advertising free wikibooks? There was already a lot of discussion on this topic but no real decision. I think that mediawiki is accepted as the most stable, feature-rich and spam-resistant software around. Given that we dont want to host the wiki ourselves, we need a hosting service: Here's a list http://en.wikipedia.org/wiki/List_of_wiki_farms There are no mediawiki-based offers that are completely free. If someone has an idea where/howto host a mediawiki completey free, that would be best! Here my pros and cons for wikia vs wikibooks: 1 +wikia: no costs 2 +wikia: a complete wiki, not just a bunch of pages 3 -wikia: ads 4 +wikibooks: really free, open content 5 -wikibooks: is intended for books/lecture material. vim tips doesnt fit that. A real book would need a structure in chapters,sections etc. 6 +wikibooks: personal Administrator. For me points 2 and 5 win. But anyway I would love to see a good VimBook on wikibooks. Other ideas/votes? Now on WikiBook there is allready a real book with structure in chapters, sections ;-) - it's called Learning the vi editor. Of the 16 chapters 7 are Vim chapters :-). And I belive Vim covers more the 50% of the content. Now the Wiki motto is Content first so here my advertising free suggestion: 1) We add the Vim tips to the Tips and Tricks Chapter 2) Once we we have enough tips (content) we split the book. Wikibooks does not ask you to create structure in chapters,sections up front. It is not even suggested! Suggested is Content first and structure in chapters,sections later. BTW: With a tabbed browser and a fast internet connection you can rename 10 pages per minute - I once rename a 200 page book from Programming:Ada to Ada Programming. Martin [1] http://en.wikibooks.org/wiki/Learning_the_vi_editor [2] http://en.wikibooks.org/wiki/Learning_the_vi_editor/Vim/Tips_and_Tricks smime.p7s Description: S/MIME cryptographic signature
RE: Vim Wiki - Tip Page Formatting Deadline
-Original Message- From: Tom Purl [mailto:[EMAIL PROTECTED] Sent: 15 May 2007 17:24 To: vim@vim.org Subject: Vim Wiki - Tip Page Formatting Deadline Task: Wiki Format Sign-Off Deadline: Monday, May 21st (arbitrary, I know) Overview We've had some great, constructive discussions lately regarding how we will be creating and editing tips in the future. Before we can finally decide how this is going to work, however, we need to decide upon a page format for tips. The most recently-updated wiki tip examples can be found at the following URL: * http://scratchpad.wikia.com/wiki/VimTest The following tips should stand out: * http://scratchpad.wikia.com/wiki/VimTip1 * http://scratchpad.wikia.com/wiki/VimTip1_v2 My preference goes to the v2, more concise. This first tip uses the Template:Tip template (http://scratchpad.wikia.com/wiki/Template:Tip), and the second tip uses the Template:Tip2 template (http://scratchpad.wikia.com/wiki/Template:Tip2). - Tip2 template is seems fine to me. - Who will or how it will be decided what are the different 'complexity' (what terms will be allowed)? - I find little inconvenient that when I want to add a comment I can't have the original tip (and perhaps other comments) in front of my eyes (maybe to scroll it manually) but that may be unsolvable - it could be useful to have a possibility to have a button saying 'Add a new tip' on every tip page so when I want to add a tip I don't have to start from a different page. That, too, may not be possible, correct? Requested Actions = Please take a look at these tips, decide which one you prefer, and then provide constructive criticism for that tip's format. There's no such thing as a dumb comment. My Two Cents I really like VimTip1_v2, which uses the Tip2 template. Here's what I like: * No special formatting for commands or any other preformatted text. I think that this is an essential requirement for the initial conversion effort. * Easy to read * Succinct Just what I meant above. How do you want to handle comments? Typically on a Mediawiki site, you sign you comments like so: This is so cool! Which is then saved to the page like this: This is so cool! Tpurl 15:17, 15 May 2007 (UTC) --- - It's a little ugly, but it's the norm in the wiki world. What do you guys think? :-) little ugly, yes. Alternatives? The whole thing seems to really be moving now in the right direction IMHO. Keep it up! Cheers, ---Zdenek smime.p7s Description: S/MIME cryptographic signature
RE: Vim Wiki - Wiki Template Proposal
-Original Message-
From: fREW [mailto:[EMAIL PROTECTED]
Sent: 15 May 2007 04:24
To: Tom Purl
Cc: vim@vim.org
Subject: Re: Vim Wiki - Wiki Template Proposal
On 5/14/07, Tom Purl [EMAIL PROTECTED] wrote:
Sebastian Menge has graciously created a Mediawiki template that
could
be used with the proposed Vim wiki. Here's a link to the template:
* http://scratchpad.wikia.com/wiki/Template:Tip
This is the wrapper for the actual tip content. Here's an example
of
some plain-text content:
{{Tip
|id=1
|title=Tip #1 - the super star
|created=February 24, 2001 14:47
|complexity=basic
|author=scott at kintana.com
|version=5.7
|text=
When a discussion started about learning vim on the vim list
Juergen
Salk mentioned the quot;*quot; key as something that he wished
he had
know earlier. When I read the mail I had to go help on what the
heck the
quot;*quot; did. I also wish I had known
earlier...brbrUsing the
quot;*quot; key while in normal mode searches for the word
under the
cursor.brbrIf that doesn't save you a lot of typing, I don't
know
what will.
}}
When you combine this content with the template on the wiki, you get
the
following:
* http://scratchpad.wikia.com/wiki/VimTip1
The big benefit of using a wiki template is that it separates the
content from the presentation, which can be very nice from the
perspective of a sysadmin or tip converter.
The disadvantage, in my eyes, of using wiki templates is that it adds
another barrier to entry for potential tip authors/editors. Not only
would they have to know how to do basic Mediawiki editing, but they
would also have to know how to use templates. Also, in my opinion,
it
is more difficult to edit the content when it's squished into a
template.
So far, we know about the opinions of me and Sebastian. What does
everyone else think? Is the template thing a good idea for our wiki?
Thanks again!
Tom Purl
I think that a template is a good idea, but like someone else (was it
you Tom) said in another thread, let's make the metadata more subtle.
It really dominates the page and it's kindav an eyesore. I put up
another template and it is at
http://scratchpad.wikia.com/wiki/Template:Tip2 with a demo at
http://scratchpad.wikia.com/wiki/VimTip1_v2 . The only difference
being that I manually took the #1 off of the tip title from VimTip1
and I made the Your signed comments here. not part of the template,
which was probably not really intended in the original anyway. What
do you guys think? The other idea that I had was to completely remove
the first header (==Tip: #{{{id}}} - {{{title}}}==) and have the tips
actually indexed something like that, so you would have that header by
default, and then a comments thing at the bottom.
Problem with asking for more opinions is that you may end up with
too many. Here is mine :-): I like the idea of a template, naively
I think this should simplify searches etc, I *much* prefer the
second template because it is not taking so much screen real estate,
and yet it contains all the info as the previous one. I'd like
entering a new tip or adding comments to existing one to be as simple as
possible, I'd prefer not to be forced to learn anything
to be able to post or update (in other words it should be obvious)
and ideally, a *normal* tip should fit on a screen, exceptions
accepted, comments can extend the whole tip over a screen.
In yet another words, I'd like to look at the screen and have
(almost) all info right there without scrolling etc (read: as much
as possible), so some big header doesn't fit my bill.
Thank you guys for doing this work!
Cheers,
---Zdenek
-
Zdenek Sekera | [EMAIL PROTECTED]
LHC Computing Grid Project | +41 76 487 4971 (mobile)
CERN, IT Department| +41 22 767 1068 (office)
CH-1211, Geneva 23, Switzerland
smime.p7s
Description: S/MIME cryptographic signature
RE: Vim Wiki - Wiki Template Proposal
-Original Message- From: Sebastian Menge [mailto:[EMAIL PROTECTED] Sent: 15 May 2007 13:49 To: Zdenek Sekera Cc: fREW; Tom Purl; vim@vim.org Subject: RE: Vim Wiki - Wiki Template Proposal Am Dienstag, den 15.05.2007, 10:03 +0200 schrieb Sebastian Menge: There is an extension called InbutBox but I have not understood yet howto use it. Now I have. There is a sample on http://scratchpad.wikia.com/wiki/VimTest This page gives error on page message during loading plus some other message, but all flashes so quickly at the bottom of the page that I couldn't get more than this. Then it looks like it loaded the whole page anyway but it's hard to say what's missing if anything. ---Zdenek smime.p7s Description: S/MIME cryptographic signature
RE: suggestion
-Original Message- From: Yongwei Wu [mailto:[EMAIL PROTECTED] Sent: 18 April 2007 10:30 To: Thomas Cc: vim@vim.org Subject: Re: suggestion On 4/18/07, Thomas [EMAIL PROTECTED] wrote: No. Delete the buffer, but keep the window open. Something like http://www.vim.org/tips/tip.php?tip_id=1078 Regards, Thomas. Ah, then one can simply use this script, and even add a command: command BC call Kwbd(1) Of course, it is a regret that one cannot use `bc', since all user defined commands must start with an uppercase letter. Coup de grace: map bc BC ---Zdenek smime.p7s Description: S/MIME cryptographic signature
RE: Vim freezes system ?!
-Original Message- From: A.J.Mechelynck [mailto:[EMAIL PROTECTED] Sent: 07 April 2007 05:46 To: Yakov Lerner Cc: vim@vim.org; Meino Christian Cramer; Bram Moolenaar Subject: Re: Vim freezes system ?! Yakov Lerner wrote: On 4/6/07, Yakov Lerner [EMAIL PROTECTED] wrote: On 4/6/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, I did th3 follwing: With a program, which generates random numbers in different formats, I created a file, which consists of _one_ line of 2097152 characters (0-9,A-F). To split the line into lines of 72 characters each, I started vim and let it read the file. I postioned the cursor at position 0 and entered the following in normal mode: qq72rightireturnesc0q Then I did a [EMAIL PROTECTED] After only 10 or 15 (guessed) executions of the macro the system freezes while constantly swapping (?) and became unuseable and did no longer respond. Even the mouse pointer was nearly unmoveable... After heavily and constantly trying I managed to kill the X- session and to 'killall -9 vim' from the console to get back my computer. Hello Meino the vim killer Cramer, I tried your scenario. You need to add 'set ul=-1' to disable undoes, and 'set lz' to disable excess redraws. Even then, vim goes rather slow at this task. Indeed, vim grows to 1000MB vm/rss size size in matter of one minute without ul=-1 (, and growing very fast. ) The thing I find strange here is that values of 'maxmem', 'maxmemtot' were: :set mm? mmt? maxmem=643272 maxmemtot=643272 , yet vim grew past x2.5 times that limits (with default 'ul') without messages. Is this expected behaviour ? Yakov I have maxmapdepth=1000 maxmempattern=1000 maxmem=249 maxmemtot=249 which strikes me as strange (even though the last three are in KB) since I never set them and the docs say maxmem is usually at least 256 and maxmemtot at least 2048. And I don't have a tiny bitty box: my total installed RAM is 2 GB. Just to add more to the confusion, on my box (RedHat Enterprise Linux, 512Mb Ram) I have maxmapdepth=1000 maxmempattern=1000 maxmem=257676 maxmemtot=257676 Which tells me the last two can hardly be in kb and all over I don't understand what really they mean. ---Zdenek smime.p7s Description: S/MIME cryptographic signature
RE: Vim freezes system ?!
-Original Message- From: A.J.Mechelynck [mailto:[EMAIL PROTECTED] Sent: 10 April 2007 09:10 To: Zdenek Sekera Cc: Yakov Lerner; vim@vim.org; Meino Christian Cramer; Bram Moolenaar Subject: Re: Vim freezes system ?! Zdenek Sekera wrote: [...] Just to add more to the confusion, on my box (RedHat Enterprise Linux, 512Mb Ram) I have maxmapdepth=1000 maxmempattern=1000 maxmem=257676 maxmemtot=257676 Which tells me the last two can hardly be in kb and all over I don't understand what really they mean. ---Zdenek According to the help, they _are_ in KB and can reach up to two million (i.e., 2 gig). I sure wonder according to what Vim sets themat startup. Why do you think they can't be in KB? The above would mean slightly over 256 meg, which sounds reasonable for a 512MB box (more reasonable at least, than the 249 K which I see). Arrgh, I guess the batteries in my mental calculator are flat after Easter vac :-). But what do these numbers really mean? You are right that mine look more acceptable than yours. Yours are really strange. ---Zdenek smime.p7s Description: S/MIME cryptographic signature
Re: paste staircasing
Ben K. wrote: Thanks much. On Fri, 9 Feb 2007, Hugh Sasse wrote: On Fri, 9 Feb 2007, Ben K. wrote: Hi, Whenever I paste something into vim, it gets staircased. Is there a way to avoid copy/paste being staircased even when I have ai, cin or si turned on? I Yes, set paste. See :he paste for more on this. Also :he pastetoggle is good I have in my .vimrc: nmap M-R :exe :undo|:set paste|:normal .:set nopaste set pastetoggle=f1 The first line of which is to redo a botched paste, the second of which is to make the F1 key turn this on an off. For me that only works in inset mode. Maybe someone can improve on this. I use this (it's in my .vimrc): # F9 - toggle paste #(must have 'pastetoggle' set) set pastetoggle=F9 toggle 'paste' option map F9:set invpaste paste?CR imap F9 C-O:set invpasteCRC-O/BS It works both i normal as well insert mode. Hit F9 in normal or insert mode and the 'paste' option will be inverted but also displayed at the bottom of your window. Stays until you hit F9 again. Regards, ---Zdenek smime.p7s Description: S/MIME Cryptographic Signature
RE: BOF Vim 8 - EncryptLine
From: [EMAIL PROTECTED] On 1/19/07, Matthew Winn [EMAIL PROTECTED] wrote: Gung'f ab tbbq. Erny areqf pna ernq ebg13 grkg jvgubhg hfvat fbsgjner. Hm. I don't understand. Is that some sort of encryption you're using? Garbled, typo somewhere or spellchecker goofed! :-) ---Zdenek smime.p7s Description: S/MIME cryptographic signature
Can somebody move my cursor?
Hi, this code is heavily influenced by vim.org tip #1363 getchar trick using recursive expr map by Hari Krishna Dara. Clever code. The code has also been posted on vim-dev recently. I just reworked it a bit to understand it better. - imap buffer silent expr F12 Double(\F12) function! Double(mymap) let char = GetChar() if char ==\Esc return \Esc.\C-R=Redraw()\CR return \Esc else return char.\C-R=Redraw()\CR.a:mymap endif endfunction function! Redraw() redraw return '' endfunction function! GetChar() try let char = getchar() catch Interrupt C-C and convert it into Esc catch /^Vim:Interrupt$/ let char = \Esc finally try throw char If the character typed is a number, convert it to character catch '^\d\+$' let char = nr2char(char) finally Return whatever was typed, or converted return char endtry endtry return char endfunction To execute: - source it in - go to Insert mode (a, i, o, ...) and start typing, observe that the cursor is inside the window at the place where the next typed-in char will be put (important). - now hit F12, the cursor will move to the bottom of the window and stay there but continue typing and characters will be placed correctly in the window. (Hit Esc to get out of INSERT.) Hence my question: how to move the cursor to the position as if one was in the normal INSERT mode? Thanks and regards, ---Zdenek smime.p7s Description: S/MIME Cryptographic Signature
RE: vim.org refreshed mockup
-Original Message- From: Gavin Gilmour [mailto:[EMAIL PROTECTED] Sent: 08 November 2006 09:51 To: Panos Laganakos Cc: vim@vim.org Subject: Re: vim.org refreshed mockup Seconding the Looks nice comments. Mee too, but the readability (the color set) still needs to be improved. ---Zdenek * Panos Laganakos [EMAIL PROTECTED] [2006-11-07 19:59:57 +0200]: I made a mockup of a refreshed version of vim.org, trying to maintain as much of the original look as possible: http://panos.solhost.org/mockups/vimorg-01.png vim tangofied icon by toZth -- Panos Laganakos
RE: Contextual 'iskeyword'?
-Original Message- From: Benji Fisher [mailto:[EMAIL PROTECTED] Sent: 17 October 2006 15:03 To: Vim users Subject: Re: Contextual 'iskeyword'? On Tue, Oct 17, 2006 at 05:43:08AM -0500, Tim Chase wrote: In some text, I've got compound words separated by a single hyphen. For convenience of yanking, I've added the hyphen to my iskeyword setting which works nicely for the most part. However, I also use a doubled-hyphen to the effect one would use an em-dash which leads to the unwanted situation that a yank of a word now includes the first word of the subordinate sentence structure--such as this where the dashes are doubled--and effects my ^N/^P searching (as duplicates appear for entries followed by the double-dash). I'm on the prowl for some way to keep the iskeyword behavior for things like doubled-hyphen and em-dash in the above paragraph, but exclude things like structure--such and doubled--and, limiting the word to things with a dash only if that dash is not repeated. Something like \w-\w but not \w-\+\w (assuming that - isn't part of iskeyword for this example) Any hints? Let's think big and look for a generic solution. IMHO, it is way too restrictive to insist that a word is anything matching the pattern /\k\+/ . I want a new option, 'wordpat', with a default value of '\k\+', that specifies what should be recognized as a word, for purposes of search patterns, Normal-mode commands such as w and b, and maybe other uses. (Oh, yes: Insert-mode completion.) Examples: :let l:wordpat = '\k\+\(-\k\+\)*' allows words-with-hyphens but--as requested--does not match double hyphens. Change the '*' to '\=' to allow no more than one hyphen per word. C programmers may like to use '\.' instead of '-'. :let l:wordpat = '\\\=\k\+' matches TeX commands like \def and \input and caters to the (lazy but common) style of omitting optional white space: $ \alpha\beta\gamma=\alpha+\beta+\gamma $. :let l:wordpat = '\a\l*' matches Capitalized words but rejects CamelCase words. What do you think? Would this solve enough problems to be worth the effort? How many vim users would add it to their wish lists? You + others + 1. ---Zdenek
RE: VimL and Exuberant tags - Suggestions please
-Original Message-
From: David Fishburn [mailto:[EMAIL PROTECTED]
Sent: 13 October 2006 02:16
To: vim@vim.org
Subject: VimL and Exuberant tags - Suggestions please
I have taken over maintenance of the VimL exuberant tags component.
That's excellent news, thanks for doing it, new features are
needed.
...
function autoloadFunc#subdirname#Funcname()
endfunction
Support for this has been added to the next version of ctags
(possibly 5.7).
Though I definitely do not like the autoload feature as implemented
(which is besides the point for ctags discussion) I think
this support is needed.
...
These are the items ctags currently flags:
augroup, autocommand groups
function, function definitions
variable, variable definitions
Does it make sense to also identify autocommands?
Or possibly only autocommands if they are outside of an augroup?
I think so. The good way could be to make it toggable
(is this english :-)?), choose what one wants to get out.
When variables are identified we strip off the scope:
let s:ignoreNextCursorMovedI = 0 == ignoreNextCursorMovedI
Should the scope be left on == s:ignoreNextCursorMovedI
This is hard, don't know. Both have their advantages and
disadvantages, maybe that depends what one needs at the
moment. I'd go for keeping the scope, though the prefix
itself isn't a guarantee (variable inside a function is local,
outside is global , that's without l: and g:, just as examples).
Instead of simply grouping everything under variables, should
we distinguish
between different types?
let forms#form = {
\ 'title': 'Address Entry Form',
\ 'fields': [],
\ 'defaultbutton': 'ok',
\ 'fieldMap': {},
\ 'hotkeyMap': {},
\ }
Right now this is identified as a variable, should we identify it as a
Dictionary by adding another kind of tag?
I vote yes.
What about identifying commands:
command! -nargs=+ Select :call s:DB_execSql(select
. q-args)
Most certainly.
What about [ion]maps (though we cannot give them a name
really, but at least
identifying where they are in the source?
Yes yes, I was already looking at the ctags code with this
idea in mind, I think this would be very useful.
We could also pick up local variables (have this off by
default) and produce
something like this:
function! s:DB_runCmd(cmd, sql)
let l:display_cmd_line = 'blah'
let display_shell = 'blah'
endf
Local variables
s:DB_runCmd.display_cmd_line
s:DB_runCmd.display_shell
If you can distinguish scopes, that's excellent!
...
At this point the sky is the limit, we can hash out details as we move
forward. Somethings might not be worth the effort.
Clearly, your call.
---Zdenek
RE: [help?] ezmlm warning
I got exactly the same message. No explanation, such messages come occassionally, very annoying. ---Zdenek -Original Message- From: Max Dyckhoff [mailto:[EMAIL PROTECTED] Sent: 05 September 2006 17:48 To: vim@vim.org Subject: [help?] ezmlm warning Has anyone else had this problem? Looking at the bounce message at the bottom shows that 131.107.1.8 (Microsoft's mail server) doesn't like 160.45.45.151 (is this the mailing list server?) because it is listed on spamcop (although a quick check of spamcop shows that isn't true). Anything I should be doing? Cheers, Max -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 05, 2006 8:36 AM To: Max Dyckhoff Subject: ezmlm warning Hi! This is the ezmlm program. I'm managing the vim@vim.org mailing list. Messages to you from the vim mailing list seem to have been bouncing. I've attached a copy of the first bounce message I received. If this message bounces too, I will send you a probe. If the probe bounces, I will remove your address from the vim mailing list, without further notice. I've kept a list of which messages from the vim mailing list have bounced from your address. Copies of these messages may be in the archive. To retrieve a set of messages 123-145 (a maximum of 100 per request), send an empty message to: [EMAIL PROTECTED] To receive a subject and author list for the last 100 or so messages, send an empty message to: [EMAIL PROTECTED] Here are the message numbers: 68464 ... 68686 --- Enclosed is a copy of the bounce message I received. Return-Path: Received: (qmail 658 invoked for bounce); 24 Aug 2006 21:56:46 - Date: 24 Aug 2006 21:56:46 - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: failure notice Hi. This is the qmail-send program at foobar.math.fu-berlin.de. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. [EMAIL PROTECTED]: 131.107.1.8 does not like recipient. Remote host said: 550 5.7.1 Email rejected because 160.45.45.151 is listed by bl.spamcop.net. Please see http://www.spamcop.net/bl.shtml for more information. If you still need assistance contact [EMAIL PROTECTED] Giving up on 131.107.1.8.
Know when the :source/:runtime has finished ?
Perhaps a strange question so maybe a small explanation of why is in order: When I :source or :runtime a *.vim file, commands in that file build a buffer. To know when the buffer is complete, I have to know what follows, and if complete (because the following has an indicator of the start of a new buffer) add it to a vim variable g:xxx and start a new buffer. In essence I have to always know ahead. Clearly the last buffer will not be ever complete because there is nothing to tell me it should be completed. There is nothing read from *.vim, since the :source ran to its end. I can handle that last buffer only when I start using the g:xxx variable and find out the buffer is not empty and then add it to g:xxx. That complicates the algorithm quite a bit so I was thinking is there a way to know :source or :runtime has finished? I was thinking of some autocmd, but unfortunately the only event of interest in this context I found is 'SourcePre' but no 'SourceAfter' which would ideal. Would anyone have an idea how to recognize the end of :source/:runtime? Thanks, ---Zdenek
RE: Irritating column numbers with encoding=utf-8
-Original Message-
From: Jürgen Krämer [mailto:[EMAIL PROTECTED]
Sent: 06 July 2006 08:01
To: vim mailing list
Subject: Re: Irritating column numbers with encoding=utf-8
Hi,
Bram Moolenaar wrote:
Jürgen Krämer wrote:
with 'encoding' set to utf-8 there is a quite confusing (to me)
difference between the column number and my expectations
(supported by
the virtual column number) if there are non-ASCII characters on the
line. I don't know what the intended meaning of column
count and the
intended behaviour of cursor() are, but it seems they
both depend on
the size of the encoded characters. I always thought nth
column was
more or less a synonym for nth character on a line while
nth virtual
column meant nth cell on a screen line.
[snipped
I don't know whether the shown behaviour is a bug or just
a feature I
don't like, but in summary I think column number should really
represent a character count (i.e, corresponding to what
the user sees),
not a byte count depending on the underlying encoding.
I have seen this behaviour in VIM 6.2, 6.3, 6.4, and 7.0,
so changing
the code will definitely introduce an incompatibility. So the final
question is: What do you (Vimmers) and you (Bram) think:
is there a need
for a change.
I don't know why you call this a column count, in most places it's
called a byte count. Perhaps in some places in the docs the remark
about this actually being a byte count is missing.
sorry, the column count in the first paragraph should have been a
column number. I called it so because I have the statusline
option set
to
%%f%= [%1*%M%*%{','.fileformat}%R%Y] [%6l,%4c%V] %3b=0x%02B %P
and noticed that %4c-%V displayed two numbers instead of the one I
expected, because I knew there were no tabs or unprintable characters
on that line. Even more disturbing was the fact that the first number
(the column number) was bigger than the second one (the virtual column
number). So I checked :help statusline and it told me
c N Column number.
v N Virtual column number.
V N Virtual column number as -{num}. Not displayed
if equal to 'c'.
You could also want a character count. But what is a character when
using composing characters? E.g., when the umlaut is not
included in
a character but added as a separate composing character?
I would say that a character is what the user sees. Why should he (be
forced to) know wheter ä is represented internally as LATIN SMALL
LETTER A WITH DIAERESIS or as LATIN SMALL LETTER A plus COMBINING
DIARESIS? So in my opinion column count is equivalent to character
count unless there are characters like tabs and unprintable ones that
have a special representation -- on the screen, not internally.
It's not so obvious what to do. In these situations I
rather keep it as
it is.
I know it's a big change and would introduce imcompatibiliy with older
versions, but here is another example: Take this line (ignoring the
leading spaces)
ääbbcc
and the following commands
:s/\%3c../xx/
%s/^..\zs../xx/
From my point of view they should both replace the 3rd and 4th column
with xx. When encoding is set to latin1 they do, but not when it is
set to utf-8 -- the first one replaces äb with xx. As a
user I would
be really stumbled and ask Why that, it's the same text as before.
Changing these commands to
:s/\%2c../xx/
%s/^.\zs../xx/
makes things even more irritating. The second one works as
expected, now
correctly replacing äb with xx, but the first one fails
with E486:
Pattern not found: \%2c... Again: Ought I (as a user) really need to
know that \%2c depends on the number of non-ASCII letters in front of
the column I'm interested in?
Yes, this is indeed very unexpected IMHO and as you say
mighty irritating. I find it very hard to disagree with
your arguments. This should be changed IMHO, even if
it surely is a big change.
---Zdenek
RE: MatchParen unreadable on dark backgrounds
From: Benjamin Esham [mailto:[EMAIL PROTECTED] Sent: 03 June 2006 05:41 To: Yakov Lerner Cc: vim@vim.org Subject: Re: MatchParen unreadable on dark backgrounds Yakov Lerner wrote: Georg Dahn wrote: This depends on the color scheme you are using. If the maintainer does not update his color scheme, a default value is chosen. If the background is darkcyan, the highlight is not visible, of course, if the background is blue, then your value is a bad choice. I don't think any single colorscheme defines MatchParen. I haven't seen any single colorscheme that define MatchParen. Do they ? Biogoo (http://vim.sourceforge.net/scripts/script.php?script_id=432) defines these groups. It's quite a nice combination of colors, if I do say so myself ;-) /shameless plug Too bad that the screen shot in the above URL has invalid link problem. ---Zdenek
RE: CurorLine, set cursorline: slow, slower, slowest ?!
-Original Message- From: Charles E Campbell Jr [mailto:[EMAIL PROTECTED] Sent: 02 June 2006 16:19 To: vim@vim.org Subject: Re: CurorLine, set cursorline: slow, slower, slowest ?! Zdenek Sekera wrote: -Original Message- From: Meino Christian Cramer [mailto:[EMAIL PROTECTED] Sent: 18 May 2006 18:43 To: [EMAIL PROTECTED] Subject: Re: CurorLine, set cursorline: slow, slower, slowest ?! From: Yakov Lerner [EMAIL PROTECTED] Subject: Re: CurorLine, set cursorline: slow, slower, slowest ?! Date: Thu, 18 May 2006 11:56:52 + On 5/18/06, Meino Christian Cramer [EMAIL PROTECTED] wrote: Hi, VIM has a neat feature to highlight the line the cursor is in. This makes reading wide texts easier. Unfortunatley (at least with my system) moving the cursor become very slow. Is there a way out (a config trich for example) or any other thing to get a fast cursor in a highlighted line ? I am using: xterm-256color mrxvt linux 2.6.16-16 AMD X2 64 3800+ vim7.0.017 I just tried scrolling with cursorline it on a maximixed terminal (74 lines, 203 columns) and it's *not* slow for me. I tried xterm, Konsole, mrxvt, and urxvt. Yakov Hi Yakov, thank you for your reply. I forgot to mention that I am using vim, not gvim (!) and that in my colorscheme the following was set: hi Normal ctermbg=lightgray ctermfg=Black hi CursorLine ctermbg=White guibg=Grey90 What do you uses for your speedy vim ? :O) Unfortunately, I have to confirm the original problem. Running xterm-256colors with xterm16 colorscheme in the xterm, when the cursorline is highlighted, the cursor movement becomes both slow and erratic. Hmmm -- with a Dell Precision machine, linux (FC5), astronaut colorscheme, and a xterm-256, I see no problem with either or both cursorline and/or cursorcolumn. I must admit I am *very* confused now: 1.I used 'astronaut', after :set cursorline the line is just underlined (not really highlighted, why?) but I have no problem with cursor movements. 2.Just to confirm my previous affirmation I went back to xterm16 colorscheme and have also *no* problem with cursor movement after :set cursorline. This is in contradiction with my previous statement above. I have no explanation for it, at all. The line is however, properly highlighted, not only underlined. Both test were doen under exactly the same conditions except for the colorscheme, RH ES, vim in xterm-256. ---Zdenek
source, runtime and all that
I'd like to before :sourc'ing a file to execute
one of my scripts (always the same).
I though the autocmd 'SourcePre' event will
help nut I can't get it work the way I'd needed it:
As a first test I did:
:au SourcePre *.vim let g:sfile=afile
then amatch (I know sfile will not
work before it gets expanded too early)
If I now do :source test.vim
which contains just 'echo g:sfile'
I get errors about invalid expression afile
or amatch depending what I used for :au.
The idea was to get the file name in g:sfile of the
file which is about to be sourced so I can call my
function (in that autocmd) to process the file
before it's :sourced.
How can this be done?
I also thought 'runtime' is somehow equivalent
to :source, except it is smart enough
to use 'runtimepath'. Using the same test above
(':runtime test.vim') I found this does *not*
fire up the autocmd while :source does.
Is this intentional or can it be considered a bug?
---Zdenek
Zdenek Sekera | [EMAIL PROTECTED]
LHC Computing Grid Project | mobile: +41-76-487.4971
CERN - IT Division | tel:+41-22-767.1068
RE: source, runtime and all that
-Original Message-
From: Eric Arnold [mailto:[EMAIL PROTECTED]
Sent: 26 May 2006 16:07
To: Zdenek Sekera
Cc: vim-dev@vim.org
Subject: Re: source, runtime and all that
On 5/26/06, Eric Arnold [EMAIL PROTECTED] wrote:
Try expanding it.
au SourcePre *.vim echomsg afile= . expand(afile)
au SourcePre *.vim let @a = afile
au SourcePre *.vim let @a = expand(afile )
That works nicely. Thanks!
Any idea about that runtime problem?
---Zdenek
On 5/26/06, Zdenek Sekera [EMAIL PROTECTED] wrote:
I'd like to before :sourc'ing a file to execute
one of my scripts (always the same).
I though the autocmd 'SourcePre' event will
help nut I can't get it work the way I'd needed it:
As a first test I did:
:au SourcePre *.vim let g:sfile=afile
then amatch (I know sfile will not
work before it gets expanded too early)
If I now do :source test.vim
which contains just 'echo g:sfile'
I get errors about invalid expression afile
or amatch depending what I used for :au.
The idea was to get the file name in g:sfile of the
file which is about to be sourced so I can call my
function (in that autocmd) to process the file
before it's :sourced.
How can this be done?
I also thought 'runtime' is somehow equivalent
to :source, except it is smart enough
to use 'runtimepath'. Using the same test above
(':runtime test.vim') I found this does *not*
fire up the autocmd while :source does.
Is this intentional or can it be considered a bug?
---Zdenek
Zdenek Sekera | [EMAIL PROTECTED]
LHC Computing Grid Project | mobile: +41-76-487.4971
CERN - IT Division | tel:+41-22-767.1068
RE: set readonly - strange?
-Original Message-
From: Eric Arnold [mailto:[EMAIL PROTECTED]
Sent: 23 May 2006 18:12
To: Yakov Lerner
Cc: Zdenek Sekera; vim-dev@vim.org
Subject: Re: set readonly - strange?
As far as I can tell, there are several instances where there are
transitory buffers as vim is starting, opening a new tab, probably
some in closing op.s.
That may be true, but...
I don't know if I used the right word by saying the buffer is
undefined, but I don't think it it's guaranteed to be usable until a
certain point, which is after -u, and at the first file loaded, i.e.
-c
If you open a buffer explicitly from inside .vimtest , then that's a
different story.
In my test case, buffer must exist, I am well passed the '-u ...'
phase because I can *see* the buffer when I do :set readable?'.
I think Yakov's test case is saying even more.
It's kinda bug-ish, but it's not a bug unless it's contrary to stated
behavior. It'll be interesting to see how Bram addresses it.
I also think it is bug.
---Zdenek
On 5/23/06, Yakov Lerner [EMAIL PROTECTED] wrote:
On 5/23/06, Zdenek Sekera [EMAIL PROTECTED] wrote:
create a file ~/.vimtest as follows:
cat .vimtest
set nocompatible
set readonly
C-D
and execute (g)vim:
vim .vimtest -u .vimtest
try :set readonly? and you'll get 'noreadonly'.
The buffer does exist when initfile is executed. The ':ls'
in initfile shows it.
Adding more printouts to initfile shows interesting results:
vim -u 1 1
- file called 1 ---
set nocompatible
ls
call input('before set readonly 111')
set readonly
set readonly?
ls
set readonly?
set readonly?
echo readonly=.readonly
call input('after set readonly 222')
-
In vim, ':verb set readonly?' shows that readonly is
misteriously reset.
The output differs between vim6 and vim7.
--- vim7 output --
1 %1line 1
before set readonly 111
1 % = 1line 1
readonly=1
after set readonly 222
Note the missing output of ':set readonly?'!!! It prints neither
'readonly' nor 'noreadonly'.
- vim6 output
1 %1line 1
before set readonly 111
before set readonly 111
1 % = 1line 1
readonly
readonly
readonly=1
after set readonly 222
-
Looks like a bug to me.
Yakov
RE: set readonly - strange?
-Original Message-
From: Eric Arnold [mailto:[EMAIL PROTECTED]
Sent: 24 May 2006 11:21
To: Zdenek Sekera
Cc: Yakov Lerner; vim-dev@vim.org
Subject: Re: set readonly - strange?
On 5/24/06, Zdenek Sekera [EMAIL PROTECTED] wrote:
-Original Message-
From: Eric Arnold [mailto:[EMAIL PROTECTED]
Sent: 23 May 2006 18:12
To: Yakov Lerner
Cc: Zdenek Sekera; vim-dev@vim.org
Subject: Re: set readonly - strange?
As far as I can tell, there are several instances where there are
transitory buffers as vim is starting, opening a new tab, probably
some in closing op.s.
That may be true, but...
I don't know if I used the right word by saying the buffer is
undefined, but I don't think it it's guaranteed to be
usable until a
certain point, which is after -u, and at the first file
loaded, i.e.
-c
If you open a buffer explicitly from inside .vimtest ,
then that's a
different story.
In my test case, buffer must exist, I am well passed the '-u ...'
phase because I can *see* the buffer when I do :set readable?'.
I think Yakov's test case is saying even more.
It's not clear that the buffer exists when the :set ro command is
read according to the -u option, though it might exist in some form
since no error occurs. Even if a buffer does exist at that time, I'm
fairly sure that is was transitory, and that it's not the same buffer
that you actually see and type :set ro? at.
Secondly, you need to be past the -c or similar stage, where it states
that files have been loaded. It doesn't say that for -u.
You *are* past the loading state when you type :set ro? , but that's
not the same as when the -u file is processed.
I don't know to that depth as you do, but then we should
agree that 'set readonly' in .vimrc is useless, because
it would never work, right?
This is hard to accept. So it looks more and more just as a bug.
---Zdenek
It's kinda bug-ish, but it's not a bug unless it's
contrary to stated
behavior. It'll be interesting to see how Bram addresses it.
I also think it is bug.
---Zdenek
On 5/23/06, Yakov Lerner [EMAIL PROTECTED] wrote:
On 5/23/06, Zdenek Sekera [EMAIL PROTECTED] wrote:
create a file ~/.vimtest as follows:
cat .vimtest
set nocompatible
set readonly
C-D
and execute (g)vim:
vim .vimtest -u .vimtest
try :set readonly? and you'll get 'noreadonly'.
The buffer does exist when initfile is executed. The ':ls'
in initfile shows it.
Adding more printouts to initfile shows interesting results:
vim -u 1 1
- file called 1 ---
set nocompatible
ls
call input('before set readonly 111')
set readonly
set readonly?
ls
set readonly?
set readonly?
echo readonly=.readonly
call input('after set readonly 222')
-
In vim, ':verb set readonly?' shows that readonly is
misteriously reset.
The output differs between vim6 and vim7.
--- vim7 output --
1 %1line 1
before set readonly 111
1 % = 1line 1
readonly=1
after set readonly 222
Note the missing output of ':set readonly?'!!! It prints neither
'readonly' nor 'noreadonly'.
- vim6 output
1 %1line 1
before set readonly 111
before set readonly 111
1 % = 1line 1
readonly
readonly
readonly=1
after set readonly 222
-
Looks like a bug to me.
Yakov
RE: set readonly - strange?
-Original Message-
From: Eric Arnold [mailto:[EMAIL PROTECTED]
Sent: 24 May 2006 12:38
To: Zdenek Sekera
Cc: vim-dev@vim.org
Subject: Re: set readonly - strange?
I think 'readonly' does not belong in the .vimrc since it is a
buffer-local-only option.
Yes, but I have only one buffer...
However, you can use an autocommand to set it. What are you really
trying to do from the .vimrc ? Setting the readonly value for the
default empty starting buffer seems odd, and you can manage the
reaonly property several ways for files actually loaded into buffers.
Clearly, my example was a case simplyfied to the utmost,
but describing what I really want to do: display a buffer
for reading only. My real '.vimtest' has many more options,
of course, so I thought I can this one into it as well
(just as I wanted 'modifiable', 'modified', and more).
This was to make things simple, start 'vim -u this that'.
Since that doesn't work for some of those settings, I'll
have to settle for another way like 'vim -R ...'.
I wanted to avoid any additional parameter on the vim call
(for some reasons), but I have to now change my mind.
You maybe right it doesn't belong to '.vimrc', but that's
not explicitly stated anywhere (and for others), hence
my trying and discovering a hole, perhaps a bug.
Wouldn't you think that it should apply always to at least
the first buffer on the vim call? Or all if it's in .vimrc?
The implementation is not clear IMHO, perhaps the doc needs
some update.
It will be indeed interesting to see what will Bram decide
about it. Let's wait.
---Zdenek
On 5/24/06, Zdenek Sekera [EMAIL PROTECTED] wrote:
-Original Message-
From: Eric Arnold [mailto:[EMAIL PROTECTED]
Sent: 24 May 2006 11:21
To: Zdenek Sekera
Cc: Yakov Lerner; vim-dev@vim.org
Subject: Re: set readonly - strange?
On 5/24/06, Zdenek Sekera [EMAIL PROTECTED] wrote:
-Original Message-
From: Eric Arnold [mailto:[EMAIL PROTECTED]
Sent: 23 May 2006 18:12
To: Yakov Lerner
Cc: Zdenek Sekera; vim-dev@vim.org
Subject: Re: set readonly - strange?
As far as I can tell, there are several instances
where there are
transitory buffers as vim is starting, opening a new
tab, probably
some in closing op.s.
That may be true, but...
I don't know if I used the right word by saying the buffer is
undefined, but I don't think it it's guaranteed to be
usable until a
certain point, which is after -u, and at the first file
loaded, i.e.
-c
If you open a buffer explicitly from inside .vimtest ,
then that's a
different story.
In my test case, buffer must exist, I am well passed
the '-u ...'
phase because I can *see* the buffer when I do :set readable?'.
I think Yakov's test case is saying even more.
It's not clear that the buffer exists when the :set ro
command is
read according to the -u option, though it might exist in
some form
since no error occurs. Even if a buffer does exist at
that time, I'm
fairly sure that is was transitory, and that it's not the
same buffer
that you actually see and type :set ro? at.
Secondly, you need to be past the -c or similar stage,
where it states
that files have been loaded. It doesn't say that for -u.
You *are* past the loading state when you type :set ro?
, but that's
not the same as when the -u file is processed.
I don't know to that depth as you do, but then we should
agree that 'set readonly' in .vimrc is useless, because
it would never work, right?
This is hard to accept. So it looks more and more just as a bug.
---Zdenek
It's kinda bug-ish, but it's not a bug unless it's
contrary to stated
behavior. It'll be interesting to see how Bram addresses it.
I also think it is bug.
---Zdenek
On 5/23/06, Yakov Lerner [EMAIL PROTECTED] wrote:
On 5/23/06, Zdenek Sekera [EMAIL PROTECTED] wrote:
create a file ~/.vimtest as follows:
cat .vimtest
set nocompatible
set readonly
C-D
and execute (g)vim:
vim .vimtest -u .vimtest
try :set readonly? and you'll get 'noreadonly'.
The buffer does exist when initfile is executed. The ':ls'
in initfile shows it.
Adding more printouts to initfile shows interesting results:
vim -u 1 1
- file called 1 ---
set nocompatible
ls
call input('before set readonly 111')
set readonly
set readonly?
ls
set readonly?
set readonly?
echo readonly=.readonly
call input('after set readonly 222')
-
In vim, ':verb set readonly?' shows that readonly is
misteriously reset.
The output differs between vim6 and vim7
RE: Pattern questions
Hi, Benji
On Tue, May 23, 2006 at 02:22:32PM +0200, Zdenek Sekera wrote:
if (char =~ '\m[;|?:[EMAIL PROTECTED]*(){}\\_+-[\]/\]')
do something
endif
2. why when the pattern ends with '+' or '\+' do I get
an error?
Can you be more specific? I tried
:let char = a
:echo char =~ '\m[;|?:[EMAIL PROTECTED]*(){}\\_+-[\]/\]+'
:echo char =~ '\m[;|?:[EMAIL PROTECTED]*(){}\\_+-[\]/\]\+'
Sorry, I should have been clearer:
Note the placement of the '+' in my pattern, somewhere
in the middle, there it doesn't cause any problem:
if (char =~ '\m[;|?:[EMAIL PROTECTED]*(){}\\_+-[\]/\]'
^
| here
The erroneous (in my judgement) patterns are (e.g.) are these:
if (char =~ '\m[;|?:[EMAIL PROTECTED]*(){}\\_-[\]/\+]')
if (char =~ '\m[;|?:[EMAIL PROTECTED]*(){}\\_-[\]/\\+]')
So the question is why is it OK to have '+' in the middle
and not at the end?
---Zdenek
RE: Pattern questions
-Original Message-
From: Charles E Campbell Jr [mailto:[EMAIL PROTECTED]
Sent: 24 May 2006 15:55
To: Zdenek Sekera
Cc: vim-dev@vim.org
Subject: Re: Pattern questions
Zdenek Sekera wrote:
Sorry, I should have been clearer:
Note the placement of the '+' in my pattern, somewhere
in the middle, there it doesn't cause any problem:
if (char =~ '\m[;|?:[EMAIL PROTECTED]*(){}\\_+-[\]/\]'
^
| here
The erroneous (in my judgement) patterns are (e.g.) are these:
if (char =~ '\m[;|?:[EMAIL PROTECTED]*(){}\\_-[\]/\+]')
if (char =~ '\m[;|?:[EMAIL PROTECTED]*(){}\\_-[\]/\\+]')
So the question is why is it OK to have '+' in the middle
and not at the end?
It has nothing to do with +, and everything to do with - .
The - is a
range character,
more commonly seen with something like [a-z] (which stands
for all lower
case characters).
You need to escape the minus sign (ie. \-).
Ops, I missed that one. Obvious! Thanks.
---Zdenek
RE: Pattern questions
-Original Message-
From: A.J.Mechelynck [mailto:[EMAIL PROTECTED]
Sent: 23 May 2006 14:22
To: Zdenek Sekera
Cc: vim-dev@vim.org
Subject: Re: Pattern questions
Zdenek Sekera wrote:
I have this:
if (char =~ '\m[;|?:[EMAIL PROTECTED]*(){}\\_+-[\]/\]')
do something
endif
Basically it is checking for all non-alphanumeric chars
(expect '=').
1. how do I include the ' char?.
I can't seem to find a proper way.
(I'd like to keep the patter in enclosed in '...')
2. why when the pattern ends with '+' or '\+' do I get
an error?
---Zdenek
1. Starting with version 7, you can have a single quote in a
single-quoted string by doubling the single quote. Thus, (four
single quotes) represents one single quote and 'a''b' (quote a quote
quote b quote) is a string consisting of the letters a and b with a
single quote between them.
Arrrgh, missed that in the doc somewhere, I'm running vim7
(I forgot to say so)
In all versions, you can concatenate strings, and a single
quote can be
enclosed in a double-quoted string. Thus, '' . ' (single double
single space dot space double single double) is an expression whose
value is a String consisting of a double quote followed by a
single quote.
Arrrgh :-), that I new but didn't think of.
2. I don't know, but I think it's either a bug, or documented under
:help pattern.txt somewhere.
My feelings, too, but I can't find it anywhere in the pattern.txt
(and I printer the newest on purpose :-)!
Thanks, Tony, for help.
---Zdenek
set readonly - strange?
create a file ~/.vimtest as follows: cat .vimtest set nocompatible set readonly C-D and execute (g)vim: vim .vimtest -u .vimtest try :set readonly? and you'll get 'noreadonly'. Looks strange at the minimum, bug? ---Zdenek
RE: Pattern questions
-Original Message-
From: Yakov Lerner [mailto:[EMAIL PROTECTED]
Sent: 23 May 2006 11:37
To: Zdenek Sekera; vim mailing list
Subject: Re: Pattern questions
On 5/23/06, Zdenek Sekera [EMAIL PROTECTED] wrote:
I have this:
if (char =~ '\m[;|?:[EMAIL PROTECTED]*(){}\\_+-[\]/\]')
do something
endif
Basically it is checking for all non-alphanumeric chars
(expect '=').
1. how do I include the ' char?.
I can't seem to find a proper way.
(I'd like to keep the patter in enclosed in '...')
let pat='[;|?:[EMAIL PROTECTED]*(){}\\_+-[\]/\'.'.']'
Thanks, Tony suggested similar solution.
---Zdenek
RE: clearing the command line
-Original Message- From: Eric Arnold [mailto:[EMAIL PROTECTED] Sent: 18 May 2006 15:09 To: vim.org user list Subject: clearing the command line I''ve been chasing this for a while, so I might as well ask, even though it seems like a stupid question. What's the right way to clear the command line between echo blocks in a script, without causing a full screen redraw? Everything I try eventually fails when the command line has been scrolled/grown upwards by output longer than cmdheight. I can't see the exact rule, since some things like: echo :CR normal : etc., come close, but no cigar. Not sure if it helps, but try this: :map ,x :let a=10CR and execute it by ',x' (no apostrophies) and then see for comparison this: :map ,x :let a=10CR/BS execute and see the difference. Is it something you were looking for? ---Zdenek
RE: updated strtrans() patch for special keys
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 12 May 2006 21:45
To: Eric Arnold
Cc: vim-dev@vim.org
Subject: Re: updated strtrans() patch for special keys
Eric Arnold wrote:
The doc page really only talks about regular control chars, leaving
the problem of special keys to the imagination. Are they to be
considered a string of characters which are to be evaluated
individually against 'isprint', or are they a
meta-character which is
to be evaluated against 'isprint'?
strtrans({expr})*strtrans()*
The result is a String, which is {expr} with
all unprintable
characters translated into printable characters
|'isprint'|.
Like they are shown in a window. Example:
echo strtrans(@a)
This displays a newline in register a as ^@ instead of
starting a new line
However, if you have a s-leftmouse, then having
€ü=02€ý,
show up in your window doesn't seem to be in the spirit of all
unprintable characters translated. Yes, the individual
components of
the string are in the @,~-255 range, but the key represented (left
mouse) is not.
The function does not have the purpose of showing key codes. It is
really only to turn a string into something without non-printable
characters. That's it.
The byte sequences used for a special character may also appear in a
file or in a file name, they must not be interpreted as a special key
then.
If you really want to convert a byte sequence to special key names
another function would need to be used.
But why? Is it really the best choice to have different
function names for things that are so similar in their substance?
IMHO, the options to strtrans as suggested by E.A. would
fit the bill well and I would have to remember another
function name, another :h, etc.
---Zdenek
RE: Inexplicable Error Running Script
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 10 May 2006 05:27 To: Vim mailing list Subject: Inexplicable Error Running Script I notice that a script I sometimes use to automatically check in files with RCS when I save a file gives error under the new Vim 7.x but did not under Vim 6.4. Here is the script: Begin script autoci if version = 600 if has(autocmd) syntax enable function! s:RCSCheckIn() cd %:p:h exe '!ci -l -m'.strftime(%Y %b %d %X).' -t- %:t' cd - endfuction ^n (endfunction) This is your problem throughout. Don't know why would it work in 6.4, it shouldn't have. ---Zdenek function! s:HiStatusLines() hi StatusLine ctermfg=0 ctermbg=1 guifg=Black guibg=Red term=bold hi StatusLineNC ctermfg=0 ctermbg=1 guifg=Black guibg=DarkGreen endfuction ^n augroup autoci au! autocmd BufWrite * exe 'silent call sidRCSCheckIn()' autocmd FileType * exe 'silent call sidHiStatusLines()' augroup END endif has(autocmd) endif E n d script autoci When I source this script under Vim 7.0 I receive the following errors: line 20: E126: Missing :endfunction line 21: E171: Missing :endif I have :endfunction and :endif commands for each :function and :if command so I do not understand why I am getting the error. Does it have something to do with defining function inside the scope of an :if statement? I compiled Vim 7.0 myself so I suppose I might have messed something up. I have enabled the Perl interpreter and CScope features using configure but otherwise done a straight forward compile. Here is the output of the :version command: VIM - Vi IMproved 7.0 (2006 May 7, compiled May 9 2006 22:25:48) Compiled by [EMAIL PROTECTED] Normal version with GTK2 GUI. Features included (+) or not (-): -arabic +autocmd +balloon_eval +browse +builtin_terms +byte_offset +cindent +clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments +cryptv +cscope +cursorshape +dialog_con_gui +diff +digraphs +dnd -ebcdic -emacs_tags +eval +ex_extra +extra_search -farsi +file_in_path +find_in_path +folding -footer +fork() +gettext -hangul_input +iconv +insert_expand +jumplist -keymap -langmap +libcall +linebreak +lispindent +listcmds +localmap +menu +mksession +modify_fname +mouse +mouseshape -mouse_dec +mouse_gpm -mouse_jsbterm -mouse_netterm +mouse_xterm +multi_byte +multi_lang -mzscheme +netbeans_intg -osfiletype +path_extra +perl +postscript +printer -profile -python +quickfix +reltime -rightleft -ruby +scrollbind +signs +smartindent -sniff +statusline -sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white -tcl +terminfo +termresponse +textobjects +title +toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo +vreplace +wildignore +wildmenu +windows +writebackup +X11 -xfontset +xim +xsmp_interact +xterm_clipboard -xterm_save system vimrc file: $VIM/vimrc user vimrc file: $HOME/.vimrc user exrc file: $HOME/.exrc system gvimrc file: $VIM/gvimrc user gvimrc file: $HOME/.gvimrc system menu file: $VIMRUNTIME/menu.vim fall-back for $VIM: /usr/local/share/vim Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -I/opt/gnome/include/gtk-2.0 -I/opt/gnome/lib/gtk-2.0/include -I/usr/X11R6/include -I/opt/ gnome/include/atk-1.0 -I/opt/gnome/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/freetype2/config -I/opt/gnome/include/glib-2.0 -I/opt/gnome/lib/glib-2.0/include -g -O2 -I/usr/X11 R6/include -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -pipe -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/lib/perl5/5.8.5/i586-linux-thread-multi/CORE Linking: gcc -L/opt/gnome/lib -L/usr/X11R6/lib -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.8.5/i586-linux-thread-multi/CORE -L/usr/local/lib -o vim -Wl,--export-dynamic -L/opt/gnome/lib -lgtk-x11-2 .0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lXt -lncurses -lgpm -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.8.5/i586-linux- thread-multi/CORE /usr/lib/perl5/5.8.5/i586-linux-thread-multi/auto/DynaLoader/D ynaLoader.a -L/usr/lib/perl5/5.8.5/i586-linux-thread-multi/CORE -lperl -lm -lutil -lc Press ENTER or type command to continue
list - string conversion confusion
This is formatted as a script that you can cut run. The - indicates the output of the 'echo' command. Ignore comments at the beginning of the line, they are there only to prevent useless errors. -- [script start] let a = [[1,2], [3,4]] echo a - [[1,2], [3,4]] This works echo list a=.a E730: using List as a String E15: Invalid expression: list a=.a So no conversion list-string is done here echo list a=a - list a= [[1,2], [3,4]] This works, but why? Isn't this also concatenation of two strings? Note: it adds a blank after '=' sign, why? This gets more obscure as you go on IMHO: let c=a[1] echo c - [3,4] That's OK echo list c=.c - I get the same error, not surprising - E730: using List as a String - E15: Invalid expression: list c=.c echo list c=c a[0] - list c= [3,4] [1,2] This also works, seems to me also a mixture of string and list so it shouldn't work, or is it correct? let d=c[0] echo d - 3 Correct echo list d=.d - list d=3 So here it works? 'd' is suddenly considered a string? While it was obtained from the list? echo list d=d - list d= 3 That works, too, with additional blank after '=' --- [script end] --- The last two cases are confusing the whole issue. So when a string and a list can be mixed, when not, what are the rules, or are some of the above bugs? ---Zdenek
RE: list - string conversion confusion
I am beginning to understand a bit more but not quite all yet: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] [...] echo list a=a - list a= [[1,2], [3,4]] This works, but why? Isn't this also concatenation of two strings? Note: it adds a blank after '=' sign, why? This is not concatenation, this is listing a string and a list separately. OK, got it, so is adding a blank correct? (I verified it happens always when using this form without a '.', not related to echo'ing lists). Like this: let q=1 :echo q=q - q= 1 but to confuse the thing: :echo q= q - q= 1 So it ignores all blanks in the echo. Probably OK if it didn't always add 1 when there is no blank (above). [...] let d=c[0] echo d - 3 Correct echo list d=.d - list d=3 So here it works? 'd' is suddenly considered a string? While it was obtained from the list? echo list d=d - list d= 3 That works, too, with additional blank after '=' --- [script end] --- The last two cases are confusing the whole issue. So when a string and a list can be mixed, when not, what are the rules, or are some of the above bugs? It's a difference between concatenation with . and listing two separate things. I now understand this case, however, how did the 'd' suddenly become a string (at least it doesn't give an error in :echo, see first case above) when it was obtained from the list? Is it the case that the conversion takes place when it can? Or are there better rules? You can use string() to convert a list to a string before concatenating it to another string. Thanks for this, I missed it in the doc. ---Zdenek
How to convert a string into a file
I have this problem (trivially simplified a real case): let a=a\nb\nc When echo'ing it, it displays lines: :echo a a b c Now I need to call system() and have the contents of 'a' as the file, without actually writing the 'a' into a temp file, something like this: execute system(. editor . . file .) where 'editor' is a variable containing the editor name, could be let editor=gvim and 'file' is *the something* containing the lines from the variable 'a'. Can that be done or do I have to go via a temp file? thanks ---Zdenek
