I have the following AutoHotkey script sample, notice the code is indented by a single space:
#z::
MsgBox The Win-Z hotkey was pressed.
Gosub MySubroutine
return
MySubroutine:
Sleep 1000
return
I searched through the VS Marketplace but didn't find a usable formatter extension for AHK scripts.
I've configured "editor.tabSize": 2, is there a way to format the code to use the specified tabSize with the VSCode built-in formatter?
It looks like there is an AutoHotKey Plus extension that includes formatting that seems to adhere to the Visual Studio Code built-in formatter setting for the tab size. I set my tab size to two and performed the format shortcut using the extension (Shift + Alt + F):
It seems though that certain keywords, such as return will cling to the margin, presumably because the formatter for the extension interprets this as the standard convention for AHK (in my opinion though, I like the way it looks).
This feature request is tracked here.
Related
How would one achieve the same result. I believe the keybinding for macOS Intellij is op+up/down and on windows it is alt+w/d.
Essentially the function highlights the current word, then, with successive presses, expands out to the full string/line/area in-between parenthesis/further out to the next set of parenthesis. Very useful for developing in LISP.
The closest I've gotten is this: https://vi.stackexchange.com/a/19028
Try this plug in: https://github.com/terryma/vim-expand-region
It expands selections based on Vim’s text objects.
Well this may seem comfortable but does not correspondent with the internal logic of vim itself.
See, in vim everything you enter is like a sentence. va{ for example: there is a verb v -> visually select and an object (or movement) { -> paragraph. In this case there is also a modifier a around. You can exchange stuff in this sentence and it will still work vaw, dil, cB and so on. The power of vim is greatly based on that concept.
Of course you can write a function that does vaw first, then S-v and lastly va{ but that will only work with visual selection. It will not work with c or d or anything. So I will recommend to get used to use different keys for different actions.
The visual selection is mostly not needed anyway. Change a paragraph? directly use ca} and so on.
I have found that VI/VA + WOBO (as many times as you need to expand) works similarly. Not as fast but its the same concept and you can even expand/shrink asymmetrically based on your WO's and BO's (Or OW's and OB's depending on how you look at it)
When I write something in VB.NET, the IDE automatically formats my line indents perfectly, I don't have to use the tab key at anytime.
In C#, when I needed to edit a line of code, and I perhaps wrecked up the indentation like this...
void MyVoid()
{
if (1==1)
{
int iThis = 5; //line with ugly indentation
}
}
..., and I have to correct the indentation manually or use Ctrl AKF to fix it.
In VB.NET, the IDE would fix it automatically when I skip to any other line.
How can I make this as easy as it is in VB.NET?
You can use my (commercial) Continuous Formatting extension that formats the code as you type.
Power Commands has an option to automatically format the document when you save. There's also a lighter-weight extension titled Format document on Save that should do the same.
I have following sample code
Dim q As Char = "a"
Dim res As String = CStr(AscW(q))
res contains correctly "97" but when I use AscW(q) in watch or immediate it returns message: Cannot convert to 'Integer'.
Is it a bug or Visual Studio or am I doing something not correctly?
How can I see a character code in Immediate.
Note
The code presented is just an example. I found the problem when trying to see Character code in the Watch Window.
For a workaround, how about the command
? System.Text.Encoding.Unicode.GetBytes(q)
I personally believe that any acceptable VB.Net code should be acceptable in the Immediate window and really don't understand why AscW is causing errors when VB.Net offers no equivalent (e.g. in C#, but not VB.Net, you can cast a Char variable to an Integer to get the character code).
You are doing everything right (and the outputs will be OK in any case), although you are using old VB code. If you need functionalities like AscW (, Asc, ChrW, etc.), you would have to rely on this "old code" to get what you want (directly or via Microsoft.VisualBasic.Strings which, btw, does not show a different behaviour). But, in any other case, you should avoid the utilisation of this old code.
Test these two lines in the Immediate Window:
Dim res As String = CStr(5)
res = 5.ToString()
As you can see, you get an "error" (VS 2010, right-click on the line and select "QuickWatch") in the first line (old version), but not in the second one (.NET version).
Thus, the behaviour you observed can be considered as an inoffensive bug (no real effects in the execution) more or less understandable if you analyse the situation (you are asking a certain language (VB.NET) to support all its own features and the ones from an old language (VB); with the old one, some secondary functionalities might not be perfect).
There are so many settings in the preferences for Code->Style->Objective-C. I'm looking for the right one to reformat this line of code
SCPropertyDefinition *test = [SCPropertyDefinition definitionWithName:#"created_at" title:#"Tweeted At" type:SCPropertyTypeLabel];
to this format
SCPropertyDefinition *test = [SCPropertyDefinition definitionWithName:#"created_at"
title:#"Tweeted At"
type:SCPropertyTypeLabel];
(the point is to have the colons indention matching)
I guess the it should be in the Wrapping and Braces Tab, but I havn't found the right setting yet.
Thanks for your ideas.
The setting you are looking for is Wrapping and Braces | Method call arguments set to Chop down if long with enabled Align by colon. Note that there are separate settings for Method parameters.
It seems like as of App Code 2017.1 (perhaps earlier too) the align by colon option is not available in Swift. You can still tell App Code to chop a long argument/parameter list:
According to MSDN vb.net uses this extended character set. In my experience it actually uses this:
What am I missing? Why does it say it uses the one and uses the other?
Am I doing something wrong?
Is there some sort of conversion tool to the original character set?
This behaviour is defined in the documentation of the Chr command:
The returned value depends on the code page for the current thread, which is contained in the ANSICodePage property of the TextInfo class in the System.Globalization namespace. You can obtain ANSICodePage by specifying System.Globalization.CultureInfo.CurrentCulture.TextInfo.ANSICodePage.
So, the output of Chr for values greater than 127 is system-dependent. If you want reproducible results, create the desired instance of Encoding by calling Encoding.GetEncoding(String), then use Encoding.GetChars(Byte()) to convert your numeric values into characters.
If you go up one level in the chart linked in your question, you will see that they do not claim that this chart is always the output of the Chr command:
The characters that appear in Windows above 127 depend on the selected typeface.
The charts in this section show the default character set for a console application.
Your application is a WinForm application, not a console application. Even in the console, the character set used can be changed (for example, by using the chcp command), hence the word "default".
For detailed information about the encodings used in .net, I recommend the following MSDN article: Character Encoding in the .NET Framework.
The first character set is Code Page 437 (CP437), the second looks like Code Page 1252 (CP1252) also known as Windows Latin-1.
I'd guess VB.Net is simply picking up the default encoding for the PC.
How did you write all this? Because usually, when you use a output stream function, you can specify the encoding going with it.
Edit: I know this is not C#, but you can see the idea...
You'd have to set the encoding of your filestream, by doing something like this:
Setting the encoding when creating the filestream