I'm missing one piece in Emacs' already superbly unique completion system (completion-styles and completion-styles-alist), namely word and sub-word-reordering a la google search.
As an example, file-write should complete to write-file if no other style finds a completion. Word-separating characters could for-example be matched using the regular expression "\\s_".
Even cooler and more general would be if applied the Damerau-Levenshtein Edit Distance (D) to words instead of letters. The completion candidates could the be sorted on increasing distance D, meaning closest match first.
My plan is quite clear on how to implement this and an implementation of D already exists. I ask anyway so I don't reinvent the wheel yet another time:
Has anybody implemented such a completion style already?
Per --
You cannot do what you want with vanilla Emacs (well, you can use Lisp to code whatever you need -- but you cannot do what you want not out of the box).
Icicles gives you exactly what you want. It's called "progressive completion", and the idea is similar to using a pipeline of grep commands.
Nutshell view of progressive completion (and chipping away the non-elephant)
Progressive completion
You can also use LevenShtein matching for completion with Icicles, and combine that with progressive completion to match the words in any order.
Related
I'm making a custom .tmLanguage file to highlight the syntax I'm using correctly and generally make coding with it easier. I'm almost done, and I got the autocompletion working using a .sublime-completions file.
There's just one minor flaw I'd like to change. I have a pretty long list of functions, and almost all of them contain an abbreviation of the word 'parameter', PAR. When I start typing that word, the following are all in the list of completions:
PAR command
DEFPAR command
JDATA command (because the description contains PAR)
SPAA command (because there's a P in the command and an A and an R in the description)
What I want is only for the commands that begin with PAR to show up, so from the list above, only the first item.
So, like this:
In other words, I want the completions to show up based on the literal string I'm typing, and only from the trigger part of my completions file, before the \t only.
That completions file looks like this:
Highlighted in orange is what I want my completions list to be based on.
I hope this is understandable. Any help is greatly appreciated.
This is not possible. By design Sublime's autocomplete feature uses fuzzy matching, so if there are a number of options that all contain the same pattern, but you don't quite remember which one you want, you can type the pattern and have all of the options available. The more you type, the smaller the list of possible options becomes. This is a good thing®, otherwise you'd have to remember the exact command you're looking for, which kind of defeats the purpose of autocomplete and code hinting.
I like rgrep a lot. The interface for finding and jumping between matches is great.
But I also want the ability to do interactive and non-interactive replacements
from the *grep* results window.
I mean the information for replacing is already laid out perfectly:
the thing to be replaced is nicely highlighted
some context is given (although it wouldn't hurt to bind
+ to increase the number of context lines)
the files and positions are here as well
But there's no interface for replacement (I checked with f1 m).
Did I miss it or it's not available? Or is it available is some package?
I think you are looking for wgrep. It uses wdired approach, and it is available in the usual package repositories.
I was looking for documentation on tr program. As you would imagine the combination of characters t and r happens fairly often in English language... Although I was sure about the name, I wasn't sure about the name of the section it belongs to, so I had to display all nodes and try searching for something like tr or tr( and so on.
Isn't there a better way to do it?
Hmm... I can only guess that the following isn't happening for you; however nodes for individual programs really ought to be listed in the top-level directory, and hence show up when you type M-x info RETd, from where you can simply use m tr RET.
However if you're searching for something which isn't in any of the directory files, the only convenient thing I know of is M-x info-apropos (which searches all of the indexes rather than the node titles).
And of course within a given manual you can use I to search its index, which is much faster than searching all of them.
Edit: This is tangential, but an excellent improvement in the upcoming Emacs 24.4 (currently undocumented in the NEWS file) is completion for Info node names in non-current manuals.
e.g. C-hig (elisp) TAB now provides completions for all the nodes in the elisp manual, even if you are not currently viewing that manual.
This is an extremely welcome change!
Icicles can help here. All Info commands that use completion let you take advantage of Icicles completion features. This includes apropos completion -- regexp matching, which means that you essentially get on-the-fly info-apropos behavior, among other things. And it includes progressive completion, which means you can add additional patterns to progressively narrow your search.
When completing you can sort the candidates in various ways, including sorting Info nodes in book order for g.
g (icicle-Info-goto-node) lets you search both node names and node contents at the same time: Your minibuffer input can contain a second search pattern that is matched against the node contents. The completion candidates are those whose names match the node-name pattern you type (if any) and the node-content pattern you type (if any). Each pattern is a regexp (which includes substring matching as a simple case).
See Icicles Info Enhancements for more information.
I am writing a function that uses the minibuffer and requires a somewhat different style of completion that might require deleting some characters. For example:
ar<tab> -> artist:
artist:ba<tab> -> artist:'Johann Sebastian Bach'
artist:'Johann Sebastian Bach'<tab> -> artist:'Bela Bartók'
artist:'Bela Bartók' and album:<tab>
etc...
I've already written the completion function, that generates a list of possible strings for the current input, yet I cannot use it with completing-read and completion-table-dynamic, because only the alternatives that do not require deletion are displayed. In this case, only the first step, from ar to artist.
To do the job, I'm considering using the lower-level (read-from-minibuffer) with a custom keymap to do the completion and display the alternatives. Is there a simpler solution? If not, which functions are there to handle displayed and cycling through the Completions buffer?
Thanks!
EDIT: In the end, I rolled my own. Here is the code, if anybody's interested.
Yes, Icicles should give you what you want, IIUC.
I'm not sure how you're handling things like 'artist' and 'album', but there are a few ways Icicles could help.
You can match parts of a completion candidate in any order. So if 'foo' and 'bar' are parts of the same candidate, then you can match any candidates that have both, in either order. This is "progressive completion": you can keep adding patterns to narrow the choices. Patterns are ANDed. You can also subtract candidates that match a pattern.
You can have candidates that are "multi-completions". These are composed of parts, separated by a configurable string. You can match against any or all parts. So, for example, a candidate might be an album name plus artist names.
If you also use Bookmark+ then you can tag files, a la delicious.com tagging. You need not visit files to tag them. Tags are generally strings (including newlines if you want), but they can also have associated Lisp values. Here, you might have a file for each album and tag albums with descriptions and various artists. Then you can complete to find a given album file by matching parts of its name and/or artists.
For all Icicles completion, you can use progressive completion and complementing (#1). For each part of a progression you can use substring or regexp matching (or even fuzzy matching of various sorts).
Some links that might help:
http://www.emacswiki.org/emacs/Icicles_-_Progressive_Completion
http://www.emacswiki.org/emacs/Icicles_-_Multi-Completions
http://www.emacswiki.org/emacs/Icicles_-_Bookmark_Enhancements -- see, for example, command `icicle-find-file-tagged'
You may benefit from the Icicles library. It contains many features for enhancing minibuffer completion.
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.