I installed ghci on Max OSX.
But everytime, the return value overwrite my last ghci prompt.
See below.
Falseghci>null[1,2,3]
Luke_ghci>
"False" over write my last line ghci prompt. (should be Luke_ghci)
So weird. How to solve it?
Thanks.
Copied from the above-linked message:
Aha! That led me to find it: I had TERM set to 'ansi'. ghci +
Haskeline works find if TERM is set to any of rxvt, vt52, vt100, vt102
or xterm. Don't know what in terminfo Haskeline is relying on, but
'ansi' doesn't have it!
Related
prt path <mru>={ files }=<buf> <-> /home/....
Error detected while processing function <SNR>48_NormalPasta:
line 13:
E21: Cannot make changes, 'modifiable' is off
Press ENTER or type command to continue
kind of a strange vim error I get when I try to type the 'p' character using vim & ctrlp, using linux ubuntu here
Let's take that message one line at a time:
Error detected while processing function <SNR>48_NormalPasta:
There is an error in function NormalPasta() in the 48th script that was sourced by Vim.
line 13:
The error is on line 13 of that function.
E21: Cannot make changes, 'modifiable' is off
The function is trying to edit a non-modifiable buffer.
From there, you can do:
:filter 48 scriptnames
or:
$ grep -R NormalPasta ~/.vim/**/*.vim
to find in what script the problematic function is located.
This leads to this plugin, which appears to be OK. The whole situation seems rather strange, though, because the problematic function is supposed to be called from normal mode and I don't think a) that you should be in normal mode at CtrlP's prompt and b) that the CtrlP prompt is supposed to be non-modifiable.
My opinion is that the vim-pasta plugin is OK and thus that there is something fishy going on with CtrlP itself or the way you use it.
This is really just out of curiosity.
A typo made me notice that in Bash, the following:
$ .anything
does not print any error ("anything" not to be interpreted literally, it can really be anything, and no space after the dot).
I am curious about how this is interpreted in bash.
Note that echo $? after such command returns 127. This usually means "command not found". It does make sense in this case, however I find it odd that no error message is printed.
Why would $ anything actually print bash:anything: command not found... (assuming that no anything cmd is in the PATH), while $ .anything slips through silently?
System: Fedora Core 22
Bash version: GNU bash, version 4.3.39(1)-release (x86_64-redhat-linux-gnu)
EDIT:
Some comments below indicated the problem as non-reproducible at first.
The answer of #hek2mgl below summarises the many contributions to this issue, which was eventually found (by #n.m.) as reproducible in FC22 and submitted as a bug report in https://bugzilla.redhat.com/show_bug.cgi?id=1292531
bash supports a handler for situations when a command can't be found. You can define the following function:
function command_not_found_handle() {
command=$1
# do something
}
Using that function it is possible to suppress the error message. Search for that function in your bash startup files.
Another way to find that out is to unset the function. Like this:
$ unset -f command_not_found_handle
$ .anything # Should display the error message
After some research, #n.m. found out that the described behaviour is by intention. FC22 implements command_not_found_handle and calls the program /etc/libexec/pk-command-not-found. This program is part of the PackageKit project and will try to suggest installable packages if you type a command name that can't be found.
In it's main() function the program explicitly checks if the command name starts with a dot and silently returns in that case. This behaviour was introduced in this commit:
https://github.com/hughsie/PackageKit/commit/0e85001b
as a response to this bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1151185
IMHO this behaviour is questionable. At least other distros are not doing so. But now you know that the behaviour is 100% reproducible and you may follow up on that bug report.
I have a default installation of vim on linux, on a system with a vt52 terminal emulator and unicode capability.
Everything has been working fine until today when I moved my vt52 terminfo file from the temporary local user directory to the permanent system directory ... at first it seemed fine, but all the sudden, when I try to execute a colon command by pressing enter (either CTRL-J, or the key itself == decimal 10), vim just flashes the screen but doesn't execute the command or leave command entry mode.
However, If I press CTRL-M to get a carriage return character (decimal 13), vim does accept the command.
I tried copying the file back to ~/.terminfo again, but it didn't fix the problem...
I thought this might be either a tty issue or a corrupted vimrc file, so...
first I tried deleting the .viminfo and .vimrc files, and doing a stty sane before starting vim but neither helps. I just noticed that enter doesn't work in insert mode either, but CTRL-M does.
Then I checked from the bash shell, using CTRL-V, that when I press CTRL-M, it shows ^M and when I press CTRL-J, it just enters and shows nothing. So -- to double check -- I did a stty raw and cat - | hexdumpx, and sure enough pressing enter returns only 0x0a, and pressing CTRL-M returns only 0x0d ; so the keyboard driver is returning the proper character in raw mode, and I retested in sane mode which apparently maps both of them to 0x0A.
The termcap file I re-compiled with tic, and copied to both ~/.terminfo/v/vt52u where it worked fine before -- and over to /usr/share/terminfo/v/vt52u.
But I don't see anything in the termcap file which could possibly cause the problem.
vt52u|vt52 with UTF-8:\
:am:eo:rs=\Ee\Eb0\Eco:is=\EE\Ee:\
:nl=^j:sr=\EI:bl=^g:ta=^i:\
:ho=\EH:cr=^m:le=\ED:nd=\EC:do=\EB:up=\EA:ta=^i:nw=^j^m:xn:\
:cm=\EY%+ %+ :it#8:co#75:li#24:\
:sc=\Ej:rc=\Ek:\
:vi=\Ef:ve=\Ee:\
:so=\Eb0\Ec3:se=\Eb0\Eco:mh=\Eb8\Eco:mr=\Ebo\Ec0:me=\Eb0\Eco:\
:cl=\EH\EJ:cb=\Eo:cd=\EJ:ce=\EK:\
:km:kb=^h:
EDIT:
I've isolated the problem by experiment 5 listed below, as being caused by something either in or missing from the above termcap file, or in the tic compiler's conversion of it to terminfo.
So -- what termcap entry is missing or which existing one is causing the problem?
---------------------- Additional experiments as I try to figure it out -------------------
1: doing a :set term in vim reveals term=vt52u .... which is correct. So VIM should be using the above termcap file, but I don't know from where (eg: cached version, or not -- or corrupted.) and :version only reveals +termcap which says vim should be using a tic compiled termcap file which is what I've been trying to give it.
2: I recompiled ncurses-5.9, and re-installed it to make absolutely sure no corrupt files exist. Nothing changed even with: ./configure --prefix=/usr --without-cxx --without-cxx-binding --without-ada --without-manpages --without-progs --without-tests --with-build-cc=gcc --with-shared --without-debug --without-profile --without-gpm --without-dlsym --without-sysmouse --enable-sigwinch --enable-hashmap --enable-scroll-hints --build=i686-linux --host=arm-linux-gnueabi --without-pthread --enable-widec --with-fallbacks=vt52u --disable-big-core --enable-termcap --enable-getcap-cache
3: doing a :set termcap shows more keys defined than the termcap file has, which is bad... termcap only defined one key ... and that one should be ^H not ^?, so VIM's value doesn't match, but the other termcap values all match, since ^[ is the same as escape \E in the termcap file. So, I have proof that vim is definitely loading the proper termcap file because t_so 's value is unique to the vt52u. So -- it's not a corrupt termcap.... :( weird.
t_kb <BS> ^? <DecMouse> ^[[
t_kd <Down> ^# <NetMouse> ^[}
t_sr=^[I t_bc=^[D t_le=^[D t_cd=^[J t_ce=^[K t_cl=^[H^[J
t_me=^[b0^[co t_mr=^[b0^[co t_ve=^[e t_vi=^[f t_nd=^[C t_se=^[b0^[c0
t_ZH=^[bo^[c0 t_ZR=^[b0^[co t_so=^b0^[c3 t_cm=^[Y%p1%' '%+%c%p2%' '%+%c
4: Recompiled vim 7.4, to remove all built in terminals, and to insure no corrupt files. Had no effect; did not fix default value of backspace key being wrong.
echo "Please Edit feature.h so that NO_BUILTIN_TERMCAPS is always #defined."
sleep 5
vim /src/feature.h
./configure --prefix=/usr/ --build=i686-linux --host=arm-linux-gnueabi --with-features=big --disable-darwin --disable-selinux --disable-xsmp --disable-xsmp-interact --disable-mzschemeinterp --disable-tclinterp --disable-netbeans --disable-sniff --disable-gui --disable-cscope --disable-workshop --enable-multibyte --disable-gtktest --disable-gpm --disable-sysmouse --disable-xim --enable-pythoninterp=dynamic --without-x --with-tlib=ncursesw vim_cv_toupper_broken="yes" vim_cv_terminfo="yes" vim_cv_tty_group="world" vim_cv_tty_mode="0620" vim_cv_getcwd_broken="yes" vim_cv_stat_ignores_slash="yes" vim_cv_memmove_handles_overlap="yes"
echo "Please Edit src/Makefile such that STRIP=arm-linux-gnueabi-strip"
sleep 5
vim src/Makefile
make
make install
5: In bash, I changed the terminal type to generic "export TERM=VT52" rather than the unicode version, with color support which I compiled with tic. ** THE NEWLINE PROBLEM WENT AWAY WITH THE SACRIFICE OF COLOR COMMANDS, AND OTHER FEATURES OF VT52U ** I need the features, but apparently something about the termcap file I listed above is defective.
This was an ugly bug to track down by trial and error...
Vim appears to require keydown to be defined, and if not defined it assumes a default value of ^# ; for an unknown reason, it then treats the enter key as if it were a key down, rather than newline. ^# is logically the value for character code 0, null; which is the only character that would be found in an empty string in "C" which vim is written in and appears to trigger the issue/feature/bug.
But in any event in the termcap shown in the opening post, the kd symbol is not defined; and that's what is causing the problem.
Within vim, the problem can be solved by setting the termcap keydown variable as the same escape sequence which would normally exit insert mode, and then do letter j (down):
:set t_kd=\Ej
The same default can always be added to the termcap entries, too;
Since this is an input escape sequence and not a terminal output escape sequence, it doesn't conflict with the VT52's "save cursor" escape sequence defined in the termcap; eg: The VT52 will never see it since Linux tty's when in line entry mode do not echo escape sequences that come from the keyboard back to the terminal's output.
If a terminal doesn't have true arrow keys -- defining the arrow keys as escaped versions of vim's h,j,k,and l keys might be a reasonably compatible solution as long as it doesn't conflict with other programs which might want to use those input escape sequences for other things. I don't use emacs and other popular programs which might want those escape sequences for something, so if anyone else knows which (if any) programs would have problems with that solution, a comment would be appropriate.
In ncurses 5.9,there appears to be a bug in the terminfo compiler, so that on many installations (eg: slackware 14), 'tic' will not be able to compile terminfo source files -- but only termcap source files. If you want the termcap source code for an arbitrary terminal, you can run "infocmp -C fooTerminalName > fooTerminalName.tcap" to have the system generate a termcap source file for you that can be edited and recompiled with tic successfully.
When I load vim I get the following message that I cannot figure out how to debug.
4FNVHQ1|tmp
λ vim
default
Press ENTER or type command to continue
4FNVHQ1|tmp
λ
I've run vim -V9myVimLog and got this in the output but there's still nothing useful to me.
....
chdir(/c/Users/bjones/.vim/bundle/vundle/autoload/vundle)
fchdir() to previous dir
line 5: sourcing "/c/Users/bjones/.vim/bundle/vundle/autoload/vundle/config.vim"
finished sourcing /c/Users/bjones/.vim/bundle/vundle/autoload/vundle/config.vim
continuing in function vundle#rc
default
Searching for "filetype.vim" in "/c/Users/bjones/.vim/bundle/vim-javascript,/c/Users/bjones/.vim/bundle/vim-coffee-script,/c/Users/bjones/.vim/bundle/vim-jade,/c/Users/bjones/.vim/bundle/nerdtree,/c/Users/bjones/.vim/bundle/vim-rails,/c/Users/bjones/.vim/bundle/vim-commentary,/c/Users/bjones/.vim/bundle/vim-rake,/c/Users/bjones/.vim/bundle/snipMate,/c/Users/bjones/.vim/bundle/bsh.vim,/c/Users/bjones/.vim/bundle/vim-csharp,/c/Users/bjones/.vim/bundle/vim-distinguished,/c/Users/bjones/.vim/bundle/surround.vim,/c/Users/bjones/.vim/bundle/ctrlp.vim,/c/Users/bjones/.vim/bundle/jshint2.vim,/c/Users/bjones/.vim/bundle/vim-ps1,/c/Users/bjones/.vim/bundle/MatchTag,/c/Users/bjones/.vim/bundle/VCard-syntax,/c/Users/bjones/.vim/bundle/vim-liquid,/c/Users/bjones/.vim/bundle/vim-jst,/c/Users/bjones/.vim/bundle/vim-stylus,/c/Users/bjones/.vim/bundle/vim-swigjs,/c/Users/bjones/.vim/bundle/xmledit,/c/Users/bjones/.vim/bundle/vim-less,/c/Users/bjones/.vim/bundle/vim-markdown,/c/Users/bjones/.vim/bundle/vim-nerdtree-tabs,/c/Use
Searching for "/c/Users/bjones/.vim/bundle/vim-javascript/filetype.vim"
Searching for "/c/Users/bjones/.vim/bundle/vim-coffee-script/filetype.vim"
....
As you can see the word "default" is printed awkwardly in the debug log but there's nothing helpful.
Any help would be greatly appreciated.
EDIT: My vimrc is here: https://gist.github.com/brettof86/9906968
EDIT2 [FIX?]: IDK how it made a difference but I commented out every "Bundle" command in my vimrc then saved and quit. Then I went back and uncommented them 5 at a time and it started working? I have no idea why it was broken but I hope this helps anyone who may also run into this issue.
You mistakenly added an extra line colors in your vimrc, that as an VIM Ex command outputs the current selected colorscheme and since you haven't defined one yet, it outputs default since that is, as the name suggests, the default VIM colorscheme. You should comment it out since it clearly appears to be a documenting comment rather than executing an Ex command.
How do you compile and run Haskell on notepad++
I installed the plugin NppExec and then I pressed F6
I saved my Haskell file to C:\Users\Sam\Desktop\haskell files\new 3.hs
So on the command after I press F6 I tried typing in a few different things:
C:\Users\Sam\Desktop\haskell files\new 3.hs`
ghc.exe new 3.hs
haskell new
but I got these responses:
C:\Users\Sam\Desktop\haskell files\new 3.hs
CreateProcess() failed with error code 2:
The system cannot find the file specified.
ghc.exe new 3.hs
Process started >>>
target `new' is not a module name or a source file
<<< Process finished.
haskell new 3
CreateProcess() failed with error code 2:
The system cannot find the file specified.
================ READY ================
What is the correct way of compiling and executing at haskell file on notepad++?
You need to set NppExec to work in the current directory, so In Plugins, NppExec, tick Follow $(CURRENT_DIRECTORY).
Use the command ghc new3.hs when you press F6 (no spaces in filenames).
If you're using Haskell with stack, I found a lovely way to run things quickly using NppExec. It's a simpler process than it looks and once you do it, you're good to go:
Suppose you have a file like this in a file called yourFileName.hs:
main :: IO ()
main = putStrLn "Hello world!"
Press F6 to begin NppExec. (See Note 1 below.)
Paste the below into the window.
cd "$(FULL_CURRENT_PATH)"
stack ghci
// This is a comment you can delete. Note 2 below.
(See Note 3 below.)
Upon pressing the OK button, the Notepad++ console will run the Haskell interpreter.
Now, press F6 again. A warning menu will pop up.
Type this into the menu: :cmd return $ unlines [":l yourFileName", ":main"] and press ENTER. The file will execute. Pressing F6+ENTER will load and run the file again. When you open Notepad++ next time, this will still be there. Whenever you want to work with a new file, you will have to change yourFileName of course.
Explanation: :cmd return " . . . " allows you to execute a string as multiple ghci commands, separated by \n. unlines takes a list of strings and joins them with \n. If you don't know about $, you'll learn it soon as it's part of basic Haskell.
If you don't have a main function in your file, then instead use :cmd return $ unlines [":l yourFileName"].
Note 1: For convenience, I used the Settings > ShortCutMapper > Plugin Commands to change Execute from F6 to F1.
Note 2: If you run multiple languages in this way (like maybe Lisp?), then you can replace the // This is a comment... line with // :cmd return $ unlines [":l yourFileName", ":main"] just so you have it for later when you switch back to Haskell.
Note 3: Instead of pasting cd "$(FULL_CURRENT_PATH)" stack ghci into the NppExec window, a much simpler way to do all this is to paste stack runghc "$(FULL_CURRENT_PATH)" and nothing else needs to be done. However I found the console takes a lot longer to load and run the file in that case, so the method above is what I use.