Testing mappings that analyse the context
Hi,
I'm currently struggling to write a unit test for a mapping that analyses the
current line.
I've actually two mappings
< that inserts <|> (| being where the cursor ends up)
> that replaces <|> with
or that moves the cursor after the > character, in *|>
or that inserts >
When I test with either
normal obar
or
call feedkeys('obar', 'x')
I end up with " mapping is triggered, what was
previously injected isn't here yet: getline('.') returns "<>", without the
"foo" part.
If I force a break before the <, it works well
call feedkeys("oa>bar", 'x')
I suspect there is way to have a simple key sequence: indeed, when I use my
complete environment (vimrc & plugins), 'obar' is enough. With a clean '-u
NONE' environment, I cannot make it work. Impossible to find what makes the
difference in the thousands lines of extra-configuration.
A simplified (non-redoable, with less cases) version of the mappings would be
inoremap< <>
inoremap > getline('.')[col('.')-2:col('.')-1]=='<>' ?
'' : ''
Does anybody know what setting (or feedkeys() flags?) 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 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
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/2039254040.-606058657.1591183790039.JavaMail.root%40zimbra60-e10.priv.proxad.net.
Re: [proposal] Project Information for vim
Hi Very good initiative! > ## Project Information > > Vim can introduce a way to provide following information: > [...] > - buffer-local options > [...] > ### Locating project root > > The project root of current file is the nearest parent directory with > a folder named `.vimprj` (can be changed by set rootmarker=xxx) in > it. > > A buffer-specific variable `v:project` is used to store the project > root directory of current buffer, it is initialized when you open a > file as: > > ```VimL > let v:projectroot = fnamemodify(find(, '.;'), ':h') > ``` I've experimented on the subject: https://github.com/luchermitte/lh-vim-lib/blob/master/doc/Project.md What will be interesting is different than "buffer-local", it's "project-local". An option (/variable) changed in one buffer belonging to a project needs to be propagated to (or better shared with!) all buffers belonging to the same project. This way, instead of a v:projectroot, it would be a p:projectroot, a p:where_the_build_directory_is, a p:where_ctags_plugin_will_build_tags_files, a p:naming_policy, and so on. Regarding the remark about 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 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 "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.
Re: Don't use function!
Hi, > I have recently changed the behavior of :function to allow for > redefining (overwriting) a function when that should normally be > fine. > Therefore, using function! is hardly ever needed. > > [...] > Vim now checks the script ID of where the function was defined, and > whether that same script is being sourced again. This allows for > silently overwriting the function from the same script file, once. > > So, please stop using function! This is a very nice improvement. Alas as long as we wish to provide portable plugins we need to stick with old 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. -- 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 message because 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.
Re: RFC: VimL functions for managing signs
Hi,
---
> With this approach, the user doesn't have to pick a unique sign
> identifier.
> But this will be different from the current ":sign place" command
> where the user specifies the identifier. Does any of the plugins
> rely on the sign using a specific identifier?
In my plugins, I start using identifiers at a some random value (like 27000 or
whatever), and then I increment.
IOW, having an id automatically attributed is perfect with me.
Actually, the steps in my scenarios [1] are:
- clear all the signs (associated to my plugin) in all buffers
- add these batch of signs (to possibly several buffers)
If there was a notion of sign-group, it would be even more simple for me. The
scenarios would become
:if !exists('s:my_plugin_sign_grp ')
:let s:my_plugin_sign_grp = new_sign_group('my_unique_plugin_identifier')
:endif
:fucntion s:some_function() abort
:call clear_signs(s:my_plugin_sign_grp)
:call add_signs(s:my_plugin_sign_grp, [ {sign_defs}... ])
:endfunction
The advantage of such a solution, from a vim script point of view, is that I
could expect more performances to clear or add thousand of signs at once (signs
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 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
"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.
Re: Test whether a glyph can be displayed
Hi, > > Is there a way to test whether vim can display a glyph with the > > current font? > I don't think there is a good way, because especially in the terminal > Vim won't know what the result of a character will actually look > like. > Best way I can think of, put the character on the tabline. Then > capture the result and compare using `:echo nr2char(screenchar(1,1))` > > That is probably nothing that can be done without the user noticing > it (e.g. it most likely requires a redraw for the tabline to be > displayed before capturing the result and then hiding and restoring > the tabline again). Thanks for the idea Christian. So far, I've played with fc-list and with python+fontconfig module when fc-list is too old. Indeed, I don't see any other native and portable way to do it, other than the one you propose. I'll add a fallback 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 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 message because 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.
Test whether a glyph can be displayed
Hi,
Is there a way to test whether vim can display a glyph with the current font?
Given it defaults to some made-up glyphs I suspect it has a way to do it
internally, but I haven't found in the doc whether this information is exposed.
The objective is to be able to select the fallback solution
: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.vim.org/maillist.php
---
You received this message because 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.
Re: [vim/vim] `:unlet $FOOBAR` (#1116)
Hi,
> OTOH, on Linux, after assigning the empty string, exists('$FOOBAR')
> still returns 1, while ":unlet $FOOBAR" gives error E488: Trailing
> characters.
>
> The classical way to test for "empty or undefined" is
>
> if ("X" . $FOOBAR) == "X"
>
> which, AFAICT, returns true even if $FOOBAR is undefined (i.e. has
> never been set in this environment).
We can also test for "is set" with
[[ -n ${FOOBAR+x} ]] && echo 1
or more simply with bash 4.2+
[[ -v FOOBAR ]] && echo 1
Anyway, the distinction becomes interesting as a few programs interpret the
unset state as "use a default value", while an empty string really means an
empty string.
Given foo.c, and a properly configured gnumake (i.e. not MinGW make), the
following will yield different results
$> 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 that's behind the issue I've opened a
while back.
Regards,
--
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 message because 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.
Re: Poor performances of glob('**/pat')
> > 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
> > unix_expandpath() (lr) cycles measured by callgrind.
>
> Off-topic, could you share what tool you used to get the relative
> time costs of the callgrind results? Or is that just the ratio of
> call *counts*, not wall-clock cost?
I've used kcachegrind and requested to display the percentages relative to the
parent function which has the focus. To do so I had to made sure two buttons
were pushed.
This way, in the scope of unix_expandpath() I had the ratio of cycles spent in
each callee. This may not be proportional to what would precisely happen, but
it gives a rough idea of the bottlenecks.
In another project, I took a snapshot of what kcachegrind displays:
https://wiki.orfeo-toolbox.org/index.php/File:AfterOptims-Warp.png You should
see the 2 buttons: "% Relative" and "+ Relative to parent"
--
Luc
--
--
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
"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.
Poor performances of glob('**/pat')
Hi,
I've observed a poor performances issue when using glob(starstar/whatever).
I know this is a known issue, I just had to look at the first lines of
unix_expandpath().
And yet, we could do better. Much better.
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 unix_expandpath() (lr) cycles
measured by callgrind.
Investigating further, I've seen that simply by caching `regmatch.regprog` when
`starstar` is true and `e-s==2`, vim_regcomp() is executed now only **once** on
my test case. From 363879003 cycles in unix_expandpath() I do down to
291294681. This looks like a good start.
static regprog_T *reg_starstar = NULL;
if (!reg_starstar) {
reg_starstar = reg_starstar_compute();
}
...
if (starstar && (e-s == 2))
{
onlystarstar = TRUE;
regmatch.regprog = reg_starstar;
if (regmatch.regprog == NULL) {
vim_free(buf);
return 0;
}
} else { old code, rearranged, of course }
And I wonder. Do we really need to apply regmatch when we know we are in a
"starstar" situation? Can't we simply go down to the next sub-directory?
BTW, on another topic, I've also executed
> vim -U NONE -u NONE -c "echo glob('~/.vim/**5/tags')" -c q
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 replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because 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.
Re: [vim/vim] Injecting `$VAR` in `job_start()` calls (#1158)
> 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 interesting to document > > it. > > Note that the last paragraph says that the first item of the list is > an executable. > > Further down the help says > > | The command is executed directly, not through a shell, the > | 'shell' option is not used. To use the shell: > > [...snipped...] > > You provided different variations of a shell command, but they were > all interpreted as the name of an executable. Indeed Jürgen, you're right. My mistake. -- 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 message because 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.
Re: Write block of raw text
Hi, > > Is there a command somewhere to put or let block of raw lines in > > VimL. > > To "put" you could use: > insert > line 1 > line 2 > Line 3 > . Thanks. I forgot about this one. I'll see after the v8 release if we could have something 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 message because 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.
Write block of raw text
Hi,
Discl.: AFAIK the following doesn't exist (yet?) in Vim, but I may have missed
it.
Is there a command somewhere to put or let block of raw lines in VimL.
I'm perfectly aware of append() and setline(), but I'm looking for something
that'll let me write things like:
:put << EOF
line1
line 2
Line 3
EOF
" + code like: %s/\v\s*(.{-})\s*\ze\d/\u\1 /
And also
:let expected << EOF
Line 1
Line 2
Line 3
EOF
The objective is to be able to write unit tests with as few boilerplate code as
possible in order to assert ll == getline(1, '$').
Of 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 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
"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.
Re: Vim 8 pre-announcement
> 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? > > What about when the locale is in another language like 'fr_FR'? > > In this case, the error messages start with "erreur: ", warnings > > with "attention: ". I guess similar issues may happen in all > > other languages. > > > > Has anybody an idea how to solve error/warning detection when the > > system is not in English? (My ultimate objective is to fill the > > error and message counters displayed by the airline plugin in the qf > > window status line) > > Set LC_MESSAGES to C before running your program: > > https://goo.gl/tMPUdV > > Less than ideal, but it makes parsing possible. Of course, I'm aware of this solution -- which I use regularly as I can't stand the translation of compilation errors. What I was hoping, is a end-user friendly solution: one that implies as few tweaks as possible to fully take advantage of my plugin. -- 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 message because 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.
Re: Vim 8 pre-announcement
Hi, > De: "Yegappan Lakshmanan" <yegapp...@gmail.com> > I am in particular interested in any comments/suggestions about the > following new functions: > > getqflist() > setqflist() I've been playing in my build-tools-wrapper plugin (*) with the new job + setqflist functions. I've to say: good job, and thank you all! However, the fact that calling setqflist() with the old interface changes the qf window title is a bit cumbersome. Once I've found it was easy to fix from my plugin. 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? What about when the locale is in another language like 'fr_FR'? In this case, the error messages start with "erreur: ", warnings with "attention: ". I guess similar issues may happen in all other languages. Has anybody an idea how to solve error/warning detection when the system is not in English? (My ultimate objective is to fill the error and message counters displayed by the airline plugin in the qf window status line) (*) https://github.com/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 message because 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.
Re: Invoking close_cb when writing to a buffer
> The only pending action, as far as I'm concerned, but may be it's > already possible through other means: can we have a addqfline(line) > VimL function that applies to the line in order to extract all > data relevant for the quickfix list/window and add that data to the > quickfix 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 --- You received this message because 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.
Re: Invoking close_cb when writing to a buffer
Hi Bram, > The problem I still have in the todo list is that a callback would be > invoked recursively. Do you still see that problem? I wouldn't say it was called recursively. Just re-entered. Like when we re-enter a sigaction that hasn't finished when its signal is emitted multiple times and to rapidly . Anyway, I don't see any trouble now with the new version. It seems to work fine. Thank you. The only pending action, as far as I'm concerned, but may be it's already possible through other means: can we have a addqfline(line) VimL function that applies to the line in 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 -- -- 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 "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.
Re: Invoking close_cb when writing to a buffer
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 working fine. I use it from these functions in case you want to see what I did. -> https://github.com/LucHermitte/vim-build-tools-wrapper/blob/job-compile/autoload/lh/btw/job_build.vim May be this was related to v 7.4-1829 and since then you've fixed something in the internals. I can restore old code base to test again if you want. But as far as I'm concerned, this feature is implemented and it doesn't deserve any more actions. Thanks you. --Luc -- -- 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 "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.
Re: RfC for background compilation with job_start
Hi Bram, > > > I've been experimenting how to compile in background thanks to the > > new job_start() feature (and without depending on Python) > > [...] > > > > 1- We plug a channel to compilation outputs with 'callback' > > callback. > > [...] > > - The 'callback' callback needs to be re-entrant because it'll be > > re-entered. This is quite complex to achieve if the function does > > too many things. For instance, I tried to decode the message > > received according to and then populate the qflist from my > > new qf-entry, and unfortunately, the callback was called again > > while the precedent call was still processing. In the end, I had > > crashes. > > It's not obvious to me why this function needs to be reentrant. > Perhaps we still have a place where a callback is invoked when > it's not "safe". > I added an error message when this happens, that might not be > sufficient. I already have a todo item for this, it would be helpful > to know when it happens, e.g. if you have a channel log. See attached an experiment (which requires my lh-vim-lib library (1) -- let me know if you want a minimal working example out of this) where the callback function takes too much time to process and is re-entered. Various kind of errors are possible: it ranges from strange errors thrown from the callback function (directories popped before being pushed), to crashes IIRC. If we uncomment the calls to sleep, everything works fine, but this is not realistic. > > - > > > > So, my questions / RfCs. > > - As there is also a 'buffer' and a 'file' modes for 'out_io' and > > 'err_io', could we also have a 'quickfix' mode ? > > I guess this is what would provide the best user experience as > > - it could be built upon 'buffer' mode, > > - it could have a direct access to messages decoding with , > > - it would be fast, > > - and as a consequence it won't suffer reentrancy issue, much (as > > long as another script isn't playing with setqflist/getqflist) > > - it won't need to be aware the pipe is closed > > A quickfix mode for the channel seems a bit too specific. It's > probably more useful to have a quickfix function that takes care > 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 file, or a quickfix window) is closed ? (I > > don't know if this could be done) > > We know when the pipe gets closed, this should be possible. Thanks, (1) https://github.com/LucHermitte/lh-vim-lib -- 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 message because 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. job-interactive.vim Description: Binary data repeat-wait.sh Description: application/shellscript
RfC for background compilation with job_start
Hi, I've been experimenting how to compile in background thanks to the new job_start() feature (and without depending on Python) So far, I've played with two approaches where I've found some drawbacks. Please note that if there are better ways to proceed, I'm interested to know them. 1- We plug a channel to compilation outputs with 'callback' callback. Pro: - We can also register a callback to 'close_cb'. This permits to know immediately when the compilation has finished. Cons: - We need to decode manually the messages received if we wish to populate the quickfix window on the fly. AFAIK, the internal function vim uses to decode outputs isn't exposed to vim scripts. - The 'callback' callback needs to be re-entrant because it'll be re-entered. This is quite complex to achieve if the function does too many things. For instance, I tried to decode the message received according to and then populate the qflist from my new qf-entry, and unfortunately, the callback was called again while the precedent call was still processing. In the end, I had crashes. If I guess correctly the situation, it'll be extremely difficult to have the 'callback' callback block until its processing is done. 2- We plug a buffer to compilation outputs with 'out_io' and 'err_io' Pro: - There no reentrancy issue - A buffer can be filled and its window updated automatically as the compilation proceeds. Con: - I haven't found any way to know immediately that the internal pipe is closed. 'close_cb' is never called. We can only rely on 'exit_cb' which isn't as reactive - The buffer cannot be analysed on the fly to populate the quickfix window. - So, my questions / RfCs. - As there is also a 'buffer' and a 'file' modes for 'out_io' and 'err_io', could we also have a 'quickfix' mode ? I guess this is what would provide the best user experience as - it could be built upon 'buffer' mode, - it could have a direct access to messages decoding with , - it would be fast, - and as a consequence it won't suffer reentrancy issue, much (as long 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 -- -- 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 "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.
Crash when the close_cb is a dict function
Hi,
I've been playing with job_start to see what can be achieved with it, and I
observe a crash with the following code on vim 7.4-1829 (compiled on an ubuntu
x89_64 machine)
It seems related to the fact I use a dict function as callback.
I may no have the correct syntax, yet the crash is certainly not a correct
behaviour.
The backtrace is:
>%
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x7db26)[0x7f4aeaa83b26]
gvim[0x47d165]
gvim(dict_unref+0x2f)[0x47d1df]
gvim(partial_unref+0x5a)[0x47c24a]
gvim(channel_close+0x1a3)[0x5f64a3]
gvim(channel_parse_messages+0xf4)[0x5f7064]
gvim(parse_queued_messages+0x13)[0x50bd23]
gvim(gui_mch_wait_for_chars+0x3b)[0x5de07b]
gvim[0x5ce86b]
gvim(gui_wait_for_chars+0x87)[0x5d0647]
gvim(ui_inchar+0xe4)[0x5bda04]
gvim(inchar+0x12f)[0x4d3ccf]
gvim[0x4d5cc9]
gvim(vgetc+0x16d)[0x4d64bd]
gvim(safe_vgetc+0x9)[0x4d6859]
gvim(normal_cmd+0xed)[0x5217bd]
gvim(main_loop+0x375)[0x5fda15]
gvim(main+0x1474)[0x44c264]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7f4aeaa2776d]
gvim[0x44d58d]
>%
and the (semi-minimalist) test program is the following
>%
" Attempt at non-interactive background compilation
"
" Compilation messages are analysed at the end of the compilation process
function! s:conclude(channel) abort
echomsg "Compilation finished"
exe 'cgetfile ' . s:buffer
endfunction
function! Build_comp(nb)
let comp = {}
" redundant version that crashes vim as well.
function! comp.conclude(channel) dict abort
echomsg "Compilation finished"
exe 'cgetfile ' . self.buffer
endfunction
let comp.conclude = function('s:conclude')
function! comp.init(nb) dict abort
" let self.buffer = tempname()
let s:buffer = tempname()
" tests/lh/repeat-wait.sh prints stuff to stdout
let self.job = job_start(['tests/repeat-wait.sh', a:nb],
\ { 'out_io': 'file', 'out_name': s:buffer
\ , 'close_cb': function('s:conclude', self)} )
" 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
--
--
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
"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.
Re: Runtime files
Hi, > Anything we can do to make it easier for plugin authors? A big > improvement would be if plugins would write tests that we can run > against different Vim configurations. I haven't seen plugins with > tests though... There are a few plugins doing automated tests. And of course, each has taken a different path. For instance, I have a few plugins with automated tests. See for instance lh-cpp: https://github.com/LucHermitte/lh-cpp which has both unit tests that can fill quickfix window and more elaborated tests where I check what the buffer contains after the commands 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 -- -- 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 "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.
Odd result for sort([ '1', '5', '48', '25', '5', '28', '6'], 'n')
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 -- -- 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 "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.
Re: Odd result for sort([ '1', '5', '48', '25', '5', '28', '6'], 'n')
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 listed > items does not change. > Damn. I missed it. Thank you! Regards, --Luc -- -- 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 "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.
Re: words counting and select mode.
> > The thing is that I wasn't sure why the > >:exe "silent normal! g\" > > > > behaved differently in SELECT-mode while it seemed to cause no > > trouble in VISUAL and INSERT mode. Hence my report in case this > > wasn't a feature but a bug. > > 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. 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 "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.
Re: words counting and select mode.
Hello, > [...] > You should report this to vim-airline. This is already done and fixed. The thing is that I wasn't sure why the :exe "silent normal! g\" behaved differently in SELECT-mode while it seemed to cause no trouble in VISUAL and INSERT mode. Hence my report in case this wasn't a feature but a bug. > > For reasons I'm not sure to completely understand, this line works > > fine in visual mode, but not in select mode. > > If I put this line behind a "if mode() =~? 's' | return", I have my > > workaround. > > > > 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 replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because 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.
Re: Improved integration between Vim and its environment (full-screen, open URL, background execute())
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-vim.googlecode.com/ http://hermitte.free.fr/vim/ -- 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
Re: Vim Lib [Was: List Questions]
- 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 about? The one written by Staale Flock, and available on sf. I'm currently building one for testing my own scripts, as manual regression testing soon becomes too tedious. (I plan to publish my framework in a few weeks, right now the test runner only works on Windows.) My few requirements, in case it helps: - we should be able to test values with very simple things like: :Assert value 42 - the result should end in the quickfix window (which implies a first pass on functions/files to determine the current line where the Assert is used) - it would be nice to test mappings/commands/abbreviations/... definitions, buffer alterations, etc. - setup/teardown support would be nice also. -- Luc Hermitte http://lh-vim.googlecode.com/ http://hermitte.free.fr/vim/ --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Vim Lib [Was: List Questions]
Tom Link micat...@gmail.com wrote: Luc, which unit testing framework are you talking about? A vim.sf.net search points to http://www.vim.org/scripts/script.php?script_id=1125 That's the one. I once wrote http://www.vim.org/scripts/script.php?script_id=1730 that is supposed to solve 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 this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Vim Lib [Was: List Questions]
Hello, Agathoklis D. Hatzimanikas a.hat...@gmail.com : So for a start, I am proposing a VimLib project, maintainable by the Vim community, written entirely in VimL and except from one function (see below) it will independent from the vim official distribution. So far there are two such projects I'm aware of. I'm maintaining one [see my signature], and Marc Weber another one. We have already considered merging parts of what we have written so far. Unfortunately I don't much time for vim right now, and I'd like to finish my boost::bind-like autoload plugin first. BTW, a good Unit Testing framework is most welcomed. There is already one, but it lacks quickfix integration, and a simple :command-like syntax. A developer that wants to utilize such a function, should include on the top of the implementation, a standard code block to request the function. I totally agree with the approach. The NIH syndrom is nice but quite tiring on the long run. Problems that have to be resolved, or things that have to be done: - a mailing list; a vim_plugin perhaps - a host for the project (code google?) That's where I'm hosting all my scripts. The hosting is nice so far, however I'm not happy with the wiki which is quite limited. - a version control system (svn, mercurial or git are popular and portable solutions (there is a git port for windows I think)) Marc had a git or mercurial solution in mind. I don't remember exactly. Possible system enhancements or things that need decisions: - a function database May be we can just start small with what we currently have. - separation of the implementation and the configuration - a quoting from Bram: If there is one thing I would like to work on, given enough time, is to compile Vim script into some kind of byte code. that will give a boost to the plugin performance Marc had interesting thoughts on versionning that should be addressed in the earliest stages preferably (is it English?). That was just a first draft, that can be serve 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 library plugins (lh-vim-lib, and may be lh-map-tool (even if people seems to like reimplementing placeholder related functions and mappings)) But it's really up to the community to create something exciting, practical and useful, for the benefit of the current user base and for the next generation of vim users. Indeed. -- Luc Hermitte http://lh-vim.googlecode.com/ http://hermitte.free.fr/vim/ --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: reverse recursive .vimrc
Hello, fnegroni [EMAIL PROTECTED] wrote: [...] I am about to embark in developing such feature for vim and will make it available as a patch, if there isn't one already available. Have a look at the two local_vimrc plugins on sourceforge. They already provide this feature. I'm not sure 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 -~--~~~~--~~--~--~---
