Re: breakindent, take 2
Yakov Lerner wrote: On 5/14/07, Václav Šmilauer [EMAIL PROTECTED] wrote: Hello, I submit patch that implements the 'breakindent' feature. It is on vim todo list, since the moment I tried a few years ago (see e.g. http://marc.info/?l=vim-devm=109921292009721w=1). Picture says what it's about (showbreak is aligned with first non-whitespace): http://beta.arcig.cz/~eudoxos/vim7/breakindent1.png http://beta.arcig.cz/~eudoxos/vim7/breakindent2.png I tried to address all Bram's comments he had to the original patch, like coding style, functionality in diff mode, selections etc. I had to change a few prototypes to pass line number. There is one bug and some (easily fixable) limitations: * BUG: there is some weird interaction with quickfix window, where very rarely there is the ml_get(): invalid line number error. I think it is caused by passing wrong line number thgouth the *chartabsize* family routines (line in the main buffer interpreted as line in the quickfix window or something like that), but I am not sure. * No test case. This will be added once there is enough interest from developers (there _is_ documentation). * The bri_min variable is not exposed to userspace yet, is set to 20 in the code. If the rest is considered ready for inclusion, I will add a user-serrable variable for that. The patch is against current svn (vim7, rev. 288). Any comments are welcome. I played with the patch. Works smoothly, I did not find any deficiencies. I have one wish though. It would be nice if I could specificy additional indent for continuation lines. You make indent for continuation line *EQUAL* to indent of the 1st screen line. Let's say you have 3 consequitive long lines with same indent, and each lines wrapped into 4 screen lines. With current 'breakindent' patch, you see 8 lines with *same* indent. It's not that easy to see beginning of each long lines. If breakindent would be numeric value N which meant assign indent K+N to continuation indent, where K is indent of the line itself. Current breakindent corresponds to N==0. But I'd probably prefer N=1 or N==2. Just my 2 cents Thanks Yakov ** nobreakindent line1line1line1line1 line1line1line1line line2line2line2line2 line2line2line2line ** breakindent=0 line1line1line1line1 line1line1line1line line2line2line2line2 line2line2line2line ** breakindent=2 line1line1line1line1 line1line1line1line line2line2line2line2 line2line2line2line ** With this change plus 'linebreak' on, it could be made to simulate French paragrah style for text, where the first line of a paragraph starts maybe 1em or so right of the left margin (but with no blank line, unlike American paragraph style which uses flush-left alignment with a blank line between paragraphs). Thus breakindent=0 flush left (as above) breakindent=-3 French style with first line indented 3 spaces, as follows: The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. Line two starts here; neither line goes back to the left margin of the Vim window. The lazy dog is jumped over by the quick brown fox. The lazy dog is jumped over by the quick brown fox. The lazy dog is jumped over by the quick brown fox. breakindent=2 all lines except the first indented 2 spaces (as you show above) A single option cannot be both boolean and integer; if a negative number is greater than the 1st line indent, don't go back farther left than the left margin of the window; thus breakindent=-999 would agree with your first example. Best regards, Tony. -- Sex is a natural bodily process, like a stroke.
Re: A performance question (patch included)
Charles E Campbell Jr wrote: A.J.Mechelynck wrote: I'm not sure what varnumber_T means: will st.stsize (the dividend) be wide enough to avoid losing bits on the left? varnumber_T is int (long if an sizeof(int) = 3). st.stsize 's size depends on whether 32bit or 64bit integers are available. So, its possible to lose bits: pick a small enough unitsize and a large enough file, st.stsize will end up not being able to fit into a varnumber_T. After all, unitsize could be 1, and getfsize() will behave no differently than it does now. However, unitsize could be 100. My patch divides st.stsize by the unitsize first; presumably in whatever arithmetic is appropriate for working with st.stsize. Regards, Chip Campbell Yes, yes, but before the division, will it be able to hold the file size? (sorry, I meant st.st_size) Will mch_stat (at line 10134, one line before the context of your patch) be able to return huge file sizes? Best regards, Tony. -- Real Programmers don't play tennis, or any other sport that requires you to change clothes. Mountain climbing is OK, and real programmers wear their climbing boots to work in case a mountain should suddenly spring up in the middle of the machine room.
Re: A performance question (patch included)
Yakov Lerner wrote: [...] stat() on Linux has 32-bit st_size field (off_t is 32-bit). There is stat64() syscall which uses 'struct stat64' structure where st_size is 64-bit. By defining __USE_LARGEFILE64 at compile-time, stat() is redirected to stat64(). I don't know whether default Linux vim build defines __USE_LARGEFILE64 or not. Yakov :version says: [...] Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -I/usr/include/cairo -I/usr/include/freetype2 -I/usr/include/libpng12 -I/opt/gnome/include/gtk-2.0 -I/opt/gnome/lib/gtk-2.0/include -I/opt/gnome/include/atk-1.0 -I/opt/gnome/include/pango-1.0 -I/opt/gnome/include/glib-2.0 -I/opt/gnome/lib/glib-2.0/include -DORBIT2=1 -pthread -I/usr/include/libart-2.0 -I/usr/include/cairo -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/libxml2 -I/opt/gnome/include/libgnomeui-2.0 -I/opt/gnome/include/libgnome-2.0 -I/opt/gnome/include/libgnomecanvas-2.0 -I/opt/gnome/include/gtk-2.0 -I/opt/gnome/include/gconf/2 -I/opt/gnome/include/libbonoboui-2.0 -I/opt/gnome/include/gnome-vfs-2.0 -I/opt/gnome/lib/gnome-vfs-2.0/include -I/opt/gnome/include/gnome-keyring-1 -I/opt/gnome/include/glib-2.0 -I/opt/gnome/lib/glib-2.0/include -I/opt/gnome/include/orbit-2.0 -I/opt/gnome/include/libbonobo-2.0 -I/opt/gnome/include/bonobo-activation-2.0 -I/opt/gnome/include/pango-1.0 -I/opt/gnome/lib/gtk-2.0/include -I/opt/gnome/include/atk-1.0 -O2 -fno-strength-reduce -Wall -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/lib/perl5/5.8.8/i586-linux-thread-multi/CORE -I/usr/include/python2.5 -pthread -I/usr/include -D_LARGEFILE64_SOURCE=1 -I/usr/lib/ruby/1.8/i586-linux Linking: [...] so, maybe we'll have to check what happens when _LARGEFILE64_SOURCE is defined? I don't find a match in src/ or src/auto/. Best regards, Tony. -- If all these sweet young things were laid end-to-end, I wouldn't be a bit surprised. -- Dorothy Parker
doc bug: 'browsedir'
In
*options.txt* For Vim version 7.1. Last change: 2007 May 11
under 'browsedir', at line 1151, there is:
{not in Vi} {only for Motif and Win32 GUI}
Actually, this option is functional in my GTK2/Gnome GUI.
Best regards,
Tony.
--
The day after tomorrow is the third day of the rest of your life.
Re: [Fwd: Re: compiling vim7.1 (huge version) gets build with normal version]
Stephan Hegel wrote: Hi, A.J.Mechelynck wrote: - Using cat is OK as long as you can be sure that you'll get them in numeric order: this is usually the case on Unix but not necessarily on Dos, where a wildcarded filename usually gets its results in directory order, not sorted by filename. Well, you are right: I'm on Linux and wasn't aware of the different DOS sorting order. So, the following below applies to Linux/Unix only ... - By patching individually, if one of the patches fails horribly you may decide not to try the following. - Usually there aren't more than a handful of _new_ patches anyway, so (except when starting from scratch with many patches already published) it's hardly worth the trouble going to a cat step. What you have described even on your Web page, IMHO still too much manual work. After downloading new patches with ncftp I just type make all with the following Makefile: - PREFIX=/usr/local help: @echo Available targets: @echoall @echoinstall @echoclean all: clean tar xfj vim-7.1.tar.bz2 tar xfz vim-7.1-lang.tar.gz tar xfz vim-7.1-extra.tar.gz cat vim-7.1.patches/7.1.* patchfile (cd vim71 ; patch -p0 ../patchfile) (cd vim71 ; ./configure --prefix=$(PREFIX) --with-x --enable-gui=gtk2 --enable-multibyte --enable-xim --enable-fontset --enable-perlinterp --enable-cscope make) install: (cd vim71; umask 022; installwatch -o /home/steve/install.log/vim-7.1.log make install) chmod 644 /home/steve/install.log/vim-7.1.log clean: rm -rf patchfile rm -rf vim71 .PHONY: help all install clean -- ... and everything is done in less than 150 sec. Works for me for a long time and starting from scratch keeps me out of trouble with old objects, etc. Should not happen with make ... yes, this is what optimists always say, but there is still Murphy ;). BTW, make should stop when patch or any other action fails. Interesting would be an extension to download the patches automagically. Comments ideas ? Regards, Stephan. Comments: - Since on Linux I build only one version of Vim (a full-featured GUI-enabled executable which can also run in console mode) I prefer to keep already-built objects, doing what the Mozilla guys call a depend build rather than a clobber build (which is what you do). I've found that it spares quite a lot of time, finishing in a few seconds rather than a few minutes. - When I really need a clobber build (because my configuration has changed), then I do make reconfig in the src subfolder. - After make clean, make will invoke configure, you don't need to run it separately. (I keep my configure options in a separate script, which I source in bash to set the required environment variables.) - What is ncftp? On my openSUSE 10.2 system I have a program called ftp but none called ncftp. Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 241. You try to look for Net Search even when you're in File Manager.
Re: [Fwd: Re: compiling vim7.1 (huge version) gets build with normal version]
Stephan Hegel wrote: A.J.Mechelynck wrote: - What is ncftp? On my openSUSE 10.2 system I have a program called ftp but none called ncftp. [39]./home/steve: rpm -qi ncftp Name: ncftpRelocations: (not relocatable) Version : 3.1.9 Vendor: SUSE LINUX Products GmbH, Nuernberg, Germany Release : 2 Build Date: Fri 09 Sep 2005 06:15:16 PM CEST Install date: Sun 16 Oct 2005 06:07:57 AM CEST Build Host: berlioz.suse.de Group : Productivity/Networking/Ftp/Clients Source RPM: ncftp-3.1.9-2.src.rpm Size: 1038391 License: Artistic License Signature : DSA/SHA1, Fri 09 Sep 2005 06:52:45 PM CEST, Key ID a84edae89c800aca Packager: http://www.suse.de/feedback URL : http://www.ncftp.com/ Summary : A Comfortable FTP Program Description : This program has been in service on UNIX systems since 1991 and is a popular alternative to the standard FTP program, /usr/bin/ftp. NcFTP offers many ease-of-use and performance enhancements over the stock FTP client, and runs on a wide variety of UNIX platforms as well as operating systems such as Microsoft Windows and Apple Mac OS X. Authors: Mike Gleason [EMAIL PROTECTED] Distribution: SUSE LINUX 10.0 (i586) Regards, Stephan. Well, AFAICT it has disappeared between SuSE 10.0 and 10.2. I have packages named lftp and lukemftp (which are installed); YaST also shows, among FTP clients, gftp, tftp and yafc; but the only available packages (in category zzzAll) whose name starts nc are ncpfs, ncurses and ncurses-devel. /usr/bin/ftp is actually a link, /bin/ftp - /etc/alternatives/ftp - /usr/bin/pftp where pftp comes from the lukemftp package which is the enhanced ftp client in NetBSD Best regards, Tony. -- How do you like the new America? We've cut the fat out of the government, and more recently the heart and brain (the backbone was gone some time ago). All we seem to have left now is muscle. We'll be lucky to escape with our skins!
Cannot print in UTF-8?
:set enc? penc? encoding=utf-8 printencoding=utf-8 :%ha not found in runtimepath: print/utf-8.ps Is this last message normal? I have here a file including an Esperanto-French glossary, which contains both the consonants+circumflex of Esperanto and the French oe ligature. No matter how I try, Vim cannot print it: - penc=utf-8 gives the above error - penc=latin3 prints Esperanto correctly, but oe becomes an inverted question mark - penc=latin9 prints French correctly but not the Esperanto letters. Compiled with +multi_byte +iconv +printer +postscript Looks like the only way to print that file properly is to load it in my browser. Best regards, Tony. -- When I said we, officer, I was referring to myself, the four young ladies, and, of course, the goat. PreÄ|o sub la verd|a standard|o 1. Al Vi, ho potenc|a sen|korp|a mister|o, Fort|eg|o, la mond|o|n reg|ant|a, Al Vi, grand|a font|o de l'am|o kaj ver|o Kaj font|o de viv|o konstant|a, Al Vi, kiu|n Äiu malsame prezent|as, Sed egal|e Äiu|j en kor|o Vi|n sent|as, Al Vi, kiu kre|as, al Vi, kiu reÄ|as, HodiaÅ ni preÄ|as. 2. Al vi ni ne ven|as kun kred|o naci|a, Kun dogm|o|j de blind|a fervor|o; Silent|as nun Äiu disput' religi|a, Kaj reg|as nur kred|o de kor|o. Kun Äi, kiu est|as Äe Äiu|j egal|a, Kun Äi, la plej ver|a, sen trud|o batal|a, Ni star|as nun, fil|o|j de l'tut|a hom|ar|o Äe Vi|a altar|o. 3. Hom|ar|o|n Vi kre|is perfekt|e kaj bel|e, Sed Äi si|n divid|is batal|e; Popol|o popol|o|n atak|as kruel|e, Frat' frat|o|n atak|as Åakal|e. Ho, kiu ajn est|as Vi, fort|o mister|a, AÅskult|u la voÄ|o|n de l'preÄ|o sincer|a, Re|don|u la pac|o|n al la infan|ar|o De l'grand|a hom|ar|o! 4. Ni ĵur|is labor|i, ni ĵur|is batal|i, Por re|unu|ig|i l'hom|ar|o|n. Sub|ten|u ni|n, Fort|o, ne las|u ni|n fal|i, Sed las|u ni|n venk|i la bar|o|n; Donac|u Vi ben|o|n al ni|a labor|o, Donac|u Vi fort|o|n al ni|a fervor|o, Ke Äiam ni kontraÅ atak|o|j sovaÄ|a|j Ni|n ten|u kuraÄ|a|j. 5. La verd|a|n standard|o|n tre alt|e ni ten|os; Äi sign|as la bon|o|n kaj bel|o|n. La Fort|o mister|a de l'mond|o ni|n ben|os, Kaj ni|a|n ating|os ni cel|o|n. Ni inter popol|o|j la mur|o|n detru|os, Kaj ili ek|krak|os kaj ili ek|bru|os Jaj fal|os por Äiam, kaj am|o kaj ver|o Ek|reg|os sur ter|o. Prononciation - L'accent tonique tombe toujours sur l'avant-dernière syllabe: potènca senkòrpa mistèro a,b,d,f,i,k,l,m,n,p,s,t,v,z : comme en français c = ts dans tsar Ä = tch dans catch, Tchantchès e = e dans cette; ai dans vrai g = g gans garçon; gu dans guerre Ä = dj dans Djerba, djinn h = comme dans les langues germaniques Ä¥ = comme ch allemand dans Bach, ch écossais dans loch, ch yiddisch dans chutzpa, j espagnoj dans jota j = comme y dans yole ĵ = comme j dans jardin o = comme o dans botte r = légèrement roulé, comme en espagnol Å = comme ch dans chant, chez, choix, pacha, chichi u = comme ou dans flou, bout, ouvrir Å = (généralement après voyelle) semi-voyelle oué L'alphabet: Aa Bb Cc ÄÄ Dd Ee Ff Gg ÄÄ Hh Ĥĥ Ii Jj Ĵĵ Kk Ll Mm Nn Oo Pp Rr Ss ÅÅ Tt Uu ŬŠVv Zz qui se lit: a, bo, tso, tcho, do, é, fo go, djo, ho, kho, i, yo, jo ko, lo, mo, no, o, po, ro so, cho, to, ou, wo, vo, zo. Vocabulaire --- -' (élision):voir -o -a (adjectif) ajn ...que ce soit al à alt(a) haut altar(o) autel am(i) aimer -aro (un ensemble de...) -as (temps présent) -ant- (participe présent actif) atak(i) attaquer ating(i) atteindre aÅskult(i) écouter bar(i) barrer batal(o) bataille,combat bel(a) beau ben(i) bénir blind(a) aveugle bon(a) bon (adj.) bru(o) bruit Äe chez;auprès de Äiam toujours Äiu chacun; (au pluriel) tous de de detru(i) détruire disput(o) dispute divid(i) diviser don(i) donner donac(o) cadeau dogm(o) dogme -e (adverbe) -eg- augmentatif egal(a) égal ek- (action subite) en en,dans est(i) être fal(i) tomber fervor(o) ferveur fil(o) fils font(o) source fort(a) fort frat(o) grand(a) grand Äi il,elle(chose) ho 1.à 2.oh! hodiaÅ aujourd'hui hom(o) être humain -i (infinitif) -ig(i) (factitif) faire (+infinitif), rendre (+attribut du c.o.d.), changer (en...) ili ils,elles infan(o) enfant inter entre (prép.) -is (passé) -j (pluriel) ĵur(i) jurer, faire serment de kaj et ke que (conj. de sub.) kiu qui?(pronom),quel?(adjectif)(interrogatif-relatif) konstant(a) constant kontraÅ contre kor(o) cÅur korp(o) corps krak! crac! kre(i) créer kred(i) croire kruel(a) cruel kun avec kuraÄ(o) courage la,l' la labor(i) travailler las(i) laisser mal- (le contraire de) mister(o) mistère mond(o) monde mur(o) mur -n (marque le c.o.d. ou le lieu où l'on va) naci(o) nation ne non,ne pas ni nous nun maintenant nur seulement -o,-' (substantif) -os (futur) pac(o) paix perfekt(a) parfait plej le plus (superlatif) popol(o) peuple por pour potenc(o) puissance preÄ(i) prier prezent(i) présenter re- re- reg(i) gouverner reÄ(o) roi religi(o) religion sam(a) pareil,même sed mais sen sans sent(i) sentir si soi sign(o)
Re: [Fwd: Re: compiling vim7.1 (huge version) gets build with normal version]
scott wrote: [...] ncftp should have popped right up for you -- what do you have in Configured Software Catalogs (under installation sources)? sc Status Refresh Name URL On On YaST iso:///?iso=openSUSE-10.2-GM-DVD-i386.isourl=hd:///?device=/dev/hda2filesystem=auto On On YUM http://gd.tuwien.ac.at/linux/suse.com/suse/update/10.2 On On YUM http://ftp.hosteurope.de/mirror/ftp.suse.com/pub/suse/update/10.2 [x] Synchronize changes with ZENworks Anyway, ftp (aka pftp from the lukemftp package), and occasionally lftp, are good enough for me. Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 242. You turn down a better-paying job because it doesn't come with a free e-mail account.
[Fwd: Re: compiling vim7.1 (huge version) gets build with normal version]
Forward to vim-dev list. See my comments at bottom.
Original Message
Subject: Re: compiling vim7.1 (huge version) gets build with normal version
Date: Tue, 15 May 2007 08:14:28 -0700
From: Tushar Desai [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: A.J.Mechelynck [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
[EMAIL PROTECTED]
HI Tony,
I tried what you suggested, but now I'm getting this really weird
compile error (I'm compiling on ubuntu 7.04 with gnome 2.0)
gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
-I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include
-I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
-I/usr/include/freetype2 -I/usr/include/libpng12 -DORBIT2=1 -pthread
-I/usr/include/libgnomeui-2.0 -I/usr/include/libgnome-2.0
-I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0
-I/usr/include/libart-2.0 -I/usr/include/gconf/2
-I/usr/include/libbonoboui-2.0 -I/usr/include/gnome-vfs-2.0
-I/usr/lib/gnome-vfs-2.0/include -I/usr/include/gnome-keyring-1
-I/usr/include/orbit-2.0 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/libbonobo-2.0
-I/usr/include/bonobo-activation-2.0 -I/usr/include/pango-1.0
-I/usr/include/freetype2 -I/usr/lib/gtk-2.0/include
-I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/libpng12
-I/usr/include/libxml2 -O2 -fno-strength-reduce -Wall
-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-I/usr/lib/perl/5.8/CORE -I/usr/include/python2.5 -pthread
-I/usr/include/tcl8.4 -D_REENTRANT=1 -D_THREAD_SAFE=1
-D_LARGEFILE64_SOURCE=1 -I/usr/lib/ruby/1.8/i486-linux -o
objects/gui_gtk.o gui_gtk.c
In file included from /usr/include/glib-2.0/glib/gi18n.h:23,
from /usr/include/libbonobo-2.0/bonobo/bonobo-i18n.h:37,
from /usr/include/libgnome-2.0/libgnome/gnome-i18n.h:41,
from /usr/include/libgnome-2.0/libgnome/libgnome.h:30,
from /usr/include/libgnomeui-2.0/gnome.h:5,
from gui_gtk.c:62:
/usr/include/libintl.h:92: error: expected identifier or '(' before ';' token
make[1]: *** [objects/gui_gtk.o] Error 1
make[1]: Leaving directory `/home/tushar/vim/vim71/src'
make: *** [myself] Error 2
Regards,
-tushar.
- End Original Message -
This may be the problem addressed by patch 7.1.001, see
http://ftp.vim.org/pub/vim/patches/7.1/
So, try the following:
cd ~/vim/vim71
mkdir -pv patches
cd patches
ftp ftp.vim.org
Name: ftp
Password: ftp
cd pub/vim/patches/7.1
mget *
a
bye
cd ..
patch -p0 patches/7.1.001
patch -p0 patches/7.1.002
# beware of beautifying mailers! Here comes a long line starting rsync
# followed by a line starting vim
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
echo $CONF_OPT_FEAT
(if the reply is not --with-features=huge):
source myconfig
make 21 |tee make.log
etc. If you still get the same error, someone else will have to help you.
Best regards,
Tony.
--
*** NEWSFLASH ***
Russian tanks steamrolling through New Jersey Details at eleven!
Re: [Fwd: Re: compiling vim7.1 (huge version) gets build with normal version]
Stephan Hegel wrote: A.J.Mechelynck wrote: patch -p0 patches/7.1.001 patch -p0 patches/7.1.002 As long as you have two patches this can be done easily. But what if you have 100+ ? Then try this: cat patches/7.1.* patchfile patch -p0 patchfile rm patchfile Done. Rgds, Stephan. If you have more than a hundred, Bram sets up recapitulative patches for one hundred patchlevels at a time, so if you want to patch plain-vanilla 7.0 to compile 7.0.233 you would do gunzip -c patches/7.0.001-100.gz |patch -p0 gunzip -c patches/7.0.101-200.gz |patch -p0 patch -p0 patches/7.0.201 patch -p0 patches/7.0.202 patch -p0 patches/7.0.203 etc. With command-line editing, you can recall the latest command and change only the last (or the last two) digit(s) every time. But normally you would download and implement the patches a few at a time as they are published, and there would never be many of them at any one time, except maybe the first time you compile Vim; so now (that there aren't many patches to the latest version) is a good time to start. - Using cat is OK as long as you can be sure that you'll get them in numeric order: this is usually the case on Unix but not necessarily on Dos, where a wildcarded filename usually gets its results in directory order, not sorted by filename. - By patching individually, if one of the patches fails horribly you may decide not to try the following. - Usually there aren't more than a handful of _new_ patches anyway, so (except when starting from scratch with many patches already published) it's hardly worth the trouble going to a cat step. Best regards, Tony. -- Justice, n.: A decision in your favor.
Re: Compiling Vim
fREW wrote: Hey Tony, What is the URL for your Vim Compile site? I can't find the link anywhere. Thanks! -fREW Method I: Start at my home portal http://users.skynet.be/antoine.mechelynck/ Click The Vim Editor then the two bottom links in the list at top left point to my HowTo pages for Windows and Unix/Linux. This method can easily be deduced from my email address plus the knowledge of how Belgacom/Skynet user sites are named. Method II: Direct links: Windows: http://users.skynet.be/antoine.mechelynck/vim/compile.htm Unix:http://users.skynet.be/antoine.mechelynck/vim/compunix.htm Best regards, Tony. -- ROMEO: Courage, man; the hurt cannot be much. MERCUTIO: No, 'tis not so deep as a well, nor so wide as a church- door; but 'tis enough, 'twill serve.
Re: problems with vim
Nageshwar M wrote: Hello, I compiled the vim 7.1 source for unix and installed it in my fedora core 4 pc. When I pressed arrows its printing A,B,C,D's(in insert mode) , backspace is not working and when I pressed delete continuously the gvim is closing down. Someone please help me. The information that vim is showing for :version is Normal version with GTK2 GUI. Features included (+) or not (-): [...] This is usually due to a termcap problem. In which case(s) do you see the problem (among the following)? - in GUI mode (e.g. Alt-F2 then gvim) - in console mode in a terminal displaying through X (and which one: xterm? konsole? gnome-terminal? other[and which one]?) - in the pure text linux console (hit Ctrl-Alt-Fn with n in the range [1..6], log in if necessary, then invoke vim) Best regards, Tony. -- A nymph hits you and steals your virginity.
Re: I can't change the font in vim7.1!
Larson, David wrote: I just upgraded to 7.1, and now when I open up a gvim session, I get this huge monospaced font that I can't change. If I type: :set guifont? it returns 7x14 which is what I set it to, but it isn't what is displayed. If I change the setting to *any* other font that is valid for my system, the display doesn't change, although the guifont setting shows that it is set to the new value. Help! David :version shows: VIM - Vi IMproved 7.1 (2007 May 12, compiled May 14 2007 09:50:48) Compiled by [EMAIL PROTECTED] Big version with GTK2 GUI. Features included (+) or not (-): With a GTK2 GUI, you can set the font interactively, using :set guifont=* This will bring up a font chooser menu. Thereafter, :set guifont=Tab will show on the command-line the exact command (with escaping backslashes if and where needed) that you need to write into your vimrc to set that font. There are (including the obsolete kvim) five different families of Vim GUIs, each of which requires a different 'guifont' format, not accepted by other GUIs. The following is what I use in my portable vimrc to sniff the GUI version: if has(gui_running) console Vim cannot set the font if has(gui_gtk2) GTK+2, not GTK+1 set gfn=Bitstream\ Vera\ Sans\ Mono\ 9 elseif has(gui_photon) Photon GUI set gfn=Bitstream\ Vera\ Sans\ Mono:s9 elseif has(gui_kde) the obsolete kvim set gfn=Bitstream\ Vera\ Sans\ Mono/9/-1/5/50/0/0/0/1/0 elseif has(x11) other X11 GUIs including GTK+1 set gfn=-*-lucidatypewriter-medium-r-normal-*-*-100-*-*-m-*-* else non-X11 GUIs including Windows set gfn=Lucida_Console:h9:cDEFAULT endif endif Best regards, Tony. -- ... My pants just went on a wild rampage through a Long Island Bowling Alley!!
Re: Bug: .viminfo file gets deleted and re-created with 666 permissions
Micah Cowan wrote: Bram Moolenaar wrote: [...] The solution is simple: Don't create a link in place of the .viminfo file. And certainly not to /dev/null. Background info: When Vim finds an existing .viminfo file, it writes the new info into a temp file (since it's still reading from the existing one it can't be overwritten). When finished the temp file is moved in place of the old .viminfo and owner and protection are set to match the original. Vim intentionally doesn't follow symlinks for .viminfo, because that can be used for a symlink attack, a security issue. How so? The user won't be able to attack files he doesn't have write permission to, and other users wouldn't be running from his .viminfo, AFAICT. And the user shouldn't have permission to replace other users' .viminfo's with a symlink... so I'm missing something. Maybe you're missing the fact that /dev/null is crw-rw-rw- i.e. world-readable and -writable? Best regards, Tony. -- You can take all the impact that science considerations have on funding decisions at NASA, put them in the navel of a flea, and have room left over for a caraway seed and Tony Calio's heart. -- F. Allen
Re: Bug: .viminfo file gets deleted and re-created with 666 permissions
Micah Cowan wrote: A.J.Mechelynck wrote: Micah Cowan wrote: Bram Moolenaar wrote: [...] The solution is simple: Don't create a link in place of the .viminfo file. And certainly not to /dev/null. Background info: When Vim finds an existing .viminfo file, it writes the new info into a temp file (since it's still reading from the existing one it can't be overwritten). When finished the temp file is moved in place of the old .viminfo and owner and protection are set to match the original. Vim intentionally doesn't follow symlinks for .viminfo, because that can be used for a symlink attack, a security issue. How so? The user won't be able to attack files he doesn't have write permission to, and other users wouldn't be running from his .viminfo, AFAICT. And the user shouldn't have permission to replace other users' .viminfo's with a symlink... so I'm missing something. Maybe you're missing the fact that /dev/null is crw-rw-rw- i.e. world-readable and -writable? No, I'm not missing that. Why should that make a difference? It is, after all, a special file; and only root would be able to replace it with something else. Anyway, Bram was saying that it's a general security hole, not just for when /dev/null is the target. Yes, but when a viminfo exists, Vim re-creates it with the same permissions. IIUC, a link inherits the permissions of the target: here, rw-rw-rw-. Instead of linking to /dev/null, make sure your viminfo is not world-writable, and it will stay that way. Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 231. You sprinkle Carpet Fresh on the rugs and put your vacuum cleaner in the front doorway permanently so it always looks like you are actually attempting to do something about that mess that has amassed since you discovered the Internet.
Re: [Bulk] Re: Bug: .viminfo file gets deleted and re-created with 666 permissions
Robert Lee wrote: A.J.Mechelynck wrote: Micah Cowan wrote: A.J.Mechelynck wrote: Micah Cowan wrote: Bram Moolenaar wrote: [...] The solution is simple: Don't create a link in place of the .viminfo file. And certainly not to /dev/null. Background info: When Vim finds an existing .viminfo file, it writes the new info into a temp file (since it's still reading from the existing one it can't be overwritten). When finished the temp file is moved in place of the old .viminfo and owner and protection are set to match the original. Vim intentionally doesn't follow symlinks for .viminfo, because that can be used for a symlink attack, a security issue. How so? The user won't be able to attack files he doesn't have write permission to, and other users wouldn't be running from his .viminfo, AFAICT. And the user shouldn't have permission to replace other users' .viminfo's with a symlink... so I'm missing something. Maybe you're missing the fact that /dev/null is crw-rw-rw- i.e. world-readable and -writable? No, I'm not missing that. Why should that make a difference? It is, after all, a special file; and only root would be able to replace it with something else. Anyway, Bram was saying that it's a general security hole, not just for when /dev/null is the target. Yes, but when a viminfo exists, Vim re-creates it with the same permissions. IIUC, a link inherits the permissions of the target: here, rw-rw-rw-. Instead of linking to /dev/null, make sure your viminfo is not world-writable, and it will stay that way. Best regards, Tony. Tony, Out of curiosity, what would vim do in this case: cp -f /dev/null ~/.viminfo chmod 400 ~/.viminfo ? Would it give any write errors? Would it delete and recreate? Would the file be left blank on exit? I guess intuitively I would expect the file to be left blank (unmodified) without vim giving me any errors. But IIUC, vim would, on exit, actually silently delete the blank file, and create a new one with new contents with the permissions set to r. Is this correct? Thanks! -Robert Let's find out (and, first, move my usual viminfo out of the way by renaming...) Logged-in as root: the viminfo is overwritten with non-zero length and -rw---. But root can write anything. Let's retry with a different login. At Vim shutdown: E137: viminfo file is not writable: /home/tonymec/.viminfo ls -l .viminfo -r 1 tonymec users 0 2007-05-12 23:52 .viminfo The file remains zero-length and readonly. Best regards, Tony. -- Last week a cop stopped me in my car. He asked me if I had a police record. I said, no, but I have the new DEVO album. Cops have no sense of humor.
Re: Bug: .viminfo file gets deleted and re-created with 666 permissions
Micah Cowan wrote: Following description lifted from bug filed at https://bugs.launchpad.net/ubuntu/+source/vim/+bug/78960 [EMAIL PROTECTED]:~$ rm .viminfo [EMAIL PROTECTED]:~$ ln -s /dev/null .viminfo [EMAIL PROTECTED]:~$ ls -l .viminfo lrwxrwxrwx 1 sa sa 9 2007-01-12 17:16 .viminfo - /dev/null [EMAIL PROTECTED]:~$ umask 007 [EMAIL PROTECTED]:~$ /usr/bin/vim.basic -c 'quit' [EMAIL PROTECTED]:~$ ls -l .viminfo -rw-rw-rw- 1 sa sa 509 2007-01-12 17:16 .viminfo As you can see the .viminfo file gets deleted and re-created with permissions 666 by vim. Note that the use of -c 'quit' is just to simplify the bug for transcribing here -- I promise you the same thing happens if you use vim for editing/saving a document as well. I consider this a security bug. vim deletes a file without telling me, and not only that but when it re-creates it, it ignores my umask by making it world writable. This is not what I expected it to do. I was able to confirm this bug, both in Ubuntu's vim-gnome-7.0-164+1ubuntu7 package, and in the latest 7.1b sources. I also have a separate question: is this an appropriate place to post bugs? Specifically, when (a) I am interested in potential discussion related to it, and/or (b) I am interested in possibly implementing the fix for it? :he bugs suggests submitting bugs to [EMAIL PROTECTED], but from the description, it sounds like those go to a single person, and are not tracked (so, no opportunity for discussion, and it's hard to know if a bug has been reported or what it's status is). A subject change may be appropriate for answering this separate question. I suppose it's not expected that your viminfo might be a soft link to a device. To avoid using a viminfo, use :set viminfo= To have it non-world-readable, what about cp -vf /dev/null ~/.viminfo chmod 600 ~/.viminfo I expect that when the viminfo is a true file, Vim will respect its permissions. Best regards, Tony. -- The Army is a place where you get up early in the morning to be yelled at by people with short haircuts and tiny brains. -- Dave Barry
Re: Bug: .viminfo file gets deleted and re-created with 666 permissions
Taylor Venable wrote: [...] If it did follow the symlink to /dev/null, and tried to read from that device, it would fail. You can't (or at least, shouldn't) read from /dev/null because it's a sink, not a source. What kind of behavior would you expect, trying to read from /dev/null? [...] Reading from /dev/null wouldn't fail (in the sense of giving a read error): it would give an end-of-file signal. /dev/null is both a source (behaving as always at end-of-file) and a sink (writing to it always succeeds but the data is silently discarded). Try copying /dev/null to a valid but nonexistent filename, and you'll get a zero-length file with no error. Or if the file exists, cp -f /dev/null filename will truncate it to zero length. On Ms-Dos 2 and higher, the NUL device inherited the same behaviour, in (IIUC) conscious imitation of Unix. Best regards, Tony. -- Osborn's Law: Variables won't; constants aren't.
Re: 7.1a.001 OSX colour scheme errors?
Bram Moolenaar wrote: [...] I'll add a specific line to copy rgb.txt. Just for the record, after reformatting the entries to a common format and sorting, a diff between my ~/.build/vim/vim71a/runtime/rgb.txt and my /usr/share/X11/rgb.txt shows no other difference than the header comment -- so I suppose copying it unconditionally oughtn't to harm the OSs where there already is an rgb.txt. Oh, and just for fun: I slapped together a syntax script for rgb.txt (attached). I use it with a zero-length ftplugin and a one-line detection autocommand in filetype.vim (which are not attached: the autocommand is: au BufRead,BufNewFile rgb.txt setf rgb); Bram, what do you think of it? Best regards, Tony.  Syntax plugin for rgb (rgb.txt) files Language: rgb.txt Maintainer: Tony Mechelynck [EMAIL PROTECTED] Last Change: 9 May 2007 sy match rgbError /^.*$/ hi def link rgbError Error sy match rgbComment /^!.*$/ display hi def link rgbComment Comment sy match rgbLine transparent /^\s*\d\+\s\+\d\+\s\+\d\+\s\+\a.*$/ contains=rgbNumber,rgbName sy match rgbNumber /\\d\+\/ contained hi def link rgbNumber Number sy match rgbName /\\a.*$/ contained hi def link rgbName Identifier
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*
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
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: 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: [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: $VIMRUNTIME problem
Anatoli Sakhnik wrote: Hello! On RHEL4 works well! On Fedora Core 6 couldn't automatically determinte $VIMRUNTIME, lacked the last part 'vim71a' in the path when I tried to open a file (say, Foo.hs). Without initial file opening from command line works well. On mingw (Windows XP) couldn't compile the gui version with errors: gui_w32.c:236: error: redefinition of `struct tagNMTTDISPINFOA' gui_w32.c:246: error: redefinition of `struct tagNMTTDISPINFOW'. Please note, that I downloaded only unix and extra packages. Sorry, I don't have enough time to dig these problems. -- Anatoli Sakhnik. What is the output of :version in your FC6 Vim? In particular, does it include lines beginning with the following, and what do they say? fall-back for $VIM: f-b for $VIMRUNTIME: By default (i.e., if no directories were specifically specified at configure time) fall-back for $VIM is /usr/local/share/vim and f-b for $VIMRUNTIME is not shown, which makes it default (in Vim 7.1a) to $VIM/vim71a If you compile Vim yourself, installing your source in a tree rooted at something/vim71a/ then using make followed by make install, it should then install (if you use default install dirs) the binaries in /usr/local/bin and the runtimes in /usr/local/share/vim/vim71a/. This is how it happens on my SuSE 10.2 system; it oughtn't to be any different if you compile Vim yourself on FC6. Of course, you must not mix pre-compiled files from Vim 7.0 with sources from Vim 7.1a; in particular, the first 7.1a build MUST NOT be made in a directory tree with a preexisting configure.cache or a preexisting nonempty auto/ directory from 7.0; It MUST be done from scratch in a build directory tree containing ONLY fresh 7.1a sources. Best regards, Tony. -- Too much of everything is just enough. -- Bob Wier
Re: vim_is_xterm() and screen
Micah Cowan wrote: [...] But you already have hacked support into your programs for mouse support. Now that you've done that, couldn't you just open it up a bit? Is there anything wrong with always recognizing the appropriate xterm sequences (provided that they don't first match a valid terminfo entry)? This is the approach that elinks seems to take, and I don't see any particular reason why vim couldn't do this as well. [...] There are conflicts between xterm mouse codes and DEC mouse codes. See :help 'ttymouse' for details (and, maybe, for a way of telling Vim which mouse is installed). Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 221. Your wife melts your keyboard in the oven.
(Doc bug) Error in options.txt
One word under :help 'ttymouse' was obviously forgotten when that option got
more possible settings. See suggested patch, attached.
Best regards,
Tony.
--
You should never wear your best trousers when you go out to fight for
freedom and liberty.
-- Henrik Ibsen
*** ../vim71a/runtime/doc/options.txt Mon May 7 23:03:49 2007
--- runtime/doc/options.txt Wed May 9 03:02:49 2007
***
*** 1,4
! *options.txt* For Vim version 7.1a. Last change: 2007 May 05
VIM REFERENCE MANUAL by Bram Moolenaar
--- 1,4
! *options.txt* For Vim version 7.1a. Last change: 2007 May 09
VIM REFERENCE MANUAL by Bram Moolenaar
***
*** 7031,7037
{only in Unix and VMS, doesn't work in the GUI; not
available when compiled without |+mouse|}
Name of the terminal type for which mouse codes are to be recognized.
! Currently these three strings are valid:
*xterm-mouse*
xterm xterm-like mouse handling. The mouse generates
Esc[Mscr, where scr is three bytes:
--- 7031,7037
{only in Unix and VMS, doesn't work in the GUI; not
available when compiled without |+mouse|}
Name of the terminal type for which mouse codes are to be recognized.
! Currently these six strings are valid:
*xterm-mouse*
xterm xterm-like mouse handling. The mouse generates
Esc[Mscr, where scr is three bytes:
Re: 7.1a.001 OSX colour scheme errors?
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). Best regards, Tony. -- If all be true that I do think, There be Five Reasons why one should Drink; Good friends, good wine, or being dry, Or lest we should be by-and-by, Or any other reason why.
Re: problem with win32 vim 7.1a.001
Michael Wookey wrote: Hello vim list, I've just synced up to 7.1a.001 (svn #263) and built on Win32 (MSVC). Everything builds fine and I replace my previous gvim.exe and vim.exe with the newly built versions. I also sync my runtime from ftp.nluug.nl. My vim installation is in: C:\Vim\vim70 My config is in: C:\Vim\_vimrc Additional plugins are in: C:\Vim\vimfiles\... This has always worked fine as this is the structure set up by the vim win32 installer. I now find that launching gvim/vim doesn't find my _vimrc or my vimfiles runtime. I can get it to load my _vimrc by moving it to: C:\Vim\Vim70\_vimrc However my runtime isn't picked up as :scriptnames doesn't list any plugins loaded. Is it just me or has something broken win32 vim? My previous sync was svn#254 (Vim 7.0.236) with a runtime sync from the same time and everything was fine. Any ideas? Make sure that VIMRUNTIME is _not_ defined in your environment (in XP or later: Control Panel = System = Adevanced = Environment variables; there are two sets, one for all users and one specific to your login name). VIM may be either undefined or set at C:\Vim; NOT at C:\Vim\Vim70 unless your distribution is in C:\Vim\Vim70\Vim70 (7.0) and/or C:\Vim\vim70\Vim71a (7.1), both of which are quite atypical to say the least. Your (user) _vimrc can be either in $HOME (wherever Vim sets it) or, on a single-user system only, in $VIM. The problem with the latter is that it's the same for all users (all login names). At Vim startup, if VIM and VIMRUNTIME are both undefined, and (g)vim was loaded from C:\Vim\vim71a\, that directory will become $VIMRUNTIME and its parent will become $VIM. Vim will then look for runtime files there and in its subfolders. Warnings: 1. I don't think you can use the same server to rsync your 7.1 runtimes as your 7.0: it would pick the 7.0 files, including help files with 'For Vim 7.0 in their first line. AFAICT, the 7.1 runtimes consist of those distributed for 7.1a.000 plus one modification in the latest patch. Couldn't find anything else at ftp.vim.org. 2. The parent of the src/ and runtime/ (and a few other) directories from yource source 7.1 distro should be named vim71a (which is where the archives unpack to) to avoid conflict with the 7.0 source. The first 7.0 compile MUST be from scratch, then you may compile only the changes but only if your featureset stays the same (e.g. big, +gui +ole +perl/dyn +python/dyn -ruby -tcl -mzscheme +multibyte_ime/dyn etc...). To force a full rebuild, use make -f makefile name clean or make -f makefilename distclean prior to rebuilding. 3. For more details, see http://users.skynet.be/antoine.mechelynck/vim/compile.htm but replace vim70 (wherever it appears) by vim71a. Best regards, Tony. -- If you think education is expensive, try ignorance. -- Derek Bok, president of Harvard
Re: Compiling vim in mingw.
Markus Trenkwalder wrote:
Hi list,
checked out vim-7.1a.001 today from svn (#263) and tried to compile it
with mingw-gcc and got the following error:
8
$ make -f Make_ming.mak
gcc -c -Iproto -DWIN32 -DWINVER=0x0400 -D_WIN32_WINNT=0x0400
-DHAVE_PATHDEF -DFEAT_BIG -DHAVE_GETTEXT -DHAVE_LOCALE_H
-DDYNAMIC_GETTEXT -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_GUI_W32
-DFEAT_CLIPBOARD -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME
-DDYNAMIC_ICONV -pipe -w -march=i386 -Wall -O3 -fomit-frame-pointer
-freg-struct-return -s gui_w32.c -o gobj/gui_w32.o
gui_w32.c:236: error: redefinition of `struct tagNMTTDISPINFOA'
gui_w32.c:246: error: redefinition of `struct tagNMTTDISPINFOW'
make: *** [gobj/gui_w32.o] Error 1
8
My naive solution to this problem is:
8
--- src/gui_w32.c.000 Mon May 7 08:26:54 2007
+++ src/gui_w32.c Mon May 7 07:01:09 2007
@@ -232,7 +232,7 @@
LPARAM lParam;
} NMTTDISPINFO_NEW;
-#ifndef LPNMTTDISPINFO
+#if !defined(LPNMTTDISPINFO) !defined(TOOLTIPTEXTA)
typedef struct tagNMTTDISPINFOA {
NMHDR hdr;
LPSTR lpszText;
8
Regards
Markus
You're not the first; there seems to have been a f*ckup in the svn commit
lately. I suggest you scrap your existing 7.1a sources and restart from
scratch, by downloading the 7.1a.000 sources then applying the 7.1a.001 patch.
Here are the files whose download I recommend:
1) the unpatched archives
http://ftp.vim.org/pub/vim/unstable/unix/vim-7.1a.tar.bz2
http://ftp.vim.org/pub/vim/unstable/extra/vim-7.1a-extra.tar.gz
http://ftp.vim.org/pub/vim/unstable/extra/vim-7.1a-lang.tar.gz
The first one is not a typo: even for Windows, I recommend the *Unix* + extra
+ lang sources. Together, they have exactly one copy of every source file
needed to compile Vim for *any* platform including Windows.
Unpack them on top of each other at what will become your Vim directory for
compiling, maybe something like D:\build\vim : they will create a subfolder
vim71a and place all the sources in it, creating subfolders as needed.
I don't know if you have a bz2 decompresser program, or if your version of
patch will accept the patch format. In both cases, MinGW may or may not
offer the necessary packages (look there first) but I know Cygwin does. (Even
WinZip knows about the .tar and .gz formats.)
2) the patch
http://ftp.vim.org/pub/vim/unstable/patches/7.1a/7.1a.001
Download it (and optionally its sibling files README MD5 and MD5SUMS) into a
newly-created subfolder named (in my example) D:\build\vim\vim71a\patches then
apply it by using (IIUC)
D:
cd \build\vim\vim70
patch -p0 patches\7.1a.001
See details at http://users.skynet.be/antoine.mechelynck/vim/compile.htm but
replace everywhere the directory name .../vim70/... by .../vim71a/..., even in
the name of what will become your production 7.1a $VIMRUNTIME after
compiling and installing.
I used Cygwin gcc and Make_cyg.mak but using MingGW and Make_ming.mak is not
very different. I trust you will know what to change in the procedure to cater
for any differences between them.
Best regards,
Tony.
--
All snakes who wish to remain in Ireland will please raise their right
hands.
-- Saint Patrick
Re: Where to find 7.1a patchlevels runtimes? (Was: patch 7.1a.001)
Bram Moolenaar wrote: Tony Mechelynck wrote: [...] I notice this patch modifies one runtime file. This reminds me that runtime updates are not always reflected in patches. Do the files in ftp://ftp.vim.org/pub/vim/runtime/ (and the equivalent rsync repository, ftp.nluug.nl::Vim/runtime/ ) apply to 7.0 only, or to both 7.0 and 7.1? (The latest changes there are for a large number of spelling dictionaries.) They are for both. There are no (recent) source code changes that are required for the updated runtime files. On thinking back, I would suspect they /aren't/ the same, since the first line of each helpfile mentions either 7.0 or 7.1a -- so at least the contents of the doc/ subfolders are different. So -- will runtime upgrades for 7.1 beta be always reflected in patches, or else will there be a runtime server -- and where? [...] Well, then for 7.1a I suppose I can use the same rsync command, but with --exclude=/doc/ in addition to --exclude=/dos/ so the new helpfiles (with 7.1a in the first line) won't all be replaced, and the :help version-7.1 section won't be deleted. This makes it (please remove spurious linebreaks added by my mailer or by yours, and correct me if I'm wrong) cd ~/.build/vim/vim71a rsync -avzcP --delete --exclude=/dos/ --exclude=/doc/ ftp.nluug.nl::Vim/runtime/ ./runtime/ 21 |tee rsync.log But won't this roll back the 7.1a.001 change in autoload/spellfile.vim ? Best regards, Tony. -- You can make it illegal, but you can't make it unpopular.
Re: Compiling vim in mingw.
Edward L. Fox wrote: On 5/7/07, A.J.Mechelynck [EMAIL PROTECTED] wrote: [...] You're not the first; there seems to have been a f*ckup in the svn commit lately. I suggest you scrap your existing 7.1a sources and restart from scratch, by downloading the 7.1a.000 sources then applying the 7.1a.001 patch. Here are the files whose download I recommend: 1) the unpatched archives http://ftp.vim.org/pub/vim/unstable/unix/vim-7.1a.tar.bz2 http://ftp.vim.org/pub/vim/unstable/extra/vim-7.1a-extra.tar.gz http://ftp.vim.org/pub/vim/unstable/extra/vim-7.1a-lang.tar.gz The first one is not a typo: even for Windows, I recommend the *Unix* + extra + lang sources. Together, they have exactly one copy of every source file needed to compile Vim for *any* platform including Windows. Unpack them on top of each other at what will become your Vim directory for compiling, maybe something like D:\build\vim : they will create a subfolder vim71a and place all the sources in it, creating subfolders as needed. I don't know if you have a bz2 decompresser program, or if your version of patch will accept the patch format. In both cases, MinGW may or may not offer the necessary packages (look there first) but I know Cygwin does. (Even WinZip knows about the .tar and .gz formats.) 2) the patch http://ftp.vim.org/pub/vim/unstable/patches/7.1a/7.1a.001 Download it (and optionally its sibling files README MD5 and MD5SUMS) into a newly-created subfolder named (in my example) D:\build\vim\vim71a\patches then apply it by using (IIUC) D: cd \build\vim\vim70 patch -p0 patches\7.1a.001 Could you please tell me the differences between svn repository and your downloaded and patched sources? In fact #262 is a broken committing because the patch 7.1a.001 was applied to 7.0.243, so the svn sources are broken. But #263 is just synced from the cvs repository. So if it is broken, so is cvs. See details at http://users.skynet.be/antoine.mechelynck/vim/compile.htm but replace everywhere the directory name .../vim70/... by .../vim71a/..., even in the name of what will become your production 7.1a $VIMRUNTIME after compiling and installing. [...] My downloaded and patched sources (from the ftp repository, thus bypassing both cvs and svn) are Bram's official 7.1a.000 full sources and Bram's official 7.1a.001 patch. If (as you're saying) the svn repository mistakenly applied the 7.1a.001 patch against the 7.0.243 sources, by doing as I suggest you won't make that error. And I don't know whether or not the CVS repository is broken, but AFAIK the FTP uploads are made directly under Bram's own responsibility, and IIUC those aren't broken (but they're incremental: you got to apply the patches yourself). Best regards, Tony. -- If you give Congress a chance to vote on both sides of an issue, it will always do it. -- Les Aspin, D., Wisconsin
Re: Vim version 7.1a BETA has been released
Gary Johnson wrote: On 2007-05-05, A.J.Mechelynck [EMAIL PROTECTED] wrote: Bram Moolenaar wrote: Announcing: Vim (Vi IMproved) version 7.1a BETA This is a BETA release of Vim 7.1. It consists of Vim 7.0 plus all patches and updated runtime files. I expect this to be stable, since the patches have been used by many people already. This BETA is mainly to check that the files has been setup properly. It's been almost a year since the last one! Please report every problem you find! It will only be a few days until the 7.1 release, so please take a little time right now to check it out. Once you have installed Vim 7.1a BETA you can find details about the changes since Vim 7.0 with :help version-7.1. [...] Compiles as a breeze :-). Yes indeed. I've compiled it so far on SunOS 5.8 and HP-UX 10.20. I may try Cygwin if I'm feeling adventurous enough. I've never done that except from Cygwin sources. The binary is now in /usr/local/vim (but we still have /usr/local/vim70 as a backup); the runtime files go in /usr/local/vim/vim71a and below, where the binary will find them with no problem (and the 7.0 runtime files in /usr/local/vim/vim70 [or wherever] aren't touched). I think some directories were omitted from the paths in that paragraph and that it should read: The binary is now in /usr/local/bin/vim (but we still have /usr/local/bin/vim70 as a backup); the runtime files go in /usr/local/share/vim/vim71a and below, where the binary will find them with no problem (and the 7.0 runtime files in /usr/local/share/vim/vim70 [or wherever] aren't touched). er, yes. I should have reread it once more. (Warning: In the ln command as used here, the target name comes before the link name. I find this counter-intuitive.) It's not just me then. I have to think carefully about that every time I use ln. Regards, Gary Yes. When linking to the same name in a different directory, I find it easier to omit the link name altogether, as shown for matchit.txt Best regards, Tony. -- He was a modest, good-humored boy. It was Oxford that made him insufferable.
Re: Vim version 7.1a BETA -- svn ?
Yakov Lerner wrote: On 2007-05-05, Bram Moolenaar [EMAIL PROTECTED] wrote: Announcing: Vim (Vi IMproved) version 7.1a BETA I tried to build vim7.1 from svn. But all I get from usual svn location (https://svn.sourceforge.net/svnroot/vim/vim7), is vim 7.0.236. Will vim7.1 be served at this localtion eventually ? Thanks Yakov Well, it should first have time to cycle (isn't 7.0 at patchlevel 243 or thereabouts?); and then maybe it's waiting for 7.1a.001? In the meantime you can get the archives from the ftp server, no patches have been issued against 7.1a yet. Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 216. Your pet rock leaves home.
Re: Vim version 7.1a BETA has been released
Michael Henry wrote: Gary Johnson wrote: On 2007-05-05, A.J.Mechelynck [EMAIL PROTECTED] wrote: (Warning: In the ln command as used here, the target name comes before the link name. I find this counter-intuitive.) It's not just me then. I have to think carefully about that every time I use ln. I used to find this hard to remember until I realized that 'ln' and 'cp' are very similar. The 'cp' command copies one or more sources to a destination; the 'ln' command links one or more sources to a destination as well. I tend to think of 'ln -s' as copy using symlinks. The order and meaning of the arguments is the same between the commands, which I now find consistent and intuitive. Michael Henry The problem is, cp -v file1 file2 outputs `file1' - `file2' (the data has been copied from file1 to file2) but ln -sv file1 file2 outputs file2 - file1 (file2 is now a link pointing to file1). I still have to call up the help or the manual every time I invoke it. Best regards, Tony. -- Celebrate Hannibal Day this year. Take an elephant to lunch.
Where to find 7.1a patchlevels runtimes? (Was: patch 7.1a.001)
Bram Moolenaar wrote: Patch 7.1a.001 Problem:Crash when downloading a spell file. (Szabolcs Horvat) Solution: Avoid that did_set_spelllang() is used recursively when a new window is opened for the download. Also avoid wiping out the wrong buffer. Files: runtime/autoload/spellfile.vim, src/buffer.c, src/ex_cmds.c, src/spell.c [...] After a little hunting, I found this patch on the ftp server too (with README, MD5 and MD5SUMS): ftp://ftp.vim.org/pub/vim/unstable/patches/7.1a/ Note: I prefer not to feed the email itself to the patch program, because: - my ISP's routers sometimes autoconvert the contents between 8-bit and quoted-printable; and the latter make the patch program choke; - if I see several patches published while I was away or asleep, by FTP I can get them all to where patch will find them. - the patch directory on FTP includes a table of contents, README I notice this patch modifies one runtime file. This reminds me that runtime updates are not always reflected in patches. Do the files in ftp://ftp.vim.org/pub/vim/runtime/ (and the equivalent rsync repository, ftp.nluug.nl::Vim/runtime/ ) apply to 7.0 only, or to both 7.0 and 7.1? (The latest changes there are for a large number of spelling dictionaries.) On thinking back, I would suspect they /aren't/ the same, since the first line of each helpfile mentions either 7.0 or 7.1a -- so at least the contents of the doc/ subfolders are different. So -- will runtime upgrades for 7.1 beta be always reflected in patches, or else will there be a runtime server -- and where? (ftp://pub/vim/unstable/runtime/ contains only one item yet: a softlink to the main spell subfolder.) Hm... I see a snapshot zip, http://ftp.vim.org/pub/vim/unstable/snapshot/vim-7.1a.zip ,but it's more than 24h older than the patch, while it's only about 2h younger than the 7.0.000 tar.gz and tar.bz2 archives so I guess it's 7.1a.000 in one big economy package... Best regards, Tony. -- If you don't have a nasty obituary you probably didn't matter. -- Freeman Dyson
Re: Vim version 7.1a BETA -- svn ?
François Pinard wrote: [Martin Krischik] [Martin Krischik] That is probalby because the svn server is a mess. [probably] Only the vim svn archive has no space for tags, braches or releases. [branches] It is not a mess, merely being different. If there is ever a _real_ need for another organisation of the Subversion repository for Vim, we can be fairly confident that it will be addressed. But now, the Subversion repository mirrors a non-Subversion one, this is for users convenience, and that's very nice already. Bram currently does not use Subversion for Vim development, so there is no point pretending that he does. If Bram was using Subversion, he might feel like changing things. But even then, the needs would mainly be Bram's! But you can do valuable service and still do it wrong [...] Once again, being different does not imply being wrong. We should not be overly dogmatic in such matters. If the download recipes are clear and work as expected, the repository fills its role. Anyway, if the code mirrored on that svn server belongs only to the 7.0 (release) code tree, there are no branches, since every patchlevel comes linearly on top on the one before, and there is one set of files applicable to all platforms and featuresets. _If_ there comes a 7.0.244, _and_ it branches out from 7.0.243 away from 7.1a.000 and 7.1a.001, _and_ both 7.0 and 7.1a are further mirrored on svn, _then_ there will maybe be a reason to define a branch point. But not before. Best regards, Tony. -- Speer's 1st Law of Proofreading: The visibility of an error is inversely proportional to the number of times you have looked at it.
Re: wish: show search progress on slow searches
Yakov Lerner wrote: On 5/1/07, Yakov Lerner [EMAIL PROTECTED] wrote: [...] How about using SIGALRM when search is progressing, every second ? SIGALRM handler would store time() into global var (and reload alarm(1)). The search would check the global var for changes, every line. It is cheap to check global integer (time_t) var, no ? What do you think about SIGALRM, Bram ? Yakov I don't know about Bram, but how portable is SIGALRM? Can you use it on non-Unix-like systems such as Windows? Wouldn't counting lines be both simpler and more portable? You could either display ...nnn lines scanned... every (e.g.) 100 lines or so, or else determine during startup how long it takes to get the time (maybe as an average of 5 tries if you want less stochastic variability) then check the time it every n lines, with n being a monotonous non-decreasing function of the time delay thus obtained. Lines of wildly varying length would make the display change at variable time intervals (in the second case, if the lines are long enough to require more than, say, one second between successive checks of the clock), but that shouldn't be a very serious problem. Best regards, Tony. -- Your lucky number has been disconnected.
Re: feedkeys() allowed in sandbox
Bram Moolenaar wrote: [...] Modelines are default off when you are root. The mail filetype plugin also switches it off. [...] Are you sure? In a terminal logged-in as root, using vim 7.0.235: vim -u NONE -N :set ml? mls? modeline modelines=5 Modelines default off when 'compatible' is set, they default on (and 5) when 'nocompatible' is set. Root login changes nothing to that AFAICT. Best regards, Tony. -- You mean there really is an answer? Yes! But you're not going to like it! Oh do please tell us! You're really not going to like it! but we MUST know - tell us Alright, the answer is yes... ... is ... yes... come on! is 42! (Douglas Adams - The Hitchhiker's Guide to the Galaxy)
Re: patch 7.0.236
scott wrote: i had to 'rm src/auto/config.cache before i could build with this one sc Yes, this is normal for a patch affecting the configure files: src/auto/configure src/configure.in src/config.h.in Me too: the first make ended in an error, suggesting to remove auto/config.cache; then after rm -vf auto/config.cache the next make rebuilt everything. Best regards, Tony. -- THE LESSER-KNOWN PROGRAMMING LANGUAGES #2: RENE Named after the famous French philosopher and mathematician Rene DesCartes, RENE is a language used for artificial intelligence. The language is being developed at the Chicago Center of Machine Politics and Programming under a grant from the Jane Byrne Victory Fund. A spokesman described the language as Just as great as dis [sic] city of ours. The center is very pleased with progress to date. They say they have almost succeeded in getting a VAX to think. However, sources inside the organization say that each time the machine fails to think it ceases to exist.
Re: patch 7.0.237
Bram Moolenaar wrote: Patch 7.0.237 Problem:For root it is recommended to not use 'modeline', but in not-compatible mode the default is on. Solution: Let 'modeline' default to off for root. Files: runtime/doc/options.txt, src/option.c Note: :set mlvim or :set nocompatible ... :set ml still sets 'modeline' on, even when logged-in as root. Best regards, Tony. -- If you want to understand your government, don't begin by reading the Constitution. It conveys precious little of the flavor of today's statecraft. Instead, read selected portions of the Washington telephone directory containing listings for all the organizations with titles beginning with the word National. -- George Will
Vim binaries for Linux
Announcement: I've tentatively uploaded my current vim binary. Here are the details and caveats: - :version output is at http://users.skynet.be/antoine.mechelynck/vim/version.txt -- check this first before you attempt to download the executable. - executable is at http://users.skynet.be/antoine.mechelynck/vim/vim -- to download it, you will probably have to click right on this link, then Save Link Target As... or whatever your mailer calls it. - This is a huge Linux/i86 version with GTK2/Gnome GUI and support for perl, python, ruby and tcl, compiled on openSUSE 10.2. If you think it's overly bloated (and you quite well may), well, compile your own then: see e.g. my how-to page http://users.skynet.be/antoine.mechelynck/vim/compunix.htm - I compiled it about one and a half hours ago to the latest patchlevel (7.0.235), plus one additional (unnumbered) patch by Bram Moolenaar to fix the 'maxmemtot' default value. - This is a naked executable with no runtime files, no message translations and no ancillary programs (such as xxd). You will have to get all that from a different source such as ftp.vim.org, and keep them up-to-date yourself. This executable expects to find its runtime files starting at the default location, /usr/local/share/vim/vim70 - GNOME support, which is included, is *not* recommended by Bram. Warnings in the compilation of gui_gtk_x11.c seem to indicate that there might be problems with message translations, especially if you change the 'encoding' setting in your vimrc. - It works on my machine with the software I have installed. I don't know if it will work on yours, so: - you may want to keep (under another name or path) a backup Vim executable which you got somewhere else, at least until you've verified that you can use this one. - I don't know exactly how much your system must resemble mine in order to be able to run this executable. I think the GUI won't run without GTK2 and Gnome2, and I don't know if this editor version will load without perl, python, ruby and tcl. You may want to check the bottom part of my :version text for other library names. - if it doesn't work for you, and you cannot make it work by (for instance) installing missing libraries, you may want to discuss symptoms with me, either on the vim-dev list if you think it's on-topic for the list, or by private mail. In the latter case, please use an explicit Subject line because if I don't recognise an email's Subject I treat it as spam; and I get a lot of spam. Happy Vimming! Tony. -- For years a secret shame destroyed my peace -- I'd not read Eliot, Auden or MacNiece. But now I think a thought that brings me hope: Neither had Chaucer, Shakespeare, Milton, Pope. -- Justin Richardson.
Re: feedkeys() allowed in sandbox
John Beckett wrote: [...] Is folding really needed in a default modeline? John Folding may be useful in a modeline. (Don't know what you call a default modeline.) Depending on how the particular file is written, you may want to set foldmethod=marker (and which marker), foldmethod=syntax, foldmethod=indent, or default it to whatever (if anything) is set by the filetype-plugin. Best regards, Tony. -- Some of these fortunes are dated: I have an ADSL connection and a 96 gig HD, and I don't feel it's any special kind of achievement. -- hundred-and-one symptoms of being an internet addict: 208. Your goals for the future are obtaining an ISDN connection and a 6 gig hard drive.
Re: accessing vim's clipboard from java
Ernie Rael wrote: Hi all, I've just joined this list. I'm not a vim developer per se. However, I put together jVi, http://jvi.sourceforge.net , whose core is a port of some of vim to java. It runs on NetBeans ( and JBuilder, but not supported any more). jVi is based on vim-5.6. A jVi user has added visual char/line and is now tackling block. So now I want to setup access to the *real* vim clipboard, so blockmode paste works between vim and jVi. So I'm learning how to access native data formats in clipboard from java. I couldn't get anything to work, so I looked at the vim7 source, couldn't find windows source (I run cygwin, but not cygwin's vim, at home). I downloaded extras. I now see that the clipboard name has changed to VimClipboard2, and there's a whole lot more... So I changed the name, but still no luck. I thought I'd ping this list in case anyone has accessed the vim clipboard from java or has some clues. As an experiment I'm doing public static final String VIM_CLIPBOARD2 = VimClipboard2; SystemFlavorMap.addFlavorForUnencodedNative( ViManager.VIM_CLIPBOARD2, Misc.VimClipboardDataFlavor.get()); and the other way around. But after a paste into jVi from vim the DataFlavor I've defined is not available. Any clues? In os_mswin.c it looks like VimClipboard2 is always made available, so it should be there somewhere. Once I get something working, I'll look at doing all the various encodings... based on VimClipboard2. Or maybe, I'll use VimClipboard2 just to find out if it is MCHAR/MLINE/MBLOCK. Then go to the regular DataFlavors to pick the string type I'm looking for. -ernie IIUC, there is no specific interface between Vim and java, so java will have to do whatever any other application may do, without special knowledge about Vim. Whatever gvim writes to the + register is available in the system clipboard, just as if you'd used Edit = Copy in just about any application. There's nothing Vim-specific there. Best regards, Tony. -- You know you have a small apartment when Rice Krispies echo. -- S. Rickly Christian
Re: arabic
Babiker Osman wrote: Hi السلام I wonder who is the most arabic -vim -tex expert to consult him babiker osman It depends what you want to do. - If it's so high-fired secret that you won't give us any hint of what you might be doing, just dig into the help. Start at :help arabic.txt if you want to edit Arabic text, for instance. - The Arabic module was written by Nadim Shaikli. He certainly has a good knowledge of how to use Vim for Arabic. I have no idea what his knowledge of TeX might be. - In general, you may ask your questions on one of the Vim mailing lists, and see if anyone replies: [EMAIL PROTECTED] for general support questions vim-dev@vim.org with questions about compiling Vim or about writing new interfaces [EMAIL PROTECTED] for questions about encodings and (human) languages It helps if the Subject of your mail is explicit and if its body is clear. A useful reference about asking questions about anything on any forums, mailing lists or newsgroups is How To Ask Questions The Smart Way http://www.catb.org/~esr/faqs/smart-questions.html Best regards, Tony. -- I disapprove of the F-word, not because it's dirty, but because we use it as a substitute for thoughtful insults, and it frequently leads to violence. What we ought to do, when we anger each other, say, in traffic, is exchange phone numbers, so that later on, when we've had time to think of witty and learned insults or look them up in the library, we could call each other up: You: Hello? Bob? Bob: Yes? You: This is Ed. Remember? The person whose parking space you took last Thursday? Outside of Sears? Bob: Oh yes! Sure! How are you, Ed? You: Fine, thanks. Listen, Bob, the reason I'm calling is: Madam, you may be drunk, but I am ugly, and ... No, wait. I mean: you may be ugly, but I am Winston Churchill and ... No, wait. (Sound of reference book thudding onto the floor.) S-word. Excuse me. Look, Bob, I'm going to have to get back to you. Bob: Fine. -- Dave Barry, $#$%#^%!^%@[EMAIL PROTECTED]
Re: feedkeys() allowed in sandbox
Tomas Golembiovsky wrote: Greetings mortals, today somebody came to #vim, and pasted some modeline (containig joke or such). He muttered something about not knowing what that means and left before long. But (!) what I noticed is that feedkeys() was used as part of foldexpression and it turned out that feedkeys() is allowed in sandbox, which means malicious file can run arbitrary command via modeline like this: vim: fdm=expr fde=feedkeys(\\:!touch\ phantom_was_here\\cr) I guess you can see the consequences. Is this known/intentional? IIUC, feedkeys() called from sandbox should execute as if in sandbox, i.e., only (at most) key sequences acceptable in sandbox should be able to be fed. Now this is what I think it ought to do. How does it actually behave? Did you try your example? Did it touch the file? Best regards, Tony. -- Of what you see in books, believe 75%. Of newspapers, believe 50%. And of TV news, believe 25% -- make that 5% if the anchorman wears a blazer.
Re: vim 7.1?
Nikolai Weibull wrote: On 4/27/07, Jonathan Smith [EMAIL PROTECTED] wrote: A.J.Mechelynck wrote: - Insane? All is relative. We're only at 7.0.233 as of today. FYI, Vim 6.2 went to 532 patches, see http://ftp.vim.org/pub/vim/patches/ Release early, release often :) Isn't that what's being done? We're at 7.0.233. That means that there's been 233 releases since 7.0. Of course, it all depends on how you define release. nikolai These 233 releases are incremental and source-only. (Steve Hall's precompiled installers for Windows are compiled in an officially supported way from official sources yet they are still unofficial.) The latest full official release with binaries was 7.0.000. To avail yourself (as I do) of any of these 233 patchlevels to date (for instance, on Linux), you have to, either: - download the current source from CVS or SVN, or - download the 7.0.000 source plus all 233 patches (there are mega- or rather hecto-patches for 001-100 and 101-200), and apply the patches in ascending order - in either case: make sure you also have the latest runtimes, most of whose updates are not reflected in the patches - ...and compile your own Vim. Happily, with the make utility and the Makefiles included in the source distribution, compiling one's own is not really a big deal. Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 202. You're amazed to find out Spam is a food.
Re: vim 7.1?
Nikolai Weibull wrote: On 4/27/07, A.J.Mechelynck [EMAIL PROTECTED] wrote: Nikolai Weibull wrote: On 4/27/07, Jonathan Smith [EMAIL PROTECTED] wrote: A.J.Mechelynck wrote: - Insane? All is relative. We're only at 7.0.233 as of today. FYI, Vim 6.2 went to 532 patches, see http://ftp.vim.org/pub/vim/patches/ Release early, release often :) Isn't that what's being done? We're at 7.0.233. That means that there's been 233 releases since 7.0. Of course, it all depends on how you define release. These 233 releases are incremental and source-only. (Steve Hall's precompiled installers for Windows are compiled in an officially supported way from official sources yet they are still unofficial.) Yes, I know, but the point is that Bram doesn't keep the changes to himself until he releases 7.1. The latest full official release with binaries was 7.0.000. To avail yourself (as I do) of any of these 233 patchlevels to date (for instance, on Linux), you have to, either: [...] Or let your package system do it for you, as on Gentoo. Thanks Gentoo! :-) nikolai My package system does it too, but never fast enough for my taste. That's how I have two versions of Vim here: /bin/vim (big version without GUI) 7.0.146, compiled by http://www.suse.de/ /usr/local/bin/vim (huge version with GTK2-Gnome GUI) 7.0.233, compiled by [EMAIL PROTECTED] (which includes the latest patches published last night). The latter comes of course first in the $PATH. Best regards, Tony. -- Spark's Sixth Rule for Managers: If a subordinate asks you a pertinent question, look at him as if he had lost his senses. When he looks down, paraphrase the question back at him.
Re: possible bug: lowercase dotless i and langmap
Bram Moolenaar wrote: [...] I guess most Turkish characters are in latin1, only the ones that are not won't work with 'langmap'. small undotted i, g-breve, s-cedilla, ... Best regards, Tony. -- The primary requisite for any new tax law is for it to exempt enough voters to win the next election.
Re: vim 7.1?
Jonathan Smith wrote: With the insane number of patches collecting against 7.0, and presumably the new features accumulating in the devel tree, is anyone thinking about when a 7.1 release might be made? -smithj - Insane? All is relative. We're only at 7.0.233 as of today. FYI, Vim 6.2 went to 532 patches, see http://ftp.vim.org/pub/vim/patches/ . - What devel tree? I'll believe that a 7.1 is on the rails when I see at least an alpha. Before that, AFA-anyone-CT, there's no devel tree. Let's not presume about what we know nothing about. - It's not anyone, it's Bram Moolenaar and no-one else; and since he now has a full-time job again, it's a small sort of miracle that he still finds some time for Vim. Best regards, Tony. -- There is no distinctly native American criminal class except Congress. -- Mark Twain
Re: vim 7.1?
Jonathan Smith wrote: [...] Even if BM is the only one who can actually make a release, I'd imagine others have opinions on the matter. Anyway, I was just wondering. -smithj AFAICT, the current bugs are all (or almost all) mere bugfixes. I don't feel a release is imperatively called-for (but Bram has of course the final say). On Unix-like systems (like yours and mine) compiling Vim is really no problem; yet if you absolutely want it, I can make my binaries available. I don't know, however, whether they will even load without perl, python, ruby and tcl all installed, and I think the GUI won't load without Gnome2. Best regards, Tony. -- Automobile, n.: A four-wheeled vehicle that runs up hills and down pedestrians.
Re: Vim's ole functionality
Sebastian Menge wrote: Am Donnerstag, den 26.04.2007, 14:08 +0200 schrieb Sebastian Menge: Perhaps this Mail from eclipse helps: [ ... ] quote from that mail: SWT supports the embedding of OleDocuments and Active X Controls only. In order to be an ActiveX control, the control must support a minimum set of interfaces. The error you are getting is Interface not supported. [...] but my guess is it does not have the minimum set of API required to be an ActiveX Control. Some of the required interfaces are: IOleObject IOleInPlaceObject IOleInPlaceActiveObject IOleControl Are the if_ole developers around? Does gvim implement these interfaces !? I don't see them in the OLEViewer from M$ ... Sebastian. I don't think gvim ever meant to be an ActiveX control. shudder/ Best regards, Tony. -- Baker's First Law of Federal Geometry: A block grant is a solid mass of money surrounded on all sides by governors.
Re: replace VimScript
Robert Lee wrote: Nikolai Weibull wrote: On 4/24/07, Gregory Seidman [EMAIL PROTECTED] wrote: In fact, what I'm asking it to do currently rarely takes much time, but it could be really nice to ask it to do a lot more and still not pay a huge time or memory penalty. What plugins/functionality are we missing that require better efficiency? Efficiency is definitely important. VimScript is probably in the order of 10^6 times slower (if not more) than C, and yet we have loads and loads of usable plugins. And what about the size of, for example, Tamarin. It's quite a big piece of software. That would certainly incur a memory penalty. It is looking more and more like the world of scripting languages for application extension (as opposed to standalone scripting languages) is converging on ECMAScript and Lua, particularly for interactive apps. I'm sure Microsoft agrees with this sentiment. What does Microsoft have to do with anything? Microsoft has, though hardly to any real degree of success, always pushed for VBA. Sure it has JScript as well and many languages could be used for application automation of windows applications. There's a lot to be said for following a path that leads to interoperability and code reuse. Yeah, follow-the-leader is everyone's favorite game. And just look at all the libraries for both these languages. Application extension may sometimes be restricted to the domain of the actual application, but having an abundance of libraries certainly opens up for more interesting possibilities. Vim already has Perl, Python, and Ruby interpreters for application extension, assuming you build it with the appropriate options. Any library available for any of these languages can be made available to the Vim runtime with minimal hassle. Wasn't that sort of my argument? Are there lots of VimScript libraries that are outside the application domain? So how does replacing VimScript with ECMAScript prevent these interesting possibilities? I don't see why you have to replace VimScript with ECMAScript to get ECMAScripts do what can be done with the, for example, Ruby bindings. As for following the leader, you are on shaky ground. No, but the following argument certainly is: Vim followed in the footsteps of vi just as Linux followed in the footsteps of Unix. Do you see something wrong with adopting good choices simply because other people are making the same good choices? I think that recognizing good choices being made by others and benefiting from them is a pretty good idea. Yes, Vim took over where vi had stagnated. Linux was created as a free version of a Unix-like operating system. I don't see how that has anything to do with rip out all the internals of Vim and replace them with a spider-monkey-type-thingy. I mean, it's not like Bram had Vi, removed insert mode and replaced it with virtual replace mode and made a better editor. (Yes, straw-man that if you like.) And just because companies like Adobe and software foundations like Mozilla have chosen JavaScript (and most Adobe applications have a COM interface, so their not usually limited to just JavaScript) for their extension languages doesn't mean it makes sense for others. I would argue that international standardization lends ECMAScript an edge over Lua, incidentally. Lua is standardized in the sense that it has only one implementation. The same applies to Intercal. I don't see the relevance. You seem to have a particularly hostile view toward ECMAScript, beyond a simple preference for the status quo, and I'm not sure why. Would you like me to talk about why I like it as a language, rather than why I think it would benefit Vim? Would you like it if I talked condescending to you? The only question that is really relevant here is: why it isn't enough with having an ECMAScript extension instead of having it replace VimScript? The following arguments have been given: 1. Because people wouldn't have to learn another language 2. Because it is standardized 3. Because lots of people are working on efficient implementations Argument 1) fails because not all people know ECMAScript in the first place. Arguably there are many other choices for languages that more people know than ECMAScript. This is completely true. EMCAScript, however, is never going away and is known by a very large number of users (both technical and non-technical). Frankly, one of Vim's greatest barriers-of-entry is the learning curve. I think much of this is due to its use of proprietary scripting formats. I think there is probably a great deal of overlap between Vim users and current EMCAScript (a.k.a. JavaScript) users. For example, I'd imaging that many PHP developers use Vim as their primary editor (such as myself)...and that most of those users use JavaScript on the client. Argument 2) fails because using a standardized language instead of a application-specific language gives us no
Re: wish: allow a: in the function def
Robert Lee wrote: [...] Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe using SpiderMonkey) so that people don't need to learn a new language just to change the color scheme or keyboard mappings. Yes, this will break backwards compatibility. Tough. [...] Don't? WTF EMCAScript? If you want to replace vimscript by something I already know (yes, /I/ am people), use COBOL, BASIC or FORTRAN. Or even ALGOL. At least vimscript uses the same commands as those which I type at the vim command-line. OTOH, some other people prefer LISP. But replacing vimscript by Lisp has already been done: it's called Emacs. Or if you want to scrap ex-commands everywhere (even when typed-in by hand, one by one) and use EMC-WTF instead, go ahead, I'm not detaining you. But don't call your new editor Vim. Best regards, Tony. -- Real Programs don't use shared text. Otherwise, how can they use functions for scratch space after they are finished calling them?
Re: replace VimScript
Nikolai Weibull wrote:
On 4/24/07, Ilya Sher [EMAIL PROTECTED] wrote:
Robert Lee wrote:
[snip]
Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe
using SpiderMonkey) so that people don't need to learn a new language
If I understand you correctly, you assume that
ECMAScript is the most popular language among
the people that wish to customize VIM. How
do you know the assumption is right?
Aw, come on. Everyone knows ECMAScript. It's like with HTML:
everyone knows HTML. It's like on the web and stuff.
I mean, seriously, it's a lot more intuitive to write
Vim.options['formatoptions'] = Vim.options['formatoptions'].replace('t',
)
than
:set fo-=t
It's all about domain specific languages. It's said so on the internet.
nikolai
More intuitive?
:set fo-=t
remove t from 'fo'. Nothing more intuitive than that, especially when there
is already :set fo+=t. If I were /required/ to learn that more verbose
gobbledygook, I'd be sure to make lots more errors writing wtf-script.
What about ;-)
[...]
DATA DIVISION.
WORKING-STORAGE SECTION.
77 I PICTURE S9(18) COMPUTATIONAL.
[...]
01 FORMATOPTIONS.
03 FORMAT-OPTION PICTURE X
OCCURS 20 TIMES.
[...]
CONSTANT SECTION.
[...]
77 FORMATOPTIONS-SIZE PICTURE 99 VALUE 20
USAGE COMPUTATIONAL.
[...]
PROCEDURE DIVISION.
[...]
MOVE 1 TO I.
X1234-1.
IF FORMAT-OPTION (I) IS EQUAL TO SPACE GO TO X1234-EXIT.
IF FORMAT-OPTION (I) IS EQUAL TO t GO TO X1234-2.
ADD 1 TO I.
IF I IS GREATER THAN FORMATOPTIONS-SIZE GO TO X1234-EXIT.
GO TO X1234-1.
X1234-2.
IF I IS EQUAL TO FORMATOPTIONS-SIZE THEN
MOVE SPACE TO FORMAT-OPTION (I)
GO TO X1234-EXIT.
MOVE FORMAT-OPTION (I + 1) TO FORMAT-OPTION (I).
ADD 1 TO I.
IF FORMAT-OPTION (I) IS EQUAL TO SPACE
GO TO X1234-EXIT.
GO TO X1234-2.
X1234-EXIT.
EXIT.
[...]
_That_ is really intuitive, don't you think? ;-)
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
195. Your cat has its own home page.
Re: wish: allow a: in the function def
Nikolai Weibull wrote: On 4/24/07, Andy Wokula [EMAIL PROTECTED] wrote: Nikolai Weibull schrieb: On 4/24/07, Andy Wokula [EMAIL PROTECTED] wrote: Thomas schrieb: So maybe one could make vimscript search a variable foo as l:foo, a:foo, (maybe also: w:foo, b:foo), s:foo, g:foo, and then throw an undefined variable name error if none exists. Or so. Don't like the idea. In Vim script there is no need or possibility to declare variables. Now, if I forget to init a fun-local variable (happens often to me) Vim gives me a helpful error (undefined variable). And I have the same problem with a: prefixes for my arguments. Fine, keep prefixes for g:, w:, and b:, but a: is just such an incredibly nonstandard way of doing things. In almost all languages parameters are treated the same as local variables. nikolai As long as function arguments are read-only, it is good to have the a: modifier. In fact, why are they read-only, although call is by value? Yes, that's the reason for the a: modifier. And yes, why are they read-only?VimScript isn't a functionaly programming language. Variables are mutable; arguments should be to. Why? Vim is a good programming language, arguments as such should never be mutable. When a value can be passed back (in languages which allow it), the argument is not the value but the _address_ of the value, and that is, again, not changeable. Although I'm sure there's an implementation reason for this, it must be possible to fix. Still, I don't have a patch, so I should probably just shut up now. I just hoped it could be better to spend some time to remove this restriction and drop the requirement of a: instead of adding additional handling for the declaration of parameters. nikolai Best regards, Tony. -- What this world needs is a good five-dollar plasma weapon.
Re: possible bug with vim7 and the arrow keys
Виктор Кожухаров wrote: Hello, I think there might be a bug with vim7, and they way it handles the arrow keys in a terminal. The problem is, that in insert mode, the arrow keys don't navigate through the text, but output letters. For example, pressing Up in insert mode would do the equivalent of OAEsc in normal mode. All the arrow keys are printing the letters that are part of their escape codes in the line above the current one. Also, the reason I think this is a bug is that, on the same machines, vim6 works correctly. the TERM variable is set to xterm in both the terminal and in vim, and this behaviour occurs in any terminal. Furthermore, none of the timeout options have any effect on this behaviour. Vim has been compiled with +terminfo and +termresponse against ncurses-5.6 Don't you have one version compiled with +terminfo and the other with -terminfo? Are both versions running with the same value of 'ttybuiltin'? Is 'term' left at its default? Try the following in both versions: :echo has(terminfo) :set term? ttybuiltin? Each of the above might explain (with a badly-set-up system) the difference in behaviour you're seeing. Also, does it get better or worse if you run vim7 or vim6 (try both) as vim -u NONE -N to avoid loading the vimrc, gvimrc and plugins? Best regards, Tony. -- If a camel flies, no one laughs if it doesn't get very far. -- Paul White
Re: syntax highlighting addition
Nikolai Weibull wrote: On 4/20/07, Bram Moolenaar [EMAIL PROTECTED] wrote: Getting better. Nikola's comments also apply (thanks Nikola!). No problem. I guess there's a bug in the current Ctrl+N implementation? It seems to be cutting off the last character in the completion. ;-) nikolai Insert-mode competion, you mean? I don't see anything cut off; but I use :set completeopt=menuone,preview which adds info (for Ctrl-N: where it was found, if not the current file) to the right of the menu items. There seems to be a maximum width, and the last column of the menu looks like a scrollbar. Maybe an off-by-one error if preview is not included? Best regards, Tony. -- Happiness, n.: An agreeable sensation arising from contemplating the misery of another. -- Ambrose Bierce, The Devil's Dictionary
Re: syntax highlighting addition
Nikolai Weibull wrote: On 4/21/07, A.J.Mechelynck [EMAIL PROTECTED] wrote: Nikolai Weibull wrote: On 4/20/07, Bram Moolenaar [EMAIL PROTECTED] wrote: Getting better. Nikola's comments also apply (thanks Nikola!). No problem. I guess there's a bug in the current Ctrl+N implementation? It seems to be cutting off the last character in the completion. ;-) Insert-mode competion, you mean? I don't see anything cut off; but I use :set completeopt=menuone,preview which adds info (for Ctrl-N: where it was found, if not the current file) to the right of the menu items. There seems to be a maximum width, and the last column of the menu looks like a scrollbar. Maybe an off-by-one error if preview is not included? You totally missed the point. What I meant was that Bram mentioned that he uses Ctrl+N to complete names in emails to make sure he doesn't misspell people's names. In his response to Jonathan's mail he wrote Nikola (note the missing 'i' in Nikola/i/), so I figured I'd be humorous about it and say that Ctrl+N completion seems broken in his version of Vim. nikolai Ah, I see. I thought it was something that /you/ had experienced. Yes, I missed the point, and the l of completion slipped away in the process (in part because I compose my emails using Thunderbird, not Vim, and that it doesn't have that kind of completion). Best regards, Tony. -- If anyone wants to trade a couple of centrally located, well-cushioned showgirls for an eroded slope 90 minutes from Broadway, I'll be on this corner tomorrow at 11 with my tongue hanging out. -- S. J. Perelman
Re: Spell checking in cwindow
Alexei Alexandrov wrote: Hi All! When spell checking is on by default, quick fix window is full of spell checking errors. Probably it should have off always, shouldn't it? Spell checking is off by default (the default for 'spell' is off). If it is on in a window you create, it must be because you set it yourself, maybe in your vimrc. To avoid setting it in special windows, use something like :autocmd BufNewFile,BufReadPost * if buftype != '' \ | setlocal nospell | endif Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 157. You fum through a magazine, you first check to see if it has a web address.
Re: Experimental patch -- clipboardwatch for Win32
Ken Hirsch wrote: Here is an experimental patch for a new feature for gvim on MS Windows. I'm glad to hear any feedback about the code or the feature itself. I've tried to follow the conventions in the vim source code. I call the feature ClipboardWatch. The new feature triggers an event ClipboardChanged whenever the clipboard is changed (in any application). The Windows editor NoteTab implements this (as pasteboard) and it is, at times, very handy. The feature is activated by :set clipboardwatch or :set cbw. To my .vimrc, I've added if has(clipboardwatch) au! ClipboardChanged * exec normal \*gp$ endif so that anything copied to the clipboard is pasted into the current buffer. Notes-- At http://kenhirsch.net/vim I have a downloadable zip file that includes these files: gvim.exe doc/autocmd.txt doc/eval.txt doc/map.txt doc/options.txt doc/tags doc/various.txt If you unzip directly into your Vim folder, usually C:\Program Files\Vim\vim70, you should be good to go. Some zip programs may not honor the full path, so you would have to copy the txt files to the vim70\doc directory. (This gvim.exe was compiled with nmake -f Make_mvc.mak GUI=yes DEFINES=-DFEAT_CBWATCH using Visual C++ Express 2005) I implemented the function 'ui_clipboard_changed()' in ui.c by copying what seemed relevant from 'ui_focus_change()'. Not knowing much about vim internals, it may need fixing, but I haven't seen any problems yet. I could implement a direct paste in addition to (or instead of) the event. This might be more convenient in most cases, if less flexible. I am using au! ClipboardChanged * exec normal \*gp$ Ouch! You would have to make sure to :enew when going to other applications, or you'd find yourself with rubbish pasted at the cursor in the current Vim buffer. (You may want to add a FocusLost autocommand to make sure some particular clipboard file was current.) To paste at end-of-file without moving the cursor: au! ClipboardChanged * exe 'norm m`' | $put + | norm `` I added the $ at the end because, when the cursor is at the end of the file and you *gp with complete lines, the cursor ends up at the beginning of the line. This might be considered a bug with normal gp. For X-Windows and MacOS, there doesn't seem to be any way for an application to get informed immediately (synchronously) of clipboard changes. X-windows seems to only notify the previous clipboard owner. I didn't see anything in the Mac API documentation that seemed right, but I'm not at all familiar with Mac programming, so I might have missed something. However, there's an open-source Mac utility called Jumpcut (http://jumpcut.sourceforge.net/) which attempts to provide similar functionality for Mac applications. It looks like it polls the clipboard once a second to see if it's changed. This leads to two conclusions: 1. Polling the clipboard is the only way to do it on the Mac. 2. Hey, that works! It could be done on X-Windows, too. IIUC, using * on X systems would (with your autocommand above) paste anything that got _selected_ with the mouse, even in the absence of an Edit = Copy command. Use + to limit yourself to what was explicitly copied or cut. The patch is relative to vim-7.0.220 These files are patched: runtime/doc/autocmd.txt runtime/doc/eval.txt runtime/doc/map.txt runtime/doc/options.txt runtime/doc/tags runtime/doc/various.txt src/eval.c src/fileio.c src/gui_w32.c src/gui_w48.c src/option.c src/option.h src/os_mswin.c src/proto/gui_w32.pro src/proto/ui.pro src/ui.c src/vim.h Ken Hirsch Chapel Hill, NC USA A lot of files to patch! I wonder whether the game is worth the candle. Best regards, Tony. -- Megaton Man:LOOK at them! Helpless, tender creatures, relying on ME, waiting for ME to make my move! (from below): Move your ASS, Fat-head! Megaton Man:It is a MANDATE, and I am DUTY BOUND to OBEY!
Re: patch 7.0.224
Bram Moolenaar wrote: Patch 7.0.224 Problem:When expanding ## spaces are escaped twice. Solution: Don't escape the spaces that separate arguments. Files: src/eval.c, src/ex_docmd.c, src/proto/ex_docmd.pro [...] This patch failed to appear at ftp.vim.org. Patching from the .eml saved email succeeded after hand-converting from quoted-printable to 8bit -- not actually 8bit since the only things to convert were :%s/=3D/=/g :%s/=\n//g Best regards, Tony. -- ... the privileged being which we call human is distinguished from other animals only by certain double-edged manifestations which in charity we can only call inhuman. -- R. A. Lafferty
Re: patch 7.0.224
Bram Moolenaar wrote: Tony Mechelynck wrote: [...] Patching from the .eml saved email succeeded after hand-converting from quoted-printable to 8bit -- not actually 8bit since the only things to convert were :%s/=3D/=/g :%s/=\n//g I'm still using text-only e-mail and don't have these strange problems. I received the patch email text-only but in Content-Transfer-Encoding: quoted-printable. This post of yours I got in 8bit. Dunno if it's your mailer or if my ISP autoconverted it: it happens, but I don't know what triggers the autoconversion step and in which direction among 8bit, quoted-printable and base64. Best regards, Tony. -- Millions long for immortality who do not know what to do with themselves on a rainy Sunday afternoon. -- Susan Ertz
Re: BUG vim 7.0-204?: autocmd CusorMoved vs select/visual mode vs :behave mswin vs norm!
Thomas wrote: Hi, When I use the following command (for demonstration purposes): au CursorMoved * norm! zz When I now press s-c-left or s-c-right, zz get inserted in the buffer. These cursor key seem to be set by :behave mswin. In summary: :au CursorMoved * norm! zz :behave mswin Press s-c-left or s-c-right zz gets inserted. Is there a work-around? Regards, Thomas. :behave mswin only sets a few options, but it is often used in conjunction with :source $VIMRUNTIME/mswin.vim, which sets a lot of potentially dangerous mappings. Search your vimrc /mswin\.vim and remove the line, or comment it away. Is the result better? Best regards, Tony. -- Scientists are people who build the Brooklyn Bridge and then buy it. -- William Buckley
Re: GVim Crash
Andy Wokula wrote: GVim7 (Win32) crashes if I do the following: clean startup :new :tabnew :call winnr(#) happens with or without 219 patches included Andy also on Linux with gvim 7.0.219 called as gvim -N -u NONE and also when replacing :call by :echo. Note that the last accessed window is on a different tab. Followup to vim-dev Best regards, Tony. -- Who needs friends when you can sit alone in your room and drink?
Re: Bug report : Spell checking doesn't know about HTML entities
Bram Moolenaar wrote: Tony Mechelynck wrote: In languages using accented letters, the Vim spell checker doesn't recognise HTML entities (in HTML text): for example, the letters outside of the ...; entities are highlighted as spellBad (after :set spell spelllang=fr) in the following French words: ougrave; meaning: où (where) apregrave;s après (after) ceacute;reacute;monie cérémonie (ceremony) courrouccedil;a courrouça ([he] angered) deacute;sespeacute;reacute; désespéré (desperate) neacute;cessairenécessaire (necessary) anneacute;e année (year) etc. They are perfectly valid French words, if one takes into account the following equivalences: ugrave; = ù egrave; = è eacute; = é ccedil; = ç etc. I don't know how to solve the problem; maybe an interpretation layer to resolve the entities between the HTML text and the French (or other non-English language) dictionary? Well, words with HTML things in them are NOT French words. Why don't you use utf-8 encoded HTML? I started that particular site some years ago, in 7-bit ASCII plus entities. I'm loath to change it now, and risk making it incompatible with some older browsers. It already holds quite a bit of text. I disagree with the statement that these words are not French words. In an HTML file, where HTML syntax must be taken into account, they are. If you really want to recognize these words, you could take the French dictionary, do a global replace and build a spell file from that. Actually, I don't use spell (I am blessed with a good sense of orthography); but I wondered if there couldn't (someday) be a solution for people who don't share the same blessing. The proposed solution would mean creating an additional spell file, slightly larger than the French dictionary, for use only with HTML text. I'm not convinced of such a solution's viability, especially since it would have to be repeated for German, Swedish, Turkish, Polish, etc., etc., etc. Maybe even for words like risqué and garçon in English. You'll have to check if using and ; in the middle of a word is causing trouble. Adding them to word characters will probably create different problems. The semicolon can also mean a semicolon, which is a punctuation mark and not a word character, and can be used as such after a word with no intervening space (or with nbsp; preceding it, depending on typesetting conventions). The case of the ampersand is simpler: to obtain a true ampersand in the rendered text, one must use one of amp; (symbolic entity) #38; (decimal entity) or #x26; (hex entity) in the HTML. Best regards, Tony.
Re: Bug report : Spell checking doesn't know about HTML entities
François Pinard wrote: [Bram Moolenar] Tony Mechelynck wrote: In languages using accented letters, the Vim spell checker doesn't recognise HTML entities (in HTML text) [...] You'll have to check if using and ; in the middle of a word is causing trouble. Adding them to word characters will probably create different problems. Character entities come from the old time people were still trying to salvage the 8th bit of each byte, on communication channels, to convey byte parity. And also, whatever justification people may invent, to protect their laziness about using tools able to do more than ASCII. They also bypass compatibility problems for users who have to upload HTML pages to servers where they don't master the headers which will be sent with the HTML. (Yes, now I know about the BOM and the META HTTP-EQUIV=Content-Type tag, but the former isn't mentioned and the latter is only mentioned but not explained, in the books I have about HTML.) Even now, email channels aren't guaranteed do be able to convey 8-bit text other than by downgrading it to 7-bit by means of conversion schemes like quoted-printable or base64: some servers are 8-bit-compliant, others still aren't. In the email I get, I sometimes notice that the body has been autoconverted between 8-bit, quoted-printable and base64 by my ISP's routers, with no obviously apparent rule to such behaviour. One property of character entities which is apparently not so well known (or maybe that property was withdrawn since then) is that the semicolon is optional. It is only mandatory where ambiguity would otherwise arise (for example, when a letter follows, a fairly common case after all). That property is not part of the present rules; it is obsolete and deprecated: ce n'est pas la règle, c'est une tolérance. It is only recognised for downward compatibility; IIUC, it does not apply to XHTML. The semicolon has of course always been mandatory when the entity is immediately followed by a letter or semicolon (or by a digit, but that is rarer). I presume that if software (or people) generating HTML were sparing those semicolons wherever they may be spared, a lot of other software would break, we would get a riot against people following standards :-). I suppose that's why the most recent standards require the semicolons. Best regards, Tony. -- Everything is worth precisely as much as a belch, the difference being that a belch is more satisfying. -- Ingmar Bergman
Bug report : Spell checking doesn't know about HTML entities
In languages using accented letters, the Vim spell checker doesn't recognise HTML entities (in HTML text): for example, the letters outside of the ...; entities are highlighted as spellBad (after :set spell spelllang=fr) in the following French words: ougrave; meaning: où (where) apregrave;s après (after) ceacute;reacute;monie cérémonie (ceremony) courrouccedil;a courrouça ([he] angered) deacute;sespeacute;reacute; désespéré (desperate) neacute;cessairenécessaire (necessary) anneacute;e année (year) etc. They are perfectly valid French words, if one takes into account the following equivalences: ugrave; = ù egrave; = è eacute; = é ccedil; = ç etc. I don't know how to solve the problem; maybe an interpretation layer to resolve the entities between the HTML text and the French (or other non-English language) dictionary? Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 131. You challenge authority and society by portnuking people
Re: improving encryption in vim
Ken Hirsch wrote: [...] To clarify, based on my understanding: if software is exported from the U.S., which vim arguably is, and it is capable of powerful encryption (64-bit symmetric keys, other limits for public-key/elliptic algorithms), then it _is_ subject to export restrictions. As the linked page says, it is exportable, but subject to a one-time review prior to export. It doesn't matter if all it does is call a subroutine that was developed in another country or even if the library itself was subjected to review and approval (e.g. see Legal Notices at http://aescrypt.sourceforge.net/). The regulations are at http://www.bis.doc.gov/encryption/Default.htm [...] Vim is exported from the Netherlands, not the US. Bram is a Dutch national, now living in Zurich (Switzerland) but during most of the time in which he developed Vim, he lived in Venlo (The Netherlands). The Vim ftp servers are hosted by ftp.nluug.nl (a server in the Netherlands). Best regards, Tony. -- Democracy is also a form of worship. It is the worship of Jackals by Jackasses. -- H. L. Mencken
[BUG] vimball changes global 'modifiable' setting
Opening a vimball in Vim sets 'nomodifiable' not only locally but also
globally: henceforward, all new [No Name] buffers opened in the same session
will be created with 'nomodifiable' set.
Workaround: Use :set modifiable in the first [No Name] buffer created after
opening a vimball.
Fix: See suggested patch, attached.
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
121. You ask for e-mail adresses instead of telephone numbers.
*** /usr/local/share/vim/vim70/plugin/vimballPlugin.vim Fri Mar 16 00:34:04 2007
--- /usr/local/share/vim/vimfiles/plugin/vimballPlugin.vim Sat Mar 17 09:07:46 2007
***
*** 27,33
com! -na=0 VimballList call vimball#Vimball(0)
com! -na=* -complete=dir RmVimball call vimball#RmVimball(f-args)
au BufEnter *.vba.gz,*.vba.bz2,*.vba.zip call vimball#Decompress(expand(amatch))
! au BufEnter *.vba set noma bt=nofile fmr=[[[,]]] fdm=marker|call vimball#ShowMesg(0,Source this file to extract it! (:so %))
=
Restoration And Modelines: {{{1
--- 27,33
com! -na=0 VimballList call vimball#Vimball(0)
com! -na=* -complete=dir RmVimball call vimball#RmVimball(f-args)
au BufEnter *.vba.gz,*.vba.bz2,*.vba.zip call vimball#Decompress(expand(amatch))
! au BufEnter *.vba setlocal noma bt=nofile fmr=[[[,]]] fdm=marker|call vimball#ShowMesg(0,Source this file to extract it! (:so %))
=
Restoration And Modelines: {{{1
Re: [BUG] vimball changes global 'modifiable' setting
A.J.Mechelynck wrote: Opening a vimball in Vim sets 'nomodifiable' not only locally but also globally: henceforward, all new [No Name] buffers opened in the same session will be created with 'nomodifiable' set. Workaround: Use :set modifiable in the first [No Name] buffer created after opening a vimball. Fix: See suggested patch, attached. Best regards, Tony. P.S. I think the autocommand in the modified line can be moved from the BufEnter event to the BufReadPost event. Best regards, Tony. -- The United States Army; 194 years of proud service, unhampered by progress.
Re: Case-sensitive :e globbing under cygwin?
John Wiersba wrote: This appears to be a bug to me, but I want to check before filing a bug report. I was unable to get any clarification on the vim mailing list. Under cygwin, :e file* will match in a case-insensitive manner. I believe this is wrong, since cygwin is emulating unix which is case-sensitive. Other tools, like bash, default to case-sensitive globbing. There is a bash option nocaseglob which allows bash to behave in a case-insensitive manner, but the default is unix-like. I believe vim under cygwin used to do case-sensitve filename globbing, but now it's doing it case-insensitively and I'd like to get it to revert to the old behavior. So, if there is a way to turn on/off case-sensitivity for :e file* globbing, then I would be happy to use it. If this is a build-time bug in the way vim is being built under cygwin, I can correspond with the cygwin maintainers to get it fixed. But, if neither of these apply, I will file a bug report/enhancement request for 1) adding an option to toggle case-sensitivity (a feature enhancement) and 2) making the default on cygwin be case-sensitive (a bug fix). Thanks much! -- John Wiersba Is your cygwin bash set to case-sensitive globbing? If it isn't, set it in your bash startup scripts (including whatever is sourced when starting non-interactive shells), then check if the Vim problem is still there. Best regards, Tony. -- If all the world's a stage, I want to operate the trap door. -- Paul Beatty
Re: google summer of code
Josh wrote: I am interested in creating a kde or other window manager interface for vim, adding debugger support or fixing bugs for google summer of code. Are there any details that I need to know before I submit my applications? It may be obvious, but obvious things have a way of getting overlooked: - When compiled with GNOME support, Vim already does some interfacing with the window manager, including the kde window manager. For instance, if Vim is running when you close the kde wm, it will be reopened with the same settings and editfiles when you restart kde. - There used to be a specific version of Vim with kde GUI (called kvim) but the kde guys dropped support for it at some point between releases 6.2 and 6.3 of Vim. It is now completely obsolete. See :help GNOME :help gnome-session Best regards, Tony. -- The conservation movement is a breeding ground of Communists and other subversives. We intend to clean them out, even if it means rounding up every bird watcher in the country. -- John Mitchell, Atty. General 1969-1972
Re: Building Vim7 with perl support using Aap
Ian Tegebo wrote: I followed the instructions at: http://www.a-a-p.org/ports.html and that installation yielded a vim without perl support. After looking at: http://www.a-a-p.org/examples.html#variants It seems like adding several flags shouldn't be that hard; I could even imagine that recipe files have already been written for this. Any recommendations? I don't use A-A-P; I compile make as a distinct step, and it has (since before Vim 7 alpha even existed) allowed me to compile Vim versions with all four of perl, python, ruby and TCL together. Of course you need the required interpreter(s) installed on your system (with development packages if compiling on Linux). See my howto pages at: - for Unix/Linux: http://users.skynet.be/antoine.mechelynck/vim/compunix.htm - for Windows:http://users.skynet.be/antoine.mechelynck/vim/compile.htm I believe you should be able to get inspiration from them to get your Vim source upgrades by A-A-P (or otherwise) and compile Vim manually with whichever features you want, including interpreted languages if you want them. For Windows, see also https://sourceforge.net/project/showfiles.php?group_id=43866package_id=39721 where Steve Hall keeps precompiled Vim distributions with periodic upgrades: as I'm writing this, the latest patchlevel there is 7.0.215. Although this page is part of the Cream (for Vim) project, the distributions on this particular page are plain-vanilla vim/gvim with all standard runtime files but without Vim. The :version text for its gvim 7.0.215 is at https://sourceforge.net/project/shownotes.php?group_id=43866release_id=492211 It includes (among others) +mzscheme/dyn +perl/dyn +python/dyn +ruby/dyn +tcl/dyn. Best regards, Tony. -- I'm really enjoying not talking to you ... Let's not talk again _REAL_ soon ...
Re: BUG? :tab wincmd ] doesn't open a new tab
Bram Moolenaar wrote: Tony Mechelynck wrote: Ctrl-W ] (or :wincmd ] ) splits the window to show the definition of the tag under the cursor, but prefixing it with :tab doesn't open a new tab: Reproducible: Always Steps to reproduce: 1. Place the cursor on a tag (e.g. on an identifier in a program for which ctags has been run). 2. Type either :tab wincmd ] or :tab exe norm \C-W] Actual result: The (first) file containing the tag definition is opened in a split window. Expected result: The file should have been opened in a new tab Right. It's not difficult to make this work. Vim 7.0.216 now opens a new tab for :tab wincmd ] but not for any of :tab exe norm \C-W] :exe tab norm \C-W] :tab norm ^W] (using Ctrl-V Ctrl-W to enter the latter): all three split the current window without changing tabs. Is this intended behaviour? If it is, then I guess doc/tabpage.txt (2006 Nov 18) should be modified near line 77 to mention that :tab also doesn't work with :normal (in addition to :diffsplit and :diffpatch). Best regards, Tony. -- Paul Revere was a tattle-tale
BUG? :tab wincmd ] doesn't open a new tab
Ctrl-W ] (or :wincmd ] ) splits the window to show the definition of the tag under the cursor, but prefixing it with :tab doesn't open a new tab: Reproducible: Always Steps to reproduce: 1. Place the cursor on a tag (e.g. on an identifier in a program for which ctags has been run). 2. Type either :tab wincmd ] or :tab exe norm \C-W] Actual result: The (first) file containing the tag definition is opened in a split window. Expected result: The file should have been opened in a new tab Additional info: 1. Workaround: :exe tab stag expand(cword) 2. Vim version VIM - Vi IMproved 7.0 (2006 May 7, compiled Mar 8 2007 18:29:45) Included patches: 1-214 Compiled by [EMAIL PROTECTED] Huge version with GTK2-GNOME GUI. Features included (+) or not (-): +arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset +cindent +clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments +cryptv +cscope +cursorshape +dialog_con_gui +diff +digraphs +dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path +find_in_path +folding -footer +fork() +gettext -hangul_input +iconv +insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap +menu +mksession +modify_fname +mouse +mouseshape +mouse_dec +mouse_gpm -mouse_jsbterm +mouse_netterm +mouse_xterm +multi_byte +multi_lang -mzscheme +netbeans_intg -osfiletype +path_extra +perl +postscript +printer +profile +python +quickfix +reltime +rightleft +ruby +scrollbind +signs +smartindent -sniff +statusline -sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white +tcl +terminfo +termresponse +textobjects +title +toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo +vreplace +wildignore +wildmenu +windows +writebackup +X11 -xfontset +xim +xsmp_interact +xterm_clipboard -xterm_save (etc.) Best regards, Tony. -- I call them as I see them. If I can't see them, I make them up. -- Biff Barf
Re: problems compiling vim 7 on solaris
Paul Stuart wrote: Hi there, I'm having some trouble compiling vim 7 on solaris 8, and I wonder if someone could point me in the right direction. This is what I see when I compile it : gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MOTIF -I/usr/dt/include -g -O2 -o objects/buffer.o buffer.c In file included from buffer.c:28: vim.h:41: parse error before `:' In file included from /usr/include/stdio.h:22, from os_unix.h:21, from vim.h:233, from buffer.c:28: /usr/include/iso/stdio_iso.h:186: parse error before `__va_list' /usr/include/iso/stdio_iso.h:187: parse error before `__va_list' /usr/include/iso/stdio_iso.h:188: parse error before `__va_list' In file included from os_unix.h:21, from vim.h:233, from buffer.c:28: /usr/include/stdio.h:227: parse error before `__va_list' In file included from /usr/include/wchar.h:11, from /usr/include/wctype.h:20, from vim.h:435, from buffer.c:28: /usr/include/iso/wchar_iso.h:191: parse error before `__va_list' /usr/include/iso/wchar_iso.h:192: parse error before `__va_list' /usr/include/iso/wchar_iso.h:193: parse error before `__va_list' make: *** [objects/buffer.o] Error 1 When I look in the config.log, I can see that there are errors there too, but I really don't know what to do about them. Here's (part of) the config.log. I haven't included all of it, cause it's quite long. This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by configure, which was generated by GNU Autoconf 2.59. Invocation command line was $ auto/configure redis --srcdir=. --cache-file=auto/config.cache ## - ## ## Platform. ## ## - ## hostname = openview1 uname -m = sun4u uname -r = 5.8 uname -s = SunOS uname -v = Generic_117350-30 /usr/bin/uname -p = sparc /bin/uname -X = System = SunOS Node = openview1 Release = 5.8 KernelID = Generic_117350-30 Machine = sun4u BusType = unknown Serial = unknown Users = unknown OEM# = 0 Origin# = 1 NumCPU = 2 /bin/arch = sun4 /usr/bin/arch -k = sun4u /usr/convex/getsysinfo = unknown hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/bin PATH: /bin PATH: /usr/sbin PATH: /sbin PATH: /usr/local/bin PATH: /opt/oracle/product/9.2.0/bin PATH: /usr/contrib/bin PATH: /usr/ccs/bin PATH: /usr/local/bin PATH: /export/home/pstuart/bin ## --- ## ## Core tests. ## ## --- ## configure:1266: creating cache auto/config.cache configure:1353: checking whether make sets $(MAKE) configure:1373: result: yes configure:1391: checking for redis-gcc configure:1420: result: no configure:1429: checking for gcc configure:1445: found /usr/local/bin/gcc configure:1455: result: gcc configure:1699: checking for C compiler version configure:1702: gcc --version /dev/null 5 2.95.3 configure:1705: $? = 0 configure:1707: gcc -v /dev/null 5 Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/specs gcc version 2.95.3 20010315 (release) configure:1710: $? = 0 configure:1712: gcc -V /dev/null 5 gcc: argument to `-V' is missing configure:1715: $? = 1 configure:1738: checking for C compiler default output file name configure:1741: gccconftest.c 5 configure:1744: $? = 0 configure:1790: result: a.out configure:1795: checking whether the C compiler works configure:1801: ./a.out configure:1804: $? = 0 configure:1821: result: yes configure:1828: checking whether we are cross compiling configure:1830: result: no configure:1833: checking for suffix of executables configure:1835: gcc -o conftestconftest.c 5 configure:1838: $? = 0 configure:1863: result: configure:1869: checking for suffix of object files configure:1890: gcc -c conftest.c 5 configure:1893: $? = 0 configure:1915: result: o configure:1919: checking whether we are using the GNU C compiler configure:1943: gcc -c conftest.c 5 configure:1949: $? = 0 configure:1953: test -z || test ! -s conftest.err configure:1956: $? = 0 configure:1959: test -s conftest.o configure:1962: $? = 0 configure:1975: result: yes configure:1981: checking whether gcc accepts -g configure:2002: gcc -c -g conftest.c 5 configure:2008: $? = 0 configure:2012: test -z || test ! -s conftest.err configure:2015: $? = 0 configure:2018: test -s conftest.o configure:2021: $? = 0 configure:2032: result: yes configure:2049: checking for gcc option to accept ANSI C configure:2119: gcc -c -g -O2 conftest.c 5 configure:2125: $? = 0 configure:2129: test -z || test ! -s conftest.err configure:2132: $? = 0 configure:2135: test -s conftest.o configure:2138: $? = 0
[Fwd: Re: Why does VimResized get triggered 4 times per resize]
Forwarding to list. Original Message Subject: Re: Why does VimResized get triggered 4 times per resize Date: Fri, 9 Mar 2007 18:49:25 +0200 From: Marius Roets [EMAIL PROTECTED] To: A.J.Mechelynck [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] Hi Tony, On Friday 09 March 2007 18:00, you wrote: function ResizeEvent() set lines-=1 redir ~/resize.log silent echo lines: lines redir END endfunction au! VimResized * call ResizeEvent() Thanks for showing me the redir command :) then invoking (once) :call ResizeEvent() at the gvim command-line, I get the following in ~/resize.log (which previously didn't exist): quote lines: 35 lines: 34 lines: 33 lines: 33 lines: 32 /quote Yes, this seems to vary, sometimes I get 3, sometimes 4. My results look similar. Which OS and Vim version (and patchlevel) are you using? I'm using openSUSE Linux 10.2 Same here. My problems started when I enabled Xgl, and changed the window manager to Compiz. Now Vim gives one line too many whenever I resize the window, hence the auto command. VIM - Vi IMproved 7.0 (2006 May 7, compiled Mar 8 2007 18:29:45) Included patches: 1-214 Compiled by [EMAIL PROTECTED] Huge version with GTK2-GNOME GUI. Features included (+) or not (-): (etc.) VIM - Vi IMproved 7.0 (2006 May 7, compiled Nov 27 2006 23:44:24) Included patches: 1-146 Compiled by http://www.suse.de/ Huge version with GTK2 GUI. Features included (+) or not (-): Funny, I was under the impression that I compiled Vim myself. Apparently I'm using a binary that came with Suse. Regards Marius
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.?
Re: Bug report: mapping fails with a few characters (i.e.: « :imap ’ foo » fails)
thomas wrote: 2007/3/2, A.J.Mechelynck [EMAIL PROTECTED]: Mapping seems to be buggy with some characters. For instance: :imap ' foo does not work (the apostrophe is U+2019). What is 'encoding' set to? Using multibyte characters (e.g. in a mapping) will only work if 'encoding' (which defines how characters are represented internally in Vim memory) is set to an appropriate multibyte setting beforehand The encoding is set to utf-8. My point is, mapping works with some multibyte characters, but not all of them. For example: :imap ∀ foo ... that is, mapping the forall symbol (U+2200), works. Since I can map some multibyte characters, there is in my opinion no issue with the encoding. The question is: why is it possible to map U+2200 but not U+2019? Regards, thomas Hm. It just might be a bug, but Bram would be better able than me to check this. I can map Char-0x2019 but I cannot really test that it works (I can just see that it is represented correctly in the list of mappings), because that character is not on my keyboard. U+2019 is encoded as E2 80 99 while U+2200 is E2 88 80. I wonder if the presence of a 0x80 in the middle might cause a bug in gvim. Did you try the code snippet in my previous post? If it works, then we can start digging why your previous method didn't work. If it doesn't, we should have a clear-cut testcase for others to try and reproduce. Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 80. At parties, you introduce your spouse as your service provider.
Re: Bug report: mapping fails wit h a few characters (i.e.: « :im ap ’ foo » fails)
Bram Moolenaar wrote:
[...]
How can you tell if the mapping works or not?
You can see what a key actually produces with CTRL-V key . So when
you type
:imap CTRL-V key foo
Where CTRL-V is one key and key is the mapped key.
Does the mapping still not work?
When I type
:map! “ -
where the {lhs}, U+201C (double high 6 quote) is produced on my keyboard by
AltGr-v
then,
:map!
list the mapping with “ (the character in question) in the {lhs}, but hitting
AltGr-v in Insert mode inserts “ (the {lhs}) not - (the {rhs}).
Using Ctrl-V before the key when defining the mapping makes no change: hitting
the key still doesn't invoke the mapping, but :map! “ (again, with or
without Ctrl-V) lists it.
Best regards,
Tony.
--
The grand leap of the whale up the Fall of Niagara is esteemed, by all
who have seen it, as one of the finest spectacles in nature.
-- Benjamin Franklin.
Re: todo? (setting eol/noeol after :r !cmd ? )
Yakov Lerner wrote: Hello Bram, Maybe vim would better set eol/noel after ':r !cmd' also, no only after reading the file into buffer ? (that is, the condition whether input had final \n or not). As I can see currently, this piece of info is lost after ': !cmd' ? Yakov Maybe after :$r !cmd (appending at end-of-file), but not in other cases since the last line of the file isn't touched. Best regards, Tony. -- Hard work may not kill you, but why take chances?
Bug? in vimgrep with g flag and long lines.
When cycling through matches using :cnext, if there are several matches in a single long line, the line is only shortened the first time (but _not_ the 2nd, 3rd, etc.,) to avoid a Hit-Enter prompt. Reproducible: every time. Steps to reproduce: 1. :set wrap I'm not sure this is necessary 2. :vimgrep /pattern/g filename where: - filename is a file or files with a number of lines longer than 'cmdheight' times 'columns' - /pattern/ will happen more than once in some long lines 3. :cn 4. Go to step 3. Notice that the first match in any given line never produces a Hit-enter prompt. Too-long lines have part of their non-matching text replaced by Actual result: 2nd, 3rd, etc. matches in any given line produces a Hit-enter prompt; the line is displayed in full, overflowing the command-line. Expected result: No hit-enter prompts. Additional info: I've been seeing this for as long as I've used :vimgrep (i.e., since shortly after that command was introduced) and I'm still seeing it in gvim 7.0.201. I just never came around to report it. (I didn't use the quickfix commands much before :vimgrep appeared, except for :helpgrep where lines are shorter than 80 characters.) Best regards, Tony. -- I'm going to Boston to see my doctor. He's a very sick man. -- Fred Allen
Re: gvim, Windows NAS share of a unix file system, hard links
Nathan Coulter wrote: bug report == version: VIM - Vi IMproved 7.0 (2006 May 7, compiled May 7 2006 16:23:43) MS-Windows 32 bit GUI version with OLE support problem: Writing to a file on a windows share where the underlying filesystem supports hard links, modifying a file using gvim (w command) causes the file to acquire a new inode. Contrast with the behavior of notepad.exe (file - save), which respects the hard link, keeping the inode intact. Apparently no patches were included: there are 201 official patches to date for Vim 7.0, the latest was a few days ago (see their table of contents at http://ftp.vim.org/pub/vim/patches/7.0/ ). Get updated distributions of Vim for Windows at https://sourceforge.net/project/showfiles.php?group_id=43866package_id=39721 I think this behaviour is related to how Vim handles backups. Set 'backupcopy' (q.v.) to yes in order to prevent renaming of the existing file: set bkc=yes Vim copies the file to create a backup, then edits the old file Advantage: all permission and ownership bits are conserved set bkc=no Vim renames the existing file to create a backup, then edits a new file with the old name advantage: faster set bkc=auto default same as no except when Vim can detect that this could cause problems (e.g., sees that the existing file is a link). advantage: tries to combine the advantages of the other two. Apparently in the case you mention, Vim-for-Windows doesn't detect that the target file is a hard link. Best regards, Tony. -- Every group has a couple of experts. And every group has at least one idiot. Thus are balance and harmony (and discord) maintained. It's sometimes hard to remember this in the bulk of the flamewars that all of the hassle and pain is generally caused by one or two highly-motivated, caustic twits. -- Chuq Von Rospach, about Usenet
Re: Cannot run background process in gvim 7
Manu Hack wrote: gvim --version gives [...] So? What exactly are you trying to do? How does it fail? Best regards, Tony. -- 'Twas midnight, and the UNIX hacks Did gyre and gimble in their cave All mimsy was the CS-VAX And Cory raths outgrabe. Beware the software rot, my son! The faults that bite, the jobs that thrash! Beware the broken pipe, and shun The frumious system crash!
Re: Quickfix window not working anymore
Bill McCarthy wrote: On Mon 19-Feb-07 7:21am -0600, A.J.Mechelynck wrote: Works for me. For me too. BTW, Tony, I've never used :copen before - I use :cw . There look the same but the documentation doesn't seem to indicate that they are the same. What's the difference between :copen and :cwindow ? :cwindow closes an already-open qf window if the error list is empty; if not open, it opens it if the error list is nonempty. :copen opens the qf window, and makes it current if already open. I rarely use :copen, I prefer :cnext and :cNext, with occasionally :cfirst and :clast. Best regards, Tony. -- Republicans raise dahlias, Dalmatians and eyebrows. Democrats raise Airedales, kids and taxes. Democrats eat the fish they catch. Republicans hang them on the wall. Republican boys date Democratic girls. They plan to marry Republican girls, but feel they're entitled to a little fun first. Democrats make up plans and then do something else. Republicans follow the plans their grandfathers made. Republicans consume three-fourths of the rutabaga produced in the USA. The remainder is thrown out. Republicans sleep in twin beds -- some even in separate rooms. That is why there are more Democrats. -- The Official Rules, as compiled by Paul Dickson
Re: Quickfix window not working anymore
Ryan Phillips wrote: Gautam Iyer [EMAIL PROTECTED] said: Hi All, I just upgraded to Vim-7.0.195, and found that my quick fix bindings don't work any more. For instance :vimgrep /pattern/ *.c :copen Then pressing Enter on a particular error does not move to that error location quick fix window. The same happens if instead of vimgrep I use :grep or :make. Does any one else have this problem? Thanks, GI PS: The problem persists if I use vim -N -u NONE, and also with Vim-7.0.17. I had this same problem. I did _not_ get this problem when I ran vim -N -u NONE, but happened when I had: nmap silent C-m :bnextCR nmap silent C-n :bprevCR in my .vimrc for some reason.. -Ryan Ctrl-M is also the Enter key: if you remap the one, the other is remapped to the same thing. Best regards, Tony. -- Fashion is a form of ugliness so intolerable that we have to alter it every six months. -- Oscar Wilde
Re: patch 7.0.193
Bram Moolenaar wrote: Alexei Alexandrov wrote; Hi Bram Moolenaar, you wrote: Patch 7.0.193 Problem:Using --remote or --remote-tab with an argument that matches 'wildignore' causes a crash. Solution: Check the argument count before using ARGLIST[0]. Files: src/ex_cmds.c After applying a patch I still observe differnt behavior between gvim.exe some file matching 'wildignore' and gvim.exe --remote-tab-silent some file matching 'wildignore' The first opens the file just fine, while the second says No match error message. Yes, well, there is a bit of a conflict about what Vim should do. You told Vim to ignore files with a certain extension, and then you tell it to edit such a file. In a new Vim this results in editing the file anyway, since there is nothing else to do. In an existing Vim you get an error message, and keep the file you were working on. I would think this is OK. Is there a specific situation where you need Vim to edit the file you wanted ignored? According to :help 'wildignore', «A file that matches with one of these patterns is ignored when completing file or directory names.» According to the name, I would expect matching files to be ignored when expanding wildcards. When specifying just a file name, with no wildcards and no completion, I would expect Vim to edit the file if it exists, regardless of any 'wildignore' setting. For instance if I want to salvage a previous version of a file from a backup: Let's say 'wildignore' is set to ~,.bak; then :args foobar.* or :e foobar.Tab should ignore foobar.bak but IMO :e foobar.bak shouldn't. Similarly on the command-line: gvim foobar.* should ignore it but gvim foobar.bak should edit it, regardless of whether --remote-tab-silent is on the command line or not. Best regards, Tony. -- Academic politics is the most vicious and bitter form of politics, because the stakes are so low. -- Wallace Sayre
Re: Vim + MzScheme on Ubuntu
Alexei Alexandrov wrote: Hi Bram Moolenaar, you wrote: I think the best method is to obtain all the files from subversion and then get the latest runtime files with rsync. Get spell files manually (this can be done automatically if you use a language for the first time). I tried to use the command given on the vim.sf.net site to update Windows runtime files: rsync -avzcP --delete ftp.nluug.nl::Vim/runtime/dos/ . It seems to work fine, but the result directory doesn't have spell directory at all. Is it bug or feature? As Bram said earlier, the runtime/dos directory on the ftp site doesn't contain any spell files. With --delete, it will delete in the target directory tree whatever it doesn't find in the source tree. If you download the full sources (unix+lang+extra) to some directory (let's say %HOME%\build\vim) creating there a tree starting at vim70, you can then maintain the runtime files (including the spell files) as follows (in Cygwin bash) (untested): cd $HOME/build/vim/vim70 rsync -avzcP --delete --exclude=\dos\ ftp.nluug.nl::Vim/runtime ./runtime cd src export CONF_ARGS='--with-global-runtime=/cygdrive/c/PROGRA~1/vim' make config make installruntime You will get runtime files with Unix ends-of-lines, but Vim-for-Windows can cope with that (provided that 'fileformats' includes unix, which is the default), and so does WordPad. Notepad can't swallow them but I guess you can live with that. Best regards, Tony. -- Show respect for age. Drink good Scotch for a change.
Re: newrw 107 and ':e .'
Bernhard Walle wrote: * A.J.Mechelynck [EMAIL PROTECTED] [2007-02-13 01:40]: It's Vim compiled by myself, from no other sources than Bram's official ones (including 192 official patches). Yes, that fixes it, but I don't want to have the new version in /usr/ simply because I have not root access on every machine (but my $HOME is everywhere through NFS and NIS). But following in ~/.vimrc helped: source ~/.vim/autoload/netrwSettings.vim source ~/.vim/autoload/netrwFileHandlers.vim source ~/.vim/autoload/netrw.vim source ~/.vim/plugin/netrwPlugin.vim Bernhard You shouldn't need that. The autoload subdirectory is for scripts which only have to be sourced on demand; but it is only supported in Vim 7 (and later ;-) ). If you are using Vim 7, remove the above lines and check the output of :scriptnames. When Vim loads, it should show ~/.vim/plugin/netrwPlugin.vim as the first or only netrw script, and no netrw script of another name (such as plugin/netrw.vim, which is obsolete). After you use the netrw facility (e.g. directory browsing), the :scriptnames display should include one or more of the autoload scripts mentioned above. Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 28. You have comandeered your teenager's phone line for the net and even his friends know not to call on his line anymore.
Re: Modelines: First Form
Bill McCarthy wrote:
Hello Vim Developers,
The help files specifies (see :help modeline):
-
There are two forms of modelines. The first form:
[text]{white}{vi:|vim:|ex:}[white]{options}
[text] any text or empty
{white} at least one blank character (Space or Tab)
{vi:|vim:|ex:} the string vi:, vim: or ex:
[white] optional white space
{options} a list of option settings, separated with white space or ':',
where each part between ':' is the argument for a :set
command
-
Yet most of the distributed help files fail to follow this
format (and are note second form).
Most end with a ':' which does not appear to be permitted
above.
It is. It just adds an empty do-nothing setting at the end.
Others start with 'vim:' without the mandatory white space
preceding it.
As stated in the following help text, the white space is not mandatory before
vi: or vim: if they start at the left margin. It is still required before
ex: to reduce the risk of confusion with example.
Perhaps the docs should mention that {white} is optional if
[text] is empty - if that is true. And a trailing ':' is
permitted.
It does: Let me quote:
The white space before {vi:|vim:|ex:} is required. This minimizes the chance
that a normal word like lex: is caught. There is one exception: vi: and
vim: can also be at the start of the line (for compatibility with version
3.0). Using ex: at the start of the line will be ignored (this could be
short for example:).
Also, for the second form, the same comment applies to its
{white}. It should also be mentioned that the mandatory ':'
is preceded by [white] (optional white space).
That is implicit: a :set command can be followed by any amount of whitespace
before being terminated by a | or linebreak.
quote
The second form (this is compatible with some versions of Vi):
[text]{white}{vi:|vim:|ex:}[white]se[t] {options}:[text]
[text] any text or empty
{white} at least one blank character (Space or Tab)
{vi:|vim:|ex:} the string vi:, vim: or ex:
[white] optional white space
se[t] the string set or se (note the space)
{options} a list of options, separated with white space, which is the
argument for a :set command
^
: a colon
[text] any text or empty
/quote
My options.txt is the following:
*options.txt* For Vim version 7.0. Last change: 2007 Jan 17
Best regards,
Tony.
--
Am I ranting? I hope so. My ranting gets raves.
Re: newrw 107 and ':e .'
Bernhard Walle wrote: * A.J.Mechelynck [EMAIL PROTECTED] [2007-02-12 02:47]: Bernhard Walle wrote: Hello, after I installed netrw 107 in my ~/.vim, I cannot browse a directory which :e /path/to/dir any more. That's annoying because also bookmarks don't work in the directory browser and there are some other problems. Can somebody help? Thanks! Works for me on openSUSE Linux 10.2 using: VIM - Vi IMproved 7.0 (2006 May 7, compiled Feb 11 2007 01:13:11) Included patches: 1-192 Compiled by [EMAIL PROTECTED] Huge version with GTK2-GNOME GUI. Features included (+) or not (-): [...] $VIMRUNTIME/plugin/netrwPlugin.vim dated Jul 18, 2006 $VIMRUNTIME/autoload/netrw.vim v107 dated Jan 03, 2007 $VIMRUNTIME/autoload/netrwFileHandlers.vim v9 dated May 30, 2006 $VIMRUNTIME/autoload/netrwSettings.vim v9a ASTRO-ONLY dated Jul 28, 2006 but that's vim compiled by yourself and netrw.vim not installed in $HOME, right? Maybe someone could help to tell me what code registers at vim to run as directory handler? Bernhard It's Vim compiled by myself, from no other sources than Bram's official ones (including 192 official patches). I didn't need to install netrw under ~/.vim because updating my runtime files from the official Vim site upgraded my netrw (under $VIMRUNTIME) to v107: see the 2nd of the fout netrw-related pathfilenames above. If you're on Linux and have the Vim sources installed, you can do the following: 1) Remove all netrw files from ~/.vim and $VIM/vimfiles 2) cd to the top build directory, e.g. cd ~/.build/vim/vim70 3) rsync -avzcP --delete --exclude=/dos/ ftp.nluug.nl::Vim/runtime/ ./runtime/ 4) cd src make installruntime 5) Check that you have no other netrw files in the production directories (those listed in 'runtimepath' and their subdirs) than the four listed above (or newer versions of the same). Best regards, Tony. -- A sense of humor keen enough to show a man his own absurdities will keep him from the commission of all sins, or nearly all, save those that are worth committing. -- Samuel Butler
Re: Inconsistent return from exists()
Bram Moolenaar wrote: Tony Mechelynck wrote: In VIM - Vi IMproved 7.0 (2006 May 7, compiled Feb 4 2007 03:42:30) Included patches: 1-191 Compiled by [EMAIL PROTECTED] Huge version with GTK2-GNOME GUI. Features included (+) or not (-): [...] exists(:simalt) or exists(:tearoff) return 2; however trying to use them results in E319: Sorry, the command is not available in this version Shouldn't the call to exists() have returned 0 (zero)? The command exists but it doesn't work. That is more something for has() to figure out. But it doesn't handle Ex commands specifically, you can only find out by check for certain features. I can add this to the todo list, but don't expect it soon. OK, well, I guess it's a case of better late than never or if you (Tony) want it real bad, then program it yourself ;-/ Best regards, Tony.
Re: Vim 8.0 Suggestion
Nikolai Weibull wrote: On 1/30/07, Martin Krischik [EMAIL PROTECTED] wrote: Am Dienstag 30 Januar 2007 schrieb [EMAIL PROTECTED]: - being able to open very large files quickly and without using too much memory. This could possibly be achieved by not loading the entire file immediately. File could be loaded lazily when required. The last (and only) editor to have that feature was The Atari Editor which run on 8 bit Atari computers. Was a full screen, modeing editor like vim as well :-). How do you mean? A lot of editors work like this. The Atari Editor is hardly the first, or last, editor to work this way. Sam works this way, Wily works this way, my editor ned works this way, James Brown's example editor Neatpad [1] works this way. It's usually down to the data structure used to manage buffer contents that defines whether it's possible to implement this feature or not. It's can also be down to support for various encodings that can require preprocessing of the files. I'm not sure to what degree Vim requires the whole file to be read before editing can commence. I'm, however, sure that it can be made to load files without too much preprocessing, but I'm also pretty sure that it would require a lot of work and I don't think it's worth the kind of time that Bram would have to invest in such a feature. Vim is, when it all comes down to it, designed to be a programmers editor, and that means that it'll mostly work with files smaller, mostly much smaller, than a megabyte, for which preprocessing works fine. nikolai nikolai [1] http://www.catch22.net/ IIUC, Vim loads the whole file in memory before starting to edit. It might be possible (but not necessarily worth the trouble on modern computers with their large memory and their huge virtual-memory addressing ranges) to only keep parts of the file in memory; but: - depending on the syn-sync setting, it may be necessary to scan part or all of the file in front of the edit point, even repeatedly, in order to synchronize the syntax highlighting properly. - if many scattered changes are made without saving the file, they may have to be written to the (Vim) swapfile, then later read from swap, causing a performance degradation over time. (I realize that for files which are larger than the available RAM, reading the whole file in memory actually always includes some virtual memory, which is OS swap, and not necessarily better managed than Vim swap.) - A command such as :$ or G (goto last line) can be implemented by seeking to EOF then scanning backwards; but for :8752 or 8752G (go to line 8752) I see no other possibility than counting the 8751 first ends-of-lines (if there are that many, of course), which means scanning the whole file until there. Of course, any search also requires scanning from the current location to the next match in the search direction (and the whole file if there is no match and wraparound is set). Loading the whole file in memory at the start allows building an index (or something) which will later allow lightning-fast access to any line given by number. I see this as an advantage when line numbers are known, e.g. when trying to evaluate a patch by looking at the parts of the source that it will change if applied, or when using a tagfile with line numbers (as opposed to a tagfile with search patterns). (And, yes, the index could be built incrementally as later parts of the file are accessed, but then a forward seek might seem to hang just because it goes to a part of the file not yet read from disk.) Vim is not only a programmer's editor (in the sense of an editor which can be used to edit source programs: even Notepad can do that). It can do any kind of editing, and it is particularly useful for complex editing tasks. If it is a programmer's editor, it is most importantly an editor which can be programmed (in five programming languages [six in version 7] including vimscript, which is a full structured-programming language for text, string, and integer processing). Unlike many other editors, it can handle any kind of text, including Unicode text, even if the underlying OS has no input method usable for arbitrary Unicode codepoints. The biggest file I'm currently using it for is 33.8 million bytes long. That file does take some time to load, and searching when there is no match, or no nearby match, does take a measurable time; but IMHO it remains bearable. Best regards, Tony.
Re: for vim v8: how about keepundo ?
Nikolai Weibull wrote: On 1/29/07, Charles E Campbell Jr [EMAIL PROTECTED] wrote: Nikolai Weibull wrote: On 1/29/07, Charles E Campbell Jr [EMAIL PROTECTED] wrote: The idea would be to leave the undo list alone, so that when the undo table gets updated next it'll have a bigger change. What do you mean? From the very short description it sounds like your describing :undojoin. A keepundo would be more akin to the keepjumps, keepalt style of suppressing some update for the command which follows. But to be able to undo/redo, Vim has to know about what changes have taken place, otherwise it can't guarantee that undo/redo will work correctly. nikolai IIUC what Dr.Chip said in his original post, the idea is to have the same set of changes to undo, but with more of them grouped under a single execution of undo/redo (i.e., make the undo points farther away from each other than they would be otherwise). I'm not sure how I feel about this suggestion. I guess the pros and cons would have to be discussed in detail. Best regards, Tony.
Re: Vim8 idea: complete strings
Martin Stubenschrott wrote: I often want to complete full strings in quotes (foo, 'bla', `command bla blub`). But for now, I really need to type all these things again and again. It would be nice, if I could say fc-x-c- to complete full strings. Or maybe also c-xc-' for single qouted strings, and c-xc-` for `-quoted strings. Or maybe just one command to complete all strings, and get from context, if we want to complete ' or ` strings, depending on what character is in front of c-xc-?. fc-xc-? would complete quoted strings 'c-xc-? '-quoted and so on. -- Martin Note: It is not always easy to determine (except by relying on syntax groups, which can be mis-synchronized, unless we use :syn sync fromstart which can be unduly slow) whether a given occurrence of or ' anywhere in the text being copied from is an opening or closing quote. Even « is an opening quote in French, closing in German, and vice-versa for ». Best regards, Tony.
Re: JavaScript indentation
Martin Stubenschrott wrote: On Sat, Jan 27, 2007 at 07:35:16PM +0100, Bram Moolenaar wrote: Whatever this ends up to be: Please send me the best javascript indent script, so that I can include it with the runtime files. A best guess is better than nothing. Full ack. BTW: The last time I browsed the updated runtime/ repository, there was no cppcomplete.vim in the autoload/ directory. I really recommend this omnicomplete script from vim.org's script repository for all C++ code editing, I even use it for coding C, because (in my opinion) it works better there than ccomplete.vim. Hope that gets added to the default vim 7.1 distribution, because it's quite the best working omni complete script I have seen so far. -- Martin For all file types which have no specific omnicomplete script, I recommend to enable syntax omni-completion, as followed (inspired from :help ft-synrax-omni): --- 8 --- start $VIM/vimfiles/after/plugin/syntaxcomplete.vim if has(autocmd) exists(+omnifunc) augroup syntaxcomplete autocmd Filetype * \ if omnifunc == | \ setlocal omnifunc=syntaxcomplete#Complete | \ endif augroup END endif --- 8 --- end $VIM/vimfiles/after/plugin/syntaxcomplete.vim The idea of placing it in an after-directory is so its autocommand gets defined (and, therefore, executed) as late as possible. Best regards, Tony.
Re: BOF Vim 8 - Suggestions
Marcus Aurelius wrote: [...] If the user wants to edit long lines, (s)he cannot write a quick mapping on-the-fly, because he needs something like this: map buffer silent up gk imap buffer silent up C-ogk map buffer silent down gj imap buffer silent down C-ogj map buffer silent home ghome imap buffer silent home C-oghome map buffer silent end gend imap buffer silent end C-ogend ***May i suggest a new command (or a standard plugin that is easy to find) that would do all of the above in one easy step?*** Optionally, the user could want this too: setlocal linebreak setlocal nolist Necessary for linebreak setlocal display+=lastline I'm not sure if it's OK or if it's going too far :-) [...] The following (among others) are set once and for all in my vimrc: set nojoinspaces set selection=inclusive keymodel=startsel set mousemodel=popup selectmode=mouse,key set laststatus=2 set display=lastline set list listchars=tab:\|_,eol:¶ silent! set listchars+=nbsp:~ Up, Down move up/down by screen lines j k (default) move down/up by file lines map Down gj imapDown C-Ogj map Upgk imapUpC-Ogk No problem for me, and no need to change them from file to file. Best regards, Tony.
Re: BOF Vim 8 - Suggestions
Georg Dahn wrote: Hi! --- A.J.Mechelynck [EMAIL PROTECTED] wrote: map Down gj imapDown C-Ogj map Upgk imapUpC-Ogk IMHO these mappings are a better choice: noremap Down gj noremap Up gk inoremap expr Down pumvisible() ? \ltDown : \ltC-Ogj inoremap expr Up pumvisible() ? \ltUp : \ltC-Ogk These two are V7 only, so: if exists(*pumvisible) inoremap expr Down pumvisible() ? \ltDown : \ltC-Ogj inoremap expr Up pumvisible() ? \ltUp : \ltC-Ogj else inoremap Down C-Ogj inoremap Up C-Ogk endif With this the cursor keys still work with the popup menu. In addition I define the following mappings: noremap S-Down gj noremap S-Up gk inoremap S-Down C-OghC-Ogj inoremap S-Up C-OghC-Ogk nnoremap S-Down ghC-Ogj nnoremap S-Up ghC-Ogk With these mappings invoking the selection mode works more consistently with above mappings. No problem for me, and no need to change them from file to file. I fully agree with this. Best wishes, Georg Best regards, Tony.
