search

dshi7 / conque

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

Invalid output when you delete Unicode character #23

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. cat > blank-conque-vimrc.vim << EOF
set nocompatible
set rtp=~/.vam/Conque_Shell
EOF
2. vim -u blank-conque-vimrc.vim -c 'ConqueTerm sh' -c 'execute ''python 
''.b:ConqueTerm_Var.''.write("«")''' -c 'execute ''python 
''.b:ConqueTerm_Var.''.write(chr(8))'''

What is the expected output?
sh-4.0$

What do you see instead?
sh-4.0$ <c2>

What version of the product are you using? On what operating system?
Linux, amd64, svn revision 330

Please provide any additional information below.
I have added support for ConqueShell to my 
[translit3](http://www.vim.org/scripts/script.php?script_id=3056) plugin which 
is able to translate ASCII to unicode, thinking that the only problem with 
unicode is that it contains too many characters to map them all.

Original issue reported on code.google.com by zyx.msu@gmail.com on 14 Sep 2010 at 11:58

GoogleCodeExporter commented 8 years ago 
Yeah. Unicode is problematic. I had thought the latin-1 set at least was 
working, but clearly something is wrong with values above 128.

Conque 2.0 will have much better support for unicode (utf-8) output, to support 
graphics character sets, or whatever else your terminal prints in muti byte.

I haven't though of a very good solution to unicode input so far. As you said, 
the main problem is figuring out a way to get all those characters mapped. I'll 
take a look at your plugin. If it provides a way to get all the mappings for a 
user's character set into ConqueTerm, that would be great.

In the long term I'm hoping some more auto commands are added to Vim to capture 
keyboard input. The commands exist in the Vim todo.tx, but given that 7.3 was 
just released, it will probably be years before anything happens on that front.

Original comment by nicora...@gmail.com on 15 Sep 2010 at 5:54

GoogleCodeExporter commented 8 years ago 
It does not provide a way to get all the mappings for user's character set into 
ConqueTerm. It just does provide a way to translate one sequence of symbols 
into other. I use it to translate between ascii and Russian and Greek letters + 
some UTF or LaTeX math symbols (or just only Greek + LaTeX math), but one may 
use it to translate from one UTF-8 characters into other (in this case they 
will also be mapped and thus accessible by your plugin).

About capturing all symbols: some times it is worth to send symbols to terminal 
only when <CR> or <Tab> is pressed. Maybe sending a diff between old terminal 
line and line when <CR>/<Tab> is pressed is worth implementing as an option.

Original comment by zyx.msu@gmail.com on 15 Sep 2010 at 7:24

GoogleCodeExporter commented 8 years ago 
The first 4 versions of conque worked as you suggest, only sending text to the 
terminal when certain keys were pressed. To do it right it would require at 
least 10 times the amount of code it took to write ConqueTerm, and I have my 
plate full already.

Vimshell [1] uses this method, and may be more to your liking if you require 
unicode input.

1. http://github.com/Shougo/vimshell

Original comment by nicora...@gmail.com on 15 Sep 2010 at 9:06

GoogleCodeExporter commented 8 years ago 
Working with another user to create a Vim patch for capturing unicode input. 
I'm optimistic it will make it into the Vim trunk this year.

Original comment by nicora...@gmail.com on 5 Oct 2010 at 5:16

GoogleCodeExporter commented 8 years ago 
> Working with another user to create a Vim patch for capturing unicode input. 
I'm optimistic it will make it into the Vim trunk this year.

Can you please provide a link to this project? I may help at least with testing.

Original comment by zyx....@gmail.com on 11 Oct 2010 at 11:15

GoogleCodeExporter commented 8 years ago 
This was the patch being worked on. It currently has a bug or two (holding down 
a key for several seconds produces garbage). I'm working on Conque 1.2 and 2.0 
at the moment. If you want to play around with the patch, go ahead :-)

Original comment by nicora...@gmail.com on 11 Oct 2010 at 4:39

Attachments:

GoogleCodeExporter commented 8 years ago 
Attached patch fixes unicode problems, but there may be problems with 
non-printable unicode (due to \%v instead of \%c, I was to lazy to add byte 
offset calculator there) and non-unicode characters (and also with tabs if it 
is possible to bypass ctl_tab function).

Original comment by zyx.msu@gmail.com on 12 Dec 2010 at 3:35

Attachments:

GoogleCodeExporter commented 8 years ago 
Thanks for the patch.

I'm working on overhauling unicode support in a new branch, including allowing 
unicode keyboard input.

I'll update this issue again when it's at a testable state.

Original comment by nicora...@gmail.com on 13 Dec 2010 at 1:54

GoogleCodeExporter commented 8 years ago 
Is this the issue that causes the strange behaviour: I somehow enter the mode 
from time to time that the character I just typed isn't displayed. It gets 
displayed after I insert another character and then again I need to type 
another character to see the previous one :) While we are waiting for the fix 
maybe some hint to configure vim that switching to Conque window resets utf-8 
to ascii and when I leave Conque window I get utf-8 again? I could live without 
utf-8 in Conque window. Anyway, awesome plugin!

Original comment by mimoohowy on 21 Dec 2010 at 6:22

GoogleCodeExporter commented 8 years ago 
Very odd. I've never seen that issue before. What characters are you typing 
that cause the delayed display? Also, do commands such as "sleep 5" or "ping 
google.com" display normally, or do you have to press a key for new output?

The conque buffer should always be utf-8. Is there a reason why you want it to 
be something else?

Original comment by nicora...@gmail.com on 21 Dec 2010 at 6:53

GoogleCodeExporter commented 8 years ago 
I was expecting an email notification that the thread is going on - sorry for 
not responding. Well, never figured out what starts the strange mode (which 
characters input). It happens to more people here so we will be trying to find 
how to reproduce. Yes, commands wait for another key press also. Everything 
seems to be one-key-press late. No, I don't need anything else than utf-8 - 
nevermind about this.

Original comment by mimoohowy on 5 Jan 2011 at 3:06