I am currently writing my bachelor's thesis in Libreoffice Writer. To make the working process easier I wondered if there is a way to get writer to automatically add an closed bracket when I type an open one. This would be useful, because I have to quote many times and I do this by writing the quote in "..." followed by the last name of the Author e.g. (STEPHEN 2005: 44).
To keep my writing flow going on I would find it easier if I don't have to hop with my fingers so many times to simply write the source of my quote.
So, is there a way to make libreoffice add the second bracket in the moment I enter the first one and then move the cursor back into the brackets so I can continue writing?
Regards, Mario
You can set up AutoCorrect Options in the Tools menu to add in parenthesis. As a test I set up ppp to change to (). However the cursor does not end up inside.
To do this in a single key press, you would need to set up a custom shortcut key (Tools -> Customize, Keyboard tab) to call a macro. The macro would be pretty simple and could be created by recording it. This would allow you to move the cursor to end up inside, as you requested.
Instead of maintaining the references manually, for scholarly writing I recommend you use a tool such as Zotero. It has a plugin for LibreOffice. In my experience, maintaining the references manually will eventually lead to mistakes. Zotero reference stylesheets allow you to use a consistent citation style, something your professors will appreciate.
Related
I have Googled a lot but cannot find one feature in VScode that I would appreciate greatly:
Copy (or move) rest of the current line (i.e. not the entire line) to the end of next line
Example:
What I have - note the cursor
What I need - again note the cursor
So ideally, with a single keyboard shortcut, I would copy (or move) the remainder of the current line (= "ABC1" in the example) to the end of the next line. Any ideas how to do that? Is it available within VScode, or is there a relevant extension? Thanks!
Since you're asking if there's an extension for it, the vim extensions should at least be mentioned. I have no intention or desire to start an(other) editor war, though.
What you're asking would be trivial in vim (y$, yank to end of line) and there are at least two very popular vim extensions for vscode that will bring the vim keybindings as well as the power of configurable commands and bindings in vim to vscode.
Yes, it would require some effort to learn the "vim way" of doing things, but the upside is that you'll probably never have to re-learn the bindings if you move between editors/IDEs since they are available in pretty much every editor and they make editing very fast and precise.
Drag and drop by mouse
Why are you not using mouse drag and drop text?
Select the text and drag it by mouse where you need
Otherwise, if you have multiple times then you can solve it in two steps.
Step1:
Replace all Name by Name(ctrl+enter)SecretCode
Step2:
Replace all "(ctrl+enter)SecretCode by "
Done
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.
Using the GUI: I assigned a macro to allow me to select the current line my cursor is on. I assigned it to 'ctrl+a', and reassigned 'select all' to 'ctrl+alt+a'. I now want, when I press 'ctrl+a' a second time, to have it highlight the remainder of the paragraph. Currently these commands are available via the following key-press:
Instruction:
1. Home->shift+end --highlights one line
2. Home->shift+end->shift+end -- highlights connected lines
So 1. is assigned to 'ctrl+a', but I'm stuck at this point. How do I assign ctrl+a when hit a second time to highlight the connected lines/paragraph? Details/specifics in layman's terms would be appreciated. Again, I've only been using the gui options, I'm not familiar with the more codey options. Note that it doesn't allow me to use
ctrl+a->shift+end.
I'm not overly familiar with macro and hotkey binding, so I'm unaware if this is a limitation or if there's a workaround, other than writing a program to fix it.
Not a coder, but from what I know of Lua I cameup with:
is_press=false
if btn(ctrl+a) and !is_press then btn(Home->shift+end) is_press=true end
if btn(ctrl+a) and is_press then btn(Home->shift+end->shift+end) is_press=false end
I could assign 2. to ctrl+shift+a, as a separate macro if all else fails.
Short answer, I don't think this is possible with a singe shortcut/macro.
Behind the scenes, Scintilla is doing the selecting. Once you've done the selection, going back to "home" the second time will reset the word wrap extension.
Scenario:
If I write some statement of my preferred language and then I use Tab on Sublime Text 3 it puts basic structure of that sentence to use quickly.
But, if I try the same behavior on VSCode, it only completes the phrase instead of structure for that sentence, forcing me to:
Write the complete structure.
Press Ctrl + Space and then use the arrows keys to choose some suggestion structure.
Use arrow keys before Tab to choose the suggestion I want.
Those three are slower than only write some statement and Tab…
TL;TR:
I want to disable the first line of suggestion to use structure suggestions for quickly development:
Are there some kind of config.suggestionBuiltIn: false? I have not seen some similar on the oficial documentation.
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.