So I've started to use Anything with Emacs. You can use 'locate' with anything, but you can also use VoidTools' 'Everything' (which is actually the default for 'Windows-NT' systems.
It took a little bit of prodding, but I have command line Everything working on my system. I get results back from it while using anything-locate or anything-for-files.
Everything works fine except I get the dreaded ^M (control-M) at the end of the lines that es returns to me. That means when I use anything to open the file, it doesn't work.
Anyone have any help on how to fix values that es returns, or alternately, strip off the ^M before trying to open the file?
Ah-ha, in the end, it was my fault.
Be careful when messing around with the process-coding-system-alist, and make sure that it's something that really needs to be done. I modified this in the past thus:
(setq process-coding-system-alist (cons '("bash" . (raw-text-unix . raw-text-dos))
process-coding-system-alist))
And I don't need to do that anymore. It meant that the files being passed up from Everything were being interpreted Unix style, and the CR/^M were showing up. By commenting out this line, I solved my own problem.
Related
I was just wondering if anyone knows the emoji support that the Terminal.app has in MacOS?
I'm using zsh, and I end up with this when I type it out, I get the following (note I didn't add a space after the flag on the first one, but added a space on the second one but in both cases you can see there's an overlap on the flag, also note the duplication on the spaces and f on the end of the input)
And when using vim I also get
Just wondering how people resolve these?
Thanks in advance!
When using Mac OS X including iTerm, I can simply press
Shift+$ and the line in bash that I am currently tiping will get a # added to the beginning and the line returns. I like this very much as it prevents from actually executing that command while still editing it and I don't have to jump to the beginning of the line to insert that # character there.
However, when I log onto our cluster, this functionality is lost. I tried to search for this feature but only found posts about using sed etc. so suggestions which are not for the interactive kind of using bash that I am referring to.
Could somebody please point me to a resource where this functionality is explained (bash-guide?) so I could look up how to make it work when logging in to other machines? Or is this something Mac/iTerm-specific? But then, I would expect it to work also on our cluster, as long as I use my machine of course.
This might work for you
See insert-comment (M-#)
My standard mode of working in Python is to edit a text file while having IPython open in a terminal. I write functions one line at a time and paste them one at a time into IPython. When a line is wrong i correct it in the text editor and then re-paste it.
This used to work well but recent versions of IPython won't accept indented code. One suggested solution is to use the qt terminal, but often I am logged in over an ssh session. Another suggested solution is to use %cpaste but that's two much overhead if you paste one line of indented code at a time (%cpaste at the beginning and -- at the end; 2 lines of overhead per line of code). What I currently do is unindent every block in my text editor before i start working on it, but that's a pain too. Any other ideas? What would be great is if there's a way to put IPython permanently into %cpaste mode, or whatever part of that mode makes it disregard leading whitespace.
See also:
unexpected indent in ipython 0.10.1
https://github.com/ipython/ipython/issues/573
thanks
Just submitted a pull request that should fix this. For large blocks delimited by multiple newlines, %cpaste is still recommended.
For some reason, I cannot jump forward with <C-I>; gives me the error beep. <C-O> works just fine.
I don't see any remapping going on either. Any ideas what might be the problem?
I'm using vim 7.3 on win7
EDIT: I just found out <C-I> does the same as %! I still can't figure out how to fix it though.
Why does having <TAB> mapped affect <C-I>? The short answer is, "historical reasons", dating from even before the original 'vi'.
The ASCII code for <TAB> is 9, same as <CTRL-I>. Since terminals receive their input encoded in ASCII, they can't tell whether that "TAB" signal came from the actual <TAB> key, or from the user holding CTRL and pressing I. Since Vim was originally written to run on terminals, it can't tell the difference either.
A couple of other pairs of indistinguishable keys are <C-M> with <Return>, and <C-[> with <Esc>.
It's possible there's some arcane way to tell the difference between the two (more likely if you're using GVim), but if there is, I don't know it. As a workaround, you could use nnoremap <SomeOtherKey> <C-I> to give <C-I>'s original function to some other key.
I found a fix for the problem, but I don't know why it works..
I had <TAB> mapped to %. By removing this, <C-I> works as normal.
Any idea why this works...?
I've sort of got Fsi.exe working as expected on a Mac OS X (Snow Leopard) with Mono. I just noticed a little bit of odd behavior with cut and paste and I was wondering if anyone had seen this.
I've defined the following alias for fsi:
alias fsi='ledit mono ~/FSharp-1.9.7.8_2/bin/fsi.exe --gui-'
ledit is an Ocaml utility that seems to make the keyboard input work correctly--without it, fsi just never seems to read the input. To see what I mean, try Fsi.exe without ledit and enter
let square x = x * x;;
without ledit, it just never seems to parse the input. I mean it never comes back to the ">" prompt after you enter the string. With ledit, the ">" prompt comes back immediately.
Of course the --gui- keeps fsi from displaying all the messages about the lack of System.Drawing etc.
So this all seems to work. The oddity is when I copy and paste code into the FSI, certain characters seem to repeat over and over again. It seems to be conditioned by the size of the buffer I'm pasting in. When I paste small snippets there seems to be no problem. But if I paste in larger chunks, there's this oddity.
If I do the following:
open System.IO;;
then paste this code snippet in FSI:
let buildFileList basepath filespec =
seq {
yield! Directory.GetFiles(basepath, filespec, System.IO.SearchOption.AllDirectories)
}
That works fine. But if I copy and paste in a bigger chunk of code ending with that, it repeats the portion up to the yield! over and over again. It seems to be somehow related to fsi attempting to parse the code as it's being pasted in because the same code pasted in will cause parsing errors (like FS0010) when it's pasted at the end of a long chunk but won't cause an error when it's isolated.
If I #load the entire file, it parses correctly as well so I think my code is ok.
This oddity in copy/paste seems to happen both with and without ledit on the command line. I don't mind researching this issue myself but I'm kind of stumped about where I should proceed with this. I'm copying from GVim if that makes a difference but anyone have any idea where I might proceed in trying to isolate the cause of this odd behavior? I suppose I could take the extra step of copying into TextEdit first and then trying to copy into fsi but any ideas beyond that?
To bottom line this: has anyone else seen this odd behavior? If not, any suggestions about how I might proceed in trying to isolate the cause of this odd behavior?
When I encountered this behavior on my Mac, I went a different route. Instead of using ledit, I employed fsi's --readline option, seen below (where ${FSHARP} is my install path).
mono ${FSHARP}/fsi.exe --readline+ --gui-
You may also want to check your terminal settings. My terminal (for example) is declared as xterm-color, and I have unchecked delete sends CTRL-H. I think those are the only relevant settings, but don't hold me to it.