In emacs lisp, I expect the following to display a list of options in the completion buffer as I type. It prompts for information but doesn't display choices, either before or after I start typing. For example, I'd expect it to display 'First' after I'd typed 'F'.
(defun reader ()
(interactive)
(let ((choices '("First" "Second" "Third")))
(completing-read "Choose: " choices)))
Essentially I'm looking for something similar to the output described here. But what I get is this (there's nothing below the line, which is the edge of my window):
Can anyone explain where I'm going wrong with completing-read?
That's the way completing-read behaves. You're not doing anything wrong. It just doesn't support any kind of automatic, incremental completion.
If you want such automatic completion then you either need to write your own code to provide that or use a completion framework that provides it.
Icicles was the first to provide this incremental-completion behavior. Many other packages now provide the same or similar.
Related
I'm considering switching back from flycheck to flymake after the Emacs 26 rewrite. One thing that bothers me about flymake is how much room on the mode line it takes up. It has a string Flymake plus the results. It seems like a silly thing but this is 10% of the mode line on an 80-char frame, just for a name! I have lots of important info I'd like to see on my mode line so I try to remove things that aren't helpful to me--I know what minor modes etc. are enabled in my buffers, since I configured them! Personally I'd prefer to not see a name at all, just the results, or at most F or FM.
I could use diminish to get rid of the mode line info completely but of course I don't want that: I want to be able to see the state of my buffer.
I took a look at flymake.el and the flymake--mode-line-format defun and it doesn't seem like this string is configurable, or easy to change at all.
Anyone have any thoughts about this?
You'd need to redefine flymake--mode-line-format function. It should probably be more customizable, but it's not. Possibly the least intrusive way to do it is to define :filter-return advice on that function to transform the output.
(defun flymake--transform-mode-line-format (ret)
"Change the output of `flymake--mode-line-format'."
(setf (seq-elt (car ret) 1) " FM")
ret)
(advice-add #'flymake--mode-line-format
:filter-return #'flymake--transform-mode-line-format)
I would like to invoke M-x helm-swoop such that it does NOT return the symbol at point. I find that it always picks up undesired symbols, e.g. when I invoke M-x helm-swoop in org-mode, I get Swoop: \*, and I then have to delete the \* before I can enter my desired search term. How can I do this?
This has been bugging me as well, for exactly the same reason (swoop in an Org-mode buffer picking up heading characters), so this question motivated me to go and look.
Looking at the source, Helm-swoop calls helm-swoop-pre-input-function to populate the prompt, and by default this is set to a function that returns (thing-at-point 'symbol), which is what causes the problem in headings.
A quick test with the following in my init file seems to work:
(setq helm-swoop-pre-input-function
(lambda () nil))
This could certainly be improved by, for example, keeping the default behaviour in non-Org buffers but as I'm only really using swoop in Org buffers this is good enough for me.
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.
In CEDET, the minor mode semantic-idle-summary-mode displays information about the symbol under point in the echo area. I really like this mode, as it helps me remember, for instance, which arguments the function I'm calling needs.
The problem is, it's a little buggy about displaying in the echo area. Since it automatically activates whenever there's a symbol under point, it sometimes hides useful information that is being displayed in the echo area (after all, that's the area that emacs uses to tell you stuff).
Is there a way to display the summary information somewhere else? A tooltip would be ideal, but one of the ecb frames is acceptable as well.
The first thing that comes to mind is the variable tooltip-use-echo-area which controls where / how tooltips are displayed. When set to t, all tooltips are displayed in the echo area. What is its value on your system? Maybe it would be possible to force cedet to use actual (pop-up) tooltips by setting that variable to nil.
semantic-idle-summary-mode uses the function eldoc-message and a few other eldoc queries to determine when to display messages. This means it should be pretty good at not covering up useful information.
Since eldoc is the preferred mode for providing similar summary information in Emacs Lisp buffers, the best thing would be to configure eldoc, but I didn't see a way to do it since eldoc-message appears configured to always call message.
Anyway, what that means is you can use defadvice to override eldoc-message to use a tooltip, and you will have your solution.
The below snippit is a guess at how to use defadvice, but I didn't give it a try.
(defadvice eldoc-message (around bruce-mode activate)
"Make eldoc display messages as a tooltip."
(if (some condition that means I want to use a tooltip)
(bruce-eldoc-message (ad-get-arg 0))
ad-do-it))
(require 'tooltip)
(defun bruce-eldoc-message (&rest args)
"My version of displaying a message for eldoc."
(if (null (cdr args))
;; One argument
(tooltip-show (car args))
;; Else, use format
(tooltip-show (apply 'format args)))
)
I had a similar need as you,
and I addressed it with this extension.
As you can see on this screenshot,
it shows the function arguments at the point of its invocation, without altering the echo area.
Some neat features are:
Shows you all overloaded functions, including constructors where appropriate.
Highlights in bold the current argument.
Jump to definition functionality for the current function variant.
Vim completes words and lines with CTRL-X P and CTRL-L. There's a Emacs plugin called Company mode but this plugin interfere and cause conflicts with lots of things within Emacs (with global linum and yasnippets). I know that I can complete words with CTRL-/ in Emacs. But it is possible to take previously written lines to complete code?
Maybe you're looking for hippie-expand? From that web page (as of this writing, anyway):
HippieExpand looks at the word before
point and tries to expand it in
various ways including expanding from
a fixed list (like expand-abbrev),
expanding from matching text found in
a buffer (like dabbrev-expand) or
expanding in ways defined by your own
functions. Which of these it tries and
in what order is controlled by a
configurable list of functions.
For a comprehensive list of completion options visit the emacs wiki page on completion.
There are a gazillion ways to do completion in Emacs. Some are mode specific, some inline, some configurable and what not. Here is a list of modes that might help you.
Use numberic argument to complete by line, say M-5 M-/ will complete by line, while M-/ alone still complete the normal way.
hippe-expend function has a very useful feature which is :
With a positive numeric argument, jumps directly to the ARG next function in this list. With a negative argument or just C-u, undoes the expansion.
Customize the expansion functions in hippie-expand-try-functions-list and put the function try-expand-line as 5th list element, then you could use M-5 M-/ to complete by line.
This tip is very handy and useful and I highly recommend it.
Also worth noting: if your window manager does not steal Alt-tab, emacs will auto-complete with Alt-tab (I set up my window manager to user the "windows key" instead of alt for this very reason).
If you are using evil, this is the most vim-like solution I use:
(defun my-expand-lines ()
(interactive)
(let ((hippie-expand-try-functions-list
'(try-expand-line-all-buffers)))
(call-interactively 'hippie-expand)))
(define-key evil-insert-state-map (kbd "C-x C-l") 'my-expand-lines)
This way you can use our old friend C-x C-l in insert mode for whole line all buffers completion.
Thanks #ymln for the suggestion of using try-expand-line-all-buffers.