Issues that Prevent Users From Switching to Lem

[cianoc]

Discussions Elsewhere

• Bookmarks
• Legit, Magit
• Completions

In Progress

• Org-mode
• Which Key
• Templates
  • There is a stale PR. It would be nice to get this merged in.
• Treesitter

Not Started

• Debug Adapter Protocol

[cianoc]

The intention for this thread is for it to be a single place where this can be discussed and tracked. For bigger issues (e.g. completion), this will just link to the discussion. For smaller issues (a command that you feel is missing, or a bug that irks you), add it here. I'll try to keep the first post up to date.

[cianoc]

For bookmarks, has anyone tried this plugin. Does it do what is needed, and is the interface what we need. The easiest thing to do would be just to take the existing code, modify it to work in the main code base and move on.

But I don't use bookmarks in Emacs, so I'm not sure if that's the best approach. Ideally a lightweight approach that people can build upon seems best.

[vindarel]

Please define "better completion"? For me Helm is only UI, not algorithms. Do you think about fuzzy completion?

[cianoc]

Anything that improves the completion, or prompt experience. Fuzzy completion would be one example, but also features of Helm/Vertico/Company mode that people miss.

[cianoc]

I've created a new discussion for completions here:
#1862

[AntheaLiles]

You allready mention Org-mode and to me it's the only thing I'm looking forward before migrate to Lem,

But, that's not really just Org-Mode but rather the Org to PDF through LaTeX I use daily (and emacs is quite anoying in the long term for this...)

I'm more a writer than a coder tho... maybe not the main target here :)
For instance, the command I use the most is "Cc Ce l o" and the minor-mode of my choice is an 80 char length Olivetti-mode 😇

On emacs, I use org-cite and org-glossary heavily and these complements are really a game changer to me. I have a one Org file for my acronyms and glossaries entry I load on each documents I'm working on. Same with a big .bib (zotero managed)

Yet... Lem might not need to became a full featured tex(t) editor

To be fair, I would love to see a CL based TeX alternative like Scribble with math power like Maxima that back the Org mode docs and the Org to PDF workflow. But i'm maybe just a folks that guive to much credit to these projects 😅 (I found them really wonderful tho...)

Last but probably not least could be Org's litterate programming capacities 🙂

I still have Lem (and Nyxt for some reasons) installed on my laptop, with the plan to give them the time they deserve

I hope this comment to be somehow helpfull 🙏

[cianoc]

If you use Emacs and want to use LEM, then you're definitely a target. Org-mode is also a priority for me.

There should be a fork/extension with an early version of org-mode coming soon. It won't be ready for serious use, but the idea is just to allow people to kick the tires a bit. Still working out how we will do that, but we'd definitely want feedback on the forum. How much would be core, and how much extensions, remains to be seen. I'd be very hesitant about trying to replicate all of org-mode, as in my opinion it's a bit of a mess. We'll see.

Now that Lem is moving to Webview that may well open up some exciting possibilities as well.

[psionic-k]

Personally, while my idea is insane, I would be in favor of developing a more consistent syntax that has the ideas of org but doesn't retain some of it's difficult ideas like weak inline item support and strange postfix vs prefix issues or :many_kinds_of_syntax:. Org is just too organic for a sensible text format and something like markdown with embedded Lisp data would make more sense IMO.

I'm also reaching a conclusion that the ideas of programming text based applications have some shortcomings in the Emacs model. With anyone who does DOM programming in web tech, while we don't really like how web tech is super fragmented and inconsistent, we know that it's simply better than regex and property based text applications in many ways. I can't outline specifics right now, but I kind of feel like importing Org to a more proper syntax would actually be the best place to start with it.

We're missing a lot of obvious stuff in org like completions, which makes it difficult to use extensions for the format. The agenda buffer is a view of the extracted data, and that general idea has power, but I just don't think we've gone very far in trying to understand what we're doing and are leaving a lot of opportunities untouched.

[cianoc]

We have an early (pre-alpha) org-mode here:
https://github.com/mahmoodsh36/organ-mode

It's not ready for heavy use, but progress is happening.

[daninus14]

Hm, perhaps making this some sort of poll or have a reply for each item so that people can upvote the ones they are most in favor. This can help for prioritizing the work

[johnhilts]

Things I use heavily in emacs:

• Org Mode
• "Occur"
• Support for other file types, along the lines of web-mode.
• eww
• Multiple frames ala Cx-5 2 and friends
• Also, Windows support would be nice, but not a deal-breaker.

[cianoc]

Thanks. I'll mull these over. I doubt EWW will be a priority for anyone, but some kind of browser might be easy with the new webview. If it is I'm sure someone will try that.

Does Lem not support multiple frames already? I don't use multiple frames, so I hadn't tried.

Support for other file types, along the lines of web-mode.
Not sure I understand what you mean. Do you mean mixed modes in a buffer? For web mode I think this might be possible using treesitter when we get support for that.

Occur. Interesting. How is that different from multiple-cursors?

[johnhilts]

I doubt EWW will be a priority for anyone

Probably not a deal-breaker, but I do use it a lot.

