Eric Leenman wrote:
I'm having the same problem, and the three solutions don't
work for me. In all the three solutions (and even the other
thread I started with your reply windo diffthis) doesn't work.
What happens is that one window folds the complete file to one
line. The other window keeps t
Sebastian Menge wrote:
Put the list of 1500 tip titles in one file, one title per
line. Then edit that file to clean up the titles. Then run a
script to rename each tip to match the cleaned-up title.
One idea was that the editing can be done on the wiki. Just
edit the Errornames page :-)
Neat
Sebastian Menge wrote:
Find the list (95 entries) here:
http://scratchpad.wikia.com/wiki/Errornames
Thanks for the good start.
FYI there are a couple of lines with broken links:
157 160: 171: Do you know the "g/" and "g?" commands?
Above gives:
Vim Online Error
Couldn't find tip 160. Are you
Yakov Lerner wrote:
9-digit number can still be larger than 2^32-1, or than
2^31-1.
Just for the record:
2^30 = 1,073,741,824
So 999,999,999 (largest 9-digit number) won't overflow a 32-bit
signed integer.
John
A.J.Mechelynck wrote:
What about a different function to return, say, the number of
1K blocks (or the number of times 2^n bytes, with a parameter
passed to the function) that a file uses?
Yes, that's a much more general and better idea.
Since there's probably not much need for this, I think th
panshizhu wrote:
Yes, but on all systems, vim script could not take 64-bit
integers
I know that. My proposal is for a new Vim script function:
islargefile({fname}, {limit})
which would return nonzero if the size of the file is greater
than the 32-bit signed {limit} argument.
Vim could easi
Yongwei Wu wrote:
Even FAT32 supports files much larger than 4GB.
Not true. FAT32 supports files up to 4 GB.
Sorry I shot my mouth off there - I realised my blunder about ten
minutes after sending. I haven't actually used a FAT32 partition
for over ten years, and was confusing the maximum siz
Charles E Campbell Jr wrote:
Sounds like the filesize is getting stored in a 32bit signed
number, and overflowing.
Yes, definitely.
Please let me know what getfsize() is actually returning
The return value is the bit pattern for the low 32 bits of the
true 64-bit file size:
3,146,839,49
panshizhu wrote:
As far as I know, Windows does not support files larger than
4GB. So its okay to use unsigned 32-bit for filesize in
windows.
It's not as bad as that! Even FAT32 supports files much larger
than 4GB.
The Win32 API includes function _stati64() to get a 64-bit file
size (the API
Peter Palm wrote:
http://www.vim.org/scripts/script.php?script_id=1506.
Indeed, among other things, this disables the swap file for
'large' files, which should really speed up things.
I was going to report the following issue to vim-dev after I got
a chance to investigate it a little further,
Sebastian Menge wrote:
[...very helpful summary for Vim Wiki...]
Thanks for keeping this moving. I'm happy with what you said,
but here are some comments. Please disregard all this and just
do it, if you can't stand my detail at the moment!
everything should fit on one page, no scrolling
Th
A.J.Mechelynck wrote:
Wouldn't it be enough to set up the main tip page with a
tip _name_ (which would be the current "title" of the tip, or
a disambiguation page if there are more than one tip with the
same title), and have the tip _number_ (only for tips imported
from Vim-online) refer to a red
It is important for us to have an easy way to refer to tips,
and the URL of each tip should be simple (and not wrap in an
email).
Below is some detail for a proposal to achieve this.
What does everyone think?
Have a script scrape tip titles from the current Vim Tips.
Create a plain text file wit
Martin Krischik wrote:
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.
I see what you mean. If that were to happen with the Vim wiki
then it would be really ugly (i.e. if junk comments were left
inde
Martin Krischik wrote:
But do we need an id? - each tip will have a page name
which will be unique.
IMHO you are correct - we should NOT have a tip id.
I'm not sure what is feasible, but here is my ideal:
- Import current tip_nr into the template.
- Display tip_nr near the top of the tip, very
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 t
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 f
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
Thomas Michael Engelke wrote:
Assuming that fileformat "unix" means 0x10 means "open a new
line" which seems to be the case (0x13 stays as ^M, 0x10 is
interpreted as a new line), shouldn't this mean that in the
last line there is a line break missing?
It's not important here, but for the record
Bram Moolenaar wrote:
Announcing: Vim (Vi IMproved) version 7.1
Excellent - thanks.
Is someone going to post to a security list like full disclosure
that Vim 7.1 is available, and it overcomes a serious security
problem?
The issue has received a brief mention in relation to patches
for Vim 7
Tom Purl wrote:
Here's what I propose we do:
1. Finalize a tip formatting standard.
2. Use the best available script that supports this standard.
3. Update the best available script if necessary.
4. Revise the standard if necessary.
5. Convert a tips sample.
6. Review the sample and revise the sc
Tim Chase wrote:
C:\Temp> find /?
No patterns other than fixed text
Since Windows 2000, there is also the findstr command.
It is not as clever as grep, but it supports patterns and is
able to efficiently handle big files.
In Vim:
:helpgrep findstr
At Windows command prompt:
findstr /?
John
Tim Chase wrote:
Or even a quality :s command instead of a function:
:%s/.\{72}/&r/g
Thanks - I occasionally need to split a line into equal-length blocks
and your command is excellent. Your posts are very valuable.
However, for anyone trying this, 'r' should be '\r'.
:%s/.\{72}/&\r/g
John
A.J.Mechelynck wrote:
Moving the tip body to a wiki page and the comments to its talk page can
(IIUC) be automated. /Then/ the tip author (or maintainer, etc.) can
archive the talk page, remove empty comments (of the "great tip" kind),
refactor useful comments into the tip body, etc.
My feeli
Paul Irofti wrote:
Back-ups are better made on the server side. For mediawiki a regular
sqldump (maybe added in crontab) is all that is necessary.
Good. But can we actually do that? I thought we were planning
to use a system where we have no access to the server except
via a wiki interface.
Jo
A few fundamental decisions need to be made so the conversion script
can produce a result that minimises future effort.
How will tips be found? Can there be a contents page? If so, the
script should generate a suitable list, perhaps for hand-tweaking.
Currently, the URL of the sample tip has for
Brian McKee wrote:
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 th
Denis Perelyubskiy wrote:
why don't we discuss that here:
http://en.wikibooks.org/wiki/Talk:Learning_the_vi_editor/Vim/TipsSandbox/Tip_1:_the_super_star
:-)
You and I started talking on that discussion page. I just wanted to say
(to everyone) that now I think all comments would be better made h
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%.
Wikiboo
Brian McKee wrote:
Proof is in the pudding - wikipedia and wikibooks seem to prove
it _does_ work.
I imagine these sites work from the frantic effort of very large
numbers of contributors (much larger than we should expect).
Twenty-four hours per day, there is someone monitoring edits to
their
Tom Purl wrote:
Ok, so here's the proposed workflow:
...
Tom - thanks for spelling out the proposed workflow.
Studying the details is essential for evaluating the system.
OTOH I guess we could just go with something, and if it doesn't
work we would refactor!
If you post another workflow, how a
Bram Moolenaar wrote:
I think this puts too much burdon the volunteers that become an admin.
And it defeats the easy of use of a wiki.
I was suggesting that people who have a tip, or a change, would
email it to a Vim mailing list, where it would be massaged by the
community, then posted to the
I like the concept of using the Google wiki. In addition to the "Google
is Good" factor, there is the likelihood of very high reliability and zero
cost. Also, it seems appropriate due to Bram's work.
As has been pointed out, spam is a really big threat, and will get
worse (more automated) every y
Tom Purl wrote:
I just checked the Google Code site (http://code.google.com/hosting/),
and couldn't find a Vim or VimTips project. I'd try creating it, but I
feel like someone more "official" to the project should do so. I think
someone should do it before someone else takes the name (like some
Tom Purl wrote:
I just checked the Google Code site (http://code.google.com/hosting/),
and couldn't find a Vim or VimTips project. I'd try creating it, but I
feel like someone more "official" to the project should do so. I think
someone should do it before someone else takes the name (like some
Bram Moolenaar wrote:
Using the project name VimTips would be good.
Everyone here is used to the name "Vim Tips" so VimTips sounds good, but on
a wiki I suggest that the name should be just "Vim".
It seems logical to me that a Vim Tips wiki would start with a (brief) page
outlining what Vim
Andy Wokula wrote:
Currently there is much spam in recent comments:
http://vim.sourceforge.net/tips/recent_notes.php
Last time this was discussed I got the impression that there is a
feeling that if no one reads the spam, then it is not a problem.
But I think the situation is worse than that.
37 matches
Mail list logo
