Slashdot Mirror
Why this? Yet Another vi-based Editor?
Poizon writes "The guys from freehackers.org have begun developing yet another vi-like editor, called Yzis (speak: "Why this?"). Their primary goal is to seperate the text processing engine and the GUI, in order to be able to integrate it into window managers like KDE as a native component. They have previously worked on KVim, a Vim port to KDE, so chances are good that they will succeed with Yzis. Sounds interesting, doesn't it?"
I was thinking the same thing. Maybe they are suffering from Not Invented Here syndrome.
With that said, I wouldn't mind having a VI-like editor intregrated into Kdevelop. I like Kdevelop and the Visual-Studio-like features, but I often sorely miss my Vim functionality and I end up being forced to switch back and forth between a terminal and Kdevelop.
The ratio of people to cake is too big
You can use some 'vi' shortcuts in Cocoa's NSTextField (or is it NSTextView?), which is used for text input fields. I'm using Safari, so I can hit ^A and go to the beginning of the line, ^E for the end, ^D to forward-delete, etc.
-Ster
Geeks must have some sort of Advertising Impairment Syndrome, where in order to make a brand-name, they take the most unpronouncable and esoteric combinations of characters and stick them together.
It's like all the crazies who go ballistic at people when people don't pronounce a hard "G" at the beginning of "Gnome". Why the fuck should they? It's pronounced differently in every other word beginning with "G-N".
This might get modded flamebait, but every geek on slashdot knows it's true. Slashdot ITSELF is an example (tee hee! "http colon slash slash slash dot dot org!"). It IS cool, but it severely impedes the chances that anyone will ever recognize your product, or even download it, because if I had a conversation with a friend about this, I'd never be able to go google for it without specifically asking how to spell it.
I agree that vi is a PITA when you are used to the new colorful world of windows, buttons and menus.
:s/I/we/g and you are done.
But... this project is aiming at providing a plugin-like editor for all applications.
Example: I am currently typing this text in a small textarea in Opera.
Imagine I'd like to replace all occurences of "I" with "we". What can I do? Search and spell checking works fine in Opera (I don't know about other browsers), even on texts in textareas, which is already something. But a Find&Replace function is simply not there.
Now imagine your browser with your favorite editor (like vi) as plugin. You do the great vi-magic like
I got the impression you could easily do this with vim already, which is why vim is now three separate projects kinda: vim-core, vim, and gvim. Couldn't they just wrap vim-core up and make it into a component right now?
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
What about have fun, program, enjoy yourself?
Frankly people that immediately go in market-speak mode are a real nuisance....
IANAL but write like a drunk one.
ugh. of course the authors just HAD to do this in C++, making it a bitch to integrate into objective-c based programs. At the very least objective-c++ with os x will work, but the gnustep people are completely shut in the dark. why do people code in that unportable language? c LINKS WITH EVERYTHING. sigh.
- tristan
For anybody's information, here is a more detailed explanation of the "Why this":
v =6 10&view=auto
...
... We managed to complete both tasks but the second one
http://mirror1.yzis.org/viewcvs/trunk/README?re
History:
========
Before working on Yzis, the authors (Mickael Marchand, Thomas Capricalli and
Philippe Fremy) had been working on GVim. GVim is clearly the best vi
compatible editor today. It contains tons of features, which are very clear
improvements upon the original vi: visual selection, unlimited undo, powerful
syntax highlighting, script language, splitted windows,
We did two things with GVim. First, we ported it on KDE and created KVim. The
second step was to make KVim embeddable as an editor component into any KDE
application. The idea was to be able to use a vi editor anywhere: in KDevelop,
in Kate, in KMail,
was very difficult to achieve and a number of problems could not be overcome.
For example, kvim can not have multiple windows on the same buffer, and thus
won't integrate in Kate.
While working with the gvim code base, we have been comfronted with a growing
amount of difficulites:
- there is a huge pile of C files without much documentation.
- it is difficult to find one's way through the code.
- the code was written in C and has very little abstraction, which make it
difficult to follow.
- the vi engine is tied to the concept of console editor. We have to add hacks
after hacks to make it work as a graphical component (for example, we need
to fork a process, embed a graphical window, and run an event loop at full
speed while still not taking the whole CPU to just make the component work).
- the main author of GVim is very reluctant to add any small change, even
those that won't affect the current behaviour
- the codebase is very big and the author does not want to introduce any new
feature, in fear of breaking something.
So, on one side we had implementation limitations and problems, on the other
side it was not possible to do any new developments on the editor. We
discussed that with the GVim team and came to the conclusion that it was not
possible to work with GVim to have a vi-like editor in KDE as a good
component.
At this point, the decision was simple. Either spend lot of time in working
around limitations of GVim, or dropping the idea of a good vi editor component
for KDE or start a new vi editor. Kudos to Thomas Capricelli and Mickael
Marchand who took over the third decision. This decision was taken shortly
before Fosdem 2003. The design documents and the name were hacked during the
Fosdem.
They put up a website, a subversion server, mailing lists and started
coding. To avoid the many problems of gvim, we took the following decisions:
1. clearly separate the vi engine from the gui
2. use C++ to provide a clean design
3. abstract the views, the buffer and the gui in the engine
4. have a KDE gui
5. have a text gui
6. provide a C interface in case a hard-core C coder wants to contribute
7. use some Qt classes for the engine. Qt would bring a string class that
handles unicode correctly (multibyte support is knightmare in gvim), efficient
lists implementations, and other goodies. Moreover, we were very familiar and
efficient with Qt.
8. Use tinyQ as a backup solution for the people not willing to link with Qt
just for a few template classes.
Over the time, maintaining a C binding to C++ turn out to be quite tedious and
time consuming. It would also make the code quite complicated. So the C
binding was dropped and yzis started to develop slowly but steadily.
Noooooooooooooooooooooooooooooooooooooo!
Multimode editing in GUI editors would be fine, but that's not the issue.
Dual-mode editors à la vi went out with the Ark. Imagine if you had to press i in Word before you could type text, and had to press Esc before you could do anything else.
I don't imagine it, I do it. Oftentimes with annoying consequences. I much prefer the vi style of editing. I feel like I go a hundred times faster than any other mode.
GPL made simple: What was my stuff is now our stuff. If you improve our stuff, please keep it our stuff.