I'm curious, did you find there were things that were easier to do because it's Janet/lisp-like language? Or you just fancied like using it (perfectly valid reason of course!).
I tried various lisp dialects, but I could never find the killer feature vs other languages I already use. And I can justify why I use these specific languages I do use, if that makes sense.
I find the REPL and interactive development workflow invaluable. A window manager is a long-running background service by nature, and has a lot of accumulated runtime states. The ability to peek inside and debug while the process keeps running helped me a lot when building Jwno.
I think Jwno's REPL module is so important, I specifically changed Jwno's architecture at one point to make it work.
> I find the REPL and interactive development workflow invaluable. A window manager is a long-running background service by nature, and has a lot of accumulated runtime states. The ability to peek inside and debug while the process keeps running helped me a lot when building Jwno.
Sure, but any particular reason you picked Janet over Common Lisp? They both support images, REPL, hot-code-reloading, etc.
TBH I dived right in when I decided I should build something with Janet, and didn't really consider any alternatives. Now you mentioned it, I think Janet's simplicity and conciseness played a large part in attracting me to it, comparing to Common Lisp at least.
Janet being a tiny embeddable runtime similar to Lua probably makes it perfect for a use-case like this. You have a full language, standard library, and interpreter in ~1 MB, along with the ability to bundle the runtime with your scripts into one binary. That's worth a lot.
I am not familiar with Janet but have been a long time lisp developer. Could you perhaps add a few lines to the readme explaining how the build process for jwno works? Would love to give it a try, understand how it works and hack around :)
> I could never find the killer feature vs other languages I already use.
You're kidding or trolling? Structural editing and the REPL are the greatest features of Lisp. The ability to just grab any expression and move it around simplifies so many things when coding and refactoring. With the connected REPL you can eval anything on the spot, that turns the entire experience of coding into a video game — you don't need to wait for linter, linker, compiler — you just run things. You often don't even have to save anything. I suspect when you "tried various lisp dialects" maybe you didn't use structural editing and the connected REPL?
Often people confuse Lisp REPL with REPLs in other programming languages, e.g. Python, where usually you have to copy-n-paste chunks of code into it. Lisp's REPLs are different in the sense that every step in Read-Eval-Print-Loop is different — in Lisp, you typically eval things right where you type them, by sending whole expressions to the connected REPL, which could be remote. We (for example) run ours in a Kubernetes cluster, that allows us to experiment with pods, running queries against the "real" DB tables, testing services "live".
I have only just begun my road down lisp, from starting to hack some elisp and working with some CL for fun. But structural editing is turning out to rapidly be my favorite feature, to the point that I'm working in my personal time on a lisp (syntax? language? idk haven't exactly decided) on top of Julia (my preferred language) so that I can use structural editing. The ability to just grab and drop entire expressions and advance through code by expression at a given level of the tree or up and down it is just really really nice.
There already is a LispSyntax.jl but it's sort of trying to be a Clojure clone and I don't care for it, haha.
I know, right? I honestly have no idea how the heck did I even code before in non-lispy languages. I imagine if I had to pair-program with someone today it would go like: "hey, how do I grab this part of the function quickly, so I can move it out?"... "Wait, what? I have to manually select it, there's no quick way of doing that with a single keystroke? Oh, I can use this 'powerful refactoring' feature of the IDE? Huh... and it only works for this specific language, there's nothing for a different one? Got it, okay... daaaarn... and I thought the coding supposed to be the easy part of programming..."
> You can implement custom commands and hooks to trigger. It's even possible to call native Win32 APIs in your own implementations. For example, to always move a Notepad window to the (100, 100) coordinates on your screen(s), using the low-level SetWindowPos function
Great job. Looks really interesting and useful. And a fun excuse to write Lisp.
I really appreciate it when APIs give you high-level functionality but keep the door open to lower-level APIs when you really need them.
My experiences with tiling window managers is that they struggle in judging a modal screen like a confirmation box or detachable/dockable mini-containers like the interface of certain programs like GIMP. Considering those as new tile-able windows tends to be a hinderance instead of increasing productivity.
For example, GIMP works without any issues. And the productivity boost is tremendous, for me it's very hard to work on anything else. I barely encounter programs where it does more harm than use.
Especially having multiple desktops with different names allow me to localize windows so much quicker than looking through a dozens of terminals manually.
Right now, I do have: 1 mail, 2 web, 3 gimp, 4 chat, 5 notes, 6 terminal, 7 ssh cluster
They do struggle with that, or rather some developers struggle with not making assumptions about the way a user's window manager is laying out their windows?
I use StumpWM, and for the few applications that this becomes a real problem it is possible to run those in a floating windows group that works just like a minimalistic non-tiling window manager. I think this is a common features of tiling window managers.
This looks to have great potential for accessibility! I work with individuals who use eye gaze input, where a significant part of the screen is taken up by an on-screen keyboard (including various shortcut/macro keys as well as for typing). Having tiling options that fit within a smaller part of the screen (e.g. still allow side by side or top/bottom split, but in a smaller total region) would be great. Particularly as Windows 11 has broken vertical docking of appbars.
The UI hints also look promising, but I can't get them working. Using example-config.janet I tried pressing RAlt or RAlt+K and I get the UI hint shortcuts list coming up, but none of them seem to do anything, except in Notepad where I sometimes get the standard UI hints (that always come up here with a long press of left alt)
Fwiw, as a newbie I found it a bit intimidating/off-putting that it doesn't work out the box without choosing a config file. That's quite a lot of extra cognitive effort and link-clicking before you can try it out. And I'm left quite unsure what I'm missing out on. Am I able to access the different documented features with the config file I have? It's not clear.
> Having tiling options that fit within a smaller part of the screen (e.g. still allow side by side or top/bottom split, but in a smaller total region) would be great.
Do you mean reserving screen space for the on-screen keyboard? If that's the case, you can try to "transform" the top-level frame (a frame that tracks a monitor's screen area), either in the REPL or in your config: https://agent-kilo.github.io/jwno/cookbook/adjust-top-level-...
> Using example-config.janet I tried pressing RAlt or RAlt+K and I get the UI hint shortcuts list coming up, but none of them seem to do anything
Can you please file a bug report and attach relevant logs? You can write logs to a file by starting Jwno like this:
There should be some interesting logs when you press one of the UI hint shortcuts.
> Fwiw, as a newbie I found it a bit intimidating/off-putting that it doesn't work out the box without choosing a config file. That's quite a lot of extra cognitive effort and link-clicking before you can try it out.
I totally understand. But I chose to not include a default config in the executable, because I thought a window manager is a... personal thing. It should evolve with your habits and workflows, so the default config will most likely get changed to something dramatically different anyway. I can be wrong though.
Yes! transforming the top level frame sounds like the way to go.
I ran jwno with example-config and pressed RAlt and RAlt+K a few times, each time trying one of the onscreen shortcut keys (b, c, d, etc). Log at the bottom of this comment. At the end of the process I was left in a state where pressing Space triggered a context menu in my title bar, and I couldn't type space in the app (e.g. in Notepad or Terminal) which I think is due to one of the Alts ending up being held down? It persisted after leaving Jwno
Thanks, that's it. I really like 'gradually walk the UI tree', though I'm struggling a bit with the thing I want being obscured by the label (and me not remembering what was there). An offset would be nice, though I'm sure it's not easy to define a heuristic that works in all places.
The first thing I tried was in my browser, I asked for all the buttons and it labelled the 'x' to close each tab, but where the labels were laid out it just looked like an inviting right-aligned label on the clickable tabs themselves. Lost a few tabs before I realised, because you also don't see any feedback on the click since any UI feedback is hidden by the label. Hmm. Food for thought.
> An offset would be nice, though I'm sure it's not easy to define a heuristic that works in all places.
I agree. I considered dynamic offsets, in an effort to declutter the labels, but found it even more confusing. Maybe I should do more experiments on this.
> but where the labels were laid out it just looked like an inviting right-aligned label on the clickable tabs themselves
The labels are left-aligned by default (except in `frame-hinter`). I think you can try some combinations of the `:anchor` and `:show-highlights` options[1] to see if they work better for you.
Meanwhile you can try to change leading `RAlt` to something else, like `Win + H`, and see if it works. There may be a bug that gets triggered when only modifier keys are mapped.
Janet looks really neat. And this project seems really cool. Windows DESPERATELY needs a more powerful built-in manager. It's ridiculous to use the mouse all the time.
One of the later PowerToys updates makes the first few steps in the right direction with "fancy zones". It's not strictly native windows, but still developed by Microsoft and adds keyboard shortcuts for all its utilities
PowerToys seems to be making two step forward, one step backwards, and then makes a leap in a random off-axis direction. Every time an update comes, I feel both joy and worry - I expect to see some new cool thing (and possibly even useful to me), but I also worry about bloat and random performance degradations. I haven't bothered with measuring and quantifying it properly, but I do feel PowerToys got heavier and slower over the last 2 years.
Ironically, 90% of use I get from them is remapping Caps Lock to CTRL. Which I historically did with AutoHotkey, which was much lighter, but then there's the 10% of the time I need something else from PowerToys...
The even simpler solution to remapping Caps Lock is to use SharpKeys, which applies registry settings to make use of Windows’ built-in remapping functionality.
Even lighter than autohotkey is remapping on the hardware of the keyboard. There's a lot of open source firmware options for that now in the custom scene
Yeah I found all the software based remapping to be a bit janky on Windows, ended up just doing it in the keyboard firmware instead to move my ctrl keys beside the spacebar.
I never use the mouse to move windows around, windows key + arrows key meets my needs fine even multi-monitor, breaks the screen up into halves and quarters. Alt-tab to change focus.
> Windows DESPERATELY needs a more powerful built-in manager. It's ridiculous to use the mouse all the time.
And yet, I find Windows window management far more advanced than macOS. It's ridiculous that up until recently, macOS didn't even have basic max-size functionality w/o reaching for 3rd party apps.
I agree, it's impressive. It brings me back to early Windows when keyboard control was a first class citizen in the UI, and most functions had dedicated alt key combos per dialog.
This means something to me that one dev recognizes another and gives them kudos. I applaud this positive behaviour. You'd never get that from the AI monsters. But of course, now you probably will. Sorry, everyone.
It's not a tiling manager but slightly related: I replicated Spectacle/Rectangle (macOS apps) on Windows a while ago to snap windows to edges/corners/two-thirds/one-thirds etc a while back. If you're interested: https://github.com/ahmetb/RectangleWin/blob/main/README.md
Long-time StumpWM user, before I switched back to Windows a few years ago. This is super-exciting to see, and I'm going to take it for a spin. It might just address my major frustrations with arranging windows and switching between them; my monitor seems just the right shape/resolution for the standard Windows splits to be suboptimal.
(Browsers, in particular, I use full-screen less and less. That annoying trend of squeezing everything into short lines "because readability" is just wasting too much screen space; zooming in makes everything too big, and I'm getting tired of writing userstyles or userscript to fix it for every other page I open, so I'm back to keeping 2 or 3 columns of windows running.)
Also, any excuse to use more Lisp is good in my book. Based on the screenshots, it looks stellar; if it works half as well as it comes across, I'll switch over instantly.
My StumpWM is heavily customized though, and I mostly modeled Jwno's behavior after my own config, so it may not be what you expected at all.
But that's one of the reasons I like Lisp and things built in Lisp: They are so flexible, you can sometimes build something based on the original thing, while it feels completely different from the original.
> my monitor seems just the right shape/resolution for the standard Windows splits to be suboptimal
Do you use an ultra-wide? In that case, Jwno has no OOTB ultra-wide support, but there's a section for adjusting it in the cookbook[1].
> Do you use an ultra-wide? In that case, Jwno has no OOTB ultra-wide support
Actually no, I'm using two regular, 16:19, 2560x1440 screens. It's more that my understanding of readability does not agree with what designers think, and when I split the screen in half, many pages end up with text a little too small for my comfort, and if zoom in to compensate, the lines get slightly too short or horizontal scrollbar appears.
(I'd guess it's probably my somewhat strong myopia glasses that are getting me "out of alignment" from average user when it comes to text size and line length preferences.)
> but there's a section for adjusting it in the cookbook[1].
Lovely!
FWIW, I took it for a spin briefly (only briefly - had work to finish, but I plan on getting back to it) and I was pleasantly surprised by how good it is, and how well it handles Windows quirks. It feels nicer than StumpWM did back when I used it. The only thing that didn't work well was VLC - it does something weird with recreating its window when switching between videos, and in the process, it "breaks out of confinement" and ends up returning to original size and position it had before Jwno took custody of it.
I recently tried hyprland after using xmonad for like 10+ years and wondered about the decision to bind workspaces to displays. I didnt like that. How does Jwno handle multiple monitors? I have looked at the docs and didnt see it mention anywhere.
Sorry for the confusion. Multi-monitor support is only briefly mentioned in the docs[1] and the interactive tutorial[2].
Jwno's internal data structure has these levels (higher-level comes first):
Root - Virtual Desktops - Monitors - Normal Frames - Windows
So monitors are part of a virtual desktop, and every virtual desktop has the same layout that reflects your physical monitor arrangement. When you switch virtual desktops, all monitors switch to the new desktop at the same time.
What kinds of automation are possible with having a scripting language inside your WM, rather than Sway-style IPC? I heard the new Windows WMs were where most pure workflow advances happen, so I wonder if they can be replicated on Linux.
What resource did you use to learn Janet? And did you already know lisp before? Comming from Python and php I found the "Janet for mortals" very difficult. It expected me to know what closures and macros are.
I'm not the one you asked, but maybe this is helpful:
I learnt Janet after learning Clojure, and it all felt very natural. So a possible approach is to grab a beginner Clojure book/tutorial first, run some of the examples, and then see how far you get with Janet.
Not everything is the same, but you'll find that out along the way, and the people in the Janet Zulip chat are always super helpful.
Custom windows shells (I know this is just a window manager, but still) in the year of our lord 2025? This takes me back to the days of installing bb4win and litestep in XP. I'm a kid again!
flashback, 2001. I'm 25, sitting in the office with litestep installed (which honestly was the only alternative to Linux or resignation). My five years younger colleague steps up to my desk and says "hey, cool desktop!"
I start explaining, very carefully, like I'm talking to a child, that this is an alternative shell, which replaces the standard Windows Explorer et cetera, und so weiter... it's very complicated you know...
Guy says, "cool... hey, why don't you check out this URL?". I do. It's the litestep contributor page. His nick is on it. Near the top.
First part of your story reminded me of when I once trolled a non-tech savvy friend by running Windows in a VM on Linux, and told him "have you ever seen what's behind windows?" then I exited full screen to reveal a desktop full of terminals running the matrix digital rain.
Wow, bb4win and bblean take me way back. In fact, they were a huge inspiration for my shells[1] feature, which are just userland programs that happen to be able to manage panels (windows).
Is it just me or did not a single one of those "l33t haxker shells" ever produceable a single ui innovation that lasted?
I mean, I remember there being a whole ton of wildly customized windows shells with menus and floating terminals and so on, but not a single thing stuck around?
I'm not sure about the Windows scene, since I only toyed around with one or two shells nearly twenty years ago, but the motivations for creating windows managers in Unix varied. Quite often they were about the appearance, customization, ease of customization, lack of customization, or low resource usage. I suspect that most of them were made for the learning experience or simply as a form of self-expression. They were never really about innovation. When there was innovation, it was usually in the form of small things like how we size and position windows (e.g. think about how it is possible to tile windows in Windows these days).
Besides, the term innovation is used far too much with respect to software, in the sense that a lot of stuff can be traced back much further than the so-called innovators will suggest. Many ideas have deep roots, but it took several (often independent) attempts until the technology or its users were ready for it.
Well, I installed Litestep as default shell on a 80486 laptop with Windows (I think it was Windows 98 SE, debloated). It replaced explorer.exe and performed better, IIRC I had more RAM free. I gave the machine away eventually, and they probably ran Linux on it. But because the machine was for my mother, it had to be able to run MSIE.
This is so cool!
It's funny because open source devs are making Windows better while MS is actively making it worse. If MS removed all telemetry and AI (and restored win10 functions in context menus), I would probably move back to it.
I've recently started playing around with Janet, and it's a great language. I think it's inspired by Clojure and Lua, and somehow manages to be better than both (in my opinion).
> I think it's inspired by Clojure and Lua, and somehow manages to be better than both
This is exactly how I feel about Janet too. I don't think I have enough experience on Clojure or Lua to comment on them, but I got attracted to Janet almost immediately.
Working on Jwno also confirms my first impression on Janet: It's really a practical language. The tooling has some room for improvement, but the language itself can get things done - usually fast and easily.
How’s the REPL/interactive editing story? I feel weird using a Lisp that is not as interactive as Racket, Scheme or Common Lisp. Running scripts from the REPL ain’t the same thing as C-x C-e an expression on a live program
> I feel weird using a Lisp that is not as interactive as Racket, Scheme or Common Lisp
I think Racket and Scheme don't belong in there because neither has a REPL as powerful and "interactive" as Common Lisp REPL. They don't support images either (but Janet and CL do).
As a Common Lisper with a Scheme background I'm gonna guess that by the interactivity of the REPL you mean the condition system with restarts? While most Schemes don't really have anything like it, I seem to recall MIT/GNU Scheme having something kinda similar. And I mean, hey, it's got Edwin, so it definitely has interactivity.
Yeah, it's mind-blowing when it clicks, and makes the whole "exceptions vs. return types" discussion look like a quarrel of 3yos in a sand box. Error handling in other languages/runtimes just doesn't feel sufficient from now on.
This is, of course, just a part of a larger whole - the fact that your Common Lisp program ships with a compiler it can access and effectively always runs in an edit-and-go debugger. Embracing this fact fully leads to a different workflow of software development.
Having done a bit of that, I found plenty of drawbacks of this approach, too - mostly various consequences of breaking the assumption that code that a program is running is the same as the code it was compiled from or that it started with. The aspect that annoyed me the most day-to-day was, basically, that whenever I fixed something on the fly through conditions and restarts and eval-ing code in a REPL, I never had a nice way to go back to that solution and port it to code. It was too easy to forget about a quick fix you did without thinking.
I now realized this should be easily fixable with external tooling - i.e. in Emacs/SLIME. What I think they need is a better way of keeping an audit trail. Capturing and persisting as much of the transient interactions you did as possible, letting you revisit them after and easily transfer into code or tests.
> I now realized this should be easily fixable with external tooling - i.e. in Emacs/SLIME. What I think they need is a better way of keeping an audit trail. Capturing and persisting as much of the transient interactions you did as possible, letting you revisit them after and easily transfer into code or tests.
To some extent, undotree on neovim allows this because it offers a drastically different view on what "undo" means. But I agree with you, the lack of a git-like system is annoying. I even think this might be THE reason CL didn't catch on—companies want to keep track of things (hence all the dashboards and ticketing systems...).
That's the other thing. Version control is tricky with image-based systems. I won't say impossible, I never looked deeply into what Smalltalk/Pharo folks are doing, but since between playing with Pharo and Glamorous Toolkit I saw Git being integrated first-class into one of them, I imagine someone has some idea how to deal with the problem.
What I meant though isn't collaborative/historical tracking, I meant day-to-day ergonomics; closer to "drastically different view on what 'undo' means", except it doesn't even have to be 'undo' - I don't need the ability to rollback every single thing; I just want to know whatever the hell I actually did an hour ago when I quickly SET-VALUE and IGNOREd my way through a few random condition popups and evaluated some code in between. Being careful and keeping track of this as I go slows me down and is kind of the opposite of REPL-driven interactive development ideas; nah, I should be able to go fast now, and later be able to review all the random surgery I did on a live image.
EDIT:
> undotree on neovim allows this because it offers a drastically different view on what "undo" means
As I understand it, this "different view" is treating undo history as a tree? If so, I know this from Emacs via similarly named `undo-tree' package. But honestly, the moment I saw this I thought this is brain-dead stupid most obvious way of treating undos. It's very unfortunate that almost no software embraces this approach, instead opting for a linear history that gets trimmed the moment you undo a few steps and make a change.
If you want to see a truly different view of undo, check out what Emacs does by default. I don't even understand it fully, but best I can tell after studying the explainer in undo-tree's documentation, is that Emacs is using a linear history like everyone else, but instead of moving back through the history and discarding "the future" when you branch out, `undo' itself is an undoable operation that gets appended to undo history, so when you type some things, undo it, type something else, and keep pressing undo, you'll erase the last text, then "undo the undo" and end up with the first thing you typed...
> Version control is tricky with image-based systems
Back in the day:
"ENVY/Manager augments this model by providing configuration management and version control facilities. All code is stored in a central database rather than in files associated with a particular image. Developers are continuously connected to this database; therefore changes are immediately visible to all developers."
"Package files are simple text files, encoded for latin alphabet (ISO 8859-15) and handled without problems by GitHub. Cuis-Smalltalk uses the LF (ascii code 10) newline convention, as preferred in GitHub. This allows Git/GitHub to diff versions, and merge branches."
> Yeah, it's mind-blowing when it clicks, and makes the whole "exceptions vs. return types" discussion look like a quarrel of 3yos in a sand box. Error handling in other languages/runtimes just doesn't feel sufficient from now on.
I am still waiting for a non-Lisp language with a half-decent restart system. Even compiled languages should be able to implement it (except dealing with a possible allocation failure when saving the register context to return to)
Restarts in CLHS are blocks of code handling a condition (exception). CL splits the "catch exception" and "react to it" parts into handlers and restarts. The two are independent; a handler can choose any restart currently installed above it in the call stack, or ask the user to choose interactively; the stack is only unwinded up to the point of a restart to resume from. This means you could e.g. following call stack:
5. Code that signals a file read error
4. Code that installs restarts "re-read line" and "skip line"
3. Code that loops over files in line
2. Code that installs restart "re-read file" or "abort"
1. Code with the handler that intelligently chooses whether to resume from 4 by re-reading a line or skipping it, or resume from 2 by attempting to read the file again, or just bailing out.
If we're still calling Guile a Scheme (I'm out of the loop) then I don't know, it gets really bloody close. Not so much in image-based development (that I've usually found less good than a decent packaging system because the contents of my files on disk is usually more tractable than the contents of my image), but its object system and error handling are definitely up there close to CL.
I mean, Common Lisp is still the gold-standard for me, but reading about Hoot recently really made me want to check Guile out a bit more (CL does not have much in the way of lovely WASM stories right now) and, honestly, I was super impressed. I think if the interactive experience of developing in Hoot in the browser matched the interactive experience of developing in native Guile, I'd be a pretty happy convert.
Tangential but I’ve been writing a lot of Janet recently using Joy[0], web framework, to build a small web app. Would love to hear what you learned about Janet from doing this work and how you feel about the language afterwards.
The one thing I’ve noticed is that it seems like Janet had a burst of interest 2020-2022 but it has since slowed down. Would love to see it become popular again. The main reason I’m using it is because I like how it’s both powerful and lightweight. I’d use clojure but I don’t want Java. I’m tempted to also try Common Lisp but so far Janet has been great.
I think Janet is quite...liberal? It's a practical language, but doesn't force a specific paradigm on you. There're "escape hatches" in different levels of the language, and I like that.
Maybe the most "opinionated" things in Janet are the ev stuff and fibers. I think they're done right though, you just need to be careful with the event loop when embedding Janet.
Strictly better unless you need an extremely small runtime rather than a very small one, or are exposing a scripting API to users who will recoil from prefix notation.
I always disliked the chaos that happens quickly with application windows, and loved the idea of tiling. But none of them really worked for me practically until I found PaperWM around a year ago or so (gnome extension). It has few core shortcuts and feels more natural. Like you would really arrange applications directly on your desk. It does not limit itself by your screen width and has the nice default that a new window appears to the right of the current window (configurable). You seldomly have the need to re-arrange windows, because the default just fits 99% of all cases. In addition, you still have the comfort of gnome. No hacky config files just to get wifi working or so. For work we have OSX, and I am really missing it there (I am using rectangle there instead). https://github.com/paperwm/PaperWM?tab=readme-ov-file#usage
It's a quick-and-dirty PoC with lots of caveats and limitations though. E.g. it works only for a single monitor. I don't think we can clip windows to a "view port" on Windows (the OS), so this may never be as nice as PaperWM, Niri etc.
scrolling window management is a new paradigm for me - really liking paper so far, thanks for sharing! (for what its worth, traditionally my approach has been fixed window positions for all applications, and enough screen real estate to support that. but that doesnt work in wayland with any mainstream compositor afaik)
How does it compare to komorebi? I've been using it for about 5 months with great success. I'm a Hyprland user when I'm on my personal machine, but for windows Komorebi has let me keep my muscle memory and workflow largely intact.
I think these are the most obvious differences between the two:
* By default, Komorebi uses dynamic tiling, while Jwno uses manual tiling.
* Komorebi has workspaces, Jwno works with Windows native virtual desktops instead.
* Komorebi uses IPC and native system command line to send commands, while Jwno usually operates all by itself.
There are definitely other details that are important to you, but these are the things that immediately came to my mind. I don't run Hyprland so can't really comment on that.
komorebi dev here - Jwno is awesome and I highly recommend people give it a try (especially people who enjoy writing Lisp!)
The Windows tiling window manager development scene is a very kind, relaxed and collaborative space where we all take inspiration from and support each other
That is amazing and I hope it'll continue to be so :).
The Linux scene isn't bad either (or at least it wasn't 4+ years ago when I was into this); I've used StumpWM as a daily driver for many years, and while it was definitely niche, I still saw friendly exchange of ideas and experiences with people using and/or contributing to dwm, i3, and ratpoison.
(Then there's EXWM, but I never really mustered the courage necessary to try it.)
I'm curious, did you find there were things that were easier to do because it's Janet/lisp-like language? Or you just fancied like using it (perfectly valid reason of course!).
I tried various lisp dialects, but I could never find the killer feature vs other languages I already use. And I can justify why I use these specific languages I do use, if that makes sense.
I find the REPL and interactive development workflow invaluable. A window manager is a long-running background service by nature, and has a lot of accumulated runtime states. The ability to peek inside and debug while the process keeps running helped me a lot when building Jwno.
I think Jwno's REPL module is so important, I specifically changed Jwno's architecture at one point to make it work.
> I find the REPL and interactive development workflow invaluable. A window manager is a long-running background service by nature, and has a lot of accumulated runtime states. The ability to peek inside and debug while the process keeps running helped me a lot when building Jwno.
Sure, but any particular reason you picked Janet over Common Lisp? They both support images, REPL, hot-code-reloading, etc.
TBH I dived right in when I decided I should build something with Janet, and didn't really consider any alternatives. Now you mentioned it, I think Janet's simplicity and conciseness played a large part in attracting me to it, comparing to Common Lisp at least.
Janet being a tiny embeddable runtime similar to Lua probably makes it perfect for a use-case like this. You have a full language, standard library, and interpreter in ~1 MB, along with the ability to bundle the runtime with your scripts into one binary. That's worth a lot.
I am not familiar with Janet but have been a long time lisp developer. Could you perhaps add a few lines to the readme explaining how the build process for jwno works? Would love to give it a try, understand how it works and hack around :)
> I could never find the killer feature vs other languages I already use.
You're kidding or trolling? Structural editing and the REPL are the greatest features of Lisp. The ability to just grab any expression and move it around simplifies so many things when coding and refactoring. With the connected REPL you can eval anything on the spot, that turns the entire experience of coding into a video game — you don't need to wait for linter, linker, compiler — you just run things. You often don't even have to save anything. I suspect when you "tried various lisp dialects" maybe you didn't use structural editing and the connected REPL?
Often people confuse Lisp REPL with REPLs in other programming languages, e.g. Python, where usually you have to copy-n-paste chunks of code into it. Lisp's REPLs are different in the sense that every step in Read-Eval-Print-Loop is different — in Lisp, you typically eval things right where you type them, by sending whole expressions to the connected REPL, which could be remote. We (for example) run ours in a Kubernetes cluster, that allows us to experiment with pods, running queries against the "real" DB tables, testing services "live".
I have only just begun my road down lisp, from starting to hack some elisp and working with some CL for fun. But structural editing is turning out to rapidly be my favorite feature, to the point that I'm working in my personal time on a lisp (syntax? language? idk haven't exactly decided) on top of Julia (my preferred language) so that I can use structural editing. The ability to just grab and drop entire expressions and advance through code by expression at a given level of the tree or up and down it is just really really nice.
There already is a LispSyntax.jl but it's sort of trying to be a Clojure clone and I don't care for it, haha.
I know, right? I honestly have no idea how the heck did I even code before in non-lispy languages. I imagine if I had to pair-program with someone today it would go like: "hey, how do I grab this part of the function quickly, so I can move it out?"... "Wait, what? I have to manually select it, there's no quick way of doing that with a single keystroke? Oh, I can use this 'powerful refactoring' feature of the IDE? Huh... and it only works for this specific language, there's nothing for a different one? Got it, okay... daaaarn... and I thought the coding supposed to be the easy part of programming..."
> You can implement custom commands and hooks to trigger. It's even possible to call native Win32 APIs in your own implementations. For example, to always move a Notepad window to the (100, 100) coordinates on your screen(s), using the low-level SetWindowPos function
Great job. Looks really interesting and useful. And a fun excuse to write Lisp.
I really appreciate it when APIs give you high-level functionality but keep the door open to lower-level APIs when you really need them.
My experiences with tiling window managers is that they struggle in judging a modal screen like a confirmation box or detachable/dockable mini-containers like the interface of certain programs like GIMP. Considering those as new tile-able windows tends to be a hinderance instead of increasing productivity.
I use AwesomeWM on Linux since over ten years.
For example, GIMP works without any issues. And the productivity boost is tremendous, for me it's very hard to work on anything else. I barely encounter programs where it does more harm than use.
Especially having multiple desktops with different names allow me to localize windows so much quicker than looking through a dozens of terminals manually.
Right now, I do have: 1 mail, 2 web, 3 gimp, 4 chat, 5 notes, 6 terminal, 7 ssh cluster
They do struggle with that, or rather some developers struggle with not making assumptions about the way a user's window manager is laying out their windows?
I use StumpWM, and for the few applications that this becomes a real problem it is possible to run those in a floating windows group that works just like a minimalistic non-tiling window manager. I think this is a common features of tiling window managers.
This looks to have great potential for accessibility! I work with individuals who use eye gaze input, where a significant part of the screen is taken up by an on-screen keyboard (including various shortcut/macro keys as well as for typing). Having tiling options that fit within a smaller part of the screen (e.g. still allow side by side or top/bottom split, but in a smaller total region) would be great. Particularly as Windows 11 has broken vertical docking of appbars.
The UI hints also look promising, but I can't get them working. Using example-config.janet I tried pressing RAlt or RAlt+K and I get the UI hint shortcuts list coming up, but none of them seem to do anything, except in Notepad where I sometimes get the standard UI hints (that always come up here with a long press of left alt)
Fwiw, as a newbie I found it a bit intimidating/off-putting that it doesn't work out the box without choosing a config file. That's quite a lot of extra cognitive effort and link-clicking before you can try it out. And I'm left quite unsure what I'm missing out on. Am I able to access the different documented features with the config file I have? It's not clear.
> Having tiling options that fit within a smaller part of the screen (e.g. still allow side by side or top/bottom split, but in a smaller total region) would be great.
Do you mean reserving screen space for the on-screen keyboard? If that's the case, you can try to "transform" the top-level frame (a frame that tracks a monitor's screen area), either in the REPL or in your config: https://agent-kilo.github.io/jwno/cookbook/adjust-top-level-...
> Using example-config.janet I tried pressing RAlt or RAlt+K and I get the UI hint shortcuts list coming up, but none of them seem to do anything
Can you please file a bug report and attach relevant logs? You can write logs to a file by starting Jwno like this:
jwno.exe --log-file C:\jwno.log --log-level debug --no-console your-config.janet
There should be some interesting logs when you press one of the UI hint shortcuts.
> Fwiw, as a newbie I found it a bit intimidating/off-putting that it doesn't work out the box without choosing a config file. That's quite a lot of extra cognitive effort and link-clicking before you can try it out.
I totally understand. But I chose to not include a default config in the executable, because I thought a window manager is a... personal thing. It should evolve with your habits and workflows, so the default config will most likely get changed to something dramatically different anyway. I can be wrong though.
Yes! transforming the top level frame sounds like the way to go.
I ran jwno with example-config and pressed RAlt and RAlt+K a few times, each time trying one of the onscreen shortcut keys (b, c, d, etc). Log at the bottom of this comment. At the end of the process I was left in a state where pressing Space triggered a context menu in my title bar, and I couldn't type space in the app (e.g. in Notepad or Terminal) which I think is due to one of the Alts ending up being held down? It persisted after leaving Jwno
Log: https://ctxt.io/2/AAB4W5O7Fg
It seems your right alt key is actually the AltGr key. I didn't explicitly support AltGr in Jwno, so it freaked out.
Sorry for the confusion. I think switching to another leader key, such as LAlt or RCtrl, should fix the issue.
Thanks, that's it. I really like 'gradually walk the UI tree', though I'm struggling a bit with the thing I want being obscured by the label (and me not remembering what was there). An offset would be nice, though I'm sure it's not easy to define a heuristic that works in all places.
The first thing I tried was in my browser, I asked for all the buttons and it labelled the 'x' to close each tab, but where the labels were laid out it just looked like an inviting right-aligned label on the clickable tabs themselves. Lost a few tabs before I realised, because you also don't see any feedback on the click since any UI feedback is hidden by the label. Hmm. Food for thought.
> An offset would be nice, though I'm sure it's not easy to define a heuristic that works in all places.
I agree. I considered dynamic offsets, in an effort to declutter the labels, but found it even more confusing. Maybe I should do more experiments on this.
> but where the labels were laid out it just looked like an inviting right-aligned label on the clickable tabs themselves
The labels are left-aligned by default (except in `frame-hinter`). I think you can try some combinations of the `:anchor` and `:show-highlights` options[1] to see if they work better for you.
[1]: https://agent-kilo.github.io/jwno/ref/built-in-modules/jwno-...
Edit: Wrong link
Thanks! I created a tracking issue here: https://github.com/agent-kilo/jwno/issues/12
Meanwhile you can try to change leading `RAlt` to something else, like `Win + H`, and see if it works. There may be a bug that gets triggered when only modifier keys are mapped.
Janet looks really neat. And this project seems really cool. Windows DESPERATELY needs a more powerful built-in manager. It's ridiculous to use the mouse all the time.
One of the later PowerToys updates makes the first few steps in the right direction with "fancy zones". It's not strictly native windows, but still developed by Microsoft and adds keyboard shortcuts for all its utilities
PowerToys seems to be making two step forward, one step backwards, and then makes a leap in a random off-axis direction. Every time an update comes, I feel both joy and worry - I expect to see some new cool thing (and possibly even useful to me), but I also worry about bloat and random performance degradations. I haven't bothered with measuring and quantifying it properly, but I do feel PowerToys got heavier and slower over the last 2 years.
Ironically, 90% of use I get from them is remapping Caps Lock to CTRL. Which I historically did with AutoHotkey, which was much lighter, but then there's the 10% of the time I need something else from PowerToys...
The even simpler solution to remapping Caps Lock is to use SharpKeys, which applies registry settings to make use of Windows’ built-in remapping functionality.
TIL: SharpKeys
TIL: Windows has a built-in remapping functionality
TIL: That functionality is controlled by registry, meaning I wouldn't even need a tool in the first place (I've learned to write REG files as a kid).
Thanks!
Even lighter than autohotkey is remapping on the hardware of the keyboard. There's a lot of open source firmware options for that now in the custom scene
Yeah I found all the software based remapping to be a bit janky on Windows, ended up just doing it in the keyboard firmware instead to move my ctrl keys beside the spacebar.
I never use the mouse to move windows around, windows key + arrows key meets my needs fine even multi-monitor, breaks the screen up into halves and quarters. Alt-tab to change focus.
> Windows DESPERATELY needs a more powerful built-in manager. It's ridiculous to use the mouse all the time.
And yet, I find Windows window management far more advanced than macOS. It's ridiculous that up until recently, macOS didn't even have basic max-size functionality w/o reaching for 3rd party apps.
Whoa, very cool. I love WMs, I love Lisp, and I hate Windows. This seems to be a perfect "medicine" for my frustration with it.
That UI hinting feature is killer. Is something similar available outside of this repo?
I agree, it's impressive. It brings me back to early Windows when keyboard control was a first class citizen in the UI, and most functions had dedicated alt key combos per dialog.
Jwno is great, agentkilo is kind, Lisp is magic :)
Thanks for the kind words! It means a lot coming from you :)
This means something to me that one dev recognizes another and gives them kudos. I applaud this positive behaviour. You'd never get that from the AI monsters. But of course, now you probably will. Sorry, everyone.
It's not a tiling manager but slightly related: I replicated Spectacle/Rectangle (macOS apps) on Windows a while ago to snap windows to edges/corners/two-thirds/one-thirds etc a while back. If you're interested: https://github.com/ahmetb/RectangleWin/blob/main/README.md
I love Rectangle, will definetly check this out!
Long-time StumpWM user, before I switched back to Windows a few years ago. This is super-exciting to see, and I'm going to take it for a spin. It might just address my major frustrations with arranging windows and switching between them; my monitor seems just the right shape/resolution for the standard Windows splits to be suboptimal.
(Browsers, in particular, I use full-screen less and less. That annoying trend of squeezing everything into short lines "because readability" is just wasting too much screen space; zooming in makes everything too big, and I'm getting tired of writing userstyles or userscript to fix it for every other page I open, so I'm back to keeping 2 or 3 columns of windows running.)
Also, any excuse to use more Lisp is good in my book. Based on the screenshots, it looks stellar; if it works half as well as it comes across, I'll switch over instantly.
A fellow StumpWM user!
My StumpWM is heavily customized though, and I mostly modeled Jwno's behavior after my own config, so it may not be what you expected at all.
But that's one of the reasons I like Lisp and things built in Lisp: They are so flexible, you can sometimes build something based on the original thing, while it feels completely different from the original.
> my monitor seems just the right shape/resolution for the standard Windows splits to be suboptimal
Do you use an ultra-wide? In that case, Jwno has no OOTB ultra-wide support, but there's a section for adjusting it in the cookbook[1].
[1]: https://agent-kilo.github.io/jwno/cookbook/adjust-top-level-...
> Do you use an ultra-wide? In that case, Jwno has no OOTB ultra-wide support
Actually no, I'm using two regular, 16:19, 2560x1440 screens. It's more that my understanding of readability does not agree with what designers think, and when I split the screen in half, many pages end up with text a little too small for my comfort, and if zoom in to compensate, the lines get slightly too short or horizontal scrollbar appears.
(I'd guess it's probably my somewhat strong myopia glasses that are getting me "out of alignment" from average user when it comes to text size and line length preferences.)
> but there's a section for adjusting it in the cookbook[1].
Lovely!
FWIW, I took it for a spin briefly (only briefly - had work to finish, but I plan on getting back to it) and I was pleasantly surprised by how good it is, and how well it handles Windows quirks. It feels nicer than StumpWM did back when I used it. The only thing that didn't work well was VLC - it does something weird with recreating its window when switching between videos, and in the process, it "breaks out of confinement" and ends up returning to original size and position it had before Jwno took custody of it.
I recently tried hyprland after using xmonad for like 10+ years and wondered about the decision to bind workspaces to displays. I didnt like that. How does Jwno handle multiple monitors? I have looked at the docs and didnt see it mention anywhere.
Sorry for the confusion. Multi-monitor support is only briefly mentioned in the docs[1] and the interactive tutorial[2].
Jwno's internal data structure has these levels (higher-level comes first):
Root - Virtual Desktops - Monitors - Normal Frames - Windows
So monitors are part of a virtual desktop, and every virtual desktop has the same layout that reflects your physical monitor arrangement. When you switch virtual desktops, all monitors switch to the new desktop at the same time.
[1]:https://agent-kilo.github.io/jwno/frame-tree/frame-nodes.htm...
[2]: https://github.com/agent-kilo/jwno/blob/master/example/tutor...
What kinds of automation are possible with having a scripting language inside your WM, rather than Sway-style IPC? I heard the new Windows WMs were where most pure workflow advances happen, so I wonder if they can be replicated on Linux.
This might be the coolest project I've seen using Janet yet!
What resource did you use to learn Janet? And did you already know lisp before? Comming from Python and php I found the "Janet for mortals" very difficult. It expected me to know what closures and macros are.
I'm not the one you asked, but maybe this is helpful:
I learnt Janet after learning Clojure, and it all felt very natural. So a possible approach is to grab a beginner Clojure book/tutorial first, run some of the examples, and then see how far you get with Janet.
Not everything is the same, but you'll find that out along the way, and the people in the Janet Zulip chat are always super helpful.
Also check out https://janetdocs.com for some examples.
So amazing. I might have to use Windows soon, against my will, and this could sweeten the deal for me considerably!
Looks very good! This one is what I need
Does your project have any influence on Windows focus stealing?
Oh ! That looks cool :)
Thanks :)
Custom windows shells (I know this is just a window manager, but still) in the year of our lord 2025? This takes me back to the days of installing bb4win and litestep in XP. I'm a kid again!
flashback, 2001. I'm 25, sitting in the office with litestep installed (which honestly was the only alternative to Linux or resignation). My five years younger colleague steps up to my desk and says "hey, cool desktop!"
I start explaining, very carefully, like I'm talking to a child, that this is an alternative shell, which replaces the standard Windows Explorer et cetera, und so weiter... it's very complicated you know...
Guy says, "cool... hey, why don't you check out this URL?". I do. It's the litestep contributor page. His nick is on it. Near the top.
Ow.
First part of your story reminded me of when I once trolled a non-tech savvy friend by running Windows in a VM on Linux, and told him "have you ever seen what's behind windows?" then I exited full screen to reveal a desktop full of terminals running the matrix digital rain.
TIL bbLean [1] still works in Windows 11! Currently digging through my archives for my old BB4Win styles repository
[1] https://bb4win.sourceforge.net/bblean/
Wow, bb4win and bblean take me way back. In fact, they were a huge inspiration for my shells[1] feature, which are just userland programs that happen to be able to manage panels (windows).
[1] https://90s.dev/technical/architecture.html#shells
Sloop manager for replacing progman.exe in windows 3.1, for me..
Is it just me or did not a single one of those "l33t haxker shells" ever produceable a single ui innovation that lasted?
I mean, I remember there being a whole ton of wildly customized windows shells with menus and floating terminals and so on, but not a single thing stuck around?
I'm not sure about the Windows scene, since I only toyed around with one or two shells nearly twenty years ago, but the motivations for creating windows managers in Unix varied. Quite often they were about the appearance, customization, ease of customization, lack of customization, or low resource usage. I suspect that most of them were made for the learning experience or simply as a form of self-expression. They were never really about innovation. When there was innovation, it was usually in the form of small things like how we size and position windows (e.g. think about how it is possible to tile windows in Windows these days).
Besides, the term innovation is used far too much with respect to software, in the sense that a lot of stuff can be traced back much further than the so-called innovators will suggest. Many ideas have deep roots, but it took several (often independent) attempts until the technology or its users were ready for it.
Well, I installed Litestep as default shell on a 80486 laptop with Windows (I think it was Windows 98 SE, debloated). It replaced explorer.exe and performed better, IIRC I had more RAM free. I gave the machine away eventually, and they probably ran Linux on it. But because the machine was for my mother, it had to be able to run MSIE.
>litestep
Brings back memories !
Oh shit yes: Rainlendar
This is so cool! It's funny because open source devs are making Windows better while MS is actively making it worse. If MS removed all telemetry and AI (and restored win10 functions in context menus), I would probably move back to it.
I've recently started playing around with Janet, and it's a great language. I think it's inspired by Clojure and Lua, and somehow manages to be better than both (in my opinion).
> I think it's inspired by Clojure and Lua, and somehow manages to be better than both
This is exactly how I feel about Janet too. I don't think I have enough experience on Clojure or Lua to comment on them, but I got attracted to Janet almost immediately.
Working on Jwno also confirms my first impression on Janet: It's really a practical language. The tooling has some room for improvement, but the language itself can get things done - usually fast and easily.
Agreed on the need for better Janet tooling. I'm trying to be the change I wish to see with Janet LSP[0]. Issues and contributions are welcome!
[0] https://GitHub.com/CFiggers/janet-lsp
How’s the REPL/interactive editing story? I feel weird using a Lisp that is not as interactive as Racket, Scheme or Common Lisp. Running scripts from the REPL ain’t the same thing as C-x C-e an expression on a live program
> I feel weird using a Lisp that is not as interactive as Racket, Scheme or Common Lisp
I think Racket and Scheme don't belong in there because neither has a REPL as powerful and "interactive" as Common Lisp REPL. They don't support images either (but Janet and CL do).
As a Common Lisper with a Scheme background I'm gonna guess that by the interactivity of the REPL you mean the condition system with restarts? While most Schemes don't really have anything like it, I seem to recall MIT/GNU Scheme having something kinda similar. And I mean, hey, it's got Edwin, so it definitely has interactivity.
Yes, I mean the conditions and restarts system in CL. Haven't seen anything like that in Clojure and other Lisps.
Yeah, it's mind-blowing when it clicks, and makes the whole "exceptions vs. return types" discussion look like a quarrel of 3yos in a sand box. Error handling in other languages/runtimes just doesn't feel sufficient from now on.
This is, of course, just a part of a larger whole - the fact that your Common Lisp program ships with a compiler it can access and effectively always runs in an edit-and-go debugger. Embracing this fact fully leads to a different workflow of software development.
Having done a bit of that, I found plenty of drawbacks of this approach, too - mostly various consequences of breaking the assumption that code that a program is running is the same as the code it was compiled from or that it started with. The aspect that annoyed me the most day-to-day was, basically, that whenever I fixed something on the fly through conditions and restarts and eval-ing code in a REPL, I never had a nice way to go back to that solution and port it to code. It was too easy to forget about a quick fix you did without thinking.
I now realized this should be easily fixable with external tooling - i.e. in Emacs/SLIME. What I think they need is a better way of keeping an audit trail. Capturing and persisting as much of the transient interactions you did as possible, letting you revisit them after and easily transfer into code or tests.
> I now realized this should be easily fixable with external tooling - i.e. in Emacs/SLIME. What I think they need is a better way of keeping an audit trail. Capturing and persisting as much of the transient interactions you did as possible, letting you revisit them after and easily transfer into code or tests.
To some extent, undotree on neovim allows this because it offers a drastically different view on what "undo" means. But I agree with you, the lack of a git-like system is annoying. I even think this might be THE reason CL didn't catch on—companies want to keep track of things (hence all the dashboards and ticketing systems...).
That's the other thing. Version control is tricky with image-based systems. I won't say impossible, I never looked deeply into what Smalltalk/Pharo folks are doing, but since between playing with Pharo and Glamorous Toolkit I saw Git being integrated first-class into one of them, I imagine someone has some idea how to deal with the problem.
What I meant though isn't collaborative/historical tracking, I meant day-to-day ergonomics; closer to "drastically different view on what 'undo' means", except it doesn't even have to be 'undo' - I don't need the ability to rollback every single thing; I just want to know whatever the hell I actually did an hour ago when I quickly SET-VALUE and IGNOREd my way through a few random condition popups and evaluated some code in between. Being careful and keeping track of this as I go slows me down and is kind of the opposite of REPL-driven interactive development ideas; nah, I should be able to go fast now, and later be able to review all the random surgery I did on a live image.
EDIT:
> undotree on neovim allows this because it offers a drastically different view on what "undo" means
As I understand it, this "different view" is treating undo history as a tree? If so, I know this from Emacs via similarly named `undo-tree' package. But honestly, the moment I saw this I thought this is brain-dead stupid most obvious way of treating undos. It's very unfortunate that almost no software embraces this approach, instead opting for a linear history that gets trimmed the moment you undo a few steps and make a change.
If you want to see a truly different view of undo, check out what Emacs does by default. I don't even understand it fully, but best I can tell after studying the explainer in undo-tree's documentation, is that Emacs is using a linear history like everyone else, but instead of moving back through the history and discarding "the future" when you branch out, `undo' itself is an undoable operation that gets appended to undo history, so when you type some things, undo it, type something else, and keep pressing undo, you'll erase the last text, then "undo the undo" and end up with the first thing you typed...
> Version control is tricky with image-based systems
Back in the day:
"ENVY/Manager augments this model by providing configuration management and version control facilities. All code is stored in a central database rather than in files associated with a particular image. Developers are continuously connected to this database; therefore changes are immediately visible to all developers."
https://www.google.com/books/edition/Mastering_ENVY_Develope...
These days:
"Package files are simple text files, encoded for latin alphabet (ISO 8859-15) and handled without problems by GitHub. Cuis-Smalltalk uses the LF (ascii code 10) newline convention, as preferred in GitHub. This allows Git/GitHub to diff versions, and merge branches."
https://drcuis.github.io/TheCuisBook/Daily-Workflow.html
The "Back in the day" sounds better as a pattern in general.
> Yeah, it's mind-blowing when it clicks, and makes the whole "exceptions vs. return types" discussion look like a quarrel of 3yos in a sand box. Error handling in other languages/runtimes just doesn't feel sufficient from now on.
I am still waiting for a non-Lisp language with a half-decent restart system. Even compiled languages should be able to implement it (except dealing with a possible allocation failure when saving the register context to return to)
ditto jdougan
"Restart. Start execution of the current method from the beginning. You can edit a method shown in the code pane, save it, and restart it!"
https://drcuis.github.io/TheCuisBook/The-Debugger.html
Restarts in CLHS are blocks of code handling a condition (exception). CL splits the "catch exception" and "react to it" parts into handlers and restarts. The two are independent; a handler can choose any restart currently installed above it in the call stack, or ask the user to choose interactively; the stack is only unwinded up to the point of a restart to resume from. This means you could e.g. following call stack:
5. Code that signals a file read error
4. Code that installs restarts "re-read line" and "skip line"
3. Code that loops over files in line
2. Code that installs restart "re-read file" or "abort"
1. Code with the handler that intelligently chooses whether to resume from 4 by re-reading a line or skipping it, or resume from 2 by attempting to read the file again, or just bailing out.
What is the issue with the system in Smalltalks?
There's multiple dimensions you can slice and dice the Lisp family by. Images and REPL experience are two big ones, but they're almost orthogonal.
I didn't mean that Racket and Scheme aren't Lisp (they are!). I meant they don't have the images and REPL-driven development of Common Lisp.
If we're still calling Guile a Scheme (I'm out of the loop) then I don't know, it gets really bloody close. Not so much in image-based development (that I've usually found less good than a decent packaging system because the contents of my files on disk is usually more tractable than the contents of my image), but its object system and error handling are definitely up there close to CL.
I mean, Common Lisp is still the gold-standard for me, but reading about Hoot recently really made me want to check Guile out a bit more (CL does not have much in the way of lovely WASM stories right now) and, honestly, I was super impressed. I think if the interactive experience of developing in Hoot in the browser matched the interactive experience of developing in native Guile, I'd be a pretty happy convert.
Guile is certainly my favourite Scheme for standalone use.
This is how I feel about Janet too, absolutely practical. So far it's been a breeze to write the little experiments I've done so far.
This is a fantastic replacement for Windows Explorer which is about 10X faster/lighter:
https://filepilot.tech/
(it's beta so it has a few little annoyances still)
For files - nothing beats TotalCommander for me.
As mentioned earlier in the thread, keyboard shortcuts are built-in, not missing or bolted on later…!
Tangential but I’ve been writing a lot of Janet recently using Joy[0], web framework, to build a small web app. Would love to hear what you learned about Janet from doing this work and how you feel about the language afterwards.
The one thing I’ve noticed is that it seems like Janet had a burst of interest 2020-2022 but it has since slowed down. Would love to see it become popular again. The main reason I’m using it is because I like how it’s both powerful and lightweight. I’d use clojure but I don’t want Java. I’m tempted to also try Common Lisp but so far Janet has been great.
[0]: https://github.com/joy-framework/joy
I think Janet is quite...liberal? It's a practical language, but doesn't force a specific paradigm on you. There're "escape hatches" in different levels of the language, and I like that.
Maybe the most "opinionated" things in Janet are the ev stuff and fibers. I think they're done right though, you just need to be careful with the event loop when embedding Janet.
How it compares with Lua?
Strictly better unless you need an extremely small runtime rather than a very small one, or are exposing a scripting API to users who will recoil from prefix notation.
If you like Janet and Lua, might as well try Fennel, which was made by the creator of Janet.
I have read about Fennel many times and considered on trying it - I didn’t know that they have the same author!
This one actually has real arrays (mutable and immutable)
I always disliked the chaos that happens quickly with application windows, and loved the idea of tiling. But none of them really worked for me practically until I found PaperWM around a year ago or so (gnome extension). It has few core shortcuts and feels more natural. Like you would really arrange applications directly on your desk. It does not limit itself by your screen width and has the nice default that a new window appears to the right of the current window (configurable). You seldomly have the need to re-arrange windows, because the default just fits 99% of all cases. In addition, you still have the comfort of gnome. No hacky config files just to get wifi working or so. For work we have OSX, and I am really missing it there (I am using rectangle there instead). https://github.com/paperwm/PaperWM?tab=readme-ov-file#usage
Jwno can do this! https://agentkilo.itch.io/jwno/devlog/871672/scroll-jwno-scr...
Thanks for posting the link!
It's a quick-and-dirty PoC with lots of caveats and limitations though. E.g. it works only for a single monitor. I don't think we can clip windows to a "view port" on Windows (the OS), so this may never be as nice as PaperWM, Niri etc.
Neat! This looks pretty close, at least for the base principle. If I had a windows machine I would definitely give it a try.
scrolling window management is a new paradigm for me - really liking paper so far, thanks for sharing! (for what its worth, traditionally my approach has been fixed window positions for all applications, and enough screen real estate to support that. but that doesnt work in wayland with any mainstream compositor afaik)
How does it compare to komorebi? I've been using it for about 5 months with great success. I'm a Hyprland user when I'm on my personal machine, but for windows Komorebi has let me keep my muscle memory and workflow largely intact.
I think these are the most obvious differences between the two:
* By default, Komorebi uses dynamic tiling, while Jwno uses manual tiling.
* Komorebi has workspaces, Jwno works with Windows native virtual desktops instead.
* Komorebi uses IPC and native system command line to send commands, while Jwno usually operates all by itself.
There are definitely other details that are important to you, but these are the things that immediately came to my mind. I don't run Hyprland so can't really comment on that.
Just in case someone new is looking, komorebi is great:
https://github.com/LGUG2Z/komorebi
komorebi dev here - Jwno is awesome and I highly recommend people give it a try (especially people who enjoy writing Lisp!)
The Windows tiling window manager development scene is a very kind, relaxed and collaborative space where we all take inspiration from and support each other
That is amazing and I hope it'll continue to be so :).
The Linux scene isn't bad either (or at least it wasn't 4+ years ago when I was into this); I've used StumpWM as a daily driver for many years, and while it was definitely niche, I still saw friendly exchange of ideas and experiences with people using and/or contributing to dwm, i3, and ratpoison.
(Then there's EXWM, but I never really mustered the courage necessary to try it.)
Definitely! I got great inspirations from both of the Komorebi and GlazeWM communities. People who like tidy desktops are definitely nice people :)