request for documentation on feature matrix parity with emacs

[hgkamath]

Firstly thank-you to the developers.
I am intrigued by the idea that you are making an on common-lisp based editor in a manner similar to the elisp-based editor emacs. I understand that the advantage of a common-lisp based editor is that it can link to native libraries, and make use of common-lisp's blazing fast jit-runtime, as opposed to elisp which is interpreted.

This issue is to request a documentation file, a checkbox-listing, which details features in lem and emacs and their status.
The list could be ordered to have 3 top-level sections

1. Features that emacs-31 does not have (or does not make sense to have) but lem has or will have
2. Features that emacs has and lem has already caught up to or will eventually catch up to. This section could be broken into a long term, mid-term, short-term, and done
3. Features present in emacs that lem will never do (as maybe it does not make sense to have)

The documentation file will need to be updated periodically whenever there is a version update to either emacs/lem. ie when features are added/deprecated in emacs as well as added/deprecated in lem.

Also, useful is another documentation file of a checkbox-listing of emacs/lem plugins/scripts., that currently exist as of today, or in the planning and will one day run be available. I saw pullreq recently #784 , unsure if it added the elisp interpreter itself or just the elisp-syntax parsing and external tool interfacing.

Such documentation will help potential users to decide if and when they can make a jump, or also maybe to contribute.
Optionally, in addition to a md file in the git, their contents could also be synced-to and made available on the lem web-portal.

Examples of feature matrices:

• moggie: comparison with previous version aka mailpile. A checkbox-listing like the below is useful to see
  https://github.com/mailpile/moggie/issues/6
• mesa: (comparison between backend drivers)
  https://mesamatrix.net/
• xen-project (self-comparison between versions)
  https://xenbits.xen.org/docs/unstable/support-matrix.html

[seanfarley]

Honestly, I think it's a bit early to do this. Lem is great and fun! But there are many minefields in the gui version and discussions to be had about text rendering and design of an api. I'd really like to iron out those first, if possible. It's just my two-cents for now.

[hgkamath]

ack, true, no pressure, no hurry, do as you see fit. Its also okay if you mark the document up as under-construction/incomplete, start empty and jot item-entries as one encounters/remembers. It'll probably double up as a todo list.

[cxxxr]

Very interesting issue, thank you for your interest in lem.

I have a concern about comparing lem and emacs too much.
GNU Emacs is very nice and there are many aspects that I would like to refer to.
However, I believe it is necessary to move away from GNU Emacs when differentiation is needed.

[Sasanidas]

I think comparison can be really interesting, but I would split this list in 2 (or one list and one easy maybe).

One can discuss the general features of the editors and the other would discuss the internal design decision that makes Lem unique and even if it's heavily inspired, is not meant to be a 1:1 clone on Common Lisp by any means, but an effort to pursue the idea of an "Emacs" with a more modern approach (modern means here not having 30+ years of development) but having the same "feeling" of a light lisp machine with superb editing capabilities.

For me, the best thing that Lem have is the real potential of it. The foundation is way more solid that GNU Emacs from a engineer perspective (this can be a very interesting conversation).

So, I think these list can be beneficial for both GNU Emacs users and Lem users, but in the end, I think Lem can aim even higher, not only improving Emacs from the ground-up but expanding the capabilities with the aid of CL.

[Sasanidas]

Also, useful is another documentation file of a checkbox-listing of emacs/lem plugins/scripts., that currently exist as of today, or in the planning and will one day run be available. I saw pullreq recently #784 , unsure if it added the elisp interpreter itself or just the elisp-syntax parsing and external tool interfacing.

It's just support for editing elisp code, using an external interpreter from an Emacs instance, but I do have in my mind to have a package for a layer from elisp -> Common Lisp (Lem), it's just that I don't think it's a priority.