201–210 of 272 posts
I'm new to Emacs, but enjoying it very much. Just got mu4e working with Gmail XOAUTH2 (for a G Suite account that the administrators have implemented their own "delightful login experience"). Would there be any interest in reading a writeup?
Earlier quoted context omitted.
What are some old fails that need fixed?
One thing I notice: too many things cause unresponsiveness. 8 cores in my laptop and I can't install a package in the background, and semantic parsing interrupts typing. There doesn't seem to be any concurrency at all, things I do every day like eval'ing forms to REPL cause stutters. I love that it allows makers to explore new ui paradigms (magit, lispy), but performance is its biggest downside.
There are lines in my Emacs config files that are older than some of the programmers I work with, so I can relate. Contrary to what some people think, Emacs does not require constant tweaking and wasting time on configuration. I revisit my setup every couple of years or so, and I always find it is time well spent, as my productivity goes up as a result. I do not know of a better environment for multi-language program…
Emacs for me was always a poor replacement for my Borland and SlickEdit developer experience. Actually during my UNIX phase, I rather used XEmacs, as it provided much more friendly tooling than Emacs. Nowadays Emacs really fails short from what Java and .NET environments offer out of the box, specially in graphical tooling. Including mixed language development with C++. It is also interesting that James Gosling nowad…
Personally I use emacs over vscode due to following reasons,
1. it does not waste CPU cycle in rendering html, we have browsers for it.
2. Provide a good irc insterface with ERC without distracting my work like slack and discord with unnecessary bells and whistles,
3. and last but not the least does one thing very well which is processing and rendering text and by virtue became the most customizable editor in the world (not necessary to use customization all the time as it provides a very good out of box experience as well).
Emacs inspired me to take on and understand functional language. Rust still feels an incremental improvement with memory safety over C, not a radical improvement or a paradigm shift.
I believe C is unfairly criticised. C has it’s own drawbacks but it is one of the language which really gave me power to tinker with hardware directly and it was refreshing. Rust may be a great language in design but didn’t generate that feeling of directly able to work with hardware as I had when I used basic peek and poke and later C. Simplicity of C is still far superior to Rust.
If org-mode, text processing and lisp stays with emacs it will continue to survive for next 40 years. Yes it needs constant evolution but I do not agree with the list like renedering html, working with slack will enable it to stay relevant with modern generation Z programmers.
There is an amazing project of converting Emacs into the more modern language - Rust (the C parts of it). It is called REmacs[1]. It is sad that the port of Emacs to Guile[2] didn't work out. And for the people who want to convert their C code to Rust, I quite recommend trying c2rust[3] transpiler and refactoring tool. [1] https://github.com/remacs/remacs [2] https://www.emacswiki.org/emacs/GuileEmacs [3] https://git…
reading the GuileEmacs thing it sounds like the project was a success? Is there pushback against using this upstream?
Guile now runs elisp, although there is a lot of low hanging fruit left when it comes to optimization. Guile is shaping up to become a very neat little VM, with proper threading, JIT compilation, and delimited continuations.
I think the idea of elisp running outside of Emacs, with access to all of the gory glory of Emacs libraries sounds fantastic. Imagine org-mode and a (emacs PKG org-mode) library you can use outside of Emacs with a sub 0.1s startup :)
Earlier quoted context omitted.
> "Writing a function for the full change" is simply not a tenable thing to do. "Duplicate a line" is fundamental in the same way that "go to start of line" or "indent this line one more tabstop" is. So write a function for "duplicate line" and use it from now on. It's very easy to do. Just as it's easy to write function for a full edit. A general algorithm to get one started: 1) Execute the edit you want to reuse. 2…
I love view-lossage. How often do You use C-x which shows elisp for what ya just did? Eg, switch buffer then try it.
Also, it reads straight from command-history variable (another thing I didn't know about). You can preview and browse it via C-h v command-history. Or, write your own elisp operating on it (perhaps interactively, by IELM - the elisp REPL).
Emacs has really undergone a renaissance in the past decade - magit, LSP, ivy, spacemacs, doom emacs - there have been so many novel new packages and frameworks written by elisp hackers. For such an old editor, the development scene feels incredibly alive.
I'd agree that LSP has been a huge boon to the ecosystem. Spacemacs I feel has had the opposite effect. It hasn't had an "official" release since Jan 2018, and there are TONS of lame and fixed bugs that persist in the mainline. I actively recommend people NOT to use spacemacs because of how broken the release process is. It really feels like the maintainer(s) simply does not have the time to devote and it has vastly…
I'd recommend just switching to the develop branch. Honestly they should just make it master.
Earlier quoted context omitted.
And it will only get better once it understands LSP, better than it does now. It's a pale copy of VSCode's incredible LSP implementation: for a user, simply clicking the button to install the extension automagically configures a fully functional language environment; even for C++. Most of the time. When last I tried to get decent C++ support working with Emacs, about a year ago, it was still a mess of compiling rtags…
I've been using Emacs' lsp-mode ( https://github.com/emacs-lsp/lsp-mode ) for professional Python development for months now and it's been a great experience. It requires a little more work than I'd like to get it working with virtual environments (making sure the LSP server process is running in your venv, mainly), but I would argue that's a problem with the Python ecosystem, not lsp-mode itself. And for statically…
Emacs - the editor that STILL doesn't have a simple way to duplicate the current line?
Once you create a macro like that you can run it, name it, save it to your config, bind it to a key, whatever suits your workflow.
I never really thought of how much I do this manually, so I just set it up for myself right now. I'll probably rewrite it as an elisp function though.
Earlier quoted context omitted.
Language Server Protocol brings this to many editors that historically lacked it, including Emacs' lsp-mode. I use it a lot (with clangd), it's great. Because it's a common interface used by all editors, there is a lot of interest in and work on the language backends.
I'm all for standardizing this but I can't hear about the Language Server Protocol without thinking about this rant: https://youtu.be/pW-SOdj4Kkk?t=2549 The rant itself is probably misdirected towards LSP when it should be directed to the circumstances that it has to deal with.
That said, LSP is more supposed to be thought as the backend to the editor, not just a library. And the problem it solves are twofold:
1. Having to rewrite the same logic in all the programming languages used by all editors. Since as far as know, there are no language agnostic libraries, but a server is.
2. A strong boundary protects from accidental coupling of the UI/UX and the business logic. Without this, maybe at first you'd think you use some part of some other editor in yours until slowly over time it becomes more and more coupled to that particular editor's UX/UI. Even LSP actually suffers a little from that in that the APIs are totally designed with VSCode in mind first, but that stronger boundary protects it getting even worse.
Earlier quoted context omitted.
Language Server Protocol brings this to many editors that historically lacked it, including Emacs' lsp-mode. I use it a lot (with clangd), it's great. Because it's a common interface used by all editors, there is a lot of interest in and work on the language backends.
I'm all for standardizing this but I can't hear about the Language Server Protocol without thinking about this rant: https://youtu.be/pW-SOdj4Kkk?t=2549 The rant itself is probably misdirected towards LSP when it should be directed to the circumstances that it has to deal with.
The thing with Emacs is that you need to embrace Elisp, and the workflow of working inside a REPL. If you're someone who like to have things your way, and who are more comfortable with a programming language then a UI, Emacs is for you!
I personally use Spacemacs in Holy mode with Ivy and my own customization and some custom layers. I find this to be a great combination.
I use it for Clojure development with Cider and Java development with lsp-java. And for editing most files, like configs, scripts, bash files, json files, etc. I also use it for notes in org-mode.
The only things I rely on a different editor is Vim and less for dealing with large files like log files, and Notepad++ for when I need to do fancy search and replace stuff especially if the file is large.