RE: VimTips Wiki: New Direction

[Zdenek Sekera]

> -Original Message-
> From: Spencer Collyer [mailto:[EMAIL PROTECTED] 
> Sent: 06 March 2007 08:31
> Cc: Vim Mailing List
> Subject: Re: VimTips Wiki: New Direction
> 
> On Tue, 6 Mar 2007 03:18:13 +0200, Ali Polatel wrote:
> > And check out
> > http://en.wikibooks.org/wiki/Learning_the_vi_editor/Vim/TipsSandbox
> > to see how it parsed tip #1.
> 
> Looks good. Only comment I have is it might be better if the 'By' and
> 'On' lines for the comments were on the same line. Anything 
> that allows
> more useful info on a screen at once is an improvement in my eyes.

Yes, I very much agree, use screen real estate for useful info
as much as possible. Otherwise good IMHO!

---Zdenek


smime.p7s
Description: S/MIME cryptographic signature

Re: BufWritePre and :wqa

[Cyril Slobin]

On 3/6/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote:


It will help a lot to understand what you are talking about if you
include an example script.  Details might matter.


Well. In my _vimrc I set up an autocommand

autocmd BufWritePre * ks|call TimeStamp()|'s

I believe that content of TimeStamp is irrelevant, but just in case it matters:

function! TimeStamp()
 let lines = line("$") < 10 ? line("$") : 10
 let pattern1 = '\(Last [Cc]hange:\s\+\)\d\d\d\d \u\l\l \d\d'
 let replace1 = '\1' . strftime("%Y %b %d")
 execute printf('1,%ds/\C\m%s/%s/e', lines, pattern1, replace1)
 execute printf('$-%d+1,$s/\C\m%s/%s/e', lines, pattern1, replace1)
 let pattern2 = '\($Id: \f\+ \d\+\.\d\+\(\.\d\+\.\d\+\)*\)\(+\(\d\+\)\)\?'
 let replace2 = '\=submatch(1) . "+" . (submatch(4) + 1)'
 execute printf('1,%ds/\C\m%s/%s/e', lines, pattern2, replace2)
 execute printf('$-%d+1,$s/\C\m%s/%s/e', lines, pattern2, replace2)
endfunction

When I save buffer with :w -- it works.
When I save buffer with :wq -- it works.
But when I save buffer with :wqa -- it doesn't work.
Vim 7.0, not patched, win32 and dos32 versions.

My whole _vimrc is at http://45.free.net/~slobin/vim/_vimrc.html if this helps.

--
Cyril Slobin <[EMAIL PROTECTED]> `When I use a word,' Humpty Dumpty said,
 `it means just what I choose it to mean'

Re: BufWritePre and :wqa

[A.J.Mechelynck]

Cyril Slobin wrote:

On 3/6/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote:


It will help a lot to understand what you are talking about if you
include an example script.  Details might matter.


Well. In my _vimrc I set up an autocommand

autocmd BufWritePre * ks|call TimeStamp()|'s

I believe that content of TimeStamp is irrelevant, but just in case it 
matters:


function! TimeStamp()
 let lines = line("$") < 10 ? line("$") : 10
 let pattern1 = '\(Last [Cc]hange:\s\+\)\d\d\d\d \u\l\l \d\d'
 let replace1 = '\1' . strftime("%Y %b %d")
 execute printf('1,%ds/\C\m%s/%s/e', lines, pattern1, replace1)
 execute printf('$-%d+1,$s/\C\m%s/%s/e', lines, pattern1, replace1)
 let pattern2 = '\($Id: \f\+ \d\+\.\d\+\(\.\d\+\.\d\+\)*\)\(+\(\d\+\)\)\?'
 let replace2 = '\=submatch(1) . "+" . (submatch(4) + 1)'
 execute printf('1,%ds/\C\m%s/%s/e', lines, pattern2, replace2)
 execute printf('$-%d+1,$s/\C\m%s/%s/e', lines, pattern2, replace2)
endfunction

When I save buffer with :w -- it works.
When I save buffer with :wq -- it works.
But when I save buffer with :wqa -- it doesn't work.
Vim 7.0, not patched, win32 and dos32 versions.

My whole _vimrc is at http://45.free.net/~slobin/vim/_vimrc.html if this 
helps.




Unlike ":w" or ":wq", ":wqa" only triggers a write if the buffer is 
'modified'. Are you sure that it was?


Best regards,
Tony.
--
Work Rule: Leave of Absence (for an Operation):
We are no longer allowing this practice.  We wish to discourage
any thoughts that you may not need all of whatever you have, and you
should not consider having anything removed.  We hired you as you are,
and to have anything removed would certainly make you less than we
bargained for.

Re: BufWritePre and :wqa

[Cyril Slobin]

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


Unlike ":w" or ":wq", ":wqa" only triggers a write if the buffer is
'modified'. Are you sure that it was?


Curioser and curioser! When I explicitly modify a buffer by hand, the
event IS triggered. But if the buffer is generated by :TOhtml command,
it is marked as 'modified', but the event IS NOT triggered. I do not
know how :TOhtml obtains this effect, I've failed to reproduce it by
hand.

--
Cyril Slobin <[EMAIL PROTECTED]> `When I use a word,' Humpty Dumpty said,
 `it means just what I choose it to mean'

Re: BufWritePre and :wqa

[Cyril Slobin]

On 3/6/07, Cyril Slobin <[EMAIL PROTECTED]> wrote:


Curioser and curioser! When I explicitly modify a buffer by hand, the
event IS triggered. But if the buffer is generated by :TOhtml command,
it is marked as 'modified', but the event IS NOT triggered. I do not
know how :TOhtml obtains this effect, I've failed to reproduce it by
hand.


Sorry, people. I am a complete idiot. My fault. No errors in Vim, error
in my script. I check the first ten and the last ten lines of a buffer
for time stamp. Time stamp is in the third line in original file, but in
the eleventh in generated HTML. As silly as any error when discovered.
Sorry again. Vim is great!

--
Cyril Slobin <[EMAIL PROTECTED]> `When I use a word,' Humpty Dumpty said,
 `it means just what I choose it to mean'

dos32 colors

[Cyril Slobin]

Hi all!

In color xterm color 1 for is #0c (red), but in dos32 it is #0c
(blue). (Strictly speaking, VGA standard palette is different, but xterm
colors are good enough approximation in practice). This makes very hard
to write portable scripts dealing with colors. Does a better way to
write a such a script exist other than:

if has("dos32")
 let color1 = "#0c"
else
 let color1 = "#0c"
endif

? By the way, 2html.vim does not perform this test and colors of HTML
generated in dos32 are wrong.

--
Cyril Slobin <[EMAIL PROTECTED]> `When I use a word,' Humpty Dumpty said,
 `it means just what I choose it to mean'

FW: Adding quotes around html attribute values

[Timothy Adams]

Hi,
 
I've been given some html which, oddly, is half in nicely quoted
attributes+values:
 

 
and half not
 

 
I'm trying to write a regex to add quotes around the ones without. I can
do this in perl, but not in vim, and I'd like to know what I'm doing
wrong because I've run across this problem before.
 
This was my attempt:
 
:%s/=\([^"]\+\)\{-}\([ >]\)/="\1"\2/g
 
My reasoning:
 
=\([^"]\+\) find and save stuff after an = that does not
have a "
\{-}I've never used this before, just found it
online, at first it seemed to do what I want it to do, make the \+
evaluation lazy
\([ >]\)find and save either the space or > after the
attribute value
 
It half works, but sometimes skips spaces and I get 
 
Any advice would be appreciated. Perhaps I'm not using \{-} correctly?

Re: FW: Adding quotes around html attribute values

[Tim Chase]

 
and half not
 

 
I'm trying to write a regex to add quotes around the ones without. I can

do this in perl, but not in vim, and I'd like to know what I'm doing
wrong because I've run across this problem before.
 
This was my attempt:
 
:%s/=\([^"]\+\)\{-}\([ >]\)/="\1"\2/g
 
My reasoning:
 
=\([^"]\+\)		find and save stuff after an = that does not

have a "
\{-}I've never used this before, just found it
online, at first it seemed to do what I want it to do, make the \+
evaluation lazy
 
Any advice would be appreciated. Perhaps I'm not using \{-} correctly?


You've diagnosed where the problem lies...it's in the interaction 
between your greedy


[^"]\+

and your non-greedy

\{-}

Greedy wins. :)  The latter is an operator like the "\+", so you 
likely want to convert your top bit to something like


[^"]\{-}

or possibly

[^"]\{-1,}

(which is "one or more, but as few as possible"...the embodiment 
of your "I want to make \+ non-greedy" aim)


You can read up on the nuances of "\{-}" at

:help /\{

If I had to take a crack at it, I'd exploit the greediness rather 
than shirk it, and do something like


:%s/=\([^" \t>]\+\)/="\1"/g

You might even be able to do something like

:%s/=\(\w\+\)/="\1"/g

depending on your attributes (what is considered a "word" 
character for an HTML attribute would need to take into 
consideration the "-" and the "." at a minimum, but these can 
easily be added to the 'iskeyword' setting with ":set 
iskeyword+=." and ":set iskeyword+=-")


The whole thing goes hooey if you have such matches outside tags, 
which you might then want to modify your regexp to be something like


:%s/\(<[^=>]*\)=\([^" \t>]\+\)/\1="\2"/g

which should help to ensure some "inside-a-tag"ness context. 
However, it only tidies one attribute for each tag, so you might 
have to run it multiple times in the event you have multiple bad 
attributes for a given tag like




Just a few ideas that might help.  YMMV :)

-tim

Re: VimTips Wiki: New Direction

[Hari Krishna Dara]

On Mon, 5 Mar 2007 at 1:26pm, Tom Purl wrote:

> Here's my view of "where we are" regarding the Vim Tips wiki conversion
> project:
>
> 1. The Google wiki seems to be a poor option due to the difficulty
>involved in registering.
> 2. Multiple other wiki engines have been discussed, and the clear
>favorite seems to be a site built on top of the Mediawiki
>application.
> 3. Of all of the sites that offer free wiki hosting using Mediawiki,
>Wikibooks seems to be the most favored.
>
> Note: These are all my opinions based on what I've read.  I hope to hear
> from everyone that has a different perspective :)
>
> Ok, so based on my version of reality, I think that we should proceed with
> the following actions:
>
> 0. I'll create the following page on the Vim Tips chapter of the Vim book
> on Wikibooks (whew!):
> * http://en.wikibooks.org/wiki/Learning_the_vi_editor/Vim/TipsSandbox
> 1. All of the people who wrote tip conversion scripts before should
>update them so that the output format is "Wikipedia markup", not
> "Google markup"
> * I apologize to the script writers for making them do more work.
>   Hopefully, the necessary changes to your scripts will be small.
> * Also, please note that I _don't_ think that anyone should
>   contribute a new script to this effort.  We already have three very
> capable scripts that can probably get the job done very well, so I don't
> think that the effort would be worthwhile for anyone else.
> 2. Convert one tip and post the output on the TipsSandbox page listed
>above.
> 3. The vim community will come to a consensus on the best format for the
>tips, and we will use the best script for the job.
> 4. Consensus achieved!!!
> 5. We will automate the task of converting all of the tips.
> 6. A group of wiki superusers will inspect 50 random tips and make sure
>that they look good.
> 7. The invisible hand of The Wiki will then gradually make our wonderful
>collection of Vim tips even more awesome than they've ever been before! ;D
>
> So, what do you guys think?
>
> Tom Purl

I have been reading posts on this subject with interest and think that
this is going to be a good decision. My only concern is on how we are
planning to support the existing rating system going forward and if we
can enforce a fixed style on commenting such that the comments don't
look like a mess. I would imagine that one needs to edit the tip to add
their comment at the end, but it will be nice if the comment itself
happens as a discussion (which appears as a discussion tab on the same
page).

--
Thanks,
Hari

-- 
Thanks,
Hari


 

Sucker-punch spam with award-winning protection. 
Try the free Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/features_spam.html

Re: VimTips Wiki: New Direction

[Ali Polatel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Zdenek Sekera ([EMAIL PROTECTED]) wrote:
> > -Original Message-
> > From: Spencer Collyer [mailto:[EMAIL PROTECTED] 
> > Sent: 06 March 2007 08:31
> > Cc: Vim Mailing List
> > Subject: Re: VimTips Wiki: New Direction
> > 
> > On Tue, 6 Mar 2007 03:18:13 +0200, Ali Polatel wrote:
> > > And check out
> > > http://en.wikibooks.org/wiki/Learning_the_vi_editor/Vim/TipsSandbox
> > > to see how it parsed tip #1.
> > 
> > Looks good. Only comment I have is it might be better if the 'By' and
> > 'On' lines for the comments were on the same line. Anything 
> > that allows
> > more useful info on a screen at once is an improvement in my eyes.

Done.

> 
> Yes, I very much agree, use screen real estate for useful info
> as much as possible. Otherwise good IMHO!

Thanks !

Another thing to mention is I found a great library called
HTML-WikiConverter. Unfortunately it's a perl library and I don't have the time
to convert stuff. But I found a rather ugly way to use it.HTML-WikiConverter
comes with a script html2wiki and vimtips.py calls this with 
commands.getstatusoutput().
This is a major decrease in performance considering creation of temporary files
but I don't think this is what we aim here.The library will help
especially with converting  tags to
appropriate places.
  Anyone who wants to test can get the library with
perl -MCPAN -e 'install Bundle::HTMLWikiConverter'

  If vimtips.py can't find html2wiki it'll just issue a warning and go on
parsing.

Here is wikipedia page generated by the new version:
http://en.wikibooks.org/wiki/Learning_the_vi_editor/Vim/TipsSandbox/Tip_1:_the_super_star

Any comments,ideas welcome.

Ali

P.S.: links like vimtip #5 don't
get parsed correctly but this will be done when we arrange the tips and
start to add them for good using html2wiki's --base-uri and --wiki-uri options

- -- 
Ali Polatel (hawking) <[EMAIL PROTECTED]>
http://hawking.nonlogic.org/
gpg: F0186CA2 fp: 7110 01E2 F8B6 83A2 AC52  1D9F 986B 76E1 F018 6CA2
()  ascii ribbon campaign - against html mail
/\
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.2 (GNU/Linux)

iD8DBQFF7ZkJmGt24fAYbKIRAnA4AJ48gETBvL7Bx/m4hRJk1qy/ZhRycgCg8P+N
FQpbSYwdG6qlhrwQxYJXYcE=
=VzBC
-END PGP SIGNATURE-

Re: BufWritePre and :wqa

[A.J.Mechelynck]

Cyril Slobin wrote:

On 3/6/07, Cyril Slobin <[EMAIL PROTECTED]> wrote:

[...]

Sorry, people. I am a complete idiot. My fault. [...]


If you can see that you're an idiot, then you aren't. Certainly not a complete 
one at least. As Georges Brassens used to sing:


/Entre nous soit dit, bonnes gens, pour reconnaître/
/Que l'on n'est pas intelligent, il faudrait l'être./

(Roughly translated: it takes intelligence to notice one's lack of it.)


Best regards,
Tony;
--
What garlic is to salad, insanity is to art.

Re: Omnicomplete for C - pattern not found problem

[Zarko Coklin]

I found a partial answer to my question here:
http://tech.groups.yahoo.com/group/vim/message/68078

However, not sure why would the following be declared
as an invalid C code:

struct foo { /* ... */ };
typedef struct foo foo_t;

int main() {
foo myfoo;
/* ... */
}

In fact, I have a lot of instances in the code where
following is used. And what I got from Bram it sounds
omnicompletion will not work!? To me this would be the
most basic thing for omnicomplete to support.

typedef struct foo 
{ /* ... */ 
} foo_t;

int main() {
foo myfoo;
/* ... */
foo. yields with "Pattern not
found"
}



 

Need a quick answer? Get one in minutes from people who know.
Ask your question on www.Answers.yahoo.com

Re: VimTips Wiki: New Direction

[A.J.Mechelynck]

Hari Krishna Dara wrote:
[...]

I have been reading posts on this subject with interest and think that
this is going to be a good decision. My only concern is on how we are
planning to support the existing rating system going forward and if we
can enforce a fixed style on commenting such that the comments don't
look like a mess. I would imagine that one needs to edit the tip to add
their comment at the end, but it will be nice if the comment itself
happens as a discussion (which appears as a discussion tab on the same
page).

--
Thanks,
Hari



Comments can go on the wiki talk page associated with a given tip. If you look 
at talk pages on ??.wikipedia.org, you'll see that in practice they mostly 
adhere to a rather uniform format. If the case warrants, part or all of the 
comments can later be incorporated (by the tip author or maintainer) into the 
main page of the tip.


Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
88. Every single time you press the 'Get mail' button...it does get new mail.

Re: Omnicomplete for C - pattern not found problem

[Vissale NEANG]

Hi,

You can try this C++ omnicomplete plugin
http://www.vim.org/scripts/script.php?script_id=1520
It will work for C files if you copy the file
~/.vim/after/ftplugin/cpp.vim to  ~/.vim/after/ftplugin/c.vim (I'll
add it for the next release).

Best regards,

Vissale

2007/3/6, Zarko Coklin <[EMAIL PROTECTED]>:

I found a partial answer to my question here:
http://tech.groups.yahoo.com/group/vim/message/68078

However, not sure why would the following be declared
as an invalid C code:

struct foo { /* ... */ };
typedef struct foo foo_t;

int main() {
foo myfoo;
/* ... */
}

In fact, I have a lot of instances in the code where
following is used. And what I got from Bram it sounds
omnicompletion will not work!? To me this would be the
most basic thing for omnicomplete to support.

typedef struct foo
{ /* ... */
} foo_t;

int main() {
foo myfoo;
/* ... */
foo. yields with "Pattern not
found"
}





Need a quick answer? Get one in minutes from people who know.
Ask your question on www.Answers.yahoo.com

RE: VimTips Wiki: New Direction

[Steve Hall]

From: Hari Krishna Dara, Tue, March 06, 2007 11:33 am
> 
> My only concern is on how we are planning to support the existing
> rating system going forward 

I don't see how this can be accomplished in a wiki, but on the plus
side we'll be able to categorize and structure the tips better, as
well as link between.

> and if we can enforce a fixed style on commenting such that the
> comments don't look like a mess. I would imagine that one needs to
> edit the tip to add their comment at the end, but it will be nice if
> the comment itself happens as a discussion (which appears as a
> discussion tab on the same page).

I agree, is there any way the porting process can push comments to
each tip's respective discussion tab?



-- 
Steve Hall  [ digitect dancingpaper com ]

Re: FW: Adding quotes around html attribute values

[Bill Moseley]

On Tue, Mar 06, 2007 at 11:04:11AM -0500, Timothy Adams wrote:
> Hi,
>  
> I've been given some html which, oddly, is half in nicely quoted
> attributes+values:

Have you considered using a tool that is designed to fix up your html?
Such as HTML Tidy?

-- 
Bill Moseley
[EMAIL PROTECTED]

RE: FW: Adding quotes around html attribute values

[Timothy Adams]

Yes, there are tools, but I had it open in vim for editing already,
anyways.

Plus, the \{- is something I've been missing out on for a long time, so
I'm glad I got it sorted out now.

Tim's solutions all worked well.

(the other) *tim* 

-Original Message-
From: Bill Moseley [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, March 06, 2007 2:49 PM
To: vim@vim.org
Subject: Re: FW: Adding quotes around html attribute values

On Tue, Mar 06, 2007 at 11:04:11AM -0500, Timothy Adams wrote:
> Hi,
>  
> I've been given some html which, oddly, is half in nicely quoted
> attributes+values:

Have you considered using a tool that is designed to fix up your html?
Such as HTML Tidy?

--
Bill Moseley
[EMAIL PROTECTED]

RE: VimTips Wiki: New Direction

[Denis Perelyubskiy]

On Tue, 06 Mar 2007 11:31:53 -0700, "Steve Hall"
<[EMAIL PROTECTED]> said:
> From: Hari Krishna Dara, Tue, March 06, 2007 11:33 am
> > and if we can enforce a fixed style on commenting such that the
> > comments don't look like a mess. I would imagine that one needs to
> > edit the tip to add their comment at the end, but it will be nice if
> > the comment itself happens as a discussion (which appears as a
> > discussion tab on the same page).
> 
> I agree, is there any way the porting process can push comments to
> each tip's respective discussion tab?

why don't we discuss that here:
http://en.wikibooks.org/wiki/Talk:Learning_the_vi_editor/Vim/TipsSandbox/Tip_1:_the_super_star

:-)

Seriously though, as I had mentioned on the discussion page, for me as a
user of the tip, it is horribly counter-productive to go and read
twenty-five thousands comments on a page. I'd much rather just read a
"perfect" tip. This assumes, of course, that tip contributors care about
me as a user. I hope they do :)

Wikipedia model seems to work great. One page. All the information.
Discussion on a separate page.

One change: if it matters, we could reserve a line (or two) for a list
of contributors. This information is available from the history page for
those who care to look anyway, but maybe people care about their names
being mentioned.

Finally, on the subject of converting the comments - it is entirely a
manual process, that can not be automated. Comments need to be
integrated into the   body of the main tip (maybe the tip needs to be
adjusted, reworded, etc). We should just push out the existing pages,
and then set to work on reworking the tips by hand. Eventually we'll be
done. 

In any case, I think this will be an extremely useful resource
(especially if we could then put VIM's documentation on there, and
cross-link)

Re: VimTips Wiki: New Direction

[Brian McKee]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 6-Mar-07, at 3:34 PM, Denis Perelyubskiy wrote:



On Tue, 06 Mar 2007 11:31:53 -0700, "Steve Hall"
<[EMAIL PROTECTED]> said:

From: Hari Krishna Dara, Tue, March 06, 2007 11:33 am

and if we can enforce a fixed style on commenting such that the
comments don't look like a mess. I would imagine that one needs to
edit the tip to add their comment at the end, but it will be nice if
the comment itself happens as a discussion (which appears as a
discussion tab on the same page).


I agree, is there any way the porting process can push comments to
each tip's respective discussion tab?


why don't we discuss that here:
http://en.wikibooks.org/wiki/Talk:Learning_the_vi_editor/Vim/ 
TipsSandbox/Tip_1:_the_super_star


:-)

Seriously though, as I had mentioned on the discussion page, for me  
as a

user of the tip, it is horribly counter-productive to go and read
twenty-five thousands comments on a page. I'd much rather just read a
"perfect" tip. This assumes, of course, that tip contributors care  
about

me as a user. I hope they do :)

Wikipedia model seems to work great. One page. All the information.
Discussion on a separate page.

One change: if it matters, we could reserve a line (or two) for a list
of contributors. This information is available from the history  
page for

those who care to look anyway, but maybe people care about their names
being mentioned.

Finally, on the subject of converting the comments - it is entirely a
manual process, that can not be automated. Comments need to be
integrated into the   body of the main tip (maybe the tip needs to be
adjusted, reworded, etc). We should just push out the existing pages,
and then set to work on reworking the tips by hand. Eventually  
we'll be

done.

In any case, I think this will be an extremely useful resource
(especially if we could then put VIM's documentation on there, and
cross-link)



One of the first things I was thinking about mirrors the above comments.
http://en.wikibooks.org/wiki/Talk:Learning_the_vi_editor/Vim/ 
TipsSandbox/Tip_1:_the_super_star has a bunch of "thanks for the  
great tip!" type comments with more useage info interspersed.  I  
think those 'great tip' comments go to a separate page, while the  
'use # or % instead' kind of comments need to be edited into the  
actual tip itself.


I don't think that can be automated though - so the question is  
comments to a separate page and edited back in?  or all on one page  
and edited over to the secondary page...


Brian

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

iD8DBQFF7dUhGnOmb9xIQHQRAlpVAJ45MZO4aj5DMVxdnN2Kvd85g6PoAwCff2AG
KdJM5sFvk/OcuLBVTVGeF6Q=
=MnvL
-END PGP SIGNATURE-

RE: VimTips Wiki: New Direction

[Tom Purl]

On Tue, March 6, 2007 2:34 pm, Denis Perelyubskiy wrote:
> Finally, on the subject of converting the comments - it is entirely a
> manual process, that can not be automated. Comments need to be
> integrated into the   body of the main tip (maybe the tip needs to be
> adjusted, reworded, etc). We should just push out the existing pages,
> and then set to work on reworking the tips by hand. Eventually we'll
> be done.

I agree mostly.  The process of moving the tips from vim.org to the wiki
host can be automated.  Ideally, I also think that it would be a good
idea to refactor some comments into the body of some tips, but I
certainly don't think that it's necessary for every tip.

For example, I wrote tip number 1280 which, in hindsight, is pretty
lame.  My tip has one comment from someone who agrees that my tip is
lame :)  Also, I imagine that about 5 people a year read this tip, and
those people probably were looking for something else anyways.

In that situation, do we *really* need to merge the comment with the
tip?  No one uses the tip, and the comment's pretty pointless.  Why
don't we just ignore it?

On the other hand, there are some tips that are used hundreds of times a
week.  These tips will probably be refactored and updated very quickly
due to the sheer number of eyeballs reading it.

So I guess what I'm saying is, what's wrong with waiting for "the
community" to refactor these tips using guidelines from the wikibook
admins?

Thanks!

Tom Purl

RE: VimTips Wiki: New Direction

[Denis Perelyubskiy]

On Tue, 6 Mar 2007 15:00:30 -0600 (CST), "Tom Purl" <[EMAIL PROTECTED]>
said:
> On Tue, March 6, 2007 2:34 pm, Denis Perelyubskiy wrote:
> > Finally, on the subject of converting the comments - it is entirely a
> > manual process, that can not be automated. Comments need to be
> > integrated into the   body of the main tip (maybe the tip needs to be
> > adjusted, reworded, etc). We should just push out the existing pages,
> > and then set to work on reworking the tips by hand. Eventually we'll
> > be done.
[snip]
> So I guess what I'm saying is, what's wrong with waiting for "the
> community" to refactor these tips using guidelines from the wikibook
> admins?

Sorry, was not clear. That's what I am arguing for as well. I am not
saying "let's have admins do all the work before the site goes live". I
am saying let's leave things the way they are, provide a template, and
slowly set about refactoring tips (encouraging users to do the same). I
haven't checked, but if there is a wikipedia-style "this page still
needs your attention" notification that can be placed on the page, we
could do that as well.

so, i propose we move to agreeing what the format should be.

-denis

To imap or to iabbr

[Eric Leenman]

Hi,

What is the difference between imap or iabbr?
Or in other words, when should you use imap and when to iabbr?

Rgds,

Eric

_
Find what you need at prices you’ll love. Compare products and save at MSN® 
Shopping. 
http://shopping.msn.com/default/shp/?ptnrid=37,ptnrdata=24102&tcode=T001MSN20A0701

Re: VimTips Wiki: New Direction

[Tobias Pflug]

On Tue, 2007-03-06 at 18:38 +0200, Ali Polatel wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> * Zdenek Sekera ([EMAIL PROTECTED]) wrote:
> > > -Original Message-
> > > From: Spencer Collyer [mailto:[EMAIL PROTECTED] 
> > > Sent: 06 March 2007 08:31
> > > Cc: Vim Mailing List
> > > Subject: Re: VimTips Wiki: New Direction
> > > 
> > > On Tue, 6 Mar 2007 03:18:13 +0200, Ali Polatel wrote:
> > > > And check out
> > > > http://en.wikibooks.org/wiki/Learning_the_vi_editor/Vim/TipsSandbox
> > > > to see how it parsed tip #1.
> > > 
> > > Looks good. Only comment I have is it might be better if the 'By' and
> > > 'On' lines for the comments were on the same line. Anything 
> > > that allows
> > > more useful info on a screen at once is an improvement in my eyes.
> 
> Done.
> 
> > 
> > Yes, I very much agree, use screen real estate for useful info
> > as much as possible. Otherwise good IMHO!
> 

If I might add my impression:

Generally I think it is indeed quite likable. Just some thoughts :

Looking at : 
http://en.wikibooks.org/wiki/Learning_the_vi_editor/Vim/TipsSandbox/Tip_1:_the_super_star

my thoughts:

1. focus/structure:

At the moment there is a bit of a lack of focus when I look at the page.
The eye-catcher is more or less the box with the author/creator/etc meta
information. The focus should however be on the actual text/body of the
tip. So maybe the text should be in a (differently colored?) box to gain
more attention and separate it from comments and meta info etc. Same
goes with the info boxes for comments on the tip and the comments
contents. I'd also suggest to maybe separate tips with
horizontal lines (maybe even removing the info boxes..) Also what about
perhaps indenting the comments a bit to the right?

2. formatting:

I think tex is right with its default formatting in which line length is
rather short. I think it would be nice if line breaks could be added ?
However while typing this I realize that this would suck when you break
up code..

I realize that currently it's still about figuring out how to properly
parse/convert the content etc.. just wanted to shout out what I have on
my mind about it.

thanks to those doing all the work, looking forward to use the wiki-tips
already..

regards,
Tobi

Re: To imap or to iabbr

[Tim Chase]

What is the difference between imap or iabbr? Or in other
words, when should you use imap and when to iabbr?


Sometimes, they have similar results, while other times they have 
disjoint purposes.  My general guidline:


- use :iab only those times when expanding some short text into 
some long text.  This is mostly in line with the meaning of 
"abbreviation".


-If there's any sort of action/movement involved, use a mapping.

How they're triggered also plays into matters.  If I do something 
like


:iab IU International Units

It won't get expanded if I type "HELIUM".  However, if I do a 
mapping:


:inoremap IU International Units

and attempt to type "HELIUM", I'll get "HELInternational UnitsM"

Multi-character mappings also have a slight delay in them, so in 
the preceeding example, after I type "HELI", there's a slight 
pause while Vim sees if I am going to type "U", or if I type 
something else, so it knows how to behave.


Things get slightly more complex if you're writing code-block 
expansions such as wanting "IF" to expand to


if (|) {
} else {
}

and put the cursor where the "|" is.  It involves an expansion 
(and thus suggests an :iab for the expansion) but also involves 
moving the cursor to a particular position.  I've not had luck 
doing those as :iab expansions, so I resort to mappings...usually 
prefixing them with an infrequently used character such as 
control+G or a tilde as fits.


Just my $0.02USD

-tim

RE: VimTips Wiki: New Direction

[Denis Perelyubskiy]

On Tue, 06 Mar 2007 13:24:09 -0800, "Denis Perelyubskiy"
<[EMAIL PROTECTED]> said:
[snip]
> so, i propose we move to agreeing what the format should be.

..and after thinking about this a bit more:
- format?
- karma/rating (i think someone already brought it up). How do we do
this here? The use seems to be that you can browse by scores. Do people
do this? Would the tips maybe just become intrinsically useful by nature
of being edited by many people?
- difficulty - do we need this? what's the use-case for that? do people
come looking for "easy" tips? it appears they may be looking for a)
useful tips (item above), or for b) tips applicable to their situation
(tag-related tips). 
- date. who cares?

anything else?

-denis

Re: VimTips Wiki: New Direction

[Diwaker Gupta]

My apologies for barging in this discussion this late. However, I
wanted to make sure all alternatives are being given a fair chance. It
seems that wikibooks.org is the most popular choice. I just want to
throw out a couple of other free, hosted Wiki alternatives for people
to look at:

o http://pbwiki.com/  http://yummy.pbwiki.com/
o http://jot.com (acquired by Google). Sample wiki http://dojo.jot.com/WikiHome
o http://wikia.com -- like wikibooks, uses mediawiki
o http://wikispaces -- run of the mill
o http://www.wetpaint.com/
o http://www.wikidot.com/

I really like pbwiki and jot.

Finally, this has been voiced before and I just wanted to add my 2c --
I'm not sure if a general purpose Wiki is the best solution for
something as specific as a collection of Tips. The notion of rating,
comments etc doesn't come naturally to a Wiki.

IMHO, the best solution is to setup a blog. There are several free
Wordpress based blog services. There are several free Wordpress
plugins to implement rating for posts, most popular posts and such.
Commenting is built in. The more I think about it, the more it seems
like the perfect solution to me. Thoughts?

Diwaker
--
Web/Blog/Gallery: http://floatingsun.net/blog

RE: VimTips Wiki: New Direction

[Hari Krishna Dara]

On Tue, 6 Mar 2007 at 12:34pm, Denis Perelyubskiy wrote:

>
> On Tue, 06 Mar 2007 11:31:53 -0700, "Steve Hall"
> <[EMAIL PROTECTED]> said:
> > From: Hari Krishna Dara, Tue, March 06, 2007 11:33 am
> > > and if we can enforce a fixed style on commenting such that the
> > > comments don't look like a mess. I would imagine that one needs to
> > > edit the tip to add their comment at the end, but it will be nice if
> > > the comment itself happens as a discussion (which appears as a
> > > discussion tab on the same page).
> >
> > I agree, is there any way the porting process can push comments to
> > each tip's respective discussion tab?
>
> why don't we discuss that here:
>
http://en.wikibooks.org/wiki/Talk:Learning_the_vi_editor/Vim/TipsSandbox/Tip_1:_the_super_star
>
> :-)
>
> Seriously though, as I had mentioned on the discussion page, for me as a
> user of the tip, it is horribly counter-productive to go and read
> twenty-five thousands comments on a page. I'd much rather just read a
> "perfect" tip. This assumes, of course, that tip contributors care about
> me as a user. I hope they do :)
>
> Wikipedia model seems to work great. One page. All the information.
> Discussion on a separate page.
>
> One change: if it matters, we could reserve a line (or two) for a list
> of contributors. This information is available from the history page for
> those who care to look anyway, but maybe people care about their names
> being mentioned.
>
> Finally, on the subject of converting the comments - it is entirely a
> manual process, that can not be automated. Comments need to be
> integrated into the   body of the main tip (maybe the tip needs to be
> adjusted, reworded, etc). We should just push out the existing pages,
> and then set to work on reworking the tips by hand. Eventually we'll be
> done.
>
> In any case, I think this will be an extremely useful resource
> (especially if we could then put VIM's documentation on there, and
> cross-link)

I agree, without updating the original tip based on the feedback from
comments, it is incredibly painful to go through all the comments and
get best out of it. In fact, currently, when you read comments, what you
are looking for a ways to improve the original tip, not those that just
complement it. From this regard, the comments are more of discussions to
improve the tip.

Since the wiki model allows for anyone to go and modify the tip, it will
be interesting to see how a tip will be modified once the discussion
results in multiple ways to improve it. I guess you can then accommodate
multiple solutions right in the tip.

-- 
Thanks,
Hari


 

It's here! Your new message!  
Get new email alerts with the free Yahoo! Toolbar.
http://tools.search.yahoo.com/toolbar/features/mail/

Re: VimTips Wiki: New Direction

[Denis Perelyubskiy]

On Tue, 6 Mar 2007 15:23:41 -0800, "Diwaker Gupta"
<[EMAIL PROTECTED]> said:
[snip]
> IMHO, the best solution is to setup a blog. There are several free
> Wordpress based blog services. There are several free Wordpress
> plugins to implement rating for posts, most popular posts and such.
> Commenting is built in. The more I think about it, the more it seems
> like the perfect solution to me. Thoughts?

I think blog does not quite work. One would have to consider an ultimate
goal - provide a collection of "accessible" and "maintainable" tips to
ease people's interaction with a wonderful yet nightmarishly-complicated
vim editor :)

There are tasks towards that goal:
- reducing spam (to enable 'accessibility') in a non-burdernsome way (to
enable maintainability)
- enable ratings (acessibility)
- format (yet again, accessibility)

- maybe i am missing something here -

This is why I argue that notion of commenting runs a bit counter to the
goal of accessibility for the tips. It requires one to read through the
tip, then go on to read what other people are saying about the tip. Why
would not those other people just edit the tip directly? There are
administrators to prevent absurdity from ensuing (witness, for example,
the Scooter Libby page on wikipedia)

You bring up a good point about a problem with rating tips though. I am
not sure how to solve that with a wiki. Frankly, I am not even sure
(yet) whether it is an important task that needs to be solved.  Does
this enable more accessible tips? Maybe. (maybe something along the
'digg' lines?) There must be a way to host a digg/reddit-like thing on
sourceforge, and put a little "dugg N times" thing on the page, and then
a link to search. Especially if this is a non-essential thing, we could
probably afford to host it on a less reliable infrastructure?

anyway, these are just my thoughts on the matter. I am sure there are
people who are much more qualified who can comment.

-denis

I want to map 't h i s' message

[wolfpil]

Using many colorschemes 't h i s'  message appears yellow and is therefore 
hardly to read inside of a light background cterm.


> Auslagerungsdatei ".post.swp" ist bereits vorhanden!
> Nur zum [L]esen ffnen, Trotzdem (e)ditieren, (W)iederherstellen, (B)eenden, 
> (A)bbrechen:

After a long long time of trial and error mapping of all sorts of messages I 
didn't find how it is called in vim.
I only could find how it is not called.

Re: VimTips Wiki: New Direction

[Paul Irofti]

On Tue, Mar 06, 2007 at 06:45:51PM +1100, John Beckett wrote:
> Tom Purl wrote:
> >I looked into the anti-spam features of Wikibooks, and they basically do
> >the basics: blacklists for abusers and easy rollbacks.  So the top 2% of
> >spammers/vandalizers will be blocked, and it will be easy for the admins
> >to roll back the problems created by the outher 98%.
> 
> Wikibooks sounds good.
> 
> I wonder if it would be worth looking for a volunteer to occasionally take
> a snapshot of the wiki as an emergency backup. Presumably wget or
> similar would be adequate, or maybe there is an easy way to get the
> mediawiki source.
> 
> Such a backup might be useful in a few weeks, and then perhaps monthly.
> 
> John
> 

Back-ups are better made on the server side. For mediawiki a regular
sqldump (maybe added in crontab) is all that is necessary.