Re: Vim 7.1 and aap?
Bram Moolenaar wrote: Richard van der Leeden wrote: Currently using AAP is still downloading and installing verison 7.0 (and all the patches). Will this be updated to load 7.1 instead? It's near the top of my todo list now. I have altered my local copy of main.aap to get 7.1 (and change the latest patch number to 000) which seems to work fine. Yeah, that should be all. Using CVS it should already work. -- hundred-and-one symptoms of being an internet addict: 121. You ask for e-mail adresses instead of telephone numbers. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org /// \\\help me help AIDS victims -- http://ICCF-Holland.org /// Thanks Bram. I can confirm aap (with or without CVS) is now installing version 7.1. -- View this message in context: http://www.nabble.com/Vim-7.1-and-aap--tf3734936.html#a10575650 Sent from the Vim - Dev mailing list archive at Nabble.com.
Re: [PATCH] gvim: Fix compilation against GNOME 2.18
On Thu, 10 May 2007 11:28:25 +0200 Bram Moolenaar [EMAIL PROTECTED] wrote: Daniel Drake wrote: gvim with FEAT_GUI_GNOME fails to compile against GNOME 2.18. See https://bugs.gentoo.org/show_bug.cgi?id=176566 for more info. This patch solves the problem. Thanks. Looks safe to include now. Unfortunately, it looks like this patch didn't get applied correctly (you're missing an underscore). The attached patch against the 7.1 source should fix this. -- Mike Kelly Index: src/gui_gtk.c === *** src/gui_gtk.c (revision 288) --- src/gui_gtk.c (working copy) *** *** 53,60 # ifdef bindtextdomain # undef bindtextdomain # endif ! # ifdef bindtextdomain_codeset ! # undef bindtextdomain_codeset # endif # if defined(FEAT_GETTEXT) !defined(ENABLE_NLS) # define ENABLE_NLS /* so the texts in the dialog boxes are translated */ --- 53,60 # ifdef bindtextdomain # undef bindtextdomain # endif ! # ifdef bind_textdomain_codeset ! # undef bind_textdomain_codeset # endif # if defined(FEAT_GETTEXT) !defined(ENABLE_NLS) # define ENABLE_NLS /* so the texts in the dialog boxes are translated */ Index: src/gui_gtk_x11.c === *** src/gui_gtk_x11.c (revision 288) --- src/gui_gtk_x11.c (working copy) *** *** 36,43 # ifdef bindtextdomain # undef bindtextdomain # endif ! # ifdef bindtextdomain_codeset ! # undef bindtextdomain_codeset # endif # if defined(FEAT_GETTEXT) !defined(ENABLE_NLS) # define ENABLE_NLS /* so the texts in the dialog boxes are translated */ --- 36,43 # ifdef bindtextdomain # undef bindtextdomain # endif ! # ifdef bind_textdomain_codeset ! # undef bind_textdomain_codeset # endif # if defined(FEAT_GETTEXT) !defined(ENABLE_NLS) # define ENABLE_NLS /* so the texts in the dialog boxes are translated */ signature.asc Description: PGP signature
Re: Project specific settings
On Mon, May 14, 2007 at 10:11:02AM +0200, Sebastian Menge wrote: Am Montag, den 14.05.2007, 10:05 +0200 schrieb Marius Roets: I always uses spaces to indent my code, but a current project requires me to use tabs. How could I make this setting only be in effect for this one project, assuming that the project will always be a in a specific directory. :help mksession :help tabstop Of, if in a specific directory means under a directory with some specific name but possibly in many places do something like au BufNewFile,BufReadPost */projectname/*.[ch] set noet ts=8 BTW tabs suck. Yeti -- http://gwyddion.net/
Re: Stable Vim version 7.1 has been released
Edward L. Fox wrote: On 5/14/07, David Neèas (Yeti) [EMAIL PROTECTED] wrote: On Sun, May 13, 2007 at 09:28:11PM +0100, [EMAIL PROTECTED] wrote: Umm, I suspect there's still an issue for us pesky OSX users with our case-insensitive filesystems: [long list of successful updates snipped] svn: Failed to add file 'src/auto/config.h': object of the same name already exists Gah. Scrub that. Manually removing the file in question and updating again has sorted it (that's the first time I've had Subversion complain over several updates). Sorry for the noise... Actually, this is a repository bug. src/auto/config.h is fully generated therefore it should not be versioned. Yes, it's a bug. I can fix the problem, but not yet. Because I shall also need to delete the corresponding files in the CVS repository to keep the two repositories' consistency. If Bram would grant me such permission to delete these unnecessary files in the CVS and SVN repository, I'll do it right away. I already have the CVS writing privilege, so the only thing I need is just a permission. :-) This is not a bug, an empty src/auto/config.h is included, because otherwise make depend doesn't work. The problem is that when running configure the file is overwritten by a non-empty one. When you update from CVS later it fails. But that is OK, just ignore the error. It would be nicer if we have some way to avoid the error message, but I don't know how. -- hundred-and-one symptoms of being an internet addict: 125. You begin to wonder how often it REALLY is necessary to get up and shower or bathe. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: Stable Vim version 7.1 has been released
On Mon, May 14, 2007 at 02:24:09PM +0200, Bram Moolenaar wrote: This is not a bug, an empty src/auto/config.h is included, because otherwise make depend doesn't work. I would rather say this means an additional problem in the Makefiles. If a rule requires src/auto/config.h, it should create it (directly or indirectly by dependences) when it does not exist. That's what make is for. If `make distclean' can remove src/auto/config.h and create it empty, why it cannot be created [empty] by the thing that actually needs it? This indeed works strangely; for instance `make -jN' with N 1 works with freshly unpacked sources, but it breaks completely after `make distclean' -- which one would expect to get the source tree to the same state. Yeti -- http://gwyddion.net/
Re: [PATCH] gvim: Fix compilation against GNOME 2.18
Mike Kelly wrote: Bram Moolenaar [EMAIL PROTECTED] wrote: Daniel Drake wrote: gvim with FEAT_GUI_GNOME fails to compile against GNOME 2.18. See https://bugs.gentoo.org/show_bug.cgi?id=176566 for more info. This patch solves the problem. Thanks. Looks safe to include now. Unfortunately, it looks like this patch didn't get applied correctly (you're missing an underscore). The attached patch against the 7.1 source should fix this. Darn. Well, we had to have a first patch for 7.1 anyway. Thanks Mike. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
I can't change the font in vim7.1!
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 (-): +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 system vimrc file: $VIM/vimrc user vimrc file: $HOME/.vimrc user exrc file: $HOME/.exrc system gvimrc file: $VIM/gvimrc user gvimrc file: $HOME/.gvimrc system menu file: $VIMRUNTIME/menu.vim fall-back for $VIM: /home/x0075669/share/vim Compilation: 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/pango-1.0 -I/usr/X11R6/include -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -O2 -I/usr/X11R6/include Linking: gcc -L/usr/X11R6/lib -L/usr/local/lib -o vim -Wl,--export-dynamic -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1. 0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lXt -lncurs es -lacl -lgpm
breakindent, take 2
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. Best regards, Václav Šmilauer
Re: breakindent, take 2
On Mon, May 14, 2007 at 07:30:23PM +0200, Václav Šmilauer wrote: The patch is against current svn (vim7, rev. 288). Any comments are welcome. I know this might not be desired comment, since I didn't even look at the patch but only at the screenshots. I just wanted to say that this feature would really be awesome, as I am doing a lot of LaTeX coding myself, and the default wrapping really doesn't look well. Martin PS: it would be nice if we could have the vim latex-suite autoindent by default in vim without the need to install the latex-suite (which is just overkill in my opinion). http://vim-latex.sourceforge.net
RE: I can't change the font in vim7.1!
Okay. I've found a clue to my problem. I'm on a kde system, and I'm obtaining a list of valid fonts with the xlsfonts command. I don't know much about how the kde gui works, bit it appears that the xlsfonts command and kde are incompatible. Now to figure out how to get a list of kde fonts. Thanks, David -Original Message- From: Larson, David Sent: Monday, May 14, 2007 10:07 AM To: vim-dev@vim.org Subject: I can't change the font in vim7.1! 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 (-): +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 system vimrc file: $VIM/vimrc user vimrc file: $HOME/.vimrc user exrc file: $HOME/.exrc system gvimrc file: $VIM/gvimrc user gvimrc file: $HOME/.gvimrc system menu file: $VIMRUNTIME/menu.vim fall-back for $VIM: /home/x0075669/share/vim Compilation: 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/pango-1.0 -I/usr/X11R6/include -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -O2 -I/usr/X11R6/include Linking: gcc -L/usr/X11R6/lib -L/usr/local/lib -o vim -Wl,--export-dynamic -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1. 0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lXt -lncurs es -lacl -lgpm
Re: Stable Vim version 7.1 has been released
(dropping [EMAIL PROTECTED] from cc) On Mon, May 14, 2007 at 07:36:30PM +0200, Bram Moolenaar wrote: This indeed works strangely; for instance `make -jN' with N 1 works with freshly unpacked sources, but it breaks completely after `make distclean' -- which one would expect to get the source tree to the same state. Well, figure out why it breaks The above report is incorrect, it just breaks always, I'm sorry. I probably run configure so automatically that I accidentally made it work. It breaks because make starts making `scratch', `config' and `myself' simultaneously. And that appears to be due to the first targets to make vim are: scratch config myself As these targets overwrite the same files with different content, it breaks one way or another. Explicite configure bootstraps the build system and thus makes -jN safe for normal compilation. and fix it... Unfortunately my view of how a build system should work is incompatible. I can tell when something breaks and hopefully I can figure out how it happens, but I have no idea what fixed means here. Yeti -- http://gwyddion.net/
Re: Stable Vim version 7.1 has been released
David Necas wrote: (dropping [EMAIL PROTECTED] from cc) On Mon, May 14, 2007 at 07:36:30PM +0200, Bram Moolenaar wrote: This indeed works strangely; for instance `make -jN' with N 1 works with freshly unpacked sources, but it breaks completely after `make distclean' -- which one would expect to get the source tree to the same state. Well, figure out why it breaks The above report is incorrect, it just breaks always, I'm sorry. I probably run configure so automatically that I accidentally made it work. It breaks because make starts making `scratch', `config' and `myself' simultaneously. And that appears to be due to the first targets to make vim are: scratch config myself As these targets overwrite the same files with different content, it breaks one way or another. Hmm, in my POV a rule like: target: one two three means that one, two and three are build in sequence, not at the same time. I suppose adding the -jN argument changes the semantics of the Makefile, and that causes it to break. The Vim makefile was written for a common version of all make programs. So that it builds nearly everywhere. I'm not sure supporting -jN is possible without breaking it for some system. Or including false dependencies. I don't think a parallel build helps much anyway, Vim builds rather fast (compared to say, OpenOffice, which takes half a day). Explicite configure bootstraps the build system and thus makes -jN safe for normal compilation. and fix it... Unfortunately my view of how a build system should work is incompatible. I can tell when something breaks and hopefully I can figure out how it happens, but I have no idea what fixed means here. I know, in my view make should do everything. Somehow people have accepted that some part of the building should be done separately, with the excuse that it's called configuration. Big mistake in my opinion. In quite a few programs you need to know the magic arguments to configure to be able to build. Ending up writing a shell script for it. Now why didn't they put that in the Makefile? Oh well... -- Don't drink and drive. You might hit a bump and spill your beer. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: Stable Vim version 7.1 has been released
On Mon, May 14, 2007 at 11:05:24PM +0200, Bram Moolenaar wrote: Hmm, in my POV a rule like: target: one two three means that one, two and three are build in sequence, not at the same time. This means `one', `two' and `three' have to be built for `target'. More precisely any commands necessary to build any of `target's prerequisites will be fully executed before any commands necessary to build the target. The order is chosen with regard to the full dependency tree: all: a b c a: c @echo a b: @echo b c: b @echo c Single-job make has no reason to reorder the prerequisites once they are fully resolved, but AFAIK it is free to. GNU make even has a special construct to specify the order of build without implying dependency. BSD make OTOH has a `be backward compatible' option to enforce building in dependency order (it is on by default in single-job invocations). Both will give you b c a from Makefile all: a b c a: @sleep 3 @echo a b: @sleep 1 @echo b c: @sleep 2 @echo c when run with enough jobs. I suppose adding the -jN argument changes the semantics of the Makefile, and that causes it to break. If there ever was such semantics. I've yet to see a make specification that precisely defines the build order of independent targets. The Vim makefile was written for a common version of all make programs. So that it builds nearly everywhere. I'm not sure supporting -jN is possible without breaking it for some system. Or including false dependencies. Maybe, although non-working -jN often indicates missing real dependencies. Anyway, if one neither knows he cannot use -jN nor that he can run make without running configure first -- which I suppose characterizes most people -- it works. And with independent dependencies that rewrite the same file with different content it probably cannot be fixed. I know, in my view make should do everything. Somehow people have accepted that some part of the building should be done separately, with the excuse that it's called configuration. Big mistake in my opinion. There's nothing wrong on acknowledging there are inherent chicken-egg problems and breaking the cycle explicitly. Yeti -- http://gwyddion.net/
[Patch] proper detection of ProC files.
Fixes an apparent typo in filetype.vim. Per https://bugs.launchpad.net/ubuntu/+source/vim/+bug/86916. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ Index: runtime/filetype.vim === --- runtime/filetype.vim (revision 292) +++ runtime/filetype.vim (working copy) @@ -1286,7 +1286,7 @@ au BufNewFile,BufRead *.it,*.ih setf ppwiz Oracle Pro*C/C++ -au BufNewFile,BufRead .pc setf proc +au BufNewFile,BufRead *.pc setf proc Privoxy actions file au BufNewFile,BufRead *.action setf privoxy signature.asc Description: OpenPGP digital signature
Re: I can't change the font in vim7.1!
Larson, David wrote: I just upgraded to 7.1, and now when I open up a gvim session, I get this huge monospaced font that I can't change. If I type: :set guifont? it returns 7x14 which is what I set it to, but it isn't what is displayed. If I change the setting to *any* other font that is valid for my system, the display doesn't change, although the guifont setting shows that it is set to the new value. Help! David :version shows: VIM - Vi IMproved 7.1 (2007 May 12, compiled May 14 2007 09:50:48) Compiled by [EMAIL PROTECTED] Big version with GTK2 GUI. Features included (+) or not (-): With a GTK2 GUI, you can set the font interactively, using :set guifont=* This will bring up a font chooser menu. Thereafter, :set guifont=Tab will show on the command-line the exact command (with escaping backslashes if and where needed) that you need to write into your vimrc to set that font. There are (including the obsolete kvim) five different families of Vim GUIs, each of which requires a different 'guifont' format, not accepted by other GUIs. The following is what I use in my portable vimrc to sniff the GUI version: if has(gui_running) console Vim cannot set the font if has(gui_gtk2) GTK+2, not GTK+1 set gfn=Bitstream\ Vera\ Sans\ Mono\ 9 elseif has(gui_photon) Photon GUI set gfn=Bitstream\ Vera\ Sans\ Mono:s9 elseif has(gui_kde) the obsolete kvim set gfn=Bitstream\ Vera\ Sans\ Mono/9/-1/5/50/0/0/0/1/0 elseif has(x11) other X11 GUIs including GTK+1 set gfn=-*-lucidatypewriter-medium-r-normal-*-*-100-*-*-m-*-* else non-X11 GUIs including Windows set gfn=Lucida_Console:h9:cDEFAULT endif endif Best regards, Tony. -- ... My pants just went on a wild rampage through a Long Island Bowling Alley!!
Re: Stable Vim version 7.1 has been released
[Bram Moolenar] Hmm, in my POV a rule like: target: one two three means that one, two and three are build in sequence, not at the same time. I suppose adding the -jN argument changes the semantics of the Makefile, and that causes it to break. In fact, so far that I know (and everything I know is debatable! :-), the in sequence is not part of the semantic of Makefiles, and should never be relied upon. Of course, if you experiment with various make implementations, you may observe that dependencies are usually build in sequence, but this should be seen as an accident, and not as a proof. Adding -jN does not change the semantics of Makefiles, but it may uncover bugs in Makefiles. I (and many other maintainers as well) used to export MAKEFLAGS=-jN (with N being a small number) just to make sure that my (our) Makefiles were not abusing of make semantics. I don't think a parallel build helps much anyway, Vim builds rather fast (compared to say, OpenOffice, which takes half a day). Using -jN does not usually spare much build time, and this was not the reason why we used it. The introduction of A[CM]_MAINTAINER_MODE (in Autoconf then Automake), to which I much objected, was symptomatic that many maintainers definitely lost hope (or at least wanted to stop aiming) for perfect Makefiles. Moreover, make is lacking in some areas and might not be worth salvaging at any price (the mere existence of aap tells me that Bram agrees at least a bit!). As a overall consequence, my starve for impeccable Makefiles faded, and I do not routinely use -jN anymore. I know, in my view make should do everything. Somehow people have accepted that some part of the building should be done separately, with the excuse that it's called configuration. Big mistake in my opinion. I've seen packages configuring on the fly while making. While nice, this also shows a few drawbacks. Nothing is perfectly black or white. Prior configuration should be seen as an optimisation issue. Configuration takes non-negligible time, and we often risk make-ing many times, so it is worth caching configurations results somehow. Also, separate configuration gives a check point where wrong configuration decisions may be corrected and retried as necessary. It is a sad thing, at least for me, that over time, configuration became so heavy, articulated over many intermediate files, and fine-grained into so many macros. It much hurts my starve for simplicity. On the other hand, the multiplication of configuration tools and independent paradigms would not be a virtue either, because of our limited ability to learn, for those of us working on many packages at once (even if admittedly, this is a disappearing trend). -- François Pinard http://pinard.progiciels-bpi.ca
