You can get all the buffer tags by calling org-get-buffer-tags. You can then combine that with completing-read whose doc string reads as follows:
completing-read is a built-in function in ‘C source code’.
(completing-read PROMPT COLLECTION &optional PREDICATE REQUIRE-MATCH
INITIAL-INPUT HIST DEF INHERIT-INPUT-METHOD)
Read a string ...
I've asked helm's author years ago about this particular issue. Your described behaviour happens whenever a completing read does not specify that it requires an exact candidate match and is therefore not considered a helm bug. That's why he recommends fixing these functions instead of providing an option to allow for this behaviour.
Finally, I found the solution to my problem. magit-status ultimately calls read-file-name. The read-file-name function uses read-file-name-function variable to find the function that it can call for reading a file path. helm-mode sets it to helm--generic-read.. and it doesn't respect the value of helm-completing-read-handlers for me somehow.
The only way I ...
Magit only used magit-completing-read when reading "magit-specific" things. When reading things that other packages also need to read, then it uses the specialized functions provided by Emacs instead. For files and directories the work is ultimately done by read-file-name-default.
I like to use ido for completing file paths and helm for all other things.
I have code which uses completing-read to do this
Ivy's analogue to completing-read is the function ivy-read, whose operation is described in its docstring and the Ivy User Manual under (info "(ivy) API").
Given a list of (point-number . title-text), how can ivy be used to show this in a list in ivy?
Here's an example of how to achieve this:
Are you sure you executed the code? I just tried:
(push '(org-tags-view . completing-read-default)
and it worked as expected.
Responding to the comment:
Indeed when calling it from org-agenda it does not work. As you supposed, this is because this-command is changed to org-agenda. As you probably don't want affect ...
What @JohnKitchin shows is a typical way to return something different from (but associated with) the candidate string that is chosen by the user.
In your case, it sounds like you might want the completion candidates (possible choices) to show more information than what is returned after choosing. E.g., you display a bunch of text describing something, and ...
Here is a complete solution based on this discussion:
'("procedural" "functional" "high-level" "low-level" "statically-scoped" "dynamically-scoped"))
;; This function is based on http://sixty-north.com/blog/writing-the-simplest-emacs-company-mode-backend
(defun company-sample-backend (...
EDIT: This issue was fixed in helm on June 6th, 2017.
See commit 09b6fcd.
After hours spent on searching it seems to me that helm forces matching input with completing-read, so I wrote my own command to quit helm sessions without matching. It allows exiting helm sessions with whatever is in the minibuffer via M-# and works by advising completing-read.
The function choices is a variation of org-capture and the variable choices-template is a variation of org-capture-templates.
USAGE: M-x choices
'(("1" "Group 1")
("1a" "Sub-Function #1a" butterfly)
("1b" "Sub-Function #1b" help-for-help)
("2" "Function #2" (lambda () "test 2"))
("3" "Function ...
You can use any elisp functions to generate the arguments for an interactive call. The code you use should return a list that matches the function arguments:
(defun my-function (beg end style)
(let ((string (completing-read "Style: " styles-list)))
(list (region-beginning) (region-end) string)))
<function body> )
See the the ...
Even with vanilla Emacs you can do this, just by using completing-read and looking up the car in I1. If the cars are unique then assoc is all you need.
(cadr (assoc (completing-read "Choose: " I1) I1))