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
            Re: Editor design & Buffer Gap Anthony Howe <achowe@snert.com> - 2026-10-18 06:03 -0400
              Re: Editor design & Buffer Gap cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-18 23:26 +0000
              Re: Editor design & Buffer Gap steve g <Sgonedes1977@gmail.com> - 2026-10-19 13:08 -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] | [next] | [standalone]

#106994 — Re: Editor design & Buffer Gap

On 2026-10-12 17:42, steve g wrote:
> 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 !

Redisplay in text, you thinking Curses/NCurses?

Curses was designed to abstract the assorted video terminals of the day (now 
everything is an VT100/ANSI derivative) and to optimise the sending of minimal 
sequences of escape codes to a **serial terminal** (or terminal emulator) to 
update the screen.

There used to be BSD Curses, Solaris Curses, System V Curses, pdcurses, (and 
Mortice Kern Systems (MKS) Curses).  X/Open (now SUS) created a standard for 
Curses that brought together the minor difference into one.  NCurses (written in 
C++) was starting around the time of POSIX.2, X/Open, and Unicode standards and 
hasn't change much since and is stable.  SUS has Curses Issue 7 which clarifies 
the text.

Terminal Difference algorithms are related to Edit Distance / Longest Common 
Subsequence algorithms - think `diff(1)`.  There is a paper from Bill Joy on 
Curses and some other papers related to terminal Edit Distance/LCS I obtained 
when working on MKS Curses (buried on my book shelf).

There are books "Software Tools in PASCAL" by Kernigan & Plauger ISBN 
0-201-103342-7 and "A Software Tools Sampler" by Web Miller ISBN 0-13-822305-X 
that cover editors.  The latter also covers terminal updating for an editor 
(Edit Distance/LCS).  See also `diff(1)` and my IOCCC 2015 `npdif(1)` also cover 
Edit Distance/LCS (I supply several References in the documentation to papers).

Frankly I think terminal updates is a well solved problem - worth learning and 
studying since the topic of Edit Distance/LCS relates to other subject areas 
like gene sequencing, but not worth a new library IMO.

 > 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.

An editor's edit engine covers the storage and its manipulation of the text. 
The terminal update display algorithm for an editor would be part of the 
UI/hardware interface and as has been mentioned else where GUI for desktop 
paradigms.

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

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

#106995 — Re: Editor design & Buffer Gap

In article <11b25hh$11ann$1@dont-email.me>,
Anthony Howe  <achowe@snert.com> wrote:
>On 2026-10-12 17:42, steve g wrote:
>> 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 !
>
>Redisplay in text, you thinking Curses/NCurses?
>
>Curses was designed to abstract the assorted video terminals of the day (now 
>everything is an VT100/ANSI derivative) and to optimise the sending of minimal 
>sequences of escape codes to a **serial terminal** (or terminal emulator) to 
>update the screen.
>
>There used to be BSD Curses, Solaris Curses, System V Curses, pdcurses, (and 
>Mortice Kern Systems (MKS) Curses).  X/Open (now SUS) created a standard for 
>Curses that brought together the minor difference into one.  NCurses (written in 
>C++) was starting around the time of POSIX.2, X/Open, and Unicode standards and 
>hasn't change much since and is stable.  SUS has Curses Issue 7 which clarifies 
>the text.

Eh?  I'm pretty sure `ncurses` is in C.

>Terminal Difference algorithms are related to Edit Distance / Longest Common 
>Subsequence algorithms - think `diff(1)`.  There is a paper from Bill Joy on 
>Curses and some other papers related to terminal Edit Distance/LCS I obtained 
>when working on MKS Curses (buried on my book shelf).

Really?  I know James Gosling wrote a paper on optimizing edit
distances applied to screen updates where he presented a dynamic
programming algorithm that ran in O(n^2) time.  It was pretty
nifty, and caused a kerfuffle when Stallman put it into GNU
emacs.  https://dl.acm.org/doi/abs/10.1145/800209.806463

Ken Arnold wrote the paper on Curses, but didn't really get into
the details of the implementation; he does credit Joy with the
display code, which he ripped out of `vi`.  Mary Ann Horton did
a better algorithm at AT&T, and left a description of it on a
park bench on day, from where it subsequently made it into
pcurses.

