“I just want to use my computer in a productive manner, not learn how to use it.” — Elysia
“A year spent in artificial intelligence is enough to make one believe in God.” — Alan Jay Perlis
I'd presume most decent GUI file browsers have hot keys for stuff like that for use by "power users" or whatever. If not, it is just 100% laziness on the part of the developers.
I think learning to use tools like mc (and vim) is hard, like learning to ride a bike is hard. A lot of GUI tools are, comparatively, very easy to pick up because everything is "intuitively obvious". However, they also sometimes -- particularly in the case of the file browser -- remind me of a bike someone welded training wheels onto, then removed all the gears and the front brake. They're great for things you do occasionally and can't be bothered to understand much. Is it "easier" if you've never used such a thing before? Sure. Is it efficient and useful if you have? No. I started using eclipse this week and it has a lot of nifty features, but it does not have a lot of useful editing features (beyond autocompletion). The "editing features" are nearly non-existent. You might as well be using notepad with syntax highlighting. That side of it just plain sucks. To me it seems like a great tool for analyzing and examining code, but for actually editing code it's pathetic.
Last edited by MK27; 01-06-2012 at 08:45 AM.
Do I really need to tell you to rtfm ? (Search "External Editors" here: Help - Eclipse Platform)
If you want to add a new one... make a plugin.Help - Eclipse Platform
What I've settled on is to use gvim and eclipse concurrently, because they both auto-detect when a loaded file has been externally changed and pop up a box, "file x was changed...re-load?" kind of thing. So if I just need to tweak something minor, I use eclipse with vwrapper, but for anything beyond that, I use gvim, then flip over to eclipse for testing. This also means I can have a full screen view while editing but leave all the side things open in eclipse (maybe there is a simple way to toggle that in eclipse too? Should be).
So far, that seems like a best of both worlds to set-up to me, I have no problems flipping back and forth -- the biggest hassle is just clicking "yes, reload". However, it brings to mind a few things:
1) the value of a unix "modular" software approach vs. the monolithic "integrated supertoaster" approach.
2) that most of the time, using an IDE is not significantly different than using a (decent, code oriented) text editor and a terminal shell.
3) that gvim seems more fundamentally useful to me, because while it does not do everything eclipse does, it does the most fundamentally important thing, IMO, coding wise (provide for text editing) much better. This is a consequence of point #1.
Last edited by MK27; 01-06-2012 at 11:39 AM.
And I don't really see a need for it as much as I see a need to encourage support for what I'm doing now (using the two separate tools together). While there's nothing wrong with "plug-ins", I don't think that should be considered synonymous with truly modular software -- individual, stand-alone components that can work as part of a chain.
I don't see why eclipse couldn't be developed to do all the things vim does, or the reverse. But just because something is possible does not make it desirable.
Right now, it seems to me eclipse (and vim) are pretty good about working with material that may also be working with another tool (concurrently or consecutively). I suppose that is somewhat related to the nature of the task. Eg, you want legitimate .cpp files, you don't want a tool that has it's own special file format, including meta-data, on the assumption that this tool is the only tool that will ever be used for this project. Hopefully that can stay that way, although I do see the potential for IDE "project files" to be maintained in such a way that changing the project outside of the IDE creates a screw-up. I'm pessimistically assuming I will run into this problem sooner or later in some form, because I'm pessimistically assuming IDE developers do not explicitly make avoiding such problems a priority.
Which is just bad design IMO, but it is commonplace in software I think because it is sort of a good business model -- by creating and exploiting incompatibility, you get a better shot at a "winner take all" monopoly. Business wise, it is probably better to engineer your product to make the consumer dependent on it rather than engineer it so that the consumer is always left with a choice.
Last edited by MK27; 01-07-2012 at 05:48 AM.