What might cause Vim to throw errors on one machine but not the other, considering both systems have identical vim configuration?
I have two Mac OS X Lion machines both running the default vim binary that ships with the OS.
I keep my .vimrc and .vim directory in a git repo. However, starting vim on one of these machines throws an error:
Error detected while processing function <SNR>41_CreateMaps..<SNR>41_DefineVariables..AutoClose#DefaultPairs..AutoClose#ParsePairs:
line 18:
AutoClose: Bad pair string - a pair longer then two character
line 19:
E121: Undefined variable: a:sring
E15: Invalid expression: " `- String: " . a:sring
line 20:
`- Pair: «» Pair len: 4
I keep my plugins organized using the Vundle plugin. The error appears to be caused by the AutoClose plugin.
For the sake of austerity, I removed the vim directory and all .vim files in my home directory then sourced everything from the repo and reinstalled the plugins, but the error remains.
I should add that the issue does not come up when launching MacVim, only vim in terminal.
Since vim comes preinstalled with Mac OS X Lion and my other machine (running the same version of Mac OS) does not generate those errors whilst using the same settings, I'm left clueless as to where to look..
In case it makes any difference, both machines have MacVim installed but the error only shows on one of them and only when launching vim from command line.
This is probably because the file is in a different encoding (latin1 vs UTF-8) than VIM expects.
If you put scriptencoding utf-8 at the top of your .vimrc (assuming your vimrc is actually encoded in UTF-8, use ISO-8859-1 if it's encoded in Latin1), everything from that point on should be properly recognised.
To see more documentation about this feature, type :help scriptencoding in vim.
(source: http://vim.wikia.com/wiki/Converting_LANG_to_UTF-8 and vim manual)
Related
I'm working with Clisp 2.49 on Windows 10. I want to open a file (to read or to write) in a folder with a name which contains non-ASCII characters, for example: foo-dir-᾿Αθηναῖοι. When I try any file operation, I get an error that the folder does not exist.
Here is a console (cmd.exe) session. The operations shown in this session are calls to TRUENAME, which seems a suitable test, and calls to OPEN trigger the same error.
C:\Users\dodier\Temp\foo-dir-᾿Αθηναῖοι>C:\maxima-5.45.1\clisp-2.49\clisp.exe -E UTF-8
[1]> (setq ext:*pathname-encoding* 'charset:utf-8)
#<ENCODING CHARSET:UTF-8 :UNIX>
[2]> (truename #p".")
*** - TRUENAME: Directory #P"C:\\Users\\dodier\\Temp\\foo-dir-?????a???\\" does not exist
[4]> (setq ext:*pathname-encoding* 'charset:cp1251)
#<ENCODING CHARSET:CP1251 :UNIX>
[5]> (truename #p".")
*** - TRUENAME: Directory #P"C:\\Users\\dodier\\Temp\\foo-dir-?????a???\\" does not exist
Note that the current working directory is the folder which has non-ASCII characters in its name.
Note that I have launched Clisp with the option -E UTF-8. I tried setting EXT:*PATHNAME-ENCODING* to plausible values (UTF-8 and CP1251) but neither one works.
Is there a setting or option I can try to help Clisp along here?
Is anyone familiar enough with Clisp internals to say what low level operation is failing when Clisp says the folder does not exist? I am thinking that if I knew, I could try to steer around it.
I was getting the same error on macOS, and I found that building a current version from Git (https://gitlab.com/gnu-clisp/clisp) fixed the problem. I tried to do the same on Windows, but I'm running into compiler errors; apparently some code which is accepted by gcc on other platforms is rejected by gcc on windows. For the record I'm working with gcc 11 installed via Cygwin.
So in summary my guess is that the observed behavior is a bug in Clisp which has been fixed in recent versions, although I'm unable to verify that directly.
I tried to upgrade my system Vim from 7.3 to a high version so I used macport to do that. This newer version is located in /opt/local/bin/. Later I decided to uninstall it due to some reason.
Now I can't open my system Vim in the terminal, the error message is -bash: /opt/local/bin/vim: No such file or directory. Somehow the machine still thinks the vim is located in /opt/local/bin/.
Then weird thing happens, when I type which vim, it shows my vim located at /usr/local/bin, and there is indeed a vim folder in that directory, but I can't open it by typing vim in the terminal.
So here is the situation: I have two working versions of Vim in my machine, a 7.3 version in /usr/bin and a 7.4 version in /usr/local/bin(I don't know how I got this one). Both working (I have to type the whole directory /urs/bin/vim or /urs/local/bin/vim), but can't be opened in the terminal by simply typing vim.
Updates:
now I can use vi or vim, but the problem is, the former opens 7.3 whereas the latter opens 7.4
At the current command window, type:
$ hash -r
then try running vim again. Or create a new window and try in that.
Bash remembered where vim was found, and expects to find it there again. When you removed vim, it got upset and complained (rather than try to find it again before complaining). Using hash -r vim forgets all previously hashed commands and then finds vim explicitly. Run hash with no options to see what it knows.
See the Bash manual on hash for more information.
The default Vim is /usr/bin/vim. There is absolutely no reason whatsoever to change it.
If you want a more up-to-date Vim, install MacVim and use the bundled mvim script instead of vim.
I'm in trouble to make flyspell to work in emacs. I'm a Mac user, but I'm not using Aquamacs, which seems to provide this facility by default.
Starting new Ispell process [/usr/local/bin/aspell::default] ...
ispell-init-process: Error: No word lists can be found for the language "en_US".
The error message is trying to tell you that Emacs started the external program aspell in a subprocess, which is good, but that it couldn't find its dictionary file, which is bad.
Try typing M-x ispell-change-dictionary RET SPC to see if there are any dictionary files that Emacs knows about, and select one of them.
If that doesn't work, then there is something wrong with your installation of flyspell. What to try next depends on the version of Emacs you are using (the terminal version that comes with OS X, a newer terminal version installed via Homebrew or MacPorts, the Cocoa version, or Aquamacs). On my machine, for example, I am running Cocoa Emacs 24 under Snow Leopard, and flyspell.el comes preinstalled, but to actually get it to work I had to install the aspell package using Homebrew (which provided the aspell executable and its dictionary files). Can you give us more information about your environment (OS X version, Emacs version, etc.)?
I've been using the vim-latex suite on my mac (10.7.?) for months with no problem. Over the weekend, I upgraded the OS to 10.8.2, and now my tex files fail to compile. The compile command
\ll
produces no errors within vim, but no pdf-file gets produced. If I drop to the command line in a terminal, the following command
latex document.tex
produces
-bash: latex: command not found
Similarly, for pdflatex. I'm not sure if this is a path error, or if latex for 10.8.2 needs to be reinstalled. I'm not sure how to proceed in either case.
I had the same problem and typing:
export PATH=/usr/texbin:$PATH
seems to work fine in a shell. Although it no longer works if I open a new shell, this is a faster solution to re-downloading and re-installing the huge MacTeX program.
This happened to me after upgrading to OS X El Capitan. I found the latex executables in /usr/local/texlive/2014/bin/x86_64-darwin. So, I just added this to my .bashrc
export PATH="$PATH:/usr/local/texlive/2014/bin/x86_64-darwin"
No need to reinstall.
On OS X, the standard way for third party installers to add a directory to the path is to put a file under /etc/paths.d. TeXLive does this as part of the installation, but the OS upgrade probably blew it away.
You should be able to just create a new file under that directory containing just one line, the path the directory containing the TeX executables.
When setting the path via #petew's answer, /usr/local/texlive/2014/bin/x86_64-darwin may not be the correct version. On my system /usr/local/texlive/2021/bin/universal-darwin was what was needed. Make sure to check your texlive binaries to see what file you downloaded.
I am learning SICP. I'm using Edwin 3.116 that installed with MIT-Scheme on my Windows 7 (32-bit) / AMD (64-bit) machine.
For the life of me I have not been able to discover why Edwin is unable to open and read a file correctly:
When I open an existing .scm file (with my code in it) Edwin just opens a blank buffer with my file name.
If I then save it, my code gets over-written with blankness. So clearly Edwin is not at pains to write.
Apart from not being able to find any answers, I have had no success with the following:
C-x C-f followed by full path D:\my-schemes\filename.scm (while the default directory was at C:.....)
M-x cd followed by d:\my-schemes followed by C-x C-f filename.scm
Quit, restart MIT-Scheme and re-try above commands
Uninstall-reinstall MIT-Scheme and re-try above commands
Is there something I have not done - like specify some parameter in some configuration file? (The Installation guide does not require any special config. for Windows, other than to follow the installer.)
I'm getting by with copy-pasting code from file-to-buffer and writing from buffer-to-file for now, but my scheming could be so much better if I could get Edwin to read too.
just in case you might not yet found a solution. I encountered the same problem and just found one that worked for me so I'm thinking sharing my solution.
If you installed with the default setting, everything is installed in 'Program Files/...'. The problem with this seems to be that the directory name contains space. When I tried saving in other directory without space, and I could write to a file. I can open the file with a normal text editor, but when I open with Edwin all I saw was a blank page. I tried installing an older version (MIT GNU scheme 9.0) and it worked as mentioned in this bug report: http://savannah.gnu.org/bugs/?35250
vutha's suggestion of installing in a directory without spaces didn't work for me because I needed to access files inside a folder with spaces in the name. But it pointed me in the right direction. There is a bug in versions 9.1 and 9.2 that completely brakes Edwin in Windows.
The only thing that worked was to uninstall the latest version (there is a uninst.exe file in the installation folder) and then install version 9.0.