Is there a way to hook onto command A, so that B is always called after A executes?
I think the most straight-forward way to accomplish this is through the use of advice.
You would do something along the lines of:
(defadvice command-A (after b-after-a activate)
"Call command-B after command-A"
(command-B))
This approach has the advantage that it works even when command-A is redefined. It does not, however, work on macros or on primitive functions called from the C code. But, in practice the thought of advising those functions is rare.
That said, it might be worth looking into just defining a new command (command-C) which first calls command-A and then command-B.
You could also play around with symbol function indirection and writing a new command.
It kind of depends on what you're trying to solve.
You can advice a function using defadvice:
;; This is the original function command-A
(defun command-A () (do-it))
;; This call will cause (do-sometihng-after-command-A) to be called
;; every-time (command-A) is called.
(defadvice command-A (after after-command-A)
(do-something-after-command-A))
;; Enable the advice defined above
(ad-activate 'command-A)
See the info node (elisp)Advising Functions for more information and examples.
Related
I have not been able to get the minibuffer-exit-hook to play nice with read-string. As far as I can tell, I should no longer be in the minibuffer after finishing up with read-string. However, the condition (minibufferp) says I'm still in the minibuffer even though read-string finished. read-string is written in C, so I can't add the hook there (i.e., at the tail end of the read-string function).
"Documentation [minibuffer-exit-hook]: Normal hook run just after exit from minibuffer.
[After thinking a little more about this, I'm pretty sure it's a bug -- so I filed a bug report: bug#16524. As I learn more, I'll update this thread.
(defun test ()
(interactive)
(read-string "Prompt: " "testing"))
(add-hook 'minibuffer-exit-hook (lambda ()
(cond
((minibufferp)
(message "Focus is still in the minibuffer: %s" (buffer-name)))
(t (message "Contragulations -- focus is now in: %s." (buffer-name))))))
The doc string is not exact; that's all. The hook is run when inputting text in the minibuffer is done (no longer possible). The buffer that is current when it is run is still the minibuffer. (And that's the way it should be, FWIW.)
Note that the Elisp manual puts it slightly differently (but again, not very precisely):
This is a normal hook that is run whenever the minibuffer is
entered.
("Whenever", meaning about the same time as, not necessarily after.)
If you want to do something after every use of read-string in your code, then define a function that does the following: first (read-string...), then whatever you want done next. And use that function.
If you need to affect also other invocations of read-string, besides those you write in your code, then advise function read-string to perform whatever action after the vanilla code finishes.
For example:
(defadvice read-string (after fooness activate)
(message "buffer: %S" (current-buffer)))
[Note: Yes, you can advise primitives (functions written in C). You used to even be able to advise special forms, but they regressively took away that feature.]
Running a hook after you truly exited the minibuffer is rather pointless: you could be in any kind of buffer (since minibuffer use can be triggered from anywhere) and you hence know very little about the current context (unless you use a buffer-local exit-hook, I guess).
If you want to run a hook when the selected window changes, then your best option is probably to use a post-command-hook that stores the current selected-window in an auxiliary variable and uses it to compare to the previous selected-window.
What problem can happen if the goto-line function is used in a non-interactive elisp program? Its docstring gives a warning saying that:
This function is usually the wrong thing to use in a Lisp program.
What you probably want instead is something like:
(goto-char (point-min)) (forward-line (1- N))
Moreover, when I try to byte-compile-file my init file including goto-line, I get a unpleasant warning like this once again:
.emacs:170:19:Warning: `goto-line' used from Lisp code
That command is designed for interactive use only
Is using goto-line in a non-interactive program really so dangerous? Relatedly, why is the suggested forward-line solution preferable?
Firstly, this prevents Elisp programmers from fall into bad habits -- writing
inefficient code in a line-number centric way. i.e. instead of using
(forward-line 1) calculating the current line number, incrementing, and using
goto-line.
From this mailing list article:
In a nutshell, the reason why goto-line should not be a frequently
used command is that normally there's no reason to want to get to line
number N unless you have a program that told you there's something
interesting on that line.
Secondly, goto-line manipulates the user's environment in addition to moving
the point (i.e. push-mark). For non-interactive use, this may not be what
you want. On the other hand if having considered all this, you believe
goto-line is exactly what you need, then just call it like this:
(defun foo ()
(interactive)
(with-no-warnings
(goto-line N)))
And you won't get any compiler warnings.
in addition to what was said:
"goto-line" finally recurs onto "(forward-line (1- line)", which in effect does the work. All other of the 43 lines of "goto-line" command body deal with interactive use. For example considering a possibly universal argument.
When writing a program resp. when running it, your computer is in another state than following an interactive call. Thus you should address this state by using "forward-line" straight on.
So at work, I've got to work from two different repositories. The files map to essentially the same place, but one path has 'data' in it.
It's relatively trivial to write a defun that determines if the file is in the data directory or not, and so which repository I actually want to check out from. But I can't figure out a way to call my function before any p4 commands without explicitly rebinding the keys to do it, and even that is sort of a big hack. I'd really just like it to run every time I try to check out or revert a file and set the p4port as I want it to.
All the hooks in the p4 system seem to be called when I don't want them to be. I tried calling my defun on the p4-mode-hook, but that hook only runs when the mode is set, and files that aren't in the repository are rejected before I ever get my defun to do anything. :/
There are a couple of approaches that you could use. First, you could consider adding the desired functions to pre-command-hook, with a predicate to check whether the current buffer is operating in p4-mode, i.e.:
(add-hook
'pre-command-hook
(lambda ()
(when (eq major-mode 'p4-mode)
;;; specify whatever functions you desire
)))
This will indiscriminately execute the functions that you include in the body of the above lambda before any command in a p4-mode buffer. If that's overkill and you need to be more selective about when to execute said functions, you should probably individually advise each of the p4 commands that should first execute your functions before running, e.g.:
(defadvice
name-of-p4-function
(before name-of-p4-function-advice activate)
;;; functions to be executed
)
(ad-activate 'name-of-p4-function)
See the Advising functions section of the Emacs manual for additional details.
There is one thing that I don't like on table function in Org-mode for emacs. I would like to see all the functions that get executed by function that I run as Emacs command.
What is the best way to do that? Any tips how to get started with debuging elisp code, especially single command of interest?
C-hf function name to find the source code for the function.
C-uC-M-x to instrument the function for Edebug.
Whenever the function is called, Emacs will drop into Edebug which makes it easy to execute the function step by step, inspect variables, and do other typical debugging tasks. See (info "(Elisp)Edebug") for more information.
I prefer the traditional Emacs debugger to edebug. To use it:
M-x debug-on-entry the-function RET
Then, whenever the-function is invoked, the debugger is entered. Use d to step through the evaluation, and c if you want to skip through a step (not dive into its details.
It helps to view the definition of the-function in another window/frame while you step through it.
You can cancel debug-on-entry using M-x cancel-debug-on-entry.
C-h f to go to function help mode, then type the name of the function. If it is an elisp function, you can then view the source and look for yourself what functions it calls.
If you want a programmatic way to see the source of a function (akin to Clojure's source macro) you can use the symbol-function subroutine.
For instance, there is a defun do-math in my .emacs file. To see its source, I can do the following
(symbol-function 'do-math)
and it gives me
ELISP> (symbol-function 'do-math)
(lambda
(expression)
(interactive "sexpression:")
(insert
(number-to-string
(eval
(read expression)))))
See also :
https://www.gnu.org/software/emacs/manual/html_node/elisp/Function-Indirection.html
See also also :
http://ergoemacs.org/emacs/elisp_symbol.html
(define (cube guess x)
(if (good-enough? guess x)
guess
(improve guess x)))
I'm using emacs+Racket, but when I write in Racket,it doesn't auto-complete.
I also can't write the Anti-brackets in the same line，like this
(define (cube guess x) ). I want to use the 'return' key to make the anti-brackets next line, however the scheme interpreter will compute the expression,then it will be wrong.
then if we write the code in the scheme-mode buffer,it may be some bother, we have to
select the region,then compute in another buffer
Anyone tell me some better ways? sorry for my poor English!
It looks to me like you're using an interactive interpreter, and when you hit the "return" key in the middle of a line, it sends the expression to be evaluated rather than allowing you to edit it further. Is this correct? If so, I would encourage you to take a look at Neil Van Dyke's "Quack" package, which (IIRC) is designed to allow you to edit Racket code using emacs.
If you're not married to emacs, then of course I would also suggest trying to use DrRacket.
It sounds like you're using the scheme interpreter from within Emacs. This is a good start for writing small functions, but you really want to use a REPL (Read-Eval-Print Loop) workflow. Thankfully, Emacs has a ready-made scheme REPL built-in, and has been mentioned elsewhere, there are additional modes (like Quack) that enhance the experience.
In the REPL model, you can freely type expressions in the interpreter if you want to try them out, but most of your coding should take place in the file you're writing. From within that buffer, if you have a scheme interpreter running (M-x run-scheme), then you can send sexps to the interpreter for evaluation without copying manually with C-c C-e. You can use C-M-x to do the same thing.
You can compile the entire file with C-c C-k, and if you have several expression you want to send together, grab them in a region and use C-c C-r to send the region to the interpreter.
There are several other commands that make transferring your code to interpreter easy; you can read more about them in your REPL session by pressing C-h m to describe the keybindings for your current mode.
What does this code even do ? Are you missing the "if" ? That could be part of the reason the interpreter isn't working.?
(if (good-enough? guess x) guess (improve guess x))
Sorry if I just don't understand what you are trying to achieve.