My vi editor has started behaving weirdly since today morning.
When I use keys in command mode, the characters are being overwritten. For example when using 'w' for word jump, it replaces the characters. To make sure something is not wrong with my settings I have removed the .exrc file from my home, but its still not working correctly.
I am using solaris 10, shell is ksh and version is: Version SVR4.0, Solaris 2.5.0
Example:
VARCHAR(3) is changed to (3) CHAR(3) on doing word jump.
Any idea how it has changed suddenly? Does it use any other default resource file that might have been changed?
It need not be a resource file of vi that has been changed. The setting of the environment variable TERM in the original shell session may be wrong. Compare $TERM there and in a new shell.
Related
I have a daily use case where I need to work with projects on different version of Java (8, 11, ...).
I would like to have it displayed in the right side prompt in my shell (ZSH with Oh-My-Zsh). I know of a dummy way (computationally expensive) to do it (just java --version to var and display it). I would like it to have it cached until I don't source a file (which is a specific project file that sets the new env vars for different java versions).
Do you have any ideas how to do this efficiently?
Br,
Stjepan
The PROMPT and RPROMPT variables can have both static and dynamic parts, so you can set the version there when you source the project file, and it will only be calculated one time. The trick is to get the quoting right.
This line goes in the project file that sets the env variables, somewhere after setting PATH to include the preferred java executable:
RPROMPT="${${=$(java --version)}[1,3]}"
The pieces:
RPROMPT= - variable for the right-side prompt.
"..." - the critical part. Variables in double quotes will be expanded then and there, so the commands within this will only be executed when the project file is sourced.
${...[1,3]} - selects the first three words of the enclosed expression. On my system, java --version returns three lines of data, which is way too big for a prompt; this reduces it to something manageable.
${=...} - splits the enclosed value into words.
$(java --version) - jre version info.
I am trying to set the dictionary option (to allow autocompletion of certain words of my choosing) using wildcards in a filename glob, as follows:
:set dict+=$VIM/dict/dict*.lst
The hope is that, with this line in the initially sourced .vimrc (or, in my case of Windows 10, _vimrc), I can add different dictionary files to my $VIM/dict directory later, and each new invocation of Vim will use those dictionary files, without me needing to modify my .vimrc settings.
However, an error message says that there is no such file. When I give a specific filename (as in :set dict+=$VIM/dict/dict01.lst ), then it works.
The thing is, I could swear that this used to work. I had this setting in my .vimrc files since I started using Vim 7.1, and I don't recall any such error message until recently. Now it shows up on my Linux laptop as well as my Windows 7 and Windows 10 laptops. I can't remember exactly when this started happening.
Yes, I tried using backslashes (as in :set dict+=$VIM\dict\dict*.lst ) in case it was a Windows compatibility issue, but that still doesn't work. (Also this is happening on my Linux laptop, too, and that doesn't use backslashes for filepaths.)
Am I going senile? Or is there some other mysterious force going on?
Assuming for now that it is a change in the latest version of Vim, is there some way to specify "use all the dictionary files that fit this glob"?
-- Edited 2021-02-14 06:17:07
I also checked to see if it was due to having more than one file that fits the wildcard glob. (I thought that if I had more than one file that fit the wildcard, the glob would turn into two filenames, equivalent to saying dict+=$VIM/dict/dict01.lst dict02.lst which would not be syntactically valid.) But it still did not working after removing extra files so that only one file fit my pathname of $VIM/dict/dict*.lst . (I had previously put another Addendum here happily explaining that this was how I solved my problem, but it turned out to be premature.)
You must expand wildcards before setting an option. Multiple file names must be separated by commas. For example,
let &dictionary = tr(expand("$VIM/dict/dict*.lst"), "\n", ",")
If adding a value to a non-empty option, don't forget to add comma too (let is more universal than set, so it's less forgiving):
let &dictionary .= "," . tr(expand(...)...)
i'm using zsh on my mac (oh-my-zsh) and i don't understand why at the end of my output there is always this character: "%"
If i don't put export TERM="xterm-256color" in my ~/.zshrc i haven't that character:
Usually a bold % (or # for root) with reversed colors is used to signify a "partial" line in the output. That is a line, which is not terminated with a newline character.
As it seems to depend on the value of TERM I suspect an incompatibility between that value and the settings of terminal emulator. Contrary to the warning shown in your second screenshot, you actually should not set TERM in your ~/.zshrc (or anywhere inside the shell session). TERM should always be set by the terminal emulator itself. Its value (in conjunction with the terminfo terminal capability data base) tells the shell and other programs, which features a terminal emulator supports and how to use them. If the value is changed in the shell, the terminal emulator will not know about it. This may lead to programs sending control codes the terminal emulator does not understand correctly or at all.
In order to change the value of TERM you should change it in the terminal emulator settings. According to the iTerm 2 FAQ the settings is to be found at Preferences->Profiles->Terminal->Report Terminal Type.
I personally placed export PROMPT_EOL_MARK='' inside my ~/.zprofile and hide the character.
Currently I have installed zsh in archlinux (in gnome 3), and every time when I open the terminal, there are 3 "???" before, then I have to change it manually on the options
Actually I have already set the default locale to UTF-8, and it works in the console before I enter the gnome.But after I enter the gnome interface, it did not work.
After I have changed that, it works, but there is another problem, everytime I type a command and press tab, all the command will be shifted right by 2 words, for example if I type ls, it will display like this:
ls becomes lsls
vim becomes vivim
The first 2 letters cannot be cleared, which is very annoying, can anyone help me about this? Thanks
I finally got how to solve this question
After we enabled the locale in the /etc/locale.gen and use locale-gen to generate it. I have to also set the locale system-wide,
create the /etc/locale.conf file
and set the default locale
localectl set-locale LANG="de_DE.UTF-8"
Then if I exit and log again, the oh-my-zsh will work fine.
I recently installed Zsh in hope of a better life and brighter mornings. However, I quickly realized Zsh introduces various issues in conjunction with tmux.
The first issue was some weird stuff happening at the end of the prompt, before my commands, but this was resolved by supplying tmux with the -u flag for unicode-support. However, I am stuck with one final issue that needs resolution before I can use Zsh with tmux:
Usecase: Autocomplete a command which contains multiple suggestions
Issue: Autocompletion shifts suggestion one character to the right, while leaving the original character behind (visual bug, it is not included in the command)
Example 1.
Then I hit TAB..
Example 2.
Then I hit TAB..
Note 1: This does NOT occur when using the Bash-shell.
Note 2: I am using "oh-my-zsh". This issue only occurs when using the provided themes. This narrows it down to an "oh-my-zsh"-theme issue, not native zsh/tmux.
In case some people still get a similar issue, see also the top-voted answer of Remnant characters when tab completing with ZSH. The plugin you were using may have had the same non-printable characters issue, that would explain the symptoms.