When commenting out a piece of code in xcode
//code
If you click comment again it adds more comments
////code
does anyone know how to prevent this?
It looks like a bug to me .... if you do command + ] it gets rid of the tabs.. The tabs are the ones causing the issue. Xcode sees the tabs and adds more comment lines. so do command +] twice or until all the tabs are gone. and then you can remove the comments using the command+/ (comment selection command)
When you "click comment again" you have to have the // selected (and optionally the rest of the line).
Usually when you comment the first time Xcode will select the text such that pressing the comment shortcut again will uncomment.
Is nothing selected after you comment the first time?
Related
I just updated my Sublime Text version (Build 4107), and it seems to me a new behaviour appeared - that I would like to avoid.
Whenever I write a colon or comma, the auto-complete popup automatically displays, which is problematic because most of the time in this situation I am about to go to next line by pressing Enter. Thing is, if press Enter, I select now the first occurence of autocomplete instead of going to next line.
I can avoid this by doing "Alt + Enter" or by pressing "Esc" before Enter, but it is not a convenient solution. Is there any way to prevent this autocomplete popup to display afer this particular punctuation signs ?
I read about punctuation.separator scope naming (https://www.sublimetext.com/docs/scope_naming.html#punctuation). But I can't figure out how to use it in auto_complete_foo settings to do what I want.
Example :
Thanks for the help !
If you have a package SublimeCodeIntel, try to disable it, and check the problem is saved or not
It helped me
You can set "auto_complete_when_likely": false, in your user preferences which should prevent this behavior.
I just installed Win 10 1809 on my Dell PC, and it seems to run okay. But the first thing I did was start up VS Code. I wanted to run yarn start for my React project, but I had to type it way down in the terminal window, while the prompt was at the top. It worked though.
And when I open any project file, there seems to be approximately 100 blank lines appended at the end of each. But the line numbers don't go down that far and the cursor stops at the last line number. But the scroll bar acts as if those blank lines are there.
So I'm guessing the same number of blank lines are being added to the terminal too. But in the terminal window, the cursor is positioned at the bottom of the scrollable window.
What's going on? Is there a fix?
EDITED:
I see that I can scroll the file's window up until the cursor and last line is at the top, but no further, regardless of the window size. Maybe this has always be the case, and I never noticed. But now because of my terminal problem, I am suspicious of everything and checking for any abnormalities. So I don't think that extra blank lines are being added to my files. Sorry for the mistake.
But the terminal problem persists. The screen clip below shows the terminal display after I enter "yarn start". The typed input shows up way down from the initial prompt, and the blank area is a long string of "0D0A" characters. Sometimes I can click on "kill Terminal" and then start a new one and the new one works correctly. But not always.
Still trying to figure this out.
Can you share snapshots for your problems?
This is some hint for your problem
In VS Code, type
Linux / Windows: Ctrl + Shift + P
MacOS: Cmd + Shift + P
Type Settings to go Settings
At settings, search end of file, at here you can configure something for your problem with auto append blank lines each file
I hope it will help you :)
Your Terminal Problem is described as Bug in VS Code Issues.
As of July 2019 the intergration is pending due to stability problems.
https://github.com/Microsoft/vscode/issues/57803
Addendum (August 2019):
The Problem seams to be fixed with VS Code 1.37.1 and Windows 10 Patchlevel 1903
Did you try uninstalling and reinstalling?
Going back to your questions.
What's going on? No idea.
Fix. Use this extension https://marketplace.visualstudio.com/items?itemName=rintoj.blank-line-organizer
or
Open Visual Studio project and collapse all the folder and make it handy.
Now press “ Control + Shift + H “ key combination and you can see the Popup which shows Find and Replace options.
In the Find place input “^&\n” combination and select Use Regular Expression checkbox without fail as this input will mainly work with the regular expressions only.
In the replace field leave it empty so nothing will be replaced rather remove the empty blank lines.
In the input Find field we have give ^ for Start of the line and $ for end of line and \n which is for new line break.
source for second solution: http://www.f5debug.net/post/2015/01/03/How-to-remove-Blank-lines-between-codes-in-Visual-Studio-Code-editor.aspx
The extension will be useful overall especially when working in a team project where a lot of people might be leaving too many empty lines. Good luck
I often use Xcode snippets which contain fields to fill (like <#time_interval#>), I jump between those fields with tabulator. Sometimes, when I fill a field with a word and click tab to jump to next field, Xcode automatically changes word to first suggestion from autocompletion dropdown, e.g. HelloWorld. I don't want to disable suggestions, I just want to disable completing my code on clicking tab. Is there a way to do so? I feel extremely dumb because I make iOS apps for over 7 years already and this setting drives me crazy. It should be something simple somewhere and I must have missed it over and over.
UPDATE for clarification (images):
Click tab and enter one field to fill it:
Type what you want to have there e.g. "literal" word:
Click tab again to pass onto next fillMe field. Expected result:
Actual result (instead of word "literal" you get Color Literal there which is the first position in autocompletion list):
You may use CMD+Z as a workaround - it will revert Xcode autocompletion and leave everything else as is.
Xcode offers the following options under
Preferences > Text Editing > Indentation > Tab key:
In leading white space: Pressing Tab inserts an indentation only at the beginning of a line or following a space.
Never: Pressing Tab never causes an indentation.
Always: Pressing Tab always causes an indentation.
I checked the documentation for these options (that's what is to the right of the colons) but I still don't understand. What is "an indentation"? What I'd really like is if Xcode wouldn't act like it knows better than me and try reindenting lines of code that were already perfectly indented (I find it often does this inside of blocks - I'll have my code nested one level more than the line before it, and for whatever reason it tries aligning with the colon that starts the block argument, leading to unwieldy long lines, as if Obj-C doesn't have enough of those.)
Can anyone give me examples of how Xcode's behavior will change if I choose each of those options? Will one of those options make Xcode behave/autoindent the way I want it to?
If what you want is:
if Xcode wouldn't act like it knows better than me and try reindenting lines of code that were already perfectly indented
then the "Tab key" indentation setting has nothing to do with what you want.
Instead, try unchecking "Automatically indent based on syntax" and Xcode will stop changing your indentation level.
Alternatively, uncheck { and } under "Automatic indent for:".
See also: Xcode Text Editing Preferences Help: Setting Source Editing and Indenting Preferences
Im facing some problems, I looked around in the forum and didnt find
any solutions discussed. Im sorry if these have been resolved earlier.
Is there someway I can make the VIM line break after 80 characters. I
dont want the text to wrap around but create a new line. And I wish it would
break off the complete last word. So instead of fo in the previous and o
in the next line, can it break with foo in the next line?
When I end my comment and press enter, I get a # in the new line. This is
cool but when I delete # and want to start a line of code, I dont get syntax
highlighting there. It still thinks what Im typing is a comment. Is this a
bug or am I doing it wrong?
One more thing is that I have set the shiftwidth to 4. But when I press
Ctrl+S to save the document, the cursor jumps to the beginning of the
sentence. I then need to manually go back to my original position to begin
the code. Is there a way I can resolve this?
Thank you for reading this. I am new to Ruby and Vim. I hope you guys help
me out.
Ctrl-S ? This is not known to me. In Vim/Gvim, a file is usually saved by
:w filename.ext (if none's been given yet)
or
:saveas filename.ext
(for all of these commands try ":help :w" or ... the same principle).
I don't know about the comment part, since I don't do Ruby, but it would be pretty wise for you to get yourself a nice commenter plugin (I think I use LineCommenter) - eases up on the commenting. Just write the comment, and add the #'s later (set it to work in normal and in visual mode; it works beautifully).
As for the breaking the text part, that could be solved by adding
:set tw=80
"wrapscan" is the vim feature that wraps a whole word to the next line; it might not be set by default in your configuration - probably isn't. So in addition to
:set tw=78 you probably want to try one of these:
:set wrapscan
:set wrap <- just a shorter version
:set nowrap <- to turn the wordwrap feature back off
Incidentally, rather than setting the text width (tw) to some number of characters (smaller than your window), you could instead set the margin you want to leave on the right side of the window like so:
:set wrapmargin=1
If wrapmargin is set to something other than 0, textwidth should be ignored.
I would use ":w" to save and continue editing (or ":w filename" if it's a new file) and "ZZ" or ":wq" to save-and-exit when you're done - none of those will move the cursor position.
I'm not sure where your "#" continuation is coming from, but I'd also make sure to set these if they aren't already (you can check what variables are set by just typing ":set" with no other options):
:set syntax=ruby
:set filetype=ruby
:syntax enable
If you started with an empty document and then added "#!/usr/bin/ruby" to it, vim won't notice you're editing ruby until you save&exit and reopen the file. There are other cases where syntax coloring isn't very bright or needs a nudge but yes, that sounds like a bug to me.