alt-b, alt-f does not work in xterm - cygwin

I use xterm under cygwin/Xming.
Alt+B (jump one word backwards) and Alt-F (one word forward) do not work, but instead display some diacritical characters or something.
I have created a file .Xresources and a file .Xdefaults in my home dir, each containing only this line:
xterm*eightBitInput: false
Yet the problem persists.

I was trying to do the same.
I had to add:
xterm*metaSendsEscape: true
in my .Xresources file and then restart my system. Wouldn't work without the restart.

I think the relevant resource is metaSendsEscape, which you'll want to set to true.

Related

Why would Vim add a new line at the end of a file?

I work with Wordpress a lot, and sometimes I changed Wordpress core files temporarily in order to understand what is going on, especially when debugging. Today I got a little surprise. When I was ready to commit my changes to my git repository, I noticed that git status was marking one of Wordpress files as not staged for commit. I remember I had reverted all the changes I did to that file before closing it, so I decided to use diff to see what had changed. I compared the file on my project with the file on the Wordpress copy that I keep in my downloads directory. It turns out the files differ at the very end. diff indicates that the there is a newline missing at the end of the original file:
1724c1724
< }
\ No newline at end of file
---
> }
I never even touched that line. The changes I made where somewhere in the middle of a large file. This leads me to think that vim added a newline character at the end of the file. Why would that happen?
All the answers I've seen here address the question "how could I prevent Vim from adding a newline character at the end of the file?", while the question was "Why would Vim add a new line at the end of a file?". My browser's search engine brought me here, and I didn't find the answer to that question.
It is related with how the POSIX standard defines a line (see Why should files end with a newline?). So, basically, a line is:
3.206 Line
A sequence of zero or more non- <newline> characters plus a terminating <newline> character.
And, therefore, they all need to end with a newline character. That's why Vim always adds a newline by default (because, according to POSIX, it should always be there).
It is not the only editor doing that. Gedit, the default text editor in GNOME, does the same exact thing.
Edit
Many other tools also expect that newline character. See for example:
How wc expects it.
GCC warns about it.
Also, you may be interested in: Vim show newline at the end of file.
Because vim is a text editor, it can sometimes "clean up" files for you. See http://vimhelp.appspot.com/vim_faq.txt.html#faq-5.4 for details on how to write without the ending newline, paraphrased below:
How do I write a file without the line feed (EOL) at the end of the file?
You can turn off the eol option and turn on the binary option to write a file without the EOL at the end of the file:
   :set binary
   :set noeol
   :w
Alternatively, you can use:
   :set noeol
   :w ++bin
Adding a newline is the default behavior for Vim. If you don't need it, then use this solution: VIM Disable Automatic Newline At End Of File
To disable, add this to your .vimrc
set fileformats+=dos
You can put the following line into your .vimrc
autocmd FileType php setlocal noeol binary
Which should do the trick, but actually your approach is somewhat wrong. First of all php won't mind that ending at all and secondly if you don't want to save your changes don't press u or worse manually try to recreate the state of the file, but just quit without saving q!. If you left the editor and saved for some reason, try git checkout <file>
3.206 Line
A sequence of zero or more non- characters plus a terminating character.
Interestingly, vim will allow you to open a new file, write the file, and the file will be zero bytes. If you open a new file and append a line using o then write the file it will be two characters long. If you open said file back up and delete the second line dd and write the file it will be one byte long. Open the file back up and delete the only line remaining and write the file it will be zero bytes. So vim will let you write a zero byte file only as long as it is completely empty. Seems to defy the posix definition above. I guess...

How to truncate long file path in vim-powerline statusline?

I would like to truncate my file path to ex: a/a/j/c/popularCategories.js.
There are two options.
Try this option:
let g:Powerline_stl_path_style = 'short'
From the powerline docs:
short Display a short path. The home directory is substituted with
"~", the first directory is displayed with its full name, and
subsequent directories are shortened to their first letter.
I.e. "/home/user/foo/bar/baz.vim" becomes "~/f/b/baz.vim" and
"long/relative/path/foo/bar/baz.vim becomes
"long/r/p/f/b/baz.vim".
Or, if you want the path truncated like Vim's default statusline, then you can create a theme that moves the truncation point. Try my sanity theme and see if it works better for you.
There is currently no way to do this. I’ve missed this option somehow. There is an issue for changing the way powerline truncates path: issue 215, not to add truncation like I used to think.

