Why SlickEdit is superior to VIM and Emacs combined!
nospam
for editors, IMHO. I use all three editors -- VIM, XEmacs,
and SlickEdit. I've used all three for years, but always
find the feature sets of XEmacs and VIM lacking compared
to SlickEdit. I'm not saying they're bad editors, but If
you've never used SlickEdit, then you'll never know what
you are missing. Here's just a partial list to make
my case. Let the editor wars begin!
-C/C++ like scripting language (Slick-C) to extend editor.
VIM's scripting capability is far inferior, and LISP with
it's plethora of parenthesis is downright ugly!
-Stores encrypted SSH passwords for remote file access (Unlike TRAMP
or VIM). Get with it!
-Simple to use custom menu editor.
-User defined dialog boxes, can set multiple parameters simultaneously.
-Has superior "tags" facility -- Far superior!
-Really cool auto code completion.
-Automatic make file generator (Or use existing Makefile to manage
your project)
-GNU C/C++ wizard -- Very cool.
-Project management - Get with it Emacs and VIM! I still can't
believe XEmacs and VIM lack project management! For VIM I found
some 4 year old script that's a lame attempt at this.
-Modern GUI interface. XEmacs GUI components are UGLY!
-Integrated version control including CVS, Subversion, GNU RCS,
and many more.
-C/C++ and Java refactoring.
-Superior C/C++/Java debugging. The debugger is exceptional.
-Handles large files much better than vim or emacs. It's fast!
-Java GUI builder.
-Runs on virtually any platform too.
-Support is far superior. If I find a bug, I report it to SlickEdit
support, and they usually email a script with the fix the same day!
Jussi Jumppanen
> Let the editor wars begin!
Ok, lets see how Zeus compares to Slick Edit.
> -C/C++ like scripting language (Slick-C) to extend editor.
Zeus allows you to write scripts using the Python, Lua, VbScript,
JavaScript or Ruby scripting languages.
> VIM's scripting capability is far inferior, and LISP with
> it's plethora of parenthesis is downright ugly!
No comment :)
> -Stores encrypted SSH passwords for remote file access (Unlike TRAMP
> or VIM). Get with it!
Zeus has no trouble editing SSH, TLS/SSL or just plaing old FTP.
> -Simple to use custom menu editor.
> -User defined dialog boxes, can set multiple parameters
> simultaneously.
Ok, you win with these :)
> -Has superior "tags" facility -- Far superior!
Zeus does automatic ctags management via the project workspace. It
also displays the tags information in a class browser tree.
> -Really cool auto code completion.
Zeus has limited auto complete based on the tags information. In
the next release the auto complete and tag management is further
improved.
> -Automatic make file generator (Or use existing Makefile to manage
> your project)
> -GNU C/C++ wizard -- Very cool.
You win again :)
> -Project management - Get with it Emacs and VIM! I still can't
> believe XEmacs and VIM lack project management! For VIM I found
> some 4 year old script that's a lame attempt at this.
Zeus has full project/workspace management.
> -Modern GUI interface. XEmacs GUI components are UGLY!
Zeus has Modern MDI GUI interface.
> -Integrated version control including CVS, Subversion, GNU RCS,
> and many more.
Zeus has integrated version control including CVS.
> -C/C++ and Java refactoring.
> -Superior C/C++/Java debugging. The debugger is exceptional.
> -Handles large files much better than vim or emacs. It's fast!
> -Java GUI builder.
I'll also concede these, apart from the fast bit of course :)
> -Runs on virtually any platform too.
Zeus is only for windows.
I am assuming Slick Edit also has the your stock standard edito
features like code folding, syntax highlighting, configurable
keyboard mappings, templates, tools etc.
Jussi Jumppanen
Author of: Zeus for Windows (New version 3.94 out now)
"The C/C++, Cobol, Java, HTML, Python, PHP, Perl folding editor"
Home Page: http://www.zeusedit.com
Nall-ohki
> -C/C++ like scripting language (Slick-C) to extend editor.
> VIM's scripting capability is far inferior,
Tell me in what way it's inferior? Is C++ inferior to Java? (or the
other way around?)
What can you do in your scripting language that you can't do in VIM's?
Last time I checked, it was turing complete.
> and LISP with it's plethora of parenthesis is downright ugly!
Not an Emacs supporter, but this is merely a matter of taste.
Functional programming has its advantages.
> -Stores encrypted SSH passwords for remote file access (Unlike TRAMP
> or VIM). Get with it!
Without looking, I'm pretty sure I could find someone somewhere that
has written a script to do this in VIM.
> -Simple to use custom menu editor.
Saying something is superior because it's "simple" is kinda missing the
point of VIM (read below).
> -User defined dialog boxes, can set multiple parameters simultaneously.
Admittedly VIM doesn't do this natively, but again... scripts can be
written.
> -Has superior "tags" facility -- Far superior!
Explain. ctags works pretty well aside from the sometimes-annoying
setup, but after that it works like a charm.
> -Really cool auto code completion.
Not going to comment on "really cool", because it's subjective. If
you're looking for something beyond the basic code completion, again,
there are plenty of options out there (IntelliSense for VIM for one).
> -Automatic make file generator (Or use existing Makefile to manage your project)
> -GNU C/C++ wizard -- Very cool.
> -Project management - Get with it Emacs and VIM! I still can't believe XEmacs and VIM lack project management! For VIM I found some 4 year old script that's a lame attempt at this.
Not sure these qualify as something that should be bundled in a text
editor per se... it sounds a lot more like something you'd want in a
programming suite. VIM IS NOT A PROGRAMMING SUITE. It never intended
to be.
Remember kids: you're reading the comp.editors group!
> -Modern GUI interface. XEmacs GUI components are UGLY!
Can't comment. Again, ugly is a subjective. GUI interface is only
useful when used in a windowing environment. My guess is your editor
can't run on just about any terminal in existance. This IS VERY
IMPORTANT to some people.
> -Integrated version control including CVS, Subversion, GNU RCS, and many more.
Jesus. This is the last thing I want my text editor doing.
> -C/C++ and Java refactoring.
A nice feature. One that is very language-specific, easily done
through a script.
> -Superior C/C++/Java debugging. The debugger is exceptional.
Not sure what you mean by debugging in this case... are you saying that
your "text editor" actually has a compiler? You're pushing the bounds
of what an "editor" is there.
> -Handles large files much better than vim or emacs. It's fast!
Again, you're pulling things out of nowhere. Just for kicks, I created
a 6 million line file on VIM. Aside from about 4 seconds of load time,
and a bit longer while saving, navigating the file was fast, and
performing actions on it was reasonable for the file size.
I'd like to see some numbers to back up your statement.
> -Java GUI builder.
Whoa! This is just overboard. This is NOT a text-editor. This is
obviously programming suite. Again, you're missing the point.
> -Runs on virtually any platform too.
Does it operate in a non-gui environment? Over telnet? SSH? Is there
a port for Amiga? No, then it does not operate on "virtually any
platform." Sorry.
> -Support is far superior. If I find a bug, I report it to SlickEdit support, and they usually email a script with the fix the same day!
Last time I found a bug in VIM (involving multi-byte character
support), I received an email within 6 hours with the bug fix included.
I recompiled and everything worked great, and it was subsequently
included in further version.
---
I think you're missing the point when it comes to VIM. Vim is made to
be small, fast, extremely flexible and powerful, and above all A TEXT
EDITOR.
The options your're describing are things that I would definately
consider nice features in a programming suite where all I do is code
C++ or Java all day, but not in a text editor. They would merely annoy
me in the same way Word annoys me for doing anything but creating
pretty documents (and even then some). You're describing apples and
oranges and exposing your ignorance of the other text editors out there
in the process.
The advantage VIM has is that it CAN do anything, but doesn't do it
unless you want it to. It can act any way you choose, but doesn't
bloat itself in the process.
This reply written in VIM
Brian Masinick
(yes, I know that I am "top posting". Some groups use this approach;
others discourage or even forbid it. I usually either intersperse
comments or post below, but this time I am posting my comments up
on top. I'll include any responses to specific comments interspersed
within the previous texts).
My fundamental comment is that a proprietary tool had better provide
at least a few, preferably quite a few, compelling reasons to pay
good money for something that I can easily use for no cost.
There are scads of what I consider to be really good text editors
out there that are available for absolutely no cost.
Vi and Emacs (referring to them first in a kind of generic way) are
applications that have been around a very long time. Because of
that, their default interfaces, especially the behaviors that are
legacy features, are aged. To some, that is a disadvantage.
To others, that spells consistency, no matter where you go.
Vim and GVim are modern rewrites that add considerably to what
was once a pretty bare (but also pretty fast and capable) text
editor. Vim is still relatively modest in size, though it is
pretty large and complicated when compared to the smallest
and simplest of text editors.
Emacs, in GNU Emacs, XEmacs, and Micro Emacs forms, are also
extremely capable tools. Unlike their Vi counterparts, however,
none of them are merely text editors, that is but one of their
functions. In that sense, the Emacs variants are more comparable
to SlickEdit than Vi and other pure text editors.
Emacs represents an extensible development environment because
of the inclusion of Emacs Lisp. Micro Emacs is not quite as
extensible as GNU Emacs and XEmacs, but it is considerably lighter
in size and still very capable as an extensible editing tool.
Editing preferences are just that, preferences.
Without a doubt, SlickEdit has much to offer.
The question we all have to ask ourselves is to what extent
is what it has to offer worth the asking price? If our
bosses pay for it, chances are many more of us would be
interested in trying it out. At home, how many of us are
STILL willing to shell out the money to get it, particularly
when that may involve buying new versions periodically. Does
it still justify the expense? For some, the answer may be yes.
Rather than debate that, I'd be glad to concede that. I would
simply be interested in knowing why
> Okay... lots of psuedo logic here...
>>-C/C++ like scripting language (Slick-C) to extend editor.
>> VIM's scripting capability is far inferior,
> Tell me in what way it's inferior? Is C++ inferior to Java? (or the
> other way around?)
I'm not sure I understand the reference to C++ and Java. C++ is a
full fledged, compiled programming language with both procedural
and object oriented capabilities. Java is primarily an interpretive
object oriented language (though there are a few compiler based
implementations available). My question, though, is what does that
have to do with comparing Vim and SlickEdit?
> What can you do in your scripting language that you can't do in VIM's?
> Last time I checked, it was turing complete.
>>and LISP with it's plethora of parenthesis is downright ugly!
> Not an Emacs supporter, but this is merely a matter of taste.
> Functional programming has its advantages.
I agree. Lisp has never caught on with mass appeal, but it certainly
has its place, and Emacs Lisp provides an extremely powerful and
extensive interpretive language from which you can write entire
applications. It's main limitation is that, for whatever reasons,
multi threaded support has never been added, so when you start
multiple applications from an Emacs session, you can use only one
of them at any given time unless you invoke multiple instances of
the Emacs image.
Emacs Lisp also doesn't provide machine level code, so you really
can't create an operating system from Emacs, in spite of jokes to
the contrary! ;-)
>>-Simple to use custom menu editor.
Simple is kind of a relative term. There are many "simple" things
that you can do with Emacs, Vim, and many other text editors.
What is easy and convenient depends to a great degree on your
personal interests and orientation.
> Saying something is superior because it's "simple" is kinda missing the
> point of VIM (read below).
I tend to agree with you.
>>-User defined dialog boxes, can set multiple parameters simultaneously.
That might be one reason why some people would be willing to pay
good money for a powerful editing system.
> Admittedly VIM doesn't do this natively, but again... scripts can be
> written.
>>-Has superior "tags" facility -- Far superior!
This is, of course, a matter of degree and a matter of opinion, but
it might be a reason why you would be willing to pay for a good product.
>>-Automatic make file generator (Or use existing Makefile to
>>-manage your project) GNU C/C++ wizard -- Very cool. Project
>>-management - Get with it Emacs and VIM! I still can't believe
>>-XEmacs and VIM lack project management! For VIM I found some
>>-4 year old script that's a lame attempt at this.
> Not sure these qualify as something that should be bundled in a text
> editor per se... it sounds a lot more like something you'd want in a
> programming suite. VIM IS NOT A PROGRAMMING SUITE. It never intended
> to be.
>
> Remember kids: you're reading the comp.editors group!
These may again be reasons why some people would prefer to choose
one tool over another. Whether they justify their expense is
only something each person (or company) can decide.
This reply is written from Thunderbird, the Mozilla Email and News
client. Generally, though, I use Gnus, a great news reader that
can also be used as an Email client. Gnus is one of many applications
that have been written in Emacs Lisp. What's nice about Gnus is that
it is much more extensible than most other tools. Thunderbird is
handy because it is easy and convenient. That's a nice feature. Gnus
is nice because it is part of a comprehensive editing environment.
I hope this message posts cleanly; I have better success with Gnus
in that respect.
--
Brian Masinick
mailto:masi...@yahoo.com
Tron
> -Runs on virtually any platform too.
But certainly not on virtually any machine. From their website:
"Each installation requires a minimum of 256 MB of memory."
For an editor! Give me a break.
Nall-ohki
Great comments and a lot of constructive points. Your opinion
concerning "features must justify cost" is definately sound.
> My fundamental comment is that a proprietary tool had better provide at least a few, preferably quite a few, compelling reasons to pay good money for something that I can easily use for no cost.
> > Tell me in what way it's inferior? Is C++ inferior to Java? (or the other way around?)
> I'm not sure I understand the reference to C++ and Java.
I apologize for the vagueness of this. What I was trying to say is
that both of these things are still called the same thing "programming
languages", they are useful in very different ways. There is no good
answer to the question: "which is better?" without a firm context and a
narrowing of the question to: "which is better in xxx situation."
Brian Masinick
> Great comments and a lot of constructive points. Your opinion
> concerning "features must justify cost" is definately sound.
Thank you! I appreciate the affirmation.
>> My fundamental comment is that a proprietary tool had better
>> provide at least a few, preferably quite a few, compelling
>> reasons to pay good money for something that I can easily use
>> for no cost.
>> > Tell me in what way it's inferior? Is C++ inferior to Java?
>> > (or the other way around?)
>> I'm not sure I understand the reference to C++ and Java.
> I apologize for the vagueness of this. What I was trying to
> say is that both of these things are still called the same
> thing "programming languages", they are useful in very
> different ways. There is no good answer to the question:
> "which is better?" without a firm context and a narrowing of
> the question to: "which is better in xxx situation."
OK, that's much clearer. I appreciate your clarification.
Steering back to the original discussion and also to specific
references to SlickEdit, I have no real experience with this
editor or development environment, as it might be better
described. It seems to have quite a following that is every bit
as loyal as the Vi and Emacs clan, all of whom are extremely
loyal to their respective tools.
My observation is that it is likely that all three of them (and
undoubtedly numerous other editors and development tools) have a
lot going for them, otherwise they wouldn't have such loyal
followings.
My guess is that SlickEdit really does have numerous features
that truly save people time and effort, otherwise they wouldn't
be shelling out good money to obtain the software.
As far as preferences toward either large, monolithic tools,
small, distinct tools, or a blending of both ideas, I do not
think that there is any one single answer that MUST be right
here, either. There are absolutes in this world, but choosing a
set of development tools certainly is not anything that ever
ought to be absolute.
I do still long for the day when computers will be such a utility
that they will be like the radio, telephone, electric power, and
other common utilities. (We're getting closer to this all the
time). But like radios, phones, televisions, and other
appliances, I hope that within the utility of them, there will
always be flexibility and choice. It's great to have standards,
but it's also great to be able to modify and extend them, and
also to use non standard alternatives when it makes sense to do
so. That ability ought to always be there, and that will be
something that I always personally work for.
Brian Masinick
Ah, so there is a characteristic that sets the needs of one
person apart from another. Good! I think that we can safely say
that for some people, conservation of system resources is a big
priority.
Have you ever seen or used the Vi clone levee? Unlike Vim, levee
strives to constrain resources and emulate the original Vi with
not much fluff or documentation. Clearly that approach isn't for
everyone, but levee sure is handy on slow hardware!
Similarly for Emacs buffs, Micro Emacs, jove, and jed provide
lightweight alternatives, as does Zile, not to intentionally
exclude numerous other worthy alternatives.
On the opposite extreme, some people would rather have the
computer do as many things for them as possible, and gladly
consume as many resources as they can in their quest for their
own convenience. Though not everyone wants or cares for this
extreme, it's nice to have it as an option.
I like knowing just a little bit about each end and quite a bit
about things that lie somewhere in between. I don't mind these
kind of exchanges one bit, nor do I ever feel threatened in the
least when others have different interests and opinions. In
fact, I enjoy these kinds of conversations because they help me
better understand why there is such diversity. Rather than
thinking of that diversity as always either bad or good, I want
to better understand which components are most worthwhile, and
why others, though not as broadly appreciated, still carry value
for some people.
Appreciating these things helps me design, conceive, and support
better options whenever I am in the position to create or even
recommend what others ought to consider creating.
Thanks for the ongoing dialog, I am really enjoying it!
nospam
You've obviously never used SlickEdit -- It's faster than GVIM!
No kidding, try it yourself.
nospam
> Okay... lots of psuedo logic here...
I'll just sum up your defensive attitude in a word - Envy.
I've heard this argument time and time again, that VIM
lacks features because it's supposed to be lightweight.
And at the same time, they keep adding features to make
it more like SlickEdit! Maybe some day VIM will catch
up -- Maybe.
I'd venture to guess that you've never used SlickEdit.
I've used all three for many years, and speak from
experience.
Dmitry Poplavsky <Dmitry Poplavsky >
>
>> -Has superior "tags" facility -- Far superior!
>
> Explain. ctags works pretty well aside from the sometimes-annoying
> setup, but after that it works like a charm.
ctags can be easy fooled by a complex sources with preprocessor/etc.
SlickEdit has much better C++ parser, and it really helps ( not only
for code completion, but for very powerfull code navigation ).
For me it's a main advantage of Slickedit over Vim.
( most of time I'm using vim )
>
>> -Really cool auto code completion.
> Not going to comment on "really cool", because it's subjective. If
> you're looking for something beyond the basic code completion, again,
> there are plenty of options out there (IntelliSense for VIM for one).
>
--
Regards
Dmitry
E. Mark Ping
nospam <n...@spam.com> wrote:
>As they say,
I find it amusing that 'nospam' is spamming the newsgroup. One think
I dislike about Slickedit is how its users tend to spew stuff like
this all over. That seems to be the case of users of trendy (but over
hyped) products.
--
Mark Ping
ema...@soda.CSUA.Berkeley.EDU
dear.ja...@gmail.com
for $0.
They even charge $39 for the user manual on the editor. What a crock!!
Brian Masinick
Once again, I think these things are a matter of choice.
Clearly, for you, spending any kind of money whatsoever for an
editor is not worth it. For me, personally, I feel the same
way. I cannot think of any features that I absolutely need that
I would be willing to pay $284 for, unless it could save me
thousands of dollars and I was working on a time critical project
that would pay that amount many times over.
However, there are clearly many people out there who are willing
to spend good money for a text editor, and for many other kinds
of software as well. Nothing wrong with that at all.
If we extend this conversation to word processors and office
suites, clearly people spend hundreds of dollars for these kinds
of tools, even when free alternatives are clearly available.
While you and I know about those free alternatives and use them
over expensive commercial alternatives, that doesn't necessarily
mean that the commercial ones are useless or no good, even if
that's what we think. Since others are willing to pay for them
(even if in ignorance), they must have some value or the sales of
such commodities would be near zero.
I'm still interested in hearing more about why some people are
willing, and even happy, to pay good money for editors. I'm also
interested in hearing various reasons why other people want the
smallest, least obtrusive tool available. Understanding both
extremes goes a long way toward understanding how to write good
software for a broad audience. At least that is the way that I
see it.
dear.ja...@gmail.com
I'm usually willing to donate $$ to the developers if I find there
software awesome.
For example, I've used and paid for StarOffice, because I find that the
suite is useful and affordable enough for my needs. But I am not about
to shell out $200+ for Microsoft Word.
$284 is way too much money, in my opinion. And $39 dollars for a manual
on how to use the $284 editor is ridiculous to me.
I guess my threshold for how much I'm willing to pay is lower than
others.
Now that I've written this...I realize I need to send some money to the
developer of VIM, because this program makes my work day so much
easier.
Peter Lee
Having used slickedit for a few years, here's my opinion.
nospam> -C/C++ like scripting language (Slick-C) to extend editor.
nospam> VIM's scripting capability is far inferior, and LISP with
nospam> it's plethora of parenthesis is downright ugly!
C/C++ LIKE scripting language. "Like" being the operative word.
There are actually enough differences in syntax and usage to drive you
crazy and you end up learning most from the included source as the
docs suck.
nospam> -Stores encrypted SSH passwords for remote file access (Unlike TRAMP
nospam> or VIM). Get with it!
You don't need an editor to do this.
nospam> -Simple to use custom menu editor.
I always turn em off...
nospam> -User defined dialog boxes, can set multiple parameters simultaneously.
This is one of the things I disliked most about slickedit. Virtually
all user input is in a damn dialog. Even simple search and replace
pops up an ugly dialog, obscuring the text. Not to mention, most of
them are so overloaded with options you have no choice but to concede
and use the mouse.
They had this facility for expanding functions... Like
CreateFile... it would pop up this dialog. Some things were text
box... others were drop down, and others were check-boxes. By the
time you switched to mouse and typed/checked/selected everything you
wanted, you could have just typed it out in less time. And it would
generally pop up right over your code so you couldn't see some of the
var names that you needed to enter in the dialog. And it wouldn't
space the parms.
Skeletons in emacs are much more efficient.
nospam> -Has superior "tags" facility -- Far superior!
It's no different than any other tagging facility I've used.
nospam> -Really cool auto code completion.
This I'll give you... but it didn't always work for me with some of
the templated libraries like ATL/WTL. But that was a few versions
ago.
nospam> -Automatic make file generator (Or use existing Makefile to manage
nospam> your project)
nospam> -GNU C/C++ wizard -- Very cool.
<shrug> Never use em so... no comment.
nospam> -Project management - Get with it Emacs and VIM! I still can't
nospam> believe XEmacs and VIM lack project management! For VIM I found
nospam> some 4 year old script that's a lame attempt at this.
This was the primary reason I switched to emacs. It was absolutely
lame at handling large workspaces. It would churn for a few mins and
typically lock up. I would have to recreate entire workspaces 3 or 4
times a week.
nospam> -Modern GUI interface. XEmacs GUI components are UGLY!
I think slickedit UI is a bit convoluted... and the dialogs are a horror.
nospam> -Integrated version control including CVS, Subversion, GNU RCS,
nospam> and many more.
Standard fare for most editors today.
nospam> -C/C++ and Java refactoring.
Never used it.
nospam> -Superior C/C++/Java debugging. The debugger is exceptional.
It didn't have a c++ debugger when I used it... not long ago.
nospam> -Handles large files much better than vim or emacs. It's fast!
So are a lot of other editors.
nospam> -Java GUI builder.
Ugh.
nospam> -Runs on virtually any platform too.
I'd be willing to bet Emacs and Vim run on more.
I had tried slickedit 9.0 for linux about a month ago to see what was
new. I redirect the display on my remote linux box to a local
cygwin-x server and typically do all my work that way with Emacs.
Works great... very fast... I forget I'm remote sometimes. Slickedit
took ~5mins to load. Once loaded, it was so slow as to be unusable.
I just uninstalled it.
nospam> -Support is far superior. If I find a bug, I report it to SlickEdit
nospam> support, and they usually email a script with the fix the same day!
I found a bug in Emacs... once. But I fixed it myself in about 30sec,
but from what I hear support is great.
I switched to Emacs ~2 years ago and haven't missed slickedit at all... That
was only confirmed by my last trial of slickedit.
nospam
>>>>> nospam writes:
>
> Having used slickedit for a few years, here's my opinion.
>
> nospam> -C/C++ like scripting language (Slick-C) to extend editor.
> nospam> VIM's scripting capability is far inferior, and LISP with
> nospam> it's plethora of parenthesis is downright ugly!
> C/C++ LIKE scripting language. "Like" being the operative word.
> There are actually enough differences in syntax and usage to drive you
> crazy and you end up learning most from the included source as the
> docs suck.
The Slick-C language is far easier to learn for someone that is
famliar with C or C++, no doubt about it. Especially compared
to VIM script or eLisp. Vim's language can't even begin to
compare to the functionality of Slick-C. I can't believe
you used SlickEdit and think otherwise.
>
> nospam> -Stores encrypted SSH passwords for remote file access (Unlike TRAMP
> nospam> or VIM). Get with it!
> You don't need an editor to do this.
Anyone that edits files on remote hosts does. Here's an actual
example -- At work, I opened an Apache configuration file on
a remote host using Netrw and SCP. I was then prompted for the
password. I then tried to "grep" for something in the file,
and could not even do that! This was because there is still
no internal grep in gvim. Unbelievable. I then made changes
to the file, and went to save it, and was prompted for my
password again. This annoying behavior is actually documented
in the Netrw docs.
>
> nospam> -Simple to use custom menu editor.
> I always turn em off...
Yea, menus are a real nuisance!
> nospam> -User defined dialog boxes, can set multiple parameters simultaneously.
> This is one of the things I disliked most about slickedit. Virtually
> all user input is in a damn dialog. Even simple search and replace
> pops up an ugly dialog, obscuring the text. Not to mention, most of
> them are so overloaded with options you have no choice but to concede
> and use the mouse.
Actually, you have the option to use GUI based prompts, or
command line. For example, if you want the "file open" dialog
box displayed (Which I do because it gives you numerous options
concerning opening the file)you use gui_open -- Or you can
simply open a file via SE's the command line.
>
> They had this facility for expanding functions... Like
> CreateFile... it would pop up this dialog. Some things were text
> box... others were drop down, and others were check-boxes. By the
> time you switched to mouse and typed/checked/selected everything you
> wanted, you could have just typed it out in less time. And it would
> generally pop up right over your code so you couldn't see some of the
> var names that you needed to enter in the dialog. And it wouldn't
> space the parms.
>
> Skeletons in emacs are much more efficient.
>
> nospam> -Has superior "tags" facility -- Far superior!
> It's no different than any other tagging facility I've used.
It's very different in that it actually lets you manage your
tags via a tree list, in one centeralized location. You can
also append existing tags files.
> nospam> -Really cool auto code completion.
> This I'll give you... but it didn't always work for me with some of
> the templated libraries like ATL/WTL. But that was a few versions
> ago.
It works great for me.
> nospam> -Automatic make file generator (Or use existing Makefile to manage
> nospam> your project)
> nospam> -GNU C/C++ wizard -- Very cool.
> <shrug> Never use em so... no comment.
>
> nospam> -Project management - Get with it Emacs and VIM! I still can't
> nospam> believe XEmacs and VIM lack project management! For VIM I found
> nospam> some 4 year old script that's a lame attempt at this.
> This was the primary reason I switched to emacs. It was absolutely
> lame at handling large workspaces. It would churn for a few mins and
> typically lock up. I would have to recreate entire workspaces 3 or 4
> times a week.
What version was this? I haven't had a problem with projects yet.
And SE has a really cool feature that allows you to created a
project from CVS. You can actually connect to a CVS repository,
SE creates the project for you, and all of the files are presented
for editing.
> nospam> -Modern GUI interface. XEmacs GUI components are UGLY!
> I think slickedit UI is a bit convoluted... and the dialogs are a horror.
>
> nospam> -Integrated version control including CVS, Subversion, GNU RCS,
> nospam> and many more.
> Standard fare for most editors today.
>
> nospam> -C/C++ and Java refactoring.
> Never used it.
>
> nospam> -Superior C/C++/Java debugging. The debugger is exceptional.
> It didn't have a c++ debugger when I used it... not long ago.
>
> nospam> -Handles large files much better than vim or emacs. It's fast!
> So are a lot of other editors.
>
> nospam> -Java GUI builder.
> Ugh.
>
> nospam> -Runs on virtually any platform too.
> I'd be willing to bet Emacs and Vim run on more.
>
> I had tried slickedit 9.0 for linux about a month ago to see what was
> new. I redirect the display on my remote linux box to a local
> cygwin-x server and typically do all my work that way with Emacs.
> Works great... very fast... I forget I'm remote sometimes. Slickedit
> took ~5mins to load. Once loaded, it was so slow as to be unusable.
> I just uninstalled it.
You should just use SE's remote file editing capabilities, they work
extremely well via SSH or FTP. Slickedit has much more in the
GUI department, which would explain it being slower.
> nospam> -Support is far superior. If I find a bug, I report it to SlickEdit
> nospam> support, and they usually email a script with the fix the same day!
> I found a bug in Emacs... once. But I fixed it myself in about 30sec,
> but from what I hear support is great.
>
> I switched to Emacs ~2 years ago and haven't missed slickedit at all... That
> was only confirmed by my last trial of slickedit.
To each his own, but there is no doubt that SE has more Development
related features that VIM or Emacs out of the box. There's a reason
that people are willing to pay $250 for an editor, when you can
get VIM and Emacs for free.
nospam
MANY people disagree, and are willing to pay for an editor that
provides a superior development environment. SlickEdit has been
around for many years, and I expect it will be around for many years
to come. As far as the user manual is concerned, it comes with
SE in HTML format.
nospam
> dear.ja...@gmail.com writes:
>
>> No editor is worth $284, especially when there are excellent
>> editors for $0.
>
>> They even charge $39 for the user manual on the editor. What a
>> crock!!
>
> Once again, I think these things are a matter of choice.
> Clearly, for you, spending any kind of money whatsoever for an
> editor is not worth it. For me, personally, I feel the same
> way. I cannot think of any features that I absolutely need that
> I would be willing to pay $284 for, unless it could save me
> thousands of dollars and I was working on a time critical project
> that would pay that amount many times over.
How about "out of the box" functionality that will save a great
deal of time and effort? Is your time valuable?
Here's another example -- Remote file editing in VIM has (Until
recently) been spurious at best. Just Friday using VIM 6.3
I opened a remote directory (You can finally do this in vim!).
I then opened an apache configuration file, and then tried to
grep for a string in the file. I found that VIM was incapable
of doing this! Vim really does need an internal grep -- BADLY.
nospam
> In article <pan.2005.07.14....@spam.com>,
> nospam <n...@spam.com> wrote:
>>As they say,
>
> I find it amusing that 'nospam' is spamming the newsgroup. One think
> I dislike about Slickedit is how its users tend to spew stuff like
> this all over. That seems to be the case of users of trendy (but over
> hyped) products.
Firstly, I'm not spamming the news group. I've used SlickEdit, VIM,
and XEmacs for years. I just recently purchased SlickEdit, and
find it to be a much more complete development environment than
VIM or XEmacs. When I try to make VIM more like SE, I find these
4 year old vim scripts at vim.org, many of which do not work correctly.
Good luck with that!
David de Kloet
> Vim really does need an internal grep -- BADLY.
What should this grep be more than search?
--
David
E. Mark Ping
nospam <n...@spam.com> wrote:
>I then opened an apache configuration file, and then tried to
>grep for a string in the file. I found that VIM was incapable
>of doing this! Vim really does need an internal grep -- BADLY.
You mean like :g ?
Are you sure you've used Vim?
--
Mark Ping
ema...@soda.CSUA.Berkeley.EDU
nospam
> In article <pan.2005.07.17....@spam.com>,
> nospam <n...@spam.com> wrote:
>>I then opened an apache configuration file, and then tried to
>>grep for a string in the file. I found that VIM was incapable
>>of doing this! Vim really does need an internal grep -- BADLY.
>
> You mean like :g ?
>
> Are you sure you've used Vim?
My mistake, I used :grep.
nospam
Okay, with SlickEdit I can be editing a remote file.
I can then grep for a string in that file, and the
results are placed in an output window. I can then
scroll through the results, double click on one,
and am placed on the corresponding line in the file.
Sort of like :copen for errors in VIM.
nospam
Actually, using :g does not work to my satisfaction either.
It doesn't create a list that you can open using :copen.
If I :grep for a string, I can then use :copen to peruse
the matching lines. However, with :g, you cannot use
:copen. A shortcoming in my opinion, because I can
do this with SlickEdit, while editing a remote file.
Villy Kruse
:g/RE/p
E. Mark Ping
nospam <n...@spam.com> wrote:
>Actually, using :g does not work to my satisfaction either.
>It doesn't create a list that you can open using :copen.
n and N aren't sufficient?
--
Mark Ping
ema...@soda.CSUA.Berkeley.EDU
Brian Masinick
If I were doing a lot of remote file editing at work and I was
experiencing time delays, I might ask my employer to get me a
tool like Slick Edit to get the job done quicker. If they didn't
want to spend the money, I'd either ask them if I could take the
time to construct a tool to speed my work or if they minded that
it would take considerably longer to get things done.
At home, I would simply write a tool if I were doing something
that often. With Emacs, you usually can find such tools already
in existence, but if not, you can either write a quick keystroke
macro and save it or write an Emacs Lisp procedure and bind it to
a set of keys. You can also quickly write a TCL/Expect procedure
and run it from either Vim or Emacs.
Given those kind of choices and the modest amount of time they
take to implement, I am still inclined to remain with freely
available tools. I do not denounce you for going the other way,
but for me, I remain unconvinced for my own needs.
Still interested in chatting on, though, Slick Edit does indeed
seem to have quite a few very strong and positive features.
Jahagirdar Vijayvithal S
* nospam <n...@spam.com> wrote:
> of doing this! Vim really does need an internal grep -- BADLY.
>
Really? Ok here goes
:h grep
{start data from vims help file}
5. Using :vimgrep and :grep *grep* *lid*
Vim has two ways to find matches for a pattern: Internal and external.
The advantage of the internal grep is that it works on all systems and
uses the powerful Vim search patterns. An external grep program can be
used when the Vim grep does not do what you want. The internal method
will be slower, because files are read into memory. The advantages are:
- Line separators and encoding are automatically recognized, as if a
file is being edited.
- Uses Vim search patterns. Multi-line patterns can be used.
- When plugins are enabled: compressed and remote files can be searched.
|gzip| |netrw|
- When 'hidden' is set the files are kept loaded, thus repeating a
search is much faster. Uses a lot of memory though!
5.1 using Vim's internal grep
*:vim* *:vimgrep* *E682* *E683*
:vim[grep][!] /{pattern}/[g][j] {file} ...
Search for {pattern} in the files {file} ... and set
the error list to the matches.
Without the 'g' flag each line is added only once.
With 'g' every match is added.
{/end}
Happy?
Regards
Jahagirdar Vijayvithal S
--
Dale Carnegie:There is only one way... to get anybody to do anything. And that is by making the other person want to do it.
Jahagirdar .V.S
IC Design Engineer , Texas Instruments (India) Ltd.
91-80-25099129(O) 91-80-28540394(R)
Antony Scriven
E. Mark Ping wrote:
> In article <pan.2005.07.18....@spam.com>,
> nospam <n...@spam.com> wrote:
In summary someone who doesn't want anyone to know their
top-secret identity doesn't like using vim for remote file
access because they can't grep. Plus slickedit is the best
editor in the world.
> >Actually, using :g does not work to my satisfaction
> >either. It doesn't create a list that you can open using
> >:copen.
>
> n and N aren't sufficient?
Nearly, but not quite, because if you want to do another
search in between your next n then you will lose your place.
But this is easily fixed by setting a mark and using the
search history.
If you must:
:let @a = '' | redir @a | g/foo/#
:redir end | new | put a
:nno <buffer> <CR> 0ye<C-W>p:<C-R>"<CR>
Now that wasn't hard was it? Better (but I bet `nospam'
won't like it because it modifies the buffer -- so what?):
/XXX$
:g/foo/s/$/XXX
nnn
In a real vi (+ nvi :-)) you can do:
Q
:g/foo/vi
QQQ
But the simplest way is probably to just set a mark. You can
automate that:
:map - `m/foo<CR>mm|km
-
... do some stuff ...
---
Actually there is nothing stopping you from writing the file
locally and grepping that. Probably netrw.vim keeps a
temporary file somewhere anyway.
Of course you could just telnet in. You can do that with
slickedit, right?
Antony
Antony Scriven
> Post made at the risk of being apprehended for feeding
> the trolls.
>
> * nospam <n...@spam.com> wrote:
> > of doing this! Vim really does need an internal grep -- BADLY.
> >
> Really? Ok here goes
> :h grep
> {start data from vims help file}
> 5. Using :vimgrep and :grep *grep* *lid*
I wasn't going to mention that because you'll need to get
vim7.0a from CVS to use it.
Antony
E. Mark Ping
Antony Scriven <ad_sc...@postmaster.co.uk> wrote:
>E. Mark Ping wrote:
>> n and N aren't sufficient?
>
>Nearly, but not quite, because if you want to do another
>search in between your next n then you will lose your place.
>But this is easily fixed by setting a mark and using the
>search history.
Or by splitting the window, which is what I do when I need this.
--
Mark Ping
ema...@soda.CSUA.Berkeley.EDU
Fred
In almost any other editor, you can "grep" for instances
of a string, which are placed in a list from which you
can goto these instances. Vim does not have this.
It only has this functionality for errors, then using
:copen. I understand that in Vim 7 a vimgrep command
has been included to address this shortcoming.
nospam
> Appreciating these things helps me design, conceive, and support
> better options whenever I am in the position to create or even
> recommend what others ought to consider creating.
>
> Thanks for the ongoing dialog, I am really enjoying it!
I understand where you're coming from, but it's somewhat
backwards thinking. Computers are cheap. RAM is cheap.
Disk space is cheap. There's really no need to use
a 50k editor anymore! <g>
nospam
> Well let 'em. There is no way I'd be suckered into that kind of deal.
Yea, having a superior editor really sucks.
nospam
|gzip| |netrw|
> - When 'hidden' is set the files are kept loaded, thus repeating a
> search is much faster. Uses a lot of memory though!
>
> 5.1 using Vim's internal grep
> *:vim* *:vimgrep* *E682* *E683*
>
> Regards
> Jahagirdar Vijayvithal S
Actually, you've proved my point completely. The :vimgrep IS
the internal grep command that vim so desperately needs.
Can you tell me after using vimgrep, is there a list of
matches from which you can select, and goto that line,
like :copen?
nospam
Yes, that proves my point entirely. Vim currently does not
have an internal grep. I personally edit numerous config
files on remote hosts, and need to grep through them, and
then be able to select matches from the list, and goto
those lines. Similar to :copen.
nospam
> In article <pan.2005.07.17....@spam.com>,
> nospam <n...@spam.com> wrote:
>>I then opened an apache configuration file, and then tried to
>>grep for a string in the file. I found that VIM was incapable
>>of doing this! Vim really does need an internal grep -- BADLY.
>
> You mean like :g ?
>
> Are you sure you've used Vim?
Obviously you don't understand. Vim 7 now promises an
internal grep command named :vimgrep. This is the
shortcoming I was referring to. Check it out.
Hopefully when you use :vimgrep, it will list the
matches in a list like :copen, or vim will still
be inadequate for remote file editing purposes.
Jahagirdar Vijayvithal S
<SNIP>
> Actually, you've proved my point completely. The :vimgrep IS
> the internal grep command that vim so desperately needs.
> Can you tell me after using vimgrep, is there a list of
> matches from which you can select, and goto that line,
> like :copen?
:vimgrep /pattern/ filename
:copen
Time to leave SE and comeback to good old vim? ;)
Regards
Jahagirdar Vijayvithal S
--
David de Kloet
I like my editor to start in a tenth of a second. If it's huge and
uses tons of resources it won't probably do this.
--
David
David de Kloet
> I personally edit numerous config
> files on remote hosts, and need to grep through them, and
> then be able to select matches from the list, and goto
> those lines. Similar to :copen.
Why don't you just run your editor on the remote host?
--
David
Bart van Deenen
> Computers are cheap. RAM is cheap.
> Disk space is cheap. There's really no need to use
> a 50k editor anymore!
There is when you're debugging your embedded software via serial line to
its embedded linux os.
Which makes my editor of choice vim, and some small vi clone on embedded
systems
Bart van Deenen
Brian Masinick
Yeah, you might even want to consider, as you mention, an even
smaller clone when you run on embedded systems. One of the
smallest vi clones that I have run across so far is levee. It is
nowhere near as functional as even Vim, much less a large,
commercial tool like SlickEdit. Nevertheless it is an extremely
small, powerful editor, made in the mold of the original Vi. If
I had to make a guess, I'd say that levee is even smaller than
the original Vi. I believe that the image size is 37336, at
least that is the size on one of my Debian systems. I think even
the original Vi was between 80-90,000 in size, but do correct me
if I am wrong.
Brian Masinick
I do not have a lot of disposable income right now, so for me
personally, there is no way that I would go out looking for a
commercial text editor, a commercial word processor, or a
commercial office suite... or take it all the way... any
commercial software.
That does not mean that commercial software is without worth,
either to me or to others, but it does mean that not everyone can
afford to go out and get either hardware or software, even if it
is cheap. My newest computer system was built in 2000, I
acquired it as part of my compensation for writing some articles
for a publisher. My next newest systems are either 1998 or 1999
vintage. Any new or reasonably current software I have either is
free software or it is commercial software that I acquired, not
by purchasing it, but by legitimately gaining it from short term
commercial contracts - the employer, not me, was the one owning a
commercial license.
Brian Masinick
> On Fri, 15 Jul 2005 10:44:38 -0400, Brian Masinick wrote:
>> Once again, I think these things are a matter of choice.
>> Clearly, for you, spending any kind of money whatsoever for an
>> editor is not worth it. For me, personally, I feel the same
>> way. I cannot think of any features that I absolutely need that
>> I would be willing to pay $284 for, unless it could save me
>> thousands of dollars and I was working on a time critical project
>> that would pay that amount many times over.
> How about "out of the box" functionality that will save a great
> deal of time and effort? Is your time valuable?
My time is indeed valuable. I am not sure that I have the same
editing requirements that you do, though.
My most common editing requirement is to edit plain text, like
this, and either use it in an Email message in an Email client,
an Email message in a Web based Email client, a response in a
blog or a forum, or in a news group. Most of the time I use Gnus
when I am in a newsgroup, as I am now. For that, I use GNU Emacs
with Gnus. I can use either Vim, NEdit, GNU Emacs, or any number
of Emacs or Vi clones when I am composing plain text and copying
and pasting it. Many of them have builtin text fill facilities,
where I can keep my text somewhere within the 65-79 characters
per line range. Even if they don't, I can use standard UNIX or
Linux facilities to get this functionality without resorting to
the use of a proprietary product. It doesn't even take as long
to use such things as it does to carry on this dialog, so their
effectiveness is completely acceptable and downright fast for me.
> Here's another example -- Remote file editing in VIM has (Until
> recently) been spurious at best. Just Friday using VIM 6.3
> I opened a remote directory (You can finally do this in vim!).
> I then opened an apache configuration file, and then tried to
> grep for a string in the file. I found that VIM was incapable
> of doing this! Vim really does need an internal grep -- BADLY.
I don't have that many cases where I have to remotely edit a
file, but when I do, I generally use my local system to edit the
file and use any one of several really good FTP client software
packages to transfer my files. Typical case is when I want to
update my Web pages. I have a commercial ISP that has my Web
page, but I also have a few freebie Web page servers that can
deliver essentially the same content. All of them have easy FTP
download and upload facilities. Checking out my work is a simple
matter of editing my file, uploading it, and clicking Reload on
my browser. I do not lose any time doing this; I can update a
Web site in less than a minute (much less than a minute if I am
awake and paying attention to what I am doing)!
Now that doesn't mean that you don't save a lot more time than I
would for what I do, but I doubt that I would save much time at
all by using SlickEdit for the kinds of things I do. If
anything, I may initially lose time familiarizing myself with its
features. I don't challenge the features, but I do question why
I would even need it in my case.
nospam
> Now that doesn't mean that you don't save a lot more time than I
> would for what I do, but I doubt that I would save much time at
> all by using SlickEdit for the kinds of things I do. If
> anything, I may initially lose time familiarizing myself with its
> features. I don't challenge the features, but I do question why
> I would even need it in my case.
I should have clarified at the beginning that SlickEdit is a
much more complete development environment than either vim
or emacs, "out of the box". It's true that you can obtain
scripts or plugins for both vim and emacs, but I find many
bugs in the vim scripts that have the SlickEdit functionality
I'm trying to duplicate in vim. I also use my editor as a
ssytems administration tool, and I have menu items in SlickEdit
and XEmacs which I simply click and then configuration files
on numerous remote hosts are opened for editing. Apache, FTP,
Samba, Weblogic, LDAP, DNS, etc., etc. So in my previous
scenerio, I opened an httpd.conf file on a remote host,
and was dismayed to find that I could not grep for a string
in this file, and have a :copen type list created, so I could
then goto those lines by clicking on one of the matches.
I understand vim 7 will include a :vimgrep command. I hope
this does what I describe above.
There are many other features in SlickEdit that are superior
to either vim or emacs, such as the C/C++ and Java debuggers.
But as you say, you may not have a need for those tools, and
simply want to edit files.
nospam
> * nospam <n...@spam.com> wrote:
> <SNIP>
>> Actually, you've proved my point completely. The :vimgrep IS
>> the internal grep command that vim so desperately needs.
>> Can you tell me after using vimgrep, is there a list of
>> matches from which you can select, and goto that line,
>> like :copen?
> yes. try
> :vimgrep /pattern/ filename
> :copen
> Time to leave SE and comeback to good old vim? ;)
> Regards
> Jahagirdar Vijayvithal S
Actually, I love vim, XEmacs, and SlickEdit. I'm somewhat of
an editor buff (Pun intended). I use my editor for Systems
Administration work as well. I have menu items defined
in XEmacs and SlickEdit that open cofiguration files on
numerous remote hosts, for such things as apache, DNS, LDAP,
FTP, Weblogic, etc., etc. I was dismayed to find that
after I opened an httpsd.conf file on a remote web server
with vim, I could not search for a string in that file,
then have a :copen type list created. This is a showstopper
for me, but your mileage may vary! <g>
nospam
Because it's much simpler to configure your editor once
on your workstation, than having to configure 89 environments
on 89 remote hosts.
nospam
Dude, you need to get a second job for a month and buy one
of those $400 Dells! <g> Seriously though, I understand
that not everyone can afford a $284 editor. Actually, with
the advent of vim 7, and the :vimgrep command, it will overcome
a (In my opinion) major shortcoming of vim, and may use it
more frequently. Currently, I use vim, xemacs, and slickedit,
of which slickedit is my favorite.
nospam
Believe it or not, even though SlickEdit has a great deal more
features than vim, it actually starts faster than gvim! (I'm
not kidding).
But how fast an editor starts is not really important to most
people. Most people open their editors once, and then simply
pass files to the open editor via the command line.
Brian Masinick
I can see where performing the kinds of tasks you are doing,
especially repetitively and probably under tight constraints,
once you master the tool, SlickEdit could come in VERY HANDY,
indeed. Sounds like in your current role, you are functioning as
a combination systems and networks administrator. Sounds like a
good role for a time saving tool, and that might be a good case
for using a strong tool like SlickEdit.
I can see that though you could write XEmacs macros or Elisp code
to do what you want, being under the gun, you may not have time
to do such things unless you do them at home or work hero hours.
Brian Masinick
> Actually, I love vim, XEmacs, and SlickEdit. I'm somewhat of
> an editor buff (Pun intended). I use my editor for Systems
> Administration work as well. I have menu items defined
> in XEmacs and SlickEdit that open cofiguration files on
> numerous remote hosts, for such things as apache, DNS, LDAP,
> FTP, Weblogic, etc., etc. I was dismayed to find that
> after I opened an httpsd.conf file on a remote web server
> with vim, I could not search for a string in that file,
> then have a :copen type list created. This is a showstopper
> for me, but your mileage may vary! <g>
Like you, I am an editor buff (I'll use the pun too) ;-), but I
am a poor buff, and I am an older buff, so I use tools that I
have gained years of experience with.
Four years ago, I was on a pretty fast paced project writing test
plans for a supercomputer system. On the desk in the office, we
had Windows NT. In the lab, we had Compaq Tru64 UNIX V5.1. We
got an inexpensive terminal emulator to save us from having to
either walk into the lab or use the lousy default terminal that
came with NT. That was a good use of money, and it didn't cost
much for three copies for the team I was on. That way, we could
write test plan and test case steps on NT using Word, then
simultaneously connect to the UNIX lab, which, in turn, could
also connect to the even higher speed UNIX supercomputers. Using
all available tools, we could do everything from our desk without
having to go into the cold and noisy lab. That way, we could
also be on the phone from our desks with developers overseas when
we encountered problems or provided status updates.
That one emulator tool gave us quite a bang for the buck. Was it
essential? No, not in the strictest sense of the word. Was it
useful, and was it worth the money spent in the productivity
gained? Absolutely. In your case, I think you can reasonably
make the same case for SlickEdit. Not everyone needs it, but
for those who do, it can probably pay for itself in the first
week of use.
Brian Masinick
> On Fri, 22 Jul 2005 16:28:49 -0400, Brian Masinick wrote:
>> I do not have a lot of disposable income right now, so for me
>> personally, there is no way that I would go out looking for a
>> commercial text editor, a commercial word processor, or a
>> commercial office suite... or take it all the way... any
>> commercial software.
> Dude, you need to get a second job for a month and buy one
> of those $400 Dells! <g> Seriously though, I understand
> that not everyone can afford a $284 editor. Actually, with
> the advent of vim 7, and the :vimgrep command, it will overcome
> a (In my opinion) major shortcoming of vim, and may use it
> more frequently. Currently, I use vim, xemacs, and slickedit,
> of which slickedit is my favorite.
Hire me to work with you, and I would be DELIGHTED to use both a
$400 Dell AND SlickEdit, (along with GNU Emacs, XEmacs, and Vim)!
;-)
Galen Boyer
> On Sun, 17 Jul 2005 17:26:44 +0200, David de Kloet wrote:
>
>> On Sun, 17 Jul 2005, nospam wrote:
>>
>>
>
> I can then grep for a string in that file, and the
> results are placed in an output window. I can then
> scroll through the results, double click on one,
> and am placed on the corresponding line in the file.
> Sort of like :copen for errors in VIM.
Emacs can do that with ease.
I can also then narrow, create a bookmark, do a shell command on it,
send it to an email buffer, regexp search within it, or any of the other
thousand things I have at my fingertips.
Is this functionality that you are crowing about available everywhere in
slickedit? Not only on files but output from shell windows, output from
sqlplus windows, directories, any type of file, you name it? Cause if
not, you might as well crow about something else.
Whoo-hoo, superior to Emacs. Yeah right, you sure got it all over Emacs
on this one.
--
Galen deForest Boyer
Galen Boyer
> Plus slickedit is the best editor in the world.
Okay, you sold me. I'll run out and get it right away ...
--
Galen deForest Boyer
Galen Boyer
> I don't have that many cases where I have to remotely edit a
> file, but when I do, I generally use my local system to edit the
> file and use any one of several really good FTP client software
> packages to transfer my files.
Since you are comfortable with Emacs, why not open a dired buffer to
your FTP target site?
C-x d /username@site: [ret]
Then, uploading is just a dired copy.
--
Galen deForest Boyer
Galen Boyer
>
>> In article <pan.2005.07.14....@spam.com>,
>> nospam <n...@spam.com> wrote:
>>>As they say,
>>
>> I find it amusing that 'nospam' is spamming the newsgroup. One think
>> I dislike about Slickedit is how its users tend to spew stuff like
>> this all over. That seems to be the case of users of trendy (but
>> over hyped) products.
>
>
> Firstly, I'm not spamming the news group. I've used SlickEdit, VIM,
> and XEmacs for years. I just recently purchased SlickEdit, and find
> it to be a much more complete development environment than VIM or
> XEmacs. When I try to make VIM more like SE, I find these 4 year old
> vim scripts at vim.org, many of which do not work correctly. Good
> luck with that!
The subject line puts VIM and Emacs together somehow beaten out by
SlickEdit. But then your posting only talk about SlickEdit beating out
VIM. Why not explain how it beats out Emacs?
--
Galen deForest Boyer
projecktzero
viz you all sheet ed it
$284! $799 for multi-platform edition!
I banish thee troll
to the endless upgrade treadmill
of closed source vendor lock in.
May the vendor raise his prices on you or go out of business leaving
you with unsupported languages, language features, and bugs.
Go to the 7th plane of unproductive hell by having to use your mouse
instead of keeping your hands on the keyboard.
Begone troll!
Leave this realm of VIM and Emacs users!
Pray that you don't go to the 9th plane of unproductive hell where all
you'll have is....
NOTEPAD!!
BEGONE!
Brian Masinick
I suppose I could do that, but I have not been an Emacs-only
kind of a guy. I have used w3, but I usually use Mozilla Firefox
as my browser. I do generally use Gnus for news. I do use dired
instead of a graphical file browser, at least when I am doing
text. When it comes to stuff like FTP, I often use my browser
for easy stuff, and either gftp or wget if I want more features.
I will tru C-x d /username@site: [ret]
to compare it to what I have been doing, though, because I do use
Emacs on a regular basis. If it flows well with the keystrokes
and patterns of things I am doing, I may go with it, so thanks
for bringing it to my attention!
Antony Scriven
> On 19 Jul 2005, ad_sc...@postmaster.co.uk wrote:
>
> > Plus slickedit is the best editor in the world.
>
> Okay, you sold me. I'll run out and get it right away ...
Just for the record, I was paraphrasing the OP.
Antony
nospam
Remember that when you're struggling with a 5 year old
vim script to try and attain functionality that SlickEdit
already has.
Antony Scriven
> On Sun, 17 Jul 2005, n...@spam.com wrote:
> > On Sun, 17 Jul 2005 17:26:44 +0200, David de Kloet wrote:
> >
> >> On Sun, 17 Jul 2005, nospam wrote:
> >>
> >>> Vim really does need an internal grep -- BADLY.
> >>
> >> What should this grep be more than search?
> >
> > Okay, with SlickEdit I can be editing a remote file.
> > I can then grep for a string in that file, and the
> > results are placed in an output window. I can then
> > scroll through the results, double click on one,
> > and am placed on the corresponding line in the file.
> > Sort of like :copen for errors in VIM.
>
> Emacs can do that with ease.
I wrote a three-line script to do that in Vim. I note the OP
chose not to comment on it.
> I can also then narrow, create a bookmark, do a shell
> command on it, send it to an email buffer, regexp search
> within it, or any of the other thousand things I have at
> my fingertips.
What's `narrow'?
Really, I can't understand why the OP doesn't just run
slickedit on the remote machine ...
Antony
Galen Boyer
When I've defined a region (either by the mouse or by the keyboard) I
can hit C-x r n and then all that is visible is the region. I can
perform any operation on this narrow'd buffer and it only happens on
what is visible. I use it all the time, mainly so I can "narrow" my
focus.
>
> Really, I can't understand why the OP doesn't just run
> slickedit on the remote machine ...
LOL
--
Galen deForest Boyer
Galen Boyer
Oops. My bad. I just assumed it was him.
--
Galen deForest Boyer
Galen Boyer
> Remember that when you're struggling with a 5 year old
> vim script to try and attain functionality that SlickEdit
> already has.
VIM and Emacs users will remember that you are stuck with exactly the
functionality that slickedit offers for the money paid and nothing more.
--
Galen deForest Boyer
Ross Presser
@g44g2000cwa.googlegroups.com:
> Now that I've written this...I realize I need to send some money to the
> developer of VIM, because this program makes my work day so much
> easier.
Old thread, I know .. but I wanted to mention that Bram prefers that you
give your money to charity. :help Uganda