Link failure in Tiny build 7.4.2245

Huge build proceeds normally to completion. In 7.4.2245 Tiny build: link.sh: $LINK_AS_NEEDED set to 'yes': invoking linker directly. gcc -L/usr/local/lib -Wl,--as-needed-o vi objects/arabic.o objects/buffer.o objects/blowfish.o objects/charset.o objects/crypt.o objects/crypt_zip.o

Does the visual bell work in GTK+ 3?

With the following settings: :verbose set eb? vb? bo? t_vb? errorbells Last set from ~/.vimrc visualbell Last set from ~/.vimrc belloff= t_vb=^[|1000f Last set from ~/.vimrc (the latter is set in a GUIEnter autocommand, the rest in the .vimrc mainline code) when I

Re: vim is compiled without python support

On Sat, Aug 20, 2016 at 10:44 PM, 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 > ... > The above means you have

Re: Vim 8 pre-announcement

On Tue, Aug 16, 2016 at 6:43 PM, Bram Moolenaar wrote: > > Hello Vim users, > > Work on Vim 8.0 is coming close to an end. I hope version 8.0 can be > released in about two weeks. > > This is a last chance to modify new features in a way that is not > backwards compatible.

Re: +/-xpm or +/-xpm_w32 out of sequence in :version (with patch)

Oops! I added a last-minute change and forgot to readd --config 'diff.unified=6' to the hg qref statement. The patch I sent actually had _too much_ context. On Fri, Aug 12, 2016 at 9:23 PM, Tony Mechelynck <antoine.mechely...@gmail.com> wrote: > Problem: +xpm (or -xpm or +/-xpm_w3

+/-xpm or +/-xpm_w32 out of sequence in :version (with patch)

..@googlegroups.com. For more options, visit https://groups.google.com/d/optout. # HG changeset patch # User Tony Mechelynck <antoine.mechely...@gmail.com> # Parent dc8ef890d0f01c5cca0a6564f9a4ea61a8035210 move +xpm into sequence in output of :version diff --git a/src/version.c b/src/version.c --- a/src/ve

Re: gvim and ASCII glyphs

On Thu, Aug 11, 2016 at 7:36 AM, Kazunobu Kuriyama <kazunobu.kuriy...@gmail.com> wrote: > Hi Tony, > > 2016-08-11 10:05 GMT+09:00 Tony Mechelynck <antoine.mechely...@gmail.com>: >> >> On Thu, Aug 11, 2016 at 1:39 AM, manuelschiller.pimail via vim_dev &g

Re: Scant GTK3 documentation

On Thu, Aug 11, 2016 at 10:01 AM, Kazunobu Kuriyama <kazunobu.kuriy...@gmail.com> wrote: > Hi Tony, > > Thank you for all those checks! Thank _you_ for the explanations, they're a great help to my understanding of the new GUI. > > 2016-08-11 12:23 GMT+09:00 Tony Mechel

Scant GTK3 documentation

- GTK3 is supported, it is said, but there aren't a lot of details about it - It is only barely mentioned under ":help GTK3" in doc/gui_x11.txt - It is mentioned here and there in version8.txt, once at lines 137 and 139, long below ":help new-8" and shortly before ":help new-vim-script-8", then

Cannot build without +acl

This has an air of déjà vu, maybe I've noticed it before. After sourcing the following script: #!/bin/bash export CONF_OPT_ACL='--disable-acl' export CONF_OPT_GUI='--disable-gui' export CONF_OPT_PERL='--disable-perlinterp' export CONF_OPT_PYTHON='--disable-pythoninterp' export

Re: gvim and ASCII glyphs

On Thu, Aug 11, 2016 at 1:39 AM, manuelschiller.pimail via vim_dev <vim_dev@googlegroups.com> wrote: > On Wednesday, 10 August 2016 02:35:04 UTC+2, Tony Mechelynck wrote: >> Manuel: >> >> In the past there have been "unofficial" features published

Re: system() delay

There are other factors which are right there in the help: - job_start() returns a Job object and doesn't wait for the job to finish - system() waits for the external command to finish and returns its full stdout output as a string. I don't know Vim job control really well, but I seem to

Re: [vim/vim] Mark "double quote" does not saved in file ".viminfo" since patch 7.4.320. (#974)

On Wed, Aug 10, 2016 at 4:08 AM, guraga wrote: > > Prepare: > > git clone https://github.com/vim/vim > cd vim > > # Compile two versions of vim > > git checkout v7.4.319 > make > cp ./src/vim ../vim-7.4.319 > > git checkout v7.4.320 > make > cp ./src/vim ../vim-7.4.320

Re: gvim and ASCII glyphs

Manuel: In the past there have been "unofficial" features published as patches which remained outside of the "official" Vim repositories but publicly available, sometimes for years, before Bram finally decided to take them in. The +conceal and +float features, now part of mainstream Vim, are two

Re: E254: Cannot allocate color Grey40

On Mon, Aug 8, 2016 at 8:43 PM, Bram Moolenaar wrote: > > Frantisek Holop wrote: > >> i succesfully compiled vim 7.4.2181 on openbsd >> but i am getting these "Cannot allocate color" >> errors after startup: >> >> $ gvim -u NONE -U NONE >> E254: Cannot allocate color Grey40 >>

Re: gvim and ASCII glyphs

On Mon, Aug 8, 2016 at 3:16 PM, manuelschiller.pimail via vim_dev <vim_dev@googlegroups.com> wrote: > On Monday, 8 August 2016 14:51:01 UTC+2, Tony Mechelynck wrote: >> Well, if you let Pango do glyph reshaping for U+0020 to U+007F you >> might end up with what you said you

Re: gvim and ASCII glyphs

or three character cells would be ugly the opposite way. Best regards, Tony. On Mon, Aug 8, 2016 at 1:50 PM, manuelschiller.pimail via vim_dev <vim_dev@googlegroups.com> wrote: > On Monday, 8 August 2016 12:33:44 UTC+2, Tony Mechelynck wrote: >> On Mon, Aug 8, 2

Re: gvim and ASCII glyphs

On Mon, Aug 8, 2016 at 11:15 AM, manuelschiller.pimail via vim_dev wrote: > On Monday, 8 August 2016 08:31:13 UTC+2, Kazunobu Kuriyama wrote: >> 2016-08-07 20:27 GMT+09:00 manuelschiller.pimail via vim_dev >> : >> >> >> On Monday, 19 October

Re: Toggling local option value also changes global value

On Wed, Aug 3, 2016 at 7:29 PM, Christian Brabandt wrote: > Hi Tony! [...] > That has been discussed before: > https://groups.google.com/d/msg/vim_dev/HpwZWJojl3E/4zCBH3qWQ5IJ > > Best, > Christian > -- > Die Vergangenheit sollten wir als Sprungbrett benutzen, nicht als Sofa.

Re: Could you provide https for vim.org?

On Mon, Aug 1, 2016 at 2:30 AM, mattn wrote: > Hi, Bram. > > In recently, most of data which is transfered in http is possible to be > intercepted by hackers/crackers. So I guess that many plugin author hope to > use https for the login. > > How do you think? > > - mattn

Toggling local option value also changes global value

Bug or feature? I see the following in my Huge gvim with GTK2/Gnome GUI (and as many features as I could get, including +keymap and +xim): I have the following in my keymap: map:let :imi = !:imi sunmap map! I would expect that with this set of mappings, hitting F8 should

Re: Changing the defaults with Vim 8

"map Q gq" has long been part of the vimrc_example.vim. Now it is moved to defaults.vim which vimrc_example.vim sources. So if you have a vimrc you won't be affected, even if your own vimrc sources the vimrc_example.vim, because in that case you already had it and will keep it. If, like me, you

Re: Changing the defaults with Vim 8

On Wed, Jul 27, 2016 at 7:47 PM, Gary Johnson wrote: > On 2016-07-27, Manuel Ortega wrote: >> On Wed, Jul 27, 2016 at 12:26 PM, Gary Johnson wrote: >> >> On 2016-07-27, Manuel Ortega wrote: >> >> > What if "syntax on" and "filetype plugin indent on" were moved into

Re: Changing the defaults with Vim 8

On Wed, Jul 27, 2016 at 8:00 PM, Gary Johnson <garyj...@spocom.com> wrote: > On 2016-07-27, Tony Mechelynck wrote: >> On Wed, Jul 27, 2016 at 4:43 PM, Gary Johnson wrote: >> > On 2016-07-27, Manuel Ortega wrote: >> > >> >> If "syntax on"

Re: Changing the defaults with Vim 8

On Wed, Jul 27, 2016 at 4:43 PM, Gary Johnson wrote: > On 2016-07-27, Manuel Ortega wrote: > >> If "syntax on" is in the system vimrc as proposed, then I can't seem to find >> any way *at all* to disable the loading of the system menu.vim (short of >> unacceptable hacks like

Re: Changing the defaults with Vim 8

On Mon, Jul 25, 2016 at 10:00 PM, Bram Moolenaar wrote: > > Hirohito Higashi wrote: > >> I think it is better to change the default value of Vim body for some >> of the options. >> >> i.e. >> set wildmenu >> set ruler >> set showcmd >> set tags=./tags;,tags; >> etc... >> >>

Re: Changing the defaults with Vim 8

On Tue, Jul 26, 2016 at 12:10 AM, Tumbler Terrall wrote: > On Monday, July 25, 2016 at 3:11:11 PM UTC-5, Christian Brabandt wrote: >> Hi Bram! >> >> On So, 24 Jul 2016, Bram Moolenaar wrote: >> >> > > please no hlsearch. That is most often annoying. >> > >> > Well, I

Re: Changing the defaults with Vim 8

On Mon, Jul 25, 2016 at 10:10 PM, Christian Brabandt wrote: > Hi Bram! > > On So, 24 Jul 2016, Bram Moolenaar wrote: > >> > please no hlsearch. That is most often annoying. >> >> Well, I find it useful. But I suppose that's more a personal >> preference. > > perhaps, if we

Re: Patch 7.4.2102

On Mon, Jul 25, 2016 at 9:27 PM, Hisashi T Fujinaka wrote: > On Mon, 25 Jul 2016, Manuel Ortega wrote: > >> On Mon, Jul 25, 2016 at 2:00 PM, Manuel Ortega >> wrote: >> >> >> On Mon, Jul 25, 2016 at 1:41 PM, Hisashi T Fujinaka >>

Re: Changing the defaults with Vim 8

On Mon, Jul 25, 2016 at 8:03 PM, Charles E Campbell wrote: +>> set langnoremap >> endif > > I had to look this one up as I've never had cause to use it. Easily > reversed, so I'm neutral on this one. >> >> >> Probably not: >> >> " these two leave files behind

Re: Patch 7.4.2102

On Mon, Jul 25, 2016 at 7:41 PM, Hisashi T Fujinaka wrote: > On Sun, 24 Jul 2016, Bram Moolenaar wrote: > >> >> Patch 7.4.2102 (after 7.4.2101) >> Problem:Tiny build with GUI fails. >> Solution: Revert one FOR_ALL_ change. >> Files: src/gui.c > > Well, --huge is

Re: Changing the defaults with Vim 8

On Mon, Jul 25, 2016 at 11:00 AM, wrote: > Ideally, starting the program as 'vim' would automatically give the user the > improvements promised in the name. And 'vi' would hide all those improvements. > > Here is my list of options to set when run as 'vim': [...] >

Re: Show keymap name in mode indicator #933

On Fri, Jul 22, 2016 at 5:40 PM, Dmitri Vereshchagin wrote: > For some reason this PR[1] was not forwarded to the list. It replaces > `lang` in `-- INSERT (lang) --` mode indicator with keymap name. It was > in todo for so long. Diff is here[2]. > > 1.

Re: Patch 7.4.2084

If there are literals in the script source which are not pure 7-bit US-ASCII, :scriptencoding defines how they are interpreted. Without it, it depends on what 'encoding' was when the script was sourced (i.e. loaded in order to be executed). With it, the :scriptencoding argument applies from the

Re: No v7.4.2062 tag on the hg mirror (Ping: Christian Brabandt)

On Wed, Jul 20, 2016 at 6:20 AM, Christian Brabandt <cbli...@256bit.org> wrote: > Hi Tony! > > On Mi, 20 Jul 2016, Tony Mechelynck wrote: > >> There is still no tag v7.4.2062 on the hg mirror, which is under >> Christian Brabandt's responsibility, but he's been u

Re: Syntax highlight error in .vim ??

On Wed, Jul 20, 2016 at 4:55 AM, skywind3...@163.com wrote: > > Reproduce: > 1. vim abc.vim: > 2. add this line: > let my_dict = { "key1":"val1", "key2": "val2", "key3": "val3", "key4":"val4" } > > Issue: > highlight color is incorrect for my_dict, > > screen capture: >

Re: No v7.4.2062 tag on the hg mirror (Ping: Christian Brabandt)

16 at 8:57 PM, Tony Mechelynck <antoine.mechely...@gmail.com> wrote: > I suppose this is an ovsersight: the current tip of the hg mirror > (changeset 695186e11daa «commit > https://github.com/vim/vim/commit/840268400dc8fda62a14f8a084e8b1ea46619454 > Author: Bram Moolenaar <b...@v

Re: How stable is the new regexp engine?

On Mon, Jul 18, 2016 at 4:13 PM, Ben Fritz wrote: [...] > So, I don't think your fear of the new engine is all that warranted. I > certainly wouldn't call it "unstable"; if I did I would basically need to > call all of Vim's source "unstable". I avoided the new engine

Re: netrw tree list produces modified buffers when refreshing

On Mon, Jul 18, 2016 at 12:29 AM, Michal Grochmal wrote: > Hello, > > Apologies if this email bounces several times, it is my first time using > googlegroups. And I am struggling with their we interface. > > I believe I found a bug in the runtime/autoload/netrw.vim

Compiler warning (type mismatch) for quickfix.c at patchlevel 7.4.2065

gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -pthread -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/libpng16 -I/usr/include/gdk-pixbuf-2.0

No v7.4.2062 tag on the hg mirror

I suppose this is an ovsersight: the current tip of the hg mirror (changeset 695186e11daa «commit https://github.com/vim/vim/commit/840268400dc8fda62a14f8a084e8b1ea46619454 Author: Bram Moolenaar Date: Sun Jul 17 20:37:43 2016 +0200 patch 7.4.2062 Problem:Using dummy

RFE: additional Make rule to avoid missing files when using a shadow dir

Problem: When using a shadow dir repeatedly, new sources (added after the creation of the shadowdir) are seen as "missing" and the build fails. Solution (untested): Add the following rules to src/Makefile (They will only come into play when building in a shadow dir) %.c: ../$@ ln -sv $< %.h:

Re: Patch 7.4.2036

On Thu, Jul 14, 2016 at 10:09 PM, Bram Moolenaar wrote: > > Patch 7.4.2036 > Problem:Looking up a buffer by number is slow if there are many. > Solution: Use a hashtab. > Files: src/structs.h, src/buffer.c This introduces several messages in the Tiny build for

Re: Tiny build failure at patchlevel 7.4.2000 (Huge is OK)

On Fri, Jul 8, 2016 at 3:32 PM, Bram Moolenaar <b...@moolenaar.net> wrote: > > Tony Mechelynck wrote: > >> After upgrading my source from 7.4.1999 to 7.4.2000 my Tiny build >> fails as follows: [...] > > Thanks for the note. Probably forgot an #ifdef there.

Tiny build failure at patchlevel 7.4.2000 (Huge is OK)

After upgrading my source from 7.4.1999 to 7.4.2000 my Tiny build fails as follows: linux-2iyu:~/.build/vim/vim-hg/src/shadow-tiny # (make || echo 'exit status' $? ; date) 2>&1 |tee -a make.log gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -fno-strength-reduce -Wall -U_FORTIFY_SOURCE

Re: Unable to use xxd to convert utf-16 file back from hex

On Thu, Jun 30, 2016 at 3:45 PM, Gabriel Barta wrote: > I was using xxd to look at the hex of a utf-16le file with byte-order-mark. > I noticed that converting from the hex form back to text just left my buffer > empty. > > It seems that this is because the fileencoding causes

Re: [vim/vim] Regression: :insert in empty buffer creates jump to line 2 (after 7.4.1896) (#892)

On Thu, Jun 30, 2016 at 6:07 PM, Ingo Karkat wrote: > My automated tests caught a regression caused by > > Date: 2016-06-04 20:14:07 +0200 > patch 7.4.1896 > Problem: Invoking mark_adjust() when adding a new line below the last line > is pointless. > Solution: Skip

Re: can't build with gui -- config not finding gtk

recompile. See http://users.skynet.be/antoine.mechelynck/vim/compunix.htm for details. Best regards, Tony. On Wed, Jun 22, 2016 at 3:58 PM, toothpik <toothp...@gmail.com> wrote: > On Wed, Jun 22, 2016 at 01:55:50PM +0200, Tony Mechelynck wrote: >> On Wed, Jun 22, 2016 at 12:08 PM, John Little

Re: can't build with gui -- config not finding gtk

On Wed, Jun 22, 2016 at 12:08 PM, John Little <john.b.lit...@gmail.com> wrote: > On Tuesday, June 21, 2016 at 7:13:46 PM UTC+12, Tony Mechelynck wrote: >> On Mon, Jun 20, 2016 at 3:46 AM, John Little <john.b.lit...@gmail.com> wrote: >> [...] >>

Re: can't build with gui -- config not finding gtk

On Mon, Jun 20, 2016 at 3:46 AM, John Little wrote: [...] > I'm on a debian-derived distro, [...] Then you may have one bit of useful information. Which command would you run using aptitude or apt-get, to make sure that you have all requirements for building Vim with

Re: [vim/vim] Unconditional 'pkgadd matchit' breaks tiny/small builds of vim (#878)

The error on :let is due to that command not being available in builds with -eval, i.e. in Tiny and Small builds. One possible solution is to guard it with if 1" equivalent with :if has('eval') ... ... ... endif because builds without +eval treat if..endif (when at start

Re: can't build with gui -- config not finding gtk

On Fri, Jun 17, 2016 at 2:54 PM, toothpik <toothp...@gmail.com> wrote: > On Fri, Jun 17, 2016 at 10:01:14AM +0200, Tony Mechelynck wrote: >> On Fri, Jun 17, 2016 at 2:29 AM, toothpik <toothp...@gmail.com> wrote: >> > On Thu, Jun 16, 2016 at 11:59:46PM +0200, Tony

Re: can't build with gui -- config not finding gtk

On Fri, Jun 17, 2016 at 2:29 AM, toothpik <toothp...@gmail.com> wrote: > On Thu, Jun 16, 2016 at 11:59:46PM +0200, Tony Mechelynck wrote: >> Check the console output from configure if you still have it, or else >> the src/auto/config.log (or src/shadow/auto/config.log if you

Re: can't build with gui -- config not finding gtk

Check the console output from configure if you still have it, or else the src/auto/config.log (or src/shadow/auto/config.log if you build in a shadow directory) which is more verbose. What exactly does configure not find that it should? I have no problem building Vim with GTK2 on openSUSE Leap

Re: vim cannot decode 'cp936' properly

'encoding' should not be changed except at the start of your vimrc, before loading any file, because otherwise it can have far-reaching effects everywhere in your Vim session, potentially making already-loaded text unreadable or corrupt. I recommend to se 'encoding' to UTF-8 once and for all, see

Re: Vim 7.5 or Vim 8?

On Mon, Apr 4, 2016 at 10:13 PM, Bram Moolenaar wrote: > > I have been wondering if the next release should be called 7.5 or 8. > We have quite a few new features, but not that many as with the Vim 7 > release. Well, that was a big release. I think the most important >

Re: Proposal: adding a "test" target to src/Make_cyg_ming.mak

On Mon, Apr 4, 2016 at 1:10 AM, Michael Soyka wrote: > Vim developers, > > Currently the Vim test scripts can only be run using the > testdir/Make_ming.mak makefile. I propose adding a "test" target to > src/Make_cyg_ming.mak to make it possible to run those tests from the "src"

Build problems after adding patches 7.4.1616 to 7.4.1626 (plus one runtime files update)

Build problems after adding patches 7.4.1616 to 7.4.1626 (plus one runtime files update) 1. Warning in channel.c (in Huge only since this file is not compiled for Tiny): gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -pthread -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include

Re: Patch 7.4.1559

On Mon, Mar 14, 2016 at 11:43 PM, Tony Mechelynck <antoine.mechely...@gmail.com> wrote: > On Mon, Mar 14, 2016 at 11:05 PM, Bram Moolenaar <b...@moolenaar.net> wrote: >> >> Patch 7.4.1559 >> Problem:Passing cookie to a callback is clumsy. >> Solution

Re: Patch 7.4.1559

On Mon, Mar 14, 2016 at 11:05 PM, Bram Moolenaar wrote: > > Patch 7.4.1559 > Problem:Passing cookie to a callback is clumsy. > Solution: Change function() to take arguments and return a partial. > Files: src/structs.h, src/channel.c, src/eval.c, src/if_python.c, >

Re: [vim] :sort sorts Japanese wrong (#685)

Hmmm… AFAIK this order is not "wrong", it is merely based on Unicode codepoint value. When doing ga on the first character of each line in your first example, they are in increasing Unicode sequence, except lines 4 and 5 which differ only in their last character. See the following remark near the

Re: Patch 7.4.1478

On Thu, Mar 3, 2016 at 5:55 PM, Bram Moolenaar <b...@moolenaar.net> wrote: > > Tony Mechelynck wrote: > >> On Thu, Mar 3, 2016 at 2:23 PM, Bram Moolenaar <b...@moolenaar.net> wrote: >> > >> > Patch 7.4.1478 >> > Problem:":loadplugin&

Re: Patch 7.4.1479

On Thu, Mar 3, 2016 at 3:47 PM, Bram Moolenaar wrote: > > Patch 7.4.1479 > Problem:No testfor ":loadplugin". > Solution: Add a test. Fix how option is being set. > Files: src/ex_cmds2.c, src/testdir/test_loadplugin.vim, > src/testdir/Make_all.mak Tiny

Re: Patch 7.4.1478

On Thu, Mar 3, 2016 at 2:23 PM, Bram Moolenaar wrote: > > Patch 7.4.1478 > Problem:":loadplugin" doesn't take care of ftdetect files. > Solution: Also load ftdetect scripts when appropriate. > Files: src/ex_cmds2.c After applying this patch (i.e., updating from the

Re: "a" . 1.1 become "a11"

A Float cannot be used as a String, that's error E806. You can see it by trying :echo "a" . (0 + 1.1) which forces 1.1 to be a Float. Since 1.1, when concatenated to "a", cannot be a Float, then it must be 1 . 1 (1 concatenated with 1) which is indeed 11. TL;DR: T'ain't a bug, it's a feature.

Re: Patch 7.4.1384

IIUC, to correct a typo in a commit message for a commit already published, you have to add a new commit backing out the "wrong" one, the a second new commit equal to the one backed out (the one with the "wrong" commit message) but with the correct commit message. At least that's how it is with

Re: runtime/doc/tags is modified after make install

On Wed, Feb 24, 2016 at 9:56 PM, Bram Moolenaar wrote: > > Takuya Fujiwara wrote: > >> After 'make && make install' in Vim source directory, >> runtime/doc/tags gets modified in current HEAD (Patch 7.4.1412). >> >> Normally tags file is not managed under version control. >> I

When GUI disabled, configure tries to enable GTK3 (and compiling gui_gtk_x11.c fails)

N.B. In my Huge build, which has --enable-gnome-check but neither --enable nor --disable -gui, configure sets gui=gtk2 as expected. The following errors are in my Tiny build, which has --disable-gui IMHO, when --disable-gui, configure should skip the GTK3 test and enable no GUI of any kind. The

Re: [vim] Support defining compilation date in $SOURCE_DATE_EPOCH (#513)

On Thu, Dec 3, 2015 at 2:22 AM, James McCoy wrote: > > There is an ongoing effort0 to make FOSS software reproducibly > buildable. In order to make Vim build reproducibly, it is necessary to > allow defining the date/time that is part of VIM_VERSION_LONG as part of >

Compiler warning

After updating my Vim clone to v7.4.1386, the same message appears in both Huge and Tiny: gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -fno-strength-reduce -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -o objects/ex_cmds2.o ex_cmds2.c ex_cmds2.c: In function ‘source_pack_plugin’:

Re: Very big file gets truncated

On Fri, Feb 19, 2016 at 11:35 AM, wrote: > I have a text file (dc.epd) that is nearly 8GB. When I open it in gvim.exe > version 1353 the display shows "dc.epd" 0 lines, 0 characters and the file is > truncated to zero characters. I have compiled with Mic. Visual Studio 2015

Re: suggestion new feature :mapgroup

On Fri, Feb 19, 2016 at 11:23 AM, mattn wrote: > On Friday, February 19, 2016 at 7:21:37 AM UTC+9, Bram Moolenaar wrote: > >> Seems like a nice idea. >> >> How about writing the help for it and sending it here for a review >> round? > > I updated patch. > >

Re: [vim] Vim cryptmethod is not authenticated (#638)

On Tue, Feb 16, 2016 at 10:27 PM, Matthew Winn wrote: > On 16/02/16 16:43, Aaron Toponce (Vim Github Repository) wrote: >> >> The goal with this issue, is to provide authenticated encryption to the >> ciphertext, so not only is data integrity maintained, but also

Re: NETBEANS is not required when CHANNEL is defined

Since, with this new set of conditionals, netbeans is never built without channel, why not leave winsock32 out of the netbeans block and make it unconditional in the channel block? Wouldn't that be logically equivalent but clearer? Best regards, Tony. On Sun, Feb 14, 2016 at 11:11 PM, Bram

POSIX flags

I see the POSIX flags are set if Vim sees $VIM_POSIX set at startup. OTOH, the manpages for many other programs talk of checking $POSIXLY_CORRECT instead. Should or shouldn't Vim check that too? Since I don't use it, I don't know. Best regards, Tony. -- -- You received this message from the

Re: Keep manual folds for hidden buffers?

On Wed, Feb 10, 2016 at 12:19 AM, John Otter wrote: > Bram Moolenaar wrote: > >> Perhaps you can move the window to another tab that lives in the >> background? > > Thats a possible solution, but the would go against my buffers/windows > usage philosophy ahah > >> Folding

Re: Runtime files

On Tue, Feb 9, 2016 at 12:54 PM, Nikolay Aleksandrovich Pavlov wrote: > 2016-02-09 13:03 GMT+03:00 Bram Moolenaar : >> >> I had another idea. Currently when installing a plugin or support for >> a language, the files are scattered over different

Documentation error about jsencode()

eceived 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. # HG changese

-Wmaybe-uninitialized (3 times) in eval.c, in Huge but not in Tiny

I don't have a patch number, but these warnings were absent in my compile of 2016-02-06 00:38, present on 2016-02-06 23:42 (times in CET = UTC+0100): gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -pthread -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/pango-1.0

Re: [patch] fixed compilation warnings in eval.c

On Sun, Feb 7, 2016 at 3:57 PM, Bram Moolenaar wrote: > > Dominique Pellé wrote: > >> Attached patch fixes the following compilation >> warnings in vim-7.4.1273 with gcc-.5.2.1 on >> Ubuntu MATE 15.10 on raspberry PI2: [...] I had the same with gcc (SUSE Linux) 4.8.5 on

Re: [patch] fixed compilation warnings in eval.c

On Sun, Feb 7, 2016 at 11:50 PM, Tony Mechelynck <antoine.mechely...@gmail.com> wrote: > On Sun, Feb 7, 2016 at 3:57 PM, Bram Moolenaar <b...@moolenaar.net> wrote: >> >> Dominique Pellé wrote: >> >>> Attached patch fixes the following compilation &g

Re: Feature or bug? dw oddities

On Sat, Feb 6, 2016 at 3:05 PM, Christian Brabandt wrote: […] >> There are a few more places in the docs that need to point to this flag. >> Also, plugin writers must be aware of the two different behaviors. > > Alright, I'll post an update later. > >> Is there a better

Re: backing out patch 866

On Mon, Feb 1, 2016 at 4:43 PM, Charles E Campbell wrote: > Bram Moolenaar wrote: >> Charles Campbell wrote: >> >>> I'm afraid that patch 866, which is flawed, will end up in 7.5. Could >>> this patch be backed out until its fixed, please? >> I'm not aware of a known

After bringing source up-to-date to 7.4.1219, compile warnings in Tiny but not in Huge

At patchlevel 7.4.1219, I see the following messages in Tiny compile but not in Huge. They "may" be due to a different (recent but earlier) patchlevel: gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -fno-strength-reduce -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -o objects/ex_cmds.o ex_cmds.c

Re: After bringing source up-to-date to 7.4.1219, compile warnings in Tiny but not in Huge

ch. Please pardon me if I erred.) On Sun, Jan 31, 2016 at 1:55 AM, h_east <h.east@gmail.com> wrote: > Hi Tony, > > 2016-1-31(Sun) 8:21:26 UTC+9 Tony Mechelynck: >> At patchlevel 7.4.1219, I see the following messages in Tiny compile >> but not in Huge. They "may&

Coding style changed? Not in the help

The coding style of C function declarations seems to have undergone a massive change yesterday (well, I'm on CET = GMT+0100 and it's shortly after midnight my time). However, runtime/doc/develop.txt lines 327-345 (about half a screen _above_ ":help style-spaces") still reflect the "old" Vim

Re: [vim] has("patch-7.3.867") return 0. (#615)

On Sun, Jan 31, 2016 at 4:59 AM, Wang Shidong wrote: > > but my vim --version show me > > VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Jan 2 2014 19:39:47) > 包含补丁: 1-52 Regardless of which version you are running (in this case: 7.4.52), has('patch-7.3.867') will

Re: After bringing source up-to-date to 7.4.1219, compile warnings in Tiny but not in Huge

On Sun, Jan 31, 2016 at 2:35 AM, h_east <h.east@gmail.com> wrote: > Hi Tony, > > 2016-1-31(Sun) 10:14:15 UTC+9 Tony Mechelynck: >> (When writing to Japanese posters, I never know which is the given >> name and which is the family name: I know that the Japanese cus

Re: [vim] has("patch-7.3.867") return 0. (#615)

On Sun, Jan 31, 2016 at 6:16 AM, Tony Mechelynck <antoine.mechely...@gmail.com> wrote: > On Sun, Jan 31, 2016 at 4:59 AM, Wang Shidong <vim-dev-git...@256bit.org> > wrote: >> >> but my vim --version show me >> >> VIM - Vi IMproved 7.4 (2013 Aug 10, co

Re: After bringing source up-to-date to 7.4.1219, compile warnings in Tiny but not in Huge

On Sun, Jan 31, 2016 at 6:17 AM, Kazunobu Kuriyama <kazunobu.kuriy...@gmail.com> wrote: > On 31-Jan-16, Tony Mechelynck wrote: >> (When writing to Japanese posters, I never know which is the given >> name and which is the family name: I know that the Japanese custom is >

Re: [vim] glob2regpat("") returns "^$" (#602)

On Thu, Jan 28, 2016 at 9:17 PM, Christian Brabandt < vim-dev-git...@256bit.org> wrote: > Hm, I think you closed too early. In my opinion an empty glob pattern > should result in an empty regexp > > > > Christian, I wouldn't have thought this of you. An empty glob pattern matches only the empty

Re: [vim] glob2regpat("") returns "^$" (#602)

On Thu, Jan 28, 2016 at 6:25 AM, Justin M. Keyes <justi...@gmail.com> wrote: > On Wed, Jan 27, 2016 at 11:40 PM, Tony Mechelynck > <antoine.mechely...@gmail.com> wrote: >> On Thu, Jan 28, 2016 at 4:45 AM, Justin M. Keyes <vim-dev-git...@256bit.org> >> wr

Re: [vim] glob2regpat("") returns "^$" (#602)

On Thu, Jan 28, 2016 at 4:45 AM, Justin M. Keyes wrote: > glob2regpat("") returns "^$", but that not the regex equivalent of an > empty wildcard pattern. It should probably return empty string instead. > Here's a patch: > > diff --git a/src/eval.c b/src/eval.c > index

Re: Link failure in Huge but not in Tiny

On Sun, Jan 24, 2016 at 5:31 PM, Tony Mechelynck <antoine.mechely...@gmail.com> wrote: > On Sun, Jan 24, 2016 at 2:22 PM, Bram Moolenaar <b...@moolenaar.net> wrote: >> >> Tony wrote: >> >>> 7.4.1153: unaffected >>> 7.4.1158: affected >>

Re: Link failure in Huge but not in Tiny

On Sun, Jan 24, 2016 at 2:22 PM, Bram Moolenaar wrote: > > Tony wrote: > >> 7.4.1153: unaffected >> 7.4.1158: affected >> 7.4.1161: affected >> >> link.sh: $LINK_AS_NEEDED set to 'yes': invoking linker directly. >> gcc -L. -fstack-protector -rdynamic -Wl,-export-dynamic

Link failure in Huge but not in Tiny

7.4.1153: unaffected 7.4.1158: affected 7.4.1161: affected link.sh: $LINK_AS_NEEDED set to 'yes': invoking linker directly. gcc -L. -fstack-protector -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.18.2/x86_64-linux-thread-multi/CORE -L/usr/local/lib -Wl,--as-needed -o vim

Re: [tabnext/tabprevious] {count} inconsistency

On Fri, Jan 22, 2016 at 12:43 PM, Tony Mechelynck <antoine.mechely...@gmail.com> wrote: > On Fri, Jan 22, 2016 at 12:04 PM, Christian Brabandt <cbli...@256bit.org> > wrote: >> Hi, >> I think, there is an inconsistency with regard to the :tabnext and >> :

Re: [tabnext/tabprevious] {count} inconsistency

On Fri, Jan 22, 2016 at 12:04 PM, Christian Brabandt wrote: > Hi, > I think, there is an inconsistency with regard to the :tabnext and > :tabprev commands: > > > :tabn[ext] {count} > {count} > {count}gt Go to tab page {count}. The first tab page has number one. > >

Re: type of number/float in vim script

On Thu, Jan 21, 2016 at 1:48 PM, Ken Takata wrote: > Hi mattn and all, > > I think that supporting 64-bit Number (even on 32-bit systems) is very useful. > One of the best examples is getfsize() as mattn said. 32-bit Number is too > small to represent a filesize nowadays.

Re: Patch 7.4.1103

On Sat, Jan 16, 2016 at 5:12 PM, Christian Brabandt <c...@256bit.org> wrote: > Hi Tony! > > On Sa, 16 Jan 2016, Tony Mechelynck wrote: > >> On Sat, Jan 16, 2016 at 3:45 PM, Bram Moolenaar <b...@moolenaar.net> wrote: >> > >> > Patch 7.4.1103 (aft

<    3   4   5   6   7   8   9   10   11   12   >