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: Sebastian Menge [mailto:[EMAIL PROTECTED] > Sent: 15 May 2007 14:47 > To: Zdenek Sekera > Cc: fREW; Tom Purl; vim@vim.org > Subject: RE: Vim Wiki - Wiki Template Proposal > > Am Dienstag, den 15.05.2007, 13:51 +0200 schrieb Zdenek Sekera: > > > 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 > > Works for me... Well, I tried again, several times, always the same error, flashes real fast... ---Zdenek 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: 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 "*" 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
> > "*" did. I also wish I had known
> earlier...Using the
> > "*" key while in normal mode searches for the word
> under the
> > cursor.If 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: VimWiki - again - but with a brand new option
> -Original Message- > From: Tom Purl [mailto:[EMAIL PROTECTED] > Sent: 10 May 2007 17:45 > To: John Beckett > Cc: vim@vim.org > Subject: Re: VimWiki - again - but with a brand new option > > On Thu, May 10, 2007 3:40 am, John Beckett wrote: > > Tom Purl wrote: > >> Here's what I propose we do: > >> 1. Finalize a tip formatting standard. > >> 2. Use the best available script that supports this standard. > >> 3. Update the best available script if necessary. > >> 4. Revise the standard if necessary. > >> 5. Convert a tips sample. > >> 6. Review the sample and revise the script if necessary. > > > > Good. But to keep our discussion focussed, please do what you > > did last time: Put a sample tip on a wiki page so we can agree > > on its features. > > We already have a tip on the page that people have been working on. > You > can see the link to it on the following page: > > * http://en.wikibooks.org/wiki/Learning_the_vi_editor/Vim/TipsSandbox > > > Please take Gene's advice and manually edit the page to how you think > > it should look. Once the format is agreed, we can ask for a script. > > > > I recommend: > > - Propose a format for the URL of each tip, as well as > > the format of the page. > > > > - Omit the info box with author, date, tip rating, Vim version. > > It's too hard to maintain, and too intrusive. > > > > - Keep the comments on the tip page, with a very simple > > comment heading in front of each, something like: > > -By UserName on March 8, 2001 14:51- > > > > To make it easy to edit the page, the comment heading should be > > a single line in the wiki source. > > I agree that we should keep things as simple as possible, at least for > the initial conversion. After that, when all updates are manual, we > can > be more fancy :) > > This not only saves time, but I just don't think that it is possible to > create a conversion script that can convert plain text that doesn't use > a single markup style to a consistent format. > > > -Or- Put all the comments on the talk page, with the format as > > above. However, that seems unnecessarily tricky to do in > > practice (it doubles the number of pages we have to work with). > > > > I favour putting the comments in the main page to make it easier > > to clean up the tip. When we see a tip with old-style comments, > > we would know that it needed an overhaul. > > So do I. > > >> 1. Let's use this mailing list to coordinate the project. > >> All comments regarding wiki page format, however, should be > >> written to the "talk" section of the affected wiki page. > > > > Please be more explicit. Will we use the vim or the vim-dev > > list? > > I was referring to the user mailing list. > > > How can we comment on the wiki page format on the "talk" section? > > Each page has a "talk" tab, and you can use it to comment on a wiki > page. > > > I think we should use the vim mailing list for all discussions until > a > > decision (your decision!) is made to finalise the wiki site, format, > > and script. > > Ok, what does everyone else think? I'm open to this, especially since > it's easier to keep up with the mailing list than it is to keep up with > a Wikibooks watchlist page. > > > Final suggestion: Please start a new thread (new subject) which > > we will follow until everything is finalised, rather than > > replying to this. > > I agree. I'm a big fan of proper mailing list thread etiquette, even > though I completely ignored it for this discussion :) > > I plan on starting a new thread for each deadline, and I think we > should > be fairly granular when it comes to thread creation. It makes things > easier to follow. If in doubt, create a new thread! > > > It would be great if you would consider what I and others have > > written, then make a proposal with what you think. > > Thanks for the feedback! My "proposal" is basically what I said > yesterday - that we follow some sort of schedule and make some > decisions. I like your suggestions. What does everyone else think? Sounds very good, go for it as per Gene's suggestion. Nothing will get done otherwise, unless somebody knowledgable really starts. Good luck! ---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: 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: 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:
> >> >
> >> > qq72i0q
> >> >
> >> > 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: VimTips Wiki: New Direction
> -Original Message- > From: Spencer Collyer [mailto:[EMAIL PROTECTED] > Sent: 06 March 2007 08:31 > Cc: Vim Mailing List > Subject: Re: VimTips Wiki: New Direction > > On Tue, 6 Mar 2007 03:18:13 +0200, Ali Polatel wrote: > > And check out > > http://en.wikibooks.org/wiki/Learning_the_vi_editor/Vim/TipsSandbox > > to see how it parsed tip #1. > > Looks good. Only comment I have is it might be better if the 'By' and > 'On' lines for the comments were on the same line. Anything > that allows > more useful info on a screen at once is an improvement in my eyes. Yes, I very much agree, use screen real estate for useful info as much as possible. Otherwise good IMHO! ---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 :exe ":undo|:set paste|:normal .:set nopaste" set pastetoggle= The first line of which is to redo a botched paste, the second of which is to make the 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): "# - toggle paste "#(must have 'pastetoggle' set) set pastetoggle=" toggle 'paste' option map :set invpaste paste? imap:set invpaste/ It works both i normal as well insert mode. Hit 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 again. Regards, ---Zdenek smime.p7s Description: S/MIME Cryptographic Signature
RE: :set guifont problem: width between characters
> -Original Message- > From: Régis B. [mailto:[EMAIL PROTECTED] > Sent: 23 November 2006 10:32 > To: vim@vim.org > Subject: :set guifont problem: width between characters > > > Hello there, > I use gVim with the GTK2+ GUI, under KUbuntu. Here is my problem: the > default font is correct, as you can see: > > http://www.nabble.com/file/4262/gVim_correct.png > > But as soon as I try to set the font, with :set guifont=Sans \9 for > instance, I get a lot of space between the characters: > > http://www.nabble.com/file/4263/gVim_toowide.png > > Ugly, isn't it? You have any idea how to fix this? This looks like every of character of your font is rended as a double width character displaying a blank after each character. I think there is a lot of useful information under :h guifont :h guifontwide :h guifontset I know I am not giving you a solution but that's because for the life of mine I can't remember how did I eventually solve it. All I am sure is that I read and reread these lines many times and tried. Hopefully that gets you on the right track at least if not solve your problem per say. Good luck. ---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: disappearing echo in ':nmap *'
> On Mon, Nov 06, 2006 at 10:55:34AM +0100, Zdenek Sekera wrote: > > > I had many cases of "disappearing echo" in the past, > > > I was mostly able to solve with some or other tricks. This > > > one is difficult, I cannot solve it whatever I try (echo in > > > the rhs of 'nmap *'): > > > > > > 1. :nnoremap * :exe "norm! *" echomsg "bla bla" > > > 2. :help help > > > 3. /for > > > 4. press * * * * * * * > > > Message "bla bla" mostly does not appear (very rarely, > > > it does; :mess shows that mapping was triggered) Why ? > > > > I don't know why but I have that problem since a long > > time (from vim 5 already!). Yes, sometimes tricks (like > > introducing dummy 'echo ""' before the real echo help, > > but sometimes they don't. I think Bram knows about it. > > Searching for "echo" in todo.txt, I did not find any mention of > this. Maybe this item? > > 9 Check handling of overwriting of messages and delays: > Very wrong: errors while redrawing cause endless loop. > When switching to another file and screen scrolls because > of the long > message and return must be typed, don't scroll the screen > back before > redrawing. > > It seems to me that the message is wiped out when the screen > scrolls. If the cursor move on the same screen, or if the screen > redraws, then I see the "bla bla". Aha: this seems to help: > > :nnoremap * :execute "norm! *" redraw echomsg > "bla bla" I can't say if thistem is *the one*. I usual have those problems when I add some echo into a script for debugging and depending how many echo's I added, possibly where, how close they are together (or not ?), I most definitely loose some of them. Usually when that happenes, I will be loosing always the same ones. However, since the debugged script has a tendency to change quite quickly, the problems will or not move with changes. So, in some sense maybe my problem is not strcitly speaking the same as that of the original poster since it is not realted to any mapping, rather a straightforward exec of echo inside a script. ---Zdenek
RE: disappearing echo in ':nmap *'
> I had many cases of "disappearing echo" in the past, > I was mostly able to solve with some or other tricks. This > one is difficult, I cannot solve it whatever I try (echo in > the rhs of 'nmap *'): > > 1. :nnoremap * :exe "norm! *" echomsg "bla bla" > 2. :help help > 3. /for > 4. press * * * * * * * > Message "bla bla" mostly does not appear (very rarely, > it does; :mess shows that mapping was triggered) Why ? I don't know why but I have that problem since a long time (from vim 5 already!). Yes, sometimes tricks (like introducing dummy 'echo ""' before the real echo help, but sometimes they don't. I think Bram knows about it. ---Zdenek
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: [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. > >
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
(add) RE: Inputdialog() broken in Vim7
> -Original Message-
> From: Zdenek Sekera [mailto:[EMAIL PROTECTED]
> Sent: 08 June 2006 14:21
> To: David Fishburn; vim@vim.org
> Subject: RE: Inputdialog() broken in Vim7
>
> > -Original Message-
> > From: David Fishburn [mailto:[EMAIL PROTECTED]
> > Sent: 08 June 2006 13:39
> > To: vim@vim.org
> > Subject: Inputdialog() broken in Vim7
> >
> >
> > Vim 7 and 7.1-17 on WinXP SP2
> >
> > This should affect all Vim platforms, not just Windows.
> >
> > Could someone please confirm this is a bug.
> >
> > If you run this command from a GUI enabled vim:
> > :echo inputdialog('hello:', 10, -1)
> >
> > You get a dialog box displayed which says "hello", with a
> > default value of
> > 10. Pressing OK, returns 10, pressing cancel returns -1.
> >
> > If you run the same command from a console Vim, you get:
> > E180: Invalid complete value: -1
> >
> > :h E180
> > Completion behavior *:command-completion*
> > *E179*
> > *E180* *E181*
> > By default, the arguments of user defined commands do not undergo
> > completion.
> >
> > This of course is not a user defined command.
> >
>
> Confirmed, I get exactly the same.
Sorry I forgot: Linux RH ES, gtk2.
---Zdenek
RE: Inputdialog() broken in Vim7
> -Original Message-
> From: David Fishburn [mailto:[EMAIL PROTECTED]
> Sent: 08 June 2006 13:39
> To: vim@vim.org
> Subject: Inputdialog() broken in Vim7
>
>
> Vim 7 and 7.1-17 on WinXP SP2
>
> This should affect all Vim platforms, not just Windows.
>
> Could someone please confirm this is a bug.
>
> If you run this command from a GUI enabled vim:
> :echo inputdialog('hello:', 10, -1)
>
> You get a dialog box displayed which says "hello", with a
> default value of
> 10. Pressing OK, returns 10, pressing cancel returns -1.
>
> If you run the same command from a console Vim, you get:
> E180: Invalid complete value: -1
>
> :h E180
> Completion behavior *:command-completion*
> *E179*
> *E180* *E181*
> By default, the arguments of user defined commands do not undergo
> completion.
>
> This of course is not a user defined command.
>
Confirmed, I get exactly the same.
---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 ;-) > > 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
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: CurorLine, set cursorline: slow, slower, slowest ?!
> -Original Message- > From: Meino Christian Cramer [mailto:[EMAIL PROTECTED] > Sent: 18 May 2006 18:43 > To: [EMAIL PROTECTED] > Cc: vim@vim.org > 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. When e.g. I place the cursor at the beginning of the line and hold e.g. 'l' for a while, cursor may move two chars, then pause and suddenly jump many chars forward depending how I've held the key. This is a problem for Bram, IMHO. ---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 : > > normal : > > etc., come close, but no cigar. > Not sure if it helps, but try this: :map ,x :let a=10 and execute it by ',x' (no apostrophies) and then see for comparison this: :map ,x :let a=10/ execute and see the difference. Is it something you were looking for? ---Zdenek
RE: Patch for AsNeeded to define proxy commands
---Zdenek > -Original Message- > From: Benji Fisher [mailto:[EMAIL PROTECTED] > Sent: 11 May 2006 14:20 > To: vim@vim.org > Subject: Re: Patch for AsNeeded to define proxy commands > > On Wed, May 10, 2006 at 09:00:32PM +0200, Thomas wrote: > > Hi, > > > > Here is a small patch for AsNeeded that eliminates the need to call > > AN(X) for commands. It creates a file called > ~/.vim/AsNeeded/ANautoload > > that contains lines like: > > > > command! -range -nargs=* Command delcommand Command | ANX Command > > > > Regards, > > Thomas. > > > --- AsNeeded.vim2006-05-10 20:48:42.442003200 +0200 > > +++ /cygdrive/f/.vim/plugin/AsNeeded.vim2006-05-10 > 20:45:13.381388800 +0200 > [snip] > > AFAICT this file is not part of the standard distribution. Where > does it come from? Perhaps you should submit the patch to > the author of > this script. This is an excellent script of Dr.Chip. ---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 RCSCheckIn()'
> autocmd FileType * exe 'silent call HiStatusLines()'
> 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
>
>
RE: new logo
> -Original Message- > From: Georg Dahn [mailto:[EMAIL PROTECTED] > Sent: 15 April 2006 09:50 > To: Zdenek Sekera > Cc: Benji Fisher; vim@vim.org > Subject: Re: new logo > > > Add the 'im' to it and they are perfect, > > which one is more than the other is left for others :-). > > The same here. What about this one: > > http://www.douglas.stebila.ca/code/vim/ > > This is more or less the same with 'im'. The others were tad more "shiny", but that's splitting the hair here. ---Zdenek
RE: new logo
> -Original Message- > From: Benji Fisher [mailto:[EMAIL PROTECTED] > Sent: 15 April 2006 04:27 > To: vim@vim.org > Subject: Re: new logo > > On Fri, Apr 14, 2006 at 03:58:26PM -0400, Benjamin Esham wrote: > > > > Personally, I *love* Matthew Webb's OS X versions of the Vim logo: > > > > http://www.cs.princeton.edu/~mtwebb/vim_icon/vim_icons.html > > > > Especially the "matte" version. It's the same design as > the current > > logo, but without the "im" text and with some subtle gradients and > > brushed-metal effects. > > > > Does anyone think that it would be unreasonable to set this as the > > default icon for Mac OS X builds of Vim? It certainly > blends better > > with the other apps' icons than the logo we have now (IMO). > > I think that Bram insists on the "im". We recently > adopted Douglas > Stebila's version of the icon for Vim.app, which includes it. Since > Matthew Webb says that he based his on this one, it might be possible > to "merge" the two icons. > > If you start a petition, you *might* convince Bram to stop > insisting on the "im" or get Matthew or Douglas to come up with a new > icon. You can also follow the instructions on the page you quoted to > install the icon in your own copy. Actually I wouldn't. I like the 'im'. Add the 'im' to it and they are perfect, which one is more than the other is left for others :-). ---Zdenek
RE: Proposal for a new logo
> -Original Message- > From: Anthony Campbell [mailto:[EMAIL PROTECTED] > Sent: 10 April 2006 11:58 > To: vim@vim.org > Subject: Re: Proposal for a new logo > > On 10 Apr 2006, Yakov Lerner wrote: > > On 4/9/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > I personally don't like it. I only agree with the goals > that you have; > > > but this particular logo i don't like. > > > > > > The old was very good... it could simply be revamped. > > > > I agree. I like the current(old) logo. > > > > Yakov > > > As we seem to be voting informally, I like the current one too. And so do I. ---Zdenek
