On Fri, Jun 14, 2019, 16:25 Bram Moolenaar wrote:
>
> Every maintainer has the freedom to use his choice of process. Some
> have a github project where you can file an issue or pull request, some
> just use email. Enforcing a certain way of working will increase the
> bureden on maintainers,
Patch 8.1.1535 (after 8.1.1534)
Problem:Popup select test fails on Mac.
Solution: Skip test if clipboard feature not available.
Files: src/testdir/test_popupwin.vim
*** ../vim-8.1.1534/src/testdir/test_popupwin.vim 2019-06-14
23:41:30.443699903 +0200
---
Patch 8.1.1534
Problem:Modeless selection in popup window selects too much.
Solution: Restrict the selection to insde of the popup window.
Files: src/vim.h, src/ui.c, src/testdir/test_popupwin.vim,
src/testdir/dumps/Test_popupwin_select_01.dump,
Patch 8.1.1533
Problem:GUI build fails on Mac.
Solution: Change VimClipboard type in non-C file.
Files: src/os_macosx.m
*** ../vim-8.1.1532/src/os_macosx.m 2019-01-24 17:59:35.143217444 +0100
--- src/os_macosx.m 2019-06-14 23:26:26.625462880 +0200
***
*** 40,52
> When building commit 0554fa478 (1531) I now get:
>
> In file included from proto.h:39:0,
> from vim.h:2084,
> from arabic.c:31:
> proto/os_unix.pro:82:30: error: unknown type name ‘Clipboard_T’
> int clip_xterm_own_selection(Clipboard_T *cbd);
>
> build
Felipe Contreras wrote:
> I didn't contact the maintainer, it should be responsibility of
> him/her to be responsive to patches.
The way Vim runtime file maintenance works is that you report any
problems or possible improvements directly to the maintainer.
If the maintainer does not respond we
Hi,
ok, 1532 fixes it.
thanks!
-m
--
--
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
Patch 8.1.1532 (after 8.1.1531)
Problem:Build fails.
Solution: Add missing changes.
Files: src/vim.h
*** ../vim-8.1.1531/src/vim.h 2019-06-14 14:39:44.553975948 +0200
--- src/vim.h 2019-06-14 23:14:26.532278303 +0200
***
*** 2006,2012
# endif
/* Info
Hi,
When building commit 0554fa478 (1531) I now get:
In file included from proto.h:39:0,
from vim.h:2084,
from arabic.c:31:
proto/os_unix.pro:82:30: error: unknown type name ‘Clipboard_T’
int clip_xterm_own_selection(Clipboard_T *cbd);
build worked ok just
On 14-Jun-2019 19:37, Bram Moolenaar wrote:
Patch 8.1.1531
Problem:Clipboard type name is inconsistent.
Solution: Rename VimClipboard to Clipboard_T.
Files: src/gui_gtk_x11.c, src/proto/gui_gtk_x11.pro, src/gui_mac.c,
src/proto/gui_mac.pro, src/gui_x11.c,
Hi all,
In https://github.com/leitzler/govim (master branch) Pontus is adding
support to govim for signs that correspond to quickfix entries.
This is done by calling sign_place/sign_unplace as required to get the
signs for a window in the correct state.
If there are lots of errors in a file,
Patch 8.1.1531
Problem:Clipboard type name is inconsistent.
Solution: Rename VimClipboard to Clipboard_T.
Files: src/gui_gtk_x11.c, src/proto/gui_gtk_x11.pro, src/gui_mac.c,
src/proto/gui_mac.pro, src/gui_x11.c, src/proto/gui_x11.pro,
src/ops.c,
I didn't contact the maintainer, it should be responsibility of him/her to be
responsive to patches.
His address on the syntax file is wrong anyway.
He eventually replied, years later, not looking at my patches, and he didn't
reply to me so I never got that response. He said he didn't read
On Fri, Jun 14, 2019, 05:27 Bram Moolenaar wrote:
>
> [fixed the email address of Charles, you had NOSPAM still in there]
>
> > This works correctly for the shifted version, but not the unshifted:
> >
> > cat <<\
> > 'E O F'
> > this is $single
> > E O F
>
> Normally I would say to talk
Patch 8.1.1530
Problem:Travis config is not optimal.
Solution: Remove system conditions. Do not use excluding matrix. Cache OSX
results. (Ozaki Kiichi, closes #4521)
Files: .travis.yml
*** ../vim-8.1.1529/.travis.yml 2019-06-09 15:21:24.159886643 +0200
--- .travis.yml
Patch 8.1.1529
Problem:Libcanberra is linked with even when not used.
Solution: Have configure check for libcanberra only when wanted.
(suggestions by Libor Bukata)
Files: src/feature.h, src/configure.ac, src/auto/configure, src/Makefile
*** ../vim-8.1.1528/src/feature.h
Patch 8.1.1528
Problem:Popup_any_visible() is unused.
Solution: Remove it.
Files: src/popupwin.c, src/proto/popupwin.pro
*** ../vim-8.1.1527/src/popupwin.c 2019-06-14 19:23:35.502289836 +0200
--- src/popupwin.c 2019-06-14 19:58:52.822867428 +0200
***
***
Patch 8.1.1527
Problem:When moving a popup window over the command line it is not
redrawn.
Solution: Redraw the command line. Move popup redrawing code to the popupwin
file.
Files: src/screen.c, src/proto/screen.pro, src/popupwin.c,
> Yes, that is the safe way. But Paul made a point for what he wanted,
> and it's a very small change.
Thanks, Bram. Just saw the commit too.
I very much appreciate the discussion and understand the reasons
behind the has()/exists() suggestions.
But as explained, my whole testing approach is
Patch 8.1.1526
Problem:No numerical value for the patchlevel.
Solution: Add v:versionlong.
Files: src/version.c, src/eval.c, src/vim.h, runtime/doc/eval.txt,
src/testdir/test_eval_stuff.vim
*** ../vim-8.1.1525/src/version.c 2019-06-13 23:59:46.788290732 +0200
---
Christian wrote:
> On Do, 13 Jun 2019, Bram Moolenaar wrote:
>
> > We could add v:longversion or v:versionlong, with:
> >
> > major version (one digit)
> > minor version (two digits)
> > patchlevel (four digits)
>
> We already have v:version
>
> Why not just add a simple
[fixed the email address of Charles, you had NOSPAM still in there]
> This works correctly for the shifted version, but not the unshifted:
>
> cat <<\
> 'E O F'
> this is $single
> E O F
Normally I would say to talk directly to the maintainer. Unfortunately
I have not received a
> > People who use Go are crazy, never do what they do!
> > (just kidding, of course).
>
> I'm looking forward to the first commit to the Vim repo that is a .go
> file ;-)
No, that would be Zimbu (it's like NeoGo). It has classes and
exceptions, like any decent programming language.
Oh, no,
On Do, 13 Jun 2019, Bram Moolenaar wrote:
> We could add v:longversion or v:versionlong, with:
>
> major version (one digit)
> minor version (two digits)
> patchlevel (four digits)
We already have v:version
Why not just add a simple v:patchlevel which contains the last
On Do, 13 Jun 2019, Felipe Contreras wrote:
> Five years later and this still doesn't work correctly.
Well, have you contacted the maintainer?
> No wonder there's a need for neovim.
No need to be snarky here. Note that Neovim handles runtime files like
Vim does (because they use mostly the
25 matches
Mail list logo
