On Tuesday, May 14, 2019 at 12:17:06 PM UTC-4, yega...@gmail.com wrote:
> Hi,
>
> On Sat, May 11, 2019 at 10:12 AM Manuel Ortega wrote:
> >
> > On Friday, May 10, 2019 at 5:20:08 PM UTC-4, Bram Moolenaar wrote:
> >
> > > I think that's the best way we provide this functionality. But I like
> >
I use Ingo Karkat's UnconditionalPaste plugin a lot, especially the
glp command when I've copied something character-wise and want to
paste it line-wise.
I've noticed on Windows, that if I copy text from some other Windows
program and attempt to paste into gvim using the glp command, I get
this
> You are right, the changes are flushed before adding one that changes
> the line numbers, but the text has already changed. I'll see how that
> can be fixed...
Thanks very much for the quick fix; I've confirmed it's working.
Thanks again for your patience; I think I now have a sufficient
Patch 8.1.1336
Solution: Add a few more test cases. (Masato Nishihata, closes #4374)
Files: src/testdir/test_bufline.vim, src/testdir/test_cindent.vim,
src/testdir/test_cursor_func.vim, src/testdir/test_delete.vim,
src/testdir/test_expand_func.vim,
Patch 8.1.1335
Problem:Listener callback is called after inserting text.
Solution: Flush the changes before inserting or deleting a line. Store
changes per buffer.
Files: src/change.c, src/proto/change.pro, src/memline.c,
src/structs.h,
Paul Jolly wrote:
> > > Again, apologies if I'm missing something obvious here.
> >
> > This is not inserting a line but splitting a line. There could be text
> > after the insertion point, which moves to the next line when pressing
> > Enter. In your case there might be nothing, but that
> > Again, apologies if I'm missing something obvious here.
>
> This is not inserting a line but splitting a line. There could be text
> after the insertion point, which moves to the next line when pressing
> Enter. In your case there might be nothing, but that doesn't cause a
> different change
Patch 8.1.1334
Problem:When buffer is hidden "F" in 'shortmess' is not used.
Solution: Check the "F" flag in 'shortmess' when the buffer is already
loaded. (Jason Franklin) Add test_getvalue() to be able to test
this.
Files: src/buffer.c, src/evalfunc.c,
Jason Franklin wrote:
> To reproduce:
>
> $ ./vim --clean # at latest commit on master
>
> :set hidden shortmess+=F
> :e file1
> :e file2
> " Notice, no messages are output, as expected.
> :bn
> :bp
> " Notice fileinfo messages are output.
>
> The main
Paul Jolly wrote:
> > The help is wrong, it should say "line above which".
> > Of course we could change the implementation, but it would be an exception.
>
> Ah, if it's "line above which" then I think there is a problem with
> the following sequence:
>
> iasdf
>
> which gives:
>
>
> The help is wrong, it should say "line above which".
> Of course we could change the implementation, but it would be an exception.
Ah, if it's "line above which" then I think there is a problem with
the following sequence:
iasdf
which gives:
[{'lnum': 1, 'col': 1, 'added': 0, 'end': 2}]
Paul Jolly wrote:
> > I'll make a patch that does this, please check it out.
>
> Hi Bram - I've only spotted one potential issue working with v8.1.1333.
>
> Using the following vimrc
>
> function EchoChanges(bufnr, start, end, added, changes)
> redir >> /tmp/listener.log | echom a:changes
To reproduce:
$ ./vim --clean # at latest commit on master
:set hidden shortmess+=F
:e file1
:e file2
" Notice, no messages are output, as expected.
:bn
:bp
" Notice fileinfo messages are output.
The main problem appears to be in the enter_buffer() function:
> I'll make a patch that does this, please check it out.
Hi Bram - I've only spotted one potential issue working with v8.1.1333.
Using the following vimrc
function EchoChanges(bufnr, start, end, added, changes)
redir >> /tmp/listener.log | echom a:changes | redir END
endfunction
call
> > See https://github.com/vim/vim/issues/3127 for that I think.
>
> Indeed, just so long as this is triggered for all visible windows when
> their viewport changes (e.g. window resize)
Sorry, that sent too quickly. I meant to finish by saying thank you
for linking to that issue; I've now added a
> See https://github.com/vim/vim/issues/3127 for that I think.
Indeed, just so long as this is triggered for all visible windows when
their viewport changes (e.g. window resize)
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are
On Do, 16 Mai 2019, Paul Jolly wrote:
> > This doesn't exist yet. To consider such an addition:
> > - - Is there a need? Now, we've already got at least two use cases (from
> > you and me).
> > - - Is it easy to implement with few changes? You say it is.
> > - - Does it help improving
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 13-May-2019 21:20 +0200, Edward Peschko wrote:
> All,
>
> I'd like to be able to write a macro that could be triggered each time
> the line changed - so that I could write an autocmd to say
> automatically split a logfile in vim that has stack
I suggest making your changes in your own git branch. My workflow is
git checkout master
git pull
git checkout john
git merge master
I find this cleaner and more flexible than git stash.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your
Hi,
2019/5/16 Thu 15:50:40 UTC+9 Ni Va wrote:
> Le mercredi 15 mai 2019 10:19:04 UTC+2, Ken Takata a écrit :
> > Hi,
> >
> > 2019/5/15 Wed 16:07:17 UTC+9 Ni Va wrote:
> > > Le vendredi 3 mai 2019 00:36:56 UTC+2, Blay263 a écrit :
> > > > On Tuesday, April 30, 2019 at 11:36:39 AM UTC-4, Blay263
Le mercredi 15 mai 2019 10:19:04 UTC+2, Ken Takata a écrit :
> Hi,
>
> 2019/5/15 Wed 16:07:17 UTC+9 Ni Va wrote:
> > Le vendredi 3 mai 2019 00:36:56 UTC+2, Blay263 a écrit :
> > > On Tuesday, April 30, 2019 at 11:36:39 AM UTC-4, Blay263 wrote:
> > > > On Tuesday, April 30, 2019 at 3:31:31 AM
21 matches
Mail list logo
