[HN Gopher] Emacs 27.2
       ___________________________________________________________________
        
       Emacs 27.2
        
       Author : lelf
       Score  : 225 points
       Date   : 2021-03-25 12:58 UTC (10 hours ago)
        
 (HTM) web link (lists.gnu.org)
 (TXT) w3m dump (lists.gnu.org)
        
       | hamburga wrote:
       | In case you're eager to upgrade (I never am, that's the point
       | with Emacs![1]) here's the description of the changes:
       | 
       | "Emacs 27.2 is a bug-fix release, with no new features with
       | respect toEmacs 27.1."
       | 
       | [1] Excellent Steve Yegge post describing how much Emacs cares
       | about stability and backwards-compatibility: https://steve-
       | yegge.medium.com/dear-google-cloud-your-deprec...
        
       | sigmonsays wrote:
       | what is the release cadence of emacs?
        
         | ddavis wrote:
         | While a set-in-stone release schedule doesn't exist, there is
         | _a lot_ of development activity (emacs-devel is a very busy
         | mailing list). 99.9% of the time it's safe to use the bleeding
         | edge head of the repository if you want to use the latest
         | stuff.
        
           | disgruntledphd2 wrote:
           | except in the few months following a major release (at least
           | for me)
        
         | nathell wrote:
         | I think there isn't an official one, but since 2016 there's
         | been a major version released approximately every two years,
         | and a minor version every couple of months.
         | 
         | https://www.gnu.org/software/emacs/history.html
        
           | unixhero wrote:
           | That's pretty solid!
        
       | ilovecaching wrote:
       | Not to start a holy war, but what are the advantages of emacs
       | over vim these days? I'm considering switching to emacs just to
       | have learned both.
        
         | ducharmdev wrote:
         | You can have the best of both worlds using spacemacs in evil
         | mode. Essentially gives you emacs with a lot of community-
         | selected plugins, but with vim keybindings.
         | 
         | As a vim user, there's just certain tools emacs provides to
         | which there's no vim equivalent (or the vim implementation is
         | lacking). Like org mode for example: I've yet to come across
         | something outside of the emacs ecosystem that does a good job
         | of replicating org mode. Maybe jupyter notebooks come close in
         | some ways, but AFAIK the org mode experience is fairly unique
         | to emacs.
        
         | elpatoisthebest wrote:
         | Take my answer with a grain of salt because I have much more
         | experience with vim and I have used emacs only off and on for a
         | couple years, and I only use it as an "IDE" of sorts.
         | 
         | So, how I experience them, they aren't exactly competitors in a
         | direct sense.
         | 
         | When I use vim in the terminal, I treat my workflow in a
         | particular way. I use tmux to have windows for multiple
         | projects (usually I run 2 or more microservices in my day to
         | day). I use TUIs like lazygit, and I rely heavily on command
         | line tools to build, compile, and do most of the daily things.
         | I am familiar with those and it's basically like the whole
         | terminal is my IDE in some ways. For note taking and idea
         | management, I use vimwiki within vim.
         | 
         | Using Emacs is different for everyone's specific use cases, but
         | the way I have tried to use it as an IDE for golang, node, and
         | some react. Emacs seems to prefer integrating your workflow
         | INTO emacs rather than just having emacs be a single part of
         | your workflow. (I'm simplifying too much, I think)
         | 
         | Evil mode gives me literally every single vim command I ever
         | have used in my entire life. I am a heavy vim user, but I am
         | not an extreme power user. I use macros, regex, and other
         | simple vim stuff. All of it is perfectly fine in evil mode as I
         | use it. But feature parity isn't a great reason to switch from
         | vim IMO.
         | 
         | -The first thing that really is a huge improvement is org mode
         | to capture anything in the code I am looking at that I don't
         | have time to address. Like capturing a weird piece of code or
         | something that might have a bug state, org capture, make a note
         | of it and I can come right back to it later when I have free
         | time.
         | 
         | - Everyone touts magit. I love magit, BUT if I'm being honest
         | with myself, lazygit is nearly just as good...and if you've
         | been using git commands fine for any amount of time, it's more
         | of a nicety than a MUST have. I don't view magit as "the killer
         | app" that other do, but I admit that I really like it and use
         | it heavily whenever I use emacs.
         | 
         | - Elisp is amazing compared to vimscript. That's pretty much
         | that whole bullet point.
         | 
         | There are more things, but it might depend on your personal
         | workflow and the kind of work you do.
         | 
         | I recommend dipping your toes in using DOOM emacs (or
         | spacemacs, but I didn't like that one as much) and getting a
         | feel for emacs. You might find that you like it, you might find
         | that you prefer your current vim & terminal based workflow
         | better.
         | 
         | I'm somewhere between the worlds. I really keep coming back to
         | emacs because of 1) Org mode 2) Csv mode (Sounds silly, but I
         | do a LOT of csv parsing in my life) 3) elisp hacking & scratch
         | mode.
        
         | znpy wrote:
         | The scripting language isn't total crap, for starters.
         | 
         | There's a huge amount of tools (package) that enable additional
         | features.
         | 
         | It's easy to interface with other stuff.
        
         | neolog wrote:
         | In some sense, they're not in the same category. The old joke
         | "Emacs is a great operating system, it just needs a good text
         | editor" is basically true.
         | 
         | If you like vim, try Doom Emacs or Spacemacs.
         | 
         | If I were going for pure text editing today I might want
         | something like https://kakoune.org/ whose selection->action
         | pattern seems better than Vim's action->selection pattern.
        
           | okamiueru wrote:
           | I'm a little confused. If doom emacs is good, wouldn't the
           | emacs experience when just disabling evil (vi-bindings), and
           | thus having regular emacs workflow not also be pretty good?
        
             | neolog wrote:
             | Spacemacs has like four different keybinding modes, one of
             | them is regular emacs mode. I thought it was pretty good. I
             | haven't used doom myself but I know people like it.
        
         | klibertp wrote:
         | NOTE: This is advice for programmers: if you're not a coder, it
         | won't make any sense for you.
         | 
         | If you are a programmer, though, and you're going to learn
         | Emacs, learn it along with Emacs Lisp and Elisp development
         | tools.
         | 
         | One definite advantage of doing that is experiencing the
         | "plugin" development environment done right. If you ever
         | scripted Vim, or any other program other than the web browser,
         | you're in for a fun ride. really The "plugins" in Emacs are,
         | surprisingly, full-blown programs. When writing them, you can
         | evaluate any part of the code and see the results immediately.
         | You have access to a source-level debugger and two profilers
         | out of the box. Every function you use is documented, and
         | accessing that documentation is trivial. You can "go to
         | definition" of any variable and function, including primitives
         | written in C (if you compiled Emacs yourself and have the
         | sources on disk). You can modify, extend, or override any
         | function anywhere with advices. The language itself is also
         | interesting: it's multi-paradigm. You can write code in
         | procedural, functional, and OOP styles. The OOP implementation
         | is based on generic functions and multimethods/multiple
         | dispatch - unless you worked with Clojure or Julia, you're
         | unlikely to have encountered that before. The quote/unquote-
         | based macros are powerful, and even if you don't use them, you
         | can benefit from them, for example, by using a library
         | providing pattern-matching/destructuring (like pcase or -let).
         | 
         | And you get all of that _just for writing plugins for an
         | editor_. Let that sink in. The tooling and language, which,
         | though a bit clunky sometimes, rivals professional IDEs and
         | languages like Kotlin, _just for writing extensions_. Seeing
         | all of this after trying - and failing - to write a simple Vim
         | plugin with VimL and Lua was a mind-blowing experience.
         | 
         | It's also an advantage - to get back to your question - which
         | explains the massive amount of Elisp programs and plugins out
         | there. Well worth experiencing.
        
         | selectnull wrote:
         | I can so recommend this.
         | 
         | I've switched to emacs few years ago for the same reason and
         | spent about a year using it. Although I've switched back to vim
         | afterwards, having spent time with emacs was fun and not a
         | waste of time.
         | 
         | Have a leap of faith, find the advantages of one (or the other)
         | for yourself. If you don't like at any time for any reason just
         | switch back: after all, it all text files you're editing.
        
       | in9 wrote:
       | as a vim user, how could I learn Emacs? I know of Evil mode, but
       | how easy is it to have some stuff just like I have in vim (such
       | as custom text objects, vim-surround, etc..).
        
         | acoard wrote:
         | Look at Doom Emacs. It's pre-configured to work out of the box
         | for modern dev.
         | 
         | There are also some good guides on YouTube by DistroTube, if
         | you prefer to learn that way.
         | 
         | https://github.com/hlissner/doom-emacs
         | 
         | https://www.youtube.com/watch?v=dr_iBj91eeI
        
       | kragen wrote:
       | https://github.com/emacs-mirror/emacs/blob/master/etc/NEWS.2...
       | says, "This is a bug-fix release with no new features." But I
       | don't understand what the bugs were.
        
         | nicklecompte wrote:
         | Check the Changelog for that:
         | https://raw.githubusercontent.com/emacs-mirror/emacs/master/...
        
           | kragen wrote:
           | Thanks!
        
         | b5n wrote:
         | From the OP:
         | 
         | > For the complete list of changes and the people who made
         | them, see the various ChangeLog files in the source
         | distribution.
        
       | Decabytes wrote:
       | I've used Emacs for almost 5 years now and it has served me well.
       | In the beginning it was frustrating and confusing, but now that I
       | understand it, it's the way I naturally interact with code on my
       | computer. The fact that so many gnu tools have movement similar
       | to Emacs means that I can quickly become more effective in them.
       | The fact that my work Macbook allows me to do some rudimentary
       | movement with C-a, C-e, C-f, C-n brings me joy.
       | 
       | Emacs rewards me for learning it better, and when I think about
       | what it does, and is capable of doing, I'm just in awe. I highly
       | recommend reading Mastering Emacs if you would like to become a
       | more effective Emacs user.
       | 
       | After using it for years I can say my single biggest gripe with
       | Emacs is its performance. Elisp is powerful but slow, and has
       | many warts. The developments with GccEmacs excites me, and there
       | is still GuileMacs. As a more experienced user Emacs frustrates
       | me because at times I demand too much of it. And when that
       | happens, I try to temper that frustration with the understanding
       | that the program is 36 years and 5 days old to the day, and has
       | outlived many other pieces of software. Computers looked
       | different in 85 than they did today, and the fact that I have
       | saved truly days of programming time due how effective it makes
       | me cannot be overlooked.
       | 
       | I want Emacs to continue to improve. I want it to get even better
       | than it already is, but I am so grateful for the people who have
       | made it what it is today.
        
         | anaerobicover wrote:
         | On the performance/stability of Elisp front, I just heard about
         | remacs, which is a fork that's starting by porting all the C to
         | Rust: https://github.com/remacs/remacs
         | 
         | Still in early stages, but I think that's one to keep an eye
         | on.
        
           | foobarbaz33 wrote:
           | The rust re-write is not intended to bring performance
           | benefits. Currently the Rust version is a massive downgrade
           | in performance relative to the C nativecomp branch.
        
           | jsilence wrote:
           | Most recent change is 7 months ago. I would not hold my
           | breath.
        
             | [deleted]
        
           | tsimionescu wrote:
           | I'd be much more interested in one of the CL rewrites, which
           | could (1) run all of the elisp as efficient compiled Common
           | Lisp, and (2) extend the customizability ot the deepest
           | layers of Emacs.
           | 
           | Unfortunately, most seem to be relatively dead from what I've
           | seen.
        
         | tharne wrote:
         | I prefer vim as an editor, but in terms of being a unique and
         | fascinating piece of software, emacs wins hands down. There's
         | something really cool about the fact that you can't easily
         | answer the question, "What is emacs similar to?", because it's
         | such a total sui generis.
        
           | luismbo wrote:
           | It's similar to a Lisp Machine.
        
             | agumonkey wrote:
             | Based on a few old mailing list it's apparently only very
             | slightly so, and i'm not dissing emacs, it's just that the
             | people who made lisp os and it's graphical layer really did
             | allow users to augment and interact with most of the system
             | in a very fluid and capable manner. Some examples from that
             | mailing list (thread from the 90s or maybe even 80s) were
             | still not present on a daily basis for code edition /
             | versionning in the 2000s. Makes you wonder
        
           | prewett wrote:
           | Viper mode could give you the best of both worlds, depending
           | on what you like about vim. If it's the key navigation, viper
           | has you covered.
        
             | NyxWulf wrote:
             | spacemacs has a very complete vim layer. By far it's the
             | most complete implementation outside of actual vim I've
             | seen.
        
               | Keyframe wrote:
               | I used emacs quite a lot, back in the day, and have
               | switched to vim for now.. well, too long. Thing with vim
               | is that I've never seen anyone using stock vim and keys,
               | there's this whole layer of plugins and custom key
               | bindings that make it so effective for any particular
               | user. Would that translate to spacemacs at all? I've only
               | glanced at it, but not sure if it supports Vim plug for
               | example.
        
               | jeremyjh wrote:
               | Stock Spacemacs is like a fully-tricked out Vim
               | configuration, made by and for "plugin" junkies. Its
               | leader-based keybindings are very well thought-out and
               | discoverable since you get a small menu for the level you
               | are at. For example <space> g gets you to the git
               | submenu, if you forget that <space> g s gets you magit-
               | status it will remind you there.
        
               | tharne wrote:
               | > Stock Spacemacs is like a fully-tricked out Vim
               | configuration, made by and for "plugin" junkies.
               | 
               | That is a fantastic description of Spacemacs
        
               | j4yav wrote:
               | Sincere question: if I already have a vim setup with all
               | the plugins I like, and I switch to evil mode so
               | everything more or less works as I had it, what does
               | emacs open the door to that I couldn't do before? Org
               | mode I imagine is one piece. Is there anything else I
               | should look at if I try it?
        
               | mapolone wrote:
               | There are a few IMHO: magit [1] is a nice piece for Git.
               | And there's vterm, if you wish to use a (usable) term or
               | tmux/screen without leaving the editor, tramp mode [2]
               | for remote files and last but not least ergoemacs [3] if
               | you prefer the CUA style for generic commands (and reduce
               | RSI). Oh, and forgot to mention helm [4] too...
               | 
               | [1] https://magit.vc
               | 
               | [2] https://www.emacswiki.org/emacs/TrampMode
               | 
               | [3] https://ergoemacs.github.io/
               | 
               | [4] https://github.com/emacs-helm/helm
        
               | acoard wrote:
               | Spacemacs is indeed great, I used it myself recently. But
               | I will say, it's no longer really actively maintained.
               | The community has migrated over to ~~Spacemacs~ Dooom
               | Emacs, which is very similar (still uses space as leader
               | key and vim bindings everywhere). In my experience, Doom
               | Emacs runs a lot faster too.
               | 
               | https://github.com/hlissner/doom-emacs
               | 
               | edit: Changeed Spacemacs to Doom Emacs, whoops.
        
               | comfydragon wrote:
               | > The community has migrated over to Spacemacs
               | 
               | I'm guessing you meant to say Doom Emacs there?
        
               | acoard wrote:
               | I did! Thank you for the correction. Editted.
        
               | dfinninger wrote:
               | Spacemacs uses "Evil mode"[1], which is available just as
               | a regular (MELPA) package. I started with Vim and so I've
               | always used evil. "Vanilla" emacs, spacemacs, now doom.
               | 
               | [1] https://github.com/emacs-evil/evil
        
               | iterati wrote:
               | I'm curious if you've already used evil with vanilla why
               | you'd migrate to spacemacs or doom. I've never found
               | either to add much that a custom config can't get to
               | easily and with more control. Maybe that's changed in the
               | past half-decade or so since I last tried Spacemacs,
               | though.
        
               | vvillena wrote:
               | The vim bindings are only one part of Spacemacs. The
               | other (and I'd say most important) part is the SPC menu
               | that exposes hundreds of keybindings in a discoverable,
               | unobtrusive, and interactive interface.
        
               | Klwohu wrote:
               | Isn't that also just an elpa / melpa package though?
        
               | vvillena wrote:
               | I guess so? And if the aim is to make something
               | completely custom, that's fine. But the Spacemacs
               | keybindings are very well thought out, the configuration
               | is just as important as the feature itself.
        
         | TeMPOraL wrote:
         | Definitely go for GccEmacs (feature/native-comp) branch if you
         | haven't yet. Despite being experimental, it's pretty much
         | stable. I've been running it for over half a year as a daily
         | driver, and seen zero issues (but much performance
         | improvements!). Similar stories abound on-line.
         | 
         | Wish something be done about proper threading support, but I
         | understand it's a herculean task at this point.
         | 
         | (For those unfamiliar, GccEmacs is a parallel branch of Emacs
         | that uses libgccjit to compile ELisp straight to native code.
         | It does it transparently - compiling in the background and then
         | substituting bytecode-compiled functions for native-compiled.)
        
           | chriswarbo wrote:
           | > Wish something be done about proper threading support, but
           | I understand it's a herculean task at this point.
           | 
           | I would agree about adding concurrency and parallelism; but
           | threading is very much a WorseIsBetter approach, which I
           | certainly wouldn't like to use directly.
           | 
           | Co-routines or futures would seem a better fit for Lispy
           | semantics. Actors seem too different and heavyweight, but I'd
           | still prefer them to threading!
        
             | taeric wrote:
             | I'm actually somewhat unclear in what the goals of
             | threading are, at times. Pushing a process out and having a
             | sentinel on a buffer has long been possible.
             | 
             | What is the aim?
        
               | TeMPOraL wrote:
               | Make it more light-weight and do it without needing a
               | foreign binary. If your elisp program needs to offload
               | some computations to a background thread, you don't want
               | to make a binary specifically for it - it would destroy
               | the flexibility and portability of otherwise perfectly
               | fine elisp code.
        
             | TeMPOraL wrote:
             | I said "threading" as a catch-all term. Whatever makes
             | Emacs able to fully utilize multiple cores of a CPU would
             | work.
        
         | taeric wrote:
         | I'm curious what sort of performance you are hit by. For me, it
         | is mainly org source buffers that I did not flag as async.
         | 
         | That and tramp not working too well over crappy internet. :(
        
           | Decabytes wrote:
           | I work in the medical field, which requires me to view large
           | xml files and multi patient csv files with years of patient
           | history. The CSVs contain embedded pdf strings that are long
           | strings of bytes in the file. Emacs struggles to copy and
           | paste, and move around in the large CSVs.
           | 
           | For the large XML files, I have to switch to fundamental
           | mode, because it struggles to highlight everything, and
           | sometimes the xmls are pure ass and are basically all on one
           | line. I've written a python script that will prettify the xml
           | because emacs locks up when I try to do that. My colleagues
           | just tell me to use sublime text.
        
             | taeric wrote:
             | Ah, yes. Long lines are known bad. I will be excited to see
             | anyone give a way to fix that with minimal impact on the
             | rest of the system.
             | 
             | I'm curious why other editors don't trip as badly on long
             | lines.
        
           | throwanem wrote:
           | Tramp works a lot more reliably if you customize where Emacs
           | puts your backups and autosaves, such that they're stored
           | locally instead of remotely. The Emacs wiki has details on
           | how to do that:
           | https://www.emacswiki.org/emacs/BackupDirectory
        
             | tsimionescu wrote:
             | The biggest problem I have with Tramp performance is much
             | deeper, the need to open a new connection for every request
             | - it makes integrating other modes with Tramp much more
             | difficult than I would hope for (e.g. I tried to make
             | kubernetes-mode work over tramp, and it mostly did, but
             | each refresh had to reconnect, which would freeze the whole
             | Emacs GUI for a second or so; thankfully kubel-mode has a
             | more complete implementation that handles this gracefully).
        
               | taeric wrote:
               | You still have this problem even with a control master
               | setup with ssh?
        
               | tptacek wrote:
               | This was problematic even with SSH multiplexing?
        
               | psanford wrote:
               | I've had this in my config for a long time. Seems to make
               | tramp work a lot better:                   ; use ssh
               | instead of scpx mode for tramp         ; this should work
               | a lot better with ssh connection sharing         (setq
               | tramp-default-method "ssh")
        
             | taeric wrote:
             | I can't and don't blame tramp, per se. My internet has
             | regular hiccups of being completely disconnected. Pretty
             | sure that is not fixable. :(
        
               | throwanem wrote:
               | Not by Emacs, but locally storing backups and autosaves
               | means it only matters when you're actively reading or
               | writing a file via Tramp.
        
               | taeric wrote:
               | Absolutely. It just sucks, as my build are so much faster
               | on the remote machine. :)
               | 
               | That is, a lot of my remote editing is not just idle
               | edits, but edit, run build, burn down compile output of
               | tests and other items I'm working.
               | 
               | If I really want hell, I'll try and run lsp remotely.
               | 
               | None of this would matter, if I hadn't built up so much
               | muscle memory from when I did have good internet and it
               | did just transparently work.
        
         | agumonkey wrote:
         | gccemacs works remarkably fine for such a big change, it does
         | bite my poor x201 hard on the compiling phase (we're now as
         | modern as lein clojure bootstrap :cough:) but it does bring
         | speed improvements already.
        
         | Smithalicious wrote:
         | I use pre-release Emacs with the nativecomp branch ("gccemacs")
         | and Doom. Starts in 2.1 seconds and it's blazing fast.
         | Definitely the best thing to come to Emacs for me in a long
         | time, very exciting.
         | 
         | I can't wait for it to hit release so everybody can play with
         | it!
        
           | whobar wrote:
           | Any warts when using it with Doom? I only recently switched
           | from vim to Doom, and I love it, but it can be a bit laggy
           | when using it with some of the C/C++ IDE features turned on.
        
             | Smithalicious wrote:
             | It works very well with Doom, Doom has support for it and
             | detects it's available and does everything for you. Just
             | compile Emacs and run doom upgrade as usual.
        
           | wiz21c wrote:
           | I have built gccemacs a week ago. I didn't see much
           | difference in speed and it breaks wanderlust... Are there
           | things to know to get the speed (and yes, I've checked it was
           | enabled during ./configure :-)) ?
        
           | newusertoday wrote:
           | are binaries available somewhere, i tried compiling it about
           | year ago but quit after struggling with few dependencies.
        
         | davidw wrote:
         | Going on 25 years with Emacs. Lots of other things I've changed
         | over the years, but still happy with Emacs and Postgres.
        
           | lovelyviking wrote:
           | I wish to use Emacs, but those keyboard shortcuts do not make
           | any sense for me.
           | 
           | Is there a way to have emacs with custom shortcuts as a
           | _ready package_ where I can modify those shortcuts before
           | digging in with all the rest.
           | 
           | I do not mind keyboard shortcuts in gneeral and use them all
           | the time, it's just those in Emacs are hard to learn/remember
           | knowing that I wish to change them anyway .
           | 
           | I am looking for the way to set those by myself but it seems
           | I need to learn _a lot_ before I can do it and thus it blocks
           | me from moving forward with exploring Emacs deeper.
        
             | TacticalCoder wrote:
             | > Is there a way to have emacs with custom shortcuts as a
             | ready package where I can modify those shortcuts before
             | digging in with all the rest.
             | 
             | I've got a very custom Emacs keybindings/shortcuts setup
             | but... Sadly it requires some hackery: basically there's
             | the whole major/minor modes shenanigan where one mode's
             | shortcut can take precedence over the other(s). And if you
             | want to define your own shortcuts which take precedence,
             | all the time, over everything else, you need to dig a bit
             | deep. And then even deeper because invariably there's this
             | or that minor mode you'll want to use where after all you
             | won't want your own shortcut but that one of the mode.
             | 
             | > I am looking for the way to set those by myself but it
             | seems I need to learn a lot before I can do it
             | 
             | Sadly this is true. I've got I'd say about 100 lines of
             | code related only to keybindings. Now, once set up, it's
             | pure bliss. For example I've got mod+{i,j,k,l} to move the
             | cursor around, anywhere (text, menus, anything). It makes
             | even more sense than vim's hjkl (ijkl mimics the cursor
             | arrow keys layout, which is more natural and ijkl is easier
             | to type than hjkl too).
             | 
             | > ... and thus it blocks me from moving forward with
             | exploring Emacs deeper.
             | 
             | I can understand that. I'd say the easiest would be to
             | define your own minor mode as explained here:
             | 
             | https://stackoverflow.com/questions/683425/globally-
             | override...
             | 
             | This should get you started: if you do it like in the
             | answer and make sure they always take precedence you should
             | be good to go and can deal with the gory details later on.
        
             | m1n1 wrote:
             | Well, if you already know vim keystrokes, just use
             | Spacemacs. The big win is easy discoverability: using the
             | space bar as a menu-starter, and when you find the command
             | you want, it tells you what key stroke you could have used
             | instead.
        
             | davidw wrote:
             | It's a good question, but asking someone who has used Emacs
             | for 25 years... I'm pretty happy with them, and indeed, do
             | my best to have them replicated in other software I use
             | such as shells and browsers.
        
       | rataata_jr wrote:
       | Anyone running the jit Emacs? Can't wait for it. I did try
       | compiling it from source for my linux setup. Would love to see it
       | on windows.
        
         | lsllc wrote:
         | Yes, it's pretty solid running Doom Emacs. There's a handy
         | macOS build script/helper:
         | 
         | https://github.com/jimeh/build-emacs-for-macos
         | 
         | The author curates a list of "known good" commits to the
         | feature/native-comp branch so you don't waste your time with
         | bad builds:
         | 
         | https://github.com/jimeh/build-emacs-for-macos/issues/6
        
         | hypersoar wrote:
         | I've been using it for a few months on wsl and it's been great.
         | I'm using the Nix package and have run into only a couple of
         | minor issues.
        
           | rataata_jr wrote:
           | That's a good idea, will finally try nix package manager on
           | windows.
        
         | bambataa wrote:
         | I've just tried it on macOS, built by this tool:
         | https://github.com/jimeh/build-emacs-for-macos
         | 
         | Unfortunately it keeps locking up my entire computer so might
         | not be a goer just yet.
        
         | rurban wrote:
         | Running the native-comp + wayland copr on fc32 for about a
         | year, whithout any problem. About 3x faster.
         | 
         | https://copr.fedorainfracloud.org/coprs/deathwish/emacs-pgtk...
        
         | TeMPOraL wrote:
         | Over half a year now, as a daily driver. Personally on Ubuntu,
         | at work on WSL (Windows Subsystem for Linux) - which I then
         | x-forward to an VcXsrv on Windows.
         | 
         | Works pretty much flawlessly, and it's much snappier on some of
         | the workloads I put it through - like big collections of big
         | Org Mode files, or viewing (and fontifying) large files.
        
         | iib wrote:
         | I have compiled straight from source on the feature/native-comp
         | branch, and it works noticeably much faster. I am actually
         | scared of going back to the regular Emacs, as I may find it way
         | too slow.
         | 
         | I am not sure how much it is from native Emacs, as when I did
         | this, I also enabled all the other recommended optimizations
         | from lsp (increasing the gc threshold early in the config,
         | installing and compiling with native json support etc.)
         | 
         | As far as I know, the latest branch has all the necessary flags
         | enabled, so you can just do                   ./autogen.sh &&
         | ./configure --with-nativecomp --with-xwidgets --with-json &&
         | make -j4 && make install
         | 
         | after you installed the dependencies and cloned the Emacs repo
         | (--with-nativecomp may actually be set to default now in this
         | branch). You also need a very recent version of gcc, as the
         | libgccjit is somewhat new, and it may err on the compilation
         | process.
        
           | taeric wrote:
           | I also enable march=native for the compile. My guess is it is
           | mostly placebo, but I feel it helps.
        
             | iib wrote:
             | I only know of this discussion[1] on Daniel Lemire's blog
             | regarding -march=native, which seems to have the "it's
             | complicated" conclusion. But yes, _theoretically_ that is a
             | way to compile for better performance, for your own
             | machine.
             | 
             | [1] https://lemire.me/blog/2018/07/25/it-is-more-
             | complicated-tha...
        
               | taeric wrote:
               | Yeah, "complicated" sums it up perfectly. I know it
               | /should/ be faster. And, it does feel so. But, I don't
               | have hard data to prove it, such that I have to ack it
               | could just be placebo.
        
           | indy wrote:
           | It looks like the configure option has been renamed to
           | --with-native-compilation
           | 
           | on the feature/native-comp branch (and it has to be specified
           | otherwise it defaults to no)
        
         | prussian wrote:
         | I am. I honestly don't notice much of a difference, but at the
         | same time I keep seeing deferred compilation warnings for
         | plugins I have added via straight.el
         | 
         | I've been using https://github.com/flatwhatson/guix-channel to
         | manage it. I don't recommend trying the Pure GTK+ stuff yet
         | though; some context menus don't seem to work. Specifically,
         | treemacs rename seems broken with PGTK.
        
         | TacticalCoder wrote:
         | > Anyone running the jit Emacs?
         | 
         | I'm running the "native-comp" (libgccjit) branch daily since
         | months and months now: not a single problem here and I've got
         | quite a "heavy" config (thousands of lines of custom config and
         | all the usual suspects: magit / org-mode / lsp / cider etc.).
         | 
         | > I did try compiling it from source for my linux setup.
         | 
         | And it worked? Worked on the first try for me (on the Debian
         | distro).
         | 
         | I was somehow expecting lots of problems (because it's one heck
         | of a change) but it really all just compiled and worked
         | perfectly fine.
        
           | rataata_jr wrote:
           | I followed this tutorial from mastering emacs blog iirc. I
           | built it inside docker. I think it worked on the first try
           | for me as well. I didn't use it much since it was in docker.
        
           | voodoologic wrote:
           | I found an easy installer for native-comp (for mac os).
           | https://github.com/d12frosted/homebrew-emacs-plus I'm new to
           | emacs and so I am unaware how much faster it is or isn't.
        
       | brightball wrote:
       | I tried Emacs after reading so much about it lately...but I don't
       | understand how people use it. The sheer volume of key
       | combinations always in play to do things makes my hands hurt.
       | 
       | It made me see the appeal of some of those concave keyboards.
        
         | neolog wrote:
         | Many people find it helpful to swap ctrl with capslock.
        
         | widdershins wrote:
         | I'm just getting into Emacs (~4 months) and I'd say that I have
         | probably ~40 key-commands memorized. I M-x search for
         | everything else and I still find it to be an excellent
         | experience. I'm building my config and muscle memory very
         | slowly, but enjoying every minute.
        
         | DocTomoe wrote:
         | That's me, two years ago, when I made the switch from vi.
         | 
         | In the end, the key combinations are something to learn - but
         | the productivity increase makes them worth learning. And for
         | the handcramp thing: Realize that you have two control, and two
         | meta keys on a standard keyboard.
        
       | wyuenho wrote:
       | and... flickering is back on the NS port.
        
         | abzug wrote:
         | Alan Third (the NS maintainer) said on reddit that "It's too
         | big and invasive a change for Emacs 27."[1]
         | 
         | [1]:
         | https://old.reddit.com/r/emacs/comments/mc82yk/flickering_em...
        
           | wyuenho wrote:
           | Too bad. I wish they could just stop breaking things.
        
             | abzug wrote:
             | It's fixed on HEAD if you don't care about running from
             | trunk. Otherwise, I suggest you to use Mitsuharu Yamamoto's
             | Mac Port: https://bitbucket.org/mituharu/emacs-mac
        
       ___________________________________________________________________
       (page generated 2021-03-25 23:02 UTC)