Re: breakindent, take 2

2007-05-28 Thread A.J.Mechelynck

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)

2007-05-25 Thread A.J.Mechelynck

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)

2007-05-25 Thread A.J.Mechelynck

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'

2007-05-21 Thread A.J.Mechelynck

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]

2007-05-17 Thread A.J.Mechelynck

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]

2007-05-17 Thread A.J.Mechelynck

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?

2007-05-17 Thread A.J.Mechelynck

: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]

2007-05-17 Thread A.J.Mechelynck

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]

2007-05-16 Thread A.J.Mechelynck

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]

2007-05-16 Thread A.J.Mechelynck

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

2007-05-16 Thread A.J.Mechelynck

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

2007-05-15 Thread A.J.Mechelynck

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!

2007-05-14 Thread A.J.Mechelynck

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

2007-05-12 Thread A.J.Mechelynck

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

2007-05-12 Thread A.J.Mechelynck

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

2007-05-12 Thread A.J.Mechelynck

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

2007-05-11 Thread A.J.Mechelynck

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

2007-05-11 Thread A.J.Mechelynck

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?

2007-05-10 Thread A.J.Mechelynck

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?

2007-05-09 Thread A.J.Mechelynck

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

2007-05-09 Thread A.J.Mechelynck
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?

2007-05-09 Thread A.J.Mechelynck

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

2007-05-09 Thread A.J.Mechelynck

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

2007-05-09 Thread A.J.Mechelynck

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

2007-05-09 Thread A.J.Mechelynck

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

2007-05-08 Thread A.J.Mechelynck

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

2007-05-08 Thread A.J.Mechelynck

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

2007-05-08 Thread A.J.Mechelynck
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?

2007-05-08 Thread A.J.Mechelynck

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

2007-05-07 Thread A.J.Mechelynck

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.

2007-05-07 Thread A.J.Mechelynck

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)

2007-05-07 Thread A.J.Mechelynck

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.

2007-05-07 Thread A.J.Mechelynck

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

2007-05-06 Thread A.J.Mechelynck

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 ?

2007-05-06 Thread A.J.Mechelynck

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

2007-05-06 Thread A.J.Mechelynck

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)

2007-05-06 Thread A.J.Mechelynck

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 ?

2007-05-06 Thread A.J.Mechelynck

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

2007-05-03 Thread A.J.Mechelynck

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

2007-05-01 Thread A.J.Mechelynck

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

2007-05-01 Thread A.J.Mechelynck

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

2007-05-01 Thread A.J.Mechelynck

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

2007-04-30 Thread A.J.Mechelynck
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

2007-04-30 Thread A.J.Mechelynck

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

2007-04-30 Thread A.J.Mechelynck

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

2007-04-30 Thread A.J.Mechelynck

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

2007-04-27 Thread A.J.Mechelynck

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?

2007-04-27 Thread A.J.Mechelynck

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?

2007-04-27 Thread A.J.Mechelynck

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

2007-04-27 Thread A.J.Mechelynck

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?

2007-04-26 Thread A.J.Mechelynck

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?

2007-04-26 Thread A.J.Mechelynck

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

2007-04-26 Thread A.J.Mechelynck

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

2007-04-25 Thread A.J.Mechelynck

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

2007-04-24 Thread A.J.Mechelynck

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

2007-04-24 Thread A.J.Mechelynck

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

2007-04-24 Thread A.J.Mechelynck

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

2007-04-22 Thread A.J.Mechelynck

Виктор Кожухаров 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

2007-04-21 Thread A.J.Mechelynck

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

2007-04-21 Thread A.J.Mechelynck

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

2007-04-01 Thread A.J.Mechelynck

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

2007-03-27 Thread A.J.Mechelynck

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

2007-03-27 Thread A.J.Mechelynck

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

2007-03-27 Thread A.J.Mechelynck

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!

2007-03-25 Thread A.J.Mechelynck

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

2007-03-25 Thread A.J.Mechelynck

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

2007-03-23 Thread A.J.Mechelynck

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

2007-03-23 Thread A.J.Mechelynck

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

2007-03-22 Thread A.J.Mechelynck
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

2007-03-20 Thread A.J.Mechelynck

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

2007-03-17 Thread A.J.Mechelynck
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

2007-03-17 Thread A.J.Mechelynck

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?

2007-03-15 Thread A.J.Mechelynck

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

2007-03-15 Thread A.J.Mechelynck

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

2007-03-14 Thread A.J.Mechelynck

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

2007-03-11 Thread A.J.Mechelynck

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

2007-03-10 Thread A.J.Mechelynck
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

2007-03-09 Thread A.J.Mechelynck

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]

2007-03-09 Thread A.J.Mechelynck

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

2007-03-06 Thread A.J.Mechelynck

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)

2007-03-02 Thread A.J.Mechelynck

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)

2007-03-02 Thread A.J.Mechelynck

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 ? )

2007-02-28 Thread A.J.Mechelynck

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.

2007-02-24 Thread A.J.Mechelynck
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

2007-02-24 Thread A.J.Mechelynck

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

2007-02-21 Thread A.J.Mechelynck

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

2007-02-19 Thread A.J.Mechelynck

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

2007-02-19 Thread A.J.Mechelynck

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

2007-02-18 Thread A.J.Mechelynck

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

2007-02-14 Thread A.J.Mechelynck

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 .'

2007-02-13 Thread A.J.Mechelynck

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

2007-02-13 Thread A.J.Mechelynck

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 .'

2007-02-12 Thread A.J.Mechelynck

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()

2007-02-04 Thread A.J.Mechelynck

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

2007-01-30 Thread A.J.Mechelynck

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 ?

2007-01-29 Thread A.J.Mechelynck

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

2007-01-29 Thread A.J.Mechelynck

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

2007-01-27 Thread A.J.Mechelynck

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

2007-01-26 Thread A.J.Mechelynck

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

2007-01-26 Thread A.J.Mechelynck

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.


  1   2   3   4   >