Re: Small GvimExt patch
Edward L. Fox wrote: > Hi Tony, > > On 8/16/07, Tony Mechelynck <[EMAIL PROTECTED]> wrote: >> Chris Sutcliffe wrote: >>> Replied direct to Bram instead of the list... >>> >>> On 8/15/07, Chris Sutcliffe wrote: > Adding (char *) casts for things that are already character strings? > Isn't this a problem in gcc? GCC complains that const char*'s is being passed as a char*'s (because it's a contant string being passed in the quotes), so I re-cast it as a (char*) to get rid of the warnings. Basically because, for example, searchpath(char *) is defined to take a char* argument and "gvim.bat" is considered a constant char*, there is a mismatch in argument types (which GCC 4 is a little more adamant about, since I believe one of GCC 4's goals is to be more standards compliant). Cheers! Chris -- Chris Sutcliffe http://ir0nh34d.googlepages.com http://ir0nh34d.blogspot.com http://emergedesktop.org >>> >> shouldn't the function take const char * as arguments instead? Meaning it >> doesn't modify that argument even though it's a pointer. > > Yes, I think so. Const-correctness is always a big problem. The old > version of C without ++ doesn't support "const". So many C progammers > are not familiar with the const keyword. > > Any way, it seems that you also misunderstood the const keyword. > "const char *" means "a pointer points to const char", so you are not > able to modify the pointed content, but the pointer itself is still > modifiable. For example, you could say: > > const char *p; > ... > ++p; > yes, yes; I mean, with a const argument you can't pass back modified pointed-to data to the calling routine, while with ordinary pointers (without const) you can. I guess I should have said the function won't modify the argument (the string) even though it is passed by address (not by value as most numeric single-item values can be passed). Best regards, Tony. -- Hartley's Second Law: Never sleep with anyone crazier than yourself. --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
undojoin after an undo
Hi Bram, If I undo a change, and then do undojoin | delete I get an error. Perhaps you could add a "undojoin!" command that silently ignores the "undojoin" if the previous operation was an undo. I currently (in scripts) have to do something like try undojoin | catch endtry Also after reading the documentation, I realize I'm unclear on the scope of :undojoin. Does it mean all changes a script makes until the user enters insert mode will be part of the previous undo block? Or just the change immediately following the undojoin command? Could you clarify this point a little in the docs? Thanks, GI -- 'Code Orange' -- Eat dessert first. --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: test64?
On 8/16/07, Xiaozhou Liu <[EMAIL PROTECTED]> wrote: > > Hi Edward, > > Patch 7.1.071 adds test64 into src/testdir/. But it is not there > as I browse the subversion repository below. Is there any problem > or am I wrong? I see... Thanks very much for your report. As I'm not able to access the Internet now, I'll fixed it 3 hours later. > > https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1/src/testdir/ > > Thanks, > Xiaozhou > > > > --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: test64?
On 8/16/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > > > Xiaozhou Liu wrote: > > > Patch 7.1.071 adds test64 into src/testdir/. But it is not there > > as I browse the subversion repository below. Is there any problem > > or am I wrong? > > > > https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1/src/testdir/ > > Subversion always lags behind, between a few hours to a few days. Use > CVS or patches if you need a bleeding edge version. Not always behind. As I remember, once, yes, only once, but it really did so, the SVN repository ran before the CVS repository. I admit that such situation rarely happens, but it really exists. > > -- > "Hit any key to continue" does _not_ mean you can hit the on/off button! > > /// 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/// > > > > --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Small GvimExt patch
Hi Tony, On 8/16/07, Tony Mechelynck <[EMAIL PROTECTED]> wrote: > > Chris Sutcliffe wrote: > > Replied direct to Bram instead of the list... > > > > On 8/15/07, Chris Sutcliffe wrote: > >>> Adding (char *) casts for things that are already character strings? > >>> Isn't this a problem in gcc? > >> GCC complains that const char*'s is being passed as a char*'s (because > >> it's a contant string being passed in the quotes), so I re-cast it as > >> a (char*) to get rid of the warnings. > >> > >> Basically because, for example, searchpath(char *) is defined to take > >> a char* argument and "gvim.bat" is considered a constant char*, there > >> is a mismatch in argument types (which GCC 4 is a little more adamant > >> about, since I believe one of GCC 4's goals is to be more standards > >> compliant). > >> > >> Cheers! > >> > >> Chris > >> > >> -- > >> Chris Sutcliffe > >> http://ir0nh34d.googlepages.com > >> http://ir0nh34d.blogspot.com > >> http://emergedesktop.org > >> > > > > > > shouldn't the function take const char * as arguments instead? Meaning it > doesn't modify that argument even though it's a pointer. Yes, I think so. Const-correctness is always a big problem. The old version of C without ++ doesn't support "const". So many C progammers are not familiar with the const keyword. Any way, it seems that you also misunderstood the const keyword. "const char *" means "a pointer points to const char", so you are not able to modify the pointed content, but the pointer itself is still modifiable. For example, you could say: const char *p; ... ++p; > > > Best regards, > Tony. > -- > A special cleaning ordinance bans housewives from hiding dirt and dust under a > rug in a dwelling. > [real standing law in Pennsylvania, United States of America] > > > > --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Small GvimExt patch
Chris Sutcliffe wrote: > Replied direct to Bram instead of the list... > > On 8/15/07, Chris Sutcliffe wrote: >>> Adding (char *) casts for things that are already character strings? >>> Isn't this a problem in gcc? >> GCC complains that const char*'s is being passed as a char*'s (because >> it's a contant string being passed in the quotes), so I re-cast it as >> a (char*) to get rid of the warnings. >> >> Basically because, for example, searchpath(char *) is defined to take >> a char* argument and "gvim.bat" is considered a constant char*, there >> is a mismatch in argument types (which GCC 4 is a little more adamant >> about, since I believe one of GCC 4's goals is to be more standards >> compliant). >> >> Cheers! >> >> Chris >> >> -- >> Chris Sutcliffe >> http://ir0nh34d.googlepages.com >> http://ir0nh34d.blogspot.com >> http://emergedesktop.org >> > > shouldn't the function take const char * as arguments instead? Meaning it doesn't modify that argument even though it's a pointer. Best regards, Tony. -- A special cleaning ordinance bans housewives from hiding dirt and dust under a rug in a dwelling. [real standing law in Pennsylvania, United States of America] --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Small GvimExt patch
Replied direct to Bram instead of the list... On 8/15/07, Chris Sutcliffe wrote: > > Adding (char *) casts for things that are already character strings? > > Isn't this a problem in gcc? > > GCC complains that const char*'s is being passed as a char*'s (because > it's a contant string being passed in the quotes), so I re-cast it as > a (char*) to get rid of the warnings. > > Basically because, for example, searchpath(char *) is defined to take > a char* argument and "gvim.bat" is considered a constant char*, there > is a mismatch in argument types (which GCC 4 is a little more adamant > about, since I believe one of GCC 4's goals is to be more standards > compliant). > > Cheers! > > Chris > > -- > Chris Sutcliffe > http://ir0nh34d.googlepages.com > http://ir0nh34d.blogspot.com > http://emergedesktop.org > -- Chris Sutcliffe http://ir0nh34d.googlepages.com http://ir0nh34d.blogspot.com http://emergedesktop.org --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Bug: g8 doesn't work properly in 7.1.079
Bram Moolenaar wrote: > Tony Mechelynck wrote: > >> g8 doesn't work properly in 7.1.079 >> >> Reproducible: Always >> >> Steps to reproduce: >> 1. Insert the Pilcrow mark into a buffer with 'encoding' and 'fileencoding' >> both set to utf-8 (e.g. using ^KPI ). >> 2. Go back to Normal mode >> 3. Place the cursor on the character inserted at step 1. >> 4. Hit g8 >> >> Actual result: b6 >> >> Expected result: c2 b6 > > I can't reproduce it. For me the result is "c2 b6" as expected. > The character is 0xb6, right? > > right, but see my "oops" post. Best regards, Tony. -- Remember when you were a kid and the boys didn't like the girls? Only sissies liked girls? What I'm trying to tell you is that nothing's changed. You think boys grow out of not liking girls, but we don't grow out of it. We just grow horny. That's the problem. We mix up liking pussy for liking girls. Believe me, one couldn't have less to do with the other. -- Jules Feiffer --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Small GvimExt patch
Chris Sutcliffe wrote:
> Below is a small patch for GvimExt to correct some warnings when
> compiled with GCC 4.
>
> Index: gvimext.cpp
> ===
> RCS file: /cvsroot/vim/vim7/src/GvimExt/gvimext.cpp,v
> retrieving revision 1.6
> diff -u -r1.6 gvimext.cpp
> --- gvimext.cpp 10 May 2007 19:09:38 - 1.6
> +++ gvimext.cpp 15 Aug 2007 01:20:05 -
> @@ -69,14 +69,14 @@
>
> // Registry didn't work, use the search path.
> if (name[0] == 0)
> - strcpy(name, searchpath("gvim.exe"));
> + strcpy(name, searchpath((char*)"gvim.exe"));
>
> if (!runtime)
> {
> // Only when looking for the executable, not the runtime dir, we can
> // search for the batch file or a name without a path.
> if (name[0] == 0)
> - strcpy(name, searchpath("gvim.bat"));
> + strcpy(name, searchpath((char*)"gvim.bat"));
> if (name[0] == 0)
> strcpy(name, "gvim"); // finds gvim.bat or gvim.exe
>
> @@ -152,9 +152,9 @@
> FARPROC *ptr;
> } libintl_entry[] =
> {
> - {"gettext", (FARPROC*)&dyn_libintl_gettext},
> - {"textdomain", (FARPROC*)&dyn_libintl_textdomain},
> - {"bindtextdomain", (FARPROC*)&dyn_libintl_bindtextdomain},
> + {(char*)"gettext", (FARPROC*)&dyn_libintl_gettext},
> + {(char*)"textdomain", (FARPROC*)&dyn_libintl_textdomain},
> + {(char*)"bindtextdomain", (FARPROC*)&dyn_libintl_bindtextdomain},
> {NULL, NULL}
> };
>
> @@ -835,7 +835,7 @@
> (LPTSTR)location) > (HINSTANCE)32)
> return location;
> }
> -return "";
> +return (char*)"";
> }
> # endif
> #endif
Adding (char *) casts for things that are already character strings?
Isn't this a problem in gcc?
--
hundred-and-one symptoms of being an internet addict:
169. You hire a housekeeper for your home page.
/// 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///
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Bug: g8 doesn't work properly in 7.1.079
Tony Mechelynck wrote: > g8 doesn't work properly in 7.1.079 > > Reproducible: Always > > Steps to reproduce: > 1. Insert the Pilcrow mark into a buffer with 'encoding' and 'fileencoding' > both set to utf-8 (e.g. using ^KPI ). > 2. Go back to Normal mode > 3. Place the cursor on the character inserted at step 1. > 4. Hit g8 > > Actual result: b6 > > Expected result: c2 b6 I can't reproduce it. For me the result is "c2 b6" as expected. The character is 0xb6, right? -- In Joseph Heller's novel "Catch-22", the main character tries to get out of a war by proving he is crazy. But the mere fact he wants to get out of the war only shows he isn't crazy -- creating the original "Catch-22". /// 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/// --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
oops
Please ignore my two latest posts to vim-dev. For some reason 'encoding' had been set to latin1 without my say-so. This may still be a bug in :mksession, albeit a different one. Best regards, Tony. -- Build a better mousetrap, the saying goes -- and with the brassiere, Yankee Ingenuity did exactly that. But their true stroke of genius was the new bait. The old fashioned mousetrap was loaded with cheese; nobody cares much about cheese, except mice. But when American Know-How reloaded the brassiere with tits, every heterosexual male in the country was hopelessly trapped. -- Alan Sherman, "The Rape of the A*P*E*" --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Bug: g8 doesn't work properly in 7.1.079
g8 doesn't work properly in 7.1.079 Reproducible: Always Steps to reproduce: 1. Insert the Pilcrow mark into a buffer with 'encoding' and 'fileencoding' both set to utf-8 (e.g. using ^KPI ). 2. Go back to Normal mode 3. Place the cursor on the character inserted at step 1. 4. Hit g8 Actual result: b6 Expected result: c2 b6 Additional info: Output of :version VIM - Vi IMproved 7.1 (2007 May 12, compiled Aug 15 2007 21:23:57) Included patches: 1-79 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 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: "/usr/local/share/vim" 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: gcc -L/opt/gnome/lib-rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.8.8/i586-linux-thread-multi/CORE -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.8.8/i586-linux-thread-multi/CORE -L/usr/local/lib -o vim -L/opt/gnome/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lfreetype -lz -lfontconfig -lexpat -lglitz -lpng12 -lXrender -lXau -L/opt/gnome/lib -lgnomeui-2 -lbonoboui-2 -lgnome-keyring -lxml2 -lgnomecanvas-2 -lgnome-2 -lpopt -lart_lgpl_2 -lpangoft2-1.0 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lfreetype -lz -lfontconfig -lexpat -lglitz -lpng12 -lXrender -lXau -lbonobo-2 -lgnomevfs-2 -lbonobo-activation -lgconf-2 -lgobject-2.0 -lORBit-2 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 -lXt -lncurses -lacl -lgpm -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.8.8/i586-linux-thread-multi/CORE /usr/lib/perl5/5.8.8/i586-linux-thread-multi/auto/DynaLoader/DynaLoader.a -L/usr/lib/perl5/5.8.8/i586-linux-thread-multi/CORE -lperl -lutil -lc -L/usr/lib/python2.5/config -lpython2.5 -lutil -Xlinker -export-dynamic -L/usr/lib -ltcl8.4 -lieee -Wl,-R -Wl,/usr/lib -L/usr/lib -lruby -lm Best regards, Tony. --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Bug (regression in 7.1.077 ?) :mks with Unicode chars in 'lcs'
:mksession (in 7.1.077) or gvim -S (in 7.1.079) doesn't work properly in UTF-8 locale with Unicode codepoints (> U+007F) in 'listchars' gvim 7.1.077 in UTF-8 locale [...] :set lcs=tab:\|_,eol:¶,nbsp:~ [...] :mks! :qa (patch to 7.1.079, make, make install) gvim -S Error detected while processing /root/Session.vim: line 79: E474: Invalid argument: listchars=tab:|_,eol:¶,nbsp:~ The offending Session.vim is attached Best regards, Tony. --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- Session.vim Description: Binary data
Re: there's undojoin -- how about dotjoin?
Bram Moolenaar wrote: >Charles Campbell wrote: > > > >>I'd like to do >> >> imap ... = ...=:something >> >>however, "." no longer repeats the small change. For example: >> >> imap = =:echo "hello!" >> >>work with the following file contents: >> >>abc; >>def; >> >>Place cursor on the semicolon with "abc;" -- insert >> =2 >> >>Now put the cursor on the semicolon with "def;" and press "." . >>All you get is >> >>def 2; >> >>Now, if there was a dotjoin: >> >>imap = =:dotjoinecho "hello!" >> >>just might work! >> >> > >How about using CTRL-G CTRL-O for going to Normal mode without breaking >the current Insert in two? It would only work when the cursor didn't >move and the text isn't changed. > > > Antony Scriven suggested using ctrl-r= and that seemed to do the trick for me. My application is my AutoAlign plugin; the first insert of =something doesn't change the text any (AutoAlign does save the position, however, to align subsequent lines against). However, when I am simply inserting things (often =0 or =NULL to declarations), the call to AutoAlign, even though it wasn't changing the text, meant that the "." change wasn't working. (I now have AutoAlign returning an empty string). So, unless I find a problem with ctrl-r= the ctrl-g ctrl-o combo will be academic for me. Still, it does seem like there should be something to do that, so I still think its a Good Idea! Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
RE: there's undojoin -- how about dotjoin?
Tony asked: >Bram Moolenaar wrote: >> >> How about using CTRL-G CTRL-O for going to Normal mode without >> breaking the current Insert in two? It would only work when >> the cursor didn't move and the text isn't changed. >> > > I don't find Ctrl-G Ctrl-O under ":help ins-special-special" (or > anywhere in Insert mode). Maybe you mean Ctrl-\ Ctrl-O ? Bram is proposing a new insert mode command Ctrl-G Ctrl-O that is like the current insert mode command Ctrl-O except that the proposed command will preserve the . command in those situations wherein the what's done after Ctrol-O does not move the cursor and does not change any text. --Suresh --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: there's undojoin -- how about dotjoin?
Bram Moolenaar wrote: > > Charles Campbell wrote: > >> I'd like to do >> >>imap ... = ...=:something >> >> however, "." no longer repeats the small change. For example: >> >> imap = =:echo "hello!" >> >> work with the following file contents: >> >> abc; >> def; >> >> Place cursor on the semicolon with "abc;" -- insert >> =2 >> >> Now put the cursor on the semicolon with "def;" and press "." . >> All you get is >> >> def 2; >> >> Now, if there was a dotjoin: >> >> imap = =:dotjoinecho "hello!" >> >> just might work! > > How about using CTRL-G CTRL-O for going to Normal mode without breaking > the current Insert in two? It would only work when the cursor didn't > move and the text isn't changed. > I don't find Ctrl-G Ctrl-O under ":help ins-special-special" (or anywhere in Insert mode). Maybe you mean Ctrl-\ Ctrl-O ? Best regards, Tony. -- "I am ready to meet my Maker. Whether my Maker is prepared for the great ordeal of meeting me is another matter." -- Winston Churchill --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: there's undojoin -- how about dotjoin?
Charles Campbell wrote: > I'd like to do > >imap ... = ...=:something > > however, "." no longer repeats the small change. For example: > > imap = =:echo "hello!" > > work with the following file contents: > > abc; > def; > > Place cursor on the semicolon with "abc;" -- insert > =2 > > Now put the cursor on the semicolon with "def;" and press "." . > All you get is > > def 2; > > Now, if there was a dotjoin: > > imap = =:dotjoinecho "hello!" > > just might work! How about using CTRL-G CTRL-O for going to Normal mode without breaking the current Insert in two? It would only work when the cursor didn't move and the text isn't changed. -- If you feel lonely, try schizophrenia. /// 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/// --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: undo after :retab
Yakov Lerner wrote: > Undo after retab modifies 'tabstop' in a way that doesn't look consistent or > correct. > Test case: > - > vim -u NONE -U NONE > iabc > :set ts=4 > :retab 8 > u > -- > After the last u, tabstop changes to 8. But we expect the screen > to return to the state before :retab where tabstop was 4, not 8. The ":retab 8" changes the text and the 'tabstop' value. Undo only undoes the change to the text. Undo never changes option values. -- hundred-and-one symptoms of being an internet addict: 168. You have your own domain name. /// 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/// --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: test64?
Xiaozhou Liu wrote: > Patch 7.1.071 adds test64 into src/testdir/. But it is not there > as I browse the subversion repository below. Is there any problem > or am I wrong? > > https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1/src/testdir/ Subversion always lags behind, between a few hours to a few days. Use CVS or patches if you need a bleeding edge version. -- "Hit any key to continue" does _not_ mean you can hit the on/off button! /// 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/// --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
patch 7.1.079
Patch 7.1.079
Problem:When the locale is "C" and 'encoding' is "latin1" then the "@"
character in 'isfname', 'isprint', etc. doesn't pick up accented
characters.
Solution: Instead of isalpha() use MB_ISLOWER() and MB_ISUPPER().
Files: src/charset.c, src/macros.h
*** ../vim-7.1.078/src/charset.cMon Aug 6 22:27:12 2007
--- src/charset.c Tue Aug 14 13:43:30 2007
***
*** 207,213
}
while (c <= c2)
{
! if (!do_isalpha || isalpha(c)
#ifdef FEAT_FKMAP
|| (p_altkeymap && (F_isalpha(c) || F_isdigit(c)))
#endif
--- 207,216
}
while (c <= c2)
{
! /* Use the MB_ functions here, because isalpha() doesn't
!* work properly when 'encoding' is "latin1" and the locale is
!* "C". */
! if (!do_isalpha || MB_ISLOWER(c) || MB_ISUPPER(c)
#ifdef FEAT_FKMAP
|| (p_altkeymap && (F_isalpha(c) || F_isdigit(c)))
#endif
*** ../vim-7.1.078/src/macros.h Thu May 10 19:21:00 2007
--- src/macros.hSat Aug 4 13:44:18 2007
***
*** 54,63
/*
* toupper() and tolower() that use the current locale.
! * On some systems toupper()/tolower() only work on lower/uppercase characters
* Careful: Only call TOUPPER_LOC() and TOLOWER_LOC() with a character in the
* range 0 - 255. toupper()/tolower() on some systems can't handle others.
! * Note: for UTF-8 use utf_toupper() and utf_tolower().
*/
#ifdef MSWIN
# define TOUPPER_LOC(c) toupper_tab[(c) & 255]
--- 54,65
/*
* toupper() and tolower() that use the current locale.
! * On some systems toupper()/tolower() only work on lower/uppercase
! * characters, first use islower() or isupper() then.
* Careful: Only call TOUPPER_LOC() and TOLOWER_LOC() with a character in the
* range 0 - 255. toupper()/tolower() on some systems can't handle others.
! * Note: It is often better to use MB_TOLOWER() and MB_TOUPPER(), because many
! * toupper() and tolower() implementations only work for ASCII.
*/
#ifdef MSWIN
# define TOUPPER_LOC(c) toupper_tab[(c) & 255]
*** ../vim-7.1.078/src/version.cWed Aug 15 20:07:53 2007
--- src/version.c Wed Aug 15 20:39:18 2007
***
*** 668,669
--- 668,671
{ /* Add new patch number below this line */
+ /**/
+ 79,
/**/
--
You're as much use as a condom machine at the Vatican.
-- Rimmer to Holly in Red Dwarf 'Queeg'
/// 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///
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Small GvimExt patch
Hey,
Below is a small patch for GvimExt to correct some warnings when
compiled with GCC 4.
Index: gvimext.cpp
===
RCS file: /cvsroot/vim/vim7/src/GvimExt/gvimext.cpp,v
retrieving revision 1.6
diff -u -r1.6 gvimext.cpp
--- gvimext.cpp 10 May 2007 19:09:38 - 1.6
+++ gvimext.cpp 15 Aug 2007 01:20:05 -
@@ -69,14 +69,14 @@
// Registry didn't work, use the search path.
if (name[0] == 0)
- strcpy(name, searchpath("gvim.exe"));
+ strcpy(name, searchpath((char*)"gvim.exe"));
if (!runtime)
{
// Only when looking for the executable, not the runtime dir, we can
// search for the batch file or a name without a path.
if (name[0] == 0)
- strcpy(name, searchpath("gvim.bat"));
+ strcpy(name, searchpath((char*)"gvim.bat"));
if (name[0] == 0)
strcpy(name, "gvim"); // finds gvim.bat or gvim.exe
@@ -152,9 +152,9 @@
FARPROC *ptr;
} libintl_entry[] =
{
- {"gettext", (FARPROC*)&dyn_libintl_gettext},
- {"textdomain", (FARPROC*)&dyn_libintl_textdomain},
- {"bindtextdomain", (FARPROC*)&dyn_libintl_bindtextdomain},
+ {(char*)"gettext", (FARPROC*)&dyn_libintl_gettext},
+ {(char*)"textdomain", (FARPROC*)&dyn_libintl_textdomain},
+ {(char*)"bindtextdomain", (FARPROC*)&dyn_libintl_bindtextdomain},
{NULL, NULL}
};
@@ -835,7 +835,7 @@
(LPTSTR)location) > (HINSTANCE)32)
return location;
}
-return "";
+return (char*)"";
}
# endif
#endif
Cheers!
Chris
--
Chris Sutcliffe
http://ir0nh34d.googlepages.com
http://ir0nh34d.blogspot.com
http://emergedesktop.org
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: there's undojoin -- how about dotjoin?
Antony Scriven wrote: > >Maybe. Could you use something like this as a workaround? > >fun! Echo() > echo 'hello!' > sleep 1 |" just to make the effect visible > return '' >endfun >imap = ==Echo() > > Hmm -- I definitely have a blind spot with = stuff. Thanks, Antony -- I think it just might! Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: there's undojoin -- how about dotjoin?
On 15/08/07, Charles E Campbell Jr <[EMAIL PROTECTED]> wrote: > Hello! > > I'd like to do > >imap ... = ...=:something > > however, "." no longer repeats the small change. For example: > > imap = =:echo "hello!" > > work with the following file contents: > > abc; > def; > > Place cursor on the semicolon with "abc;" -- insert > =2 > > Now put the cursor on the semicolon with "def;" and press "." . > All you get is > > def 2; > > Now, if there was a dotjoin: > > imap = =:dotjoinecho "hello!" > > just might work! Maybe. Could you use something like this as a workaround? fun! Echo() echo 'hello!' sleep 1 |" just to make the effect visible return '' endfun imap = ==Echo() --Antony --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: dynamic programming for gq formatting
On 2007-08-15, Andrew Myers <[EMAIL PROTECTED]> wrote: > On Aug 15, 2007, at 3:21 AM, Matthew Winn wrote: > > > > I get the impression that the OP doesn't want right-aligned text, but > > wants a better distribution of ragged-right lines. For example, > > consider the first two lines of this paragraph. The naïve breaking > > algorithm used by my mail client has left a deep indentation at the > > end of the second line. A better algorithm would move the "but" from > > the end of the first line to the start of the second, making the ends > > of the lines appear more regular. > > Exactly. For a small example, Oh! I misunderstood. Thanks for the explanation. Yes, that would be a nice alternative to the current algorithm. Regards, Gary --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
patch 7.1.078
Patch 7.1.078
Problem:Dropping a file name on gvim that contains a CSI byte doesn't work
when editing the command line.
Solution: Escape the CSI byte when inserting in the input buffer. (Yukihiro
Nakadaira)
Files: src/gui.c, src/ui.c
*** ../vim-7.1.077/src/gui.cThu May 10 19:19:15 2007
--- src/gui.c Tue Aug 14 12:41:43 2007
***
*** 5117,5123
p = vim_strsave_escaped(fnames[i], (char_u *)"\\ \t\"|");
# endif
if (p != NULL)
! add_to_input_buf(p, (int)STRLEN(p));
vim_free(p);
vim_free(fnames[i]);
}
--- 5117,5123
p = vim_strsave_escaped(fnames[i], (char_u *)"\\ \t\"|");
# endif
if (p != NULL)
! add_to_input_buf_csi(p, (int)STRLEN(p));
vim_free(p);
vim_free(fnames[i]);
}
*** ../vim-7.1.077/src/ui.c Thu May 10 21:14:11 2007
--- src/ui.cTue Aug 14 12:41:42 2007
***
*** 1603,1610
#if defined(FEAT_GUI) || defined(FEAT_MOUSE_GPM) \
|| defined(FEAT_XCLIPBOARD) || defined(VMS) \
|| defined(FEAT_SNIFF) || defined(FEAT_CLIENTSERVER) \
- || (defined(FEAT_GUI) && (!defined(USE_ON_FLY_SCROLL) \
- || defined(FEAT_MENU))) \
|| defined(PROTO)
/*
* Add the given bytes to the input buffer
--- 1603,1608
***
*** 1630,1636
}
#endif
! #if (defined(FEAT_XIM) && defined(FEAT_GUI_GTK)) \
|| (defined(FEAT_MBYTE) && defined(FEAT_MBYTE_IME)) \
|| (defined(FEAT_GUI) && (!defined(USE_ON_FLY_SCROLL) \
|| defined(FEAT_MENU))) \
--- 1628,1636
}
#endif
! #if ((defined(FEAT_XIM) || defined(FEAT_DND)) && defined(FEAT_GUI_GTK)) \
! || defined(FEAT_GUI_MSWIN) \
! || defined(FEAT_GUI_MAC) \
|| (defined(FEAT_MBYTE) && defined(FEAT_MBYTE_IME)) \
|| (defined(FEAT_GUI) && (!defined(USE_ON_FLY_SCROLL) \
|| defined(FEAT_MENU))) \
*** ../vim-7.1.077/src/version.cTue Aug 14 23:06:51 2007
--- src/version.c Wed Aug 15 20:07:06 2007
***
*** 668,669
--- 668,671
{ /* Add new patch number below this line */
+ /**/
+ 78,
/**/
--
hundred-and-one symptoms of being an internet addict:
164. You got out to buy software, instead of going out for a 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///
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: undo after :retab
On Wed 15-Aug-07 9:59am -0600, Yakov Lerner wrote: > Undo after retab modifies 'tabstop' in a way that doesn't look consistent or > correct. > Test case: > - > vim -u NONE -U NONE > iabc > :set ts=4 > :retab 8 > u > -- > After the last u, tabstop changes to 8. But we expect the screen > to return to the state before :retab where tabstop was 4, not 8. What we should expect from 'u' is the buffer to change to its state before ':retab 8' - it does exactly that. In your example: :set ts=4 does not change the buffer but does change the visual appearance. The tabstop is change to 4. :retab 8 changes the tabstop to 8 but does not change the visual appearance - as stated in the help file. It does this by changing the tab to 4 spaces - a change to the buffer. u This undoes the buffer change - the 4 spaces are restored to a tab. It does not change settings - the tabstop remains 8. -- Best regards, Bill --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
test64?
Hi Edward, Patch 7.1.071 adds test64 into src/testdir/. But it is not there as I browse the subversion repository below. Is there any problem or am I wrong? https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1/src/testdir/ Thanks, Xiaozhou --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: dynamic programming for gq formatting
Georg Dahn wrote: > Andrew Myers wrote: >> Actually, I think I would make the strong claim that what I am >> talking about is not just some personal preference, but a fairly >> universal one. All serious text formatting systems try to make line >> lengths equal (without introducing additional line breaks), because >> this is known to aid readability. > > If your purpose is text formatting, you are right, but Vim is no text > formatting system, but a text editor which is mainly used for > programming and other technical stuff. > >> The TeX formatting algorithm is one >> widely used approach. I can't see what generally held notion of >> goodness the current formatting optimizes for except algorithmic >> simplicity. But perhaps someone can explain why they prefer >> linebreaks to be inserted greedily? > > Vim is mainly used for coding and other technical stuff. Your preferred > behavior is better for formatting prose, but it is not wanted when > someone wants to reformat C code. In many situations I would like to > have your suggested behavior available, thus I wrote that I would like > to have it in addition to the current behavior. I really miss it when I > write emails or some other texts in prose. But when I use Vim for more > technical stuff like coding, I prefer the current behavior. > > Best wishes, > Georg Dahn Vim is a plain _text editor_ , not a fancy _word processor_ . This said, 20 years ago on Dos 3.2 I used a shareware plaintext editor which could justify text and even print it justified within user-settable left and right margins using pixel-spacing and a proportional font on a 9-pin raster printer. It would even "ring the bell", like typewriters do (actuating the computer's beep), when you arrived at a user-settable column near the right margin. Vim doesn't do that (or at least it doesn't do it out of the box), but it does many things which that primitive editor didn't do. Syntax colouring, for example, or running scripts with ifs and whiles. And, of course, things which were unknown in those days, such as selecting a display font or editing Unicode text. All in all, I wouldn't go back, even if I still had a copy of that old editor someplace where I could use it. Best regards, Tony. -- A man wrapped up in himself makes a very small package. --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
there's undojoin -- how about dotjoin?
Hello! I'd like to do imap ... = ...=:something however, "." no longer repeats the small change. For example: imap = =:echo "hello!" work with the following file contents: abc; def; Place cursor on the semicolon with "abc;" -- insert =2 Now put the cursor on the semicolon with "def;" and press "." . All you get is def 2; Now, if there was a dotjoin: imap = =:dotjoinecho "hello!" just might work! Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
undo after :retab
Undo after retab modifies 'tabstop' in a way that doesn't look consistent or correct. Test case: - vim -u NONE -U NONE iabc :set ts=4 :retab 8 u -- After the last u, tabstop changes to 8. But we expect the screen to return to the state before :retab where tabstop was 4, not 8. THanks Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: dynamic programming for gq formatting
On Aug 15, 2007, at 3:21 AM, Matthew Winn wrote: > > I get the impression that the OP doesn't want right-aligned text, but > wants a better distribution of ragged-right lines. For example, > consider the first two lines of this paragraph. The naïve breaking > algorithm used by my mail client has left a deep indentation at the > end of the second line. A better algorithm would move the "but" from > the end of the first line to the start of the second, making the ends > of the lines appear more regular. Exactly. For a small example, suppose that the text width is 10. The current greedy algorithm tries to pack as much onto each line as possible before inserting a line break. Sometimes this means it does a bad job of filling later lines, resulting in text like this: xxx yyy zz bbb. when it would be better to break the first line earlier: xxx zz bb. Equalizing line lengths makes a very noticeable difference when applied to large blocks of text. (Note that the last line in a paragraph doesn't count -- you don't try to make that one equal-length.) A couple of people have commented, "I like what gq does now because I use it on code." It seems to me that the proposed change would make it do no worse a job of formatting code, and would improve the formatting of comments within code. Cheers, -- Andrew --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Windows gvim leaves command prompt up
On 10/08/2007 09:58, Mike Williams wrote:
> On 10/08/2007 02:01, Ilya Bobir wrote:
>> Ilya Bobir wrote:
>>> [...]
>>>
>>> It does work on NT. But CreateProcess(..., CREATE_NO_WINDOW, ...) is
>>> needed. An example implementation is attached.
>>>
>> I've just found slightly different approach to creating a console for a
>> child process. It has an advantage of creating one console per child
>> thus allowing communication with more that one child process.
>> Here is the code:
>>
>> SECURITY_ATTRIBUTES sa;
>> PROCESS_INFORMATION pi;
>> HANDLE newstdin, newstdout;
>> HANDLE read_stdout, write_stdin;
>>
>> sa.lpSecurityDescriptor = 0;
>> sa.nLength = sizeof(SECURITY_ATTRIBUTES);
>> sa.bInheritHandle = true;
>>
>> CreatePipe(&newstdin, &write_stdin, &sa, 0);
>> CreatePipe(&read_stdout, &newstdout, &sa, 0);
>>
>> GetStartupInfo(&si);
>> si.dwFlags = STARTF_USESTDHANDLES | STARTF_USESHOWWINDOW;
>> si.wShowWindow = SW_HIDE; // hide child application window
>> si.hStdOutput = newstdout; // use newstdout instead of STDOUT
>> si.hStdError = newstdout; // use newstdout instead of STDERR
>> si.hStdInput = newstdin; // use newstdin instead of STDIN
>>
>> if(0 == CreateProcess(
>> exe, NULL, NULL, NULL, true, CREATE_NEW_CONSOLE,
>> NULL, NULL, &si, &pi))
>> {
>> printf("\nCreateProcess() fails with error: %i", GetLastError());
>> return -1;
>> }
>>
>>
>> In case pipes are in blocking mode then the PeekNamedPipe() call can be
>> used to check for incoming data:
>>
>> if (0 == PeekNamedPipe(
>> read_stdout, buf, BUFSIZE - 1, &bread, &avail, NULL))
>> {
>> printf("\nPeekNamedPipe() fails with error: %i", GetLastError());
>> break;
>> }
>>
>> if (bread > 0)
>> {
>> // Data have arrived
>> }
>
> All looks good stuff - I'll try and get round to trying it out this weekend.
Ok, starting to look into this in detail. I was delayed from moving
over to using a Mercurial repository to track released VIM patches and
my own hacking around with the source. Progress wont be as fast as
Windows hacking is not my usual job - then again I hack VIM on WIndows
to learn ;-) More soon(ish).
Mike
--
When I want your help, I'll ask for it. Help?
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: patch 7.1.068
Adri Verhoef wrote: > On Sun, Aug 12, 2007 at 14:55:48 +, Bram Moolenaar wrote: > > Patch 7.1.068 > > --- runtime/doc/options.txt Sat Aug 11 17:25:38 2007 > > ! 4. one of the other windows are wider than the current or new > > ! window. > > Should be: ...one of the other windows is wider... Thanks. But it's in windows.txt, not in options.txt. -- hundred-and-one symptoms of being an internet addict: 162. You go outside and look for a brightness knob to turn down the sun. /// 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/// --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: dynamic programming for gq formatting
Andrew Myers wrote: > Actually, I think I would make the strong claim that what I am > talking about is not just some personal preference, but a fairly > universal one. All serious text formatting systems try to make line > lengths equal (without introducing additional line breaks), because > this is known to aid readability. If your purpose is text formatting, you are right, but Vim is no text formatting system, but a text editor which is mainly used for programming and other technical stuff. > The TeX formatting algorithm is one > widely used approach. I can't see what generally held notion of > goodness the current formatting optimizes for except algorithmic > simplicity. But perhaps someone can explain why they prefer > linebreaks to be inserted greedily? Vim is mainly used for coding and other technical stuff. Your preferred behavior is better for formatting prose, but it is not wanted when someone wants to reformat C code. In many situations I would like to have your suggested behavior available, thus I wrote that I would like to have it in addition to the current behavior. I really miss it when I write emails or some other texts in prose. But when I use Vim for more technical stuff like coding, I prefer the current behavior. Best wishes, Georg Dahn --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: dynamic programming for gq formatting
On Tue, 14 Aug 2007 18:55:53 -0700, Gary Johnson <[EMAIL PROTECTED]> wrote: > I believe the studies that have shown fully-justified text to be > easier to read than left-justified (ragged-right) text used > proportional fonts properly typeset on a printed page. > > Vim uses a mono-spaced font. Attempts to fully justify mono-spaced > type generally look pretty bad--you can't adjust the spacing within > words and the spacing between words is adjustable only increments of > m spaces. I get the impression that the OP doesn't want right-aligned text, but wants a better distribution of ragged-right lines. For example, consider the first two lines of this paragraph. The naïve breaking algorithm used by my mail client has left a deep indentation at the end of the second line. A better algorithm would move the "but" from the end of the first line to the start of the second, making the ends of the lines appear more regular. -- Matthew Winn --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
