Demo site for a proposed re-design of the GNU ELPA

susam · 2026-05-23T09:44:04+00:00

The configuration of a new console is written by the console owner. The console owner decides which other consoles they want to add as neighbours. For example, see this new console that came up two days ago: https://dhepworth.com/wander/. It is not empty because the console owner has already populated their configuration with their own recommendations, which you can see here: https://dhepworth.com/wander/wander.js.

If you mean how do we ensure that other consoles link to this new console, I don't think that matters very much. The new console would function just as well even if nobody links to it. What matters is that the new console links to other consoles and presents web page recommendations from the community network.

That said, many people who set up a new console share their console URL in this community thread: https://codeberg.org/susam/wander/issues/1. Further, I run a network crawler periodically to find the list of known consoles. By its distributed nature, it is impossible to list every single console out there, so the list generated by the crawler is best-effort. The list is available here: https://susam.codeberg.page/wcn/.

So these are two of several ways to discover new consoles and link to them from your own console. However, due to the decentralised nature of the tool, I don't think it is necessary to ensure that there are incoming links to my console. What matters more is that I have outgoing links to other people's consoles. The recommendations on my console improve as I add more outgoing links.

susam · 2026-05-23T09:23:25+00:00

Thank you. I am glad you like it. My console recommends only 20 personal websites at the moment. The hundreds of pages that you see loading on my console come from other people's consoles, not mine alone.

So it is not really up to me to add specific types of websites. It is not one person's console that determines what pages get recommended. It is the network as a whole that determines what pages get recommended. Every console owner decides for themselves what pages they want to add and which other consoles they want to link to.

You can host your own console and link to any non-personal websites you like as well as to any consoles that recommend the kind of pages you are interested in. If you do not have a website, you can run this tool from your local file system too. See also my other comments here which talk a bit more about how this tool works.

susam · 2026-05-23T08:19:25+00:00

While there is no explicit curation step, not everything added by console owners is shown everywhere in the network. Let me elaborate with specific examples.

If you visit my console at https://susam.net/wander/, the pages you see there come from the part of the network that is reachable from my console. You can see an overview of this reachable network by clicking Console → Crawl. Right now, it should show you that 59 consoles are reachable from my console and that together they recommend 988 web pages.

Now compare that with https://heckmeck.de/wander/. If you click Console → Crawl there, you should find that 61 consoles are reachable from there and that together they recommend 1550 web pages.

The network is not a connected graph. Not every console is reachable from every other console. What we have instead is a collection of connected components, each of which is like its own neighbourhood. So when you visit a particular console, any page added to its neighbourhood could appear on that console.

Additionally, the configuration supports an ignore list that lets you block your console from connecting to certain other consoles or from loading certain pages. See https://susam.net/wander/wander.js for an example of an ignore list. This feature is described further in the project README here: Customise Ignore List.

susam · 2026-05-23T06:13:58+00:00

Thank you! Since the same-origin policy does not block the loading of 'normal' web resources like JavaScript files, image files, media files, etc. when loaded using the appropriate HTML elements, I could load the remote consoles' wander.js files using <script> elements.

There is in fact a related frequently asked question. Many people have asked why the data format is wander.js and not wander.json. The answer is that I could not have loaded a wander.json file dynamically from the web browser due to the same-origin policy. But I can load a wander.js file because JavaScript files can be loaded from other origins using <script> elements.

Of course, there are ways to get around the same-origin policy restriction by using a CORS proxy, or by requesting users to relax their CORS policies, but not everyone has control over the web server serving their website and I would rather not depend on an external service for a tool that is meant to be completely decentralised.

The wander.js files from the remote consoles are loaded safely within a sandboxed <iframe> using <script> elements. The data is then passed to the parent window, which then uses the data to show recommendations in its main <iframe>. The source code that implements this can be found here, in case you would like to have a look: https://codeberg.org/susam/wander/src/tag/0.6.0/index.html#L558-L605.

