Joining forces between Lem and Next browser

[Ambrevar]

I've been hard at work on Next browser for the past few months and it occurred to me that a lot of concepts we are working on with Next have already been implemented in projects like StumpWM or Lem.

For instance, it would be nice to have a full-fledged editor within Next (there are already functions like delete-backwards-word and kill-line, but that's rather basic at the moment).

So instead of re-inventing the wheel, what about factorizing the work into reusable libraries? Maybe Lem's code could already be reused as a library in Next: what would be the most convenient way to proceed then?

A similar idea was implemented in Guile scheme: Emacsy. It's essentially "Emacs as a library." The Nomad web browser (which happens to be extremely similar to Next both in features and goals) is based on it. A first alpha was released recently: I like how reusable the code is.

The main differences between all those projects is the language and the "view renderer." A web-based renderer has the benefit that it can render anything: pictures, GIFs, vector graphics, videos, 3D and, the hardest of them all, web pages! :) (Those two alone would essentially fix Emacs' biggest drawbacks.)

At this point it's clear to me that there are a lot of ideas out there taking off, and it seems that we are all trying to do the same thing: a programmable (Lisp-based) environment. I believe we could achieve great things by joining forces and collaborating on code and ideas.

Example of some features which could be shared, at least for the design, if not for the code:

• Buffer management.

• Window management? And what about sharing some code with StumpWM here? A
  window management library would be nice.

• Key bindings: this is really hard to get right. Next is already similar to Lem (although the code is a big hack that needs a good clean up), but has the concept of "binding schemes" which allows for defining separate Emacs-style and VI-style bindings in a way that is composable). Emacs has lots of ideas there too, e.g. the general library.

• Modes: Next needs to borrow more from Lem here ;) Will try to do this week.

• Hooks: Same.

• Minibuffer: There are a lot of approaches to the minibuffer problem. From day 1 Next attempted to follow the design of Emacs' Helm/Ivy. I believe it's important to aim high here. I know it's a matter of taste, but everything should be configurable and after all, if you can do more, you can do less!

• And possibly bookmarks, kill rings, keyboard macros, undo list (tree?), and so much more.

Thoughts? @cxxxr @jmercouris @vindarel @mrosset @PuercoPop @jorams
(Feel free to include others in the discussion.)

[svetlyak40wt]

How about browser-mode for Lem? :)

This way a browser may be open as one of the buffers.

[mrosset]

Hello @Ambrevar

For nomad I originally starting writing my own emacs features. But thanks to work by @janneke to revive and fix some short comings in Emacsy. I've switched to using emacsy where possible.

Based on your criteria of buffer management, window, key bindings, modes, hooks, minibuffer and macros, kill rings. Emacsy provides all of those things in a pretty generic way. The only thing I've seen so far that emacsy does not handle yet is frames *note what modern people call windows :) .
I have not looked much into macros, kill rings. And I'm not sure if emacsy handles undo quite yet.

Emacsy also provides some features that you would expect from emacs. Like command history, minibuffer keybindings, mode maps.

For text-buffers its pretty trivial to use emacsy. I actually added text editor support to nomad using emacsy premitives and a gtk source view. here's my naive redisplay to handle this redisplay. This was a quick hack. But with a little work this could easily provide full text editing. Basically emacsy does all the work and the graphical widget is used to redisplay.

In terms of a emacsy webview-buffer. I have done some work with nomad to try to make this as generic as possible. The issue with webview's is they are tied to the html rendering backend. So it's hard to make this generic. Right now with nomad I only handle really basic browser functions. Like back, forward, scroll up, scroll down. But to make a true webview buffer with say a cursor, marking etc. This would require DOM introspection and that's a pretty daunting task for GTK. I think with QT Webengine this would be easier. But again not sure how to make this generic either.

I'm also not sure how emacsy would translate into CL.

Also emacsy would need some work to provide helm/ivy modern UI features. Though I do intend to provide helm/ivy features to emacy or nomad where possible. But as of now I've kept to using emacsy 's basic emacs UI for simplicity. But this is definitely something I can help with if you were to consider using emacsy.

CC: @o-nly

[Ambrevar]

Regarding the webview manipulation: I believe you can do DOM introspection simply by sending the right Javascript to WebKitGTK. That's what I do in Next. (I use Parenscript to be precise, a lispy way to write Javascript.)

