I love the old school editors because they enable users to absolutely fly through their code, editing almost as fast as they can think.
However, they suck balls at awareness of their environment, lacking robust implementations of features like Intellisense (pre-emptive strike: no, there really isn't an intellisense implementation in emacs that is trivial to install and doesn't suck) and common refactorings (pre-emptive strike #2: "global search and replace" does not a refactoring tool make). (i.e. It would be nice to be able to use nothing but vim to develop in .Net, but at the moment it is an ill-conceived undertaking at best).
I love Visual Studio/Eclipse/XCode because they are so integrated with their environments that I almost never need to look up API documentation, and can refactor fearlessly.
However, they suck balls at basic text manipulation and macros (relative to vi/emacs), are not available on all platforms (with exception of Eclipse), are likely either going to change nontrivially or perhaps just not be around in the next 10-20 years, and most importantly, are unable to run tetris.
Will we ever see the day when emacs or vi will be able to be as tightly integrated with .Net, Java and Objective-C projects as Visual Studio, Eclipse and XCode?
If not, is it because of proprietary concerns? (i.e. would require emacs to ship with a copy of the .Net framework)? Or is it just because at the moment our team doesn't have the manpower?
Why not load a Vi / Emacs emulator into Visual Studio / Eclipse and get the best of both worlds?
There are free versions of both for Visual Studio 2010 and above.
VsVim - Free
Emacs Emulator - Free
ViEmu - License Fee, works prior to VS 2010
Eclipse has some as well.
Vrapper
See eclim which provides Eclipse features for Emacs/Vim, so you can work in your favorite editor while having intelligent completion and other features supported by an Eclipse backend.
If we don't have the manpower to implement these features natively then the best we can do is to utilize the features implemented by others.
I think a significant part of the reason is technical and is due to Elisp: Elisp is very slow, and it lacks libraries. A good IDE requires a good parser, various auxiliary data-structures, and needs to be fast (e.g. parsing many files).
Related
We developers often working on some different projects and often we need to switch IDE tools, like Eclipse, JDeveloper, IntelliJ. But one problem is there are so many keyboard shortcuts to remember...
But that's quite a burden to memorize these. So I want to minimize the memory burden and hope to use the same shortcuts everywhere.
I searched online and found there was an old project on Mac OS for this proposal (https://github.com/fe9lix/CodingKeys).
"What problem does it solve?
Nowadays, developers often work in several different development environments and text editors. For example, you may need Eclipse for regular Java development, Android Studio for Android development, Xcode for iOS development, Visual Studio for C#, Sublime Text for web development, etc.. Every tool, however, has different keyboard shortcuts. Since it is hard to remember all shortcuts, there's a constant loss of productivity when switching tools. If you don't want to edit all shortcut sets in every tool, you can instead use CodingKeys as an "abstraction layer".
CodingKeys lets you define unified shortcuts, which are dynamically re-mapped to existing shortcuts of other applications when you switch tools. All mappings can be conveniently edited in a single configuration file. The config file also gives you a nice overview of all shortcuts and grows as you add new apps to your coding toolbox."
This is exactly what I need. However, I didn't find anything like this on Windows or Linux.
So firstly I want to know how these shortcuts invented at the very beginning?
Are they just come up from someone's mind and then all followers adopted that. Or have they collected some stats and found what are the most frequently used keys?
Can we do some stats and build the best shortcuts for all IDEs?
So is it possible to unite all keyboard shortcuts across IDEs? Or how to reach there (if not today maybe we can reach there in future)?
Alternatives of CodingKeys for Windows and Linux
For Windows, you can try AutoHotkey and its remapping keys feature. Unlike some other solutions, it lets you remap the keys per application - by using the IfWinActive directive.
For Linux, there are probably some alternatives or ports, see https://unix.stackexchange.com/questions/165124/autohotkey-equivalent.
How the shortcuts were invented?
Yes, I would also like to know. I'm afraid in some cases though, there was no deep investigation before introducing some shortcuts.
Another reason for editors having some unfortunate default shortcuts (both Eclipse and IDEA users will surely find some) may be that authors just don't want to change them, because they want to retain backwards compatibility for users. Even though in the long run it would possibly hurt less to change them to some common ones, which brings us to the last topic...
Can we do some stats and build the best shortcuts for all IDEs?
I was just thinking about this idea before getting to this question. It would be great to have some kind of initiative that would do the research and that would propose some "unified set of basic IDE shortcuts". It would consider not just IDEs, but text editors generally, while web browsers play an important role nowadays as well (with their navigation or debugging shortcuts).
It looks like there is no initiative like that so far. I can see 3 main reasons for that:
It definitely isn't easy to do the research and to agree on some common shortcuts that would satisfy all.
Unless using some workarounds like AutoHotkeys, it would require active cooperation of all the major IDEs authors in order to efficiently improve the current state of things. I'm not sure how realistic it is.
Although far from perfect (which is given by-design), there exist those predefined keymaps for various IDEs that can somewhat mitigate this problem.
A lot of IDEs and Editors today have one of their standard keymaps, but they also come along with keymaps from an other IDEs and editors as well.
For example, if you are using Visual Studio Code, they have their standard keybindings, but if you come from an other editor, you can search extensions for other keymaps as well:
Anyway, any editor or IDE you use, just search their plugins or extensions for keymaps and you can install keymap you are familiar with.
My thought on unified keymap (one that you can always use), would be Vim keymap. If you learn that, you are on a good path in any editor.
I know TextWrangler shows the option, but it doesn't actually do anything. So what I want is autocomplete, either with a key combination, or while I type.
Syntax coloring/highlighting is a requirement as well, though I know Xcode and TextWrangler have that.
You might want to use Lua Development Tools for this purpose. It has syntax coloring, plus it is doing smart autocomplete, depending on what your actual context is (required modules, ...)
It is an Eclipse Technology project, and it is Open Source! (EPL license).
Project web page - http://www.eclipse.org/koneki/ldt
Installation via Eclipse Marketplace - http://marketplace.eclipse.org/content/lua-development-tools-koneki
I don't know if you have seen this page, but it seems a good place to start:
http://lua-users.org/wiki/LuaEditorSupport
If I search for "completion" I get:
Decoda (Win)
LuaEdit (Win)
DForD (Win)
NsEditor (Win)
Visual Studio + LuaLite
Eclipse + LuaEclipse or LunarEclipse (java)
I personally use Vim + SuperTab (which only auto-fills with things that you have previously written).
There's a nice plugin for IntelliJ IDEA for Lua. IntelliJ IDEA is really nice, though kind of biggish.
Aside of that there is also TextAdept which is a lot smaller, and 100% configurable in Lua.
And probably a bunch of others.
If you want full (semantic) autocompletion, you should try lua-inspect (source code), which can be installed in the SciTE editor, and also into ViM using vim-lua-inspect.
It uses Metalua to fully parse the source code into AST and then performs code analysis. Apart from simple keyword-based syntax highlighters, it can:
differentiate between local/global variables, parameters and unused variables
jump to the definition of a variable/function
autocomplete table members
correctly rename variables/functions (not only definitions but also uses)
Even though it is not yet stable, and tends to hang on large scripts, it is very usable for standard Lua programs, mainly for it's intelligent autocompletion and renaming.
I was always wondering why it is a big deal having version control support inside an IDE.
I always preferred to use a command-line/standalone version of the version control of choice and never found IDE integration helpful.
I know it can be helpful sometimes, for example to automatically keep track of renames, but I was bitten by version control plugins a couple of times (especially the ClearCase Eclipse plugin) that I'm now finding it counter productive compared to the command-line version, where I have better control.
What is your opinion?
Integrated Source Control also helps to only keep the important files under Source control. For example, when I add a new File in Visual Studio, the Plugin (visualSVN) will allow me to add it easily without me having to remember to go outside of my IDE and run the command to add it to the repository. On the other hand, it will automatically ignore temporary files, like the obj/ and bin/ Folders.
Essentially: Integrated Version Control that actually works is a great way to keep the repository clean and complete.
I like how some IDE's implement this. Ankh-SVN for Visual Studio is not that great and is a bit buggy, however Subeclipse I find to work exceedingly well when I'm using Eclipse.
I think it really depends on the IDE you're using and the quality of that plug-in. It's going to work well for some setups and terrible for others.
That's why I like Subversion with Tortoise SVN so much. I can choose to use the IDE integration when and where it makes sense, otherwise, just like you said, I can simply use the command line or in my case, the windows explorer based client!
Integration of the IDE with version control and, in particular, software change management (SCM) helps bringing together the philosophies of the IDE and the source control system.
One example is temporary files and binaries, that should not be checked-in and, e.g. in Visual Studio, end up within the source directory if you're not carefully creating new project and solution templates with a non-default directory configuration.
Another could be tracking of work items and complex bug fixes.
Also it saves some ceremony and context-switching when editing files.
Advanced integrations may also allow to push the change management system's concept of "configuration" ("branch", "tag", "view") into the IDE.
ClearCase integration, however, is clearly not "advanced".
A lot of it is simply the preference and comfort level of the user. Some folks are comfortable with the command line. Some prefer a GUI.
I wouldn't make generalized assumptions that all version control within the IDE is bad or buggy based on experiences with a particular plugin which had issues.
Why even have an IDE? Why not just do everything with a command line? ;)
The answer is that having it integrated with the IDE is "better".
My #1 reason:
You can visually see if a file is checked out or not, and if you need to edit a file, you can take the action right there where you are working.
There are more, but that is the big one.
It's depend on your IDE and the way you work with VCS.
Me and my team using VSS plugin-ins inside Delphi IDE, it gives a lot of flexibable feature when working together for example, All our forms are check-in when you start to write a letter or move components it asked if you want to check-out the code file or form.
also when some one change any code in other forms, it pop up and telling you it's already update by someone else and asking you to update current files in your H.D.
and you just get everything while you are in the IDE, you don't need to move to other external file, or command prompt to do a simple task.
I find most people who like to deal with command prompt working mostly in code without GUI IDE or may I be wrong.
Nearly all of my subversion needs can be handled by the IDE interface. It's a lot faster to do 2 quick clicks than pop up a command line, cd to the right place, issue the command, etc.
Command line has it's place, but with the current crop of IDEs, that place continues to shrink.
I have battle scars from using a buggy implementation of an IDE/VCS integration. In all honesty, if it was not buggy it would have been great. As long as there are great tools like TortoiseSVN, I don't see a need for IDE/VCS integration. I'd rather have more tools that do their job well than a few buggy tools.
Version control support in an IDE generally gives you a better view. The IDE actually knows what type of file you are looking at when doing a diff, which means it can do context highlighting and help you do merges more effectively.
I also think it saves setup time. In stead of installing all kinds of tools, a developer can download the IDE, do a checkout an be on it's way. If every developer on a project uses the same IDE, they can help eachother.
"Counterproductive" is a large word. If you have serious CVS/SVN problems maybe once a month, it's still way to few to have complicated clients installed on all your dev machines.
I have both systems where there is an integrated IDE (Microsoft FrontPage against an IIS Development Web site with Visual Source Safe on all of the web content) and where there is not (java command-line development, Visual Studio Express Editions). An intermediate case that I use is jEdit 4.x with VSS integration via plug-in.
I think the integrated case is valuable for the reason it always is -- you don't have to leave your application to interact with source-control functions and you don't have to worry about remembering to add new files and to check out files before editing them. The ability to have a smooth work process and to minimize the risk of oversights is powerful, as far as I am concerned. Even when the IDE-plugin integration is less than perfect (the jEdit 4.x case), I still prefer it over not having it.
I also agree that having explorer integration on Windows, the case for Tortoise SVN, is also a great capability, even when IDE integration is available. This allows convenient operation without having to launch the IDE while also being able to launch from the explorer window into the IDE (depending on file type) or editor or make or whatever while operating in Windows Explorer.
And yes, the command-line interfaces remain valuable, especially for scripting of recuring-operation patterns.
I operate in many contexts. Having low barriers and fluidity of operation in all of them is to be prized.
I'm not sure I understand the question. IDEs by definition are integrated, meaning that they're supposed to help you avoid the need to get out of the environment for anything project-related. Version control obviously fits the bill.
If you're looking for more practical reasons, one is that IDEs can offer you awareness by the nature of their graphical presentation. Eclipse, for example, will present files and directories that have changed. With additional plugins or suites, you can ever get real-time awareness as soon as another user is editing the same file, helping you predict a merge conflict before it occurs. I'm not familiar with a commandline based mechanism.
I use intellij integrated with cvs on a regular basis and by far the best feature of the integration of version control inside the IDE is line-by-line indications of what is added, edited, or deleted along with easy access (mouse hover/tool tip) to the pre-edit changes.
This is all within the source code in a non-obtrusive way.
For the nuts and bolts of version control (checkin/checkout/update/etc) I sometimes use the IDE and sometimes use the command line.
The number 1 reason for an SCM integrated with the IDE is that it makes it more effortless to use it and eliminates the need to REMEMBER to check things out. Through experience I have seen that steps that developers construe as extraneous, which often encompases anything other than writing code, don't get done. Making them do extra steps increases the odds that developers won't bother with it and will work around the source control system
I am looking into designing new features for Eclipse-based programming tools, from the requirements/ideas perspective. To really do this quickly, I would like to sketch UI elements without having to code things -- my concern is with the concepts and ideas right now, not the possible later realization. Are there any such graphical sketching tools for Eclipse?
(on a side note, I should also note that I find Eclipse a better idea every day, in the way that you can combine partial systems from very many different sources into a single environment. It really is the future of IDEs, especially for embedded systems. It used to pretty horrible pre-Eclipse-3.0, but now it does seem to work)
WireframeSketcher is a tool that helps quickly create wireframes, mockups and prototypes for desktop, web and mobile applications. It comes both as a standalone version and as a plug-in for Eclipse IDEs. It has some distinctive features like storyboards, components, linking and vector PDF export. Among supported IDEs are are Aptana, Flash Builder, Zend Studio and Rational Application Developer.
(source: wireframesketcher.com)
Incidentally, NetBeans is known for having a really good GUI editor (Matisse), but I realize that you weren't asking about NetBeans :)
I've tried the Visual Editor Project before, but in the past it crashed my instance of Eclipse, and I haven't visited it since.
Jigloo is a new one that I'd like to try out soon.
This is really specific to Eclipse: it is the platform of choice for general IDEs today, and I am looking to sketch out extensions to it. The target programming language is more likely to be raw assembler and C than anything else -- OS, driver, system-level debug.
What version control systems have you used to manage projects developed with Visual Studio (2005)? What would you recommend and Why? What limitations have you found with your top rated version control system?
Covered many times
Search for 'Visual Studio Source Control' sorted by Votes
I've used SourceGear's Vault - it integrates nicely with VS as well as with FogBugz.
We really need more information to make good recommendations. For example, ClearCase is amazingly powerful but unless you're in a decent sized development studio it would be immensly wasteful, and likely reduce overall productivity.
For personal work I like SVN, but that's mainly personal taste and being familar with it.
Whatever you do, don't learn Git - after you learn it, you realize how every other SCM is trash and you'll hate every minute you have to use Perforce, SVN, or (God help you) VSS/TFS
I used to use SourceSafe, but have made the switch to Subversion and will never go back.
I use TortoiseSVN with VisualSVN. VisualSVN provides the IDE integration with Visual Studio so it feels much like SourceSafe.
The first big benefit is that it works very well over HTTP so I can work with a distributed team. I host my files with CVSDude.
Secondly, the fact that you don't need to check out a file before editing is a huge benefit, particularly when working with files that sit outside the Visual Studio project.
Thirdly, my source code actually feels safe. Ironically it never did with SourceSafe...