Thread: This had me literally rofling once I got the meaning(s)!

Originally Posted by Yarin

I've been using MC exclusively for a couple months now, and find that it has it's strengths, and weaknesses, when compared to a GUI file manager. Most notably, dragging and dropping random files to random directories _is_ much faster with a mouse than a keyboard; because fancy pattern matching won't help you very much there. While I'm sure my having more exp. with a GUI file manager effects my judgement, most of the time, when casually poking around, the efficiency is about the same.

I don't fancy pattern match, I just select files via the arrow keys and "insert" to select, then F5 or F6 to move/copy. You can do the same thing with the mouse in MC (select with the mouse in X or via gpm); that's faster if they are far apart and you have a big screen, which makes it potentially the exact same thing as a point and click browser -- but pressing an F key afterward is still faster than drag n' drop. How could it not be? It's instantaneous. And you can screw "the drop" or "the drag" up either.

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.

Originally Posted by manasij7479

Well... look no further than external editors... most can be integrated into eclipse instead of the default 'plain' one.
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

I did install vrapper, and that gives you some of the added vim functionality, but not all, eg, it doesn't include whatever plugins and configuration you have for your actual vim, doesn't have the : line, etc. There's another vim plugin that actually embeds vim into eclipse, but I believe you then loose the eclipse interface completely for that window.

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.

Originally Posted by manasij7479

Btw..you could try making an eclipse plugin that suits exactly what you need. It seems that a lot of other people will find it very useful.

Lol -- I think that would take me quite a long time.

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.