What is the normal mode vim command that converts false to FALSE as well as 12:48:03 AM to 12:48 simultaneously?

I accidentally performed a command in Normal mode in vim, on a TSV file, where it converted all the false to FALSE, all the true to TRUE, and all the times from 12:48:03 AM format to 12:48.
I believe it was a single command, because I could undo and redo it using 'u' and 'Ctrl-R', but I can't figure out what it was. Does anyone know?
If there is a Command Mode equivalent, I'd also be interested in learning about it, but I am trying to find the normal Mode version.
I have already tried q: and know that it is not a Command Mode command that I accidentally hit.
For changing the case of words you use "gu" and "gU" in normal mode. Both need a scope, so he are some examples:
guu - make whole line lowercase
gUU - make whole line UPPERCASE
guw - make word lowercase
gUw - make word UPPERCASE
guj - make this and next line lowercase
gUk - make this line and previous line UPPERCASE
It also works with curent selections and is fully "." repeatable. More can be found under change in the vim docs.
You know vim has that magic. Try this:
:%s/\(\d\d\:\d\d\)\:\d\d\ [A-P]M\|\(true\)\|\(false\)/\1\U\2\U\3/g
In case you need explanation please reply to the post and i will explain it. Thanks!!
~ command does the following: Change the case of characters. This works both in visual and command mode. In visual mode, change the case of highlighted characters. In command mode, change the case of the character under cursor. This info is taken from tuxfiles
Edit: I guess my reply is not totally answers your question, but may help you
Also, how do you relate this with computer forensics?

Ignore one "misspelling" in Vim

Is there a way to tell Vim not to highlight a word once? For example, in "the password is abc123", I don't want to add abc123 to the wordlist, but still wouldn't like the big red rectangle around it.
Clarification: I'm looking for a command that makes the spell checker ignore the current word (or last misspelling).
Without having the word stored somewhere, it's hard (not to say impossible) to ignore it always.
But, if you are looking to ignore the word really once, that is only for a moment, you can add it to the internal list with the zG command.
*zG*
zG Like "zg" but add the word to the internal word list
|internal-wordlist|.
*internal-wordlist*
The internal word list is used for all buffers where 'spell' is set. It is
not stored, it is lost when you exit Vim. It is also cleared when 'encoding'
is set.
When your cursor is positioned on a word that is highlighted as misspelled you can add it to your wordlist by pressing zg. Vim allows you to load more than one wordlist at a time, which makes it possible to have (for example) a global wordlist, and a project specific wordlist.
By default, when you run zg it will add the current word to the first spellfile it finds in your runtime path for the current encoding. In my case, that turns out to be ~/.vim/spell/en.utf-8.add when I'm working with UTF-8 encoding. Try running the following commands:
:setlocal spellfile+=~/.vim/spell/en.utf-8.add
:setlocal spellfile+=oneoff.utf-8.add
That will set you up so that zg (or 1zg) adds the current word to your default spellfile. But running 2zg would add the current word to a file called oneoff.utf-8.add, in the same directory as the file that you are working on. If the file doesn't exist, Vim will try to create it for you.
When you open the file again in the future, you will have to run the same two commands to make Vim check the oneoff.utf-8.add spellfile. Unfortunately, Vim does not allow you to set the spellfile option in a modeline, so if you want to run these commands automatically when the file opens, you would have to find some other way. This question includes a few ideas on how you might proceed.

Gedit adds line at end of file

The answer to this must be somewhere but I'm not finding it -- can anyone help me understand why in Gedit, if I have a page of code there is no extra trailing blank line, but then when I do a file comparison for my svn commit it shows an extra line being added at the end of the file?
I have a feeling that Gedit is automatically adding an ending line break. But why, I have no idea...
Reality finally won and it's been fixed, but the broken behavior is still the default; enable the WYSIWYG behavior in a terminal with
gsettings set org.gnome.gedit.preferences.editor ensure-trailing-newline false
It's a feature. I don't think it can easily be disabled.
this is intentional: text files should always be terminated by \n, otherwise
tools like 'cat', 'sed' etc may have problems. However there is no reason to
always show an empty line at the bottom of the text view, that's why we do not
show the last \n
paolo borelli [gedit developer]
Some editors (I'm unfamiliar with Gedit specifically) will try to ensure that a file always ends with a newline character. Other editors, like perhaps the one that you originally created the file with, will allow you to end a file without a final newline character.
Try the Whitespace Remover plugin.

Resources