I tried setting it in preferences, disabling word wrap, changing word wrap column, trying alt z, but the line is always there and forces the code to wrap into 1/3 of the available space which makes long code hard to read
Related
how can I add lines to my code on Xcode as other code editors like the image below?
how can I add lines to my code on Xcode as other code editors like the image below?
You can't, because Xcode doesn't render code that way. However, those vertical lines are often used to indicate which lines will be collapsed or folded, and Xcode does support code folding:
The vertical gray bars next just to the right of the line numbers are Xcode's way of showing how code is nested. If you place the cursor over one of those bars, Xcode highlights the beginning and ending braces. Clicking on a bar will fold the corresponding block down to a single line with ... between the braces. This is similar to what the vertical indentation lines do in some other editors.
Is there a way to cycle through VS Code's four word-wrap (editor.wordWrap) settings?
The four settings are:
off
on (lines will wrap at viewport width)
wordWrapColumn (lines will wrap at editor.wordWrapColumn)
bounded (lines will wrap at minimum of viewport width and editor.wordWrapColumn)
All I can do right now is toggle wrapping on and off (I've bound this to a shortcut). Note, by 'on' I mean it toggles between off and whichever of the three 'on' states is set.
Depending on what I am doing, I'd like to cycle through the settings instead of toggle on and off.
I've not been able to find a plugin that does this specifically. Is there perhaps a generic way to cycle or select specific settings?
I would love to have some space between the line numbers and the first intendation/code in the VS Code editor window:
I just want to indent the code in the editor without actually adding whitespace in the code.
I tried "editor.glyphMargin", but this will only increase the space on the left of the line numbers, not between the line numbers and the code.
I'm also aware of the "Centered Layout" view, but this also decreases the width of e. g. the tabs for the file selection.
Is there a setting I'm missing or do I need a plugin/custom CSS?
You can try this --
"editor.lineDecorationsWidth": 25,
This increases the space on the right side of the numbers. I haven't seen anything that increases the padding on the other side of the gutter nearest your code.
Opinion --
Ideally, there would be a editor.padding.left like there is a editor.padding.top, but I haven't seen this yet.
Alright, I do not know how to fix this and only ran into this problem after trying to put in some longer text on a UI Text component. I have tried both pasting a value into its Text attribute through the Unity editor, and setting its value programmatically like this:
t.GetComponent<Text> ().text = "This is where meat, fish, and [...] (long text)"
Because Horizontal wrap is on, the text wraps when it reaches the edge of the available space.
However, the text displays backwards. Meaning, the start of the paragraph is at the bottom, and bottom at the top. Taking off wrap fixes this, but then the font size has to be really small (or it won't all be visible), and it can't form a normal paragraph because it has to... you know... wrap.
Is this a bug in Unity?
This is what happens - as you can see, it is displayed backwards:
The negative Line Spacing value is what is causing the issue here:
When the value of this field is less than 0, the lines will actually be arranged backwards, leading to the behaviour you're currently encountering. Just change the value to a positive number to have the text display correctly.
Enlarging text while having line numbers enabled covers the view of the numbers?
I've enabled line numbers globally by adding (global-linum-mode t) to init.el.
Zooming in on text using the C-x C-+ keybinding results in the behavior seen below, which is not satisfactory.
What can I do to fix this? Are their working alternatives?
I don't see this problem, using library zoom-frm.el (see also Emacs Wiki page Set Fonts).
But vanilla Emacs clearly has another bug, in that enlarging the text by scaling enlarges the horizontal space used for the line numbers (good), but shrinking the text then does not shrink that space used for line numbers (bad). I've just now filed Emacs bug #24164 for this.