coding text editor - Linux

This is a discussion on coding text editor - Linux ; Hi! I am writiing a VI like text editor in C++ for the console. I would like to know some opensource tools that would help me build it faster. Also, What would be the best approach to build it? Thank ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: coding text editor

  1. coding text editor

    Hi!
    I am writiing a VI like text editor in C++ for the console. I
    would like to know some opensource tools that would help me build it
    faster. Also, What would be the best approach to build it?
    Thank You.

  2. Re: coding text editor

    sid wrote:
    > Hi!
    > I am writiing a VI like text editor in C++ for the console. I
    > would like to know some opensource tools that would help me build it
    > faster. Also, What would be the best approach to build it?
    > Thank You.


    Hi, I'm the primary author of elvis.

    I suggest you get a book entitled "The Craft of Editing Text" by Craig
    Finseth. It uses EMACS for many of the examples, but really it tries
    to be a generic reference for how to write text editors. It is online
    at http://www.finseth.com/craft

    You should also read http://www.cs.unm.edu/~crowley/papers/sds/sds.html
    which discusses various data structures for storing edit buffers.

    The POSIX documentation for ex and vi are very vague, and not worth
    tracking down. Clearly, the authors had never implemented vi before.

    I can tell you that in elvis, there are a lot of data structures with
    associated sets of functions for manipulating them. It should be easy
    to derive classes and methods from that. For example, there's a LOWBUF
    data structure, and the lowbuf.c file containing functions which replace
    text and maintain versions. There's also a BUFFER data structure which
    uses LOWBUF to store the text, remembers which versions to use for
    "undo", and adds buffer options like "filename" and "readonly".
    I'm *NOT* saying you should base your editor on elvis -- I'm just
    saying that any C editor is likely to be organized in a way that
    translates well to C++. So look at as many C editors as you can
    find.

    The ex command processor and vi command processors are both driven off
    dispatch tables -- basically an array of structs containing a command
    name, a function pointer, and a bitmap of each command's quirks.
    There are a lot of quirks, and I suggest you look at an existing vi
    clone REAL SOON to get an idea of the kind of quirks you'll need to
    support. In elvis, the dispatch tables are in ex.c and vi.c.

    Screen updates are tricky in elvis. Elvis supports multiple display
    modes (including HTML, nroff -man, and hex dump) and multiple user
    interfaces (including X11 and ASCII terminals), so the screen update
    logic had to be very versatile. Unless you can dedicate big steaming
    piles of time to your project, I suggest you stick with plain text
    displays in a terminal emulator using the curses library.

    Some other potential problem areas: Key maps. External programs (the !
    command and its variations). Security. Regular expressions. Options
    (the :set command). Tags (the :tag command).

    Elvis is available at ftp://ftp.cs.pdx.edu/pub/elvis/elvis-2.2_0.tar.gz

  3. Re: coding text editor

    I'm the author of a (closed source) IDE and one of the few who is not
    using
    the scintilla widget. I can only tell you that the stuff recommended
    from steve
    is old and makes a lot of features impossible or had to implement.
    Texts are
    not span's of characters. They are structured in lines and we should
    preserve
    this. Today it is not a problem to have 200.000 different strings in
    memory.

    Remember that text editors are really complex beasts these days if you
    want
    to implement different features like good folding and syntax
    colorization. Text
    storage management is not really important anymore because of the
    GBytes of
    RAM.

    Even better use multiple text engines and map to them based on the
    file. If i
    ever have the time i will for example add a special "Brief" like
    structure that
    does allow to view/edit gigabyte size log files without holding more
    then a few
    Kilobytes in text.

    But you have to ask yourself what you want to learn by doing this. If
    you are
    a C programmer who want to learn more about C++ i don't think this is
    a good
    excercise. You will run into too many real world text editing problems
    that do
    not help you with your intended goal.




  4. Re: coding text editor

    llothar writes:
    > I'm the author of a (closed source) IDE and one of the few who is
    > not using the scintilla widget. I can only tell you that the stuff
    > recommended from steve is old and makes a lot of features impossible
    > or had to implement. Texts are not span's of characters. They are
    > structured in lines and we should preserve this.


    Perhaps you can manage to convince to author of the toy program you
    use for posting to usenet that preserving the line (or even paragraph
    structure) of the text would be more sensible than forcing it into the
    'well-kown' Windows-invented 'comb structure' ...

    Independently of this, it ocasionally pays to become familiar with
    something before declaring it to be obsolete for some weird reason.
    Quoting from the linked paper (I have not read it entirely, because I
    have no actual interest in text editing):

    The more sophisticated sequence data structures keep the
    sequence as a recursive sequence of spans of text. The line
    span method keeps each line together and keeps an array or a
    linked list of line pointers.

  5. Re: coding text editor

    > Perhaps you can manage to convince to author of the toy program you
    > use for posting to usenet that preserving the line (or even paragraph
    > structure) of the text would be more sensible than forcing it into the
    > 'well-kown' Windows-invented 'comb structure' ...


    Well i'm 99,99% sure that Google is using Linux or a BSD for there
    non critical web servers, so i think it's best that you as a Fanboy
    ask them to do this.

    > Independently of this, it ocasionally pays to become familiar with
    > something before declaring it to be obsolete for some weird reason.



    > Quoting from the linked paper (I have not read it entirely, because I
    > have no actual interest in text editing):
    >
    > The more sophisticated sequence data structures keep the
    > sequence as a recursive sequence of spans of text. The line
    > span method keeps each line together and keeps an array or a
    > linked list of line pointers.


    Yes but they are AFAIK pointer into the buffer. They are not C
    strings.
    This has advantages and disadvantages. What you really need is a
    datastructure
    that let you attach arbitrary data to each line. As i said, text
    editors can be
    really complicated - the part to represent text and do simple insert/
    delete is
    pretty irrelevant. And try to implement a column editing mode with
    this datastructure
    (all that keep spans of text), this will make you crazy. By the way:
    Do VI and Emacs
    have column editing modes?


  6. Re: coding text editor

    llothar writes:
    >> Perhaps you can manage to convince to author of the toy program you
    >> use for posting to usenet that preserving the line (or even paragraph
    >> structure) of the text would be more sensible than forcing it into the
    >> 'well-kown' Windows-invented 'comb structure' ...

    >
    > Well i'm 99,99% sure that Google is using Linux or a BSD for there
    > non critical web servers,


    Which part of 'some software you are using produces (ridicolously)
    unreadable text (in a format 'originally invented' by MS Outlook)'
    didn't you understand?

    >> Independently of this, it ocasionally pays to become familiar with
    >> something before declaring it to be obsolete for some weird reason.

    >
    >
    >> Quoting from the linked paper (I have not read it entirely, because I
    >> have no actual interest in text editing):
    >>
    >> The more sophisticated sequence data structures keep the
    >> sequence as a recursive sequence of spans of text. The line
    >> span method keeps each line together and keeps an array or a
    >> linked list of line pointers.

    >
    > Yes but they are AFAIK pointer into the buffer. They are not C
    > strings.


    |Texts are not span's of characters. They are
    |structured in lines and we should preserve this.

    This was what you wrote. The text I quoted from the paper talks about
    doing exactly this.

  7. Re: coding text editor

    Hi! I am now having problem with using ncurses. I cannot use the Home
    key and other special keys. Also how to use the escape key.
    I have enabled the cbreak mode and also the keypad. If possible can
    anyone write a small snippet to do the above.
    Please help. I am using it on a dell d531 laptop with Fedora 8 x86_64
    OS. can this be a problem?
    Thanking you,
    Sid

    On Mar 20, 2:33*pm, sid wrote:
    > Hi!
    > * * I am writiing a VI like text editor in C++ for the console. I
    > would like to know some opensource tools that would help me build it
    > faster. Also, What would be the best approach to build it?
    > *Thank You.



+ Reply to Thread