[HN Gopher] EmacsConf 2022
___________________________________________________________________
EmacsConf 2022
Author : hprotagonist
Score : 163 points
Date : 2022-12-03 14:27 UTC (8 hours ago)
(HTM) web link (emacsconf.org)
(TXT) w3m dump (emacsconf.org)
| davidkunz wrote:
| Right before NeovimConf: https://www.neovimconf.live/
| usr1106 wrote:
| Oh no, I missed half of it already when reading this.
|
| Well, in theory I could watch a lot of recordings any time later.
| But in practice I hardly ever do. If I decide to attend a
| conference, I spend the day there, even if it's at my desk. (Or
| the night, hello Linuxcon Australia). If I don't register and
| attend real-time I will never find the time to watch most of it.
| throwaway27084 wrote:
| Can you watch it purely in Emacs?
| donio wrote:
| Depends on your definition of "purely". I will watch using an
| mpv managed by EXWM so it will be showing up as an Emacs
| buffer. Or you could use the embedded video player in EAF.
| mark_l_watson wrote:
| Please post a link for setting this up. Thanks.
|
| EDIT: found https://wiki.archlinux.org/title/EXWM I would
| like to try that on an old Linux laptop
| _eht wrote:
| And EdConf tomorrow! Conference season is among us.
|
| exit
|
| quit
|
| bye
|
| /q ...
| hestefisk wrote:
| I heard VimConf was above standard.
|
| _ducks_
| Wonnk13 wrote:
| Good to know! For as much as I use Emacs I don't really follow
| the Emacs community / ecosystem.
|
| I saw version 29 was recently cut- is there anywhere I can get a
| good overview of "best practices in 2022"?
|
| I wouldn't mind dusting off my init.el and updating it. I haven't
| had a good yak shave in five years or so :)
| hprotagonist wrote:
| https://blog.phundrak.com/emacs-29-what-can-we-expect/ has some
| highlights.
|
| eglot, tree-sitter are both very nice.
|
| the sqlite integration is currently what i'd describe as
| "cute", but maybe not the most featureful.
| agumonkey wrote:
| I'm shocked that ast based edition is back. Many people were
| against this, lots of grammar based tools sadly failed (for
| better or worse reasons). In a way it seems that the
| mainstream rose above regex level tree manipulation, and that
| even html/css made people start to think in subtrees rather
| than linear data. This might reduce efforts a lot, whether it
| is for edition or analysis.
|
| And this fine grained source interaction was why I was so
| enamoured with emacs in the first place. It was such a deep
| feeling of control compared to anything I tried in the late
| 90s.
| hprotagonist wrote:
| tangentially related, https://hazel.org/
| agumonkey wrote:
| Thanks a lot :)
| signa11 wrote:
| yup, here is the previous discussion:
| https://news.ycombinator.com/item?id=33788208
| tmtvl wrote:
| The best way to set keybindings has been changed, from _define-
| key_ and _global-set-key_ to _keymap-set_ and _keymap-global-
| set_.
|
| Some examples: (keymap-global-set "<remap>
| <upcase-word>" #'upcase-dwim) (keymap-set icomplete-
| minibuffer-map "TAB" #'icomplete-force-complete)
|
| You can also use package.el to install packages from version
| control now, check the _package-vc-selected-packages_ variable.
| Erlangen wrote:
| The videos are pre-recorded, but after the video there is a live
| Q&A section. Come and join the IRC channel. It's a lot of fun.
| agumonkey wrote:
| Was this an exceptional measure or a planned new kind of
| organization ? It's interesting.
| michaelanckaert wrote:
| Fosdem has been doing prerecorded talks ever since the
| "covid" edition.
| bad416f1f5a2 wrote:
| This format started in 2018 or 2019, I can't recall which.
| hprotagonist wrote:
| 2019, just in time _not_ to be a covid adaptation.
| [deleted]
| spenrose wrote:
| As with the high vote totals for Firefox-related links, the
| presence of a link on an ancient* text editor at #1 on HN (as I
| write) reveals that HN voters are a bit ... old school. These
| tools' relative importance has declined over the last 15 years.
|
| * (I am a graybeard who used Emacs daily for a long time)
| G3rn0ti wrote:
| > These tools' relative importance has declined over the last
| 15 years.
|
| I would say to the contrary. There has been a flurry of new
| development on Emacs in the recent years initiated by a new
| generation of developers. New (and simpler) search and
| autocompletion frameworks (Ivy, vertico), native compilation of
| Elisp, the rise of Org and the advent of LSP clients (thx
| VScode). In the coming years Treesitter might render LSP
| obsolete some day. Exciting times ahead.
|
| And what does it mean to be an old piece of software anyway?
|
| Software may age but compared to hardware it has the advantage
| of being able to evolve. I hate it to break to you: Windows and
| Linux kernels are over 30 years old written in a language that
| was invented 50 years ago. The whole design principle of state
| of the art operating systems was invented in the 1970s. MS
| Office kernels are probably older than 30 years and the leading
| X86 platform looks back on an over 40 year old history. The
| first Python version was released back in 1991, that's 30
| years. JS almost has 27 years (1995 afir). Chrome BTW was
| released back in 2008, that's already been 14 years. Safari's
| engine comes closer to 20 years.
|
| Does it even make any sense to compare Emacs 29 with versions
| from the 80s?
| spudlyo wrote:
| > In the coming years Treesitter might render LSP obsolete
| some day.
|
| While LSP can support semantic highlighting, it's often used
| for navigation, ala goto-definition. I think there is little
| overlap between Tree-sitter and LSP.
| G3rn0ti wrote:
| > It's often used for navigation, ala goto-definition
|
| Yes, that's LSP's primary use case, either to jump to a
| definition or show inline documentation from around the
| definition as well as for autocompletion based on symbols
| in the execution environment accessible to a static
| analyser at least. I think that could all be done by a
| tree-sitter based parser, too, no need for a separate
| language server process. The LSP server can't do much
| beyond static analysis anyway. That's what makes me think
| it could be well replaced by a more sophisticated language
| mode. Check out the tree sitter talk, he demonstrates how
| easy TS makes querying the source code (using the tree
| sitter query builder) -- similarly how you query the DOM
| using a selector engine.
| pxc wrote:
| There's an Emacs mode for Scala development inspired by
| SLIME called ENSIME, which antedates the LSP servers for
| Scala.
|
| There are things ENSIME could do that back when I did
| Scala development were not supportable via the LSP
| protocol because it didn't have rich enough metadata to
| encode certain kinds of contextual information. The
| contemporary ENSIME maintainer, who was burning out on
| the project at the time, wrote about this and the growing
| but, in his view, native excitement around LSP efforts
| with a lot of frustration. In a few blog posts or tweets
| he pointed out specific issues the developers of one
| language server were running into which he'd anticipated
| and pointed out, to no avail.
|
| I like the multiprocess approach with standard protocols,
| despite its complexities, because it lets different
| editors share smarts. It's good when Vim users and Emacs
| users can participate in development with huge numbers of
| users of whatever is the trendy editor of the day, and
| share code in the form of LSP servers to benefit from
| IDE-like features. But I think it's likely we'll see an
| evolution beyond what LSP is capable of, and maybe
| standardization for some languages will be around
| something other than LSP.
| G3rn0ti wrote:
| > I like the multiprocess approach with standard
| protocols, despite its complexities, because it lets
| different editors share smarts.
|
| Yes, the benefit LSP brings is putting editors/IDEs on
| equal footing with respect to a specific language. Also
| the multiplicative effect when the author of a new
| language provides a language server so nobody needs to
| switch their IDEs to try it out.
|
| However, seeing how ,,straight forward" a tree-sitter
| specific language grammar looks in practice (1) makes we
| wonder if by providing a TS grammar for a language would
| realize (almost) the same benefit. Based on such a
| grammar and TS' selector engine figuring out a syntax
| highlighting scheme, code folder, a docstring or symbol
| scanner might not be such a huge endeavor any more as you
| described for ENSIME.
|
| So, yeah, in the end LSP might be dead end at some point,
| especially because TS promises to be very fast and avoids
| any IPC. Performance seems to be the biggest problem of
| LSP clients in Emacs and probably other editors as well.
|
| (1) https://github.com/Wilfred/tree-sitter-
| elisp/blob/main/gramm... -- of course, the example being
| ELISP makes it look easier than said, if you compare it
| with the grammar of Perl5 that's not yet finished
| unsurprisingly.
| pxc wrote:
| Idk. I started using Emacs at my second internship as a
| software developer, thanks to the current generation of fancy,
| IDE-like starter kits (Spacemacs in particular). I was in my
| 20s, and it was less than a decade ago.
|
| I experienced Emacs in that first encounter as hip and
| exciting! Setup was extremely easy, and the workflow was such a
| joy and such a shock that it changed what I want out of
| computer interfaces forever. The discoverability and in-band
| documentation blew my mind, and made the incredibly complex
| bundle of functionality and keybindings in front of me feel
| shockingly approachable and learnable. The Vim emulation was so
| good that Emacs is where I learned Vim, and even as a
| relatively unsophisticated Vimmer, few Vim emulation plugins
| have ever lived up to what I experienced with Evil.
|
| I don't think Emacs is about to take over the world, but it
| seems to be doing quite well. It seems a clear and ongoing
| source of inspiration for the trendiest applications that
| people use to edit code today, like VSCode. Important Emacs
| plugins like Magit have inspired the creation of some really
| nice TUI applications like lazygit and lazydocker, etc., and
| continue to be excellent.
|
| It may not be for everyone, but Emacs still still has a lot to
| offer. For a significant minority of developers in current and
| future generations, I think it will continue to 'click'. For
| developers of other software development tools, it will
| continue to be a source of friendly competition and
| inspiration, and in that way it will continue to anchor and
| influence the landscape.
| tuukkah wrote:
| What do you use now and how is it better than Emacs?
|
| I thought I was behind the times and learned VSCode but I've
| been underwhelmed so far. You still need to choose, install and
| configure extensions but these extensions are not of the same
| quality as Emacs extensions. For example, the Git extensions of
| VSCode fail as soon as something a bit unexpected happens. With
| no Magit around, you end up using Git command line which is not
| known for great ergonomics.
| markdeloura wrote:
| Editor wars are right up there with tabs vs spaces, right? I
| too was an Emacs devotee once upon a time. On of the CS
| professors at our school in the late 90's was even more so,
| known for doing all his work from inside of Emacs. But these
| days VS Code is really making life easy. It's impressively
| feature-rich with a minimum of futzing.
| hprotagonist wrote:
| you say old school, i say "prefers battle-hardened tools"
|
| it is kind of amusing to use an editor every day that is
| significantly older than me, i have to admit.
| gpderetta wrote:
| Emacs might be old school, but it will be still around when the
| current crop of editors of choice will have been forgotten.
| [deleted]
| ducktective wrote:
| >You can view streams using the watch pages or in a streaming web
| player such as MPV. If you need to reverse the video for easier
| viewing (ex: turning dark mode into light mode), try a command
| like mpv --vf=negate URL.
|
| Love attention to details like these
| jhallenworld wrote:
| Check out HHC, the HP Handheld Conference. It's just like
| EmacsConf, but the people are older :-)
|
| https://hhuc.us/
|
| The presentations are on YouTube, some I like:
|
| "Don't make me wait" https://www.youtube.com/watch?v=PPJdAvQpsGc
|
| "Book binding 2.0" https://www.youtube.com/watch?v=SAnkiaefcB8
|
| "Know thine enemy (TI)"
| https://www.youtube.com/watch?v=WIN2y-SnA6c (TI fast mode)
| sph wrote:
| Cool, but completely off-topic.
| agumonkey wrote:
| Only partly so, I'm stretching it a bit but HP Calc's RPN is
| inspired by lisp, and emacs calc is in turn stack based, just
| like RPN :) It's a big cross pollinization fest.
| zasdffaa wrote:
| RPN is forth not lisp, and I seriously doubt HP got their
| idea from emacs. I think HP's RPN precedes the first
| release of emacs anyway. Edit: 1st release of emacs was
| 1976 so I take that last bit back.
| agumonkey wrote:
| Sorry, I mistyped. I was thinking about HP42 and above
| RPL not the basic RPN. RPL is a blend of lisp idiom on
| top of good old stack based RPN (list, map, numerical
| tower). It goes so far that they even added quoted lambda
| expressions. You could push << a -> + a a >> on your
| stack.
| jhallenworld wrote:
| RPL is like LISP in that it's all about quoting. ' and
| eval are primary (unshifted) keys on these calculators.
|
| There was a LISP based pocket computer: the Casio
| AI-1000:
|
| https://www.youtube.com/watch?v=H-yuZ2pejGU
| Jtsummers wrote:
| It's use of RPN wasn't, but RPL was with one meaning for it
| being "Reverse Polish Lisp".
|
| https://en.wikipedia.org/wiki/RPL_(programming_language)
___________________________________________________________________
(page generated 2022-12-03 23:01 UTC)