RE: bug: gvim 7.0.205 on xp can not display ucs-2
What gets displayed? Does this happen on gVim as well? Do Chinese characters appear correctly in the console window when using other programs? -Original Message- From: Mike Li [mailto:[EMAIL PROTECTED] Sent: Monday, March 05, 2007 10:04 PM To: vim-dev@vim.org Subject: Re: bug: gvim 7.0.205 on xp can not display ucs-2 console vim 7.0 (patches 1-205), built with the mingw compiler under cygwin (gcc -mno-cygwin), as well as the console vim 7.0.122 binary distributed with cygwin have the same problem as the gvim binaries under windows xp. -x On 3/5/07, Mike Li [EMAIL PROTECTED] wrote: gvim 7.0 (patches 1-205) under windows xp, built with the mingw compiler under cygwin (gcc -mno-cygwin), can not display ucs-2 text files. see below for the xxd-dump of an ucs-2 text file containing a single chinese character (U+6c38): 000: 6c 38 00 0d 00 0al8 the same problem is seen with the little-endian (ucs-2le) version of the same file: 000: 38 6c 0d 00 0a 008l the presence or absence of a BOM (byte order marker) at the beginning of the file does not make a difference. the issue is also seen with gvim from the original windows binary distribution. console vim 7.0 (patches 1-205) under fedora core 6, built with gcc 4.0, works fine with '++enc=ucs-2'. the original binary from the yum package vim-enhanced-7.0.201-1.fc6 also works fine. -x
Jump to tag in a file opened in another session
Hi, I've searched for this for some time now but it's either not available or I have to hone my search skills a lot. Most of the time I have multiple xterms opened, running vim sessions within the same project. The files are tagged and I'm using :ta and :tj a lot. It happens often that I'm about to jump to a tagged function in a file which I have opened in another xterm. What happens is that the swap file is found and the Swap file [...] already exists message is printed, giving the usual choice which has to be confirmed. The more often this happens, the more annoying it is. What I usually want is to open the file readonly, because I just want to have a look into that function. The actual editing of this file is done in the other vim window. I can't find a way to accomplish this. I know there's the shortmess=A option, but it avoids the attention message in a dangerous way: It doesn't print *any* warning and it allows to edit the file. If I really edit the file at this point, because I miss the fact that this is the same file as in the other xterm session, the first warning appears in the second session only when trying to write back the changes made there. So, the bottom line is, I'm looking for is a way to open a file automatically in r/o mode if I'm going to jump to a tag in that file and the file is opened in another session. Is that possible already? If not, would it make sense to add a setting which enables this behaviour? Thanks in advance, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat
Re: bug: gvim 7.0.205 on xp can not display ucs-2
for big-endian, the following is displayed: [EMAIL PROTECTED]@ for little-endian, the following is displayed: 8l^M^@ ^@ ^@ and ^M are control characters. this definitely happens on gvim as well as console vim under windows xp. i'm not sure if it happens with other programs in the console window, as the platform is windows. i have the appropriate fonts, and notepad displays the little-endian version correctly. -x On 3/6/07, Doug Cook [EMAIL PROTECTED] wrote: What gets displayed? Does this happen on gVim as well? Do Chinese characters appear correctly in the console window when using other programs? -Original Message- From: Mike Li [mailto:[EMAIL PROTECTED] Sent: Monday, March 05, 2007 10:04 PM To: vim-dev@vim.org Subject: Re: bug: gvim 7.0.205 on xp can not display ucs-2 console vim 7.0 (patches 1-205), built with the mingw compiler under cygwin (gcc -mno-cygwin), as well as the console vim 7.0.122 binary distributed with cygwin have the same problem as the gvim binaries under windows xp. -x On 3/5/07, Mike Li [EMAIL PROTECTED] wrote: gvim 7.0 (patches 1-205) under windows xp, built with the mingw compiler under cygwin (gcc -mno-cygwin), can not display ucs-2 text files. see below for the xxd-dump of an ucs-2 text file containing a single chinese character (U+6c38): 000: 6c 38 00 0d 00 0al8 the same problem is seen with the little-endian (ucs-2le) version of the same file: 000: 38 6c 0d 00 0a 008l the presence or absence of a BOM (byte order marker) at the beginning of the file does not make a difference. the issue is also seen with gvim from the original windows binary distribution. console vim 7.0 (patches 1-205) under fedora core 6, built with gcc 4.0, works fine with '++enc=ucs-2'. the original binary from the yum package vim-enhanced-7.0.201-1.fc6 also works fine. -x
Re: bug: gvim 7.0.205 on xp can not display ucs-2
one point of clarification: the correcly functioning fedora console vim binaries were run under x11 (rxvt-unicode) with appropriate truetype fonts. -x On 3/5/07, Mike Li [EMAIL PROTECTED] wrote: gvim 7.0 (patches 1-205) under windows xp, built with the mingw compiler under cygwin (gcc -mno-cygwin), can not display ucs-2 text files. see below for the xxd-dump of an ucs-2 text file containing a single chinese character (U+6c38): 000: 6c 38 00 0d 00 0al8 the same problem is seen with the little-endian (ucs-2le) version of the same file: 000: 38 6c 0d 00 0a 008l the presence or absence of a BOM (byte order marker) at the beginning of the file does not make a difference. the issue is also seen with gvim from the original windows binary distribution. console vim 7.0 (patches 1-205) under fedora core 6, built with gcc 4.0, works fine with '++enc=ucs-2'. the original binary from the yum package vim-enhanced-7.0.201-1.fc6 also works fine. -x
Re: Jump to tag in a file opened in another session
So, the bottom line is, I'm looking for is a way to open a file automatically in r/o mode if I'm going to jump to a tag in that file and the file is opened in another session. hi, I've thought about the same feature. I think there are three solutions now: 1. use one xterm with tabs instead of several xterms (don't like) 2. use a communication with vim server to synchronize (seems hard for me) 3. write a couple of functions: tagjump - set the variable jumpingThereBecauseOfTag and calls tag jump checktag - check the variable jumpingThereBecauseOfTag and set readonly if this variable is set and swap file exists then create (and use) a new command :Tj calling tagjump and add an autocommand for BufReadPre event calling checktag It's just an idea, I still didn't write these. But I think it should work. Milan
Re: bug: gvim 7.0.205 on xp can not display ucs-2
one more update: if i add the following two lines to my _vimrc, then the ucs-2le text file works: set fileencodings+=ucs-2le set encoding=utf-8 note that both need to be set before i edit the file. once i load the file, setting them no longer helps. -x On 3/6/07, Mike Li [EMAIL PROTECTED] wrote: one point of clarification: the correcly functioning fedora console vim binaries were run under x11 (rxvt-unicode) with appropriate truetype fonts. -x On 3/5/07, Mike Li [EMAIL PROTECTED] wrote: gvim 7.0 (patches 1-205) under windows xp, built with the mingw compiler under cygwin (gcc -mno-cygwin), can not display ucs-2 text files. see below for the xxd-dump of an ucs-2 text file containing a single chinese character (U+6c38): 000: 6c 38 00 0d 00 0al8 the same problem is seen with the little-endian (ucs-2le) version of the same file: 000: 38 6c 0d 00 0a 008l the presence or absence of a BOM (byte order marker) at the beginning of the file does not make a difference. the issue is also seen with gvim from the original windows binary distribution. console vim 7.0 (patches 1-205) under fedora core 6, built with gcc 4.0, works fine with '++enc=ucs-2'. the original binary from the yum package vim-enhanced-7.0.201-1.fc6 also works fine. -x
Re: Jump to tag in a file opened in another session
On Mar 6 11:54, Milan Vancura wrote: So, the bottom line is, I'm looking for is a way to open a file automatically in r/o mode if I'm going to jump to a tag in that file and the file is opened in another session. hi, I've thought about the same feature. I think there are three solutions now: 1. use one xterm with tabs instead of several xterms (don't like) 2. use a communication with vim server to synchronize (seems hard for me) 3. write a couple of functions: tagjump - set the variable jumpingThereBecauseOfTag and calls tag jump checktag - check the variable jumpingThereBecauseOfTag and set readonly if this variable is set and swap file exists then create (and use) a new command :Tj calling tagjump and add an autocommand for BufReadPre event calling checktag It's just an idea, I still didn't write these. But I think it should work. I guess the most easy way to accomplish this is another shortmess option which is like A, but with an automatic r/o open mode. If this behaviour is accompanied with an inverse [readonly] marker (inverse red on color terminals), that would be sufficient, IMHO. Actually, if I have a file already open in another session I never want to open it for editing in another session. I'm aware that I'd have to use the -r option to recover, should that be necessary. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat
Re: bug: gvim 7.0.205 on xp can not display ucs-2
Mike Li wrote: one more update: if i add the following two lines to my _vimrc, then the ucs-2le text file works: set fileencodings+=ucs-2le set encoding=utf-8 note that both need to be set before i edit the file. once i load the file, setting them no longer helps. -x Of course: - Vim needs to be able to represent Unicode codepoints in memory (:set encoding=utf-8). This must be done before any attempt to read the file. - Vim needs to know how to detect the encoding. This can be done in several ways: * if 'fileencodings' *begins* with ucs-bom, any Unicode encoding with BOM will be recognised. * if you use :e ++enc=ucs-2be filename, the file will be interpreted according to big-endian UCS-2 * if 'fileencodings' contains ucs-2le, and anything preceding it checks invalid for that file, then the file will be read as little-endian UCS-2 if it contains no invalid bytes for that encoding. Of course, if you change 'fileencodings' after the file has been read, it is too late. You also need to set a font containing the glyphs for whatever codepoints you'll want to see. This is not a trivial problem in multilingual file: e.g., I know no fixed-width font having both Chinese and Arabic glyphs. Setting the font is done in gvim by means of the 'guifont' option; console Vim uses whatever font is set by the hardware text console or by the software terminal emulator. See: :help 'encoding' :help 'fileencodings' :help ++opt :help mbyte.txt :help 'guifont' Best regards, Tony. -- Did you know that there are 71.9 acres of nipple tissue in the U.S.?
patch 7.0.208
Patch 7.0.208 (after 7.0.171 and 7.0.180)
Problem:VMS: changes to path handling cause more trouble than they solve.
Solution: Revert changes.
Files: src/buffer.c, src/memline.c, src/os_unix.c
*** ../vim-7.0.207/src/buffer.c Tue Nov 28 17:44:51 2006
--- src/buffer.cMon Mar 5 21:34:41 2007
***
*** 4145,4157
/*
* Force expanding the path always for Unix, because symbolic links may
* mess up the full path name, even though it starts with a '/'.
- * Also expand always for VMS, it may have alternate paths that need to be
- * resolved.
* Also expand when there is .. in the file name, try to remove it,
* because c:/src/../README is equal to c:/README.
* For MS-Windows also expand names like longna~1 to longname.
*/
! #if defined(UNIX) || defined(VMS)
return FullName_save(fname, TRUE);
#else
if (!vim_isAbsName(fname) || strstr((char *)fname, ..) != NULL
--- 4145,4155
/*
* Force expanding the path always for Unix, because symbolic links may
* mess up the full path name, even though it starts with a '/'.
* Also expand when there is .. in the file name, try to remove it,
* because c:/src/../README is equal to c:/README.
* For MS-Windows also expand names like longna~1 to longname.
*/
! #ifdef UNIX
return FullName_save(fname, TRUE);
#else
if (!vim_isAbsName(fname) || strstr((char *)fname, ..) != NULL
*** ../vim-7.0.207/src/memline.cTue Feb 13 04:03:05 2007
--- src/memline.c Mon Mar 5 21:34:41 2007
***
*** 3592,3600
#else
(buf-b_p_sn || buf-b_shortname),
#endif
! #if defined(VMS) || defined(RISCOS)
! /* Avoid problems if fname has special chars, eg Wimp$Scrap.
!* For VMS always use full path for swapfile. */
ffname,
#else
# ifdef HAVE_READLINK
--- 3592,3599
#else
(buf-b_p_sn || buf-b_shortname),
#endif
! #ifdef RISCOS
! /* Avoid problems if fname has special chars, eg Wimp$Scrap */
ffname,
#else
# ifdef HAVE_READLINK
*** ../vim-7.0.207/src/os_unix.cTue Feb 27 16:51:07 2007
--- src/os_unix.c Mon Mar 5 21:40:31 2007
***
*** 2214,2262
int len;
int force; /* also expand when already absolute
path */
{
- #ifdef VMS
- /*
- * VMS does this in a completely different way.
- *
- * By default a file found in a complex path is written to the first
- * directory in the path and not to the original directory. This
- * behaviour should be avoided for the existing files and we need to find
- * the exact path of the edited file.
- */
- {
- char_u *fixed_fname = vms_fixfilename(fname);
- int fd = mch_open((char *)fixed_fname, O_RDONLY | O_EXTRA, 0);
-
- if (fd 0)
- {
- char nbuf[MAXNAMLEN];
-
- /* File exists, use getname() to get the real name. */
- if (getname(fd, nbuf))
- vim_strncpy(fixed_fname, (char_u *)nbuf, (size_t)(len - 1));
- close(fd);
- }
-
- if (STRLEN(fixed_fname) = len)
- return FAIL;
-
- STRCPY(buf, fixed_fname);
- }
-
- #else /* not VMS */
-
int l;
! # ifdef OS2
int only_drive; /* file name is only a drive letter */
! # endif
! # ifdef HAVE_FCHDIR
int fd = -1;
static intdont_fchdir = FALSE;/* TRUE when fchdir() doesn't
work */
! # endif
char_uolddir[MAXPATHL];
char_u*p;
int retval = OK;
/* expand it if forced or not an absolute path */
if (force || !mch_isFullName(fname))
{
--- 2214,2235
int len;
int force; /* also expand when already absolute
path */
{
int l;
! #ifdef OS2
int only_drive; /* file name is only a drive letter */
! #endif
! #ifdef HAVE_FCHDIR
int fd = -1;
static intdont_fchdir = FALSE;/* TRUE when fchdir() doesn't
work */
! #endif
char_uolddir[MAXPATHL];
char_u*p;
int retval = OK;
+ #ifdef VMS
+ fname = vms_fixfilename(fname);
+ #endif
+
/* expand it if forced or not an absolute path */
if (force || !mch_isFullName(fname))
{
***
*** 2265,2280
* and then do the getwd() (and get back to where we were).
* This will get the correct path name with ../ things.
*/
! # ifdef OS2
only_drive = 0;
if (((p = vim_strrchr(fname, '/')) != NULL)
|| ((p = vim_strrchr(fname, '\\')) != NULL)
|| (((p = vim_strchr(fname, ':')) != NULL) ++only_drive))
! # else
if ((p = vim_strrchr(fname, '/')) != NULL)
! # endif
{
! # ifdef
RE: bug: gvim 7.0.205 on xp can not display ucs-2
Using gVim, if I load your file normally, I do get ASCII instead of Unicode. But if I then type: :e ++enc=ucs-2 it appears to work. I don't have a Chinese font, so I get a box, but it is a single character and it is double-width, so it appears to be interpreted correctly by Vim. The same thing happens automatically if I insert the UCS-2 byte order mark fe ff at the start of the file. The console version is a bit more tricky, and correct behavior from Vim might depend on various system settings. In my case, the console version reports a conversion error. -Original Message- From: Mike Li [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 06, 2007 1:53 AM To: Doug Cook Cc: vim-dev@vim.org Subject: Re: bug: gvim 7.0.205 on xp can not display ucs-2 for big-endian, the following is displayed: [EMAIL PROTECTED]@ for little-endian, the following is displayed: 8l^M^@ ^@ ^@ and ^M are control characters. this definitely happens on gvim as well as console vim under windows xp. i'm not sure if it happens with other programs in the console window, as the platform is windows. i have the appropriate fonts, and notepad displays the little-endian version correctly. -x On 3/6/07, Doug Cook [EMAIL PROTECTED] wrote: What gets displayed? Does this happen on gVim as well? Do Chinese characters appear correctly in the console window when using other programs? -Original Message- From: Mike Li [mailto:[EMAIL PROTECTED] Sent: Monday, March 05, 2007 10:04 PM To: vim-dev@vim.org Subject: Re: bug: gvim 7.0.205 on xp can not display ucs-2 console vim 7.0 (patches 1-205), built with the mingw compiler under cygwin (gcc -mno-cygwin), as well as the console vim 7.0.122 binary distributed with cygwin have the same problem as the gvim binaries under windows xp. -x On 3/5/07, Mike Li [EMAIL PROTECTED] wrote: gvim 7.0 (patches 1-205) under windows xp, built with the mingw compiler under cygwin (gcc -mno-cygwin), can not display ucs-2 text files. see below for the xxd-dump of an ucs-2 text file containing a single chinese character (U+6c38): 000: 6c 38 00 0d 00 0al8 the same problem is seen with the little-endian (ucs-2le) version of the same file: 000: 38 6c 0d 00 0a 008l the presence or absence of a BOM (byte order marker) at the beginning of the file does not make a difference. the issue is also seen with gvim from the original windows binary distribution. console vim 7.0 (patches 1-205) under fedora core 6, built with gcc 4.0, works fine with '++enc=ucs-2'. the original binary from the yum package vim-enhanced-7.0.201-1.fc6 also works fine. -x
Re: bug: gvim 7.0.205 on xp can not display ucs-2
much thanks to Doug and A.J. -- i now see that it wasn't a bug at all. sorry for the noise. -x On 3/6/07, Doug Cook [EMAIL PROTECTED] wrote: Using gVim, if I load your file normally, I do get ASCII instead of Unicode. But if I then type: :e ++enc=ucs-2 it appears to work. I don't have a Chinese font, so I get a box, but it is a single character and it is double-width, so it appears to be interpreted correctly by Vim. The same thing happens automatically if I insert the UCS-2 byte order mark fe ff at the start of the file. The console version is a bit more tricky, and correct behavior from Vim might depend on various system settings. In my case, the console version reports a conversion error. -Original Message- From: Mike Li [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 06, 2007 1:53 AM To: Doug Cook Cc: vim-dev@vim.org Subject: Re: bug: gvim 7.0.205 on xp can not display ucs-2 for big-endian, the following is displayed: [EMAIL PROTECTED]@ for little-endian, the following is displayed: 8l^M^@ ^@ ^@ and ^M are control characters. this definitely happens on gvim as well as console vim under windows xp. i'm not sure if it happens with other programs in the console window, as the platform is windows. i have the appropriate fonts, and notepad displays the little-endian version correctly. -x On 3/6/07, Doug Cook [EMAIL PROTECTED] wrote: What gets displayed? Does this happen on gVim as well? Do Chinese characters appear correctly in the console window when using other programs? -Original Message- From: Mike Li [mailto:[EMAIL PROTECTED] Sent: Monday, March 05, 2007 10:04 PM To: vim-dev@vim.org Subject: Re: bug: gvim 7.0.205 on xp can not display ucs-2 console vim 7.0 (patches 1-205), built with the mingw compiler under cygwin (gcc -mno-cygwin), as well as the console vim 7.0.122 binary distributed with cygwin have the same problem as the gvim binaries under windows xp. -x On 3/5/07, Mike Li [EMAIL PROTECTED] wrote: gvim 7.0 (patches 1-205) under windows xp, built with the mingw compiler under cygwin (gcc -mno-cygwin), can not display ucs-2 text files. see below for the xxd-dump of an ucs-2 text file containing a single chinese character (U+6c38): 000: 6c 38 00 0d 00 0al8 the same problem is seen with the little-endian (ucs-2le) version of the same file: 000: 38 6c 0d 00 0a 008l the presence or absence of a BOM (byte order marker) at the beginning of the file does not make a difference. the issue is also seen with gvim from the original windows binary distribution. console vim 7.0 (patches 1-205) under fedora core 6, built with gcc 4.0, works fine with '++enc=ucs-2'. the original binary from the yum package vim-enhanced-7.0.201-1.fc6 also works fine. -x
Re: [!] missing from :cb and related commands?
Hi Gary, On 3/6/07, Gary Johnson [EMAIL PROTECTED] wrote: If I open a new window, read into it the results of a grep command, e.g., :r !grep -nH somepattern somefileset and then try to use that buffer as a quickfix list or location list with either the :cb or :lb commands, respectively, I get E37: No write since last change (add ! to override) If I then try to add ! to the :cb or :lb commands, I get E477: No ! allowed It seems to me that the :cb and :lb commands are missing the ability to handle a !. The most recent version of vim I had to verify this with was 7.0.178. You can try using the :cgetbuffer and :lgetbuffer commands. These commands will not automatically jump to the first error. - Yegappan
Re: BufWritePre and :wqa
Cyril Slobin wrote:
On 3/6/07, Bram Moolenaar [EMAIL PROTECTED] wrote:
It will help a lot to understand what you are talking about if you
include an example script. Details might matter.
Well. In my _vimrc I set up an autocommand
autocmd BufWritePre * ks|call TimeStamp()|'s
I believe that content of TimeStamp is irrelevant, but just in case it
matters:
function! TimeStamp()
let lines = line($) 10 ? line($) : 10
let pattern1 = '\(Last [Cc]hange:\s\+\)\d\d\d\d \u\l\l \d\d'
let replace1 = '\1' . strftime(%Y %b %d)
execute printf('1,%ds/\C\m%s/%s/e', lines, pattern1, replace1)
execute printf('$-%d+1,$s/\C\m%s/%s/e', lines, pattern1, replace1)
let pattern2 = '\($Id: \f\+ \d\+\.\d\+\(\.\d\+\.\d\+\)*\)\(+\(\d\+\)\)\?'
let replace2 = '\=submatch(1) . + . (submatch(4) + 1)'
execute printf('1,%ds/\C\m%s/%s/e', lines, pattern2, replace2)
execute printf('$-%d+1,$s/\C\m%s/%s/e', lines, pattern2, replace2)
endfunction
When I save buffer with :w -- it works.
When I save buffer with :wq -- it works.
But when I save buffer with :wqa -- it doesn't work.
Vim 7.0, not patched, win32 and dos32 versions.
My whole _vimrc is at http://45.free.net/~slobin/vim/_vimrc.html if this
helps.
Unlike :w or :wq, :wqa only triggers a write if the buffer is
'modified'. Are you sure that it was?
Best regards,
Tony.
--
Work Rule: Leave of Absence (for an Operation):
We are no longer allowing this practice. We wish to discourage
any thoughts that you may not need all of whatever you have, and you
should not consider having anything removed. We hired you as you are,
and to have anything removed would certainly make you less than we
bargained for.
dos32 colors
Hi all! In color xterm color 1 for is #0c (red), but in dos32 it is #0c (blue). (Strictly speaking, VGA standard palette is different, but xterm colors are good enough approximation in practice). This makes very hard to write portable scripts dealing with colors. Does a better way to write a such a script exist other than: if has(dos32) let color1 = #0c else let color1 = #0c endif ? By the way, 2html.vim does not perform this test and colors of HTML generated in dos32 are wrong. -- Cyril Slobin [EMAIL PROTECTED] `When I use a word,' Humpty Dumpty said, http://45.free.net/~slobin `it means just what I choose it to mean'
FW: Adding quotes around html attribute values
Hi,
I've been given some html which, oddly, is half in nicely quoted
attributes+values:
span class=good
and half not
span class=bad
I'm trying to write a regex to add quotes around the ones without. I can
do this in perl, but not in vim, and I'd like to know what I'm doing
wrong because I've run across this problem before.
This was my attempt:
:%s/=\([^]\+\)\{-}\([ ]\)/=\1\2/g
My reasoning:
=\([^]\+\) find and save stuff after an = that does not
have a
\{-}I've never used this before, just found it
online, at first it seemed to do what I want it to do, make the \+
evaluation lazy
\([ ]\)find and save either the space or after the
attribute value
It half works, but sometimes skips spaces and I get tag attrib1=blah
attrib2=duh
Any advice would be appreciated. Perhaps I'm not using \{-} correctly?
Re: FW: Adding quotes around html attribute values
span class=good
and half not
span class=bad
I'm trying to write a regex to add quotes around the ones without. I can
do this in perl, but not in vim, and I'd like to know what I'm doing
wrong because I've run across this problem before.
This was my attempt:
:%s/=\([^]\+\)\{-}\([ ]\)/=\1\2/g
My reasoning:
=\([^]\+\) find and save stuff after an = that does not
have a
\{-}I've never used this before, just found it
online, at first it seemed to do what I want it to do, make the \+
evaluation lazy
Any advice would be appreciated. Perhaps I'm not using \{-} correctly?
You've diagnosed where the problem lies...it's in the interaction
between your greedy
[^]\+
and your non-greedy
\{-}
Greedy wins. :) The latter is an operator like the \+, so you
likely want to convert your top bit to something like
[^]\{-}
or possibly
[^]\{-1,}
(which is one or more, but as few as possible...the embodiment
of your I want to make \+ non-greedy aim)
You can read up on the nuances of \{-} at
:help /\{
If I had to take a crack at it, I'd exploit the greediness rather
than shirk it, and do something like
:%s/=\([^ \t]\+\)/=\1/g
You might even be able to do something like
:%s/=\(\w\+\)/=\1/g
depending on your attributes (what is considered a word
character for an HTML attribute would need to take into
consideration the - and the . at a minimum, but these can
easily be added to the 'iskeyword' setting with :set
iskeyword+=. and :set iskeyword+=-)
The whole thing goes hooey if you have such matches outside tags,
which you might then want to modify your regexp to be something like
:%s/\([^=]*\)=\([^ \t]\+\)/\1=\2/g
which should help to ensure some inside-a-tagness context.
However, it only tidies one attribute for each tag, so you might
have to run it multiple times in the event you have multiple bad
attributes for a given tag like
img src=foo.jpg class=myclass
Just a few ideas that might help. YMMV :)
-tim
Re: VimTips Wiki: New Direction
On Mon, 5 Mar 2007 at 1:26pm, Tom Purl wrote: Here's my view of where we are regarding the Vim Tips wiki conversion project: 1. The Google wiki seems to be a poor option due to the difficulty involved in registering. 2. Multiple other wiki engines have been discussed, and the clear favorite seems to be a site built on top of the Mediawiki application. 3. Of all of the sites that offer free wiki hosting using Mediawiki, Wikibooks seems to be the most favored. Note: These are all my opinions based on what I've read. I hope to hear from everyone that has a different perspective :) Ok, so based on my version of reality, I think that we should proceed with the following actions: 0. I'll create the following page on the Vim Tips chapter of the Vim book on Wikibooks (whew!): * http://en.wikibooks.org/wiki/Learning_the_vi_editor/Vim/TipsSandbox 1. All of the people who wrote tip conversion scripts before should update them so that the output format is Wikipedia markup, not Google markup * I apologize to the script writers for making them do more work. Hopefully, the necessary changes to your scripts will be small. * Also, please note that I _don't_ think that anyone should contribute a new script to this effort. We already have three very capable scripts that can probably get the job done very well, so I don't think that the effort would be worthwhile for anyone else. 2. Convert one tip and post the output on the TipsSandbox page listed above. 3. The vim community will come to a consensus on the best format for the tips, and we will use the best script for the job. 4. Consensus achieved!!! 5. We will automate the task of converting all of the tips. 6. A group of wiki superusers will inspect 50 random tips and make sure that they look good. 7. The invisible hand of The Wiki will then gradually make our wonderful collection of Vim tips even more awesome than they've ever been before! ;D So, what do you guys think? Tom Purl I have been reading posts on this subject with interest and think that this is going to be a good decision. My only concern is on how we are planning to support the existing rating system going forward and if we can enforce a fixed style on commenting such that the comments don't look like a mess. I would imagine that one needs to edit the tip to add their comment at the end, but it will be nice if the comment itself happens as a discussion (which appears as a discussion tab on the same page). -- Thanks, Hari -- Thanks, Hari Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html
Re: Omnicomplete for C - pattern not found problem
I found a partial answer to my question here:
http://tech.groups.yahoo.com/group/vim/message/68078
However, not sure why would the following be declared
as an invalid C code:
struct foo { /* ... */ };
typedef struct foo foo_t;
int main() {
foo myfoo;
/* ... */
}
In fact, I have a lot of instances in the code where
following is used. And what I got from Bram it sounds
omnicompletion will not work!? To me this would be the
most basic thing for omnicomplete to support.
typedef struct foo
{ /* ... */
} foo_t;
int main() {
foo myfoo;
/* ... */
foo. CTRL-xCTRL-o yields with Pattern not
found
}
Need a quick answer? Get one in minutes from people who know.
Ask your question on www.Answers.yahoo.com
Re: VimTips Wiki: New Direction
Hari Krishna Dara wrote: [...] I have been reading posts on this subject with interest and think that this is going to be a good decision. My only concern is on how we are planning to support the existing rating system going forward and if we can enforce a fixed style on commenting such that the comments don't look like a mess. I would imagine that one needs to edit the tip to add their comment at the end, but it will be nice if the comment itself happens as a discussion (which appears as a discussion tab on the same page). -- Thanks, Hari Comments can go on the wiki talk page associated with a given tip. If you look at talk pages on ??.wikipedia.org, you'll see that in practice they mostly adhere to a rather uniform format. If the case warrants, part or all of the comments can later be incorporated (by the tip author or maintainer) into the main page of the tip. Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 88. Every single time you press the 'Get mail' button...it does get new mail.
Re: Omnicomplete for C - pattern not found problem
Hi,
You can try this C++ omnicomplete plugin
http://www.vim.org/scripts/script.php?script_id=1520
It will work for C files if you copy the file
~/.vim/after/ftplugin/cpp.vim to ~/.vim/after/ftplugin/c.vim (I'll
add it for the next release).
Best regards,
Vissale
2007/3/6, Zarko Coklin [EMAIL PROTECTED]:
I found a partial answer to my question here:
http://tech.groups.yahoo.com/group/vim/message/68078
However, not sure why would the following be declared
as an invalid C code:
struct foo { /* ... */ };
typedef struct foo foo_t;
int main() {
foo myfoo;
/* ... */
}
In fact, I have a lot of instances in the code where
following is used. And what I got from Bram it sounds
omnicompletion will not work!? To me this would be the
most basic thing for omnicomplete to support.
typedef struct foo
{ /* ... */
} foo_t;
int main() {
foo myfoo;
/* ... */
foo. CTRL-xCTRL-o yields with Pattern not
found
}
Need a quick answer? Get one in minutes from people who know.
Ask your question on www.Answers.yahoo.com
RE: VimTips Wiki: New Direction
From: Hari Krishna Dara, Tue, March 06, 2007 11:33 am My only concern is on how we are planning to support the existing rating system going forward I don't see how this can be accomplished in a wiki, but on the plus side we'll be able to categorize and structure the tips better, as well as link between. and if we can enforce a fixed style on commenting such that the comments don't look like a mess. I would imagine that one needs to edit the tip to add their comment at the end, but it will be nice if the comment itself happens as a discussion (which appears as a discussion tab on the same page). I agree, is there any way the porting process can push comments to each tip's respective discussion tab? -- Steve Hall [ digitect dancingpaper com ]
Re: FW: Adding quotes around html attribute values
On Tue, Mar 06, 2007 at 11:04:11AM -0500, Timothy Adams wrote: Hi, I've been given some html which, oddly, is half in nicely quoted attributes+values: Have you considered using a tool that is designed to fix up your html? Such as HTML Tidy? -- Bill Moseley [EMAIL PROTECTED]
RE: FW: Adding quotes around html attribute values
Yes, there are tools, but I had it open in vim for editing already,
anyways.
Plus, the \{- is something I've been missing out on for a long time, so
I'm glad I got it sorted out now.
Tim's solutions all worked well.
(the other) *tim*
-Original Message-
From: Bill Moseley [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 06, 2007 2:49 PM
To: vim@vim.org
Subject: Re: FW: Adding quotes around html attribute values
On Tue, Mar 06, 2007 at 11:04:11AM -0500, Timothy Adams wrote:
Hi,
I've been given some html which, oddly, is half in nicely quoted
attributes+values:
Have you considered using a tool that is designed to fix up your html?
Such as HTML Tidy?
--
Bill Moseley
[EMAIL PROTECTED]
Re: VimTips Wiki: New Direction
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6-Mar-07, at 3:34 PM, Denis Perelyubskiy wrote: On Tue, 06 Mar 2007 11:31:53 -0700, Steve Hall [EMAIL PROTECTED] said: From: Hari Krishna Dara, Tue, March 06, 2007 11:33 am and if we can enforce a fixed style on commenting such that the comments don't look like a mess. I would imagine that one needs to edit the tip to add their comment at the end, but it will be nice if the comment itself happens as a discussion (which appears as a discussion tab on the same page). I agree, is there any way the porting process can push comments to each tip's respective discussion tab? why don't we discuss that here: http://en.wikibooks.org/wiki/Talk:Learning_the_vi_editor/Vim/ TipsSandbox/Tip_1:_the_super_star :-) Seriously though, as I had mentioned on the discussion page, for me as a user of the tip, it is horribly counter-productive to go and read twenty-five thousands comments on a page. I'd much rather just read a perfect tip. This assumes, of course, that tip contributors care about me as a user. I hope they do :) Wikipedia model seems to work great. One page. All the information. Discussion on a separate page. One change: if it matters, we could reserve a line (or two) for a list of contributors. This information is available from the history page for those who care to look anyway, but maybe people care about their names being mentioned. Finally, on the subject of converting the comments - it is entirely a manual process, that can not be automated. Comments need to be integrated into the body of the main tip (maybe the tip needs to be adjusted, reworded, etc). We should just push out the existing pages, and then set to work on reworking the tips by hand. Eventually we'll be done. In any case, I think this will be an extremely useful resource (especially if we could then put VIM's documentation on there, and cross-link) One of the first things I was thinking about mirrors the above comments. http://en.wikibooks.org/wiki/Talk:Learning_the_vi_editor/Vim/ TipsSandbox/Tip_1:_the_super_star has a bunch of thanks for the great tip! type comments with more useage info interspersed. I think those 'great tip' comments go to a separate page, while the 'use # or % instead' kind of comments need to be edited into the actual tip itself. I don't think that can be automated though - so the question is comments to a separate page and edited back in? or all on one page and edited over to the secondary page... Brian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) Comment: Verify this email or encrypt your email for free - see gnupg.org iD8DBQFF7dUhGnOmb9xIQHQRAlpVAJ45MZO4aj5DMVxdnN2Kvd85g6PoAwCff2AG KdJM5sFvk/OcuLBVTVGeF6Q= =MnvL -END PGP SIGNATURE-
RE: VimTips Wiki: New Direction
On Tue, March 6, 2007 2:34 pm, Denis Perelyubskiy wrote: Finally, on the subject of converting the comments - it is entirely a manual process, that can not be automated. Comments need to be integrated into the body of the main tip (maybe the tip needs to be adjusted, reworded, etc). We should just push out the existing pages, and then set to work on reworking the tips by hand. Eventually we'll be done. I agree mostly. The process of moving the tips from vim.org to the wiki host can be automated. Ideally, I also think that it would be a good idea to refactor some comments into the body of some tips, but I certainly don't think that it's necessary for every tip. For example, I wrote tip number 1280 which, in hindsight, is pretty lame. My tip has one comment from someone who agrees that my tip is lame :) Also, I imagine that about 5 people a year read this tip, and those people probably were looking for something else anyways. In that situation, do we *really* need to merge the comment with the tip? No one uses the tip, and the comment's pretty pointless. Why don't we just ignore it? On the other hand, there are some tips that are used hundreds of times a week. These tips will probably be refactored and updated very quickly due to the sheer number of eyeballs reading it. So I guess what I'm saying is, what's wrong with waiting for the community to refactor these tips using guidelines from the wikibook admins? Thanks! Tom Purl
RE: VimTips Wiki: New Direction
On Tue, 6 Mar 2007 15:00:30 -0600 (CST), Tom Purl [EMAIL PROTECTED] said: On Tue, March 6, 2007 2:34 pm, Denis Perelyubskiy wrote: Finally, on the subject of converting the comments - it is entirely a manual process, that can not be automated. Comments need to be integrated into the body of the main tip (maybe the tip needs to be adjusted, reworded, etc). We should just push out the existing pages, and then set to work on reworking the tips by hand. Eventually we'll be done. [snip] So I guess what I'm saying is, what's wrong with waiting for the community to refactor these tips using guidelines from the wikibook admins? Sorry, was not clear. That's what I am arguing for as well. I am not saying let's have admins do all the work before the site goes live. I am saying let's leave things the way they are, provide a template, and slowly set about refactoring tips (encouraging users to do the same). I haven't checked, but if there is a wikipedia-style this page still needs your attention notification that can be placed on the page, we could do that as well. so, i propose we move to agreeing what the format should be. -denis
To imap or to iabbr
Hi, What is the difference between imap or iabbr? Or in other words, when should you use imap and when to iabbr? Rgds, Eric _ Find what you need at prices youll love. Compare products and save at MSN® Shopping. http://shopping.msn.com/default/shp/?ptnrid=37,ptnrdata=24102tcode=T001MSN20A0701
Re: VimTips Wiki: New Direction
On Tue, 2007-03-06 at 18:38 +0200, Ali Polatel wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Zdenek Sekera ([EMAIL PROTECTED]) wrote: -Original Message- From: Spencer Collyer [mailto:[EMAIL PROTECTED] Sent: 06 March 2007 08:31 Cc: Vim Mailing List Subject: Re: VimTips Wiki: New Direction On Tue, 6 Mar 2007 03:18:13 +0200, Ali Polatel wrote: And check out http://en.wikibooks.org/wiki/Learning_the_vi_editor/Vim/TipsSandbox to see how it parsed tip #1. Looks good. Only comment I have is it might be better if the 'By' and 'On' lines for the comments were on the same line. Anything that allows more useful info on a screen at once is an improvement in my eyes. Done. Yes, I very much agree, use screen real estate for useful info as much as possible. Otherwise good IMHO! If I might add my impression: Generally I think it is indeed quite likable. Just some thoughts : Looking at : http://en.wikibooks.org/wiki/Learning_the_vi_editor/Vim/TipsSandbox/Tip_1:_the_super_star my thoughts: 1. focus/structure: At the moment there is a bit of a lack of focus when I look at the page. The eye-catcher is more or less the box with the author/creator/etc meta information. The focus should however be on the actual text/body of the tip. So maybe the text should be in a (differently colored?) box to gain more attention and separate it from comments and meta info etc. Same goes with the info boxes for comments on the tip and the comments contents. I'd also suggest to maybe separate tips with horizontal lines (maybe even removing the info boxes..) Also what about perhaps indenting the comments a bit to the right? 2. formatting: I think tex is right with its default formatting in which line length is rather short. I think it would be nice if line breaks could be added ? However while typing this I realize that this would suck when you break up code.. I realize that currently it's still about figuring out how to properly parse/convert the content etc.. just wanted to shout out what I have on my mind about it. thanks to those doing all the work, looking forward to use the wiki-tips already.. regards, Tobi
Re: To imap or to iabbr
What is the difference between imap or iabbr? Or in other
words, when should you use imap and when to iabbr?
Sometimes, they have similar results, while other times they have
disjoint purposes. My general guidline:
- use :iab only those times when expanding some short text into
some long text. This is mostly in line with the meaning of
abbreviation.
-If there's any sort of action/movement involved, use a mapping.
How they're triggered also plays into matters. If I do something
like
:iab IU International Units
It won't get expanded if I type HELIUM. However, if I do a
mapping:
:inoremap IU International Units
and attempt to type HELIUM, I'll get HELInternational UnitsM
Multi-character mappings also have a slight delay in them, so in
the preceeding example, after I type HELI, there's a slight
pause while Vim sees if I am going to type U, or if I type
something else, so it knows how to behave.
Things get slightly more complex if you're writing code-block
expansions such as wanting IF to expand to
if (|) {
} else {
}
and put the cursor where the | is. It involves an expansion
(and thus suggests an :iab for the expansion) but also involves
moving the cursor to a particular position. I've not had luck
doing those as :iab expansions, so I resort to mappings...usually
prefixing them with an infrequently used character such as
control+G or a tilde as fits.
Just my $0.02USD
-tim
RE: VimTips Wiki: New Direction
On Tue, 06 Mar 2007 13:24:09 -0800, Denis Perelyubskiy [EMAIL PROTECTED] said: [snip] so, i propose we move to agreeing what the format should be. ..and after thinking about this a bit more: - format? - karma/rating (i think someone already brought it up). How do we do this here? The use seems to be that you can browse by scores. Do people do this? Would the tips maybe just become intrinsically useful by nature of being edited by many people? - difficulty - do we need this? what's the use-case for that? do people come looking for easy tips? it appears they may be looking for a) useful tips (item above), or for b) tips applicable to their situation (tag-related tips). - date. who cares? anything else? -denis
Re: VimTips Wiki: New Direction
My apologies for barging in this discussion this late. However, I wanted to make sure all alternatives are being given a fair chance. It seems that wikibooks.org is the most popular choice. I just want to throw out a couple of other free, hosted Wiki alternatives for people to look at: o http://pbwiki.com/ http://yummy.pbwiki.com/ o http://jot.com (acquired by Google). Sample wiki http://dojo.jot.com/WikiHome o http://wikia.com -- like wikibooks, uses mediawiki o http://wikispaces -- run of the mill o http://www.wetpaint.com/ o http://www.wikidot.com/ I really like pbwiki and jot. Finally, this has been voiced before and I just wanted to add my 2c -- I'm not sure if a general purpose Wiki is the best solution for something as specific as a collection of Tips. The notion of rating, comments etc doesn't come naturally to a Wiki. IMHO, the best solution is to setup a blog. There are several free Wordpress based blog services. There are several free Wordpress plugins to implement rating for posts, most popular posts and such. Commenting is built in. The more I think about it, the more it seems like the perfect solution to me. Thoughts? Diwaker -- Web/Blog/Gallery: http://floatingsun.net/blog
RE: VimTips Wiki: New Direction
On Tue, 6 Mar 2007 at 12:34pm, Denis Perelyubskiy wrote: On Tue, 06 Mar 2007 11:31:53 -0700, Steve Hall [EMAIL PROTECTED] said: From: Hari Krishna Dara, Tue, March 06, 2007 11:33 am and if we can enforce a fixed style on commenting such that the comments don't look like a mess. I would imagine that one needs to edit the tip to add their comment at the end, but it will be nice if the comment itself happens as a discussion (which appears as a discussion tab on the same page). I agree, is there any way the porting process can push comments to each tip's respective discussion tab? why don't we discuss that here: http://en.wikibooks.org/wiki/Talk:Learning_the_vi_editor/Vim/TipsSandbox/Tip_1:_the_super_star :-) Seriously though, as I had mentioned on the discussion page, for me as a user of the tip, it is horribly counter-productive to go and read twenty-five thousands comments on a page. I'd much rather just read a perfect tip. This assumes, of course, that tip contributors care about me as a user. I hope they do :) Wikipedia model seems to work great. One page. All the information. Discussion on a separate page. One change: if it matters, we could reserve a line (or two) for a list of contributors. This information is available from the history page for those who care to look anyway, but maybe people care about their names being mentioned. Finally, on the subject of converting the comments - it is entirely a manual process, that can not be automated. Comments need to be integrated into the body of the main tip (maybe the tip needs to be adjusted, reworded, etc). We should just push out the existing pages, and then set to work on reworking the tips by hand. Eventually we'll be done. In any case, I think this will be an extremely useful resource (especially if we could then put VIM's documentation on there, and cross-link) I agree, without updating the original tip based on the feedback from comments, it is incredibly painful to go through all the comments and get best out of it. In fact, currently, when you read comments, what you are looking for a ways to improve the original tip, not those that just complement it. From this regard, the comments are more of discussions to improve the tip. Since the wiki model allows for anyone to go and modify the tip, it will be interesting to see how a tip will be modified once the discussion results in multiple ways to improve it. I guess you can then accommodate multiple solutions right in the tip. -- Thanks, Hari It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. http://tools.search.yahoo.com/toolbar/features/mail/
Re: VimTips Wiki: New Direction
On Tue, 6 Mar 2007 15:23:41 -0800, Diwaker Gupta [EMAIL PROTECTED] said: [snip] IMHO, the best solution is to setup a blog. There are several free Wordpress based blog services. There are several free Wordpress plugins to implement rating for posts, most popular posts and such. Commenting is built in. The more I think about it, the more it seems like the perfect solution to me. Thoughts? I think blog does not quite work. One would have to consider an ultimate goal - provide a collection of accessible and maintainable tips to ease people's interaction with a wonderful yet nightmarishly-complicated vim editor :) There are tasks towards that goal: - reducing spam (to enable 'accessibility') in a non-burdernsome way (to enable maintainability) - enable ratings (acessibility) - format (yet again, accessibility) - maybe i am missing something here - This is why I argue that notion of commenting runs a bit counter to the goal of accessibility for the tips. It requires one to read through the tip, then go on to read what other people are saying about the tip. Why would not those other people just edit the tip directly? There are administrators to prevent absurdity from ensuing (witness, for example, the Scooter Libby page on wikipedia) You bring up a good point about a problem with rating tips though. I am not sure how to solve that with a wiki. Frankly, I am not even sure (yet) whether it is an important task that needs to be solved. Does this enable more accessible tips? Maybe. (maybe something along the 'digg' lines?) There must be a way to host a digg/reddit-like thing on sourceforge, and put a little dugg N times thing on the page, and then a link to search. Especially if this is a non-essential thing, we could probably afford to host it on a less reliable infrastructure? anyway, these are just my thoughts on the matter. I am sure there are people who are much more qualified who can comment. -denis
I want to map 't h i s' message
Using many colorschemes 't h i s' message appears yellow and is therefore hardly to read inside of a light background cterm. Auslagerungsdatei .post.swp ist bereits vorhanden! Nur zum [L]esen ffnen, Trotzdem (e)ditieren, (W)iederherstellen, (B)eenden, (A)bbrechen: After a long long time of trial and error mapping of all sorts of messages I didn't find how it is called in vim. I only could find how it is not called.
Re: VimTips Wiki: New Direction
On Tue, Mar 06, 2007 at 06:45:51PM +1100, John Beckett wrote: Tom Purl wrote: I looked into the anti-spam features of Wikibooks, and they basically do the basics: blacklists for abusers and easy rollbacks. So the top 2% of spammers/vandalizers will be blocked, and it will be easy for the admins to roll back the problems created by the outher 98%. Wikibooks sounds good. I wonder if it would be worth looking for a volunteer to occasionally take a snapshot of the wiki as an emergency backup. Presumably wget or similar would be adequate, or maybe there is an easy way to get the mediawiki source. Such a backup might be useful in a few weeks, and then perhaps monthly. John Back-ups are better made on the server side. For mediawiki a regular sqldump (maybe added in crontab) is all that is necessary.
