) permits to have a
behaviour that really matches what happens when we type the exact same keys?
Or do we have no choices but to test more atomic sequences?
--
Luc Hermitte
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below th
bout editor-config: there is no neat way to specify
values for vim variables or options if need be. With the main editorconfig
plugin for vim, we cannot be sure a variable will be set before another one
which could be tedious to introduce dependencies.
--
Luc Hermitte
--
--
You received thi
practices. Typically, I'm often stuck with the version of vim shipped with
CentOS/RedHat 7 distributions. As such I cannot always migrate my plugin code
to use the latest improvements of Vim.
Any way, this is a nice improvement. Thanks for it. I'll definitively use it,
eventually.
--
L
s
would come from errors in the qf window)
If I was writing a UI for debugger, I would need more precise control to add
and remove breakpoints -- here performances don't really matter
[1] in https://github.com/LucHermitte/vim-compil-hints
--
Luc Hermitte
--
--
You received this message fr
lback based on screenchar() when the other solutions cannot be
used. I guess I'll cache the results so the user will only have to do suffer
from the check once.
I guess I'll require her/him to explicitly update the glyph cache when the
plugin is ran for the first time.
Thanks again
--
Luc Hermit
:let warning_sign = FirstSupportedAmong("\u26a0", "\u26DB", "!!")
--
Luc Hermitte
--
--
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
gt; CC=clang make foo
# prints: clangfoo.c -o foo
$> CC= make foo
# prints: foo.c -o foo
# and can't compile anything
$> unset CC # just to assert the situation
$> make foo
# prints: ccfoo.c -o foo
This is the recurrent use case I run into
> > I've run a simple test case in callgrind:
> >
> >> valgrind --tool=callgrind ./vim -U NONE -u NONE -c "echo
> >> glob('~/.vim/**/tags')" -c q
> >
> > On my current machine, I see vim_regexec() and vim_regcomp()
> > executed 14036 times, and taking respectively 41.72% + 15.67% of
> >
which yields no result on v 8.0.502, un-patched, and on my patched v8.0.563
If I understand the documentation correctly, this looks like a bug.
--
Luc Hermitte
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are re
> De: "'Jürgen Krämer' via vim_dev" <vim_dev@googlegroups.com>
> Luc Hermitte (Vim Github Repository) schrieb am 12.10.2016 um 10:40:
> > While I can't be sure, it looks like a limitation of |job_start|.
> > If there a workaround that works, it'd be interes
similar to feed into
:let or may be other commands.
--
Luc Hermitte
--
--
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 me
course this could be achieved with
:call setline(1, ['line1', 'line 2', 'Line 3'])
:let expected = ['Line 1', 'Line 2', 'Line 3']
But this'll be extremely cumbersome to maintain.
--
Luc Hermitte
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type yo
> On 18 August 2016, Luc Hermitte <hermi...@free.fr> wrote:
> > Another point on the qflist topic is bugging me. IIRC, when an
> > error is detected, the type flag is set to 'E'. But how is error
> > detection done? Is it when the message 'error:' is detected?
>
m/LucHermitte/vim-build-tools-wrapper/tree/job-compile
--
Luc Hermitte
--
--
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 m
ckfix list?
My mistake. I see we already have :caddexpr.
Thank you again!
--
Luc Hermitte
--
--
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
---
order to extract all data relevant for the quickfix
list/window and add that data to the quickfix list?
We can try to decode a line according to manually, but I'm quite sure Vim
already knows how to do it, and it'll be more efficient and more correct than
us.
Thank you
--
Luc Hermitte
--
-
Hi Bram,
> You wrote that when writing to a buffer close_cb isn't invoked. I
> added a test for it and it appears to work just fine.
Indeed. This is working fine now.
> Any special circumstances when close_cb is not invoked?
None. I've just updated vim code and recompiled vim, now it's
e
> of this. It would need an identifier for the quickfix list to
> add to.
May be. If it's fast enough to never get entered multiple times simultaneously,
it'll be perfect.
> > - Could we have a 'close_cb' callback that get notified when a pipe
> > filling a buffer (or a fil
as
another script isn't playing with setqflist/getqflist)
- it won't need to be aware the pipe is closed
- Could we have a 'close_cb' callback that get notified when a pipe filling a
buffer (or a file, or a quickfix window) is closed ? (I don't know if this
could be done)
thanks,
--
Luc Hermitte
)
" let self.job = job_start(['tests/repeat-wait.sh', 2],
" \ { 'out_io': 'file', 'out_name': self.buffer
" \ , 'close_cb': function('self.conclude', self)} )
endfunction
return comp.init(a:nb)
endfunction
>%
--
Luc Hermitte
--
--
ds I execute.
https://github.com/kana/vim-vspec provides another framework for testing
plugins.
My biggest issue is related to feedkey() that I wasn't able to use through
--remote-expr to trigger omni-completion. I had to find other way to test my
snippets.
Regards
--
Luc Hermitte
--
--
Hello,
I'm not sure whether sort() can be applied with 'n' parameter on lists of
strings that encode numbers.
Right now (v7.4-908) the result produced is: ['1', '5', '48', '25', '5', '28',
'6'] which is really odd.
Is this a vim bug, or an undefined behaviour?
Regards,
--
Luc Hermitte
Hi Jürgen,
- Mail original -
> > [...]
> > Is this a vim bug, or an undefined behaviour?
>
> see the fifth paragraph of ":help sort()". Note that Strings are
> explicitly mentioned "to be considered as being 0". Also read the
> second to last paragraph which explains why the order of the
>
> Well in select mode, everything you enter will replace the selection.
> So it works as expected I would say.
And yet nothing is inserted in INSERT mode. That's why I was quite intrigued.
Regards,
--
Luc Hermitte
--
--
You received this message from the "vim_dev" maillist.
gt; > Could we have a countword() function that would avoid such dirty
> > tricks?
>
> I'll look into this.
Thanks.
Regards,
--
Luc Hermitte
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replyin
Hello,
Tom Link wrote :
Which executable do you intend to execute in a cross-plattform
portable way?
(c)make/(b)jam/aap, gcc, doxygen, ctags, latex, ...
As far as I'm concerned, the need exists. I'd rather not require an external
executable/DLL though.
--
Luc Hermitte
http://lh
- Ingo Karkat sw...@ingo-karkat.de a écrit :
On 06-Feb-09 22:17, Luc Hermitte wrote:
BTW, a good Unit Testing framework is most welcomed. There is
already one, but it lacks quickfix integration, and a
simple :command-like syntax.
Luc, which unit testing framework are you talking
a similar purpose although it's still quite
minimalist.
I wasn't aware of your script. I'll give it a try.
Thanks for the link, and the work. ^^
--
Luc Hermitte
http://lh-vim.googlecode.com/
http://hermitte.free.fr/vim/
--~--~-~--~~~---~--~~
You received
for inspiration or
just to be the first brick of a stable, flexible and viable 'plugin'
system/foundation. It's based on personal experiments and from the
work of Marc Weber and Luc Hermitte.
Ah! You were already aware of our work. :)
As far as I'm concerned, I'd be glad to contribute
with my core
patching vim is the best course of action.
--
Luc Hermitte
http://lh-vim.googlecode.com/
http://hermitte.free.fr/
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
30 matches
Mail list logo
