Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.editors > #106967 > unrolled thread

z-ed

Back to article view | Back to comp.editors

Contents

  z-ed Zayd Mohammed <zaydm@172.24.208.1> - 2026-08-16 21:29 +0000
    Re: z-ed Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-16 16:20 -0700
      Re: z-ed Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-17 21:46 +0800
        Editor design & Buffer Gap Anthony Howe <achowe@snert.com> - 2026-10-11 09:05 -0400
          Re: Editor design & Buffer Gap ram@zedat.fu-berlin.de (Stefan Ram) - 2026-10-11 13:42 +0000
          Re: Editor design & Buffer Gap Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-11 21:00 +0000
            Re: Editor design & Buffer Gap Anthony Howe <achowe@snert.com> - 2026-10-11 20:50 -0400
              Re: Editor design & Buffer Gap Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-12 06:11 +0000
                Re: Editor design & Buffer Gap Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-12 11:05 +0200
          Re: Editor design & Buffer Gap steve g <Sgonedes1977@gmail.com> - 2026-10-12 17:42 -0400

#106967 — z-ed

who wants to collaborate on this:
https://github.com/Zaydiscool777/z-ed


-- 
https://zaydiscool777.github.io/index.html
https://beacons.ai/zaydiscool777 <- list of links, not actually ai
zaydiscool777@gmail.com <- use this if not replying on usenet

[toc] | [next] | [standalone]

#106968

Zayd Mohammed <zaydm@172.24.208.1> writes:
> who wants to collaborate on this:
> https://github.com/Zaydiscool777/z-ed

Most likely nobody if you don't provide more information.

Even the README.md in the git repo only says "Nothing notable, as this
is unfinished. Any help you give in the project will be helpful.", with
a hand-drawn diagram.

You cross-posted to comp.lang.c and comp.editors, with followups to
comp.lang.c.  I've cross-posted and directed followups to comp.editors.
This isn't topical in comp.lang.c unless you're talking about the
language.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#106970

On 17/08/2026 7:20 AM, Keith Thompson wrote:
> Zayd Mohammed <zaydm@172.24.208.1> writes:
>> who wants to collaborate on this:
>> https://github.com/Zaydiscool777/z-ed
> 
> Most likely nobody if you don't provide more information.
> 
> Even the README.md in the git repo only says "Nothing notable, as this
> is unfinished. Any help you give in the project will be helpful.", with
> a hand-drawn diagram.
> 
> You cross-posted to comp.lang.c and comp.editors, with followups to
> comp.lang.c.  I've cross-posted and directed followups to comp.editors.
> This isn't topical in comp.lang.c unless you're talking about the
> language.
> 

I know you've killfiled me, so good luck replying!  Of course we want to
discuss how to make editors in comp.lang.c.  Finseth wrote a great book
about how to make an Emacs in C, so I've re-added comp.lang.c, and also
added comp.emacs, because who doesn't want to know about completely for-
eign implementation of Emacs from scratch?

So, everyone interested in the subject can just head over to

   https://www.finseth.com/craft/

grab a copy of the PDF, and /read/ how to make an Emacs, in C.


Happy text editing!
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;

[toc] | [prev] | [next] | [standalone]

#106983 — Editor design & Buffer Gap

On 2026-08-17 09:46, Johann 'Myrkraverk' Oskarsson wrote:
>                                                    Of course we want to
> discuss how to make editors in comp.lang.c.  Finseth wrote a great book
> about how to make an Emacs in C, so I've re-added comp.lang.c, and also
> added comp.emacs, because who doesn't want to know about completely for-
> eign implementation of Emacs from scratch?
> 
> So, everyone interested in the subject can just head over to
> 
>    https://www.finseth.com/craft/
> 
> grab a copy of the PDF, and /read/ how to make an Emacs, in C.

I have implemented two editors in the `vi(1)` style that used "Buffer Gap" as 
discussed in Finseth's book, which I bought as hard copy long ago.  It was 
central to both.

`eh` was an IOCCC 2024 winner.  The full version provides more features, but 
still is a very small `vi`.  Version 1.9.0 supports UTF8, arrow keys, and paging 
in insert mode, along with a `Gold-Key`.  Together these tweaks are essentially 
a hybrid between vi and emacs.  Wouldn't take much to modify the front-end and 
go full emacs, or joe, or nano.  https://codeberg.org/SirWumpus/eh

`ae` was an IOCCC 1991 winner, a `vi` in 1536 bytes of C source code.  The 1993 
version allowed for configuration as either modal `vi` like or modeless `emacs` 
like.  https://github.com/SirWumpus/ioccc-ae

There are two aspects of an editor:

* the underling edit & storage engine (buffer-gap, link-list lines, Berkeley DB, 
rope, etc.)  See https://en.wikipedia.org/wiki/Gap_buffer#See_also lists several.

* the user interface (ed, vi, emacs, xedit/kedit, touch screen/stylus, ...)

* target environment (ok, two part design expressed as a trilogy).

The designing the edit engine is what fascinates me, regardless of UI.  Pity 
there are few discussions any more around this topic.

UI is influenced by the history of interface hardware: teletype printers, serial 
cable terminals, block-mode terminals, PC, PDAs + stylus, fondle slabs 
(tablets/smart phones), voice, "mind control"/direct human interface.  These are 
all interesting too, but they rely on the edit engine to do the work.

-- 
Anthony C Howe
achowe@snert.com                              BarricadeMX & Milters
http://nanozen.snert.com/              https://github.com/SirWumpus

[toc] | [prev] | [next] | [standalone]

#106984 — Re: Editor design & Buffer Gap