Do you mean mixed modes in a buffer? For web mode I think this might be possible using treesitter when we get support for that.

Cool!

Occur. Interesting. How is that different from multiple-cursors?

Occur is a list of search matches for 1 buffer (AFAIK it's limited to 1 buffer). It let's you see at a glance all search hits which sometimes is nicer than jumping to each one. In emacs, search for something, then hit M-s o. Not sure what the connection to multi-cursor would be.

But since you did mention multi-cursor, I use C-x r t aka "string-rectangle" a lot (not sure if that's the same thing as multi-cursor, though?).

[vindarel]

mixed modes in a buffer

Lem can do this sometimes: in markdown files, code blocks will behave with the language's major mode! (syntax highlighting, keybindings)

Also in the Lisp REPL, typing ,ls lists files, and you have a mini directory mode in this file listing.

[cianoc]

I doubt EWW will be a priority for anyone

Probably not a deal-breaker, but I do use it a lot.

To be clear - I doubt a text browser will be a priority for anyone. With the new webview I'm sure someone will probably end up creating a graphical browser in LEM (not a promise, more of a prediction).

Occur. Interesting. How is that different from multiple-cursors?

Occur is a list of search matches for 1 buffer (AFAIK it's limited to 1 buffer). It let's you see at a glance all search hits which sometimes is nicer than jumping to each one. In emacs, search for something, then hit M-s o. Not sure what the connection to multi-cursor would be.

I think isearch in LEM already does this, as it shows all the matches, with the selected one highlighted. Maybe I'm missing something.

I'd be very hesitant to try and recreate all the modes and functions in Emacs, which can be quite haphazard. Instead I think the goal should be to support workflows, and to make accessing those workflows as intuitive as possible. In that spirit - what is missing from the current isearch implementation that you use?

But since you did mention multi-cursor, I use C-x r t aka "string-rectangle" a lot (not sure if that's the same thing as multi-cursor, though?).

Sort of. All the things that you can do in rectangle can also be done with multi-cursor, though the workflow is a little bit different. You can also do a lot more with multi-cursor implementations in neovim/helix and SublimeText. Currently the multi-cursor implementation in LEM is quite limited, but there are plans afoot to expand it. And I imagine those implementations would be different in the vi-mode, than the normal mode.

[sebasmonia]

For me it is Windows binaries, and a recipe to run from source easily (or a binary) for Linux.

[deano7000]

A homebrew recipe would be great. I'm keen to try lem but kept having problems getting it up and running on OSX.

[vindarel]

AppImages for Linux are here 🚀 https://github.com/lem-project/lem/releases

[cianoc]

A homebrew recipe would be great. I'm keen to try lem but kept having problems getting it up and running on OSX.

@deano7000 - I've added some info on how to make it an 'Application' on OSX. It's a bit of a hack, but it works. This is now in the documentation, and also as a reply to another discussion here.

Let me know if you run into issues and I'll try to help you (preferably in a new discussion).

[ValorZard]

@cianoc @vindarel i wonder if theres a way to automatically compile windows binaries the same way you guys are doing it for linux and MacOS on nightly

[cianoc]

Don't want to take credit for cxxxr's work, but I think he's working on windows binaries next.

[gggion]

A package repository or a way of submitting/checking out lem packages/libraries.

With emacs there's the benefit of having its own lisp, so in addition to checking out anything on MELPA, you can find miscellaneous emacs lisp code through searching elisp on github etc.

Ironically, Lem using Common Lisp makes it harder to find code for extending it, which makes it more difficult to ground designs or figure out ways of manipulating its constructs to implement an idea. I know I can look up its source code to see how things work, but there's something about seeing other people's implementations that makes me want to make my own and use it. In my opinion it could speed up development and contributions.

[vindarel]

for a start, could a better https://github.com/thebigcicca/awesome-lem be useful?

(then there's lem-extension-manager coming)

[cianoc]

Yes, or at least an expanded one.

I was also thinking that I put do a PR in the documentation with a list of all the extensions I know of. If anyone else knows of extensions, add them here and I'll add them to that list.

[jsadusk]

I'm an emacs user and I'd like to give lem a try, but I rely on tramp to develop on remote workstations. To seriously use lem that feature would have to work, not just for remote editing but anything that needs to run on the host with source code, like lsp.

[jsadusk]

Fair enough, I wasn't commenting on how easy of a feature this was, just that it's a capability of emacs that people rely on.

On that note I'd fit the bill for that skillset, but I have seriously limited time right now.

[cianoc]

Understood. I was just noting what would be required for this to be a reality. I agree it seems like a useful feature, even if unfortunately it's unlikely to be a reality any time soon.

[jsadusk]

On that note,is the webview intended to be the primary or only GUI? I'd find that to be very limiting. A frustration I have with emacs is how slow the UI layer is, and the state of the C code makes it prohibitive to make a faster one. New editors like Zed are interesting purely for their fast gpu accelerated UIs. The SDL UI of lem is close to that and it would be a shame to lose it.

[cianoc]

My understanding is that the SDL2 layer will no longer be maintained by cxxxr. Lem is written so that it can support multiple front ends, but obviously someone needs to maintain them.

In my very limited testing of webview so far I have not noticed any speed differences between it and the SDL version.

If you want to try it yourself, then run a build from master using lem -i webview - or try the new nightly builds (Linux and OSX only I think).

[cianoc]

This is on OSX. Your milage may obviously vary.

[daninus14]

• Docs and tutorials. For example guides on how to do things in lem.
  • This is probably the easiest way to lower barriers of entry. For example, I think the legit docs are a readme in the legit folder and not really (unless it's changed) available elsewhere. IIRC there are not even links to the legit docs in the main lem website
  • I think it would be great to fork the emacs manual/docs for all the bindings and functions and use that both as for creating a manual as well as for having a TODO list and maybe a document to test against for conformity of functionality. Of course if you guys want to do somethings differently, at least it should be marked and noted in both the manual and TODO list

[daninus14]

I hope to contribute as things come up

[monkpearman]

I'd like it if all possible keybinds could supersede the OS level bindings on Darwin. Ive had trouble figuring out how to work around some of those that drive MacOS windowing.

[cianoc]

I don't think this is possible unfortunately. The best solution is probably to disable all the ones that you can, then to use Karabiner to deflect the rest (this is what I do).

[monkpearman]

I'd also like to see an Info facility (ideally with both an Lem.info manual and a CL hyperspec.info node). The Emacs and elisp Info manuals are one of Emacs' greatest (and most overlooked features). I use and prefer Emacs' Info facility to man files and html based documentation, and try to avoid leaving the editor just to read documentation. I'd prefer to do similarly with Lem.

Indeed, Common Lisp has any number of documentation libraries and schemes for algorithmic manipulation of CL documentation, and there's no shortage of ways to skin that cat. What's lacking is a good in editor interface for viewing documentation that is easily integrated within a larger ecosystem of documentation. I believe that texinfo and Emacs' Info facility is a (mostly) good design for such things, and the fact that texinfo is so clearly descended from Scribe, it seems a no brainer to try to keep that mode of documentation alive in Lem.

[lemaster]

Some docs on how to write indentation and syntax highlighting rules for a new language mode would be welcomed. My emacs usage is super basic, just movement commands, an on-file-save hook and classic highlighting plus indentation (without using an lsp). So being able to define rules for less popular languages would be enough to make the jump.

[daninus14]

• functionality for the following packages (probably doesn't need to be part of lem but can be an extension like the originals)
  • marginalia
  • orderless
  • vertico

[cianoc]

Yes, this is coming.

We have some marginalia functionality already in place (checkout M-x for example), and more is planned (by me). Currently this is baked in, but I may look into making this more extensible and adding it in more places. Hopefully when I'm done it will be pretty trivial to add this to any prompt-completer. Hopefully...

Orderless: quite a few algorithms already exist for matching, and @vindarel is adding more. A goal for me in the next month is to provide the ability to mix and match algorithms, and make this a little bit more user flexible. I will probably start a thread and draft PR when that is ready and try to get as much feedback as possible. I doubt we will match this exactly, but hopefully we can get close enough in a way that makes sense for LEM.

Vertico - the basic functionality for this is how the prompt in Lem already works. There are improvements (actively being worked on by me). I've fixed a couple of annoying paper cuts already, and a bug that drove me absolutely crazy. I'm currently working on implementing an automatic completion setting for the prompt, so that you wouldn't have to press tab, and fewer keystrokes are needed. Hopefully that will be ready in the next couple of days.

Beyond that I'm not sure what else would be needed from Vertico, other than more prompt-completions.

All this also needs documenting obviously. That too will come...

[cianoc]

please describe what they do? : ( or how they differ from stock Lem.

When I get a chance I'll document this in the completions thread. I use these extensions myself - so I'm fairly familiar with them.

[psionic-k]

People often forget prescient. It is also the case that we could create and share a small bit of ML to provide some completions before the user has generated sufficient data.

[daninus14]

Is there a way to enable the search of commands to not be limited by dashes -? Like if I want to search for lsrepl for lisp-repl and start-lisp-repl to show up without typing - and separating the words.

[vindarel]

yes I'm trying this (using fuzzy-match).

[daninus14]

• It would be nice to have a simple tutorial with how to change themes, a list of available themes with screenshots, and a solarized-theme

[daninus14]

https://github.com/40ants/lem-solarized

[vindarel]

isn't it built-in now? M-x load-theme RET solarized-[light, dark] RET or I forgot where my is loaded from.

[cianoc]

Yes this makes sense. Some of this would be quite easy and quick, other parts less so. I'll add it to the list.

[daninus14]

Very cool, just tried it. Didn't realize it was there already. Thanks! 😄

[psionic-k]

The only thing I want is a CL MCP server so that LLM tools can be used to query a running CL image, look up documentation, and do smarter things with CL than me while I get familiar with the package landscape and differences between CL and Elisp. I want the LLM to answer questions about Lem, which it will have no idea about because there is not a lot of Lem data to train on. It will need to be able to query high-level indexes and to traverse through the editor's introspection tools towards facts it needs in order to deduce correct answers.

Here is kind of a prototype of this idea for Emacs, but it's not an MCP server and the tool ideas and descriptions need to mature more.

Many Emacs users are not great at Elisp and do not want to be great because it's not a general purpose language. However, CL is a great general purpose language. If it has great MCP support and LLM integration for extending and configuring Lem, it will be great.

Other things I need are simple, integrations like the Emacs Claude Code package, very fast and snappy LSP integration for Rust Analyzer and a fast terminal emulator for running processes with feedback. I have no idea what the state of those things are.

[vindarel]

Lem work for AI: #1745

MCP in CL:

• 40ants-MCP - a framework for building Model Context Protocol servers in Common Lisp.

[psionic-k]

So it looks like the infrastructure is there and just needs some tool definitions that can plug into the CL REPL to interrogate CL. It's nice that CL has so much more surrounding support than Elisp.

[cianoc]

You can do things a lot lot faster in Common Lisp, but there are fewer people working on LEM than Emacs. Anyone who can grok Emacs Lisp is capable of learning Common Lisp, but obviously it takes an investment of time.

[psionic-k]

Re-reading this, I can't tell if I was clear. I don't mean a CL MCP server library but literally an MCP server that is equipped with tools to introspect CL documentation and code in order to retrieve and deduce answers instead of attempting to generate them. With any new code, it can never be in training, and so this kind of integration is valuable when new CL programmers are reading & writing very new CL code.

[okflo]

Currently my biggest show-stopper to use LEM is actually the "limited" interpretation of Meta-Key. I am used for years to only use ESC as Meta-key (not ALT). You would do me a big favor, if ESC behaves the same as with emacs. Or is there actually a way to configure it already that way? many thanks - okflo

[cianoc]

Honestly not sure. Raise an issue for it and hopefully when @cxxxr has time he'll be able to give you a definitive answer.

[vindarel]

maybe a config like this? not sure either. #858 (comment)

(defparameter lem-sdl2/keyboard::*modifier-code-table*
  `((:shift ,sdl2-ffi:+kmod-lshift+ ,sdl2-ffi:+kmod-rshift+)
    (:ctrl ,sdl2-ffi:+kmod-lctrl+ ,sdl2-ffi:+kmod-rctrl+)
    (:meta ,sdl2-ffi:+kmod-lalt+ ,sdl2-ffi:+kmod-ralt+)  ;; <-- ralt added
    (:super ,sdl2-ffi:+kmod-lgui+ ,sdl2-ffi:+kmod-rgui+)))

[cxxxr]

I believe that esc being treated as "M-" is specific to GNU Emacs.
Rather than supporting GNU Emacs behavior in the core of lem, I think it would be better to add an emacs-mode similar to vi-mode.

[cianoc]

Yes, I always bind escape to escape in Emacs, as this behavior is useless to me (and i have my capslock bound to escape - because VI).

[fedreg-bn]

For me the biggest blocker is a Clojure mode.

...like CIDER for Emacs -- the clojure equivalent of SLIME.

even a simple repl that piggybacks off slime would probably work as a first pass.

If anyone has something like this working, please share

[cianoc]

I think you could get started by adding some code to support nrepl. But I have no idea what's necessary for this I'm afraid. I don't use Clojure.

[veqqq]

Documentation depends on Emacs. There are magic steps between what's covered and getting results or creating workflows which seem to be based on Emacs experiences - which blocks people who haven't used Emacs. Now, I do use Lem but a very small non-customized subset of its features because I don't have a good idea of useful workflows (since I didn't spend a decade with Emacs before) etc.

Everyone here's thinking about Emacs parity or how to attract people from Emacs, but... Just being a good editor and softening the process for people interested in e.g. Common Lisp is both easier and more distinguishing!

A tutorial to modal editors and customizing them through Lem would be cool!

[veqqq]

This will come off very negative because there's a huge chasm... But everything's fine, but I know I'm missing out on a lot with no clear path that isn't "learn Emacs for a few months". I love the Lem project and am happy you guys are doing this.

What are the things in the documentation that you found confusing?

Most things, honestly. For context, I used CL for many years, I used to use Allegro but couldn't stand the new browser based version. I've also used acme, Jetbrains, vscode, atom, sublime and so on. I used Emacs a bit, I just didn't see the point of learning a new language etc. when I could use Common Lisp with Lem, but... Lately, I'm mostly writing Janet on vscdoe.

What's even the purpose of modes vs. having a single mode/stable hotkeys? How do you make a given mode automatically apply to a certain file ending (to default to paredit...)? How do you make it open where you closed it at (with the same buffers etc.)? What workflow are you supposed to have with Lem, why is this useful?

It's clear enough to learn chords to open files and use paredit, but immediately after that, nothing makes sense without Emacs knowledge. For example, the documentation just starts with "buffer" and lists off commands, which are... still meaningless to me. But even worse, the promoted lem configurations are (all but one) for vim bindings etc. So it's not just demanding you know Emacs but also vim to reverse engineer what they're trying to do or... at least understand when settings are for vim instead, to search there?

Reading the code, you can see how some things are done internally and modify them. But it's not clear what hooks you should attach your own code to. I'm pretty sure 99% of stuff I've tried to do is already implemented, I just don't know how to find it or express my desires.

Then, like, how are you supposed to work through a real project with hundreds of files? Do people just remember every open buffer magically? Past ~10 files in a project, I go to vscode.

As an analogy, Lem seems like a fancy industrial drill for ex-users of brand x (who use settings based on brand y(, but I'm wondering why you'd want a drill instead of a hammer or glue, what problems this is for. I use it, because I want to attach things (and inline execution or sending to the repl and paredit are obvious enough) but I don't understand 99% of things and don't understand things enough to ask coherently.

---

There is a wide gulf. If you want, I'd be happy to have a call and point out uncomfortable things, questions and explain how I tried and failed to solve them in the past. But the basic problem: There's no tutorial.

[cianoc]

No, that's useful feedback. I think currently the documentation is quite lacking, and as you say is mostly written for people who know Emacs (and even then I had to dig into the code). I'm not sure that all of these things can be addressed immediately in documentation, just because writing documentation is difficult and takes time. But I think there are definitely things that can be done to make things clearer. And I can see that language which is second nature to an Emacs user, is opaque to an outsider. Emacs also (rather like Lisp) is from an earlier age where the language was a little different to how it is today.

I think Lem does need a tutorial that assumes nothing about Emacs, or Vim, and makes few assumptions about what the user does know. But before then I think we need to address some other stuff. For example I want to make some improvements to discoverability, help and to add an additional interface layer. And maybe see if I can persuade other people to drop some of the Emacs stuff that's probably not needed (e.g. M-x could easily be changed to 'Cmd' in the prompt window, with zero effect on anything).

I'd also like to set it up so that users can use non-emacs keybindings if they desire. I think there's a lot to be said for key chords, but there's also something to be said for not forcing people to unlearn familiar keybindings.

[veqqq]

The emacs stuff doesn't necessarily need to be dropped, just explained. It's fine to have a special notation, but e.g. a "glossary for beginners" or a "how to use this documentation" could help a lot!

Good luck!

[vindarel]

work through a real project with hundreds of files?

with project-related commands? M-x project-find-file or C-x p f to auto-complete all files in a project. https://lem-project.github.io/usage/usage/#find-file-in-project If fdfile (the program) is found, it allows to skip node_modules/ and other typical directories.

[psionic-k]

Reading the code, you can see how some things are done internally and modify them. But it's not clear what hooks you should attach your own code to. I'm pretty sure 99% of stuff I've tried to do is already implemented, I just don't know how to find it or express my desires.

This honestly feels like where leaning on LLM integrations and getting better at them is crucial to success. I can read. An LLM injests, filters, and summarizes.

[ValorZard]

Very much a long shot (i.e. I don't see this happening anytime soon, but)
would be nice if rust-analyzer got ported to Lem for the rust people
https://github.com/rust-lang/rust-analyzer

[cianoc]

Well ideally that should be necessary and I appreciate your attempt.

It sounds like we need a tutorial to Lem that ignores Emacs, and focuses on all the things that you need to do to get started. Also some of the things that you ran into here are papercuts that are slowly being improved (not that this is much consolation to you).

For future reference, 'C-x C-f' will open a file. Yes that's kind of terrible, yes it comes from Emacs and maybe that needs to change (or we have an Emacs mode for the die hard fans). I have also been wondering if we should replace 'M-x' with 'Cmd:' - as M-x is kind of mysterious.

There doesn't seem to be a compile command. That's definitely something that's missing. If there's anything else you would want, let me know.

[ValorZard]

@cianoc I think as someone who uses VSCode/Jetbrains products as my daily drivers, id appreciate a "Lem for VSCode/Jetbrains Users" type tutorial (but a tutorial for someone completely new to programming will also be nice)

[ValorZard]

I also think that some sort of options hotbar would be nice, see

[psionic-k]

is there a treesitter server that people use for Rust?

There's grammar files. I don't know the details of the integration, but in Emacs it has libtreesitter or something like that and just needs to load a grammar to work for that language.

[cianoc]

Okay, I'll add Rust-LSP to my list of things to look at. I haven't used Rust in a couple of years, but I do know the language - so it's probably good test case for improving LSP. And maybe I can work with @ValorZard.

Treesitter is also on my list. I have a very rough version that works, but doesn't actually generate highlighting :)

[daninus14]

Normal Key Bindings mode or VSCode Key Bindings Mode

Lem should be useful and usable for people who use normal editors like sublime, vscode, jetbrains, etc. Not just for emacs people.

For example:

• Cmd+Shift+p should open the M-x dialog.
  • Search in that dialog and any dialog should not be limited to breaking the names with - but should be a normal fuzzy search.
  • The Commands should be displayed with a title in bigger letters and there should be a description label in smaller letters. Just see vscode.
• Cmd+p should open the file open dialog like in vscode. Note this is equivalent to C-p f in emacs, not C-x C-f.
  • That same dialog with typing : should allow an integer to be typed afterwards which is jump to line (M-g M-g in emacs iirc)
• The regulars Cmd+c copy, Cmd+v paste, Cmd+x cut, Cmd+z undo, Cmd+Shift+z redo, etc
• Even the buffer cursor jump, split buffers, and others have key bindings in vscode and sublime. Pick vscode since it's more standard, can call it vscode-bindings-mode.
• Cmd+shift+[ and Cmd+shift+] for switching buffers
• I think there's a list of the basic key bindings in vscode.

I think this would basically make lem accessible for normal folk who are interested in CL and org mode and others but don't use emacs because of the emacs insanity.

Disclaimer: I am an emacs user and will just use the regular emacs key bindings. 5 years ago, had this been available, then it would be a different story, now it's too late haha but this is very important for non emacs users

[daninus14]

This should be the default key bindings mode to make lem accessible and welcoming to non emacs users. We emacs users wouldn't mind adding a quick line in the init.lisp file, but this is something that may be hard for non emacs users.

[cianoc]

Cmd should probably be the default for Ctrl on OSX, if it isn't already, for the default mode. Though that can cause issues, as OSX steals a lot of Cmd bindings by default. Which for a keyboard driven UI is a problem. Also, there's a reason that Emacs has a lot of keychords under x and c - and while I think Emacs has way too many keybindings by default (with mostly of them seemingly chosen at random), more keybindings is good.

These are good suggestions. I almost feel like there should be no keybindings by default, and easy way to add default keybindings (Emacs/Normie/VIM) etc. That's probably a little radical - but in Emacs its ridiculously hard to create your own keybindings that differ from the norm, and I think that's kind of bad.

I'm also not sure that we should slavishly follow the conventions of one particular editor. If these things are used by multiple browsers/IDEs then that's fine. But is Cmd-P really that standard?

I also want to add something like Doom's space menu, as I think that is a much better fit for a text driven interface. This would be M-space (as cmd-space, at least on OSX, is already taken).

I'll start a new discussion to talk about keybindings. It seems important, but it's also really hard to get right.

[daninus14]

I would not make Cmd in macos default to replace ctrl for emacs like bindings, because that's not how emacs works. At least not for me. The bindings I suggested which use Cmd are the standard bindings most editors have.

Cmd+Shift+p is fairly standard. It's in vscode, Sublime Text, Brave Browser, and a bunch of other places. Almost by default, whenever I'm in a new editor or even program, I try to do Cmd+Shift+p and Cmd+p to see if there's a quick command dialog. I picked vscode since it's pretty popular. I would assume, though we should check, that cursor, zed, and all the other new editors follow this convention.

I don't know about no key bindings by default. I think either Normie or Emacs, but then again I'm biased towards emacs. I think it's a decision that depends on who the target market is: any developer or emacs users. If so, even though I personally want emacs bindings and have a list of things to do to make it that way, it would probably make sense to have the default mode be normie key bindings and just have a global mode that can be set in init.lisp for emacs, vi, etc key bindings.

[cianoc]

I wouldn't do it for an emacs mode - this is just for a normal mode (though I have Emacs setup on my mac so cmd is ctrl - because it's more ergonomic).

No keybindings would be more something at the implementation level, so it was easier to create a new binding layer for those who want it (e.g. ergoemacs, or Kakoune/Helix or whatever). I'm probably overthinking it, but if I was to go in and do this - might as well do it right.

If there's a target market then it's probably Common Lisp users...

[daninus14]

A Settings Page

Non emacs users will find it easier to get started. This should have all the basic settings, not overly complicated things.
I think even in emacs there's a way to open some buffer to change some basic settings with a UI instead of text. Something like this. Normal (AKA non emacs) users are coming from vscode and sublime where they have regular UIs to edit settings. Even vscode which uses json data, displays a UI for editing it to make it easier for people.

• Should be accessible with Cmd+, like in every app
• It should allow to change or add a lot of basic settings that are common
• If there's an init.lisp file, then that file will be executed after this file overwriting any settings which are different

Disclaimer: I'm an emacs user. This does not affect me. It will just make it easier for new lem users not from emacs. This can help a lot of people who are interested in CL get into it as well.

[cianoc]

Emacs has customize screens. I'm not a huge fan of them, though some people seem to like them.

My worry with a settings screen is that it can be brittle when you have text based configuration, and its interaction with user custom config can be confusing (also a lot of dev work). I wonder if there's a way to keep text based configuration, to make that more accessible, without actually having the screen. Maybe something similar to how magit handles its UI, or the kind of inspectability you get with Smalltalk/Slime.

Also, I'm not sure Lem is necessarily a good fit for people who just want another VSCode. Part of its appeal is that its very configurable, and while I think it should be normal than Emacs, I think hiding that configurability behind a UI is bad.

Cmd+, is a good note. Thanks - that should do something.

[daninus14]

Thanks. I hear. I personally wouldn't use this and I'm happy with init.lisp. Cmd+, automatically opening or switching to the open init.lisp buffer would be convenient.

First users would also then know where to go.

Probably adding a template init.lisp can be very beneficial for first time users.

It could have:

• comments at the top
  • a welcome message
  • a link to the lem configuration docs website
  • and a comment about where to get help (command help or link to the usage website)

[cianoc]

I like this suggestion.

We can also do a better job with the dashboard, so that it does some of this.

[daninus14]

Proper Multiple Cursors

I actually switch from emacs quite often during the day to use vscode and sublime just because of the lack of this feature. The emacs package implementation is lacking.

Details here: #1892

• Able to add a cursor in the next instance or previous instance of the current selection of text
  • In vscode, if the search default is ignore case, then the multiple cursor functionality also ignores case. This would be nice to have as well.
• After selection a region, insert a cursor in each of the lines selected. This is like Cmd+Shift+l in Sublime Text. I actually switch back to sublime text from emacs just to use this functionality when editing text sometimes. A bit of a pain really to copy the text back and forth
• Add cursors in all instances of a selected text. This is Ctrl+Cmd+g in Sublime Text and Cmd+f in vscode code to search and then Alt+Enter. Sublime Text also allows this functionality with the find mode. It's actually very useful because it then allows regex, case sensitivity changes, and the match whole word setting for doing this. I actually leave emacs in my normal workflow and open files in sublime or vscode just because of this.

[alejandrozf]

I would like to run Lem using ABCL

[vindarel]

There have been work for this to be possible. I don't know the current state. https://lem-project.github.io/development/implementations-details/

[jasom]

An equivalent to message-mode would be great.

I currently use notmuch with emacs as my primary mail client. I'm willing to reimplement the notmuch-specific parts of that for LEM, but implementing message-mode involves so much yak-shaving that I'd really rather not be the one to do it.

[cianoc]

I suspect at the moment that you, or someone else similarly motivated, would have to be that person. I haven't used Emacs for email in years.

I would like to create a TUI library for LEM at some point to make this kind of thing easier for people to do. But I doubt that will happen any time soon.

[vindarel]

Here's a good start for a notmuch mode: #1048

[yzhou216]

Not licensed under GPL.

[cianoc]

The license is ultimately the choice of the editor's author, and we should respect that. I'm trying to keep the focus on features/bugs/limitations.

If your choice of editor is dictated by political values, which is perfectly reasonable, then I don't think Lem is going to be the right editor for you.

[yzhou216]

The license is ultimately the choice of the editor's author, and we should respect that.

I do respect that, just personally don't think a permissive license is the right choice for most software.

[daninus14]

I find this shocking:

That's debatable. The issue with MIT is that they don't always protect the rights of the end users.

Any end user can use the editor as he wishes and if there's a disagreement any party can make his own fork and version contributing to proliferation of features that people want. If everyone switches over to an editor because of feature x, the other forks will realize that feature x is a good idea and implement it. Otherwise development just advances based on the ideas of whoever is in control which is unlikely to yield the features most users want. How are the rights of the end users not protected? If you want to share a link, that's good to. At this point I'm just curious because I don't quite understand your point of view at all.

[cianoc]

If possible, I'd prefer if we move discussions of licenses somewhere more appropriate.

[monkeyjunglejuice]

Prefer MIT over GPL? Read this: https://lukesmith.xyz/articles/why-i-use-the-gpl-and-not-cuck-licenses/

[q3cpma]

Reposting from an external post:

• c-mode and c++-mode still not having something like clangd integrated is a bit sad.
• Sorry if this already exists: xref-go-back equivalent?

Not an issue, but I'm still weirded by the need to go through a small C library for LSP and other non-interactive use cases instead of just uiop:launch-program. And I wonder about the cost (if there is one) considering the verbosity of the LSP protocol ("protocol protocol", I know) and the need for terminal sequence stripping in the actual solution (because programs detect a TTY). #1182 has some discussion concerning this.

Other than that, great job! Simply polishing the current experience and frontends (maybe SDL3 one day?) is the best thing that can be done. Will probably start donating soon (EDIT: or not, didn't know the webview was to become the standard GUI frontend).

[cianoc]

Not an issue, but I'm still weirded by the need to go through a small C library for LSP and other non-interactive use cases instead of just uiop:launch-program. And I wonder about the cost (if there is one) considering the verbosity of the LSP protocol ("protocol protocol", I know and the need for terminal sequence stripping in the actual solution (because programs detect a TTY).

What is the reason for using the C library, and what are your concerns?

I agree on a debugger. Its just a matter of someone having time/inclination.

[BooAA]

As an EXWM user, I really hope some day I can login to a lem xsession and no need to worry about some synchronized operations blocking the whole UI. Probably it's out of the scope of this project though.

[nahuel]

Writing this as an Lem lurker, without any real knowledge of the current Lem state, more a wishlist than a list of issues:

• Do what neovim got right and Emacs is struggling on:

  • Use tree-sitter as the core for all modes, piggyback on it for font-locking / structural editing / outlining / folding.

    • Even for org-mode (join forces with the Neovim users that are implementing the org-mode tree-sitter parser)
    • Include tree-sitter langs compiled as WASM, make Lem batteries included or at least provide a very simple way to download the tree-sitter modules if there are license problems.

  • Implement a full LSP client / DAP debugger

    • Emacs eglot is still lacking in this front, for example, it doesnt' support multiple LSP servers attached to a single buffer. Be sure all LSP VSCode capabilities are present and accesible.
    • Make installing LSP servers very user-friendly

• Make the textual UI based on org-mode, for example, man/info/help pages should be converted to org-mode (if not in org already) and be displayed in read-only org-mode. Buttons should be org-mode links. E.g. source code samples in help pages should be runnable org src blocks. A grep results buffer maybe can be also implemented as an org buffer. Extend org format for cases were is
  not sufficient.

• Diffing should be superb (better than ediff), git actions can come later.

• Make WYSIWYM the closer possible to WYSIWYG. For example, a Markdown editor shouldn't have a "preview" pane. It must be like https://typora.io/ . I think Lem can get a lot of users just with this. Latex inline rendering is a must for this.

• Related to the previous point, Images inlined in buffers should be top-noch.

  • Note Emacs still have scroll issues with them, and Neovim only recently started to standarize inline images (using Kitty protocol)

• Make great neovim/evil keybindings, if well done they are going to attract a lot of users (like Doom emacs attracted lot of vim users)

• I think ditching SDL and using WebView is a very good idea, but if the console is still in the plans then support the Kitty terminal protocol extensions (now available in other terminals like WezTerm): KKP, Image and Font sizes

  • The JS should be the minimal possible, think Phoenix Liveview. Optimize for the case in which the browser and the Lem Common Lisp side are running on the same machine (minimum latency), this trade-offs against dual language code complexity.

• Remote development support

  • Support Devcontainers (now an standard beyond VSCode), make Lem capable of deploying a Lem agent inside a devcontainer just like VSCode does.
    • Note Neovim still lacks this, current neovim workflow is to install neovim inside each devcontainer and run it from it (a mess if you have many)
  • Support a tramp-like mechanism abstracting filesystem access like Emacs (Neovim also lacks this), to connect to machines in which there is no possibility of deploying the Lem agent
  • I think having remote dev support is more important than console support, as many console use cases are really remote dev use cases, that can be solved better by remote dev support (and with better latency)

• Server / client ("emacsclient") architecture

  • Make possible of running multiple Lem clients against a Lem server.
    • Note that emacsclient allows to run console emacs frontends and GUI Emacs frontends connected to the same server, can be good for debugging console/GUI differences.

• Base the default theme on Nerd Font, so icons are ready to be displayed both on GUI and on terminal

• Make Lem very screencasteable for the youtube community, e.g., make a mode in which the key pressed / command dispatched appear on screen

• Make packages isolated by default (like WASM), with capability-based security. I don't know at which extent this is possible using Common Lisp, but in think in the future it will be a must to use third-party packages avoiding supply chain attacks.

• Make live workflows tutorials. Emacs is too fragmented and is not always clear what the possible workflows are, you are always looking up commands in isolation. It will be good to be able to "play" an example multi-step workflow from inside the editor. E.g. "how to live search files, press [play]" and then you are guided throught the steps required. Think complex workflows, also
  be able to make branches in the workflows.

• Make possible to manage multiple projects / DAP debuggers from a single window (but also support multiple frames like Emacs). Note VSCode still cannot do this.

• Make a great base architecture, the community code will follow.

  • Try to use to the greater extent possible immutable data structures (like Clojure)

[mtha790]

As an Emacs and VS Code user, what I like about both is that I didn't spend much time on configuration.
For Emacs I'm using Doom Emacs, and VS Code's LSP configuration is so practical.
If tomorrow I have to work on a new workstation, 10 minutes of configuration and I'm done.
And I find it hard to get into Lem. I'm not used to packages vs Emacs' global namespace. It's hard for me to do introspection as I do in Emacs. Documentation is lacking—I spent a lot of time crawling through the source and I think it's not acceptable for the mainstream user that I represent. Reading the source is a very good thing but the mainstream user is not supposed to do that in order to setup Lem for his work

What I think would be great:

• A framework à la Doom Emacs for Lem, to lower the entry barrier to using LEM.
• More effort on documentation. I feel like documentation today targets more an advanced user than the average user.

To finish, I want to emphasize something about Emacs. Emacs is a tool for reading and writing. People who are not computer scientists actually use it everyday to read and write stuff. Having a larger target audience sets a standard for documentation and learning resources. Users are not supposed to know anything about computer science to start using Emacs. I think that Lem should also adopt this philosophy. Because Common Lisp has an exceptionally steep learning curve, it's a good reason to spend time on documentation and learning resources.

That's my two cents. I might sound rough but I really like your work on LEM. It's an exceptional piece of software that has a bright future.

[willbush]

Since you're asking. Wanted to try Lem for the first time today. Couldn't get the nix flake or Docker image to work. Couldn't find it packaged in NixOS. I'm not complaining. This is an ambitious project and a small community. I could probably fix the flake. Might try again tomorrow. Just thought I'd share what interested users might be bouncing off of.

I've been editor hoping recently.. Emacs (like 10 years at least), Helix 1 year, and now to neovim. I had a moment today when configuring things in Lua and was really missing Emacs. Watched a EmacsConf about Lem and got interested. I like the vision of Lem. Wonder how receptive contributions are. Wonder about performance (main annoyance with Emacs).