Re: Feature request: Add a --role= command line argument for gvim
On Saturday, 25 April 2015 21:55:15 UTC+2, James McCoy wrote: > On Sat, Apr 25, 2015 at 12:42:04PM -0700, Tomas Sandven wrote: > > When multiple separate gvim instances are running, there is no good > > way to tell them apart (that I've found.) > > > > I suggest adding a command line argument so that gvim instances can be > > launched > > with different X roles: > > > > gvim --role=notepad > > gvim --role=dev_proj1 > > gvim --role=dev_proj2 > > This is already supported if you have a Gtk build of Vim. > > $ gvim --help > … > Arguments recognised by gvim (GTK+ version): >-font Use for normal text (also: -fn) >-geometry Use for initial geometry (also: -geom) >-reverse Use reverse video (also: -rv) >-displayRun vim on (also: --display) >--role Set a unique role to identify the main window >--socketid Open Vim inside another GTK widget >--echo-wid Make gvim echo the Window ID on stdout > > Cheers, > -- > James > GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy Wow, you're right... I've been through "man vim" several times, and the GTK+ specific stuff wasn't in there. Thanks! -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: kconfig.vim: support for matchit
Hi Peter, > Just a quick warning: You may want to involve Bram (cc him) right away. > Nikolai Weibull maintained an indent file for vim that I sent a patch to > and didn't reply for months. When I finally got in touch with him, it > turned out that he was no longer able to give his time to maintain the > file. Things may have gotten better, but it sounded like he didn't think > he'd be available in the future. Thanks :-). I've already sent it just to Nikolai. If he does't reply in few days, I forward it to Bram. Kind Regards, Petr -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: vim-cpp updated
Yasuhiro Matsumoto wrote: > updated vim-cpp. > > description: https://github.com/vim-jp/vim-cpp/pull/32 > changes: > https://github.com/vim-jp/vim-cpp/commit/0911af4c4c2ba8b54fe1a90a36dd0a3f1341da83.patch Thanks, I'll include it soon. -- Sometimes you can protect millions of dollars in your budget simply by buying a bag of cookies, dropping it on the budget anylyst's desk, and saying something deeply personal such as "How was your weekend, big guy?" (Scott Adams - The Dilbert principle) /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: E94 generated by bufwinnr()
Jakson Alves de Aquino wrote: > With the following in my vimrc > > set debug=msg,throw > > the function bufwinnr() generates E94 if the buffer does not > exist. Example: > > :echo bufwinnr("nothing") > > Is it correct to raise an error in this case? I think that there > should be no error because when the buffer does not exist the > function returns a predefined value (-1) that can be checked in > scripts. This happens because you have put "msg" in 'debug'. Docs: msg Error messages that would otherwise be omitted will be given anyway. -- A salesperson says:Translation: "backward compatible" Old technology "Premium" Overpriced "Can't keep it on the shelf" Unavailable "Stands alone" Piece of shit "Proprietary" Incompatible (Scott Adams - The Dilbert principle) /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: round() with digits
Yasuhiro Matsumoto wrote: > Hi list. > > round(n) should take digits to round up with second argument. > > round(5.127)-> 5.0 > round(5.127,-1) -> 10.0 > round(5.127,0) -> 5.0 > round(5.127,1) -> 5.1 > round(5.127,2) -> 5.13 > round(5.127,3) -> 5.127 > > below is a patch to add second argument {digit} into round(). > > https://gist.github.com/mattn/8591d5316b990fc4d7d5 I suppose it's useful sometimes. Although it can be done a multiply and divide (which is how it's implemented). The documentaiton doesn't explain what {digits} is for, there is only an example. -- If the Universe is constantly expanding, why can't I ever find a parking space? /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: kconfig.vim: support for matchit
On Saturday, April 25th, 2015 at 8:30AM, petr.vo...@gmail.com wrote: > Hi Christian, > > > Usually the maintainer takes care of changes to the plugins and will > > later send complete files to Bram for inclusion with Vim. > Thanks for info. I'll send it to Nikolai Weibull. Just a quick warning: You may want to involve Bram (cc him) right away. Nikolai Weibull maintained an indent file for vim that I sent a patch to and didn't reply for months. When I finally got in touch with him, it turned out that he was no longer able to give his time to maintain the file. Things may have gotten better, but it sounded like he didn't think he'd be available in the future. Best, Peter -- We have not been faced with the need to satisfy someone else's requirements, and for this freedom we are grateful. Dennis Ritchie and Ken Thompson, The UNIX Time-Sharing System -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: kconfig.vim: support for matchit
Hi Christian, > Usually the maintainer takes care of changes to the plugins and will > later send complete files to Bram for inclusion with Vim. Thanks for info. I'll send it to Nikolai Weibull. Kind regards, Petr -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Feature request: Add a --role= command line argument for gvim
On Sat, Apr 25, 2015 at 12:42:04PM -0700, Tomas Sandven wrote: > When multiple separate gvim instances are running, there is no good > way to tell them apart (that I've found.) > > I suggest adding a command line argument so that gvim instances can be > launched > with different X roles: > > gvim --role=notepad > gvim --role=dev_proj1 > gvim --role=dev_proj2 This is already supported if you have a Gtk build of Vim. $ gvim --help … Arguments recognised by gvim (GTK+ version): -font Use for normal text (also: -fn) -geometry Use for initial geometry (also: -geom) -reverse Use reverse video (also: -rv) -displayRun vim on (also: --display) --role Set a unique role to identify the main window --socketid Open Vim inside another GTK widget --echo-wid Make gvim echo the Window ID on stdout Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: Feature request: Add a --role= command line argument for gvim
Hi Tomas! On Sa, 25 Apr 2015, Tomas Sandven wrote: > When multiple separate gvim instances are running, there is no good > way to tell them apart (that I've found.) > > I suggest adding a command line argument so that gvim instances can be > launched with different X roles: > > gvim --role=notepad gvim --role=dev_proj1 gvim --role=dev_proj2 > > This makes is easy to apply different window management rules to the > different gvim instances. > > I am using i3wm with saved layouts to start my work environment. This > involves 8 terminals and 3 instances of gvim. gnome-terminal has a > --role= option, but gvim doesn't, so I currently have to position > those windows manually every time. I still don't understand what --role is supposed to do. So can you please explain in more detail? Best, Christian -- Letztens waren wir Beamten bei einer Schneckenjagd. Aber ich hatte kein Glück- immer wenn eine Schnecke ankam und ich sie fangen wollte - schwupp, weg war sie, wie der Blitz! -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Feature request: Add a --role= command line argument for gvim
When multiple separate gvim instances are running, there is no good way to tell them apart (that I've found.) I suggest adding a command line argument so that gvim instances can be launched with different X roles: gvim --role=notepad gvim --role=dev_proj1 gvim --role=dev_proj2 This makes is easy to apply different window management rules to the different gvim instances. I am using i3wm with saved layouts to start my work environment. This involves 8 terminals and 3 instances of gvim. gnome-terminal has a --role= option, but gvim doesn't, so I currently have to position those windows manually every time. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [patch] 'list += list' changes locked/RO list; issues changing v:oldfiles
On 25-Apr-15, Bram Moolenaar wrote: > Thanks for the analysis, patch and test! I am glad when this helps. :) Olaf -- Olaf Dabrunz (oda fctrace.org) -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
E94 generated by bufwinnr()
Hi, With the following in my vimrc set debug=msg,throw the function bufwinnr() generates E94 if the buffer does not exist. Example: :echo bufwinnr("nothing") Is it correct to raise an error in this case? I think that there should be no error because when the buffer does not exist the function returns a predefined value (-1) that can be checked in scripts. Thanks! -- Jakson Alves de Aquino www.lepem.ufc.br/aquino.php?lang=en -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [patch] more non-breaking spaces
Christian Brabandt wrote: > Bram, > Vim is treating U+0160 special with the listchars flag "nbsp". > But there are more non-breaking spaces, e.g. U+202F (narrow no-break > space) and U+FEFF (zero width no-break space). > > So here is a patch, that will also use the nbsp flag for those two chars > as well. > > Also, one could argue, U+FEFF should be displayed as ' ' and not as > but for now I leave it as is. Thanks! I think it's good to handle FEFF differently, it's supposed to be used as a byte order mark, not as white space. If Vim doesn't recognize it and set 'bomb' then it's good to display it. -- At some point in the project somebody will start whining about the need to determine the project "requirements". This involves interviewing people who don't know what they want but, curiously, know exactly when they need it. (Scott Adams - The Dilbert principle) /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [patch] fixed invalid memory access in regex_nfa.c with invalid utf8
Dominique wrote: > Vim-7.4.711 accesses invalid memory with this command: > > $ vim -E -u NONE -c 'call search(getline("."))' crash-2 > > ... where "crash-2" is the attached file (12 bytes). > > Symptoms look similar to the bug fixed in Vim-7.4.704, > but it is a different bug with a different stack reported by > the address sanitizer: [...] > Attached patch fixes it. I hope that such bugs with > invalid utf8 are not too nitpicky. Each one of these might cause a crash. > Bug was found using the "american fuzzy lop" fuzzer: > http://lcamtuf.coredump.cx/afl/ Thanks for the patch! -- If your company is not involved in something called "ISO 9000" you probably have no idea what it is. If your company _is_ involved in ISO 9000 then you definitely have no idea what it is. (Scott Adams - The Dilbert principle) /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [patch] 'list += list' changes locked/RO list; issues changing v:oldfiles
Olaf Dabrunz wrote: > Example: > > :let l = ['a', 'b', 3] > :lockvar 1 l > :let l += ['x'] > E741: Value is locked: l > :let l > l ['a', 'b', 3, 'x'] > > When the error message is shown, the list has already been changed. > > > Changing lists in the v: scope has a related problem: v:oldfiles is not > locked nor readonly and thus modifiable (as documented in > ':he v:oldfiles'), but changing such a v: scope list variable prints an > error message and does not succeed, except when extending it with '+=': > > :let v:oldfiles += ['test'] > E685: Internal error: set_var() > :let v:oldfiles > v:oldfiles['fileA', 'fileB', ..., 'test'] > > :let v:oldfiles = ['otherfile'] > E685: Internal error: set_var() > :let v:oldfiles > v:oldfiles['fileA', 'fileB', ..., 'test'] > > > The patch adds checks for the lock and readonly flags of a variable > before preparing a [+-.]= assignment, as that preparation alone is > sufficient to extend an existing list variable. (Preparations for other > variable types do not change existing variables.) > > The patch also adds code to allow v: scope lists, dicts, floats and > funcrefs to be changed, unless they are locked or readonly or unless the > change also would change the variable type. > > So far, this only affects v:oldfiles. > > v:key is either set to a string or a number and is readonly, v:val > can have any type but is readonly, and the remaining v: scope > variables have types fixed at string or number, and most are > readonly as well. > > With these changes in place, a '+=' extension of a list, once prepared, > cannot be canceled by any of the subsequent checks in set_var() before > the variable setting is finalized. These checks are: > > - Check for user lock and readonly flags. Same as done in tv_op(). > > - Two checks for variable type mismatches. > > For a list extension, tv_op() would have failed on a type mismatch > already, and for others the assignment target variable has not been > changed yet, so there is no problem if the assignment fails here. > > Note that in other places tv_op() is used to change the target value(s) > directly, and no subsequent checks are done that could cause problems. > > > A remaining problem is that the interdependence of the checks and > preparations in set_var_lval() and tv_op() with checks in set_var() > is implicit, and this makes this code more difficult to maintain. One > could consider moving the tv_op() for setting plain variables into > set_var(), but I have not looked into this sufficiently. Thanks for the analysis, patch and test! -- For large projects, Team Leaders use sophisticated project management software to keep track of who's doing what. The software collects the lies and guesses of the project team and organizes them in to instantly outdated charts that are too boring to look at closely. This is called "planning". (Scott Adams - The Dilbert principle) /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
How to link libwinpthread statically using mingw-w64-builds undef windows
Hi. Can anybody help to build gvim with statically linked libwinpthread? I use following command: mingw32-make.exe -j%NUMBER_OF_PROCESSORS% -f Make_ming.mak ^ STATIC_STDCPLUS=yes ^ ARCH=x86-64 ^ OPTIMIZE=MAXSPEED ^ DIRECTX=yes ^ FEATURES=HUGE ^ OLE=yes ^ POSTSCRIPT=yes ^ gvim.exe xxd/xxd.exe vimrun.exe but libwinpthread still linked dynamically. gcc version 4.9.2. Thanks. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [patch] more non-breaking spaces
Hi Marius! On Fr, 24 Apr 2015, Marius Gedminas wrote: > On Thu, Apr 23, 2015 at 09:17:57PM +0200, Christian Brabandt wrote: > > Bram, > > Vim is treating U+0160 special with the listchars flag "nbsp". > > But there are more non-breaking spaces, e.g. U+202F (narrow no-break > > space) and U+FEFF (zero width no-break space). > > (U+FEFF is also known as the Byte Order Mark.) Oh yes, I should have known that. I got confused, because that was not mentioned in the Unicode Table I used to lookup the names. > > > So here is a patch, that will also use the nbsp flag for those two chars > > as well. > > > > Also, one could argue, U+FEFF should be displayed as ' ' and not as > > but for now I leave it as is. > > U+FEFF is zero-width, ' ' isn't. I don't think it's a good idea to make > it appear the same as other no-break spaces. Yes, it should probably left alone. Mit freundlichen Grüßen Christian -- Man wird in der Freundschaft und der Liebe leicht Heuchler, der übertreibt, wenn man das stärkste Bedürfnis und Gefühl beider hat und den Gegenstand dazu entbehrt; und doch falschen dafür sucht und nimmt. -- Jean Paul -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.