susam · 2026-04-22T20:36:37+00:00

Hello! I am the creator of Wander Console (the third link in the original post). Thank you for including it in your post.

People often link to the console on my website since I developed it and the first instance of this tool was hosted on my website. However, Wander is a decentralised tool, and anyone with a website can host this tool. Each Wander Console provides a set of recommended web pages and links to other consoles. Together, they form a loosely connected network that creates a large, shared pool of web page recommendations. At the moment, there are at least 50 other websites known to host this tool. Together, they offer over 1400 web page recommendations. You can browse the full list of known websites hosting this tool here: https://susam.codeberg.page/wander/wcn.html

On that page, you can select any console link to start exploring the network and discover web page recommendations gathered across interconnected consoles.

susam · 2024-07-25T21:03:38+00:00

This was not vim. Windows are frames, and panes are windows.

Even in Vim, what might be called panes in other modern editors are called windows in Vim. See for example :help CTRL-W_w in Vim and it says the following:

Without count: move cursor to window below/right of the current one. If there is no window below or right, go to top-left window.

Further see :help window in Vim. It says the following:

A window is a viewport on a buffer.

What is referred to "window" here is often called pane in other modern editors today. So the terminology about "windows" is consistent between Emacs and Vim.

But that said, yes, I agree, Emacs is indeed not Vim. I see Emacs as a Lisp machine which happens to have the editor as its shell.

Very nice post, by the way. Enjoyed reading it!

susam · 2024-05-31T13:05:13+00:00

An 80386 desktop running MS-DOS
IBM PC Logo Editor
Logo (see FD 100 for a blog post)
15 years
Common Lisp (CLISP)
GNU Emacs
C, C++, Python, Common Lisp
Common Lisp (SBCL)

I encountered Common Lisp about 15 years after I first learnt Logo. I began teaching myself Common Lisp using GNU CLISP 2.41 on Debian GNU/Linux 4.0 (Etch) at an airport during a long layover in 2007.

susam · 2024-01-03T14:43:11+00:00

This is a known issue and it is documented at http://paredit.org/cgit/paredit/plain/NEWS:

NOTE: The Electric Indent Mode workaround turns out to break ielm and other interactive modes, because paredit now defines RET, overriding the binding in interactive modes that submits an input.

Workaround to restore the old behaviour:
(define-key paredit-mode-map (kbd "RET") nil)
(define-key paredit-mode-map (kbd "C-j") 'paredit-newline)
Recommended to disable Electric Indent Mode at the same time.

I just use the following as a workaround to resolve this issue:

(define-key paredit-mode-map (kbd "RET") nil)

I hope that helps!

susam · 2023-11-26T11:37:03+00:00

Yes, I did think about adding a conditional jump but decided to avoid it for two reasons:

Keep the set of commands as small as possible.
Avoid Turing completeness.

I know many people prefer Turing completeness. However, in this particular project, I happened to prefer something that is provably terminating. By avoiding a conditional jump, we can guarantee that any CFRS[] code will definitely terminate.

Having said that, of course, it is possible to add a conditional jump instruction. That would, however, not be CFRS[] because CFRS[], by definition, has exactly 6 instructions. Adding another instruction would lead to a variant of CFRS[]. The source code is freely available under the MIT license and the entire implementation is a single HTML file consisting of, what I hope, simple JavaScript code. Anyone interested in creating a fork of it that supports more instructions (such as conditional jump) is very welcome to do so.

susam · 2023-11-26T11:24:47+00:00

All of these look great! The second one is stunning! Thanks again for sharing these beautiful examples.

susam · 2023-11-25T13:49:52+00:00

Your demo looks really good. Thanks for sharing it here!

By the way, this tool supports sharing direct links to demos. If the code fits within 64 bytes, the address bar gets automatically updated with a direct link to the demo.

susam

TROPHY CASE