Re: embedable vim?

[Greg Novack]

Thus spake Franco Saliola [05/16/07 @ 21.26.10 -0400]:
> Is there a way to embed vim into my browser (or any other application
> for that matter)?
> 
> I hate typing in the html text boxes and would much prefer to use vim
> to edit my email.
> 
> Or are there any suggestions on reading/writing email using Gmail and Vim?
> 
> I'll create a tip if I figure out a good method.
> 

Well, if you have MacOSX Tiger, there's a freeware utility called Vi Input 
Manager: http://www.macupdate.com/info.php/id/22864/vi-input-manager

This lets you call a decent subset of vim in any text field in any Cocoa 
application, which inlcudes Safari and Camino (the latter is Mac-ified Firefox, 
in a manner of speaking).  So long as you use a Cocoa-based browser to check 
Gmail, you should be able to do the most useful vimmaneuvers on your email.

I have no idea if there are utilities like this for other platforms.

-Greg

Re: enabling cyrillic character display support

[Snucky]

Yongwei Wu wrote:
> 
> Please describe in more detail, so other people understand if it is a
> display issue or
> encoding issue.  The above discussion addresses the encoding issue,
> i.e., the Cyrillic characters are displayed in Latin-1 or things like
> that.  If some squares are in the place of the characters, but the
> number of characters are correct, it may be a font problem.  Just check
> to ensure you have the Cyrillic support installed on your Windows
> system, and put this in your _vimrc:
> 
> :set guifont=Courier_New:h10:cDEFAULT
> 

it was indeed a font-issue, how embarrassing!! ... Just a bit sad that my
favorite font (Fixedsys) doesn't support cyrillic characters. Well, a matter
of habit.

Thank you all for your support! I am gladly using my VIM now with a proper
display for me, newbie :)
btw: i was always surprised why, after saving, the cyrillic chars would
still be displayed in the other editor. Now i know...

пока всем!
-- 
View this message in context: 
http://www.nabble.com/enabling-cyrillic-character-display-support-tf3762452.html#a10658315
Sent from the Vim - General mailing list archive at Nabble.com.

Flashing omnicomplete menu

[Michael F. Lamb]

In gVim (and console vim) 7.0 under linux, when using omnicomplete with 
a large list of choices, scrolling through the list causes the whole 
omnicomplete menu to be cleared and redrawn, which creates an annoying 
"flashing" effect.


Is this a bug? Is there a way to fix this?

Re: embedable vim?

[A.J.Mechelynck]

Franco Saliola wrote:

Is there a way to embed vim into my browser (or any other application
for that matter)?

I hate typing in the html text boxes and would much prefer to use vim
to edit my email.

Or are there any suggestions on reading/writing email using Gmail and Vim?

I'll create a tip if I figure out a good method.

Thank you,
Franco

--



It all depends on your browser (or other application for that matter). Some 
browsers (or other applications) support defining an external editor, either 
natively as (IIRC) kde applications do, or by means of an extensions (as 
seveal other posts mention doing for Firefox). Other browsers (such as IE 
IIRC) simply don't support any external editor.



Best regards,
Tony.
--
... The Anarchists' [national] anthem is an international anthem that
consists of 365 raspberries blown in very quick succession to the tune
of "Camptown Races".  Nobody has to stand up for it, nobody has to
listen to it, and, even better, nobody has to play it.
-- Mike Harding, "The Armchair Anarchist's Almanac"

Re: map gives me headache!

[Winfred Lu]

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

Try this out.

function! RaiseEnter()
 let i = winbufnr(winnr())
 if getbufvar(i, '&buftype') == 'quickfix'
 exe "nunmap "
 endif
endfunction

function! KillEnter()
 let i = winbufnr(winnr())
 if getbufvar(i, '&buftype') == 'quickfix'
 exe "nmap  "
 endif
endfunction

Regards,
Winfred

Re: embedable vim?

[Chris Grau]

On Wed, May 16, 2007 at 09:26:10PM -0400, Franco Saliola wrote:
> Is there a way to embed vim into my browser (or any other application
> for that matter)?
> 
> I hate typing in the html text boxes and would much prefer to use vim
> to edit my email.
> 
> Or are there any suggestions on reading/writing email using Gmail and
> Vim?
> 
> I'll create a tip if I figure out a good method.

This won't be very useful to you unless you use Firefox, but I've been
using the "It's All Text" extension to launch gvim to edit HTML text
areas, including GMail.

https://addons.mozilla.org/en-US/firefox/addon/4125

-- 
Chris Grau


pgpAO7hFvNm59.pgp
Description: PGP signature

Re: embedable vim?

[Pete Johns]

On Wed, 2007-05-16 at 21:26:10 -0400, Franco Saliola sent:
>I hate typing in the html text boxes and would much prefer to
>use vim to edit my email.
>
Don't we all? Using w3m, it's easy to use Vim to edittext areas.
I shall assume that you are using a graphic web-browser and
assume further that you are using Firefox. In which case then
there a couple of extensions / add-ins for Firefox which you can
use.

My preference is:
ViewSourceWith 

Others like:
It's All Text! 

Both require a little configuration to tell them where (g)Vim is,
etc. This was discussed on this list a little while ago
.

This isn't embedding /per se/, but it does help with email
composition.

Best;

--paj

--
Pete Johns   
Contact Information  
Ubuntu 
MovieWorld LogFlume  



pgpwsPUUIbJ76.pgp
Description: PGP signature

Re: embedable vim?

[fREW]

On 5/16/07, Franco Saliola <[EMAIL PROTECTED]> wrote:

Is there a way to embed vim into my browser (or any other application
for that matter)?

I hate typing in the html text boxes and would much prefer to use vim
to edit my email.

Or are there any suggestions on reading/writing email using Gmail and Vim?

I'll create a tip if I figure out a good method.

Thank you,
Franco

--



Try searching the tips database.  I remember reading something once
about sending gmail with vim.  Reading it with vim is harder, and if
you really want to do that you will want to look into using the gmail
pop3 with mutt.  I think that you can embed vim with konqueror or
something like that, but for the most part you should vote for that as
a feature in vim.  Currently it is #4.  Hope that helps.

[1] http://www.vim.org/sponsor/vote_results.php

-fREW

Re: Identify this Vim font for me, please

[panshizhu]

"A.J.Mechelynck" <[EMAIL PROTECTED]> 写于 2007-05-17 09:19:03:
> I don't think that font is available on Motorola Macs (including Power
PCs).
> It may or may not be available in Intel Macs but I don't know how to get
at
> it. Maybe the same way on OS X as on Linux above, I'm not sure.
> Best regards,
> Tony.
> --

I can confirm that intel-based Macs had this in full-screen text console. I
can do this by boot MS-DOS or most flavors of Linux LiveCD on an
intel-based Mac.

--
Sincerely, Pan, Shi Zhu. ext: 2606

Re: Vim71: breaking change not mentioned in the document.

[A.J.Mechelynck]

[EMAIL PROTECTED] wrote:

Hi, vimmers:

The line 1230 of editing.txt said:

To change to the directory of the current file:
:cd %:h

This works for Vim 7.0 and before, but not for Vim 7.1. In Vim 7.1 when the
pwd is the same as the directory of current file, the command will fail
with E500. The failure will break the execution of a mapping, if one have a
mapping to do :cd %:h and then continue to do something else.

To reproduce the error, just at anytime, run :cd %:h twice. (I've got
Windows gvim7.1.1, cygwin console vim 7.1.1)

So there's at least two issues IMHO:
1. the line 1230 of editing.txt should be changed to :cd %:p:h
2. somewhere in the document should mention: if we had used :cd %:h in our
mappings or scripts, we should change them into %:p:h after upgraded to vim
7.1.

Or did I missed anything?
--
Sincerely, Pan, Shi Zhu. ext: 2606



I agree with point 1.

As for point 2, the way I remember it, ":cd %:h" and ":lcd %:h" already failed 
on Vim 6.3 or maybe earlier, if the current filename (as displayed e.g. on the 
status line) had no explicit path before it. So apparently one of us either 
missed something or remembered something the wrong way.


Note that ":cd" (without an argument) has different meanings on different 
OSes, thus reflecting the OS's idiosyncrasies: on Windows it is synonymous 
with ":pwd", on Linux with ":cd $HOME".



