I want auto-complete menu to show automatically while typing but never expand except if explicitly requested (return or M-tab or such). I type very fast and I only want to potentially expand if I don't know what I want or there's a very long completion. I cannot seem to be able to prevent expansion when a single option is available in the menu and this causes big problems when there are already characters on the line right of the cursor.
Auto-complete menu shows fine. With each character the options get more narrow. Problem shows when a single option is left - the menu disappears and the overlay expansion shows (obscuring existing characters to the right of the cursor). When I type one more character the expansion takes effect but it is broken up with the remaining characters of the expansion as a suffix to the existing line. If the one more character I typed was NOT the one in the suggested expansion things still break but without the rest of the suggestion.
This is very inconvenient as I usually type very fast and trigger broken completions. I would like to have the menu always show automatically but expansions NEVER take effect except explicitly (I slow down my typing when I'm unsure what I want to type.
I tried all the options I found in the documentation but I just cannot prevent expansions from taking effect. I want to completely disable expansions (except for explicit expansion).
Related
I want to map two dot/period key presses to Tab key in AutoHotkey script. I tried to map similarly as its shown for remapping semicolon key - on AutoHotkey forums, but it doesn't work. I tried following:
1. `..`::Tab
2. ..::Tab
AutoHotkey gives an error
.
I tried searching on AutoHotkey Remap docs, but couldn't figure it out. The period key is the one with the greater than mark and not the number keypad period key. See this: Dot/period key
Addition info/context in response to reply by user 0x464e:
Basically, I am trying to expand Emmet style abbreviations in devtools style sub-panel since the chrome devtools team wont implement it.
I am not a fast typist, so it's a pain to type complete property names. For example, if I want to type margin-top, (see the image), Chrome autocomplete brings up margin, margin-block margin-block-end etc.
Now, for margin-top, you need to at least type margin-t to get the autocomplete to show that property.
This is the case for many very common CSS properties like margins, paddings, etc., so autocomplete isn't great.
On the other hand, if I just type mt and have Autohotkey expand to margin-top, it's much much faster, saves me much time and keeps me sane.
Basically, I have setup some hotstring in .ahk script and they work too.
However, if I press mt followed by a Tab key press, Chrome's autocomplete takes over and hotstring fails, (try once to see the problem). Instead, currently I press spacebar, or . (period) to trigger the hotstring. It works, but the problem is it leaves a space or a dot with the expanded text. [see this].
So, that's the actual reason I wanted a double period key trigger to replace Tab.
It would be great if the hotstring trigger would work with a double period key, but doesn't leave the trigger character itself and then have send Tab so as to jump to the value input of the just expanded property.
You're not really looking for a traditional remap, which is why you didn't find it from the documentation.
Remapping is just simply remapping one key to another, but you're not trying to do that. You're trying to make some action do another action.
Anyway, what you're asking is doable, but there's loads of different ways it can be achieved with difficulties varying from simple to extremely advanced & complicated.
You'll need to specify things more clearly before this can be answered properly.
Biggest questions that pop into my head right away are at least:
Should this work everywhere, or just in text input fields?
How should the original functionality of . be preserved, if at all.
(What should happen after the initial . keypress?)
Should there be some timeout between the keypresses?
Etc, this is just what I could think of right away, but surely there's more.
Anyway, for now I can give a simple implementation with a hotstring:
:*?:..::{Tab}
So this is a hotstring with the * and ? options.
I'm guessing these would probably be pretty good options for this.
So what this does, is it presses backspace twice and sends a Tab if you type ...
This should be fine for text editors, but it leaves much to be desired (the points I listed above aren't considered since I can't know what you're looking for. This is just what a default simple hotstring can offer).
Looks to me like you don't actually want the additional mapping of .. to Tab, but instead just want to update your existing hotstrings to activate immediately (without waiting for an EndChar) when the hotstring is followed by ..
Normally, you might look to the Ending Characters option to create this functionality, but since you want multiple characters to trigger this, we need to look to other options.
I will be using the example of ::mt::margin-top for my sample implementation. Extend any changes I make to these to the rest of your hotstrings in the script you screenshotted.
Here are the changes I am making to this example:
Add your .. to the end of each of your hotstrings triggers. For example ::mt::margin-top becomes ::mt..::margin-top. However, at this present, this still requires some sort of ending character to be pressed in order to proc. Let's fix that in the next step
Add the Asterisk Modifier to the hotstring. From the docs:
* (asterisk): An ending character (e.g. Space, ., or Enter) is not required to trigger the hotstring.
Final code for ::mt::margin-top example:
:*:mt..::margin-top
And extend this * insertion and .. appendation to each of your hotstrings.
Hope this helped! Lmk if you need any more help or changes.
Is there any way to globally configure all text editors in Eclipse to insert only the user's actual keystrokes into the file, and zero additional characters?
In particular, is there a way to ensure that typing ENTER always inserts exactly ENTER, no more, no less, and never inserts ENTER SPACE SPACE...SPACE for some context-dependent number of spaces?
The behavior will have several desirable (to me) consequences:
typing ENTER BACKSPACE would restore the file to its exact state prior to ENTER. Currently, roundtripping the state (e.g. to revert an accidental keypress) requires ENTER BACKSPACE BACKSPACE BACKSPACE ... BACKSPACE.
typing ENTER ENTER ENTER ENTER at any location in the file would produce three completely empty lines and leave the cursor at the extreme left of the fourth line, versus four lines prefixed by SPACE SPACE...SPACE which demand further cleanup.
Multi-line copy-paste will be 100% predictable and consistent irrespective of context.
This is how every other basic editor behaves (or at least can behave), so it seems plausible that this would be achievable in Eclipse, somehow. But although I have found ways to disable every other 'smart' intervention Eclipse throws across my path, I have never found a way to disable the ENTER SPACE SPACE...SPACE behavior.
The solution needn't be a built-in configuration parameter (and by this point I doubt such exists). Plugins or other one-time hacks of moderate complexity are acceptable, provided the result is an always-on type-one-key-get-one-character behavior.
Note, importantly, that invoking an auto-format operation after the fact to clean up unwanted whitespace is a non-solution. I know that works; it's not what I'm looking for.
Which setting needs to be done in init.el file, which allows completing the rest of command if one hit M-x and initial letter of the command.
Infact in need something similar as ido-mode for minibuffer too
The ido-mode for the "M-x minifuffer" is called smex (smex use ido).
Available on the main package repos of Emacs. Homepage here
I think you are talking about incremental completion, i.e., having Emacs automatically complete what you type in the minibuffer, without your having to explicitly request completion (e.g., using TAB).
Incremental completion is available in Icicles, as well as Ido and IswitchB. And icomplete-mode shows you completion candidates in a similar way to Ido and IswitchB.
Icicles incremental completion has two aspects:
When buffer *Completions* is displayed and updated, showing you the candidates matching your input -- how soon that happens and what triggers updating
Whether and how much your minibuffer input is expanded (completed) to reflect the set of matching completions
Wrt *Completions* display (#1):
You can use C-# to cycle among the levels (normal, eager, off) at any time.
Normal means that *Completions* is not displayed until you ask for it, but thereafter it is automatically updated as you type/edit your input.
Eager means that *Completions* is displayed as soon as you type something that matches at least two candidates.
(There is also an option to show *Completions* from the outset, before you type anything -- useful as a kind of menu.) You can also specify how long to wait after you type or delete a character before updating *Completions*.
Wrt input expansion (#2):
Icicles is unique in expanding your input to (typically) the longest common match among all completions, even when completion uses apropos matching (that is, regexp or substring -- S-TAB), not just prefix matching (TAB).
There are 4 levels/behaviors for this expansion, plus off (no expansion):
Off -- this is like Ido and IswitchB: completions are shown, but your input is not completed
On request -- expand your input only when requested (TAB or S-TAB)
On request or sole candidate -- on request or when there is only one match
Always for TAB, on request for S-TAB -- TAB expands whenever possible; S-TAB is like previous
Always -- expand input whenever possible
C-" toggles between two of the input-expansion behaviors that you choose (a user option), and C-M-" cycles among all of the behaviors.
While trying to autocomplete a file (e.g. to open a file with C-x C-f) Emacs-helm shows a list of possible candidates.
If I then press Tab (which I would hope it would help me choose the first/closest match), I get the following in the minibuffer:
It looks like the minibuffer gets confused with escape characters, and it does not choose the file that I actually want to open (the top choice).
Helm requires this conceptual jump from the default Emacs completion, which is not so obvious:
You don't need to press a key to complete. The completion buffer refreshes
with new results after every input.
This is called "incremental" completion.
The normal tab functionality is not needed in "incremental"
completion. So tab was rebound to helm-select-action, which allows you to
choose an alternative action with the selection. But there is only one action
in read-file-name.
The error you're seeing could be clearer though, I've filed this issue on github.
Additionally, note Helm treats each space separated term as a filtering
regular expression. So, pressing space foo will filter
the current list down to those that contain foo in the name.
It's not that convenient when you do a typo during an incremental search and the search string receives the wrongly typed character. Is there a way to prevent this. As if control-g was pressed automatically on error.
For example we have the following text:
keywords
keys
Default emacs behavior:
We start incremental search and search for "keyz"
The "keyz" is displayed in the search echo area and the "key" part in "keywords" is higlighted
We press s
"keys" won't be found, the cursor stays on the "keywords" line, search echo area displays "keyzs", which is not convenient
Needed behavior:
We start incremental search and search for "keyz"
The "key" is displayed in the search echo area and the "key" part in "keywords" is higlighted
We press s
"keys" is found and highlited
You could try something like
(defadvice isearch-printing-char (before drop-mismatches-on-next-char activate)
(while (or (not isearch-success) isearch-error)
(isearch-pop-state)))
Emacs keeps the incorrect part, because it happens very often that you search for a string and it is not found, but not because it's incorrect, only the search string is found before the cursor. In this case it is very convenient that you can press C-s and the search starts from the beginning of the file.
It is very useful behavior and it happens to me more often than mistyping the search string. If there is indeed an error in the search string then you can simply press C-g to go back to last good search string.
I think the problem is that you're not thinking about searching in a way that's congruent with the way isearch has been designed to work, and so your question doesn't really make sense within the context of isearch as it currently exists.
Isearch does already give you exactly the feature what you want, but you have to tell it that you want it to happen by typing that C-g you seem so vehemently opposed to typing. If you don't tell isearch what you want to do, and when you want it to do it, how is it supposed to know what to do?
As #Tom tried to explain, the default way isearch starts from the current position in the buffer, and can restart at the beginning of the buffer if you've typed some failed characters and then press C-s, is a very valuable feature. I'm sure many people rely on this behaviour. Your method of using a macro to always start an isearch at the beginning of the buffer would confound and confuse many of us, though of course it's not a bad thing for someone such as yourself who is accustomed to it. It does mean though that the rest of us are quite confused by your dislike for having to press C-g to delete the non-matching text.
Think also for a moment about what a second C-s does if you press it immediately after starting isearch (any time but the first time in a session) (i.e. before you type any other character). Note in particular what happens if your previous search string would only partly match something in the current buffer, and then you press C-g (and also note how the failed search string is presented, regardless of whether it would partly match something in the current buffer or not).
Think also about how your feature might adversely affect the use of multi-isearch-next-buffer-function.
Claiming that other editors can do what you want isearch to do in emacs doesn't really help your case much.
I think what you really want is some slightly different type of search function which only allows you to search for text that it is possible to find in the current buffer, instead of isearch's ability to search for anything whether that text happens to exist in the current buffer or not.
Perhaps isearch-mode could be adapted to do what you want it to do, but one way or another I think you'll have to write some elisp code. Perhaps you could implement your new search mode as an option within isearch-mode that can be toggled on and off in the same way case sensitivity can be toggled on and off; and that can be set by default, again in the same way that case sensitivity can be turned on or off by default.
If you make a typo during incremental search all you need to do it press backspace to correct the typo.
We start incremental search and search for "keyz"
The "keyz" is displayed in the search echo area and the "key" part in "keywords" is higlighted
We press backspace
We press s
"keys" is found and highlited
As with most of the other answers, I'm just pointing out another feature which helps mitigate the described problem. This one is particularly useful if you've continued to type several would-have-been-good characters after the bad one.
M-e is the binding for editing the isearch string, and in the case where there are no matches for the current string, it rather helpfully places point at the first non-matching character.
So if you have made a small typo, you can quickly type M-e, fix the mistake, and type RET to return to isearch using the corrected search string.