Can I customize emacs in any other language except elisp?

I saw that emacs can be configured in guile too. Is it possible to customize emacs in any other language or be able to write things that allow the configuration of emacs in that particular language?

you can write dynamic moduleb in any language as long as it exposes C FFI.

The guile project is a different version of emacs. However, while it may be possible to transliterate from one language out to lisp, you might find it easier just to use emacs lisp.

You can use JavaScript in emacsng

Even if you can, that would be a misuse. The whole point of emacs is to extend emacs with elisp.

> Is it possible to customize emacs in any other language or be able to write things that allow the configuration of emacs in that particular language? yes and no, there are several ways to: - use the other language's runtime (command line, Rest or any other API callable from elisp) - generage Emacs lisp code using the language of your choice - generate Emacs bytecode directly - dynamic modules most of them (except the 1st one maybe) are pretty fragile and hard to use for a generic Emacs user

Is it a rhetorical question or do you have a specific need in mind? As smug as the "why, just use elisp" answers are (and they are smug), emacs kind of /is/ a somewhat-crusty lisp interpreter with some text editing features. Even using another lisp (eg. guile) introduces a layer of redundancy and disconnect-- elisp *is* core anatomy of the program, not just an arbitrary configuration-language choice like it might be in other software. So this question sounds like... say... "can I measure something in metric using only a foot-long ruler?" You certainly can, but it begs other questions.

As a lover of lisps myself, there is nothing wrong with seeking to use a tool with which you’re familiar. One of the great advantages of emacs is the ease of integrating external tooling.

Short answer, yes. Long answer: Not without installing some plugins, practically. There is a project that adds JS and python, emacsng. There is a project that seeks to add applications into emacs, EAF, using QT framework. There are individual projects that add some interop. And then there is OrgMode, which is kinda special, because it is now built-in to emacs. In an org file, you can execute codeblocks to basically any language installed on your system. Need to run some python code, sure, why not. You can use the results from one source block to another, even if it is a different language. Including Elisp. And you can set up emacs to essentially run this at every startup. So, if you put that together, you can change variables at emacs startup, which is about as close you can ger from built-in functionality.

> Is it a rhetorical question or do you have a specific need in mind? >>Is it possible to customize emacs in any other language or be able to >>write things that allow the configuration of emacs in that particular language? Seems like a very specific question to me. > emacs kind of /is/ a somewhat-crusty lisp interpreter with some text editing features Huh? Why "sort-of" and "crusty"? Emacs *is* a lisp interpreter. Configurable Emacs options are exposed via its Lisp dialect, and thus its Lisp dialect *is* the easiest and most straightforward way to configure Emacs. The answer to Op is probably depending on if Op would like to just configure Emacs or extend Emacs with custom functionality. For the configuration use customize, there is no need to touch Emacs Lisp unless Op would like to write extensions for Emacs. Configuration != extension. For writing extensions, Emacs Lisp is the easiest and best supported language when it comes to ease of use, tooling quality etc, but it is possible to write plugins that expose Emacs runtime to some other language like emacs-ng does.

that could be alright and true(although even here i might protest that "integration with external tooling" isn't emacs's strongest skill ), but still the whole architecture, idea, design and culture(! yes, culture!) of emacs is lisp. Yes, you can use a rifle like club or shoot with rubberbullets, but a rifle is most effective when you use it for how it was designed for. You can also use SQL to do numerical integration and write AI stuff in assembler. It's all possible. Suppose you write an extension for emacs in python and you need to debug it. You still will have to deal with elisp each time some elisp is called. And you will have to deal with wrappers in python that wrap elisp up. Do you think this is a wise decision? If anybody wants to work on this extension they need to know both python and elisp. Is there any advantage of adding this complexity? Maybe op should instead just learn some elisp and become a better programmer for the rest of his days? Maybe neither op, nor the people who downvoted my comment have heard about this quote, read RMS's text about the history of emacs and can put this into some context. So while it's possible to extend emacs with anything(and actually it's possible to extend anything with anything), the question of the "why" remains. Just for fun? Ok, that's a valid reason. Otherwise I don't see really a point. I see more disadvatages of such a solution then advatages. It all comes down to the particular use-case, but in general it's like that. Putting a whole python app into a terminal buffer is also ok to me, but messing around with wrappers of wrappers so that one can more easily use the python eco system? Are you sure that for op's use-case(whatever it might have been) the elisp functions developed since the 80's are not sufficient? If I would want to implement extensions in other languages I would rather stick with neovim, that project goes more into the direction of being extended in multiple languages. I'll paraphrase what RMS had to say about emacs on MS windows: On ms windows emacs is just a text editor, nothing more. Similar my personal opinion is that with extending emacs in anything else then elisp you leave out a lot. My argumentation is here not chauvinistic like "elisp rules" or "real germans write only elisp and python is for the uneducated" or whatever. The whole point of emacs is to be extended in elisp, similar like the point of postgres is to hold data that can be queried with SQL. In most cases extending emacs with anything else then elisp is an architectural mistake and leads to an inferior solution

Elisp is honestly quite easy to get the hang of. And it has everything it needs to work well for configuring a program. I don't know if what you ask is possible, but I am curious as to why you want that

I've been wishing for the ability to configure Emacs using Clojure (another lisp) so hard that I might actually take the time to do it. In the meantime, I've come across this project that allows you to write Emacs extensions in Haskell: [https://github.com/knupfer/haskell-emacs](https://github.com/knupfer/haskell-emacs) Haven't used it yet so I can't comment, and it looks like it's been in hibernation for the last few years, but it may still work. I second emacs-ng, seems the most promising if you don't want to use Elisp at all.

Elisp may be passable for simple configuration code, but as soon as you want to start writing anything less trivial (like a package, minor/major modes etc) then it really starts to crack. I, for one, can't get over the fact that it doesn't have namespaces or modules, and so I have to prefix every single function definition *and* function call so that it doesn't clash with others and lead to weird bugs (even weirder if you're not using lexical scoping). The concurrency situation is also very problematic.