Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

EmacsConf 2021 Call for Proposals

emacsconf.org

Post reply on HN
Print view View original

21–30 of 86 posts

Re: EmacsConf 2021 Call for Proposals

#21

Post by tptacek »

na85 wrote: post #12

LSP-mode has really reinvigorated emacs, at least for me. With flycheck and a language server it's magical. Writing go, it even auto-formats your code and auto-adds imports.

Just for what it's worth, `goimports` has done this for many years:

https://pkg.go.dev/golang.org/x/tools/cmd/goimports

It's how Emacs handled inputs before there was lsp-mode, and presumably is easy to link into other editors too (it's just an implementation of gofmt that manages imports). I agree: it's an extremely nice feature to have.

Re: EmacsConf 2021 Call for Proposals

#22

Post by gumby »

p_l wrote: post #18
gumby wrote: post #11

Earlier quoted context omitted.

> As someone who’s not a developer nor a full-time product person Emacs was famously used by “secretaries” (as they were referred to in those days) not only to write documents and mail but to write macros to make their lives simpler. Of course none of them could “program” (which was considered quite intimidating) but they didn’t consider writing Emacs macros to be “programming”. Back then Emacs was written in TECO so…

The version that was used by secretaries in that story was programmed in Lisp, MACLISP for Multics specifically, and extended in Lisp.

I would be surprised if that were the case as the secretaries in tech square were using it on the PDP-10.

But its very possible -- I never interacted with any non-programmer Multics users.

Re: EmacsConf 2021 Call for Proposals

#23

Post by p_l »

gumby wrote: post #22
p_l wrote: post #18

Earlier quoted context omitted.

The version that was used by secretaries in that story was programmed in Lisp, MACLISP for Multics specifically, and extended in Lisp.

I would be surprised if that were the case as the secretaries in tech square were using it on the PDP-10. But its very possible -- I never interacted with any non-programmer Multics users.

The AI ITS machines I think weren't used by non-technical users much, the TOPS-20 machines might be, but the anecdote I heard was always in context of Multics, which had much more explicit time sharing story behind it (with computing as utility).

Re: EmacsConf 2021 Call for Proposals

#24

Post by truncate »

na85 wrote: post #12

LSP-mode has really reinvigorated emacs, at least for me. With flycheck and a language server it's magical. Writing go, it even auto-formats your code and auto-adds imports.

Before LSP, it was always annoying getting things setup. You want to get serious with a new language, spend a day configuring Emacs first. Or, fix your 3 year old config. Now it all pretty much just works! With native-comp its even better. Plus I'm using lot of modern features that I never did earlier, eg. renaming, automatically remove imports, see the inferred type in minibuffer.

Flycheck still makes it a bit slow. I think, one big missing piece is lack of multiple threads, which often makes few things a bit laggy. For example, if I'm reading a big C++ source code with indentation guides[1], even with native-comp it can lag a bit.

[1] https://github.com/DarthFennec/highlight-indent-guides

Re: EmacsConf 2021 Call for Proposals

#25

Post by jsrcout »

badsectoracula wrote: post #9
markmichalski wrote: post #3

I’m not a long-time emacs user, but as a new one, my enthusiasm is really growing. Like everyone, I’m finding that I’m in an increasingly disparate set of tools with diverging interface design choices to get my jobs done. The cognitive dissonance that all these different interfaces presents me with feels like it’s getting out of hand, and is growing non-linearly. Emacs is a arcane tool, and is dated in so many ways,…

Unified interfaces and allowing users to transfer any transferable knowledge between programs was one of the main ideas behind GUIs like the original Macintosh and Windows, but somewhere around the turn of the millennium things... broke. But there was a time when interfaces were unified, sometimes to an absurd level (e.g. applications having a File menu when they had nothing to do with files) but IMO that is still be…

My first job out of college was developing software on the Macintosh in the late 80s/early 90s and I absolutely took for granted being able to count on the user interface to work in a sane and consistent way for 99% of all software. I fondly recall and very much miss that.

Re: EmacsConf 2021 Call for Proposals

#26

Post by pdimitar »

Rant incoming. Dub it flamey or justified, it's up to you. I am posting it because this is one of my last hopes to make amends with Emacs. I accidentally used it for ~19 years -- my first ever team taught me it and I've never bothered to learn anything much else beyond Eclipse and VS Code.

So how about a more modern take on Emacs that doesn't pull punches? Let's go.

1. Finally use a proper LISP like Common Lisp, SBCL or Racket? (Maybe even Gerbil Scheme, last I checked it it was pretty nice to look at and code in.) While you're at it, make a transpiler from Elisp to the LISP you end up using?

2. Make sure your core editor is mega ultra super fast for a change? It's frankly pitiful to have Emacs lag on a server-grade / workstation CPU with an NVMe SSD when you are trying to pick one of 2000 files in a project. I should not even NOTICE a lag on this machine! I can enumerate ~10,000 files in the Alacritty terminal before I manage to blink and press Ctrl-C, so what does that say about Emacs? (And make ahead-of-time / JIT LISP compilation the default and only option for running LISP code, please!)

