enabling cyrillic character display support

[Snucky]

Hi,

i am pretty much a newbie among the VIM-configurations though love to type
in this editor. I have tried to get through by using the help and such but
soon realized that it takes some hours to learn out all basics - which i am
not interested in, at least right now.

So, i know that there is this _vimrc file on my harddisc... 

I created an utf-8 coded document in another editor and typed down some
cyrillic chars. Do i now open this very file in my dear VIM it will not
properly display. I have thought to set VI to also use utf-8 coding but
already failed this task.

Would somebody please just give me the commands i need to type in that
config file "_vimrc" or is this not so easy?

Btw, i am running on a windows system

THANKS a million!
-- 
View this message in context: 
http://www.nabble.com/enabling-cyrillic-character-display-support-tf3762452.html#a10635337
Sent from the Vim - General mailing list archive at Nabble.com.

Re: yanking text

[A.J.Mechelynck]

Robert Cussons wrote:
Hi, I think a question like this was posted a long time ago, but I can't 
remember where or the answer, so please excuse me for asking it again.

If I yank the next word with yw the cursor stays where it is.
However if I want to yank text backwards from my current position for 
example to get the last word I use yb and the cursor moves to the 
beginning of the word. As I thought these two motion commands were the 
inverse and they appear to operate like that, why the difference in 
their reaction under the y operator?


Thanks
Rob.



The answer doesn't have a help tag, but it is somewhere under the description 
of the yank command in change.txt:



Note that after a characterwise yank command, Vim leaves the cursor on the
first yanked character that is closest to the start of the buffer.  This means
that "yl" doesn't move the cursor, but "yh" moves the cursor one character
left.
Rationale:  In Vi the "y" command followed by a backwards motion would
sometimes not move the cursor to the first yanked character,
because redisplaying was skipped.  In Vim it always moves to
the first character, as specified by Posix.
With a linewise yank command the cursor is put in the first line, but the
column is unmodified, thus it may not be on the first yanked character.



Best regards,
Tony.
--
"I'd love to go out with you, but I did my own thing and now I've got
to undo it."

VIM 7.1 compilation error

[keedi]

Hi, :-)

