Patch 8.0.1832 made ":unlet" work on environment variables. No change was made
to allow completion to work like with:
:unlet $
This patch makes completion work as expected.
A test is included to ensure that ":unlet" completion works properly.
-- Jason Franklin
ubscribe 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.
>From 8ddb5e6b03fe59c9e9d819ee0856e9d91e881e3a Mon Sep 17 00:00:00 2001
From: Jason Franklin
Date: Wed, 30 May 2018 08:22:08
Yegappan,
Attached is the updated patch. To confirm, I...
* merged qf_view_result() and qf_view_result_split()
* used vim_snprintf(); I believe I used it properly
* I used the X... functions to merge the test code
Let me know what you think!
-- Jason Franklin
--
--
You received
Hey Yegappan,
I can certainly make these changes. It shouldn't be too difficult... I'm
still learning best practices in the context of the Vim project. Just
a moment.
-- Jason
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you
Note that more can be done to fix up this command, but I didn't want to do too
much in one patch.
--
--
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
---
+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
>From 1591f6a25c962ed58adad2211304a53da7170dbe Mon Sep 17 00:00:00 2001
From: Jason Franklin
Date: Tue, 29 May 2018 10:40:45 -0400
Subject: [PATCH] Fix bug with "CTRL-W " quickfix window command
---
Another note: git bisect shows that the problem started somewhere around
8.0.1309, but I can't be sure becuase I can't build vim on this system for
several commits in that range (the build errors out).
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your
May 17, compiled May 24 2018 09:52:50)
Included patches: 1-22
Compiled by Jason Franklin
Huge version without GUI. Features included (+) or not (-):
+acl +cmdline_compl -ebcdic-hangul_input
-lua +mouse_xterm -python+tag_binar
Good tips. Thank you!
I indeed use older versions of Vim without `getwininfo()` on disparate
machines. So, keeping this function is necessary at the moment.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For
The first instance makes sense. After all, no one would want to change the
file name in the command line window.
The second instance means that I can't run :file in the ftplugin for the "qf"
file type. I was previously doing this in my own "ftplugin/qf.vim" script to
get the type of list I was
To replicate with the cmdline window:
vim -u NONE
q:
:file
To replicate with the quickfix window:
vim -u NONE
:autocmd FileType qf file
:copen
In both of these cases, ":file" fails. This is more
what I was talking about.
--
--
You received this message from the "vim_dev"
Just a follow up on what I've learned here.
I don't think that the ":file" command makes much sense in the cmdline window.
However, I don't think it should be disallowed when curbuf_lock is set. Since
these restrictions go together, not much can be done.
Still, this is more of a decision about
Just a follow up on what I've learned here.
I don't think that the ":file" command makes much sense in the cmdline window.
However, I don't think it should be disallowed when curbuf_lock is set. Since
these restrictions go together, not much can be done.
Still, this is more of a decision
Hey Bram, and anyone else interested.
Just a friendly ping concerning this issue. Like Andy, I feel pretty strongly
that this patch is worth merging.
I noted in my original post that the code for sentence text objects could use
a more general refactoring later down the line. However, I think
In the command index table, the ":file" command doesn't have the CMDWIN flag.
This means it can't be called in the cmdline window.
Should this be the case?
I know that ":file" has variations that let you change the name of the current
buffer, but it doesn't switch buffers that I can tell.
One
This conversation is fun, btw. :)
--
--
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
Thanks for the support, Andy. Just a thought:
I don't know that checking for a capital letter would work. Proper
nouns will always get in the way.
--
--
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
Well, British style is more specific than American style.
The rule under British style is that punctuation should go inside the quotes if
it "belongs" to the quoted text (e.g., with our technical writing). The only
exception, unfortunately, is the one we're talking about! Closing punctuation
Well, according to the most widely accepted conventions in English grammar,
quotes always come after the period, exclamation point, or question mark. So,
the following:
This is a "sentence." This is a sentence.
would be considered two correct and completely separate sentences.
The
I looked at this patch again today, and I realized I used "normal" in some of
the tests instead of "normal!" with the '!' modifier. The latter is probably
preferred. Just wanted to make a note of that.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your
Thanks Marius!
> Both places should probably be updated to also mention the mouse wheel.
I see now that my initial idea was mistaken. However, I noted in an email
directly to Bram that gvim on Microsoft Windows does not obey this behavior.
That is, both windows are scrolled regardless of which
Reproduce as follows (I used Gnome Terminal):
vim -u NONE
:set mouse=a
:e [name of long file]
:vsp
:windo set scrollbind
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
cause 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.
>From 935840a35df5b520dcb2b7d0c8d15c60
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.
>From a4c10e42d533785c85382497f4ce757b36ee573f Mon Sep 17 00:00:00 2001
From: Jason Franklin <j_...@fastmail.us>
Date
Thanks, guys! This is really great stuff. The tips I gathered are here:
1. Use "VIMRUNTIME=../runtime .vim" to run the fresh Vim binary.
2. I can run "./configure" directly to override default build options (allows
me to NOT change the makefile).
3. The "Makefile" can also be edited directly to
Does anyone have any advice for running Vim with a debugger?
1. What debugger is preferred? GDB or something else? Specific commands to run
would be useful here.
2. How do I build Vim with debugging information in the binary?
3. How can I go about debugging Vim on Windows?
Thanks,
Jason
nt to include this because I didn't want to be redundant.
The patch will fix either case!
I'm one of the maintainers of the NERDTree, and this was originally
discovered by one of our users:
https://github.com/scrooloose/nerdtree/issues/644
He'll be happy to know that it's fixed!
Best,
J
...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
example.vim
Description: Binary data
>From 9002f09dc8f89ba67d8b45e8ec3c5cb7b78dcecb Mon Sep 17 00:00:00 2001
From: Jason Franklin <j_...@fastmail.us>
Date: Fri, 4 May 2018 09:07:46 -0400
Subject: [PATCH]
I'm writing two new tests for a patch that fixes a bug with the ":close"
command. There is already a file for testing the various commands that close a
buffer/window (see "src/testdir/test_winbuf_close.vim").
My questions are:
Should new tests always be placed in their own file to isolate
Sorry, I didn't realize you had already taken care of that. Thanks, Bram!
--
--
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
I appreciate it Bram!
> Thanks for the verbose explanation.
I hope not too verbose. :/ I was just being thorough since the bug left me
quite confused at first!
> Another way to fix it is to use "firstwin" in f_gettabvar() when "tp" is
> "curtab". curtab->tp_firstwin is not guaranteed to be
Georgia Southern University
P.O. Box 8088
Statesboro, GA 30460
912.478.5639
On Mon, Jul 17, 2017 at 1:19 PM, Christian Brabandt <cbli...@256bit.org>
wrote:
>
> On Mo, 17 Jul 2017, Jason Franklin wrote:
> > On Monday, July 17, 2017 at 12:29:44 PM UTC-4, yega...@g
On Monday, July 17, 2017 at 12:29:44 PM UTC-4, yega...@gmail.com wrote:
> Hi,
>
> On Mon, Jul 17, 2017 at 8:20 AM, Jason Franklin
> <jrf...@georgiasouthern.edu> wrote:
> > On Monday, July 17, 2017 at 10:52:17 AM UTC-4, yega...@gmail.com wrote:
> >> Hi,
> >
On Monday, July 17, 2017 at 10:52:17 AM UTC-4, yega...@gmail.com wrote:
> Hi,
>
> On Mon, Jul 17, 2017 at 6:04 AM, Jason Franklin
> <jrf...@georgiasouthern.edu> wrote:
> > On Sunday, May 10, 2015 at 4:16:29 AM UTC-4, Bram Moolenaar wrote:
> >> Danie
On Sunday, May 10, 2015 at 4:16:29 AM UTC-4, Bram Moolenaar wrote:
> Daniel Hahler wrote:
>
> > @Bram,
> >
> > what do you think about the patch?
> >
> > I have not checked if it still applies (I have it in my local branch), but
> > came across it being missing a few times recently.
> >
> >
101 - 135 din 135 matches
Mail list logo