Best regards,
Tony.
--
"Here's something to think about:  How come you never see a headline like
`Psychic Wins Lottery'?"
-- Jay Leno

embedable vim?

[Franco Saliola]

Is there a way to embed vim into my browser (or any other application
for that matter)?

I hate typing in the html text boxes and would much prefer to use vim
to edit my email.

Or are there any suggestions on reading/writing email using Gmail and Vim?

I'll create a tip if I figure out a good method.

Thank you,
Franco

--

Re: Vim71: breaking change not mentioned in the document.

[Gary Johnson]

On 2007-05-17, [EMAIL PROTECTED] wrote:
> Gary Johnson <[EMAIL PROTECTED]>  2007-05-17 00:35:42:
> > On 2007-05-16, [EMAIL PROTECTED] wrote:
> > > Gary Johnson <[EMAIL PROTECTED]>  2007-05-16 16:41:22:
> > > > On 2007-05-16, [EMAIL PROTECTED] wrote:
> > > > > Hi, vimmers:
> > > > >
> > > > > The line 1230 of editing.txt said:
> > > > >
> > > > > To change to the directory of the current file:
> > > > > :cd %:h
> > > > >
> > I don't think disabling E500 would help.  The text of E500 is,
> > "E500: Evaluates to an empty string".  That's warning you that there
> > is no head component of the file name.  If you disabled the error,
> > and presumably allowed %:h to return an empty string, then your ":cd
> > %:h" command would be executing just ":cd", which on a Unix system
> > changes to the home directory--not what you want.
> >
> > Another way to fix your mapping would be to use
> >
> >:silent! cd %:h
> >
> > which allows the cd to fail silently.
> >
> > Regards,
> > Gary
> >
> > --
> 
> You certainly are right, disabling E500 would not help. However:
> 
> > The line 1230 of editing.txt said:
> >
> > To change to the directory of the current file:
> > :cd %:h
> 
> If I was tell that a script could change to the directory of the current
> file, I would think that it will always change to the directory of the
> current file, and it is absurd to see it will give an error when the pwd is
> already the directory of the current file.
> 
> I'm sure most average users will take it for granted if the document says
> this. and they will not think the E500 is reasonable here. The document is
> aprently misleading.

I see what you mean.  Not everyone would read "change to the 
directory of the current file" as literally as I did in my initial 
reply.  While the manual is correct, it could be more clear here.

> So, if :cd %:h must give E500 here, I think the document should change it
> to :cd %:p:h

Yes, that seems reasonable.

Regards,
Gary

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

Re: Identify this Vim font for me, please

[A.J.Mechelynck]

madiyaan wrote:

Hello,

This isn't very related to Vim, but I found this font on Vim's wikipedia
webpage:

http://upload.wikimedia.org/wikipedia/commons/8/8c/Vim-%28logiciel%29-console.png

Can anyone identify this font for me? It looks very good for programming.

Thank you very much,


That's the 80x25 font cooked into the PC ROM-BIOS.

To use it on Windows: open a Dos Box, then select Alt-Space => Properties
Select 80 columns, 25 lines and "Full screen" display.

On Linux: hit Ctrl-Alt-Fn (with n in the range [1..6]), then log in with 
username and password.


I don't think that font is available on Motorola Macs (including Power PCs). 
It may or may not be available in Intel Macs but I don't know how to get at 
it. Maybe the same way on OS X as on Linux above, I'm not sure.


In both cases, you can then invoke Vim as "vim" (not "gvim"). For Windows, 
you'll need a console version (compiled as "vim.exe") for that. On Linux, a 
single binary can do double duty as Console Vim and as gvim GUI.



Best regards,
Tony.
--
Yea, though I walk through the valley of the shadow of APL, I shall
fear no evil, for I can string six primitive monadic and dyadic
operators together.
-- Steve Higgins

Re: Vim71: breaking change not mentioned in the document.

[panshizhu]

Gary Johnson <[EMAIL PROTECTED]> 写于 2007-05-17 00:35:42:
> On 2007-05-16, [EMAIL PROTECTED] wrote:
> > Gary Johnson <[EMAIL PROTECTED]>  2007-05-16 16:41:22:
> > > On 2007-05-16, [EMAIL PROTECTED] wrote:
> > > > Hi, vimmers:
> > > >
> > > > The line 1230 of editing.txt said:
> > > >
> > > > To change to the directory of the current file:
> > > > :cd %:h
> > > >
> I don't think disabling E500 would help.  The text of E500 is,
> "E500: Evaluates to an empty string".  That's warning you that there
> is no head component of the file name.  If you disabled the error,
> and presumably allowed %:h to return an empty string, then your ":cd
> %:h" command would be executing just ":cd", which on a Unix system
> changes to the home directory--not what you want.
>
> Another way to fix your mapping would be to use
>
>:silent! cd %:h
>
> which allows the cd to fail silently.
>
> Regards,
> Gary
>
> --

You certainly are right, disabling E500 would not help. However:

> The line 1230 of editing.txt said:
>
> To change to the directory of the current file:
> :cd %:h

If I was tell that a script could change to the directory of the current
file, I would think that it will always change to the directory of the
current file, and it is absurd to see it will give an error when the pwd is
already the directory of the current file.

I'm sure most average users will take it for granted if the document says
this. and they will not think the E500 is reasonable here. The document is
aprently misleading.

So, if :cd %:h must give E500 here, I think the document should change it
to :cd %:p:h

--
Sincerely, Pan, Shi Zhu. ext: 2606

Re: enabling cyrillic character display support

[A.J.Mechelynck]

Yongwei Wu wrote:
[...]

If you are courageous enough see a real-world example of complicated
multi-language support, check my _vimrc at:

http://wyw.dcweb.cn/download.asp?path=vim&file=_vimrc.txt (as text) or
http://wyw.dcweb.cn/download.asp?path=vim&file=_vimrc.html (as HTML)

Best regards,

Yongwei



I see a number of tests for has("eval") in this vimrc, sometimes embedded in 
longer if clauses.


Note that the following:

if has("gui_running)
" do something
endif
"
" then later
"
if ! has("gui_running)
" blah blah
if has("eval")
" do something
endif
" more blah blah
endif

will do nothing at all (neither the 'if has("gui_running")' nor the 'if ! 
has("gui_running") will be run) if expression evaluation is not compiled-in, 
because in that case the if...endif structure is treated as a nestable 
comment: see ":help no-eval-feature".


The one way that I know of executing some statements _only_ if evaluation is 
not compiled-in, is to place them at the end of a script (such as a vimrc), as 
follows:


if 1
finish
endif
" the following, to the end of the script, runs only if
" evaluation is not compiled-in.


Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
240. You think Webster's Dictionary is a directory of WEB sites.

Re: Vim Wiki - Tip Page Formatting Deadline

[fREW]

On 5/16/07, A.J.Mechelynck <[EMAIL PROTECTED]> wrote:

Gene Kwiecinski wrote:
>> Thinking about how a wiki works shows that keeping tip numbers
>> is doomed. First, there is no auto-increment id, and as you
>> point out, there is no reasonable way to automate fixes.
>
> Is there any equivalent to javascript's document.lastModified?
>
> Can create a "serial number" based on the date of submission, then
> rearrange by fields to a sortable ID, eg 2007.05.15.23.53 for a tip
> created yesterday at 23:53.
>
> Don't need dots, or hyphens, or anything, as 2007051523353 would be
> fine, too.  The odds of having 2 tips be submitted in the same minute
> would be remote.
>
>

I don't think so. A minute is sixty seconds, and sooner or later we'll have
two different users submitting tips less than sixty (or even thirty) seconds
away from each other. Even adding the seconds to the ID doesn't clear the
problem, it lowers the probability but doesn't make it zero. With enough
Vimmers adding tips, sooner or later there'll be a clash.


Best regards,
Tony.
--
If the odds are a million to one against something occurring, chances
are 50-50 it will.



I still think we could automate it with a cron job.  It doesn't have
to be run on wikia.  I don't think it would be that hard to scrape and
moving a tip is even simpler.  So you just move all the tips created
since the last run of the cron job and move them to "$id - $title"

-fREW

Re: Vim Wiki - Tip Page Formatting Deadline

[A.J.Mechelynck]

Gene Kwiecinski wrote:

Thinking about how a wiki works shows that keeping tip numbers
is doomed. First, there is no auto-increment id, and as you
point out, there is no reasonable way to automate fixes.


Is there any equivalent to javascript's document.lastModified?

Can create a "serial number" based on the date of submission, then
rearrange by fields to a sortable ID, eg 2007.05.15.23.53 for a tip
created yesterday at 23:53.

Don't need dots, or hyphens, or anything, as 2007051523353 would be
fine, too.  The odds of having 2 tips be submitted in the same minute
would be remote.




I don't think so. A minute is sixty seconds, and sooner or later we'll have 
two different users submitting tips less than sixty (or even thirty) seconds 
away from each other. Even adding the seconds to the ID doesn't clear the 
problem, it lowers the probability but doesn't make it zero. With enough 
Vimmers adding tips, sooner or later there'll be a clash.



Best regards,
Tony.
--
If the odds are a million to one against something occurring, chances
are 50-50 it will.

Re: OT: net neutrality comments to FCC

[Alan G Isaac]

Someone wrote:
> Here is the URL for submitting e-mail comments: 
> http://www.fcc.gov/cgb/ecfs/email.html
> I found it by starting at the FCC home page, www.fcc.gov 
> and following the link from the left side-bar labeled 
> "Filing Public Comments", "main". That page didn't have 
> 07-52, so I followed the "Other Comments", "expert 
> version" link in that page's left side-bar, and from there 
> the "Email Filing Instructions" link near the bottom of 
> the page.
> If you post that URL to the vim list, I'd prefer it if you 
> didn't say whom you got it from.

Thanks!
Alan

Re: Identify this Vim font for me, please

[Greg Novack]

Thus spake madiyaan [05/16/07 @ 00.41.45 -0700]:
> 
> Hello,
> 
> This isn't very related to Vim, but I found this font on Vim's wikipedia
> webpage:
> 
> http://upload.wikimedia.org/wikipedia/commons/8/8c/Vim-%28logiciel%29-console.png
> 
> Can anyone identify this font for me? It looks very good for programming.
> 
> Thank you very much,
> -- 

It sure looks to me like the Linux console, before one logs into Xwindows.  At 
least, that's definitely the font that Yellowdog Linux uses.  It also pretty 
clearly does not match the two suggestions at the bottom of the Wikipedia page. 
 Just look at "p", "f", and "d".

HTH,
G

Re: Syntax highlightning

[Manfred Rondorf]

> What do you mean by outline?

I think outline was the wrong word. I just want to highlight functions.
-- 
Pt! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger

Re: Identify this Vim font for me, please

[Friedrich Strohmaier]

Hi madiyaan, *,

madiyaan schrieb:

>Hello,
>
>This isn't very related to Vim, but I found this font on Vim's
> wikipedia webpage:
>
>http://upload.wikimedia.org/wikipedia/commons/8/8c/Vim-%28logiciel%29console.png

>Can anyone identify this font for me?

It's called "console" and I'm using it every day.

>It looks very good for programming.

Oh, it *is*! :o))

But as you read: tastes are different ;o))
It works fine here in my linux environment.

regards
-- 
Friedrich 

Schöne Grüße von der Schwäbischen Alb

OT: net neutrality comments to FCC

[Alan G Isaac]

Apologies if this is too off topic!
(And it mostly interests US residents, I think.)

I am looking at this through the lens of securing
my access to the Vim website.

The FCC is accepting public comment on
Docket 07-52, In the Matter of Broadband Industry Practices.
Essential, large ISPs are requesting the right to offer
fee based prioritization of web traffic.

I did not find how to comment on the FCC site, but
until someone posts how to do that, you can use the
Common Cause form at
http://www.commoncause.org/InternetFreedom>

My letter (based on theirs) follows.

Cheers,
Alan Isaac



Re: Docket 07-52, In the Matter of Broadband Industry Practices

Please act now to protect net neutrality!

Net neutrality is the longstanding principle that prevents 
discrimination on the Internet.  Countries deviating from 
net neutrality do so primarily as a means of political 
oppression.  Net neutrality protects political as well as 
economic liberties.

Net neutrality was the basis of the growth of the Internet.  
Deviations of net neutrality put Internet providers in the 
position of being able to tax Internet commerce, which will 
damage its growth.  Stop special interests from killing the 
goose that laid the golden egg!

Telephone and cable companies wish to change the way the 
Internet operates.  Instead of an open Internet that ensures 
every website can be readily accessed by anyone with 
Internet service, they want to control this access and 
implement a a fee-based system.  It is easy to foresee that 
the websites of nonprofits, small businesses, bloggers, 
artists, and even political candidates will become more 
difficult to find or use.  It is also likely that this power 
to limit access will quickly be abused, as it is abused 
today in countries that do not insist on net neutrality.  
That would be a disaster for our economy, our culture, and 
our democracy.

I count on the Federal Communications Commission to protect 
consumers like me from companies that would like to 
discriminate against certain types of content on the web.

I strongly urge you to support net neutrality principles 
that prohibit broadband providers from blocking, impeding or 
interfering with any lawful Internet traffic, or 
prioritizing any content or services.

Thank you.

RE: regex help

[Gene Kwiecinski]

>>>Well,
>>>:g/^\(.\{8}\)\(.*\)\n\(\s{8}\)/s//\1\2\r\1/
>>>   ^
>>>works, but I'd have to run it 12 times if there are twelve blanks
>>>after the filled in line.

>>Hm?  Not sure why you escaped the '{'.  Apparently didn't need to  
>>after
>>the "\s".

>You are right - it was a typo - I actually need to escape both of them
-

>:g/^\(.\{8}\)\(.*\)\n\(\s\{8}\)/s//\1\2\r\1/
>^ ^

Ah, lookit that...  '[' is normally magic unless you escape it to
literal text, and '{' is normally literal text unless you escape it to
magic.  Eerie, don't think I had occasion to put that to the test
before.

Hah, learn something new every day...

Been using "{#}" notation in lex/js/perl so long, don't think I had
occasion to actually use them in 'vim', else I would've run into that
problem before.

Re: Go to start of visual selection

[Andy Wokula]

Andy Wokula schrieb:

Tim Chase schrieb:

How can I move the cursor the start of the visual selection?
With the "o" command, yes.  But how can I make sure the cursor
is at the start while visual mode is on?  The "`<" motion
followed by "gv" sets the cursor back to the end if it was
there.


