Live data from Hacker News

Emacs: The Editor for the Next Forty Years [video]

media.emacsconf.org

261–270 of 272 posts

Re: Emacs: The Editor for the Next Forty Years [video]

#261
post #260
post #83

Earlier quoted context omitted.

What are some old fails that need fixed?

The big ones, to me: - No support for threads or any other concurrency model. Any I/O and the entire UI freezes, no matter how many cores you have idling. - Even on a single thread, the runtime is generally several times slower than comparable modern scripting languages. The GC is not so great, either. - The drawing model is archaic. Every mode seems to have its own kluge to work around such basic tasks as "I want to…

> The drawing model is archaic. Every mode seems to have its own kluge to work around such basic tasks as "I want to display a simple table".

It has pros and cons.

The pro is clearly that in Emacs everything is text, and can be processed as text, by using the same commands, keys and macros you use for everything else.

No other editor has this, and I cannot understate how handicapped I feel in those editors where some things are "off limites" and cannot be copied, because it's a designated "GUI" of some sort, instead just... text.

Taking that away from Emcas would IMO be a major loss.

Re: Emacs: The Editor for the Next Forty Years [video]

#262

Earlier quoted context omitted.

Don't know about the second, but displaying two copies of the same file side by side is pretty common in my experience, e.g.: PyCharm: Yes VS Code: Yes Eclipse: Yes

Vs code can't open two windows properly though..

I'm curious what you mean, as I've not had any issues thus far. I'm only an occasional VS Code user however.

Re: Emacs: The Editor for the Next Forty Years [video]

#263

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?

By no means a mu4e expert here. If of help, some of the mu4e bits I've picked along the way:

http://xenodium.com/trying-out-mu4e-and-offlineimap

http://xenodium.com/adding-mu4e-maildirs-extension

http://xenodium.com/trying-out-mu4e-with-mbsync

http://xenodium.com/faster-junk-mail-deletion-with-mu4e

http://xenodium.com/emailing-pdfs-to-kindle-from-mu4e

http://xenodium.com/building-mumu4e-on-macos

http://xenodium.com/mu4e-as-macos-mail-composer

edited: formatting

Re: Emacs: The Editor for the Next Forty Years [video]

#264

Earlier quoted context omitted.

Vs code can't open two windows properly though..

I'm curious what you mean, as I've not had any issues thus far. I'm only an occasional VS Code user however.

Only one os-level window per workspace is supported AFICT. It's possible to tile editors within this window, bit you can't detach an editor.

Re: Emacs: The Editor for the Next Forty Years [video]

#265

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?

By no means a mu4e expert here. If of help, some of the mu4e bits I've picked along the way: http://xenodium.com/trying-out-mu4e-and-offlineimap http://xenodium.com/adding-mu4e-maildirs-extension http://xenodium.com/trying-out-mu4e-with-mbsync http://xenodium.com/faster-junk-mail-deletion-with-mu4e http://xenodium.com/emailing-pdfs-to-kindle-from-mu4e http://xenodium.com/building-mumu4e-on-macos http://xenodium.com/m…

Thank you, your blog posts are really informative and clear. I am guessing from the last two you have working SMTP, and that's the step I'm stuck on. Any advice?

Re: Emacs: The Editor for the Next Forty Years [video]

#266
post #87

A question for Emacs user: Do you use the GUI version or the terminal version? I found the terminal version next to unworkable because I couldn't find any terminal that didn't capture some keystrokes that were meant for Emacs.

Terminal support is the only reason I use Emacs. Remote editing is a must. Emacs is the most feature-complete editor available on terminals.

The alternatives are: run VNC or RDP to get a remote graphical environment for an IDE or use VS Code's proprietary remote extension. Neither of these get me excited for many reasons.

The trick for terminal Emacs is to run Emacs as a daemon and spawn Emacs with the `emacsclient` command.

  alias e='emacsclient -nw -a "" -c "$@"'
You will have to rebind some of the key chords that terminal emulators refuse to pass through, but you really shouldn't be using key chords anyway (to avoid RSI).

Re: Emacs: The Editor for the Next Forty Years [video]

#267

Earlier quoted context omitted.

Upgrading org-mode should count as tweaking the config. Is there any part of org-mode that stopped working suddenly?

