Re: replace number with zero-packed number
Luke Vanderfluit wrote:
Hi. I have a csv file that contains a field with a number, say 98.
I need to zerofill the fields to be 6 digits.
So any field that is say 98, should become 98.
Is there an easy way to do this with search and replace?
Thanks.
Kind regards.
There are several ways to do it, depending in part on what exactly you want to
do. I haven't tested the following but I think they will work:
- To fill in only the number under the cursor: no search-replace needed, place
the Insert-mode cursor just before it and type in four zeros.
- To replace the number 98 (only) wherever it appears as a word (thus 98 but
not 498 or 987 or 89 or 0098):
:%s/\98\/98/g
- To replace the number 98 wherever it appears between non-digits (thus also
k98g or \x98 which the above wouldn't replace, but still not 0098 or x098):
:%s/\%(^\|[^[:digit:]]\)98\_[^[:digit:]]/98/g
- To fill-in all numbers to at least 6 digits:
:%s/\\d\{1,5}/=(0 . submatch(0))[-6:]/g
- To fill or truncate all numbers to exactly 6 digits (losing the millions if
there are any):
:%s/\\d\+\/=(0 . submatch(0))[-6:]/g
All this, assuming that existing numbers have no thousands separators and that
you don't want to add any.
See
:help :s
:help /\
:help /\
:help /\d
:help /multi
:help [:digit:]
:help sub-replace-expression
:help submatch()
:help expr-[:]
etc.
Best regards,
Tony.
--
Fortune's Real-Life Courtroom Quote #29:
THE JUDGE: Now, as we begin, I must ask you to banish all present
information and prejudice from your minds, if you have
any ...
Re: what feature is required to return to last editing position?
On 5/8/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: When opening a file in vim, the cursor will move to the last position when the file was saved. The feature is enabled by some autocommands in vimrc_example.vim, I copied the code into my .vimrc and use it in all platform. It really does work in my WindowsXP gvim, cygwin vim, MacOSX vim, and Ubuntu Dapper vim. Recently I installed Ubuntu Feisty and the feature seems to have gone (I installed vim-gnome version 7.0.135). Since I use the same .vimrc in all platform, it is unlikely to be the fault of my .vimrc script, the problem is I do not know how to debug vim script, and I don't know why that autocommand does not work. Any idea where is the problem, or any hint on how to find where the problem is? The simplest way to fix this is to add this line to your .vimrc: $VIMRUNTIME/vimrc_example.vim Another, more difficult method is documented under :help restore-cursor Yakov
Re: what feature is required to return to last editing position?
Yakov Lerner wrote: On 5/8/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: When opening a file in vim, the cursor will move to the last position when the file was saved. The simplest way to fix this is to add this line to your .vimrc: $VIMRUNTIME/vimrc_example.vim Another, more difficult method is documented under :help restore-cursor :help restore-position :) -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: what feature is required to return to last editing position?
[EMAIL PROTECTED] wrote: When opening a file in vim, the cursor will move to the last position when the file was saved. The feature is enabled by some autocommands in vimrc_example.vim, I copied the code into my .vimrc and use it in all platform. It really does work in my WindowsXP gvim, cygwin vim, MacOSX vim, and Ubuntu Dapper vim. Recently I installed Ubuntu Feisty and the feature seems to have gone (I installed vim-gnome version 7.0.135). Since I use the same .vimrc in all platform, it is unlikely to be the fault of my .vimrc script, the problem is I do not know how to debug vim script, and I don't know why that autocommand does not work. Any idea where is the problem, or any hint on how to find where the problem is? -- Sincerely, Pan, Shi Zhu. ext: 2606 IIUC, it requires both +autocmd and +viminfo -- IOW, at least a Normal version. Tiny or small (including the version of vim installed under the name vi by the RedHat package vim-minimal) won't have it. (Sorry, I don't know the Ubuntu package names.) Best regards, Tony. -- APL is a write-only language. I can write programs in APL, but I can't read any of them. -- Roy Keir
Re: what feature is required to return to last editing position?
Hello,
I'm also using vim with an Ubuntu Feisty. Here is what I have in my .vimrc:
Try to restore cursor position when reading a buffer
au BufReadPost * if line('\) | exe normal '\ | endif
It works quite well.
On 5/9/07, A.J.Mechelynck [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
When opening a file in vim, the cursor will move to the last position when
the file was saved.
The feature is enabled by some autocommands in vimrc_example.vim, I
copied the code into my .vimrc and use it in all platform.
It really does work in my WindowsXP gvim, cygwin vim, MacOSX vim, and
Ubuntu Dapper vim.
Recently I installed Ubuntu Feisty and the feature seems to have gone (I
installed vim-gnome version 7.0.135). Since I use the same .vimrc in all
platform, it is unlikely to be the fault of my .vimrc script, the problem
is I do not know how to debug vim script, and I don't know why that
autocommand does not work.
Any idea where is the problem, or any hint on how to find where the problem
is?
--
Sincerely, Pan, Shi Zhu. ext: 2606
IIUC, it requires both +autocmd and +viminfo -- IOW, at least a Normal
version. Tiny or small (including the version of vim installed under the
name vi by the RedHat package vim-minimal) won't have it. (Sorry, I don't
know the Ubuntu package names.)
Best regards,
Tony.
--
APL is a write-only language. I can write programs in APL, but I
can't read any of them.
-- Roy Keir
Re: what feature is required to return to last editing position?
François Ingelrest wrote:
Hello,
I'm also using vim with an Ubuntu Feisty. Here is what I have in my .vimrc:
Try to restore cursor position when reading a buffer
au BufReadPost * if line('\) | exe normal '\ | endif
It works quite well.
Yeah, that is almost the same as the code in the vimrc_example.vim. The latter
also guards against invalid remembered locations, and doesn't update the jumplist:
When editing a file, always jump to the last known cursor position.
Don't do it when the position is invalid or when inside an event handler
(happens when dropping a file on gvim).
autocmd BufReadPost *
\ if line('\) 0 line('\) = line($) |
\ exe normal! g`\ |
\ endif
So here's what /I/ have in my vimrc, and it works quite well:
runtime vimrc_example.vim
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
224. You set up your own Web page. You set up a Web page for each
of your kids... and your pets.
omni-completion
hi all! this will seem to be a dumb question. what is omni-completion? How can I use it in vim? How can I create my own? tnx in advance!
Re: omni-completion
On 2007-05-09, Normandie Azucena [EMAIL PROTECTED] wrote: hi all! this will seem to be a dumb question. what is omni-completion? How can I use it in vim? How can I create my own? :help compl-omni :help 24.3 HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: VimWiki - again - but with a brand new option
On Tue, May 8, 2007 3:32 pm, Bram Moolenaar wrote: The main goal now is to get the Vim tips collection back to live. It has been dead for three months now! I wasn't aware of this, and it's definitely a problem. Here's what I propose we do: 1. Finalize a tip formatting standard. 2. Use the best available script that supports this standard. 3. Update the best available script if necessary. 4. Revise the standard if necessary. 5. Convert a tips sample. 6. Review the sample and revise the script if necessary. Once we're done with all of that, we can revisit the question of which wiki we'll use and then convert all of the tips. Since this project is lagging, let's also use the following standards: 1. Let's use this mailing list to coordinate the project. All comments regarding wiki page format, however, should be written to the talk section of the affected wiki page. If you're unsure as to where to post your comment, then just post it to this mailing list. 2. Let's set a deadline for signing off of the wiki formatting standard of 5/21. 2. Let's set a deadline for determining the best conversion script of standard of 6/4. This is just a start, and I'm open to all opinions/criticism. I just want to give this project a shot in the arm so that we can resurrect one of the best features of the Vim editor. What do yo guys think? Perhaps we can figure out some clever way to also make the help files available with links between the tips and the help files. Thus in the help file you would see some link that takes you to a tip associated with the text at that position. But without that the tips are still very useful. -- From know your smileys: O:-) Saint /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org /// \\\help me help AIDS victims -- http://ICCF-Holland.org ///
Re: omni-completion
* Normandie Azucena [2007.05.09 09:30]: this will seem to be a dumb question. what is omni-completion? How can I use it in vim? How can I create my own? Have you given :h omni-completion a try? -- JR
Tab right-click menu hardcoded
The current right-click menu on GUI tabs is hardcoded and presents a whole host of issues for anyone who uses code to manage buffers, tabs, or windows. It pretends to be a sophisticated menu but it really executes a basic Vim command which may or may not be what the user expects. Could we at least change the menu item names to the exact command being executed barring the option to customize these? -- Steve Hall [ digitect dancingpaper com ]
Re: what feature is required to return to last editing position?
[EMAIL PROTECTED] wrote: When opening a file in vim, the cursor will move to the last position when the file was saved. The feature is enabled by some autocommands in vimrc_example.vim, I copied the code into my .vimrc and use it in all platform. It really does work in my WindowsXP gvim, cygwin vim, MacOSX vim, and Ubuntu Dapper vim. Recently I installed Ubuntu Feisty and the feature seems to have gone (I installed vim-gnome version 7.0.135). Since I use the same .vimrc in all platform, it is unlikely to be the fault of my .vimrc script, the problem is I do not know how to debug vim script, and I don't know why that autocommand does not work. Restore cursor to file position in previous editing session : http://vim.sourceforge.net/tips/tip.php?tip_id=80 The command therein will return your cursor to the same line and column that it was in previously. Regards, Chip Campbell
^M displayed in vi but not in vim
Hi all, Does anyone know why vim don't show the ^M characters in a file but vi does? :set list in vim shows $ at the end of the lines but no ^M characters? :set ff=unix :w This removed the ^M characters but I had to use vi to verify. Is there some setting I'm missing that needed to show the ^M characters in vim? Thanks in advance, Dan
$HOME inconsistent in Windows?
Hey All, I've defined a HOME environment variable as %HOMEDRIVE%%HOMEPATH%. In a command prompt, if get the following: echo %HOME% C:\Documents and Settings\user ID In gvim, I get the following: :e $HOME\ which expands to :e c:\Documents\ and\ Settings\user ID\Application\ Data\ Is there some reason why vim is ignoring the HOME variable I've set? What is interesting is that my _viminfo is being read from C:\Documents and Settings\user ID just fine. Chris -- Chris Sutcliffe http://ir0nh34d.googlepages.com http://ir0nh34d.blogspot.com http://emergedesktop.org
RE: replace number with zero-packed number
Could I ask a follow-up question along these lines?
I've never used \=, but I see it only works at the beginning of the substitute
string and makes the entire replacement an expression. Is there a way to put it
in the middle.
For example, I was thinking if the CSV file had other numbers, and only one
field should be 0 padded, ex:
Blah, 745, blah, 98, blah
Blah, 34, blah, 200, blah
And only the 4th field should be zero padded, you'd want something like this:
%s/\(\([^,]\+,\s*\)\{4\}\)\(\d\{1,6\}/\1\=someExprWith\2/g
That's an eyesore, maybe not the best regex, but it'd work if you could put the
expr in the middle of the replace string. Is this doable?
*tim*
-Original Message-
From: A.J.Mechelynck [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 09, 2007 4:15 AM
To: Luke Vanderfluit
Cc: vim@vim.org
Subject: Re: replace number with zero-packed number
Luke Vanderfluit wrote:
Hi. I have a csv file that contains a field with a number, say 98.
I need to zerofill the fields to be 6 digits.
So any field that is say 98, should become 98.
Is there an easy way to do this with search and replace?
Thanks.
Kind regards.
There are several ways to do it, depending in part on what exactly you want to
do. I haven't tested the following but I think they will work:
- To fill in only the number under the cursor: no search-replace needed, place
the Insert-mode cursor just before it and type in four zeros.
- To replace the number 98 (only) wherever it appears as a word (thus 98 but
not 498 or 987 or 89 or 0098):
:%s/\98\/98/g
- To replace the number 98 wherever it appears between non-digits (thus also
k98g or \x98 which the above wouldn't replace, but still not 0098 or x098):
:%s/\%(^\|[^[:digit:]]\)98\_[^[:digit:]]/98/g
- To fill-in all numbers to at least 6 digits:
:%s/\\d\{1,5}/=(0 . submatch(0))[-6:]/g
- To fill or truncate all numbers to exactly 6 digits (losing the millions if
there are any):
:%s/\\d\+\/=(0 . submatch(0))[-6:]/g
All this, assuming that existing numbers have no thousands separators and that
you don't want to add any.
See
:help :s
:help /\
:help /\
:help /\d
:help /multi
:help [:digit:]
:help sub-replace-expression
:help submatch()
:help expr-[:]
etc.
Best regards,
Tony.
--
Fortune's Real-Life Courtroom Quote #29:
THE JUDGE: Now, as we begin, I must ask you to banish all present
information and prejudice from your minds, if you have
any ...
Re: replace number with zero-packed number
I've never used \=, but I see it only works at the
beginning of the substitute string and makes the entire
replacement an expression. Is there a way to put it in the
middle.
For example, I was thinking if the CSV file had other
numbers, and only one field should be 0 padded, ex:
Blah, 745, blah, 98, blah
Blah, 34, blah, 200, blah
And only the 4th field should be zero padded, you'd want
something like this:
%s/\(\([^,]\+,\s*\)\{4\}\)\(\d\{1,6\}/\1\=someExprWith\2/g
That's an eyesore, maybe not the best regex, but it'd work
if you could put the expr in the middle of the replace
string. Is this doable?
There are a couple ways around this. You can reference
those tagged items as you describe:
%s/\(...\)regexp\(...\)/\=submatch(1).someExpr.submatch(2)/g
using the submatch() function to call in the parts you
referenced (in the expression, submatch(1) is the \1 you'd
refer to)
Another idea would be to employ the \zs and \ze markers
to specify where the beginning/end of the match are supposed
to be replaced:
%s/\(...\)\zsregexp\ze\(...\)/\=someExpr/g
This requires the context in the \(...\), but the replaced
match only spans from \zs through \ze which makes it
somewhat easier to read.
In your original regexp, there were an imbalance of \(...\)
tagging, so I'm not sure what exactly you were attempting
for, but it will choke unless you fix that.
You also have nested \(...\) groups which are ambiguous as
to which becomes which number in a replacement. A clearer
idea would be to use \%(...\) which is a non-tagging (it
doesn't get a \9 backreference number assigned to it) so you
could do something like
%s/^\(\%([^,]\+,\s*\)\{4}\)\(d\{1,6}\)/\=submatch(1).someExpr(submatch(2))
which would be similar to
%s/^\(\%([^,]\+,\s*\)\zs\{4}\)\(d\{1,6}\)/\=someExpr(submatch(2))
You can read up on these at
:help submatch()
:help /\zs
and before long, you'll be abusing them too. :)
Oh, and if you want the 4th field, your \{...} should capture
3 fields, not 4, or otherwise you'll change the 5th (not 4th)
field.
-tim
Re: ^M displayed in vi but not in vim
Dan Fabrizio wrote: Hi all, Does anyone know why vim don't show the ^M characters in a file but vi does? :set list in vim shows $ at the end of the lines but no ^M characters? :set ff=unix :w This removed the ^M characters but I had to use vi to verify. Is there some setting I'm missing that needed to show the ^M characters in vim? Thanks in advance, Dan :verbose set ff? ffs? If 'fileformats' (plural) includes dos, the fact that you don't see a ^M when lines end in CR+LF is not a bug, it's a feature (which is not present in Vi, and I mean the original Vi, not Vim running in 'compatible' mode). If 'fileformats' includes dos, the 'fileformat' (singular) will be set to dos for files with CR+LF ends-of-lines, and all lines will be written with CR+LF unless you tell Vim not to, by using e.g. setlocal ff=unix. See for details: :help 'fileformat' :help 'fileformats' :help file-format :help file-read :help DOS-format-write :help Unix-format-write :help Mac-format-write To check the ends-of-lines for a file loaded in a window: :setlocal fileformat? The answer can take three possible values: fileformat=dos The file contained CR+LF endings, and it will be written back using CR+LF endings. If 'fileformats' (plural) does not include unix, it is possible that the file included one or more lines with LF-only endings; they will be repaired to CR+LF when you save the file. fileformat=unix The file contains LF endings; any spurious CR's are shown as ^M fileformat=mac The file contains CR-only endings. Best regards, Tony. -- It would be nice if the Food and Drug Administration stopped issuing warnings about toxic substances and just gave me the names of one or two things still safe to eat. -- Robert Fuoss
Re: ^M displayed in vi but not in vim
On Wed, May 09, 2007 at 12:39:45PM -0400, Dan Fabrizio wrote:
Does anyone know why vim don't show the ^M characters in a file but vi does?
Vim understands all EOL types. All types included in
'fileformats' are equal, whatever characters they are
physically represented with.
:set list
in vim shows $ at the end of the lines but no ^M characters?
$ marks ends of lines, it does not stand for any particular
character. If lines are ended with CRLF, CR (^M) is simply
a part of end of line, it is not included in the text.
:set ff=unix
:w
This removed the ^M characters but I had to use vi to verify.
You can display the current EOL style ('fileformat') any
time:
:set ff
Is there some setting I'm missing that needed to show the ^M characters in
vim?
If you do not want to accept CRLF as end of line, do not
include `dos' in 'fileformats'. Then only the LF part
becomes end of line, CR will be included in the text. You
will see ^M displayed as you wish, however, semantically it
is not the same.
Yeti
--
http://gwyddion.net/
Re: $HOME inconsistent in Windows?
Chris Sutcliffe wrote: Hey All, I've defined a HOME environment variable as %HOMEDRIVE%%HOMEPATH%. In a command prompt, if get the following: echo %HOME% C:\Documents and Settings\user ID In gvim, I get the following: :e $HOME\ which expands to :e c:\Documents\ and\ Settings\user ID\Application\ Data\ Is there some reason why vim is ignoring the HOME variable I've set? What is interesting is that my _viminfo is being read from C:\Documents and Settings\user ID just fine. Chris Maybe you set it to something different? :view $HOMEDRIVE$HOMEPATH/_vimrc /$HOME :verbose set viminfo? Best regards, Tony. -- A team playing baseball in Dallas Called the umpire blind out of malice. While this worthy had fits The team made eight hits And a girl in the bleachers named Alice.
Re: Tab right-click menu hardcoded
Setting followups to vim-dev Steve Hall wrote: The current right-click menu on GUI tabs is hardcoded and presents a whole host of issues for anyone who uses code to manage buffers, tabs, or windows. It pretends to be a sophisticated menu but it really executes a basic Vim command which may or may not be what the user expects. Could we at least change the menu item names to the exact command being executed barring the option to customize these? When using text-style tabs (in the console, or if 'guioptions' does not include e), there is no tab context menu. When using GUI-style tabs (in the GUI, but only if 'guioptions' includes e) I see three menu items: Close (close clicked tab) New tab (open a new tab on a [No Name] buffer) Open tab... (open a new file in a new tab using a file selector: I presume :tab browse split or something like that) These titles seem to me to accurately describe the operations performed. Which titles would you prefer? The fact that the menu is hardcoded presents two problems: - it cannot be customized - it cannot be invoked via :emenu, e.g. in a mouseless console. Best regards, Tony. -- An effective way to deal with predators is to taste terrible.
Re: VimWiki - again - but with a brand new option
On Wed, May 9, 2007 11:37 am, Sebastian Menge wrote: First, im not sure about what you mean by a) formatting standard and b) a script that supports the standard is a) something like a template in mediawiki-speak? see: http://home.comcast.net/~gerisch/MediaWikiTemplates.html http://www.mediawiki.org/wiki/Help:Templates By formatting standard, I mean that we need to agree on how we want the tips to look once they're converted and posted to the wiki. Basically, what do we want the tips to look like so we can tweak the conversion script (if necessary). is b) something that reads the tips-db on vim.org and posts it to the wiki? Here, I'm referring to the script that will convert the scripts from their current format to their future, wiki-fied format. We already have 3 or 4 scripts that could do this. Everything else is agreed and appreciated :-) Thanks! Seb. PS: When writing this mail I got my hands dirty on the scratchpad of wikia.com: http://scratchpad.wikia.com/wiki/VimTest http://scratchpad.wikia.com/wiki/Template:Tip PPS: There are extensions for mediawiki that could be useful: To supply a HTML-Form to submit a tip: http://meta.wikimedia.org/wiki/Help:Inputbox To order a list of pages by popularity http://semeb.com/dpldemo/index.php/Manual Both are installed on wikia.org We do have a Wikia site available if we want it (http://vim.wikia.com/wiki/Main_Page). I agree with you; it has a lot of nice features, and may give us a bit more flexibility than the wikibooks option. I think we should revisit this topic once we're ready to start the real conversion.
is there a list-administrator ?
Is there a list-administrator also listening in ? I have tried to unsubscribe a zillion times now and I'm still on this list. I would appreciate if the ml-admin could help me out here. thanks toon
Re: Could you please give me the most bleeding-edge sources?
Edward L Fox wrote: I noticed that you also maintained another CVS repository besides the sf.net's CVS repository. And many changes to that internal CVS won't be applied to the sf.net's CVS repository unless a large release is to be made. In my opinion, as the SVN repository is now standardized, could you please give me the most bleeding-edge sources so that I can commit them into the trunk/ directory of the SVN repository, and some users who wish to use the unstable experimental version then can help you to test the code. I don't know what you are talking about. The most recent version is the distributed archives plus the patches plus updated runtime files. In CVS is that minus runtime file updates. There are a few changes on my local harddisk, but they are not in a patch yet for good reasons. -- From know your smileys: =):-) Uncle Sam /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
RE: is there a list-administrator ?
-Original Message- From: Toon Knapen [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 09, 2007 1:11 PM To: vim@vim.org Subject: is there a list-administrator ? Is there a list-administrator also listening in ? I have tried to unsubscribe a zillion times now and I'm still on this list. I would appreciate if the ml-admin could help me out here. thanks toon I'm not a list-admin, but did you try sending a message to [EMAIL PROTECTED] Mike
Re: is there a list-administrator ?
I'm not a list-admin, but did you try sending a message to [EMAIL PROTECTED] From the account with which you subscribed? (just to make sure) It should be the same one with which you posted to the list, as the list shouldn't let you post if you're not subscribed. -tim
RE: VimWiki - again - but with a brand new option
We do have a Wikia site available if we want it (http://vim.wikia.com/wiki/Main_Page). I agree with you; it has a lot of nice features, and may give us a bit more flexibility than the wikibooks option. I think we should revisit this topic once we're ready to start the real conversion. No offense intended to any of the involved parties, but I just want to point out that I've seen great ideas suffer death by committee. Someone becomes a cheerleader trying to get a lot of others involved, nothing happens, then the idea just languishes and eventually dies. What I found myself doing in the past was to just *do* something, then unveil it to the others involved. One place where I worked, my 2 biggest contributions which had *the* highest impact on the company in general, I had to quite literally wait for him to be out sick one day so I could disregard what he was telling me (ie, refusing to give me permission to work on what he even acknowledged was a good idea, saying, Yeah, it's a good idea, but there are more important things I have for you to do...), just so I could get started on the proof-of-concept version of what I was proposing, then thankfully he was out sick for *another* day so I could polish it somewhat and put some finishing touches on it. Once I already *did* it, the idea took hold, and other departments also started to use it. Now, I have zero idea just how much work is involved in making a wiki, but if it's enough for one person to do... hey, have at it. Otherwise, if you end up waiting for a consensus as to which wiki software to use, which site to use, /ad nauseam/, it's likely not going to get done. At least that's been my experience, which is why I, to quote the old saw, find it easier to ask forgiveness than permission.
Re: is there a list-administrator ?
Toon Knapen wrote: Is there a list-administrator also listening in ? I have tried to unsubscribe a zillion times now and I'm still on this list. I would appreciate if the ml-admin could help me out here. Somewhat modified version of what Tony M sent awhile ago... Unsubscribing from the vim or vim-dev list requires the following steps: 1. Send an email to the list you want off of: [EMAIL PROTECTED] -and/or- [EMAIL PROTECTED] That email does not need any body text, but its From: line must contain your subscribed address. The From: line *must* be the same as the one from which you subscribed and are receiving list mail! 2. Wait (usually a few seconds, sometimes a few minutes, depending on how often you fetch mail from your server) for a robot autoreply to the message you sent at step 1. 3. The robot autoreply (step 2) is there to check that the message (step 1) was really from you! It will contain instructions on how to complete the unsubscription. 4. Do what the autoreply says: this usually means sending an email to an address containing a complicated pseudorandom key, and acts as verification that its really you that wants to unsubscribe, not some prankster. 5. Shortly after you complete step 4, the list mail for this list should stop coming in.
Re: VimWiki - again - but with a brand new option
Am Mittwoch, den 09.05.2007, 13:06 -0500 schrieb Tom Purl: We do have a Wikia site available if we want it (http://vim.wikia.com/wiki/Main_Page). I agree with you; it has a lot of nice features, and may give us a bit more flexibility than the wikibooks option. I think we should revisit this topic once we're ready The features are mostly the same. In fact all major extensions are installed on wikibooks too. On any mediawiki try out the page Special:Version to see all installed extensions: http://wikibooks.org/wiki/Special:Version Note the modules SpamBlacklist, UsernameBlacklist and ConfirmEdit (Captcha) Wikia.com is clearly aimed at making money with ads. Therefore I now vote for wikibooks.org. :-) Sebastian.
Re: is there a list-administrator ?
Toon Knapen wrote: Is there a list-administrator also listening in ? I have tried to unsubscribe a zillion times now and I'm still on this list. I would appreciate if the ml-admin could help me out here. thanks toon AFAIK, there is no list-admin; just the mail robot. Or if there is one, he only reads the list when the moon is blue on the 4th Thursday of a week, and I don't know his phone number (if any). Let's recap the steps. 1. Send an email to [EMAIL PROTECTED] . The body and Subject can be anything (even empty) but the From MUST be your email-address-of-record. I suppose the latter is [EMAIL PROTECTED] but you should be able to check it by looking at the source of any list post you got (using Ctrl-U in Thunderbird) and checking the topmost Received line (including the indented lines that are logically part of it) for a string like for [EMAIL PROTECTED]. -- Warning: you will probably receive the present email twice: once directly and once via the list. The list post is the one whose Received-lines (not necessarily the topmost one) mention foobar.math.fu-berlin.de. 2. That email (sent at step 1) will trigger an autoreply. You MUST receive and read that autoreply, not delete it unread: IT IS NOT SPAM. The autoreply will tell you how to complete the unsubscription process, and it will include a secret code to make sure that the email at (1) wasn't sent by someone else to unsubscribe you against your will. (Spoofing from-lines is very easy.) 3. After you do whatever the autoreply tells you, the list mail should soon stop. Best regards, Tony. -- Remember: Silly is a state of Mind, Stupid is a way of Life. -- Dave Butler
Re: is there a list-administrator ?
Charles E Campbell Jr wrote: Toon Knapen wrote: Is there a list-administrator also listening in ? I have tried to unsubscribe a zillion times now and I'm still on this list. I would appreciate if the ml-admin could help me out here. Somewhat modified version of what Tony M sent awhile ago... Unsubscribing from the vim or vim-dev list requires the following steps: 1. Send an email to the list you want off of: [EMAIL PROTECTED] -and/or- [EMAIL PROTECTED] That email does not need any body text, but its From: line must contain your subscribed address. The From: line *must* be the same as the one from which you subscribed and are receiving list mail! 2. Wait (usually a few seconds, sometimes a few minutes, depending on how often you fetch mail from your server) for a robot autoreply to the message you sent at step 1. 3. The robot autoreply (step 2) is there to check that the message (step 1) was really from you! It will contain instructions on how to complete the unsubscription. 4. Do what the autoreply says: this usually means sending an email to an address containing a complicated pseudorandom key, and acts as verification that its really you that wants to unsubscribe, not some prankster. 5. Shortly after you complete step 4, the list mail for this list should stop coming in. Congrats, Dr. Chip! You put it more clearly than I could. Best regards, Tony. -- A widow who fancied a man some Was diddled three times in a hansome. When she clamored for more Her young man became sore And exclaimed My name's Simpson not Samson.
Re: is there a list-administrator ?
A.J.Mechelynck wrote: AFAIK, there is no list-admin; just the mail robot. Or if there is one, he only reads the list when the moon is blue on the 4th Thursday of a week, and I don't know his phone number (if any). The Vim mailing list page (http://www.vim.org/maillist.php) mentions [EMAIL PROTECTED], but moon is blue on the 4th Thursday of a week might still apply... -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: VimWiki - again - but with a brand new option
Original Message Subject: RE: VimWiki - again - but with a brand new option From: Gene Kwiecinski [EMAIL PROTECTED] Date: Wed, May 09, 2007 1:35 pm To: Tom Purl [EMAIL PROTECTED], Vim Mailing List vim@vim.org [snip] Yeah, it's a good idea, but there are more important things I have for you to do...), [snip] Wow, you had one of those guys too? We just barely got rid of ours a few weeks ago. He moved on to greater opportunities. Bright guy, but to follow his lead, you'd just never get to do anything!
RE: VimWiki - again - but with a brand new option
Yeah, it's a good idea, but there are more important things I have for you to do...), Wow, you had one of those guys too? We just barely got rid of ours a few weeks ago. He moved on to greater opportunities. Bright guy, but to follow his lead, you'd just never get to do anything! Thankfully, I'm long out of there, so I don't have to put up with much of that. But yeah, his famous explanation is that I was down there holding hand just slightly off the desk busy doing things that to me seemed important, but he was up here holding hand significantly higher, presumably because he was more in-tune with the Master Plan(tm) of what the company needed to get done. The only difference was that doing things His Way(tm), I was still taking care of the minutiae that I was *already* doing, only having to wait for his permission to do so. Just like the infamous Dilbert car2n where Pointy-Haired Boss gives him an assignment, he goes ticka-ticka-ticka on his keyboard while PHB is prattling on about something, then says Done!, that's pretty much what I was doing there. Going Through Channels(tm), my friend there would write up the fix-request, give it to her boss, who'd sit on it a few days, then forward it to my grandboss, who'd then give it to my boss, who'd then give it to me... typically a week or more after it was first written-up. And usually, I got the heads-up and just did the fix directly, actually implementing the fix, testing it, etc., well before I'd even see the paperwork. That was the more efficient way of *not* Going Through Channels(tm). And of course, when GTCing, some things would be held up in paperwork so long, that by the time I'd see it, it would have to be done, like *that* *day*. Feh. Anyhoo, sorry for the tirade, but back to the wiki, sometimes the only way to get one done at all is to just do it yourself, screw anyone else's opinions beforehand, then unveil it at the end. Use it, or not, your choice... If it ends up with too much spam, or is an ugly format, or the site itself is unreliable, okay, *then* let the critics have at it and try to do one better. Difference is, *you've* got one, and *they* don't, so by default you had that much more to show for it. Just my 2c...
Re: [Announcement] Subversion repository location changed
On 5/9/07, Edward L. Fox [EMAIL PROTECTED] wrote: If you had checked out a copy of the sources before, please run this command in your source root directory to switch into the current branch: svn switch https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 This switch command gives me error: $ cd vim7 $ svn info Path: . URL: https://svn.sourceforge.net/svnroot/vim/vim7 Repository Root: https://svn.sourceforge.net/svnroot/vim Repository UUID: 2a77ed30-b011-0410-a7ad-c7884a0aa172 Revision: 263 Node Kind: directory Schedule: normal Last Changed Author: edyfox Last Changed Rev: 263 Last Changed Date: 2007-05-06 23:13:56 -0400 (Sun, 06 May 2007) $ svn switch https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 svn: 'https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1' is not the same repository as 'https://svn.sourceforge.net/svnroot/vim' What am I doign wrong ? Yakov
Re: [Announcement] Subversion repository location changed
Yakov Lerner wrote: On 5/9/07, Edward L. Fox [EMAIL PROTECTED] wrote: If you had checked out a copy of the sources before, please run this command in your source root directory to switch into the current branch: svn switch https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 This switch command gives me error: $ cd vim7 $ svn info Path: . URL: https://svn.sourceforge.net/svnroot/vim/vim7 Repository Root: https://svn.sourceforge.net/svnroot/vim Repository UUID: 2a77ed30-b011-0410-a7ad-c7884a0aa172 Revision: 263 Node Kind: directory Schedule: normal Last Changed Author: edyfox Last Changed Rev: 263 Last Changed Date: 2007-05-06 23:13:56 -0400 (Sun, 06 May 2007) $ svn switch https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 svn: 'https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1' is not the same repository as 'https://svn.sourceforge.net/svnroot/vim' What am I doign wrong ? Yakov The vim.svn vs svn... . https://svn.sourceforge.net/svnroot/vim/branches/vim7.1 (no vim) works for me. I've a question, though: isn't bleeding-edge development done in https://svn.sourceforge.net/svnroot/vim/trunk ? That /would/ be the appropriate line for the latest sources, right? -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: VimWiki - again - but with a brand new option
Ian Tegebo wrote: On 5/6/07, Sebastian Menge [EMAIL PROTECTED] wrote: Hi all Independent of the implementation used, I suggest to develop good guidelines. The Wiki should be really valuable and not redundant to vim-tips or mailing-lists. I would like to make another implementation independent suggestion; one could make a VimWiki more valuable by importing the _extremely_ valuable vim helpfiles into it. Please don't do this. It might sound like a nice idea, but it means making a branch that will be very hard to merge back into the help files of the distribution. I feel misunderstood but it serves me right for not saying what I mean... Synchronizing data is no fun, I agree. While I was up in the clouds I was imaging that the wiki would be the authoritative source for the helpfiles after doing an initial _import_. Then the text version would be exported as needed, e.g. end user runtime update or for a new release. That's the problem: It's very easy to change the text in the wiki in such a way it won't be possible to put back in the distribution. Also, I need to check every change, at least briefly (depend on where the change comes from). That is the only way to maintain the quality. Thus I would need a list of changes, preferably in the form of a patch. When people change the wiki in various ways this will quickly become a nightmare. Taking the existing help files and _adding_ to them is good. Especially if corrections and additions are marked somehow, so that they eventually end up in the distribution. Otherwise links to tips can be added. I'm currently working on the 7.1 release and then will go travelling, thus I won't have much time to discuss the tips wiki. I certainly encourage everybody to make it work. After all, a wiki is a collaborative work! -- From know your smileys: 2B|^2B Message from Shakespeare /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: VimWiki - again - but with a brand new option
On Wed, 2007-05-09 at 13:06 -0500, Tom Purl wrote: On Wed, May 9, 2007 11:37 am, Sebastian Menge wrote: First, im not sure about what you mean by a) formatting standard and b) a script that supports the standard is a) something like a template in mediawiki-speak? see: http://home.comcast.net/~gerisch/MediaWikiTemplates.html http://www.mediawiki.org/wiki/Help:Templates By formatting standard, I mean that we need to agree on how we want the tips to look once they're converted and posted to the wiki. Basically, what do we want the tips to look like so we can tweak the conversion script (if necessary). Put me down as voting for 'simplistic'. ie no fancy boxes/backgrounds just bold headings and maybe a splash of Vim green somewhere. (Man pages come to mind) is b) something that reads the tips-db on vim.org and posts it to the wiki? Here, I'm referring to the script that will convert the scripts from their current format to their future, wiki-fied format. We already have 3 or 4 scripts that could do this. Everything else is agreed and appreciated :-) Thanks! Seb. PS: When writing this mail I got my hands dirty on the scratchpad of wikia.com: http://scratchpad.wikia.com/wiki/VimTest http://scratchpad.wikia.com/wiki/Template:Tip PPS: There are extensions for mediawiki that could be useful: To supply a HTML-Form to submit a tip: http://meta.wikimedia.org/wiki/Help:Inputbox To order a list of pages by popularity http://semeb.com/dpldemo/index.php/Manual Both are installed on wikia.org We do have a Wikia site available if we want it (http://vim.wikia.com/wiki/Main_Page). I agree with you; it has a lot of nice features, and may give us a bit more flexibility than the wikibooks option. I think we should revisit this topic once we're ready to start the real conversion. cheers, -- Mark
Re: Tab right-click menu hardcoded
On Wed, 2007-05-09 at 20:04 +0200, A.J.Mechelynck wrote: Steve Hall wrote: The current right-click menu on GUI tabs is hardcodedCould we at least change the menu item names to the exact command being executed barring the option to customize these? When using GUI-style tabs (in the GUI, but only if 'guioptions' includes e) I see three menu items: Close New tab Open tab... These titles seem to me to accurately describe the operations performed. Which titles would you prefer? Exactly what command is being used would be better I think, for example instead of Close: :close ZZ :tabclose :tabclose! The user isn't really sure what it does so it's a risk to use it. The fact that the menu is hardcoded presents two problems: - it cannot be customized - it cannot be invoked via :emenu, e.g. in a mouseless console. I'm more interested in the first--doesn't the current monolithicity(?!) seem so un-Vim-like? -- Steve Hall [ digitect dancingpaper com ]
[Fwd: Re: $HOME inconsistent in Windows?]
Forward to list
Original Message
Subject: Re: $HOME inconsistent in Windows?
Date: Wed, 9 May 2007 20:22:53 -0400
From: Chris Sutcliffe [EMAIL PROTECTED]
To: A.J.Mechelynck [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
[EMAIL PROTECTED]
Maybe you set it to something different?
:view $HOMEDRIVE$HOMEPATH/_vimrc
/$HOME
There is nothing there because I use a global vimrc. I can't find
HOME defined anywhere in my vim71a files:
C:\Program Files\Vim\vim71afindstr /s /n $HOME *.vim
autoload\getscript.vim:81: if exists('$HOME')
isdirectory(expand($HOME)./.s:dotvim)
autoload\getscript.vim:82: let s:autoinstall= $HOME./.s:dotvim
autoload\netrw.vim:1425:if s:FileReadable(expand($HOME/.netrc))
!g:netrw_ignorenetrc
autoload\netrw.vim:1463: elseif s:FileReadable(expand($HOME/.netrc))
autoload\netrw.vim:4494: let dirname= substitute(a:1,'\~',expand($HOME),'')
ftplugin\man.vim:139: silent exec edit $HOME/.page...sect.~
ftplugin\ruby.vim:177: 2. Copy matchit.txt into a doc directory
(e.g. $HOME/.vim/doc).
ftplugin\ruby.vim:179: 3. Copy matchit.vim into a plugin
directory (e.g. $HOME/.vim/plugin).
ftplugin\ruby.vim:183: 5. Ensure you have this line in your $HOME/.vimrc:
menu.vim:186:if $HOME != ''
menu.vim:187: let fname = $HOME/_vimrc
menu.vim:194:let fname = $HOME/.vimrc
syntax\groovy.vim:22: 1) copy the file in the (global or user's
$HOME/.vim/syntax/) syntax folder
syntax\groovy.vim:27: in the global vim filetype.vim file or inside
$HOME/.vim/filetype.vim
syntax\groovy.vim:38: in the global scripts.vim file or in
$HOME/.vim/scripts.vim
:verbose set viminfo?
Last set from C:\Program Files\Vim\vim71a\vimrc_example.vim
Doing a :vimgrep $HOME I found the following in todo.txt (under MSDOS,
OS/2, and Win32):
8 Should $USERPROFILE be preferred above $HOMEDRIVE/$HOMEPATH? No, but it's
a good fallback, thus use:
$HOME
$HOMEDRIVE$HOMEPATH
SHGetSpecialFolderPath(NULL, lpzsPath, CSIDL_APPDATA, FALSE);
$USERPROFILE
SHGetSpecialFolderPath(NULL, lpzsPath, CSIDL_COMMON_APPDATA, FALSE);
$ALLUSERSPROFILE
$SYSTEMDRIVE\
C:\
In general it looks like odd things are occurring when expanding
system variables, APPDATA is being used all the time when expanding
$HOME, $HOMEDRIVE$HOMEPATH or $USERPROFILE. COMMON_APPDATA is being
used when expanding $ALLUSERSPROFILE. $SystemDrive is expanding to
C:Makefile.
FWIW, I'm using 7.1a.1 compiled with MinGW.
Chris
--
Chris Sutcliffe
http://ir0nh34d.googlepages.com
http://ir0nh34d.blogspot.com
http://emergedesktop.org
Re: [Fwd: Re: $HOME inconsistent in Windows?]
Forward to list Sorry, forgot to check the To field in the reply... Cheers! Chris -- Chris Sutcliffe http://ir0nh34d.googlepages.com http://ir0nh34d.blogspot.com http://emergedesktop.org
Re: [Fwd: Re: $HOME inconsistent in Windows?]
Chris Sutcliffe wrote: Forward to list Sorry, forgot to check the To field in the reply... Cheers! Chris Next time, use Reply to All (or Reply to List if your mailer offers it). Best regards, Tony. -- George Orwell 1984. Northwestern 0. -- Chicago Reader 10/15/82
Re: what feature is required to return to last editing position?
Vincent BEFFARA [EMAIL PROTECTED] 写于 2007-05-09 23:54:27: Hi, Recently I installed Ubuntu Feisty and the feature seems to have gone (I installed vim-gnome version 7.0.135). Since I use the same .vimrc in all platform, it is unlikely to be the fault of my .vimrc script, the problem is I do not know how to debug vim script, and I don't know why that autocommand does not work. Just in case - might it be that you don't have right permissions to your own ~/.viminfo ? I had a similar problem : on a new install, typically you might go and edit some files using sudo vim /etc/whatever, this creates .viminfo belonging to root, and then vim as a normal user cannot use it, and fails silently. Only happens if there is no .viminfo to start with, vim does the sane thing and does not overwrite, but still might be considered a bug ... hth, /vincent -- Vincent Beffara Wonderful, the problem really is about permission of .viminfo! I noticed that you considered this to be a bug, but is this bug belongs to sudo or vim? i.e. for non-interactive su of root, vim will save at user $HOME with root permission. -- Sincerely, Pan, Shi Zhu. ext: 2606
Blocking of save
Hi, is there a way to disabling the saveing and writing of/to a file and leaving of vim until a certain condition of the contents of the file is not given (in this case certain characters are not allowed as contents of the file)? The whole thing should only be active for a C-/C++-Files. Thanks a lot for any help in advance! Keep editing! mcc -- Please don't send me any Word- or Powerpoint-Attachments unless it's absolutely neccessary. - Send simply Text. See http://www.gnu.org/philosophy/no-word-attachments.html In a world without fences and walls nobody needs gates and windows.
Re: Blocking of save
[EMAIL PROTECTED] wrote: Hi, is there a way to disabling the saveing and writing of/to a file and leaving of vim until a certain condition of the contents of the file is not given (in this case certain characters are not allowed as contents of the file)? The whole thing should only be active for a C-/C++-Files. Thanks a lot for any help in advance! Keep editing! mcc ~/.vim/after/ftplugin/c.vim (Unix) ~/vimfiles/after/ftplugin/c.vim (Windows) function s:CheckCFile() do something ... setting a variable (let's say l:FileOK) to true (1) or false (0) return FileOK endfunction augroup cfilecheck au BufWritePre *.c,*.h,*.cpp \ setlocal modified \ | let l:readonly = ! s:CheckCFile() augroup END This should give you the familiar error if you attempt to save a bad file or exit Vim without an exclamation mark after the command name (see :help abandon). Best regards, Tony. -- Excellent day for drinking heavily. Spike office water cooler.
Re: automatically enter normal mode
Hi all No one has mentioned the feedkeys() work-around (ahem, swallow) for this, if you want periodic events. For example, function! Timer() echo strftime(%c) let K_IGNORE = \x80\xFD\x35internal key code that is ignored call feedkeys(K_IGNORE) endfunction au CursorHold,CursorHoldI * :call Timer() turns vim into a clock. It doesn't work in visual, command, and operator pending mode. I use it as a tail -f viewer (replace the echo with checktime | normal G) for log files I want to have syntax highlighted, a practice I find really helpful. Regards, John Little
Re: Blocking of save
A.J.Mechelynck wrote: [EMAIL PROTECTED] wrote: Hi, is there a way to disabling the saveing and writing of/to a file and leaving of vim until a certain condition of the contents of the file is not given (in this case certain characters are not allowed as contents of the file)? The whole thing should only be active for a C-/C++-Files. Thanks a lot for any help in advance! Keep editing! mcc ~/.vim/after/ftplugin/c.vim (Unix) ~/vimfiles/after/ftplugin/c.vim (Windows) function s:CheckCFile() do something ... setting a variable (let's say l:FileOK) to true (1) or false (0) return FileOK endfunction augroup cfilecheck au BufWritePre *.c,*.h,*.cpp \ setlocal modified \ | let l:readonly = ! s:CheckCFile() augroup END This should give you the familiar error if you attempt to save a bad file or exit Vim without an exclamation mark after the command name (see :help abandon). Best regards, Tony. Oops! no, it should be global. Place it in your vimrc instead. Best regards, Tony. -- Ask five economists and you'll get five different explanations (six if one went to Harvard). -- Edgar R. Fiedler
Re: automatically enter normal mode
John Little wrote: Hi all No one has mentioned the feedkeys() work-around (ahem, swallow) for this, if you want periodic events. For example, function! Timer() echo strftime(%c) let K_IGNORE = \x80\xFD\x35internal key code that is ignored call feedkeys(K_IGNORE) endfunction au CursorHold,CursorHoldI * :call Timer() turns vim into a clock. It doesn't work in visual, command, and operator pending mode. I use it as a tail -f viewer (replace the echo with checktime | normal G) for log files I want to have syntax highlighted, a practice I find really helpful. Regards, John Little If it works, it also turns the CursorHold[I] events frome one-shot timers to repeat clocks, so invoke the function (replacing the :echo by nothing) then trigger anything that must be called repeatedly from _another_ CursorHold,CursorHoldI autocommand (which may be defined in a different script). If this timer autocommand is defined in its own augroup (let's say timerrepeat) you can turn it off easily: :au! timerrepeat. Warning: It is possible that some plugins expect the CursorHold[I] events to fire only once in periods of inactivity of any duration. Best regards, Tony. -- Said a horny young girl from Milpitas, My favorite sport is coitus. But a fullback from State Made her period late, And now she has athlete's fetus
Re: what feature is required to return to last editing position?
[EMAIL PROTECTED] wrote: Vincent BEFFARA [EMAIL PROTECTED] 写于 2007-05-09 23:54:27: Hi, Recently I installed Ubuntu Feisty and the feature seems to have gone (I installed vim-gnome version 7.0.135). Since I use the same .vimrc in all platform, it is unlikely to be the fault of my .vimrc script, the problem is I do not know how to debug vim script, and I don't know why that autocommand does not work. Just in case - might it be that you don't have right permissions to your own ~/.viminfo ? I had a similar problem : on a new install, typically you might go and edit some files using sudo vim /etc/whatever, this creates .viminfo belonging to root, and then vim as a normal user cannot use it, and fails silently. Only happens if there is no .viminfo to start with, vim does the sane thing and does not overwrite, but still might be considered a bug ... hth, /vincent -- Vincent Beffara Wonderful, the problem really is about permission of .viminfo! I noticed that you considered this to be a bug, but is this bug belongs to sudo or vim? i.e. for non-interactive su of root, vim will save at user $HOME with root permission. FYI, this same issue was discussed at https://bugs.launchpad.net/ubuntu/+bug/58002 -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: 7.1a.001 OSX colour scheme errors?
Michael Wookey wrote: A.J.Mechelynck wrote: Michael Wookey wrote: Hello vimmers, I am running 7.1a.001 on OSX and have just noticed the following from console vim (running in Terminal.app and also occurs in iTerm.app). If I change the colour scheme I receive a lot of error output. For example: :colorscheme desert Results in: Error detected while processing /Applications/Vim.app/Contents/Resources/vim/runtime/colors/desert.vim: line 27: E254: Cannot allocate color khaki E254: Cannot allocate color slategrey line 36: E254: Cannot allocate color gold line 37: E254: Cannot allocate color tan ... Other colour schemes produce similar output. The error messages have only appeared for me in console vim on OSX (10.4.9 PPC). They have not appeared in the linux or win32 console vims of 7.1a.001. GVim's on each of the platforms (OSX, linux, Win32) have worked fine. My console vim is symlinked as follows: $ ls -l `which vim` lrwxr-xr-x 1 root wheel 40 Feb 28 14:33 /usr/bin/vim - /Applications/Vim.app/Contents/MacOS/Vim These errors did not occur before 7.1a.001 and occurs on builds from CVS and SVN. The errors still occur even with starting vim with: vim -u NONE Has anyone else noticed this? These color names should be used only in the GUI. In the desert colorscheme I have (v1.1, 2004/06/13 19:30:30) they are only present in guibg= and guifg= arguments to the :hi command, which is normal. If you want to debug that problem, you may want to vimgrep your sources for the highlight command, then inspect the source to see if (as it should) it does ignore guibg= guifg= and gui= when setting highlights in Console Vim. You may restrict yourself to the modules which were actually compiled for your configure options, as shown e.g. by the contents of the objects folder (src/objects or whatever). I think I've found it.. The OSX Vim is built with FEAT_GUI_MAC always defined. This in turn forces FEAT_GUI to be defined. This is from around lines 66-102 of src/vim.h. In src/syntax.c:do_highlight() there are checks for FEAT_GUI to be defined. Items like guifg and guibg etc are conditionally compiled to only take effect if FEAT_GUI is defined (which it is in the OSX case). The call chain eventually looks like: do_highlight() color_name2handle() gui_get_color()- E254: Cannot allocate color So because FEAT_GUI is always defined on OSX, vim gets these errors for console vim. I still don't quite understand why this is causing an error when it doesn't on linux. The console linux version reports: VIM - Vi IMproved 7.1a BETA (2007 May 5, compiled May 8 2007 00:27:42) Included patches: 1 Huge version with GTK2 GUI. Features included (+) or not (-): ... While the console OSX version reports: VIM - Vi IMproved 7.1a BETA (2007 May 5, compiled May 9 2007 11:33:38) MacOS X (unix) version Included patches: 1 Huge version with Carbon GUI. Features included (+) or not (-): ... So both have the GUI built in yet only the OSX version complains about the colour scheme being set. Hm... Maybe the console version checks the values of the guibg= guifg= settings even though it doesn't use them. Try dropping the attached file into your $VIMRUNTIME folder and see if it makes any difference. (See :help rgb.txt for an explanation of how Vim uses it. IIUC, on X11- and Windows-based systems, those colour names' RGB values can be obtained by querying the OS.) Best regards, Tony. -- All this wheeling and dealing around, why, it isn't for money, it's for fun. Money's just the way we keep score. ! $Xorg: rgb.txt,v 1.3 2000/08/17 19:54:00 cpqbld Exp $ 255 250 250 snow 248 248 255 ghost white 248 248 255 GhostWhite 245 245 245 white smoke 245 245 245 WhiteSmoke 220 220 220 gainsboro 255 250 240 floral white 255 250 240 FloralWhite 253 245 230 old lace 253 245 230 OldLace 250 240 230 linen 250 235 215 antique white 250 235 215 AntiqueWhite 255 239 213 papaya whip 255 239 213 PapayaWhip 255 235 205 blanched almond 255 235 205 BlanchedAlmond 255 228 196 bisque 255 218 185 peach puff 255 218 185 PeachPuff 255 222 173 navajo white 255 222 173 NavajoWhite 255 228 181 moccasin 255 248 220 cornsilk 255 255 240 ivory 255 250 205 lemon chiffon 255 250 205 LemonChiffon 255 245 238 seashell 240 255 240 honeydew 245 255 250 mint cream 245 255 250 MintCream 240 255 255 azure 240 248 255 alice blue 240 248 255 AliceBlue 230 230 250 lavender 255 240 245 lavender blush 255
(Doc RFE) rgb.txt
I had a devil of a time locating the rgb.txt file on my SuSE 10.2 distro. In order to alleviate the task of fellow users, I propose the attached patch to :help rgb.txt. Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 223. You set up a web-cam as your home's security system. *** ../vim71a/runtime/doc/gui_w32.txt Mon May 7 23:02:41 2007 --- runtime/doc/gui_w32.txt Wed May 9 09:15:34 2007 *** *** 1,4 ! *gui_w32.txt* For Vim version 7.1a. Last change: 2007 May 03 VIM REFERENCE MANUALby Bram Moolenaar --- 1,4 ! *gui_w32.txt* For Vim version 7.1a. Last change: 2007 May 09 VIM REFERENCE MANUALby Bram Moolenaar *** *** 332,339 spaces. You can get an rgb.txt file from any X11 distribution. It is located in a ! directory like /usr/X11R6/lib/X11/. For Vim it must be located in the ! $VIMRUNTIME directory. Thus the file can be found with $VIMRUNTIME/rgb.txt. == *gui-w32-dialogs* *dialog* --- 332,340 spaces. You can get an rgb.txt file from any X11 distribution. It is located in a ! directory like /usr/X11R6/lib/X11/ or /usr/share/X11/. For Vim it must ! be located in the $VIMRUNTIME directory. Thus the file can be found with ! $VIMRUNTIME/rgb.txt. == *gui-w32-dialogs* *dialog*
[SOLVED] RE: 7.1a.001 OSX colour scheme errors?
Hm... Maybe the console version checks the values of the guibg= guifg= settings even though it doesn't use them. Try dropping the attached file into your $VIMRUNTIME folder and see if it makes any difference. (See :help rgb.txt for an explanation of how Vim uses it. IIUC, on X11- and Windows-based systems, those colour names' RGB values can be obtained by querying the OS.) Ahh.. found it. 'make install' wasn't copying the 'rgb.txt' to $VIMRUNTIME. It seems that this is a bug because even on the linux machine, 'make install' doesn't copy rgb.txt either. However on the linux machine there are existing copies of rgb.txt in places like /etc/x11/rgb.txt (Ubuntu 7.04) which vim must have picked up which is why it works. I've never noticed this bug before since I always rsync the runtime after a build - which therefore places an rgb.txt into my $VIMRUNTIME. Because rsync is not suitable for the Vim 7.1a runtime, rgb.txt is missing from my $VIMRUNTIME hence the issue showed itself. I just did a build of 7.0.243 (svn#261) and it also fails with the inability to understand the colour scheme - because there is no rgb.txt copied to $VIMRUNTIME! So it looks like this might have been a long standing issue. Bram - can you change the Makefile to copy rgb.txt to $VIMRUNTIME for OSX builds? Thanks for the tip Tony!
Re: [SOLVED] RE: 7.1a.001 OSX colour scheme errors?
Michael Wookey wrote: Hm... Maybe the console version checks the values of the guibg= guifg= settings even though it doesn't use them. Try dropping the attached file into your $VIMRUNTIME folder and see if it makes any difference. (See :help rgb.txt for an explanation of how Vim uses it. IIUC, on X11- and Windows-based systems, those colour names' RGB values can be obtained by querying the OS.) Ahh.. found it. 'make install' wasn't copying the 'rgb.txt' to $VIMRUNTIME. It seems that this is a bug because even on the linux machine, 'make install' doesn't copy rgb.txt either. However on the linux machine there are existing copies of rgb.txt in places like /etc/x11/rgb.txt (Ubuntu 7.04) which vim must have picked up which is why it works. The help mentions /usr/X11R6/lib/X11/ ; I found mine in /usr/share/X11 (on SuSE 10.2)... Apparently there is no single fixed location for that file. I wonder what the rule is? Any app using colour names should be able to find it after all. I've never noticed this bug before since I always rsync the runtime after a build - which therefore places an rgb.txt into my $VIMRUNTIME. Because rsync is not suitable for the Vim 7.1a runtime, rgb.txt is missing from my $VIMRUNTIME hence the issue showed itself. I just did a build of 7.0.243 (svn#261) and it also fails with the inability to understand the colour scheme - because there is no rgb.txt copied to $VIMRUNTIME! So it looks like this might have been a long standing issue. Bram - can you change the Makefile to copy rgb.txt to $VIMRUNTIME for OSX builds? Thanks for the tip Tony! Best regards, Tony. -- ... Logically incoherent, semantically incomprehensible, and legally ... impeccable!
Re: vim_is_xterm() and screen
I wrote:
Therefore, there would seem to be no harm whatsoever in detecting screen
as an xterm-mouse-code-capable terminal, and sending the mouse-mode
sequence (xterm protocol, since AFAIK screen provides no way to detect
the underlying xterm version). If the underlying terminal claims to be
xterm or rxvt, then the user will automatically get the benefit of mouse
support without trouble; otherwise, screen will simply ignore the
sequence and no harm is done to other terminals (such as unrecognized
sequence-emitters, or DEC-mouse-only terminals).
Attached is a proposed patch that effects the change I'm requesting. I
would love to get some feedback/further discussion based on it. They say
code talks, and so here is my concrete expression. :)
--
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/
Index: os_unix.c
===
--- os_unix.c (revision 276)
+++ os_unix.c (working copy)
@@ -2034,6 +2034,21 @@
|| STRCMP(name, builtin_xterm) == 0);
}
+/*
+ * Return TRUE if name appears to be that of a terminal
+ * known to support the xterm-style mouse protocol.
+ * Relies on term_is_xterm having been set to its correct value.
+ */
+int
+vim_uses_xterm_mouse(name)
+char_u *name;
+{
+if (name == NULL)
+ return FALSE;
+return (STRNICMP(name, screen, 6) == 0
+ || term_is_xterm);
+}
+
#if defined(FEAT_MOUSE_TTY) || defined(PROTO)
/*
* Return non-zero when using an xterm mouse, according to 'ttymouse'.
Index: term.c
===
--- term.c (revision 276)
+++ term.c (working copy)
@@ -1601,6 +1601,9 @@
int try;
int termcap_cleared = FALSE;
#endif
+#if defined(UNIX) || defined(VMS)
+int term_uses_xterm_mouse;
+#endif
int width = 0, height = 0;
char_u *error_msg = NULL;
char_u *bs_p, *del_p;
@@ -1903,6 +1906,7 @@
#if defined(UNIX) || defined(VMS)
term_is_xterm = vim_is_xterm(term);
+term_uses_xterm_mouse = vim_uses_xterm_mouse(term);
#endif
#ifdef FEAT_MOUSE
@@ -1923,7 +1927,7 @@
#endif
clip_init(FALSE);
# endif
- if (term_is_xterm)
+ if (term_uses_xterm_mouse)
{
if (use_xterm_mouse())
p = NULL; /* keep existing value, might be xterm2 */
signature.asc
Description: OpenPGP digital signature
Re: (Doc RFE) rgb.txt
On Wed, May 09, 2007 at 09:25:09AM +0200, A.J.Mechelynck wrote: I had a devil of a time locating the rgb.txt file on my SuSE 10.2 distro. locate rgb.txt Or, if you don't have locate installed for some reason, find /usr -name rgb.txt In order to alleviate the task of fellow users, I propose the attached patch to :help rgb.txt. The file can be virtually anywehre, it is even in /etc/X11 on some systems. Yeti -- http://gwyddion.net/
RE: [SOLVED] RE: 7.1a.001 OSX colour scheme errors?
Michael Wookey wrote: Hm... Maybe the console version checks the values of the guibg= guifg= settings even though it doesn't use them. Try dropping the attached file into your $VIMRUNTIME folder and see if it makes any difference. (See :help rgb.txt for an explanation of how Vim uses it. IIUC, on X11- and Windows-based systems, those colour names' RGB values can be obtained by querying the OS.) Ahh.. found it. 'make install' wasn't copying the 'rgb.txt' to $VIMRUNTIME. It seems that this is a bug because even on the linux machine, 'make install' doesn't copy rgb.txt either. However on the linux machine there are existing copies of rgb.txt in places like /etc/x11/rgb.txt (Ubuntu 7.04) which vim must have picked up which is why it works. The help mentions /usr/X11R6/lib/X11/ ; I found mine in /usr/share/X11 (on SuSE 10.2)... Apparently there is no single fixed location for that file. I wonder what the rule is? Any app using colour names should be able to find it after all. On Ubuntu 7.04, the following are all symlinked to /etc/X11/rgb.txt /usr/share/X11/rgb.txt /usr/lib/X11/rgb.txt On OSX, there is no rgb.txt on the system at all unless X11 is installed (which it is not by default). This is why it may be a good thing to include rgb.txt for the OSX vim builds.
Re: vim_is_xterm() and screen
Micah Cowan wrote: I wrote: Therefore, there would seem to be no harm whatsoever in detecting screen as an xterm-mouse-code-capable terminal, and sending the mouse-mode sequence (xterm protocol, since AFAIK screen provides no way to detect the underlying xterm version). If the underlying terminal claims to be xterm or rxvt, then the user will automatically get the benefit of mouse support without trouble; otherwise, screen will simply ignore the sequence and no harm is done to other terminals (such as unrecognized sequence-emitters, or DEC-mouse-only terminals). Attached is a proposed patch that effects the change I'm requesting. I would love to get some feedback/further discussion based on it. They say code talks, and so here is my concrete expression. :) Shouldn't it rather use the 'ttymouse' option? IIUC, that option is supposed to be set to either xterm or xterm2 at startup if the terminal is known to support xterm mouse codes. This is done as a result of sending the t_RV code and receiving an answer for it, which happens after the first file has been loaded and all -c commands have been processed: probably just before or just after the VimEnter event. IOW, you cannot test them in your vimrc or even in a global plugin (they are sourced too early). At the VimEnter event might be late enough but I haven't tested it. Best regards, Tony. -- A billion here, a couple of billion there -- first thing you know it adds up to be real money. -- Senator Everett McKinley Dirksen
Re: vim_is_xterm() and screen
A.J.Mechelynck wrote: Micah Cowan wrote: Attached is a proposed patch that effects the change I'm requesting. I would love to get some feedback/further discussion based on it. They say code talks, and so here is my concrete expression. :) Shouldn't it rather use the 'ttymouse' option? It does. :) ...or rather, my code is what would be used to set ttymouse's default based on the detected terminal. IIUC, that option is supposed to be set to either xterm or xterm2 at startup if the terminal is known to support xterm mouse codes. My code is used at the spot where the value of the 'ttymouse' option is set automatically by setting the 'term' option: both at startup, and whenever the user sets it manually via :set term=. This is done as a result of sending the t_RV code and receiving an answer for it, which happens after the first file has been loaded and all -c commands have been processed: probably just before or just after the VimEnter event. IOW, you cannot test them in your vimrc or even in a global plugin (they are sourced too early). At the VimEnter event might be late enough but I haven't tested it What happens, to the best of my reading, is: 1. If the terminal is detected as supporting t_RV (which basically means that it has been detected as fully compatible), it issues that sequence and checks for a result. If it gets an expected response, it will set ttymouse appropriately. 2. Sometime later, but before the first file is loaded, etc, the term option is automatically set based on the TERM environment variable. The term option is a magic option which causes it to check a bunch of things, including whether xterm mouse support is enabled (at the point where I set the term_uses_xterm_mouse var). 3. If the tty is xterm-mouse capable (before patch, if it is a full xterm implementation), then it sets ttymouse to xterm: but only if ttymouse doesn't already contain a setting that works for the current terminal (thus, if t_RV is set and the xterm said it was xterm2-compliant, ttymouse will already have been set to xterm2). Screen is actually quite capable of understanding and transmitting xterm2 protocol, but it doesn't provide t_RV, and so has no way of telling vim whether it's on an xterm2-supporting xterm or not. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: vim_is_xterm() and screen
A.J.Mechelynck wrote: This is done as a result of sending the t_RV code and receiving an answer for it, which happens after the first file has been loaded and all -c commands have been processed: probably just before or just after the VimEnter event. IOW, you cannot test them in your vimrc or even in a global plugin (they are sourced too early). At the VimEnter event might be late enough but I haven't tested it. Sorry, I meant to address this more explicitly: I tested, and under xterm, .vimrc sees term=xterm, ttymouse=xterm (note that ttymouse later becomes xterm2). Same for screen (except ttymouse doesn't change later). So I was probably a little wrong about the order in which things take place. Regardless, the code change seems to be consistent with the current process. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: vim_is_xterm() and screen
Micah Cowan wrote: A.J.Mechelynck wrote: This is done as a result of sending the t_RV code and receiving an answer for it, which happens after the first file has been loaded and all -c commands have been processed: probably just before or just after the VimEnter event. IOW, you cannot test them in your vimrc or even in a global plugin (they are sourced too early). At the VimEnter event might be late enough but I haven't tested it. Sorry, I meant to address this more explicitly: I tested, and under xterm, .vimrc sees term=xterm, ttymouse=xterm (note that ttymouse later becomes xterm2). Same for screen (except ttymouse doesn't change later). And, of course, term=screen, rather than xterm. :) -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: [Announcement] Subversion repository location changed
On Wed, May 09, 2007 at 10:27:24AM +0800, Edward L. Fox wrote: On 5/9/07, Suresh Govindachar [EMAIL PROTECTED] wrote: Edward L. Fox announced: Hi Vimmers, The directories structure of the Subversion repository has been changed. Please use this command to checkout the latest sources: svn co https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 vim7 If you had checked out a copy of the sources before, please run this command in your source root directory to switch into the current branch: svn switch https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 Hope this change won't bother you too much. Shouldn't there be vim7.1a (the a'th candidate for 7.1) today, and eventually, when Bram releases version 7.1, vim7.1? So is the last argument to svn co correct? And isn't today's branch/trunk/whatever 7.1a rather than 7.1? 7.1, not 7.1a. Because as the alphabetical version changes so fast, personally I don't want to create too many branches for that. --Suresh That's what tags are for. Let's say you want to release 7.1b from the current 7.1 branch: svn copy -m Tagging 7.1b release https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 https://vim.svn.sourceforge.net/svnroot/vim/tags/vim7.1b Copies are very space-efficient in svn, which is why they are the mechanism for both branching and tagging. --Greg
Re: Patch: Recent visit folder selection in gtk2 filechooser
Jochen Baier wrote: hi, the attached patch will add a combobox to the gtk2 filechooser to easy switch between recent visit folder. (=folder you opened a file) maybe worth to add to gvim. screenshot: http://www.jochen-baier.de/vim_recent.jpg regards jochen patch is obsolete, gtk+ will include something similar in the future versions of the filechooser widget regards jochen
Re: surprised by beta
On Tuesday 08 May 2007 21:29, you wrote: On 5/8/07, scott [EMAIL PROTECTED] wrote: i was surpised by the fact that simply running 'svn update' bumped me up to 7.1a -- from previous posts i had thought there was something extra that had to be done to get the beta, like create a new 71a directory or something now i've got the beta i feel committed, and will commence chasing after the errors it spews from /usr/local/share/vim/vim71a/filetype.vim when i run it -- apparently the install created the 71a directory for me i am not asking any questions here, it's more like i'm warning those who may prefer to stay with a stable version Maybe you'll be surprised again today... Don't simply svn up. Take care~ oh don't worry -- i am definitely in wait til the dust settles mode and i'll be reading up on svn switch in the immediate future thank you edward sc
Re: VimWiki - again - but with a brand new option
On Tue, May 8, 2007 3:32 pm, Bram Moolenaar wrote: The main goal now is to get the Vim tips collection back to live. It has been dead for three months now! I wasn't aware of this, and it's definitely a problem. Here's what I propose we do: 1. Finalize a tip formatting standard. 2. Use the best available script that supports this standard. 3. Update the best available script if necessary. 4. Revise the standard if necessary. 5. Convert a tips sample. 6. Review the sample and revise the script if necessary. Once we're done with all of that, we can revisit the question of which wiki we'll use and then convert all of the tips. Since this project is lagging, let's also use the following standards: 1. Let's use this mailing list to coordinate the project. All comments regarding wiki page format, however, should be written to the talk section of the affected wiki page. If you're unsure as to where to post your comment, then just post it to this mailing list. 2. Let's set a deadline for signing off of the wiki formatting standard of 5/21. 2. Let's set a deadline for determining the best conversion script of standard of 6/4. This is just a start, and I'm open to all opinions/criticism. I just want to give this project a shot in the arm so that we can resurrect one of the best features of the Vim editor. What do yo guys think? Perhaps we can figure out some clever way to also make the help files available with links between the tips and the help files. Thus in the help file you would see some link that takes you to a tip associated with the text at that position. But without that the tips are still very useful. -- From know your smileys: O:-) Saint /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org /// \\\help me help AIDS victims -- http://ICCF-Holland.org ///
Re: VimWiki - again - but with a brand new option
Am Mittwoch, den 09.05.2007, 10:33 -0500 schrieb Tom Purl: I wasn't aware of this, and it's definitely a problem. Here's what I propose we do: First, im not sure about what you mean by a) formatting standard and b) a script that supports the standard is a) something like a template in mediawiki-speak? see: http://home.comcast.net/~gerisch/MediaWikiTemplates.html http://www.mediawiki.org/wiki/Help:Templates is b) something that reads the tips-db on vim.org and posts it to the wiki? Everything else is agreed and appreciated :-) Seb. PS: When writing this mail I got my hands dirty on the scratchpad of wikia.com: http://scratchpad.wikia.com/wiki/VimTest http://scratchpad.wikia.com/wiki/Template:Tip PPS: There are extensions for mediawiki that could be useful: To supply a HTML-Form to submit a tip: http://meta.wikimedia.org/wiki/Help:Inputbox To order a list of pages by popularity http://semeb.com/dpldemo/index.php/Manual Both are installed on wikia.org
[PATCH] vim_is_xterm() and screen
Sorry for the repost; but I realized I should've drawn more attention to
the message with the patch in it, both so other lurkers know the thread
now includes a proposed patch, and so that we know what message to go
back to if we want to refer to the code we're discussing.
I have made a slight adjustment to the patch, swapping the order of
STRICMP and term_is_xterm within vim_uses_xterm_mouse(). I was using
vim_is_xterm() instead of term_is_xterm at first, but afterwards
replaced it for efficiency, but left the order as it was.
--
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/
Index: os_unix.c
===
--- os_unix.c (revision 276)
+++ os_unix.c (working copy)
@@ -2034,6 +2034,21 @@
|| STRCMP(name, builtin_xterm) == 0);
}
+/*
+ * Return TRUE if name appears to be that of a terminal
+ * known to support the xterm-style mouse protocol.
+ * Relies on term_is_xterm having been set to its correct value.
+ */
+int
+vim_uses_xterm_mouse(name)
+char_u *name;
+{
+if (name == NULL)
+ return FALSE;
+return (term_is_xterm
+ || STRNICMP(name, screen, 6) == 0);
+}
+
#if defined(FEAT_MOUSE_TTY) || defined(PROTO)
/*
* Return non-zero when using an xterm mouse, according to 'ttymouse'.
Index: term.c
===
--- term.c (revision 276)
+++ term.c (working copy)
@@ -1601,6 +1601,9 @@
int try;
int termcap_cleared = FALSE;
#endif
+#if defined(UNIX) || defined(VMS)
+int term_uses_xterm_mouse;
+#endif
int width = 0, height = 0;
char_u *error_msg = NULL;
char_u *bs_p, *del_p;
@@ -1903,6 +1906,7 @@
#if defined(UNIX) || defined(VMS)
term_is_xterm = vim_is_xterm(term);
+term_uses_xterm_mouse = vim_uses_xterm_mouse(term);
#endif
#ifdef FEAT_MOUSE
@@ -1923,7 +1927,7 @@
#endif
clip_init(FALSE);
# endif
- if (term_is_xterm)
+ if (term_uses_xterm_mouse)
{
if (use_xterm_mouse())
p = NULL; /* keep existing value, might be xterm2 */
signature.asc
Description: PGP signature
signature.asc
Description: OpenPGP digital signature
Re: Tab right-click menu hardcoded
Setting followups to vim-dev Steve Hall wrote: The current right-click menu on GUI tabs is hardcoded and presents a whole host of issues for anyone who uses code to manage buffers, tabs, or windows. It pretends to be a sophisticated menu but it really executes a basic Vim command which may or may not be what the user expects. Could we at least change the menu item names to the exact command being executed barring the option to customize these? When using text-style tabs (in the console, or if 'guioptions' does not include e), there is no tab context menu. When using GUI-style tabs (in the GUI, but only if 'guioptions' includes e) I see three menu items: Close (close clicked tab) New tab (open a new tab on a [No Name] buffer) Open tab... (open a new file in a new tab using a file selector: I presume :tab browse split or something like that) These titles seem to me to accurately describe the operations performed. Which titles would you prefer? The fact that the menu is hardcoded presents two problems: - it cannot be customized - it cannot be invoked via :emenu, e.g. in a mouseless console. Best regards, Tony. -- An effective way to deal with predators is to taste terrible.
Re: VimWiki - again - but with a brand new option
On Wed, May 9, 2007 11:37 am, Sebastian Menge wrote: First, im not sure about what you mean by a) formatting standard and b) a script that supports the standard is a) something like a template in mediawiki-speak? see: http://home.comcast.net/~gerisch/MediaWikiTemplates.html http://www.mediawiki.org/wiki/Help:Templates By formatting standard, I mean that we need to agree on how we want the tips to look once they're converted and posted to the wiki. Basically, what do we want the tips to look like so we can tweak the conversion script (if necessary). is b) something that reads the tips-db on vim.org and posts it to the wiki? Here, I'm referring to the script that will convert the scripts from their current format to their future, wiki-fied format. We already have 3 or 4 scripts that could do this. Everything else is agreed and appreciated :-) Thanks! Seb. PS: When writing this mail I got my hands dirty on the scratchpad of wikia.com: http://scratchpad.wikia.com/wiki/VimTest http://scratchpad.wikia.com/wiki/Template:Tip PPS: There are extensions for mediawiki that could be useful: To supply a HTML-Form to submit a tip: http://meta.wikimedia.org/wiki/Help:Inputbox To order a list of pages by popularity http://semeb.com/dpldemo/index.php/Manual Both are installed on wikia.org We do have a Wikia site available if we want it (http://vim.wikia.com/wiki/Main_Page). I agree with you; it has a lot of nice features, and may give us a bit more flexibility than the wikibooks option. I think we should revisit this topic once we're ready to start the real conversion.
Re: (Doc bug) Error in options.txt
Tony Mechelynck wrote:
One word under :help 'ttymouse' was obviously forgotten when that
option got more possible settings. See suggested patch, attached.
To avoid it being forgotten again, I'll simply remove the count.
--
From know your smileys:
:-{} Too much lipstick
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: Could you please give me the most bleeding-edge sources?
Edward L Fox wrote: I noticed that you also maintained another CVS repository besides the sf.net's CVS repository. And many changes to that internal CVS won't be applied to the sf.net's CVS repository unless a large release is to be made. In my opinion, as the SVN repository is now standardized, could you please give me the most bleeding-edge sources so that I can commit them into the trunk/ directory of the SVN repository, and some users who wish to use the unstable experimental version then can help you to test the code. I don't know what you are talking about. The most recent version is the distributed archives plus the patches plus updated runtime files. In CVS is that minus runtime file updates. There are a few changes on my local harddisk, but they are not in a patch yet for good reasons. -- From know your smileys: =):-) Uncle Sam /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: VimWiki - again - but with a brand new option
Am Mittwoch, den 09.05.2007, 13:06 -0500 schrieb Tom Purl: We do have a Wikia site available if we want it (http://vim.wikia.com/wiki/Main_Page). I agree with you; it has a lot of nice features, and may give us a bit more flexibility than the wikibooks option. I think we should revisit this topic once we're ready The features are mostly the same. In fact all major extensions are installed on wikibooks too. On any mediawiki try out the page Special:Version to see all installed extensions: http://wikibooks.org/wiki/Special:Version Note the modules SpamBlacklist, UsernameBlacklist and ConfirmEdit (Captcha) Wikia.com is clearly aimed at making money with ads. Therefore I now vote for wikibooks.org. :-) Sebastian.
Re: 7.1a.001 OSX colour scheme errors?
Michael Wookey wrote: I am running 7.1a.001 on OSX and have just noticed the following from console vim (running in Terminal.app and also occurs in iTerm.app). If I change the colour scheme I receive a lot of error output. For example: :colorscheme desert Results in: Error detected while processing /Applications/Vim.app/Contents/Resources/vim/runtime/colors/desert.vim: line 27: E254: Cannot allocate color khaki E254: Cannot allocate color slategrey line 36: E254: Cannot allocate color gold line 37: E254: Cannot allocate color tan ... Other colour schemes produce similar output. The error messages have only appeared for me in console vim on OSX (10.4.9 PPC). They have not appeared in the linux or win32 console vims of 7.1a.001. GVim's on each of the platforms (OSX, linux, Win32) have worked fine. My console vim is symlinked as follows: $ ls -l `which vim` lrwxr-xr-x 1 root wheel 40 Feb 28 14:33 /usr/bin/vim - /Applications/Vim.app/Contents/MacOS/Vim These errors did not occur before 7.1a.001 and occurs on builds from CVS and SVN. The errors still occur even with starting vim with: vim -u NONE Has anyone else noticed this? You apparently are missing the runtime/rgb.txt file. It's part of the extra archive. Perhaps you didn't unpack it correctly? You must have unpacked it, since it contains src/gui_mac.c. And you must not change the directory structure, otherwise Vim.app can't be generated correctly. -- From know your smileys: :-XMy lips are sealed /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: [Announcement] Subversion repository location changed
On 5/9/07, Edward L. Fox [EMAIL PROTECTED] wrote: If you had checked out a copy of the sources before, please run this command in your source root directory to switch into the current branch: svn switch https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 This switch command gives me error: $ cd vim7 $ svn info Path: . URL: https://svn.sourceforge.net/svnroot/vim/vim7 Repository Root: https://svn.sourceforge.net/svnroot/vim Repository UUID: 2a77ed30-b011-0410-a7ad-c7884a0aa172 Revision: 263 Node Kind: directory Schedule: normal Last Changed Author: edyfox Last Changed Rev: 263 Last Changed Date: 2007-05-06 23:13:56 -0400 (Sun, 06 May 2007) $ svn switch https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 svn: 'https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1' is not the same repository as 'https://svn.sourceforge.net/svnroot/vim' What am I doign wrong ? Yakov
Re: [Announcement] Subversion repository location changed
Yakov Lerner wrote: On 5/9/07, Edward L. Fox [EMAIL PROTECTED] wrote: If you had checked out a copy of the sources before, please run this command in your source root directory to switch into the current branch: svn switch https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 This switch command gives me error: $ cd vim7 $ svn info Path: . URL: https://svn.sourceforge.net/svnroot/vim/vim7 Repository Root: https://svn.sourceforge.net/svnroot/vim Repository UUID: 2a77ed30-b011-0410-a7ad-c7884a0aa172 Revision: 263 Node Kind: directory Schedule: normal Last Changed Author: edyfox Last Changed Rev: 263 Last Changed Date: 2007-05-06 23:13:56 -0400 (Sun, 06 May 2007) $ svn switch https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 svn: 'https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1' is not the same repository as 'https://svn.sourceforge.net/svnroot/vim' What am I doign wrong ? Yakov The vim.svn vs svn... . https://svn.sourceforge.net/svnroot/vim/branches/vim7.1 (no vim) works for me. I've a question, though: isn't bleeding-edge development done in https://svn.sourceforge.net/svnroot/vim/trunk ? That /would/ be the appropriate line for the latest sources, right? -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: [PATCH] vim_is_xterm() and screen
Micah Cowan wrote: Sorry for the repost; but I realized I should've drawn more attention to the message with the patch in it, both so other lurkers know the thread now includes a proposed patch, and so that we know what message to go back to if we want to refer to the code we're discussing. I have made a slight adjustment to the patch, swapping the order of STRICMP and term_is_xterm within vim_uses_xterm_mouse(). I was using vim_is_xterm() instead of term_is_xterm at first, but afterwards replaced it for efficiency, but left the order as it was. Looks OK to me. If I understood your other message correctly then using xterm2 for 'ttymouse' would not work for screen. -- From know your smileys: :-DBig smile /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: VimWiki - again - but with a brand new option
Ian Tegebo wrote: On 5/6/07, Sebastian Menge [EMAIL PROTECTED] wrote: Hi all Independent of the implementation used, I suggest to develop good guidelines. The Wiki should be really valuable and not redundant to vim-tips or mailing-lists. I would like to make another implementation independent suggestion; one could make a VimWiki more valuable by importing the _extremely_ valuable vim helpfiles into it. Please don't do this. It might sound like a nice idea, but it means making a branch that will be very hard to merge back into the help files of the distribution. I feel misunderstood but it serves me right for not saying what I mean... Synchronizing data is no fun, I agree. While I was up in the clouds I was imaging that the wiki would be the authoritative source for the helpfiles after doing an initial _import_. Then the text version would be exported as needed, e.g. end user runtime update or for a new release. That's the problem: It's very easy to change the text in the wiki in such a way it won't be possible to put back in the distribution. Also, I need to check every change, at least briefly (depend on where the change comes from). That is the only way to maintain the quality. Thus I would need a list of changes, preferably in the form of a patch. When people change the wiki in various ways this will quickly become a nightmare. Taking the existing help files and _adding_ to them is good. Especially if corrections and additions are marked somehow, so that they eventually end up in the distribution. Otherwise links to tips can be added. I'm currently working on the 7.1 release and then will go travelling, thus I won't have much time to discuss the tips wiki. I certainly encourage everybody to make it work. After all, a wiki is a collaborative work! -- From know your smileys: 2B|^2B Message from Shakespeare /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: [PATCH] vim_is_xterm() and screen
Bram Moolenaar wrote: Micah Cowan wrote: Sorry for the repost; but I realized I should've drawn more attention to the message with the patch in it, both so other lurkers know the thread now includes a proposed patch, and so that we know what message to go back to if we want to refer to the code we're discussing. I have made a slight adjustment to the patch, swapping the order of STRICMP and term_is_xterm within vim_uses_xterm_mouse(). I was using vim_is_xterm() instead of term_is_xterm at first, but afterwards replaced it for efficiency, but left the order as it was. Looks OK to me. Terrific! Does that mean it'll go in? :) If I understood your other message correctly then using xterm2 for 'ttymouse' would not work for screen. Well... manually setting it to xterm2 will work fine (assuming screen is running under a supporting version of xterm): I get the full dragging effect, etc. But screen doesn't do t_RV, and I don't know how else you'd determine support for xterm2, so there doesn't seem to be a safe way to set ttymouse to it automatically, for screen. Towards a better solution: how straightforward do you think it'll be to talk the ncurses guys into adding support for some of screen's extensions? AFAIK, the only one I care about is the xterm mouse support; another interesting one is a boolean supports ansi setforeground/setbackground codes; but I usually infer this (if necessary) from the presence of setaf/setbf (not a given, but...). -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
RE: 7.1a.001 OSX colour scheme errors?
Has anyone else noticed this? You apparently are missing the runtime/rgb.txt file. It's part of the extra archive. Perhaps you didn't unpack it correctly? You must have unpacked it, since it contains src/gui_mac.c. And you must not change the directory structure, otherwise Vim.app can't be generated correctly. I have the rgb.txt in my build tree. Its just that 'make install' doesn't copy it over when building Vim.App. See further on in this thread with the subject [SOLVED] RE: 7.1a.001 OSX colour scheme errors?. Is it possible for you to change the Makefile to copy rgb.txt to $VIMRUNTIME during 'make install'? Thanks.
Re: [Announcement] Subversion repository location changed
On Wed, May 09, 2007 at 02:20:52PM -0700, Micah Cowan wrote: If you had checked out a copy of the sources before, please run this command in your source root directory to switch into the current branch: svn switch https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 This switch command gives me error: $ cd vim7 $ svn info Path: . URL: https://svn.sourceforge.net/svnroot/vim/vim7 Repository Root: https://svn.sourceforge.net/svnroot/vim Repository UUID: 2a77ed30-b011-0410-a7ad-c7884a0aa172 Revision: 263 Node Kind: directory Schedule: normal Last Changed Author: edyfox Last Changed Rev: 263 Last Changed Date: 2007-05-06 23:13:56 -0400 (Sun, 06 May 2007) $ svn switch https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 svn: 'https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1' is not the same repository as 'https://svn.sourceforge.net/svnroot/vim' What am I doign wrong ? I got the same error. My response was rm -rf vim7 svn co https://svn.sourceforge.net/svnroot/vim/trunk vim7 I've a question, though: isn't bleeding-edge development done in https://svn.sourceforge.net/svnroot/vim/trunk ? That /would/ be the appropriate line for the latest sources, right? I hope so :) GI -- Top Ten New Intel Slogans For The Pentium: 6.831538 You Don't Need to Know What's Inside
Re: VimWiki - again - but with a brand new option
On Wed, 2007-05-09 at 13:06 -0500, Tom Purl wrote: On Wed, May 9, 2007 11:37 am, Sebastian Menge wrote: First, im not sure about what you mean by a) formatting standard and b) a script that supports the standard is a) something like a template in mediawiki-speak? see: http://home.comcast.net/~gerisch/MediaWikiTemplates.html http://www.mediawiki.org/wiki/Help:Templates By formatting standard, I mean that we need to agree on how we want the tips to look once they're converted and posted to the wiki. Basically, what do we want the tips to look like so we can tweak the conversion script (if necessary). Put me down as voting for 'simplistic'. ie no fancy boxes/backgrounds just bold headings and maybe a splash of Vim green somewhere. (Man pages come to mind) is b) something that reads the tips-db on vim.org and posts it to the wiki? Here, I'm referring to the script that will convert the scripts from their current format to their future, wiki-fied format. We already have 3 or 4 scripts that could do this. Everything else is agreed and appreciated :-) Thanks! Seb. PS: When writing this mail I got my hands dirty on the scratchpad of wikia.com: http://scratchpad.wikia.com/wiki/VimTest http://scratchpad.wikia.com/wiki/Template:Tip PPS: There are extensions for mediawiki that could be useful: To supply a HTML-Form to submit a tip: http://meta.wikimedia.org/wiki/Help:Inputbox To order a list of pages by popularity http://semeb.com/dpldemo/index.php/Manual Both are installed on wikia.org We do have a Wikia site available if we want it (http://vim.wikia.com/wiki/Main_Page). I agree with you; it has a lot of nice features, and may give us a bit more flexibility than the wikibooks option. I think we should revisit this topic once we're ready to start the real conversion. cheers, -- Mark
Re: [Announcement] Subversion repository location changed
On 5/10/07, Gautam Iyer [EMAIL PROTECTED] wrote: On Wed, May 09, 2007 at 02:20:52PM -0700, Micah Cowan wrote: If you had checked out a copy of the sources before, please run this command in your source root directory to switch into the current branch: svn switch https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 This switch command gives me error: $ cd vim7 $ svn info Path: . URL: https://svn.sourceforge.net/svnroot/vim/vim7 Repository Root: https://svn.sourceforge.net/svnroot/vim Repository UUID: 2a77ed30-b011-0410-a7ad-c7884a0aa172 Revision: 263 Node Kind: directory Schedule: normal Last Changed Author: edyfox Last Changed Rev: 263 Last Changed Date: 2007-05-06 23:13:56 -0400 (Sun, 06 May 2007) $ svn switch https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 svn: 'https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1' is not the same repository as 'https://svn.sourceforge.net/svnroot/vim' What am I doign wrong ? I got the same error. My response was rm -rf vim7 svn co https://svn.sourceforge.net/svnroot/vim/trunk vim7 svn switch can only switch from a directory into another directory inside the same repository. It doesn't allow the user to switch from one server to another server. So you will not be able to switch from svn.sourceforge.net to vim.svn.sourceforge.net. So you can try to switch to https://svn.sourceforge.net/svnroot/vim/branches/vim7.1 svn.sourceforge.net sometimes gives out 403 forbidden errors when doing some maintaining work. The sf.net staff recommended to use vim.svn.sourceforge.net instead of svn.sourceforge.net. However, if you don't want to do any maintaining work, I think both URL will be OK. I've a question, though: isn't bleeding-edge development done in https://svn.sourceforge.net/svnroot/vim/trunk ? That /would/ be the appropriate line for the latest sources, right? I don't know. I'm still asking Bram for the latest sources. Currently, trunk and 7.1 branch will be the same. I hope so :) GI -- Top Ten New Intel Slogans For The Pentium: 6.831538 You Don't Need to Know What's Inside
Re: [Announcement] Subversion repository location changed
Micah Cowan wrote: Edward L. Fox wrote: On 5/10/07, Gautam Iyer [EMAIL PROTECTED] wrote: I got the same error. My response was rm -rf vim7 svn co https://svn.sourceforge.net/svnroot/vim/trunk vim7 svn switch can only switch from a directory into another directory inside the same repository. It doesn't allow the user to switch from one server to another server. So you will not be able to switch from svn.sourceforge.net to vim.svn.sourceforge.net. So you can try to switch to https://svn.sourceforge.net/svnroot/vim/branches/vim7.1 Well, except that in this case, the --relocate option would probably be appropriate, which is used to support switches between different repositories. I don't know. I'm still asking Bram for the latest sources. Currently, trunk and 7.1 branch will be the same. My understanding of what Bram said is that trunk/ already has the latest sources. I'm not entirely sure what was meant by runtime files, but I suspect he /may/ have meant: files that are generated automatically, and are therefore potentially inappropriate to a repository. No, the runtime files are those which go into runtime/ not src/ and are not compiled into the binaries but copied to $VIMRUNTIME and below. Their updates are usually not mentioned in the official patches, but their latest versions can be had (now) by rsync. Here's the script I use (the last line is for cleaning up the log by removing temporary lines which were erased as the download progressed): #!/bin/bash rsync -avzcP --delete --exclude=/dos/ ftp.nluug.nl::Vim/runtime/ ./runtime/ 21 | tee rsync.log vim -es -u NONE -c '%s/^.*\r//' -cx rsync.log Beware of beautifying mailers! There are three lines, starting respectively #!/, rsync and vim. Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 226. You sit down at the computer right after dinner and your spouse says See you in the morning.
Re: [PATCH] vim_is_xterm() and screen
On 2007-05-09, Micah Cowan [EMAIL PROTECTED] wrote: Towards a better solution: how straightforward do you think it'll be to talk the ncurses guys into adding support for some of screen's extensions? AFAIK, the only one I care about is the xterm mouse support; another interesting one is a boolean supports ansi setforeground/setbackground codes; but I usually infer this (if necessary) from the presence of setaf/setbf (not a given, but...). The ncurses guys is Thomas Dickey, who frequents a number of lists and newsgroups, and who would probably be willing to discuss it with you. Contact information is here: http://www.gnu.org/software/ncurses/ Look for Who's Who and What's What. You might also consider joining the bug-ncurses-request mailing list, which is open to anyone interested in helping with the development and testing of this package. I would imagine the process would be more a matter of convincing Thomas to accept the concept, the design, and any patches you would submit, rather than the ncurses guys adding this support themselves. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: [PATCH] vim_is_xterm() and screen
Gary Johnson wrote: On 2007-05-09, Micah Cowan [EMAIL PROTECTED] wrote: Towards a better solution: how straightforward do you think it'll be to talk the ncurses guys into adding support for some of screen's extensions? AFAIK, the only one I care about is the xterm mouse support; another interesting one is a boolean supports ansi setforeground/setbackground codes; but I usually infer this (if necessary) from the presence of setaf/setbf (not a given, but...). The ncurses guys is Thomas Dickey, who frequents a number of lists and newsgroups, and who would probably be willing to discuss it with you. Contact information is here: http://www.gnu.org/software/ncurses/ Look for Who's Who and What's What. You might also consider joining the bug-ncurses-request mailing list, which is open to anyone interested in helping with the development and testing of this package. Thanks for that! I would imagine the process would be more a matter of convincing Thomas to accept the concept, the design, and any patches you would submit, rather than the ncurses guys adding this support themselves. Fair enough. :) -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
