Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Newcomers » Newcomers » Lack of VI Emulation Is a Signifigent Oversite
Lack of VI Emulation Is a Signifigent Oversite [message #262761] Sat, 09 August 2008 01:40 Go to next message
Eclipse UserFriend
Originally posted by: bobarror.soco.agilent.com

Why is there no VI emulation in eclipse? VI is one of the most powerful
editors in the hands of a skilled user. The eclipse editor(CUI) is clumsy
and weak in comparison. Experienced coders don't need welded on training
wheels. I, like many developers, would love to use eclipse, but will
continue to give it a pass until VI functionality is available. I have
been wanting to make it part of my organizations base Linux and HPUX
development platforms (for starters, thinking about RCPs for instrument
control, gets me excited). But after two and a half years of tracking the
eclipse project with no indication of it ever having real editing
available, I have decided to make eclipse not a part of our platforms ( id
est, our platforms will be defined as "not using eclipse"). This is to
prevent the inadvertent lockout of VI. As a developer, I would be spending
most of my time interacting with the editing functions of an IDE then with
any of its other features. No amount of coolness can compensate for the
anemic performance of a systems primary functions. (Okay, so the
appetizers. drinks, desert and setting are absolutely marvelous, the main
course of two steamed hotdogs, kinda sucks.) This makes eclipse CDT ( and
just about every other IDE) pretty much useless, which is a shame because
eclipse is only the second "IDE" that I have played with that I would
consider using ( SlickEdit; the other).

What bothers me though, is the mind set that has yielded a platform that
still lacks, even after many comments and requests, a real editor for real
developers. Its as if quality is secondary to image. How can I trust an
organization that apparently routinely ignores real issues? On top of
this, I have seen too many ignorant comments implying that those who do
not what to abandon a real editor are barbarians that need to be dragged
into the "modern" world. Give me a editor that allows me to do what I can
do in VI ( and without having to take my hands off the keyboard ) and I
will gladly learn it. I've learned so many editors and code input systems
( card punch Fortran in HS!) over the 30 years of my involvement with code
creation, that adding another is trivial. BTW, it is really galling, that
these critics of VI, generally have no clue as to how to use it or what
can be done with it. On top of that, they are the ones who can't learn,
yet they assume that their inability is normal and applies to everyone,
but especially to experienced users. Then they use this characterization
as a specious attach on VI users, implying that they are primitives
holding up progress. I am starting to wonder if this mindset is typical of
the eclipse community. So far, I have seen nothing to indicate otherwise.

The existence of an over priced closed source plugin is NOT a substitute
for something that should NOT have been lacking in the first place. I have
used an eval version of the plugin at home, and its okay, but come on,
trying to continue to make money off of this thing is like eating a meal
and expecting to never be hungry again. To continue this analogy, paying
for this cute plugin just to be able to use eclipse, is the same as going
to a fancy restaurant and having to ordering out for delivery because the
restaurant lacks a kitchen. Personally, I think it is rather silly to
expect to make money off of every piece of code I wrote for the rest of my
life. A developers worth is in what can be developed, not in what HAS been
developed. Besides the silliness of trying to milk 40 hours of work for
years, my organization will not pay for anything ( our Linux/OSS
utilization needs to be kept sub rosa). After all, we have ms' VisualAge
and Java rip offs available and a former ms VP on the board complete with
sycophantic management chain all googley eyed over ms just ready to
mandate OS unity. So the purchase of closed source non/free software for
our non-winduhers systems is absolutely out of the question. Even if ms
did not have most of the world in demonic enthrallment, most Companies
just do not have the resources to manage the licenses of thousands of
silly little pieces of single function apps. It kills one of the
advantages of GPL like licensing.

The following is NOT a brag, but written to indicate that I do know of
which I speak.
For those who are clueless about vi, I have recently finish a major phase
of my project. In this phase, I took our entire 15 year old,
inconsistently structured, ansi C layered with pre-iso C++ on HP-UX 10.20
with aCC codebase weighing in at 1.5 million lines and converted it to a
pedantic ISO C/C++ on HP-UX and Linux with GCC codebase. I did this in
four months because of what can be done with VI. ( To be honest, I would
have been done a week earlier, but one of my big bold multi file edits
went ... um ... poorly. Oh, the price of power).

The fix was ...
%g/^[^"]*"[^" ,]*[^[(, "]\?\( *[[(][^])" ]*\| *[^-+/*"][^" ]*\)*\(
*[-+/*]\|[[(,]\) *[^"]*".*$/s/ \([-+/*]\) \|\([[(]\) /\1\2/g
%s/ \/ /\//g
Re: Lack of VI Emulation Is a Signifigent Oversite [message #262764 is a reply to message #262761] Sat, 09 August 2008 04:04 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: billdsd.gmail.com

Robert Barror wrote:
> Why is there no VI emulation in eclipse? VI is one of the most powerful
> editors in the hands of a skilled user. The eclipse editor(CUI) is
> clumsy and weak in comparison. Experienced coders don't need welded on
> training wheels. I, like many developers, would love to use eclipse, but
> will continue to give it a pass until VI functionality is available.

Sorry but no.

Just to let you know where I'm coming from, I've been a vi user since
1985 (23 years). I still use it every day for some tasks. I like it
so much that I use WinElvis or gVim when I have to edit text files on
Windows.

However, vi can't do some things that Eclipse can do. Really, really
useful things.

The one I like the most is "Open Declaration" a.k.a. F3. I work in a
system with roughly a million lines of Java code in thousands of source
files that I didn't write. Being able to quickly see how things are
defined is simply indispensable.

Another one I really really like is the outline. Being able to quickly
jump from one thing to another is very handy.

Refactor is pretty spiffy too. Being able to change something in several
places, even in several source files, adhering to language rules,
simultaneously is just awesome. Vi can't do it.

As you type syntax checking and code assist are also really nice.

I do miss being able to ":s/^/\/\//20" or ":s/^\/\///20" but I can live
without it if I have to. At least they have regular expressions in their
search and replace dialog. That gets me around the desire for ":g" and
":s" a large percentage of the time. It's still slower to use than vi but
at least it is usable. You can even limit the scope to "selected lines"
which helps.

I would like a vi editor mode to be available as part of the base package.
It would be nice but it's far from a necessity. I've accepted that most
people who never mastered a powerful command based text editor like vi
will never understand its real value or how quickly and easily it can do
things or why it's superior to a glorified notepad for text editing.
That's just life.

Of course, this is also open source world so as the incredibly annoying
old saying goes, if you want it so much, then you should write it. I
actually contemplated it, but then realized that it wasn't important enough
to me to put in the effort it would require to do it right. How about you?
Re: Lack of VI Emulation Is a Signifigent Oversite [message #262772 is a reply to message #262764] Sat, 09 August 2008 11:31 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 31909
Registered: July 2009
Senior Member
Guys,

Comments below.

Bill Davidson wrote:
> Robert Barror wrote:
>> Why is there no VI emulation in eclipse?
I think the primary reason is that vi isn't simply a key binding to
existing function. It's a modal environment that needs to track what
mode you're in.
>> VI is one of the most powerful editors in the hands of a skilled user.
I couldn't live without it.
>> The eclipse editor(CUI) is clumsy and weak in comparison.
I wouldn't go that far, but would feel crippled without it.
>> Experienced coders don't need welded on training wheels.
I'm not sure what this is referring to?
>> I, like many developers, would love to use eclipse, but will continue
>> to give it a pass until VI functionality is available.
I'd suggest visiting http://satokar.com/viplugin/ and parting with a few
dollars so that you can pamper your vi addition while taking advantage
of Eclipse. The combination of vi and Eclipse's Ctrl+Space is pure
joy. I've been using this for years and is well worth your dollars.
>
> Sorry but no.
Well, actually there is. It just costs a few dollars. I know that's
almost like sacrilege, but I'm sure a true zealot will get over that.
>
> Just to let you know where I'm coming from, I've been a vi user since
> 1985 (23 years).
I go back to 1981. I feel really old!
> I still use it every day for some tasks.
I uses it every day whenever possible.
> I like it
> so much that I use WinElvis or gVim when I have to edit text files on
> Windows.
I used to use those too. I have cygwin installed so that my crippled OS
works the way I want.
>
> However, vi can't do some things that Eclipse can do. Really, really
> useful things.
Imagine the combination!
>
> The one I like the most is "Open Declaration" a.k.a. F3. I work in a
> system with roughly a million lines of Java code in thousands of source
> files that I didn't write. Being able to quickly see how things are
> defined is simply indispensable.
Maybe you didn't know about vi plugin either. What's nice is that keys
that do nothing in vi do cool things in Eclipse, so it's easy to have
both. Ctrl-Space is my favorite.
>
> Another one I really really like is the outline. Being able to quickly
> jump from one thing to another is very handy.
>
> Refactor is pretty spiffy too. Being able to change something in several
> places, even in several source files, adhering to language rules,
> simultaneously is just awesome. Vi can't do it.
The right tool for the right job.
>
> As you type syntax checking and code assist are also really nice.
>
> I do miss being able to ":s/^/\/\//20" or ":s/^\/\///20" but I can live
> without it if I have to.
You don't though!
> At least they have regular expressions in their
> search and replace dialog. That gets me around the desire for ":g" and
> ":s" a large percentage of the time. It's still slower to use than vi
> but
> at least it is usable. You can even limit the scope to "selected lines"
> which helps.
>
> I would like a vi editor mode to be available as part of the base
> package.
> It would be nice but it's far from a necessity. I've accepted that most
> people who never mastered a powerful command based text editor like vi
> will never understand its real value or how quickly and easily it can do
> things or why it's superior to a glorified notepad for text editing.
> That's just life.
Some people just don't get it. They're just losers. :-P
>
> Of course, this is also open source world so as the incredibly annoying
> old saying goes, if you want it so much, then you should write it.
Someone already did. Doesn't anyone know how to use Google. :-P
> I
> actually contemplated it, but then realized that it wasn't important
> enough
> to me to put in the effort it would require to do it right.
Sadly actually I wrote such a thing in C++ when working on a C++ IDE
many years ago.
> How about you?
Spend some money dudes. :-P

Note that once you paid for the license, you can keep getting updates...


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Lack of VI Emulation Is a Signifigent Oversite [message #262781 is a reply to message #262772] Sun, 10 August 2008 03:28 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: bobarror.soco.agilent.com

Hi Guys,

First, I think my original post leads to the impression that I am against
the author of viPlugin from charging for it. As a libertarian, nothing
could be farther from the truth. What I was trying to say was that the
fact that the author is making a profit, should not be used to justify not
placing this functionality within eclipse. And yes I am aware of the
plugin as I use it at home. It is very nice. I probably could not do
better, though without looking at the code, that is really hard to judge.

I have explained in my original post why viPlugin can not be part of our
base development platform. This means that deploying eclipse will make it
very difficult to use VI, and franckly CUI is garbage and not worthy to be
used for code development. As manipulating text constitutes the major
activity of a developer, the base text editor is of primary importance.
All of the other stuff is just icing. I normally operate with up to 50
instances of gvim, a few tabbed terminals, and some scripts for filtering
in vim and for using vim as a bulk editor. The wonderful stuff that
eclipse could add to what I already can do, is just not significant enough
to abandon a real text editor. And as I work with C/C++, and eclipse,
despite its claim, is still mostly a java IDE, the wonderful stuff that is
eclipse, dose not all exist. This means that I will insure that eclipse
dose not become part of our base dev platform.

But what really bothers me is 1) the existence of this plugin is being
used as justification for not fixing eclipse, 2) the eclipse development
community seams to be blinded by MS's deliberately anemic products, as
demonstrated by eclipse not having VI functionality in the first place,
and 3) the mindset that seams to be okay with the brilliance of the past
being ridiculed, obscured, and ultimately displaced by amateurish hacks
not worthy of a college freshman, all because of a parasitic monopolies
business model depending on products, who's market viability is predicated
on customer ignorance.

The eclipse team has made a big mistake in the design of their editor
model. This fact is completely undeniable as demonstrated by its inability
to work as a foundation for all editors. I am assuming that this mistake
was made out of ignorance, though it makes one wonder what else is amiss.
The whole reason I am even posting is in the hopes that this lapse is a
special case and not a general trend.

Every year, the fight becomes harder to keep what is demonstrably superior
from being replaced by junk. Not including VI functionality in eclipse
will insure that the power of modal editors will disappear forever. I am
not being hyperbolic. How in the hell are the kids going to learn, if they
never get a chance to see?!?! And without the kids learning who will speak
up for truth?

I am tired of college grads trumping experienced professionals on issues
like this because of ignorance (and ignorance of the ignorance) and a
philosophy that assumes that grads have the latest and greatest, and that
the latest is the greatest. "You guys don't like it because its new and
different." GRRRRRRR!
(Fortunately, and amazingly, I am currently not in a situation were this
happens as a rule. The organizations "new hire" grads are brilliant and
incredibly fast learners, who will surely contribute many great thing in
the years to come { gawd, I hope they don't see this!})

But ultimately, because of the wacked economic models currently used by
most businesses, even the smallest barrier will prevent anything perceived
as redundant from being acquired, especially in the face of multi-million
dollar deception campaigns. So goodby VI.

thx bob

P.S. I would love to get involved with the eclipse community. I have way
too much on my plate right now to contribute. I have five or six major
personal projects going ( including a very VI like programmable streaming
"block editor" for use with gvim that will be a proof of concept for one
of the things that can be done with some parsing theory that I have
developed). I am also concerned that I would end up having to defend
against irrational attack. Considering the pedigree of eclipse, I am sure
that that would never be an issue but this VI thing introduces some doubt.
BTW, I would not touch Gnome with a someone else's 10 foot pole. Them kids
are totally and irrevocably lost. And I have started my own "desktop"
project based on fox.

I have scoped the time required for creating a vim plugin and came up with
about 40 hours; way too much until maybe Feb 2009. Plus I have never
written in Java (though I am a Sun certified Java Developer) so I would
feel rather shy about my first few endevours. If I seem rather harsh, its
nothing compared to how harsh I can be to myself. BTW, this area of work
is right up my alley as parsing theory is my specialty. I only work as a
software developer because its as close as I can get to being a systems
theorist.

P.P.S. Ive been writing software since 1974 and real engineered software
since 1976. I'm only 48 :)
Re: Lack of VI Emulation Is a Signifigent Oversite [message #262794 is a reply to message #262781] Sun, 10 August 2008 13:06 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 31909
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------020205080805040905080008
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Robert,

Comments below.

Robert Barror wrote:
> Hi Guys,
>
> First, I think my original post leads to the impression that I am
> against the author of viPlugin from charging for it. As a libertarian,
> nothing could be farther from the truth. What I was trying to say was
> that the fact that the author is making a profit, should not be used
> to justify not placing this functionality within eclipse. And yes I am
> aware of the plugin as I use it at home. It is very nice. I probably
> could not do better, though without looking at the code, that is
> really hard to judge.
I don't think anyone is trying to justify not doing it in the first
place and most certainly no to avoid cutting into anyone's profits.
>
> I have explained in my original post why viPlugin can not be part of
> our base development platform. This means that deploying eclipse will
> make it very difficult to use VI, and franckly CUI is garbage and not
> worthy to be used for code development. As manipulating text
> constitutes the major activity of a developer, the base text editor is
> of primary importance. All of the other stuff is just icing. I
> normally operate with up to 50 instances of gvim, a few tabbed
> terminals, and some scripts for filtering in vim and for using vim as
> a bulk editor. The wonderful stuff that eclipse could add to what I
> already can do, is just not significant enough to abandon a real text
> editor. And as I work with C/C++, and eclipse, despite its claim, is
> still mostly a java IDE, the wonderful stuff that is eclipse, dose not
> all exist. This means that I will insure that eclipse dose not become
> part of our base dev platform.
I don't buy this whole line of thinking.
>
> But what really bothers me is 1) the existence of this plugin is being
> used as justification for not fixing eclipse,
That's just your bogus interpretation. Feel free to start a project and
Eclipse and donate it. The vi zealots of the world will be forever
grateful for you free service and support. But don't bother with the
war dance because your put out that someone else refuses to do it for
you for free.
> 2) the eclipse development community seams to be blinded by MS's
> deliberately anemic products, as demonstrated by eclipse not having VI
> functionality in the first place,
You think MS deliberately makes its products anemic? I find it odd that
you seem to think that whenever someone else doesn't invest time and
effort to make something better than it is that there's deliberation
involved other than the simple economic fact that time and effort are in
always in limited supply and always cost money. You don't want to spend
yours but you want others to spend theirs. Isn't that a bit ironic?
> and 3) the mindset that seams to be okay with the brilliance of the
> past being ridiculed, obscured, and ultimately displaced by amateurish
> hacks not worthy of a college freshman, all because of a parasitic
> monopolies business model depending on products, who's market
> viability is predicated on customer ignorance.
Wow, that's a great sentence! I don't agree with it though. Of course
folks do love to ridicule vi, but they can't really help it. They're
losers who don't know any better. :-P So that means brilliant thinkers
like you and me need to invest in showing them the error of their
pathetic ways. As I said, I've done that in the past at IBM working on
an IBM product, which kind of blows the above argument away; although
granted, I did it under my own steam with no direct support for the
effort. The deep technical problem is that vi is modal, yet most
extensible/configurable editor frameworks simply want to bind
alternative keys to basic actions to make users happy. That doesn't
suffice for vi.
>
> The eclipse team has made a big mistake in the design of their editor
> model. This fact is completely undeniable as demonstrated by its
> inability to work as a foundation for all editors. I am assuming that
> this mistake was made out of ignorance, though it makes one wonder
> what else is amiss. The whole reason I am even posting is in the hopes
> that this lapse is a special case and not a general trend.
I just don't get it. The things you are saying seem so polarized. It's
like there are no shades of gray in your world. Just black and white.
It seems to me the fact that I've happily used vi for many years with
Eclipse makes the above statement false.
>
> Every year, the fight becomes harder to keep what is demonstrably
> superior from being replaced by junk. Not including VI functionality
> in eclipse will insure that the power of modal editors will disappear
> forever. I am not being hyperbolic. How in the hell are the kids going
> to learn, if they never get a chance to see?!?! And without the kids
> learning who will speak up for truth?
Hallelujah. I'm sure folks will argue that modal is complex and that
everything needs to be simple. It's quite sad really.
>
> I am tired of college grads trumping experienced professionals on
> issues like this because of ignorance (and ignorance of the ignorance)
> and a philosophy that assumes that grads have the latest and greatest,
> and that the latest is the greatest. "You guys don't like it because
> its new and different." GRRRRRRR!
> (Fortunately, and amazingly, I am currently not in a situation were
> this happens as a rule. The organizations "new hire" grads are
> brilliant and incredibly fast learners, who will surely contribute
> many great thing in the years to come { gawd, I hope they don't see
> this!})
The folks who didn't learn vi are sad. We should pity them. I'm sure
they're snickering as they read this, and that's sad. :-P
>
> But ultimately, because of the wacked economic models currently used
> by most businesses, even the smallest barrier will prevent anything
> perceived as redundant from being acquired, especially in the face of
> multi-million dollar deception campaigns. So goodby VI.
This is starting to sound like one of my rant blogs.

http://ed-merks.blogspot.com/2008/08/engulf-and-devour.html

>
> thx bob
>
> P.S. I would love to get involved with the eclipse community. I have
> way too much on my plate right now to contribute. I have five or six
> major personal projects going ( including a very VI like programmable
> streaming "block editor" for use with gvim that will be a proof of
> concept for one of the things that can be done with some parsing
> theory that I have developed). I am also concerned that I would end up
> having to defend against irrational attack.
I'll be here. And all anti-vi bigots will have tunnel carpal syndrome
from their ctrl/alt/shift contortions and will be wasting time
constantly hunting for function keys that are way of out easy touch
typist reach, so they won't be able to keep up.
> Considering the pedigree of eclipse, I am sure that that would never
> be an issue but this VI thing introduces some doubt.
You really ought to believe me that this is purely about return on
investment and that it reflects the thinking that the effort to support
vi would not produce a return on investment. For me personally, I just
don't have the time or energy to invest in this, given that for a
nominal fee I can get what I need.
> BTW, I would not touch Gnome with a someone else's 10 foot pole. Them
> kids are totally and irrevocably lost. And I have started my own
> "desktop" project based on fox.
>
> I have scoped the time required for creating a vim plugin and came up
> with about 40 hours; way too much until maybe Feb 2009. Plus I have
> never written in Java (though I am a Sun certified Java Developer) so
> I would feel rather shy about my first few endevours.
The vi support really has to integrate with all the existing text
editors be be truly useful. Have you tried chatting with Michael
Bartl? You might well find he'd be more than happy to cut you a deal,
particularly if you're working an open source project.
> If I seem rather harsh, its nothing compared to how harsh I can be to
> myself.
I can be harsh as well. I have unfortunately a limited fuse when it
comes to people demanding things happen for free. Only dollars buys the
privilege of making demands. In all other cases, sociology will be at
play, i.e., you have to convince people nicely to do something for you,
which means you have to swallow harsh criticism and tone down personally
directed ranting.
> BTW, this area of work is right up my alley as parsing theory is my
> specialty. I only work as a software developer because its as close as
> I can get to being a systems theorist.
I was and am totally into languages and everything related to them
myself, including parsers...
>
> P.P.S. Ive been writing software since 1974 and real engineered
> software since 1976. I'm only 48 :)
You're older than me, but not much. I remember my Apple ][ very well. :-P

In the end, I agree that it's sad that there is no free vi emulation in
the basic platform. That really ought to have been something considered
right from the start. But I know how all this works, and it's all
driven by economics. If there were a significant outcry of paying
customers such that this issue hit companies in their pocket books,
action would be taken. But as long as no pain is felt, no action will
be taken. And that leaves the issue up to those who have their own
steam to invest...

>
>

--------------020205080805040905080008
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Robert,<br>
<br>
Comments below.<br>
<br>
Robert Barror wrote:
<blockquote
cite="mid:7a5b9d0a683991eb11f9eb90cfe7b298$1@www.eclipse.org"
type="cite">Hi Guys,
<br>
<br>
First, I think my original post leads to the impression that I am
against the author of viPlugin from charging for it. As a libertarian,
nothing could be farther from the truth. What I was trying to say was
that the fact that the author is making a profit, should not be used to
justify not placing this functionality within eclipse. And yes I am
aware of the plugin as I use it at home. It is very nice. I probably
could not do better, though without looking at the code, that is really
hard to judge.
<br>
</blockquote>
I don't think anyone is trying to justify not doing it in the first
place and most certainly no to avoid cutting into anyone's profits.<br>
<blockquote
cite="mid:7a5b9d0a683991eb11f9eb90cfe7b298$1@www.eclipse.org"
type="cite"><br>
I have explained in my original post why viPlugin can not be part of
our base development platform. This means that deploying eclipse will
make it very difficult to use VI, and franckly CUI is garbage and not
worthy to be used for code development. As manipulating text
constitutes the major activity of a developer, the base text editor is
of primary importance. All of the other stuff is just icing. I normally
operate with up to 50 instances of gvim, a few tabbed terminals, and
some scripts for filtering in vim and for using vim as a bulk editor.
The wonderful stuff that eclipse could add to what I already can do, is
just not significant enough to abandon a real text editor. And as I
work with C/C++, and eclipse, despite its claim, is still mostly a java
IDE, the wonderful stuff that is eclipse, dose not all exist. This
means that I will insure that eclipse dose not become part of our base
dev platform.
<br>
</blockquote>
I don't buy this whole line of thinking.<br>
<blockquote
cite="mid:7a5b9d0a683991eb11f9eb90cfe7b298$1@www.eclipse.org"
type="cite"><br>
But what really bothers me is 1) the existence of this plugin is being
used as justification for not fixing eclipse, </blockquote>
That's just your bogus interpretation.


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Lack of VI Emulation Is a Signifigent Oversite [message #262824 is a reply to message #262781] Sun, 10 August 2008 20:45 Go to previous messageGo to next message
Nitin Dahyabhai is currently offline Nitin DahyabhaiFriend
Messages: 4064
Registered: July 2009
Senior Member

Robert Barror wrote:
> ...As manipulating text constitutes the
> major activity of a developer, the base text editor is of primary
> importance. All of the other stuff is just icing. I normally operate
> with up to 50 instances of gvim, a few tabbed terminals, and some
> scripts for filtering in vim and for using vim as a bulk editor. The
> wonderful stuff that eclipse could add to what I already can do, is just
> not significant enough to abandon a real text editor. And as I work with
> C/C++, and eclipse, despite its claim, is still mostly a java IDE, the
> wonderful stuff that is eclipse, dose not all exist...

My day to day job involves delivering source editors for multiple
languages, only one of which includes Java in its contents, so
referring to Eclipse as mostly a Java IDE doesn't mesh well with
reality as I or Ganymede's UDC see it. While I've found your posts
in this thread to be somewhat inflammatory (referring to quality
work from the Platform Text team as "garbage" doesn't sit well with
me), I'd suggest you channel your obvious passion for this feature
into a RFE in Bugzilla, and rally the community around you to
produce a high quality patch that can be either freely added to or
included in the Platform. If anything, I think you've seriously
underestimated the amount of time it would take.

--
---
Nitin Dahyabhai
Eclipse WTP Source Editing
IBM Rational


Nitin Dahyabhai
Eclipse Web Tools Platform
Re: Lack of VI Emulation Is a Signifigent Oversite [message #262827 is a reply to message #262761] Sun, 10 August 2008 20:57 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: v_the_gaul.gmail.com

4 months to generate 143 characters?

Yup, that's one great tool ya got there. Feel free to count me amongst
the ignorant unwashed masses.
Re: Lack of VI Emulation Is a Signifigent Oversite [message #262830 is a reply to message #262824] Sun, 10 August 2008 22:07 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 31909
Registered: July 2009
Senior Member
Nitin,

I totally agree. I have a petty good idea of what it would take to
support vi and I doubt very much that I'd be done in a week. I think
Robert does have a reasonable point, but it's likely to be lost in the
overstatement. In particular, crapping on the hard work people have
invested in Eclipse will get him nowhere.


Nitin Dahyabhai wrote:
> Robert Barror wrote:
>> ...As manipulating text constitutes the major activity of a
>> developer, the base text editor is of primary importance. All of the
>> other stuff is just icing. I normally operate with up to 50 instances
>> of gvim, a few tabbed terminals, and some scripts for filtering in
>> vim and for using vim as a bulk editorent. The wonderful stuff that
>> eclipse could add to what I already can do, is just not significant
>> enough to abandon a real text editor. And as I work with C/C++, and
>> eclipse, despite its claim, is still mostly a java IDE, the wonderful
>> stuff that is eclipse, dose not all exist...
>
> My day to day job involves delivering source editors for multiple
> languages, only one of which includes Java in its contents, so
> referring to Eclipse as mostly a Java IDE doesn't mesh well with
> reality as I or Ganymede's UDC see it. While I've found your posts in
> this thread to be somewhat inflammatory (referring to quality work
> from the Platform Text team as "garbage" doesn't sit well with me),
> I'd suggest you channel your obvious passion for this feature into a
> RFE in Bugzilla, and rally the community around you to produce a high
> quality patch that can be either freely added to or included in the
> Platform. If anything, I think you've seriously underestimated the
> amount of time it would take.
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Lack of VI Emulation Is a Signifigent Oversite [message #262831 is a reply to message #262827] Sun, 10 August 2008 22:17 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 31909
Registered: July 2009
Senior Member
You didn't find that regular expression to be a completely transparent
expression of the problem being solved? :-P

In all seriousness though, this issue of key bindings and specifically
support for vi is unfortunately similar to a religion and in general,
aside from joking, it's best to respect someone else's point of view. I
completely understand that someone else might find vi to be an
abomination, but I can assure you that for me it's the most concise way
to convert my thoughts into textual changes as I believe is possible.

To each their own I always say...

Just to throw some gasoline into the fire, wouldn't have good tool have
highlighted the spelling mistakes on "Signifigent Oversite" and helped
turn it into "Significant Oversight"? :-P


Vercingeterix wrote:
> 4 months to generate 143 characters?
> Yup, that's one great tool ya got there. Feel free to count me
> amongst the ignorant unwashed masses.
>
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Lack of VI Emulation Is a Signifigent Oversite [message #262840 is a reply to message #262827] Mon, 11 August 2008 09:34 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: bobarror.soco.agilent.com

Ha!

I am pretty sure your brain would melt if I had included all of the vim
scripts and the ksh tools I had used in the task within my post. After all
some of them make even my eyes hurt to look at and I am an RE master. ( I
actually had some problems printing hard copies of my vim scripts because
someone kept thinking that they where postscript mishaps and was throwing
them out!). BTW, That line took me about 10 seconds to create. ( I needed
it because I should have taken a few more seconds writing another command
that was a little amiss and caused some serious damage that needed to be
repaired quickly for a scheduled eval cycle, and thuss highlighting the
main problem of a powerful editor, the power to do damage, and the problem
with REs, they can be damn hard to read.) I included this vi command line
because it is a good example of what can be done quickly with VI. How
would you do this in CUI???

BTW, I'm pretty sure your joking, but just to be clear of were I am coming
from. I started with 4 GB of source including pre-ANSI, ANSI, and ISO C
and Pre-ISO C++ ( it had to use two compilers, aCC and HPs cc) in some
8000 files, which was written by many coders of every skill level over a
period of some 15 years. I found abominations that made my head hurt, e.g.
aCC would not even whimper when a double was passed to an int(int) and
that assigned to a double, so guess what I found ... in abundance. Then
there was the whole char * vs. const char * thing along with and other
fundamental architectural problems. The C++ code used the old STL names.
And on top of this were all of the violations of the organizations
established coding practices.

This is real living code and it demonstrates what real coders often need
to contend with. It was chaotic and dirty and devoid of any of the
preconditions that all of the spiffy new development tools require. And I
had to single handedly edited every single line of this mess to bring it
up to strict ISO ( with GCC pedantic) compliance. I used GVIM, ksh, and
GCC and it took me four months.

The work was done on a old HP-UX 10.20 machine so about 40% of the time
was just waiting for the compiler to do its thing (while my hair got
grayer). Another 10-15% of my time was trying to figure out what the
original author was really trying to do so that I could fix the code while
minimizing the changes to run time behavior (while my hair got grayer
still). The actual editing activity consumed about two months.

N.B., I am not writing this as a demonstration of what I can do, after
all this activity was more like being a breakfast cook at the local dinner
on Saturday morning then being a software architect. I am explaining this
as a demonstration of what VI (gvim) can do in skilled hands.

Your EMACS would wither to dust in the face of such a task as this :P

Seriously, I am pretty certain that whatever eclipse with CDT ( judging
from what I learned playing with Callisto) could have contributed would
have been more then counteracted by the constraints of a CUI editor. I do
know that CDT is moving fast, and thus my knowledge is a bit old so I
could be wrong, but I doubt it.
Re: Lack of VI Emulation Is a Signifigent Oversite [message #262846 is a reply to message #262840] Mon, 11 August 2008 10:23 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: subs._nospam_consertum.com

I'm a long term Vi user (20+years), and a recent convert to Eclipse (3
years).

I use both tools every day, but in their appropriate places.

For day-to-day editing, compiling, debugging etc. Eclipse is great and I
wouldn't use anything else. I'd say this is 99.9*% of my work.

For the rare occurances when I need to do some major source
restructuring, I use vi/grep/sed/whatever. Eclipse isn't suitable for
this, and I wouldn't want it to be. However, it *is* suitable for most
of the day-to-day editing I need - reformating, moving code about, code
templates, code-completions, refactoring, etc etc.

My fingers 'know' vi, and they occasionally try to do it in Eclipse...
However, I have now moved (mostly) into the 21st Century and find that
Eclipse will do nearly everything I used to do in vi (except as stated
in above) and a whole lot more besides.

Just my 2c.

Robert Barror wrote:
> Ha!
>
> I am pretty sure your brain would melt if I had included all of the vim
> scripts and the ksh tools I had used in the task within my post. After
> all some of them make even my eyes hurt to look at and I am an RE
> master. ( I actually had some problems printing hard copies of my vim
> scripts because someone kept thinking that they where postscript mishaps
> and was throwing them out!). BTW, That line took me about 10 seconds to
> create. ( I needed it because I should have taken a few more seconds
> writing another command that was a little amiss and caused some serious
> damage that needed to be repaired quickly for a scheduled eval cycle,
> and thuss highlighting the main problem of a powerful editor, the power
> to do damage, and the problem with REs, they can be damn hard to read.)
> I included this vi command line because it is a good example of what can
> be done quickly with VI. How would you do this in CUI???
>
> BTW, I'm pretty sure your joking, but just to be clear of were I am
> coming from. I started with 4 GB of source including pre-ANSI, ANSI, and
> ISO C and Pre-ISO C++ ( it had to use two compilers, aCC and HPs cc) in
> some 8000 files, which was written by many coders of every skill level
> over a period of some 15 years. I found abominations that made my head
> hurt, e.g. aCC would not even whimper when a double was passed to an
> int(int) and that assigned to a double, so guess what I found ... in
> abundance. Then there was the whole char * vs. const char * thing along
> with and other fundamental architectural problems. The C++ code used the
> old STL names. And on top of this were all of the violations of the
> organizations established coding practices.
>
> This is real living code and it demonstrates what real coders often need
> to contend with. It was chaotic and dirty and devoid of any of the
> preconditions that all of the spiffy new development tools require. And
> I had to single handedly edited every single line of this mess to bring
> it up to strict ISO ( with GCC pedantic) compliance. I used GVIM, ksh,
> and GCC and it took me four months.
>
> The work was done on a old HP-UX 10.20 machine so about 40% of the time
> was just waiting for the compiler to do its thing (while my hair got
> grayer). Another 10-15% of my time was trying to figure out what the
> original author was really trying to do so that I could fix the code
> while minimizing the changes to run time behavior (while my hair got
> grayer still). The actual editing activity consumed about two months.
>
> N.B., I am not writing this as a demonstration of what I can do, after
> all this activity was more like being a breakfast cook at the local
> dinner on Saturday morning then being a software architect. I am
> explaining this as a demonstration of what VI (gvim) can do in skilled
> hands.
>
> Your EMACS would wither to dust in the face of such a task as this :P
>
> Seriously, I am pretty certain that whatever eclipse with CDT ( judging
> from what I learned playing with Callisto) could have contributed would
> have been more then counteracted by the constraints of a CUI editor. I
> do know that CDT is moving fast, and thus my knowledge is a bit old so I
> could be wrong, but I doubt it.
>


--
Derek
Re: Lack of VI Emulation Is a Signifigent Oversite [message #262849 is a reply to message #262840] Mon, 11 August 2008 11:15 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 31909
Registered: July 2009
Senior Member
Robert,

Comments below.

Robert Barror wrote:
> Ha!
>
> I am pretty sure your brain would melt if I had included all of the
> vim scripts and the ksh tools I had used in the task within my post.
> After all some of them make even my eyes hurt to look at and I am an
> RE master. ( I actually had some problems printing hard copies of my
> vim scripts because someone kept thinking that they where postscript
> mishaps and was throwing them out!). BTW, That line took me about 10
> seconds to create. ( I needed it because I should have taken a few
> more seconds writing another command that was a little amiss and
> caused some serious damage that needed to be repaired quickly for a
> scheduled eval cycle, and thuss highlighting the main problem of a
> powerful editor, the power to do damage, and the problem with REs,
> they can be damn hard to read.) I included this vi command line
> because it is a good example of what can be done quickly with VI. How
> would you do this in CUI???
I agree. Regular expressions are extremely cryptic but their power to
script massive changes quickly should not be underestimated. I could
imagine the search and replace dialog taking full advantage of them...
>
> BTW, I'm pretty sure your joking, but just to be clear of were I am
> coming from. I started with 4 GB of source including pre-ANSI, ANSI,
> and ISO C and Pre-ISO C++ ( it had to use two compilers, aCC and HPs
> cc) in some 8000 files, which was written by many coders of every
> skill level over a period of some 15 years. I found abominations that
> made my head hurt, e.g. aCC would not even whimper when a double was
> passed to an int(int) and that assigned to a double, so guess what I
> found ... in abundance. Then there was the whole char * vs. const char
> * thing along with and other fundamental architectural problems. The
> C++ code used the old STL names. And on top of this were all of the
> violations of the organizations established coding practices.
>
> This is real living code and it demonstrates what real coders often
> need to contend with. It was chaotic and dirty and devoid of any of
> the preconditions that all of the spiffy new development tools
> require. And I had to single handedly edited every single line of this
> mess to bring it up to strict ISO ( with GCC pedantic) compliance. I
> used GVIM, ksh, and GCC and it took me four months.
>
> The work was done on a old HP-UX 10.20 machine so about 40% of the
> time was just waiting for the compiler to do its thing (while my hair
> got grayer). Another 10-15% of my time was trying to figure out what
> the original author was really trying to do so that I could fix the
> code while minimizing the changes to run time behavior (while my hair
> got grayer still). The actual editing activity consumed about two months.
>
> N.B., I am not writing this as a demonstration of what I can do,
> after all this activity was more like being a breakfast cook at the
> local dinner on Saturday morning then being a software architect. I am
> explaining this as a demonstration of what VI (gvim) can do in skilled
> hands.
>
> Your EMACS would wither to dust in the face of such a task as this :P
>
> Seriously, I am pretty certain that whatever eclipse with CDT (
> judging from what I learned playing with Callisto) could have
> contributed would have been more then counteracted by the constraints
> of a CUI editor. I do know that CDT is moving fast, and thus my
> knowledge is a bit old so I could be wrong, but I doubt it.
You might have gotten the best of both. What vi is not great at doing
is navigating between files, e.g., given the use of an identifier,
finding the one the compiler considers its declaration. As Derek
argued, its good to use the right tool for the right job...


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Lack of VI Emulation Is a Signifigent Oversite [message #262854 is a reply to message #262846] Mon, 11 August 2008 11:15 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 31909
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------090703070009030108070904
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Derek,

Comments below.

Derek wrote:
> I'm a long term Vi user (20+years), and a recent convert to Eclipse (3
> years).
>
> I use both tools every day, but in their appropriate places.
I use both tools all the time.
>
> For day-to-day editing, compiling, debugging etc. Eclipse is great and
> I wouldn't use anything else. I'd say this is 99.9*% of my work.
Yes, we spend a heck of a lot more time working with code (reading,
debugging, navigating) than generating it with our finger tips.
>
>
> For the rare occurances when I need to do some major source
> restructuring, I use vi/grep/sed/whatever. Eclipse isn't suitable for
> this, and I wouldn't want it to be.
But it is, though if you don't want it to be you can pretend it's not.
> However, it *is* suitable for most of the day-to-day editing I need -
> reformating, moving code about, code templates, code-completions,
> refactoring, etc etc.
Yes, more than suitable.
>
> My fingers 'know' vi, and they occasionally try to do it in Eclipse...
Then why not satisfy your fingers too.
> However, I have now moved (mostly) into the 21st Century and find that
> Eclipse will do nearly everything I used to do in vi (except as stated
> in above) and a whole lot more besides.
True, but this attitude that something of value should be thrown away
for the sake of progress is just poor Teflon Programming
< http://ed-merks.blogspot.com/2008/04/teflon-programming.html>
attitude. Especially for something as fundamental as what "my fingers
know." It would be nice to think that just a few of the things that have
happened in the last 30 years might have some lasting value. EMACS
users tend to be as zealous about the wonders of EMACS as well and also
have a very strong case to argue.
>
> Just my 2c.
>
> Robert Barror wrote:
>> Ha!
>>
>> I am pretty sure your brain would melt if I had included all of the
>> vim scripts and the ksh tools I had used in the task within my post.
>> After all some of them make even my eyes hurt to look at and I am an
>> RE master. ( I actually had some problems printing hard copies of my
>> vim scripts because someone kept thinking that they where postscript
>> mishaps and was throwing them out!). BTW, That line took me about 10
>> seconds to create. ( I needed it because I should have taken a few
>> more seconds writing another command that was a little amiss and
>> caused some serious damage that needed to be repaired quickly for a
>> scheduled eval cycle, and thuss highlighting the main problem of a
>> powerful editor, the power to do damage, and the problem with REs,
>> they can be damn hard to read.) I included this vi command line
>> because it is a good example of what can be done quickly with VI. How
>> would you do this in CUI???
>>
>> BTW, I'm pretty sure your joking, but just to be clear of were I am
>> coming from. I started with 4 GB of source including pre-ANSI, ANSI,
>> and ISO C and Pre-ISO C++ ( it had to use two compilers, aCC and HPs
>> cc) in some 8000 files, which was written by many coders of every
>> skill level over a period of some 15 years. I found abominations that
>> made my head hurt, e.g. aCC would not even whimper when a double was
>> passed to an int(int) and that assigned to a double, so guess what I
>> found ... in abundance. Then there was the whole char * vs. const
>> char * thing along with and other fundamental architectural problems.
>> The C++ code used the old STL names. And on top of this were all of
>> the violations of the organizations established coding practices.
>>
>> This is real living code and it demonstrates what real coders often
>> need to contend with. It was chaotic and dirty and devoid of any of
>> the preconditions that all of the spiffy new development tools
>> require. And I had to single handedly edited every single line of
>> this mess to bring it up to strict ISO ( with GCC pedantic)
>> compliance. I used GVIM, ksh, and GCC and it took me four months.
>>
>> The work was done on a old HP-UX 10.20 machine so about 40% of the
>> time was just waiting for the compiler to do its thing (while my hair
>> got grayer). Another 10-15% of my time was trying to figure out what
>> the original author was really trying to do so that I could fix the
>> code while minimizing the changes to run time behavior (while my hair
>> got grayer still). The actual editing activity consumed about two
>> months.
>>
>> N.B., I am not writing this as a demonstration of what I can do,
>> after all this activity was more like being a breakfast cook at the
>> local dinner on Saturday morning then being a software architect. I
>> am explaining this as a demonstration of what VI (gvim) can do in
>> skilled hands.
>>
>> Your EMACS would wither to dust in the face of such a task as this :P
>>
>> Seriously, I am pretty certain that whatever eclipse with CDT (
>> judging from what I learned playing with Callisto) could have
>> contributed would have been more then counteracted by the constraints
>> of a CUI editor. I do know that CDT is moving fast, and thus my
>> knowledge is a bit old so I could be wrong, but I doubt it.
>>
>
>

--------------090703070009030108070904
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Derek,<br>
<br>
Comments below.<br>
<br>
Derek wrote:
<blockquote cite="mid:g7p3vl$hik$1@build.eclipse.org" type="cite">I'm a
long term Vi user (20+years), and a recent convert to Eclipse (3
years).
<br>
<br>
I use both tools every day, but in their appropriate places.
<br>
</blockquote>
I use both tools all the time. <br>
<blockquote cite="mid:g7p3vl$hik$1@build.eclipse.org" type="cite"><br>
For day-to-day editing, compiling, debugging etc. Eclipse is great and
I


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Lack of VI Emulation Is a Signifigent Oversite [message #262857 is a reply to message #262830] Mon, 11 August 2008 12:32 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: bobarror.soco.agilent.com

Hi,

You guys misunderstand; 40 hours to create a plugin for VIM which is well
suited for being used as a plugin. To correct the deficiencies in eclipse
???? I'd probably spend 40 hours just having a look see as to what need to
be done.

The problem with correcting errors in the design of core functionality is
in dealing with all of the ramifications that the delinquent design place
on the rest of the system. This is exactly why compromising on the design
of the foundation of any system is a significant mistake. The weak design
gets locked in and the work needed to correct the lapse increases with
every passing day. Usually, the work required for a repair far exceeds
what would have been needed to do the job right to begin with.

This is why I consider the lack of a proper editor foundation in what is
supposed to be the ultimate IDE/RCP platform such an issue. A proper IDE
platform would not need to rely on a second source plugin to provide core
IDE functionality.

I am not trying to disrespect the eclipse community. On the other hand, I
do not compromise on issues of quality or accuracy. I absolutely refuse to
lie. A mistake is a mistake and to say otherwise would be a lie. My dad
was an engineer and I grew up surrounded by engineers. Everyone in my
family is an engineer. Once upon a time engineers were thick skinned. They
had to be. 1) Truth is more important then hurt feelings. And 2) a lot of
good engineers are social klutzes who's speech sometimes lacks gentleness
especially to coworkers. To real engineer, substance is far more important
the appearance.

So the facts remain stated as politely as I can without loosing accuracy:

The lack of VI functionality in the core of eclipse violates the stated
goal of eclipse.

Either the core team was aware of this or they were not.

If aware, then they did not consider VI important enough to be included
in eclipse.

Either the team felt the functionality could be added later or they
felt that it was not important enough to be ever included.

If they thought to have it added later, then the design would have
had room for this eventuality. Does it? I get the impression it does not.
Is the design of the rest of the system completely isolated from the
editors CUI behavior so that an editor supporting VI can be dropped in
without touching anything else? Kudos if it is. This type of thing is
quite difficult. If not, then the design is flawed and does not meet
goals, i.e. adding VI functionality becomes non trivial relative to the
entire system.

If The team decided to never include it, then the core team is okay
with flawed design. And this is an indication of systemic issues. The
whole point in my post is to find out if this impression is accurate or
not.

If not aware, then they are ignorant of VI and that is an indication of
other problems. How can one trust the design of an IDE platform from a
team that is ignorant of editors?
Re: Lack of VI Emulation Is a Signifigent Oversite [message #262860 is a reply to message #262846] Mon, 11 August 2008 12:41 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: bobarror.soco.agilent.com

Thanks. I have been trying to imagine what an eclipse plus gvim
development environment would look like. I really do like eclipse. I wrote
my very first Python program with it using viPlugin and pyDev. It was
quite cool. I have also done some C and C++ at work using the native
editor and found the editing irritating but I liked everything else.
Re: Lack of VI Emulation Is a Signifigent Oversite [message #262874 is a reply to message #262857] Mon, 11 August 2008 13:40 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 31909
Registered: July 2009
Senior Member
Robert,

Comments below.

Robert Barror wrote:
> Hi,
>
> You guys misunderstand; 40 hours to create a plugin for VIM which is
> well suited for being used as a plugin. To correct the deficiencies in
> eclipse ???? I'd probably spend 40 hours just having a look see as to
> what need to be done.
Yes, I think it's a big task.
>
> The problem with correcting errors in the design of core functionality
> is in dealing with all of the ramifications that the delinquent design
> place on the rest of the system. This is exactly why compromising on
> the design of the foundation of any system is a significant mistake.
> The weak design gets locked in and the work needed to correct the
> lapse increases with every passing day. Usually, the work required for
> a repair far exceeds what would have been needed to do the job right
> to begin with.
Given that vi plugin works so well, I see no basis for your assumption
that there are deficiencies that need to be correct.
>
> This is why I consider the lack of a proper editor foundation in what
> is supposed to be the ultimate IDE/RCP platform such an issue. A
> proper IDE platform would not need to rely on a second source plugin
> to provide core IDE functionality.
A proper platform allows anything to be plugged in and work well. I
think Eclipse and vi plugin have demonstrated this. The argument that
something should just come with the platform is orthogonal to this.
>
> I am not trying to disrespect the eclipse community.
Clearly folks are interpreting it that way, so you're doing a good job
without trying. :-P
> On the other hand, I do not compromise on issues of quality or
> accuracy. I absolutely refuse to lie. A mistake is a mistake and to
> say otherwise would be a lie. My dad was an engineer and I grew up
> surrounded by engineers. Everyone in my family is an engineer. Once
> upon a time engineers were thick skinned. They had to be. 1) Truth is
> more important then hurt feelings. And 2) a lot of good engineers are
> social klutzes who's speech sometimes lacks gentleness especially to
> coworkers. To real engineer, substance is far more important the
> appearance.
Life is a balancing act and often you need to think if your actions are
more about expressing your own emotions or about producing a specific
outcome. If the former, feel free to rant. If the latter, some social
skills are needed.
>
> So the facts remain stated as politely as I can without loosing accuracy:
I think you could do better. Stop make excuses. :-P
>
> The lack of VI functionality in the core of eclipse violates the
> stated goal of eclipse.
If only one in 100 users agree with you, is it still true?
>
> Either the core team was aware of this or they were not.
Or they were and had limited capacity to make emacs and vi users happy.
>
> If aware, then they did not consider VI important enough to be
> included in eclipse.
Or didn't have enough resource to contain it nor the management support
to consider it a priority.
>
> Either the team felt the functionality could be added later or they
> felt that it was not important enough to be ever included.
I expect both are true.
>
> If they thought to have it added later, then the design would
> have had room for this eventuality. Does it? I get the impression it
> does not.
Doesn't vi plugin prove it is?
> Is the design of the rest of the system completely isolated from the
> editors CUI behavior so that an editor supporting VI can be dropped in
> without touching anything else? Kudos if it is.
Talk to Michael Bartl. See if he'll give you a free version to try.
> This type of thing is quite difficult. If not, then the design is
> flawed and does not meet goals, i.e. adding VI functionality becomes
> non trivial relative to the entire system.
>
> If The team decided to never include it, then the core team is
> okay with flawed design. And this is an indication of systemic issues.
> The whole point in my post is to find out if this impression is
> accurate or not.
I think there is evidence to indicate you've got a few flawed
assumptions. The fact that I happily use vi with the JDT---not a
separate vi editor plugged into Eclipse but rather basic vi key bindings
in all the text-based editors---demonstrates that the architecture is
suitably flexible and hence where there's a will there's a way.
>
> If not aware, then they are ignorant of VI and that is an indication
> of other problems. How can one trust the design of an IDE platform
> from a team that is ignorant of editors?
It pretty much indicates they're mostly losers and that Eclipse is
darned near useless too. Clearly it will be a failure. Of course the
facts seem to contradict this conclusion; in my estimation Eclipse saves
me at least one day per week by making me more productive.
>
>
>
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Lack of VI Emulation Is a Signifigent Oversite [message #262899 is a reply to message #262874] Mon, 11 August 2008 19:04 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: bobarror.soco.agilent.com

Thanks Ed,

Your comment regarding the usability of viPlugin within the eclipse
framework is clearly an indication that my fears are unfounded. I have
only used viPlugin at home for working with Python ( pyDev) and I enjoyed
the experience so much that I wanted to be able to do the same thing at
work. Being new to both eclipse and Python yet still able to crank
TupPup.py ( see below) out, with little preparatory planning, in a few
hours totally blew me away.

I did not enjoy the C++ coding that I did with eclipse and CDT at all
because of the editor ( I'm pretty much over my dislike for the travesty
of an OOP language that is C++).

This is exactly why I care so much about the lack of core VI support. I
will update my system to Ganymede and give the combo of eclipse along with
my many GVIM instances a spin to see if I can have the power of VI and the
capabilities of eclipse at the same time. The only other issue would be
integrating our entrenched build system, which is pretty much my puppy so
I do not have far to go to find someone to blame for the mess it make on
the floor as I try migrating to eclipse. BTW, build/distribution systems
are one of my specialties, which I would just as soon abandon as there are
way cooler things to apply parsing to :)

If I find real work after my current contract is up then I would be able
and willing to start putting my time where my fingers are and contribute,
which is really what the correct response to OSS project issues is. I am
not sure where to begin, but Nitin provided some info in his response.


#!/usr/bin/python
############################################################ ###################
# TupPup.py generates integer solutions to a^2 + b^2 = c^2
# written by wolf on 1 Oct 2006
############################################################ ###################
# Functions for my matrix type. Will become part of a matrix class

from operator import *

def isseq(x):
return type(x) in [ list, tuple]

def tupme(x):
if type(x) in [ list, tuple]:
x = tuple([ tupme(i) for i in x])
return(x)

def shape(x):
y=()
if type(x) in [ list, tuple]:
y = y + ( len(x),) + shape(x[0])
return y

def issquare( vtup, stup=None):
if stup == None: stup = shape( vtup)
if not isseq( vtup): vtup = [vtup]

sq = False
for x in vtup:
if ( isseq(x) and ( len(x) != stup[1] or not issquare( x,
stup[1:]) )
or len( stup) > 1): break
else:
sq = True
return sq

def matmult( A, B):
As = shape(A)
Bs = shape(B)
if len(As) == len(Bs) == 2 and As[1] == Bs[0]:
return tuple([ tuple(
[ reduce( add, [ A[a][i]*B[i][b] for i in range( Bs[0]) ])
for b in range(Bs[1]) ]) for a in range( As[0]) ])

def seq(X):
return [ X[i][0] for i in range( len(X))]

############################################################ ###################
# misc support functions that are fairly general but not realy related to
mat

def b3(i):
if i > 0:
return b3( i/3) + [ i%3,]
else:
return []

############################################################ ###################
# Start of programm

# Secret sauce matricies, discovered by wolf years ago
ML = [ [ [ 1, -2, 2], [ 2, -1, 2], [ 2, -2, 3]],
[ [ -2, 1, 2], [ -1, 2, 2], [ -2, 2, 3]],
[ [ 2, 1, 2], [ 1, 2, 2], [ 2, 2, 3]]]

# first two solutions. P0 is the trivial solution. Two different mats
generate
# P1 from P0, so I start from P1 so as not to have two copies of every
solution
P0 = [ [0], [1], [1]]
P1 = [ [3], [4], [5]]

M = tupme(ML)

P = [ tupme(P0), tupme(P1)] # list of solutions
I = [ 0 , 1 ] # list of solution index numbers

m = 2 # matrix number
p = 0 # list index
i = 0 # solution index number

#print M[m], " * ", P[p]
#print "And the answer is ..."
while i < 5000:
p += (m + 1) / 3
m = (m + 1) % 3

Z = matmult( M[m], P[p])
i = 3 * I[p] + m
P.append(Z)
I.append(i)
z = seq(Z)
t = z[1] / float( z[0])
z3 = z[0]**2 + z[1]**2
zt = z[2]**2
print z
print " ", i, "=", b3(i), " : C**2 =", zt, " slope =", t
Re: Lack of VI Emulation Is a Signifigent Oversite [message #262905 is a reply to message #262899] Mon, 11 August 2008 19:26 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 31909
Registered: July 2009
Senior Member
Robert,

If you ever want to get involved, there are plenty of people like me who
will be more than happy to help facilitate that. May all your regular
expressions match only their intended targets. :-)


Robert Barror wrote:
> Thanks Ed,
>
> Your comment regarding the usability of viPlugin within the eclipse
> framework is clearly an indication that my fears are unfounded. I have
> only used viPlugin at home for working with Python ( pyDev) and I
> enjoyed the experience so much that I wanted to be able to do the same
> thing at work. Being new to both eclipse and Python yet still able to
> crank TupPup.py ( see below) out, with little preparatory planning, in
> a few hours totally blew me away.
>
> I did not enjoy the C++ coding that I did with eclipse and CDT at all
> because of the editor ( I'm pretty much over my dislike for the
> travesty of an OOP language that is C++).
> This is exactly why I care so much about the lack of core VI support.
> I will update my system to Ganymede and give the combo of eclipse
> along with my many GVIM instances a spin to see if I can have the
> power of VI and the capabilities of eclipse at the same time. The only
> other issue would be integrating our entrenched build system, which is
> pretty much my puppy so I do not have far to go to find someone to
> blame for the mess it make on the floor as I try migrating to eclipse.
> BTW, build/distribution systems are one of my specialties, which I
> would just as soon abandon as there are way cooler things to apply
> parsing to :)
> If I find real work after my current contract is up then I would be
> able and willing to start putting my time where my fingers are and
> contribute, which is really what the correct response to OSS project
> issues is. I am not sure where to begin, but Nitin provided some info
> in his response.
>
>
> #!/usr/bin/python
> ############################################################ ###################
>
> # TupPup.py generates integer solutions to a^2 + b^2 = c^2
> # written by wolf on 1 Oct 2006
> ############################################################ ###################
>
> # Functions for my matrix type. Will become part of a matrix class
>
> from operator import *
>
> def isseq(x):
> return type(x) in [ list, tuple]
>
> def tupme(x):
> if type(x) in [ list, tuple]:
> x = tuple([ tupme(i) for i in x])
> return(x)
>
> def shape(x):
> y=()
> if type(x) in [ list, tuple]:
> y = y + ( len(x),) + shape(x[0])
> return y
>
> def issquare( vtup, stup=None):
> if stup == None: stup = shape( vtup)
> if not isseq( vtup): vtup = [vtup]
>
> sq = False
> for x in vtup:
> if ( isseq(x) and ( len(x) != stup[1] or not issquare( x,
> stup[1:]) )
> or len( stup) > 1): break
> else:
> sq = True
> return sq
>
> def matmult( A, B):
> As = shape(A)
> Bs = shape(B)
> if len(As) == len(Bs) == 2 and As[1] == Bs[0]:
> return tuple([ tuple(
> [ reduce( add, [ A[a][i]*B[i][b] for i in range( Bs[0]) ])
> for b in range(Bs[1]) ]) for a in range( As[0]) ])
>
> def seq(X):
> return [ X[i][0] for i in range( len(X))]
>
> ############################################################ ###################
>
> # misc support functions that are fairly general but not realy related
> to mat
>
> def b3(i):
> if i > 0:
> return b3( i/3) + [ i%3,]
> else:
> return []
>
> ############################################################ ###################
>
> # Start of programm
>
> # Secret sauce matricies, discovered by wolf years ago
> ML = [ [ [ 1, -2, 2], [ 2, -1, 2], [ 2, -2, 3]],
> [ [ -2, 1, 2], [ -1, 2, 2], [ -2, 2, 3]],
> [ [ 2, 1, 2], [ 1, 2, 2], [ 2, 2, 3]]]
>
> # first two solutions. P0 is the trivial solution. Two different mats
> generate
> # P1 from P0, so I start from P1 so as not to have two copies of every
> solution
> P0 = [ [0], [1], [1]]
> P1 = [ [3], [4], [5]]
>
> M = tupme(ML)
>
> P = [ tupme(P0), tupme(P1)] # list of solutions
> I = [ 0 , 1 ] # list of solution index numbers
>
> m = 2 # matrix number
> p = 0 # list index
> i = 0 # solution index number
>
> #print M[m], " * ", P[p]
> #print "And the answer is ..."
> while i < 5000:
> p += (m + 1) / 3
> m = (m + 1) % 3
>
> Z = matmult( M[m], P[p])
> i = 3 * I[p] + m
> P.append(Z)
> I.append(i)
> z = seq(Z)
> t = z[1] / float( z[0])
> z3 = z[0]**2 + z[1]**2
> zt = z[2]**2
> print z
> print " ", i, "=", b3(i), " : C**2 =", zt, " slope =", t
>
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Lack of VI Emulation Is a Signifigent Oversite [message #262916 is a reply to message #262824] Tue, 12 August 2008 00:36 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: bobarror.soco.agilent.com

Hi Nitin,

My comments about eclipse being mostly a platform for Java development
does not imply that it is only for that. But the facts remain that the
core of eclipse targets Java development first and anything else
secondarily. A quick look at all of the top level projects shows just
that. Support for other languages lags. Last I checked, (3.1) CDT did not
do everything that Java developers could do. This does not bother me and
is quit reasonable, as a language had to be chosen and support for that
language would get added first. Besides, Java is a fine choice for this
type of system. Java is also a pretty good instantiation of an abstract OO
language so any work done to support it would most likely map directly
onto other reasonable languages. I probably would have chosen Ada or
Python or lisp (just kidding) for writing the system and used Java
development to define the basis of the problem space. BTW, I detest C++
and would never willingly choose to use it for anything.

Also I never said that the work of the eclipse team was garbage. Only that
they had made a mistake. I make mistake. By recognizing those mistakes for
what they are, and analyzing why they occurred, I learn new things and
become stronger.

What I called garbage is CUI which only exists in this century because ms
commands it to be so. It really is a stupid hack and ever disparaging
thing I say about it is absolutely valid.

BTW, you are not the first to notice that my language can tend to be a bit
strong, especially when it is used to discuss issues that require accuracy
and candor. So readers often apply an emotional context that does not
exist. I do not understand this very well and when I try to take it into
account, I end up with sentences that have little real meaning. I don't
have much use with unclear circumlocutions. I am aware that this tendency
works to my disfavor because of the current trend to be okay with ignoring
quality and pampering weakness. I do try to maintain awareness of this
problem when I write, but it does get lost in the desire to accurately
express myself. I could give you some example of what I write when I
really am flaming, but I'd rather not because the mode that I use for that
stuff is not fun for me to be in anymore. On the other hand, the sentences
in my post concerning ms, do exemplify the type of language I like to use
when I am expressing the dislike that you think I am expressing for the
eclipse team.
Re: Lack of VI Emulation Is a Signifigent Oversite [message #262918 is a reply to message #262761] Tue, 12 August 2008 04:17 Go to previous messageGo to next message
Russell Bateman is currently offline Russell BatemanFriend
Messages: 3798
Registered: July 2009
Location: Provo, Utah, USA
Senior Member

vi emulation isn't quite enough to make vi useful. In Codewright and
Visual Slick Edit as well as in the Eclipse vi plugin (whose license fee I
paid almost 3 years ago), being able to use vi commands is good, but
where's the .exrc support? To fly in vi, you have to be able to use
remappings and macros. These mere emulations are like trying to fly
through a tunnel no wider than your wings.

And, you need regular expressions, at least a comfortable subset.

What is really needed is for Bram Molenaar to get Eclipse as his religion
and create a full-octane Vim plugin. Then I wouldn't spend my time doing
"real" or heavy-duty editing outside of Eclipse.

This said, the completion and resident available doc in a modern
environment like Eclipse, Visual Studio and NetBeans far outstrips
anything we've seen in Vim. So does the mouse support.

It wouldn't matter to me, as it probably doesn't to 90% of Eclipse users,
if I weren't a vi user since the early 1980s.

Russ Bateman
Re: Lack of VI Emulation Is a Signifigent Oversite [message #262921 is a reply to message #262918] Tue, 12 August 2008 05:41 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: bobarror.soco.agilent.com

Hi Russ,

I have use viPlugin at home to write my first Python scripts. I did not
notice that there was not any support for macros because I was not
familiar enough with Python to know what I would need. I have used Visual
SlickEdit on HP-UX, but there again I did not try to do any macros as I
was evaluating how well the tool fit in with my work flow. I never adopted
it because I like working with 20 or more files simultaneously and
SlickEdit made this difficult on an old HP B180 I was using. I have a
licensed copy of v10 for Linux, but have not had the time to play with it.
My impression is that it is an excellent tool.

When it comes to tools, I tend to the most basic. Gvim is about the most
complicated thing I use. So moving to an IDE, even a good one, seems a bit
constraining. I'm a tool maker and not a tool user by nature. I almost
never use debuggers as I can look at the source and run it in my head just
fine. The call me mister printf at work. I like the basic concept of IDEs
and have created some myself, generally by creating sets of ksh scripts
driving terms running debuggers, vi editors, and other stuff I created
that can be used together trough pipes. Kinda cheesy really, but very
modular. I never thought I would ever want an IDE to work in, then eclipse
came around. I tell ya, If I was to design a proper IDE it would be just
like eclipse. I.e., a platform based around plugins ... too cool! And
after my experience using it to write my very first Python program, I
think I'm hooked

Now that I have learned all of he stuff that I have regarding the design
of eclipse, I realize that creating a plugin for the powerhouse that is
VIM is truly the way to go.

I am now sort of glad that eclipse did not try to natively support VI. I
am also very glad to find that the lack of VI support within eclipse is
not an indication of systemic problems with either the code or the design
process and that key members of the community do use VI. The whole point
of my original post was to find this stuff out. I was hoping that my
original impressions were wrong :) The eclipse team exhibits some of the
highest levels of professionalism I have seen.

BTW, I have been using vim almost 10 years. I have lost count of how many
times I compiled it for HP-UX. I believe I have the skill and experience
to do the work necessary to assist in creating an eclipse plugin for it.
As soon as I free up some time, I plan on getting involved to do just
that. I have been wanting to contribute to the community for over a
decade, and this looks like the perfect project. I have an itch and I have
a hand to scratch it. And the thought of the possibility of working with
two of the very best OSS projects is very exciting. I will try to get in
touch with Bram to get his opinion of all of this. I seem to remember that
VIM is designed to be able to be used as a plugin.

Thanks for suppling the last piece of data I need to reach this conclusion,

bob
Re: Lack of VI Emulation Is a Signifigent Oversite [message #262923 is a reply to message #262905] Tue, 12 August 2008 07:40 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: bobarror.soco.agilent.com

Thanks for helping me to find out what I needed to know. The eclipse
project is well worth devoting time and energy on. I will probably be able
to get something going in the Nov-Dec time frame. Until then, I'll do some
research and get refamiliar with Java. I am looking to try and create a
eclipse plugin for vim. I am going to try to contact Bram Moolenaar to get
his opinion.

This will be a warm up project because what I really want to do is a major
RCP project that will take a year or two to get to a pre-release. A
contract extension or a job offer would put this on hold again .... then
again, I could get a decent position in a different industry. If not
working on the plugin might reveal another task that has enough meat on it
to keep my ADD/asperger addled mind focused and that is also orthogonal to
my current industry of choice.

thanks again,

bob

P.S. I think I found an alternate RCP project and its actual the same as
the first. Its funny that from a parsing point of view a lot of problem
spaces that do not appear related are actually equivalent if abstracted
properly. Cool!
Re: Lack of VI Emulation Is a Signifigent Oversite [message #263021 is a reply to message #262923] Tue, 12 August 2008 11:26 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 31909
Registered: July 2009
Senior Member
Robert,

Comments below.

Robert Barror wrote:
> Thanks for helping me to find out what I needed to know. The eclipse
> project is well worth devoting time and energy on. I will probably be
> able to get something going in the Nov-Dec time frame. Until then,
> I'll do some research and get refamiliar with Java. I am looking to
> try and create a eclipse plugin for vim. I am going to try to contact
> Bram Moolenaar to get his opinion.
I could imagine a vim-type editor being a great alternative to the plain
text editor. When editing Java though, for me it would be really
important for it to be integrated with the JDT's editor. I've grown to
depend on things like Ctrl+Space as much as I do on "i" and "esc".
>
> This will be a warm up project because what I really want to do is a
> major RCP project that will take a year or two to get to a
> pre-release. A contract extension or a job offer would put this on
> hold again ....
I hope the fire you then. :-P
> then again, I could get a decent position in a different industry. If
> not working on the plugin might reveal another task that has enough
> meat on it to keep my ADD/asperger addled mind focused and that is
> also orthogonal to my current industry of choice.
There's a lot happening in the Eclipse ecosystem. Experts have are quite
valuable I've found...
>
> thanks again,
>
> bob
>
> P.S. I think I found an alternate RCP project and its actual the same
> as the first. Its funny that from a parsing point of view a lot of
> problem spaces that do not appear related are actually equivalent if
> abstracted properly. Cool!
The modeling project is doing some interesting work in this space; the
textual modeling framework subproject specifically. Support for human
readable serializations of models is a great alternative to the
inexcusable machine-oriented focus of XML that for some bizarre reason
has far too many people in a daze.
>
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Lack of VI Emulation Is a Signifigent Oversite [message #263022 is a reply to message #262916] Tue, 12 August 2008 11:39 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 31909
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------000903000400060707040501
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Robert,

Comments below.

Robert Barror wrote:
> Hi Nitin,
>
> My comments about eclipse being mostly a platform for Java development
> does not imply that it is only for that.
It's indeed a perception problem and in my opinion not nearly enough if
being done to change it. You go to the download page and see three
flavors of Java and it's clear that this perception is being reinforced:
<http://www.eclipse.org/downloads/>

http://www.eclipse.org/downloads/

Some of us are trying hard to change this perception.
> But the facts remain that the core of eclipse targets Java development
> first and anything else secondarily.
It's true.
> A quick look at all of the top level projects shows just that. Support
> for other languages lags. Last I checked, (3.1) CDT did not do
> everything that Java developers could do.
It probably never will simply based on the momentum and head start of
JDT, but CDT is a very cool thing.
> This does not bother me and is quit reasonable, as a language had to
> be chosen and support for that language would get added first.
> Besides, Java is a fine choice for this type of system. Java is also a
> pretty good instantiation of an abstract OO language so any work done
> to support it would most likely map directly onto other reasonable
> languages. I probably would have chosen Ada
Oh no!
> or Python or lisp (just kidding)
You missed Smalltalk! :-P
> for writing the system and used Java development to define the basis
> of the problem space. BTW, I detest C++ and would never willingly
> choose to use it for anything.
I had to work on an IDE for it for many years and just as it was getting
read to go to market, Java came along. I like all languages, but some
of them I like to criticize too.
>
> Also I never said that the work of the eclipse team was garbage.
I looked for that comment. I would have bitch slapped you for such a
comment. :-P
> Only that they had made a mistake. I make mistake. By recognizing
> those mistakes for what they are, and analyzing why they occurred, I
> learn new things and become stronger.
We all make mistakes. Well, not me so much, but other people certainly...
>
> What I called garbage is CUI which only exists in this century because
> ms commands it to be so. It really is a stupid hack and ever
> disparaging thing I say about it is absolutely valid.
Kind of like XML is a totally sad excuse for human readable syntax.
>
> BTW, you are not the first to notice that my language can tend to be a
> bit strong, especially when it is used to discuss issues that require
> accuracy and candor.
I would absolutely never overstate things myself. Oh wait, I think I
just did...
> So readers often apply an emotional context that does not exist.
I've noticed folks read between the line. I like to type between them. :-P
> I do not understand this very well and when I try to take it into
> account, I end up with sentences that have little real meaning.
I think if you look really closely, there are emotion packed words.
It's also important to make clear when you attack ideas as opposed to
the holder of those ideas...
> I don't have much use with unclear circumlocutions. I am aware that
> this tendency works to my disfavor because of the current trend to be
> okay with ignoring quality and pampering weakness.
I recall another exchange I had with someone where he complained about
the emotional neediness of others.
> I do try to maintain awareness of this problem when I write, but it
> does get lost in the desire to accurately express myself. I could give
> you some example of what I write when I really am flaming, but I'd
> rather not because the mode that I use for that stuff is not fun for
> me to be in anymore.
I've learned the hard way to avoid ever deliberately putting strong
negative emotional content it a note. I'm way too good at it. :-P
Notes have a way of allowing one to say things without seeing the face
of the person receiving the information and hence somehow seems to
encourage us to do things we would never do to someone's face.
> On the other hand, the sentences in my post concerning ms, do
> exemplify the type of language I like to use when I am expressing the
> dislike that you think I am expressing for the eclipse team.
See what I mean about expressing things about the team rather than about
their work. It's hard enough to have our work criticized, but direct
personal criticism is generally going to get you the same in return. It
will ultimately be completely fruitless...

I'm glad you've taken a positive track though...
>
>
>
>
>

--------------000903000400060707040501
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Robert,<br>
<br>
Comments below.<br>
<br>
Robert Barror wrote:
<blockquote
cite="mid:c3ecd1885b5bdb75a0738b2c432f7b84$1@www.eclipse.org"
type="cite">Hi Nitin,
<br>
<br>
My comments about eclipse being mostly a platform for Java development
does not imply that it is only for that. </blockquote>
It's indeed a perception problem and in my opinion not nearly enough if
being done to change it.


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Lack of VI Emulation Is a Signifigent Oversite [message #263029 is a reply to message #263022] Tue, 12 August 2008 18:25 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: bobarror.soco.agilent.com

Hi Ed,

I was having a pretty good morning until I read your post.

Now I'm having a magnificent morning.

Tanks :)

P.S. I wrote Smalltalk first, but changed it to lisp. I'd never seriously
do something like this in lisp, but I might actually consider Smalltalk
(maybe I should not be admitting such things, oh wait I already indicated
I like Ada. Oh well, there goes my software career).
Re: Lack of VI Emulation Is a Signifigent Oversite [message #263031 is a reply to message #263022] Tue, 12 August 2008 21:29 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: dcarver.starstandard.org

Ed Merks wrote:
> Kind of like XML is a totally sad excuse for human readable syntax.

Now those are fighting words! :) Angle brackets at twenty paces at
noon. :)

Dave
Re: Lack of VI Emulation Is a Signifigent Oversite [message #263032 is a reply to message #263031] Tue, 12 August 2008 21:43 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 31909
Registered: July 2009
Senior Member
Dave,

I'll match your brackets, <x></x>, against my brackets, {}, anywhere,
any time. We'll start by seeing how well % works for you! Hehehe.


David Carver wrote:
> Ed Merks wrote:
>> Kind of like XML is a totally sad excuse for human readable syntax.
>
> Now those are fighting words! :) Angle brackets at twenty paces at
> noon. :)
>
> Dave


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Lack of VI Emulation Is a Signifigent Oversite [message #263033 is a reply to message #263032] Tue, 12 August 2008 21:59 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: eclipse-news.rizzoweb.com

Ed Merks wrote:
> Dave,
>
> I'll match your brackets, <x></x>, against my brackets, {}, anywhere,
> any time.

And I'll gladly put my [] up against either one any day of the week and
twice on Sunday.
Long live Smalltalk!

Eric


> David Carver wrote:
>> Ed Merks wrote:
>>> Kind of like XML is a totally sad excuse for human readable syntax.
>>
>> Now those are fighting words! :) Angle brackets at twenty paces at
>> noon. :)
>>
>> Dave
Re: Lack of VI Emulation Is a Signifigent Oversite [message #263035 is a reply to message #263032] Tue, 12 August 2008 23:09 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: nowhere.a.com

Ed Merks wrote :
> Dave,
>
> I'll match your brackets, <x></x>, against my brackets, {}, anywhere, any
> time. We'll start by seeing how well % works for you! Hehehe.
>
>
> David Carver wrote:
>> Ed Merks wrote:
>>> Kind of like XML is a totally sad excuse for human readable syntax.
>>
>> Now those are fighting words! :) Angle brackets at twenty paces at noon.
>> :)

Be happy you are not using tri-graphs...

--
Wojtek :-)
Re: Lack of VI Emulation Is a Signifigent Oversite [message #263118 is a reply to message #263031] Thu, 14 August 2008 01:10 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: lhasadad.gmail.google.com

Be careful Dave. Ed will take a model framework and knock you senseless.

David Carver wrote:
> Ed Merks wrote:
>> Kind of like XML is a totally sad excuse for human readable syntax.
>
> Now those are fighting words! :) Angle brackets at twenty paces at
> noon. :)
>
> Dave
Re: Lack of VI Emulation Is a Signifigent Oversite [message #263124 is a reply to message #263118] Thu, 14 August 2008 03:50 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: dcarver.starstandard.org

Yeah, I'll just have to pull out DOM Level 1, Level 2, and Level 3. :)

Or maybe I'll just deflect it with Dave Carlson's XML Profile for UML.

Dave

Bill Trautman wrote:
> Be careful Dave. Ed will take a model framework and knock you senseless.
>
> David Carver wrote:
>> Ed Merks wrote:
>>> Kind of like XML is a totally sad excuse for human readable syntax.
>>
>> Now those are fighting words! :) Angle brackets at twenty paces at
>> noon. :)
>>
>> Dave
Re: Lack of VI Emulation Is a Signifigent Oversite [message #264383 is a reply to message #263021] Tue, 16 September 2008 22:09 Go to previous messageGo to next message
Anton Sharonov is currently offline Anton SharonovFriend
Messages: 2
Registered: July 2009
Junior Member
Ed Merks wrote:

> You might have gotten the best of both. What vi is not great at
> doing is navigating between files, e.g., given the use of an
> identifier, finding the one the compiler considers its
> declaration. As Derek argued, its good to use the right tool
> for the right job...

This is just not true. Using vim + ctags you can very easy navigate to
the definitions of any class, using normal tags functionality.
You can even jumpt to any _function_ of class, provided that they
are called somehow more unique than just "load" or "run" or
whatever (otherwise you will have to select one of 100 matches
using :tselect or do 100 times :tn :tn :tn ...). You can use
wildcards in tag names as well - :tag M*C*Na<TAB> will expand to
MyClassName... For the scope / class variables it is always gd gD
good enough to navigate to their definitions. I feel me very
comfortable navigating large java project with vim.


What is really missing (partly, see <C-P>, <C-X><C-P>, <C-X><C-L>
etc) is completion, compiler output, refactoring, possibility to
run junit tests, ... Partly those features are already available
from vim using eclim - headless usage of eclipse libraries for
vim. Headed usage (concurrent access to same workspace from eclim
and running eclipse) is still impossible, but I'm sure it is just
a matter of time.

Vim'ers, don't give up, we will survive :)
Re: Lack of VI Emulation Is a Signifigent Oversite [message #264450 is a reply to message #264383] Wed, 17 September 2008 14:57 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 31909
Registered: July 2009
Senior Member
Anton,

Comments below.

Anton Sharonov wrote:
> Ed Merks wrote:
>
>> You might have gotten the best of both. What vi is not great at
>> doing is navigating between files, e.g., given the use of an
>> identifier, finding the one the compiler considers its
>> declaration. As Derek argued, its good to use the right tool
>> for the right job...
>
> This is just not true. Using vim + ctags you can very easy navigate to
> the definitions of any class, using normal tags functionality.
> You can even jumpt to any _function_ of class, provided that they
> are called somehow more unique than just "load" or "run" or
> whatever (otherwise you will have to select one of 100 matches
> using :tselect or do 100 times :tn :tn :tn ...). You can use
> wildcards in tag names as well - :tag M*C*Na<TAB> will expand to
> MyClassName... For the scope / class variables it is always gd gD
> good enough to navigate to their definitions. I feel me very
> comfortable navigating large java project with vim.
Surely you can't argue that vim can do much beyond a poor man's version
of the deep semantic knowledge of JDT? After all, JDT can find the
exact overload that's being used and can find it even if it's in an
installed plugin's source bundle.
>
> What is really missing (partly, see <C-P>, <C-X><C-P>, <C-X><C-L>
> etc) is completion, compiler output, refactoring, possibility to
> run junit tests, ... Partly those features are already available
> from vim using eclim - headless usage of eclipse libraries for
> vim. Headed usage (concurrent access to same workspace from eclim
> and running eclipse) is still impossible, but I'm sure it is just
> a matter of time.
>
> Vim'ers, don't give up, we will survive :)
Typically survival involves evolution...
>
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Lack of VI Emulation Is a Signifigent Oversite [message #264470 is a reply to message #264450] Wed, 17 September 2008 20:42 Go to previous messageGo to next message
Anton Sharonov is currently offline Anton SharonovFriend
Messages: 2
Registered: July 2009
Junior Member
Ed Merks wrote:

> Surely you can't argue that vim can do much beyond a poor man's version
> of the deep semantic knowledge of JDT? After all, JDT can find the
> exact overload that's being used and can find it even if it's in an
> installed plugin's source bundle.

I can't of course recognize different overloads. And even more
annoying, that I can't sometimes jump to real function
definitions, if there are several functions with the same name in
different classes (what is pretty often the case in OO
languages). But as praxis showed to me, I personally anyway
rarely need this kind of precision (I still need it sometimes,
indeed). But for "poor man's version" the VIM+ctags navigation
works surprisingly well - at least I am satisfied with that. And
I can do it on non-compilable sources as well. And it works
seamlessly with my C++ code. And I can just jump directly to
function by it's name (of course if it unique enough) - in
Eclipse I don't know any possibility to find the _function_ by
name directly, other than to first locate it's class, than open
outline and look for function. And I can mix together tags of
several workspaces using just trivial "set
tags+=/path/to/another_workspace/tags".

BTW, outliner. Somewhere in this thread IIRC, I have saw that
with VI you have no outline. This is also not true: simple
command :Tlist and I see all function definitions on the left
side of my VIM window. This is done with well known taglist.vim
[1] plugin (for all possible languages: Assembly, ASP, Awk, Beta,
C, C++, C#, Cobol, Eiffel, Erlang, Fortran, HTML, Java,
Javascript, Lisp, Lua, Make, Pascal, Perl, PHP, Python, Rexx,
Ruby, Scheme, Shell, Slang, SML, Sql, TCL, Verilog, Vim and
Yacc).

>> Vim'ers, don't give up, we will survive :)

> Typically survival involves evolution...

Exactly what I think as well :) It is clear that "plane vim" can
be used as a solid basis for daily plane text editing, but it
will lack high level features (not navigating, it is done IMO
well enough already), but code completion, refactoring and JIT
compiling. We can in fact already "upgrade" vim to something
incredible cool, just by installing eclim. (Significant problem
of eclim at the moment that you must close eclipse on this
workspace - it isn't yet possible to quickly do something in
eclipse and than switch back to VIM) Obviously the way to go is
to improve the usability of the eclipse core features from within
vim. For my personal taste, VIM have more power and just used
better if integrated with headless eclipse, like it is done by
eclim [2] project. But another way also has it's own advantages -
there is vimplugin [3] project, which tries to embed vim as yet
another editor directly into eclipse GUI.

[1] taglist.vim
http://vim-taglist.sourceforge.net/index.html

[2] eclim
http://eclim.sourceforge.net/

[3] vimplugin
http://vimplugin.org/

Anton.
Re: Lack of VI Emulation Is a Signifigent Oversite [message #790671 is a reply to message #262827] Sat, 04 February 2012 16:51 Go to previous message
Dotan Cohen is currently offline Dotan CohenFriend
Messages: 23
Registered: January 2011
Junior Member
Eclipse User wrote on Sun, 10 August 2008 16:57
Originally posted by: v_the_gaul.gmail.com

4 months to generate 143 characters?

Yup, that's one great tool ya got there. Feel free to count me amongst
the ignorant unwashed masses.


Obviously typing 143 characters does not take four months. But deciding _which_ 143 characters to type does!
Previous Topic:Help! Content Assist disappears
Next Topic:dynamic web project
Goto Forum:
  


Current Time: Sun Jun 20 05:01:13 GMT 2021

Powered by FUDForum. Page generated in 0.09732 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top