From: Andrey Borzenkov <arvidjaar@newmail.ru>
To: zsh-workers@sunsite.dk
Subject: Re: PATCH: fix 4, was Re: unpatch: metafying zle line
Date: Sun, 14 Aug 2005 19:55:31 +0400 [thread overview]
Message-ID: <200508141955.43507.arvidjaar@newmail.ru> (raw)
In-Reply-To: <200508121021.j7CAL18n012569@news01.csr.com>
[-- Attachment #1: Type: text/plain, Size: 4840 bytes --]
On Friday 12 August 2005 14:21, Peter Stephenson wrote:
> After this, completion is basically working with ZLE_UNICODE_SUPPORT
> defined when you stick to using single-byte characters. It's almost
> time to allow that to be enabled by default, which will help picking up
> the remaining problems with multi-byte characters: those are likely to
> be widespread, but probably in most cases fixable by local changes.
>
Hat off to you, Sir! It is worth more than pizza ...
Multibyte basically works (ru_RU.UTF-8, Mandrake^H^H^Hiva cooker, gcc 4.0.1,
glibc 2.3.5). I.e. basic line editing (movement char, word, emacs or vi
mode). Completion - i.e. listing etc.
Some random problems.
1. attempt to use a-a-m-c results in
{pts/2}% ll кккккккк ккккккккккк/home/bor/src/zsh/Src/Zle/compresult.c:690:
line not metafied
zsh: segmentation fault (core dumped) pkg/bin/zsh
#0 0xb7bef892 in hasbrpsfx (m=0x8178a50, pre=0x0, suf=0x0)
at /home/bor/src/zsh/Src/Zle/compresult.c:699
699 memcpy(oline, zlemetaline, zlemetall);
(gdb) bt
#0 0xb7bef892 in hasbrpsfx (m=0x8178a50, pre=0x0, suf=0x0)
at /home/bor/src/zsh/Src/Zle/compresult.c:699
#1 0xb7bf1e67 in calclist (showall=1)
at /home/bor/src/zsh/Src/Zle/compresult.c:1489
#2 0xb7f4e3a4 in complistmatches (dummy=0xb7bf6ab0, dat=0xbff669b0)
at /home/bor/src/zsh/Src/Zle/complist.c:1608
#3 0x080961f4 in runhookdef (h=0xb7bf6ab0, d=0xbff669b0)
at /home/bor/src/zsh/Src/module.c:1889
#4 0xb7bf4761 in list_matches (dummy=0xb7c2cec0, dummy2=0x0)
at /home/bor/src/zsh/Src/Zle/compresult.c:2200
#5 0x080961f4 in runhookdef (h=0xb7c2cec0, d=0x0)
at /home/bor/src/zsh/Src/module.c:1889
#6 0xb7c14a5e in zrefresh ()
at /home/bor/src/zsh/Src/Zle/zle_refresh.c:752
#7 0xb7f5027c in domenuselect (dummy=0xb7bf6a74, dat=0xbff66fe0)
at /home/bor/src/zsh/Src/Zle/complist.c:2153
#8 0x0809618f in runhookdef (h=0xb7bf6a74, d=0xbff66fe0)
at /home/bor/src/zsh/Src/module.c:1883
#9 0xb7bdea62 in after_complete (dummy=0xb7c2cefc, dat=0xbff6706c)
at /home/bor/src/zsh/Src/Zle/compcore.c:506
#10 0x080961f4 in runhookdef (h=0xb7c2cefc, d=0xbff6706c)
at /home/bor/src/zsh/Src/module.c:1889
#11 0xb7c19e55 in docomplete (lst=0)
at /home/bor/src/zsh/Src/Zle/zle_tricky.c:851
#12 0xb7c18544 in completeword (args=0xb7c2d13c)
at /home/bor/src/zsh/Src/Zle/zle_tricky.c:232
#13 0xb7c18421 in completecall (args=0xb7c2d13c)
at /home/bor/src/zsh/Src/Zle/zle_tricky.c:208
#14 0xb7c0b09f in execzlefunc (func=0xb7c2b050, args=0xb7c2d13c)
at /home/bor/src/zsh/Src/Zle/zle_main.c:1063
#15 0xb7c0a62b in zlecore ()
at /home/bor/src/zsh/Src/Zle/zle_main.c:838
#16 0xb7c0ad1b in zleread (lp=0x80e63e0, rp=0x0, flags=7, context=0)
at /home/bor/src/zsh/Src/Zle/zle_main.c:992
#17 0x08080ac3 in inputline () at /home/bor/src/zsh/Src/input.c:278
#18 0x08080978 in ingetc () at /home/bor/src/zsh/Src/input.c:214
#19 0x0807775b in ihgetc () at /home/bor/src/zsh/Src/hist.c:240
#20 0x080880f4 in gettok () at /home/bor/src/zsh/Src/lex.c:628
#21 0x0808792c in yylex () at /home/bor/src/zsh/Src/lex.c:344
#22 0x080a1269 in parse_event () at /home/bor/src/zsh/Src/parse.c:451
#23 0x0807d8d6 in loop (toplevel=1, justonce=0)
at /home/bor/src/zsh/Src/init.c:128
#24 0x080805ba in zsh_main (argc=1, argv=0xbff67614)
at /home/bor/src/zsh/Src/init.c:1315
#25 0x08052652 in main (argc=1, argv=0xbff67614)
at /home/bor/src/zsh/Src/main.c:93
apparently it correctly inserts first match but crashes at recursive
completion attempt.
2. Attempt to complete anything beyond U'd183' results in
{pts/2}% ll уBUG: substring ends in the middle of a metachar in
ztrsub()mpleting `files'
ll у
{pts/2}% echo у | xxd
0000000: d183 0a ...
I do not know what is magic about it; all characters before are completed
normally. Probably it somehow clashes with META characters. The above is in
UTF-8, it is 0400 unicode plane, character in question is 0443.
3. emacs ^W sometimes removes too much not just a previous word in Russian
(where word delimiter in this case is space):
{pts/2}% ll АААААА ББББББББ ВВВВВВВВВ^W
{pts/2}%
4. Undo (in emacs or vi) often puts cursor not at previous position but at
some random position. In the above example, if I have anyhing after cursor:
{pts/2}% ll А Б В^W
^cursor here
{pts/2}% ^_
^ cursor here
{pts/2}% ll А Б В
^ cursor here
the position is really random, sometimes it is end of buffer sometimes more.
But yes, I think it makes sense enable UNICODE by default now. It seems to be
usable, at least for simple filename completion.
Thank you
-andrey
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2005-08-14 15:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-12 10:21 Peter Stephenson
2005-08-12 19:50 ` David Gómez
2005-08-14 15:55 ` Andrey Borzenkov [this message]
2005-08-15 17:22 ` [PATCH] fix zrefresh recursive completion call Andrey Borzenkov
2005-08-15 9:57 ` PATCH: fix 4, was Re: unpatch: metafying zle line Peter Stephenson
2005-08-15 15:06 ` some unicode issues [was Re: PATCH: fix 4, was Re: unpatch: metafying zle line] Clint Adams
2005-08-15 15:13 ` Peter Stephenson
2005-08-15 15:17 ` Peter Stephenson
2005-08-15 17:15 ` Clint Adams
2005-08-15 17:20 ` Peter Stephenson
2005-08-15 17:44 ` Clint Adams
2005-08-16 0:45 ` Clint Adams
2005-08-16 2:02 ` Wayne Davison
2005-08-18 9:56 ` Peter Stephenson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200508141955.43507.arvidjaar@newmail.ru \
--to=arvidjaar@newmail.ru \
--cc=zsh-workers@sunsite.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).