[HN Gopher] EmacsConf 2021 Call for Proposals
___________________________________________________________________
EmacsConf 2021 Call for Proposals
Author : todsacerdoti
Score : 167 points
Date : 2021-08-05 15:51 UTC (7 hours ago)
(HTM) web link (emacsconf.org)
(TXT) w3m dump (emacsconf.org)
| pdimitar wrote:
| 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.
| Jtsummers wrote:
| Re (3):
|
| There is a terminal-only version, and it's not even new. It
| should be available without any build flags, though maybe
| you'll need a launch flag. Try _emacs -nw_ from the terminal if
| _emacs_ by itself launches a GUI window for you.
| pdimitar wrote:
| Yep, did that a while ago, was very disappointed how much
| coloring do you lose by doing it, for seemingly no good
| reason. :(
|
| Could be my config but dude, it's a 99% almost pristine
| Spacemacs config. You can't get much more vanilla than that.
| alex_smart wrote:
| >pristine Spacemacs
|
| >vanilla
|
| What? :O
|
| Spacemacs is like 50k LOC away from vanilla config.
| pdimitar wrote:
| Ah, I mean _vanilla Spacemacs_. :D
|
| I also meant I barely changed it, nothing more. Hence why
| I was baffled that switching to terminal mode lost like
| half the syntax coloring. :|
| Jtsummers wrote:
| https://develop.spacemacs.org/doc/FAQ.html#why-does-my-
| color...
|
| Seems like an appropriate FAQ item.
| pdimitar wrote:
| Well okay, fair enough but it doesn't actually solve the
| problem. Modern terminals can render basically all colors
| your DE / display supports so I am not sure why there
| isn't a check for that and utilize the feature if it's
| there.
| alex_smart wrote:
| https://i.imgur.com/TFTOj8Z.png
|
| This is with the default spacemacs theme. Can you tell
| which one is the terminal and which one the GUI?
|
| https://www.gnu.org/software/emacs/manual/html_node/efaq/
| Col...
|
| Emacs does have the feature you want. Perhaps your setup
| wasn't supported. Which terminal/os were you on?
| pdimitar wrote:
| Ouch.
|
| macOS with iTerm2 and then Alacritty.
|
| Now I am even more confused why it doesn't work well for
| me.
| spudlyo wrote:
| For your possible inspiration: Emacs in iterm2/tmux with
| 24-bit color, and a bunch of fancy icon sets mapped into
| the private use area running LSP mode looking a large
| Python code base[0].
|
| [0]: https://muppetlabs.com/~mikeh/ttyemacs.png
| alex_smart wrote:
| >why it doesn't work well for me
|
| Possible reasons:
|
| 1. (macOS + inside terminal) isn't a common workflow for
| emacs contributors, or perhaps for people with that
| workflow working with 256 colors isn't an issue
|
| 2. people who want that workflow who care about having 24
| bit colors didn't bother to file a bug report (did you?)
|
| Bitter pill, but I hope it helps: as a beginner to an
| ecosystem, if you are going to be opinioniated about
| having an unusual workflow, you are always going to run
| into problems. If you are running Emacs locally, just run
| it in GUI mode, that's what most people do.
| pdimitar wrote:
| I do run Emacs in GUI mode and it's embarrassingly slow
| due to various factors I gradually managed to pinpoint:
|
| 1. 5K retina display (other Mac owners seem to share the
| experience)
|
| 2. A font with a lot of graphemes (those without emoji
| seem to render faster)
|
| 3. The synchronous nature of LSP; I still don't get it
| why LSP can't work asynchronously in Emacs -- it does in
| VIM.
|
| Hence me asking about terminal mode where it also works
| rather confusingly to me (I mean the colors).
|
| > _(macOS + inside terminal) isn 't a common workflow for
| emacs contributors_
|
| As a guy who worked on OSS before -- and wants to do it
| again -- I am never feeling entitled to other people's
| work. I just wonder why those scenarios are supported in
| the first place (if no contributors are interested in
| making them work well).
|
| > _as a beginner to an ecosystem, if you are going to be
| opinioniated about having an unusual workflow, you are
| always going to run into problems_
|
| Fair enough and I don't think it's a bitter pill at all,
| I appreciate the feedback. But again, I am wondering why
| the supposedly first-class option (GUI) is also having
| problems. :(
|
| > _2. people who want that workflow who care about having
| 24 bit colors didn 't bother to file a bug report (did
| you?)_
|
| I wouldn't even know where to begin. The whole community
| and ecosystem seem extremely foreign to me and I never
| even got as far as to find a bug report template
| (admittedly I didn't try very hard). There's just
| something... alienating about this community, especially
| Emacs devs. Maybe I am wrong, I hope I am wrong but, just
| an accumulated feeling.
|
| In any case, the reason I am getting a bit ticked off is
| that Emacs is supposedly hugely popular. I'd expect a 5K
| screen and some richer fonts to not trip it but perhaps
| you're right that macOS isn't a focus.
| alex_smart wrote:
| >5K retina display >A font with a lot of graphemes
|
| You might have fun reading the article linked here:
|
| https://news.ycombinator.com/item?id=12830206
|
| >The synchronous nature of LSP; I still don't get it why
| LSP can't work asynchronously in Emacs
|
| Oh god, that is actually terrible.
|
| > I never even got as far as to find a bug report
| template
|
| The official way to file a bug report is M-x report-
| emacs-bug.
|
| >especially Emacs devs
|
| What's that feeling based on?
| Jtsummers wrote:
| You'll need to make sure that your terminal actually
| supports the variety of colors that emacs is emitting and
| that your terminal palette matches your emacs GUI color
| palette. Emacs can't magically switch your terminal from
| a 16-color mode to 256-colors, or change the palette.
| pdimitar wrote:
| I guess I have to tinker with the palette. Thought I
| didn't have to when the terminal supports a lot of
| colors.
| alex_smart wrote:
| >lost like half the syntax coloring
|
| Spacemacs's default theme works quite well in the
| terminal. Of course, when you are mapping a theme
| designed for a colorspace with millions of colors to one
| with 256 colors, there might _some_ issues, but that is
| to be expected.
|
| If even trying a different theme is too much of an effort
| for you, why in God's name are you wasting your time on
| an editor whose main USP is customizability?
| pdimitar wrote:
| Because I had no idea Emacs is about that when I started
| (loooooong ago, almost 20 years ago) and by the time I
| found out I was already burned out. Sigh.
|
| But I'll make time to migrate away, seems like it's time.
| taeric wrote:
| 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.
| pdimitar wrote:
| macOS.
|
| Can you give me a hint on how to do the async LSP thing then?
| I never was actually interested in becoming a master in
| Emacs. -\\_(tsu)_/-
| dbmikus wrote:
| Looks like LSP mode is async [1], but I haven't set it up
| myself. I mostly use Emacs as an org-mode app.
|
| [1] https://emacs-lsp.github.io/lsp-mode/
| taeric wrote:
| Apologies, I meant that async had long been doable in
| emacs. Compilation mode being a clear example of what that
| could look like.
|
| That said, most of the newest lsp code is built with the
| idea that calls out to the server are fast enough to just
| block.
| pdimitar wrote:
| Thank you for clarifying, much appreciated. <3
| zdragnar wrote:
| Not OP, but macOS here on a MacBook Pro less than a year old.
| Emacs has always tempted me, but a number of commands take
| roughly 2-5x the time compared to something like vscode.
|
| Every time I get back to trying out emacs again, I find
| myself wondering why I would bother with the massive time
| sink to get it customized to be a sub-par equivalent to
| another tool that works better for me.
|
| Doom emacs comes the closest for pre-configured setups, but
| even that isn't halfway to the productivity of what I am
| trying to replace.
|
| What I really wish is sublime had gone with something other
| than python for plugins, and was more scriptable overall...
| taeric wrote:
| What commands, in particular?
| jasonmorton wrote:
| Not OP, but for me adding or deleting a character in the
| middle of a paragraph in a latex doc hangs for maybe .5s
| or more, often. This is a fairly new phenomenon, never
| happened 2+ years ago.
| taeric wrote:
| That sounds broken. :(
|
| Good luck getting it fixed, if you are still trying. A
| basic profiler-start, type, profiler-stop, profiler-
| report can probably pay the blame easily.
| zdragnar wrote:
| The most distinctive one is when you start typing a
| chord- it can take up to a good second to populate the
| command list. Compare this to vscodes command palette
| which is instant.
|
| I admit that perhaps there is a configurable lag built in
| (it would make sense to do so) and while there are other
| examples that I know bother me, this is the one that
| jumped out straight away. I'd have to dig back in to have
| more specifics.
| taeric wrote:
| I'm not sure what chord menu you mean. :(. I /think/ you
| are describing "echo-keystrokes", which defaults to one
| second.
|
| M-x is basically instant for me, though. So, not sure why
| anything like that would be slow.
| pdimitar wrote:
| That's why I am 99% likely to move to NeoVim (or LunarVim
| which steps on it). LuaJIT looks like a very easy script
| language to learn, with minimal quirks -- at least on the
| first few looks.
| na85 wrote:
| 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.
| Wonnk13 wrote:
| 100% this. I learned Emacs in college for LaTeX and R (pre
| RStudio). I used it off and on for years after college to be a
| contrarian if I'm being honest.
|
| With LSP and the various client implementations I'm
| legitimately more productive in Emacs writing Python, Go, or
| Rust than whatever flavor of the month IDE thingamajig. Magit
| and Org are the cherry on top of the sundae.
|
| That said I don't push my beliefs on anyone in my team and I
| try to learn JetBrains products to make pair programming easier
| for folks that don't use Emacs.
| tptacek wrote:
| 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.
| na85 wrote:
| Ah, well, I only picked up go very recently so I have no
| experience writing go outside of the emacs+lsp environment.
| weavie wrote:
| How are you finding the performance of LSP?
|
| I dropped Emacs for NeoVim because Emacs would frequently
| lockup for a second or more due to LSP. NeoVim doesn't have
| this problem.
|
| I would love to return to Emacs someday.
| na85 wrote:
| I only use some of the more mature ecosystems (C#,
| Microsoft's Python language server, golang, etc) but I've
| always found the performance to be good.
| cle wrote:
| I don't experience any performance problems with lsp-mode, it
| is very snappy and never gets in my way of going from
| thought->code. In particular, Go's LSP support is excellent
| and very fast. I've found these days that the LSP perf is up
| to the LSP implementation, not Emacs.
| weavie wrote:
| Interesting. I'm using Rust on a fairly large project. I
| guess that takes a hefty chunk of processor time to work
| with, which causes Emacs to lock up and NeoVim not to..
| truncate wrote:
| 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
| lliamander wrote:
| 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.
| ashton314 wrote:
| I write lots of Elixir at my day job. What's been tricky for
| you setting up LSP mode?
| pdimitar wrote:
| 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. :(
| dpbriggs wrote:
| I would recommend checking out the emacs native-comp
| feature. It may not entirely solve the lag, but in my
| experience it helps a lot.
| yewenjie wrote:
| Last year EmacsConf was amazing. Looking forward to another great
| edition.
| thecatster wrote:
| Same as everyone else, happy to see EmacsConf is here. Hoping to
| get a talk together this time around.
| rcgorton wrote:
| Proposal: emacs is now irrelevant. Stabilize it, freeze and kill
| "future development". Oh, sorry, emacs 'development' is solely
| about emacs, rather than being about productivity. Too bad that
| emacs is more about DECs TECO than reality.
| [deleted]
| ddavis wrote:
| Emacs is really thriving right now. There are a lot of creative
| developers contributing to a really nice ecosystem of packages
| right now, with some things getting pushed upstream.
| markmichalski wrote:
| 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, but I don't
| know that I can find another solution that allows me to counter
| the ever-growing complexity of software productivity solutions
| that I presented with both in my personal and professional life.
| I know I'm not alone.
|
| As someone who's not a developer nor a full-time product person,
| (actually a doctor that wandered into tech), I often wonder why I
| can't choose my own front end, and why am forced to use
| interfaces that don't work very well for me. Emacs helps me
| escape some of that (at the cost of a huge relative learning
| curve, granted)
| gumby wrote:
| > 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 writing actual libraries
| was pretty arcane and not as easy as it is today.
|
| But I'm glad the learned helplessness around programming has
| largely ablated, in part through improved tools and in part
| through simple acceptance.
| dctoedt wrote:
| > _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.
| p_l wrote:
| The version that was used by secretaries in that story was
| programmed in Lisp, MACLISP for Multics specifically, and
| extended in Lisp.
| gumby wrote:
| 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.
| p_l wrote:
| 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).
| gumby wrote:
| 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)
| p_l wrote:
| Multics was also at 545 tech square, from 1967 to 1988.
|
| ITS version 1 is counted from 1967 as well (first
| mentions of PDP-6 ITS), simply because Project MAC
| couldn't deliver computing resources needed by other
| groups, not to mention AI Lab tended to modify the hw all
| the time (a fate AFAIK common to all ITS systems).
|
| The anecdote about secretaries extending Emacs came from
| RMS, describing a group that used the shared "utility"
| computing resources provided by Project MAC (later turned
| into LCS) and who used a manual that didn't mention the
| word programming, compiled by who-knows-who, which showed
| how to modify Multics Emacs (which was the second Lisp-
| based Emacs) to user's liking.
| BeetleB wrote:
| > As someone who's not a developer nor a full-time product
| person,
|
| If this year's Emacsconf is anything like the last one, you are
| a good candidate for watching/attending it. I know whenever
| Emacs is brought up on HN inevitable comparisons with IDEs and
| VSCode are made, but if you browse last year's talks, you'll
| see that most talks are _not_ related to SW development. Emacs
| has a _lot_ of enthusiasts who like it not for SW development
| but as an ecosystem.
| badsectoracula wrote:
| 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 better than
| every app being its own thing.
| jen20 wrote:
| > but somewhere around the turn of the millennium things...
| broke
|
| The rise of electron as an 'acceptable' (to some people)
| substitute for platform-native applications and the myth of
| the possibility of the "cross platform UI" has accelerated
| this, really. It's quite unfortunate.
| tikhonj wrote:
| Seems like Electron would make a _stronger_ foundation than
| native toolkits for Emacs-style flexibility, extensibility
| and composition. The DOM, for all its faults, charts a
| solid path between being _flexible_ and still being
| _structured_ , all while making it easy to change and
| extend from the outside. I've found it's much easier to
| write a browser extension that adds functionality to GMail
| --even without GMail actively supporting extensions--than
| it is to write a similar extension to, say, the native
| Outlook app (even with explicit plugin support from
| Microsoft).
|
| I haven't paid much attention to the Electron world myself
| so I don't know to what extent anybody is taking advantage
| of this, but even if they're not, I expect it would be
| easier than with alternatives.
| jsrcout wrote:
| 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.
| lifeisstillgood wrote:
| Well said. :-)
| agumonkey wrote:
| there's some enjoyable stability in emacs in a way, sadly it's
| changing a bit due to the growing number of packages and
| overlays. But it's still a little less tiring than trying idea
| then vscode then <new-ide>
|
| In emacs I get my freedom, it's cool. And in 2020.. it's the
| 2nd or 3rd lightest choice.
| jasonmorton wrote:
| I've been using emacs for many years now, and I'm sad to say
| that it has never been slower, despite the hardware getting
| better. Now it lags like crazy when editing a latex document,
| no matter the recent version. Something went off the rails in
| the last year or so, and even Atom is more responsive.
| tikhonj wrote:
| Have you tried the new native compilation system? I haven't
| worked on LaTeX documents specifically, but I did see a
| noticeable improvement in responsiveness across the board and
| a _massive_ improvement in Elisp-heavy functionality like
| org-agenda.
|
| I've used it on both Linux and macOS; for whatever reason, my
| Emacs has always been snappier on my Linux machine, and
| that's still true with native compilation, but now the macOS
| experience is also pretty solid.
| ducktective wrote:
| As a vim user, I'm happy about EMACS popularity and converge
| increase... Anything but Electron re-skins is a "right"
| technological move in my books...
| hnrj95 wrote:
| a lot of very rich emacs development has happened in the last few
| years, both to emacs itself and to extensions. it's been an
| absolute pleasure to use and has genuinely increased my
| productivity tremendously. eg after getting used to magit, the
| git cli becomes ludicrously cumbersome
| nosefrog wrote:
| I'm glad emacsconf is still a thing :)
___________________________________________________________________
(page generated 2021-08-05 23:00 UTC)