Related
I was wondering whether there is an easy way to synchronize your preferences/settings across VS Code and VS 2019?
You can go to Tools -> Options -> Environement -> Keyboard
Syncing Settings Across VS Code & VS 2022
I think I have a pretty good idea of what you're asking for, and I would say that they don't have what you are thinking to have. Like, if you wonder that since they are both funded by Microsoft dollars, that there maybe some sort of interoperability, but there's not. Many people have have been hoping for some time to see Visual Studio work in harmony with V.S. Code, but I don't think that will ever happen like many people are hoping it will. The reason is, they are fundamentally — at the very core of what they are — very different beasts. While, as I pointed out, they are both developed by Microsoft dollars, and they are both "Development Environments", they are not both "Integrated Environments", and there in lies the difference that makes them worlds apart.
Visual Studio (the IDE) is considered to be an IDE — integrated is the keyword here — because it integrates into the projects that are built using Visual Studio as the Development Environment. Visual Studio Code does not integrate into projects, instead it allows you to structure the project, provide the compiler, debugger, and things like a build system, RTE, REPL, libraries, modules, plugins, the Languages themselves, etc... You are the master of your own environment with V.S. Code, and where developers have much more control over their projects using a non-integrated dev-env, especially one that's non-proprietary, they also have to put in much more work, to produce many of the same programs that Visual Studio can practically generate for you.
So the point here is, that you can't really swap configurations between the two, not for the majority of configured stuff, however; that's not to say that some settings cannot not be swapped. Any configuration that can have the same values applied to it, whether the configuration is in VS Code, or Visual Studio 2022, would not be unique to Visual Studio, and VS Code, and has nothing to do with the fact that they are both backed by Microsoft. In fact, if you have a group of settings, and those settings exist in both environments, and are able to accept all the same values (they can't accept any different values in any env) then that configuration will port to environments far beyond Visual Studio Code & Visual Studio 2022, and will probably be configurable in over 90% of the Development Environments out there. And this is something that software engineers, programmers & web-developers/designers take advantage of already, and it's referred to by its filename...
Dot-Editor-Config or .editorconfig
"Above is the Dot-Editor-Config Project's Logo."
EditorConfig, is a good gig, but it won't configure entire environments. Like most tools, the more you use it, the better you will get at making use of it. It seems to me that it is more useful across IDE's, as IDEs, as I explained above, work similarly (obviously), so they have more settings in common. Editor config basically creates a medium for setting semantics. Since settings found in different Development Environments are often called something different in each environment, what the .editorconfig file does, is it gives a single name for each of the variation of the setting that ports across environments, and gives a single place to configure the setting, allowing you to take one file from IDE to IDE. Like I said though, there is only so much it will configure, and it works better between IDE's than between IDE and Editor, at least IMHO.
Check Editor Config out, and see what you think.
I used to use it mainly to configure formatting across C++ projects, but CLang's CLang-Format Tool has become such a good tool that I did away with it.
This link will take you to the Dot-Editor-Config GitHub Repository, where you can find the .editorconfig extensions for...
VS Code
Visual Studio
JetBrains
Emacs
Vim
...and probably many more.
I did some research, or lack-of I should say, after authoring this. I couldn't find any other options out there. There really isn't a lot in the way to help in porting configurations, except for .editorconfig, and really .editorconfig won't do much between an IDE & Editor than configure formatting styles. You can get that same functionality with Prettier, CLang, ESLint, and many other tools. Editor-config doesn't just configure its-self though, like a formatter does, so I am sure you can find some extras it targets, but It's not so much that I use it. A lot of people do, though.
Dot Editor Config GitHub Repo
Watching this thought as well. I've been working in VSCode for a few years off and on as needed. But the full VS IDE (2022 currently) is both more complicated and more capable, so I'm running both.
Then realized that many of the extensions may (should?) be cross-usable, but still digging through that to determine what 'reality' looks like.
Sensible question though.
I've been programming in python and C for a little less than a year, now. I switched from OSX to Ubuntu about a month ago. I'm learning C++, and most specific (non-beginner, I.E.: an SFML tutorial I'm using) tutorials that I've seen talk as if I use an IDE. I've used Textwrangler (OSX), gedit (Linux), and nano (Both; With built-in syntax highlighting and other extras turned on) for programming, along with the terminal and "make" so far, and I'm perfectly happy with them. I would use emacs, but I really don't like the way it looks. Should I use an IDE for C++? If so, why? Honestly, I'm just scared of being a ctrl-space'ing heathen. Thank you for any responses, and take the previous sentence with a grain of salt.
Short answer: Use an IDE if you feel comfortable with one. Don't use an IDE if you don't feel comfortable with one.
To really answer this question, though, we should probably look what using an IDE gets you. Here's the Visual Studio interface for C++:
(source: msdn.com)
The first thing you notice, of course, is the code windows with the pretty highlights. However, that's not the IDE; that's just the text editor part. The rest of it is what's really important. Visual Studio includes a debugger, a file/project manager, a compiler, support for source control... the list goes on. The first letter of "IDE" is the most important one - integrated. It includes everything you need to develop in one neat package.
However, this has its downsides, too. Maybe you don't like VS's text editor. Then, you have to have two windows open, and use the IDE only for debugging, compiling, and source control, wasting most of the screen space. Maybe, after a while, you start to think maybe GCC optimizes your code better, so you start using that. Eventually, the "integrated" part of IDE goes out of the window, and you're using only a few features of the product. At that point, it might be more productive just to find replacements for everything.
Of course, there are extensions and plugins for some of these things, but the point is: an IDE is generally only useful if you spend all or most of your time in it. If you like the entire or most of the IDE, great. If you don't, then use something else, whether that's another IDE or a bunch of command line tools or something else.
Addendum: I used to use Visual Studio, and then moved to Linux with Vim, gcc, and gdb. I work with SFML a fair amount in personal projects, and I don't feel that an IDE is especially suited to it in any particular way; I do just fine with the command line tools. The tutorials are most likely written that way because most people begin coding with an IDE, and SFML attracts a lot of beginners.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
This may be too opinionated, but what I'm trying to understand why some companies mandate the use of an IDE. In college all I used was vim, although on occasion I used netbeans for use with Java. Netbeans was nice because it did code completion and had some nice templates for configuration of some the stranger services I tried.
Now that my friends are working at big companies, they are telling me that they are required to use eclipse or visual studio, but no one can seem to give a good reason why.
Can someone explain to me why companies force their developers into restricted development environments?
IDE vs Notepad
I've written code in lots of different IDEs and occasionally in notepad. You may totally love notepad, but at some point using notepad is industrial sabatoge, kind of like hiring a gardener who shows up with a spoon instead of a shovel and a thimble instead of a bucket. (But who knows, maybe the most beautiful garden can be made with a spoon and a thimble, but it sure isn't going to be fast)
IDE A vs IDE B
Some IDE's have team and management features. For example, in Visual Studio, there is a screen that finds all the TODO: lines in source code. This allows for a different workflow that may or may not exist in other IDEs. Ditto for source control integration, static code analysis, etc.
IDE old vs IDE new
Big organizations are slow to change. Not really a programming related problem.
Because companies standardize on tools, as well as platforms--if your choice of tools is in conflict with their standards then you can either object, silently use your tool, or use the required tool.
All three are valid; provided your alternative doesn't cause other team-members issues, and provided that you have a valid argument to make (not just whining).
For example: I develop in Visual Studio 2008 as required by work, but use VS2010 whenever possible. Solutions/Projects saved in 2010 can't be opened in 2008 without some manual finagling--so I can't use the tool of my choice because it would cause friction for other developers. We also are required to produce code according to documented standards which are enforced by Resharper and StyleCop--if I switched to a different IDE I would have more difficulty in ensuring the code I produced was up to our standards.
If you're good at using vim and know everything there is to know about it, then there is no reason to switch to an IDE. That said, many IDEs will have lots of useful features that come standard. Maintaining an install of Eclipse is a lot easier than maintaining an install of Vim with plugins X, Y, and Z in order to simulate the same capabilities.
IntelliSense is incredibly useful. I realize that vim has all sorts of auto-completion, but it doesn't give me a list of overloaded methods and argument hints.
Multiple panes to provide class hierarchies/outlines, API reference, console output, etc.. can provide you more information than is available in just multiple text buffers. Yes, I know that you have the quickfix window, but sometimes it's just not enough.
Compile as you type. This doesn't quite work for C++, but is really nice in Java and C#. As soon as I type a line, I'll get feedback on correctness. I'm not arrogant enough as a programmer to assume that I never make syntax errors, or type errors, or forget to have a try/catch, or... (the list goes on)
And the most important of all...
Integrated Debuggers. Double click to set a break point, right click on a variable to set a watch, have a separate pane for changing values on the fly, detailed exception handling all within the same program.
I love vim, and will use it for simple things, or when I want to run a macro, or am stuck with C code. But for more complicated tasks, I'll fire up Eclipse/Visual Studio/Wing.
Sufficiently bad developers are greatly assisted by the adoption of an appropriately-configured IDE. It takes a lot of extra time to help each snowflake through his own custom development environment; if somebody doesn't have the chops to maintain their own dev environment independently, it gets very expensive to support them.
Corporate IT shops are very bad at telling the difference between "sufficiently bad" and "sufficiently good" developers. So they just make everybody do the same thing.
Disclaimer: I use Eclipse and love it.
Theoretically, it would decrease the amount of training needed to get an unexperienced developer to deal with the problems of a particular IDE if all the team uses that one tool.
Anyway, most of the top companies don't force developers to use some specific IDE for now...
I agree with this last way of thinking: You don't need your team to master one particular tool, having team knowledge in many will improve your likelyhood to know better ways to solve a particular roblems.
For me, I use Visual Studio with ReSharper. I cannot be nearly as productive (in .Net) without it. At least, nobody has ever shown me a way to be more productive... Vim, that is great. You can run Vim inside of Visual Studio + R# and get all the niceties that the IDE provides, like code navigation, code completion and refactoring.
Same reason we use a hammer to nail things instead of rocks. It's a better tool.
Now if you are asking why you are forced to use a specific IDE over another, well that's a different topic.
A place that uses .NET will use Visual Studio 99% of the time, at least that's what I've seen. And I haven't found anything out there that is better than Visual Studio for writing .NET applications.
There is much more than code completion into an IDE:
debugging facilities
XML validation
management of servers
automatic imports
syntax checking
graphical modeling
support of popular technologies like Hibernate, TestNG or Spring
integration of source code management
indexing of file names for quick opening
follow "links" in code: implementation, declaration
integration of source code control
searching for classes or methods
code formatting
process monitoring
one click/button debugging/building
method/variable/field/... renaming
etc
Nothing to do with incompetence from the programmers. Anybody would be A LOT less productive using vim for developing a big Java EE application.
How big were you projects at college? A couple of classes in a couple of files? Or rather a couple of hundreds of classes in a couple of hundreds of files?
Today I had the "honor" of looking at a file in a rather large project where the programmer opted to use vi (yes vi, not vim) and a handcrafted commandline compiler call (no make). The file contained on function spanning about 900 lines with a series of if-else-if-else-constructs (because that way you have all your code in one place!!!!!!). Macho-Programmer at his finest.
OK there are very good reasons for enforcing a particular toolset within a production environment:
Companies want to standardize everything so that if an employee leaves they can replace that person with minimal effort.
Commercial IDEs provide a complex enough environment to support a single interface for a variety of development needs and supporting varying levels of code access. For instance the same file-set could be used by the developer, by non-programmers (graphics designers etc.) and document writers.
Combine this with integrated version control and code management without the need of someone learning a particular version control system, all of a sudden IDEs start to look nicer and nicer.
It also streamlines maintenance of build systems in a multi-homed environment.
IDEs are easier to give tutorials to via phone or video, and probably come with those.
etc. etc. and so forth.
The business decision making behind enforcing a standardized environment goes beyond the preference of a single programmer or for that matter perhaps the understanding of the programming team.
Using an IDE helps an employee to work with huge projects with minimal training. Learn a few key combos - and you will comfortably work with multi-thousand-file project in Eclipse, IDE handles most of the work for you under the hood. Just imagine how many years of learning it takes to feel comfortable developing such projects in Vim.
Besides, with an IDE it is easy to support common coding standards across the entire team: just set a couple of options and an IDE will force you to write code in a standardized way.
Plus, IDE gives a few added bonuses like refactoring tools (especially good in Eclipse), integrated debugging (especially good in Visual Studio), intellisense, integrated unit tests, integrated version control system etc.
The advantages and disadvantages of using an IDE also greatly depends on the development platform. Some platforms are geared towards the use of IDEs, others are not. As a rule of thumb, you should use IDE for Java and .Net development (unless you're extremely advanced); you should not use IDE for ruby, python, perl, LISP etc development (unless you're extremely new to these languages and associated frameworks).
Features like these aren't available in vim:
Refactoring
Integrated debuggers
Knowing your code base as an integrated whole (e.g., change a Java class name; have the change reflected in a Spring XML configuration)
Being able to run an app server right inside the IDE so you can deploy and debug your code.
Those are the reasons I choose IntelliJ. I could go back to sticks and bones, but I'd be a lot less productive.
As said before, the question about using an IDE is basicaly productivity. However there is some questions that should be considered by the company when choosing a specific IDE. that includes:
Company culture
Standardize use of tool, making it accessible for all developers. That easies training, reduces costs and improve the speed of learn curve.
Requirements from specific contract. As an example, there are some development packages that are fully supported (i.e. plugins) by some IDE and not by anothers. So, if you are working with the support contract you will want to work with the supported IDE. A concrete example is when you are working with not common OS like VxWorks, where you can work with the Workbench (that truely is an eclipse with lot of specific plugins for eclipse).
Company policy (and also I include the restriction on company budget)
Documentation relating to the IDE
Comunity (A strong one can contribute and develop still further the IDE and help you with your doubts)
Installed Base (no one wants to be the only human to use that IDE on the world)
Support from manufacturers (an IDE about to be discontinued probably will not be a good option)
Requirements from the IDE. (i.e. cross platform or hardware requirements that are incompatible with some machines of the company)
Of course, there is a lot more. However, I think that this short list help you to see that there is some decisions that are not so easy to take, when we are talking about money and some greater companies.
And if you start using your own IDE think what mess will be when another developer start doing maintenance into your code. How do you think will the application be signed at the version manager ? Now think about a company with 30+ developers each using its own IDE (each with its own configuration files, version and all that stuff)...
http://xkcd.com/378/
Real programmers use the best tools available to get the job done. Some companies have licenses for tools but there's nothing saying you can't license/use another IDE and then just have the other IDE open to copy/paste what you've done in your local IDE.
The question is a bit open-ended, perhaps you can make it community wiki...
As you point out, the IDE can be useful, or even a must have, for some operations, like refactoring, or even project exploring: I use Eclipse at my work, on Java projects, and I find very useful to get a list of all occurrences of the usage of a public method or a class in a project. Likely, I appreciate to be able to rename it from where it is defined, and having all these occurrences automatically updated.
The fact I have the JavaDoc displayed when hovering over a name is very nice too. Like autocompletion, jump to a class name, etc.
And, of course, debugging facilities...
Now, usage of Eclipse isn't mandatory in our shop! Some years ago, some people used the Delphi IDE (forgot its name), I tried NetBeans, etc. But I think we de facto standardized on Eclipse, but it was a natural evolution rather than a company policy. And we often just open files in a text editor when we need a quick update...
Hi I mostly do C++, Objective-C programming. And I found Xcode plus an auto completion/macro plugin (Completion Dictionary) quite adequate.
However, all people seem to praise over their pure text editors. I tried Textmate for a bit; liked its simplicity but dislike its files/framework handling.
Am I missing something here? Or, do Vim or Emacs have auto-completion as good as Xcode?
Pull up a chair son, let me speak on this.
Well before the days of Xcode, there was VIM and Emacs. I know it's hard to imagine, but it's true.
Many people got accustomed to VIM/Emacs, and thus continue to use it.
Emacs is extremely customizable, and offers pretty much everything you can imagine (including a built in shrink and the towers of hanoi). You can easily call compilers from Emacs, and create your own extensions as needed.
VIM has incredible regex engine (Emacs does as well) and is very handy because (VI) comes with pretty much every Unix OS, and works fantastically if you don't have arrow keys (yeah yeah, real old school). People are very good with using keys to move around documents, without having to use the mouse.
The same is true with Emacs as well, but for me, I find cursor motion much easier on VIM.
The text editor war is fueled with as much religious zealotry as the Mac vs PC war, and the answer is pick the best that works for you. If you like Xcode, great, continue to use it, however good luck if you're ever forced to work on a PC or Linux machine. Personally, I use Emacs to code, VIM to manipulate text and Firefox to look at lolcats.
I really don't understand why emacs props up when people talk about text editors. In my experience it's more like eclipse (or one of those other platforms/IDEs) than vi because it is an environment, which happens to be good at text editing.
As an IDE emacs features version control, live compilation, spell checking, auto completion, debugging, code browsing and lots more for a wide variety of SDKs. For the rest of your computing needs it's an email/news/web/irc/twitter/xmmp client, calendar, organizer, calculator, terminal emulator, remote editing, speadsheets, games etc. etc. etc.
After Dijkstra: "Emacs is no more about text editing than astronomy is about telescopes"
What you are missing is that Emacs and Vim are actually IDEs.
vi is ubiquitous on UNIX systems, and Emacs almost so. AFAIK, Xcode is on one platform.
Having a powerhouse IDE is a great thing, but everyone should have a smattering of skill to keep them functional on any platform they might be dropped into.
It's all up to your preference.
Some people like to work with lightweight texteditors like (g)vim, emacs, pico, etc.
Others like to work with IDEs like MS Visual Studio, Eclipse, Xcode.
As long as your environment is compatible with the text editing technology, it's all up to you.
By the way, I like working with Eclipse and vim because they are what I used to learn programming ;)
The main reason you seem to think people like Emacs/Vim is for code completion. People like Emacs/Vim cause they are both MADE for editing text. You have control and options available to you that other editors just don't have. Once you get REALLY good at using one of these programs you want these key bindings / commands available everywhere. Macros, regular expressions, moving around by search/word/paragraph/function, interfacing with version control, complicated undo/redo and copy/paste functions and extension options are just a FEW of the things that these editors do really really well.
Code completion is just one of MANY things that can make writing programming easier. Emacs/Vim can handle ALL of them (natively or by exntensions).
No, not really. It's a matter of preference really. I liked working in Visual Studio 6, but nowadays the newer versions are just too bloated. So if I can do something outside VS I usually do it without opening the whole IDE box.
On windows I like notepad2 and gvim. I've customized vim to the point where it suits my needs perfectly, so I don't have to think about what and where.
But, it's good to mention that (you could also figure that out by yourself by reading these kinda posts) a lot of users uses vim/emacs/... 'cause of the heard-its-the-best/cool-factor/actual-usability. So if it doesn't suit you, don't use it. Nobody's gonna look you the wrong way cause of that.
For me most the two most important features are:
Emacs key bindings, as that is what my fingers are compatible to.
Open-source, for the freedom it provides. Being tied to one platform is anathema.
These days I mostly use Eclipse for programming (set to Emacs keybindings) and FSF Emacs for reading mail and some occasional LaTeX.
I personally love emacs. I've used vim and a handful of IDEs. Vim and emacs both have great communities where people are willing to code up features for just about any language. I don't know of any IDEs that, say, support Haskell. It all depends on what's important to you. Both have extension languages, though IMO, emacs lisp is the better of the two. The ability to ignore the mouse is the main thing I like as well. So many IDEs also feature emacs and vim compatibilty modes or extensions. They both have a large time investment, but both are worth it. Sooner or later, you will choose which suits you, vim/emacs/IDE, and then stick to improving your skills with it.
When you are using Emacs, you can install Cedet or Autocomplete package to use name completion for some languages (C++ is pretty good, while Obj-C is still not supported), in addition to rich editor functionality
emacs is powerful. I use emacs with vimpluse.el so that I can use the vim key bindings with all the emacs features.
I use Vim mostly for the input model. Once you have become proficient in the input model, going back to an editor where you are forced to use a mouse feels clumsy and ultimately (at least to me) irritating. It is a lot more efficient to type "ci'" to alter all the text between two single quotes, then taking your hands off of the home row, finding and selecting the text with the mouse and finally hitting 'delete'.
I have only used Emacs briefly and while I prefer Vim, I am jealous of some of its features. But I ultimately went with Vim because I find the chord-input model that Emacs uses to put unnecessary strain on my fingers.
I have Xcode and TextMate and I don't use them although I know they can be very powerful. Instead I use Vim (or MacVim if you prefer). Why ?
Because it's light, fast, addictive, powerful, customizable...
I could go on like this for a long time but the most important thing is that I can do all I want with Vim.
Whatever the editor you use, the best editor is the one you master (almost) perfectly.
I don't use vi to do my coding; however, I do, when available, use vi emulation in my editors. When I am doing Java coding in IntelliJ I use the IdeaVIM plugin which gives me vi support in IntelliJ's editor. This means I almost never have to take my fingers off of home row. I navigate with the keyboard (h,j,k,l), cut/paste with yy, dd, etc. And of course when I do need the power of a full feature GUI editor vi emulation doesn't keep me from using those features.
It drives me nuts that XCode doesn't have vi emulation in its editor. Seems like functionality that any decent IDE should have.
TextMate just feels lighter to me. Off the top of my head:
It has great support for jumping between files and methods within files. Think Quicksilver for files/methods. With a file open for editing, hit command-shift-t to bring up a floating panel listing all the methods in the file. Start typing and the list filters itself down. Select the method you want and hit return to jump to it. Xcode has something like this but the sting matching is more literal.
Lots of built in text expansion. Type a trigger and hit tab to have it expanded. For example, on a new line typing m and then hitting tab creates a method for you. The tab key then intelligently jumps to the various parts of the inserted text so that you can edit them in place. These are such a huge timesaver it's ridiculous.
Nice plugin support for Subversion and Git. Probably other VCSs too.
Completions (like Xcode) and history. TextMate allows you to tab-complete basically any text that exists in the file. So once you type a variable name or method call once, you can use tab to auto-complete it anywhere in that same file.
Smart past board with history, nice built in diffs, theme support, good keyboard support, find in files and across projects (with RegEx) and probably more that I'm forgetting.
Anyway, that's enough from me.
Personally, I love TextMate, because it's actually a really lightweight solution. Granted, I have not used Vim or Emacs in depth (I like my GUIs)...although I do thoroughly enjoy the Control-based cursor navigation (Control-A is beginning of line, Control-E is end of line, Control-F and Control-B are forward and backward, etc). So between Xcode and TextMate, I use Xcode for most of my serious development, but if I just need to quickly edit a source file I can be up and coding before Xcode even finishes launching (it helps that TextMate can remember which files were previously opened and restore them). So for some lightweight text editing, TextMate is my choice.
Above that, TextMate's plug-in support is amazing; it provides full support (syntax coloring, building & running, etc.) for so many different things (shell scripts, CSS, SQL, LaTeX, and much more) that Xcode doesn't provide. When I need to brush up a quick program in Java or tweak a webpage, it's a lot easier then using Vim and then building from the Terminal.
My only complaint with TextMate is that the console is read-only, so I can't build anything interactive. That, and the fact that it doesn't seem to support C99 keywords (for loops and booleans) in a plain-C file.
I am a long time vim user, and find that I really like Komodo edit with the Vim emulation turned on. Thus, I get all of convenience of the vim key bindings (to which I have become so accustomed that a recent MS Word document that I recently produced had no less than three ":w"s in it) plus the well implemented code completion for C++, Python, javascript, etc.
I don't use XCode because I don't develop OS X specific applications very much and so the benefit of the OS X framework integration isn't large enough to outweigh the cost of not having vim key bindings and the "do it our way or not at all" approach that Apple takes toward development.
Xcode is more of an IDE, whereas emacs and vi are for pure text (though they have massive extensions to them). This is preferable if you're on an older system or over an SSH. In addition, they're pretty much on every UNIX based computer, whereas XCode is proprietary Apple software.
You might have a look at my essay on the subject Why Emacs?. While it's more or less Emacs-centric some of the points made in it would apply to vim and TextMate as well.
I tried vim a long time ago and for one reason or another "I didn't get it". Then after trying other editors over the years I reached a point where no editor seemed to do what I wanted it to do. After voicing my frustration to a friend he recommended that I try vim....and I am so glad that I took another look because it was the answer to a question that I didn't know how to ask! I have used Vim/MacVim ever since...
here my configuration:
https://github.com/RandyMcMillan/QuickVim
I use Xcode as well because it is nice to have code completion.
XVim is good for people that want a modal/vim feel in the Xcode editor:
https://github.com/JugglerShu/XVim
But when it comes to my day to day editing Vim wins every time. That is why I have the QuickVim repo is so that I can quickly reproduce my environment anytime/anywhere.
I have a list of licenses for editors like TextMate, etc..but it is likely that I won't ever use them since I can use vim for free and customize it to my exact specifications.
Heavy Vim user here. I generally find the text manipulation capability of Vi/Vim far superior than traditional editors which lack things like:
visual mode: e.g. prefixing 5 lines with comment //
macros: e.g. surround 3rd to 5th words in a line with quotation marks, repeat for 100 lines
multiple registers: think 36 registers to copy and paste
delete{motion}: e.g. delete from cursor up to the next occurrence of 'initWithFrame'
These are just a few examples that Vim has XCode text editing beat hands down
For Objective-C. I tend to install a Vim plugin on the IDE to get the best of both worlds - native build / UI components support.
Incidentally. Emac keyboard bindings (e.g. CTRL-A to go to top of line) are supported in a lot of native (Coacoa) text fields on Mac. Including the one you're using for typing answers on stackoverflow :D
XVim works with XCode. IdeaVim for AppCode
I've seen several responses to questions asking for IDEs where text editors were suggested and vice-versa. That makes me think that people treat them as the same thing, where I draw clear distinctions.
How do you define "text editor" and "IDE"?
Do you see a difference between the two tools?
Note that I accepted an answer which I think best addressed the concepts of "text editor" and "IDE". However, it's just my personal opinion of what best addresses the question and I will continue to check in on this question from time to time to see if there's a better answer and I will accept that one.
The confusion arises from the fact that a text editor is a core component of every IDE. But, an IDE has much more than just a text editor; it also has interfaces to compilers, debuggers, profilers, reference material, and more.
Many text editors have plugins or other flexible extension mechanisms, often including the ability to "wrap" external tools like those I mentioned above. The key difference, IMHO, is the "I" in IDE - integrated. An IDE is (again, IMHO) something that's purposefully designed to support a specific set of tools, one of which is a text editor.
I use both and I suggest you do too. Sometimes an IDE can make development faster - like code completion and refactoring support. Fast find of files and symbols, functions, classes in project not to mention project management features. Sometimes they'll manage the build for you. Maybe it has a built in debugger (a good built in debugger is worth gold). How about code snippets and file templates. Sometimes an IDE will help you build GUI interfaces and data stores. I've seen ones that help you build regexps and run SQL queries.
These (IMO) are all sugar. I also use a plain text editor (although I really appreciate code syntax coloring nowadays) and roll most of that other stuff myself. Some of the newer text editors are creeping into IDE territory (e.g. TextMate) since they are extensible enough to allow for most of the above paragraphs niceties.
In 90% of the cases I use what I am given or what the majority of the teams uses (I am a contractor). This reduces the build conflicts that can arise if you decide to go it on your own. By learning to use IDE's, text editors and everything in between you will stay flexible and able to cope with whatever is thrown at you.
I do, but it's more in the way you use them than a difference in the software itself. Some software is used as an IDE by some, but a mere text editor by others. Some software can only be a text editor, some is difficult to use as only a text editor, and some can be easily used as both.
I would say that such stalwarts as Vi(m) and Emacs are used by some as text editors and some as IDEs. Things like eclipse, visual studio, etc only really make sense as IDEs and things like notepad can hardly be anything but a text editor.
I would say if you stay in your text editor to do other things - compile, debug, etc - then you're using it more like an IDE. Quite where I'd draw the line, I'm not sure.
The obvious difference is the "I" from the IDE. IDE's are an integrated platform that allows not only editing, but debugging, file management for your project, and usually cool features like syntax highlighting and code completion. oh yeah, and integration of tools and compilers, as well as source control.
To me, a text editor is light weight tool used to edit text based documents. There is no mark up or formatting of the text other than defining the "system" font for the editor. Useful tools can still be part of a text editor, like a folder tree, syntax highlighting, even cmd line execution of compilers. In the end though, all it does it allow you edit the text in a document. It will not display it to you in a different way. ie: it will not show you a grid when viewing an XML document
An IDE is much more robust and is generally specific to a language or framework.
you know, before i started writing this answer, i had a clear line between a text editor and an IDE. But now, i'm thinking they are one in the same. I mean really and IDE like VS is just a glorified text editor. And a text editor like Textpad is an IDE with a much smaller budget for development of features.
I guess the real answer is, an IDE is backed by a large company or group expanding it's features in many different directions. But a text editor is built by a small group of people, with just enough features to get by.
If you look at Kate, the text editor and Kdevelop, the IDE the main difference is that Kdevelop supports project management (CVS/Subversion) and build scripts, whereas Kate does not.
Personally where I think the 'line' is drawn between IDE's and Text Editors is knowledge of the end program, rather than just knowledge of it's source code.
As examples:
Can it compile your code into a binary? It's an IDE
Does it have an integrated debugger? It's an IDE
In order to have an integrated debugger it needs to know about either the binary compiled program, or in the case of scripting languages, the in-memory interpretation of the program as it runs.
Note: Things like intellisense don't rely on your code being compiled into anything, so I wouldn't say that intellisense implies IDE
Note 2: Many text editors like textmate have plugin systems which can be extended to build your project. This does not make them an IDE, as they are simply shelling out to a plugin, they don't have any knowledge about the building itself.