bugGNU nano - Bugs: bug #64320, something goes wrong when editing...


You are not allowed to post comments on this tracker with your current authentication level.

bug #64320: something goes wrong when editing on a Linux console in 4K on Slackware

Submitter:  David Chmelik <darwin>
Submitted:  Tue 20 Jun 2023 07:34:16 AM UTC
Severity:  3 - Normal Status:  Need Info
Assigned to:  None Open/Closed:  Open

Jump to the original submission

Thu 06 Jul 2023 09:28:07 AM UTC, comment #16: 

You changed it too soon.  I was unable to reproduce the bug on Slackware the same way I recently tested on other GNU/Linux.  I have to do a different sort of test, again.  It's hard to explain.  I just know if you fill up the screen with lines, and move it around, and save, and maybe do it again, something will go wrong, and most likely on Gentoo and others too.  Slackware doesn't compile the kernel wrong because it just compiles the kernel the way it is: no patches.

David Chmelik <darwin>
Thu 06 Jul 2023 09:04:14 AM UTC, comment #15: 

Another good test would be: to boot into another system (say Debian or Gentoo) and then chroot into the Slackware system.  If the problem does not occur then, it shows that there is nothing wrong with nano and ncurses, but that somehow the Slackware kernel has an issue.  Maybe the upstream kernel code has a bug and the way that Slackware configures and/or compiles it exposes the bug.  Or maybe Slackware miscompile or misconfigures the kernel.

Benno Schulenberg <bens>
Group administrator
Wed 05 Jul 2023 02:58:04 AM UTC, comment #14: 

Okay, I booted openSUSE, some Debian-/Ubuntu-based OSs, Fedora, Gentoo, and it didn't happen in those... this may just be a Slackware problem but I'm unsure.  I can still test NetBSD, FreeBSD, DragonFlyBSD later...

David Chmelik <darwin>
Tue 04 Jul 2023 01:05:15 PM UTC, comment #13: 

You're still not providing a reproduction recipe.  The phrase "just adding a few lines of unique letters and/or numbers to the bottom until all lines were filled, and then saved" is way too vague.

You have to describe exactly and in all detail what you are doing -- all the keystrokes.  Preferably you don't type the extra text but read in a second file that you prepared beforehand, so that it is easy to each time add the exact same piece of text, to see whether you get the exact same result.  Lines being "saved in the wrong order" sounds like an impossibility -- if you typed them in a certain order, they will be saved in that same order even if the display is messed up.

And no, chrooting is not okay.  The kernel versions may be the same, they were compiled by different distros, and thus will be different.  To reproduce the problem on another system, you actually have to boot the other system.

Benno Schulenberg <bens>
Group administrator
Tue 04 Jul 2023 03:33:31 AM UTC, comment #12: 

