TinyMce paste from the context menu does not work right when pasting onto a blank line - tinymce

When copying and pasting using the Context menu (on a Macbook Pro), the paste doesn't work as expected when pasting to a new line. The text is inserted at the end of the previous line. Has anyone observed this behavior and, if so, have you found a fix?
Here's what I'm seeing:
Go to the latest "demo" TinyMce page (https://www.tiny.cloud/docs/tinymce/6/)
Add at least two lines of text but leave one or more blank lines between the two lines of text.
Copy (using the context menu) some text from the line following the blank line.
Click on the blank line.
Paste the text using the context menu.
I would expect the text to be inserted after the linefeed.
Instead, it appears that the linefeed is overwritten by the text in the paste buffer because the blank line is deleted and the pasted text appears at the end of the previous line.
The cmd-V shortcut doesn't exhibit this behavior

Related

Insert "real" spaces when tab in visual studio code

When I hit tab in visual studio code, the code gets indented with what seems to be "fake" spaces. If I hit tab on a new line without typing anything on the previously indented line, the spaces on the previous line seem to disappear. Is this fixable?
It sounds like the unnecssary (because there is no text on that previous line) is being trimmed automatically. To stop that disable the setting:
Editor: Trim Auto Whitespace
I think that'll result in what you want.

Disable untitled editor improvement - first line name in the title

Is there any to revert/disable the newest change for the untitled tab name (https://code.visualstudio.com/updates/v1_42#_untitled-editor-improvements)
I would prefer to the untitled-1 than the first sentence line.
As your link says:
Note: If the first line is empty or does not contain any words, the
title will fall back to Untitled-* as before.
I don't think there is a way to disable it other than to have that first line blank until you do give it a name.
The request for a setting to disable the current functionality is tracked here: https://github.com/microsoft/vscode/issues/90378 (Config to limit/disable the new Untitled tab auto-naming) or https://github.com/microsoft/vscode/issues/90495
you could upvote that issue.
---------- update, coming in v1.43:
A new setting workbench.editor.untitled.labelFormat lets you control
whether untitled editors should use the file contents as the title or
not. Possible values are content or name. Configure
'workbench.editor.untitled.labelFormat': 'name' for the previous
behavior, where untitled editors would have a short title, such as
Untitled-1.
When pasting text into an untitled editor, VS Code now automatically
tries to detect the language mode from the first line of text. For
example, pasting XML will set the XML mode automatically upon paste if
the first line contains the typical XML header .

Changing the default display of line breaks in search window?

I recently switched from Textwrangler to BBEdit. I use these editors to perform large multi-file GREP-search mainly. But in BBEdit I noticed that line breaks automatically get converted to \n in the search window, and that makes in very hard for me to get an overview of the search I'm about to perform, when everything is on one line.
When I copy a text with line breaks, for example
Line
Line
Line
and paste it in the search window, it looks like this:
Line\n\nLine\n\nLine
In TextWrangler I was able to see the line breaks as line breaks, not \n. How can I change that in BBEdit?
Thanks!

How do I prevent Visual Studio Code from automatically deleting whitespace in blank lines

When I move the cursor from a line without typing anything on it, VS Code seems to automatically delete the whitespace from that line so that, when I put the cursor back on that line, it ends up flush to the left, forcing me to tab to the desired indentation level again. What setting do I change to make it not do that? I tried Googling this problem but all the answers were about removing blank lines with regular expressions, which is not my issue at all.
/* Automatically remove indentation in empty lines on save */
"emptyIndent.removeIndent": true,

How do I get a cursor on every line in vscode

I'm trying to use the multi cursor functionality of vscode on a large(ish) file.
the file is too large to select every line individually with ctrl-alt-up or down. In sublime-text I would select everything and push ctrl-shift-l. Is there a similar thing in vscode. I've tried using a regex search for ^, but that gives me an error stating "Expression matches everything".
The command Selection / Add Cursors to Line Ends altshifti will put a cursor on every line in the current selection. (For mac use optshifti)
Tip: You can pull up the keyboard shortcut reference sheet with ctrlk,ctrls (as in, those two keyboard combos in sequence).
(For mac use cmdk,cmds)
Hold Alt+Shift and select the block. Then press End or Right button.
You get selected individual lines.
I use version VSCode 1.5.3 in Windows.
Hold Alt+Shift+i
Hold Home (fn+-> Mac) for right-most or End for left most(fn+<- Mac)
This feature is actually called split selection into lines in many editors.
Sublime Text uses the default keybinding, CTRLSHIFT L
VSCode uses ALTSHIFTI
For Atom you actually need to edit your keymap to something like this
'.platform-win32 .editor, .platform-linux .editor':
'ctrl-shift-L': 'editor:split-selections-into-lines'
Real Lines vs Display Lines
First we have to understand the difference between Real Lines and Display Lines to completely understand the answer of the question.
When Word Wrap is enabled, each line of text that exceeds the width of the window will display as wrapped. As a result, a single line in the file may be represented by multiple lines on the display.
The easiest way to tell the difference between Real Lines and Display Lines is by looking at the line number in the left margin of the text editor. Lines that begin with a number correspond to the real lines, which may span one or more display lines. Each time a line is wrapped to fit inside the window, it begins without a line number.
Cursor At the Beginning of each Display Lines:
Cursor At the Beginning of each Real Lines:
Answer to the Question
Now that we know the difference between Display Lines and Real Lines, we can now properly answer the actual question.
Hold AltShift and select the text block.
Press Home to put cursor on the beginning of every Display Line.
Press End to put cursor on the end of every Display Line.
Press HomeHome (Home twice) to put cursor on the beginning of every Real Line.
Press EndEnd (End twice) to put cursor on the end of every Real Line.
Please understand that AltShiftI put cursor on the end of every Real Line.
Install the extension Sublime Commands.
[Sublime Commands] Adds commands from Sublime Text to VS Code: Transpose, Expand Selection to Line, Split into Lines, Join Lines.
(Don't forget to add the keybinding(s) from the extensions details page to your keybindings.json)
Doesn't VS Code already have a "split into lines" command?
Yes, yes it does. However it differs from the one in Sublime.
In VS Code, when you split into lines your selection gets deselected and a cursor appears at the end of each line that was selected (except for the last line where the cursor appears at the end of the selection).
In Sublime, when you split into lines a cursor appears at the end of each line (with the same exception as in VS Code) and the selection is divided on each line and "given" to the same line.
I have the same problem, i'm used to Alt + drag to do 'box selections' in visual studio but it does'n work in code.
It seems to be impossible for now to do it differently than by selecting every single line.
However plugins should be supported soon so we will likely see a plugin for this if not implemented directly by microsoft.
From visual studio uservoice forums:
We plan to offer plugin support for Visual Studio Code. Thank you for your interests and look for more details in our blog in the coming weeks. http://blogs.msdn.com/b/vscode.
For the preview we are looking for exactly this type of feedback. Keep it coming.
Sean McBreen – VS Code Team Member