I've been using org-mode for about a decade now, and while I know there were changes made, I don't think there was even a single thing that just stopped working under me during the upgrade. I have a somewhat nontrivial amount of org setup, and there was never a case I'd have to fix anything in it after upgrade.

Export to HTML had some non-trivial changes in output.

Re: Emacs: The Editor for the Next Forty Years [video]

#268
post #250
post #247

Earlier quoted context omitted.

Text editors

And how they lack features to match what IDEs are capable of. Given that James Gosling created XEmacs, my go-to editor back in the day, I think you will find this interview interesting, although most certainly it won't change your opinion. https://thenewstack.io/a-conversation-with-the-creators-behi...

Thanks for this, nothing jumps out at me vis-a-vis our exchange here but since you took the time to post it I will take the time to read it.

It's not so much that I have strongly held beliefs so much as a combination of experiences that have led me to the juncture where I see most codebases as being quite unstructured, and I appreciate the benefits of a more unstructured tool for dealing with them.

The baseband for nearly everything I work with is text, pretty much all of Latin form (ASCII, UTF-8, ISO-8859-x etc). When it comes to having to switch context between various languages and codebases, all of many and varying levels of hygene, I've come to a conclusion that I have "a particular tool" that is more suitable than most others.

Of course, when I have the luxury of working with "more structured" code, I will use the appropriate tools, but quite often the tools don't work as effectively once the code deviates from more idiomatic structure (Eclips is notably robust in this sense - but I find it can be quite clunky).

But if I have the time to learn the tools, and the tools can make the code more "fluid" to work with then I'm all for it.

In particular "Java" (which is I presume why you're linking Gosling) lends itself to this, and I did make this point above. The language itself is so robust, and the development culture seems to value best practices well enough that making the investment to learn these tools is worthwhile (EDIT - exactly in the sense that Gosling describes in TFA).

Another example in recent times has been Apple XCode when doing IOS development. The tool-chain is far too complex for me to get a "bottom up" appreciation of how it works, and the IDE in that case works just fine for me.

But these are exceptions in my 20 years or so of experience. More often than not I've a big mess to be dealing with that demands a powerful text editor.

As a younger guy I used to spend hours trying to set up my IDE and get projects to work with my tools, but I've got kids to feed now and have other stuff to do.

EDIT - read it now. Still unclear of what point you are making, unless you are erroneously assigning me to the "real men use vi" camp ... vi (or vim) has it's place, but I wouldn't really put it in the same category as Emacs, except for the fact that maybe Emacs has a terminal mode of operation. vi to me is more like windows notepad. It's always there when I need to quickly edit a configuration file.

Re: Emacs: The Editor for the Next Forty Years [video]

#269
post #268
post #250

Earlier quoted context omitted.

And how they lack features to match what IDEs are capable of. Given that James Gosling created XEmacs, my go-to editor back in the day, I think you will find this interview interesting, although most certainly it won't change your opinion. https://thenewstack.io/a-conversation-with-the-creators-behi...

Thanks for this, nothing jumps out at me vis-a-vis our exchange here but since you took the time to post it I will take the time to read it. It's not so much that I have strongly held beliefs so much as a combination of experiences that have led me to the juncture where I see most codebases as being quite unstructured, and I appreciate the benefits of a more unstructured tool for dealing with them. The baseband for n…

[deleted]

Re: Emacs: The Editor for the Next Forty Years [video]

#270

Earlier quoted context omitted.

By no means a mu4e expert here. If of help, some of the mu4e bits I've picked along the way: http://xenodium.com/trying-out-mu4e-and-offlineimap http://xenodium.com/adding-mu4e-maildirs-extension http://xenodium.com/trying-out-mu4e-with-mbsync http://xenodium.com/faster-junk-mail-deletion-with-mu4e http://xenodium.com/emailing-pdfs-to-kindle-from-mu4e http://xenodium.com/building-mumu4e-on-macos http://xenodium.com/m…

Thank you, your blog posts are really informative and clear. I am guessing from the last two you have working SMTP, and that's the step I'm stuck on. Any advice?

I have additional config for SMTP. Added to http://xenodium.com/trying-out-mu4e-and-offlineimap

Here's the diff https://github.com/xenodium/xenodium.github.io/commit/73a27f...

Post reply on HN