I am starting with emacs, and don't know much elisp. Nearly nothing, really.
I want to use ack as a replacement of grep.
These are the instructions I followed to use ack from within emacs:
http://www.rooijan.za.net/?q=ack_el
Now I don't like the output format that is used in this el file, I would like the output to be that of ack --group.
So I changed:
(read-string "Ack arguments: " "-i" nil "-i" nil)
to:
(read-string "Ack arguments: " "-i --group" nil "-i --group" nil)
So far so good.
But this made me lose the ability to click-press_enter on the rows of the output buffer. In the original behaviour, compile-mode was used to be able to jump to the selected line.
I figured I should add a regexp to the ack-mode. The ack-mode is defined like this:
(define-compilation-mode ack-mode "Ack"
"Specialization of compilation-mode for use with ack."
nil)
and I want to add the regexp [0-9]+: to be detected as an error too, since it is what every row of the output bugger includes (line number).
I've tried to modify the define-compilation-modeabove to add the regexp, but I failed miserably.
How can I make the output buffer of ack let me click on its rows?
--- EDIT, I tried also: ---
(defvar ack-regexp-alist
'(("[0-9]+:"
2 3))
"Alist that specifies how to match rows in ack output.")
(setq compilation-error-regexp-alist
(append compilation-error-regexp-alist
ack-regexp-alist))
I stole that somewhere and tried to adapt to my needs. No luck.
--- EDIT, result after Ivan's proposal ---
With ack.el updated to include:
(defvar ack-regexp-alist
'(("^[0-9]+:" ;; match the line number
nil ;; the file is not found on this line, so assume that it's the same as before
0 ;; The line is the 0'th subexpression (the whole thing)
)
("^[^: ]+$" ;; match a file -- this could be better
0 ;; The file is the 0'th subexpression
))
"Alist that specifies how to match rows in ack output.")
(setq compilation-error-regexp-alist
(append compilation-error-regexp-alist
ack-regexp-alist))
(define-compilation-mode ack-mode "Ack"
"Specialization of compilation-mode for use with ack."
nil)
Then checking the compilation-error-regext-alist variable, I get the value:
(absoft ada aix ant bash borland caml comma edg-1 edg-2 epc ftnchek iar ibm irix java jikes-file jikes-line gnu gcc-include lcc makepp mips-1 mips-2 msft oracle perl rxp sparc-pascal-file sparc-pascal-line sparc-pascal-example sun sun-ada 4bsd gcov-file gcov-header gcov-nomark gcov-called-line gcov-never-called
("^[0-9]+:" nil 0)
("^[^: ]+$" 0))
I find the format of the variable very strange, isn't it? I don't know elisp (yet), so maybe it's correct that way.
Still no links or color in the *ack* buffer.
There is another full-ack package up on ELPA which I have used before and handles --group output.
That said, reading the documentation for compilation-error-regexp-alist you see that it has the form:
(REGEXP FILE [LINE COLUMN TYPE HYPERLINK HIGHLIGHT...])
In the case of --group output, you have to match file and line separately, so I think you want something like (untested)
(defvar ack-regexp-alist
'(("^\\S +$" ;; match a file -- this could be better
0 ;; The file is the 1st subexpression
)
("^[0-9]+:" ;; match the line number
nil ;; the file is not found on this line, so assume that it's the same as before
0 ;; The line is the 0'th subexpression (the whole thing)
))
"Alist that specifies how to match rows in ack output.")
-- Updated --
The variable compilation-error-regext-alist is a list of symbols or elements like (REGEXP ...). Symbols are looked up in compilation-error-regexp-alist-alist to find the corresponding elements. So yes, it is a little weird, but it's easier to see what's turned on and off without having to look at ugly regexes and guess what they do. If you were going to distribute this I would suggest adding the regex to compilation-error-regexp-alist-alist and then turning it on in compilation-error-regext-alist, but that is somewhat moot until you get it to work correctly.
Looking more closely at ack.el, I notice that it uses
(let (compile-command
(compilation-error-regexp-alist grep-regexp-alist)
...)
...
)
In other words it locally overwrites compilation-error-regexp-alist with grep-regexp-alist, so you need to add the regexes there instead. Or even better might be to replace it with
(let (compile-command
(compilation-error-regexp-alist ack-regexp-alist)
...)
...
)
In the end I still recommend full-ack since the filename regex does not seem to be working correctly. It seems more complete (though more complicated), and I have been happy with it.
Related
Generally, I find myself writing short macros that, e.g. add or remove line comments or correct indentation on a line.
However, with whitespace-mode enabled, I will still have to look out not to fire these macros on blank lines; if the macro tries to delete a character on an empty line, generally it will mess up the entire document.
Is there any solution to this problem which does not involve having some amount of spaces on blank lines, or otherwise altering my document structure?
You could use C-M-s ^. at the beginning of the macro. That is, search for a line that contains at least one character.
Expanding on the legoscia's answer -- here's a version which also notifies if there's no previous line at all:
(defun goto-first-previous-non-empty-line ()
(interactive)
(if (re-search-backward "^." nil t)
(message "First previous non-empty line")
(message "Beginning of buffer")
)
)
The Emacs Help page for the function shell-command-on-region says (elided for space):
(shell-command-on-region START END COMMAND &optional OUTPUT-BUFFER
REPLACE ERROR-BUFFER DISPLAY-ERROR-BUFFER)
...
The noninteractive arguments are START, END, COMMAND,
OUTPUT-BUFFER, REPLACE, ERROR-BUFFER, and DISPLAY-ERROR-BUFFER.
...
If the optional fourth argument OUTPUT-BUFFER is non-nil,
that says to put the output in some other buffer.
If OUTPUT-BUFFER is a buffer or buffer name, put the output there.
If OUTPUT-BUFFER is not a buffer and not nil,
insert output in the current buffer.
In either case, the output is inserted after point (leaving mark after it).
If REPLACE, the optional fifth argument, is non-nil, that means insert
the output in place of text from START to END, putting point and mark
around it.
This isn't the clearest, but the last few sentences just quoted seem to say that if I want the output of the shell command to be inserted in the current buffer at point, leaving the other contents of the buffer intact, I should pass a non-nil argument for OUTPUT-BUFFER and nil for REPLACE.
However, if I execute this code in the *scratch* buffer (not the real code I'm working on, but the minimal case that demonstrates the issue):
(shell-command-on-region
(point-min) (point-max) "wc" t nil)
the entire contents of the buffer are deleted and replaced with the output of wc!
Is shell-command-on-region broken when used non-interactively, or am I misreading the documentation? If the latter, how could I change the code above to insert the output of wc at point rather than replacing the contents of the buffer? Ideally I'd like a general solution that works not only to run a command on the entire buffer as in the minimal example (i.e., (point-min) through (point-max)), but also for the case of running a command with the region as input and then inserting the results at point without deleting the region.
You are wrong
It is not a good idea to use an interactive command like shell-command-on-region in emacs lisp code. Use call-process-region instead.
Emacs is wrong
There is a bug in shell-command-on-region: it does not pass the replace argument down to call-process-region; here is the fix:
=== modified file 'lisp/simple.el'
--- lisp/simple.el 2013-05-16 03:41:52 +0000
+++ lisp/simple.el 2013-05-23 18:44:16 +0000
## -2923,7 +2923,7 ## interactively, this is t."
(goto-char start)
(and replace (push-mark (point) 'nomsg))
(setq exit-status
- (call-process-region start end shell-file-name t
+ (call-process-region start end shell-file-name replace
(if error-file
(list t error-file)
t)
I will commit it shortly.
If you follow the link to the functions' source code, you'll quickly see that it does:
(if (or replace
(and output-buffer
(not (or (bufferp output-buffer) (stringp output-buffer)))))
I don't know why it does that, tho. In any case, this is mostly meant as a command rather than a function; from Elisp I recomend you use call-process-region instead.
In my case (emacs 24.3, don't know what version you're using), the documentation is slightly different in the optional argument:
Optional fourth arg OUTPUT-BUFFER specifies where to put the
command's output. If the value is a buffer or buffer name, put
the output there. Any other value, including nil, means to
insert the output in the current buffer. In either case, the
output is inserted after point (leaving mark after it).
The code that checks whether to delete the output (current) buffer contents is the following:
(if (or replace
(and output-buffer
(not (or (bufferp output-buffer) (stringp output-buffer)))))
So clearly putting t as in your case, it is not a string or a buffer, and it is not nil, so it will replace current buffer contents with the output. However, if I try:
(shell-command-on-region
(point-min) (point-max) "wc" nil nil)
then the buffer is not deleted, and the output put into the "Shell Command Output" buffer. At first sight, I'd say the function is not correctly implemented. Even the two versions of the documentation seem not to correspond with the code.
I have a single line text file of csv values
I would like to able to 'pretty-print' the file to span multiple lines to make it more readable
The 1st no. represents the no. of csv values in the next section and so on
e.g.
3,1,2,3,3,4,5,6
would be converted to:
3,1,2,3
3,4,5,6
I know a little about making macros, e.g.
C-x (
C-s RET ,
C-x )
using this I can do:
C-u 3 C-x e to move 3 csv values along
My sticking point is how to use the value from file to paste into the arg to C-u
maybe I should be using an e-lisp function instead as its a function I would like to 'save' for continual use across emacs sessions. Is it possible to save macros as such?
any ideas gratefully received
I find elisp easier to think about than keyboard macros. How about this:
(defun csv-line-breaks ()
(interactive)
(while (search-forward "," nil t
(1+ (string-to-number (thing-at-point 'word))))
(delete-char -1)
(insert "\n")))
(global-set-key (kbd "C-c b") 'csv-line-breaks)
With this in your .emacs (or just evaluate the code in your scratch buffer), you put point at the beginning of the line, then hit C-c b to break the line up into the chunks you want.
What this does:
Looping over the buffer until it runs out of values, and for each loop:
Read the first value. (thing-at-point 'word) grabs anything it finds between whitespace of punctuation (more or less).
Convert the value, which is actually a string, into a number
Add one to that number, and move forward that many commas
Delete the previous comma
Insert a new line
You might want to take a look at csv-mode for Emacs: http://emacswiki.org/emacs/CsvMode
Although it might not do exactly what you're looking for, it has a feature for formatting for readability, as well as other features for munging csv files in a variety of ways.
Alt+f in emacs when writing in tex mode seems to not include the . as part of the word. So how do I modify the alt+f behavior to remain the same exact when going forward if there is punctiation to include that as part of the word.
I have a separate file that loads for when writing in tex so I will just throw it in there so it doesn't affect normal emacs behavior.
Thanks for any help.
Thought of an addition to this but same related problem is when using Alt+d and deleting. Getting it to delete not only the word but also the punctation following eg.. (,.! etc..).
The following code should work for you:
(defun unpunctuate-syntax (str)
"Make the characters of the given string word characters."
(let ((st (copy-syntax-table (syntax-table))))
(dotimes (n (length str))
(modify-syntax-entry (elt str n) "w" st))
(set-syntax-table st)))
(defun dots-are-not-punctuation ()
(unpunctuate-syntax "."))
(add-hook 'TeX-mode-hook 'dots-are-not-punctuation)
The way M-f (the forward-word function) works is that it skips all characters in the buffer that have type "w" (ie word) in the current syntax table.
This code makes a modified syntax table and gives it to the buffer and the add-hook bit at the bottom sets it to run when you open a file in TeX-mode. (This method avoids you having to do the separate file thing you described).
You might notice that I make a copy of the syntax table rather than editing the one belonging to the TeX major mode. This is because I always get things wrong when playing with syntax tables and you can mess things up royally... This method means you just have to close the buffer and start again!
I'm using GNU Emacs 23.3 on Windows. I work in a very large codebase for which I generate a TAGS file (using the etags binary supplied with Emacs). The TAGS file is quite large (usually hovers around 100MB). I rarely need to use any functionality beyond find-tag, but there are times when I wish I could do completion out of the TAGS table.
Calling complete-tag causes Emacs to make a completion table automatically. The process takes quite a bit of time, but my problem isn't in the amount of time it takes, but rather the fact that right at the end (around 100% completion), I get a stack overflow (sorry about the unprintable chars):
Debugger entered--Lisp error: (error "Stack overflow in regexp matcher")
re-search-forward("^\\(\\([^]+[^-a-zA-Z0-9_+*$:]+\\)?\\([-a-zA-Z0-9_+*$?:]+\\)[^-a-zA-Z0-9_+*$?:]*\\)\\(\\([^\n]+\\)\\)?\\([0-9]+\\)?,\\([0-9]+\\)?\n" nil t)
etags-tags-completion-table()
byte-code(...)
tags-completion-table()
Has anyone else run into this? Know of a way to work around it?
EDIT: Stack output after turning on debug-on-error
EDIT: Removed stack, since I now know what the failing entries look like:
^L
c:\path\to\some\header.h,0
^L
c:\path\to\some\otherheader.h,0
My tags file contains quite a few entries in this format. Looking at the headers involved, it's clear that they couldn't be correctly parsed by etags. This is fine, but I'm surprised that tags-completion-table doesn't account for this format in its regex. For reference, here's what a real entry looks like:
^L
c:\path\to\some\validheader.h,115
class CSomeClass ^?12,345
bool SomeMethod(^?CSomeClass::SomeMethod^A67,890
The regexp in question is used to match a tag entry inside the TAGS file. I guess that the error can occur if the file is incorrectly formatted (e.g. using non-native line-endings), or if an entry simply is really, really large. (An entry is typically a line or two, which should not be a problem for the regexp matcher.)
One way of tracking down the problem is go to the TAGS buffer and see where the point (cursor) is, after the error has occurred. Once you know which function it is, and you could live without tags for it, you could simply avoid generating TAGS entries for it.
If the problem is due to too complex entry, I would suggest that you should send bug report to the Emacs team.
If you load the tags table (open the TAGS table with Emacs, then bury-buffer), try M-x dabbrev-expand (bound to M-/). If the present prefix is very common, you might end up running through many possible completions before reaching the desired one.
I don't use Windows, but on the Mac and Linux machines I use, I have not faced this issue.
This looks like a bug in Emacs, see:
https://groups.google.com/d/msg/gnu.emacs.help/Ew0sTxk0C-g/YsTPVEKTBAAJ
https://debbugs.gnu.org/db/20/20703.html
I have applied the suggested patch to etags-tags-completion-table (copied below in completeness for your convenience) and trapped an error case.
I'm triggering the error in an extremely long line of code (46,000 characters!). I presume somebody programmatically generated the line and pasted it into the source. A workaround could be to simply filter such lines at the ctag building or loading stage, just something that deletes "long" lines, whatever that may mean. Probably 500 characters is long enough!
I could also look at adding maximum sizes to my regexes in ctags, but that really isn't a general solution because many ctags patterns do not have such limits.
(defun etags-tags-completion-table () ; Doc string?
(let ((table (make-vector 511 0))
(progress-reporter
(make-progress-reporter
(format "Making tags completion table for %s..." buffer-file-name)
(point-min) (point-max))))
(save-excursion
(goto-char (point-min))
;; This monster regexp matches an etags tag line.
;; \1 is the string to match;
;; \2 is not interesting;
;; \3 is the guessed tag name; XXX guess should be better eg DEFUN
;; \4 is not interesting;
;; \5 is the explicitly-specified tag name.
;; \6 is the line to start searching at;
;; \7 is the char to start searching at.
(condition-case err
(while (re-search-forward
"^\\(\\([^\177]+[^-a-zA-Z0-9_+*$:\177]+\\)?\
\\([-a-zA-Z0-9_+*$?:]+\\)[^-a-zA-Z0-9_+*$?:\177]*\\)\177\
\\(\\([^\n\001]+\\)\001\\)?\\([0-9]+\\)?,\\([0-9]+\\)?\n"
nil t)
(intern (prog1 (if (match-beginning 5)
;; There is an explicit tag name.
(buffer-substring (match-beginning 5) (match-end 5))
;; No explicit tag name. Best guess.
(buffer-substring (match-beginning 3) (match-end 3)))
(progress-reporter-update progress-reporter (point)))
table))
(error
(message "error happened near %d" (point))
(error (error-message-string err)))))
table))