Opened 7 years ago
Closed 7 years ago
#54863 closed defect (worksforme)
vim @8.0.1098_0 +huge shows garbage in buffer
Reported by: | dmarteau (David Marteau) | Owned by: | raimue (Rainer Müller) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.4.1 |
Keywords: | Cc: | ||
Port: | vim |
Description
When upgrading to vim @8.0.1098_0+huge the buffer shows characters garbage at the beginning of the first line.
It happends with any file loaded (thus overriding original characters) or just new buffer. Reinstalling or recompiling from source does no fix the problem.
Reinstalling the previous version vim @8.0.0891_0+huge fix the issue.
All dependencies up to date.
OSX 10.11.6 (darwin 15)
Thx.
Change History (17)
comment:1 Changed 7 years ago by raimue (Rainer Müller)
comment:2 Changed 7 years ago by dmarteau (David Marteau)
The garbage is: '$q q$p' (without quotes), always the same.
Launching with vim -u NONE -N
still shows garbage.
comment:3 Changed 7 years ago by wilya7
You might want to read this thread on the Vim issues tracker:
https://github.com/vim/vim/issues/2008
in particular:
https://github.com/vim/vim/issues/2008#issuecomment-324560993
If I understand what they are saying, your problem has nothing to do with MacPorts. It's an issue with a patch introduced recently in Vim and how the Terminal application works in MacOS. If this is true, probably this bug should be closed.
comment:4 follow-up: 6 Changed 7 years ago by dmarteau (David Marteau)
May be MacPorts should stick with @8.0.1098_0 @8.0.0891_0 while the Vim bug is not fixed ?
comment:6 follow-up: 11 Changed 7 years ago by wilya7
Replying to dmarteau:
May be MacPorts should stick with
@8.0.1098_0@8.0.0891_0 while the Vim bug is not fixed ?
The bug there is closed. If I understand correctly (and I might be wrong), I don't think they will change the code in Vim to fix an issue with a closed source terminal that doesn't follow the xterm standard. Maybe you can ask them?
comment:7 follow-up: 8 Changed 7 years ago by dmarteau (David Marteau)
The consequence ATM is that Macports has now a broken vim package... May be it is possible to apply an ad-hoc patch ?
comment:8 follow-up: 9 Changed 7 years ago by wilya7
Replying to dmarteau:
The consequence ATM is that Macports has now a broken vim package... May be it is possible to apply an ad-hoc patch ?
not exactly broken for everyone though. It is possible to use a different terminal application which follows the xterm standard better than the MacOS Terminal
, or set the Terminal
app to a value other than xterm, as suggested in the link I provided.
comment:9 Changed 7 years ago by danielluke (Daniel J. Luke)
Replying to wilya7:
not exactly broken for everyone though. It is possible to use a different terminal application which follows the xterm standard better than the MacOS
Terminal
, or set theTerminal
app to a value other than xterm, as suggested in the link I provided.
That's really a distinction that doesn't matter, though - most people are going to be using Terminal.app with its default 'declared terminal' setting.
comment:10 Changed 7 years ago by dmarteau (David Marteau)
Switching to another type of terminal with iterm2 - 'linux' or 'ansi' - fix that issue with vim but introduces unsatisfactory behaviors with ncurses based programs.
comment:11 follow-up: 12 Changed 7 years ago by wilya7
Replying to wilya7:
Replying to dmarteau:
May be MacPorts should stick with
@8.0.1098_0@8.0.0891_0 while the Vim bug is not fixed ?The bug there is closed. If I understand correctly (and I might be wrong), I don't think they will change the code in Vim to fix an issue with a closed source terminal that doesn't follow the xterm standard. Maybe you can ask them?
I reply to myself to correct my wrong statements. I read a bit better the thread and it seems to me that they have fixed the issue upstream with a patch which has been successfully adopted by homebrew people:
https://github.com/vim/vim/issues/2008#issuecomment-325131994
therefore probably Macport should do the same and ship Vim 8.0.0997. This would solve the bug.
comment:12 follow-up: 15 Changed 7 years ago by raimue (Rainer Müller)
Replying to wilya7:
therefore probably Macports should do the same and ship Vim 8.0.0997 or later. This would solve the bug.
As you correctly stated in the title, MacPorts vim is 8.0.1098, so this fix is already included.
I am using iTerm2.app, so I did not notice any problem. I can also not reproduce the problem with Terminal.app. It just works for me with TERM=xterm-256color
which should be the default on recent versions of macOS. I also tried with TERM=xterm
, but it still works.
The only later fix would be 1.0.1094, but that is meant for non-macOS systems where the problem occurs when using SSH. Are you connecting to your Mac over SSH?
comment:13 follow-up: 14 Changed 7 years ago by raimue (Rainer Müller)
Now I confused myself. Of course even 1.0.1094 is included in the current vim port. I see no reason why it would not work if you are using that.
comment:14 Changed 7 years ago by dmarteau (David Marteau)
I think i have a clue:
I have just been striked that the problem does not occurs with Terminal.app but only with iTerm2.
My version of iTerm2 is quite old (v2.4.1) and I suspect that's the the xterm support should have been improved since. So the vim patch seems only to impact old version of iterm2 with incomplete xterm support
Need to check further to be sure...
Sorry for the noise
comment:15 Changed 7 years ago by wilya7
Replying to raimue:
Replying to wilya7:
therefore probably Macports should do the same and ship Vim 8.0.0997 or later. This would solve the bug.
As you correctly stated in the title, MacPorts vim is 8.0.1098, so this fix is already included.
Just to be clear, I am not the original poster. My apologies if I confused the issue.
comment:16 Changed 7 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | raimue@… removed |
---|---|
Owner: | set to raimue |
Status: | new → assigned |
comment:17 Changed 7 years ago by raimue (Rainer Müller)
Resolution: | → worksforme |
---|---|
Status: | assigned → closed |
I am unable to reproduce the problem (on Sierra 10.12). What does this garbage look like?
Does it also appear when launching
vim -u NONE -N
(disables .vimrc and plugins, starting innocompatible
mode)?