Well, I have the same kernel in Slackware and Gentoo so I think chrooting is fine.  This has been happening since late Linux kernel 4, all through 5, and dozens in 6; probably 100+ kernels overall, so they're not really the problem.
        I tested on large plaintext /etc/*.conf files just adding a few lines of unique letters and/or numbers to the bottom until all lines were filled, and then saved, and then I could see how those changed (saved in the wrong order).

David Chmelik <darwin>
Mon 26 Jun 2023 09:40:44 AM UTC, comment #11: 

Chrooting is not a good way to try and reproduce the problem: you are actually using the kernel (and thus the console-driver code) from your base Slackware system.  To really try and reproduce the issue on other systems, you need to boot into them.

You say that you can reproduce the garbling issue in multiple situations, but you're not exactly describing the steps for reproduction.  For me to be able to reproduce the issue, I need a detailed and precise recipe.

Benno Schulenberg <bens>
Group administrator
Thu 22 Jun 2023 09:55:42 AM UTC, comment #10: 

I also tested for you in an X terminal and didn't have a problem in a chroot of one that had severe problems on a pure terminal.  However, if I'm in X I uually use KDE Advanced Text Editor (KATE) and expect terminal text editors to work well on pure terminals.

David Chmelik <darwin>
Thu 22 Jun 2023 09:47:29 AM UTC, comment #9: 

On nano 7.2, I noticed similar/worse problems when I chrooted into Fedora, Gentoo, openSUSE (using defaults on all, and no ~/.nanorc) but not when chrooted in Debian-/Ubuntu-based.
        On some of those and Slackware, if you edit a full screen and are at the bottom, and save, sometimes there ends up being an unnumbered line between two numbered lines, and sometimes the last couple lines are saved in reverse order.
        The worse thing is when you do that, sometimes the first line of menus will be displayed above part of the text file, and part of the text file under that on a line or maybe at the beginning of a line of menus, all garbled.
        I tested on large plaintext /etc/*.conf files just adding a few lines of a letter and/or number to the bottom (so I don't think these were unicode).
        Seems something went wrong with calculations for where the cursor is, maybe, and where things should be displayed.
        Apart from booting some of those GNU/Linux distributions later, and FreeBSD later this Summer, is there anything else I can test so far?  It's probably best to see if a few other people can test this.

David Chmelik <darwin>
Thu 22 Jun 2023 12:20:55 AM UTC, comment #8: 

I don't run tabs command in any ~/.*rc nor ~/.*profile nor system initialization.

David Chmelik <darwin>
Wed 21 Jun 2023 01:55:23 PM UTC, comment #7: 

One thing to watch out for when trying to reproduce the issue: maybe it only happens when using nano after having used another program first, one which leaves the terminal in a subtly strange state.

Do you maybe use a `tabs` command in your ~/.bashrc or ~/.profile or some other init file?

Benno Schulenberg <bens>
Group administrator
Wed 21 Jun 2023 10:30:35 AM UTC, comment #6: 

The output of that command you asked for was just: TERM=linux.  There was no $TAB, so it's default I guess.
        Later I'll try more editing and see if I can find out what happened.  Another thing I can say is that it may only happen when the cursor is farther down the screen, so it has to be a large file, maybe almost or at least as many lines as nano can display.  If I edit higher up in a file, the problems might not happen, but I haven't been able to determine exactly where it starts happening yet...

David Chmelik <darwin>
Wed 21 Jun 2023 09:43:56 AM UTC, comment #5: 

It would be great if you could test your editing also on the console of two other distros.  If you can't reproduce the problem there, then it's something in Slackware.  If you can reproduce it there, then we have a problem.  But it will also mean that you know more or less how to reproduce the problem, and can tell me how.

Looking at your /etc/nanorc, I see you have enabled both sets of interface colors ('set titlecolor ...' et cetera).  The second set overrides the first, so you could delete that first set.  Also, you include all nanorc files and then three of them explicitly.  Those latter includes are redundant.

With "tab size" I wasn't referring to nano's 'tabsize' option but to the tab size of the terminal.  I know ncurses can make use of tabs to move the cursor efficiently over a short range, and also that it can be told not to do that, but this is just a vague memory and I don't actually know how it works.

Please post the output of `env | grep -e TAB -e TERM`.

(There is a preview button, but it's somewhat hard to notice -- either at the top of the input field, or to its left.)

Benno Schulenberg <bens>
Group administrator
Wed 21 Jun 2023 07:34:36 AM UTC, comment #4: 

I had a second typographical error; the stty size is 135 480.
        Sorry; I am new to Savannah and used to having submission forms you can preview before you post, so you can get rid of these errors.

David Chmelik <darwin>
Wed 21 Jun 2023 07:33:24 AM UTC, comment #3: 

I had a typographical error; the stty size is 134 480.

David Chmelik <darwin>
Wed 21 Jun 2023 07:32:24 AM UTC, comment #2: 

Okay.  As described, the tty command certainly shows a /dev/ttyn for some n=1 to 12, but I rarely if ever edit in 4K on a terminal emulator so don't know if the same problem happens there, but am willing to test xterms as well.
        stty size: 145 480 (I counted lines (correct) but didn't count columns... is there some setting/tool that can number those?)
        I often use softwrapping (when not on 4K) but most files I edit (configuration) in 4K don't need it because lines end far before the right side of the screen, so I don't think I ever actuallly turned it on in 4K.
        I have no ~/.nanorc; only /etc/nanorc (attached).
        More, most, & less generally display files right (and alpine-pico at least initially).
        Some .TXTs I edit have a character at the beginning called something such as unicode byte order marker, indicating they're  unicode, but most files I edit (configuration) I think are just ASCII, though this may slowly be changing as the GNU/Linux distribution I use changed terminals to default to unicode.
        I use nano 7.2.
        I use Slackware GNU/Linux 15+current, FreeBSD UNIX 13.2, but noticed this problem on earlier Slackware (and maybe FreeBSD though these days I use it less and don't remember if the problem happened on it)... I can test on several other GNU/Linux such as Devuan/Debian-based, Gentoo, RedHat-based, openSUSE.
        I wouldn't say I have strange environment variables but unsure what that means.
        I haven't trued using '--linenumbers' but my nanorc is set to show line numbers.
        I didn't reduce the tab size from what seems default eight but possibly will in future... but I don't always press <TAB> before I see this problem.
        Let me know if there's anything else I can do/check/test/debug.

(file #54851)

David Chmelik <darwin>
Tue 20 Jun 2023 02:02:52 PM UTC, comment #1: 

Sorry, the description of your problem is too vague.  What I understand is that something goes wrong when you edit on Linux console (a VT, 'tty' reports /dev/ttyn), but it works fine on any terminal emulator ('tty' reports /dev/pts/n), right?

  • How large is your Linux console ('stty size')?
  • Do you use softwrapping?
  • What other options do you use?  Please attach your ~/.nanorc file.
  • Have you looked at your file with another ncurses-based program (like 'less') to see if it displays right?
  • Do you have non-ASCII characters in your files?
  • What version of nano?
  • What distro?
  • Anything strange in your environment variables?
  • Have you tried using --linenumbers (to maybe get an early warning when something is displayed wrong)?

My suspicion is that either your VT reports a different size than what the console actually has, which will mess up the cursor movements of ncurses because it relies on certain behavior near the edges; or the tab size is not what ncurses expects, which will also mess up the cursor movements (but much worse).

Benno Schulenberg <bens>
Group administrator
Tue 20 Jun 2023 07:34:16 AM UTC, original submission:  

Often I edit in nano on a 4K pure (non-X) terminal/shell, and the number of lines or something is handled wrong.  Some many not be counted near the bottom, so text starts being offset.  You might end up deleting stuff above a line on the wrong line, and you won't even see that displayed right until you exit and reopen.  If you saved, you may find the file was messed up because of the wrong count and text offset being not displayed right.  I haven't figured out the exact details but something went wrong.  It works fine to edit on pure terminals in 1600x1200 and 1080p.  When editing in 4K I can only save small sections at a time if done carefully/right before I have to exit and restart to see/do any more.

David Chmelik <darwin>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #54851:  nanorc added by darwin (11KiB - application/octet-stream)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by bens (Posted a comment)
  • -email is unavailable- added by darwin (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.


    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-07-06 bens Summarysomething goes wrong when editing on a Linux console in 4K something goes wrong when editing on a Linux console in 4K on Slackware
    2023-06-21 darwin Attached File- Added nanorc, #54851
    2023-06-20 bens StatusNone Need Info
        Summarynano can't handle editing in terminals/shells in 4K something goes wrong when editing on a Linux console in 4K

    Back to the top

    Powered by Savane 3.12