>There are books "Software Tools in PASCAL" by Kernigan & Plauger ISBN 
>0-201-103342-7 and "A Software Tools Sampler" by Web Miller ISBN 0-13-822305-X 
>that cover editors.  The latter also covers terminal updating for an editor 
>(Edit Distance/LCS).  See also `diff(1)` and my IOCCC 2015 `npdif(1)` also cover 
>Edit Distance/LCS (I supply several References in the documentation to papers).

Webb Miller wrote several papers on this, which are interesting;
he observed that Gosling's algorithm breaks down because it
assumes all editing commands have a uniform cost, but reality is
more nuanced, and the cost of each command is proprotional to
the _length_ of the command; going to position (23, 78) is more
expensive than going to (2,4); etc.  He presented a dynamic
programming algorithms that addressed this efficiently for the
row-replacement problem, and implemented them in his `s` editor
as a proof of concept; I don't think that version made it into
the Software Tools Sampler, though, nor to any of the versions
of S that are online. https://dl.acm.org/doi/10.5555/52187.52188
and https://dl.acm.org/doi/abs/10.1145/59287.59290 are links;
the text of the first paper is online.

>Frankly I think terminal updates is a well solved problem - worth learning and 
>studying since the topic of Edit Distance/LCS relates to other subject areas 
>like gene sequencing, but not worth a new library IMO.

+1.

Sadly, in recent years it seems that people have largely given
up on this, however.  Our systems are so blindingly fast now
that lots of programmers just repaint the whole display canvas
on each change.

> > 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.
>
>An editor's edit engine covers the storage and its manipulation of the text. 
>The terminal update display algorithm for an editor would be part of the 
>UI/hardware interface and as has been mentioned else where GUI for desktop 
>paradigms.

It may be worth mentioning that similar editing distance
minimization techniques can be useful for e.g., updating a
bitmapped display (also a solved problem, however).

	- Dan C

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

#106997 — Re: Editor design & Buffer Gap

Anthony Howe <achowe@snert.com> writes:

> On 2026-10-12 17:42, steve g wrote:
>> 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 !

> Redisplay in text, you thinking Curses/NCurses?

terminfo/ncurses


> Curses was designed to abstract the assorted video terminals of the day (now
> everything is an VT100/ANSI derivative) and to optimise the sending of minimal
> sequences of escape codes to a **serial terminal** (or terminal emulator) to
> update the screen.

yes i am aware

> There used to be BSD Curses, Solaris Curses, System V Curses, pdcurses, (and
> Mortice Kern Systems (MKS) Curses).  X/Open (now SUS) created a standard for
> Curses that brought together the minor difference into one.  NCurses (written
> in C++) was starting around the time of POSIX.2, X/Open, and Unicode standards
> and hasn't change much since and is stable.  SUS has Curses Issue 7 which
> clarifies the text.

I am very aware of this aggrevation.

> Terminal Difference algorithms are related to Edit Distance / Longest Common
> Subsequence algorithms - think `diff(1)`.  There is a paper from Bill Joy on
> Curses and some other papers related to terminal Edit Distance/LCS I obtained
> when working on MKS Curses (buried on my book shelf).

yeah, but building the matrix is not easy, especially when the person is
currently typing.


> There are books "Software Tools in PASCAL" by Kernigan & Plauger ISBN
> 0-201-103342-7 and "A Software Tools Sampler" by Web Miller ISBN 0-13-822305-X
> that cover editors.  The latter also covers terminal updating for an editor
> (Edit Distance/LCS).  See also `diff(1)` and my IOCCC 2015 `npdif(1)` also
> cover Edit Distance/LCS (I supply several References in the documentation to
> papers).


YES! New Books! Thank you!

> Frankly I think terminal updates is a well solved problem - worth learning and
> studying since the topic of Edit Distance/LCS relates to other subject areas
> like gene sequencing, but not worth a new library IMO.

I agree with you on this.

> An editor's edit engine covers the storage and its manipulation of the text.
> The terminal update display algorithm for an editor would be part of the
> UI/hardware interface and as has been mentioned else where GUI for desktop
> paradigms.

Well call the "edit engine" a "redisplay engine".
Thank you for the descent conversation and my new books that are now
being shipped by amazon, thank you for the recommendations.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.editors

csiph-web