I am faced by the difficulity during compiling the new version of vim
7.1. I think I already have dev packages(gtk2-dev, gnome2-dev,
xft-dev, ...) but my system could not compile `gui_gtk_x11.c'


Any helpful suggestions appreciated. :-)

Regards,
keedi



I changed src/Makefile just uncomment below items and remain others
default:
CONF_OPT_GUI = --enable-gui=gnome2
CONF_OPT_PERL = --enable-perlinterp
CONF_OPT_CSCOPE = --enable-cscope
CONF_OPT_MULTIBYTE = --enable-multibyte
CONF_OPT_INPUT = --enable-hangulinput
CONF_OPT_OUTPUT = --enable-fontset
CONF_OPT_FEAT = --with-features=huge

Environment:
OS: Ubuntu Linux Edgy, 2.6.17-11-generic
LANG: ko_KR.UTF-8

compile error message:
gui_gtk_x11.c: In function ‘gui_mch_init_check’:
gui_gtk_x11.c:1586: warning: pointer targets in passing argument 2 of
‘dcgettext’ differ in signedness
gui_gtk_x11.c: In function ‘sm_client_die’:
gui_gtk_x11.c:2339: warning: pointer targets in passing argument 2 of
‘vim_strncpy’ differ in signedness
gui_gtk_x11.c: In function ‘gui_mch_get_fontset’:
gui_gtk_x11.c:4610: warning: pointer targets in passing argument 2 of
‘dcgettext’ differ in signedness
gui_gtk_x11.c: In function ‘gui_mch_get_font’:
gui_gtk_x11.c:5221: warning: pointer targets in passing argument 2 of
‘dcgettext’ differ in signedness
gui_gtk_x11.c: In function ‘gui_mch_set_fontset’:
gui_gtk_x11.c:5348: error: ‘gui_T’ has no member named ‘current_font’
gui_gtk_x11.c: In function ‘gui_mch_free_fontset’:
gui_gtk_x11.c:5374: warning: passing argument 1 of ‘gdk_font_unref’ from
incompatible pointer type
make: *** [objects/gui_gtk_x11.o] Error 1

Re: Vim Wiki - Tip Page Formatting Deadline

[Gary Johnson]

On 2007-05-15, Tom Purl <[EMAIL PROTECTED]> wrote:
> 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
> 
> 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).
> 
> 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.

I much prefer "VimTip1 v2".  Whether just browsing tips or reading 
tips I've searched for, I want to be able to read it quickly without 
having to scan through a bunch of boilerplate.  I would even 
advocate a Synopsis line that would summarize the tip if the title 
didn't already do so.  I like having the meta data collected as it 
is in one line at the bottom of the tip:  it's concise and in an 
unobtrusive yet consistent and easy-to-find location.

In the table of contents, each tip really needs to have the title 
alongside its number.  The first page, 
http://scratchpad.wikia.com/wiki/VimTest, is lacking that, unless 
the names there (e.g., VimTip123) are just place holders for real 
titles.  I really don't want to have to load each tip page one at a 
time to browse the latest contributions.

My $0.02.

Regards,
Gary

-- 
Gary Johnson | Agilent Technologies
[EMAIL PROTECTED] | Mobile Broadband Division
 | Spokane, Washington, USA

Re: vim 7.1 and cr/lf interpretation

[Micah Cowan]

Gene Kwiecinski wrote:
 "fileformats=dos,unix", so both formats are available, yet the
 detection and switching does not seem to work.
> 
>>> Are you sure _every_ line ends in "^M"?
> 
>> Positive. Every single line shows an ^M at the end. "set fileformat"
>> gives "unix" after loading. Setting fileformat to "dos" doesn't change
>> the files interpretation in vim. Somehow I think I miss something.
> 
> Uhhh, don't think it *should* automagically delete the ^Ms.  I'm always
> running into that, and in addition to an almost reflexive alt-EIFD to go
> dos-mode, I *still* always have to ':s/^V^M' to get rid of 'em, and I'm
> using version 6.4, not even 7.x, so it's definitely been around for a
> while.

If vim opens a file that truly has ^M^J at the end of every line, and
fileformats contains dos, then it will automatically convert ^M^J to
"line ending". If you then set ff=unix, and save the file, it will write
those endings out as just ^J. I've used this a few times (also in
reverse, when I want to write an SMTP transcript for netcat, but forgot
to save with CRLFs the first time :) ).

-- 
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/




signature.asc
Description: OpenPGP digital signature

RE: vim 7.1 and cr/lf interpretation

[Gene Kwiecinski]

>Uhhh, don't think it *should* automagically delete the ^Ms.  I'm always
>running into that, and in addition to an almost reflexive alt-EIFD to
go
>dos-mode, I *still* always have to ':s/^V^M' to get rid of 'em, and I'm
 

I sit corrected, so before anyone yells at me :D I should point out that
most if not all times I encounter that is when pigging webpages, so it's
likely a bastardised version of dos/unix snippets of text, headers,
inline css, js code, etc., all thrown together by the server and vomited
up into my browser.  So there's likely to be at least 1 line w/o a '^M',
hence my having to manually kill 'em off.

RE: vim 7.1 and cr/lf interpretation

[Gene Kwiecinski]

>>>"fileformats=dos,unix", so both formats are available, yet the
>>>detection and switching does not seem to work.

>>Are you sure _every_ line ends in "^M"?

>Positive. Every single line shows an ^M at the end. "set fileformat"
>gives "unix" after loading. Setting fileformat to "dos" doesn't change
>the files interpretation in vim. Somehow I think I miss something.

Uhhh, don't think it *should* automagically delete the ^Ms.  I'm always
running into that, and in addition to an almost reflexive alt-EIFD to go
dos-mode, I *still* always have to ':s/^V^M' to get rid of 'em, and I'm
using version 6.4, not even 7.x, so it's definitely been around for a
while.

Re: Project specific settings

[hermitte]

Hello,

Gary Johnson <[EMAIL PROTECTED]>:

> On 2007-05-14, "Larson, David" <[EMAIL PROTECTED]> wrote:
> > > From: Gary Johnson [mailto:[EMAIL PROTECTED]
> > > Sent: Monday, May 14, 2007 12:41 PM
> > >
> > > On 2007-05-14, [EMAIL PROTECTED] wrote:
>
> > > > Another solution is to use plugins like local_vimrc.vim (there
> > > > are two similiar plugins with this name) or plugin.vim
> > >
> > > My search of scripts for "local_vimrc" yielded only one result,
> > > script #727.

The other one is Markus Braun's script (-> #441) -- I completly missed his
script when I wrote mine ^^' Hence the two different scripts.

BTW, the latest version of my script is only available on my web site for the
moment:
   http://hermitte.free.fr/vim/ressources/vimfiles/plugin/local_vimrc.vim

> I did that.  Here are the results (the headings of the first search
> results pages) from searching for the plugin.vim script that Luc
> suggested.
> [...]
> If one searches instead for "project", one does indeed get 66
> results.
> [...]
> Maybe that's what Luc intended, but it isn't what he wrote.

Indeed, I meant project.vim. My mistake.

--
Luc Hermitte
http://hermitte.free.fr/vim/

Re: vim 7.1 and cr/lf interpretation

[Micah Cowan]

Thomas Michael Engelke wrote:
> 2007/5/15, Micah Cowan <[EMAIL PROTECTED]>:
>> Thomas Michael Engelke wrote:
>>
>> > But that's arguing semantics when the core of the problem is known
>> > now. I apologize for having a different set of mind and not
>> > understanding the problem instantly.
>>
>> This is not a fair remark, considering I pointed out to you, privately,
>> that he made the statement fairly clearly before his last post, which is
>> why he said it all-caps/bold the second time around.
>>
>> It's not that you didn't understand the problem instantly: the problem
>> was explained fairly clearly; it's that you made him repeat his answers,
>> indicating that you hadn't read them.
> 
> Damn. I apologize again, this time for replying your mail on the list.
> Now I know why there was no "Reply to all", which I thought to be a
> glitch in GMail.

Oh. Well, I actually hadn't noticed you'd done that, believe it or not.
And I don't mind.

-- 
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/




signature.asc
Description: OpenPGP digital signature

RE: mouse-wheel scrolling with vertically split windows

[Waters, Bill]

Is there a way to map mouse-wheel to CTRL-mouse-wheel?  That seems to be
a work-around.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Monday, May 14, 2007 6:43 PM
To: Waters, Bill; vim
Subject: Re: mouse-wheel scrolling with vertically split windows

Yes, with gvim 7.1 on WinXP SP2 I get the same behaviour. 

gvim -u NONE -U NONE some_file
:vsp
C-W C-W
Use the wheel to scroll. Only the left window will scroll. 


Whoa, I was just trying this again when I discovered if you hold down
the CTRL key you get different behaviour. 

CTRL-wheel scroll will do the right side window. 

Crap, now I restarted Vim and it will scroll both windows again as it
should. 


So after it not doing it 5 restarts in a row, once I held down the CTRL
button and scrolled (which worked). Now everytime I restart Vim it works
flawlessly. 

Walter, what happens when you try the same thing?


Dave





- Original Message -
From: "Waters, Bill" [EMAIL PROTECTED]
Sent: 05/14/2007 05:56 PM EST
To: David Fishburn; "vim" 
Subject: RE: mouse-wheel scrolling with vertically split windows



> What happens if you start vim using:
> Gvim -u NONE -U NONE

Same results.  I start gvim, do a :vsplit, and the mouse wheel will only
scroll the left window, even when the right window is selected.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Monday, May 14, 2007 5:45 PM
To: Waters, Bill; vim
Subject: Re: mouse-wheel scrolling with vertically split windows

What happens if you start vim using:
Gvim -u NONE -U NONE 

And try again?
If it doesn't happen sounds like possibly a plugin issue (or compability
mode). But from a code perspective I don't think a plugin could affect
Vim in this way. 

Dave



- Original Message -
From: "Waters, Bill" [EMAIL PROTECTED]
Sent: 05/14/2007 02:51 PM EST
To: "David Fishburn" <[EMAIL PROTECTED]>; 
Subject: RE: mouse-wheel scrolling with vertically split windows



It happens every time for me.  I just have to open a file and then do a
:vsplit.

It really shows up and is annoying with using the taglist plugin.

Do you know of a command for the Edit->Global Settings->Toggle Right
Scroll Bar option?


-Original Message-
From: David Fishburn [mailto:[EMAIL PROTECTED] 
Sent: Monday, May 14, 2007 2:42 PM
To: Waters, Bill
Subject: RE: mouse-wheel scrolling with vertically split windows

 

> -Original Message-
> From: Waters, Bill [mailto:[EMAIL PROTECTED] 
> Sent: Monday, May 14, 2007 3:23 PM
> To: vim@vim.org
> Subject: mouse-wheel scrolling with vertically split windows
> 
> (I am using gVim 7.1 in Windows XP.)
> 
> If I do a :vsplit, I end up with a scroll bar on the right 
> for the right window and a scroll bar on the left for the 
> left window.  When I use my mouse wheel to scroll, the left 
> window scrolls, regardless of which window is selected.
> 
> If I do a Edit->Global Settings->Toggle Right Scroll Bar, the 
> right scroll bar disappears.  But I am able to mouse-wheel 
> scrolling based on which window is selected.
> 
> Is there a way to keep both scroll bars, and be able to 
> mouse-wheel scroll based on which window is selected?

Unfortunately, this has been reported since the betas of 7.0.

Many of us on Windows are running into this, but I cannot reliably come
up
with a series of steps to reproduce the issue to hand over to Bram.

Can you reliably reproduce this so that it will happen on other peoples
machines?

Dave

RE: mouse-wheel scrolling with vertically split windows

[Waters, Bill]

Bringing it up with " gvim -u NONE -U NONE", I see guioptions=egmrLtT.
I set it to your options (gimrLTt) and I see the same behavior as before
- the mouse wheel only scrolls the left window.

> When running as a GUI, if I use my mouse wheel to scroll,
> the window under the mouse pointer scrolls, regardless of
> whether or not it is selected for keyboard input. IMHO
> this is "proper" behavior.

I agree.  Even with the CTRL-mouse-wheel work-around, it scrolls the
right/left window based on which window is selected/active.  I agree
with you, it should simply scroll the window under the pointer.


-Original Message-
From: A.J.Mechelynck [mailto:[EMAIL PROTECTED] 
Sent: Monday, May 14, 2007 8:22 PM
To: Waters, Bill
Cc: vim@vim.org
Subject: Re: mouse-wheel scrolling with vertically split windows

Waters, Bill wrote:
> (I am using gVim 7.1 in Windows XP.)
> 
> If I do a :vsplit, I end up with a scroll bar on the right for the
right
> window and a scroll bar on the left for the left window.  When I use
my
> mouse wheel to scroll, the left window scrolls, regardless of which
> window is selected.
> 
> If I do a Edit->Global Settings->Toggle Right Scroll Bar, the right
> scroll bar disappears.  But I am able to mouse-wheel scrolling based
on
> which window is selected.
> 
> Is there a way to keep both scroll bars, and be able to mouse-wheel
> scroll based on which window is selected?
> 
> 

I am using Vim 7.1.1 with GTK2/Gnome GUI on openSUSE Linux 10.2 with kde
desktop.

When running as a GUI, if I use my mouse wheel to scroll, the window
under the 
mouse pointer scrolls, regardless of whether or not it is selected for 
keyboard input. IMHO this is "proper" behaviour.

In the GUI, when there are three vertically split windows, and I use the

scrollbars (not the wheel) then which scrollbar moves the (selected)
middle 
window depends on which window it was split from.

In console mode there are no scrollbars:

When running in konsole, then if I use the wheel, the selected window
scrolls, 
not necessarily the one under the mouse pointer.

When running in the linux console (/dev/tty), the mouse is recognised
but the 
wheel has no effect.

What is your 'guioptions' set to? Mine is gimrLTt and in the GUI I see
the 
right-hand scrollbar always, the left-hand one if there is a vertical
split.


Best regards,
Tony.
-- 
"I'd love to go out with you, but I'm converting my calendar watch from
Julian to Gregorian."

RE: mouse-wheel scrolling with vertically split windows

[Waters, Bill]

If the right window is selected and I do CTRL-wheel, the right window
will scroll.  That is the only way that I can get the right window to
scroll with the mouse wheel though.

So, I am seeing similar behavior to yours, but not the exact same thing.

--Bill


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Monday, May 14, 2007 6:43 PM
To: Waters, Bill; vim
Subject: Re: mouse-wheel scrolling with vertically split windows

Yes, with gvim 7.1 on WinXP SP2 I get the same behaviour. 

gvim -u NONE -U NONE some_file
:vsp
C-W C-W
Use the wheel to scroll. Only the left window will scroll. 


Whoa, I was just trying this again when I discovered if you hold down
the CTRL key you get different behaviour. 

CTRL-wheel scroll will do the right side window. 

Crap, now I restarted Vim and it will scroll both windows again as it
should. 


So after it not doing it 5 restarts in a row, once I held down the CTRL
button and scrolled (which worked). Now everytime I restart Vim it works
flawlessly. 

Walter, what happens when you try the same thing?


Dave





- Original Message -
From: "Waters, Bill" [EMAIL PROTECTED]
Sent: 05/14/2007 05:56 PM EST
To: David Fishburn; "vim" 
Subject: RE: mouse-wheel scrolling with vertically split windows



> What happens if you start vim using:
> Gvim -u NONE -U NONE

Same results.  I start gvim, do a :vsplit, and the mouse wheel will only
scroll the left window, even when the right window is selected.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Monday, May 14, 2007 5:45 PM
To: Waters, Bill; vim
Subject: Re: mouse-wheel scrolling with vertically split windows

What happens if you start vim using:
Gvim -u NONE -U NONE 

And try again?
If it doesn't happen sounds like possibly a plugin issue (or compability
mode). But from a code perspective I don't think a plugin could affect
Vim in this way. 

Dave



- Original Message -
From: "Waters, Bill" [EMAIL PROTECTED]
Sent: 05/14/2007 02:51 PM EST
To: "David Fishburn" <[EMAIL PROTECTED]>; 
Subject: RE: mouse-wheel scrolling with vertically split windows



It happens every time for me.  I just have to open a file and then do a
:vsplit.

It really shows up and is annoying with using the taglist plugin.

Do you know of a command for the Edit->Global Settings->Toggle Right
Scroll Bar option?


-Original Message-
From: David Fishburn [mailto:[EMAIL PROTECTED] 
Sent: Monday, May 14, 2007 2:42 PM
To: Waters, Bill
Subject: RE: mouse-wheel scrolling with vertically split windows

 

> -Original Message-
> From: Waters, Bill [mailto:[EMAIL PROTECTED] 
> Sent: Monday, May 14, 2007 3:23 PM
> To: vim@vim.org
> Subject: mouse-wheel scrolling with vertically split windows
> 
> (I am using gVim 7.1 in Windows XP.)
> 
> If I do a :vsplit, I end up with a scroll bar on the right 
> for the right window and a scroll bar on the left for the 
> left window.  When I use my mouse wheel to scroll, the left 
> window scrolls, regardless of which window is selected.
> 
> If I do a Edit->Global Settings->Toggle Right Scroll Bar, the 
> right scroll bar disappears.  But I am able to mouse-wheel 
> scrolling based on which window is selected.
> 
> Is there a way to keep both scroll bars, and be able to 
> mouse-wheel scroll based on which window is selected?

Unfortunately, this has been reported since the betas of 7.0.

Many of us on Windows are running into this, but I cannot reliably come
up
with a series of steps to reproduce the issue to hand over to Bram.

Can you reliably reproduce this so that it will happen on other peoples
machines?

Dave

Re: Vim Wiki - Wiki Template Proposal

[Tom Purl]

On Tue, May 15, 2007 10:39 am, Sebastian Menge wrote:
> I attach the three scripts (without any warranty ;-) ). But it would be
> better to use a svn repository when we work on it together...
>
> Can we get commit access to
> http://vimtips.googlecode.com/svn/trunk/scripts/ ?

Sure, I can handle that.  First, you need a gmail/google account,
however.  Then I can add you as an SVN committer for the scripts
repository.

Thanks,

Tom Purl

Re: Vim Wiki - Wiki Template Proposal

[Sebastian Menge]

Am Dienstag, den 15.05.2007, 09:09 -0600 schrieb fREW:
> possible to wiki syntax.  Could someone send out the script that was
> used to upload pages initially?  It would be helpful to see it so that
> we could set up some translation code in the script.

I adapted the script vimtips.py from the URL Tom posted and the "bulk
page creator" script for mediawiki. The latter is in php and depends on
another php script. Would be nice if someone could translate the 80lines
php-script to python !?

Then I wrote a simple bashscript that calls both scripts.

A problem with bulkinsert.php was that mediawiki uses a Captcha
mechanism when there is a  in the text. The bash-scripts tries
to detect that and echoes a message.

I attach the three scripts (without any warranty ;-) ). But it would be
better to use a svn repository when we work on it together...

Can we get commit access to
http://vimtips.googlecode.com/svn/trunk/scripts/ ?

Sebastian


bulkinsert.php
Description: application/php
#!/usr/bin/python
# -*- coding: utf-8 -*-
# vimtips.py -- parse tips from www.vim.org
# written by Ali Polatel

import os
import sys
import re, urllib2
import commands

__author__ = 'Ali Polatel'
__contributors__ = []

# Globals
URL = 'http://www.vim.org/tips/tip.php?tip_id=%d'
headers= { 'User-Agent': 'vimtips.py' }
href_r = re.compile(r'.*?)["\']>(?P.*?)',re.IGNORECASE)
 


class comment:
""" Type for additional comments
"""
email = None
date = None
text = None

def htmltowiki(str):
""" Take care of html stuffed 
that's not recognized by wikipedia
"""
# Remove ^M's
str = str.replace('\r','')

# Convert href tags
#m = href_r.findall(str)
#for tag in m:
# Add www.vim.org if the link starts with /
# TODO change this to the corresponding wiki adress of the tip ;)
#if tag[0].startswith('/'):
#link = 'http://www.vim.org' + tag[0]
#str = re.sub(r'%s' % tag[1]
# ,'[%s %s]' % (link, tag[1])
# ,str)

# Initial support for html2wiki
# Very ugly but it does the job well
fp = open('vimtip_tmp.html','w')
fp.write(str)
fp.close()
status,tmpstr = commands.getstatusoutput('html2wiki --dialect MediaWiki vimtip_tmp.html')
if status != 0: # html2wiki is not in PATH or it exited with error
sys.stderr.write('html2wiki not found, skipping conversion\n')
else:
str= tmpstr
os.remove('vimtip_tmp.html')
return str

def gettip(id):
""" Get the tip from www.vim.org
"""
tip_url = URL % id
req = urllib2.Request(tip_url, None, headers)
data = urllib2.urlopen(req)
return data.read()

def parsetip(tip):
""" Parse the tip
"""

title_r = re.compile('Tip #\d*\ -\ (.*?)\s:')
rating_r = re.compile('Rating\s(-?\d+/\d+)')
body_r = re.compile('(.*)')
add_r = re.compile('\n\t\s*\t\s*(?P.*?),\s\n\t\s*\t\s*<.*>\s(?P.*?)')
comment_r = re.compile('(.*)')

try:
title = title_r.search(tip).groups()[0]
except AttributeError: # Tip doesn't exist
return None
rating = rating_r.search(tip).groups()[0]
body = body_r.search(tip).groups()[0]

# Additional comments
comments = []
m = add_r.finditer(tip)
for match in m:
new = comment()
new.email = htmltowiki(match.group('email'))
new.date = match.group('date')
comments.append(new)

m = comment_r.finditer(tip)
index = 0
for match in m:
comments[index].text = htmltowiki(match.groups()[0])
index+=1

lst = tip.split('\n')

# The lines we want are two lines below these lines
created_td = 'created:'
complexity_td = 'complexity:'
author_td = 'author:'
version_td = 'as of Vim:'

created = re.sub('\s*<.?td>','',lst[lst.index(created_td)+2])
complexity = re.sub('\s*<.?td>','',lst[lst.index(complexity_td)+2])
author = re.sub('\s*<.?td>','',lst[lst.index(author_td)+2])
version = re.sub('\s*<.?td>','',lst[lst.index(version_td)+2])

if not version: # Version empty
version = 'n/a'

return htmltowiki(title), author, created, complexity, version, rating, htmltowiki(body), comments

if __name__ == '__main__':

if len(sys.argv) != 2:
print 'Usage %s tip_id' % sys.argv[0]
sys.exit(-1) 
id = int(sys.argv[1])
tip = gettip(id)
parsedtip = parsetip(tip)
   
if parsedtip is None:
print 'No tip with id %d exists on www.vim.org' % id
sys.exit(-2)

print 'VimTip%d' % id
print '--ENDTITLE--'
print '{{Tip2'
print '|id=%d' % id
print '|title=%s' % parsedtip[0]
print '|created=%s' % parsedtip[2]
print '|complexity=%s' % parsedtip[3]
print '|author=%s' % parsedtip[1]
print '|version=%s' % parsedtip[4]
print '|ratin=%s' % parsedtip[5]
print '|text='
print parsedtip[6]
print '}}'
# And additional comment

Re: Vim Wiki - Wiki Template Proposal

[Tom Purl]

On Tue, May 15, 2007 10:13 am, fREW wrote:
>> Also, check out the wikia site (vim.wiki.com).  I uploaded Sebastian's
>> logo.
>>
>> Thanks,
>>
>> Tom Purl
>>
>
> I dig the page!  That logo is great :-)  I think you dropped off an a
> when you sent out the link though.
>
> http://vim.wikia.com/wiki/Main_Page

Yikes!  Thanks for fixing that typo.

Tom Purl

Re: vim 7.1 and cr/lf interpretation

[Micah Cowan]

Thomas Michael Engelke wrote:

> But that's arguing semantics when the core of the problem is known
> now. I apologize for having a different set of mind and not
> understanding the problem instantly.

This is not a fair remark, considering I pointed out to you, privately,
that he made the statement fairly clearly before his last post, which is
why he said it all-caps/bold the second time around.

It's not that you didn't understand the problem instantly: the problem
was explained fairly clearly; it's that you made him repeat his answers,
indicating that you hadn't read them.

-- 
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/



signature.asc
Description: OpenPGP digital signature

Vim Wiki - Tip Page Formatting Deadline

[Tom Purl]

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

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).

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

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?

Tom Purl

Re: Vim Wiki - Wiki Template Proposal

[Tom Purl]

On Tue, May 15, 2007 9:51 am, fREW wrote:
> On 5/15/07, Sebastian Menge <[EMAIL PROTECTED]> wrote:
>> Am Dienstag, den 15.05.2007, 10:03 +0200 schrieb Sebastian Menge:
>>
>> Now I have. There is a sample on
>> http://scratchpad.wikia.com/wiki/VimTest
>>
>> But it leads to another problem: In a wiki we have no means to
>> autoincrement the id.
>>
>> Thus the convention VimTip for page names is not feasible. A good
>> prefix is a must in my opinion, but what suffix? Howto assure that it
>> is unique, not cryptic etc? Or what about complete freedom, and
>> revising it afterwards? Perhaps we can even drop the prefix and use
>> simply a "category".
>>
>> Seb.
>
> That's a hard question.  Would it be worth it to have a cron job or
> something that ran every night and moved/linked the newest tips to
> chronologically ordered tip numbers?  I don't think doing that would
> be a problem, I just think it might be surprising when you make a tip,
> and it's gone the next day. But a redirect like wikipedia has might
> make that more reasonable.

This sounds like an excellent idea to me, and not too terribly difficult
to implement.

Thanks,

Tom Purl

RE: Vim Wiki - Wiki Template Proposal

[Tom Purl]

On Tue, May 15, 2007 7:46 am, Sebastian Menge wrote:
> Am Dienstag, den 15.05.2007, 13:51 +0200 schrieb Zdenek Sekera:
>> > http://scratchpad.wikia.com/wiki/VimTest
>> >

Since I'm the *only* person who has so far voted against using wiki
templates, I will accept the fact that I'm in the minority and get out
of the way :)

Having said that, I really like the idea of using templates in this way
if we're going to use macros.

Also, check out the wikia site (vim.wiki.com).  I uploaded Sebastian's
logo.

Thanks,

Tom Purl

Re: Problem with digraphs through Putty

[Micah Cowan]

Jeenu V wrote:
> Hi Vimmers,
> 
> I'm using VIM (version 6.2) through putty. The digraphs that are
> displayed (either through :dig command or CTRL-K insertions) are all
> weird characters. When I tried to use digraphs as fold markers, it
> worked, but the fold markers inserted are still those weird
> characters. Does any body ever experienced this kind of problem? Any
> configurations to be done on putty?

It sounds to me as though your locale settings are off. That is, vim
thinks your terminal locale is other than it is.

Please ensure that your LANG and LC_* terminal environment variables
match the locale that putty recognizes.

-- 
HTH,
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/



signature.asc
Description: OpenPGP digital signature

Re: book

[Tom Purl]

On Mon, May 14, 2007 11:21 pm, Dave Land wrote:

 Hi, I am a beginner in VIM. Wonder whether there is any good book
 for VIM?  Also, what is the difference between vim and latex?
 Thanks,
 Linda
>
> I'm surprised that nobody's mentioned the books on this page:
>
>  http://iccf-holland.org/click5.html
>
> All of them are a bit old. The first one, "Vi IMproved - Vim", by Steve
> Oualline, is about six years old, and covers Vim 5.7, but much of it
> would still be current.

Yes, I agree.  I have a dead tree version of this book on my work desk,
and I still use it with the latest version of Vim weekly.

Tom Purl

Re: Vim Wiki - Wiki Template Proposal

[Tom Purl]

On Mon, May 14, 2007 2:49 pm, Martin Krischik wrote:
> Am Montag 14 Mai 2007 schrieb Tom Purl:
>
>> 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?
>
> Templates tend to be a good idea for small amount of text - and most
> tips don't have have that much text.

Some tips are pretty long, especially if you include the comments.

> Now refresh my mind: Why did we choose advertising ridden wikea over
> advertising free wikibooks?

Nothing's been decided yet, we're just exploring all of our options.

Thanks!

Tom Purl

RE: Vim Wiki - Wiki Template Proposal

[Zdenek Sekera]

> -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 7.1 and cr/lf interpretation

[Jean-Rene David]

* A.J.Mechelynck [2007.05.15 08:01]:
> If you had, as I already told you twice (this is
> the third one) done
> 
>   :set fileformats=
>   :e ++ff=dos list02.p
>   :w
> 
> your file would have been repaired immediately.
> SO WHY DIDN'T YOU?

Or equivalently:

:e list02.p
GA " add ^M at the end of the last line
:w
:e

-- 
JR

RE: Vim Wiki - Wiki Template Proposal

[Sebastian Menge]

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...

S.

yanking text

[Robert Cussons]

Hi, I think a question like this was posted a long time ago, but I can't 
remember where or the answer, so please excuse me for asking it again.

If I yank the next word with yw the cursor stays where it is.
However if I want to yank text backwards from my current position for 
example to get the last word I use yb and the cursor moves to the 
beginning of the word. As I thought these two motion commands were the 
inverse and they appear to operate like that, why the difference in 
their reaction under the y operator?


Thanks
Rob.

Re: vim 7.1 and cr/lf interpretation

[Thomas Michael Engelke]

2007/5/15, A.J.Mechelynck <[EMAIL PROTECTED]>:

Thomas Michael Engelke wrote:
> 2007/5/15, A.J.Mechelynck <[EMAIL PROTECTED]>:
>> Thomas Michael Engelke wrote:
>> > 2007/5/15, A.J.Mechelynck <[EMAIL PROTECTED]>:
>> >> Thomas Michael Engelke wrote:
>> >> > 2007/5/14, Andy Wokula <[EMAIL PROTECTED]>:
>> >> >> Thomas Michael Engelke schrieb:
>> >> >> > :set fileformats?
>> >> >> >
>> >> >> > gives
>> >> >> >
>> >> >> > "fileformats=dos,unix", so both formats are available, yet the
>> >> >> > detection and switching does not seem to work.
>> >> >>
>> >> >> Are you sure _every_ line ends in "^M"?
>> >> >
>> >> > Positive. Every single line shows an ^M at the end. "set fileformat"
>> >> > gives "unix" after loading. Setting fileformat to "dos" doesn't
>> change
>> >> > the files interpretation in vim. Somehow I think I miss something.
>> >> >
>> >>
>> >> If 'fileformats' includes "dos", then if _all_ lines end in CR+LF, the
>> >> 'fileformat' should be set (locally) to "dos".
>> >>
>> >> But a single line without a CR causes 'fileformat' to be set to
>> >> "unix", and
>> >> all other lines show a ^M
>> >>
>> >> Test 1:
>> >>
>> >> Load the file. Then:
>> >>
>> >> /[^[:return:]]$
>> >>
>> >> If there is a line ending in LF-without-CR, this search should find
>> it.
>> >>
>> >> Test 2, variant a: To remove all carriage-returns at end-of-line:
>> >>
>> >> :set fileformats=
>> >> :e ++ff=dos filename
>> >> :setlocal ff=unix
>> >> :w
>> >>
>> >> Test 2, variant b: to repair any lines where a CR is missing, (by
>> >> adding it):
>> >>
>> >> same as 2a, but omit the line with ":setlocal ff=unix".
>> >>
>> >>
>> >> Then exit Vim and reload the file with your usual settings to see
>> if the
>> >> problem has gone away. If it hasn't, do you still see it with
>> >>
>> >> vim -u /usr/local/share/vim/vim71/vimrc_example.vim
>> >>
>> >> (replace the path if necessary by wherever Vim sets $VIMRUNTIME on
>> your
>> >> installation: on Windows it might be
>> >>
>> >> vim -u "C:\Program Files\Vim\vim71\vimrc_example.vim"
>> >>
>> >> instead)?
>> >
>> > Hello Tony, and thanks for your extensive answer. Unfortunately, this
>> > is what I can report. To make things easier, I'll attach the file I am
>> > talking about to this message so that you can either check for
>> > yourselves and/or see that I'm telling the truth.
>> >
>> > What is the current state: Of course, there's one line without 0x13
>> > 0x10 at the end, and that is the last line. As I checked using your
>> > regex (I'm always forgetting the :word:-syntax is available as well,
>> > which makes it difficult as I can never remember how to search for a
>> > hex char), I found one single line except the last one without 0x13
>> > 0x10 at the end. I removed the line in joining it with the line above
>> > (multi line command) and saved the file. I closed it, closed vim and
>> > reopened the file again. The problem persists. Now the only line your
>> > regex finds is the last one. "set fileformats" still evaluates to
>> > "dos,unix". "set fileformat" after loading the file evaluates to
>> > "unix". Setting it to "dos" via "set fileformat=dos" does not help the
>> > issue.
>>
>> Apparently your last line still has a LF without CR, causing the
>> heuristic to
>> detect the file's 'fileformat' as "unix". Ends of lines are line
>> ENDINGS, not
>> line SEPARATORS: even the last line must have one, for various
>> reasons, the
>> most obvious of which is that, if "file1" lacks a proper end-of-file,
>>
>> copy file1+file2 file3
>>
>> will concatenate the last line of file1 with the first line of file2,
>> making
>> them a single line somewhere in the middle of file3.
>>
>> Try, as I said in my previous post,
>>
>> vim
>> :set fileformats= " cancel autodetect of fileformat
>> :edit ++ff=dos list02.p   " force 'dos' fileformat
>>
>> Then saving the file should add a proper CR+LF ending to the last line
>> (and to
>> any other line lacking a CR).
>>
>> >
>> > The example file of vim (in my case,
>> > c:\Programme\vim\vim71a\vimrc_example.vim) loads fine and gets the
>> > fileformat "dos", as expected.
>>
>> With -u before it on the Vim command-line, Vim should use it instead
>> of your
>> vimrc, not as an editfile.
>
> Assuming that fileformat "unix" means 0x10 means "open a new line"
> which seems to be the case (0x13 stays as ^M, 0x10 is interpreted as a
> new line), shouldn't this mean that in the last line there is a line
> break missing? If I would have seen a line there with no ^M at the end
> I would have seen the problem right away. But this way, it seems a
> little odd that although 0x13 0x10 gives a ^M and a new line, 0x10
> alone does not give a new line.
>

You would have seen a line with no ^M at the end? But your last line indeed
has no ^M at the end, how come you didn't see it?

0x10 alone gives an *end* of line, not necessarily a *begin* of line. Any
character after that, if t

Re: map gives me headache!

[Alberto Miorin]

> You can use the BufEnter or BufNew autocmd and test whether
> the 'buftype' option is set to 'quickfix' for the current buffer.
> 
> - Yegappan
I did this script, but it doesn't work. I open the quickfix window
with :cope . I have to leave the quickfix window and come back to
trigger the event BufEnter. Which event should I add?

function! RaiseEnter()"<<<
if getbufvar("", "&buftype") == "quickfix"
nunmap 
endif
endfunction 
">>>
function! KillEnter()"<<<
if getbufvar("", "&buftype") == "quickfix"
nmap  
endif
endfunction
">>>
au BufEnter * call RaiseEnter()
au BufLeave * call KillEnter()

Any advices?
Thanks

Alberto

Problem with digraphs through Putty

[Jeenu V]

Hi Vimmers,

I'm using VIM (version 6.2) through putty. The digraphs that are
displayed (either through :dig command or CTRL-K insertions) are all
weird characters. When I tried to use digraphs as fold markers, it
worked, but the fold markers inserted are still those weird
characters. Does any body ever experienced this kind of problem? Any
configurations to be done on putty?

Thanks
Jeenu V

RE: Vim Wiki - Wiki Template Proposal

[Zdenek Sekera]

> -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

[Sebastian Menge]

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

But it leads to another problem: In a wiki we have no means to
autoincrement the id.

Thus the convention VimTip for page names is not feasible. A good
prefix is a must in my opinion, but what suffix? Howto assure that it is
unique, not cryptic etc? Or what about complete freedom, and revising it
afterwards? Perhaps we can even drop the prefix and use simply a
"category".

Seb.

Re: vim 7.1 and cr/lf interpretation

[John Beckett]

Thomas Michael Engelke wrote:

Assuming that fileformat "unix" means 0x10 means "open a new
line" which seems to be the case (0x13 stays as ^M, 0x10 is
interpreted as a new line), shouldn't this mean that in the
last line there is a line break missing?


It's not important here, but for the record, 0x10 means hex 10,
which is decimal 16. That's not what you have.

The correct story is:
 ^M = Ctrl-M = 13 = 0x0d = CR = carriage return
 ^J = Ctrl-J = 10 = 0x0a = LF = line feed

A "Unix format" file has LF at the end of each line.
A "DOS format" file has CR LF at the end of each line.

Some stupid systems put nothing at the end of the last line.
That is what we see in your sample file (your last line has
no terminator).

John

how to get the highlighting status for search command?

[Simson Liu]

Dear all,

The search command '*' in normal mode will highlight the cursor word.
The command ':noh' in command mode will stop the highlighting. But how
to get the current highlighting status for the search command '*' in a
vim script?

Can anyone give me some hints?

Thanks.

Lht

Re: where to install tlib?

[Thomas]

I moved tmru.vim into ~/.vim/plugin, but where do I install tlib.vba?


Open the file in vim and type: :so %

See http://www.vim.org/scripts/script.php?script_id=1502 for details. 
With 7.0, you might need to install a current version of vimball first. 
(I'm not sure about that though.)

where to install tlib?

[Claus Atzenbeck]

Hi all,

I run Vim 7.0 on Mac OS X. I want to try out tmru
, which requires
tlib .

I moved tmru.vim into ~/.vim/plugin, but where do I install tlib.vba?

Cheers,
Claus

Re: vim 7.1 and cr/lf interpretation

[A.J.Mechelynck]

Thomas Michael Engelke wrote:

2007/5/15, A.J.Mechelynck <[EMAIL PROTECTED]>:

Thomas Michael Engelke wrote:
> 2007/5/15, A.J.Mechelynck <[EMAIL PROTECTED]>:
>> Thomas Michael Engelke wrote:
>> > 2007/5/14, Andy Wokula <[EMAIL PROTECTED]>:
>> >> Thomas Michael Engelke schrieb:
>> >> > :set fileformats?
>> >> >
>> >> > gives
>> >> >
>> >> > "fileformats=dos,unix", so both formats are available, yet the
>> >> > detection and switching does not seem to work.
>> >>
>> >> Are you sure _every_ line ends in "^M"?
>> >
>> > Positive. Every single line shows an ^M at the end. "set fileformat"
>> > gives "unix" after loading. Setting fileformat to "dos" doesn't 
change

>> > the files interpretation in vim. Somehow I think I miss something.
>> >
>>
>> If 'fileformats' includes "dos", then if _all_ lines end in CR+LF, the
>> 'fileformat' should be set (locally) to "dos".
>>
>> But a single line without a CR causes 'fileformat' to be set to
>> "unix", and
>> all other lines show a ^M
>>
>> Test 1:
>>
>> Load the file. Then:
>>
>> /[^[:return:]]$
>>
>> If there is a line ending in LF-without-CR, this search should find 
it.

>>
>> Test 2, variant a: To remove all carriage-returns at end-of-line:
>>
>> :set fileformats=
>> :e ++ff=dos filename
>> :setlocal ff=unix
>> :w
>>
>> Test 2, variant b: to repair any lines where a CR is missing, (by
>> adding it):
>>
>> same as 2a, but omit the line with ":setlocal ff=unix".
>>
>>
>> Then exit Vim and reload the file with your usual settings to see 
if the

>> problem has gone away. If it hasn't, do you still see it with
>>
>> vim -u /usr/local/share/vim/vim71/vimrc_example.vim
>>
>> (replace the path if necessary by wherever Vim sets $VIMRUNTIME on 
your

>> installation: on Windows it might be
>>
>> vim -u "C:\Program Files\Vim\vim71\vimrc_example.vim"
>>
>> instead)?
>
> Hello Tony, and thanks for your extensive answer. Unfortunately, this
> is what I can report. To make things easier, I'll attach the file I am
> talking about to this message so that you can either check for
> yourselves and/or see that I'm telling the truth.
>
> What is the current state: Of course, there's one line without 0x13
> 0x10 at the end, and that is the last line. As I checked using your
> regex (I'm always forgetting the :word:-syntax is available as well,
> which makes it difficult as I can never remember how to search for a
> hex char), I found one single line except the last one without 0x13
> 0x10 at the end. I removed the line in joining it with the line above
> (multi line command) and saved the file. I closed it, closed vim and
> reopened the file again. The problem persists. Now the only line your
> regex finds is the last one. "set fileformats" still evaluates to
> "dos,unix". "set fileformat" after loading the file evaluates to
> "unix". Setting it to "dos" via "set fileformat=dos" does not help the
> issue.

Apparently your last line still has a LF without CR, causing the 
heuristic to
detect the file's 'fileformat' as "unix". Ends of lines are line 
ENDINGS, not
line SEPARATORS: even the last line must have one, for various 
reasons, the

most obvious of which is that, if "file1" lacks a proper end-of-file,

copy file1+file2 file3

will concatenate the last line of file1 with the first line of file2, 
making

them a single line somewhere in the middle of file3.

Try, as I said in my previous post,

vim
:set fileformats= " cancel autodetect of fileformat
:edit ++ff=dos list02.p   " force 'dos' fileformat

Then saving the file should add a proper CR+LF ending to the last line 
(and to

any other line lacking a CR).

>
> The example file of vim (in my case,
> c:\Programme\vim\vim71a\vimrc_example.vim) loads fine and gets the
> fileformat "dos", as expected.

With -u before it on the Vim command-line, Vim should use it instead 
of your

vimrc, not as an editfile.


Assuming that fileformat "unix" means 0x10 means "open a new line"
which seems to be the case (0x13 stays as ^M, 0x10 is interpreted as a
new line), shouldn't this mean that in the last line there is a line
break missing? If I would have seen a line there with no ^M at the end
I would have seen the problem right away. But this way, it seems a
little odd that although 0x13 0x10 gives a ^M and a new line, 0x10
alone does not give a new line.



You would have seen a line with no ^M at the end? But your last line indeed 
has no ^M at the end, how come you didn't see it?


0x10 alone gives an *end* of line, not necessarily a *begin* of line. Any 
character after that, if there is one, goes on a new line. If the last line 
lacks an end-of-line it is *B* *R* *O* *K* *E* *N*, OK? Presence of an 
end-of-line character at the end of the last line doesn't mean an empty line, 
it means that the file is correctly formatted. If there isn't one, Vim will 
say [noeol] when reading and add an EOL when writing.


Since there originally was a line lac

wiki hosting

[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.

For me points 2 and 5 win. But anyway I would love to see a good VimBook
on wikibooks.

Other ideas/votes?

Sebastian.

Re: vim 7.1 and cr/lf interpretation

[Thomas Michael Engelke]

2007/5/15, A.J.Mechelynck <[EMAIL PROTECTED]>:

Thomas Michael Engelke wrote:
> 2007/5/15, A.J.Mechelynck <[EMAIL PROTECTED]>:
>> Thomas Michael Engelke wrote:
>> > 2007/5/14, Andy Wokula <[EMAIL PROTECTED]>:
>> >> Thomas Michael Engelke schrieb:
>> >> > :set fileformats?
>> >> >
>> >> > gives
>> >> >
>> >> > "fileformats=dos,unix", so both formats are available, yet the
>> >> > detection and switching does not seem to work.
>> >>
>> >> Are you sure _every_ line ends in "^M"?
>> >
>> > Positive. Every single line shows an ^M at the end. "set fileformat"
>> > gives "unix" after loading. Setting fileformat to "dos" doesn't change
>> > the files interpretation in vim. Somehow I think I miss something.
>> >
>>
>> If 'fileformats' includes "dos", then if _all_ lines end in CR+LF, the
>> 'fileformat' should be set (locally) to "dos".
>>
>> But a single line without a CR causes 'fileformat' to be set to
>> "unix", and
>> all other lines show a ^M
>>
>> Test 1:
>>
>> Load the file. Then:
>>
>> /[^[:return:]]$
>>
>> If there is a line ending in LF-without-CR, this search should find it.
>>
>> Test 2, variant a: To remove all carriage-returns at end-of-line:
>>
>> :set fileformats=
>> :e ++ff=dos filename
>> :setlocal ff=unix
>> :w
>>
>> Test 2, variant b: to repair any lines where a CR is missing, (by
>> adding it):
>>
>> same as 2a, but omit the line with ":setlocal ff=unix".
>>
>>
>> Then exit Vim and reload the file with your usual settings to see if the
>> problem has gone away. If it hasn't, do you still see it with
>>
>> vim -u /usr/local/share/vim/vim71/vimrc_example.vim
>>
>> (replace the path if necessary by wherever Vim sets $VIMRUNTIME on your
>> installation: on Windows it might be
>>
>> vim -u "C:\Program Files\Vim\vim71\vimrc_example.vim"
>>
>> instead)?
>
> Hello Tony, and thanks for your extensive answer. Unfortunately, this
> is what I can report. To make things easier, I'll attach the file I am
> talking about to this message so that you can either check for
> yourselves and/or see that I'm telling the truth.
>
> What is the current state: Of course, there's one line without 0x13
> 0x10 at the end, and that is the last line. As I checked using your
> regex (I'm always forgetting the :word:-syntax is available as well,
> which makes it difficult as I can never remember how to search for a
> hex char), I found one single line except the last one without 0x13
> 0x10 at the end. I removed the line in joining it with the line above
> (multi line command) and saved the file. I closed it, closed vim and
> reopened the file again. The problem persists. Now the only line your
> regex finds is the last one. "set fileformats" still evaluates to
> "dos,unix". "set fileformat" after loading the file evaluates to
> "unix". Setting it to "dos" via "set fileformat=dos" does not help the
> issue.

Apparently your last line still has a LF without CR, causing the heuristic to
detect the file's 'fileformat' as "unix". Ends of lines are line ENDINGS, not
line SEPARATORS: even the last line must have one, for various reasons, the
most obvious of which is that, if "file1" lacks a proper end-of-file,

copy file1+file2 file3

will concatenate the last line of file1 with the first line of file2, making
them a single line somewhere in the middle of file3.

Try, as I said in my previous post,

vim
:set fileformats= " cancel autodetect of fileformat
:edit ++ff=dos list02.p   " force 'dos' fileformat

Then saving the file should add a proper CR+LF ending to the last line (and to
any other line lacking a CR).

>
> The example file of vim (in my case,
> c:\Programme\vim\vim71a\vimrc_example.vim) loads fine and gets the
> fileformat "dos", as expected.

With -u before it on the Vim command-line, Vim should use it instead of your
vimrc, not as an editfile.


Assuming that fileformat "unix" means 0x10 means "open a new line"
which seems to be the case (0x13 stays as ^M, 0x10 is interpreted as a
new line), shouldn't this mean that in the last line there is a line
break missing? If I would have seen a line there with no ^M at the end
I would have seen the problem right away. But this way, it seems a
little odd that although 0x13 0x10 gives a ^M and a new line, 0x10
alone does not give a new line.

--
GPG-Key: tengelke.de/thomas_michael_engelke.asc

Re: vim 7.1 and cr/lf interpretation

[A.J.Mechelynck]

Thomas Michael Engelke wrote:

2007/5/15, A.J.Mechelynck <[EMAIL PROTECTED]>:

Thomas Michael Engelke wrote:
> 2007/5/14, Andy Wokula <[EMAIL PROTECTED]>:
>> Thomas Michael Engelke schrieb:
>> > :set fileformats?
>> >
>> > gives
>> >
>> > "fileformats=dos,unix", so both formats are available, yet the
>> > detection and switching does not seem to work.
>>
>> Are you sure _every_ line ends in "^M"?
>
> Positive. Every single line shows an ^M at the end. "set fileformat"
> gives "unix" after loading. Setting fileformat to "dos" doesn't change
> the files interpretation in vim. Somehow I think I miss something.
>

If 'fileformats' includes "dos", then if _all_ lines end in CR+LF, the
'fileformat' should be set (locally) to "dos".

But a single line without a CR causes 'fileformat' to be set to 
"unix", and

all other lines show a ^M

Test 1:

Load the file. Then:

/[^[:return:]]$

If there is a line ending in LF-without-CR, this search should find it.

Test 2, variant a: To remove all carriage-returns at end-of-line:

:set fileformats=
:e ++ff=dos filename
:setlocal ff=unix
:w

Test 2, variant b: to repair any lines where a CR is missing, (by 
adding it):


same as 2a, but omit the line with ":setlocal ff=unix".


Then exit Vim and reload the file with your usual settings to see if the
problem has gone away. If it hasn't, do you still see it with

vim -u /usr/local/share/vim/vim71/vimrc_example.vim

(replace the path if necessary by wherever Vim sets $VIMRUNTIME on your
installation: on Windows it might be

vim -u "C:\Program Files\Vim\vim71\vimrc_example.vim"

instead)?


Hello Tony, and thanks for your extensive answer. Unfortunately, this
is what I can report. To make things easier, I'll attach the file I am
talking about to this message so that you can either check for
yourselves and/or see that I'm telling the truth.

What is the current state: Of course, there's one line without 0x13
0x10 at the end, and that is the last line. As I checked using your
regex (I'm always forgetting the :word:-syntax is available as well,
which makes it difficult as I can never remember how to search for a
hex char), I found one single line except the last one without 0x13
0x10 at the end. I removed the line in joining it with the line above
(multi line command) and saved the file. I closed it, closed vim and
reopened the file again. The problem persists. Now the only line your
regex finds is the last one. "set fileformats" still evaluates to
"dos,unix". "set fileformat" after loading the file evaluates to
"unix". Setting it to "dos" via "set fileformat=dos" does not help the
issue.


Apparently your last line still has a LF without CR, causing the heuristic to 
detect the file's 'fileformat' as "unix". Ends of lines are line ENDINGS, not 
line SEPARATORS: even the last line must have one, for various reasons, the 
most obvious of which is that, if "file1" lacks a proper end-of-file,


copy file1+file2 file3

will concatenate the last line of file1 with the first line of file2, making 
them a single line somewhere in the middle of file3.


Try, as I said in my previous post,

vim
:set fileformats= " cancel autodetect of fileformat
:edit ++ff=dos list02.p   " force 'dos' fileformat

Then saving the file should add a proper CR+LF ending to the last line (and to 
any other line lacking a CR).




The example file of vim (in my case,
c:\Programme\vim\vim71a\vimrc_example.vim) loads fine and gets the
fileformat "dos", as expected.


With -u before it on the Vim command-line, Vim should use it instead of your 
vimrc, not as an editfile.




Thank you for your help, guys.

Thomas



Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
237. You tattoo your email address on your forehead.

Re: vim 7.1 and cr/lf interpretation

[Micah Cowan]

Thomas Michael Engelke wrote:
> Hello Tony, and thanks for your extensive answer. Unfortunately, this
> is what I can report. To make things easier, I'll attach the file I am
> talking about to this message so that you can either check for
> yourselves and/or see that I'm telling the truth.
> 
> What is the current state: Of course, there's one line without 0x13
> 0x10 at the end, and that is the last line. As I checked using your
> regex (I'm always forgetting the :word:-syntax is available as well,
> which makes it difficult as I can never remember how to search for a
> hex char), I found one single line except the last one without 0x13
> 0x10 at the end. I removed the line in joining it with the line above
> (multi line command) and saved the file. I closed it, closed vim and
> reopened the file again. The problem persists. Now the only line your
> regex finds is the last one. "set fileformats" still evaluates to
> "dos,unix". "set fileformat" after loading the file evaluates to
> "unix". Setting it to "dos" via "set fileformat=dos" does not help the
> issue.

It doesn't matter whether it's the very last line or not: if a single
line (even at the end) ends in \n without \r, it is unix-format (note
that if it the final line had not ended at all, it would have been dos).

-- 
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/



signature.asc
Description: OpenPGP digital signature

Re: Appending to Paste (*) Register

[A.J.Mechelynck]

zzapper wrote:

"Yegappan Lakshmanan" <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]: 


Hi,

On 5/14/07, zzapper <[EMAIL PROTECTED]> wrote:

Hi
I believe that the problem of Appending to Paste (*) Register was one
of the points Bram was looking at (problem is no uppercase for a
symbol) 


Was there


In Vim7 and above, you can append the output of an ex command to the
clipboard register '*' using the following command:

  :redir @*>>

- Yegappan

From the doc how are the following different?

:redi[r] @*> 
:redi[r] @+>		Redirect messages to the selection or clipboard. 
For

backward compatibility, the ">" after the register
name can be omitted. See |quotestar| and |quoteplus|.
{not in Vi}
:redi[r] @*>> 
:redi[r] @+>> Append messages to the selection or clipboard.
{not in Vi}


Anyway I was looking for something like

:g/fred/y A  append to register a but for the clipboard register *





1) @*> and @+> clobber the register, @*>> and @+>> append to it.

2) * and + are synonymous, except on X systems, where "+ is the CLIPBOARD 
(pasted into other programs by Edit => Paste or Ctrl-V), while "* is the 
SELECTION (pasted by MiddleMouse).



For yanking, you may use something like

:g/fred/yank | let @a .= @0


Best regards,
Tony.
--
Mencken and Nathan's Fifteenth Law of The Average American:
The worst actress in the company is always the manager's wife.

Re: vim 7.1 and cr/lf interpretation

[Thomas Michael Engelke]

2007/5/15, A.J.Mechelynck <[EMAIL PROTECTED]>:

Thomas Michael Engelke wrote:
> 2007/5/14, Andy Wokula <[EMAIL PROTECTED]>:
>> Thomas Michael Engelke schrieb:
>> > :set fileformats?
>> >
>> > gives
>> >
>> > "fileformats=dos,unix", so both formats are available, yet the
>> > detection and switching does not seem to work.
>>
>> Are you sure _every_ line ends in "^M"?
>
> Positive. Every single line shows an ^M at the end. "set fileformat"
> gives "unix" after loading. Setting fileformat to "dos" doesn't change
> the files interpretation in vim. Somehow I think I miss something.
>

If 'fileformats' includes "dos", then if _all_ lines end in CR+LF, the
'fileformat' should be set (locally) to "dos".

But a single line without a CR causes 'fileformat' to be set to "unix", and
all other lines show a ^M

Test 1:

Load the file. Then:

/[^[:return:]]$

If there is a line ending in LF-without-CR, this search should find it.

Test 2, variant a: To remove all carriage-returns at end-of-line:

:set fileformats=
:e ++ff=dos filename
:setlocal ff=unix
:w

Test 2, variant b: to repair any lines where a CR is missing, (by adding it):

same as 2a, but omit the line with ":setlocal ff=unix".


Then exit Vim and reload the file with your usual settings to see if the
problem has gone away. If it hasn't, do you still see it with

vim -u /usr/local/share/vim/vim71/vimrc_example.vim

(replace the path if necessary by wherever Vim sets $VIMRUNTIME on your
installation: on Windows it might be

vim -u "C:\Program Files\Vim\vim71\vimrc_example.vim"

instead)?


Hello Tony, and thanks for your extensive answer. Unfortunately, this
is what I can report. To make things easier, I'll attach the file I am
talking about to this message so that you can either check for
yourselves and/or see that I'm telling the truth.

What is the current state: Of course, there's one line without 0x13
0x10 at the end, and that is the last line. As I checked using your
regex (I'm always forgetting the :word:-syntax is available as well,
which makes it difficult as I can never remember how to search for a
hex char), I found one single line except the last one without 0x13
0x10 at the end. I removed the line in joining it with the line above
(multi line command) and saved the file. I closed it, closed vim and
reopened the file again. The problem persists. Now the only line your
regex finds is the last one. "set fileformats" still evaluates to
"dos,unix". "set fileformat" after loading the file evaluates to
"unix". Setting it to "dos" via "set fileformat=dos" does not help the
issue.

The example file of vim (in my case,
c:\Programme\vim\vim71a\vimrc_example.vim) loads fine and gets the
fileformat "dos", as expected.

Thank you for your help, guys.

Thomas

--
GPG-Key: tengelke.de/thomas_michael_engelke.asc


list02.p
Description: Binary data

Re: Appending to Paste (*) Register

[zzapper]

"Yegappan Lakshmanan" <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]: 

> Hi,
> 
> On 5/14/07, zzapper <[EMAIL PROTECTED]> wrote:
>> Hi
>> I believe that the problem of Appending to Paste (*) Register was one
>> of the points Bram was looking at (problem is no uppercase for a
>> symbol) 
>>
>> Was there
>>
> 
> In Vim7 and above, you can append the output of an ex command to the
> clipboard register '*' using the following command:
> 
>   :redir @*>>
> 
> - Yegappan
> 
>From the doc how are the following different?
:redi[r] @*>
:redi[r] @+>Redirect messages to the selection or clipboard. 
For
backward compatibility, the ">" after the register
name can be omitted. See |quotestar| and |quoteplus|.
{not in Vi}
:redi[r] @*>>   
:redi[r] @+>>   Append messages to the selection or clipboard.
{not in Vi}


Anyway I was looking for something like

:g/fred/y A  append to register a but for the clipboard register *



-- 
zzapper
http://www.rayninfo.co.uk/vimtips.html

RE: Vim Wiki - Wiki Template Proposal

[Sebastian Menge]

Thanks for the feedback!

1) I think learning to fillout the template is easier than learning wiki
markup.

2) Im pretty sure there is a way to post a new tip by means of an HTML
Form. Perhaps Martin knows more about the abilities of mediawiki in this
respect. There is an extension called "InbutBox" but I have not
understood yet howto use it.

3) The template I posted was just a very first (and ugly) prototype
intended to keep the whole layout question off this list! If you don't
like it, feel free to change it: It's a wiki!

Sebastian.

MSVC build option about default library MSVCRT

[Yongwei Wu]

Hi Bram,

I am wondering whether l. 705 of Make_mvc.mak in vim-7.1-extra.tar.gz
should be change from

 LINKARGS1 = $(linkdebug) $(conflags) /nodefaultlib:libc

to

 LINKARGS1 = $(linkdebug) $(conflags) /nodefaultlib:libc /nodefaultlib:msvcrt

I have been using it for maybe half a year and not found a single
problem yet. It will eliminate this message when building vim.exe:

libcmt.lib(crt0init.obj) : warning LNK4098: defaultlib 'msvcrt.lib'
conflicts with use of other libs; use /NODEFAULTLIB:library

Without /nodefaultlib:msvcrt vim.exe will have a dependency on
MSVCR71.DLL (I use MSVC 7.1). This added flag will not affect
gvim.exe. The command lines I used are:

nmake -f Make_mvc.mak GUI=yes OLE=yes MBYTE=yes IME=yes GIME=yes
CSCOPE=yes PERL=C:\Perl DYNAMIC_PERL=yes PERL_VER=58
PYTHON=C:\Python24 DYNAMIC_PYTHON=yes PYTHON_VER=24 RUBY=C:\ruby
DYNAMIC_RUBY=yes RUBY_VER=18 RUBY_VER_LONG=1.8 TCL=C:\Tcl
DYNAMIC_TCL=yes TCL_VER=84 TCL_VER_LONG=8.4 XPM=C:\xpm %*
nmake -f Make_mvc.mak MBYTE=yes CSCOPE=yes PERL=C:\Perl
DYNAMIC_PERL=yes PERL_VER=58 PYTHON=C:\Python24 DYNAMIC_PYTHON=yes
PYTHON_VER=24 RUBY=C:\ruby DYNAMIC_RUBY=yes RUBY_VER=18
RUBY_VER_LONG=1.8 TCL=C:\Tcl DYNAMIC_TCL=yes TCL_VER=84
TCL_VER_LONG=8.4 XPM=C:\xpm %*

Best regards,

Yongwei

--
Wu Yongwei
URL: http://wyw.dcweb.cn/

Re: Stable Vim version 7.1 has been released

[Bram Moolenaar]

Yongwei Wu wrote:

> > > On 13/05/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Announcing:  Vim (Vi IMproved) version 7.1
> > >
> > > I guess you already know about them. Just in case:
> > >
> > > * The home page still says "Vim 7.0.243 is the current version"
> >
> > That should be fixed automatically when the first patch goes out,
> > which will be soon...
> 
> I see it now :-)
> 
> > > * Sources and Patches pages are not updated.
> >
> > Please give me the URL of where something wrong appears.  That saves
> > me a lot of time (which I don't have much of...).
> 
> OK. Checking more thoroughly now.
> 
> http://www.vim.org/download.php
>   The left side still has (wow, should be a long time ago, and I did
>   not notice it all the time): "Vim 6.4 has been released. Many people
>   have helped...".
> 
> http://www.vim.org/sources.php
>   The information is about Vim 7.0 and 6.4, but no 7.1.
> 
> http://www.vim.org/patches.php
>   Only 7.0 README.
> 
> http://www.vim.org/subversion.php
>   7.1 is marked unstable there.

Thanks, I've updated them.

- Bram

-- 
hundred-and-one symptoms of being an internet addict:
133. You communicate with people on other continents more than you
 do with your own neighbors.

 /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

Re: compiling vim7.1 (huge version) gets build with normal version

[A.J.Mechelynck]

Tushar Desai wrote:

I recently did a clean install of Ubuntu 7.04 and also installed all
vim related packages. That got me a gui version of vim (7.0.164/Big
compiled on 2007/03/11).

I now want to compile and install the gui version of vim 7.1. So, I
downloaded the tar-ball for the 7.1 sources to my home dir
($HOME/vim), untarred at ($HOME)/vim/vim71, enabled "CONF_OPT_FEAT =
--with-features=huge" in the src/Makefile. I also did "apt-get
build-dep vim" and finally ./configure followed by make (in
$HOME/vim/vim71).

However, I'm ending up with the "Normal version" of vim and although
"vim -g" pops up a window, it doesn't show the menu and the toolbar.

I tried the same on Fedora Core 6 and got the same results. I tried
vim7.0 on ubuntu and have the same situation. Strangely enough, I was
previously able to compile vim7.0 on my Fedora Core 6 box and it gave
the menu and toolbar. (I don't know what I did right in that case.).

Any idea what I could be happening here?

Thanks,
Tushar.



I suspect your configure step and your make step are setting different 
options. Here's what I suggest:


1. Undo any changes you made to the Makefile.

2. Paste the following text as $HOME/vim/vim71/myconfig. It doesn't need to be 
made executable.


#!/bin/bash
export CONF_OPT_GUI='--enable-gnome-check'
export CONF_OPT_PERL='--enable-perlinterp'
export CONF_OPT_PYTHON='--enable-pythoninterp'
export CONF_OPT_TCL='--enable-tclinterp --with-tcl=tclsh8.4'
export CONF_OPT_RUBY='--enable-rubyinterp'
export CONF_OPT_MZSCHEME='--disable-mzschemeinterp'
#export CONF_OPT_PLTHOME='--with-plthome=/usr/local/plt'
export CONF_OPT_CSCOPE='--enable-cscope'
export CONF_OPT_MULTIBYTE='--enable-multibyte'
export CONF_OPT_FEAT='--with-features=huge'
export CONF_OPT_COMPBY='"[EMAIL PROTECTED]"'

3. Edit it (change at least the last line) to reflect your desired settings.

4. Do the following, in bash:

source myconfig
cd src
make reconfig 2>&1 |tee ../config.log

(It is important to "source" the script, not "run" it.) This should re-run 
configure and proceed to compile. If the configure step suggests that you 
delete config.cache or something, do it, then repeat the last line above.


5. If the compile proceeds to its end:

ls -l vim

(if there is a vim executable with a timestamp of a few seconds ago):

./vim --version |more

6. If you got the desired "huge" version, you can then

cd ..
make install 2>&1 |tee install.log

If you still did _not_ get a "huge" version, inspect ~/vim/vim71/config.log 
for details of what might have gone wrong.




Best regards,
Tony.
--
Q:  How many DEC repairman does it take to fix a flat ?
A:  Five; four to hold the car up and one to swap tires.

RE: Vim Wiki - Wiki Template Proposal

[Zdenek Sekera]

> -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: Appending to Paste (*) Register

[Yegappan Lakshmanan]

Hi,

On 5/14/07, zzapper <[EMAIL PROTECTED]> wrote:

Hi
I believe that the problem of Appending to Paste (*) Register was one of the
points Bram was looking at (problem is no uppercase for a symbol)

Was there/will there be any progress?

Here's a hack I use

let @w=":redir @*^M:g//^M:redir END"



In Vim7 and above, you can append the output of an ex command to the
clipboard register '*' using the following command:

  :redir @*>>

- Yegappan