I think it sounds like you want something like the following:

vnoremap gt `>:exec 'norm '.visualmode().'`'
vnoremap gb `:exec 'norm '.visualmode().'`>'

which gives you a "Go to the Top" and "Go to the Bottom" mapping 
within visual mode.


It can be a little funky in blockwise visual-mode, if your '< and '> 
points are top-right and bottom-left (rather than top-left and 
bottom-right), as the "top" will go to the top-right, not the 
top-left.  I haven't figured out a good way to do this without 
considerably more code in the mapping (save the column of '< and then 
"gvO" to go back to visual-mode but in the other corner and then 
compare the columns to see which you want, perhaps needing to switch 
back...it's ugly).


However, it should work fine in character-wise and line-wise visual 
modes.


HTH,

-tim


I don't understand why this works.

There must be a difference between
`>v`<
and
:normal `>v`<

"v" defines a new visual area and overwrites the `<,`> markers.  Why
does "`<" after ":normal" move the cursor to the start of the
_previously_ selected visual area?

Thx,
Andy


Ah, with a later Vim7 there is no difference any more.
Obviously this has been fixed with patch 125, dated August 2006.
Ok, this took three months till I got it ...

--
Regards,
Andy

Re: regex help

[Tim Chase]

:g/^\s\{8}/-s/^\(.\{8}\).*\n\zs\s\{8}/\1


I don't understand that regex completely - but it deletes
lines of data :-)

Looks like it globably matches the 'blank start' lines, then
searches in that for the pattern - thus deleting the third
line...


That's really odd...the "\zs" *should* be forcing the substitute
to start on the "next" line.  I suspect I've stumbled across an
odd bug?  Switching it to the following

  :g/^\s\{8}/-s/^\(.\{8}\)\(.*\n\)\s\{8}/\1\2\1

worked, though in theory *should* be the same sort of thing. 
It's also much shorter and more readable than the "\=" version I 
sent second.



What's the -s do as compared to just s after the g/pattern/


The -s is a range/offset ("-", which is the same as "-1", meaning 
"back one line") and the command ("s"ubstitute).


For your bedtime reading, they break down as

:g  on every line
/^\s\{8}/   starting with 8 whitespace characters
-   go to the previous line
s/  and substitute
^ from the beginning of the line
\(.\{8}\) make note of 8 "whatever"s as "\1"

==[non-working]
.*and skip the rest of the line
\nand a newline
\zs   and start the replacement here
  treating everything before the \zs as
  merely required context
==[working]
\(.*\n\)  make note of the rest of the line as "\2"
===

\s\{8} the 8 whitespace characters we want to replace


The replacement in the first [non-working] *should* simply be the 
thing we tagged as \1.  In the second [working] version, the 
replacement is "the first tagged thing followed by the second 
tagged thing (namely, the whole previous line remains untouched) 
followed by the first thing tagged thing again"



> :g/^\s\+/k a|?^\S?y|'a|s/^\s\+/\=strpart(@", 0, strlen(submatch(0)))



That works  dunno what it does... but that works :-)

I'm going to record that little gem, and put it aside for a bedtime  
puzzle I think.


It helps to break it at the pipes :)

:g/^\s\+   on lines beginning with some whitespace
k amark that line as "a"
|  and
?^\S?  search backwards for a line beginning w/ non-ws
y  yanking that line into the scratch register
|  and
'a jump back to the "a" mark we placed earlier
|  and
s/ do a substitute
^\s\+  of the leading whitespace[*]
/  with
\= the results of this expression
strpart(   a piece of
@",the stuff we yanked previously
0, starting at the beginning
strlen(and running for the length of
submatch(0)the whitespace[*] we're replacing
))

It's a bit terse to say the least, and has slightly odd behaviors 
if you have staircased indentation like


first line
second line
 third line

where you'll end up with

first line
firssecond line
firsseconthird line

I'm glad they should save you oodles of time...that's one of the 
great things about Vim :)


-tim
(is this email a sign I need to get a life? :)

Re: regex help

[Brian McKee]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 16-May-07, at 2:27 PM, Tim Chase wrote:


:g/^\s\+/k a|?^\S?y|'a|s/^\s\+/\=strpart(@", 0, strlen(submatch(0)))



That works  dunno what it does... but that works :-)

I'm going to record that little gem, and put it aside for a bedtime  
puzzle I think.


Thank you

Brian

PS  I promise to use that little sucker at least 30 or 40 times in  
the next month or so - please believe me when I say I appreciate it.
Currently I'm importing into Excel and using a really really  
nasty couple of 'if then else' formulas to achieve the same result!

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (Darwin)
Comment: Verify this email or encrypt your email for free - see gnupg.org

iD8DBQFGS0+KGnOmb9xIQHQRAsSPAKCRsno91NmR5FgbuXBvrxcSMZ8qjwCg1l4o
K4ABU7aeY4ftTDusWPEmfSI=
=Lhjc
-END PGP SIGNATURE-

Re: regex help

[Brian McKee]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 16-May-07, at 2:23 PM, Gene Kwiecinski wrote:


:g/^\(.{8}\)\(.*\)\n\(\s{8}\)/s//\1\2\r\1/



Well,
:g/^\(.\{8}\)\(.*\)\n\(\s{8}\)/s//\1\2\r\1/
   ^
works, but I'd have to run it 12 times if there are twelve blanks
after the filled in line.


Hm?  Not sure why you escaped the '{'.  Apparently didn't need to  
after

the "\s".


You are right - it was a typo - I actually need to escape both of them -

:g/^\(.\{8}\)\(.*\)\n\(\s\{8}\)/s//\1\2\r\1/
   ^ ^

Brian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (Darwin)
Comment: Verify this email or encrypt your email for free - see gnupg.org

iD8DBQFGS030GnOmb9xIQHQRAkrxAKCQ2s0Z4CpdNbLlq5GB1Emfao9lrACgjWIs
U2W8X6FLElJSMaJyhYqxi4c=
=K8FT
-END PGP SIGNATURE-

Re: regex help

[Tim Chase]

	I'm trying to work out if it's possible to refer to 'the previous  
line' in a regex.

e.g.  if the first 8 characters of a line are blank,
^\s{8}
replace them with the 8 characters at the start of the previous line.

Ideally it would handle a line a time, thus multiple blank line  
starts would be filled in with the last non blank start.



