Re: Class implementation
On Fri, Feb 03, 2023 at 12:55:30PM +, Bram Moolenaar wrote: > > On Thu, Feb 02, 2023 at 05:28:03PM +, Bram Moolenaar wrote: > > > 3. Add a mechanism to name the members in the call, e.g. > > > var obj = Class.new(line = 5, column = 0) > > >This is similar to 2. but puts it in one line. > > >It requires marking a method to not use positional arguments.a > > > > > > Although 3. looks like a good solution, it requires implementing a new > > > mechanism. And disallowing positional arguments might be considered > > > weird, I cannot think of a language that has this functionality. > > > > Python lets you declare that a function will not accept positional > > arguments: > > > > def fn(*, line, column, also_arg_with_a_default_value=42): > > ... > > > > fn(line=5, column=0) > > fn(column=0, line=5) > > fn(0, 5)# <-- error, positional arguments not allowed > > fn(line=5) # <-- error, 'column' argument is required > > I have been using Python but didn't know about this mechanism. This syntax was added in Python 3.0. Since I started with Python 2.1, I still think of it as "the new keyword-only argument syntax". I'm old. > Apparently the "*" can also appear later, e.g. > > def fn(line, *, column, also_arg_with_a_default_value=42): > > Now you can use: > fn(5, column=0) > > Although this works, I find it rather obscure. It is a consequence of allowing variable number of arguments with *args: def fn(regular, args, *the_rest): the Python designers decided to allow additional arguments after the all-consuming varargs argument def fn(regular, args, *the_rest, keyword_only=None): and then if you don't actually want the varargs you can omit the name for it def fn(regular, args, *, keyword_only=None): Anyway, I wasn't proposing this syntax for Vimscript, merely mentioning that there are languages that have this functionality. Marius Gedminas -- Initially, there were few or no postal regulations governing packages mailed parcel post. To construct a bank in Vernal, Utah in 1916, a Salt Lake City Company figured out that the cheapest way to send 40 tons of bricks to the building was by Parcel Post. Each brick was individually wrapped & mailed. Postal rules were promptly rewritten. -- http://en.wikipedia.org/wiki/United_States_Postal_Service -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/20230204135355.t3dapt6ktwbttprc%40blynas. signature.asc Description: PGP signature
Re: Class implementation
On Thu, Feb 02, 2023 at 05:28:03PM +, Bram Moolenaar wrote: > 3. Add a mechanism to name the members in the call, e.g. > var obj = Class.new(line = 5, column = 0) >This is similar to 2. but puts it in one line. >It requires marking a method to not use positional arguments.a > > Although 3. looks like a good solution, it requires implementing a new > mechanism. And disallowing positional arguments might be considered > weird, I cannot think of a language that has this functionality. Python lets you declare that a function will not accept positional arguments: def fn(*, line, column, also_arg_with_a_default_value=42): ... fn(line=5, column=0) fn(column=0, line=5) fn(0, 5)# <-- error, positional arguments not allowed fn(line=5) # <-- error, 'column' argument is required Marius Gedminas -- I can barely exit nano. -- Christian Neukirchen -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/20230203115840.ok4vynyj7z724wpn%40blynas. signature.asc Description: PGP signature
Re: Problem with opening urls with vim 9.815
On Tue, Oct 25, 2022 at 08:25:30AM -0700, Cesar wrote: > I'm using vim 9.815 on Windows 10 Home, compiled with MinGW64. When I > type gx or :Utl on a url, say https://www.google.com, I get the site > displayed, but when I type it again, after a couple of minutes, I get: > > -- > Vi Improved - A Text Editor has stopped working > > A problem caused the program to stop working correctly. Windows will > close the program and notify you if a solution is available > > DebugClose program > -- > > That didn't happen with older releases, at least not with vim 9.667 This is likely the same issue as https://github.com/vim/vim/issues/11424 Downgrading to 9.0.0814 should fix it. Marius Gedminas -- This company has performed an illegal operation and will be shut down. If the problem persists, contact your vendor or appeal to a higher court. -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/20221026062205.k3lb24niwup7jwqn%40blynas. signature.asc Description: PGP signature
Re: Strange patch 9.0.815
On Sat, Oct 22, 2022 at 05:47:32PM +0200, Tony Mechelynck wrote: > At least on the Mercurial server, patch 9.0.815 has no description of > the "problem", nor of the "solution", and it also hasn't got a > Mercurial tag. Same on the Git server. Also, the v9.0.0814 tag points to the same commit as v9.0.0813, and the actual 9.0.0814 commit is untagged. > Neither does it have a vim-dev message AFAICT. I haven't seen one. But I have seen the segfaults introduced by it. Marius Gedminas -- /* Intel provided a special instruction to clear the TS bit for people too cool * to use write_cr0() to do it. This "clts" instruction is faster, because all * the vowels have been optimized out. */ -- lguest source code -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/20221022190307.4ci3j7yvgkwmwf4z%40blynas. signature.asc Description: PGP signature
Re: 9.0.0475 segfaults while compiling vim9script
On Fri, Sep 16, 2022 at 01:09:32PM +0300, Marius Gedminas wrote: > On Fri, Sep 16, 2022 at 01:07:06PM +0300, Marius Gedminas wrote: > > vim 9.0.0475 segfauls whenever I try to edit a file, including a > > nonexistent file (e.g. vim newfile.txt). > > git bisect blames > > commit b46c083a5ed9e0c4ac5f3aec577946dcbe8c9dc5 > Author: Bram Moolenaar > Date: Thu Sep 15 17:19:37 2022 +0100 > > patch 9.0.0470: in :def function all closures in loop get the same > variables The segfault went away when I did a full rebuild after git clean -dfx. Weird. Perhaps some data structure layout changed and the Makefile didn't have the correct dependencies to rebuild everything affected? Marius Gedminas -- I don't do martial arts, runny aroundy sports and I certainly don't put on armour and have at other people with a sword, which I think are the activities that account for most of the injuries. I just get hit in the face with staircases wielded by tiny, tiny cats and occasionally am set on fire. Normal stuff. -- James Nicoll -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/20220916101718.wdtydvce2q4emsiz%40blynas. signature.asc Description: PGP signature
Re: 9.0.0475 segfaults while compiling vim9script
On Fri, Sep 16, 2022 at 01:07:06PM +0300, Marius Gedminas wrote: > vim 9.0.0475 segfauls whenever I try to edit a file, including a > nonexistent file (e.g. vim newfile.txt). git bisect blames commit b46c083a5ed9e0c4ac5f3aec577946dcbe8c9dc5 Author: Bram Moolenaar Date: Thu Sep 15 17:19:37 2022 +0100 patch 9.0.0470: in :def function all closures in loop get the same variables Problem:In a :def function all closures in a loop get the same variables. Solution: When in a loop and a closure refers to a variable declared in the loop, prepare for making a copy of variables for each closure. Marius Gedminas -- Hoffstadter's Law states: "It always takes longer than you think, even when you consider Hoffstadter's Law." -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/20220916100932.pykdj6ap4tiij5im%40blynas. signature.asc Description: PGP signature
9.0.0475 segfaults while compiling vim9script
pe_stack2 (vim9type.c:1313) ==26992==by 0x450C25: generate_instr_type2 (vim9instr.c:81) ==26992==by 0x450C67: generate_instr_type (vim9instr.c:96) ==26992==by 0x451C9C: generate_PUSHNR (vim9instr.c:648) ==26992==by 0x451A66: generate_tv_PUSH (vim9instr.c:581) ==26992==by 0x448DFE: generate_ppconst (vim9expr.c:39) ==26992==by 0x450A3B: compile_expr0_ext (vim9expr.c:3291) ==26992==by 0x450A8D: compile_expr0 (vim9expr.c:3302) ==26992==by 0x44A538: compile_arguments (vim9expr.c:644) ==26992== Address 0x320010 is not stack'd, malloc'd or (recently) free'd ==26992== ==26992== Invalid read of size 8 ==26992==at 0x45317F: check_internal_func_args (vim9instr.c:1422) ==26992==by 0x45327F: generate_BCALL (vim9instr.c:1450) ==26992==by 0x44AF7E: compile_call (vim9expr.c:846) ==26992==by 0x44E697: compile_expr9 (vim9expr.c:2367) ==26992==by 0x44E929: compile_expr8 (vim9expr.c:2427) ==26992==by 0x44EA34: compile_expr7 (vim9expr.c:2461) ==26992==by 0x44ED51: compile_expr6 (vim9expr.c:2540) ==26992==by 0x44F23A: compile_expr5 (vim9expr.c:2648) ==26992==by 0x44F713: compile_expr4 (vim9expr.c:2785) ==26992==by 0x450155: compile_expr3 (vim9expr.c:3059) ==26992==by 0x4501C2: compile_expr2 (vim9expr.c:3084) ==26992==by 0x45029C: compile_expr1 (vim9expr.c:3125) ==26992== Address 0xfff8 is not stack'd, malloc'd or (recently) free'd ==26992== ==26992== ==26992== Process terminating with default action of signal 11 (SIGSEGV) ==26992==at 0x640775B: kill (syscall-template.S:120) ==26992==by 0x314080: may_core_dump (os_unix.c:3519) ==26992==by 0x314020: mch_exit (os_unix.c:3485) ==26992==by 0x4D72D8: getout (main.c:1743) ==26992==by 0x2D3204: preserve_exit (misc1.c:2243) ==26992==by 0x31163E: deathtrap (os_unix.c:1170) ==26992==by 0x640751F: ??? (in /usr/lib/x86_64-linux-gnu/libc.so.6) ==26992==by 0x45317E: check_internal_func_args (vim9instr.c:1422) ==26992==by 0x45327F: generate_BCALL (vim9instr.c:1450) ==26992==by 0x44AF7E: compile_call (vim9expr.c:846) ==26992==by 0x44E697: compile_expr9 (vim9expr.c:2367) ==26992==by 0x44E929: compile_expr8 (vim9expr.c:2427) Marius Gedminas -- Quantum materiae materietur marmota monax si marmota monax materiam possit materiari? -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/20220916100706.vdxpbip455zmvx72%40blynas. signature.asc Description: PGP signature
Re: Travis CI no longer triggers
On Sat, Jun 12, 2021 at 12:54:33PM +0200, Bram Moolenaar wrote: > The last patch to have been run on Travis is 8.2.2966. Since then it > looks like this CI is no longer picking up patches. Anyone knows why? Travis CI gives 1 free credits to OSS projects. This is not a monthly/yearly amount, it's a one-time donation. Once the credits run out, you have to pay, or email Travis and ask for an additional one-time donation that starts the cycle anew. I'm familiar with some organizations maintaining OSS software that have emailed Travis to ask for credits and have waited months to get a response. Most of them gave up and migrated to alternative CI solutions, usually GitHub Actions. You can check the amount of used and remaining credits after logging in to travis-ci.com: - https://travis-ci.com/account/plan/usage (for personal projects) - https://travis-ci.com/organizations/ORGANIZATION/plan/usage (for GitHub organizations) Marius Gedminas -- We're sysadmins. To us, data is a protocol-overhead. -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/20210613182106.yklbu3vpy47ps5xt%40blynas. signature.asc Description: PGP signature
Re: Patch 8.2.2421
On Thu, Jan 28, 2021 at 02:26:18PM +0100, Bram Moolenaar wrote: > Patch 8.2.2421 > Problem:Double free when using autocommand with "argdel". (Houyunsong) > Solution: Add the arglist_locked flag. > Files: src/arglist.c, src/testdir/test_autocmd.vim This fails to build with arglist.c: In function ‘check_arglist_locked’: arglist.c:29:9: error: ‘e_cannot_change_arglist_recursively’ undeclared (first use in this function); did you mean ‘e_cannot_change_list_item’? 29 | emsg(_(e_cannot_change_arglist_recursively)); | ^~~~~~~ Marius Gedminas -- I can barely exit nano. -- Christian Neukirchen -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/20210128154503.jz4jlvnmmg7ae7fg%40blynas. signature.asc Description: PGP signature
Re: Impossible to abort slow read and write
On Wed, Oct 28, 2020 at 11:32:42AM +0100, Bram Moolenaar wrote: > Brennan Vincent wrote: > > > Let's simulate a read that will block forever: > > > > $ mkfifo /tmp/myfifo > > $ vim /tmp/myfifo > > > > Now vim hangs permanently; it cannot be killed or suspended except by > > going to another terminal and running `pkill -9 vim`. (Or, of course, > > writing stuff to the fifo, but the point here wasn't about fifos > > specifically, but just about reads that are slow to return for whatever > > reason). > > > > Same story with :w or :w! to a file that is slow to write. > > > > IMO, this "hang forever and give the user no way to recover" behavior is > > a bug, but reasonable people might disagree. > > It's not so easy to make this work, especially with a fifo. Vim is in > raw mode, thus a CTRL-C is not turned into an interrupt. We could > switch to cooked mode for that, but then any typeahead is becoming a > problem. Would switching to cbreak mode help? It works like raw, but converts ^C to an interrupt. (I'm not sure exactly when, but it seems to me that in the last year or so modern versions of Vim became harder to interrupt with ^C, especially when a plugin is running.) Marius Gedminas -- Apologies for taking up the bandwidth with the apology. Anything else I can apologise for .. er no can't think of anything, sorry about that. Andy Hunt (Member of British Olympic Apology Squad) -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/20201028164531.24xp3yolhy64ef7d%40blynas. signature.asc Description: PGP signature
Re: Patch 8.2.0807
On Fri, May 22, 2020 at 01:11:18PM +0200, Bram Moolenaar wrote:
> Patch 8.2.0807
> Problem:Cannot easily restore a mapping.
> Solution: Add mapset().
> Files: runtime/doc/eval.txt, src/map.c, src/proto/map.pro, src/evalfunc.c
> src/testdir/test_maparg.vim
> *** ../vim-8.2.0806/runtime/doc/eval.txt 2020-05-13 16:34:10.397723799
> +0200
> --- runtime/doc/eval.txt 2020-05-22 12:52:07.920142788 +0200
> ***
> *** 2582,2587
> --- 2586,2593
> rhs of mapping {name} in mode {mode}
> mapcheck({name} [, {mode} [, {abbr}]])
> String check for mappings matching {name}
> + mapset({name}, {mode}, {abbr}, {dict}
This line is missing a closing )
> + nonerestore mapping from |maparg()| result
> match({expr}, {pat} [, {start} [, {count}]])
> Number position where {pat} matches in {expr}
> matchadd({group}, {pattern} [, {priority} [, {id} [, {dict}]]])
Marius Gedminas
--
Isn't air travel wonderful? Breakfast in London, dinner in New York,
luggage in Brazil.
--
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/20200522175003.apohgnrymvqnl72u%40blynas.
signature.asc
Description: PGP signature
Re: Patch 8.2.0713
On Thu, May 07, 2020 at 06:52:00PM +0200, Bram Moolenaar wrote: > Patch 8.2.0713 > Problem:The pam_environment file is not recognized. > Solution: Add a filetype pattern for pamenv. (closes #6051) > Files: runtime/filetype.vim, src/testdir/test_filetype.vim > > > *** ../vim-8.2.0712/runtime/filetype.vim 2020-04-29 23:01:46.317364426 > +0200 > --- runtime/filetype.vim 2020-05-07 18:49:36.470272234 +0200 > *** > *** 1133,1138 > --- 1133,1141 > " Pam conf > au BufNewFile,BufRead */etc/pam.confsetf pamconf > > + " Pam environment > + au BufNewFile,BufRead .pam_environment setf pamenv > + I see no pamenv.vim in runtime/syntax/ or in runtime/filetype/ in current git master. Also, /etc/environment and /etc/default/locale use the same format and could be added to the pattern. (While at it, /etc/pam.d/*.conf could be added to the pamconf pattern above.) Marius Gedminas -- Un*x admins know what they are doing by definition. -- Bernd Petrovitsch -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/20200507204825.ng7cw3tpz5y3jlru%40blynas. signature.asc Description: PGP signature
Re: Patch 8.1.2296
On Tue, Nov 12, 2019 at 10:44:50PM +0100, Bram Moolenaar wrote:
>
> Patch 8.1.2296
> Problem:Text properties are not combined with syntax by default.
> Solution: Make it work as documented. (closes #5190)
> Files:src/testprop.c, src/testdir/test_textprop.vim
The changes to src/testprop.c are missing from the diff in this email,
and from the git commit as well. (Possibly because the file is actually
named src/textprop.c. Last change Nov 2, 2019.)
> *** ../vim-8.1.2295/src/testdir/test_textprop.vim 2019-11-09
> 21:28:06.526103024 +0100
> --- src/testdir/test_textprop.vim 2019-11-12 22:43:52.507605417 +0100
> ***
> *** 681,687
> \ "call prop_type_add('background', {'highlight': 'BackgroundProp',
> 'combine': 0})",
> \ "call prop_type_add('backgroundcomb', {'highlight': 'NumberProp',
> 'combine': 1})",
> \ "eval 'backgroundcomb'->prop_type_change({'highlight':
> 'BackgroundProp'})",
> ! \ "call prop_type_add('error', {'highlight': 'UnderlineProp',
> 'combine': 1})",
> \ "call prop_add(1, 4, {'end_lnum': 3, 'end_col': 3, 'type': 'long'})",
> \ "call prop_add(2, 9, {'length': 3, 'type': 'number'})",
> \ "call prop_add(2, 24, {'length': 4, 'type': 'number'})",
> --- 681,687
> \ "call prop_type_add('background', {'highlight': 'BackgroundProp',
> 'combine': 0})",
> \ "call prop_type_add('backgroundcomb', {'highlight': 'NumberProp',
> 'combine': 1})",
> \ "eval 'backgroundcomb'->prop_type_change({'highlight':
> 'BackgroundProp'})",
> ! \ "call prop_type_add('error', {'highlight': 'UnderlineProp'})",
> \ "call prop_add(1, 4, {'end_lnum': 3, 'end_col': 3, 'type': 'long'})",
> \ "call prop_add(2, 9, {'length': 3, 'type': 'number'})",
> \ "call prop_add(2, 24, {'length': 4, 'type': 'number'})",
> *** ../vim-8.1.2295/src/version.c 2019-11-12 22:33:32.089004066 +0100
> --- src/version.c 2019-11-12 22:41:08.140040889 +0100
> ***
> *** 743,744
> --- 743,746
> { /* Add new patch number below this line */
> + /**/
> + 2296,
> /**/
>
Marius Gedminas
--
> find /lib/modules/2.4.17-expt/kernel/ -type f|while read i; do insmod $i; done
You're sick. I like you.
-- Andrew Morton on lkml
--
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/20191113071334.4bzwecgwozvidg3r%40blynas.
signature.asc
Description: PGP signature
Re: How about sound?
On Thu, Jun 06, 2019 at 02:07:46PM +0200, Bram Moolenaar wrote:
> I tried a little example:
>
>
> #include
> #include
> int main () {
> ca_context * hello;
> ca_context_create (&hello);
> ca_context_play (hello, 0,
> CA_PROP_EVENT_ID, "phone-incoming-call",
> CA_PROP_EVENT_DESCRIPTION, "hello world",
> NULL);
> sleep(2);
> return 0;
> }
>
> gcc -o sound -D_REENTRANT -lcanberra sound.c
> /usr/bin/ld: /tmp/ccArSjRM.o: in function `main':
> sound.c:(.text+0x1f): undefined reference to `ca_context_create'
> /usr/bin/ld: sound.c:(.text+0x57): undefined reference to `ca_context_play'
> collect2: error: ld returned 1 exit status
>
> Somehow linking doesn't work, must be missing something...
This works:
gcc -o sound -D_REENTRANT sound.c -lcanberra
(At some point back in 2011 Ubuntu changed the linker defaults to use
--as-needed, which means the linker tries to drop unneeded libraries if
it doesn't see any object files using symbols from that library before
it encounters the name of the library. I don't really understand this;
but it caused everyone's build scripts to fail at the time, and the fix
was to move all the libraries to the end of the compiler command line.
It's documented in
https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition#Indirect_Linking_for_Shared_Libraries
but I don't understand a word on that page. I hope it's the right
page.)
Marius Gedminas
--
Perl is hard for most people to write. They write PERL or Pearl.
-- Abigail
--
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/20190606170546.b6y6ajnlocplfnsj%40platonas.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: PGP signature
Re: How about sound?
On Thu, Jun 06, 2019 at 11:59:34AM +0200, Bram Moolenaar wrote: > It appears libcanberra is widely available. My system also has the -dev > package installed (I didn't do that, perhaps because of a gtk > dependency). I could not find something for autoconf though. But I > expect it to be simple. On my system libcanberra-dev ships a pkg-config file, so it should be simple to hook it up to autoconf. $ pkg-config --libs libcanberra -lcanberra $ pkg-config --cflags libcanberra -D_REENTRANT (I've never used autoconf so I'm afraid I cannot offer a patch.) Marius Gedminas -- Be cheerful. Strive to be happy Oh, and we just set fire to your desktop. -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/20190606110546.mqurow4d4znvg4sa%40platonas. For more options, visit https://groups.google.com/d/optout. signature.asc Description: PGP signature
Re: generate desktop files from translations
On Thu, Apr 11, 2019 at 02:00:18PM +0200, Bram Moolenaar wrote: > Christian wrote: > > Bram, > > in issue 4222 (https://github.com/vim/vim/pull/4222) it was mentioned, > > that the desktop file translations could be generated at build time. So > > here is a patch, that adds this capabilities to the desktop files. ... > I have included this with patch 8.1.1147. Unfortunately CI fails: > > msgfmt: unrecognized option '--desktop' > > How do we work around that? Can we force-install a newer msgfmt > version? According to http://git.savannah.gnu.org/cgit/gettext.git/tree/NEWS, desktop file support was added in version 0.19. Currently vim's .travis.yml specifies dist: trusty Ubuntu 14.04 LTS (trusty) comes with gettext 0.18.3. Ubuntu 16.04 LTS (xenial) comes with gettext 0.19.7 so everything should work nicely if you change dist: to xenial. (This is best done in a branch so you can see if asking the CI to use a newer distro image breaks anything else.) HTH, Marius Gedminas -- TCP_SeqNum - The 32-bit Sequence Number, encoded as an ASCII string representing the hex value of the Sequence number. This field MUST be sent as lower case because it is not urgent. -- RFC 3093 -- -- 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: PGP signature
Re: Patch 8.1.0881
On Fri, Feb 08, 2019 at 02:34:26PM +0100, Bram Moolenaar wrote:
> Patch 8.1.0881
> Problem:Can execute shell commands in rvim through interfaces.
> Solution: Disable using interfaces in restricted mode. Allow for writing
> file with writefile(), histadd() and a few others.
> Files:runtime/doc/starting.txt, src/if_perl.xs, src/if_cmds.h,
> src/ex_cmds.c, src/ex_docmd.c, src/evalfunc.c,
> src/testdir/test_restricted.vim, src/testdir/Make_all.mak
>
>
> *** ../vim-8.1.0880/src/ex_docmd.c2019-01-31 18:26:05.734803539 +0100
> --- src/ex_docmd.c2019-02-08 13:21:20.959437381 +0100
> ***
> *** 2007,2017
> #ifdef HAVE_SANDBOX
> if (sandbox != 0 && !(ea.argt & SBOXOK))
> {
> ! /* Command not allowed in sandbox. */
> errormsg = _(e_sandbox);
> goto doend;
> }
> #endif
> if (!curbuf->b_p_ma && (ea.argt & MODIFY))
> {
> /* Command not allowed in non-'modifiable' buffer */
> --- 2007,2022
> #ifdef HAVE_SANDBOX
> if (sandbox != 0 && !(ea.argt & SBOXOK))
> {
> ! // Command not allowed in sandbox.
> errormsg = _(e_sandbox);
> goto doend;
> }
> #endif
> + if (restricted != 0 && (ea.argt & RESTRICT))
> + {
> + errormsg = _("E981: Command not allowed in rvim");
> + goto doend;
> + }
> if (!curbuf->b_p_ma && (ea.argt & MODIFY))
> {
> /* Command not allowed in non-'modifiable' buffer */
This causes a build failure:
ex_docmd.c: In function ‘do_one_cmd’:
ex_docmd.c:2015:36: error: ‘RESTRICT’ undeclared (first use in this function);
did you mean ‘RE_STRICT’?
if (restricted != 0 && (ea.argt & RESTRICT))
^~~~
RE_STRICT
ex_docmd.c:2015:36: note: each undeclared identifier is reported only once for
each function it appears in
make[1]: *** [Makefile:2988: objects/ex_docmd.o] Error 1
make[1]: *** Waiting for unfinished jobs
make[1]: Leaving directory '/home/mg/src/vim/src'
make: *** [Makefile:29: first] Error 2
git grep -w RESTRICT finds no other mentions of this name in the vim
codebase.
Marius Gedminas
--
The C language does not lend itself to providing all three of "safe," "simple,"
and "fast" in the same package.
-- Jonathan Corbet
--
--
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: PGP signature
Re: Patch 8.1.0709
On Wed, Jan 09, 2019 at 09:47:49PM +0100, Bram Moolenaar wrote: > Patch 8.1.0709 > Problem:Windows are updated for every added/deleted sign. > Solution: Do not call update_debug_sign(). Only redraw when the line with > the sign is visible. (idea from neovim #9479) > Files:src/sign.c, src/screen.c, src/proto/screen.pro Wow, this made placing multiple signs *much* faster! Marius Gedminas -- "In general, it is safe and legal to kill your children and their children" POSIX Prg Gt, by Donald Lewine, O'Reilly & Associates, 1991, p.110 (On process termination) -- http://lambda.weblogs.com/discuss/msgReader$7635?mode=day -- -- 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: PGP signature
Re: [vim/vim] Raise length limit for :set rtp? (#3466)
On Tue, Oct 30, 2018 at 08:41:05AM +0100, Christian Brabandt wrote: > On Mo, 29 Okt 2018, Bram Moolenaar wrote: > > Thanks. It would be helpful to add a few comments. E.g., why is the > > buffer size sufficient? I suppose because home_replace() can only make > > it shorter (is that actually true?). > > Yes, it was my understanding of the home_replace() function, that the > result can only be shorter (if it replaced anything, else the buffer > would not be modified). On some systems root's HOME is /. It would be a shame if home_replace replaced /foo with ~/foo, making it one character longer. I hope it's smart enough not to do that, but the actual C is too impenetrable for an amateur like me to understand. Marius Gedminas -- I want patience, and I WANT IT NOW! -- -- 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: PGP signature
Re: Patch 8.1.0030
On Sun, Jun 03, 2018 at 05:11:43PM +0200, Bram Moolenaar wrote:
> Patch 8.1.0030
> Problem:Stoping Vim running in a terminal may not work.
> Solution: Instead of sending send CTRL-O.
> *** ../vim-8.1.0029/src/testdir/screendump.vim2018-06-03
> 14:42:17.848505102 +0200
> --- src/testdir/screendump.vim2018-06-03 17:05:18.094429502 +0200
...
> --- 81,91
> " Stop a Vim running in terminal buffer "buf".
> func StopVimInTerminal(buf)
> call assert_equal("running", term_getstatus(a:buf))
> !
> ! " CTRL-O : works both in Normal mode and Insert mode to start a command
> line.
> ! " In Command-line it's inserted, the CTRL-U removes it again.
> ! call term_sendkeys(a:buf, "\\:qa!\")
Shouldn't this be \:\qa!\? In insert mode :qa!
will literally input :qa! into the buffer.
Marius Gedminas
--
"... one of the main causes of the fall of the Roman Empire was that,
lacking zero, they had no way to indicate successful termination of
their C programs."
-- Robert Firth
--
--
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: PGP signature
Re: Bug report: 'scrollbind' breaks when using mouse in xterm window
On Sat, May 19, 2018 at 09:23:07AM -0700, Jason Franklin wrote: > Now, use the mouse wheel to try and scroll in both windows. The window with > cursor focus will scroll both windows properly, but not the other window, > thus breaking the 'scrollbind' setting. This is intentional, to let you adjust the relative offset between the two windows. The 'scrollbind' option is not reset, and will be used (with the new relative offset) when you start scrolling the active window again. This is documented in :help scroll-binding When using the scrollbars, the binding only happens when scrolling the window with focus (where the cursor is). You can use this to avoid scroll-binding for a moment without resetting options. and again in :help scrollbind-quickadj The 'scrollbind' flag is meaningful when using keyboard commands to vertically scroll a window, and also meaningful when using the vertical scrollbar of the window which has the cursor focus. However, when using the vertical scrollbar of a window which doesn't have the cursor focus, 'scrollbind' is ignored. This allows quick adjustment of the relative offset of 'scrollbind' windows. Both places should probably be updated to also mention the mouse wheel. Marius Gedminas -- It is easier to optimize correct code than to correct optimized code. -- Bill Harlan -- -- 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: PGP signature
Re: Terminal close behavior
On Tue, Mar 13, 2018 at 01:56:03PM +0100, Bram Moolenaar wrote:
> Currently the :terminal command keeps the window open after the job
> exists. The idea is that you have a chance to see the job output, you
> might want to yank it. Closing the window automatically might mean you
> loose that text, there is no way to get it back.
>
> However, in practice I find that I mostly want the window to close as
> soon as the job finishes. So how about changing the default behavior?
>
> Currently:
> :terminal requires "exit:q" to close
> :terminal ++close requires "exit" to close
>
> With different default:
> :terminal requires "exit" to close
> :terminal ++noclose requires "exit:q" to close
>
> Good idea or bad idea?
Personally I like the current behavior.
I use vim's :terminal to run a couple of web servers (a Python one for a
web app backend, and a Node.js one for the app's frontend). These
autorestart when the source code on disk changes, but sometimes (e.g. when I
save a file during an unfinished refactoring) one of the servers
crashes. I like being able to see the error and to restart the command
in the same terminal window, for which I use a little user-defined
command:
command! TermRestart exec 'term ++curwin' expand("%")[1:]
Maybe an option would be better? Then people to select which one they
prefer in their vimrc, and they wouldn't have to repeat their preference
on every :terminal command?
Marius Gedminas
--
/*
* This function is about (re)setting the class of a held lock,
* yet we're not actually holding any locks. Naughty user!
*/
--
--
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: PGP signature
Re: How about a release?
On Fri, Mar 09, 2018 at 08:36:03AM -0500, David Fishburn wrote: > On Thu, Mar 8, 2018 at 5:16 PM, Christian Brabandt <[1]cbli...@256bit.org> > wrote: > > Oh and I think perhaps including the background make plugin would make > sense for a new release. > > I have been using Dispatch.vim (Tim Pope) for this: > [2]https://www.vim.org/scripts/script.php?script_id=4504 I've been using asyncrun.vim (https://github.com/skywind3000/asyncrun.vim). It's nice, but it also has some shortcomings (like if you do a :grep while a background program is running, the program's output gets appended to the wrong quickfix list). Marius Gedminas -- Apologies for taking up the bandwidth with the apology. Anything else I can apologise for .. er no can't think of anything, sorry about that. Andy Hunt (Member of British Olympic Apology Squad) -- -- 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: PGP signature
Re: Recent netrw.vim update very buggy
On Thu, Dec 14, 2017 at 08:12:49PM +0100, Bram Moolenaar wrote: > > Marius Gedminas wrote: > > > I git pull vim's master a few times a week to test the latest features. > > Unfortunately it has recently become painful to use due to netrw's bugs. > > I keep finding my options (like 'nohidden', but sometimes even 'readonly', > > 'nomodifiable' and 'buftype') blatantly changed behind my back, and > > :verbose set blames netrw. It also started using :lcd, which I cannot > > stand. > > > > Does netrw have a bug tracker of its own, or a public source repository? > > I was unable to find either :/ > > Are you sure it's netrw actually changing the values? It may just be > saving and restoring them. For :verbose that's still a change. That is a very good point! I'll investigate: For readonly/nomodifiable/buftype=nohidden, that happens when I hit 'gx' when the cursor is top of a URL. I can reproduce that with vim --clean +'runtime plugin/netrwPlugin.vim' For :lcd, I've an indicator in my statusline that shows when a window haslocaldir(), and this happens as soon as I use :Explore to switch to a different file. I can also reproduce this with vim --clean: 1. runtime plugin/netrwPlugin.vim 2. echo haslocaldir() " prints 0 3. Explore 4. select some file 5. echo haslocaldir() " prints 1 The 'hidden' option is also adjusted by :Explore. Steps to reproduce this with vim --clean: 1. runtime plugin/netrwPlugin.vim 2. set hidden 3. Explore 4. select some file 5. verbose set hidden? " prints nohidden Regards, Marius Gedminas -- Unix is an operating system, OS/2 is half an operating system, Windows is a shell, and DOS is a boot partition virus. -- Peter H. Coffin -- -- 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: PGP signature
Recent netrw.vim update very buggy
Hi! I git pull vim's master a few times a week to test the latest features. Unfortunately it has recently become painful to use due to netrw's bugs. I keep finding my options (like 'nohidden', but sometimes even 'readonly', 'nomodifiable' and 'buftype') blatantly changed behind my back, and :verbose set blames netrw. It also started using :lcd, which I cannot stand. Does netrw have a bug tracker of its own, or a public source repository? I was unable to find either :/ Marius Gedminas -- Theory is when you know something, but it doesn't work. Practice is when something works, but you don't know why. Programmers combine theory and practice: Nothing works and they don't know why. -- -- 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: PGP signature
Re: difference between submatch(1) and \1 intended?
On Fri, Nov 24, 2017 at 11:30:03AM +0100, Christian Brabandt wrote:
> Hi,
> while writing the test for checking the URLs I stumbled on this
> difference between submatch(1) and \1:
> #v+
> let a = 'https://www.vim.org '
> let g:pat = '.\{-}\(http[^ ]*\).\{-}$'
> echo substitute(a, g:pat, submatch(1), '')
> echo substitute(a, g:pat, '\1', '')
> #v-
>
> If you execute this piece of script, the first map() returns an empty
> list, while the second map() returns the URL stripped by whitespace
> (which would be my expected behaviour for both map() calls).
>
> Is this expected?
You're calling submatch(1) and then passing the returned value to substitute().
Try
echo substitute(a, g:pat, '\=submatch(1)', '')
or
echo substitute(a, g:pat, {m->submatch(1)}, '')
or
echo substitute(a, g:pat, {m->m[1]}, '')
Marius Gedminas
--
Initially, there were few or no postal regulations governing packages mailed
parcel post. To construct a bank in Vernal, Utah in 1916, a Salt Lake City
Company figured out that the cheapest way to send 40 tons of bricks to the
building was by Parcel Post. Each brick was individually wrapped & mailed.
Postal rules were promptly rewritten.
-- http://en.wikipedia.org/wiki/United_States_Postal_Service
--
--
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: PGP signature
Re: vim 7.3
On Sat, Oct 28, 2017 at 02:50:48AM +0200, Tony Mechelynck wrote:
> On Thu, Oct 26, 2017 at 7:19 PM, tooth pik wrote:
> > you don't use git?
> >
> No I don't, not for Vim anyway. Somehow I understand Mercurial but not
> git, so given a choice between them I always choose Mercurial. (For
> instance, does git have a specific function to list incoming
> changesets, other than "git pull --dry-run"? I like the "log-style"
> format of "hg incoming".)
I've a git alias `incoming` for this:
# ~/.gitconfig
[alias]
incoming = !git fetch && git log --oneline ..@{u}
(I do not remember what the format of `hg incoming` is.)
I also have another git alias, `new`, that shows me the contents of the
last pull after I've done it:
new = !sh -c 'git log $1@{1}..$1@{0} "$@"'
Regards,
Marius Gedminas
--
/*
* This function is about (re)setting the class of a held lock,
* yet we're not actually holding any locks. Naughty user!
*/
--
--
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: PGP signature
Re: '?12$p' shows at the first line, since Vim 8.0.1009
On Thu, Aug 31, 2017 at 12:36:21PM +0200, Dominique Pellé wrote: > Latest vim (8.0.1026) still outputs spurious characters > with xfce4-terminal on xubuntu-16.04 (xfce4-terminal 0.6.3). > I see this when starting vim: > > [?12$p > > Attached patch fixes it. > diff --git a/src/term.c b/src/term.c > index 4244892..8ec799e 100644 > --- a/src/term.c > +++ b/src/term.c > @@ -4562,10 +4562,11 @@ check_termcode( > && STRNCMP(tp + extra - 2, "1;95;0c", 7) == 0) > is_not_xterm = TRUE; > # endif > - /* Gnome Terminal.app sends 1;3801;0 or 1;4402;0, > - * assuming any version number over 3000 is not an > + /* Gnome Terminal.app sends 1;3801;0 or 1;4402;0. FWIW it's called GNOME Terminal with no ".app" suffix. When I see "Terminal.app", I always think Mac OS X. > + * xfce4-terminal sends 1;2802;0. > + * Assuming any version number over 2800 is not an >* xterm. */ > - if (col >= 3000) > + if (col >= 2800) > is_not_xterm = TRUE; > > /* Only request the cursor style if t_SH and t_RS are Marius Gedminas -- Hi. I'm the "I love you" .signature virus. You have been infected. Please panic immediately. -- -- 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: PGP signature
Re: '?12$p' shows at the first line, since Vim 8.0.1009
On Wed, Aug 30, 2017 at 01:59:28PM +0200, Christian Brabandt wrote:
> On Mi, 30 Aug 2017, Bram Moolenaar wrote:
> > I'm getting tired of those terminals that say they are xterm while they
> > are not...
>
> Understood. I still have this condition in my .vimrc:
>
> https://github.com/chrisbra/vim_dotfiles/blob/master/vimrc#L219-L222
>
> " gnome terminal sucks
> if (exists("$COLORTERM") && $COLORTERM is# 'gnome-terminal')
> set term=builtin_ansi
> set t_Co=256
> colorscheme molokai
> endif
>
> This is obviously only a workaround and I don't remember why I initially
> wrote this. This has been in one of my vimrcs for much longer than the
> git blame output would state. But I don't know what problem this
> initially worked around.
Note that this does nothing today since gnome-terminal stopped setting
$COLORTERM in 2014 (and then began setting COLORTERM=truecolor in 2016).
It also switched from using "xterm" as default $TERM value to
"xterm-256color", but you can override that with a ./configure
argument. I don't know if any distros do that; I'm pretty sure Ubuntu
doesn't.
Incidentally, libvte exports $VTE_VERSION, which could be used to detect
if you're running inside gnome-terminal or any other VTE-using terminal,
as long as you don't mind this detection breaking when sudo or ssh
strips the environment or when you run a screen/tmux, which intercepts
and interprets all the escape sequences.
Marius Gedminas
--
I doubt, therefore I might be.
--
--
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: PGP signature
Re: '?12$p' shows at the first line, since Vim 8.0.1009
On Wed, Aug 30, 2017 at 01:48:21PM +0200, Bram Moolenaar wrote:
> Marius Gedminas wrote:
> > libvte version is more relevant. On my system (GNOME Terminal 3.20.2,
> > VTE 0.44.2) printf '\033[?12$p' produces garbage on screen instead of
> > responding with the expected reply.
> >
> > But then again I can't find any trace of DECRQM handling in vte's git
> > master, so I'm surprised you don't see this problem.
>
> It is supposed to swallow any escape sequence starting with CSI and
> ending with a letter. Perhaps the "$" causes the problem.
Oh, interesting! I saw "Vte should ignore escape sequences it doesn't
about" in the open bug list[*] and assumed it didn't (yet). Also, my
experiments with
printf '\033[?12$p'
printf '\033[?12p'
printf '\033[12p'
show that it doesn't ignore any of those.
[*] https://bugzilla.gnome.org/show_bug.cgi?id=403130
> > I've filed a vte bug: https://bugzilla.gnome.org/show_bug.cgi?id=787007
> >
> > I've little hope of the fix (even if it's made) making its way into
> > Linux distros that are used today (e.g. latest upstream VTE is version
> > 0.49.1, while latest Ubuntu release is still on 0.44.2).
>
> I'm getting tired of those terminals that say they are xterm while they
> are not...
(I remember the pain of fixing the terminfo databases on all the remote
machines (including random Linux-based handheld PCs) so they would
understand my $TERM, and I understand why terminal emulators pretend to
be xterm.)
> My gnome-terminal reports this version: [>1;4402;0c
> What does yours say?
[>1;4402;0c
The 4402 part is computed from the VTE version number (major * 1 +
minor * 100 + patchlevel), thus 0.44.2 => 4402.
> Since a real xterm only has a version in the 300 range now, we could
> take a version >4000 as Gnome perhaps?
To be safer you could in addition check whether the terminal reports a
hardcoded icon label ("LTerminal") and title ("lTerminal") in response
to to CSI 20t and CSI 21t.
Ideally libvte upstream will implement the DECRQM.
Marius Gedminas
--
Users will less and less tolerate the risk of being attacked from anywhere in
the universe.
-- David Clark about network security, 1992
--
--
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: PGP signature
Re: '?12$p' shows at the first line, since Vim 8.0.1009
On Tue, Aug 29, 2017 at 08:18:59PM +0200, Bram Moolenaar wrote:
> Hirohito Higashi wrote:
>
> > Hi Bram and list,
> >
> > How to reproduce:
> > - Run vanilla Vim with specify the 'colorscheme' on terminal
> > $ vim -Nu NONE --cmd 'colorscheme desert'
> >
> > Then garbage('?12$p') at the first line. (See the attached file
> > "garbage_on_vim.png")
> >
> > NOTE:
> > It doesn't occur if you don't specify 'colorscheme' at .vimrc or --cmd.
> > I think patch 8.0.1009 is wrong.
> >
> > MY env.
> > OS: fedora 25
> > Terminal: GNOME terminal 3.22.1
> > (TERM=xterm-256color)
> > Vim:
> > configure option: --enable-gui=gnome2 --enable-terminal
> > --enable-fail-if-missing
> > version: 8.0.1010
>
> Gnome terminal can't handle a standard xterm escape sequence?
> The escape sequence is correct, it works fine on any xterm.
> I verified it correctly gets us the right cursor blink mode.
>
> I don't see this problem in a gnome-terminal on my system:
> GNOME Terminal 3.20.2
libvte version is more relevant. On my system (GNOME Terminal 3.20.2,
VTE 0.44.2) printf '\033[?12$p' produces garbage on screen instead of
responding with the expected reply.
But then again I can't find any trace of DECRQM handling in vte's git
master, so I'm surprised you don't see this problem.
I've filed a vte bug: https://bugzilla.gnome.org/show_bug.cgi?id=787007
I've little hope of the fix (even if it's made) making its way into
Linux distros that are used today (e.g. latest upstream VTE is version
0.49.1, while latest Ubuntu release is still on 0.44.2).
Marius Gedminas
--
Of course it is very important to support quitting emacs.
-- Bram Moolenar
--
--
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: PGP signature
Re: Cursor not visible in :terminal with TERM=xterm?
On Tue, Jul 25, 2017 at 10:10:23AM +0800, Nazri Ramliy wrote: > Cursor visible: > > TERM=ansi vi -u NONE -U NONE -c :terminal > > Cursor not visible: > > TERM=xterm vi -u NONE -U NONE -c :terminal > > help? I can reproduce (vim 8.0.771 running in gnome-terminal with TERM=xterm-256color). Note that when I first run :term bash, I can see the cursor -- but it disappears as soon as I start typing. Hitting Ctrl-W once makes the cursor re-appear and start blinking again. Marius Gedminas -- Any sufficiently advanced bug is indistinguishable from a feature. -- Rich Kulawiec -- -- 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: PGP signature
Re: "nnoremap g" trigger tag-searching on startup
On Sat, May 27, 2017 at 08:43:22PM -0700, Yubin Ruan wrote: > Hi, > > I have this mapping in my vimrc: > nnoremap g > which tells vim to jump to function definition rather than declaration when I > push . > > However, this setting will trigger a tag-searching behavior on startup. If > vim fails to find that tag file, it will throw errors like this: > E433: No Tag File > E426: tag not found, x > where ``x'' is current identifier under the cursor. The tricky thing is, > vim will automatically pre-push a `c' key for you, which means that if you > push `j' or `k' key after starting up vim it will effectively act as `cj' or > `ck' and you will delete a line accidentally, which is VERY VERY annoying I cannot reproduce with vim --noplugins -u test.vim test.vim where test.vim has just this one line nnoremap g I've vim 8.0.597. > I am using vim 8.0 Marius Gedminas -- Making software smarter is much easier than making people smarter. -- Matthew Paul Thomas -- -- 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: PGP signature
Filetype detection sometimes fails in recent vim
I'm on vim 8.0.597. I've recently noticed that sometimes when I open a file from the quickfix list I get it without syntax highlighting. The &filetype is blank, and :verbose set filetype? doesn't show it being set by any script. Re-opening the file with :e triggers filetype detection to run correctly. I haven't been able to figure out how to reproduce the issue. Has anyone else noticed this? Marius Gedminas -- Unix gives you enough rope to shoot yourself in the foot. -- -- 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: PGP signature
Re: Patch 8.0.0560
On Mon, Apr 10, 2017 at 09:47:02PM +0200, Bram Moolenaar wrote:
>
> Patch 8.0.0560
> Problem::windo allows for ! but it's not supported.
> Solution: Disallow passing !. (Hirohito Higashi)
> Files: src/ex_cmds.h
This looks like a different patch than the above description implies:
> diff --git a/src/tag.c b/src/tag.c
> index e2795b8..d6d1df2 100644
> --- a/src/tag.c
> +++ b/src/tag.c
> @@ -2355,18 +2355,19 @@ find_tags(
> }
> else
> {
> -#define TAG_SEP 0x01
> +#define TAG_SEP 0x02
> size_t tag_fname_len = STRLEN(tag_fname);
> #ifdef FEAT_EMACS_TAGS
> size_t ebuf_len = 0;
> #endif
>
> /* Save the tag in a buffer.
> - * Use 0x01 to separate fields (Can't use NUL, because the
> - * hash key is terminated by NUL).
> - * Emacs tag: <0x01><0x01>
> - * other tag: <0x01><0x01>
> - * without Emacs tags: <0x01>
> + * Use 0x02 to separate fields (Can't use NUL because the
> + * hash key is terminated by NUL, or Ctrl_A because that is
> + * part of some Emacs tag files -- see parse_tag_line).
> + * Emacs tag: <0x02><0x02>
> + * other tag: <0x02><0x02>
> + * without Emacs tags: <0x02>
>* Here is the "mtt" value plus 1 to avoid NUL.
>*/
> len = (int)tag_fname_len + (int)STRLEN(lbuf) + 3;
> diff --git a/src/testdir/test_taglist.vim b/src/testdir/test_taglist.vim
> index b89b25e..2d1557e 100644
> --- a/src/testdir/test_taglist.vim
> +++ b/src/testdir/test_taglist.vim
> @@ -19,3 +19,40 @@ func Test_taglist()
>bwipe
> endfunc
>
> +func Test_taglist_native_etags()
> + if !has('emacs_tags')
> +return
> + endif
> + call writefile([
> + \ "\x0c",
> + \ "src/os_unix.c,13491",
> + \ "set_signals(\x7f1335,32699",
> + \ "reset_signals(\x7f1407,34136",
> + \ ], 'Xtags')
> +
> + set tags=Xtags
> +
> + call assert_equal([['set_signals', '1335,32699'], ['reset_signals',
> '1407,34136']],
> + \ map(taglist('set_signals'), {i, v -> [v.name, v.cmd]}))
> +
> + call delete('Xtags')
> +endfunc
> +
> +func Test_taglist_ctags_etags()
> + if !has('emacs_tags')
> +return
> + endif
>
> --
> I'd like to meet the man who invented sex and see what he's working on now.
>
> /// 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.
Marius Gedminas
--
America and England are two countries separated by a common language.
--
--
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: PGP signature
Re: Building on Ubuntu with Python 3.6
On Wed, Mar 08, 2017 at 08:40:56PM +0100, Bram Moolenaar wrote:
> Recently there was a test failing specifically with Python 3.6.
> I tried installing it, but configure could not find it.
>
> For Python 3.5 the config directory is
> /usr/lib/python3.5/config-3.5m-x86_64-linux-gnu
> And it contains config.c. That is what configure checks for.
>
> For Python 3.6 the config directory should be
> /usr/lib/python3.6/config-3.6m-x86_64-linux-gnu
> However, it does not contain config.c (or any other relevant files).
>
> Perhaps I'm just missing a package. I don't have python3-dev installed,
> it's for Python 3.5 anyway.
You want python3.6-dev.
Note that Ubuntu 16.10 has a pre-release of Python 3.6. You can get the
final release from Felix Krull's PPA:
https://launchpad.net/~fkrull/+archive/ubuntu/deadsnakes
sudo add-apt-repository ppa:fkrull/deadsnakes
sudo apt-get update
sudo apt-get install python3.6-dev
HTH,
Marius Gedminas
--
Alan Turing thought about criteria to settle the question of whether
machines can think, a question of which we now know that it is about
as relevant as the question of whether submarines can swim.
-- Dijkstra
--
--
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: PGP signature
Re: conflicts with in windows console vim (vim.exe), bug ?
On Fri, Sep 23, 2016 at 12:41:56AM -0700, skywind3000 wrote: > Magnus Woldrich： > > >Thanks, very disappointted with cmd.exe > > > > Here you go: https://msys2.github.io/ > > After downloading msys2 and installing gcc, ncurses-devel ... with pacman, > I started to build latest vim inside msys2, and found these: > > checking for tgetent in -ltinfo... (cached) no > checking for tgetent in -lncurses... (cached) yes > ncurses library is not usable You need to figure out why that is (check config.log for clues). Alternatively, install Git for Windows and you get a nice set of tools that include bash, vim and a better console (mintty). The vim might be a bit feature-limited, though, so I understand your desire to build something newer. Marius Gedminas -- Never trust an operating system you don't have sources for. -- -- 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: PGP signature
Re: [patch] corrections in runtime/doc/version8.txt
On Sat, Sep 03, 2016 at 06:43:06AM +0200, Dominique Pellé wrote: > diff --git a/runtime/doc/version8.txt b/runtime/doc/version8.txt > index 61299fb..b7f7b3e 100644 > --- a/runtime/doc/version8.txt > +++ b/runtime/doc/version8.txt > @@ -6364,7 +6364,7 @@ Files: src/testdir/Make_dos.mak > > Patch 7.4.995 > Problem:gdk_pixbuf_new_from_inline() is deprecated. > -Solution: Generate auto/gui_gtk_gresources.c. (Kazunobu Kazunobu, > +Solution: Generate auto/gui_gtk_gresources.c. (Kazunobu Kuriyama), I don't think you want to close the parenthesis here > closes #507) > Files: src/Makefile, src/auto/configure, src/config.h.in, > src/config.mk.in, src/configure.in, src/gui_gtk.c, Marius Gedminas -- There are 10 kinds of people in the world: Those who understand binary mathematics and those who don't. -- -- 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: PGP signature
Re: vim is compiled without python support
On Sat, Aug 20, 2016 at 01:44:05PM -0700, Adam Russell wrote:
> i compile vim from source on a daily basis, lately i encounter an issue, when
> vim is not compiled with python support.
>
> $ vim --version
> ...
> +python/dyn
> +python3/dyn
> ...
Is this your self-compiled vim you say isn't compiled with Python
support???
> The build process i follow, is this one
> https://github.com/Valloric/YouCompleteMe/wiki/Building-Vim-from-source
>
> i do set python configuration directory for both (python2.7 and python) like
> so:
>
> $ ./configure --with-features=huge \
> --enable-multibyte \
> --enable-rubyinterp \
> --enable-pythoninterp\
>
> --with-python-config-dir=/usr/lib/python2.7/config-i386-linux-gnu \
> --enable-python3interp \
>
> --with-python3-config-dir=/usr/lib/python3.5/config-3.5m-i386-linux-gnu
> \
> --enable-perlinterp \
> --enable-luainterp \
> --enable-gui=gtk2 \
> --enable-cscope \
> --prefix=/usr
Do the directories you mention here actually exist? E.g. my laptop
doesn't have a /usr/lib/python2.7/config-i386-linux-gnu because it's a
64-bit machine and the Pthon config directory is called
/usr/lib/python2.7/config-x86_64-linux-gnu
> i'am using linux, python-dev and python3-dev are installed,
>
> :echo has('python') return 0
Marius Gedminas
--
The last good thing written in C was Franz Schubert's Symphony #9.
-- Erwin Dietrich
--
--
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: PGP signature
Re: problems with git and maintaining files
On Fri, Aug 19, 2016 at 04:56:34PM -0400, Charles E Campbell wrote: > Charles E Campbell wrote: > > Christ van Willegen wrote: > >> Op 19 aug. 2016 22:28 schreef "Charles E Campbell" > >> mailto:drc...@campbellfamily.biz>>: > >>> I tried git stash push instead of git push -- and it still doesn't work: > >> Probably only 'stash' then... > >> > > That doesn't work either, unfortunately: > > > > runtime/syntax/sh.vim: needs merge > > runtime/syntax/sh.vim: needs merge > > runtime/syntax/sh.vim: unmerged (711971ea4ae7b3a72c2062c18130b3eca35dc67b) > > runtime/syntax/sh.vim: unmerged (34b8ab79e45bb1f39827e940e4b3428bedfad64b) > > runtime/syntax/sh.vim: unmerged (b285b04979551b260ab016ba089d9e69ded01612) > > fatal: git-write-tree: error building trees > > Cannot save the current index state > > Mruntime/doc/syntax.txt > > Uruntime/syntax/sh.vim > > Pull is not possible because you have unmerged files. > > Please, fix them up in the work tree, and then use 'git add/rm ' > > as appropriate to mark resolution, or use 'git commit -a'. > > runtime/syntax/sh.vim: needs merge > > Cannot apply to a dirty working tree, please stage your changes > > > Oh, well -- I tried several things based on web searches, and none of > them worked. I just went ahead and did what I know does work -- save > off the affected files manually, wipe out the local copy, git clone > https://github.com/vim/vim.git, and manually copy the affected files > back to where they needed to be. An entire full clone must be painful. A simpler solution that doesn't rely on any advanced git mastery would be mv runtime/syntax/sh.vim runtime/syntax/sh.vim.mine # for each file git checkout . # restore pristine upstream versions of every file git pull mv runtime/syntax/sh.vim.mine runtime/syntax/sh.vim # for each file HTH, Marius Gedminas -- To err is human, but to really foul things up requires a computer. -- -- 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: PGP signature
Re: [vim/vim] E575: viminfo: Illegal starting char in line (#870)
On Thu, Jun 16, 2016 at 12:53:43AM -0700, Marius Gedminas wrote: > git bisect blames commit a890f5e34887bff7616bdb4b9ee0bf98c8d2a8f0 for this Please ignore this message, I messed up git bisect somehow (twice). Patch 7.4.1919 introduces this. Marius Gedminas -- Why when I was a kid, we had to defragment all our data structures. Had to know all the ins and outs of which data types aligned to what word size to minimize memory usage. Uphill both ways. -- Mike Barton -- -- 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: PGP signature
Re: Any way to scroll quickfix window automatically for long-time-running jobs ?
On Wed, Jun 08, 2016 at 10:33:55PM +0200, Christian Brabandt wrote: > Hi skywind3000! > > On Do, 09 Jun 2016, skywind3...@163.com wrote: > > > ":cbottom" seems more adaptive than auto scroll > > Why? I think it has been shown, that depending on the use case auto > scroll does not make sense always. So it's not that hard, to simply > scroll manually, whenever you need. I am not sure, an extra :cbottom > command is really needed, but I am not against it. How about a compromise: any build/grep/etc. plugin that adds new lines to the end of the quickfix should autoscroll if and only the bottom line was already visible. This way if the user switched to the quickfix window and started studying the 1st error or whatnot, they won't be distracted by autoscrolling. And if the user just wants to see how the build is progressing, they don't need to do anything special. Now implementation-wise maybe it's best to have a way for vimscript to determine if the bottom quickfix row is visible or not, before adding new lines, and then the script can call the suggested :cbottom depending on the saved result. Marius Gedminas -- UNIX is user friendly. It's just selective about who its friends are. -- -- 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: PGP signature
Re: Windows: After Patch 7.4.1792 colors completely wrong
On Tue, Apr 26, 2016 at 02:48:48PM -0600, Christian J. Robinson wrote: > > Something went wrong with this patch. Most of my colors are wrong. > > How it looks now: > https://www.dropbox.com/s/q8wc4vzkg8r0uj2/vimwrongcolors.png?dl=0 > > How it should look: > https://www.dropbox.com/s/3of53y3qdiz1xcm/vimcorrectcolors.png?dl=0 Does 7.4.1795 fix this? Marius Gedminas -- Just to be extra clear about this: yes, it is morally wrong for us to have written RetchMail, and it is morally wrong for you to use it. But try it, it's really fast! -- http://alumnit.ca/wiki/index.php?page=RetchMail -- -- 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: PGP signature
Re: gD broken in 7.4.1743
On Fri, Apr 15, 2016 at 03:11:20PM -0700, Gary Johnson wrote: > Is it expected or desired that gD is affected by 'ignorecase'? Case-insensitive languages exist, so I suppose it makes sense for gd/gD to pay attention to 'ignorecase'. :help says gd/gD work the same as * (except for skipping comments), and :help * says that it pays attention to 'ignorecase' (but not 'smartcase'). Regards, Marius Gedminas -- "Learning Perl" is actually a very well-written book for beginning programmers. The only thing wrong with it is it's about Perl... -- Paul Rubin -- -- 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: Dynamic python bindings and "undefined symbol" error
On Wed, Apr 06, 2016 at 09:07:32AM -0700, 'Anatol Pomazau' via vim_dev wrote:
> Here is a followup for this discussion at Arch Linux forum
> https://bbs.archlinux.org/viewtopic.php?id=210968
>
> Arch recently switched to dynamic language bindings to support both
> python2 and python3 by the same package. It works great except a few
> use-cases. It turned out that some python packages (like python-dbus)
> do not link their packages to python shared library:
>
> $ ldd /usr/lib/python2.7/site-packages/_dbus_bindings.so | grep python
> # compare it to yaml library:
> $ ldd /usr/lib/python2.7/site-packages/_yaml.so | grep python
> libpython2.7.so.1.0 => /usr/lib/libpython2.7.so.1.0 (0x7ffa53d88000)
>
> I am not a python guru and not sure why it is done. Does anybody know why it
> is not linked to libpython2.7.so?
This thread on Python's distutils-sig@ may be relevant:
https://mail.python.org/pipermail/distutils-sig/2016-February/028275.html
> But this enough for vim to crash when this package is loading:
>
> :py import dbus
> Traceback (most recent call last):
> File "", line 1, in
> File "/usr/lib/python2.7/site-packages/dbus/__init__.py", line 77, in
>
> import dbus.types as types
> File "/usr/lib/python2.7/site-packages/dbus/types.py", line 6, in
> from _dbus_bindings import (
> ImportError: /usr/lib/python2.7/site-packages/_dbus_bindings.so: undefined
> symbol: PyExc_KeyboardInterrupt
Ouch.
> This behavior is different from static language bindings where (it
> seems) python libraries are loaded into namespace by vim itself.
>
> What is the right way to resolve it? Should vim preload python
> libraries when the language binding is used? Or all python libraries
> should be linked to libpython2.7.so?
Perhaps if vim used RTLD_GLOBAL when dlopen'ing libpython that would
make things work? Apparently that's the workaround that mod_wsgi uses
to fix this exact situation, if I correctly understood
https://mail.python.org/pipermail/distutils-sig/2016-February/028286.html
:h if_pyth.txt describes what to do to try that (undefine
PY_NO_RTLD_GLOBAL in auto/config.h after running ./configure), and what
the downsides are ("may crash Vim", if you attempt to use both :py and
:py3 in the same vim seession).
Marius Gedminas
--
Every nonempty totally-disconnected perfect compact metric space is
homeomorphic to the Cantor set.
--
--
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: [patch] Fix quickfix handling of long lines
On Mon, Apr 04, 2016 at 10:03:22PM +0200, Bram Moolenaar wrote: > > Anton Lindqvist wrote: > > > If a file passed to the 'qf_init_ext' function contains lines longer > > than 1021 bytes (might be platform specific) the rest of the line is > > recognized as a separate error without a valid filename and lnum. If a > > string or list is passed to 'qf_init_ext' the rest of a long line is > > discarded. This patch adds the same behavior while reading errors from a > > file. This is done by continue reading from the file in to a temporary > > buffer until end-of-line is encountered. Could any existing general > > purpose buffer with a known size be used instead of allocation a new > > one? > > This code comes from when memory was scarce and error messages were > short. Using a fixed size buffer isn't so nice these days. > > A good strategy could be to use IObuff as it is, and when an error > message is longer then allocate a larger buffer and append to it. > It does require growing (doubling?) the buffer further until a NL is > found. That can be slow, e.g. if the error file has no NL at all > (that's a mistake, but you don't want Vim to hang then). So some upper > limit would still be useful. > > I have seen error messages from a test that say "expected > but got ". I've seen C++ error messages longer than 1024 characters thanks to the wonder that is templates. The other case where I've seen very long wrapped lines in quickfix is when a recursive grep finds a match in a minified Javascript file. > Not sure what a useful upper limit would be. 100 Kbyte perhaps? I've a jquery.min.js of an uncertain version at 94 KB. I see a few minified JS files on my disk weighing more (one seems to be 1.4 megs, ouch!). At some point maybe it seems reasonable to just truncate the remainder of the quickfix line? Marius Gedminas -- Bumper sticker: No radio - Already stolen. -- -- 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: set default fileformat with empty first buffer
On Sun, Mar 20, 2016 at 08:46:23AM +, Mike Williams wrote: > I noticed a problem with the fileformats option not being applied to the > initial buffer when VIM is started without any initial buffer content. I > mainly work on Windows and have fileformats=unix,dos so the default file > format to be unix line-endings. However VIM on Windows starts new empty > initial buffers with dos line-endings but if I start a new buffer with :new > or :e with the name of file that did not exist then the fileformat is set to > unix line-endings. The help says this about 'fileformats': Note that when Vim starts up with an empty buffer this option is not used. Set 'fileformat' in your .vimrc instead. > The following patch applies fileformats to the initial buffer created by > VIM. I have been using it for the last 9 months without any obvious issues. > I have tested a couple of ways of feeding data into the initial buffer (such > as C:> dir | vim -) and it does what I would expect. So can anyone see any > issues with this patch? If you're changing the behavior, you should probably also change the help text to match. Regards, Marius Gedminas -- Photons have energy, and trying to cram too many into too small of a space can cause a black hole to form, which is, needless to say, not a desirable trait for an optical computer. -- http://scottaaronson.com/blog/?p=261#comment-13693 -- -- 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: [Patch] GTK3 GUI
On Fri, Feb 19, 2016 at 11:11:45PM +0900, Kazunobu Kuriyama wrote:
> 2016-02-19 22:37 GMT+09:00 Marius Gedminas :
>
> > I use Adwaita, which is the default GNOME 3 theme (and I think also the
> > default GTK+ 3 theme).
>
> Hmm. Then the theme has nothing to do with the border draw. And Vim
> contains no code for drawing border or specifying the drawing area offset
> to the parent GtkForm.
> Do you use other applications which use GtkDrawingArea and draw the border?
I've no idea. :-)
I suspect this is something similar to
https://bugzilla.gnome.org/show_bug.cgi?id=733027: the widget doesn't
draw the background explicitly, so you end up with something undefined.
> > The usual keys (Ctrl+Shift+I/Ctrl+Shift+D) do not open the GTK+
> > inspector in gvim.
> >
> > Curiously: if I run 'GTK_DEBUG=interactive gvim' and then right-click,
> > the border does not turn black.
>
> Did you mean the GTK+ of your system was somehow unstable, or gvim didn't
> behave like other GTK+ apps?
Are you familiar with the GTK+ inspector? There's a setting that
enables hot keys for it: https://wiki.gnome.org/Projects/GTK%2B/Inspector
I've that setting enabled. Usually this means Ctrl+Shift+I or
Ctrl+Shift+D in any GTK+ app will invoke the inspector, but individual
apps can override these key bindings. E.g. Nautilus uses Ctrl+Shift+I
to invert the selection, so only Ctrl+Shift+D works to toggle the
Inspector window.
What I'm saying is that Vim takes over both shortcuts so the only way to
get to the GTK+ inspector is to use the GTK_DEBUG environment variable.
This is not a problem, just an observation.
About the "does not turn black on right-click" thing -- I found that if
I go to the Style tab in the Inspector and switch themes, the border
becomes black: http://imgur.com/M0MhBQl
> > Anyway, I've now realized that the GTK+ inspector apparently doesn't
> > show the CSS rules that come from the theme, and I'm not quite sure
> > where to check what.
>
> OK, you mean you are using GTK+ with the default settings and haven't done
> anything with files in $HOME/.config/gtk-3.0, right?
Right:
mg@platonas: ~ $ cat ~/.config/gtk-3.0/settings.ini
[Settings]
gtk-application-prefer-dark-theme=0
> To make sure, could you try the following program and check how it responds
> against a right click on the drawing area window?
>
> /*
> * main.c - drawing area test program
> *
> * To compile: gcc `pkg-config --cflags --libs gtk+-3.0` main.c
This fails with link errors due to Debian/Ubuntu default linker flags
(--as-needed):
https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-Wl.2C--as-needed
I can compile with
gcc main.c `pkg-config --cflags --libs gtk+-3.0`
> */
>
> #include
>
> int main(int argc, char *argv[])
> {
> GtkWidget *window;
> GtkWidget *da;
> gtk_init(&argc, &argv);
> window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
> g_signal_connect(window, "destroy", G_CALLBACK(gtk_main_quit), NULL);
> da = gtk_drawing_area_new();
> gtk_container_add(GTK_CONTAINER(window), da);
> gtk_widget_show_all(window);
> gtk_main();
> return 0;
> }
No strange color-changing borders appear with this example.
I've played a bit more with the GTK+ inspector. The border that changes
the color comes from the GdkDrawingArea: http://imgur.com/a/zgDJY
It's exactly 2 pixels wide: http://imgur.com/qWauoUd
Marius Gedminas
--
My mail reader can beat up your mail reader.
--
--
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: [Patch] GTK3 GUI
On Fri, Feb 19, 2016 at 09:51:18PM +0900, Kazunobu Kuriyama wrote: > Thank you all. > > I owe much to you for making a thing usable on Linux out of a series of > zipped garbage:) > > Marius Gedminas, you always kindly wrote detailed reports with informative > pictures. Not only that, I remember your interesting, useful script, too. > You’ve kept my eyes open to what I was unable to see by myself. I’d like > to dedicate the diff between the latest and the first patch to you :) > > SungHyun Nam, your comment was the only one that witnessed my patches were > usable. I cannot describe how much your comment has been encouraging me :) > > Christian Brabandt, I believe, since you’ve joined this thread, the > momentum of the development has been kept; otherwise, my attempt would be > abandoned with the failed patches :) > > As Marius reported, there may still be (no, must be) unresolved issues > unknown to us. So, someone who finds anything wrong with this GTK+ 3 GUI, > please let us know. > > Marius, I’m preparing a patch to resolve the issue you reported, but cannot > do that in hours. Till then, could you please check what the CSS > parameters for GtkDrawingArea are in the GTK+ theme you use? I use Adwaita, which is the default GNOME 3 theme (and I think also the default GTK+ 3 theme). The usual keys (Ctrl+Shift+I/Ctrl+Shift+D) do not open the GTK+ inspector in gvim. Curiously: if I run 'GTK_DEBUG=interactive gvim' and then right-click, the border does not turn black. Anyway, I've now realized that the GTK+ inspector apparently doesn't show the CSS rules that come from the theme, and I'm not quite sure where to check what. Marius Gedminas -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- Avi Kivity -- -- 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: [Patch] GTK3 GUI
On Thu, Feb 18, 2016 at 08:57:07PM +0900, Kazunobu Kuriyama wrote: > Patch updated, made against v7.4.1345. > > With this patch, I addressed the cursor issue, aiming at smooth cursor draw > and low cpu usage. > > Hopefully, this resolves all the known issues since the first patch was > posted, and eventually allows us to go further to address other unknown > issues. Yes, all the former issues seem to be completely gone! > If you find an issue, it would be very helpful if you could report it with > the result of `vim -g -u NONE`, just like other bug reports. I found one very minor new issue. Here's gvim -u NONE -U NONE: http://i.imgur.com/wddWGCV.png And then I right-click anywhere in the window and the grey border becomes black: http://i.imgur.com/GndHZyA.png On Fri, Feb 19, 2016 at 12:15:41AM +0900, Kazunobu Kuriyama wrote: > Oh, I forgot one thing to note. > > If you find the cursor disappears while keeping holding down the keys j or > k, add The cursor doesn't disappear while I hold down h/j/k/l. I tried both my .vimrc and gvim -u NONE -U NONE. Marius Gedminas -- Only great masters of style can succeed in being obtuse. -- Oscar Wilde Most UNIX programmers are great masters of style. -- The Unnamed Usenetter -- -- 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: [Patch] GTK3 GUI
On Wed, Feb 17, 2016 at 05:32:38PM +0900, Kazunobu Kuriyama wrote: > Thank you for giving a try. > > The cursor issue you've just pointed out is rather expected results and I > know the cause. > > That said, I can't put my hands on the cursor issue till the redraw issue > is resolved. > > The Vim core draws text and cursor(s) simultaneously. > > But that drawing model don't work cleanly with GUI; because of GUI's > asynchronicity and double buffering mechanism, the place where the cursor > appears is often different from that the Vim core puts. > > The cursor issue is a result of a brutally forced synchronization. > > Any other problems on redrawing? If you all don't see much problem on > that, and say OK to me, I can go and fix the cursor issue. I was unable to trigger any other redrawing problems. One curious thing: when I press Ctrl-L to redraw (especially if I hold it down to cause continuous redraws), the vim window flashes white before being redrawn. I'd hope that with GTK+'s double-buffering only the finished image would be actually shown on screen? But that's a quality of implementation issue, not a bug, and perhaps too difficult to do right with vim's generic architecture? Regards, Marius Gedminas -- In fact, liking [C++] is a strong indicator that you're not an expert in it. -- ssylvan on reddit -- -- 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: [Patch] GTK3 GUI
On Mon, Feb 15, 2016 at 05:05:39PM +0900, Kazunobu Kuriyama wrote: > Thank you for the comment. > > To me, the cursor draw issue is another side of the redraw issue; one issue > is tried to be fixed, another manifests then :) > > To fix those two issues simultaneously and make the code portable, I wrote > another patch in such a way that no assumption was made on what had already > been drawn on the cairo surface. It may be inefficient but looks surer of > redraw. > > While the complexity of the draw event function increases, I wish it will > work on Linux. > > Please try it at your convenient time. > > The patch was made against v7.4.1320, some merge conflicts resolved. Applied it on top of 7.4.1342. Everything works fine, except the cursor disappears rather quickly after any motion and never reappears. Could be related to my .vimrc having set guicursor+=a:blinkon0 Indeed, if I :set guicursor&, the cursor blinks almost normally -- except the very first blink is somehow different. It's hard to describe in words. The cursor stays on for too long before disappearing for the first time. Regards, Marius Gedminas -- QOTD: "A child of 5 could understand this! Fetch me a child of 5." -- -- 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: [Patch] GTK3 GUI
On Sun, Feb 14, 2016 at 05:01:22PM +0900, Kazunobu Kuriyama wrote: > Hmm... > > Looks Linux X11 or GTK works differently from that for OS X. It must be hard trying to fix something when you cannot reproduce a problem. Have you tried running Linux in a virtual machine? > Could you please change a cpp directive from #if 0 to #if 1 at > gui_gtk_x11.c:633, although that causes logically unnecessary redraws? The screen gets redrawn *mostly* correctly after a PageDown with this change. Here are three screenshots: http://imgur.com/a/NImWI 1. after :help 2. after 3. after > What happens to cursor(s)? Does the GUI clears cursors on unused windows? No -- the cursor remains on the inactive window, and also on the command line. The cursor blinking in the active window is also broken: when I switch to a window (or move the cursor) the cursor is briefly visible, then it blinks out of existence and doesn't reappear until I move the cursor again. My .vimrc has this line: set guicursor+=a:blinkon0 " disable cursor blinking ever since my redraw call logging experiments, so the cursor shouldn't be blinking at all. Once, I did :set lines=24 columns=80 and the entire window was solid grey until I forced a redraw with Ctrl-L. I can no longer reproduce that intentionally. It's as if some kind of double-buffering going on, and gvim is *sometimes* drawing into the wrong buffer, due to a race condition or something. On Sun, Feb 14, 2016 at 05:20:57PM +0900, Kazunobu Kuriyama wrote: > By the way, how about your resurrected icons? > > It looks to me that they appear on the toolbar, right? Yes. Regards, Marius Gedminas -- One picture is worth 128K words. -- -- 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: [Patch] GTK3 GUI
On Sun, Feb 14, 2016 at 03:54:46PM +0900, Kazunobu Kuriyama wrote: > 2016-02-14 14:38 GMT+09:00 Kazunobu Kuriyama : > > > Hi, Christian > > > > Oops, one more thing to fix. > > Please replace the previous patch with this one: I'm afraid this one suffers from the redraw problem: http://imgur.com/a/u5Ovi Apologies for not finding the time to test your earlier patches. Regards, Marius Gedminas -- Two Ineluctable Facts of Project Planning: 1. If you don’t know what you’re going to build, you can’t know how long it will take to build it. 2. You only really know what you’re going to build when you finish it. -- -- 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: Channel & job design
On Tue, Feb 09, 2016 at 10:24:55PM +0200, LCD 47 wrote: > > - A socket (what ch_open() currently does) > > - A pipe (only possible with an associated job) connected to > > stdin/stdout/stderr. > > There are also UNIX domain sockets (a.k.a. named pipes), which you > get essentially for free once you have the code for INET sockets. They > are as efficient as (unnamed) pipes. Nitpick: Unix domain sockets and named pipes (aka FIFOs) are two different concepts. http://linux.die.net/man/7/unix http://linux.die.net/man/4/fifo Marius Gedminas -- IBM motto: "If you can't read our assembly language, you must be borderline dyslexic, and we don't want you to mess with it anyway" -- Linus Torvalds -- -- 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: [Patch] GTK3 GUI
On Fri, Feb 05, 2016 at 08:17:29PM +0900, Kazunobu Kuriyama wrote: > This is a revised patch, using a single surface. > > It was made against v7.4.1261. > > Marius, does it work for you? No :( That is, it builds fine, but scrolling with PageDown leaves the usual mess. Regards, Marius Gedminas -- Ambition is a poor excuse for not having enough sense to be lazy. -- -- 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: [Patch] GTK3 GUI
On Thu, Feb 04, 2016 at 12:55:56PM +0200, Marius Gedminas wrote: > On Thu, Feb 04, 2016 at 12:33:37PM +0200, Marius Gedminas wrote: > > On Thu, Feb 04, 2016 at 12:06:57PM +0200, Marius Gedminas wrote: > > > The 'clearing ... 149 cells' messages in the log prove that this bit of > > > code > > > > > > set_cairo_source_rgb_from_pixel(cr, gui.bgcolor->pixel); > > > cairo_rectangle(cr, > > > FILL_X(col), FILL_Y(row), > > > num_cells * gui.char_width, gui.char_height); > > > cairo_fill(cr); > > > > > > was executed, so it remains to be discovered why it didn't clear > > > anything. Was there an active clipping rectangle? Was bgcolor->pixel > > > wrong? I'll try to add more debugging printfs(). > <...> > > Everything seems correct, so I've no idea why cairo isn't clearing that > > area :( > > I turned to IRC for help (#gnome-hackers on irc.gnome.org), and this is > the advice I received: > >mgedmin: Stop using gdk_cairo_create() and instead use the >cairo_t that GtkWidget::draw gives you >mgedmin: If you want to draw outside of the drawing code, >then create a surface using >gdk_window_create_similar_surface() or >gdk_window_create_similar_image_surface(), and draw on it; >then, inside the ::draw vfunc, use the surface as the source >on the cairo_t provided you by GtkWidget Summarizing some further conversation: * GTK+ apps are supposed to do the drawing only from expose event callbacks (or the "draw" signal of the widget, I suppose). * If you need to draw at some other time, use gdk_window_invalidate_rect() to tell GTK+ that redrawing is needed, and you'll get an expose event. Perhaps the generic gui_redraw/gui_redraw_block() can be changed to call gdk_window_invalidate_rect(), and the draw_event() callback can be changed to do the drawing directly instead of calling gui_redraw()? Because otherwise I don't see how to pass the cairo context passed to draw_event() through the generic gui_redraw() code into internal drawing functions. Marius Gedminas -- Bumper sticker: No radio - Already stolen. -- -- 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: [Patch] GTK3 GUI
On Thu, Feb 04, 2016 at 12:33:37PM +0200, Marius Gedminas wrote: > On Thu, Feb 04, 2016 at 12:06:57PM +0200, Marius Gedminas wrote: > > The 'clearing ... 149 cells' messages in the log prove that this bit of code > > > > set_cairo_source_rgb_from_pixel(cr, gui.bgcolor->pixel); > > cairo_rectangle(cr, > > FILL_X(col), FILL_Y(row), > > num_cells * gui.char_width, gui.char_height); > > cairo_fill(cr); > > > > was executed, so it remains to be discovered why it didn't clear > > anything. Was there an active clipping rectangle? Was bgcolor->pixel > > wrong? I'll try to add more debugging printfs(). <...> > Everything seems correct, so I've no idea why cairo isn't clearing that > area :( I turned to IRC for help (#gnome-hackers on irc.gnome.org), and this is the advice I received: mgedmin: Stop using gdk_cairo_create() and instead use the cairo_t that GtkWidget::draw gives you mgedmin: If you want to draw outside of the drawing code, then create a surface using gdk_window_create_similar_surface() or gdk_window_create_similar_image_surface(), and draw on it; then, inside the ::draw vfunc, use the surface as the source on the cairo_t provided you by GtkWidget Regards, Marius Gedminas -- Being really good at C++ is like being really good at using rocks to sharpen sticks. -- Thant Tessman -- -- 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: [Patch] GTK3 GUI
On Thu, Feb 04, 2016 at 12:06:57PM +0200, Marius Gedminas wrote:
> The 'clearing ... 149 cells' messages in the log prove that this bit of code
>
> set_cairo_source_rgb_from_pixel(cr, gui.bgcolor->pixel);
> cairo_rectangle(cr,
> FILL_X(col), FILL_Y(row),
> num_cells * gui.char_width, gui.char_height);
> cairo_fill(cr);
>
> was executed, so it remains to be discovered why it didn't clear
> anything. Was there an active clipping rectangle? Was bgcolor->pixel
> wrong? I'll try to add more debugging printfs().
CODE:
cr = gdk_cairo_create(gtk_widget_get_window(gui.drawarea));
cairo_rectangle(cr, area.x, area.y, area.width, area.height);
cairo_clip(cr);
printf("clip area: %dx%d+%d+%d\n", area.width, area.height, area.x, area.y);
DEBUG OUTPUT:
clip area: 1341x18+2+218
CODE:
printf("clearing(%d,%d): %d cells in %08x\n", row, col,
num_cells, gui.bgcolor->pixel);
set_cairo_source_rgb_from_pixel(cr, gui.bgcolor->pixel);
cairo_set_line_width(cr, 1.0);
cairo_rectangle(cr,
FILL_X(col), FILL_Y(row),
num_cells * gui.char_width, gui.char_height);
printf("cairo_rectangle: %dx%d+%d+%d\n", num_cells * gui.char_width,
gui.char_height, FILL_X(col), FILL_Y(row));
cairo_fill(cr);
DEBUG OUTPUT:
clearing(12,0): 149 cells in 00ff
cairo_rectangle: 1341x18+2+218
Everything seems correct, so I've no idea why cairo isn't clearing that
area :(
I've got libcairo 1.14.2-2ubuntu2 from Ubuntu 15.10.
Regards,
Marius Gedminas
--
Any sufficiently advanced bug is indistinguishable from a feature.
-- Rich Kulawiec
--
--
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: [Patch] GTK3 GUI
On Thu, Feb 04, 2016 at 01:00:59AM +0900, Kazunobu Kuriyama wrote: > 2016-02-03 23:59 GMT+09:00 Marius Gedminas : > > On Wed, Feb 03, 2016 at 11:10:22PM +0900, Kazunobu Kuriyama wrote: > > > Looking at the pictures you kindly uploaded, I can see what is cleared by > > > vim still remains on the screen. It's just like as if clear window/block > > > clear operations were intentionally skipped > > > > But not all of them -- just some character cells! And only when > > scrolling forwards -- hitting PageUp redraws the screen correctly! > > > > It's as if clearing works, but outputting "text with spaces" skips > > clearing the background behind each space character. > > > > This additional info is quite helpful, from which we know where to start. > > While there're several issues we have to solve, let's focus on the "scroll > forward" issue for now. It's easier to attack than the visual quarks, that > is, vague enemies like ghosts :) I've patched vim to log all calls to gui_gtk2_draw_string() and wrote a small Python script to visualize the draw calls using ncurses. Here's a screencast: https://asciinema.org/a/35507 The interesting part starts at about second 35: when I press PageDown, vim clears the window by drawing a lot of spaces: Drawing a string at (2,0): ' ' clearing(2,0): 149 cells Drawing a string at (3,0): ' ' clearing(3,0): 149 cells ... Drawing a string at (19,0): ' ' clearing(19,0): 149 cells and then it draws additional help text -- just words -- on top of the cleared area: Drawing a string at (2,22): 'Visual' clearing(2,22): 6 cells Drawing a string at (2,29): 'mode' clearing(2,29): 4 cells Drawing a string at (2,34): 'command' clearing(2,34): 7 cells Drawing a string at (2,50): 'v_' clearing(2,50): 2 cells Drawing a string at (2,59): ':help' clearing(2,59): 5 cells Drawing a string at (2,65): 'v_u' clearing(2,65): 3 cells Drawing a string at (2,80): ' ' clearing(2,80): 69 cells Drawing a string at (3,22): 'Insert' clearing(3,22): 6 cells Drawing a string at (3,29): 'mode' clearing(3,29): 4 cells Drawing a string at (3,34): 'command' clearing(3,34): 7 cells This all works correctly in my ncurses visualizer -- but when the real gvim draws this, it's as if those 149-cell whitespace strings were not drawn at all. Or, to be more precise, cleared. The 'clearing ... 149 cells' messages in the log prove that this bit of code set_cairo_source_rgb_from_pixel(cr, gui.bgcolor->pixel); cairo_rectangle(cr, FILL_X(col), FILL_Y(row), num_cells * gui.char_width, gui.char_height); cairo_fill(cr); was executed, so it remains to be discovered why it didn't clear anything. Was there an active clipping rectangle? Was bgcolor->pixel wrong? I'll try to add more debugging printfs(). You can find the visualizer script, the draw call log, and the vim patch that adds debug printfs() in this gist: https://gist.github.com/mgedmin/de3663d9fd5d32b2c779 On Thu, Feb 04, 2016 at 01:35:15AM +0900, Kazunobu Kuriyama wrote: > Oh, one thing to ask you. > > When scrolling forward, which side of the screen begins messing up on > drawing, upper side or lower side? I can't tell -- it's too fast. Regards, Marius Gedminas -- The First and Second Rules of Program Optimisation: 1. Don't do it. 2. (For experts only!): Don't do it yet. -- Michael A Jackson -- -- 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: [Patch] GTK3 GUI
On Wed, Feb 03, 2016 at 11:10:22PM +0900, Kazunobu Kuriyama wrote: > Marius, > > Just to make sure. > > Do you use the gvim on an X11 with a compositor or on a VM? I run gnome-shell, which is a compositor. I run on native hardware (Intel video on a ThinkPad X220). > Looking at the pictures you kindly uploaded, I can see what is cleared by > vim still remains on the screen. It's just like as if clear window/block > clear operations were intentionally skipped But not all of them -- just some character cells! And only when scrolling forwards -- hitting PageUp redraws the screen correctly! It's as if clearing works, but outputting "text with spaces" skips clearing the background behind each space character. > Actually, if I comment out drawing functions for clearing the window or a > block, I get a similar phenomenon in you reports. > > To deepen our understanding on the issue, I'd like to hear your thoughts on > possible causes of the failure of the clear operation. Could it be that vim computes the width of a space incorrectly (e.g. 0 pixels) because it has no visible pixels? Or maybe the glyph is missing in a font (because it's empty) and so it doesn't get drawn? Perhaps I'll find some time to debug this, as it seems like an interesting problem -- I'm a bit daunted since I've no familiarity with gvim's GUI drawing code, and also almost no familiarity with GTK+/Cairo text drawing APIs. Regards, Marius Gedminas -- Life begins when you can spend your spare time programming instead of watching television. -- Cal Keegan -- -- 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: [Patch] GTK3 GUI
On Tue, Feb 02, 2016 at 05:15:16PM +0900, Kazunobu Kuriyama wrote: > 2016-02-02 16:47 GMT+09:00 Marius Gedminas : > > On Mon, Feb 01, 2016 at 05:30:43PM +0900, Kazunobu Kuriyama wrote: > > > 2016-02-01 16:44 GMT+09:00 Marius Gedminas : > > > > The blank text cells are still not being painted -- here's what I see > > > > after I :help and a few times: http://imgur.com/ssh6CJg ... > > Ctrl-L doesn't help. > > Thank you for taking your time. > > Then, I wish the new patch attached to this email could fix it. > > I updated the implementation of window clear and block clear functions. > > It was made against 7.4.1235. It applied cleanly on top of 7.4.1246. Unfortunately the redrawing problem isn't fixed. One think I noticed now: moving the cursor left/right over incorrectly-painted text fixes those cells I move over (i.e. blank spaces get cleared): http://imgur.com/a/iZu4j I hadn't thought to test this before, so I don't know if this is new with your recent patch, or if moving horizontally always cleared the spaces correctly. BTW on the command line if I type :something and then use , the erased characters get replaced by black blocks. Except for some of them: http://imgur.com/a/TFsEC (I've seen this with older versions of your patch too.) Marius Gedminas -- PCMCIA - People Can't Memorize Computer Industry Acronyms -- -- 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: htmlcomplete#CompleteTags() incorrectly returns upper case completion
On Tue, Feb 02, 2016 at 05:49:13AM -0800, Axel Bender wrote:
> Using after " completions ("UL" and "BLOCKQUOTE" in my case) instead of the appropriate
> lowercase completions. There are no uppercase tags in the document
> (htmlcomplete.vim of 20.06.2014).
>
> diff --git i/runtime/autoload/htmlcomplete.vim
> w/runtime/autoload/htmlcomplete.vim
> index 984ba8b..d89db7a 100644
> --- i/runtime/autoload/htmlcomplete.vim
> +++ w/runtime/autoload/htmlcomplete.vim
> @@ -251,7 +251,7 @@ function! htmlcomplete#CompleteTags(findstart, base)
> let tag = split(context)[0]
> " Detect if tag is uppercase to return in proper case,
> " we need to make it lowercase for processing
> - if tag =~ '^[A-Z]*$'
> + if tag =~# '^[A-Z]*$'
> let uppercase_tag = 1
> let tag = tolower(tag)
> else
What is your locale?
I think a better patch would be to use
if tag =~ '^[[:upper:]]*$'
Marius Gedminas
--
A "critic" is a man who creates nothing and thereby feels qualified to judge
the work of creative men. There is logic in this; he is unbiased -- he hates
all creative people equally.
--
--
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: [Patch] GTK3 GUI
On Mon, Feb 01, 2016 at 05:30:43PM +0900, Kazunobu Kuriyama wrote: > 2016-02-01 16:44 GMT+09:00 Marius Gedminas : > > The blank text cells are still not being painted -- here's what I see > > after I :help and a few times: http://imgur.com/ssh6CJg > > > > The scrollbar is sometimes missing. In the screenshots here I have three > > panes -- a :help split at the top, and two vsplits at the bottom. The > > bottom scrollbar disappears when I focus the bottom-right pane; it > > reappears when I focus the bottom-left pane: http://imgur.com/a/e0MX4 > > > For these two cases, what if Ctrl-L is pressed? Ctrl-L doesn't help. On Mon, Feb 01, 2016 at 06:02:18PM +0900, Kazunobu Kuriyama wrote: > Marius, > > By the way, on the first picture, I see two "image-missing" icons (a gray > rectangle with a white frame, folded at the bottom-right corner) to the > right of the "Find Previous" (left arrow) button. > > Is it OK for you, or something I should do something with? Those are my custom toolbar buttons from ~2001: https://github.com/mgedmin/dotvim/blob/master/vimrc#L1370-L1377 I used to have custom icons for them, but have accidentally dropped the .xpm files while moving my ~/.vim from Subversion to git. Hm. I've now resurrected them, but the icons are missing. I've tried converted the .xpm to .png, but that didn't help. /usr/bin/gvim (a gnome2 build) can load them fine from ~/.vim/bitmaps/, so I guess this is something you may want to do something about. Marius Gedminas -- "Perfection is achieved, not when there is nothing left to add, but when there is nothing left to take away." -- Antoine de Saint-Exupéry -- -- 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: [Patch] GTK3 GUI
On Fri, Jan 29, 2016 at 06:54:12PM +0900, Kazunobu Kuriyama wrote: > In the new patch, I elaborated scroll and window clear functions a little > bit. So, I’d be happy if you would try it and report the result here. ... > Note that the attached patch was made against 7.4.1190, not against my > previous patch. Tried this one. There are no more black bars -- the unused areas of the window are grey, like they're supposed to be: http://imgur.com/E0r1rTW The blank text cells are still not being painted -- here's what I see after I :help and a few times: http://imgur.com/ssh6CJg The scrollbar is sometimes missing. In the screenshots here I have three panes -- a :help split at the top, and two vsplits at the bottom. The bottom scrollbar disappears when I focus the bottom-right pane; it reappears when I focus the bottom-left pane: http://imgur.com/a/e0MX4 BTW I couldn't reproduce the scrollbar issue with gvim -u NONE -U NONE. (I could reproduce the non-cleared text problem with -u NONE -U NONE.) Regards, Marius Gedminas -- /* Halley */ (Halley's comment.) -- -- 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: [Patch] GTK3 GUI
On Tue, Jan 26, 2016 at 10:39:00AM +0100, Christian Brabandt wrote: > Hi Marius! > > On Di, 26 Jan 2016, Marius Gedminas wrote: > > > On Tue, Jan 26, 2016 at 08:28:19AM +0100, Christian Brabandt wrote: > > > Hi Kazunobu! > > > > > > Wow. This is great news. > > > > > > So I went ahead, updated my local vim tree, applied your patch and > > > configured: > > > > > > ~/vim/src$ ./configure --enable-gui=gtk3 --with-features=huge > > > [...] > > > checking for GCC 3 or later... yes I didn't notice that at first, but this talking about GCC 3, not GTK+ 3 ;-) > > > [...] > > > But it actually does not build with gui enabled. I must be missing > > > something. > > > > > > auto/config.log wasn't really helpful to find why the gui was not > > > enabled. > > > > Could you pastebin it somewhere? Here's mine, from a successful build > > with this patch applied: > > https://gist.github.com/mgedmin/38fd0d1a10d708206fa3 > > https://www.256bit.org/~chrisbra/config.log > > > > I am probably missing some header files, I just don't know > > > which ones, and there does not appear to be a libgtk3.0-dev (or similar) > > > package available on debian. > > > > https://packages.debian.org/search?keywords=libgtk-3-dev > > Oh, I searched for libgtk3-dev since the 2 version is called > libgtk2.0-dev > > But see logfile above, gui is still not build. The log has this: configure:8508: checking --enable-gui argument configure:8594: result: Sorry, gtk3 GUI is not supported which looks as if you're trying to build a vim without this patch being applied? Marius Gedminas -- Moore's Law, I need hardly remind a top-notch industry professional like you, states that as the density of silicon circuitry doubles, the probability of you not being able to find some sensibly-priced extra memory to fit your old lappy approaches 1.0. -- Verity Stob -- -- 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: [Patch] GTK3 GUI
On Tue, Jan 26, 2016 at 08:28:19AM +0100, Christian Brabandt wrote: > Hi Kazunobu! > > Wow. This is great news. > > So I went ahead, updated my local vim tree, applied your patch and > configured: > > ~/vim/src$ ./configure --enable-gui=gtk3 --with-features=huge > [...] > checking for GCC 3 or later... yes > [...] > But it actually does not build with gui enabled. I must be missing > something. > > auto/config.log wasn't really helpful to find why the gui was not > enabled. Could you pastebin it somewhere? Here's mine, from a successful build with this patch applied: https://gist.github.com/mgedmin/38fd0d1a10d708206fa3 > I am probably missing some header files, I just don't know > which ones, and there does not appear to be a libgtk3.0-dev (or similar) > package available on debian. https://packages.debian.org/search?keywords=libgtk-3-dev HTH, Marius Gedminas -- We don't care. We don't have to. We're the Phone Company. -- -- 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: [Patch] GTK3 GUI
On Tue, Jan 26, 2016 at 03:55:57PM +0900, Kazunobu Kuriyama wrote: > Attached is a patch to add a GTK3 GUI to vim. Woohoo! I built vim 7.4.1180 with this patch applied on Ubuntu 15.10 (with GTK 3.18 from the gnome3-staging PPA). Seems to work mostly fine, but there are visual quirks. E.g. there's a strange black area around the window: http://imgur.com/ZGzwLyV It's even worse if I start vim as gvim instead of using :gui: http://imgur.com/UuMbfaS It seems as if blank cells are not redrawn? Try opening a text file, then use :help, then close the :help file -- bits of help text will show through the actual text you're editing: http://imgur.com/a/YCiow Ctrl-L doesn't help in that situation. Similar problems occur in the status line: old text is not cleared away when you press : and start entering a new command. Scrolling with PageUp also exhibits this kind of redrawing problem. Using PageDown clears the screen correctly before drawing. (BTW also notice the missing scrollbar in the :help split -- it shows up when you switch to it, but is just a black rectangle initially.) Marius Gedminas -- Do not meddle in the affairs of sysadmins, they are quick to anger and have no need for subtlety. -- -- 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: Patch 7.4.1154
v:val Value of the current item of a |List| or |Dictionary|.
> Only
> valid while evaluating the expression used with |map()| and
> ***
> *** 1901,1906
> --- 1929,1936
> islocked( {expr}) Number TRUE if {expr} is locked
> items( {dict}) Listkey-value pairs in {dict}
> join( {list} [, {sep}]) String join {list} items into one
> String
> + jsondecode( {string}) any decode JSON
> + jsonencode( {expr}) String encode JSON
> keys( {dict}) Listkeys in {dict}
> len( {expr})Number the length of {expr}
> libcall( {lib}, {func}, {arg}) String call {func} in library {lib}
> with {arg}
> ***
> *** 4145,4150
> --- 4233,4259
> converted into a string like with |string()|.
> The opposite function is |split()|.
>
> + jsondecode({string})*jsondecode()*
> + TODO
> +
This seems incomplete.
> + jsonencode({expr}) *jsonencode()*
> + Encodode {expr} as JSON and return this as a string.
Typo: Encode
> + The encoding is specified in:
> + http://www.ietf.org/rfc/rfc4627.txt
> + Vim values are converted as follows:
> +Number decimal number
> +Floatfloating point number
> +String in double quotes (possibly null)
> +Funcref nothing
> +List as an array (possibly null); when
> + used recursively: []
> +Dict as an object (possibly null); when
> + used recursively: {}
> +v:false "false"
> +v:true "true"
> +v:none nothing
> +v:null "null"
> +
> keys({dict})*keys()*
> Return a |List| with all the keys of {dict}. The |List| is in
> arbitrary order.
Marius Gedminas
--
Did you know that 7/5 people don't know how to use fractions?
--
--
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: [vim] Vim directory browsing is leaving swap files (#552)
On Mon, Jan 11, 2016 at 03:31:17PM -0500, Charles E Campbell wrote: > Dino Morelli wrote: > > On Monday, January 11, 2016 at 1:29:48 PM UTC-5, Christian Brabandt wrote: > >> Closed #552. > >> > > Can you tell me if this is an existing issue already reported? Or if it's > > not an issue at all but something that can be changed with config? There > > are no details for why this has been closed. > > > > As it stands, I temporarily rolled back to 7.4.884 in my distro and pinned > > it to no longer upgrade. Eventually I'm going to have to unpin that to let > > my system update. > > > Did you (D.M.) miss my reply? Please try v155h of netrw. Can we get an updated version of netrw included in vim? Currently https://github.com/vim/vim/blob/master/runtime/plugin/netrwPlugin.vim#L23 is v154. Marius Gedminas -- If nothing else helps, read the documentation. -- -- 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: Patch 7.4.1000
On Thu, Dec 31, 2015 at 07:39:02PM +0100, Bram Moolenaar wrote: > > Charles Campbell wrote: > > > Bram Moolenaar wrote: > > >> Den onsdag 30 december 2015 kl. 15:49:30 UTC+1 skrev Bram Moolenaar: > > >>> Patch 7.4.1000 > > >>> Problem:Test 49 is slow and doesn't work on MS-Windows. > > >>> Solution: Start moving parts of test 49 to test_viml. > > >>> Files: src/Makefile, src/testdir/runtest.vim, > > >>> src/testdir/test_viml.vim, > > >> Patches 7.4.1000 to 7.4.1004 are listed in the README-file but aren't > > >> available on ftp://ftp.vim.org/pub/vim/patches/7.4/ > > > I can see them there. Keep in mind they are sorted alphabetically, thus > > > 7.4.1000 comes right after 7.4.100 and before 7.4.101. > > I had a problem with patch#1000: > > > > Applying patch 7.4.1000 > > patching file src/Makefile > > Hunk #1 FAILED at 1976. > > 1 out of 1 hunk FAILED -- saving rejects to file src/Makefile.rej > > Perhaps you are missing one of the earlier patches? > Note that patch 7.4.1000 sorts before 7.4.101, thus if you apply patches > in alphabetical order that would fail. Perhaps vim 7.5 should use four digits from the start (7.5.0001 etc.)? Marius Gedminas -- People who think, "Oh this is a one-off," need to be offed, or perhaps politely removed from the project. -- George Neville-Neil -- -- 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: $TMPDIR bug
On Wed, Dec 02, 2015 at 05:24:03PM -0800, Jörn Engel wrote: > On Thu, Dec 03, 2015 at 01:20:22AM +0100, Tony Mechelynck wrote: > > On Thu, Dec 3, 2015 at 12:39 AM, Jörn Engel wrote: > > > Retry after subscribing to the list. I hope this works and I can > > > unsubscribe again. > > > [...] ... > Cannot say I enjoy this policy or that it encourages bug reports. You can also report bugs at https://github.com/vim/vim/issues > But then again, this is the first bug I have encountered in 17 years > of using vim, so you must be doing something right. > > Thank you and everyone else that made my life better in the past 17 > years. > > And I will unsubscribe long before I stop using vim. The latter should > be a few weeks before my death, if that long. ;) BTW you can stop email delivery without unsubscribing, at https://groups.google.com/forum/#!forum/vim_dev (the my settings button, second on top-right; then Membership and email settings; then Email delivery preference: Don't send email updates). Marius Gedminas -- "If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor, and when was the last time you needed one?" -- Tom Cargil, _C++_Journal_ -- -- 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: Compilation warning: gdk_pixbuf_new_from_inline is deprecated (@ gui_gtk.c line 152)
On Mon, Nov 30, 2015 at 12:01:07AM +0100, Tony Mechelynck wrote: > When compiling 7.4.944, huge, with GTK2/Gnome2 GUI (i don't know > exactly at which changeset it appeared): > > gcc -c -I. [...] -o objects/gui_gtk.o gui_gtk.c > gui_gtk.c: In function ‘add_stock_icon’: > gui_gtk.c:152:5: warning: ‘gdk_pixbuf_new_from_inline’ is deprecated > (declared at /usr/include/gdk-pixbuf-2.0/gdk-pixbuf/gdk-pixbuf-core.h:314) > [-Wdeprecated-declarations] > pixbuf = gdk_pixbuf_new_from_inline(data_length, inline_data, FALSE, > NULL); > ^ > > I don't know if we can do something about it now; but as everyone > knows, "deprecated in one release may mean removed in the next > release" and if and when that happens we'll be in trouble. GTK+ 2.x is no longer being maintained; it's unlikely that someone will create a new release and remove deprecated functions. Is anyone working on porting Vim to GTK+ 3? Marius Gedminas -- We did it for smallpox, we'll also win over on ISO 8859-1 ... ;-) -- Markus Kuhn after eradicating one more ISO 8859-1 file from his disk -- -- 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: [bug] access to uninitialized memory in match_backref() regexp_nda.c:4882
On Tue, Nov 24, 2015 at 05:11:02PM +0100, Bram Moolenaar wrote: > Dominique wrote: > > > afl-fuzz fuzzer came up with the following command, > > which causes access to uninitialized memory in > > Vim-7-4-909: > > > > $ valgrind --track-origins=yes 2> valgrind.log \ > > vim -u NONE -c 'syn keyword x nextgroup=\(\1\)' > > > > In valgrind.log: > > > > ==4366== Memcheck, a memory error detector > > ==4366== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. > > ==4366== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright > > info > > ==4366== Command: ./vim -u NONE -c syn\ keyword\ x\ nextgroup=\\(\\1\\) > > ==4366== > > ==4366== Conditional jump or move depends on uninitialised value(s) > > ==4366==at 0x55246B: match_backref (regexp_nfa.c:4882) > > ==4366==by 0x555276: nfa_regmatch (regexp_nfa.c:6398) > > ==4366==by 0x556214: nfa_regtry (regexp_nfa.c:6894) > > ==4366==by 0x5569DF: nfa_regexec_both (regexp_nfa.c:7085) > > ==4366==by 0x556D6A: nfa_regexec_nl (regexp_nfa.c:7247) > > ==4366==by 0x55702D: vim_regexec_both (regexp.c:8179) > > ==4366==by 0x5571BD: vim_regexec (regexp.c:8238) > > ==4366==by 0x5A90B8: get_id_list (syntax.c:6027) > > ==4366==by 0x5A5C2F: get_syn_options (syntax.c:4602) > > ==4366==by 0x5A63C4: syn_cmd_keyword (syntax.c:4840) > > ==4366==by 0x5A97B3: ex_syntax (syntax.c:6296) > > ==4366==by 0x46E052: do_one_cmd (ex_docmd.c:2961) > > ==4366== Uninitialised value was created by a heap allocation > > ==4366==at 0x4C2AB80: malloc (in > > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > > ==4366==by 0x4E27E3: lalloc (misc2.c:921) > > ==4366==by 0x5530D0: nfa_regmatch (regexp_nfa.c:5474) > > ==4366==by 0x556214: nfa_regtry (regexp_nfa.c:6894) > > ==4366==by 0x5569DF: nfa_regexec_both (regexp_nfa.c:7085) > > ==4366==by 0x556D6A: nfa_regexec_nl (regexp_nfa.c:7247) > > ==4366==by 0x55702D: vim_regexec_both (regexp.c:8179) > > ==4366==by 0x5571BD: vim_regexec (regexp.c:8238) > > ==4366==by 0x5A90B8: get_id_list (syntax.c:6027) > > ==4366==by 0x5A5C2F: get_syn_options (syntax.c:4602) > > ==4366==by 0x5A63C4: syn_cmd_keyword (syntax.c:4840) > > ==4366==by 0x5A97B3: ex_syntax (syntax.c:6296) > > Is this fixed by patch 7.4.937, or is this another problem? I can reproduce this with vim 7.4.941, so it must be a different problem. (Unsurprisingly, since \z(\) doesn't make an appearance.) Marius Gedminas -- (mental note: stop installing red hat. everytime i do so, it takes ages to fix my system again.) -- from the sig of Martin Högman -- -- 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: Compiler warings after patches 7.4.904 to 7.4.908
On Mon, Nov 02, 2015 at 07:15:53PM +0100, Tony Mechelynck wrote: > After patches 7.4.904 to .908 I get the following compile warnings: > the first one is for using a deprecated declaration defined in a GDK > include file, so possibly unavoidable; No: that's the GDK library saying you shouldn't be calling gdk_pixbuf_new_from_inline() any more, because it's deprecated: "gdk_pixbuf_new_from_inline has been deprecated since version 2.32 and should not be used in newly-written code. Use GResource instead." -- https://developer.gnome.org/gdk-pixbuf/stable/gdk-pixbuf-Image-Data-in-Memory.html#gdk-pixbuf-new-from-inline It's vim's code thats calling this function: > gui_gtk.c: In function ‘add_stock_icon’: > gui_gtk.c:152:5: warning: ‘gdk_pixbuf_new_from_inline’ is deprecated > (declared at /usr/include/gdk-pixbuf-2.0/gdk-pixbuf/gdk-pixbuf-core.h:314) > [-Wdeprecated-declarations] > pixbuf = gdk_pixbuf_new_from_inline(data_length, inline_data, FALSE, > NULL); > ^ > the other two are for breaking strict aliasing rules in if_py_both.h. > In file included from if_python.c:825:0: > if_py_both.h: In function ‘AlwaysFalse’: > if_py_both.h:479:5: warning: dereferencing type-punned pointer will > break strict-aliasing rules [-Wstrict-aliasing] > Py_INCREF(Py_False); > ^ > if_py_both.h: In function ‘AlwaysTrue’: > if_py_both.h:487:5: warning: dereferencing type-punned pointer will > break strict-aliasing rules [-Wstrict-aliasing] > Py_INCREF(Py_True); > ^ Python has macros for this: Py_RETURN_TRUE https://docs.python.org/2/c-api/bool.html#c.Py_RETURN_TRUE https://docs.python.org/3/c-api/bool.html#c.Py_RETURN_TRUE Py_RETURN_FALSE https://docs.python.org/2/c-api/bool.html#c.Py_RETURN_FALSE https://docs.python.org/3/c-api/bool.html#c.Py_RETURN_FALSE Those macros do the same thing: https://github.com/python/cpython/blob/1fe0fd9feb6a4472a9a1b186502eb9c0b2366326/Include/boolobject.h#L25-L26 so I wonder what's going on here. Marius Gedminas -- There is a 70% probability of tomorrow. (Actual weatherman quote, 1988) -- -- 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: Installation failure
On Mon, Nov 02, 2015 at 01:57:55PM +0100, Bram Moolenaar wrote: > > With the latest changes this error is reported: > > cp ../runtime/vim.desktop ../runtime/gvim.desktop \ > /usr/local/share/vim/vim-7.4/share/applications > cp: target `/usr/local/share/vim/vim-7.4/share/applications' is not a > directory > > What is the correct directory? /usr/local/share/applications Marius Gedminas -- Whom the gods would destroy, they first teach BASIC. -- -- 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: Repository cleanup (Was: Preparations for moving to github)
On Fri, Aug 14, 2015 at 01:39:18AM +0200, Markus Heidelberg wrote: > Am Donnerstag, 13. August 2015, 13:14:34 schrieb Bram Moolenaar: > > You mentioned the size of the repository after "export to github" was > > much larger than the one resulting from the local conversion. How do > > you see that? > > Try this (using your 2nd test repo): > > $ git clone https://github.com/vim/vim.git > [..] > Receiving objects: 42% (22538/53119), 206.21 MiB | 622.00 KiB/s > > -> 200 MB already transferred and still 58% to do. I aborted then. > > It seems like GitHub optimizes the repository some day later or > regularly because your first test repo (now at > https://github.com/vim/vim-old-tryout) has a reasonable compact size: > Receiving objects: 100% (52960/52960), 33.29 MiB | 657.00 KiB/s, done. > > $ du -sh vim-old-tryout/.git > 36M .git > > But I remember my initial clone a few months ago was really big. > > Compare the size of .git/ with your locally converted Git repo, this > must be huge (743 MB for me). It might be a manual process. I remember when git clone https://github.com/vim/vim produced a 700 meg .git. I complained on Twitter and somebody from GitHub noticed and ran a manual "git gc --aggressive" (or something like that) on the server side: - https://twitter.com/mgedmin/status/581131821796196353 - https://twitter.com/vmg/status/581144886826672130 If you're planning to do a new conversion, you may need to ask GitHub admins to do the compaction by hand again. Marius Gedminas -- If the meanings of "true" and "false" were switched, then this sentence wouldn't be false. -- Douglas Hofstadter -- -- 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: [Patch] Python syntax: avoid highlighting attributes as builtins
On Sat, Aug 01, 2015 at 07:39:47AM -0700, Zvezdan Petkovic wrote: > Let’s have others chime in and take a look at this next week. I've been mildly annoyed by 'filter' getting mistakenly highlighted as a builtin in expressions like foo.filter(...) There are packages out there (e.g. SQLAlchemy) that have this kind of API and I cannot change that. I don't really care about class Foo: filter = ... one way or another. Marius Gedminas -- Get a life? Well, once I nearly found one, but the link was broken. -- -- 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
Ctrl-X and negative numbers in visual mode
Just built vim 7.5.754 to play with the new / in visual mode. I observe something strange. Given the following text in a buffer: 1. lalala Pressing Ctrl-X twice while on the '1' changes it to '0' then '-1'. However if I undo back to the original state, select the '1' in a visual block with Ctrl-V, and then press Ctrl-X, gv, Ctrl-X, I get '0' and then '1' again. I would expect '0' and then '-1'. The other experiment: yank the line and paste it 10 times: 1. lalala 1. lalala 1. lalala 1. lalala 1. lalala 1. lalala 1. lalala 1. lalala 1. lalala 1. lalala 1. lalala Select a visual block to the end of the file (VG), press g Ctrl-X. I get 1. lalala 0. lalala 18446744073709551615. lalala 18446744073709551614. lalala 18446744073709551613. lalala 18446744073709551612. lalala 18446744073709551611. lalala 18446744073709551610. lalala 18446744073709551609. lalala 18446744073709551608. lalala 18446744073709551607. lalala I expected 1, 0, -1, -2, ... Marius Gedminas -- A: No. Q: Should I include quotations after my reply? -- -- 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: [patch] more non-breaking spaces
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.) > 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. Marius Gedminas -- HOST SYSTEM NOT RESPONDING, PROBABLY DOWN. DO YOU WANT TO WAIT? (Y/N) -- -- 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: How to stop buffer number incrementing when writing to a temp file?
On Wed, Apr 01, 2015 at 03:21:15PM +0200, Christian Brabandt wrote: > Am 2015-04-01 11:30, schrieb b...@airbladesoftware.com: > >I have some VimL where I write the current buffer to a temporary file like > >this: > > > >let tmp = tempname() > >execute 'keepalt silent write' tmp > > > >I then use the temporary file in an external command invoked with > >system(). Finally I delete the temporary file: > > > >call delete(tmp) > > > >At no point do I load, or want to load, the temporary file into a vim > >buffer. > > > >However every time my VimL executes, a new buffer number is taken > >because the temporary file is allocated an unlisted buffer (visible > >with :ls!). How can I prevent Vim allocating buffers for my temporary > >files? > > > >For example: > > > >1. Open some file in Vim. This is loaded into buffer 1. > >2. Execute my VimL ten times. > >3. Open some other file. > > > >Desired behaviour: "some other file" is loaded into buffer 2. > >Actual behaviour: "some other file" is loaded into buffer 12. > > I fail to understand, why this is a problem, For people who sometimes like to switch buffers by using their numbers (e.g. myself), it's much nicer to be able to do 1, 2, 3, as opposed to 1, 15, 42. Marius Gedminas -- We have enough youth, how about a fountain of SMART? -- -- 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: Preparations for moving to github
On Mon, Mar 30, 2015 at 07:16:40PM +0200, Christian Brabandt wrote: > On Mo, 30 Mär 2015, LCD 47 wrote: > > On 30 March 2015, Christian Brabandt wrote: > > > I have setup a mercurial mirror here: > > > https://bitbucket.org/vim-mirror/vim > > > (as a bonus, this is a clone of the official google code repository, so > > > it contains all commits from there). > > [...] > > > > Your manual commits are shown as "draft". A quick search seems to > > imply this is a configuration problem: > > > > http://stackoverflow.com/questions/20648510/draft-commits-on-mercurial/20669697#20669697 > > This bug report > https://bitbucket.org/site/master/issue/8678/draft-status-on-commits > indicates, this might be caused by an old installation of mercurial. > (There is no hg phases command available) > > The server pushing the commits is a 12.04 Ubuntu LTS and it's mercurial > is of version 2.0.2. That seems to be a little bit outdated, a sid box > here has 3.1 You can get 3.3.2 for Ubuntu 12.04 from this PPA: https://launchpad.net/~mercurial-ppa/+archive/ubuntu/releases?field.series_filter=precise > We talked about upgrading the server's operating system before, but I > don't know, when this will happen. If this causes trouble, I'll have to > go through the process of updating the server, but I'd rather avoid that > for now. Marius Gedminas -- Do not meddle in the affairs of sysadmins, they are quick to anger and have no need for subtlety. -- -- 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
Remove empty Mercurial tag commits?
The current Git conversion has a lot of empty commits like
https://github.com/vim/vim/commit/e675d947a7ec993176262a888bfde5702427056d
Are they of any use to anyone? Can they be stripped away when doing the
final conversion ('git filter-branch --prune-empty' might be helpful
here)?
Marius Gedminas
--
I code in vi because I don't want to learn another OS. :)
-- Robert Love
--
--
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: Preparations for moving to github
On Fri, Mar 27, 2015 at 04:42:31PM +1300, Jan Larres wrote: > James McCoy : > > $ git clone https://github.com/vim/vim > > ... > > $ cd vim > > $ du -hs .git . > > 685M.git > > 47M . > > $ git gc --aggressive > > ... > > $ du -hs .git . > > 34M .git > > 47M . > > The Google Code to GitHub exporter seems to do a pretty bad job at finding > good deltas; I've seen other projects that were exported with it and had a > similarly bloated repository. I would probably be a good idea to contact > GitHub support and ask them to perform an aggressive gc on the server so that > first-time cloners don't have to download so much junk. I pinged @GitHub on Twitter and they say they've fixed this on the server side: https://twitter.com/vmg/status/581144886826672130 'git clone' now needs to download only 32 megs, yay! mg@platonas: /tmp $ git clone https://github.com/vim/vim vim2 Cloning into 'vim2'... remote: Counting objects: 51714, done. remote: Total 51714 (delta 0), reused 0 (delta 0), pack-reused 51714 Receiving objects: 100% (51714/51714), 32.43 MiB | 527.00 KiB/s, done. Resolving deltas: 100% (41960/41960), done. Checking connectivity... done. [1m11s] mg@platonas: /tmp $ du -chs vim2/.git 35M vim2/.git 35M viso mg@platonas: /tmp $ du -chs vim2 81M vim2 81M viso Marius Gedminas -- Si fractum non sit, noli id reficere. -- -- 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: Preparations for moving to github
On Tue, Mar 24, 2015 at 11:36:02PM +0100, Bram Moolenaar wrote: > > I do have the tags in my local git repository. Do they not get pushed > to the repository with "git push" ? No, one always has to use 'git push && git push --tags'. It's one of the biggest warts of Git IMHO. (This being git there are of course a myriad of other options, like 'git push origin HEAD --tags' to push both the current branch and all the tags, or 'git push --follow-tags', which only pushes reachable _annotated_ tags created with 'git tag -a', but doesn't push regular lightweight tags created with 'git tag'.) (For the record, I still prefer Git to Mercurial and am very happy with the decision to migrate to GitHub.) Marius Gedminas -- It's not illegal to disagree with my opinions (*). [...] (*) Although it obviously _should_ be. Mwhaahahahahaaa... You unbelievers will all be shot when the revolution comes! -- Linus Torvalds -- -- 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: Google summer of code
On Tue, Feb 10, 2015 at 08:56:12PM +0100, Bram Moolenaar wrote: > Christian Brabandt wrote: > > I have a couple of ideas on what to work (in no particular order): ... > > - Update the GTK Gui to use a more modern and nicer GUI > > Migrate to GTK3? > > There has been very little work on the GUI, it would be good to see what > updates can be made. On the other hand, there are not many user > requests in this area. As a user, I'd like Vim to migrate to GTK+ 3.x please. Marius Gedminas -- I went cold turkey on games early on in college in an attempt to focus; in retrospect, putting Linux on my primary computer to help enforce that was likely a valuable career decision. -- Evan Martin -- -- 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: Mapping fails argh......help!!
On Thu, Feb 05, 2015 at 03:04:13AM -0800, Enno wrote:
> Le samedi 23 octobre 2010 22:56:28 UTC+2, PabloHot a écrit :
> > I'm trying something like :map ... but just cannot get this to
> > work. I have tried using Ctrl-K to enter the '-' key, using
> > {minus}, but the mapping does nothing when I type it. If I map map
> > '-'
> >
> > on its own it works perfectly , but just cannot get it to work when
> > using the Ctrl key. Is this a bug, or a I an idiot? Please help!!!
>
> In Vim (under Linux and in urxvt), the map is triggered by
> hitting simultaneously Ctrl and -. In gVim (under Linux) it is
> triggered by hitting simultaneously Ctrl, Shift and -.
>
> Because, Shift+- = _, one could say that gVim does it right. However,
> at the same time in Vim AND gVim, the map is triggered by
> hitting simultaneously Ctrl and 6.
>
> Why is that?
For historical reasons[*] only the following Ctrl+punctuation sequences
are recognized by vim:
- Ctrl-@
- Ctrl-[ (same as )
- Ctrl-\ (sends SIGQUIT by default)
- Ctrl-]
- Ctrl-^
- Ctrl-_
- Ctrl-? (same as or , depending)
[*] ASCII has 33 control characters: 0 through 31 and 127, represented
by ^@, ^A ... ^Z, ^[, ^\, ^], ^^, ^_, and ^?. Control keys in a
terminal emit those control characters. This is also why Vim can't
distinguish Ctrl-A from Ctrl-Shift-A.
There are some alternative ways of entering those control characters:
- Ctrl-Space inputs Ctrl-@
- Ctrl-` inputs Ctrl-@
- Ctrl-2 inputs Ctrl-@ (2 and @ are on the same key on US layouts)
- Ctrl-3 inputs Ctrl-[
- Ctrl-4 inputs Ctrl-\
- Ctrl-5 inputs Ctrl-]
- Ctrl-6 inputs Ctrl-^ (6 and ^ are on the same key on US layouts)
- Ctrl-7 inputs Ctrl-_
- Ctrl-8 inputs Ctrl-?
- Ctrl-/ inputs Ctrl-_
Different terminal emulators might behave differently.
Marius Gedminas
--
In modern best-practices Java it is no longer necessary or even possible to
write big piles of gratuitous OO spaghetti. Today, experienced Java programmers
build their applications on top of huge, industry-standard, highly polished
piles of architectural bullshit, wrestling with which leaves them with no time
to write any code of their own.
-- dkarl on HN
--
--
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: "Make closed folds line up" by Charles Campbell, rare crashes in case "relativenumber nonumber"
On Fri, Dec 12, 2014 at 12:57:39AM +0100, Roland Eggner wrote: > Patch "Make closed folds line up" by Charles Campbell is already on Brams > todo list. > http://www.drchip.org/astronaut/vim/patch/folding.ptch > > It works nicely apart from case "relativenumber nonumber" with numberwidth > smaller than for absolute linenumbers would be appropriate. And in this > particular case, I am encountering rare crashes -- both with and without the > named patch applied, “foldmethod=expr” and „syntax on” always in effect. So > far > I cannot reproduce the crashes, they are too rare. > > E.g. with terminal LINES=90 relativenumbers are never longer than 2 digits, > thus > I set numberwidth=3. If the buffer holds a file with >1 lines of text, > numberwidth<6 seems to be not considered in all related code parts, the > relativenumbers are consuming part of the padding introduced by the patch, > which > does not look as nice as with “norelativenumber number” set. > > > With the patch applied: > *** glibc detected *** ../vim: free(): invalid next size (fast): > 0x05cd68894730 *** Have you tried running vim under valgrind? Marius Gedminas -- You have moved the mouse. NT must be restarted for the changes to take effect. -- -- 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: incsearch+scrolloff causes incorrect viewport positioning
On Tue, Dec 02, 2014 at 02:03:07PM -0800, Troy Sankey wrote: > I noticed a bug with viewport positioning when incsearch and scrolloff > are set. It's rare and difficult to reproduce, but can be reproduced > with vim 7.3.547-7 (debian) and 7.4.537-1 (arch). I cannot reproduce with vim 7.4.540. Marius Gedminas -- C, n: A programming language that is sort of like Pascal except more like assembly except that it isn't very much like either one, or anything else. It is either the best language available to the art today, or it isn't. -- Ray Simard -- -- 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: Patch 7.4.530
On Thu, Nov 27, 2014 at 09:55:36PM +, Marcin Szamotulski wrote:
> I found that `:.,$-bdelete` will trigger a segfault. The attached patch
> fixes that, and in addition it makes `:%bdelete` and `:%bwipeout`
> work as well.
> diff --git a/runtime/doc/windows.txt b/runtime/doc/windows.txt
> index d116c9f..30e62d9 100644
> --- a/runtime/doc/windows.txt
> +++ b/runtime/doc/windows.txt
> @@ -1029,7 +1029,11 @@ list of buffers. |unlisted-buffer|
> Actually, the buffer isn't completely deleted, it is removed
> from the buffer list |unlisted-buffer| and option values,
> variables and mappings/abbreviations for the buffer are
> - cleared.
> + cleared. Examples: >
> + :.,$-bdelete" delete buffers from the current one to
> + " penulimum one
Is that a word? Did you mean "penultimate"?
> + :%bdelete " delete all buffers
> +<
>
> :bdelete[!] {bufname}*E93*
> *E94*
> Like ":bdelete[!] [N]", but buffer given by name. Note that a
Marius Gedminas
--
If you're one of those types that "likes the smell of books", just buy one to
sniff and use the Kindle for reading.
-- shihchiun on reddit
--
--
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: vimdiff screen not redrawn properly when using 'diffexpr'
On Tue, Nov 25, 2014 at 11:12:50AM -0800, Gary Johnson wrote: > On 2014-11-24, Gary Johnson wrote: > > On 2014-11-23, Gary Johnson wrote: > > > > > I'll try to find an old version that doesn't exhibit the problem in > > > my normal work environment. > > > > Well, that didn't pan out, either. I went back to almost a year > > ago, to 7.4.135, and I still see the display not fully refresh after > > a command that causes 'diffexpr' to be evaluated. I'll try to find > > out why and create a patch and/or a workaround. > > > > I don't know why I didn't notice this until recently. > > Progress! I remembered what I changed about the time this problem > appeared! > > I normally clear 't_ti' and 't_te' in my ~/.vimrc because I usually > want whatever I was editing to remain on the screen after I exit vim > so that I can continue to refer to it as I execute other commands. > I recently added an exception for vimdiff because for my work flow I > would rather have the screen restored to what it was before I > executed vimdiff. > > That changed Vim's processing of 'diffexpr'. When screen switching > was disabled, Vim's display was always updated correctly. Now that > I have screen switching enabled for vimdiff, Vim swaps screens > before executing the 'diffexpr' shell command. After the shell > command has executed, vim attempts to restore the screen it uses for > editing by calling starttermcap (from within do_shell at line 1508 > of ex_cmds.c). That function, rather than restoring the previous > screen contents, clears the screen completely. Subsequently-called > functions that update the screen contents update only the parts they > think have changed, leaving the screen a patchwork of text. > > At this point I understand part of the problem, but I don't > understand the mechanics of Vim's screen management well enough to > be able to spot what's missing. I'll continue to work on it, but I > hope by posting here I'll prompt someone else's insight. I'm pretty sure the problem is not related to diffexpr, but rather the :silent prefix in front of the shell command you're running. If I do :!sleep 1 vim redraws the screen correctly. If I do :silent !sleep 1 vim clears the screen and doesn't redraw it. This is in fact documented: ":silent" will also avoid the hit-enter prompt. When using this for an external command, this may cause the screen to be messed up. Use |CTRL-L| to clean it up then. although I don't understand why the seemingly-buggy behavior was documented rather than fixed. Marius Gedminas -- /* * This function is about (re)setting the class of a held lock, * yet we're not actually holding any locks. Naughty user! */ -- -- 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: ftplugin/python.vim & indent/sass.vim overwrites my expandtab/tabstop settings
On Tue, Oct 07, 2014 at 04:30:03PM +0200, Christian Brabandt wrote: > On Di, 07 Okt 2014, Martin Tournoij wrote: > > > I think there is a difference; ftplugin files almost always sets useful, > > filetype-specific stuff. > > > > A quick grep on setlocal shows that it usually just sets comments, foldexpr, > > formatoptions, etc. These things are what almost everyone wants, regardless > > of > > personal preferences (I *want* those settings). > > This is not the case for expandtab & tabstop. These are "personal" > > settings, and, IMHO, different from almost all other stuff set in ftplugin > > files. > > At least for python, it provides defaults for being PEP8 compliant. (see > issue https://code.google.com/p/vim/issues/detail?id=98) It's more serious than that: indentation is significant in Python, and Python always treats a tab character as 8 spaces. If you mix tabs and spaces, and your editor shows the tabs differently from 8 spaces, you'll end up seeing the wrong block structure. Have fun debugging! Marius Gedminas -- The world is going metric - inch by inch. -- Michael Meeks signature.asc Description: Digital signature
Re: [patch] updated breakindent patch
On Fri, May 09, 2014 at 12:06:49AM +0200, Christian Brabandt wrote: > 1 Question remains: > - Where to draw the 'sbr' setting? Does anybody have an opinion on that? I like your 2nd version better: > > > , > > > | Lorem ipsum dolor sit amet, > > > | consetetur sadipscing elitr, > > > | sed > > > | Lorem ipsum dolor sit amet, > > > |>> consetetur sadipscing elitr, > > > |>> sed > > > ` Marius Gedminas -- This is an old fashioned book, written before women were invented. -- Jo Walton reviews Eric Frank Russel's _Wasp_ signature.asc Description: Digital signature
Re: [patch] Document update for ttymouse option
On Wed, Apr 30, 2014 at 05:00:36PM +0900, Hayaki Saito wrote: > Hello, > > Now the description of “ttymouse” option of the vim documents seems to be out > of date. > This patch updates it and includes a small comment fix of os_unix.c. > > Thanks, > diff -r 609b7c0be284 runtime/doc/options.txt > --- a/runtime/doc/options.txt Tue Apr 29 20:04:09 2014 +0200 > +++ b/runtime/doc/options.txt Wed Apr 30 16:52:10 2014 +0900 > @@ -7504,8 +7504,8 @@ > "s" = button state > "c" = column plus 33 > "r" = row plus 33 > - This only works up to 223 columns! See "dec" for a > - solution. > + This only works up to 223 columns! See "dec", > + "urxvt", and "sgr" for solutions. > xterm2 Works like "xterm", but with the xterm reporting the > mouse position while the mouse is dragged. This works > much faster and more precise. Your xterm must at > @@ -7527,29 +7527,35 @@ > ptermQNX pterm mouse handling. > *urxvt-mouse* > urxvtMouse handling for the urxvt (rxvt-unicode) terminal. > + The mouse works only if the terminal support this Typo: s/support/supports/ > + encoding style, but it does not have 223 columns limit > + unlike "xterm" or "xterm2". > *sgr-mouse* Marius Gedminas -- My inferiority complex isn't as good as yours. signature.asc Description: Digital signature
Re: security context with undo file
On Wed, Apr 02, 2014 at 07:56:05PM +0200, Davido wrote: > Dear list, > > Since today, Vim sends me a strange warning when I write a modified file : > > > "scratch" 357 lines, 9418 characters written > > > > Could not remove security context security.SMACK64 for > > /home/[...]/vim/undo/%home%[...]%scratch > > Could not remove security context security.SMACK64EXEC for > > /home/[...]/vim/undo/%home%[...]%scratch > > Could not remove security context security.SMACK64MMAP for > > /home/[...]/vim/undo/%home%[...]%scratch > > This concept seems to be related with SELinux, which is apparently not > activated on my boxes : Not SELinux, SMACK. http://en.wikipedia.org/wiki/Smack_(Linux_security_module) > > $ ls --context /home/[...]/vim/undo/%home%[...]%scratch > > > > ? /home/david/var/quigonjinn/edit/vim/undo/%home%david%notes%scratch > > (tested on two distinct computers) > > So, Vim does try to remove an inexistant security context on the undofile, > I guess. This is weird, because I’ve seen no patch related with SELinux > recently. Any idea ? Look closer at patch 7.4.238. Marius Gedminas -- There are only two hard things in Computer Science: cache invalidation and naming things. -- Phil Karlton signature.asc Description: Digital signature
Re: Undefined references when building Vim with Python/Lua
On Fri, Mar 07, 2014 at 02:58:23AM -0800, nkmathew wrote: > I've been trying to build Vim74 from sources obtained from here, > http://www.vim.org/sources.php, without much luck. That page lists multiple options for obtaining sources. Which one did you choose? > It builds ok without any languages enabled but chokes every time I > enable Python or Lua. My goal is to build it with Lua support since > python support comes with the installer. > > These are the error messages I get: > > [ Python ]~~~ > gobji386/if_python.o:if_python.c:(.text+0x979): undefined reference to > `get_option_value_strict' > gobji386/if_python.o:if_python.c:(.text+0x11ce): undefined reference to > `dict_lookup' > gobji386/if_python.o:if_python.c:(.text+0x1f42): undefined reference to > `get_win_number' > gobji386/if_python.o:if_python.c:(.text+0x1fa8): undefined reference to > `get_tab_number' > gobji386/if_python.o:if_python.c:(.text+0x5a74): undefined reference to > `win_find_tabpage' > gobji386/if_python.o:if_python.c:(.text+0x5be5): undefined reference to > `get_option_value_strict' > gobji386/if_python.o:if_python.c:(.text+0x6f6c): undefined reference to > `get_win_number' > gobji386/if_python.o:if_python.c:(.text+0x80d3): undefined reference to > `get_tab_number' > gobji386/if_python.o:if_python.c:(.text+0x8383): undefined reference to > `dict_lookup' > gobji386/if_python.o:if_python.c:(.text+0x84cc): undefined reference to > `dict_lookup' > gobji386/if_python.o:if_python.c:(.text+0x866d): undefined reference to > `dict_lookup' > gobji386/if_python.o:if_python.c:(.text+0x89c3): undefined reference to > `dict_lookup' > gobji386/if_python.o:if_python.c:(.text+0x8b6b): undefined reference to > `dict_lookup' > gobji386/if_python.o:if_python.c:(.text+0x9b1d): undefined reference to > `get_win_number' > [ Lua ]~~~ > gobji386/if_lua.o:if_lua.c:(.text+0xfba): undefined reference to > `dict_lookup' > > The paths to the libraries in the makefile(.\src\Make_ming.mak) look like > this: > PYTHON=C:/python27 > LUA="C:/Program Files/LuaJIT-2.0.2" > > Which libraries am I missing? These are references to vim's internal functions. If the build fails, the error most likely lies in vim's Makefile. Please test the latest vim version from Mercurial (because manually downloading and applying 193 patches by hand would be very tedious). There was a similar build problem for Perl fixed in patch 7.4.117. It's possible the same patch could've fixed build problems for other interpreters as well. Marius Gedminas -- Those parts of the system that you can hit with a hammer (not advised) are called hardware; those program instructions that you can only curse at are called software. -- Levitating Trains and Kamikaze Genes: Technological Literacy for the 1990's. signature.asc Description: Digital signature
Re: Problem with Python 3.4
On Thu, Feb 20, 2014 at 12:19:27PM +0200, İsmail Dönmez wrote: > I am the vim maintainer for openSUSE and SUSE Enterprise Linux so its not > that hard for me to test latest patches :-) > > But sadly going up to .182 doesn't fix the problem. Ok, so vim implements a special module loader that can look for Python modules in runtimepath. This is described by :h python-special-path Now Python 3.4 changed the import machinery a bit, as described by PEP 451: http://legacy.python.org/dev/peps/pep-0451/ This PEP claims that it is fully backwards-compatible[1][2], which doesn't appear to be the case. Maybe file a Python bug about this? [1] http://legacy.python.org/dev/peps/pep-0451/#what-will-existing-finders-and-loaders-have-to-do-differently [2] http://legacy.python.org/dev/peps/pep-0451/#backward-compatibility I'm not very familiar with either codebase (vim or CPython), and despite working with Python for over 10 years I never felt the need to implement a custom module finder/loader. I'm not sure how much of a help I can be... Marius Gedminas -- At one job, for a short time my desktop HP (running HPUX) was being used as a print server. I soon found out that having something heavy in front of the plug was a good idea, after kicking it out of the outlet a couple of times. I used my old TRS-80 4P, doubtless the slowest computer ever to perform a critical function at that company. -- David Thornley signature.asc Description: Digital signature
Re: Pattern matching broken with re=2 and ignorecase
On Wed, Dec 11, 2013 at 11:48:19PM -0800, Axel Bender wrote: > Hi Tony, > > > What does 64 bit have to do with it? (IOW, why "hence"?) > > Nothing - I referred to the Windows 7 Console which usually has problems with > UTF-8 and special characters (even when changing to CP 65000). > > > Also, I suppose using filenames re1.so and re2.so rather than re1.vim and > > re2.vim makes no difference, but filename.so is usually a binary filetype > > (Unix-like "shared object", of similar use as Windows's DLLs). > > It's supposed to indicate a source file ;-) .src would be clearer Marius Gedminas -- Attempts to stick to simple on-or-off options lead to monsters like gcc, which now has so many flags that programmers are using genetic algorithms to explore them. -- http://www.third-bit.com/~gvwilson/xmlprog.html signature.asc Description: Digital signature
Re: What is the logic behind limiting the diff buffer count to 4?
On Fri, Nov 01, 2013 at 07:50:58AM -0700, ZyX wrote: > > I recompiled vim with a DB_COUNT of 5, and that successfully worked to > > diff five files. I suspect that the DB_COUNT limit can be raised > > without difficulty. I suspect that with a bit of coding that the > > DB_COUNT could be made arbitrary (ie. dependent upon how many files are > > being requested for simultaneous diffing). > > Absence of limit makes sense. Both 9 and 4 look like some magic > number. 4 was questioned by OP, I just added a question for 9. > > I do not think though somebody is going to bother with memory > (de)allocation implied by removing the limit. But before increasing > limit to 9, 99 or INT_MAX one has to answer why. I do not see much > difference between 4 and 9: I never actually needed more then 3; and > even 3 diffed buffers are a bit confusing. Thus I would like to hear a > use-case that resulted in request to increase the limit. I've once needed to diff five[*] very similar files[**]. I had to rebuild vim after increasing that arbitrary limit, and then vimdiff worked just fine. [*] probably five, I don't remember the exact number, only that it was more than vim's default limit [**] they contained names of installed Debian packages from five different computers, one per line Marius Gedminas -- The laser etcher can accept most any image data, (think logos or screen dumps!) and render it on a heat-sensitive surface. There's a big tunable exhaust fan, so the thing can be dialed in to Not vaporize your laptop. -- Stuart Kreitman signature.asc Description: Digital signature
Re: [BUG?] Statusline bg turns black on "sy on"
On Wed, Oct 02, 2013 at 05:54:21PM +0200, Florian Bruhin wrote: > I discovered something that might be a bug, using vim 7.4. It isn't: > After trying to simplify my vimrc first I was able to reproduce it > with this .vimrc and no .vim folder: > > --- > set nocompatible > colorscheme desert > set laststatus=2 > highlight User1 ctermbg=Red ctermfg=Black > set statusline=%1*test > --- > > When I start vim, the statusline is red, as it should be. However, as > soon as I do :sy on, the statusline turns black. :syntax on resets highlighting to default colors. You may want to use :syntax enable instead. Read :help :syn-on. Regards, Marius Gedminas -- As far as we know, our computer has never had an undetected error. -- Weisert signature.asc Description: Digital signature
