:
try
echoerr 'foo bar baz'
catch /^foo/
echo 'caught'
endtry
You will see that the message was NOT caught. It appears that using the
"^" metacharacter here causes the message not to match.
Can anyone else confirm this? Is this a bug?
It definitely surp
ems.
Bram, is this reasonable?
--
Jason Franklin
--
--
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 becaus
'm not sure how to go about setting t_RV to an empty string. I tried the
following:
VIMRUNTIME=../runtime ./vim -u NONE --cmd 'set nocp t_RV= lz title'
with no success.
--
Jason Franklin
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your
and, in my
opinion.
Anyway, the debugger tells me that the reason redrawing() returns FALSE on
the first call to maketitle() is because char_avail() returns TRUE. Why
would this be the case with my "./vim" command above?
Thanks,
Jason Franklin
--
--
You received this message from th
ll assert_true(empty(v:errmsg), v:errmsg)
+
source $VIMRUNTIME/delmenu.vim
+ call assert_true(empty(v:errmsg), v:errmsg)
endfunc
func Test_translate_menu()
--
Jason Franklin
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below
.
Only one remains: e.g., "1.0.0.0" is still highlighted as a float even
though it
is not a valid float.
This is also the case in C source files, currently.
Is there a way to keep this from happening... I couldn't think of one.
--
Jason Franklin
--
--
You received this message from th
->w_redr_status = TRUE;
+
+if (bt_terminal(wp->w_buffer))
+ redraw_mode = TRUE;
+
redraw_tabline = TRUE;
if (restart_edit)
redraw_later(VALID);/* causes status line redraw */
--
Jason Franklin
--
--
You received this message from the "vim_dev" mail
Greetings:
To reproduce the bug:
1. vim --clean
2. :terminal
3. w
4. iw
Observe that the insert-normal mode indicator fails to be cleared (same in
replace-normal mode).
The patch (attached) fixes this problem, but at the cost of making some
other tests fail. What do
you think?
--
Jason
d behavior?
I would like to stop myself from *ever* overwriting a file that has
the 'readonly' option set (unless I manually disable 'ro').
Thanks,
Jason Franklin
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are rep
und.
+return
+ endif
+
+ " man page
+ call assert_false()
+ call assert_equal(0, )
+
+ " initial window
+ wincmd p
+ call assert_true()
+ call assert_equal(1, )
+
+ %bw!
+ set foldcolumn& number&
+endfunc
Sorry for the inconvenience!
Thanks,
Jason Franklin
--
--
You
.
Thanks,
Jason Franklin
--
--
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 Goo
Interested to see if anyone can reproduce this:
./vim --clean --cmd 'set lz title' --cmd 'autocmd VimEnter * sleep'
Summary:
If it works for you, you may see that the title string is not
redrawn when Vim is fully loaded up.
That is, when the VimEnter autocommands take too long with
uot;tab" unless it was reset).
The patch that fixes these problems is also attached.
Essentially, my change avoids running ":new" without an argument which
will create a superfluous, empty buffer.
All existing tests continue to pass.
Thanks,
Jason Franklin
--
--
You received this messa
uot;tab" unless it was reset).
The patch that fixes these problems is also attached.
Essentially, my change avoids running ":new" without an argument which
will create a superfluous, empty buffer.
Thanks,
Jason Franklin
--
--
You received this message from the "vim_dev" maillist
uot;tab" unless it was reset).
The patch that fixes these problems is also attached.
Essentially, my change avoids running ":new" without an argument which
will create a superfluous, empty buffer.
All existing tests continue to pass.
Thanks,
Jason Franklin
--
--
You received this messa
> Wel already do use :argadd actually, when starting with "vim file1
> file2". The first buffer is wiped out, we just don't have buffer number
> one.
I think this is not true if 'hidden' is set. I failed to include that in
my example
though. Sorry for being unclear there. With 'hidden' the
Bram,
> Perhaps using :argadd works to create the buffers without actually
> opening them or any other side effects. Then later reset the
> argument list.
I think it's even trickier than using :argadd. For example...
vim --clean
:argadd test.txt
:e test.txt
Notice that you're now
> Does this also fix https://github.com/vim/vim/issues/4352 I suppose not?
No, it does not fix that issue.
However, I'm not exactly sure that the issue referenced is a valid
complaint. It was my understanding that buffer numbers are simply id
numbers and shouldn't be relied upon for anything
++nr;
else
restore_size = FALSE;
- if (curwin == wp)
+ if (tab_curwin == wp)
cnr = nr;
}
Thanks,
Jason Franklin
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply be
= execute('bn', '')
" Notice, the message appears, as expected.
:echo x
" But, it wasn't captured!
I'm not sure how to fix this problem. The bug appears to be that execute()
does not capture messages that are set to be printed after the next redraw,
as opposed to being printe
at 11:57 AM Bram Moolenaar wrote:
>
> Jason Franklin wrote:
>
> > Thank you so much for taking the time to work with me on this.
> >
> > Unfortunately, I still can't get the colors to match on the latest build
> > (patch 8.1.1330). I should note that
eal fix. Why exactly
do we need to avoid the switch on a 256 color terminal? I would like to
understand why it works instead of just accepting that it works for me...
Can anyone offer an explanation? It will make me feel better. :)
Thanks again to both of you for following up on this!
Best,
J
> Perhaps you need to adjust your setup?
I'm perfectly fine with that, but I'm at a loss for what should be
adjusted.
I'll poke around. If you have any suggestions, let me know!
Thanks,
Jason
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below
of the
indent.
It looks like the "saved_cursor" variable is being adjusted
incorrectly at the bottom of the "set_indent()" function. I
am unable to discern precisely how this works, but it's where
I think the problem is, anyway.
Best,
Jason Franklin
--
--
You receiv
Bram,
I still like this change. I especially like that it makes it obvious
when a region of text was already sorted (this can be useful sometimes).
I noticed, though, that I made an omission here:
The u_save() function is still called at the top. This means that,
even though may not be set,
e many other things demanding my time at the
moment.
-- Jason Franklin
--
--
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 mes
to let it go
for now.
-- Jason Franklin
--
--
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
I should also note that using ":set hlsearch" in the above
examples makes the problems more apparent.
-- Jason Franklin
--
--
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 inf
onsidered bugs (I think they are). I don't want
to put in effort if the fix is considered unnecessary.
Thanks,
Jason Franklin
--
--
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.
Just tried the fix (8.1.0856). Beautiful!
-- Jason
--
--
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
Bram,
I noticed that this patch introduced the following side-effect:
vim --clean
:set cul
:e src/screen.c
:new
Now, with cursor focus on the blank window, scroll screen.c with the mouse.
You'll notice that the cursorline is no longer updated to visually indicate
where the cursor would be
owever, that Patch 8.1.0849 fixed this problem as a
side-effect!
Thanks,
Jason Franklin
--
--
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 recei
);
}
+redraw_later(SOME_VALID);
}
// Highlight attributes used for displaying entries from the quickfix list.
As usual, there may be a much better solution, and review would be greatly
appreciated!
Thanks,
Jason Franklin
--
--
You received this message from the "vim_dev" maillist.
Do no
t sure if this takes
away some of the performance improvements of this patch.
Best,
Jason Franklin
--
--
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
-
not
exist before was added to the test suite?
This is more of a "how it works" question... it's not really about the
patch itself.
Thanks,
Jason Franklin
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are rep
diff --git a/runtime/doc/autocmd.txt b/runtime/doc/autocmd.txt
index b78cddfef..02019c5a5 100644
--- a/runtime/doc/autocmd.txt
+++ b/runtime/doc/autocmd.txt
@@ -311,6 +311,7 @@ Nametriggered by ~
|FuncUndefined|a user function is used but it isn't defined
> Test fails on Windows...
Darn. I really wish I could help here. I'm not set up to develop Vim on
Windows machines. It looks like the directory names are being escaped twice.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you
ter solution exists, but I'm not really familiar
enough with the code to arrive at the perfect fix... though I try.
Best,
Jason Franklin
--
--
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, visi
Adding all of the buffers
at the end then adds buffers that do not occupy a window. Running :badd on
a buffer that is already in the list has no effect, so it doesn't hurt to
leave it.
I hope I didn't miss anything here. I think my reasoning is sound.
Best wishes,
Jason Franklin
--
--
You
> + FOR_ALL_TABPAGES(tp)
> {
> - tabpage_T *tp = find_tabpage(tabnr);
> -
> - if (tp == NULL) /* done all tab pages */
> - break;
> -
> - if (tabnr > 1 && put_line(fd, "tabnew") == FAIL)
> + if (tp->tp_next != NULL && put_line(fd, "tabnew")
_line(fd, "tabnext 1") == FAIL)
return FAIL;
}
for (tabnr = 1; ; ++tabnr)
All of the existing tests for mksession still pass.
Let me know if anything looks amiss.
Thanks,
Jason Franklin
--
--
You received this message from the "vim_dev" maillist.
Do not
L)
+if (put_line(fd, "%argdelete") == FAIL)
return FAIL;
for (i = 0; i < gap->ga_len; ++i)
{
Very simple.
Thanks,
Jason Franklin
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you
All is now right in the Universe.
--
--
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
John,
Please also see this discussion. I also ran git bisect and arrived
at the same patch.
https://groups.google.com/forum/#!topic/vim_dev/oxi_dTY02as
Thanks,
Jason
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying
highlighting doesn't follow the cursor as expected.
Just wondering if anyone else can reproduce this issue before I
try to dig deeper.
Thanks,
Jason Franklin
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to
RLEN(get_vim_var_str(VV_THIS_SESSION)) == 0
+#endif
+ )
intro_message(FALSE);
}
Best,
Jason Franklin
--
--
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
It looks like I omitted something here:
> + if (no_hlsearch)
> + put_line(fd, "nohlsearch");
Perhaps this should test if put_line(...) == FAIL just as the
other calls to put_line() do. I was a bit careless here.
-- Jason Franklin
--
--
You received t
ot;nohlsearch");
+# endif
if (put_line(fd, "doautoall SessionLoadPost") == FAIL)
failed = TRUE;
if (eap->cmdidx == CMD_mksession)
Let me know if anything needs adjustment.
Best,
Jason Franklin
--
--
You received this message from the "vim
Oh! I see... it fails and then it tries again.
If that's the expected behavior, then this all seems good to me.
--
--
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
I was able to verify the following:
1. The test fails with out the change to diff.c
2. The test passes with the patch.
The change to the test suite seems okay. However, when I run the
test without the patch, I see the message:
"Executed 31 tests"
And, when I run with the patch...
"Executed
> Does the test fail if the change to diff.c is not applied?
Good catch. It looks like the test doesn't fail for me when
the change to "diff.c" is not applied.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For
> How about the following...
This seems perfectly reasonable to me.
The tests run and everything checks out on visual inspection. I'm content!
Best,
Jason Franklin
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you
ting of the option. That is,
there's no way to get direct access to the internal data managed by
the option when set. Let me know if this is not acceptable.
Best,
Jason Franklin
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text y
Hey Bram,
The other example I had in mind was...
:execute %
It's not a huge deal, but it just seemed odd that error
messages would be duplicated. I thought that the issuing
of an error message would make aborting() return true
all the way up the stack.
Thanks,
Jason
--
--
You received
Greetings,
I'm just wondering why duplicate error messages are printed for the
command...
:echo %
I've looked at the code, but I can't figure out if this is on purpose
or by mistake.
If you look at the ex_echo() function, you can see that aborting()
returns false even after the expression
> Strangely, the test fails on AppVeyor but passes everwhere else.
That is quite odd. Unfortunately, I don't have what I need to
build Vim on Windows at the current time, so I can't help debug
this.
Hopefully, someone else can close in on this.
Thanks,
Jason
--
--
You received this message
Yegappan,
I'm running the latest code on Ubuntu now... it looks like the
problem is fixed!
Thanks,
Jason
--
--
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
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 f3ee3a79220881278505a139ba99c797a44d67df Mon Sep 17 00:00:00 2001
From
lit window on other buffer
With this patch, will work just like but it will split
a window first (with some sanity/error checking before it does so).
I also included MANY test cases. Before these patches, these commands weren't
tested very well at all.
Best,
Jason Franklin
--
--
You received th
directly without discarding an empty buffer in between.
It seems to me like this is hiding the underlying problem, rather than
fixing it.
Maybe I'm being a little to picky? Let me know what you think...
Thanks,
Jason Franklin
--
--
You received this message from the "vim_dev" ma
more options, visit https://groups.google.com/d/optout.
>From ce39bc19ebdf7500b2d8efc6cb4f5448102b014f Mon Sep 17 00:00:00 2001
From: Jason Franklin
Date: Mon, 15 Oct 2018 16:13:29 -0400
Subject: [PATCH] Check for directory access with term_start() cwd
---
src/channel.c
I had the same thought!
Currently extending the test for your review.
Thanks!
Jason
--
--
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
I just realized that the call to "mch_isdir()" is necessary.
I'm not sure why I thought I could delete it. I'll send an updated
patch in just a moment.
-- Jason
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
or.
This patch uses "mch_access()" to check for both the existence and the
accessibility of the directory.
A test, which currently fails, is included in the patch. This seems to
work on Ubuntu 18.04, but I haven't tested the change on other systems.
Thanks,
Jason Franklin
--
--
The instructions for adding a new-style test in vim/src/testdir/README.txt
appear to
be a little stale. I'd update them myself, but I don't know what they
should be.
If they aren't lagging, then they must omit something, becuase I'm not able
to precisely
follow the instructions and get a new
That's sort of what I mean, but it seems really brittle.
--
--
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
What I mean, specifically, is the words in red. I wanted to have the
search results in each line highlighted as well as the file name and
location.
--
--
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
Hey Yegappan,
I like it!
Any way I could have the commands modify the current list instead of
overwriting the next list?
Thanks,
Jason
--
--
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,
in
a window.
I've worked on a basic patch to do this. It needs some tests and what not,
but it looks
solid so far.
Does any one have a preference either way? If the main guys (Bram, et.
al.) object, let
me know so I don't do a bunch of work for nothing.
Thanks!
Jason Franklin
--
--
You received
> Last time I checked the test was failing. Did you fix that?
I suppose so. I just now rebased, rebuilt, and then re-ran the tests.
Everything passed. Hmmm...
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
Friendly ping concerning this patch. :)
Does this change look okay? I thought while coding this up that there
must be a better way to do it. But, since it's a special case, I
was not sure what would be preferred.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post!
I noticed that this was still in the "todo.txt" file. I had some free time
today, so I decided
to fix it.
> Using ":file" in quickfix window during an autocommand doesn't
work.
> (Jason Franklin, 2018 May 23) Allow for using it when there is no
argument.
A failing te
Hey all,
See ":h term_start()" under the section on options.
Just found out that term_start() supports "cwd" and "env", but they
aren't listed in the help entry for the function. These are pretty
useful options... not sure what else is missing.
Thanks,
Jason
diff --git a/runtime/doc/eval.txt
> Doesn't this make copy (modeless selection) difficult?
Not sure. This is where I was asking for review.
> What if you try to click in the command line to move the cursor, but
accidentally
> click a bit too high?
This hasn't been a problem for me since I started using this patch. I
suppose
What really concerns me is how the clipboard code above my change
will interact with what I've written... it may make the change
I made pointless if the user has "+clipboard". I'm not sure.
That's where I need review.
--
--
You received this message from the "vim_dev" maillist.
Do not
> shouldn't this code be qualified by #ifdef lines for FEAT_MOUSE? Or
> are those changes already within such a conditional-assembly region
The changes are already inside of a "#ifdef FEAT_MOUSE" block.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your
an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
>From f5f4ff37a407dfcd6bad5cd1a69809f0b7860ecc Mon Sep 17 00:00:00 2001
From: Jason Franklin
Date: Sun, 5 Aug 2018 09:06:11 -0400
Subject: [PATCH] Allow clicking away from the comma
That's odd. When I ran "make test_cmdline" on my machine before and
after the fix, the tests reported no errors. I wonder why that happened for
you and not me. Any idea? Just curious...
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the
p 17 00:00:00 2001
From: Jason Franklin
Date: Sat, 28 Jul 2018 12:10:14 -0400
Subject: [PATCH] Fix shellcmd completion
---
src/ex_getln.c | 13 -
src/testdir/test_cmdline.vim | 22 ++
2 files changed, 34 insertions(+), 1 deletion(-)
diff --git
Sounds good. Thanks!
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
roups.com.
For more options, visit https://groups.google.com/d/optout.
From 3b3adda598f780968ac2c959e46cc723d92e1b9c Mon Sep 17 00:00:00 2001
From: Jason Franklin
Date: Fri, 27 Jul 2018 08:37:16 -0400
Subject: [PATCH] Recognize bash-fc[-.]* files as Bash scripts
---
runtime/doc/syntax.txt | 4 +++-
runtime/
> Using :clearjumps also deletes older jumps. That's not what I expect.
> Could we just remove the jumps to the quickfix window buffer?
I defer to you on this one. Your take sounds reasonable. My choice here
was
little naive. I haven't looked at how to go about deleting only certain
jump list
Nevermind about testing... it looks like I can use the getcompletion()
function for a test. However, I'm not sure how to set up the test data
since it involves creating directories and files for the test.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your
Hey Bram,
Hmmm... I wasn't thinking about going down into the current directory,
haha.
How about we try something like this? Basically, my idea is to match
sub-dirs only if the
current directory is being searched...
Currently looking for a good way to test this. It's hard to find one :/
---
o, I'm trying to submit patches properly... I think I'm doing it right
(I start at the "---") with the patch right? Still working on my email
workflow.
Thanks,
Jason Franklin
---
src/ex_getln.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/ex_getln.c b/src/ex_g
to press enter).
This is inconsistent with all other confirm dialogs I've seen from Vim.
Just wondering if this is intentional. I've tried tracking down the problem
to no avail.
Thanks,
Jason Franklin
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type
the functions are
too long to fit on one screen.
Let me know if you think its useful.
Thanks,
Jason Franklin
--
--
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/ma
I see now. Thanks for the explanation!
--
--
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
Hey Bram,
I was a little confused by this patch, and I was hoping you'd enlighten me.
1. I see that the error messages from the test don't show up when I restored
'modifiable' in the original patch. So I didn't see them while working.
2. They also go away when using ":setlocal" instead of
...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
>From 61897c98c78c0ed448cde83cc8296f5ff25fa8e5 Mon Sep 17 00:00:00 2001
From: Jason Franklin
Date: Wed, 27 Jun 2018 08:47:33 -0400
Subject: [PATCH] Fix duplicate errmsg from Normal mode "p" command
---
s
I noticed that the :sort command always sets 'modified'.
This patch makes :sort check whether or not it actually changed
the buffer.
Tests included.
Thanks,
Jason Franklin
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below th
ba9 Mon Sep 17 00:00:00 2001
From: Jason Franklin
Date: Tue, 26 Jun 2018 09:47:01 -0400
Subject: [PATCH] Fix duplicate errmsg from Normal mode "p" command
---
src/ops.c | 7 ++---
src/testdir/test_messages.vim | 2 +-
src/testdir/test_put.vim | 48 +++
r checking and practice.
Thanks,
Jason Franklin
--
--
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 becaus
Hey Bram,
Just a friendly ping. Checking to see if you've had a chance to peek at this
change.
Thanks,
Jason
--
--
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
That seems to fix my problem. Thanks, Bram!
The cursor still "flickers" quite a bit. Is that to be expected with a job
that requires so much redrawing of the terminal window?
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are
It looks like the clearing of the command line we're seeing is done here:
https://github.com/vim/vim/blob/master/src/screen.c#L799
I'm finding it difficult to track down a solution, though... I just thought I'd
respond with what I found from a cursory look at the code involved.
--
--
You
System: Ubuntu 16.04, gnome-terminal
Vim Version: 8.1.62
So, I'm toying around with the Vim code. I ran "make test" in the vim/src/
directory in a Vim :terminal window. I then noticed that typing in an ex
command with : was difficult. I suppose that this is due to the fact that
"make test"
Thanks, Bram. Some notes...
> I could not reproduce this.
Strange. I was very careful to reliably replicate it on my machine...
In any case, I re-compiled with the patch, and I can no longer produce
what I was seeing. Weird. Perhaps I didn't include :set lazyredraw?
> Not sure what you
obey the 'lazyredraw' setting by using the logic
already in maketitle().
I would include a test, but I don't see a good way to grab the current title
being displayed.
Thanks,
Jason Franklin
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply be
I wanted to fix this myself, but I'm not having any fun fighting with the
Microsoft build tools. Hopefully, someone else has time to look into this
issue.
System: Windows 10
Vim Version: 8.1.0001
To reproduce:
:echo fnamemodify('C:\__nodir__\__nofile__', ':.')
You'll see that the
1 - 100 din 135 matches
Mail list logo
