while multiline select using shift+end if cursor is above start point, or shift+home if cursor below start point, the cursor move base on start point position not the current blinking cursor position

disable the 2 keybindings is the expected behavior.

vscode 1.28.2
tabsanity 0.0.11

When a long line wraps around in VS editor cursor won't move past it. It'll get stuck there.

Could you publish a build in the VS2015 RC extension gallery?

I've noticed a couple behaviors that don't quite match what would happen if I were using tabs instead of spaces-pretending-to-be-tabs. Are these intended? (Assume the little squares are spaces and tabs are 4 spaces.)

1. "Tabs" inside of code aren't always treated as such with respect to arrow keys. Adding or removing certain characters, like commas and parenthesis seems to change this behavior per-line. With the CaretIsWithinCodeRange code in ArrowKeyFilter, it looks like you're trying to treat any space with code on either side of it as a space?

static some_struct const my_table_of_stuff[] =
{ +- Definitely a tab. Arrows step through 4 spaces at a time.
  v /*  field_1,    field_2,    field_3 */
▪▪▪▪{   0,          1,          2       },
    {▪▪▪3,      ▪▪▪▪4,          5       }
};    ^          ^
      |          +- Probably a tab.
      +- Maybe a tab?

1. Groups of spaces smaller than a tab are still treated like tabs:

▪▪▪▪abc /* Arrows step through the "tab" as expected. */
▪▪▪abc  /* Not a full "tab", but arrows still skip through it. The right boundary doesn't
           fall on a tab stop, so you can't make this happen with tabs. */
a▪▪▪bc  /* Should arrows skip through this? This can be done with tabs. */
a▪▪     /* Arrows skip through the two spaces as if it were a tab.
           Neither side of this lands on tab stop, so treating it like a tab feels weird. */ 

To really make groups of spaces act like tabs, it seems to me that the following rules for when a group of spaces should be treated as a tab should work:

1. A group of spaces is a full tab wide and both ends lands on a tab stop (either end could be checked, since if one lands on a tab stop, the other necessarily will), OR
2. A group of spaces is smaller than one tab wide, >= 2 spaces wide, and its right end lands on a tab stop.

Hello.

The latest release (1.0.2) is not working in VS 2017 for me, nothing is reported, it just doesn't do its job anymore. After I cloned repo and opened it I managed to compile it by myself and after installing it from VSIX package manually it works again. But it required a changes to many referenced Microsoft.VisualStudio.* assemblies: I turned off "Specific Version" flag or else it cannot find and build package. So, probably this change is also required to support both VS 2017 and VS 2019 versions (if it's planned), or else on VS 2017 it references more new assemblies and cannot work?

Unless you read any of the issues where you've noted it, there's no indication on the readme page that this extension is no longer actively maintained.

Adding a note to readme.md could achieve two things:

• developers can now make an informed decision on whether to install the extension
• you may get someone who puts their hand up to maintain the code

HTH

You can still click and have the cursor land in the middle of an indent. Would be nice if it also landed on the closest valid space instead.

VS 15 will be coming out soon, and it would be nice to have this extension available.

As noted in #6

Replacing virtual spaces with real ones causes some backspace operations
to take two undos. This could probably be improved.

When the "virtual spaces" setting is enabled, TabSanity should not change the caret position when it is already after the last character in the current line. Currently TabSanity and virtual spaces cannot be used at the same time.

Hello, I was very happy to find your extension but so sad when I tried to use it in VS 2013.
I simply can't, because it requires the 2015 version.
I tried to build it from your sources and the 2013 sln file. I even installed the 2013 SDK but I can'tg manage to build it.
Could you please compile a version of the 2013 variation?

I like the idea of this extension, and it seems to work on lines that contain spaces.

If other text precedes spaces, then it has problems - a backspace only goes back a single space.

I am using Visual Studio 2015.

When pressing backspace on a new line which Visual Studio has auto-indented, the entire newline is removed and the cursor jumps forward to the beginning of the next line. If you press delete under the same circumstances, the cursor jumps to the start of the line.

For example, given the following Python code and with the cursor located at the | character:

class Foo:
    def __init__(self):
        self.var1 = 1|
        self.var2 = 2

Press Enter once to create a new line:

class Foo:
    def __init__(self):
        self.var1 = 1
        |
        self.var2 = 2

Now press backspace once. Instead of deleting a single tab, you get this:

class Foo:
    def __init__(self):
        self.var1 = 1
|       self.var2 = 2

...instead of this:

class Foo:
    def __init__(self):
        self.var1 = 1
    |
        self.var2 = 2

If you repeat the first two steps but press Delete instead of Backspace, you get this:

class Foo:
    def __init__(self):
        self.var1 = 1
|
        self.var2 = 2

...instead of this:

class Foo:
    def __init__(self):
        self.var1 = 1
        |       self.var2 = 2

This occurs regardless of whether the indentation settings for the current language are set to tabs or spaces, and it happens for other languages such as C as well. If you change anything on the new line before pressing backspace or delete, everything works as expected. When Visual Studio auto-indents a new line, it doesn't seem to actually insert the tabs/spaces to indent the line until you start typing on the line, which is probably messing with your code in some way.

In the immediate window and powershell window (I presume others) when I press the up arrow my cursor moves up a line rather than cycle through the previous input. This is very inconvenient.

In some cases in VS 2017 after pressing enter it ignores the indent level and puts the cursor at the start of the line. Was using Resharper, though I'm not sure if that's a necessary component to reproduce.

In Visual Studio 2017 (tested on Professional v15.2 26430.6) TabSanity v1.0.1 overrides the tab size setting as configured in the code editor settings.

Regardless of the original tab size setting, after installing TabSanity, the editor will behave as if tab size was set to 2 spaces. The original setting will, however, still be displayed in Visual Studio's text editor options. It has to be set to some different value in order to be respected again.

For example, my usual setting is a tab size of 4. When tabbing on a new line, the caret jumps to columns 5, 9, 13, and so on. After installing TabSanity and restarting Visual Studio, the caret will jump to columns 3, 5, 7, etc., even if the tab size setting in the options dialogue still shows a 4. If I want to restore the setting, I have to set the value to some different number, confirm the options dialogue, then open it again, set my value of 4, and confirm again.

Thank you for this wonderful plugin. I have started using Visual Studio 2019 Preview at work (it seems mostly stable), and this is the plugin that I miss the most. It would be great to see this updated to support VS2019 when possible.

Hi, I am really sad you don't support the project any more, it is one of my favorite extensions and the only reason I can work fine with spaces for indentation (instead of tabs).

In case the extension is still compatible with VS2022, it would be really nice if you publish an update to the marketplace.

Thanks for the awesome work!