Re: Bug in netrw.vim
A.J.Mechelynck wrote: Charles E Campbell Jr wrote: Victor Hsieh wrote: [...] I know. But I just want to read the html code or so with my favoriate editor ;) I used to do it with vim6. Actually in most case, connecting to ftp://somewhere (when open http://somewhere) is not gonna work. Not if you don't have the username/password access to the site, 'tis true. [...] Also not if there is no FTP server at that address. Many FTP servers can be accessed read-only by HTTP; but most HTTP servers have no FTP counterpart AFAIK. Many? Like Victor, I would have said most. In fact, other than software mirrors (gnu.org and the like) I think it's pretty rare to have a site where http and ftp are mirrors of each other (my web host, for instance, gives me a chroot'd environment when I log into ftp, so even though they have both, they are not symmetric). And most sites (e.g. google.com) don't have ftp at all. Trying ftp://somewhere when http://somewhere doesn't work *might* work 1% of the time. I would say http:// should be treated read-only, since it almost always is, and the few cases where it isn't span a wide variety of /ways/ in which it isn't. -- Matthew What's Cygwin? you ask. 'Tis mostly absurd software Concerning hippos.
Re: Possible addition to the c.vim and perl.vim syntax files
Mike Williams wrote: mwoehlke did utter on 11/09/2006 18:37: Mike Williams wrote: mwoehlke did utter on 11/09/2006 17:44: Bram Moolenaar wrote: I don't know what the rules are in all kinds of C, but at least things like 0x0L, 0x0u, 0x0UL are valid. Using a match instead of region would be simpler. If one takes KATE's c.xml as canonical, supported suffixes (but not necessarily on all build configurations) are all combinations of 'U', 'L' and 'L', with no mention of 'u'. That makes: ULL, LUL, LLU, LL, UL, LU, L and U. As a regexp, 'U?L?L?|L?(UL|LU)'. Standard C only allows the following suffixes (in lower or uppercase): u, ul, ull, l, lu, and llu. D'oh! I looked again, and I see that c.xml says 'insensitive=TRUE', so all of the above are case-insensitive. But you are saying that 'ull'/'llu' are supported, but NOT 'll'? That can't be right? I would not be surprised if 'lul' is not well-supported, however. Mea culpa, you are right. Add an ll to the above list. What are not valid is lul. Ah, whew, my faith in standards is restored. :-) Thanks for following up. -- Matthew Ok, so the quotes aren't entirely original.
Re: Possible addition to the c.vim and perl.vim syntax files
Mike Williams wrote: mwoehlke did utter on 11/09/2006 17:44: Bram Moolenaar wrote: I don't know what the rules are in all kinds of C, but at least things like 0x0L, 0x0u, 0x0UL are valid. Using a match instead of region would be simpler. If one takes KATE's c.xml as canonical, supported suffixes (but not necessarily on all build configurations) are all combinations of 'U', 'L' and 'L', with no mention of 'u'. That makes: ULL, LUL, LLU, LL, UL, LU, L and U. As a regexp, 'U?L?L?|L?(UL|LU)'. Standard C only allows the following suffixes (in lower or uppercase): u, ul, ull, l, lu, and llu. D'oh! I looked again, and I see that c.xml says 'insensitive=TRUE', so all of the above are case-insensitive. But you are saying that 'ull'/'llu' are supported, but NOT 'll'? That can't be right? I would not be surprised if 'lul' is not well-supported, however. -- Matthew KATE: Awesome Text Editor
Re: Possible addition to the c.vim and perl.vim syntax files
mwoehlke wrote: Mike Williams wrote: mwoehlke did utter on 11/09/2006 17:44: Bram Moolenaar wrote: I don't know what the rules are in all kinds of C, but at least things like 0x0L, 0x0u, 0x0UL are valid. Using a match instead of region would be simpler. If one takes KATE's c.xml as canonical, supported suffixes (but not necessarily on all build configurations) are all combinations of 'U', 'L' and 'L', with no mention of 'u'. That makes: ULL, LUL, LLU, LL, UL, LU, L and U. As a regexp, 'U?L?L?|L?(UL|LU)'. Standard C only allows the following suffixes (in lower or uppercase): u, ul, ull, l, lu, and llu. D'oh! I looked again, and I see that c.xml says 'insensitive=TRUE', so all of the above are case-insensitive. But you are saying that 'ull'/'llu' are supported, but NOT 'll'? That can't be right? I would not be surprised if 'lul' is not well-supported, however. ...and I don't think it is. According to a cross-platform-support header we use, 'LL' is supported on the default compilers for HPUX, Linux, Irix, and Solaris (in 32-bit mode); possibly others as well. Microsoft's compiler, being the non-standard aberration it is, of course uses 'i64' for 64-bit integral constants. I don't think we need to worry about supporting _that_ :-). -- Matthew KATE: Awesome Text Editor
Re: Possible addition to the c.vim and perl.vim syntax files
Nikolai Weibull wrote: On 9/11/06, mwoehlke [EMAIL PROTECTED] wrote: mwoehlke wrote: Mike Williams wrote: mwoehlke did utter on 11/09/2006 17:44: Bram Moolenaar wrote: I don't know what the rules are in all kinds of C, but at least things like 0x0L, 0x0u, 0x0UL are valid. Using a match instead of region would be simpler. If one takes KATE's c.xml as canonical, supported suffixes (but not necessarily on all build configurations) are all combinations of 'U', 'L' and 'L', with no mention of 'u'. That makes: ULL, LUL, LLU, LL, UL, LU, L and U. As a regexp, 'U?L?L?|L?(UL|LU)'. Standard C only allows the following suffixes (in lower or uppercase): u, ul, ull, l, lu, and llu. D'oh! I looked again, and I see that c.xml says 'insensitive=TRUE', so all of the above are case-insensitive. But you are saying that 'ull'/'llu' are supported, but NOT 'll'? That can't be right? I would not be surprised if 'lul' is not well-supported, however. ...and I don't think it is. According to a cross-platform-support header we use, 'LL' is supported on the default compilers for HPUX, Linux, Irix, and Solaris (in 32-bit mode); possibly others as well. For the literature, see /The C Programming Language/, Second Edition, Section A2.5.1, Integer Constants, p. 193. Since none of the standards are freely available (not that I can see, anyway), all I can tell you is what is widely supported, and 'll' seems to qualify. -- Matthew KATE: Awesome Text Editor
Re: Patch (Unofficial): Malformed characters in menu and toolbar when using zh_CN.GBK encoding under Linux
Bram Moolenaar wrote: hundred-and-one symptoms of being an internet addict: 256. You are able to write down over 250 symptoms of being an internet addict, even though they only asked for 101. So where is the complete list? ;-) FIXME and XXX are two common keywords used to mark broken or incomplete code not only since XXX as a sex reference would grab everbodys attention but simply due to the fact that Vim would highlight these words. -- Hendrik Scholz ...and those of us that use KATE (I use VIM for one-off edits, and when I'm not working on my local box) simply edit alerts.xml :-) -- Matthew We're all mad here. I'm mad. You're mad... You must be, or you wouldn't have come here. -- The Cheshire Cat
Re: Patch 7.0.047
Bram Moolenaar wrote: Patch 7.0.047 Problem:When running configure the exit status is wrong. Solution: Handle the exit status properly. (Matthew Woehlke) Files: configure, src/configure [snip] Thanks, Bram! -- Matthew I blame the hippo.
Re: vim -S
(On the list, please?) Rodolfo Borges wrote: mwoehlke wrote: A.J.Mechelynck wrote: Rodolfo Borges wrote: I made a file with vim commands, starting with #!/usr/bin/vim -S so I can execute the file directly, instead of using vim -S file. The problem is that vim tries to execute this first line too. Can we have a workaround on this? Like, ignoring #! at the start of a command, instead of giving the no ! allowed error? Or am I having it all wrong? Method I: -8- foo (or whatever) #!/bin/bash vim -S foo.vim -8- then put the rest in foo.vim and do chmod a+x foo or chmod 0755 foo. Method II: add to one of your shell startup scripts (~/.bashrc or whatever): alias foo='vim -S ~/foo.vim' Commentary: In a vim script, the first line has no special meaning. Empty lines, blank lines (i.e. consisting only of spaces and/or tabs) and lines starting with zero or more spaces or tabs plus a double quote are comments; the rest are ex-commands (which don't have to start with a colon). :# is synonymous with :number so Vim tries to execute your first line as the command :number!/usr/bin/vim -S. Now the :number command doesn't accept a bang (there is no :number! command), so you get an error. So... if it's an error, and we know it's an error, and will always be an error (at least at the present)... is in unreasonable to make '#!.*', as the first line of a '-S' script, be ignored? *I* thought it was a reasonable suggestion... That was my first thought. Now, why does Vim use instead of # for comments is a mistery to me.. Probably because - as Tony noted (above) - '#' itself is potentially a valid command? (But I still say this is a reasonable exception.) -- Matthew This is not the list you're looking for. -- Perversion of Obi Wan
Re: vim -S
A.J.Mechelynck wrote: Rodolfo Borges wrote: I made a file with vim commands, starting with #!/usr/bin/vim -S so I can execute the file directly, instead of using vim -S file. The problem is that vim tries to execute this first line too. Can we have a workaround on this? Like, ignoring #! at the start of a command, instead of giving the no ! allowed error? Or am I having it all wrong? Method I: -8- foo (or whatever) #!/bin/bash vim -S foo.vim -8- then put the rest in foo.vim and do chmod a+x foo or chmod 0755 foo. Method II: add to one of your shell startup scripts (~/.bashrc or whatever): alias foo='vim -S ~/foo.vim' Commentary: In a vim script, the first line has no special meaning. Empty lines, blank lines (i.e. consisting only of spaces and/or tabs) and lines starting with zero or more spaces or tabs plus a double quote are comments; the rest are ex-commands (which don't have to start with a colon). :# is synonymous with :number so Vim tries to execute your first line as the command :number!/usr/bin/vim -S. Now the :number command doesn't accept a bang (there is no :number! command), so you get an error. So... if it's an error, and we know it's an error, and will always be an error (at least at the present)... is in unreasonable to make '#!.*', as the first line of a '-S' script, be ignored? *I* thought it was a reasonable suggestion... -- Matthew DOS Attack: See America Online -- my college room mate
Re: Crazy wish: vimcat
Benji Fisher wrote: On Fri, Jul 21, 2006 at 03:31:15PM -0500, mwoehlke wrote: Is this possible? It just occurred to me that it would be great if there was a VIM-related program that would 'cat' in color using VIM's highlighting rules. Is this something that VIM could be made to do via scripting, or would it need to be a totally new program? If the latter, any guesses how hard it would be to make such a critter? I notice that echo ':q' | vim file sort-of works... it gives the first page, plus trailing '~'s (if less then a page), although this wouldn't work with TERM's where curses displays are a separate buffer (like 'xterm', but not 'linux'). Maybe this is what you want: http://www.vim.org/tips/tip.php?tip_id=121 I keep meaning to play with this, but it occurs to me I am pretty sure this is not what I want. First off, I want 'cat', not 'more' (i.e. not a pager). Second, for it to work right, it has to *not* use the termlib, for the above-mentioned reason. -- Matthew DOS Attack: See America Online -- my college room mate
Re: Bug in filetype.vim w.r.t. mutt temp file names
Yakov Lerner wrote:
On 7/26/06, mwoehlke [EMAIL PROTECTED] wrote:
Gary Johnson wrote:
I noticed recently that vim does not always set 'filetype' to mail
when I edit mutt temporary files, e.g., postponed messages. I
traced the problem to mutt's use of mktemp() with the pattern
muttXX. I don't know about other OSs, but mktemp() on SunOS
5.8 replaces those Xs with characters from the POSIX portable
filename character set:
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
0 1 2 3 4 5 6 7 8 9 . _ -
The pattern used in filetype.vim to match file names of this form is
mutt\w\{6\}
The \w character class does not include the characters '.' or '-'.
I replaced that pattern with this one:
mutt[[:alnum:]._-]\{6\}
I was surprised that [:alnum:] worked in the context of an
autocommand filename pattern. I didn't want to use \f because it
included too much.
A patch is attached. I have posted it here rather than sending it
to Bram directly to allow others to comment in case I missed
something.
Ok, you asked for comments :-).
What's wrong with:
mutt[\w.-]\{6\}
I think \w is not recognized inside [].
Hmm... ok, maybe not. I must be thinking of KATE and '\s'. Or maybe KATE
also supports '\w' in []'s.
--
Matthew
DOS Attack: See America Online -- my college room mate
Crazy wish: vimcat
Is this possible? It just occurred to me that it would be great if there was a VIM-related program that would 'cat' in color using VIM's highlighting rules. Is this something that VIM could be made to do via scripting, or would it need to be a totally new program? If the latter, any guesses how hard it would be to make such a critter? I notice that echo ':q' | vim file sort-of works... it gives the first page, plus trailing '~'s (if less then a page), although this wouldn't work with TERM's where curses displays are a separate buffer (like 'xterm', but not 'linux'). -- Matthew Doom doom dooM doo-DooM dOOm DOom doOM... DOOM! -- Gir
Re: VIM7 on Tandem OSS
A.J.Mechelynck wrote:
mwoehlke wrote:
A.J.Mechelynck wrote:
mwoehlke wrote:
Well, that was exciting... I recently tried to build vim 7 on OSS
(Tandem / HP Nonstop S-Series). I finally got it to work by diff'ing
the ITUG Floss sources (link below) against vim-6.1 and applying the
diffs to vim-7.0 (and by first building/installing ncurses-5.5). I
would like to submit my efforts to be included upstream. Are there
any objections if I post the .patch here?
If the patch is relatively small, you can also post it on the vim-dev
list [snip]
Well, I guess 260 lines is not overly large (at any rate, I see there
have been larger things on the list), so here it is. NOTE: the changes
to Makefile are broken in that they are not conditional to TANDEM. It
seems like -lfloss should be added more nicely (ideally by ./configure)
but I am not sure where or how to make such a change.
You still need to compile with -WIEEE_float (including ncurses, if you
use it), because libfloss is IEEE_float.
--
Matthew
We're all mad here. I'm mad. You're mad... You must be, or you wouldn't
have come here. -- The Cheshire Cat
file:///faith3/home/mwoehlke/src/other/vim/vim7_oss.patch
diff -cr mine/src/ex_cmds.c oss/src/ex_cmds.c
*** mine/src/ex_cmds.c 2006-04-22 13:56:56.0 -0500
--- oss/src/ex_cmds.c 2006-07-18 16:55:59.0 -0500
***
*** 1765,1771
--- 1765,1775
*/
st_old.st_dev = st_old.st_ino = 0;
st_old.st_mode = 0600;
+ #ifdef __TANDEM
+ if (mch_stat((char *)fname, st_old) == 0 (getuid() != 65535)
+ #else
if (mch_stat((char *)fname, st_old) == 0 getuid()
+ #endif
!(st_old.st_uid == getuid()
? (st_old.st_mode 0200)
: (st_old.st_gid == getgid()
diff -cr mine/src/fileio.c oss/src/fileio.c
*** mine/src/fileio.c 2006-04-30 10:28:57.0 -0500
--- oss/src/fileio.c 2006-07-18 16:56:37.0 -0500
***
*** 25,34
# include fcntl.h
#endif
- #ifdef __TANDEM
- # include limits.h /* for SSIZE_MAX */
- #endif
-
#if defined(HAVE_UTIME) defined(HAVE_UTIME_H)
# include utime.h /* for struct utimbuf */
#endif
--- 25,30
***
*** 1105,1115
if (!skip_read)
{
#if SIZEOF_INT 2
- # ifdef __TANDEM
- size = SSIZE_MAX; /* use max I/O size, 52K */
- # else
size = 0x1L; /* use buffer = 64K */
- # endif
#else
size = 0x7ff0L - linerest; /* limit buffer to 32K */
#endif
--- 1101,1107
diff -cr mine/src/Makefile oss/src/Makefile
*** mine/src/Makefile 2006-05-07 08:25:27.0 -0500
--- oss/src/Makefile 2006-07-18 18:24:48.0 -0500
***
*** 1287,1293
PFLAGS = $(PROTO_FLAGS) -DPROTO $(LINT_CFLAGS)
ALL_LIB_DIRS = $(GUI_LIBS_DIR) $(X_LIBS_DIR)
! ALL_LIBS = $(GUI_LIBS1) $(GUI_X_LIBS) $(GUI_LIBS2) $(X_PRE_LIBS) $(X_LIBS) $(X_EXTRA_LIBS) $(LIBS) $(EXTRA_LIBS) $(MZSCHEME_LIBS) $(PERL_LIBS) $(PYTHON_LIBS) $(TCL_LIBS) $(RUBY_LIBS) $(PROFILE_LIBS)
# abbreviations
DEST_BIN = $(DESTDIR)$(BINDIR)
--- 1287,1293
PFLAGS = $(PROTO_FLAGS) -DPROTO $(LINT_CFLAGS)
ALL_LIB_DIRS = $(GUI_LIBS_DIR) $(X_LIBS_DIR)
! ALL_LIBS = $(GUI_LIBS1) $(GUI_X_LIBS) $(GUI_LIBS2) $(X_PRE_LIBS) $(X_LIBS) $(X_EXTRA_LIBS) $(LIBS) $(EXTRA_LIBS) $(MZSCHEME_LIBS) $(PERL_LIBS) $(PYTHON_LIBS) $(TCL_LIBS) $(RUBY_LIBS) $(PROFILE_LIBS) -lfloss
# abbreviations
DEST_BIN = $(DESTDIR)$(BINDIR)
diff -cr mine/src/osdef1.h.in oss/src/osdef1.h.in
*** mine/src/osdef1.h.in 2004-06-07 09:32:26.0 -0500
--- oss/src/osdef1.h.in 2006-07-18 17:00:20.0 -0500
***
*** 98,104
--- 98,106
#ifndef USE_SYSTEM
extern int fork __ARGS((void));
+ #ifndef __TANDEM
extern int execvp __ARGS((const char *, const char **));
+ #endif
extern int wait __ARGS((int *)); /* will this break things ...? */
extern int waitpid __ARGS((pid_t, int *, int));
#endif
***
*** 123,132
extern int kill __ARGS((int, int));
extern int access __ARGS((char *, int));
extern int fsync __ARGS((int));
extern int fchown __ARGS((int, int, int));
! #if defined(HAVE_GETCWD) !defined(sun)
extern char *getcwd __ARGS((char *, int));
#else
extern char *getwd __ARGS((char *));
--- 125,136
extern int kill __ARGS((int, int));
+ #ifndef __TANDEM
extern int access __ARGS((char *, int));
+ #endif
extern int fsync __ARGS((int));
extern int fchown __ARGS((int, int, int));
! #if defined(HAVE_GETCWD) !defined(sun) !defined(__TANDEM)
extern char *getcwd __ARGS((char *, int));
#else
extern char *getwd __ARGS((char *));
diff -cr mine/src/osdef2.h.in oss/src/osdef2.h.in
*** mine/src/osdef2.h.in 2004-06-07 09:32:26.0 -0500
--- oss/src/osdef2.h.in 2006-07-18 17:01:31.0 -0500
***
*** 11,23
--- 11,29
extern int setenv __ARGS((char *, char *, int));
extern int putenv __ARGS((const char *));
+ #ifndef __TANDEM
extern int gethostname __ARGS((char *, int));
+ #endif
extern void perror __ARGS((char
VIM7 on Tandem OSS
Well, that was exciting... I recently tried to build vim 7 on OSS (Tandem / HP Nonstop S-Series). I finally got it to work by diff'ing the ITUG Floss sources (link below) against vim-6.1 and applying the diffs to vim-7.0 (and by first building/installing ncurses-5.5). I would like to submit my efforts to be included upstream. Are there any objections if I post the .patch here? This is the ITUG vim: https://www.itug.org/secure/ituglib/shared/act_download.cfm/vim.tar.Z?lib_file_id=666 NOTE: I also had to configure ncurses and vim as follows: ncurses5-5$ CFLAGS=-WIEEE_float ./configure vim-7.0$ LDFLAGS=-lfloss CFLAGS=-WIEEE_float ./configure (I am not sure if 'floss' is necessary, but it was used in ITUG vim61.) -- Matthew Lions and tigers and ...penguins? We're being invaded!
Re: VIM7 on Tandem OSS
A.J.Mechelynck wrote: mwoehlke wrote: Well, that was exciting... I recently tried to build vim 7 on OSS (Tandem / HP Nonstop S-Series). I finally got it to work by diff'ing the ITUG Floss sources (link below) against vim-6.1 and applying the diffs to vim-7.0 (and by first building/installing ncurses-5.5). I would like to submit my efforts to be included upstream. Are there any objections if I post the .patch here? This is the ITUG vim: https://www.itug.org/secure/ituglib/shared/act_download.cfm/vim.tar.Z?lib_file_id=666 NOTE: I also had to configure ncurses and vim as follows: ncurses5-5$ CFLAGS=-WIEEE_float ./configure vim-7.0$ LDFLAGS=-lfloss CFLAGS=-WIEEE_float ./configure (I am not sure if 'floss' is necessary, but it was used in ITUG vim61.) Well, IMHO you ought to send them to Bram [EMAIL PROTECTED] , preferably in the form of context or unified diffs against the most recent sources (i.e., 7.0 as seen after applying the 39 official patches already published). If your patches are bulky, they might perhaps not be worth publishing on the list; but that's only my private opinion. Well, I'll hope for a reply from Bram. I'm used to projects that don't appreciate people shooting e-mail off to any particular individual when there is a designated list/forum. :-) So nice to have the keys behave, though. :-) (While we're on the subject, can someone remind me how to *make* a .patch? Is it just 'diff -u' or is there something special in getting the multiple-files-in-one-output-block right?) -- Matthew Now where did I put my hippo?
Re: BUG: indirect 'configure' invocation hides exit status
A.J.Mechelynck wrote: mwoehlke wrote: I found a really annoying problem trying to build VIM 7 on HP-UX. I have an automated script that builds VIM as part of a toolchain. It ran through, and to my surprise and annoyance, installed VIM in /usr/local instead of where I wanted it. Long story short, the script called 'configure', which failed because it isn't (for some reason I have not yet figured out) finding the ncurses I built (--with-tlib=ncurses). Now, 'root/configure' calls 'src/configure' which calls 'src/auto/configure'... but the exit status is not preserved AT EITHER STEP. As a result, my script thinks 'configure' succeeded and moves on to 'make', which RE-runs 'configure' with default parameters, succeeds, and ultimately allows the script to move on to 'make install'! THIS IS BAD! The indirect 'configure' scripts need to preserve the exit status. The fix, which is trivial, I leave as an exercise. Answer to the exercise: set the appropriate environment variables so that when make runs configure, it will use whatever configure options you want to apply. Then you can do without a separate configure step (or use make config if you absolutely want one). ...Or... fix the indirect-invocation 'configure' scripts to not mask the exit status? IMO these are broken as-is (and the fix is trivial; Bram was looking at it last I heard). -- Matthew Interix, Sphinterix. Cygwin apps don't crash. :-)
Re: BUG: indirect 'configure' invocation hides exit status
(re-send because I forgot to CC vim-dev; sorry)
Bram Moolenaar wrote:
Matthew Woehlke wrote:
[snip]
The indirect 'configure' scripts need to preserve the exit
status.
The fix, which is trivial, I leave as an exercise.
So, what is the fix? I'm lazy.
Goodness, I'll say. :)
vim/configure:
-cd src ./configure $@
+cd src exec ./configure $@
vim/src/configure:
CONFIG_STATUS=auto/config.status \
auto/configure $@ --srcdir=${srcdir:-.} \
--cache-file=auto/config.cache
+result=$?
# Stupid autoconf 2.5x causes this file to be left behind.
if test -f configure.lineno; then rm -f configure.lineno; fi
+exit $result
Anyway, when the curses library isn't found configure will continue.
This is because on a few platforms the functionality is included in the
standard libraries and Vim can be build anyway.
Not when using '--with-tlib=ncurses' it won't. However, I consider this
a GOOD thing; if I *tell* it to use ncurses, I expect it to either do
so, or fail. Particularly on HP-UX (at least, I think HP-UX is where I
had the problem), it otherwise wants to fall back on termlib which
results in reduced functionality. Of course, if I /don't/ explicitly use
'--with-tlib', then it's OK for it to fall back on termlib and continue
(and it does, as evidenced by the case where I did get termlib instead
of curses, which is why I started using --with-tlib=ncurses in the first
place).
--
Matthew
DOS Attack: See America Online -- my college room mate
BUG: indirect 'configure' invocation hides exit status
I found a really annoying problem trying to build VIM 7 on HP-UX. I have an automated script that builds VIM as part of a toolchain. It ran through, and to my surprise and annoyance, installed VIM in /usr/local instead of where I wanted it. Long story short, the script called 'configure', which failed because it isn't (for some reason I have not yet figured out) finding the ncurses I built (--with-tlib=ncurses). Now, 'root/configure' calls 'src/configure' which calls 'src/auto/configure'... but the exit status is not preserved AT EITHER STEP. As a result, my script thinks 'configure' succeeded and moves on to 'make', which RE-runs 'configure' with default parameters, succeeds, and ultimately allows the script to move on to 'make install'! THIS IS BAD! The indirect 'configure' scripts need to preserve the exit status. The fix, which is trivial, I leave as an exercise. Otherwise, having a VIM with working highlighting and WORKING KEYS on the almost-half-dozen platforms I work on is wonderful. :-) Even if I've only managed builds for four of them so far... -- Matthew Do not expose to extreme heat, cold, or open flame.