Anthony Howe <achowe@snert.com> wrote or quoted:
>The designing the edit engine is what fascinates me, regardless of UI.  Pity 
>there are few discussions any more around this topic.

  I heard of ropes and the piece table, both with specific
  advantages and disadvantages. One could separate the UI
  from the engine by an interface and then allow the user 
  to select the engine as late as at runtime, like

myedit -ui=vim -engine=ropes myfile.txt

  . Something like this is done in MySQL where one can select
  the storage engine at runtime.

[toc] | [prev] | [next] | [standalone]

#106985 — Re: Editor design & Buffer Gap

On Sun, 11 Oct 2026 09:05:36 -0400, Anthony Howe wrote:

> The designing the edit engine is what fascinates me, regardless of
> UI. Pity there are few discussions any more around this topic.
>
> UI is influenced by the history of interface hardware: teletype
> printers, serial cable terminals, block-mode terminals, PC, PDAs +
> stylus, fondle slabs (tablets/smart phones), voice, "mind
> control"/direct human interface. These are all interesting too, but
> they rely on the edit engine to do the work.

All the best open-source content-creation apps are built around a
scriptable/command-line engine with the UI as a separate layer.

[toc] | [prev] | [next] | [standalone]

#106986 — Re: Editor design & Buffer Gap

On 2026-10-11 17:00, Lawrence D’Oliveiro wrote:
> All the best open-source content-creation apps are built around a
> scriptable/command-line engine with the UI as a separate layer.

For me that's a Unix shell (ksh, rc) which provides scripting, plus AWK, sed, 
and other similar tools.  Unix command line IS the IDE for me.  The `vi` family 
is built around shell (filter commands, ctags), etc.

As long as an editor can filter text in some manner and read the result back as 
new or replacement text, one has sufficient tools (assuming they see how the CLI 
can work with the editor).

Its all perspective.


-- 
Anthony C Howe
achowe@snert.com                              BarricadeMX & Milters
http://nanozen.snert.com/              https://github.com/SirWumpus

[toc] | [prev] | [next] | [standalone]

#106987 — Re: Editor design & Buffer Gap

On Sun, 11 Oct 2026 20:50:51 -0400, Anthony Howe wrote:

> On 2026-10-11 17:00, Lawrence D’Oliveiro wrote:
>>
>> All the best open-source content-creation apps are built around a
>> scriptable/command-line engine with the UI as a separate layer.
>
> For me that's a Unix shell (ksh, rc) which provides scripting, plus
> AWK, sed, and other similar tools. Unix command line IS the IDE for
> me. The `vi` family is built around shell (filter commands, ctags),
> etc.

Not really good enough any more. The combination of a GUI and a
command line can be more powerful than either alone. GUI gives you
copy/paste, which you can apply to command/script snippets --
ironically, the GUI itself doesn’t let you apply such operations to
GUI user actions.

For an IDE, I regularly use two: Emacs and Jupyter. Emacs is for more
heavy-duty development, while Jupyter is handy for less formal work:
its notebook paradigm makes it easy to do “scratchpad” programming,
experimentation, that kind of thing. Each notebook cell can hold any
amount of code in any of a range of languages, and can display rich
output in a variety of formats -- plain text, formatted text,
graphics, video, audio ... plus of course the option for interactive
widgets to allow the output to be “live”.

[toc] | [prev] | [next] | [standalone]

#106988 — Re: Editor design & Buffer Gap

On 2026-10-12 08:11, Lawrence D’Oliveiro wrote:
> On Sun, 11 Oct 2026 20:50:51 -0400, Anthony Howe wrote:
>> On 2026-10-11 17:00, Lawrence D’Oliveiro wrote:
>>>
>>> All the best open-source content-creation apps are built around a
>>> scriptable/command-line engine with the UI as a separate layer.
>>
>> For me that's a Unix shell (ksh, rc) which provides scripting, plus
>> AWK, sed, and other similar tools. Unix command line IS the IDE for
>> me. The `vi` family is built around shell (filter commands, ctags),
>> etc.
> 
> Not really good enough any more. The combination of a GUI and a
> command line can be more powerful than either alone. GUI gives you
> copy/paste, which you can apply to command/script snippets --
> ironically, the GUI itself doesn’t let you apply such operations to
> GUI user actions.

Are you two still talking about the same topic? - Your previous
post, Lawrence, was about UI, now you speak about GUI.

GUIs typically have mouse control, buttons, menus.

The Vi interface is a text UI. It needs no GUI; that's actually
its strength that you can do things efficiently with the keyboard
not slowing speed by changing forth and back between keyboard and
mouse.

Copy/Paste with the mouse (that you mention) can also be done on
the command line interface since the Window-managers provide that
functionality. But that is typically not the most efficient way
to copy things with Vi.

(The Gvim has a GUI above the Vim, for example, but it [mostly]
doesn't add anything essential to the power of the underlying Vi
"engine", though.)

Janis

[ comp.lang.c removed from cross-post ]

> [..]

[toc] | [prev] | [next] | [standalone]

#106989 — Re: Editor design & Buffer Gap

Anthony Howe <achowe@snert.com> writes:


> The designing the edit engine is what fascinates me, regardless of UI.  Pity
> there are few discussions any more around this topic.


I agree. I would love to play with a redisplay engine. let alone read
more about them. I usually just read some old pascal books from the
1990s. I would love to reimplement lotus style menus !


> UI is influenced by the history of interface hardware: teletype printers,
> serial cable terminals, block-mode terminals, PC, PDAs + stylus, fondle slabs
> (tablets/smart phones), voice, "mind control"/direct human interface.  These
> are all interesting too, but they rely on the edit engine to do the work.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.editors

csiph-web