x-itec / conque

Automatically exported from code.google.com/p/conque
0 stars 0 forks source link

can't type anyth #55

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Open vim
2. :ConqueTerm [python, bash, etc.]
3. Type something

What version of the product are you using? On what operating system?
conque 2.1 on GVim 7.3.198 on Pardus 2011 GNU/Linux.

Whenevery I type something at ConqueTerm buffer, I get this error:
  Error detected while processing function conque_term#key_press:
  line 1:
  E523: Not allowed here

Here's a screensnot: http://img27.imageshack.us/i/conqueerr.png/

Thanks

Original issue reported on code.google.com by omeraga...@gmail.com on 26 Jun 2011 at 8:29

GoogleCodeExporter commented 8 years ago
I also see this behavior with MacVim snapshot 59 (Vim 7.3.237) and tty-based 
Vim 7.3.237 from MacPorts.

I have successfully used the same version of Conque (2.1) with MacVim snapshot 
57 (7.3.107).

I setup a 'verbosefile' and found this:

    line 0: py ConqueTerm_1.auto_read()
    line 0: call feedkeys("\<left>\<right>", "n")
    Executing InsertCharPre Auto commands for "<buffer=1>"
    autocommand call conque_term#key_press()

    line 0: call conque_term#key_press()
    calling function conque_term#key_press()

    line 1:     sil exe s:py . ' ' . b:ConqueTerm_Var . ".write_ord(" . char2nr(v:char) . ")"
    line 1: py ConqueTerm_1.write_ord(106)
    Error detected while processing function conque_term#key_press:
    line    1:
    E523: Not allowed here
    line 2:     sil let v:char = ''
    function conque_term#key_press returning #0

The problem seems to be caused by Conque’s use of InsertCharPre (introduced 
in Vim 7.3.196). This particular interaction has been raised on the Vim 
development mailing list (as a followup to the 7.3.196 patch email), though 
there was no resolution:

    http://groups.google.com/group/vim_dev/browse_thread/thread/e96d6c66c7f6c9c3

The description of InsertCharPre says that the "textlock" will be active. My 
guess is that the automatic read done by write() (called by write_ord()) is 
violating the text lock.

I have two workarounds:

* Revert to :map based key handling (instead of InsertCharPre) by changing
        if exists('##InsertCharPre')
    to
        if 0 && exists('##InsertCharPre')
    in autoload/conque_term.vim.

    My barely informed analysis is that reverting to :map based key handling will prevent proper handling of non-ASCII input.

* Suppress the auto-read when calling write_ord from conque_term#key_press(). 
Change 
        …".write_ord(" . char2nr(v:char) . ")"
    to
        …".write_ord(" . char2nr(v:char) . ", True, False)"
    in autoload/conque_term.vim.

    I have no idea what complications this might have, but it (seems like it) “works for me”.

Original comment by Chris.Jo...@gmail.com on 13 Jul 2011 at 5:47

GoogleCodeExporter commented 8 years ago
Er, it looks like nicoraffo just recently committed a fix:

    http://code.google.com/p/conque/source/detail?r=475

It adds a new write_buffered_ord() function and reverts back to :map-based 
input handling unless explicitly configured to use InsertCharPre.

Original comment by Chris.Jo...@gmail.com on 13 Jul 2011 at 5:54

GoogleCodeExporter commented 8 years ago
Thanks, my problem is solved now.

Original comment by omeraga...@gmail.com on 13 Jul 2011 at 6:50

GoogleCodeExporter commented 8 years ago
Is it possible to have a version with this fix pushed to vim.org?

Original comment by mkomi...@gmail.com on 11 Aug 2011 at 11:43

GoogleCodeExporter commented 8 years ago
2.2 just released.

Original comment by nicora...@gmail.com on 13 Aug 2011 at 12:40