3. Drop GUI efforts and just make a full-blown terminal-only version? (This might be achievable with build flags and/or fetching certain packages if I remember correctly.) I mean, the GUI efforts are historically nothing short of heroic but if Emacs is going to lag severely on a retina 5K screen (iMac Pro) then obviously somebody is hard-coding assumptions into some GUI code somewhere. Not a good software design.

4. Use async interfaces to external tools like language servers? It's baffling to have my editor completely locked for 5-10 seconds when I first open a file in a project. I am sure I'll survive without compiler warnings for that period of time.

5. Oh, and can we stop lagging the editor on every scroll because the font has more than 1000 graphemes, please? My Apple IIc computer could handle a file with 1000 records in 2-3 ms (excluding time loading it from the floppy disc, of course). I know it's not the same but come on.

---

Emacs is dated in many ways. But I am not seeing any will for a change. It seems the team is happy with gradual super-careful steps until the end of time.

I mean, that's fine, obviously it's their prerogative and all others can't do anyhing.

But this here is one last cry from me; a cry for some common sense and perspective before I swallow my low-energy levels (pre-diabetes) and lack of time (family man) and sacrifice my not-so-much sleep and me-time and finally learn NeoVim. I am sure it's going to be worth it even if it ruins my health for a few weeks because the people there are actually invested in performance, lightweight operation and ergonomics.

Re: EmacsConf 2021 Call for Proposals

#27

Post by pdimitar »

ashton314 wrote: post #16
lliamander wrote: post #13

Earlier quoted context omitted.

I've struggled a bit with LSP mode (at least for Elixir). I find it hard to use as a full-time IDE replacement, especially since IntelliJ has such good emacs keybindings. However, as a general text editor, emacs is still great. And I enjoy org-mode.

I write lots of Elixir at my day job. What’s been tricky for you setting up LSP mode?

For me it's not tricky, even on Spacemacs (where configuring modes is a bit more arcane but once you learn it it's happily easy), it's more like it's laggy. :(

Re: EmacsConf 2021 Call for Proposals

#28

Post by gumby »

p_l wrote: post #23
gumby wrote: post #22

Earlier quoted context omitted.

I would be surprised if that were the case as the secretaries in tech square were using it on the PDP-10. But its very possible -- I never interacted with any non-programmer Multics users.

The AI ITS machines I think weren't used by non-technical users much, the TOPS-20 machines might be, but the anecdote I heard was always in context of Multics, which had much more explicit time sharing story behind it (with computing as utility).

I don’t know why you say that — the ITS machines were used by everybody in 545 tech square, researchers, admins and “secretaries” alike (both AI and LCS), from when I was there until they were gradually retired. The one TOPS-20 machine, Oz, didn’t arrive until times had changed and a lot of alternatives were already in use.

As for time sharing: ITS stands for “Incompatible Timesharing System” (a joke on CTSS), with memory protection, etc used by multiple users on terminals and over the net starting around/before the Multics project (all of which preceded Emacs of course)

Re: EmacsConf 2021 Call for Proposals

#29

Post by dctoedt »

gumby wrote: post #11
markmichalski wrote: post #3

I’m not a long-time emacs user, but as a new one, my enthusiasm is really growing. Like everyone, I’m finding that I’m in an increasingly disparate set of tools with diverging interface design choices to get my jobs done. The cognitive dissonance that all these different interfaces presents me with feels like it’s getting out of hand, and is growing non-linearly. Emacs is a arcane tool, and is dated in so many ways,…

> As someone who’s not a developer nor a full-time product person Emacs was famously used by “secretaries” (as they were referred to in those days) not only to write documents and mail but to write macros to make their lives simpler. Of course none of them could “program” (which was considered quite intimidating) but they didn’t consider writing Emacs macros to be “programming”. Back then Emacs was written in TECO so…

> Emacs was famously used by “secretaries”

As a law student in 1980-81, I wrote a custom user manual for the law review editors and our admin to use Emacs and Brian Reid's Scribe formatter (on the Computer Science Department's TOPS-20 machine using a VT-100 terminal over a 9600 bps line). I was the only even-remotely technical person on the editorial board, but even so, we were all in heaven: Once manuscripts were typed into Emacs / Scribe by our admin, we didn't have to literally cut, paste, hand-mark, retype, etc., on paper as the editing process progressed. And it speeded up the production process because we sent "clean" edited manuscripts to the printer, as opposed to manuscripts with significant pen-and-ink proofreader marks; this dramatically reduced the time we spent reading and correcting galley proofs. (Electronic transmission to the printer was next on the experiment list but we graduated and left.) I'm sure that's why I've been an Emacs user ever since, and wrote keyboard emulators for WordPerfect and MS Word.

Re: EmacsConf 2021 Call for Proposals

#30

Post by taeric »

pdimitar wrote: post #26

Rant incoming. Dub it flamey or justified, it's up to you. I am posting it because this is one of my last hopes to make amends with Emacs. I accidentally used it for ~19 years -- my first ever team taught me it and I've never bothered to learn anything much else beyond Eclipse and VS Code. So how about a more modern take on Emacs that doesn't pull punches? Let's go. 1. Finally use a proper LISP like Common Lisp, SBCL…

I'm curious what OS you are in. Unless I am over a slow tramp connection, it isn't common for me to see any lag in the editor.

And it is amusing that async through a buffer has always been possible. Just far more common for folks to not go that route on round one.

Post reply on HN