Just for the record: This issue is fixed upstream by now and will be in
the next version of the package.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Frank Terbeck f...@bewatermyfriend.org wrote:
If you still think this is a bug and not an error in your setup, then
please provide a concise way to reproduce the issue, because so far I've
invested about an hour into seeing that everything works as expected. ;)
If I am missing something,
Morten Bo Johansen wrote:
[...]
What you are missing is that you never once tried the combination setting
I described as causing problem. Please try to set a non-utf8 _country_
I'd be surprised to see different results with `de_DE' and `POSIX'.
locale for the LANG variable together with a
* Morten Bo Johansen [Tue Jan 03, 2012 at 12:10:49PM +0100]:
Frank Terbeck f...@bewatermyfriend.org wrote:
If you still think this is a bug and not an error in your setup, then
please provide a concise way to reproduce the issue, because so far I've
invested about an hour into seeing that
Michael Prokop m...@debian.org wrote:
I can't reproduce the issue neither.
Neither with Zsh version 4.3.6, 4.3.12-1 nor with a recent devel
version based on 4.3.13.
What terminal are you using?
I attach the output from infocmp. But at my end it is reproducible with
any terminfo
Morten Bo Johansen wrote:
[...]
export LANG=de_DE
export LC_ALL=de_DE.utf8
type in e.g. an umlaut character, type backspace to delete it and notice
that it is deleted piecemeal by octet. It should happen to you too!
Hum.
I can reproduce this right now. I'm unsure where I went
Frank Terbeck wrote:
[...]
I can reproduce this right now. I'm unsure where I went wrong before.
Now I know.
The order in which you have to set LANG and LC_ALL is crucial to
reproduce the issue. And the order in my recipe from the last mail is
wrong:
[...]
b) export LANG=de_DE (*not*
* Frank Terbeck [Tue Jan 03, 2012 at 03:46:09PM +0100]:
Frank Terbeck wrote:
[...]
I can reproduce this right now. I'm unsure where I went wrong before.
Now I know.
The order in which you have to set LANG and LC_ALL is crucial to
reproduce the issue. And the order in my recipe from the
* Michael Prokop [Tue Jan 03, 2012 at 03:59:43PM +0100]:
* Frank Terbeck [Tue Jan 03, 2012 at 03:46:09PM +0100]:
Now I know.
The order in which you have to set LANG and LC_ALL is crucial to
reproduce the issue. And the order in my recipe from the last mail is
wrong:
b) export
Michael Prokop wrote:
[...]
I sadly still can't reproduce it yet, FTR.
Mika and I talked about this on IRC. Turns out he had `LC_CTYPE' in his
environment, which gets saved by zsh's handling, which prevents the
problem.
So, the real[tm] recipe is this:
a) Start a blank zsh (zsh -f)
b)
Package: zsh
Version: 4.3.12-1
Severity: normal
Hi,
I could not get multibyte support to work in zsh, even if I had a, what
seemed to me, perfectly working utf-8 environment. I then checked the
output from the locale command and noticed that all my LC_.* variables
were set to da_DK.utf8 whereas
Morten Bo Johansen wrote:
I could not get multibyte support to work in zsh, even if I had a, what
seemed to me, perfectly working utf-8 environment. I then checked the
output from the locale command and noticed that all my LC_.* variables
were set to da_DK.utf8 whereas the $LANG variable
Frank Terbeck f...@bewatermyfriend.org wrote:
Locale settings work like this: LC_* variables control the different
pieces of the puzzle, when one of those is not set `LANG' is used as a
fallback. `LC_ALL' is special, because it overrides all other LC_*
variables and `LANG' becomes
Morten Bo Johansen wrote:
[...]
I attach my rather small zshrc.
Nothing in that file is relevant to this issue.
~/.zshenv is a symlink to ~/.environment
which just set a lot of environment variables. It is there that I now
specifiy the LANG variable which makes zsh behave correctly.
That
14 matches
Mail list logo
