When I'm working at someone else's code, sometimes it happens that I've found something useful that I likely will need to return later to.
Except the chances are that I forget where I've found that part and then I need to find it again. Nowadays I'm mostly using breakpoints to set these down, But I don't need these breakpoints for debugging, so I don't think that's the most efficient method. Something that could work for me is a sort of marker that functions marking down like a breakpoint, but does not affect debugging.
Will all these ways of breakpoints, search functions, finding references, and adding a Watches. I do have a feeling that such feature is present in Visual Studio already. But I havn't found it yet, I've already tried searching it up, but it looks like it hasn't asked before.
So, is there a feature in Visual Studio that let you mark down code like breakpoints, but just for the purpose of marking down?
There is more than one way to do so.
If I finde something interesting I mark it with a Bookmark.
Just STRG + K, STRK + K and it will be places on your current row.
With these Buttons you can switch to your bookmarks or delete them all. They are client based.
Visual Studio also gives you a "To Do List" Function. This one is triggered by comments in the code and seen for everyone with the right options used.
See here how it works in detail.
Yes, it's called a bookmark. This little toolbar is for bookmarks:
You can also use the Edit, Bookmarks... menu item and the View, Other Windows, Bookmark Window which among other things lets you see all of them and give them names.
One caveat: the bookmark binds to the line number, and doesn't move if you add or remove lines. So if you bookmark the first line of a function, then make changes above that, the bookmark won't be on the first line of a function any more.
Update: This complaint relates to an old version of fish -- see the below comment from one of the fish developers describing the awesome improvements to the fish pager behavior which nullified this complaint.
The fish shell is pretty cool -- however I hate one of the features of tab-completion.
I frequently -- almost like a nervous tick -- will hit {tab}{tab} while typing a path when changing directories. This lets me use {tab} to examine the contents of some path while simultaneously solving however much of the path disambiguation problem my current keystrokes allow to be solved. This gives a great way to quickly discover the quickest key combination to get to a certain place in the filesystem without a lot of thought or necessarily having to know the contents of the various directories in advance.
Fish on the other hand interprets {tab} {tab} in what I consider to be an incredibly annoying way. The first {tab} lists the possible completions, that's great. The next tab is pressed fish selects the first completion in the list and replaces the last portion of the path currently entered on the line with the full first completion -- regardless of disambiguation status. Subsequent tabs cycle through the next possibilities. Its similar to what the windows command shell does.
This is far worse than the normal bash behavior ...
Consider a deeply nested directory structure foo/bar/baz/a/b/c/
Where some of foo, bar, baz, are empty directories. Bash tab completion lets me type cd foo/{tab}{tab}{tab}{tab}{tab}{tab} -- without having to think about how many times I'm hitting tab, without having to think through the effects in advance of hitting tab on the current state of my command line entry.
The normal case all these directories won't be empty -- but the above still works to very quickly discover the fewest number of characters I need to enter to make it to some deeply nested path.
With bash behavior:
cd some/unknown/dir/{tab}{tab} guarantees that
(1) I see the contents of the directory dir/
(2) as much of what can unambiguously be expressed from my command so far is completed, but no more.
After hitting the two tabs above I might see contents like this:
abc123
bar123
baz123
bcd123
mnop123
the following actions are possible:
a{TAB}{TAB} (gives me abc123 and if this is a directory lists its contents)
m{tab}{tab} (gives me mnop123 and if its a directory lists its contents)
Suppose I want to get to the path bcd123:
b -- shows me that I was too fast in my typing, with only 3 options now shown I easily conclude I need only hit 'c' to disambiguate to my goal
b{tab}{tab}c{tab}{tab} (gets me the path I want, lists bcd123's contents if its a directory)
fish's model is much worse. b{tab}{tab} would've completed to bar123, and I have to hit tab an unknown number of times to get the value I wanted, furthermore I have no way of getting the entry context back to only the letters that I've actually typed up to this point (other than hitting backspace a whole bunch of times). What if there happen to be a whole bunch of things that start with ba in this directory -- I'm totally screwed is what happens ...
In general fish's model is worse:
it does not allow using tab to complete nested paths -- to do this with fish you need to '/' at the correct time within the command sequence -- which requires mental feedback
much more difficult to discover disambiguation sequences when in large directories
in general requires you to 'be careful' before you hit tab which makes you hit it less often and decreases its utility ...
Somone please tell me there's a way to change fish's behavior here to be more like bash ... fish is cool but this behavior is unusable -- I'll have to go back to bash if there's not a way to change this ...
I commend you for writing up this detailed and thoughtful post, and it deserves an equally detailed and thoughtful response!
The tab completion behavior has been rewritten in fish top-of-tree (not yet released), and is referred to as the "new pager." You can see the design goals and discussion here. I put a note at the bottom of this reply for how to get it.
Shells are personal, and like anything personal, rationalizations and justifications aren't worth anything: you either like it, or you don't, and we may not even be conscious of the factors influencing our feelings. So all I can really say is try it, see how you feel, and (please) report back.
I put up a short little screencast of the new pager on YouTube. Things to notice: 1. the menu is dismissed just by typing more, 2. it "unfurls" progressively (requires a few tabs to become fully visible), never modally takes over your screen even when there's a huge number of completions, and is easily searchable and navigable, and 3. escape will always dismiss it and put your command line back to just what you typed.
Let me go through your concerns individually:
"I have to hit tab an unknown number of times to get the value I wanted". With the new pager, the selected item is highlighted in the menu. This sounds minor, but personally I believe this makes a huge difference: the number of additional times to hit tab becomes known, and since your finger is over tab, it's often easier to just hit it a few more times than to type additional letters. You can also use the arrow keys to navigate.
"I have no way of getting the entry context back to only the letters that I've actually typed up to this point". With the new pager, the escape key does exactly that. It's easy to press since escape is right above tab, where your finger is.
"What if there happen to be a whole bunch of things that start with ba in this directory -- I'm totally screwed is what happens". Neither bash nor old-pager-fish handles large numbers of completions well. fish would drop you into this modal paging environment, while bash breaks your flow with the modal "Display all 1002 possibilities? (y or n)" dialog that forces you to stop what you're doing and hit 'n'.
I think you'll love how the new pager handles this. Initially you get a short menu, that fills a maximum of five lines below your prompt (not above, and not replacing). This menu is non-modal, and is dismissed by typing more or hitting escape. If you hit tab again, the menu grows to show more completions, but is still non-modal. There's never a jarring transition.
"it does not allow using tab to complete nested paths" Sorry, I'm not sure what you mean by this. Both bash and fish append a / when tab completing a directory.
"much more difficult to discover disambiguation sequences when in large directories" With the new pager, you can hit escape, type some more, and then tab again. Or you can search the menu: put the focus in the menu and type something, and it's filtered. See the screencast above.
"in general requires you to 'be careful' before you hit tab which makes you hit it less often and decreases its utility" A very valid point, which the new pager addresses in a few ways. First of all, it uses a notion of progressive disclosure, which means that it takes "work" to output a lot of data. Second, it never "takes over your screen" like the old modal pager. And lastly, you can hit escape to get back to just what you typed, and since the pager appears below the prompt, it won't leave little turds in your scrollback like bash does.
If you're using homebrew, you can install from master via brew install fish --HEAD. There's also nightly builds for Linux. And lastly, feel free to open an issue at https://github.com/fish-shell/fish-shell/issues with any ideas for improvements you have.
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.
This may sound a bit provocative but it actually is a real question. Feel free to edit if you don't like the tone.
Now, as much as I understand vi from my short experience with it like 10 years ago, it's a primitive text editor with one editable line at the bottom of the screen created before the scrollbars were invented, with some crazy shortcuts to overcome this limitation.
Can somebody explain me how one can be more productive with it than with, say normal VS.NET editor? Moreover, why would anybody want to use viEmu which supposedly turns your VS.NET into an ancient vi?
I'm willing to give it a try but I need some motivation to overcome the learning curve.
It honestly sounds like you have never seen someone use Vi who is truly proficient in it. When you normally use Visual Studio you frequently will move your hand over to your mouse, click through options, dialogs, classes, etc.
With ViEmu your hand never leaves the keyboard. You are compiling, switching files, highlighting groups of text, fixing indentation, performing complex motions on your code and running regular expression searches in seconds. For people who are fast typists it allows you to achieve a speed for tasks you would not be able to otherwise.
Many people will counter this by saying things like, "Most of my development time is spent thinking. The extra speed I gain from using tools like these is negligible.".
That is a non-argument in my opinion. It is true, for most large programming tasks you spend far more time planning and thinking then you do actually slinging code. But that doesn't mean that being able to express yourself through your IDE 2x faster doesn't have an impact on your productivity as a programmer.
The viEmu page itself has a pretty good article that might help to answer your question: Why, oh WHY, do those #?#! nutheads use vi?
I've spent the last couple months trying to teach myself to use vim "properly" and now I can hardly stand using other editors because they seem underpowered and clunky. For a random example, imagine you have a line of code that looks like this:
$welcomeMessage = "Welcome to SiteName!"; // shows at the top of homepage
In a normal editor, how would you change the string? You'd probably have to reach over and grab your mouse and carefully select it, or you'd move your cursor inside the first quotation mark, and hold down Shift and the right-arrow until you got to the closing quotation mark.
In vim, with my cursor anywhere in-between the quotes, I type ci" and it erases everything inside the quotation marks and puts me into insert-mode so I can type the new value I want. My hands didn't even have to move from my normal typing position.
There are so many things like this, I think you really have to spend a while using the editor to understand how powerful it is. It's very slow and hard to use at first, that's why a lot of people try it for a short time and think "this is dumb, everything is way harder", but after a while you start thinking in terms of the motions, it all starts to become automatic and it's much, much faster than using a "normal" editor. As I said, I can't go back now.
I've also had trouble understanding why people choose vim as their editor, even though I was using it from time to time, until I've finally "got it". I think most explanations of "why?" fails, because they fail to show couple crucial points. To explain those points, first you need to understand that in vim you are manipulating text primarily being in command mode. Ie by default your key presses are commands, and do not usually insert any text, unless those commands (like append, insert, change) switch to insert mode. This lets you navigate and edit your text easily without ever touching your mouse or moving your hands away from "editing pose".
Now the crucial points are:
Vim commands are divided into nouns, verbs and modifiers.
Editing is performed by combining them.
And this is what gives vim the power. To ilustrate the point, here are some most used commands:
Nouns: word, sentence, block, quotes and braces.
Verbs: cchange, insert, visual, delete
Modifiers: inside, around, till
And to ilustrate how you can mix them:
Want to change a word? cw
Same, but cursor in the middle of the word? caw
Change text inside quotes? ci", also change quotes? ca"
Delete function body? di{
Delete up till first comma? dt,
Delete up till second comma? d2t,
Jump to first comma? t,
Select word? viw
Also notice how all commands nicely translate into natural language:
delete word
change inside {
In vim if you learn a new verb, noun or modifier, you can easily mix and match with what you already know. So basically learning just one thing, you learn how to do a lot of different things.
Another great thing is that vim remembers what commands you have used, and you can repeat the sequence just by pressing .. For this post I've had to surround a lot of letters with <kbd> tag. But I've did that only once, and then just went over each letter and pressed ..
And that's basically the thing you "need to get" to understand the power of vim and become advanced user overnight.
P.S. if you don't like vim because it's console based and want a modern text editor, then I suggest looking into Sublime Text editor, which is a great editor and also supports vim mode.
P.S.2. I also recommend to map Esc key to jj and kk, which makes things a lot easier.
You are wrong about "one editable line at the bottom of the screen." All the text in the window is editable. And it does scroll (all versions) and in the case of gvim, has scrollbars.
Maybe you inadvertently put it in "ex mode". This is easily done and can be confusing.
Another answer got me thinking that watching some skilled editing using vim would be pretty revealing so I dug up this video showing basic and more advance motions while coding. This person could get even a bit efficient using some marks, etc but it gives an idea.
http://www.youtube.com/watch?v=FcpQ7koECgk&feature=related
If you need inspiration or want to see someone who really knows what they are doing with Vim, check out Gary Bernhardt's String Calculator Kata In Python, look at him go! http://vimeo.com/8569257
I think they have a long and acceptable answer for your question on the viEmu hompage:
One other even more powerful example: let's take the 'ce' command, which is composed of 'c' and 'e'. The 'c'hange command deletes the range specified by the next motion command, and also enters insert mode. It's the same as 'd', but with the distinction that it enters insert mode, instead of staying in normal mode. The boon is that the text you type in the next (short) input session is also part of the command. So if you do 'ceHello>', what you do is replace from the cursor to the end of the word by 'Hello', and the '.' command afterwards will work exactly like that: replace up to the end of the word with 'Hello'.
From:
http://www.viemu.com/a-why-vi-vim.html
I have viEmu installed ~half year ago. But I have to say (maybe without strong linux experiences) I've never used it. Too alien, too far, too complex.
So IMHO viEmu it's a great technical&historical challenge but no more for the 95% of the developers.
Basically with Vi (or ViM) you get faster because you don't need to touch the mouse and the key-map is improved (this represent learning curve cost but worth the effort) for do any text manipulation in a very easy way once that the fundamentals are learned.
Top 10 things Vi user need to know about Vim
I have not experience with VS.Net but I guess it has the same features that any other IDE has.
I have found that learning the all the key commands of the editor in my IDE was a sufficient replacement for Vi. Things like renaming, indenting, formatting, moving lines and that kind of stuff.
So I guess the major win would be for someone who already know Vi to be productive without having to learn VS.Net.
But then again, Vi has some truly esoteric but powerful features that probably can't be matched by you standard IDE editor.
I think you really should give Vim a try.
If you quickly tried Vi ten years ago, I may understand you didn't appreciate it. It's not really user-friendly at first sight. Actually its real power is revealed when you start feeling comfortable with the movements and start making it your own with customisation.
Once Vim is familiar to you you may understand why it deserves to be learnt.
I actually use VS only for debugging these days. Coding with vim (real vim, not viemu) is just a better experience.
Now, I am not going to claim that using one over another makes any difference in productivity - after all I spend most of my time trying to figure out how to solve a problem - entering the code is the easy part.