I don't think this is just Scala, or the Metals plugin. I remember this happening with Python, too, but my current situation is with Scala.
I really like using autofill and suggestions; it's my favorite part of any IDE, including VS Code.
VS Code autofill works great, it's just really frustrating where it puts the cursor after autofilling. And I feel like I must be doing something wrong, since I couldn't find any search of others having this problem.
Example:
Below I am writing println, just as a dummy, but it happens with any autofill. I type enough so that I can see the autocomplete options appear.
Then I hit to autocomplete on the highlighted option, and it fills with the cursor after the closing parenthesis:
But, of course, when I autofill, I want the cursor to be inside the parentheses, not after them.
What can I do to get autocomplete to be more friendly in VS Code?
Argh!! I eventually figured out what was happening, and why it seemed so inconsistent:
If I choose an autofilled function that requires no arguments, then it will autofill and place the cursor at the end of the parentheses. If I choose one that does require arguments, then it will go inside the parentheses.
That makes sense, except that there are several functions which can be used without arguments, but rarely are, and VS Code will always put the no-argument case as the top choice. So, if you see the top one and are "happy" with it and choose it, the cursor will jump to the end.
As you can see above, there is a no argument println() which is the top of the autofill list. Not ideal, but at least now I understand what was going on. Not sure of a fast way to fix it, since again, this is something that I will be typing a bunch. Probably just avoiding autofill will be fastest. :(
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.
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).
I'm tinkering about switching my IDE to emacs. (I'm still an emacs newbie.)
The problem is that I customized my IDE quite well and I'd regret to leave my helpers behind.
Let me explain:
Shows the current open files/buffers, allows fast switching with a hotkey (C-1, C-2, ...)
Shows the most recent texts on the "clipboard" or inserted by complete (no. 4), text insertable with a hotkey (C-b 1, C-b 2, ...) Last inserted shown in bold, insertable with C-`
The last inserted complete (no. 4) text, insertable with M-`
Autocomplete-ish list, gathered from all open files, regardless of their type with some magical logic. text insertable with a hotkey (M-1, M-2, ...)
I guess emacs has such features, but I'm a visual type I'd like to see what I have available.
Of course actual hotkeys don't matter much, but as you see having all that info visible makes it easy to hit the spot with the least keypresses.
My pain is that there is a plethora of emacs extensions providing various features, checking all seems to take a lifetime.
My question is:
are there any emacs extensions to achieve similar looks and behavour?
as I'm a programmer, which extensions could I take as a base to assemble something like this?
Thanks!
Elaborating a bit more:
I’m a python dev, so most of the code I’m writing is python. Add some HTML JS CSS XML to the picture.
One important thing is that completion needs to work across filetype boundaries, because python / HTML(template) / XML(config) / doctest identifiers are cross-referenced. It’s a huge pain with some IDEs that completion works only for python filetypes.
I have a lot of same named files but in different folders, like init.py, configure.zcml, etc. It seems to be a pain to switch between those by filename.
Better said that’s a list of recently inserted text. To be reused by the fewest keys as possible. Usually when coding I’m reusing the same identifiers/whatever within the same task. So it’s handy to have them listed instead having to retype the starting x chars to get completion again.
Usually best use of this feature is when changing/refactoring code. Like adding one more extra feature and the identifier is needed several times over the place.
TL;DR
Learn keyboard macros. Learn yasnippet.
Autocomplete mode is probably similar to what you have.
Get acquainted with emacs kill-ring before trying to change it, it wants to be your friend. Then you'll know what to look for when you DO want to change it.
Long Version
Shows the current open files/buffers, allows fast switching with a hotkey (C-1, C-2, ...)
You have three options for this.
My personal preference is to have all source files open at all times. So I don't need a visual list of open buffers. Whenever I want to switch to a file I hit C-= (which I've bound to iswitchb-buffer) and type a couple of unique letters. It's common to constantly switch between the same two buffers so I also bound C-backspace to previous-buffer.
Another option I can recommend is tabbar. It's not exactly like your setup, but it displays a list of open buffers (just like webpages in a browser) and it has functions for cycling through the tabs, so it shouldn't be hard to reproduce your C-number key bindings.
You could use speedbar or ecb. They would be the most similar to your current visual configuration, but I'd argue the other options are more efficient.
Shows the most recent texts on the "clipboard" or inserted by complete (no. 4), text insertable with a hotkey (C-b 1, C-b 2, ...) Last inserted shown in bold, insertable with...
I see you've sort of mixed the clipboard with completion history. When it comes to emacs, yasnippet and autocomplete are just so good you're better off going with them for completion (see below).
Emacs clipboard is called the kill-ring. I'm sure you know of C-y and M-y, so you can always recover anything you've cut in the past. Unfortunately, I don't know of any packages that constantly display the kill ring or allow you to yank a specific part of it (though that shouldn't be too hard to write), but at least you know what to search for (kill-ring).
The last inserted complete (no. 4) text, insertable with M-`
I'll be honest, I don't see that much use in this. If you have to repetitively insert text, you should learn keyboard macros. In fact, you should learn keyboard macros anyway, they're the first reason I got hooked to emacs.
Autocomplete-ish list, gathered from all open files, regardless of their type with some magical logic. text insertable with a hotkey (M-1, M-2, ...)
Emacs had many great completion options. In your case, the best one is probably autocomplete-mode. It pops-up completion options (much like your separate completions window), and I think it allows for quick selection of a specific option (like your M-number shortcuts). Also it has several different ways of deciding which completions to offer you (it calls them "sources") and one of them is to gather from all buffers.
In addition to that you have yasnippet, and I couldn't possibly recommend it enough. Seriously. Learning to use it and writing your own snippets will change the way you write code. You'll become a mage whose fingers produce pages of code flowing through your screen in blazing speeds. Use yasnippet!
Once you have it configured, every 3 or 4 keys you press will generate a line (or more) of code for you.
After all that, if you still miss something from your previous editor you'll write it yourself. :-)
Your setup looks exactly like https://github.com/emacsmirror/ecb.
To me at least, since I don't use side-bars:)
You should take a look at the extension speedbar. I have installed this extension, but I rarely use it even for a very large project.
total Emacs noob here. So right now I'm working on a fairly big LaTeX project in Emacs in which there are couple of places where I need to index some words, using the makeidx package. Because I also wanted indexed words to be bold, I created my own command \ind{} which would make the argument go bold and indexed. But right now I'm dissatisifed with this command so I'd like to change every instance of \ind{whatever} in my text by \textbf{whatever}\index{whatever by default}.
The thing is I know exactly what I want :
Go through the text, look for any instance of \ind{ and replace by \textbf{ using search-and-replace
Save the argument of \ind ("whatever" in this case) in memory
Ask me the user what should the argument of \index be. By default (by striking enter), it should be the first argument, but I can also change my mind and enter something different ("whatever by default" in this case). If there's no input (only a space " " for example) stop the program.
Write down \index{, the new argument and }.
Go to next occurance in the text.
But, alas!, I know not how to achieve this, so I need someone's help. If it should take too much time to explain how to do such a thing, would you please send me some tutorial about writing my own functions?
I hope I'm being clear, and thanks for your patience!
This approach seems vaguely unorthodox to me, but it works and seems sufficient for a one-off job...
In the replacement text for replace-regexp and query-replace-regexp (C-M-%), one newer escape sequence is \,(...), where ... can be any Lisp expression. There's a Lisp function read-from-minibuffer which reads arbitrary text typed by the user, with an optional default. Therefore:
C-M-%: Start query-replace-regexp.
\\ind{\([^}]+?\)}: The pattern to search for.
\\textbf{\1}\\index{\,(read-from-minibuffer "index content? " \1)}: The replacement text. The user will be prompted for the text to put in the braces following the \index{} element, using the original text between the braces following the \ind{} element as a default.
Note that when using query-replace-regexp, you'll have to confirm each choice by typing y after each. Use M-x replace-regexp if you want to avoid this step.
Vlad give you the LaTeX answer to your problem. An Emacs solution is the key-macro: start with
C-x (
to define a new macro, then do one step of your change, say:
C-s \ind{
<left>ex
Then copy and paste the argument in the \textbf macro... You have to be careful to move in a way that will be repeatable. Once the standard modification is done, you let the cursor after the whatever by default and end the definition by
C-x )
now C-x e will call the macro you just define, letting your cursor at the correct place to change the part you want to change You can also repeat the e to call the macro several time at once.
Why not just redefine the \ind so that it can get an optional argument?
For example:
\newcommand{\ind}[2][]{%
\def\first{#1}%
\ifx\first\empty
\textbf{#2}\index{#2}%
\else
\textbf{#2}\index{#1}%
\fi
}
This way you can use \ind{whatever} or \ind[whatever-else]{whatever}.
When I try to add closing parentheses, it always override the next parentheses to the right.
Here is a screen capture (it looks like I hit the right-key on the keyboard, but I'm actually inserting a new closing parentheses):
Is it possible to change this behavior?
As of version 1.38, the answer is yes, you can turn it off completely, while still keeping the autoclosing brackets.
That version introduced a new setting, editor.autoClosingOvertype, which can take three possible values:
always - always overtype closing parens (the old, classic, Sublime-Text-inspired behavior)
auto - "smart" overtype which tries to detect whether a closing paren was automatically inserted by the editor, and overtypes only those parens (this is the default)
never - never overtype closing parens
The current default behavior was introduced in version 1.37. At that time, there was no setting available, you just got the "smart" overtype behavior no matter what.
I'm leaving the material below for historical purposes.
No, it's not possible (yet), and this is by design. When you are typing brand-new code, and you type an opening bracket, you get the closing bracket automatically (when you have editor.autoClosingBrackets on, of course). Then, when you are finished with typing whatever you want inside those brackets, how are you going to "exit" and leave the closing bracket where it is? The most natural way is to type a closing bracket! Some disagree, but many typists find this much easier than moving their hand all the way out to the arrow keys or mouse to move past it.
Note that this behavior is largely inspired by and modeled after what Sublime Text does.
It may be helpful to understand that the autoclosing brackets feature isn't primarily for saving keystrokes. Rather, its main purpose is to improve the stability of syntax highlighting (which can get wonky when there is an unclosed bracket), and secondarily to help prevent you from forgetting to type the closing bracket. If you happen to navigate away for some other reason without typing it, then congratulations, you do get that bracket for free!
The two simplest options you have if you want to add a bracket (and let me note that in your example, you'd be adding a mismatched bracket) are to either (1) put the cursor after the cluster of closing brackets before you type a new bracket, or (2) put the cursor where you did, but just keep typing closing brackets until a new one is added. In either case, any new brackets will only be added to the end of the cluster.
Update (now obsolete):
For what it's worth, there's now an issue for this on the tracker, as well as a pull request to create a setting which allows you to turn off the "bracket-swallowing". For anyone who is reading this, if it's something you're interested in, you should give your feedback on the pull request.
Further update (now obsolete):
There is currently new code being tested which will make the bracket overtyping more sophisticated. The plan is for the editor to keep track of which brackets have automatically been generated, and only type over those brackets. Once the cursor leaves the bracketed area, the editor stops keeping track of those brackets and they become "full-fledged" characters that can no longer be typed over. Hopefully, this will retain the overtyping where it's useful and get rid of it where it's not. Note that the current plan is for this new behavior to become standard, and to not have a setting to control whether it is in effect.
Try setting:
"editor.autoClosingBrackets": "never"
to disable the autoclosing brackets feature entirely.
Vscode has finally fixed this issue, and you don't need to do anything in order to get the new behaviour. Now it will swallow only brackets that were automatically added, so everything works as expected. If you already disabled the autoClosingBrackets option from the settings, it is recommended to turn it on again now.
The way to work with the VSCode original setting is to add new parenthesis at the end of a list of parenthesis.
...if (test === funFunction(data))| /* <- here */ {...
You should be able to type a new parenthesis and it won't override the old one. This doesn't solve your problem, but if you wanted to follow the paradigm that VSCode is using then there you go.
(personally I disable it like the other comments say)
There's another option available now called autoClosingBrackets beforewhitespace. This will overtype an automatically added parenthesis but it will not overtype of there's any characters to the right of that closing parenthesis. This is perhaps a step closer to the OPs intended behavior, it certainly saved me from going totally bald.