fun! Dummy()
let g:test = 1
augroup RESIZE
autocmd VimResized * if g:test == 1 | let g:test =2 | endif
augroup end
for j in range(0,200)
for i in range(0,5000)
let x = 7
endfor
endfor
echoe g:test
let g:test = 0
endf
What do I expect? If I run "my viml" code I expect that that viml code
does not get interrupted. Because I cannot prevent Vim from doing so
because VimL does not have locking features.
What do I expect? That the resize handler gets run after the two for
loops finish. Thus I echoe to echo the initial value 1.
If I resize while the loops are running I get 2 which means that the
resize handler was run in between.
It is a hypotetical case.
Real use cases I've been suffering from:
If you call into Vim using client-server vim tends to segfault. I never
debugged it. Also evaluation errors are not shown.
Also client-server actions gets run at arbitrary times, eg when editng
in a command window.
What is the current issue? We want to improve python.
:py while True: x =7
Vim hangs. That's fine. You cannot stop it (bad).
You use xkill - window is gone - vim continues to run. Bader.
Yes this happens often, eg if you try to parse the output of external
tools such as sbt (simple build tool for scala).
When I wrote vim-addon-sbt it drove me crazy.
Now python can be interrupted easily by calling:
PyErr_SetInterrupt();
The issue is that its hard to call this function if Vim doesn't notice
that the user has pressed ctrl-c.
For the console case it can be fixed by catching the signal SIGINT.
Not quitting on sigint is quite common. Eg gdb does not quit.
The problem is: I don't want to mess with signals unless I understand in
which way they are used. Eg now I start wondering why ctrl-z (suspend)
should not work when vim is doing some work. It should be me deciding
upon when to supsend Vim ? Because I don't know I cannot just provide a
patch setting different terminal mode for the the time Do_PyCommand is
executed.
At least I understand that the terminal vim python ctrl-c case is
fixable.
Now what about the gui case? Using kill -SIGINT vim-pid works, but its
not user friendly, because users are used to ctrl-c because it always
worked fine for VimL.
The problem is Vim is running one thread only. And that thread (which
usually waits in the g_object_* main loop) is executing vim - thus no
key inputs can be recieved. ctrl-c is they key I'd be looking for.
How to fix? Introduce a thread continuing to recieve key presses.
However I cannot simply create a thread and call the main event loop
(gtk) - while python is running. Because python might be calling into
Vim, The main event gui event loop could recieve (you've been resized)
events - and two threads would be executing viml at the same time.
This is very likely to cause a crash very soon.
I have three choices
- fix
- live with it
- choose another tool
Also man "signal" says that "sigaction' should be preferred, because
semantics of signal are not well defined.
At this point I would touch much history without knowing what I could
break. I don't even know on which systems Vim still gets compiled
So I'm lost - I don't know whether I should even try to touch and fix -
or whether I should fork - thinking "only my linux box is important,
its me using Vim" - or I can ask for help - hoping that others having
more insight assist me.
I want simple features like
:make-interactive
which should behave like make, but while filling quickfix allowing the
user to continue using vim. It should no longer echo the lines fist,
then load into quickfix. It should fill the buffer window right ahead
(maybe autoscroll down or not)
Just try this:
:set makeprg=seq
:make 2000
It takes about 2 secs.
try time seq 2000 in your terminal. (0.014 total)
same applies for :grep
Is it only me? I asked at #vim: Summary:
doomedbunnies> Bit under 4 seconds for me, using MacVim.
romainl> yeah, maybe 2 secs on this new iMac
donri> MarcWeber: 4.310 seconds to run :make 2000
Is scrolling 2000 lines really that hard? Its not only my ati
proprietary driver then. Soon I started to use :!seq XXX
to test my graphic hardware ..
Oh - and having buildsystems or grep output many 2000 lines is quite
common if you enable basic debugging features.
Yes - again - its my problem only - the same as the development workflow
Rather than complaining I want to get my hands dirty and improve those small
annoyances.
How should it be?
While the process is running feed output into the quickfix cycle.
Every 1/20th sec sync (scrolling down) or such. Lines would be shown
only once, when done append "exited with code XX". When targeting the
same buffer kill an already running process
Then
- you'd see that the process is running
- things would be fast always on any hardware
- you would not see lines scrolling by twice.
So adding a new call interactive_gather_output('command-line',
'auto-scroll yes/no') would be all making me happy - along with some
simple quickfix related parsing - and that without hacks.
That's why its so important to me to get any common interpreter
implementation right.
I love Vim, I use it everday which is why I want to change those small
remaining issues getting into my way rather than complaining about it.
However I fear getting my started because I don't even know which
systems to test. Eg :helpgrep os2 or OS2 or grepping for the same in
source tells me: Vim has support for it. But I have no idea whether
this backends should still be maintained or not.
So does a list of supported operating systems exist - are people willing
to tell that they are still using recent Vim on such exotic systems?
If I cannot test, I cannot change. (Because Vim should be backward
compatible forever)
And currently I'm not even sure what to test. So is there an official
list of supported platforms which will be maintained?
Sorry for being noisy - yes - its me having problems. Otherwise I'd be
a happy silent user, sure.
Needless to say that emacs gets :!seq 2000 right easily using its m-x
grep feature. I do no longer want to suffer just because of using (g)Vim.
Of course, the problem is always the user - having chosen "the wrong
tools" for job - never the software. I agree on that.
Marc Weber
--
--
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/groups/opt_out.
