Bug 477078 - misbehavior on long lines
Summary: misbehavior on long lines
Status: RESOLVED NOT A BUG
Alias: None
Product: konsole
Classification: Applications
Component: general (show other bugs)
Version: 23.08.3
Platform: Neon Linux
: NOR normal
Target Milestone: ---
Assignee: Konsole Developer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-11-16 07:40 UTC by Michael
Modified: 2023-12-04 14:43 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael 2023-11-16 07:40:12 UTC
after latest upgrade, konsole (and Yakuake) is misbehaving after scrolling down or down up over long lines which occupy several terminal lines
soon such a line is reached the next keypress up or down jumps to the next line and the window below stays black with a "@" placeholder for the occupied space by the text which is not visible
 this behavior renders the program useless
since Yakuake behaves the same way the problem is probably not the program itself, but I have no idea where I could look at
the problem appears also on Arch with the same plasma version upgraded 
thanks
Comment 1 ninjalj 2023-11-17 22:23:33 UTC
Can you provide detailed instructions on how to reproduce the problem?
Comment 2 Michael 2023-11-20 10:17:28 UTC
(In reply to ninjalj from comment #1)
> Can you provide detailed instructions on how to reproduce the problem?

sure, 

take any text file, insert in the middle a line with 1000 words or so, save it and scroll in vi
when you do ':set nowrap'  you can see the beginning of a line and so much chars as your window allows
when you do ':set wrap' you can scroll to the long line, one more down and you jump to the next line (skipping all what didn't fit onto your windows, when you then go one line back up, you jump to the beginning of the long line and every other line until the bottom of your window starts with @ and is empty

expected is that with 'set: wrap' the long line is wrapped to your window width and you can scroll up or down without skipping anything 

thanks
Comment 4 Michael 2023-11-22 17:28:00 UTC
(In reply to ninjalj from comment #3)
> That's a vim behavior. See
> https://vi.stackexchange.com/questions/102/show-partially-hidden-wrapped-
> lines and https://vimhelp.org/options.txt.html#%27display%27

well, I use vi and don't think that's a vi behavior, because vi runs on (kde)console in this case, when I switch to another terminal the behavior is correct, "set: wrap" is the default, when on a terminal, all lines appear, when on konsole it shows the wrong behavior 

the problem is consistent on Kde Plasma, running on LinuxMint, on KdeNeon, Archlinux and FreeBSD14
Comment 5 fanzhuyifan 2023-11-22 17:42:31 UTC
(In reply to Michael from comment #4)
> (In reply to ninjalj from comment #3)
> > That's a vim behavior. See
> > https://vi.stackexchange.com/questions/102/show-partially-hidden-wrapped-
> > lines and https://vimhelp.org/options.txt.html#%27display%27
> 
> well, I use vi and don't think that's a vi behavior, because vi runs on
> (kde)console in this case, when I switch to another terminal the behavior is
> correct, "set: wrap" is the default, when on a terminal, all lines appear,
> when on konsole it shows the wrong behavior 
> 
> the problem is consistent on Kde Plasma, running on LinuxMint, on KdeNeon,
> Archlinux and FreeBSD14

Maybe you accidentally have an alias from vi to vim? Or you changed your config files? This does seem like expected vim behavior, as mentioned in the links above.
Comment 6 Michael 2023-11-23 09:28:37 UTC
(In reply to fanzhuyifan from comment #5)
> (In reply to Michael from comment #4)
 
> Maybe you accidentally have an alias from vi to vim? Or you changed your
> config files? This does seem like expected vim behavior, as mentioned in the
> links above.

LOL, no ... :)
Comment 7 Michael 2023-11-30 20:50:20 UTC
not a bug?

what is it then?
Comment 8 ninjalj 2023-11-30 23:12:49 UTC
As already written in comment 3, it _is_ a vim behavior. See the description at https://vimhelp.org/intro.txt.html#window-contents

If it doesn't show up in other terminals, it's probably because they have different size, and the long line fits in its entirety.
Comment 9 fanzhuyifan 2023-11-30 23:20:05 UTC
(In reply to Michael from comment #7)
> not a bug?
> 
> what is it then?

If you insist, could you provide the following so that we could better debug this issue?

On both konsole where you were witnessing this issue, and a terminal where you did not witness this issue, could you provide

1. The output of `vi --version`, if vi was the editor command you were using.
2. Screenshots of the document opened in vi with a very long line, making sure that in both cases, the file is the same, and the terminal sizes are the same.
3. The output of `echo -e "lines\ncols"|tput -S`. This tells you the sizes of the terminals.

Thanks!
Comment 10 Michael 2023-12-02 20:08:21 UTC
(In reply to ninjalj from comment #8)
> As already written in comment 3, it _is_ a vim behavior. See the description
> at https://vimhelp.org/intro.txt.html#window-contents
> 
> If it doesn't show up in other terminals, it's probably because they have
> different size, and the long line fits in its entirety.

eventually the issue then wasn't properly analyzes
Comment 11 Michael 2023-12-02 20:58:44 UTC
(In reply to fanzhuyifan from comment #9)
> On both konsole where you were witnessing this issue, and a terminal where
> you did not witness this issue, could you provide
> 
> 1. The output of `vi --version`, if vi was the editor command you were using.
> 2. Screenshots of the document opened in vi with a very long line, making
> sure that in both cases, the file is the same, and the terminal sizes are
> the same.
> 3. The output of `echo -e "lines\ncols"|tput -S`. This tells you the sizes
> of the terminals.

on FreeBSD has solved the problem, last upgrade last week on fbsd14 with konsole 28.8.3 it is ok now
some library issue, because Yahuake also is ok now on the same machine
the vi version is
Version 2.2.0 (2020-08-01) The CSRG, University of California, Berkeley. 
that is on a terminal or in Konsole the same version

I never called for vi version, so the output was funny, now for me, I didn't know the vim part, seems to be a package on linux

on Linux 
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Oct 16 2023 18:15:38)
Included patches: 1-579, 1969, 580-1854, 1857, 1855-1857, 1331, 1858, 1858-1859, 1873, 1860-1969, 1992, 1970-1992, 2010, 1993-3995, 4563, 4646, 4774, 4895, 4899, 4901, 4919, 213, 1840, 1846-1847
same version on a terminal or in Konsole


I think the lines and columns are not relevant here, their values should adapt automatically even under resizing konsole with a file open, like FreeBSD is doing again, no distortion happens, on linux before also not

also we should take into consideration that it happens only with very long lines only, for example with a two-liner 150chars for example, the distortion doesn't occur 

the konsole width/height setting is irrelevant when remember windows size and position is set, and makes no difference

hope that was helpful
thanks
Comment 12 fanzhuyifan 2023-12-02 21:09:39 UTC
(In reply to Michael from comment #11)
> on Linux 
> VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Oct 16 2023 18:15:38)
> Included patches: 1-579, 1969, 580-1854, 1857, 1855-1857, 1331, 1858,
> 1858-1859, 1873, 1860-1969, 1992, 1970-1992, 2010, 1993-3995, 4563, 4646,
> 4774, 4895, 4899, 4901, 4919, 213, 1840, 1846-1847
> same version on a terminal or in Konsole

This indicates that the command vi was actually calling vim. So the previous comments about vim behavior applies -- you were actually using vim when you thought you were using vi by the vi command.
Comment 13 Michael 2023-12-04 14:43:43 UTC
> This indicates that the command vi was actually calling vim. So the previous
> comments about vim behavior applies -- you were actually using vim when you
> thought you were using vi by the vi command.

ok, I see, you were right from beginning and sorry for my ignorance in this matter on Linux
I just installed nvi and the problem is not existent 

thanks