I use xCode as my C editor for a small makefile project I'm working on. I keep noticing during Git commits that the whitespace is being changed on me. Here's an example:
void parse_key_values(Card *card, Errors *errors)
{
char str[MAX_LINE_LEN];
char key[MAX_LINE_LEN], value[MAX_LINE_LEN];
Although difficult to see, if you cursor through this you will notice there is a single 2-space-wide tab and a space at the front of the lines. The tab is correct and what I would expect to see. I have no idea where the space is coming from. When I remove it manually and re-indent, it re-inserts it.
Here is my setup:
I have tried changing "prefer tabs" to "prefer spaces", and then goes ahead and inserts three spaces.
I suspected that it was counting the opening brace and indenting from there, but then noticed the same problem on code like this:
if(split != NULL) {
if (split[0] == '=') split++;
if (split[0] == ':') split++;
This is driving me crazy, and causing all sorts of annoyance during commits. Anyone know what's going on here?
sigh
So right over on the right side of the screen is this little bit of UI:
Somehow, and it absolutely was not deliberate, the second of those two settings was changed to "3", so xcode was doing precisely what it was told to do.
Having never used that field, ever, I have never even looked at it. I'm still lost as to how I managed to change it.
Related
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 installed DataGrip and spent a couple hours getting rid of bells and whistles that distract me from editing sql, like the lightbulb. I'm down to this one that for my life I can't figure, so when I move around with the caret, the editor comes up with what it thinks is the current statement and draws a thin border around it, say if it's a line ending in a semicolon, it will border just that line, but if I have several statements each not ending in semicolon, it will think they all make up a single one and draw the rectangle around the whole thing. This in itself is distracting, plus if I hit Enter within the border, it will indent differently according to what it thinks the whole thing is. I just want Enter to go to a new line at the 0, leftmost position.
Is there any way to turn the whole feature off completely?
Apart from that, does anyone know if it's possible to get DataGrip to display the number of rows affected after an INSERT or UPDATE, like most other tools do?
I'm using it with Postgresql. Thank you in advance!
cpp_developer! (By the way, what do you think about CLion? :)
There are several questions in one, let's get answers one by one.
Lightbulb: there is no UI for getting rid of it, but there is the way. It is described in this ticket: https://youtrack.jetbrains.com/issue/IDEA-94381
TLDR:
Following line should be added to the
$IDE_CONFIG_HOME/options/editor.xml then:
<option name="SHOW_INTENTION_BULB" value="false" />
Line showing the current statement.
It can be removed, like any other color/font thing: A small helpful action. For now it is only present in the Find Action menu (Ctrl/Cmd+Shift+A), but as usual, you can assign any shortcut to it.
This action will navigate you to the settings which are relevant to the context under the caret. If there are several of them, just choose one. In your case "Statement to execute". Then remove it or make white.
Smart indenting. Just turn this off:
Number of INSERTed and UPDATEd rows can be found in Output tab. But please, run them in batch mode -> context menu "Run %your_console%.sql"
Since few days (since the last version of xcode?), I noticed that the syntax color takes sometimes a while to appear and sometimes doesn't even appear, then I need to "reload" the file by clicking on another file and going back to the current one.
I tried to solve it by deleting the derived data but it didn't solve my problem. It is quite annoying as it seems I cannot click on a method (and go to its definition) if the syntax color is not ready.
Any idea?
So briefly, my problem was about some lines of code that had a hard time to compile and was taking the whole compilation process ages. It was linked to my problem probably because Xcode quickly compiles the file you're working on before enabling any inner link/color for the code.
So if your compilation takes a while here is how you can quickly find out what's the problem (if it is related to some of your lines of code)
So I found some help on some website to find out what it was but I can't give you the links as I don't remember them. So here is how I proceed.
First when you compile, go on the Report Navigator on your left and select the Build being built. Then in your main tab, try to look for the file that takes a while to compile (it is the one that should stay with the arrow longer than the other ones). Once you found it, select the line of the file and on the very right side, there is a button that will expand a tab showing the command to compile your file with Terminal.
Copy the part starting with /Applications/Xcode.app/Contents/Developer/Toolchains to the end (name_of_your_file.o) and paste it in the Terminal.
If you execute it, it should take more than just 3-4 seconds.
Then when you execute it, you have to press Ctrl(^) + \, you will send a quit signal and it will cause the process to terminate and dump core, showing you the line and the code it was compiling so most probably the part that was taking a long time.
In my case, one of the problematic lines was
maximumValue = CGFloat(abs(high + (15/100) * (high - low)))
I replace it by
let maximumValue = abs(high + (15/100) * (high - low))
maximumValue = CGFloat(maximumValue)
and it solved my problem. Why this piece of code was causing problem is another question...
I found that is also was a line that seemed too complex to process. I found that if I typed "let bob = UII" at the very top of the class, the syntax highlight worked fast, whereas at the bottom of the file, it was crazy slow. The simplest way I found was to simply try the "let bob = UII" at half way, and then basically halve and halve again. My problem turned out to be calculating a variable with multiple calculation and additions. Broke it up over 4 lines and everything is fine again.
I am writing a Visual Studio extension which provides intelliSense for a certain content type.
The problem that I am facing now is the effect of "Auto Indent" that Visual Studio provides on empty lines when user types a character.
Here a completion session started on an empty line (over virtual spaces):
Notice the tab symbols on the other lines and no tab on the line with caret on it.
Now when use starts typing, VS automatically and correctly adds necessary tab characters to the line:
Now the problem is those Added tabs apparently become part of the user input and as a result CurrentSession.SelectedCompletionSet.SelectBestMatch() or Filter() method cannot find the current item which starts with "C" here (thinking user has typed \t\tC instead).
If I start the session on anywhere else which does not require auto indent everything works fine.
Any idea?
Edit (more information): I used a code flow very similar to:
Ook here
vsLua here
vsClojure here
In Lua and Clojure you wouldn't face this problem because they never provide intelliSense on virtual spaces (meaning they always start after a certain set of characters) and if you start after a character virtual spaces are already turned into real spaces.
Ook on the other had has the same problem.
Revised Answer:
Ah, I see. I interpreted your question thinking that you were referring to completion triggering via typing, not from the explicit command. If you enable "show whitespace" for the C# editor, you can see what we do here: when you trigger the "show completion" command, we explicitly realize the whitespace so you're no longer floating around in virtual space. You should probably do this as well. (Alternatively, you could detect the scenario and fix it up on the first typing by adjusting your ApplicableTo span, but that's probably not worth the trouble.)
You can get the whitespace that should be inserted from IEditorOperations. So MEF import an IEditorOperationsFactoryService, and then do:
var editorOperations = editorOperationsFactoryService.GetEditorOperations(textView);
var whitespace = editorOperations.GetWhitespaceForVirtualSpace(textView.Caret.Position.VirtualBufferPosition);
if (whitespace.Length != 0)
{
textView.TextBuffer.Insert(textView.Caret.Position.BufferPosition, whitespace);
}
(Funny aside: as I answered this, I was curious to see how we handled this in the Roslyn C# and VB editors. The answer was "not", but filtering still worked by pure luck later in the code.)
Original Answer:
I suspect by your description of the problem that you are implementing your completion like this: you know a character is about to be typed (either via a keyboard filter or IOleCommandTarget) and you trigger an ICompletionSession, where the tracking span is an empty span on the current caret position.
The best approach to fixing this is to not trigger the session before the key is pressed and goes into the editor, but rather after it. This is what we do in the Roslyn implementation for C# and VB completion. Then, when you are in your AugmentCompletionSession call and creating your CompletionSet, compute the "applicable to" span which consists of the non-whitespace characters around your caret. The easiest way to compute this might just be to call GetWordExtent from the text structure navigator.
This allows for other scenarios to work right. Consider scenarios where the user types C, presses escape, and then continues to type your identifier. If you want to trigger completion again, you'd have to do the math to ensure that the "C" is counted as part of your span anyways.
How can I turn on curly brace matching?
This worked fine in Xcode 3.x. In Xcode 4 is doesn't work. I've already checked the box for "Automatically insert closing '}'" in the Preferences->Text Editing->Editing panel.
How can I turn on parenthesis matching?
How can I turn on code compeletion for "if/else-if", "for" etc?
In Xcode 3.x I would start to type "for" and autocomplete would provide the parenthesis, curly braces, semi-colons etc. I could then press escape for a menu containing (amongst other things) the option to do a "for i" loop (in which case Xcode would fill in "int i; i < n; i++" with n selected so I could just type a value).
In Xcode 3.x I could do something similar for if/else-if blocks. I could just start to type "if" and autocomplete would provide parenthesis, curly braces etc.
Edit: after looking for the "get info" option for a source code file (was simply right click the file name in Xcode 3) for five minutes I decided to downgrade to version 3.2.x. Which means hours of downloading. This really stinks :-(
Auto-} works a little differently in Xcode4. It doesn't appear as soon as you type the {. You have to hit return after to get the closing brace. So typing { gives the autocomplete. It feels a little odd at first, it took me awhile to adjust, but I think it makes sense. Most coding styles dictate a return after the opening brace, so it pretty much will always auto-close when you want it to. It doesn't give the } though in a case like making a single line if into a multi-line one. You can now add in the opening brace, move the curser to after the line, and enter the closing brace. Before when I did something like that I'd have to spend time deleting the auto-}.
For code completion, it sounds like you're having an indexing issue. Code completion still works as you want (it's actually a lot smarter now) in Xcode4. Your syntax coloring is also usually off when this happens. I ran into it with one of my projects and fixed it by editing my build settings, I had a bad one in it. You might also try deleting the project's derived data in the organizer. That'll force a rebuild of the index.
The "get info" items have moved. It's one of the land mines of the IDE rewrite. They're not in the file inspector. Show the utilities pane and then select the file inspector (the first icon in the tab bar).
Xcode 4 is a bit alien when coming from Xcode 3. They changed a lot of stuff. I'd recommend getting a feel for it. At some time in the near future Xcode 3 will be deprecated and you won't get the new SDks for it. You can have Xcode 3 and 4 both installed at once which is helpful for making the switch. That way you can fall back to Xcode 3 when you get stuck on something and will allow you to gradually make the change.