for those who don't know, imenu is a thing in emacs that lets a mode insert one or more menu items into the menu bar. The most common usage is to make a "table of contents" accessible from a drop-down menu, so the user can quickly jump to declarations of functions or classes or sections in a document, etc.
imenu has a couple different ways of working - in the first and more commonly used way, a major mode provides regexps to imenu, and imenu uses those regexps to perform the scan of the buffer and build the index. A major mode sets this up by putting the list of regexps into imenu-generic-expression. The second way is for the major mode to perform its own scan. It can do this by instead setting the variable imenu-create-index-function to the name of a function defined by themode, which returns a list containing the table of contents.
I'm doing the latter - imenu-create-index-function - but sometimes the fn takes a looong time to run, say 3 or 4 seconds or more, which freezes the UI. If I make the operation asynchronous, that would solve that problem.
I know about asynch processes. The scan logic is implemented in elisp. Is it possible to run elisp in an asynch process? If so, how?
Or, is there a way to run regular elisp asynchronously in emacs, without resorting to an asynch process?
I think the way font-lock does it is, it fontifies on idle. It keeps state and fontifies a little at a time, always remembering where it left off, what else needs to be fontified, what has changed since the last fontification run, etc. Is my understanding correct? Maybe I could use this incremental approach .
Recommendations?
To run elisp asynchronously you can use either run-with-idle-timer or run-with-timer. I imagine you'll want the idle version. Check the documentation links for more details.
Note: If the code takes 3 or 4 seconds to run, it'll still take that long (and freeze your Emacs while it runs), so if you can break the work up into small enough chunks that it only takes .5 seconds or so at a time, that might work well.
One package that I use all the time, pabbrev.el, uses idle timers really well - I never notice it running. That might be a good package to examine to see how it breaks up the work (it is scanning all open buffers and building up a word frequency list).
The answers posted by TreyJackson and jeremiahd were valid back in year 2011. Now, in 2018, here is a link to the emacs documentation for asynchronous processes.
You can run elisp in an asynch process by spawning emacs in batch mode as the process, see http://www.emacswiki.org/emacs/BatchMode . Other than that, there's basically nothing as far as I know.
It looks like http://nschum.de/src/emacs/async-eval/ basically wraps the boilerplate necessary to do this. No clue if it's actively maintained or anything though.
Related
as the title said, I am learning common lisp right now and using portacle, following Practical Common Lisp by Peter Seibel.
I found it quite annoying that the Slime-repl-sbcl buffer keep the writing at the end of the screen (using C-l or C-v doesn't help since once I try to execute an expression it will roll back to the end of the screen)
Is there anywhere to improve this? (should I just write on a text file and compile it? the only similar subject I found was about Cider repl and couldn't understand it, since I am still new to lisp)
Thank you for your time
I would like this fixed too. No solution yet. In slime-repl.el, I found:
scroll-conservatively (variable):
A value of zero means always recenter point if it moves off screen.
my test wasn't conclusive.
slime-display-output-buffer (function), which calls slime-repl-show-maximum-output, which role is to
Put the end of the buffer at the bottom of the window.
I rewrote slime-display-output-buffer without this call, but that wasn't conclusive either.
Maybe I tested badly.
(I'm making this answer a wiki)
You would indeed typically write in a source file, and compile each expression separately. Use the REPL only to test functions or do simple computations. To compile functions (or really, any toplevel expression), use C-c C-c - bound to slime-compile-defun by default - when the point (= your cursor) is inside the function's code. The REPL will then "know" of it, so you can test it there, but as it is now written in file, you can also modify it without having to copy/paste anything ! Just make sure to recompile functions that you modify !
If you want to compile/load entire files at once, look at the other compilation commands, e.g. slime-compile-and-load-file (see the SLIME manual, and its Compilation section)
For your problem: there is Emacs variable, named comint-scroll-to-bottom-on-input (or something along those lines, can't remember exactly ...) which enables the behaviour you are seeing, so that you don't have to scroll back to enter new expressions. It is possible that SLIME has another variable which configuring this behaviour for its REPL; in that case, it would probably be named almost the same, and you can set it to nil to disable it.
Finally, don't hesitate to look at the other tools provided by SLIME ! For example, it comes with an "inspector" (see the relevant section), that you can use instead of evaluating expressions such as *db* in the REPL. In that simple case, it makes no real difference, but if you start having - say - hash-tables or different structures/classes, it becomes an incredible tool for interactive development, to examine the internal of almost everything, redefine things directly from within the inspector without needing complex accessors, and so on.
I am trying to execute when the active buffer has changed by either
Changing the buffer in the current window (e.g. C-x <left>).
Switching to another window (C-x o).
Switching to another frame.
Are their hooks suitable for detecting this?
What I figured out so far
Looking through the Standard Hooks I found the following options, none of which quite do what I want:
buffer-list-update-hook is called for both (1) and (2). It is however unsuitable, because it is run before the buffer is changed, while I want to know what the current-buffer after the change is.
window-configuration-change-hook can be used to detect a change of the buffer displayed in the current window, and it is run after the change, as needed. It is however not run for M-x other-window.
mouse-leave-buffer-hook seems viable for detecting mouse-based window switching, but it gets called a bit often (for me four times upon switching windows with the mouse, three times before and once after switching), which requires additional logical to prevent multiple execution.
post-command-hook would be viable but a bit heavy handed, risking significant slow-down of the editor by even minor bugs.
Since my action would need to use with-selected-window, which triggers these hooks, care has to be taken to avoid endless loops where the hook triggers itself.
Judging from the comments, the answer to this question is “No, there is no such hook.”
Additionally, some of the hooks mentioned in my question, are also triggered by changes, which are not user-visible, such as temporary changes due to with-current-buffer and with-selected-window.
However, using post-command-hook has proven to be a non-issue for performance, since the required state-check is cheap.
Alternative
Probably obvious, but stated for completeness.
Store state information in a global variable, in a frame-parameter, in a window-parameter or in a buffer-local variable, whichever is most applicable to the use-case. In my use-case, this necessary unique state is was defined by current-buffer, current-window, and in one case line-beginning-position.*
In post-command-hook, check if the state has changed, possibly skipping
even that, if this-command is self-insert-command.
If it has, perform the intended action and update the stored state.
* line-number-at-pos is unsuitable, because it counts lines by iterating over the buffer from point-min to point, making it generally cheap, but not cheap enough to be executed after every typed character.
Emacs27.1 introduce a new variable called `window-buffer-change-functions'
I'm very excited of emacs auto-completion mode. But my codebase is big, and sometimes, when i type, and it tries to ssuggest a completion, it searchs through all possible words, and hangs. It is very annoying.
Is there a way to run the search in background in parallel process, so emacs would still response to user actions. And only if the point holds on the place when the query is finished, suggest auto completion?
Like, the keyboard input is a primary process, and can never be delayed, and autocompletion works as a residual on machine resources.
emacs-jedi exactly does that for Python auto-completion. You can send a request to the background process using the init property and then store the result somewhere. In the candidate property, you can process the stored result to pass it to auto-complete. Here is the ac-source definition. Please look at the source for details.
(ac-define-source jedi-direct
'((candidates . jedi:ac-direct-matches)
(prefix . jedi:ac-direct-prefix)
(init . jedi:complete-request)
(requires . -1)))
emacs-ipython-notebook also uses similar technique but I guess emacs-jedi is easier to read.
I do really like key-chord.el but I'd need it to only trigger when I start pressing keystrokes after a short delay during which I didn't do anything elapsed. I'd like to know if it's easy to modify key-chord.el to do that.
Why I want that is simple and I'll try to explain it as easily as I can:
I do want keychords to be assigned to keys that are on my "strong" fingers (no pinky) and that are on my home row (I do touch-type). Hence I'm potentially creating quite a few keychords which may clash with common words / code when I'm typing.
I realized that everytime there's a clash (i.e. keychords kicking in while I didn't want to) it's because I'm in the process of frenziedly modifying the buffer.
Here's an example...
I'm a fast typist so if I'm entering, say, "held", there is never going to be a long delay between when I add the 'e' of "held" and when I then type the 'l'. So in this case it should be "obvious" that I do not want key-chord to kick in when I type 'ld'. However if there's a pause and if 'ld' is an assigned key-chord and then I hit 'ld', then it is very unlikely that I'm writing code / text that would be starting with 'ld'. So in this later case (and because I have assigned 'ld' to a key-chord), I do want it to kick in.
Now don't get me wrong: I'm not sayin this would eliminate every single possible clash in every single case. All I'm saying is that, in my case, this would probably eliminate 99.9% of the (already rare) clashes. The "time lost" should one clash still occur after this change to key-chord would be negligible compared to the amount of time key-chord is making me gain.
The code to key-chord.el is very small so maybe such an addition wouldn't be too hard?
Does anyone have an idea as to how if it would be easy to modify key-chord.el to provide such a feature? (I hope I explained correctly what I want to do)
Here's the code to key-chord.el and half of it is comments:
http://emacswiki.org/emacs/key-chord.el
The Idle Timer mechanism should be able to facilitate this.
C-hig (elisp) Idle Timers RET
I'll leave it to you (or someone else) to figure out the details. Offhand thoughts are:
enable the Key Chord functionality via an idle timer
use post-command-hook to disable it again
That might be all that is needed?
I see two timings at play here
time before the chord (between the letter before the chord and the chord. If short enough, no chord)
time after the chord (if new letter quickly typed, no chord)
The second type of timing is probably more natural, and easy to get used to. If one type the chord, a short timeout before it executes can be accepted. (This is not what you asked for and would not solve the "ld" example. But it could potentially solve the problem with letter combinations that may appear in the beginning of words.)
The first type of timing is probably harder to get used to. When one have completed typing a word and the next thing is to type a chord, I suspect it is not a natural instinct to make a short pause. If one uses the chord often, one is likely to type it quickly, and get annoyed if it is not recognized (and the two chars are inserted into the text instead). What I want to say is, I am not sure a timing before the chord will solve the problem to a satisfactory degree.
As for the implementation of such a timing. The way the state machine in the key-chord-input-method function is currently structured, it would grow exponentially with the number of timers to consider (if I recall correctly). I.e. there would be at least about a dozen new lines of code.
To experiment with the functionality, try phils suggestion in the other answer: a post command that disables chords, and an idle timer that, after a fraction of a second, enables them again. A quick and dirty way to disable and enable chords, without actually changing minor mode, would be to set the input-method-function variable.
Code for test purpose only. It assumes, but does not check, that key-chord-mode version 0.5 is loaded and enabled:
;; Helper functions to be used in timers and hooks
(defun my-enable-chords () (setq input-method-function 'key-chord-input-method))
(defun my-disable-chords () (setq input-method-function nil))
;; Start test
(add-hook 'post-command-hook 'my-disable-chords)
(setq my-timer (run-with-idle-timer 0.3 'repeat 'my-enable-chords))
;; Finish test
(remove-hook 'post-command-hook 'my-disable-chords)
(cancel-timer my-timer)
I'm wondering if anyone could weigh in on pros and cons of different spelling modes for Emacs. Emacswiki-CategorySpelling mentions three modes for spell checking:
Flyspell mode (default one)
Speck mode (seems to be designed to be faster than flyspell)
Wcheck mode. (designed to be general purpose)
I'm also interested in which of these modes provide a way for the spell checker to skip part of a buffer depending on its syntax (for instance, in order to skip math mode parts in a LaTeX document, which are highlighted as brown in AUCTEX mode). Flyspell doesn't seem to do this
You can do partial flyspell-mode in a number of different ways. One is to use a multi-mode approach, where you define multiple modes in a single buffer, one of which is a mode to edit comments (for example), in which flyspell-mode is enabled. I used to do this for some programming language, but I can't find the config for it any more, so I guess I don't use that language anymore. Anyhow, see mmm-mode for more info there.
A second alternative is to use `flyspell-prog-mode' (which see) which sets up flyspell mode for certain parts of the buffer, defined in this case by the font face (there are specific faces for strings and comments for most programming language major modes). It uses a predicate call-back function, which can be defined however you want it; I maintain TNT, which is an AIM-mode for Emacs, and we use it like so:
(defun tnt-im-mode-flyspell-verify ()
"This function is used for `flyspell-generic-check-word-p' in TNT."
(not (get-text-property (point) 'read-only)))
(put 'tnt-im-mode 'flyspell-mode-predicate 'tnt-im-mode-flyspell-verify)
(put 'tnt-chat-mode 'flyspell-mode-predicate 'tnt-im-mode-flyspell-verify)
Regarding flyspell vs. speck vs. wcheck -- I've only used flyspell mode. speck seems to be very oriented on what is viewable, which can be fine, but generally I want the whole of whatever document I'm working on to be spell-checked, so I wouldn't want that. wcheck seems to be a generic interface to an external program; I'd guess you're going to have to build up its use yourself. flyspell can be used two different ways: as-you-type, which is how I usually use it, and "batch mode", where a whole region or buffer is checked at once. The former is incredibly fast, and I've never found a reason to look for a better tool. The latter can be a tad slow, especially when there are a lot of misspelled words and the document is large, but I really can't remember waiting more than 15 seconds for it to complete. While watching the screen for 15 seconds and doing nothing can seem like a long time, it's not, really. YMMV, of course.
Bottom line: I'd stick with flyspell-mode, assuming it meets your needs, of course.