Using the attached script with 7.4.1795, Vim reliably crashes when
freeing the job and operator-pending mode is active.
$ vim -u NONE -N foo.vim
:source %
d
" Wait for 10 seconds or so to ensure the job gets automatically freed
GDB shows the stack at the time of the crash as:
On Thu, Apr 18, 2013 at 4:58 PM, glts 676c7...@gmail.com wrote:
Hi,
I have recently learnt of a patch that was submitted to the list almost
five years ago. Please see here:
https://groups.google.com/d/msg/vim_dev/lR5rONDwgs8/iLsVCrxo_WsJ
The reception was positive but for some reason the
On Apr 19, 2013, at 5:50 PM, glts 676c7...@gmail.com wrote:
...
Here's a good real-life example.
The textobj-word-column.vim plugin lets you select a column (Visual
block) of words/WORDs based on the word/WORD under the cursor. If
v:motiontype were available, the plugin could let you
On 18-Apr-2013 16:16 +0200, glts wrote:
Hi,
I have recently learnt of a patch that was submitted to the list almost
five years ago. Please see here:
https://groups.google.com/d/msg/vim_dev/lR5rONDwgs8/iLsVCrxo_WsJ
Oh dear, I remember that! It's frightening how quickly time passes :-)
Ingo,
On Fri, Apr 19, 2013 at 8:58 PM, Ingo Karkat sw...@ingo-karkat.de wrote:
On 18-Apr-2013 16:16 +0200, glts wrote:
As for the name of the variable, how about:
v:motiontype
The documentation says that when no motion type is given the variable
will be empty, when an explicit motion
On Saturday, April 20, 2013 6:50:58 AM UTC+9, glts wrote:
On Fri, Apr 19, 2013 at 8:58 PM, Ingo Karkat wrote:
With v:motiontype, I'd expect that to be applicable to _every_ motion,
not just those few special ones. I would prefer v:forcedmotiontype. The
only saving grace for this unreadable
Hi,
I have recently learnt of a patch that was submitted to the list almost
five years ago. Please see here:
https://groups.google.com/d/msg/vim_dev/lR5rONDwgs8/iLsVCrxo_WsJ
The reception was positive but for some reason the discussion was
abandoned. I would like to reopen the discussion. I'd
David Bürgin wrote:
I have made a simple new test covering Visual mode and operators. All
tests are green for the current Vim version 7.3.875.
I think it would be useful to have a test to guard against regressions
in this area; it may also serve as a basis for discussion of bugfixes
and
On Wednesday, March 6, 2013 4:43:56 PM UTC-6, glts wrote:
While investigating an item on the todo list, I found out that the
behaviour of :normal[!] in operator-pending mode is not well-defined: it
is not documented and is not taken special care of in the source.
Consider
it mentioned
explicitly) but if I recall correctly, any : command in operator-pending
mode acts as an exclusive motion.
Yes, I did see that in the code for the colon command at normal.c#5398:
if (cap-oap-op_type != OP_NOP)
{
/* Using : as a movement is characterwise exclusive
if this is documented (I couldn't find it mentioned
explicitly) but if I recall correctly, any : command in operator-pending
mode acts as an exclusive motion.
Yes, I did see that in the code for the colon command at normal.c#5398:
if (cap-oap-op_type != OP_NOP)
{
/* Using : as a movement
While investigating an item on the todo list, I found out that the
behaviour of :normal[!] in operator-pending mode is not well-defined: it
is not documented and is not taken special care of in the source.
Consider the following text with the cursor on the first m:
summer
for commands starting with g or z,
+ in which case it is two characters. Best used alongside
+ |v:prevcount| and |v:register|. Useful if you want to cancel
+ Operator-pending mode and then use the operator.
+ :omap O Esc:call MyMotion
normal [(
endwhile
exe normal \BS\_yiw
echo 'normal '.(last_count0?(last_count):'').''.last_reg.last_op.'e'
endfun
I see. In general the reason we need v:operator would then be that you
need it for situations where you need to get out of operator pending
mode, move
David Fishburn wrote:
This is very useful for me, but I suspect other plugin developers will
also benefit since they can make smarter functions by looking at what
the user has keyed in.
Well, I can see that you get the information, but this is not really a
useful real-world
On 30/10/2007, Ben Schmidt [EMAIL PROTECTED] wrote:
Very happy to modify the patch to document this. It does not include the
count;
that is what v:count is for. And it will be two characters for commands
that begin
with 'g' or 'z', and one character otherwise.
Happy to include an example
On Oct 30, 1:38 pm, Bram Moolenaar [EMAIL PROTECTED] wrote:
Ben Schmidt wrote:
3. Don't know about v:operator (works for me), the showcmd option
means it could also be v:command or v:operatorcommand (since there is
...
I'm not quite convinced adding v:operator is useful. What would help
On 10/30/07, Bram Moolenaar [EMAIL PROTECTED] wrote:
David Fishburn wrote:
On Oct 30, 1:38 pm, Bram Moolenaar [EMAIL PROTECTED] wrote:
Ben Schmidt wrote:
3. Don't know about v:operator (works for me), the showcmd option
means it could also be v:command or v:operatorcommand
Well, I can see that you get the information, but this is not really a
useful real-world example. Think of a user that wants to get something
done for which v:operator is needed. And for which there is no other
solution.
Here's a somewhat naively implemented example where a custom
Well, I can see that you get the information, but this is not really a
useful real-world example. Think of a user that wants to get something
done for which v:operator is needed. And for which there is no other
solution.
Here's a somewhat naively implemented example where a custom
[CCing this to the mailing lists; only went to Bram before, but some parts may
be
useful for others.]
I'm not quite convinced adding v:operator is useful. What would help is
giving a couple of examples how it's used. Also, in the docs for
v:operator it would be good to have a few examples
21 matches
Mail list logo