Something like the following (untested) regexp should do the trick:

   :%s/^\(.\{8}\).*\n\zs\s\{8}/\1

or

   :%s/^\(.\{8}\)\(.*\n)\s\{8}/\1\2\1


Playing around with this a little more ("how did you spend your 
morning, dear?"  "Oh, just playing around with some regular 
expressions for a guy on a email list, one could expand it from 8 
spaces to N spaces with something like


 :g/^\s\+/k a|?^\S?y|'a|s/^\s\+/\=strpart(@", 0, 
strlen(submatch(0)))


It tromps on your scratch register, and your "a" mark (the "k a" 
and "'a" bits) but it is a little more flexible.


If you need multiples of a given number of spaces, you could 
alter it to


 :g/^\(\s\{4}\)\+/...

which would be multiples of 4 whitespace characters.

-tim

Re: regex help

[Brian McKee]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 16-May-07, at 1:05 PM, Tim Chase wrote:


:g/^\s\{8}/-s/^\(.\{8}\).*\n\zs\s\{8}/\1


I don't understand that regex completely - but it deletes lines of  
data :-)


Looks like it globably matches the 'blank start' lines, then searches  
in that for the pattern - thus deleting the third line...


What's the -s do as compared to just s after the g/pattern/

Brian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (Darwin)
Comment: Verify this email or encrypt your email for free - see gnupg.org

iD8DBQFGS003GnOmb9xIQHQRAv5VAKC6QXC8mLr7Fj0E5NDb47Wi1J5OjwCeLZkg
43BTgSoka6rAbFjotqeMT+g=
=gVmG
-END PGP SIGNATURE-

comments after brackets with vim?

[Simon Butler]

