[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-moe] keycodes are entered into buffer

From: Antonio Diaz Diaz
Subject: Re: [Bug-moe] keycodes are entered into buffer
Date: Wed, 07 Sep 2016 19:18:04 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv: Gecko/20110420 SeaMonkey/2.0.14

Benno Schulenberg wrote:
Majorly inconvenient.  At first I let it be, when xz couldn't decrompress
the file.  But I wanted to investigate the competitors of nano, so I tried
again, and finally figured out that I needed lzip for decompression.  Bwuh.

Sorry for the inconvenience. I hope that as a xz user, at least it brings something positive to you.

BTW, I find moe more convenient than nano to edit large projects. For example, just now I am editing 54126 files of linux 4.7 with moe.

What problems or defects does xz have?

You may find some of them described in this article[1]. The second half of this benchmark[2] shows some more. But before reading anything, please, try this interoperability test between xz-utils and xz-embedded (busybox):

$ echo 'The quick brown fox jumps over the lazy dog.' | xz > fox.xz

Open fox.xz with an hex editor (moe will do) and modify any character in the sentence above, that xz stores in an uncompressed LZMA2 chunk. Now try to decompress the modified file. Xz-utils detects the corruption, but busybox's xz does not:

$ xz -t fox.xz
xz: fox.xz: Compressed data is corrupt
$ echo $?
$ busybox xz -t fox.xz
$ busybox xz -cd fox.xz
The quick brown fox jumps over the lazy fog.
$ echo $?

[1] http://www.nongnu.org/lzip/xz_inadequate.html
[2] http://www.nongnu.org/lzip/lzip_benchmark.html

If you want to showcase lzip, you should get a major package like grep
or coreutils to adopt it.

This is exactly what the xz maintainers did; they got grep and coreutils distributed in xz format only. As a result a bad format has become relatively popular. Everybody loses when technical matters are decided by popularity contests.

Oh, ^H was quite intuitive.  Much more than F1.  Besides, F1 in my
terminal emulator calls up the manual of that Terminal.  :|

Thanks. I think I'll change the message in the status line to "^H for help".

In my VGA text console, Shift+<arrow>  and Ctrl+<arrow>  both work just as
<arrow>  alone.

Ah, yes, a Linux console is completely handicapped: for the Arrow
keys it completely ignores the modifiers.

The question is that I use moe almost exclusively on a VGA text console, and I would prefer not to add functions that do not work there.

Another problem is that ncurses.h (5.6 and 5.9) only provides key codes for Shift+Left and Shift+Right. I need to investigate this further.

Konsole is another deficient terminal.  I pray for its users that
those key combos can be reassigned.

How curious. Another user said something similar about Gnome Terminal. In fact I added the ^H help key because F1 is not available there.

Just about all editors do this.  Emacs, Vim, Pico, nano, Gedit, Geany.
And all word processors that I know (LibreOffice Writer, for example).
(Not on a Linux console, of course, but on a Gnome Terminal yes.)
The only one that doesn't do it is Joe.

It seems that Ctrl+Left/Right only works on a Gnome Terminal, which I do not use nor have installed. Nano does not recognize Ctrl+Left/Right neither on a VGA text console nor on Konsole. This makes it difficult for me to implement and test the feature. :-(

Best regards,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]