Leaving question here for reference. The Lord alone knows why, but whereas once upon a time this didn't work for me, prompting me to ask this question, today it does. Typical bloody emacs. Also typically, it is an utter joy once you've wrestled with it a bit. YMMV.
These two commands:
find ~/myco -type f -print0 | xargs -0 -e grep -nH -e "setjmp"
and
ack --no-heading --no-color "setjmp" ~/myco
Seem to me to produce very similar results at the terminal.
And yet when I try to use the second as the command with M-x find-grep in emacs, it just prints the results, rather than hyperlinking and highlighting them as it would with the first.
Anyone know what is happening? Initial experiments with ack at the command line indicate that it blows find and grep out of the water, so it would be nice to be able to use it from emacs too.
On windows I call ack from find-grep e.g. like this:
c:/xampp/perl/bin/perl.exe c:/bin/ack-standalone.txt --type-set java=.java --type=java -i information
and it's working perfectly. The results are linked and colored in the grep buffer. I don't know why it doesn't work for you, but I can say it does work here.
emacs version: GNU Emacs 23.2.1
ack version: 1.94
Emacs tries to show the output of find-grep in a buffer in grep-mode. Apparently grep-mode (surprise, surprise) doesn't understand the output format of ack. Use a dedicated ack-mode.
I found this ack-mode to work better, and out of the box. Some more coloring would have been nice, but at least it's readable:
https://github.com/sudish/ack-mode.el
Related
To not bore anyone here with specifics, whenever I evaluate an expression similar to this one:
emacsclient -t -e '(set-buffer *scratch*)'
the client will flash up on the terminal and crash.
This seems to be happening with all window-changing functions. Is the client not supposed to work like that? Running this in a normal emacs session does not cause this problem.
You're also using -t, but I'm not exactly sure why.
Is your emacs running in another tty session?
Or is your emacs running in windowing mode (e.g. on X Windows)?
If I have emacs running in windowing mode and I run the following command from another xterm window, then everything works exactly as I would expect it to:
emacsclient -c -e '(set-buffer "*scratch*")
Note in particular the -c option, and the fact that the buffer name is a string and so must be enclosed in double-quotes.
How do I consistently control window focus after running emacsclient?
Currently, focus depends on if I already have an emacs server running. When emacsclient invokes an alternative editor, focus is shifted to the new emacs window. When emacsclient connects to an existing emacs server, focus is not shifted (ie. it stays on my putty client).
I would like to consistently focus on the emacs window, since I usually go to emacs after opening a file.
Any help would be greatly appreciated!
Notes
Version Info
emacs: 21.4.1
emacsclient: 21.4
client os: Windows XP Service Pack 3
x server: Exceed 11.0.0.0
Relevant section of my .bash_profile
# a wrapper is needed to sandwich multiple command line arguments in bash
# 2>/dev/null hides
# "emacsclient: can't find socket; have you started the server?"
emacs_wrapper () {
if [ 0 -eq $# ]
then
emacsclient -n -a emacs ~/notes.txt 2>/dev/null &
else
emacsclient -n -a emacs $* &
fi
}
alias x="emacs_wrapper"
Also, at the end of my .emacs I have
(server-start)
My current workaround is a simple autohotkey script, which focuses on my first Exceed window
^+x::
If WinExist("ahk_class EXCEEDW:MWCLIENT0")
WinActivate
return
As a side note, it seems my redirection to /dev/null confused the syntax-highlighter :(
How about:
emacsclient -e "(select-frame-set-input-focus (selected-frame))"
works for me on emacs 23.1
To unfocus (lower-frame) might be useful.
Would the "--create-frame" option to emacsclient work for you? You'd get a new frame for each file you opened this way, but at least it would be focused (I think).
For some unknown reason, the issue fixed itself. Opening files now consistently changes focus to the emacs frame with the corresponding file. I'm honestly unsure what changed the behavior, but I'm happy.
Thanks to everyone for their comments and suggestions!
First time perl user and I am trying to debug some script to follow project logic and of course syntax.
Using cygwin after entering at command line $
$ perl -d sample.pl
Loading DB routines from perl5db.pl version 1.3
Editor support available.
Enter h or `h h' for help, or `perldoc perldebug' for more help.
main::(sample.pl:5): print 'Hello world.'; # Print a message
DB<1>
It hangs at the DB<1> line. I cannot enter anything at the prompt.
Is there a reason why this post is inappropriate? or how is this not clear?
This is the actual program code:
#!/usr/local/bin/perl
#
# Program to do the obvious
#
print 'Hello world.'; # Print a message
I upgraded my cygwin installation at home and ran into a similar problem (though maybe not the exact same problem -- the perl debugger still responds to my input but does not display my input, and fubars my input even after I quit the debugger). In the meantime while I figure what is going on, my workaround is to fire up xemacs, launch a shell (M-x shell), and run the perl debugger from the emacs buffer.
If this works for you, then there is something funky going on with your cygwin terminal settings. If your debugger hangs even in an emacs buffer, then something else funky is going on but I have no idea what it could be.
Sorry for reviving this three-year-old question, but I believe to have been hit with the same problem, and to have found the solution.
In my case, perl -de0 invokes infocmp from ncurses, which hangs in a weird way (can't kill it). And infocmp seemed to be a victim of my Avast anti-virus which is listed under BLODA as affecting Cygwin. Disabling it resolved the issue -- see if you have any of the listed applications and try disabling it (perhaps also try safe mode).
Also, simply renaming infocmp.exe allowed perl -d to run normally. In the end I used this approach and left my Avast running.
It could also be a different executable that perl -d is starting -- try to run whatever hangs with strace, see what is the last executable mentioned and try to see if that is the culprit.
I've downloaded and installed the GnuWin32 tools, and added the grep executables to the Emacs bin. I've also, for what its worth, added the GnuWin32 bin folder to my Path variable.
Problem is though, when I try and run with suggested grep commands, I always get:
Grep exited abnormally with code 53 at Wed Feb 24 17:16:12
For the life of me, I can't find any reference to error code 53 anywhere! :(
I've tried the exact examples on a number of websites for example, when I enter:
M-x grep <ret>
It comes up with
Run grep (like this): grep -n
Which is fine, but I have no idea of what parameters it expects. I've tried some in some tuorials, but I get error code 53 again!
One of the things I've tried is straight from the emacs wiki (http://www.emacswiki.org/emacs/GrepMode#toc2) (maybe not for the windows version though?) and it says to try this command:
M-x grep -n -e setq ~/.emacs
Which I've tried and I get:
-*- mode: grep; default-directory: "c:/[My Directory]/" -*-
Grep started at Wed Feb 24 17:30:47
grep -n -e setq ~/.emacs NUL
Grep exited abnormally with code 53 at Wed Feb 24 17:30:47
So frustrating as this is meant to be a powerful feature of Emacs and I'm really trying to learn it as I've heard good things about it!
Any help would be appreciated! :)
Andy
UPDATE
From the suggestion below, I've tried it via command line and it seems to work fine, perhaps there some config I'm missing?
UPDATE
I've found the command M-x Occur which seems to do much the same as I would image grep does. Are there many extra benefits to using grep over occur if I can't get this working?
Download the dependencies zip file and copy libiconv2.dll, libintl3.dll, pcre3.dll and regex2.dll to Emacs' bin directory.
Copy grep.exe and find.exe to Emacs' own bin directory. Emacs will then use these files over any other executables with the same name, including Windows' own find utility.
Note: if you don't use the installer, you need to download the dependencies zip file as well and copy libiconv2.dll, libintl3.dll, pcre3.dll and regex2.dll to Emacs' bin directory, otherwise you may get an "exited abnormally with code 53" error message.
EmacsWiki: Grep Mode
The exit code of 53 is possibly an OS exit code rather than a grep-specific exit code. For windows this would be "The network path was not found". Are you doing anything over a network path? Are there any missing dll's that grep needs? Can you successfully run grep on the command line?
I had a similar problem and the following worked for me.
Go to the windows console
Enter the command "set" to bring up your system variables
I had shell=c:\progra~1\rational\ration~1\nutcroot\mksnt\sh.exe
Enter "set shell=" to remove the variable
Try Emacs again
Good luck!
Today's Daily Vim says this:
Assuming you're using the bash shell, the following can be helpful when composing long command lines.
Start typing on the command line and then type Ctrl-x Ctrl-e, it should drop you into your system's default editor (hopefully Vim) and allow you to edit the command line from there. Once finished, save the command line, and bash will run the command.
Is there any way to do this in tcsh?
A little explanation for the uninitiated.
bindkey -v
puts you in vi-mode (oh yeah!)
and hitting v from there would take you to $EDITOR -- and all is good with the world from there on.
Hmmm... IIRC, tcsh uses a command called bindkey. Try bindkey -v at the command line. Then hit escape followed by v. It's been a while since I used tcsh so the details are a bit fuzzy. When in doubt, Google it.