What's most tricky about it is that Javascript (and thus the DOM) are foreign to the calling site (the Lisp), so it's not so easy to do error control, etc.
Another thing is that Javascript may run asynchronously. Asynchronous operations on a foreign component make the whole program significantly more complex I believe.

Regarding Helm/Ivy: I don't think it would be too hard to add it to Emacsy. In fact, many of the "basic Emacs UI" features would not need to be implemented once Helm/Ivy is implemented.
Actually, I recomment thinking straightaway of the more general Helm/Ivy: the mix of both, which means essentially Helm that ca be placed anywhere (currently in Emacs Helm must spawn a new buffer beside that actual minibuffer -- we don't need that).

[vindarel]

In addition to the first list, we certainly have common interest in

• candidates selection based on criteria (just starting in Next),
• fuzzy matching (done alright in Next)
• introspection features and nice display (basic in Next). In addition to printing the function documentation, we want to cross-link, display associated variables and commands, print similar functions, etc.

I'd be also interested in sharing knowledge and difficulties on publishing third-party libraries and keeping on track (git subprojects and Quicklisp, using Qlot or Ultralisp or not, etc).

Now back to reading Lem's sources.

[akater]

Original post reflects my thoughts, almost exactly. I have four somewhat large things to share.

1. StumpWM

I do wish I had a Common Lisp Desktop Environment (CLDE for short). I wish I could contribute to it, too. But I do not want a desktop environment which has three different ways of spliting the screen, much less do I want to contribute to one: even if one does want to use it, it sounds like a mess to work on.

Lem can split screen. So can StumpWM. Next has minibuffer. So does Lem. If Next can't split screen yet, I'm pretty sure it one day will. Ditto StumpWM/minibuffer. The screen-splitting example highlights why I think StumpWM should have been included in the list in the issue title.

However, StumpWM is X-only. The only discussion re: Wayland in StumpWM GitHub repository stumpwm/stumpwm#739 is pessimistic about its Wayland future. The discussion linked above also mentions Mahogany https://github.com/sdilts/mahogany an attempt at StumpWM-inspired Wayland alternative that starts from scratch, due to the pessimistic conclusions outlined in the discussion.

I guess I have no conclusion for point 1, but rather a question: how feasible does it look to you to have a screen splitting functionality that is not in any way duplicated across Lem, Next, and (one or maybe several) CL window manager(s)? P.S. I'm using EXWM when I use X; having web pages in separate Emacs buffers is a pleasant experience.

2. Moving the design forward

One might say that users or potential contributors don't have to think about these different admirable programs as if they were a mythical Common Lisp environment of one's personal dreams. I respectfully disagree. As well-known aphorism goes ≈like this: “each program tends to grow until it incorporates a mail reader.” Of all present day users of computing environments, Common Lisp users probably know and understand this aphorism better than others.

I believe it would be a terrible waste if these two (maybe three, depending on answers to point 1) programs are kept being developed in isolation. On the other hand, getting their “core” right looks like an intellectually challenging and time-consuming task.

There are Patreon and OpenCollective pages for Next and Lem respectively; I think descriptions on those pages should mention this line of work too—eventually if not right now. The question is, what exactly could this work realistically be?

This thread is about 7 months old, and there is no conclusion on what's next. (No pun intended.) It is unrealistic to set the large-scale design and go on implementing it. But some decisions need to be made. I believe this issue can be closed as soon as it becomes established how this work should go. Actually, I believe that it should be closed this way because otherwise it can stay open indefinitely long, to everyone's dismay, with no understanding of what to do next.

One obvious basic question: should there be one single core library that could constitute a basis of CLDE, or should there be many, crystallized as developers of Lem and Next go along? Or maybe thinking in terms of CLDE is a bad idea in the first place? (Looks like @Ambrevar, at least, agrees it's not) I think it would be more productive to settle on this, decide where the discussion of the implementation will go, who's expected to participate, and close this topic, the way it's formulated, to avoid vicious circle of indecisiveness. As long as it stays open the way it's phrased, we're not really sure even if forces should joined at all. I'm not a contributor of any of the projects in question but if there's at least one from each side who can work on the core, whichever form it's decided to have, that should be enough to move forward.

3. Guiding lights

My last big question is, what sources of inspiration do we have? What's been mentioned so far, is

• Emacs
• Emacsy

Is that all? How far should one go in search of source of inspiration here? Should CLIM Listener serve as one? There's recent (totally alpha) Doors Window Manager based on McCLIM https://github.com/admich/Doors There's McCLIM HTML5 “backend hack” https://twitter.com/dk_jackdaniel/status/1239672579117461507 https://twitter.com/dk_jackdaniel/status/1239672579117461507 By the time any core libraries discussed here actually materialize, integration with something like this might become relevant.

Regarding Emacsy—how widely is it used? How well its successes and shortcomings are understood? Given that the task outlined seems challenging, it'd be reasonable to stick to designs that are tested and are known to work well. Lots of what's in Emacs works satisfactorily. My opinion may be irrelevant but I don't understand what knowledge is expected to be taken from a Guile library that hooks to Emacs when Emacs functions are accessible in a single Emacs memory-/user- space and CL functions, similarly, are accessible in a single CL environment. “Emacsy code is reusable”—do you (@Ambrevar) propose to write a CL layer that approaches Lem as a black box, as Guile has to approach Emacs? Maybe it's just me, and I have to read Emacsy code to understand; I'm ready to accept this as answer.

4. Omnipresence

Lem works in text mode, with the aid of ncurses. It is clear that it can work reliably in text mode; there is nothing conceptually challenging about this. Even though Emacs is mostly used in GUI, it works fine in text-only mode (I know this from experience as I mostly don't X these days, and Emacs is a great Text-Only Desktop Environment.) OTOH, making Next work in text mode can be expected to be as difficult as making any other browser work in text bode. As far as I know, rendering html reliably in text mode is an incredibly complicated task. There's not much else; my question is, what conclusions, if any, can be drawn from this observation that are relevant for our goal?

[equwal]

The CL gardeners have four principles for effective maintainership of the Common Lisp library ecosystem:

• Consumer reports: Write a comparison of different libraries that do the
  same or similar things. Summarize the strengths and weaknesses of each.
  Include "under the hood" assessment; would I want to maintain this if the
  author got hit by a bus?
• Code revival: Adopt an abandoned library and clean up the bit rot.
• Code mining: Dig through existing open source code bases of large
  applications and extract bits that can be packaged as a useful stand-alone
  libraries.
• Implementation convergence: Help bring various CL implementations into
  alignment where there's no good reason for them to differ. This can be done by
  providing portability libraries or, better yet, by doing the decidedly
  non-trivial work of finding a common ground that different implementers can
  actually agree on and then doing whatever it takes to convince them to make
  the necessary changes to their implementation. ("Whatever it takes" in this
  case, likely includes patches, test suites, documentation, and civil, egoless,
  participation in relevant developer forums.)

Here it seems we are discussing these same principles of maintainership.

@Ambrevar writes:

So instead of re-inventing the wheel, what about factorizing the work into reusable libraries?

I think this is the most important insight here. Splitting up these large
projects into CL packages, putting them in separate repos, and importing them
with CL's package system is the way to go. This is similar to code mining,
although I think the original package depending on its offspring is important
for reducing maintenance overload.

Take this portion of StumpWM's build process. It is a general method of converting some texinfo macros into tex. Lines like ### example-var get converted into CL-aware
documentation for that symbol in whatever namespace is specified by the first
three characters on the line. There is no reason that only StumpWM can benefit
from such a system, and it has nothing to do with window management.

I'd like to see an approach like this to avoid making the same mistakes as
before -- which is the creation of huge, unwieldy CL systems that have too many
tightly coupled disparate components. Currently I'm seeing the CL ecosystem
morph into a lisp machine emulator, like a highly configured Emacs. Instead of
letting this continue until the community is split between multiple large
projects, let's garden.

[akater]

Code mining: Dig through existing open source code bases of large
applications and extract bits that can be packaged as a useful stand-alone
libraries.

Applied to the case discussed, this suggests, as short-term goal, to build an indefinite amount of libraries that provide common functionality.

I'm fairly inexperienced in how it usually happens in open source space. Still, I believe that having a single specialized Lem+Next[+StumpWM or another WM] common library as a short-term goal (long-term, this library would likely split) would help its contributors stay more focused and would make contributors to Lem and Next aware of how not to complicate matters for them in corresponding areas.

Minibuffer, split-screen, setting keybindings would be solid starting goals for such library. When considering using Lem and StumpWM (independently), I first thought of these, and decided I'd rather stay with Emacs and EXWM. For those who don't know: it allows key translation, so one's init.el can make any web browser understand Emacs keys.

One feature that users wanted in EXWM was to turn all input fields (in particular, those found in graphical browsers) into Emacs buffers. It's a great goal but I just assume it's much more difficult to achieve than the above three.

[Ambrevar]

Thank you for resurrecting this thread! :)

@akater

• If I understood you right, you are confronting the approaches of a
  core library ("CLDE") vs. independent libraries.

  I don't think a "core library" is feasible not desirable. It seems
  that it's what Lem / StumpWM are already doing with too many
  opinionated design decisions, too little universality, and as a
  consequence no one ends up reusing components.

  However once we've got all the right independent libraries,
  writing Lem / Next / Stumpwm becomes trivial and CLDE naturally comes out.

  Besides, multiple Common Lisp applications can trivially communicate
  with each other, so the idea of a "common core" is not important I think.

  I don't understand what knowledge is expected to be taken from a Guile
  library that hooks to Emacs when Emacs functions are accessible in a
  single Emacs memory-/user- space and CL functions, similarly, are
  accessible in a single CL environment.

  Not sure what you mean: Emacsy does not hook to Emacs, and Nomad
  neither.

  do you (@Ambrevar) propose to write a CL layer that approaches Lem
  as a black box, as Guile has to approach Emacs?

  No, I don't think interfacing the various programs as black box is
  desirable: it's too limiting. Next, StumpWM and Lem can communicate
  with each other in pure CL, so there is no need for a black box
  interface here.

  Still, I believe that having a single specialized Lem+Next[+StumpWM
  or another WM] common library as a short-term goal (long-term, this
  library would likely split) would help its contributors stay more
  focused and would make contributors to Lem and Next aware of how not
  to complicate matters for them in corresponding areas.

  I think a common library would be hard to write and a waste of time:
  once written, it's unlikely that anyone is going to put in tremendous
  effort to split it.

  If we write independent libraries straight away, it will beneficial
  immediately.

  Finally, independent libraries don't take much more time than building
  a single core. They also have the benefit of being easier to test and
  maintain.

• Text mode: There may be a confusion between two concepts here. Either
  we are talking about the UI rendering done for terminal emulators
  (e.g. ncurses). Or we are talking about textual interfaces, e.g. EWW
  in graphical Emacs.

  Textual interfaces can be done regardless or the UI.

  Terminal UI like ncurses are not very useful nowadays in my opinion.
  The main common use case today is SSH, but for this case I'd advocate
  the use of something like TRAMP which allows us to use the GUI program
  locally over remote resources.

  (For those who find Emacs TRAMP unreliable, we would make sure the CL
  TRAMP works better!)

• Editable fields:

  One feature that users wanted in EXWM was to turn all input fields
  (in particular, those found in graphical browsers) into Emacs
  buffers. It's a great goal but I just assume it's much more
  difficult to achieve than the above three.

  I think StumpWM should already be capable of doing this. I don't use
  StumpWM myself though.

@equwal: Thanks for the link to the gardeners page, it's a nice write
up!

I've already started "mining" Next. So far I've managed to extract:

• ring-buffer structure: now in cl-containers.

• hooks: Now in
  https://github.com/atlas-engineer/next/tree/master/libraries/hooks,
  hopefully soon merged in
  Enhancing hooks ruricolist/serapeum#41.

• history-tree structure: Now in
  https://github.com/atlas-engineer/next/tree/master/libraries/history-tree.

• Password manager interface: Now in
  https://github.com/atlas-engineer/next/tree/master/libraries/password-manager.

• keymap library: Now in https://github.com/atlas-engineer/next/tree/master/libraries/keymap.

I hope to publish the last three in Quicklisp at some point.

Future libraries:

• Window management.
• Minibuffer.
• Modes.
• Commands.
• Bookmarks.
• Undo (tree).
• Keyboard macros.

[akater]

If we write independent libraries straight away, it will beneficial

immediately. Not immediately if “no one ends up reusing components”. If some common part of Next and Lem gets detached into its own system from Next, so that Next uses it as before but Lem ignores this, then effectively nothing changes.

It seems that it's what Lem / StumpWM are already doing with too many opinionated design decisions, too little universality, and as a consequence no one ends up reusing components. However once we've got all the right independent libraries, writing Lem / Next / Stumpwm becomes trivial and CLDE naturally comes out.

Since no one ends up reusing components, do you envision completely new applications being built after certain independent libraries are produced? (Say, those that you mentioned: Window management, minibuffer, etc.)

Text mode: There may be a confusion between two concepts here. Either we are talking about the UI rendering done for terminal emulators (e.g. ncurses). Or we are talking about textual interfaces, e.g. EWW in graphical Emacs.

I was mostly talking about whether one could hope to be able (in future) to start Lem in console, open html file/stream, get it rendered in a buffer by Next, interact with it through Next. If your vision of future is for Lem and Next to be replaced by something else, this question of mine is irrelevant.

[dmb2]

Hi, I just wanted to say: anything you want to pull out of stumpwm into an independent library, I am supportive of. Ideally stumpwm as a git organization would own the library in quicklisp, and whoever did the refactoring would be the angel maintainer. Less ideally, the repo would live wherever it got ripped out of. Getting the useful bits refactored into independent libraries has been a long term goal of mine, but one which has had little attention from anyone outside the stumpwm community. Please take our leaves, apples, and tree-trunk and grow into an amazing project!

[equwal]

Hi, I just wanted to say: anything you want to pull out of stumpwm into an independent library, I am supportive of.

Currently working on Sigil, which has features I want for my own documentation.

Here is some context:
stumpwm/stumpwm#696
stumpwm/stumpwm#682
stumpwm/stumpwm#695

Currently I'm still working on cleaning it up, adding tests, and adding non-breaking functionality.

Ideally stumpwm as a git organization would own the library in quicklisp, and whoever did the refactoring would be the angel maintainer. Less ideally, the repo would live wherever it got ripped out of. Getting the useful bits refactored into independent libraries has been a long term goal of mine, but one which has had little attention from anyone outside the stumpwm community. Please take our leaves, apples, and tree-trunk and grow into an amazing project!

I'll be happy to add this library to the StumpWM organization when it is working.

[Ambrevar]

@dmb2 I'd like to add windowing to Next sometime soon. Do you think it'd be possible to extract some parts of StumpWM to that end? Any pointers?

[Ambrevar]

akater <[email protected]> writes:

Not immediately if “no one ends up reusing components”. If some common part of Next and Lem gets detached into its own system from Next, so that Next uses it as before but Lem ignores this, then effectively nothing changes.

This is the responsibility of the Lem developers, there is nothing else we can do about it, regardless of how we decide to "factor the work."

> It seems > that it's what Lem / StumpWM are already doing with too many > opinionated design decisions, too little universality, and as a > consequence no one ends up reusing components. > However once we've got all the right independent libraries, > writing Lem / Next / Stumpwm becomes trivial and CLDE naturally comes out. Since no one ends up reusing components,

Why? Not sure for Lem, but as I understand StumpWM is quite active, so it it may very well happen. do you envision completely new applications being built after certain independent libraries are produced? (Say, those that you mentioned: Window management, minibuffer, etc.) Which applications? I'm not sure I understand your question. All applications, existing ones and new ones, can reuse existing libraries. That's the goal of libraries: they offer features that are reusable by anyone.

I was mostly talking about whether one could hope to be able (in future) to start Lem in console, open html file/stream, get it rendered in a buffer by Next, interact with it through Next.

I think you can already to this.

If your vision of future is for Lem and Next to be replaced by something else, this question of mine is irrelevant.

I have no clue about the future of Lem. I hope Next will take off :)

[zx9w]

Hi, I am also working towards a CLDE. See datalisp.is.

I think this issue has touched on the reasons we need to think about version control and then backed off into a bottom-up approach focusing on the immediate problems.

My approach is about trying to find the inevitable convergence points so I have proceeded very slowly. Also, I am just not that comfortable with programming yet and am in some financial difficulties etc. However! I believe that all of this can change pretty fast.

Maybe this issue can be closed.

[Sasanidas]

This issue have a really interesting conversation about commons and lisp editors/projects but I don't think it's that important to keep it open.

Can this issue be closed @Ambrevar ?

[jmercouris]

yes, it can be closed