So, anyone done something like this before, i'm about to break out the
vim scripting manual.. :(

--

hi, when i write this skill (cadence extension language) fragment in
emacs i get the following:


procedure( vscCheckpointHier( @key lib cell view message inclibs )
let(( ddCVs )
vscPrint0(sprintf( nil "Hierarchy for %s,%s,%s ..." lib cell
view ))
when( ddCVs = vscGetHierarchyDDs( ?lib lib ?cell cell ?view
view
  ?inclibs inclibs )
vscPrint0(sprintf( nil "  %d cellviews." length(ddCVs) ))
vscCheckpoint( ddCVs ?message message)
); when ddCVs
); let
); procedure vscCheckpointHier


Notice all the comments placed on the closing brackets. Is there a
way to make vim do this?

TIA

RE: regex help

[Gene Kwiecinski]

>>:g/^\(.{8}\)\(.*\)\n\(\s{8}\)/s//\1\2\r\1/

>Well,
>:g/^\(.\{8}\)\(.*\)\n\(\s{8}\)/s//\1\2\r\1/
>^
>works, but I'd have to run it 12 times if there are twelve blanks  
>after the filled in line.

Hm?  Not sure why you escaped the '{'.  Apparently didn't need to after
the "\s".


>I suppose global picks all the lines, then operates on them.

Ideally, yeh.  Wondered if the op for lines 3-4 would fill in the chars,
then the op would also work on lines 4-5, or if it'd still think the 1st
chars be blank and skip to lines 5-6 as matching the pattern.


>That's a start - thanks!

No worries.

Re: regex help

[Brian McKee]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 16-May-07, at 12:49 PM, Gene Kwiecinski wrote:


:g/^\(.{8}\)\(.*\)\n\(\s{8}\)/s//\1\2\r\1/



Well,
:g/^\(.\{8}\)\(.*\)\n\(\s{8}\)/s//\1\2\r\1/
   ^

works, but I'd have to run it 12 times if there are twelve blanks  
after the filled in line.


I suppose global picks all the lines, then operates on them.

That's a start - thanks!

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (Darwin)
Comment: Verify this email or encrypt your email for free - see gnupg.org

iD8DBQFGS0gYGnOmb9xIQHQRAg04AKCiPBKmNTc1MhA7r9IeJG0dC4lPwwCgsH0l
k4/ExrBsVzsfV1K3ktfEo08=
=sbTc
-END PGP SIGNATURE-

Re: Syntax highlightning

[Ian Tegebo]

On 5/16/07, Meier Zwei <[EMAIL PROTECTED]> wrote:

Hi list,

I'm currently customizing my one syntax file for C and C++. Therby I
don't understand one little detail: How can I outline C functions? I
didn't find a syntax file that does similar.

What do you mean by outline?

There is a vimscript that creates a sidebar containing folds.  It then
tries to indent them based on fold level:

http://www.vim.org/scripts/script.php?script_id=500

Many filetype plugins for code create folds for each function so this
should provide a way to create "function outlines".

--
Ian Tegebo

Automatically select encoding based on certain characters present in the file

[Szabolcs Horvát]

I have fileencodings=ucs-bom,utf-8,latin1. But I would like to use
latin2 instead of latin1 for files that contain the characters 0xf5 or
0xfb (ő and ű in latin2).

I tried to modify the example that is given on the help page for
'fileencodings', like this:

au BufReadPost * if &fenc == "latin1" && search('\%xfb\|\%xf5', 'w') >
0 | exe ":e ++enc=latin2" | endif

This seems to work, but the syntax highlighting gets turned off for
latin2 encoded files. Could someone explain why this happens? How can
I avoid this?

It would be even better if someone could give a solution which also
works for reading files with :r, not just :e.

Thanks for your replies in advance,
Szabolcs

Re: Vim71: breaking change not mentioned in the document.

[Gary Johnson]

On 2007-05-16, [EMAIL PROTECTED] wrote:
> Gary Johnson <[EMAIL PROTECTED]>  2007-05-16 16:41:22:
> > On 2007-05-16, [EMAIL PROTECTED] wrote:
> > > Hi, vimmers:
> > >
> > > The line 1230 of editing.txt said:
> > >
> > > To change to the directory of the current file:
> > > :cd %:h
> > >
> > > This works for Vim 7.0 and before, but not for Vim 7.1. In Vim 7.1 when
> the
> > > pwd is the same as the directory of current file, the command will fail
> > > with E500. The failure will break the execution of a mapping, if one
> have a
> > > mapping to do :cd %:h and then continue to do something else.
> > >
> > > To reproduce the error, just at anytime, run :cd %:h twice. (I've got
> > > Windows gvim7.1.1, cygwin console vim 7.1.1)
> >
> > I would expect ":cd %:h" to give an error the second time it is
> > executed.  Just to be sure, I repeated your experiment on 7.1, 7.0
> > and 6.4 on Unix and 7.0 on Windows.  I always got E500.  Are you
> > sure that it "works" for you for Vim 7.0?
> 
> Positive, I've got a mapping which do :cd %:h then :grep, this mapping
> works since Vim 6.3, 6.4 and 7.0, this is the mapping I used "Everyday" and
> I cannot use Vim without it, then suddenly it breaks after I installed Vim
> 7.1.  Now I changed :cd %:h to :cd %:p:h and everything works.

That's very strange.  Your observations certainly don't match mine.  
I wonder what's going on.

> Anyway, I think there should be an option to disable E500, or "catch and
> throw". This is the Unix trend: if the caller feel necessary, a program
> should fail silently in order not to break a script.

I don't think disabling E500 would help.  The text of E500 is, 
"E500: Evaluates to an empty string".  That's warning you that there 
is no head component of the file name.  If you disabled the error, 
and presumably allowed %:h to return an empty string, then your ":cd 
%:h" command would be executing just ":cd", which on a Unix system 
changes to the home directory--not what you want.

Another way to fix your mapping would be to use

   :silent! cd %:h

which allows the cd to fail silently.

Regards,
Gary

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

regex help

[Brian McKee]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi All
	I'm trying to work out if it's possible to refer to 'the previous  
line' in a regex.

e.g.  if the first 8 characters of a line are blank,
   ^\s{8}
replace them with the 8 characters at the start of the previous line.

Ideally it would handle a line a time, thus multiple blank line  
starts would be filled in with the last non blank start.


Hoping that made sense...
Brian 
-BEGIN PGP SIGNATURE-

Version: GnuPG v1.4.6 (Darwin)
Comment: Verify this email or encrypt your email for free - see gnupg.org

iD8DBQFGSy1kGnOmb9xIQHQRAuXcAKCvQL9kHdr/xKhkgp5jve6NPNJqgQCgmQRw
LcscyQAMfFMdMQadBAg8vmQ=
=1lwZ
-END PGP SIGNATURE-

Re: Vim Wiki - Wiki Template Proposal

[Martin Krischik]

Am Mittwoch 16 Mai 2007 schrieb John Beckett:

> A wiki discussion page (as you know!) is intended for people to
> discuss the future of the page.

And most valuable comments are about improving the tip.

>  However, we hope that will be temporary. Perhaps I
> should say that *I* hope it will be temporary because I see that
> the proposed sample has a section for Comments.

As long at the comments are not to archived for ever on the main page I guess 
it is Ok.

> (easier than editing the main page and
> the discussion page, because once a comment is dealt with, it
> would have to be removed from the discussion page).

Well, on most Wikibooks comments are seldom cleaned up. They are just left to 
rot. And since there are not on the main page it does not matter.

Martin
-- 
Martin Krischik
mailto://[EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part.

RE: Identify this Vim font for me, please

[Gene Kwiecinski]

>This isn't very related to Vim, but I found this font on Vim's
>wikipedia webpage:
>http://upload.wikimedia.org/wikipedia/commons/8/8c/Vim-%28logiciel%29-c
onsole.png
>Can anyone identify this font for me? It looks very good for
programming.

Eww.  That dates back to the crappy default IBM font cooked into the
BIOS for CGA monitors (typically at FFA6E in memory... *scary* I still
remember that).

I used to rip out that crappy font and put my own in, and recook my
video boards' EPROMs with my new fonts, just so I'd never ever *ever*
*EVER* have to see that ugly disgusting font even when the machine's
first booting up.

Yecch. 

That being said, it's probably listed as something with "system" in the
font name.  I imagine you're not using a normal peecee, else that should
be listed as one of the options for monospaced fonts.  Sparc box?
Anyhoo, it's listed as "fixedsys" here, 'though that might vary.

A bunch of other people posted their favorite monospaced fonts a while
ago, and some were really crisp and easy-to-look-at.  I'd seriously
suggest one of those over fixedsys.  I go blind trying to figure out '0'
from '8', etc., when I gotta work in a fake-DOS window and that's all it
has available.

Re: Tip #80: Restore cursor to file position in previous editing session does not work on Ubuntu

[Tushar Desai]

Yes this is the same issue. Thanks for the pointer...

On 5/16/07, François Ingelrest <[EMAIL PROTECTED]> wrote:

Hi,

You should try to have a look at this bug and see if it's the same problem:

https://bugs.launchpad.net/ubuntu/+bug/58002

On 5/16/07, Tushar Desai <[EMAIL PROTECTED]> wrote:
> This tip (which restores cursor to the last position in previous
> editing session) is the lifeline of any developer and it works great
> for me at work (on Fedora Core 6).
> I've Ubuntu 7.04 @home and I just compiled and installed vim7.1 and
> this doesn't work for me. It didn't work with vim7.0 either.
>
> Actually, even on Ubuntu it works if I don't quit from vim. On FC6,
> irrespective of the quit. I suppose on ubuntu this is some how not
> being "remembered". So, how do I get my cursor back across session
> quits?
>
> Regards,
> -tushar.
>
> PS: Pardon me for some lame questions, while I try to improve my vim skills.
>

Re: Identify this Vim font for me, please

[Dudley Fox]

On 5/16/07, madiyaan <[EMAIL PROTECTED]> wrote:


Hello,

This isn't very related to Vim, but I found this font on Vim's wikipedia
webpage:

http://upload.wikimedia.org/wikipedia/commons/8/8c/Vim-%28logiciel%29-console.png

Can anyone identify this font for me? It looks very good for programming.


As far as I can tell it is the windows Fixedsys font.
http://en.wikipedia.org/wiki/Fixedsys

Enjoy,
Dudley



Thank you very much,
--

RE: Vim Wiki - Tip Page Formatting Deadline

[Gene Kwiecinski]

>Thinking about how a wiki works shows that keeping tip numbers
>is doomed. First, there is no auto-increment id, and as you
>point out, there is no reasonable way to automate fixes.

Is there any equivalent to javascript's document.lastModified?

Can create a "serial number" based on the date of submission, then
rearrange by fields to a sortable ID, eg 2007.05.15.23.53 for a tip
created yesterday at 23:53.

Don't need dots, or hyphens, or anything, as 2007051523353 would be
fine, too.  The odds of having 2 tips be submitted in the same minute
would be remote.

Re: calling normal commands from ex/a function

[fREW]

On 5/16/07, Charles E Campbell Jr <[EMAIL PROTECTED]> wrote:

fREW wrote:

> Hey everyone,
>
> How do I have a function call Normal commands?  Example: I'd like to
> make a function that will open a certain file, and then set the
> foldlevel to 1, and then go to the right window.  So I have:
>
> function TodoListMode()
>  execute ":e ~/.todo.otl"
>  execute ":Calendar"
> endfunction
>
> and then after the second command I want to do:
> wl
> zM
> zr

* may I point out that you're using "execute" when you don't need to.
* you're already in ex mode; no need to use colons to do ex mode commands
* ctrl-w_l can be performed with wincmd l .
* to perform normal mode commands in a function, use norm! (the
exclamation prevents any maps from interfering)

So, with these points in mind:

fun! TodoListMode()
  e ~/.todo.otl
  wincmd l
  norm! zMzr
  Calendar
endfun

Now, I confess that I didn't test this...

Regards,
Chip Campbell




Thanks for the pointers!

I ended up with this, which doesn't use any normal commands at all ironically.


function! TodoListMode()
 e ~/.todo.otl
 Calendar
 wincmd l
 set foldlevel=1
endfunction

Thanks for the help though, it works just as one would hope now!

-fREW

Re: Vim Wiki - Wiki Template Proposal

[fREW]

On 5/16/07, John Beckett <[EMAIL PROTECTED]> wrote:

Martin Krischik wrote:
> We should not include comments on the content page!
> That's what the discussion page is for.

You are very keen on that point, so I'm going into a bit of
detail about why I don't agree.

A wiki discussion page (as you know!) is intended for people to
discuss the future of the page. Does an error need fixing? Are
there points which need to be expanded? Is the content or style
inconsistent with overall guidelines?

Or, on the discussion page, I might ask why you reverted my
edits, and we could debate whether my wording was better than
yours.

We'll still need the above in a Vim wiki.

However, the Comments in Vim Tips are a different animal. Most
comments are fluff, and need to be deleted ASAP.

Many comments are very helpful, and their content needs to be
merged into the body of the tip. On some tips, a reader would
need a lot of persistence to work out what to do, because the
tip says X, some comment says Y, and another comment says Z.

I think I recall seeing cases where a comment points out that
the tip is hopeless because there's a better way of handling the
situation. We wouldn't want that comment hidden on the
discussion page (where a casual reader won't see it).

As I understand it, the whole point of moving Vim Tips to a wiki
is so that we can fix each tip so that there is one consistent
story on each page.

You are correct that having the comments on the main page will
be ugly. However, we hope that will be temporary. Perhaps I
should say that *I* hope it will be temporary because I see that
the proposed sample has a section for Comments.

I imagine editing the wiki will go like this:
- Import all tips with comments on main page.
- Edit important tips and clean them up completely.
- Edit nearly all tips to remove junk comments.
- Leave difficult cases for later.

I imagine there will be lots of difficult cases where
considerable effort would be needed to merge the comments.
In those cases, we would just leave the useful comments, perhaps
editing them where helpful.

Later (say in six months) we would discuss what to do with those
tips that still have unmerged comments. In some cases, it might
be very reasonable to leave comments on the main page. For
example, a tip might describe a scenario and its solution.
Then a comment might say that if you are running on a certain
platform, then a better approach would be something else.
It may never be worth fixing all tips to eliminate such
comments, yet you wouldn't want to hide that useful info on
the discussion page.

I think that following the above strategy would be much easier
for people editing a tip (easier than editing the main page and
the discussion page, because once a comment is dealt with, it
would have to be removed from the discussion page).

Also, seeing the old comments on the main page would be an
immediate reminder that the tip needs cleaning up.

Imagine the mess if comments were on the discussion page, then
someone edited the main page to include a few useful comments
from the discussion page, but failed to remove those comments.
It would then take herculean efforts to properly fix the tip,
and the discussion pages would have so much junk in them that
their function as a tip discussion would fail.

John




Also, just to follow up with what John said, Wikipedia is /not/ like
most wiki's in this respect.  I read a certain wiki off and on and I
have stumbled upon a few that are similar where people just ask
questions right on the page.  It's pretty nice once you get used to
it, so I'd say leave the discussion for meta-thought and not actual
thoughts about content.

-fREW

Re: calling normal commands from ex/a function

[Charles E Campbell Jr]

fREW wrote:


Hey everyone,

How do I have a function call Normal commands?  Example: I'd like to
make a function that will open a certain file, and then set the
foldlevel to 1, and then go to the right window.  So I have:

function TodoListMode()
 execute ":e ~/.todo.otl"
 execute ":Calendar"
endfunction

and then after the second command I want to do:
wl
zM
zr


* may I point out that you're using "execute" when you don't need to.
* you're already in ex mode; no need to use colons to do ex mode commands
* ctrl-w_l can be performed with wincmd l .
* to perform normal mode commands in a function, use norm! (the 
exclamation prevents any maps from interfering)


So, with these points in mind:

fun! TodoListMode()
 e ~/.todo.otl
 wincmd l
 norm! zMzr
 Calendar
endfun

Now, I confess that I didn't test this...

Regards,
Chip Campbell

Re: Tip #80: Restore cursor to file position in previous editing session does not work on Ubuntu

[fREW]

On 5/15/07, Tushar Desai <[EMAIL PROTECTED]> wrote:

This tip (which restores cursor to the last position in previous
editing session) is the lifeline of any developer and it works great
for me at work (on Fedora Core 6).
I've Ubuntu 7.04 @home and I just compiled and installed vim7.1 and
this doesn't work for me. It didn't work with vim7.0 either.

Actually, even on Ubuntu it works if I don't quit from vim. On FC6,
irrespective of the quit. I suppose on ubuntu this is some how not
being "remembered". So, how do I get my cursor back across session
quits?

Regards,
-tushar.

PS: Pardon me for some lame questions, while I try to improve my vim skills.



Actually this problem came up something like 3-4 days ago.  First off,
you need to make sure that you have permissions to read and modify
~/.viminfo .  It appears that sudo'ing can mess that up.  After that
you can just put this (from tip 80?) into your .vimrc

augroup JumpCursorOnEdit
   au!
 autocmd BufReadPost *
 \ if expand(":p:h") !=? $TEMP |
 \   if line("'\"") > 1 && line("'\"") <= line("$") |
 \ let JumpCursorOnEdit_foo = line("'\"") |
 \ let b:doopenfold = 1 |
 \ if (foldlevel(JumpCursorOnEdit_foo) >
foldlevel(JumpCursorOnEdit_foo - 1)) |
 \let JumpCursorOnEdit_foo = JumpCursorOnEdit_foo - 1 |
 \let b:doopenfold = 2 |
 \ endif |
 \ exe JumpCursorOnEdit_foo |
 \   endif |
 \ endif
   " Need to postpone using "zv" until after reading the modelines.
   autocmd BufWinEnter *
   \ if exists("b:doopenfold") |
   \   exe "normal zv" |
   \   if(b:doopenfold > 1) |
   \   exe  "+".1 |
   \   endif |
   \   unlet b:doopenfold |
   \ endif
augroup END

I had the same issue from Ubuntu upgrades and that fixed it.

Hope that helps!

-fREW

Syntax highlightning

[Meier Zwei]

Hi list,

I'm currently customizing my one syntax file for C and C++. Therby I 
don't understand one little detail: How can I outline C functions? I 
didn't find a syntax file that does similar.



Greetings from Cologne

Meier

Re: calling normal commands from ex/a function

[Robert Cussons]

fREW wrote:

Hey everyone,

How do I have a function call Normal commands?  Example: I'd like to
make a function that will open a certain file, and then set the
foldlevel to 1, and then go to the right window.  So I have:

function TodoListMode()
 execute ":e ~/.todo.otl"
 execute ":Calendar"
endfunction

and then after the second command I want to do:
wl
zM
zr

Thanks!

-fREW



Hi fREW,

execute "normal! wl zM zr"

would be my guess, but I've never tried writing my own functions, this 
is adapted from someone else's work, so someone else's input would be 
useful :-)


Rob.

Re: Vim Wiki - Tip Page Formatting Deadline

[Brian McKee]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 15-May-07, at 3:02 PM, Gary Johnson wrote:



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.


I have to say that I prefer the Metadata at the top, but I agree the  
giant table is a bit much.

How about a blend of the two?

I quickly created http://scratchpad.wikia.com/wiki/Template:Tip4
but I didn't figure out how to get tip 1 to use that template.
Editing tip 1 starts editing the template. - Where do I assign it

Brian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (Darwin)
Comment: Verify this email or encrypt your email for free - see gnupg.org

iD8DBQFGShSLGnOmb9xIQHQRAtwPAJ0YpRmcsTStjZ2AUyBGb8mFYecalwCgx3Cz
CM35zURSnPRsWu7zYO0/QWk=
=/vcf
-END PGP SIGNATURE-

Re: Vim Wiki - Wiki Template Proposal

[John Beckett]

Martin Krischik wrote:

We should not include comments on the content page!
That's what the discussion page is for.


You are very keen on that point, so I'm going into a bit of
detail about why I don't agree.

A wiki discussion page (as you know!) is intended for people to
discuss the future of the page. Does an error need fixing? Are
there points which need to be expanded? Is the content or style
inconsistent with overall guidelines?

Or, on the discussion page, I might ask why you reverted my
edits, and we could debate whether my wording was better than
yours.

We'll still need the above in a Vim wiki.

However, the Comments in Vim Tips are a different animal. Most
comments are fluff, and need to be deleted ASAP.

Many comments are very helpful, and their content needs to be
merged into the body of the tip. On some tips, a reader would
need a lot of persistence to work out what to do, because the
tip says X, some comment says Y, and another comment says Z.

I think I recall seeing cases where a comment points out that
the tip is hopeless because there's a better way of handling the
situation. We wouldn't want that comment hidden on the
discussion page (where a casual reader won't see it).

As I understand it, the whole point of moving Vim Tips to a wiki
is so that we can fix each tip so that there is one consistent
story on each page.

You are correct that having the comments on the main page will
be ugly. However, we hope that will be temporary. Perhaps I
should say that *I* hope it will be temporary because I see that
the proposed sample has a section for Comments.

I imagine editing the wiki will go like this:
- Import all tips with comments on main page.
- Edit important tips and clean them up completely.
- Edit nearly all tips to remove junk comments.
- Leave difficult cases for later.

I imagine there will be lots of difficult cases where
considerable effort would be needed to merge the comments.
In those cases, we would just leave the useful comments, perhaps
editing them where helpful.

Later (say in six months) we would discuss what to do with those
tips that still have unmerged comments. In some cases, it might
be very reasonable to leave comments on the main page. For
example, a tip might describe a scenario and its solution.
Then a comment might say that if you are running on a certain
platform, then a better approach would be something else.
It may never be worth fixing all tips to eliminate such
comments, yet you wouldn't want to hide that useful info on
the discussion page.

I think that following the above strategy would be much easier
for people editing a tip (easier than editing the main page and
the discussion page, because once a comment is dealt with, it
would have to be removed from the discussion page).

Also, seeing the old comments on the main page would be an
immediate reminder that the tip needs cleaning up.

Imagine the mess if comments were on the discussion page, then
someone edited the main page to include a few useful comments
from the discussion page, but failed to remove those comments.
It would then take herculean efforts to properly fix the tip,
and the discussion pages would have so much junk in them that
their function as a tip discussion would fail.

John

Re: Vim Wiki - Tip Page Formatting Deadline

[John Beckett]

Sebastian Menge wrote:

Therefore, I would vote for using tip-title == page-title and
let the categorization be done by [[Category:VimTip]]. Using
Wikipedia standards (CamelCaseIsUgly) we would get pages like
"The Super Star" and we could reuse the title in the template.
We would lose the tip-id for new tips.


Thinking about how a wiki works shows that keeping tip numbers
is doomed. First, there is no auto-increment id, and as you
point out, there is no reasonable way to automate fixes.

But more than that. I hope that the wiki tips really will be
edited and improved. Currently, there are lots of tips that are
of very marginal value, and there are several related tips.

I hope that unhelpful tips will be brutally deleted, and related
tips will be merged (if that doesn't make the new tip too big).
In other words, we should end up with many missing tip numbers.

If all tips are retained for nostalgic reasons, the usefulness
of the whole site will be reduced due to the growing amount of
cruft that would obscure the helpful tips.

Re the tip URL, what would you recommend for this:
List of text editors
http://en.wikipedia.org/wiki/List_of_text_editors

Will it be possible to edit the URL of a link, in order to
simplify it? For example, I don't like:
Optimization (mathematics)
http://en.wikipedia.org/wiki/Optimization_%28mathematics%29

I've seen much worse URLs, but can't find one now.

John

Re: vim 7.1 and cr/lf interpretation

[John Beckett]

Thomas Michael Engelke wrote:

In the programming language I currently write, using the
seperator string somewhere in the string I'm parsing gives a
new entry. So a string containing only a line seperator
char/pattern would have 2 entries, which in this case would
mean 2 lines. As I see now, this is handled differently in
vim.


Sorry to beat this really dead horse, but it's not Vim which
handles this differently! End-of-line has always been a
terminator, not a separator (as Tony explained earlier).

I've had a closer look at the file you attached:
- All lines end with CR LF, except for three lines.
- Two lines end with CR only.
- One line (the last) ends with LF only.

John

calling normal commands from ex/a function

[fREW]

Hey everyone,

How do I have a function call Normal commands?  Example: I'd like to
make a function that will open a certain file, and then set the
foldlevel to 1, and then go to the right window.  So I have:

function TodoListMode()
 execute ":e ~/.todo.otl"
 execute ":Calendar"
endfunction

and then after the second command I want to do:
wl
zM
zr

Thanks!

-fREW

Re: Vim Wiki - Wiki Template Proposal

[fREW]

On 5/15/07, fREW <[EMAIL PROTECTED]> wrote:

On 5/15/07, Sebastian Menge <[EMAIL PROTECTED]> wrote:
> 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.

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.

Sound good?

-fREW



Also, we need to make sure that the script correctly escapes any wiki
formatting.  For example, http://scratchpad.wikia.com/wiki/VimTip7.
As you can see the and is set to be a page in the first comment.  To
fix that you just put  around the brackets.  Also, I
think that for the most part 's can be replaced with newlines.
Any html at all should have a wiki version.   See below for help on
that.  For the most part I don't think the markup is a huge deal, but
think that we should try to get the script to output the closest thing
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.

[1] http://en.wikipedia.org/wiki/Wikipedia:Cheatsheet
[2] http://www.wikia.com/wiki/Help:Tutorial_3
[3] http://www.wikia.com/wiki/Help:Tutorial_4
[4] http://www.wikia.com/wiki/Help:Tutorial_5

-fREW

Re: Vim and email quoting

[Benjamin Esham]

fREW wrote:


On 5/12/07, Troy Piggins <[EMAIL PROTECTED]> wrote:


* Timothy Knox is quoted & my replies are inline below :


I use vim to write my outgoing email, and for the most part, it
rocks. Thanks to all the folks who have written modules and
provided tips that make it the best thing for writing email
since mailx .


What tips/scripts are you using and what are your favourites?


Yeah, I am interested as well.  What do you use to do all of this?


I use the non-Vim-friendly Apple Mail for my e-mail, but I use pan  
and Vim for Usenet; here is the function that's called whenever I set  
filetype=usenet:


" :: set us up for usenet-article editing
function! UsenetSetup()
setl textwidth=75" wrap at 75 columns
setl comments=n:>,n:\|,n:%   " recognize [>|%] as quote  
indicators
setl formatoptions=qn" allow formatting with 'gq';  
recognize lists (q.v.)
" the unholy mess on the next line recognizes lists with "1.",  
"-", and "*" as bullets,
setl flp=^\\(\\d\\+[.\\t\ ]\\\|[-*•]\ \\\|\ \ \\)\\s*" and  
also recognizes two-space blockquoting
setl expandtab   " use spaces instead of tabs  
(eugh)


nmap s :call InsertSpoilerSpace()
nmap f :call FormatUsenetParagraph()
" insert a randomly-chosen signature and turn on spell checking
nmap g :r !~/.vim/usenet/sig.pl ~/.vim/usenet/ 
sigs:setl spell


setl encoding=utf-8
setl fileencoding=utf-8
endfunction

function! FormatUsenetParagraph()
sil '{,'}s/\%(^[|>% \t]*\)\@<=\([|>%]\)\s*/\1 /ge
normal gqip
endfunction

The second function does a beautiful job of reflowing paragraphs to  
take up the entire textwidth; it was devised by Peppe on  
comp.editors.  (If anyone has questions about how any of this works,  
please ask!)


HTH,
--
Benjamin D. Esham
[EMAIL PROTECTED]  |  AIM: bdesham128  |  Jabber: same as e-mail
Esperanto, the international language  ☆  http://www.lernu.net

Re: Vim Wiki - Wiki Template Proposal

[fREW]

On 5/15/07, Tom Purl <[EMAIL PROTECTED]> wrote:

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



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

-fREW

Re: Vim Wiki - Tip Page Formatting Deadline

[fREW]

On 5/15/07, Gary Johnson <[EMAIL PROTECTED]> wrote:

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



I don't know how to add pages to that dynamic page there if they have
already been created, but I made [1] with template [2] so that it
would work better if you just wanted to see the titles of pages.  The
only problem is that this would require more work if we wanted to
scrape the wiki at some point.  Anyway, if we WERE to do this, this is
how I envision it working:
1: User creates a new page using Template:Tip3 (or 2 or whatever)
2: They leave the id blank because it will be ignored
3: At some specified interval, a cron job runs that will scrape the
source of any newly created pages and sort them in a chronological
list
4: The program in the cron job moves each new tip to: #{generated id} - #{title}

And then we could probably have another program that would run say,
once a week that would iterate through the entire tip list ensuring
that people didn't do something silly, like change the numbers.  I
presume that we would have to use the history and then look at the
initial creation of the page to ensure correct times and whatnot.

I can still see why we would want to use the format:
Tip1
Tip2
...
Tip10
...
but it makes sense to have the names show the titles (or more
obviously, the titles should BE the names).

What do you guys think?
[1] http://scratchpad.wikia.com/wiki/1_-_the_super_star
[2] http://scratchpad.wikia.com/wiki/Template:Tip3

Re: vim 7.1 and cr/lf interpretation

[Thomas Michael Engelke]

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.

And yes, you are right about the other thing, too. I did understand
what he wrote but discarded it as not possible. I think I fell into
that pattern when I read the first reply to my problem which was
bollocks, obviously by someone who did not read what I wrote as he
suggested something I already did and described.

I promise to read the replies I will be given better from now on and
not discard them so easily.

Thomas

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

Re: Vim Wiki - Wiki Template Proposal

[fREW]

On 5/15/07, Sebastian Menge <[EMAIL PROTECTED]> wrote:

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.


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.

Sound good?

-fREW

Re: Tip #80: Restore cursor to file position in previous editing session does not work on Ubuntu

[François Ingelrest]

Hi,

You should try to have a look at this bug and see if it's the same problem:

https://bugs.launchpad.net/ubuntu/+bug/58002

On 5/16/07, Tushar Desai <[EMAIL PROTECTED]> wrote:

This tip (which restores cursor to the last position in previous
editing session) is the lifeline of any developer and it works great
for me at work (on Fedora Core 6).
I've Ubuntu 7.04 @home and I just compiled and installed vim7.1 and
this doesn't work for me. It didn't work with vim7.0 either.

Actually, even on Ubuntu it works if I don't quit from vim. On FC6,
irrespective of the quit. I suppose on ubuntu this is some how not
being "remembered". So, how do I get my cursor back across session
quits?

Regards,
-tushar.

PS: Pardon me for some lame questions, while I try to improve my vim skills.

Re: Vim71: breaking change not mentioned in the document.

[panshizhu]

Gary Johnson <[EMAIL PROTECTED]> 写于 2007-05-16 16:41:22:
> On 2007-05-16, [EMAIL PROTECTED] wrote:
> > Hi, vimmers:
> >
> > The line 1230 of editing.txt said:
> >
> > To change to the directory of the current file:
> > :cd %:h
> >
> > This works for Vim 7.0 and before, but not for Vim 7.1. In Vim 7.1 when
the
> > pwd is the same as the directory of current file, the command will fail
> > with E500. The failure will break the execution of a mapping, if one
have a
> > mapping to do :cd %:h and then continue to do something else.
> >
> > To reproduce the error, just at anytime, run :cd %:h twice. (I've got
> > Windows gvim7.1.1, cygwin console vim 7.1.1)
>
> I would expect ":cd %:h" to give an error the second time it is
> executed.  Just to be sure, I repeated your experiment on 7.1, 7.0
> and 6.4 on Unix and 7.0 on Windows.  I always got E500.  Are you
> sure that it "works" for you for Vim 7.0?

Positive, I've got a mapping which do :cd %:h then :grep, this mapping
works since Vim 6.3, 6.4 and 7.0, this is the mapping I used "Everyday" and
I cannot use Vim without it, then suddenly it breaks after I installed Vim
7.1.  Now I changed :cd %:h to :cd %:p:h and everything works.

Anyway, I think there should be an option to disable E500, or "catch and
throw". This is the Unix trend: if the caller feel necessary, a program
should fail silently in order not to break a script.

Re: Vim Wiki - Wiki Template Proposal

[Martin Krischik]

Am Dienstag 15 Mai 2007 schrieb 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.

We should not include comments on the content page! That's what the discussion 
page if for.

Martin
-- 
Martin Krischik
mailto://[EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part.

Re: wiki hosting

[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
-- 
Martin Krischik
mailto://[EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part.

Re: Vim Wiki - Wiki Template Proposal

[Martin Krischik]

Am Dienstag 15 Mai 2007 schrieb Zdenek Sekera:

> Problem with asking for more opinions is that you may end up with
> too many.

Current WikiMedia allows for default values and if|then|else structures. So 
Templates can have beginner and expert options.

Martin

-- 
Martin Krischik
mailto://[EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part.

Re: Vim Wiki - Tip Page Formatting Deadline

[Martin Krischik]

Am Dienstag 15 Mai 2007 schrieb Tom Purl:

> Task:  Wiki Format Sign-Off
> Deadline:  Monday, May 21st (arbitrary, I know)

I like Template 2 more.

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

Comment should go to the discussion page. There ugly signatures won't matter 
there. Also comments are often threaded - which is even uglier - but again - 
won't matter that much on the discussion page.

The Main page should only contain the clean and simple tip.

Martin
-- 
Martin Krischik
mailto://[EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part.

Tip #80: Restore cursor to file position in previous editing session does not work on Ubuntu

[Tushar Desai]

This tip (which restores cursor to the last position in previous
editing session) is the lifeline of any developer and it works great
for me at work (on Fedora Core 6).
I've Ubuntu 7.04 @home and I just compiled and installed vim7.1 and
this doesn't work for me. It didn't work with vim7.0 either.

Actually, even on Ubuntu it works if I don't quit from vim. On FC6,
irrespective of the quit. I suppose on ubuntu this is some how not
being "remembered". So, how do I get my cursor back across session
quits?

Regards,
-tushar.

PS: Pardon me for some lame questions, while I try to improve my vim skills.

Re: Vim71: breaking change not mentioned in the document.

[Gary Johnson]

On 2007-05-16, [EMAIL PROTECTED] wrote:
> Hi, vimmers:
> 
> The line 1230 of editing.txt said:
> 
> To change to the directory of the current file:
> :cd %:h
> 
> This works for Vim 7.0 and before, but not for Vim 7.1. In Vim 7.1 when the
> pwd is the same as the directory of current file, the command will fail
> with E500. The failure will break the execution of a mapping, if one have a
> mapping to do :cd %:h and then continue to do something else.
> 
> To reproduce the error, just at anytime, run :cd %:h twice. (I've got
> Windows gvim7.1.1, cygwin console vim 7.1.1)

I would expect ":cd %:h" to give an error the second time it is 
executed.  Just to be sure, I repeated your experiment on 7.1, 7.0 
and 6.4 on Unix and 7.0 on Windows.  I always got E500.  Are you 
sure that it "works" for you for Vim 7.0?

> So there's at least two issues IMHO:
> 1. the line 1230 of editing.txt should be changed to :cd %:p:h

I disagree.  If you want to _change_ directory to that of the 
current file, the command ":cd %:h" is correct.  If the working 
directory is already that of the current file, such that executing 
":cd %:h" would give E500, then there is no reason to change 
directory.

> 2. somewhere in the document should mention: if we had used :cd %:h in our
> mappings or scripts, we should change them into %:p:h after upgraded to vim
> 7.1.

I don't see that this behavior has changed.

Regards,
Gary

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

Re: vim 7.1 and cr/lf interpretation

[Thomas Michael Engelke]

2007/5/15, Micah Cowan <[EMAIL PROTECTED]>:

Please note that he had already given you this exact same answer already
in his last message, including and especially the bit that \n is an
end-of-line (line terminator), not a open-new-line (line separator).
This is generally true for all operating systems, not just Unix
(substituting \r or \r\n as necessary). This is the part that he
shouted, since apparently he thought you'd notice it more this time
around if he did.

While I don't approve of shouting, I do understand his frustration:
asking questions to learn about mysteries is definitely a good thing,
and to be encouraged; but please do take the time to thoroughly read the
answers that people spend time writing.


I think my problem stems from the fact that I usually do not hold this true:


0x10 alone gives an *end* of line, not necessarily a *begin* of line.


In the programming language I currently write, using the seperator
string somewhere in the string I'm parsing gives a new entry. So a
string containing only a line seperator char/pattern would have 2
entries, which in this case would mean 2 lines. As I see now, this is
handled differently in vim.

IIRC, even a java string tokenizer would work the same way, and by the
original name, line feed in fact /does/ mean a new line on a
serialized terminal.

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.

Thomas

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

Re: Vim Wiki - Tip Page Formatting Deadline

[A. S. Budden]

On 15/05/07, 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.

[snip]

What do you guys think?


My vote definitely goes for version two (which seems to correspond
with most people on the list).  The nice thing about using a template
though, is that if at some point later down the line a change is
considered desirable, the template can be changed and hopefully this
will update all the tips (depending on how drastic the change is of
course!)

I guess this is either me being daft or something strange about the
setup, but at the moment, if you click the "edit" button on the
right-hand side in line with either "Comments" or "Tip: #1 - the super
star", it edits the template rather than the tip!

Regards,

Al

RE: Vim Wiki - Tip Page Formatting Deadline

[Sebastian Menge]

Am Mittwoch, den 16.05.2007, 09:43 +0200 schrieb Zdenek Sekera:
> - 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 also vote for v2 (though i wrote v1 :-) )

And lets dont forget, that the layout of the template can be changed
always at a later time. So its no problem if we use a suboptimal
template for the beginning ... More important is that the fields keep
consistent ...


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

There is already a "Add Tip" Button on
http://scratchpad.wikia.com/wiki/VimTest . If you try that out, you will
find some instructions on the top. These are freely editable at
http://scratchpad.wikia.com/wiki/TipInstructions .

When using this "AddTip" approach, people have to invent their own
pagename. (autoincrementig the tip-id seems to be impossible) 

Therefore, I would vote for using  tip-title == page-title and let the
categorization be done by [[Category:VimTip]]. Using Wikipedia standards
(CamelCaseIsUgly) we would get pages like "The Super Star" and we could
reuse the title in the template. We would loose the tip-id for new tips.
But that seems to be unavoidable. And what is the id good for anyways?
Using a cron job to convert tips wont work, because we have no access to
the host.

Sebastian.

Re: enabling cyrillic character display support

[A.J.Mechelynck]

Snucky wrote:

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!


To see cyrillic characters in Console Vim you need a terminal with Cyrillic 
display, since Console Vim can only use whatever characters the underlying 
terminal offers.


In gvim, you can display Cyrillic characters on two conditions:
- 'encoding' must be set to some value which supports Cyrillic text. This can 
be an 8-bit encoding like koi8-r, cp1251 or ISO-8859-5, or a multibyte 
encoding like UTF-8.
- Your 'guifont' must include Cyrillic glyphs. Lucida_Console has a problem in 
that its Cyrillic bold glyphs are slightly wider than its unbold glyphs. 
Courier_New is uglier but "saner".


So here is (a part of) a vimrc for gvim, to use Cyrillic characters:



if &enc !~? '^u'
if &tenc == ''
let &tenc = &enc
endif
set enc=utf-8
endif
set fencs=ucs-bom,utf-8,default,iso-8859-5
setglobal bomb fenc=utf-8
if has('gui_running')
if has('gui_gtk2')
set gfn=Courier\ New\ 10
elseif has('gui_photon')
set gfn=Courier\ New:s10
elseif has('gui_kde')
set gfn=Courier\ New/10/-1/5/50/0/0/0/1/0
elseif has('x11')
set gfn=*-courier-medium-r-normal-*-*-100-*-*-m-*-*
else
set gfn=Courier_New:h10:cDEFAULT
endif
endif
language messages ru_RU.UTF-8
runtime vimrc_example.vim
" add additional customizations here




Best regards,
Tony.
--
"It's not Camelot, but it's not Cleveland, either."
-- Kevin White, mayor of Boston

Vim71: breaking change not mentioned in the document.

[panshizhu]

Hi, vimmers:

The line 1230 of editing.txt said:

To change to the directory of the current file:
:cd %:h

This works for Vim 7.0 and before, but not for Vim 7.1. In Vim 7.1 when the
pwd is the same as the directory of current file, the command will fail
with E500. The failure will break the execution of a mapping, if one have a
mapping to do :cd %:h and then continue to do something else.

To reproduce the error, just at anytime, run :cd %:h twice. (I've got
Windows gvim7.1.1, cygwin console vim 7.1.1)

So there's at least two issues IMHO:
1. the line 1230 of editing.txt should be changed to :cd %:p:h
2. somewhere in the document should mention: if we had used :cd %:h in our
mappings or scripts, we should change them into %:p:h after upgraded to vim
7.1.

Or did I missed anything?
--
Sincerely, Pan, Shi Zhu. ext: 2606

Re: enabling cyrillic character display support

[Yongwei Wu]

Hi Snucky,

On 16/05/07, Snucky <[EMAIL PROTECTED]> wrote:


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?


If your file is already encoded in UTF-8, it should be quite trivial.
If you are using the latest Windows gVim, this single line should do the
magic:

:set encoding=utf-8

Open your UTF-8 encoded file after executing the above line (put it in
_vimrc will do), and all should be OK.

BTW, what do you mean by "not properly display"?  Please describe in
more detail, so other people understand if it is a display issue or
encoding issue.  The above discussion addresses the encoding issue,
i.e., the Cyrillic characters are displayed in Latin-1 or things like
that.  If some squares are in the place of the characters, but the
number of characters are correct, it may be a font problem.  Just check
to ensure you have the Cyrillic support installed on your Windows
system, and put this in your _vimrc:

:set guifont=Courier_New:h10:cDEFAULT

If you are courageous enough see a real-world example of complicated
multi-language support, check my _vimrc at:

http://wyw.dcweb.cn/download.asp?path=vim&file=_vimrc.txt (as text) or
http://wyw.dcweb.cn/download.asp?path=vim&file=_vimrc.html (as HTML)

Best regards,

Yongwei

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

Re: vim 7.1 and cr/lf interpretation

[A.J.Mechelynck]

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.




Setting ff=dos after the file is loaded changes nothing to the contents of the 
file data in memory, it only changes how the ends-of-lines will be represented 
on output. So if you have a file with mixed ends-of-lines and 'fileformat' 
detected as "unix", using ":setlocal ff=dos" will result in some lines having 
CR+LF (where there was only LF before) and others (which already had CR+LF 
shown as ^M at end of line) will get CR+CR+LF. So this is not the way to go.


To detect a file with mixed ends-of-lines as dos-format, we must first disable 
automatic "unix" filetype detection. One way to do this is to set the 
'fileformats' (plural) option to the empty string:


:set fileformats=

Now we can manually detect the file's format (see ":help ++opt"):

:e ++ff=dos filename

which will interpret CR+LF as an end-of-line, and LF-without-CR also as an 
end-of-line. So now all lines (in memory) are as they should be, with no 
spurious end-of-line ^M showing. ^M will only appear if there is a CR not 
immediately followed by a LF (either a lone CR in the middle, or more than one 
CR before a LF).


We must now save this "file-in-memory" to disk, to make the "repairs" 
permanent. Here we have the choice of how we want to save it:


- To save the file with CR+LF at the end of every line, leave 'fileformat' at 
its current value ("dos") and just write the file:


:w

- To save the file with LF-only:

:setlocal ff=unix
:w

- To save the file with CR-only:

:setlocal ff=mac
:w

After that, we may want to re-enable automatic fileformat detection: either 
set it back to its default:


:set fileformats&

or set the value explicitly, for example:

:set ffs=dos,unix,mac



Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
238. You think faxes are old-fashioned.

Re: Vim Wiki - Tip Page Formatting Deadline

[fREW]

On 5/15/07, 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.

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




I think you are right about the comments.  It doesn't look like the
best thing ever, but it will work fine for a wiki.  People will
probably leave off the  sometimes and that will probably be
something that we will have to live with.  I think that there is
probably a way that we can make a reminder for people to put that
there after comments, but I don't think we could easily require it.
Also, it should be obvious that I prefer the Tip2 template ;-)

-fREW

RE: Vim Wiki - Tip Page Formatting Deadline

[Zdenek Sekera]

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

Identify this Vim font for me, please

[madiyaan]

Hello,

This isn't very related to Vim, but I found this font on Vim's wikipedia
webpage:

http://upload.wikimedia.org/wikipedia/commons/8/8c/Vim-%28logiciel%29-console.png

Can anyone identify this font for me? It looks very good for programming.

Thank you very much,
-- 
View this message in context: 
http://www.nabble.com/Identify-this-Vim-font-for-me%2C-please-tf3763035.html#a10637057
Sent from the Vim - General mailing list archive at Nabble.com.

Re: yanking text

[Robert Cussons]

A.J.Mechelynck wrote:

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:


sorry, did look at the help file, but didn't read the whole section and 
it was right at the end :">





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.


Few moments pause while I look up what POSIX isso this method is 
standard compliant with other Unix systems, but is not so useful for 
effective text editing IMHO as when I yank text backwards it is because 
I want to use that text again at some later part of the document (as I 
like most people, I believe) write documents from start to finish (with 
a lot of detours admittedly ;-)), so to me it would make more sense to 
leave the cursor alone. Is this purely a compliance reason then or does 
someone have some text editing reason for doing it aswell?


If I wanted to change this behaviour, would I be right in thinking that 
I would have to define the yank command followed by a motion to set a 
mark, do the yank command then return to that mark? Actually just done a 
bit of reading in the help file and it appears I don't need marks, I 
could make use of the `] function, so then all I would want is to change 
the behaviour of any backwards yank to the same command, but with `] 
tagged on the end. However, you can only remap single keys can't you, so 
I guess something like:


nnoremap y y`]

wouldn't work, and I wouldn't know how to include the motion without 
specifying them all individually.


Or is this all a very bad idea and shouldn't be done anyway ;-)

Thanks for any input,
Rob.