(Windows) Gvim: Backspace in insert mode does not delete text
I had an odd issue just now when using Gvim. Usually, backspacing when in insert mode (iwhen running the editor as an administrator.
I had an odd issue just now when using Gvim. Usually, backspacing when in insert mode (iwhen running the editor as an administrator.
An easy avenue in Windows to change the encoding of a file is to open it in Notepad and then use the Save As option which allows you to specify the encoding that the file should be saved using ...
Linux does offer a bunch of solutions too, albeit perhaps relatively less simple:
Some documents contain paragraphs which are wrapped often at the 80 character mark to help with formatting and readability. This is sometimes accomplished using forced line breaks which can be quite annoying especially when you want to reverse it as I did earlier today. Rather than messing with regex and weird edge cases, use Vim which provides a lovely solution! Here it be:
While performing a CSV import recently, I ran into the following error messages:
Warning (Code 1366): Incorrect string value: '\xE9, a <...' for column 'body' at row 3
Warning (Code 1366): Incorrect string value: '\xE6. He ...' for column 'body' at row 24
Warning (Code 1366): Incorrect string value: '\xE9, and...' for column 'body' at row 26
The first message was triggered due to the accented é in the word, protegé, in the input. The rest of the field was not imported. The others were similarly triggered.
During imports and stuff, it's imperative that all steps utilise the same encoding/character set. If a text file is not using the preferred encoding, we can use Vim to change it during its save action as follows:
:set fileencoding=utf8
:w
or if you want to save it to a different file and leave the current file unchanged:
:w ++enc=utf-8 newfile.txt
Just now while attempting to perform a substitution in GVim, I found that the regex was not working as expected. Apparently, instead of matching all non-whitespace characters denoted by the shorthand class \S
, the engine was matching the letter S instead, which was odd. It turns out that, as usual, I was the one at fault. What I was doing wrong was attempting to use the character class within []
groups.
Earlier today, I had to perform a substitution in Gvim within a 2GB file. Unfortunately, after a few thousand operations, Vim ran out of memory with the following error:
Out of memory!
Out of memory! (allocating XXX bytes)
Windows too complained about running out of virtual memory and my system slowed down to treacle-like response times.
Today, I made quite an impression on my furniture thanks to incessant contact between it and my illustrious head. This, as usual, was due to my looking for a clean regex to solve my issue while working with text files in Vim. My task was, I initially believed, quite simple: delete all the lines that are sandwiched between two types/patterns of lines. In this case, the top slice of the sandwich consisted of a line which was entirely a number and the bottom slice was a line entirely populated with underscores.
On a new installation of GVim (in Windows 7), I ran into the following curious error whenever I tried to open a new document for editing:Vim E303: Unable to open swap file for "[No Name]", recovery impossible
According to friendly chap on IRC, this is caused by a temporary directory bug and that it can be fixed by adding the following directive to the _vimrc
file:set directory=.,$TEMP
I'm not sure whether it was something I did, something that the Vim developers did, or an anomaly with the Windows 7 binary, but I could no longer see the line number and cursor position tracker in the bottom right of my interface. Looking at the menus, I could find nothing. I could turn on a line number prefix for each bleeding line, but this is not what I was after.