[HN Gopher] Making Emacs Popular Again (2020)
___________________________________________________________________
Making Emacs Popular Again (2020)
Author : draven
Score : 199 points
Date : 2021-11-04 09:33 UTC (13 hours ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| jstx1 wrote:
| To be more popular Emacs needs to be easier to get started with
| and easier to extend. If I have to read a whole book or learn an
| entire new programming language, I'm not going to put the time
| in. If any time I search for "how to do x", I get a disjointed
| mess of "but spacemacs...", "in prelude...", "this custom elisp
| snippet..." where every piece of advice can be potentially
| incompatible with any past or future modification that I've done
| - then the effort and frustration doesn't seem worth for a text
| editor / org tool.
| cpach wrote:
| When I set out to learn Emacs in the year ~2001 or so, I just
| did _C-h t_ in order to launch the builtin tutorial. IMHO that
| can still be a viable way to get started.
|
| Spacemacs might be nice but it's in no way required in order to
| be productive with Emacs. My personal .emacs file is only 32
| lines long (28 lines of comments are not counted).
| deworms wrote:
| If you need a dedicated tutorial for a text editor it's a
| great sign that something is very wrong with its design,
| particularly concerning discoverability.
|
| Emacs has no user-friendly command names (you need to
| memorize function names which are often meaningless
| abbreviations), no autocomplete, and doesn't show available
| functions.
| jsilence wrote:
| Maybe helm (https://emacs-helm.github.io/helm/) should be
| installed and preconfigured by default.
|
| This solves a lot of the shortcomings of vanilla emacs.
| NoGravitas wrote:
| Helm is a little heavy-weight. Ivy is lighter, but also
| does a lot of NIH stuff it doesn't need to. I personally
| like selectrum, (https://github.com/raxod502/selectrum)
| because it provides the features of Ivy and quite a bit
| of extensibility, while still only using the built-in
| extension points in emacs (completing-read-function,
| etc.). I do wish the emacs developers would bless
| _something_ and include and configure it by default,
| though.
| b3morales wrote:
| There's a new builtin icomplete-vertical mode in Emacs
| 28, but I assume that like so many defaults, switching is
| deemed socially infeasible, so we are stuck turning it on
| ourselves.
| rich_sasha wrote:
| Vim has a built-in tutorial too. As said elsewhere, you
| literally cannot get started in Vim without knowing a dozen
| command and grokking modes, in Emacs you can at least
| stumble around without knowing anything.
|
| Equally, there's a difference in target audience. Do you
| need a tutorial to operate a screwdriver? No. Power drill?
| Arguably yes. CNC mill? Dear God please yes. I don't think
| you expect a fork lift or nail gun to be accessible with
| zero runway by anyone, or for their features to be
| discoverable by trial-and-error.
|
| You could argue that this is not a worthwhile niche, and
| maybe that's right (at least for you and like-minded
| people) but it's just what it is.
| Zababa wrote:
| > As said elsewhere, you literally cannot get started in
| Vim without knowing a dozen command and grokking modes
|
| You need i, escape, :w! and !wq. hjkl too if you're
| feeling fancy. But i, escape, :w! and !wq is all you need
| to use Vim. I know because I used it like that for two
| years in college.
| vidarh wrote:
| Ctrl-z followed by killall -9 vim is how I usually exited
| vim.
|
| I once pissed off dozens of customers by symlinking vim
| to emacs on one of our shell servers (back when isps gave
| you login access to a Linux/Unix box...
|
| (Yes, it wasn't very nice, but it was funny)
| underatree wrote:
| > Emacs has [...] no autocomplete, and doesn't show
| available functions
|
| My impression is that you are not familiar with Emacs.
| deworms wrote:
| I have been using emacs for 7 years prior to switching to
| VS Code. Never looked back. It's better in all regards.
| d0mine wrote:
| Could name a single specific feature that somebody who
| uses emacs for years is missing? (perhaps, a link to a
| video if it is hard to describe concisely would be
| useful)
|
| I've tried recently to steal some features from VS Code
| but nothing fundamental came up. I've discovered the
| gitlens' git-blame overlay feature but it is cosmetics (I
| use magit-blame). btw, the feature is available as blamer
| emacs package (just add the corresponding (use-package)
| elegant declaration to your .emacs).
|
| I use tramp to run remote commands using Org-babel all of
| the time. Obviously, emacs can edit remote files just
| fine too. What am I missing?
| underatree wrote:
| Sorry for misunderstanding. I see now that you meant
| autocompletion like LSP (rather than M-x minibuffer
| completion). Emacs could benefit from built-in LSP, I
| agree.
|
| Emacs-devel are keen for it, and eglot.el is a good
| contender for inclusion.
| alex_smart wrote:
| You used emacs for 7 years without learning that it very
| much has auto-completion, you can see available functions
| with fuzzy matching, and that you can easily alias any
| function to any name or key-binding you want instead of
| memorizing it?
|
| :-O
| 2pEXgD0fZ5cF wrote:
| > I have been using emacs for 7 years prior to switching
| to VS Code.
|
| Based on what you've been claiming I doubt that.
| cpach wrote:
| Emacs was founded in the 1970s. There is a lot of legacy in
| there, but IMHO it still holds up as a very powerful and
| nice text editor.
|
| _"If you need a dedicated tutorial for a text editor it 's
| a great sign that something is very wrong with its design,
| particularly concerning discoverability."_
|
| I don't agree. If it was a mass-market product for users
| who just wants something convenient, then I would agree.
| Those users are probably better served by other
| applications. (Word, Evernote, OneNote, Notepad++ etc etc)
| But Emacs is a power tool for power user. Therefore I think
| it's okay that it needs a tutorial to get started. You need
| to invest some time to learn in. That will, in my
| experience, pay off greatly in the long run.
|
| Let's take an example from another domain:
|
| Suppose someone wants to get started with 3D Graphics. I'm
| pretty sure software like Blender and Maya also needs some
| kind of tutorial in order to be useful.
| deworms wrote:
| There already exists better power tools for power users,
| that are easy to use and easy to customize, yet still
| more powerful than Emacs. It's a common misconception
| that if it's arbitrarily hard to understand, it must be
| something for power users. Bad design is not a feature.
| NoGravitas wrote:
| "No autocomplete" and "doesn't show available functions"
| are a matter of bad defaults, rather than lack of
| capability. There are great packages for them available,
| but even in core, there are OK options (ido-mode). I do
| wish that the core team would "bless" great packages and
| work towards bringing them into core and into the defaults.
| b3morales wrote:
| FSF copyright assignment is a stumbling block here in my
| opinion.
| nverno wrote:
| You need dedicated tutorials, or equivalents, for all
| complicated tools and machinery. The power of Emacs (with
| respect to text editing capabilities) comes from mastering,
| by committing to muscle memory, a large number of key
| sequences. There's no easy way to do this- it takes time
| and effort (100% worth the payoff imo).
| deworms wrote:
| That's some kind of protestant work ethic. It doesn't
| need to require days of busywork to be powerful. VS Code
| is more powerful, easier to configure, and more
| productive out of the box. The default feature VS Code
| offers make hundreds of lines of Emacs configs with
| dozens of custom plugins look laughable. Tramp mode is
| pure trash compared to remote editing in vs code. Stuff
| like syntax highlighting, intellisense, git integration,
| and other useful features are years ahead of Emacs too.
| Every language, including C, is supported better.
| nverno wrote:
| Yes, it takes work, it's like learning how to dance,
| draw, or paint. My emacs config is literally 64183 lines
| of elisp + 2356 snippets (just checked), so I'm not
| really considering a major editor switch at this point.
|
| I've used VS code as well, it's fine for what it does and
| certainly much more beginner friendly.
| deworms wrote:
| Imagine what you could have accomplished if you didn't
| have to spend all that time writing an entire large
| codebase just to make it usable. It's a false assumption
| that it should require pointless busywork to be useful.
| You're never getting back the time you've wasted on
| writing a config for an obsolete editor.
| Zababa wrote:
| > Imagine what you could have accomplished if you didn't
| have to spend all that time writing an entire large
| codebase just to make it usable. It's a false assumption
| that it should require pointless busywork to be useful.
| You're never getting back the time you've wasted on
| writing a config for an obsolete editor.
|
| Isn't this precisely the kind of "protestant work ethic"
| that you mentioned just before? If someone enjoys writing
| ELisp for Emacs, what's wrong with writing 61k lines of
| it?
| nverno wrote:
| I love writing elisp, obviously! It wasn't some drudgery
| for me, it was the whole reason I even got into coding
| (from using R in emacs) in the first place.
|
| I got into a habit (obsession?) of automating as much as
| possible everything I repetitively do on a computer by
| writing elisp. It's essentially my operating system.
| kristjansson wrote:
| ESS is truly a gateway drug.
| underatree wrote:
| I'm keen to hear more about VS Code's remote editing
| strengths over TRAMP.
|
| What is it in particular?
|
| I see some UI operations block on TRAMP operations which
| is laggy and annoying.
| gaganyaan wrote:
| This is kind of an odd attitude. I haven't used VS Code,
| but I have used PyCharm extensively before. There's a) so
| many buttons everywhere, with hovertext that doesn't help
| unless you already know what you're doing, and b) so many
| things buried in random configuration screens.
|
| I recently started using Doom Emacs and really like it.
| There's a learning curve, but in contrast to what you're
| asserting, every other IDE has at least a similar learning
| curve. Unless by "text editor" you mean no IDEs, but then
| VS Code is out too, and I'm not sure what we're talking
| about.
| salamandersauce wrote:
| Emacs has user friendly command names, functions in Emacs
| have a full command name. Can you guess what "comment-
| region" does? That's right it comments out the currently
| selected region. Or "switch-to-buffer"? That's right, it's
| used to switch buffers. Obviously if you use these things
| regularly typing all that gets tedious so you can use
| keyboard shortcuts like C-x-b to switch buffers instead.
| Sometimes these have relation to the command they call but
| sometimes they don't, but neither does something like
| Ctrl-Z (What does Z have to do with undo?).
|
| Emacs doesn't have autocomplete built in but it does have
| tab completion and if you press tab it will show you
| possible functions that start with what you typed if there
| is more than 1 option available.
|
| I think most of the trouble people have with Emacs is that
| it doesn't use standard terminology or conventions mainly
| do to its age. There is nothing more discoverable about
| Ctrl-Z vs. Ctrl-/ other than that Ctrl-Z became the defacto
| standard. If you took two novice computer users that have
| never used a computer in their life I think they would have
| just as much trouble with VS code as Emacs.
| rvieira wrote:
| I think Spacemacs helps with getting started.
|
| For a newcomer there is a "curse of Emacs", helm? ivy? ido?
| Wnat to do Python? elpy, lsp, etc
|
| It's easy to get confused and just give up. Having a curated
| config like Spacemacs helps to get it working out of the box
| IMO.
| tharne wrote:
| Doom Emacs is very good in this regard too. Without Doom and
| its sane defaults, I certainly would have given up on emacs.
| rnkn wrote:
| No! Emacs _does not_ require the user to learn any code in
| order to use it.
|
| Unfortunately this is a persistent false narrative to which
| many new users fall victim (as I believe you have). I maintain
| several packages aimed at non-coding writers. I put a lot of
| effort into ensuring that writers never need to write or
| understand any code in order to get writing.
|
| Emacs has a built-in user-friendly options UI system that
| provides documentation on every option and its available
| settings, and provides input error checking. All options are
| organised hierarchically, or you can search for any options
| matching a string.
|
| But, there are a lot of programmers out with a desperate need
| to appear clever. Using the options UI is an affront to their
| cleverness, so they insist that writing code is the only way.
| It keeps them feeling clever and it perpetuates this idea that
| the only way to use Emacs is by learning how to manipulate its
| internal code.
|
| So we have people sharing their overly complex configuration
| files. And worse, these horrible "starker kits" that obfuscate
| the extensive in-built help, and further abstract the program
| away from the user.
|
| Ignore anyone pushing any of those "starter kits". Ignore
| anyone who says "just paste this code into your init". They're
| only trying to appear clever. Anyone trying to appear clever
| usually isn't.
|
| Edit: here's a video where I set up Emacs from scratch to a
| full-featured screenwriting program, without a single bit of
| code: https://www.youtube.com/watch?v=Be1hE_pQL4w
| hollerith wrote:
| This is the first time in my 29 years of Emacs use that it
| has occurred to me that someone out there might like M-x
| customize enough to hold it up as a pro-Emacs argument.
|
| I use it very occasionally in order to discover the name of
| one of Emacs's thousands of user options, which option I then
| manipulate with Emacs Lisp code added to a file. I much
| preferred the (recently completely removed from Gnu Emacs
| after 2 decades of being marked as deprecated) vastly simpler
| list-options command for doing that.
|
| For me, easy modification of one's personal software
| environment by adding Emacs Lisp code to files is _the_
| central argument for Emacs and cancels out the negatives such
| as the fact that, e.g., C-z does not undo the latest editing
| action.
|
| One of benefits of online discussion of things like editors
| and programming languages is that it is a constant reminder
| of the largeness of the diversity in cognitive styles and
| preferences among people.
| NoGravitas wrote:
| I'm actually in-between on this. What I normally do is
| write short bits of code (generally `use-package' forms) to
| install and load packages and set options that are
| essential to the operation of the package, are not private
| information, and don't vary between my different machines.
| Then I use `customize-group' to set any remaining options.
|
| Customize could stand improvement in terms of widgets and
| layout, but it's not _bad_. Other than a coat of paint, it
| 's pretty similar to VS Code's preferences interface.
| hollerith wrote:
| I agree that M-x customize is not horrible at what it
| does.
|
| On reflection, what inspired me to chime in on this
| thread is amazement that there exists at least one person
| who is enthusiastic about the fact that Emacs has
| thousands of customizable settings. (M-x customize exists
| solely to make persistent and ephemeral changes to those
| settings.)
| omnicognate wrote:
| At least two. The vast range of customizable settings is
| one of the main selling points of emacs for me, and I
| find M-x customize a very pleasant way to discover and
| tweak them
|
| Anyway brb, I'm off to customize how EXWM assigns
| workspaces to monitors when I plug my laptop into the
| docking station.
| underatree wrote:
| I'm a daily Emacs user, and happily use a 100 line init.el,
| mostly composed of "enable this mode".
|
| Emacs supports customization needs to the nth degree, but I've
| found that this is a false economyy.
|
| I agree Emacs needs to be easier to get started with.
| deworms wrote:
| You would probably be more productive in VS Code with an
| empty config.
| BeetleB wrote:
| > You would probably be more productive in VS Code with an
| empty config.
|
| Org mode is the main productivity multiplier. How do I do
| that in VS Code?
|
| Any time I read a comment where VSCode is the obvious
| alternative to Emacs, it's a clear sign the commenter knows
| little of Emacs.
|
| Take a look at last year's EmacsConf and count how many of
| the talks are about SW development (hint - minority). A
| very large number of Emacs users do not use it for SW
| development, and stating they'd be more productive in VS
| Code is simply false.
| bmitc wrote:
| I took a look at the EmacsConf talks and didn't see
| anything in particular that stood out. Mind pointing
| something out?
|
| At the end of the day, Emacs and VSCode are extensible
| environments and editors, so there's gonna be a lot of
| overlap and some fringe cases that are only possible on
| either one.
|
| But VSCode is definitely the more immediate of the two. I
| can install VSCode, sign in with my GitHub account, and
| immediately have my exact same environment as on any
| other machine. Any change I make to my environment, such
| as keybindings or installed extensions gets synced to
| other installations. I can remote into other computers
| and again have my same environment, developing as if I
| was on that computer itself. If I see a colleague with a
| certain behavior, all I usually have to do with VSCode is
| ask what extension it is, install it, and then I get the
| same behavior without any configuration (with Emacs,
| everyone has their own little custom environment). I
| don't ever need to be writing Emacs Lisp just to use the
| environment as I would expect to. You simply cannot do
| all of this with Emacs with the same usability and
| immediacy. And this alone is why I use VSCode.
|
| I have tried getting into Emacs. At one point, I was on
| Windows and needed to run MIT Scheme, which doesn't
| really work on Windows, so I installed and ran MIT Scheme
| on Windows Subsystem for Linux (WSL). Through some
| configuration of my .emacs file I was able to get things
| up and running by using Emacs on Windows and then calling
| into WSL and Scheme (this is before the days of official
| GUI support in WSL). It didn't really work in the end,
| despite all the hackery, one reason being Emacs' terminal
| is its own little custom thing. So I install VSCode,
| install the Remote - SSH extension, and I was off and
| running within minutes developing in a Windows GUI with
| code running on Linux, as if I was just on the Linux
| machine. So I never looked back. Any experiment of mine
| for Emacs meant I spent all this time trying to configure
| the editor to do what I'd expect rather than doing what I
| actually wanted to do. With VSCode, I have found that I
| rarely spend time needing to bend it to my will. It
| basically does what I need, and if not, there's
| extensions or simple configurations that accomplish it.
| I'm almost always working _in_ VSCode and not working
| _on_ VSCode.
|
| > Any time I read a comment where VSCode is the obvious
| alternative to Emacs, it's a clear sign the commenter
| knows little of Emacs.
|
| This is also why people stay away from Emacs.
| BeetleB wrote:
| > I took a look at the EmacsConf talks and didn't see
| anything in particular that stood out. Mind pointing
| something out?
|
| That most of the talks are not relevant for SW
| Development, and VSCode is likely not the correct thing
| to point existing Emacs users to. Looking at the talks
| from last year, is VSCode good for:
|
| - Writing novels
|
| - Produce sheet music
|
| - Editing audio files' metadata and tying it to producing
| a web site.
|
| - All things Org mode
|
| - Roam-like wiki
|
| - Gaming
|
| - Creating fonts support for native American languages
|
| - Reading mail/newsgroups
|
| - Using it as a computer algebra system
|
| - Interacting with external programs like the browser
|
| Note: I do 3-4 of the above regularly.
|
| I honestly have not checked if VSCode can do these things
| - will be happy to be informed.
| 2pEXgD0fZ5cF wrote:
| Can you elaborate with examples from both emacs and VSCode
| on why you believe that to be the case?
| rich_sasha wrote:
| Emacs fits so nicely into my workflow. I can use it,
| feature-rich, from terminal, within tmux, and easily
| switching from the editor (where I _write_ code) to other
| terminal panes (where I _run_ the code). I can also use
| Emacs without any mouse input at all, have a rich set of
| keyboard shortcuts, and where I find myself doing something
| repetitive, I can easily automate it. While I 'm at it, I
| can use the very same environment for a ton of other things
| - note-taking, editing more file types than I could care
| about etc.
|
| I can see that with different priorities, perhaps VS Code
| might be a better fit. But does it work in the terminal?
| Can I edit LaTeX and have equations rendered in-place? Can
| I easily switch layouts from having 3/4 panes of code _and
| nothing else_ on the screen, to having various other bits
| around? Does C &P trivially support multiple "buffers"
| (registers in Emacs lingo; can copy & paste persistently to
| different places). Can I easily record rich keyboard macros
| - ones that, dunno, search second and third word on a line,
| replace first instance of _second word_ with _third word_ ,
| then return to the starting point?
|
| I suspect the answer is yes to some of these questions, but
| no to most. And this is barely scratching the surface of
| what Emacs can do.
| underatree wrote:
| I think I would be more productive with VS Code too.
|
| But productivity isn't my only goal.
|
| I want to give back to the community: Emacs is
| introspectable enough that it allows me to easily
| contribute.
|
| I want to explore a different UI paradigm, which blurs the
| line between user and developer.
|
| I want to support a grassroots developed editor.
| johnisgood wrote:
| I never had to read a book to use emacs well. Same with vim,
| VSCodium, and IntelliJ.
|
| Sometimes I ssh into a machine that has only vim installed, so
| I use vim. Sometimes it is faster to open a file using vim, so
| I use vim. If I expect to spend a lot of time editing it, then
| emacs.
|
| Currently I am using IntelliJ for a Java/Kotlin project.
| lgrapenthin wrote:
| Just because it is expensive to learn Emacs doesn't meant that
| it isn't worth it. Fine, you aren't "going to put the time in".
| But what do you get then? A mess of programs and plugins that
| need to be replaced, rewritten or reconfigured all the time,
| and its not even close compared to a well managed Emacs setup.
| [deleted]
| [deleted]
| agumonkey wrote:
| If you find emacs hard to extend then i hope you never use
| eclipse, more on that later.
|
| Part of the problem you raise kinda comes from the newfound
| popularity of emacs, people started more projects on top of
| emacs and now we have a paradox of choice.
|
| That said emacs core is pretty stable, even though there an
| acceleration in new ideas there too, it's not breakage
| inducing.
|
| About ease of extension, in emacs you can add functions, menus,
| buttons, libs in 15 seconds. That's less time than it takes
| Eclipse to "create" an empty plugin project.
|
| emacs is not the easiest (or the neatest or any -est) but
| relatively speaking, it's still a good thing.
| rgoulter wrote:
| Emacs would benefit from being easier to get started with? Yes.
|
| Emacs is held back by not being easy enough to extend, because
| it uses Emacs Lisp? I don't see how. I'd expect learning to
| write plugins for some application to be harder than figuring
| out enough syntax/semantics of a language to call library
| functions.
| rbanffy wrote:
| The fact extensions in other editors are written in Java or
| TypeScript do not make it any easier to write them.
|
| In any case, learning Lisp is useful, even if you never write
| an Emacs plugin.
| commandlinefan wrote:
| > If I have to read a whole book or learn an entire new
| programming language, I'm not going to put the time in.
|
| If I actually believe that the time will be well spent, I'm
| willing to spend it. Having gone through the effort of learning
| emacs (yes, reading a whole book about it) and forcing myself
| to use it as my primary editor for a year, I have to say... I
| don't think it was time well spent. vi, however, was. It was
| (at least) as hard to learn initially as emacs was, but for
| most text-editing tasks, it's still a _lot_ faster than any GUI
| editor both to start up as well as to actually perform text
| editing tasks. Plus, it 's _always_ there, no matter how many
| jump boxes you 've ssh'ed through.
| randomstring wrote:
| I've been using emacs as my primary editor since 1989. It has for
| that entire time been a PITA to configure. My first customization
| was to map backspace to ^H and map the insert key to 'nil.
|
| I used to dedicate a couple days every January to investigate new
| emacs tools. Read about the latest features or new modes, often
| from my org-mode TODO list where I bookmarked them. I have
| learned to never update emacs mid-project as I've on multiple
| occasions shattered my emacs config updating versions or moving
| to a new distros. MacOS brew install vs .dmg install? Aquaemacs?
| DoomEmacs? Oh, hello the malpa repo URL changed and is https only
| now.
|
| "eldoc" error wrong-type-argument stringp number-or-marker-p
|
| Googling that doesn't get you anywhere.
|
| VSCode has a healthy extension marketplace, something emacs
| should adopt.
|
| elisp is dead. Not because it is dead, or deserves to be dead,
| but because everyone "believes" it dead. Same goes for Perl.
|
| I love emacs, it has been a rock my entire programming life, but
| it's a time suck to configure. I know there are some who have
| created a Sistine Chapel in their .emacs.d, and I'm jealous.
| There's a fine balance between spending time and effort
| optimizing and sharpening your tools and emacs is deep on the
| wrong side of the line for me.
|
| I don't want emacs to ever die. But come on, if you're losing to
| vim in popularity, you are already dead.
| butterisgood wrote:
| > elisp is dead
|
| I guess I'm a necromancer.
|
| I'm ok with this.
| akagr wrote:
| > elisp is dead
|
| I'm not sure it was ever alive to begin with. Not in the
| classical sense. I mean, I don't think elisp ever got good (or
| any) use outside of emacs configuration and extension. There
| weren't any popular web frameworks, numerical libraries etc.
| written in elisp.
|
| Inside its target space, though, it seems as vibrant as ever.
| New, helpful packages keep appearing that are written in elisp.
| For better or worse, the extension ecosystem is not nearly as
| fragmented as some other editors.
|
| That's not to say that elisp doesn't need serious improvements,
| though. Making it natively multi threaded alone will advance
| the story quite a bit imo.
| rbanffy wrote:
| > VSCode has a healthy extension marketplace, something emacs
| should adopt.
|
| What's wrong with MELPA?
| tarboreus wrote:
| Yeah, MELPA is solid. Great, even.
| jeromenerf wrote:
| > There is a balance between ...
|
| Common mistake. The problem is procrastination and bike
| shedding, not emacs. It's because some people love their tools,
| sometimes more than the craft. It's the same with cars,
| photography and woodworking. Maybe because hacking emacs lisp,
| supercharging a Miata, retro-fitting lenses or Tuning a pre-war
| Stanley handplane feels as good as using them.
| Arubis wrote:
| I understand why there's all this concern about making Emacs
| popular--as software professionals, we've all seen a few tools
| that we use and love wither at the vine and die slow deaths. But
| the concern for _overall_ popularity is a little misplaced.
| There's more developers than ever, and the pie continues to grow;
| Emacs just needs a sufficient total userbase to stay maintained,
| and that seems already to be in place.
|
| The greatest threat to Emacs, as to any other fairly well-liked
| open-source editor, is a paradigm change in how software gets
| built or run, not whether it has 7% or 9% mindshare.
| deltarholamda wrote:
| I agree with this. I used emacs in the late 90s through early
| 00s, and it worked great. I pretty much stick with BBEdit these
| days, because it works great for my personal workflow. I never
| got into vim: I only learned enough of it to edit config files
| and the like when I shell into a computer.
|
| The modern paradigm of running
| npm/brew/composer/webpack/whatever gimcrack tool that gets
| shoehorned into the build process has led a lot of people to
| the VSCode-ish side of things that make integrating these
| things easy. emacs tends to look like a well-appointed workshop
| with lots of good, sharp tools and a stack of raw lumber,
| whereas VSCode looks like a finished Chesterfield. It takes a
| certain sort of person to prefer the workshop over the finished
| piece, and I'm not sure you could ever change that.
| Azsy wrote:
| I was nodding along with the first paragraph. But then,
|
| > The greatest threat to Emacs, [..] is a paradigm change in
| how software gets built or run
|
| Is a little to far into scify land.
|
| First it requires software to no longer be text based, and then
| it requires virtually all software to switch to this non-text
| based solution.
|
| In that world a single user can keep Emacs up to date and
| compatible by asking our AI overlords to do it.
| heyparkerj wrote:
| I see where you're going - but I've personally noticed that
| there are a lot of things coming along with these cloud
| infrastructure paradigms that have made me feel like my
| localhost text editing workflows are going to make me look
| and feel even more like an absolute dinosaur as time goes on.
| I can't speak eloquently on this as I'm still an amateur to
| these cloud infra configuration concepts and their real
| limitations on how I'm used to thinking about application
| development, but I hope this comment sparks some inspiration
| for someone else to do so.
| lpcvoid wrote:
| Don't think of it as you being a dinosaur - think of it as
| you being a sane person making sane decisions about your
| development environment.
| lgrialn wrote:
| I fully expected there would be a fair amount of discussion of
| RSI here.
| amosj wrote:
| Emacs groks my soul. I can't defend it's flaws. But if I'm reborn
| a developer in a thousand years I sure hope it will still be
| around. Otherwise I'd rather be a shrimp or a dolphin or
| something (I hope those will be around too)
| anonuser123456 wrote:
| I've been an emacs user for 10 years. Before that, vi for another
| 10.
|
| This year I switched to VSCode and I will probably not go back.
|
| I like emacs, but the modes I depend on are just too brittle, and
| there is no easy way to discover that your old favorite mode for
| some particular feature set has been surpassed by a new one in
| popularity. VS Code plug-in search gives you ranked options.
|
| Also, there is something to be said for having everyone on your
| team / company on the same editor; you get economies of scale
| w.r.t. setting and configurations. As someone that personally
| invests in tooling, it's nice to then be able to scale that
| tooling out to 50 people and have everyone get the benefits.
|
| I can't do that with emacs, because the learning curve is too
| steep. But I've been able to switch dozens of people with VSCode.
| edgyquant wrote:
| I was a vi user for a decade also and decided to try vscode and
| never looked back. I'm really not sure what it is about it but
| i just don't fight with it. Since then I've also switched to
| PyCharm for python editing
| joebergeron wrote:
| Preface: I have been using Emacs as my only editor for over ten
| years.
|
| This article is at once extremely funny to me and extremely
| frustrating.
|
| Funny, in that it reads like a tabloid magazine article from an
| alternate reality where the goings-on of our savior RMS is the
| hottest gossip available, and Emacs is the topic _du jour_.
|
| Frustrating, from what I perceive to be an impenetrable thickness
| from RMS and RMS-adjacent Linux contributors/Emacs users. People
| who use text editors just don't care. (not to imply that they
| _ought_ to care.) It 's not just that Emacs, as it tends to ship,
| is extraordinarily ugly. It's not just that Emacs is difficult to
| master, or that it requires knowledge of Lisp to be meaningfully
| configurable, or that it isn't friendly to new users. It's all of
| this and many more.
|
| People use VS Code and Sublime Text and Atom and $EDITOR because
| they're simple on the surface, they're easy to install (you just
| download it and go), don't need heaps of customization to become
| useful, don't force the user into learning a completely new set
| of metaphors, etc. etc. The average developer just wants to write
| some code.
|
| This quote got it the most right: > [...] no
| Microsoft word user has ever considered themselves to have opened
| a "buffer". They open "files". They move "windows" around, not
| "frames." They cut and paste not kill and yank, etc.
|
| As long as core usage of the basic functionality of the software
| demands users learn a totally new set of concepts, develop new
| mental models, and develop intuition for new design metaphors,
| Emacs isn't going to win over (m)any new users. It doesn't matter
| how much Emacs users try to evangelize (what ends up amounting
| to,) their system of beliefs, or attempt to proselytize their
| design as "best", or most well-reasoned. Unless Emacs ditches its
| fundamental philosophy that it ought not to "baby" the user by
| natively offering familiar and welcoming design patterns and a
| de-facto feature set that people living in this century expect by
| default, I don't see Emacs gaining meaningful share.
|
| People use the alternatives because they simply don't care about
| the things that Emacs contributors care about. If, down the road,
| they end up caring, those alternatives do indeed offer plenty of
| reward for those who take the time to learn; it's just that with
| the alternatives, the ceiling is presumably much lower than for
| Emacs. On the other hand, the floor is much higher. With Emacs,
| the floor is somewhere around the molten core of the Earth.
|
| Meanwhile, you have Emacs core contributors quibbling about
| rounding edges and custom icons; unable to come to a consensus
| about all manner of trivialities, when what they really need is a
| seismic shift in core philosophy. It reeks of impending
| irrelevancy and a gives profound sense that Emacs is deeply out
| of touch with what the average person wants, as far as their
| mission of _actually getting people to use the product_ goes.
| TacticalCoder wrote:
| If anything I see more love for Emacs over the years, not less.
| From Spacemacs to DoomEmacs to all the vim users switching to
| Emacs+evil-mode. There's LSP support since a while too.
|
| The Emacs ecosystem is alive and very well. It's in much better
| shape than it used to be.
|
| I used to live inside JetBrains' IntelliJ IDE, starting at
| IntelliJ version 4 (yup, I'm that old) and I'd probably use
| IntelliJ again if I was forced to work in a nonsensical Java
| codebase, full of boilerplate, impossible to navigate because it
| became a gigantic mess of spaghetti code. But that is my vision
| of hell.
|
| Emacs is something else. My custom config is about 3 000 lines of
| elisp code, written over the years.
|
| About anything I want Emacs to do, I can have it do it.
|
| Dunno, last thing I did was configure my 3-ways merge/diff
| environment: didn't like the default, didn't like the layout,
| didn't like the colors. Dived into some elisp code and I changed
| the layout to better match my very wide screen.
|
| Another quick hack: when asking for the list of recent
| buffers/files opened, I wanted, for those in version control, to
| see how many commits they had (to quickly find hot spots)... Some
| elisp code to modify "counsel", one shell script. Boom, done.
| I've done that years ago. Still working flawlessly.
|
| I've written a plug-in for IntelliJ back in the days. It's
| horrible.
|
| Also if we compare Emacs to IDEs, it's the most lightweight, and
| by very far. It was _" Eight Megabytes And Constantly Swapping"_
| and it was funny joke in the 90s but today 8 MB fits in the L1
| cache or so. It's not swapping anymore (even if it's a bit more
| than 8 MB, granted).
|
| I'm using the native-comp branch of Emacs since it came out and
| stuff like burntsushi's ripgrep directly integrated in Emacs. It
| is not just a bit fast, but incredibly fast.
|
| Sure there are gotchas. You have to dig a bit into elisp to fix
| the usual suspects (like long lines making it slow: it's all
| configurable).
|
| But you're in control of absolutely everything.
|
| You have the source code, use it when you need it.
|
| Now I know some are using Emacs with the default setup and the
| default keybindings and without knowing / using any elisp. I'm no
| elisp guru but I think Emacs only begins to show its power once
| you being to use elisp to tailor Emacs to your way of working.
|
| That's the thing: you adapt Emacs to your way of doing things,
| not the other way around.
|
| I don't think there's any need to "make it popular again". It is
| popular enough and it is thriving.
| didibus wrote:
| I love Emacs, but you need to be a retro minded programmer to
| enjoy it, that means you have to prefer code as your user
| interface, because in Emacs, code is the main UX, you're
| basically living inside a running Lisp command shell.
|
| Now honestly, I don't think it needs to become more popular, I
| think it just needs to continue to attract enough people that are
| smart enough to work on future versions and maintain the popular
| extensions, and that's all.
| aj7 wrote:
| This was super valuable as it showed me conclusively why Emacs is
| dead, except for a relatively small group of persons who were
| exposed to it very early in their careers.
| tharne wrote:
| > Emacs is dead, except for a relatively small group of persons
| who were exposed to it very early in their careers
|
| This is false. There are plenty of new users.
| https://emacssurvey.org/2020/
|
| Emacs is not now or in the future ever going to have "mass
| appeal" and that's okay. It caters to a niche, intellectually
| curious developers who like tinkering for its own sake.
|
| If programming is just a job to you, that's totally fine. For a
| lot folks, programming is like accounting, a safe path to a
| decent paycheck. These folks will likely use VS Code and that's
| OK.
|
| Not every piece of software needs to "eat the world". Some
| software, like Emacs, can just be enjoyed by a community of
| dedicated users.
| BeetleB wrote:
| Emacs likely has more new users now than ever before. I'd wager
| the absolute number of users are clearly growing. There's an
| order of magnitude more Youtube videos, blog posts, etc than
| there were 10 years ago. Getting Emacs help via a Google search
| often failed me a decade ago. Now it's extremely rare that I
| don't find an answer.
| NoGravitas wrote:
| The joke "Generally Not Used Except by Middle-Aged Computer
| Scientists" has been around for like 20 years, though.
| iLemming wrote:
| I think the only way to make Emacs popular is to get more users.
| And in any of the over six thousand human languages in use today:
| "Emacs user" typically means "a programmer". Emacs desperately
| needs more programmers.
|
| Unfortunately, many of the core Emacs developers are also FSF
| advocates. Some of them have very radical and uncompromising
| views. It sometimes feels like they have little understanding of
| the real world and the software industry in general, and they
| live in the 16th century equivalent of the computing world.
|
| I mean, many of us (software developers) are very sympathetic to
| the cause and the idea of liberating all software, but sometimes
| it just gets too crazy. As if someone tried saving the world by
| harassing palm oil plantation workers in Indonesia: "Why don't
| you try planting cedar trees instead?". Vilifying and fighting
| the evil in the industry is right; punishing everyone
| indiscriminately - is not.
|
| One of the latest examples: a question about LSP server
| implementation for Emacs Lisp - the verdict of the people in
| charge? Nope, we shouldn't do it because: "it would allow editing
| Emacs Lisp in non-free programs like VSCode". Seriously? IMO,
| it's not just a simple non-sense, it actually sounds like
| borderline narcissistic schitzo thinking.
|
| Emacs codebase needs to adopt the ubiquitous and familiar model
| of issues and pull requests instead of clinging to the outdated
| way of email threads and patches. That's what made Neovim
| popular. That's how VSCode achieved in just five years, what was
| like twenty for Emacs. That's why the most innovation in Emacs
| happens today outside of its core. Today GitHub, GitLab, and
| other Git forges have so much Emacs Lisp - it's probably the most
| widely used Lisp in the industry (maybe even comparable to
| Clojure and Common Lisp). And guess what? Authors and maintainers
| of those awesome libs and packages not sending patches over
| email.
|
| I don't think Emacs is going to fade away anytime soon. But the
| strategic mistakes made by the core decision-makers have done
| irredeemable damage, and Emacs now doomed to play catch-up.
| indymike wrote:
| I've been using Emacs for the better part of 30 years. Right now,
| I use it less than ever. I've switched to using JetBrains IDEs
| for programming. JetBrains replaced VS Code which was nice, but
| required a lot of time dealing with plug-ins that the JetBrains
| IDEs don't. The full IDE with tightly integrated deployment,
| language tools, really advanced code completion, documentation,
| source control, debugging (and remote debugging), code profiling
| and project management is just 20-30 too many plugins to manage
| in most extensible text editors. I still use Emacs for remote
| text editing and org-mode, but that's it. The UI problems in
| Emacs are not a "round corners" problem. Emacs is a great console
| app. But GUI Emacs is sabotaged by it's excellence as a console
| app. Emacs' autocompletes, tooltips, forms and dialogs are more
| mid-80s terminal UIs than GUI native. I suspect putting a full,
| comfortable GUI on emacs is a hard problem. You can't even resize
| an emacs window with the precision you can every other app on
| Linux and MacOS (no idea on Windows) because it forces resizes
| based on line height and character width (or something that
| approximates that).
|
| In the end, Emacs isn't bad software. On the contrary, it is
| excellent, but it's excellent at being a text editor that is
| native to a terminal, that runs well as a GUI app. It still is
| very useful, but it is not competitive with newer ides and
| through the web capable editors.
| dang wrote:
| Discussed at the time (of the article):
|
| _Making Emacs Popular Again_ -
| https://news.ycombinator.com/item?id=23107123 - May 2020 (761
| comments)
| Kessler83 wrote:
| Emacs is like Earth. You can't claim to "learn it" or "master
| it," but it's still the best place to live.
|
| Some other editor is more popular now, and in five years,
| something else will be more popular than that. Meanwhile, Emacs
| will continue to grow, fascinating new users and developers.
|
| Simply put, (eq 'new 'best) doesn't evaluate to true. Knowing
| your way around Emacs says something about you as a programmer or
| computer user. Like you are clearly curious, willing to learn,
| know some Lisp, read documentation and recognize possibilities
| and depth when you encounter them. Knowing editor XXXXXX usually
| says nothing.
| aww_dang wrote:
| Who is actually using the GUI elements mentioned in the article?
| Emacs is a comfort zone where I don't need the mouse.
|
| >...buttons could be improved with rounded corners...
| sokoloff wrote:
| I'm a 30-year user of emacs. I still pick up the mouse to do
| something in emacs at least once a month.
| thom wrote:
| I would worry if people started moving away from Emacs as text-
| centric. My biggest complaint with VSCode (which I do fully
| expect to take over and to which I will one day presumably have
| to migrate) is that there's so much damn UI for things. The
| terminal window isn't just a buffer of text like everything
| else, it's its own ungodly window that pops up differently.
| Most extensions are primarily UI instead of keyboard and text
| driven. There's a nice Magit clone which does things properly,
| and I'd love to see more effort on things like that. But
| fundamentally VSCode doesn't seem to have the right level of
| abstraction to allow all this.
| justsomedood wrote:
| This is the exact issue I have with VSCode. I don't
| particularly like the keybinds in emacs, but the killer
| feature for me is that everything is a text buffer. Eshell,
| magic, lsp, I interact with them all in a similar way from
| the keyboard. It was the terminal in VSCode that brought me
| back to emacs
| thrower123 wrote:
| The problem with VS Code is there is *not enough* UI. I
| desperately would like to have some toolbars and menu
| options, because the kotkeys and key-chords VS Code uses,
| where they aren't following conventions, are not easily
| discoverable.
|
| They're in a bind because they are trying to straddle a
| market where you've got emacs an vim users to one side and
| Visual Studio users to the other. Some ability to customize
| the UI, even if it were provided by a plugin, would be
| helpful.
| alvarlagerlof wrote:
| I use the Ctrl + shift + p for everything like that until I
| learn the shortcut.
| thom wrote:
| Are they not discoverable via the command palette? I find
| Emacs very helpful here, commands are always prefixed
| sensibly and you can do fuzzy search on them anyway. You
| can run 'apropos' if you're really stuck and help is built
| in to every function. It'll show you bindings if you don't
| know them and invoke a command directly etc etc. I feel
| like VSCode has most of this. Besides, they're your key
| bindings anyway, I think it's worth investing in whatever's
| ergonomic for you given you'll likely spend a decade or
| more with an editor. One annoyance I had was that
| extensions were regularly changing commands and throwing
| away my bindings though.
|
| I should be clear though, I am not suggesting they strip it
| to the bone at the expense of other users' tastes. I just
| hate that I can't do that _myself_ because it's not quite
| as low level as Emacs.
| thrower123 wrote:
| It's difficult to discover a command with the command
| palette if you don't already know what they've called it.
|
| I dunno, I'm old. I use directories and folders and
| hierarchical organization instead of searching when I'm
| allowed to.
|
| VS Code is offputting enough and different enough in
| conventions from everything else I use that I don't have
| a great deal of interest in learning it's idiosyncrasies
| where they depart from standard UX.
| underatree wrote:
| I use Emacs GUI. I like the desktop integration, mouse support,
| rich fonts/themes.
| yakubin wrote:
| I'm using GUI Emacs. There is one thing I use the mouse for:
| resizing windows. Apart from that, GUI is more visually
| pleasing, it doesn't try to emulate graphics by fitting
| characters into the grid. When it wants to paint a line, it
| paints a line, not a column of "|" characters; same with arrows
| and whatever. Another advantage is that it gets the key presses
| directly instead of through the terminal. In the terminal it
| can't distinguish between e.g. "C-/" and some other keys (I
| don't remember which).
|
| However, I'm looking for a better editor anyway. Emacs is too
| unresponsive at times. I'll probably either switch to a GUI
| version of neovim when one of them gets good enough[1], or
| write myself a new editor, because I haven't really seen
| anything promising outside of neovim.
|
| [1]: I think neovim folks might have abandoned this idea, so
| I'm not holding my breath.
| aww_dang wrote:
| To clarify, I use the GUI version of Emacs as well, but I
| never interact with the buttons or UI quirks mentioned in the
| article.
| yakubin wrote:
| My bad.
| rvieira wrote:
| I'm using the GUI simply because I like `org-mode` inline
| images. It's just a cosmetic reason, really. It would be 99.99%
| functional from a terminal.
| WalterGR wrote:
| You don't need the mouse to use GUI Emacs.
| cjv wrote:
| I'm curious to know what people think about elisp as a extension
| language. Would Emacs be better if everything was implemented in
| elisp including the core data structures (assuming elisp was very
| fast)? Do people suffer from lack of static typing?
| b3morales wrote:
| Elisp is nowhere near perfect, but it's fast enough in general.
| I recently wrote an indent function for a private DSL; it looks
| like a big slow mess, but when I run it on a code file, it does
| its job with no noticeable lag. You can write slow code in any
| language, of course.
| vintermann wrote:
| Emacs' fundamental problem is that in text editing, there are
| many equally good ways to do things.
|
| It's equally good for Undo to be on control _ as on control z.
| It's equally good for scrolling to move the cursor as to not move
| it. It's equally good to have Lisp as a scripting language as
| JavaScript. No, really, I mean it. It's not a big deal in the big
| picture.
|
| And Emacs choose perfectly good, perfectly sensible defaults on
| all these things back when it came. (That can't be said about all
| editors from that time.)
|
| It's just that in the 30+ years since, the world has converged on
| other defaults. Every little thing is done different than you're
| almost certainly used to - yet not different enough that anyone
| can claim it's somehow superior (unlike its modal cousins from
| the same period. I think their claim is dead wrong, but at least
| it's different enough that they can persuade some).
| avgcorrection wrote:
| I would be very happy if I could use Emacs' text editing and
| text manipulation/navigation everywhere. Things like a real IDE
| with an Emacs editor. Or the IDE being controlled by Emacs. Or
| a desktop manager controlled by Emacs.
|
| That Emacs lets you design a great user interface is exactly
| why some people want to "live in Emacs". (Similar to how some
| misguided souls prefer to "live in the terminal"...)
| kqr wrote:
| This sounds like it's not written by an actual Emacs user...
| and the fact that I can tell points to the real fundamental
| problem of Emacs: it's not a text editor but the real thing it
| is is so complicated it finds it easier to market itself as a
| mere text editor.
|
| What is Emacs really? It's a virtual Lisp machine with a
| standard library for writing graphical text applications. It's
| more like the JVM than like Notepad.
|
| It just happens to come bundled with a text editor (and a file
| manager, and a calculator, etc) as example applications. You're
| free to install a better text editor than the bundled example,
| and many people to (see the popularity of Evil, for example).
|
| But of course, this is a much more complicated point in space
| to sit in, so Emacs markets itself primarily as a text editor
| and we get confusion like yours as a result.
| krylon wrote:
| This is something I wish someone had told me 20 years ago
| when I first started using emacs. The whole "it's a text
| editor, but also it's not really a text editor"-thing was
| very confusing initially.
|
| ... Although, now that I think about it, being told this
| mind-blowing revelation about the emacs nature might have
| confused me even more.
|
| What I love about emacs is that I have a variety - an
| _extensible_ variety! - of programs under one roof, so to
| speak, sharing the same - customizable! - keyboard shortcuts
| that comfortably integrate with each other.
|
| I think the main problem in "proselytizing" emacs to
| potential new users is that it is kind of the C++ of text
| editors, in the sense that it takes a very big up front
| investment that _does_ pay off in a big way if you persist,
| but getting to that point took - at least for me - a multi-
| year commitment. It is hard to sell someone on that unless
| they want to do it anyway. I did it out of fun and curiosity,
| but if you view it as an investment in purely transactional
| terms, it 's hard to sell.
| chipotle_coyote wrote:
| You just succinctly described why my annual attempts to
| learn Emacs never actually go anywhere. As much as I like
| the idea of an all-purpose text processor construction kit,
| even with "starter kits" I spend a week trying to configure
| various languages to a point that I'm happy, find myself
| copying, pasting and tweaking Lisp code, _invariably_ find
| weird conflicts that lead me to do web searches (which may
| find more Lisp code, which may be a decade out of date),
| and so on. I don 't doubt that if I kept at it I'd
| eventually reach nirvana, but I frequently find myself
| thinking "this was just so much easier in Vim" -- and any
| time _anything_ can be described as "easier in Vim", it
| feels like a sign of a UX problem. :)
| krylon wrote:
| _sigh_
|
| I cannot blame you. And if vi makes you happy, I want you
| to enjoy the heck out of it. Between discovering emacs
| and making it my editor of choice I spent a few years
| using vi heavily, and to this day, I reflexively use it
| for quickly editing config files.
|
| Regarding emacs, all I can say is that, in my experience,
| it gets better if you really stick with it for a while.
| The payoff is _huge_ if you put in the time. But time is
| limited resource, vi gives you a payoff much faster, so
| ... like I said, if it works you, don 't fix what ain't
| broken.
|
| I love Emacs, but I also love the variety of editors
| programmers can choose from. With programmers' editors,
| as with society as a whole, I consider diversity an
| advantage.
| hosh wrote:
| Does that include Spacemacs? It didn't take me a week to
| get up and running from switching from vim.
| srcreigh wrote:
| It's an early web browser. Elisp is an early JS. Viewing
| documents is just a little more complicated (download
| packages, sync stuff down using Git, etc)
| jimbokun wrote:
| > What is Emacs really? It's a virtual Lisp machine with a
| standard library for writing graphical text applications.
|
| If you substitute Javascript for Lisp, doesn't that describe
| Visual Studio Code pretty well?
|
| So now there's a product that leverages the architectural
| advantages of Emacs, with modern defaults across the board.
| Zababa wrote:
| Not exactly, VSCode is more of an editor that can accept
| very advanced plugins. The "virtual JavaScript machine with
| a standard library for writing graphical (text)
| applications." is a web browser.
| NoGravitas wrote:
| > If you substitute Javascript for Lisp, doesn't that
| describe Visual Studio Code pretty well?
|
| Almost, but not quite. VSC doesn't give you javascript
| access to the internals of the application, it just
| provides a fairly broad set of extension APIs. You can see
| this in how the VSC equivalent of rainbow-delimiters-mode
| (parentheses and brackets recolored based on their nesting
| depth) had to be rewritten as part of the core application
| for performance reasons. This wasn't necessary for emacs.
| slightwinder wrote:
| Emacs is not that much different there with it's C-core
| and lisp-land. It had even a similar case with the
| reimplementation of linenumber-mode in C for performance-
| reasons. The question is more what emacs can offer
| generally that vscode is lacking in ability, even just
| theoretically. Because in reality there are of course
| many features not implemented yet in vscode.
| convolvatron wrote:
| I'm doing a highly integrated language environment for a
| research language and faced this decision recently.
|
| elisp and javascript are both pretty iffy lisps, but at
| this point I think I'd prefer javascript.
|
| however VSCode presents an API around a specific notion
| of what a language is and how it interacts with the
| editor. emacs comes in at lower level and presents a
| model with just buffers and text.
|
| I remember elisp debugging as being a joy - not really
| finding that to be true. but I really don't want to be
| limited by what the VSC designers thought I should want
| to do with source files - actually I don't want to use
| source files at all.
| b3morales wrote:
| > VSCode presents an API around a specific notion of what
| a language is and how it interacts with the editor
|
| I would say Emacs has this as well, in its syntax tables.
| They are its schema for "what a language can be" and
| especially "how the editor can interact with it".
| convolvatron wrote:
| yes - but those are completely optional
| kqr wrote:
| That is true of any editor: they will only seeem
| intelligent if you ask them about the languages they have
| support for.
| kqr wrote:
| I haven't personally used VS Code much, but from what I
| understand, it still runs in two castes that don't,
| generally, mix: there's its core code, and then there's
| plugins, and the latter exists on a separate plane from the
| former. You can't write a plugin that redefines some core
| behaviour. The functions internal to the core are not all
| automatically accessible for any plugin. Plugins don't
| become fully integrated with the core code to the point
| where the source file location is your only hint as to
| whether behaviour comes from a plugin or core
| functionality.
|
| (A non-Emacs user might very well go "Emacs plugins can do
| what now?" at the description of a plugin re-defining a
| core function. That's a fully understandable reaction. That
| level of hackability is not for everyone. But as far as I
| can tell, it's unique to Emacs and very small set of other
| software.)
|
| But I could be misunderstanding this. Maybe VS Code
| actually does have Emacs-level hackability, in which case
| I'd probably want to try it out more than I have!
| vintermann wrote:
| No, I do not go "Emacs plugins can do what now". I rather
| go, "and that is supposed to be a good idea?". If you
| want to use Emacs as an OS, doesn't protected mode seem
| like a desirable feature?
| kqr wrote:
| From personal experience, I've benefited way more from
| that than I've been hurt by it. Whether that's true for
| all people I don't know.
|
| Of course, you're not supposed to do it other than very
| carefully and it has caused me problems when some plugin
| has made a mistake in a way that worked for the original
| author but not for me, but because of the openness of the
| system, it's fairly easy to "overwrite it back"
| automatically when the plugin is loaded - and submit a
| patch back upstream.
|
| So maybe this sort of system works only when a large
| portion of the users are hackers, and making Emacs more
| popular is not a good idea!
| m45t3r wrote:
| Yeah, exactly. For example, evil-mode is still miles
| better than VSCode Vim plugins just because it works
| everywhere. Any buffer that my Emacs opens I can still
| use my Vim shortcuts (so it doesn't change that I open a
| text, a binary, file manager, a fuzzy search or PDF).
| Compared to this, on VSCode I basically need to
| explicitly say "make vim commands do this in this
| context" for everything I need.
| deviaan wrote:
| My current client wants all of us to standardize on VS
| Code at some point, and this is by far the most annoying
| thing for me. I hate that if I leave the editor, it goes
| back to a mouse-driven design. I'm glad to hear you can
| change the behavior, so I guess I'll just have to do that
| at some point to make it work for my needs.
| krylon wrote:
| I have not played with VS Code a lot, but I get the
| impression that, yes, they aim for something similar. I'm
| not qualified to judge, though, how successful they are so
| far.
|
| FWIW, when I hear people talk about VS Code, they appear to
| like it very much. But AFAICT, it has some way to go to
| catch up with all the functionality emacs has accreted over
| 30+ years.
|
| Also, there is an effort replace the old lisp engine inside
| emacs with GNU Guile, which is a JIT compiler that supports
| Scheme, ELisp, and Javascript. I have not tried it so far,
| but it might become possible to customize and extend emacs
| with Javascript in the not-so-distant future.
| oblio wrote:
| Isn't the Guile effort practically dead? I remember
| hearing about it 10 years ago.
|
| It was actually started in 2000 and doesn't seem to have
| progressed since 2014:
| https://emacsninja.com/posts/state-of-emacs-lisp-on-
| guile.ht...
|
| Plus, even if it's finished, will it get any traction in
| the ecosystem? Will the ecosystem start moving to it to
| take advantage of its unique benefits? Who knows?
|
| Bonus: Have you heard of GNU Hurd? :-)
| r-zip wrote:
| Yes, Guile Emacs got abandoned, at least the last time I
| checked.
| krylon wrote:
| I honestly don't know about the state or progress of
| Guile Emacs. I know it exists, but I haven't followed it
| beyond that.
|
| Assuming it gets "finished" (is any software ever
| finished?), it should be no-brainer as long as it
| provides backward compatibility with old elisp code. And
| open up the emacs ecosystem to Scheme and Javascript,
| which _could_ make it much more attractive to newcomers.
| But, as they say, I 'll believe it when I see it.
|
| The trouble with Hurd, IMHO, is that I've run out of
| jokes. We used to joke that it would run Duke Nukem
| Forever out of the box, but that one actually got
| finished. Then it was Perl 6, but that has arrived, too.
| Star Citizen maybe?
| eadmund wrote:
| Ah, but Javascript is a profoundly terrible language to do
| anything in, while Lisp is a joy to write in.
|
| Being a Lisp machine is core to the value of Emacs. Emacs-
| without-Lisp is just another editor.
| Steltek wrote:
| eLisp? Where lexical scoping is this brand new feature
| that generates compiler warnings? Where the UI thread is
| the same as your eLisp thread? Where multiprocessing is a
| super clunky fork-exec with a weird side buffer? Where a
| simple regular expression works differently between what
| the user invokes and how you'd write it in a function?
|
| Yeah, it's a super joy to write.
| r-zip wrote:
| As someone who uses Emacs and likes writing lisp, 100%
| agree. elisp is without a doubt the worst lisp still in
| common use.
| oblio wrote:
| It is a joy. When writing code in the ivory tower :-)
| Zababa wrote:
| What do you find profoundly terrible about JavaScript?
| edgyquant wrote:
| I disagree, I like JavaScript
| foldr wrote:
| Elisp arguably has worse warts than Javascript. For
| example, non of Javascript's legacy 'var' scoping
| nonsense compares to elisp's archaic model of using
| dynamic scope for everything by default. On top of that,
| modern Javascript implementations are of extremely high
| quality, whereas Elisp is stuck with an interpreter of
| mediocre performance.
| spiderice wrote:
| > Javascript is a profoundly terrible language to do
| anything in
|
| Makes it really hard to take anything you say seriously
| when you reveal just how ok with extreme hyperbole you
| are
| Mikeb85 wrote:
| > If you substitute Javascript for Lisp, doesn't that
| describe Visual Studio Code pretty well?
|
| For the most part, except for the fact VSCode is owned by
| MS and has just enough proprietary code to break a lot of
| functionality if you try to use it without the proprietary
| bits.
| warkdarrior wrote:
| > For the most part, except for the fact VSCode is owned
| by MS and has just enough proprietary code to break a lot
| of functionality if you try to use it without the
| proprietary bits.
|
| That's a personal policy choice, not a technical concern.
| Mikeb85 wrote:
| Let's face it, the fact it's free software is the reason
| it's used at all, the reason it's been hacked on by so
| many people, etc... It's always relevant to discuss it's
| free nature, especially when discussing it's popularity.
| hollerith wrote:
| Unless I was very _un_ lucky in my decisions about what and
| how to learn about vscode or my ability to learn has
| dropped more than 10-fold between the time I learned to
| modify Emacs and the time I tried to learned to modify
| vscode (which is unlikely but not impossible: it was an
| interval of 28 years) emacs is much easier to learn to
| modify than vscode is unless one is already a web dev.
|
| Of course, if one does learn how to modify vscode, one has
| a skill (namely, web dev) in much higher demand on the
| labor market than knowledge of Emacs Lisp.
| bigbillheck wrote:
| In a couple months I'll have been using emacs for 30 years,
| and it seemed like a pretty good summary to me. In that time
| the closest I've gotten to using any of the lisp stuff is
| setting some variables in my .emacs file. (and it's been
| fewer of those as the year go by)
| vintermann wrote:
| I never claimed to be an emacs user. I've used Linux
| exclusively at home since 2001, and I've never "switched" to
| it or vim, though of course I have a passing familiarity with
| both from such things as certifications or working on other
| people's machines.
|
| Of course I'm familiar with the "never leave emacs" meme,
| moon phase indicators and "what it needs is a good editor"
| etc. I even gave an example of it being used as a platform in
| my other comment here (proof general).
|
| But this was about its popularity relative to other editors,
| not relative to other scriptable framework things.
| varjag wrote:
| Thing is the difference between Emacs undo tree and
| ...other editors undo is way more than the key binding.
| Your comment barely scratches the surface of the issue.
| teddyh wrote:
| > _for Undo to be on control _ as on control z._
|
| Well, Ctrl-_ is three keys; control, shift and _. _However_ ,
| Undo in Emacs is actually designed to be on the two-key
| combination Ctrl-/ and the fact that this key produces the same
| ASCII control code as Ctrl-_ is incidental.
| didibus wrote:
| Actually, ounce I got used to Emacs choices I ended up liking
| them better. Hard to say why, I think it's that when you start
| adding more and more shortcuts, the choices Emacs made start to
| make sense in terms of maximizing all the various bindings.
| agumonkey wrote:
| I never minded emacs peculiar history / bindings. It's a no
| brainer to swap between vi / emacs / CUA.
|
| People trying to learn very deep kind of software should be
| ready to swallow a little more info than that IMO.
| WalterGR wrote:
| The biggest problem for me is the constant context switching
| between those defaults chosen 30 years ago and the defaults
| converged on by every other app I use.
|
| Of course, no context switching is needed if you do everything
| in Emacs.
| oblio wrote:
| You can't. Everyone except for RMS also uses at least a real
| web browser.
| babypuncher wrote:
| Clearly this is just how Emacs cultivates vendor lock-in.
| isolli wrote:
| There's nothing worse than reflexively typing ctrl+z to undo in
| Emacs and instead have the window disappear into the
| background!
| jyriand wrote:
| Or while cutting a text in browser and typing ctrl+w, thereby
| closing the tab.
| ReleaseCandidat wrote:
| Actually, there is. Typing `C-x C-s` in a 'normal' Editor.
| Always happens to me :(
| foobarian wrote:
| You guys both got nothing on pressing Cmd-W on a MacOS
| terminal when you intend to copy a selection. :-( I swear
| whoever designed that UI must have been a vi partisan.
| b3morales wrote:
| I found it better to make Option (rather than Command) be
| Meta for this reason.
| bluecatswim wrote:
| Yep, for me it's this. I don't know why others are
| complaining about the other way around, maybe it's because
| I thought of Emacs as being different from other editors
| right from the get go, but I doubt I've ever accidentally
| entered CUA shortcuts in Emacs. But Emacs shortcuts in
| normal editors while using school PCs was something I did
| all the time.
| kwhitefoot wrote:
| Done that about a dozen times today!
| isolli wrote:
| Same here! It's just easier to undo :)
| ajross wrote:
| In my .emacs since time immemorial:
| (global-unset-key [(control z)])
|
| It's absolutely true that defaults are "bad" in many modern
| environments (though remember C-z to suspend in a terminal
| environment makes perfect sense!).
|
| But the nature of the editor is customization like this.
| People unwilling to do this just aren't ever going to be
| happy with emacs. And for those just learning, tricks like
| that (c.f. emacswiki.org) are a very reasonable entryway into
| a world of possibilities.
|
| I mean, look, Emacs isn't ever going to be VSCode. If you
| want VSCode, use VSCode. It's a great editor, and frankly at
| this stage I think nothing is going to do VSCode better than
| VSCode already has. Emacs is something different, and we
| might as well embrace that.
|
| (Not that I'd object to switching some of the dumb defaults
| around, of course. I just don't think that's going to help
| very much if your goal is "displace VSCode").
| babypuncher wrote:
| I find this at least a little frustrating. I haven't used
| Emacs, but when using other apps that use non-standard
| defaults (or just defaults that I am not used to), changing
| one shortcut leads to a cascade where I have to change many
| shortcuts. I now have to spend a somewhat significant
| amount of time configuring a new piece of software before I
| even know if I actually like it.
|
| Shipping with some easily configurable presets to mimic
| other popular tools would probably help new users a lot.
| teddyh wrote:
| Ctrl-z for suspend is useful in the terminal, though, so
| maybe something like this? (if window-
| system (global-set-key (kbd "C-z") 'undo))
| tom_ wrote:
| Suggested tweak: (when window-system
| (global-unset-key (kbd "C-z")))
| servilio wrote:
| The recommended way to do this now seems to be:
| (when display-graphics-p (global-unset-key (kbd
| "C-z")))
|
| Also, though this works with Emacs running as a server, I
| find it better to just quit emacsclient instead of
| learning to do something different depending on what
| environment it is running.
| ajross wrote:
| Nope. Again, context matters here. I never use emacs in a
| terminal; all editting of files on remote systems is done
| in a local X11 emacs over ssh. And this is not because of
| circumstance but because making that choice opens up more
| doors. I can have keybindings not just on C-z but ones
| that aren't representable in the terminal at all (e.g. I
| like to put end/beginning-of-buffer on C-. and C-,)
|
| Would I submit my choices as good defaults for new emacs
| users? Hell no. But they remain good choices nonetheless.
| That's the essence of my point, not the minutiae.
| d0mine wrote:
| To understand why emacs is great, think of it not as an editor
| but as a platform. Killer apps for me are:
|
| - magit :: everyday things are just a key away, less common
| things are visible, complex things are possible
|
| - Org-mode :: whole life in plain text (for some brain types it
| enables almost impossible to achieve otherwise + Org-Babel +
| emacs-jupyter
| pfortuny wrote:
| mu4e has simplified my life enormously.
|
| I can do things no other would let me do easily. Namely:
| create automatic exams with latex, each for a different
| address and send each to its corresponding pupil, all in a
| single script.
|
| Attaching is a breeze, by the way.
| rich_sasha wrote:
| I'm surprised at the disparity between Emacs and vim use (20% vs
| 3% according to some survey). I thought it's more equal.
|
| I suppose, while the learning curve for Vim is a lot steeper, you
| reach the power regions very quickly too. With Emacs, while it's
| less alien initially, you need to learn quite a bit more to get
| to "power user" levels. But then, in turn, it seems that Emacs is
| much easier to mold into an IDE sort of thing, whereas this seems
| against the Fu of Vim. One tool, one purpose.
| agumonkey wrote:
| Emacs is also a whole distribution. You never see the end of
| it.
| lgrapenthin wrote:
| Its quite similar percentages to about a 10-15 difference of IQ
| points at end of the distribution curve.
|
| https://commons.wikimedia.org/wiki/File:IQ_distribution.svg
| sidr wrote:
| Any probability distribution of any attribute can be
| aribtrarily cut off at the 90th or 85th percentiles to make
| this point. Are you claiming there's something special that
| relates _integer_ multiples of standard deviation of the IQ
| distribution to emacs usage?
| deworms wrote:
| You'd expect more intelligent people to prefer a tool that
| doesn't require days of tuning to start being remotely usable
| though
| SauciestGNU wrote:
| Prefacing with that I don't think iq is the best way to
| measure intelligence, but I wonder what the intelligence
| distribution of tinkerers is. The sort of person who might
| sit down to learn emacs because it's a blank functional
| canvas that you can customize to meet your particular
| needs.
| rich_sasha wrote:
| Jokes aside, definitely not a day's worth of tuning.
|
| My minimal set-up is mostly hiding all the GUI elements.
| Though I also make a semi-virtue out of trying to use as
| much vanilla Emacs as possible, for this very reason.
|
| If you know your way around it, there's a lot of power in
| unmodded Emacs still.
| SauciestGNU wrote:
| Stuff like electric pairs, rainbow delimeters, rjsx-mode,
| prettier, and neotree are really all I use. I started
| using emacs because of auctex writing my master's thesis,
| and ended up switching from vim because of the
| experience. Once you know the basics about packaging
| (enabling melpa) and setting a comfortable theme you're
| pretty much ready to roll.
| rich_sasha wrote:
| You made my day! :)
| commandlinefan wrote:
| > mold into an IDE sort of thing
|
| Emacs would be a great operating system if only it came with a
| decent text editor...
| sleibrock wrote:
| I have worked at a number of jobs where it sometimes required me
| to use coding. I was not treated like a programmer ever. I was
| given very old hardware and expected to do my work. The worst
| computer I had was a Dell machine which had an i3 CPU and 4GB of
| RAM. Opening VS Code on this machine brought it to it's knees.
|
| I solved this issue by simply using Emacs instead. It uses far
| less memory, didn't cripple my system, and it is after all my
| preferred text editing environment for the last few years. I
| eventually got fed up with Windows bluescreens that I switched to
| Linux, and then I spent more time fixing other people's older
| Windows machines than doing my tasks.
|
| Emacs has me sucked in and I don't see myself going anywhere
| else. Now I'm using Emacs on another old Dell with Linux in
| another workplace, and it's fantastic to use as always.
| rbanffy wrote:
| What I like about Emacs is the things you learn from it. The
| "config file" is a program, not a JSON or INI file. This allows
| the user to add functions to the editor very easily.
|
| For instance, one of the first tricks I taught Emacs to do was to
| find the right font size so I could have at least 80 columns on a
| window. It was a bit of work, and needs to contemplate some
| corner cases, but it's really cool to be able to do that in your
| config file.
|
| This is a pattern other programs and frameworks use. It's
| relatively normal in Python to import configuration from a
| settings.py file that'll do whatever is appropriate to get the
| information (a bucket with an INI file, constants declared in
| code, a local settings_devel.py file...)
| finder83 wrote:
| I use Emacs (with Evil) daily, and despite having tried to move
| to other editors I'm locked into Emacs. Not so much because of
| the functionality of Emacs itself but because of plugins...
|
| First, Emacs has the best Vim compatibility I've seen outside of
| Vim itself. Visual Studio is probably "good enough" for me on
| this with the vim plugin, but that 5% difference in compatibility
| makes a difference in practice.
|
| But the largest reason I can't get away from Emacs is
| Ivy/Counsel. Being able to fuzzy search on the current file or
| entire project, see results, jump around to each one to see
| context, make changes to the results in an occur buffer to
| selectively mass edit search results...all of that I just haven't
| found a replacement for. Search/replace just doesn't cut it.
|
| So effectively if I move to another editor, my code navigation
| time increases by 5-10x. Things like better autocomplete might
| fill that gap, but just even understanding how things go together
| is so much more difficult when you're fighting with your editor.
|
| Add on other things like org-roam, buffer fuzzy searching in Ivy,
| fasd tie-in, the customization options, etc, and Emacs is just an
| amazing experience. There are definitely things I would change,
| like inline debugging (which I use VS Code for instead), setting
| up languages and autocomplete, etc. Getting things just right
| takes a long time for a new language.
| rement wrote:
| Nvim has some plugins and features that do some of the things
| you might be interested in. Telescope[0][1] which is a fuzzy
| finder for anything you can think of (files, symbols, color
| themes, etc.[2]). The LSP and Treesitter stuff in nvim 0.5+ is
| also pretty cool. If you want to just try it without much work
| the Lunarvim[3] project comes with sane defaults and included
| plugins (including Telescope).
|
| Lua as the default configuration language makes things simple
| to configure as well.
|
| Having said all that...if someone told me [insert-text-editor]
| had everything I would want I would probably check it out and
| go home to vim (but I do enjoy learning about new stuff and
| features).
|
| [0] https://github.com/nvim-telescope/telescope.nvim
|
| [1] https://www.youtube.com/watch?v=65AVwHZflsU -- demo video
|
| [2] https://github.com/nvim-telescope/telescope.nvim#vim-
| pickers
|
| [3] https://www.lunarvim.org/
| skulk wrote:
| The diversity in the emacs ecosystem has a hand in this I
| think. There are so many different ways to switch buffers:
| vanilla, Ido, Helm, Ivy, and all of the other ones I haven't
| heard about. This kind of diversity is unseen in other
| consolidated, centrally managed software ecosystems.
| kristjansson wrote:
| And those aren't just ways to switch buffers - they're
| options on a 'select among choices' dimension that's totally
| orthogonal to 'things that generate choices to select'. List
| of buffers, list of commands, list of files in a project ...
| can be presented, narrowed, and selected in an interface
| chosen by the user
| deworms wrote:
| Emacs should have been what VSCode is now - a powerhouse of
| customizability that offers unmatched functionality by default.
| Instead it's a toy for some old people who are still holding onto
| the remnants of an age that passed a long time ago. Emacs is
| basically useless compared to VS Code, and its authors are what's
| holding it back. I don't see it bouncing back to popularity any
| time soon.
|
| Anything you can do in Emacs, you can do in VS Code faster,
| better, and easier.
|
| Emacs is being steered by a committee of living fossils that look
| condescendingly on people who expect a text editor to be
| discoverable, easy to learn, and productive out of the box. They
| make passive aggressive comments ridiculing anyone who wants
| Emacs to behave remotely like any other program. With this kind
| of leadership, it will be dead in a few years.
| BeetleB wrote:
| > Anything you can do in Emacs, you can do in VS Code faster,
| better, and easier.
|
| Show me how to do the following in VS Code:
|
| 1. Org mode, or anything as powerful as Org mode (org mode is
| one of the two major packages that keep people in Emacs - it's
| not an obscure thing).
|
| 2. Reading, writing, and managing email (e.g. adding a tag to
| an email). While you're at it, please make sure the org mode
| equivalent can have a TODO linking to a particular email.
|
| 3. IRC
|
| 4. Feed reader
|
| I honestly have not searched whether these exist in VSCode, so
| it would be nice to know.
| underatree wrote:
| > Emacs should have been what VSCode is now - a powerhouse of
| customizability that offers unmatched functionality by default.
|
| +1.
|
| Emacs is a powerhouse of customizability, and it needs to work
| on functionality by default.
|
| > Instead it's a toy for some old people who are still holding
| onto the remnants of an age that passed a long time ago. Emacs
| is basically useless compared to VS Code, and its authors are
| what's holding it back.
|
| I don't think Emacs is held back by its authors. The article
| might not make it clear but RMS does not contribute much to the
| vision or code of Emacs today. Read emacs-devel, and though
| there's occasionally some conflicts, the authors are keen on
| progress aligned with what people expect from an editor.
|
| Emacs is a complex platform, owing to its unique vision on
| blurring the line between user and developer. The authors do a
| great job of keeping that up-to-date.
| deworms wrote:
| If you need to use a specific dialect of lisp most people
| won't be familiar with, it does a poor job at it. Lisp is not
| a language many people use today. NeoVim lets you use any
| language you want for writing extensions. VS Code uses
| javascript which is easy to learn and most developers already
| know it.
| underatree wrote:
| It's a great strength that NeoVim supports many languages,
| and VS Code uses Javascript.
|
| Lisp is not widely used, and this is an impediment to
| Emacs' popularity.
|
| However, when people speak about Emacs customizability,
| they are referring to a deeper level of customizability
| than most programs (even NeoVim/VS Code), in which its
| innards and UI are all subject to modification, at runtime,
| within the beast itself. This isn't necessarily a good
| thing, but it happens to be my preference at least.
| heartofgold wrote:
| > Lisp is not widely used
|
| This is so unfortunate. Lisp has so many good things to
| teach us.
| motomoto wrote:
| So does neovim. As an example:
|
| https://github.com/rktjmp/lush.nvim#readme
| qwerty2021 wrote:
| evidently, some people do deserve being talked down to.
| butterisgood wrote:
| Emacs is my daily driver for work lately.
|
| Oddly enough I don't use it for code editing as much as I do for
| reading (TAGS navigation is great!)
|
| But, for a lisp environment - it's outstanding! I use it to do
| complex Jira queries (jiralib2), and have even used the source to
| jiralib2 as inspiration for writing my own RESTful connectivity
| to two other proprietary in-house systems.
|
| Then I cross reference them, to find out what stuff needs my
| attention immediately. There's no amount of email notifications,
| or slack bot popups that can replace what I'm doing for my
| workflows every day that I can get done in Emacs right now.
|
| Basically I create a lisp-interaction mode document, and treat my
| lisp expressions like things I can expand in a report by C-j'ing
| them. Then I've got keyboard shortcuts to open things in brower
| tabs using eww's functionality.
|
| I did a demo video for a few coworkers and folks who'd strayed
| from Emacs are starting to think about coming back to it again.
|
| I started kicking around the idea of building this out again in
| Racket, just to learn Racket, but it's a distraction from the
| system that's working great for me right now.
|
| My compile, test, edit cycle is now driven mostly by the Acme
| editor which makes it easy for me to script connecting to remote
| systems, issue builds, find failures, and jump to the line of
| code where things break while I'm working. I haven't found a way
| to go faster than this.
|
| Perhaps VS Code could replace some of this, but I just don't have
| the time (or perhaps the gumption) to give it a try honestly.
| Maybe I'm just having too much fun...
| adamc wrote:
| A number of years ago, I reported a problem with its default
| Python mode and the way it automatically indents things. I got a
| response, which confirmed it was a problem. Then nothing happened
| and the report was eventually closed.
|
| For me, that was representative of several other issues I had
| encountered over the years. It's a great tool, but it is 1) old
| and sometimes baroque ("make-frame" comes to mind), 2) so large,
| even if you consider just the built-in functionality, that they
| seem to have problems keeping everything up to snuff.
|
| I am starting to move to Visual Studio Code. That's a painful
| shift, because I wrote lots of customizations in emacs, but, on
| the other hand, it has much better tools for many modern things I
| need to deal with (AWS, for example).
|
| I love emacs, but it needs a replacement -- something with the
| same basic architecture, but more modern concepts of how editors
| work and maybe an extension language easier to get buy-in for
| than emacs lisp. I had hopes for Atom, but... that looks pretty
| dead.
| cjauvin wrote:
| I have realized recently that a value that is gaining a lot of
| importance for me is the stability of my cognitive investments,
| in terms of tooling, across a time frame that goes beyond my
| "current project", and more into the "my entire career"
| territory. In that sense, I feel more and more that the choice of
| learning and owning Emacs, more than 20 years ago, while in
| school, has paid off tremendously, in the sense that it has
| always constituted a solid and consistent backbone from which I
| can always start a new project, no matter what the context is
| (corporate or personal). I feel this would have been harder to
| achieve with a tool which is asking me to update it every 3 days,
| and which periodically introduce important paradigm changes
| forcing me to reconsider the way I work. In short, I value Emacs'
| stability and consistency across time and tech fashions more than
| anything else, as I grow older.
| olivertaylor wrote:
| This is the reason I left the whole app ecosystem. Apps are
| cool, and sometimes really great, but there's no sense of
| permanence, no guarantee that your data will survive for long,
| that the app will be maintained, or that future devices will be
| able to run the app or access the data.
| II2II wrote:
| The way I usually put it is you have a choice: learning your
| tools in depth or relearning old skills each time your tools
| tools. I decided upon the former and firmly believe it was the
| right decision.
|
| That being said, there is a cost. Tools that adapt with the
| times try to reduce the effort needed to get contemporary tasks
| done. Stable tools tend to reflect the times in which they were
| created (or at least peaked), meaning that it may take more
| effort to get things done in the here and now. Unfortunately,
| Emacs is very much a reflection of this.
| [deleted]
| sofunnytotell wrote:
| so you say:
|
| emac users are, well; conservatives...
|
| (( use controversy ))
| davidw wrote:
| I have been a happy Emacs user for 25 years. Still gets the job
| done and is quite flexible with whatever code I'm working with,
| and hackable if I need to make it do things differently.
| jdblair wrote:
| I've been using emacs for approximately 30 years. Every once in a
| while, someone ask me what editor or IDE I suggest they learn,
| and I never suggest emacs. It's incredibly powerful, but it's a
| fossil.
|
| I keep using emacs mostly because of muscle memory.
| AQuantized wrote:
| I'm relatively young and for me Emacs isn't a fossil just
| because there isn't a better alternative I've found for taking
| notes than Org mode. This is especially true if you want to
| embed LaTeX or code into your notes (and even execute it).
|
| As I've gotten into learning Lisp and using Magit occasionally
| I can't think of a an editor that's more versatile in its
| extensibility or offers a Git interface on Magit's level
| (although I still mostly use command line).
|
| I did rebind a lot of stuff to more common shortcuts, with the
| exception of C-c just because it was too much work.
|
| This may be more of an argument for Emacs as a general editor
| than IDE specifically however.
| rjrodger wrote:
| That's it. That's the reason. You can usually get Emacs key
| bindings (or a shallow approximation thereof) in most editors.
| But yeah, we're stuck, so I guess we just gotta double down.
|
| It is fun when the young 'uns do a double take after you
| execute a particularly fancy macro. I do love that.
| jdblair wrote:
| The macros are always the deal-breaker. I tried sublime text,
| set up emacs keybindings, then tried to ctrl-x-( to start a
| macro and... switched right back to emacs. (and then
| proceeded to modify me emacs config so it approximated many
| sublime text features)
| azeirah wrote:
| I used to be a heavy Sublime Text power user a couple years
| ago. I found out at some point that while Sublime does
| market itself as supporting macros, many commands were one
| of these four
|
| - extremely basic (ie, move left or right)
|
| - poorly thought out
|
| - Straight up not implemented as a recordable macro command
|
| - Buggy
| MereInterest wrote:
| I've customized my setup to the point where I don't just want
| emacs keybindings, I want _my_ emacs keybindings. Because
| those are the ones that are in my fingertips.
| mark_l_watson wrote:
| Same situation for me, but much longer than 30 years. I still
| use Emacs with SBCL Common Lisp (but use VSCode if I am
| exploring someone else's large codebase) and for routine non-
| programming editing, but otherwise I use IDEs: LispWorks,
| PyCharm for Python, IntelliJ for Java and Clojure, XCode for
| Swift, and Racket IDE for Racket Scheme.
|
| I like having Emacs key bindings for other editors and IDEs.
| tazjin wrote:
| I think it's interesting that there are Emacs users who use it
| for so long and yet still regard it as a text editor.
|
| For me it's a window manager, mail client, terminal emulator
| and so much more and I don't know of a rivaling ecosystem where
| I could get these things in a consistent way. Maybe something
| Apple makes, but that's a non-starter really (especially if you
| care about keyboard accessibility).
| earth_walker wrote:
| Here's the major benefit of investing long-term into emacs.
|
| Not only do I have virtually the same, infinitely configurable
| interface for coding in any language, I also have that interface
| for most things I need to do in my workday. On top of coding in
| my day-to-day I:
|
| - manage my task lists
|
| - manage clients and projects
|
| - keep a daily journal and other notes
|
| - draft documents and create templates
|
| - search through or replace in multiple documents
|
| - navigate directories and manage files
|
| - do quick calculations and tables
|
| - and much more
|
| All using the same interface, without having to reach for a mouse
| or switch to a different program. The amount of cognitive load
| and context switching this reduces is great.
|
| The only other tool I use that is as flexible is the web browser,
| but it's nowhere near as consistent.
|
| Of course it's emacs, so if I chose to I could also manage
| emails, newslists, blogposts, pong, etc. etc.
|
| If I'm playing with a language that is much better served by an
| IDE or vscode, then I can always use it for that language.
| However I find that a) those features that made me want to switch
| weren't worth losing the other powers and I eventually end up
| back in emacs; and b) often the language's emacs package will
| eventually end up with that feature anyway.
|
| It is absolutely worth the investment.
|
| No, you're not going see this benefit in the first month of
| learning it. It'll be incremental over years of using it.
|
| As far as configuration goes - Yes, you can spend lots of time in
| configuration, just like new linux users tend to spend years
| distrohopping. But it's not necessary. I suggest that if you
| learn vanilla emacs first, you'll figure out which keybindings
| you really need to change later on.
|
| My configuration has been stable for years, and the only time I
| need to edit it is if I've added configuration for a new package.
| I don't use overlays like evil or doom, so perhaps this provides
| a bit more stability, I don't know.
| rawoke083600 wrote:
| Any "recently-beginner-Emacs" users that could share a good
| tutorial or "the one" tutorial that made things click or made
| them push through ?
|
| Side Note. I recently "invested" my time in moving to i3 and the
| first week was hard as hell, but now i can't imagine my daily
| linux life without i3.
|
| Conclusion: As "computer professional" it always pays off to
| invest in learning your daily-tools properly - Advise from a very
| wise ex-boss !
| Bostonian wrote:
| I'm an experienced Emacs user but not an advanced one. What I
| like is the ability to have code in one or more buffers and a
| shell (CMD on Windows, bash on Linux) in another buffer. In that
| buffer I compile with `make foo` and see the output there.
| AtNightWeCode wrote:
| Have not used Emacs since I coded things in Lisp on SPARC
| machines in the last century. This got me curious though. Will
| try Emacs again just for fun.
| bachmeier wrote:
| Emacs is not just for programming. Given the popularity of other
| uses (org-mode being the obvious big example) it's likely that
| text editing is the bigger potential market than programming.
|
| There's a market for a customizable text editor. Look at what
| non-programmers are doing with Obsidian. The outdated defaults
| Emacs uses kills off their chances of getting into that market.
| Weird default shortcuts for no reason, a block cursor by default,
| strange terminology in the documentation, excessive keystrokes in
| the keyboard shortcuts (C-x C-s to save rather than C-s and C-f
| to search), and the list goes on. When someone gets to the point
| of customizing, they're happy with Emacs, but Emacs does
| everything it can to run them off before they get there.
|
| Another thing they need to do is make sure they have the best
| markdown mode in the default install, complete with Pandoc
| integration. As good as it is, org-mode is not what most people
| are looking for when they are writing a text document.
|
| > Yes, make Emacs appealing and user friendly. But don't forget
| that a masterful tool in the end requires mastery, which can't
| come for free.
|
| That's true, but why add all the unnecessary baggage for new
| users? Just make the editor function like any new user expects
| and let the customization options turn them into passionate
| users.
| MonkeyClub wrote:
| > a block cursor by default
|
| Hands off the block cursor, it's very helpful with astigmatism.
| bachmeier wrote:
| Nothing against the block cursor as long as it's not on by
| default. I'm having trouble thinking of other text editors
| that use it as the default.
| tonyfader wrote:
| please, no.
| CJefferson wrote:
| Speaking as someone who sees a lot of students start using text
| editors for the first time, VSCode has two massive advantages
| over Emacs:
|
| 1) Most students already basically know their OS's graphical
| interface -- the "basic keys" like cut/copy/paste/load/save all
| work as expected.
|
| 2) The first time you load many common filetypes (like Java for
| example), a box pops up saying "Do you want me to install a nice
| set of standard Java plugins?"
|
| Both points are really useful for getting started quickly, but
| would I imagine be really hard for emacs. The first would require
| changing default behaviour on first startup, the second would
| need accepting some set of people to decide the "default" sets of
| plugins.
|
| For those who say "emacs is worth learning", that might be true,
| but when students can choose between Emacs, Vim, VSCode, nano,
| Intellij, pycharm, Eclipse, Atom, Sublime Text or Notepad++
| (that's all the editors I think I've seen in the last year), they
| need a special reason to give emacs all that extra work needed to
| understand it.
|
| Vim/Neovim had a bump a few years ago and got really popular
| (although that might be over now, at least on my limited
| experience). I think that was because there were obvious
| improvements going on, which attracted students to take a look.
| gjvc wrote:
| Computer Science students would greatly benefit from an
| introductory-level course in the two of the most historically
| influential languages -- LISP and Smalltalk.
|
| Emacs as an editor does take effort to learn, and it's a
| different type of effort from all the other editors you
| mention, because they are all quite different beasts.
|
| In the end, it comes down to pedagogical considerations and how
| each individual learns.
|
| Emacs has suffered by having an awfully austere default
| installation, and Linux distributions have refrained from
| delivering a version with something like Doom or Prelude to
| make it more approachable. (Prelude is my favourite.)
| Jtsummers wrote:
| Not always with those two languages, but in many CS curricula
| in the US there is a "programming languages" course that
| covers between 4 and 10 [0] languages in different language
| families. Prolog and Common Lisp (or Scheme) are typically
| included, you may get Smalltalk in there depending on the
| school. It's brief, because it's one course, but it's usually
| a 3rd year course so students should be competent programmers
| by then (that is, an Algorithms 101 course _but in Lisp_
| would be a slog for them).
|
| Other schools make a point (or made, not sure the current
| state) of changing languages between courses in the first
| couple years and giving more choice to students later. Like,
| an OO course would have been taught with Smalltalk after an
| intro algorithms/data structures course sequence using Java,
| Python, or other languages. A compilers course may have used
| SML, but it wasn't an _SML_ course, just a compilers course
| that happened to use SML.
|
| [0] The most I've seen, it was absurdly paced, an intern was
| taking that one.
| gjvc wrote:
| You'd certainly want to avoid spreading yourself too thin,
| which is why I specifically limited my hypothetical first-
| year module to these two languages, as they would provide
| the (IMHO) ideal context for learning the rest.
| xroche wrote:
| > The first time you load many common filetypes (like Java for
| example), a box pops up saying "Do you want me to install a
| nice set of standard Java plugins?"
|
| This. Used Emacs for fifteen years professionally, and I gave
| up when I had to reinstall my laptop, as having intellisense-
| like features and easy navigation in Emacs is a complete pain.
|
| I actually did not intent to switch to VSCode, but after a
| couple of hours of scratching my head with list configuration
| files, I ended up "trying" VSCode, and after a couple of
| _minutes_, everything was working (completion, navigation etc.)
|
| After a couple of tweaking, clangd was plugged, and I had
| direct visual compiler feedback in realtime while typing code
| in the window.
|
| VSCode is not "better". It's just another world.
| NoGravitas wrote:
| I've used Emacs for 30 years, and I have no intention of ever
| giving it up, but IMO this is somewhat accurate. The package
| installation and configuration story on Emacs has gotten a
| lot better over the last ten years or so, but there really
| ought to be a kind of meta package installer and configurator
| that does exactly what VSCode does: when it finds a file that
| it doesn't handle specially but for which there is an
| existing package or set of packages, install those packages
| and configure them with reasonable defaults.
|
| Spacemacs does this, which is the main nice thing about it.
| Unfortunately, it also carries a lot of other baggage rather
| than _just_ doing this.
| brabel wrote:
| Emacs Prelude[1] does exactly that.
|
| It comes with very few extra packages installed, but when
| you try to open a file in a certain language, it will offer
| to install a set of "standard" packages for you that enable
| support for it.
|
| [1] https://prelude.emacsredux.com/en/latest/
| AzzieElbab wrote:
| - I've used Emacs for 30 years, and I have no intention of
| ever giving it up - why? I hear it is much easier to quit
| then vim :)
| vidarh wrote:
| I gave up emacs by writing my own editor... I realised I
| could write one in fewer lines than my emacs config...
| NoGravitas wrote:
| I have noticed that on average, I throw out my emacs
| config and start from scratch every ten years or so.
| bachmeier wrote:
| This is why I still use Emacs for a lot of things. Just not
| programming.
| globular-toast wrote:
| My emacs setup takes minutes to install on a new computer. I
| use borg, but there are many other ways to do it.
| mr337 wrote:
| I was thinking the same thing. I use spacemacs and have
| moved to about 5 laptops over the last five years. Just
| bring along the .spacemacs files and any supporting tools
| like ripgrep etc and I am up and running.
| oblio wrote:
| How long did it take you to assemble your setup?
|
| Wall time, not fuzzy memories a la "it takes 5 minutes to
| cook this".
|
| My bet? Tens, if not hundreds of hours.
| convolvatron wrote:
| my setup is 200 line long. on a new machine I just scp it
| over. many years ago they dropped support for
| automatically decoding files with a 'Z' extension, so I
| had to change that sometime in the 90s.
|
| total time invested over 40 years - less than 4 hours.
| Jtsummers wrote:
| I've probably spent less than 50 hours total over 20
| years on my emacs configuration. But it wasn't all at
| once. And now I just copy the .emacs file between
| systems. Tweaking it is maybe minutes a year now. If I
| want to do something with, say, Go, I just download the
| appropriate mode. The longest time spent was when I had a
| few bespoke languages at work that had no text editor
| support in _any_ editor. I wrote some minor modes to
| support them, that was probably 10 hours total with most
| of the time on the first minor mode, and the rest flowing
| quickly thanks to the prior experience.
|
| EDIT: For comparison, I've probably spent 100x that (if
| not more) on Linux configurations.
| donio wrote:
| Not the OP but yeah, it's definitely up there for me.
|
| BUT the big difference is that the decades old portions
| of my .emacs are still very relevant and in use every day
| while basically all the work I've sunk into configuring
| some long forgotten GUI junk has rotted away long ago and
| has to be redone over and over again.
|
| We all spend an enormous amount of time tinkering with
| things but unlike Emacs most of it is so ephemeral that
| it's forgotten the next day.
| globular-toast wrote:
| Countless hours. How long do you think a carpenter spent
| learning and developing t his tool kit?
| oblio wrote:
| I don't know about you, but my toolkit, which I'm
| perfecting, is programming language paradigms, design
| patterns, algorithms, programming language SDKs, popular
| libraries and frameworks, etc.
|
| And there isn't enough time in the world to become as
| proficient as I'd like for those, let alone if I'd waste
| time to optimize tools to get 99.999% efficiency with
| them.
|
| At some point your hammer is good enough and your saw is
| sharp enough.
| globular-toast wrote:
| > I don't know about you, but my toolkit, which I'm
| perfecting, is programming language paradigms, design
| patterns, algorithms, programming language SDKs, popular
| libraries and frameworks, etc.
|
| Well that's great but none of that gets anything done.
| You need to be able to write programs effectively.
|
| > At some point your hammer is good enough and your saw
| is sharp enough.
|
| Yeah. I don't regularly invest many hours into emacs. You
| asked how many hours went into it. Over the past 15 years
| it's countless hours. Over the past year, not many at
| all.
| pxc wrote:
| > 2) The first time you load many common filetypes (like Java
| for example), a box pops up saying "Do you want me to install a
| nice set of standard Java plugins?"
|
| Spacemacs also does this, and it's a big part of why I stuck
| around long enough to discover some of the plugins that make
| the Emacs world really special, like Org mode and Magit.
|
| I'm still no Emacs hacker, but I know enough to get by, and
| that a good starter kit can make me productive in Emacs in just
| a few minutes.
| sleepycatgirl wrote:
| Yee, very similar here, Though for me, Doom Emacs, very
| simple to set up, and was more or less just work for me.
|
| Though one day I will bother to configure emacs from scratch,
| but that day is not today.
| pxc wrote:
| I'm planning to use the next time I move to a new computer
| to switch to Doom Emacs and start over with some of my
| other, old dotfiles, too
| vintermann wrote:
| Vim is different enough that when its fans say it's superior,
| at least some people think it's plausible enough that it's
| worth learning. And even if they don't become appreciably more
| productive by it, at that point it's sunk cost and they might
| as well keep using it.
|
| The last time I had any reason to consider getting into emacs,
| was when I came across a proof assistant many years ago that
| basically required it - it used emacs to provide an interactive
| interface. Not unlike how everyone uses electron/chrome these
| days to quickly provide a familiar interactive interface. It
| was like an exotic artefact from a parallel universe where
| emacs' conventions became dominant instead of IBM and
| Microsoft's.
| wayoutthere wrote:
| I personally love Vim because once you know how to work it,
| you can code extremely quickly. You don't really even need
| any macros (though they can make you even faster) -- I find
| the default commands to be fast enough that I consider vim to
| be an "expert interface" for text editing.
|
| Also love the VS Code vim plug-in.
| agentwiggles wrote:
| The fact that vim-style modal editing can be implemented in
| other editors is huge. I use console vim frequently, but
| when I need to bump up to something more IDE-like (VSCode
| or a Jetbrains IDE), I can carry 99% of the vim
| functionality I use, and be up and running with a minute or
| two of config.
| jimbokun wrote:
| > Both points are really useful for getting started quickly,
| but would I imagine be really hard for emacs. The first would
| require changing default behaviour on first startup, the second
| would need accepting some set of people to decide the "default"
| sets of plugins.
|
| I actually don't think these are very hard from a technical
| perspective.
|
| The first has been done in the past. Aquamacs was a version of
| Emacs for Mac OS that supported conventional Mac keyboard
| shortcuts, in addition to the Emacs ones.
|
| The second should really just be a matter of matching certain
| file extensions and prompting to download the most popular mode
| for that file type. The Emacs package manager is very good, so
| it's a simple change to just include a mapping from file
| extension to Emacs package and trigger the prompt when opening
| a file of a given type for the first time.
| nobody9999 wrote:
| I read through the comments here a couple hours ago and heard all
| the same arguments that come up whenever folks talk about emacs
| vs. other editors|IDEs|platforms|OS's. As such, I didn't feel the
| need to add my own comment to the fray.
|
| But as I was scrolling through the front page, the _title_ of the
| article struck a chord.
|
| I'd say that emacs was _never_ popular. It is (and always was) a
| fairly niche product used by those who found something about it
| compelling.
|
| Even "back in the day" emacs usage was dwarfed by vi (vim didn't
| exist), notepad, Wordstar, WordPerfect and even ED/EDT[1].
|
| Full disclosure: I am a long-time emacs user (25+ years, preceded
| by using the Epsilon Programmer's Editor[0] -- a commercial emacs
| work-alike -- for 5+ years).
|
| [0] https://en.wikipedia.org/wiki/Epsilon_(text_editor)
|
| [1] https://en.wikipedia.org/wiki/EDT_(Digital)
| bitwize wrote:
| I still feel the same way now about this article that I did then:
| Popularity is a misguided goal for Emacs. Emacs is a hacker's
| editor. Back when I started using it, the OS I ran it on -- Linux
| -- was niche, and the editor itself was niche of the niche. It
| seemed to come with "power users only" signs guarding it. It had
| its own diskset in Slackware because it was big and heavy and not
| the kind of thing every Linux user needed to have so you could
| easily exclude it. It's designed to be shaped into a custom tool
| that does what you need the way you need it done, _as you work
| with it_. Not everybody works this way, not every _programmer_
| works this way. Many enterprise shops aim for a software factory
| approach where there is one common, blessed workflow and you
| train people in that workflow and just plug them right into the
| assembly line. Those people make up the vast bulk of developers
| and most of them wouldn 't know what to do with an Emacs if they
| had one. And that's fine.
|
| When those people start crossing over onto Emacs mailing lists
| and going "What Emacs needs is to work exactly like my favorite
| IDE, else it will die in obscurity" I'm just like, psh. Go away.
| You've got your own great big ballfield to play in, why do you
| feel the need to come in and start trying to set rules for our
| little one?
|
| In fact, this reminds me of a story. Back in the early 2000s
| there was a clown called Scott McCollum. An ultraconservative, he
| was fond of writing articles about how Linux and open source were
| communist cancer. McCollum had an acolyte named Joseph D. Wagner,
| who once trolled the gcc mailing list with a bug report about a
| TOTALLY CRITICAL SECURITY VULNERABILITY wherein gcc's optimizer
| would remove code to scrub sensitive data such as passwords from
| a buffer before reusing the buffer. When he was told "that's what
| 'volatile' is for" and to go fuck himself by the gcc maintainers,
| Wagner had an op-ed published on McCollum's site wherein he went
| "AHA! The open-source commies maintaining gcc don't care about
| your security! Use Microsoft Visual C++ if you want your software
| to be secure!"
|
| Because of people like that, I don't trust entryists from outside
| a community. I have reason to believe there's a good chance
| they're not acting in good faith for the benefit of the project.
| the_spacebyte wrote:
| As an Emacs user for ~10 years the greatest deterrent is it being
| single-threaded and lisp. I just can't understand the love for
| it. I've spent countless hours customizing my own configuration
| and I just can't enjoy lisp. Emacs's source code is also hard to
| understand and contribute to (let's not talk about lisp.h).
|
| I'd rather have a new editor (or emacs fully re-written) with the
| same mindset as emacs - near-full customization via a modern
| scripting language (lua?) and/or c/cpp plugins, and text-centric.
| I don't care for fancy UI or buttons it could even have the same
| look and feel which I love
| diegocg wrote:
| There is something weird about projects that choose a
| functional programming language as one of their pillars. When I
| read nixos documentation, there are constant references to how
| awesome and pure and functional their language is.
| e40 wrote:
| > lisp.h
|
| Wow. Been using and extending Emacs for 40 years and I've never
| had to even look at lisp.h or hack the C code.
| the_spacebyte wrote:
| That was mostly a "tongue in cheek" joke : ) What I meant was
| that the code base is overwhelming both because it has some
| years on top and I don't like/understand lisp that much
| gorjusborg wrote:
| That an emacs user holds that opinion is a bit surprising to
| me, as _to me_ most of the reason for me using emacs is to
| develop in lisp-inspired languages. I think lisp development is
| the raison d 'etre for emacs in the modern times.
|
| As someone who loves fennel, clojure, scheme, etc., I find
| myself drawn to emacs because the (repl driven) workflow is so
| good. That said, I've found that I can't give up vi-style modal
| editing. The interface matters to me. So neovim it is, for now.
| bsder wrote:
| I'm going to go out on a limb and suggest that Lisp is, in
| fact, an albatross hanging around Emacs neck.
|
| Using Lisp (and especially elisp) is not okay. Lisp has some
| _very_ sharp corners that simply are not acceptable in modern
| languages. I use Lisp when I 'm very resource constrained but
| still need an interpreted language--otherwise I use
| _anything_ else.
|
| Dynamic scoping is just stupid (fault of elisp). Not being to
| operate on a sequence is stupid. cons pairs to build
| everything is stupid. nil() terminated to signify lists is
| stupid. The pervasive _necessity_ of metaprogramming macros
| is stupid. An inability to type things is stupid.
|
| Lisp/Scheme encased itself in amber in the 1980's and refused
| to keep up with genuine improvements in programming
| languages. Sure it meant they missed out on the collective
| brain damage that was design patterns and object oriented--
| but it also meant that it missed out on good things, too.
|
| Take a very hard look at Clojure and look at what parts of
| Lisp/Scheme Rich Hickey put a bullet in and which parts he
| kept. The Lispers still excoriate Clojure as "not a Lisp" and
| that perfectly sums up the problems with Lisp nowadays.
| Jtsummers wrote:
| > Not being to operate on a sequence is stupid. cons pairs
| to build everything is stupid.
|
| There are other sequence types than lists in elisp and
| pretty much every other lisp out there. And what do you
| mean with "Not being [able?] to operate on a sequence"? [0]
| contains a bunch of functions for operating on sequences,
| and it's notable they don't say _list_ but _sequence_ in
| their signature. They work on multiple types of sequences,
| not just lists.
|
| I do agree on dynamic scoping by default, that's a major
| weakness in elisp.
|
| [0] https://www.gnu.org/software/emacs/manual/html_node/eli
| sp/Se...
| bsder wrote:
| Lisp "lists" (cons pairs with terminating nil) act kinda
| sorta like sequences (although the elisp names don't
| agree with Common Lisp names)--until you need length()
| and your algorithm blows up to O(n^2) or you replace a
| value and your list walker blows itself into a mess. This
| is part of why Clojure shot the idea of building lists up
| from cons pairs and gave explicit syntax for certain
| sequence types and made them fundamental.
|
| Which would be fine if all the pedagogy didn't teach
| stupid cons-pair lists and recursion as _THE_ fundamental
| pieces of Lisp when they should instead have a gigantic
| red klaxon saying "Don't use these outside of toy
| programs as they're a maintenance and abstraction
| nightmare."
|
| Other grief: #() syntax makes read-only vectors. The
| syntax for what is basically [] is every other language:
| (make-array 5 :fill-pointer 0 :adjustable t) I can go on
| and on and on about the usability disaster that are
| sequences and collections in Common Lisp. And then let's
| add the joy of a Lisp-2 on top of everything else.
|
| The problem is that the Real Lisp Programmers know to
| ditch those and go grab better abstractions when doing
| Real Programming. However, the extra abstractions are
| just annoying enough that stuffing things into an
| unlabeled list is too convenient. So, you see a small
| number of good abstractions and a bunch of little
| unlabeled "containers" passing data around with cadr and
| caddr. There is a reason why a "labeled struct" is a
| fundamental part of most languages and gets its own
| syntax.
|
| And even "Practical Common Lisp," which like I like very
| much, introduces macros before collections. And look at
| how much time it spends on vectors and hashes (which are
| _FAR_ more important to building most programs) vs cons-
| type lists (this ratio holds even as far back as
| Touretzky in 1986--it 's gotten a little better over the
| years). And then people wonder why nobody uses Lisp for
| real programming?
|
| So, sure, you can use the Common Lisp standard--and get
| saddled with a bunch of good design decisions from 40
| years ago that now look absurdly stupid.
|
| Or, you can use Scheme which has nothing built in and
| construct it all yourself. Oh joy.
|
| Alternatively, you can just use a modern language that
| made design decisions in merely the last decade.
| oblio wrote:
| Neovim?
| steelframe wrote:
| At the recommendation of an EE professor, I adopted EMACS as an
| undergraduate in the first few years of the 3rd millennium. I
| stuck with it for about 18 years, including stumbling through a
| handful of custom elisp scripts to get some stuff done that I
| wanted.
|
| With the advent of VMs in data centers, I found that constantly
| installing EMACS started to become a real chore, and vi was just
| always present in base images. Also, always needing to remap caps
| lock and left ctrl was obnoxious, especially as I moved between
| Linux, Windows, and MacOS environments. So last year I bit the
| bullet and went fully into vi.
|
| First I did some research into the scriptability of the editor,
| and upon learning that I could hook events via autocmd that call
| into custom Python code, that was it for me. I wasn't interested
| at all in struggling to figure out some arcane (to me) elisp
| invocation just to do some simple text manipulation, when I
| already knew Python well enough to just get done what I wanted
| with minimal trial-and-error. Plus the wealth of libraries
| available from pip and Vundle pretty much gives me all the
| extensibility and integration with other toolsets I could
| possibly want.
|
| I spent some time practicing the key combinations for stuff I
| would effortlessly "just do" in EMACS: split window, jump to the
| bottom window in the frame, open a buffer, find text, highlight
| and copy, jump back to the other frame, record macro and run it
| 12 times, yank words/lines, re-indent region, etc.
|
| Aside from muscle memory, there really wasn't anything keeping me
| with EMACS any more. I still am not quite as proficient in vi as
| I was in EMACS, but at the same time my career has moved away
| from 100% coding to more a mix of emails, documents, and
| occasionally some code, so maybe that has something to do with my
| departure from the EMACS world. I care more about the hassle of
| having to install EMACS in various environments I jump into as
| I'm working with nodes in the data center than I do about my
| level of comfort and proficiency in EMACS.
| [deleted]
| todd8 wrote:
| I've used full Emacs and Emacs style editors (mg, jove, epsilon)
| for over 40 years and programmed in LISP for longer than that. In
| the 1990's it was evident that Emacs was in decline.
|
| For a couple of years, I used Vi because IBM's lawyers were
| afraid of the GPL; during that time I found Vi to be a superior
| text editor than Emacs. Sometime in the late 80's, Emacs and the
| GPL were accepted by IBM's planners, and I switched back to
| Emacs. Quite a few of the AIX kernel developers did end up using
| Emacs, even though Vi had its advantages as a text editor. It was
| the customizability of Emacs and the ecosystem of high quality
| packages that drew me back to Emacs. (For example, a developer on
| my team wrote the tower of Hanoi command. Try it out: _M-x hanoi_
| ). Emacs became a general purpose tool for interfacing with your
| system. With Emacs, I didn't need a graphical terminal to work
| with multiple windows, I didn't need Norton Commander to have a
| powerful, portable interface to directory management. It has
| incredible outliner, mode for LaTeX, interface to git, etc., etc.
|
| My point is that it wasn't the text editing (Vi handled that
| better), it was everything else, and that everything else was
| enabled by Stallman's brilliant insight that the editor should be
| built around a powerful interpreted language, LISP.
|
| LISP was key to the success of Emacs. In the 1980's, people were
| excited about LISP; by the 1990's the excitement was wearing off.
| The LISP Machine companies weren't commercial successes. While
| some LISP compiler/interpreters performed well, Emacs Lisp was
| simply adequate. In CS programs, Scheme was being taught instead
| of the more fully featured LISP--Scheme has a simpler tighter
| core of fundamental features and consequently was a better choice
| for the ubiquitous undergrad Programming Language smorgasbord
| courses.
|
| I needed an embedded interpreter to be a key part of a
| distributed network of servers I was designing. LISP was my
| choice, but my companies own, very experienced, developers
| rebelled. Smalltalk, Prolog, and even building our own C-based
| language interpreter were all viewed as more acceptable than
| LISP.
|
| The way to make Emacs more popular isn't to persuade people that
| they want a customizable editor that requires a great deal of
| LISP expertise. That just won't happen. Pick a language from the
| one of the top 15 languages and allow Emacs customizations to be
| developed in one of these languages. Here's one measure of the 15
| most popular languages[1]: Python, Java, Javascript, C#, C/C++,
| PHP, R, Objective-C, Swift, Typescript, Kotlin, Matlab, Go, VBA,
| Rust.
|
| Out of the 15 languages listed above, many can be disqualified
| for obvious reasons: R and Matlab are not general purpose enough,
| Rust is far from interpreted and has a slow compiler, and so on.
| In my opinion, Emacs would be more popular if its core supported
| Python or Javascript or even Go (say running in a separately
| compiled process that interacted with the Emacs server via IPC).
| I'm not a Javascript person, but Javascript is likely the best
| solution; I would gladly take the time to learn how to use it for
| Emacs configuration and customization. If Emacs was customizable
| in Javascript, there would be an army of developers working with
| it.
|
| [1] https://pypl.github.io/PYPL.html
| jimmyvalmer wrote:
| I was nodding along to your recount until your recommendation
| for a new extension language. It wasn't your selection of
| language that rankled so much as the cavalier manner in which
| you suggest it. Replacing elisp with, say, javascript is
| tantamount to rewriting nearly all of emacs, a product of 40
| years (although presumably fewer man-years).
| User23 wrote:
| Ignore the hater's comments. Emacs is Lindy[1], will be around
| for another 40+ years, and no amount of ankle-biting will change
| that. Having used it off and on for a couple decades, I can say
| with confidence that the Emacs community and ecosystem has never
| been stronger. And thanks to the LSP, it's comparable in IDE
| features to other LSP capable editors. With the new in version 28
| type-inferencing JIT compiler[2], performance has also never been
| better.
|
| Emacs outshines all other editors in two major respects:
| discoverability and extensibility. These are two sides of the
| same coin. When I say discoverability, I mean how the editor
| actually functions, not just reminders for what the keybinds are.
| The internal calls can be instrumented, advised, and even
| rewritten. And this ties into extensibility. In other editors
| writing an extension is a full blown project. Let's say you
| identify a need while you're doing your real work. In most
| editors you now have to create a new plugin project and set up a
| bunch of boiler plate before you can even get started. By then
| I've already discovered what I need to do and hacked a solution
| in the _scratch_ buffer without getting dropped out of my flow
| for my real work.
|
| There's no denying that Emacs has its warts and that Elisp has a
| lot of historical baggage. Those who don't grok the Lisp approach
| to interactive development will never be able to understand why
| even an admittedly mediocre Lisp is a more frictionless
| development experience than anything they've ever used.
|
| [1] https://en.wikipedia.org/wiki/Lindy_effect
|
| [2] https://akrl.sdf.org/gccemacs.html#orge596749
| hnrj95 wrote:
| it's worth mentioning that there's been great work wrt emacs and
| its packages very recently. it seems somewhat revitalized, i
| think
| hosh wrote:
| I didn't start using emacs until (1) hardware became fast enough
| to run evil-mode with low keypress latency (because vim uses key
| sequences rather than chords and I type fast), and (2) Spacemacs.
| I switched to Spacemacs before there were a neovim, and if it
| weren't for spacemacs, I would have ended up with neovim instead.
|
| I have not had time to really dig into the code and customize my
| editor. I installed Spacemacs, some layers, and know just enough
| to keep the things I am used to there (such as layouts), and
| that's pretty much it. I really enjoy how Spacemacs organized
| things, and it has made it much easier to learn.
|
| I still typically use vim for quick-editing config files on
| remote systems.
| didibus wrote:
| As someone who picked up Emacs about 3 years ago, and now finds
| it to be my favorite editor, I think the only issue with Emacs is
| performance on large files and stability of builds on Windows.
| ho_schi wrote:
| The complain about the weird and twenty year old issue in Gtk
| questionable[1]. Gtk2, X11 and disconnecting a display and Emacs
| calls abort(). I cannot speak about EMACS because I prefer VIM
| and NEOVIM. My requirements are usability - where VIM excels with
| your knowledge (learning curve) - and LSP-Support. The later is
| provided since NEOVIM '0.5`[2] nearly ready to use. A modern
| editor should know what the user is actually doing and interact
| with the compiler, spell-something (languagetool?) or whatever :)
|
| LSP with NEOVIM? Requirements: 1.) VIM-PLUG
| 2.) NVIM-LSPCONFIG 3.) NVIM-CMP
|
| Your compiler will provide everything. In my case CLANGD for C
| and C++. Setup isn't hard but I would appreciate a HowTo directly
| at neovim.io or even built-in NVIM-LSPCONFIG and NVIM-CMP within
| the package. Because figuring out is hard, setup is not. Where
| GNU needs to catch up quickly is LSP with GCC, the compiler
| doesn't provide a user back-end. This is important and actually I
| want know what GCC things about my code - I'm using GCC to
| compile. EMACS and VI-Family will greatly improve through this.
| You don't need to like Microsoft because of LSP - but LSP is
| great.
|
| [1] https://gitlab.gnome.org/GNOME/gtk/-/issues/221#note_577021
|
| [2] https://github.com/neovim/nvim-lspconfig
| NoGravitas wrote:
| Strongly agree that there should be a GCC LSP server, and that
| Stallman's objections to the GCC features that would be needed
| to make one are Not Helpful.
| okasaki wrote:
| Emacs does support LSP: https://github.com/emacs-lsp/lsp-mode
| b3morales wrote:
| Eglot is another excellent LSP client implementation:
| https://github.com/joaotavora/eglot
|
| I slightly prefer Elgot's interface, which feels a bit more
| restrained, but both are excellent.
| SNosTrAnDbLe wrote:
| I have stopped using emacs from the last 5 years since I had
| problems with its key bindings. My left little finger ended up
| paying the price as that is what I use for control key. I still
| miss org-mode which I used for more than 10 years. It is one huge
| reason why I kept coming back to emacs even after all the hurt.
|
| From then on, I used sublime and now vscode to do text editing
| and an IDE like IntelliJ for development. My left little finger
| has gotten a lot better.
| therealcamino wrote:
| I hear you. The first thing I do on any new computer is remap
| the Caps Lock to be Control, for exactly that reason. It helps
| a lot.
| Mikeb85 wrote:
| 2021 and Emacs still my preferred editor (and I'm young enough,
| in my 30's). Yes it requires a bit more setup (not much more
| however, VSC also misses functionality out of the box). However
| that setup is saved forever, across machines in the form of your
| .emacs file, so whatever changes you make to make it personal
| stay with you. And it's really not much more difficult to setup,
| Emacs lisp is more intuitive than JSON files and as a programming
| language, it's pretty easy to understand that you invoke a
| function and then just pass it parameters, and that's about all
| you need to understand about it to set up the editor anyway.
|
| But there's literally nothing I don't have with Emacs that other
| editors provide. I have code completion in a bunch of languages
| (that pops up, with documentation pop-ups), linting, snippets, a
| project tree preview, project awareness, etc...
| canaus wrote:
| VSCode allows you to export settings and keybinds via JSON
| files.
|
| Also, saying EMacs Lisp is more intuitive than JSON is quite
| absurd. You could give a 15 minute presentation on how to read
| JSON to someone who knows how to use Word and they'd at least
| be able to read it. The same wouldn't be possible with any
| subset of lisp.
| Jtsummers wrote:
| Well, JSON is "just" a serialization format. I'd expect that
| to be much easier to teach someone than a programming
| language. That's a rather bizarre comparison.
|
| If _all_ you 're doing is serializing the configuration, then
| lisp's s-expressions are just as intuitive as JSON (in the
| sense that both can be explained in a few minutes).
| canaus wrote:
| Yes, it is a bizarre comparison because of that fact. A
| programming language will never be more intuitive than
| "just a serialization format".
|
| Also, the argument that lisp's s-expressions are just as
| intuitive as JSON is verifiably false because you can use a
| simple natural experiment: what is used more for
| serialization, JSON or s-expressions?
|
| It's extremely ironic to try and argue these points on a
| post that's entire theme is how to get more people to use
| an editor that is quickly losing market share to easier to
| understand and configure applications.
| Jtsummers wrote:
| Be careful not to mistake ubiquity with intuitive. It's
| arguable that BASIC is more intuitive than Javascript,
| but Javascript is more ubiquitous. That only tells us
| that it's more popular, but not why.
| canaus wrote:
| Would you say that BASIC is more intuitive for web
| development than JavaScript?
|
| The syntax of something is only one part of its
| intuitiveness. A large part is the context of which it is
| used.
| ReleaseCandidat wrote:
| > But there's literally nothing I don't have with Emacs that
| other editors provide.
|
| Hmm, refactoring, fixes of Flycheck errors (if the checker/LSP
| provides them), a Tramp mode that actually works. Oh, and I
| would like to be able to continue editing my file while Emacs
| is doing something else ;)
| gpderetta wrote:
| Fix-it and renames work with lsp+clangd. More complex
| refactoring would be nice, but in the end what is supported
| depends on the lsp-server capabilities.
|
| Emacs hanging at times has unfortunately been the reality for
| a looong time. There is extensive async support, but it is
| not always used were needed.
| ReleaseCandidat wrote:
| > Fix-it and renames work with lsp+clangd More complex
| refactoring would be nice
|
| I used (the paid version of) Xrefactory a long time ago
| with Emacs and C++, that really worked well.
|
| The Clojure-LSp has many code actions too.
|
| > Emacs hanging at times has unfortunately been the reality
| for a looong time.
|
| Well, at least 25 years :D
| slightwinder wrote:
| > However that setup is saved forever, across machines in the
| form of your .emacs file
|
| Until you use a plugin which is dead after the next update.
| Which happens a lot...
|
| > Emacs lisp is more intuitive than JSON files
|
| Not really. In the first place JSON is just data-format which
| usually is used through a proper GUI. There is not much you can
| do break there.
|
| > But there's literally nothing I don't have with Emacs that
| other editors provide.
|
| Which only means your horizon is too small to know the missing
| parts. Or your work is not specific enough to demand something
| not available in emacs.
|
| If you are satisfied with emacs, ok. Good for you. But how will
| it benefit the popularity of emacs?
| josteink wrote:
| > But there's literally nothing I don't have with Emacs that
| other editors provide.
|
| I like Emacs, have an extensive personalised config and use it
| as my primary editor across OSes.
|
| That said, I wish its debugging-support was better. Some
| simpler "just click to start debugging" options for a few
| popular platforms would be nice (Node, Python, .NET, Rust,
| whatever).
|
| I've heard there are similar efforts like LSP, except for
| debugging. Maybe they can help out Emacs' debugging-support,
| just like LSP helped improve Emacs' auto-completion and
| refactoring support?
| User23 wrote:
| You're looking for the DAP[1], which is pretty much LSP for
| debuggers.
|
| [1] https://github.com/emacs-lsp/dap-mode
| [deleted]
| criddell wrote:
| > But there's literally nothing I don't have with Emacs that
| other editors provide.
|
| Some IDEs that can semi-compile the code (to something like an
| AST) can provide a lot more support for refactoring correctly.
| Mikeb85 wrote:
| > Some IDEs that can semi-compile the code (to something like
| an AST) can provide a lot more support for refactoring
| correctly.
|
| Plenty of Emacs plugins invoke a compiler, language server,
| whatever to get information about the code. That isn't a
| feature unique to IDEs.
| criddell wrote:
| For example, in C++ in Visual Studio I can click on a class
| member variable or method and rename it and the IDE will
| rename all uses of that variable or method and not get
| confused about other classes with the same name.
| struct Foo { std::string name;
| int age; }; struct Bar {
| std::string name; double weight; };
| Foo f1 = ...; Foo f2 = ...; Bar b = ...;
| std::cout << f1.name;
|
| In the code above I can select "name" on the last line and
| rename it. The Foo struct and all instances of name via f1
| or f2 are updated to use the new name. Bar and instance b
| are untouched. AFAIK, Emacs can't do this.
| the-smug-one wrote:
| You use clangd and get it (as part of lsp-mode).
| yaantc wrote:
| Such renaming is part of the LSP protocol, so any LSP
| supporting editor (Emacs, nvim, etc.) will support this
| as long as the used language server does. I can do this
| with clangd and Emacs, but it's not Emacs specific
| anymore.
|
| There may still be some gap with some very advanced
| integrated IDE support, but the LSP ecosystem is still
| evolving and getting there. Which is not a surprise as
| Microsoft designed it for VS Code. The difference now is
| not so much between an IDE and a given editor, but
| between and IDE built-in language support and LSP servers
| for a given language. For C/C++ the progress of clangd is
| real over a few years, and it's very usable now.
| ReleaseCandidat wrote:
| >Plenty of Emacs plugins invoke a compiler, language
| server, whatever to get information about the code.
|
| Yes, but Emacs (at least the LSP-modes of the languages I
| use) doesn't offer the same refactorings and code fixes
| like the same LSPs do with e.g. Code. Treesitter doesn't
| work with many languages, so syntax highlighting is also
| lacking for many languages.
| natded wrote:
| Not possible until they simply suck it up and pander to plebs. I
| can have a development environment setup in VSCode in under 5-10
| minutes in most cases; you cannot even begin to understand Emacs
| configuration (let alone what you need to google). You need to go
| heavy into the language itself.
| vzaliva wrote:
| Emacs distributions I think is a good way to make it more
| popular. Out-of-box emacs install is very dry and unappealing.
| There are many packages which could be installed to make it much
| more modern and user-friendly. Emacs distributions which pack
| emacs with a list of packages and default customizations is the
| right direction. I've seen many new emacs users who started using
| spacemacs but would probably be put off by learning curve of
| standard bare-bones emacs.
| ashika wrote:
| mass appeal is overrated. being able to use terminal mode over
| ssh is more useful to me than rounded buttons.
| gopiandcode wrote:
| I see many people on here (likely non-emacs users) claiming that
| Emacs is obsolete/outdated/dying by completely misunderstanding
| its position in the ecosystem.
|
| Maybe it's easier to understand via analogy. Let's consider cars.
| Of the global population of car users, relatively few of them are
| F1 racecar drivers. Furthermore, you can easily make the case
| that the particular features (aerodynamics, speed etc.) that make
| the F1 a good racecar, would not be useful for the average driver
| - the time they spend honing their skills to handle such a beast,
| you could argue, would be better spent on other things. But, at
| the same time, the F1 car has and will continue to have a place
| in the car ecosystem.
|
| In the case of developers, you might be right that, for the
| average developer, working on your run of the mill, mundane,
| forgotten-in-a-few-years, CRUD web apps, a normal _average_ car
| (M$ vscode) would be a better investment, but no matter what, you
| will _never_ be as fast or flexible as an F1 car (GNU Emacs).
| mnd999 wrote:
| That's a terrible analogy. An F1 car isn't flexible, it's
| highly specialised.
|
| And there are roughly 20 F1 drivers on the planet at a given
| time, are you suggesting the total audience for emacs is about
| 20?
| FredPret wrote:
| I know right, are there actually 20 people who want to use
| Emacs!?
| medo-bear wrote:
| 21
| asah wrote:
| 22
| npmaile wrote:
| 21
| masterof0 wrote:
| 22
| donio wrote:
| Yeah, that sounds about right. And not to mention that with
| the 5K+ packages currently on MELPA we each had to write
| 250 of them. It's rough.
| FredPret wrote:
| At least you had Emacs!
| GhettoComputers wrote:
| A better analogy is a non fuel injector vehicle that doesn't
| need electronics to fix, is old and consistent, that works the
| same. It's like x.org, you can rely on it to not change the UI
| constantly (like gnome breaking something in every version).
| passivate wrote:
| I don't think your analogy holds up. If you race an F1 car
| alongside a commuter sedan, it is obvious to anyone observing
| the differences in performance, handling, traction, etc.
|
| So going by results, if emacs was so awesome and if it gave
| such a huge boost, then we would see those results, and it
| would be trivial to convince anyone to switch to it.
|
| Personally, I don't see editing text as a bottleneck for
| developer productivity. The vast majority of time is spent
| reading code, thinking about code, stepping through/debugging
| code, reading specs, etc. Yes, emacs can do those things to (as
| can any system that supports plugins), but my point is that we
| don't see a 'competitive edge' where all the most productive
| developers use X. What we see is productive developers using a
| wide variety of tools. Going back to your F1 analogy, there
| isn't a single sedan winning F1 races.
| WastingMyTime89 wrote:
| > but no matter what, you will never be as fast or flexible as
| an F1 car (GNU Emacs).
|
| The massive flaw in your analogy being that Emacs has more to
| do with an old and crumbling collection racing car than a F1.
| Its users constantly need to tinker it to make it somewhat run
| like a normal car. It's still slower and less ergonomic but
| they are blinded by their love and habit to its obvious flaws.
|
| The amount of IDE and editors that just work well with little
| customisation and have great refactoring features is now so
| high, it leaves little place for emacs.
| klodolph wrote:
| I would love to meet this mythical Emacs programmer which is
| blinded to its flaws, I don't think they're common.
| WastingMyTime89 wrote:
| There are people in this thread talking positively of ELisp
| (a shameful language even by the low standards set by other
| Lisp) and who thinks the emacs GUI experience is acceptable
| in 2021. Some are even arguing that having to write 1000
| lines of the previously cited terrible language to get the
| UX behaviours everyone has been expecting from a text
| editor in the past three decades is a worthwhile time
| investment. I would argue that apparently they are
| numerous.
| throwaway2331 wrote:
| I'm thinking about converting to a modern IDE away from
| emacs-nox.
|
| What can they do that emacs can't?
| klodolph wrote:
| There's very little that they can do that Emacs can't.
| It's just that if you're on the easy path, the IDE will
| give you a pretty high-quality experience with very
| little time spent configuring it. The "easy path"
| supports more and more use cases each year, but my
| experience is still that the more custom your build
| system is, the more likely it is that you'll not get your
| nice IDE integrations. That's was true in the 1990s as it
| is today.
| throwaway2331 wrote:
| Any recommendations for one that runs on Linux?
| klodolph wrote:
| It sounds like you are saying that people who don't share
| your opinion on ELisp are blinded to its flaws... but
| that doesn't make sense. Are you saying that?
| oblio wrote:
| I've read a bunch of articles where long time Emacs users
| are put into a position where they have to achieve
| something on a tight deadline. Many of them try to muddle
| through their Rube Goldberg contraption of a local config
| and under time pressure or advised by someone else they try
| a modern IDE and suddenly realize why many professional
| developers use them.
|
| They realize that despite the potentially subpar text
| editing experience, a highly polished modern Integrated
| Development Environment is a power tool and a productivity
| machine for the environment it's aimed at.
|
| One simple example, maybe Emacs can do this. Can Emacs
| through a press of a button, show a tooltip or a hovering
| window, directly over the text where my cursor is? Not
| another window to the side of the editing window or below
| it. I want my eyes to be stationary and I want the tooltip
| to be easily dismissable.
|
| Plus, IDEs have professional developers writing
| integrations so I don't have to, and they're paid to do
| that for tens of thousands of paying customers, so they
| pretty much are guaranteed to work. They are also pretty
| much guaranteed to work well with other advanced integrated
| features.
| PaulDavisThe1st wrote:
| 1. I'm a long time Emacs user (30+ years) _and_ a
| professional developer. Trying to contrast one of these
| versus the other as you do twice in your comment isn 't
| really helpful or useful.
|
| 2. Why would I want to put a tooltip over an emacs
| window?
|
| 3. The things that contemporary IDEs can do that Emacs
| may be clunkier at are mostly things I'm not interested
| in doing. They are also often addressable in totally
| different ways. The speed of tools like ag(1) and their
| integration into Emacs changes the need for Emacs itself
| to be able to take me to special places in a codebase,
| for example.
| oblio wrote:
| > 2. Why would I want to put a tooltip over an emacs
| window?
|
| Why would you want to? I don't know.
|
| But <<I>>'d want to :-)
| convolvatron wrote:
| which is all absolutely fantastic if you are following
| the script.
| oblio wrote:
| The script these days is a lot more flexible than it used
| to be back in the 90's with Visual Studio.
|
| It's flexible to cover maybe 90-95% of development needs
| for the main language targeted.
|
| And for those clearly defined use cases, modern IDEs
| generally fly. Which is far from guaranteed with bespoke
| configurations (Emacs, Vim).
| klodolph wrote:
| 90-95% of my time is spent working in at least two
| languages. Usually JavaScript and some backend language,
| like Go or Python.
| oblio wrote:
| And modern IDEs support 2 languages at the same time.
| Heck, they support dozens if not hundreds of languages at
| the same time.
|
| Eclipse has Javascript and Python plugins, for example so
| you can code in Java, Javascript, Python at the same
| time.
|
| VS Code has a ton of language plugins you can use all at
| the same time.
|
| IntelliJ has a ton of language plugins you can also use
| all at the same time.
| ReleaseCandidat wrote:
| > And modern IDEs support 2 languages at the same time.
| Heck, they support dozens if not hundreds of languages at
| the same time.
|
| No, they don't. Show me the IDEs with Common Lisp, Coq,
| Ocaml, Haskell, Elm, ... support. That's actually the
| reason Code is a real alternative to Emacs and Intellij
| isn't.
| ReleaseCandidat wrote:
| I wouldn't use Emacs for that, and I use Emacs since more
| than 25 years.
|
| Emacs shines when using Coq (with Proof General) or
| Common Lisp or Clojurescript (I guess Clojure too). But
| for mainstream languages like JS, Go or Python you're
| better off with something like Code.
| klodolph wrote:
| I split my time between Emacs, Rider, and VS Code these
| days. Of those, I spend the most time in VS Code.
|
| I have spent way more time fighting against the VS Code
| configuration than I would like, and even comparing it
| against all the time I've spent customizing Emacs over my
| lifetime, I don't think VS Code can come out ahead. All
| this because I'm not building my project with some build
| system that has a simple, easy integration with the IDE.
| When VS Code instantly works, it's great. Otherwise, I'm
| editing JSON configuration files. That doesn't seem like
| some massive improvement over editing your .emacs file.
| It's often worse.
|
| Often it comes down to working with larger projects
| written in multiple languages. If you are working on some
| bog-standard JavaScript project that runs in the browser,
| Node.js, or both, maybe you won't run into this stuff.
|
| Emacs is my escape hatch for "damn, VS Code is messed up
| again, and I just want to work on the code instead of
| fussing about". I've had major problems getting VS Code
| to deal with the C or C++ code that I work on, like, at
| all. I'm hesitant to even try CLion because it sounds
| like many of the problems are the same there (it has
| great CMake integration... but I don't use CMake).
|
| > One simple example, maybe Emacs can do this. Can Emacs
| through a press of a button, show a tooltip or a hovering
| window, directly over the text where my cursor is?
|
| That's how code completion works in Emacs. Integrates
| with LSP, if you want, with various fallbacks.
|
| LSP has really leveled the playing field between IDEs and
| Emacs. It lets you get a lot of the high-quality
| integrations, and they work well in both Emacs and IDEs.
| Prior to LSP, I'm going to say that the only easy way to
| get that kind of tooling was to use an IDE for a specific
| language, and it only worked well if your build system
| was integrated with that IDE.
|
| > Plus, IDEs have professional developers writing
| integrations so I don't have to, and they're paid to do
| that for tens of thousands of paying customers, so they
| pretty much are guaranteed to work. They are also pretty
| much guaranteed to work well with other advanced
| integrated features.
|
| My experience with C++ mode in VS Code is _extremely_
| rough.
|
| This is the age-old problem... I remember reading people
| making the same complaints about IDEs and text editors on
| newsgroups in the 1990s. Like, if you are a Mac
| programmer, you want to use CodeWarrior... if it works.
| If you have a more complicated build system, then you
| need MPW. Too bad.
|
| The experience with IDEs is getting better, much better,
| and I think all that is really happening is that Emacs
| users occasionally pop their heads over to IDE-land to
| see if will work for them. Sometimes it does, and you get
| one of those articles you're talking about.
| ReleaseCandidat wrote:
| > My experience with C++ mode in VS Code is extremely
| rough.
|
| That's because you're supposed to use Visual Studio for
| everything VS can do at all.
| klodolph wrote:
| Visual Studio can't do it at all, I'm afraid. That's why
| I'm not using it.
|
| I'm fairly familiar with it, and how it's integrated with
| MSBuild, and what the limitations of MSBuild are, and
| whether I'm comfortable working within those limitations
| (and porting my code to Windows).
| pvaldes wrote:
| > Can Emacs through a press of a button, show a tooltip
| or a hovering window, directly over the text where my
| cursor is?
|
| Let me check...
|
| Yes, it can do it. In org mode at least.
| garren wrote:
| The VS Code/normal car and emacs/F1 racer analogy seems weak.
| VS Code can bring most of the functionality of a relatively
| well tuned and customized vim or emacs setup to a much broader
| range of developers, and with very little investment. Less time
| spent gold-plating and polishing an editor's configuration is
| more time spent solving actual problems.
| btreecat wrote:
| There is no world, in which "flexible" and "F1 Car" belong in
| the same sentence. By design, a track car gets rid of anything
| "flexible" for highly optimized choices.
|
| If we want to assign a car to emacs, it's more like a Toyota
| Tacoma, with no body. Rugged, flexible, some basic building
| blocks that function out of the box.
| bitwize wrote:
| Emacs is more like a car from a Mad Max film than it is an F1
| racer: each instance of Emacs has been so heavily modified
| (often in haphazard, kitbash fashion) that it's only ever
| supposed to be driven by one person: its owner.
| PaulDavisThe1st wrote:
| Some of us want a car that is intimately adapted to how and
| where we drive.
|
| Some of us want a car that any of our relatives can just jump
| in and use.
|
| Both goals make sense.
| mjh2539 wrote:
| I think a better analogy would be comparing a Mercedes W123
| (Vim/Neovim) with a Toyota Camry or Honda Accord
| (VSCode/Jetbrains) with a Jeep Wrangler (Emacs).
|
| Yes, the Jeep Wrangler will topple over while trying to go
| through a ravine (which no other mass-produced four-wheeled
| vehicle would ever be capable of going through), but that's
| what after-market rollcages are for.
| lpcvoid wrote:
| In my opinion Jetbrains products are vastly superior to
| VSCode in every metric except price.
| deworms wrote:
| There's that condescending attitude again. In your fantasy land
| Emacs is an F1 race car, and everyone else is a CRUD-writing
| code monkey that drives a cheap sedan.
|
| In reality though, Emacs is a subpar editor for both everyday
| and specialized tasks that's fallen into obscurity as its
| maintainers refuse to implement anything that would make it
| keep up the pace with superior editors.
| rollcat wrote:
| With 15+ years of daily Emacs usage, I couldn't agree more.
| It's 50% force of habit, and 50% the few commands (align-
| regexp! kill-rectangle!), packages (magit! tramp!), or custom
| Lisp snippets that make every other editor feel inadequate...
|
| Until your Emacs process is hung again, waiting for IO, or
| can't process a "jump to definition", or chokes on a file
| with extremely long lines, or the stitched-together macOS
| dark mode switcher daemon has crashed, ad infinitum.
|
| Yes, it's a race car, but from 1987, and in total disrepair.
| sbuttgereit wrote:
| Hmmm... I agree that Emacs is specialist, but at least half the
| reason I don't use it is that it tends to be fairly sluggish if
| you start really configuring it and using it.
|
| Rather than an F1 race car, maybe the analogy would be better
| made to one of those backhoe/front loader combos. While it
| won't do simple operations like getting you from point 'A' to
| point 'B' as quickly, you can do more once you get there as
| compared to the family sedan. Of course, once you do get there
| you have to invest substantial time learning how to use the
| backhoe, the front loader, how not to tip it over, how not to
| inadvertently break stuff with it, etc. But once you've taken
| all that time and practiced it enough... you can do quite a
| lot.
|
| That metaphor feels very much more Emacs like.
| kqr wrote:
| It sounds like you know very little about either F1 cars or
| Emacs. Emacs is more like an older Toyota pickup truck - been
| around for a long time, ubiquitous, flexible, can carry a load,
| simple, there's an abundance of spare parts, and there's no
| problem with it that a good mechanic cannot fix - most problems
| can be fixed even by improvisation in the field.
| pkulak wrote:
| I still like the idea that professional tools, while too much
| work for most, are worth the effort to master, in a
| professional setting.
|
| Your analogy works too, but it's parallel.
| Zababa wrote:
| I don't want to sound rude but I've never seen a well executed
| car analogy, especially when they use F1 racecars. Your analogy
| doesn't make the position of Emacs easier to understand at all.
| dagw wrote:
| _you will never be as fast or flexible as an F1 car_
|
| F1 race cars are literally the least flexible cars available.
| They are designed for exactly one type of racing and there is
| hardly anything you are allowed to configure the way you want.
| There are cars with higher top speeds than F1 cars, and cars
| that accelerate faster. A $2k second hand Honda Civic will beat
| the crap out of an F1 car around a gravel track. F1 cars aren't
| even the fastest design for racing on F1 race tracks. F1 cars
| are only good for one thing, and that is winning F1 races.
| f00zz wrote:
| > F1 cars aren't even the fastest design for racing on F1
| race tracks.
|
| I found this a bit confusing. Why is that, do F1 races have a
| speed limit? I openly admit my ignorance about F1.
| rodgerd wrote:
| > Why is that, do F1 races have a speed limit?
|
| F1 cars are mostly optimised for massive aerodynamic
| downforce and lightness, which allows for unholy levels of
| braking, acceleration, and cornering speeds, but eventually
| the downforce hobbles top speed.
|
| The LMP (Le Mans) formula of a couple of years ago has
| heavier cars with higher peak outputs, but lower downforce.
| They're slower around an F1 style track because their
| cornering and acceleration suffers due to the extra weight,
| but they have a higher top speed if they're on a long
| straight.
| windthrown wrote:
| There isn't a speed limit but by placing strict limitations
| on the engine design, they indirectly limit the speed of
| the cars.
| AtNightWeCode wrote:
| There are a lot of rules to reduce cost, assure safety and
| to make it more competitive. You can not for instance have
| moving parts. If you could the top speed would increase a
| lot.
| skytreader wrote:
| I'll defer to someone better informed than me but I
| understood that as a reference to the rules and regulations
| around F1 cars.
|
| The "Formula" in "Formula 1" means there are certain
| constraints (i.e., the _formula_ ) to how you can design
| your car. Very quick illustration, check out the buzz on
| the new F1 car spec for next year. It is already touted to
| be _faster than this year 's cars_ mostly because of aero
| changes.
|
| Even easier illustration: the current (and I assume all
| future) spec has this halo whose sole purpose is to protect
| the driver. It's a ~7kg frame that's basically dead weight
| to the car. You can remove that and instantly gain maybe a
| few seconds of laptime at the expense of safety (I am in
| favor of the halo's presence, btw.).
|
| The spec aside, the rules and regulations also _try_ to
| enforce a competitive line-up so they regulate budget and,
| next year, wind tunnel testing time. So in theory if teams
| had carte blanche for car R &D we can have faster cars. But
| they won't be F1-compliant so they lose by default.
| rurban wrote:
| Having worked in F1 that's entirely wrong. A Honda Civic will
| not even beat a F1 car in the first gear, which goes up to
| 180km/h. With an unlimited engine of ~24k rpm and a chassis
| which sucks around each curve nothing can be compared to a
| F1. If there are curves. On a straight track there are faster
| cars for about 4 seconds, but then the F1 overtakes. Our
| usual estimate was that everything in a F1 car was about
| 1000x better than in other cars. Gearbox? Engine? Chassis?
| ECU, TCU, tires, you name it
| SeanLuke wrote:
| You're really claiming that an F1 will beat a Civic on a
| gravel track? Or perhaps you misread?
|
| How about in the snow? How about a road with random 2-inch-
| high debris? How about a road with lanes of uneven
| pavement? And how's that air conditioning in the F1? Great
| for transporting kids too.
|
| The F1 is designed to do exactly one thing exceptionally
| well, at the expense of practically everything else. It is
| the _opposite_ of flexible.
| h2odragon wrote:
| Gimme an F1 chassis and i'll put tractor tires on it for
| the snow. I'd be delighted to give it a try. I'm sure my
| mechanic buddy would help for the giggles too.
| [deleted]
| dagw wrote:
| _Our usual estimate was that everything in a F1 car was
| about 1000x better than in other cars._
|
| And none of that will matter after the first time you drive
| over a 6 inch rock
| ReleaseCandidat wrote:
| > Our usual estimate was that everything in a F1 car was
| about 1000x better than in other cars.
|
| Well, I can't say that I like cars or enjoy driving them,
| but the biggest advantage of a car compared to a bike is
| its roof - at least, when it rains.
| drumhead wrote:
| I used Emacs, its a lot more than just a simple text editor,
| its more powerful than a text editor or even many IDEs. But the
| learning curve is too steep for most people. With VScode I can
| just install it and start working straight away, I cant really
| do that with Emacs. I dont want Emacs to die out or fade away,
| but lets be honest its for a much smaller group of users. It
| they want it to be be popular it would have to change, but then
| it wouldnt be Emacs anymore.
| sigzero wrote:
| That about sums it up.
| Ologn wrote:
| > claiming that Emacs is obsolete/outdated/dying > run of the
| mill, mundane, forgotten-in-a-few-years, CRUD web apps, a
| normal _average_ car (M$ vscode)
|
| With regards to obsolete and outdated - I started using vi and
| emacs back in 1989 (I currently use vi more). The keybindings
| and such I learned back then are still relevant.
|
| In my day job, I mostly program Android. Before 2014, I
| programmed with Eclipse and an Android plugin, which is what
| Google suggested. Then Android Studio was released, which is
| what Google suggested. As I haven't used Eclipse at all since
| around 2014-2015, Eclipse, to me any how, has become
| "obsolete/outdated". Yet I'm still using vi (and emacs) as I
| have since the 1980s. They have not become outdated, I still
| use them as I always have.
| bch wrote:
| I just love that for a moment here we've put aside our
| differences about emacs vs vi and focused our efforts on bike
| shedding which car analogy best fits. Peak computing culture.
| skytreader wrote:
| I wouldn't waste keystrokes on the classic religious war
| being waged in this thread so I'm gonna throw my hat in this
| arena instead. I agree with you---that analogy sucks.
|
| Being able to drive an F1 car comes with excellent financial
| opportunities. Even if I'm not "on the grid" (i.e., actively
| competing in the GPs), I can be a test driver. Heck the
| license required to drive an F1 car opens other doors in
| itself (maybe in other motorsports, but also allegedly the
| range of vehicles you can drive).
|
| In contrast, if I am proficient in emacs I am...proficient in
| emacs. I edit code in a manner that is visually impressive to
| maybe three persons in the CS department. I'd have an ever-
| so-slightly deeper connection to RMS than your average CRUD-
| slinger. I am out of advantages to enumerate and I'm trying
| very hard.
|
| Maybe text editors are about as similar to cars as apples are
| to buildings.
| nextos wrote:
| I think the right POV is that Emacs is a text-mode Lisp VM,
| or at least the remains of one. Whereas vi is just a
| (great) modal editing interface. They are not comparable.
|
| Actually, vim is not a very good implementation of vi's
| principles.
|
| Concerning Emacs, as a heavy user I think it needs 4 things
| to stay relatively popular. I don't think it will be ever
| super popular, and that's fine:
|
| * Get popular workflows to work with zero configuration.
| Some packages like AuCTeX, Magit or Notmuch are great at
| this. But many programming modes require adding too much
| code to init.el (or .emacs), this code breaks often and it
| is poorly documented.
|
| * There are too many half-finished packages for some tasks,
| mostly programming modes. Variety is great, but too much
| fragmentation is hurting the ecosystem.
|
| * Look at things that other editors are doing better,
| mostly VS Code. In the past, this approach motivated
| implementing a package manager (ELPA), which was a _huge_
| step forward.
|
| * Get better documentation. It's hard to find up-to-date
| information for many packages. Besides, the tutorial
| focuses too much on keybindings and doesn't talk about
| Emacs core principles. So, to a beginner Emacs looks like a
| bunch of keystroke tricks that make zero sense.
| goohle wrote:
| VI is modal text editor (think JEdit). Emacs is IDE
| (think Eclipse).
|
| Vim can be upgraded to IDE with plugins, and Emacs can be
| downgrade to a plain text editor, so they are comparable,
| but their primary goals are different: Vim focus is on
| editing of text, while Emacs focus is on integration of
| editor with tools.
|
| If you need a development environment, then forget about
| Vim, JEdit, nano, pico, etc. If you need just a text
| editor, then forget about Emacs, Eclipse, Idea, VSCode,
| etc.
| avgcorrection wrote:
| My eyes roll so hard at mentions of the "religious war"
| that my eye doctor has had to put them back in their
| sockets multiple times.
|
| The Vim vs. Emacs "war" _meme_ has far surpassed the
| supposed rivalry itself; the two programs are so different
| that you might as well be comparing a, I dunno, a megaphone
| to a woodchipper. (What, the analogy doesn't make sense,
| you say? Well exactly.)
|
| The two programs attract not only people with different
| _temperaments_ but also people with completely different
| _needs_ and wants.
| deworms wrote:
| If you need to install a dozen plugins (helm, projectile,
| company/autocomplete, flycheck, whatever else) to match something
| that's installed by default in any modern text editor, Emacs will
| never be remotely popular. Even something as simple as theming
| doesn't work by default; each theme needs to be implemented
| separately for every mode. 99% of people will see how fruitless
| it is to try to configure it and move on. Why waste time on
| fiddling with configs?
| p2t2p wrote:
| Exactly that, plus it doesn't really serve well as platform. I
| mean VSCode renders Markdown previews correctly, not some ASCII
| based approximation. It renders images if I happen to click on
| one. Extensions can actually provide decent UI, thank's to that
| CSVs never looked better in my text editors.
| underatree wrote:
| I use Emacs's markdown mode for syntax highlighting.
|
| I have never used live export, but looked for it in its
| dropdown menu, found it, and clicked it:
| https://i.imgur.com/0LG6nnS.png
|
| It renders images and doesn't rely on ASCII for its
| rendering.
|
| I agree Emacs could benefit from some polish, on the whole.
| p2t2p wrote:
| I compared it two what I see in my VSCode
| (https://imgur.com/a/u9naqVi) and fair enough, it got way
| better since I tried it last time.
| AlanYx wrote:
| Both the examples you give seem kind of arguable; I'd almost
| say they demonstrate the opposite.
|
| The problem with VSCode's built-in Markdown previews is that
| they're not extensible, so there are a variety of alternate
| Markdown renderer plugins, for example to better work with
| the various wiki-like Markdown plugins. Emacs also has
| Markdown previewing, but it is extensible by design.
|
| I'm not an expert in either VSCode or Emacs (I use both off
| and on), but inline image handling seems like it works better
| in Emacs. I've never figured out how to show Markdown images
| inline in the actual text editor part of VSCode (as opposed
| to the preview), whereas that's super easy in Emacs.
| wirrbel wrote:
| Emacs' user base is probably larger than any time before.
|
| Granted, market share dropped because many people are never
| exposed to Emacs (or vim), directly start with PyCharm, VSCode,
| etc.
|
| The question is: Can emacs increase its market share by
| becoming more approachable? Probably yes, on the other hand
| since Emacs is so different to the User Interface expectations
| of 2021, it will always have a hard time.
|
| I myself have been a hardcore vim user for now 20 years, in the
| last 2 years I have made an effort to learn Emacs and like it
| quite a bit. I am also a VS Code user at work.
|
| > Why waste time on fiddling with configs?
|
| Config fiddling is not specific to emacs. The time I spent
| fiddling with VSCode configs and plugins, or IntelliJ config.
| The difference is that with emacs I see the result of my
| fiddling in the form of emacs lisp code that I can store and
| easily transfer from computer to computer and for the IntelliJ
| stuff I had to take notes on what I changed where so I could
| reproduce it.
| azeirah wrote:
| I just find it a little saddening although very
| understandable that at this point Emacs just simply isn't
| better for writing code than any Jetbrains product.
|
| Yes I'm very aware that there are plugins, stand-alone
| terminal tools to integrate, language-server-protocol and all
| that... But it's just that Jetbrains tools have far deeper
| intelligence about your code. By default.
|
| I tried hard to like Emacs, and I did end up liking it, I
| just don't know for what workflow.
|
| Knowledge work? Obsidian
|
| Working on large coding projects? Jetbrains IDEs
|
| Working on scripts or quick edits? Sublime Text or sometimes
| vscode
|
| Need to make a change to bla.config from the terminal? (n)vim
|
| I think the only advantage Emacs really still has to offer
| nowadays is that it's general enough to be able to do all of
| the above very well to quite well. None of those tools comes
| close enough to be able to do all of those workflows. Yes you
| can force sublime or vim into becoming a workstation for all
| of the above, but then it will become very bloated and slow.
|
| It also doesn't help that Emacs is very archaic. I can teach
| you Obsidian, Sublime and vs code in a day, I can teach you
| jetbrains IDEs in a month, but it will take me years to teach
| you to use emacs effectively.
| pxc wrote:
| > Working on large coding projects? Jetbrains IDEs
|
| IME language support and a desire for intellisense type
| features is a bigger factor. JetBrains generally has
| excellent support for that across the board, and it's
| sometimes lacking for some languages with Emacs
|
| but size of the codebase doesn't really matter. At work we
| have a sizeable PHP codebase, and it's just as fast, if not
| faster, to navigable with ripgrep and fzf or editor plugins
| based on them as with a JetBrains IDE
| thunderscore wrote:
| > for the IntelliJ stuff I had to take notes on what I
| changed where so I could reproduce it.
|
| IntelliJ (and all other variants), stores setting in code
| (xml) too. It's not as exposed or clean as a single .vimrc or
| .emacs.d/init file but it does the job. You can easily export
| the settings or have them auto sync via your jetbrain
| account.
| tincholio wrote:
| > each theme needs to be implemented separately for every mode
|
| I am not sure whether you're trolling or just completely
| clueless about Emacs (despite your claims of using it for many
| years).
| rafamaddd wrote:
| your argument that a text editor is not going to be popular
| because you need to install a dozen plugins to match what would
| be considered "modern" doesn't add up. I can see a thousand
| reasons why emacs is not popular but having to install plugins
| is not one of them. VSCode itself needs a bunch of plugins for
| certain languages, and even if you used it for the out the box
| languages (e.g. JavaScript) there's a couple of things missing
| that and IDE would have out the box (I agree that emacs would
| need much more plugins compared to VSCode).
|
| Also, look at vim/neovim. They are still one of the most
| popular text editors (much more popular than emacs for
| example), look at the stackoverflow developer survey, in the
| last one neovim was ranked the most loved text editor and vim
| is ALWAYS ranked between on of the most used editors. You need
| a dozen plugins if you want anything close to a modern IDE, yet
| they are still very popular and used.
| NoGravitas wrote:
| Agreed about plugins. The main nice thing about VSCode is
| that it installs and reasonably-configures needed plugins as
| needed (though Spacemacs does this, too).
| PaulHoule wrote:
| I used to be an emacs partisan, but line continuation characters
| killed it for me.
|
| With vi I can cut and paste into other applications on the
| desktop, with emacs I can't.
|
| I'm not going to accept the "just customize it" argument because
| if you do any administration at all you will sometimes log into a
| machine that you've never seen before.
|
| Sometimes you're going to log into a machine that is damaged.
|
| In that case you should be facile with whatever editor is already
| installed on the machine.
| philsnow wrote:
| Emacs doesn't lend itself well to running on machines you've
| never logged into before, or ephemeral machines/containers/etc.
|
| It's not a tiny sleek thing that you can start anywhere and
| have the same experience (that's nano or vi), but if you let
| your local Emacs eldritch horror reach out with its noodly
| appendage to whatever you're trying to edit, you'll have a much
| better experience.
| bondolo wrote:
| Editor fetishism should have died in the last millennium.
| iLemming wrote:
| Ehm. I think it's natural, and there's nothing wrong with that.
| I'm not a musician but I think, for example, guitar players do
| fetishize their instruments and have their favorites, no?
| xedrac wrote:
| I've used Emacs for about 5 years now, exclusively in Evil mode.
| One of my biggest complaints is that my big complex configuration
| setup seems to break every time I migrate to a new version of
| Emacs, or a new computer. This last time, I had to install VS
| code to get my work done quickly because I didn't have time to
| mess around with my configuration (yet again). It was
| surprisingly easy to get up and going on vscode. If it wasn't
| based on Electron, I just might consider sticking with it.
| Tweaking Emacs consumes a lot of time and seems to never end.
| natded wrote:
| The speed to 'first development environment' (lol) is a day and
| night difference between VSC and Emacs. VSC is faster to setup
| by several orders of magnitude (even if you know Emacs).
| Overall I believe you can get the same functionality, if less
| customizable, in VSC.
|
| I can't remember the last time by VSC configuration broke. I
| guess there isn't much to break in it.
| hhnever wrote:
| Have you tried any package manager tool that support taking a
| snapshot of your current whole setup (i.e. all the exact
| package version you are using)? Then on your new environment,
| it can be restored by the snapshot you saved before.
|
| Here is one I'm using https://github.com/raxod502/straight.el
| (it works for me except the overwhelming document).
| throwawayswede wrote:
| I'm happy that Emacs community doesn't have a lot of those who
| think that "everything should be easy" and that working hard to
| learn something is a waste of time by default.
|
| Emacs is great with or without your usage of it.
| shaoner wrote:
| I've been using Emacs for 15y, I can't replace it. Emacs-server
| is just amazing for me.
|
| I truly believe that its weakness is elisp, it's not hard but at
| the same time it's not a language you want to learn or spend time
| with, so of course that means less packages, less support and
| less interest in customizing it well.
|
| Other than that, I would be quite happy to see a modern version,
| with support for another scripting language and maybe dropping
| all these UI features, like menubar, toolbar etc.
|
| If we acknowledge there's a learning curve, the UI buttons are
| non essential. VSC & others are probably better at this.
| hvasilev wrote:
| I fell for the "text editor only" meme 8 years ago. I'm actively
| a vim user that uses tons of plugins just to be able to do simple
| things that IDEs do by default. I would not recommend it to
| anyone.
|
| I work primarily with embedded systems (ST and NXP MCUs). Not
| working with the respective IDEs that have been specifically
| designed for this type of work and using a text editor instead
| (of any type) would be objectively a bad choice.
|
| There is just so much value in being able to visually configure
| pins, peripherals, clocks, etc. that just the text editor makes
| no sense. Also the debugging experience is probably order of
| magnitude better.
|
| What you can do and what does make sense is vim emulation inside
| of the IDE. It is not perfect, but it is what it is.
|
| There is A LOT of ideology in the software world. DO NOT FALL for
| it. Take things at face value. Be a pragmatic, not an ideologue.
| SirensOfTitan wrote:
| I've used emacs for years, and then vim before that for several
| years. I maintained my own config for a while, then moved to
| doom.
|
| ...while I eventually ended up abandoning notes in org for a
| dedicated tool, I love using emacs. My only issue is perf: on an
| M1 Max I get multiple freezes from LSP per day when working with
| typescript. I'm currently on the latest emacs-mac build (plus
| with native comp doesn't seem to be that much better). The perf
| issues in a large typescript project are so severe that I've
| considered looking at other editors. A modern UI should just not
| lock up while waiting for a command to finish.
| gjvc wrote:
| Emacs 28 with native compilation is _much_ faster for me on
| Linux. :- / though there are hints of the GUI stuttering here
| and there.
___________________________________________________________________
(page generated 2021-11-04 23:01 UTC)