Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

#92 causes right-to-left text when commenting #105

Closed
russellshackleford opened this issue Dec 4, 2018 · 13 comments
Closed

#92 causes right-to-left text when commenting #105

russellshackleford opened this issue Dec 4, 2018 · 13 comments

Comments

@russellshackleford
Copy link

Git bisect got me to 5043a88. Removing format.vim prevented the error. I don't know enough vimscript to narrow it down further. I'll try my best to describe what is happening.

What I typed
# This text is backwards

What is shown:
sdrawkcabs it xets ihT#

<letter><space> seems to be LTR and everything else is RTL. Here's a key by key entry and what it looks like. signifies that the first space I entered stays as a trailing space for the duration.
Type #, get
#
Type space, get
#<space>
Type T, get (everything else after this should be self-evident as to what I typed)
T#<space>
hT#<space>
ihT#<space>
sihT#<space>
s ihT#<space>
ts ihT#<space>
ets ihT#<space>
xets ihT#<space>
txets ihT#<space>
t xets ihT#<space>
it xets ihT#<space>
sit xets ihT#<space>
s it xets ihT#<space>
bs it xets ihT#<space>
abs it xets ihT#<space>

I removed all vim plugins and used a very stripped down vimrc to confirm.

set background=dark
set showcmd
set showmode
set modeline
set switchbuf=useopen
set splitbelow
set splitright
set ignorecase
set smartcase
setlocal nospell
@rodjek
Copy link
Owner

rodjek commented Dec 4, 2018

@russellshackleford That is quite the error... What version of vim or neovim are you using?

@russellshackleford
Copy link
Author

@rodjek Sorry, I meant to add that. It is the standard vim with ubuntu-14.04. 2:7.4.052-1ubuntu3.1 by their reckoning, Or:

VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Nov 24 2016 16:43:18)
Included patches: 1-52
Extra patches: 8.0.0056

@lelutin
Copy link
Collaborator

lelutin commented Dec 4, 2018

hello! I'm trying to reproduce this in vim 8.1 in debian sid and I'm not seeing the same behaviour than described -- or maybe I misunderstood how to reproduce it?
I should try again in an ubuntu VM to make sure..

@russellshackleford
Copy link
Author

Oh wow, I missed something in the vimrc.: filetype plugin indent on However, this got me to thinking more about even those "common" options that I didn't think could possibly affect this. I have a better case to test now. Move .vim and .vimrc out of the way and then:

git clone https://github.com/rodjek/vim-puppet ~/.vim
$ cat >~/.vimrc <<EOF
filetype plugin indent on
set modeline
EOF

This shows the error for me. Removing either of those 2 lines from .vimrc and the error goes away.

@nbeernink
Copy link

I can confirm this issue on VIM 7.4, CentOS 6.10 final. The suggested workaround (moving format.vim) works for me.

@russellshackleford
Copy link
Author

russellshackleford commented Dec 7, 2018

I self-compiled 7.4 on an ubuntu-18-04 host. I created the .vim and .vimrc as above. I was able to reproduce on puppet files that had modelines. If I remove any one of: the modeline itself, the set modeline option, the filetype plugin indent on option, or the autoload/puppet/format.vim file then the problem goes away. Additionally, I self-compiled 7.4.2367 and the problem went away. I guess I'll start bisecting between those two versions trying to find where the problem was introduced.

@russellshackleford
Copy link
Author

russellshackleford commented Dec 7, 2018

7.4.658 (vim/vim@0f8dd84) is where the breakage stops due to changes in how formatexpr works.

And 5043a88#diff-869892d8f079089b97f27957fbbc1aafR15 adds the use of formatexpr.

@mandos, would you have any idea how to make your change work for < 7.4.658 without breaking 658 and later?

@rlpowell
Copy link

I have this issue with all text entry in "*.pp" files, not just comments, presumably (given the discussion) because I have weird formatoptions settings.

I'm on Oracle Linux 6 (basically: RHEL 6), vim 7.4.629

It is sufficient to comment out this line:

call puppet#format#Indention(l:start_lnum, l:end_lnum)

This presumably breaks indenting, but it does fix the problem.

@squaricdot
Copy link

Also encountered this issue. Maybe not en entirely truthful fix, but did build vim from latest https://github.com/vim/vim/archive/master.zip on centos 7, and this seems to be working fine

@lelutin
Copy link
Collaborator

lelutin commented Sep 16, 2019

with vim 8, I can see text inversion happening with the last two characters when formatexpr is called (when going beyond textwidth). I would tend to believe that if formatexpr is called too often as the vim commit pointed out by @russellshackleford suggests, it would manifest as inverting all text.

fwiw, some recent changes with regards to formatexpr might make this a bit less present for some people -- the plugin is not trying to break up lines anymore when textwidth is disabled.

From what I could see, the problem is caused by a call to execute 'normal! gww' at line 58 of auto/puppet/format.vim.
According to documentation, the function gww is supposed to place the cursor back where it was after it has done its work, great! However, during the call to the formatexpr function, the cursor is at column 80 (assuming I have a textwidth of 78), which still does not exist -- it will be the column at which the character awaiting insertion will be placed, or in other words formatexpr is called before the character that was last typed get inserted into the buffer.
So when gww exists, the cursor gets positioned on column 79 since that position does exist at that moment, and that's where the new character gets inserted, pushing character on column 79 to column 80 (thus inverting them).

So.... we need to find a way to replace that call to gww but .. I don't know with what :
Making our formatexpr function return a value that'll make vim default to the internal default behaviour produces some really weird results.

@lelutin
Copy link
Collaborator

lelutin commented Dec 10, 2019

I've been thinking about this problem (and been very annoyed by it over time) and I don't know of a good way to solve this while keeping the current functionality.

one way to fix this would be to constrain the puppet#format#Format function to run only if the mode is 'n', so entirely disable autoformatting while inputting text in insert mode. users would then need to use gq to explicitely reformat the text.

while to me this makes more sense in terms of useability (e.g. let ppl format things how they want them, but give a tool to get more standardized placement easily), removing the autoformatting during input might annoy other folks.
So I think I'd like to get more feedback on this before implementing some feature removal.

What do ppl think? remove autoformatting during anything but normal mode? or rather try to fix this somehow (and actually, how?)

@lelutin
Copy link
Collaborator

lelutin commented Jan 31, 2021

I sent a pull request to implement what I had described in my last comment here.

If ppl experiencing this issue can test #136 it would help me build confidence in the fix

@lelutin
Copy link
Collaborator

lelutin commented Sep 8, 2024

I just merged the pull request to disable autoformat on insert mode while typing. it was causing a similar character reversing issue when i was hitting the textwidth column.

so I believe that if folks are still running the affected vim 7.4 versions, updating to current master should calm this problem down

@lelutin lelutin closed this as completed Sep 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants