[HN Gopher] The values of Emacs, the Neovim revolution, and the ...
___________________________________________________________________
The values of Emacs, the Neovim revolution, and the VSCode gorilla
Author : mpereira
Score : 348 points
Date : 2021-01-17 13:18 UTC (9 hours ago)
(HTM) web link (www.murilopereira.com)
(TXT) w3m dump (www.murilopereira.com)
| aprdm wrote:
| Our text editor is a tool, there's no fundamental value in a tool
| vs the other, they do not possess life. They're tools like a fork
| is a tool.
|
| I wonder what of the things you use in the day to day you analyze
| so deeply, your microwave ? The forks you buy?
|
| Might be an interesting exercise of thought but for something
| that I use to make money, I will use the best tool available for
| the job, thank you very much.
| db48x wrote:
| My values certainly informed my decision when I last purchased
| forks. My values are that the design should lean towards
| minimalism over overt decoration, that they should have
| appreciable weight, and be likely to last a lifetime.
|
| I could have saved a few dollars by getting those really cheap
| forks you see that are obviously just stamped out of sheets of
| steel, but cheapness wasn't one of my values. Instead I got
| forks that have never bent, or rusted, or tarnished, or shown
| any signs of wear in almost a decade of use. Plus they feel
| nice in the hand, they look good, and they don't have flowers
| or birds carved into the handle or any of that nonsense. It was
| also a nice bonus that I found them at a Target a mile from
| where I live. I hate shopping, so that satisfied a tertiary
| value by not making me visit a lot of stores.
|
| It's the same with editors. Most people value price above all
| else, so there's no business in selling editors any more. Back
| in the day I used a rather nice commercial editor called VEdit.
| My Dad must have bought it, because at that age I never would
| have. It had a ton of features, and came with an inch-thick
| printed manual. I don't recall how extensible or introspectable
| it was (I was 12 at the time, and didn't care about such
| things), so probably it wouldn't satisfy my values today. On
| the other hand, it satisfied (or cultivated) values that I
| didn't even know at the time that I had. When I discovered
| VEdit's hex-editor, I started using it on everything. I
| explored how file names were stored in directory entries. I
| hex-edited some games to change their messages. I learned quite
| a lot from those sorts of things, so I'd say that it was money
| well spent.
|
| But you're correct in saying that editors are not alive, and
| cannot themselves have values. However, the people who develop
| the editor certainly do have values, and those values affect
| the choices they make when they write code. If those values are
| similar to your own values, then the developers of the editor
| will make similar choices to the ones you would have made if
| you had been developing the editor. Thus, the editor will fit
| you well.
| antonvs wrote:
| > there's no fundamental value in a tool vs the other
|
| > I will use the best tool available for the job
|
| The article is pointing out that the way you decide which tool
| is best depends on values that you have, which is certainly
| true whether or not you consciously think about or recognize
| those values.
|
| Describe your decision process for selecting the best tool in a
| given scenario, and the values you use should become clear.
| ht_th wrote:
| Maybe not forks for eating. But when I buy a pitchfork, I do
| care about the source of the handle's wood because I do not
| want to contribute to deforestation. I also look at the
| repairability. For example, would any standard handle fit? And
| can I attach one myself? And the "usability" of the handle, and
| the fork as a whole, is another factor that is important to me.
| Often, just from handling them, you do get a good feel if the
| pitchfork makers actually seem to care about their users and
| know what they are doing or not.
| mpalmer wrote:
| You didn't even skim the headline correctly.
| auggierose wrote:
| I don't like any of the three. I like Xcode, even better now that
| interface builder is destined for the garbage heap.
| qwerty456127 wrote:
| They have wrote such a list of values down but seemingly forgot
| such values as aesthetics (e.g. Sublime and VSCode look great, at
| least after you install a theme which suits your taste) and smart
| context-aware code completion and refactoring facilities (e.g.
| try IntelliJ once and you are hardly ever going back).
| cjauvin wrote:
| The article discusses it in sections related to Emacs' attitude
| toward modernization and progressiveness (see the citation from
| Ahmed Khanzada).
| jasim wrote:
| doom-emacs looks wonderful from the get go.
| https://github.com/hlissner/doom-emacs
| qwerty456127 wrote:
| Indeed! Does it have a light theme also? I have a window
| behind my back so I mostly prefer to use the ayu-light or
| alike themes wherever available.
| galfarragem wrote:
| Noob question: Is Sublime text still a good text-editor in 2021?
| Did it just loose momentum or not being open-source is
| insurmountable? I still think its speed and usability are not
| easy to match.
| Ozzie_osman wrote:
| My problem with sublime was it was just less polished. Harder
| to find extensions. Extensions randomly don't work. Etc.
|
| Vscode strikes a good balance. It's mostly got enterprise level
| of "polish" and stability, but still feels light-weight and
| flexible.
| ddek wrote:
| Open source is kinda irrelevant IMO.
|
| The answer is, of course, _it depends_. How much do you value
| language integration? Do you have muscle memory for vim or
| emacs? There are many more questions here.
|
| VSCode supports language server protocol arguably best, because
| LSP/VSCode/TypeScript were all developed somewhat in parallel.
| But some languages don't have complete language servers, or
| already had their own forms of IDE integration. JetBrains
| ReSharper has it's own csharp parser which it uses for analysis
| and automated refactoring.
| diffeomorphism wrote:
| > Open source is kinda irrelevant IMO.
|
| Good tools become even better with time investment. I don't
| want to invest time into a tool that dies if the dev company
| loses interest/goes bankrupt/gets bought by oracle/... .
| Emacs is much older than me and will be around for decades to
| come. Sublime 2? Probably not. Sublime 3, probably several
| years. Sublime 4,5,6... who knows.
| aniforprez wrote:
| Sublime is a perfectly fine and frankly faster editor than
| VSCode. The problem is the slow nature of the updates, the
| underwhelming API and people abandoning it in droves because
| they opt for VSCode makes the extension library not as
| comprehensive or feature packed. Half the extensions I use in
| VSCode don't have a parallel in Sublime
|
| I still use it to quickly edit text or read some files quickly
| cause it opens really fast but it's definitely never going to
| be my daily driver unless something changes drastically
| drzoltar wrote:
| In my workflow, one reason I prefer VSCode over Sublime is
| for dealing with large (10mb+) files. Sublime takes upwards
| of a minute to open such files but VSCode is nearly instant.
|
| For smaller files, Sublime is great.
| natchy wrote:
| It's my primary editor. It's a better text editor than VsCode,
| but VsCode is a better IDE.
| tkuraku wrote:
| I think sublime is a fantastic text editor. But it just doesn't
| cut it for me as a development environment. Getting productive
| in vscode is easy. It just works. Though Sublime hq's sublime
| merge git client is fantastic. I don't really care about
| sublime text anymore, but I'm a devoted user of sublime merge.
| 0xEFF wrote:
| After 10+ years with Vim, and 5 on emacs before that I switched
| to vscode this year and have been pleasantly surprised.
|
| I tried vscode in 2018 and it wasn't there yet.
|
| What I like better than vim:
|
| Better integration with python.
|
| Per-workspace interpreter and linter path settings.
|
| Outline view.
|
| Integrated terminal.
|
| direnv and venv both work well.
|
| JSON Schema integration. This is actually what sold it for me.
|
| Edit: format
| gegtik wrote:
| Nothing to add - just a great article that provides an objective
| and humanistic review of the field which is extremely refreshing
| to me.
|
| It invites the reader to consider their values and its mapping to
| the tooling we use (instead of working backward by having a gut
| feel of what they like and trying to justify why a specific
| feature is The Best)
| kloud wrote:
| VSCode has great and convenient language support, but the trade-
| off is reduced text editing efficiency, slower speed and more
| bloat. It is a worthy trade-off in many situations, I use it
| often when working on projects that are written in languages I am
| not too familiar with.
|
| I would like to emphasize how big of a game changer the next
| release of Neovim 0.5.0 will be. With builtin LSP support it will
| get code navigation, auto-completion and refactoring support on
| the level of VSCode out of the box, while being way more
| efficient and faster. I will likely still keep VSCode installed
| just in case, but only expect it to use it in rare occasions in
| the future.
|
| Emacs is really powerful, but its age is showing and there are
| some serious technical deficiencies under the hood. I would
| challenge the idea from the post that the need for "Neoemacs" is
| not that great. From the history it appears to me more like that
| many people tried, but due to complexity of Emacs nobody has been
| able to successfully pull it off yet.
| moocowtruck wrote:
| hmm in terms of neomacs, is this what remacs was trying to do
| but in rust?
| aidos wrote:
| That's amazing news. Native LSP would be game changing. I use
| coc, but it takes a bit of messing about to get everything
| working smoothly. Also vscode has has a bunch of extra stuff
| beyond what's available via LSP for python now, which is a
| shame because I'd love to get a full pyright + bells experience
| in vim.
| ashwanidausodia wrote:
| Coc has coc-pyright extension. You don't have to use pyls.
| https://github.com/neoclide/coc.nvim/wiki/Using-coc-
| extensio... https://github.com/fannheyward/coc-pyright
| aidos wrote:
| I use it, but MS have forked pyright with some features now
| locked just to vscode without support in the LSP.
|
| https://devblogs.microsoft.com/python/announcing-pylance-
| fas...
| tylerscott wrote:
| I've had great luck using ALE lately. I don't have much
| experience with coc but the ALE setup process is very
| straightforward.
| bobajeff wrote:
| I've used Neovim prior to trying vscode because it has a
| language server protocol client extension. Unfortunately, the
| extension didn't work too well (it had issues with `clangd`) at
| the time. So, just to compare I installed vscode and was amazed
| at how polished it was.
|
| Still, I had it in my mind that I wanted to have and fast
| alternative to vscode so I kept trying to work with Neovim.
| That is 'till I noticed how much I dislike using vim. You see
| it has that learning curve that if you've stopped using it for
| awhile it's a struggle to do basic things. So I used a
| configuration that made it act more like normal editors. So
| problem solved? Unfortunately, most extensions are made for a
| normal vim settup not my easy mode settup. Plus, I started
| missing having simple things like scrollbars and tabs I could
| click on and move with the mouse. (I remember the graphical
| front end for Neovim not meeting these needs at the time.)
|
| So ultimately, I just moved on and stayed with vscode. I would
| still like an alternative (kedit/k-develop looks promising).
| However, I'm sort of addicted to the plugins.
| atweiden wrote:
| I'm more excited about Onivim [1] than I am about Neovim making
| Lua a first-class language for writing plugins.
|
| [1]: Onivim is a VSCode/Vim hybrid in the works
| (https://onivim.io/)
| dmortin wrote:
| I use Emacs, but I like the polish of VSCode too.
|
| Emacs is a portable programming platform and once you learn it,
| it's so easy to program that it's trivial to create mini
| applications with a text/keyboard interface to get things done or
| quickly automate recurring tasks. (Those who can create VScode
| plugins and don't know emacs, have no idea how convoluted
| creating a vscode plugin is, and how trivial it is in emacs).
|
| Even if I happen to do something via VSCode, I still use Emacs
| for Org, Magit, etc. and also as the above mentioned programming
| platform, because I found these mini apps with key/text interface
| help a lot with everyday tasks.
| enriquto wrote:
| I read this "definition" of philosophy elsewhere: we all share
| the exact same set of moral values, but their relative order is
| different. It's the order of the moral values that determines a
| philosophical stance.
|
| The article starts by recalling this, but then it describes each
| project by the principles that it holds, but not by their order.
| This is a bit strange.
| piazz wrote:
| My daily driver is VSCode with Vim editing and Emacs Spacemacs
| keybindings. I use a VSCode port of Emacs' Magit client for
| version control.
|
| I'm genuinely curious, from other folks perspectives, what I'm
| missing with this setup. I've tried standalone Vim, I've tried
| standalone Emacs (Spaceamacs), and this is by far the best
| developer experience I've had. I don't know why I would ever
| switch to another tool, this feels to me like the best of all
| worlds.
|
| VSCode Spacemacs: https://github.com/VSpaceCode/VSpaceCode
|
| VSCode Magit:
| https://marketplace.visualstudio.com/items?itemName=kahole.m...
| spamizbad wrote:
| A thoughtful essay. I find myself frustrated with Sublime Text
| these days, and as a former (novice) vim user, I've been debating
| if I should go for VSCode like all the young guns these days or
| commit to Doom Emacs to leverage a solid initial setup and my vim
| memory and fully embrace libre route, which are a little more
| aligned with my values (although not to the degree of RMS). I
| remain oddly indecisive.
| antonvs wrote:
| I'm an old gun (learned to program in Fortran in 1977), and I
| recommend giving VScode a try.
|
| Its barrier to entry is very low, so you don't need to invest a
| lot of time to find out whether it's going to be productive for
| you. It's a real usability jump over older IDEs.
|
| I've switched from a combo of, mostly, Intellij IDEA and Vim to
| almost exclusively VScode (for development). I do still use
| Spacemacs just for org mode.
|
| > my vim memory
|
| There are vim compatibility plugins for VScode.
|
| > fully embrace libre route
|
| VScode is open source and MIT licensed, here's the repo:
| https://github.com/microsoft/vscode
|
| Someone would need to explain to me what values I'm forgoing in
| order to use this. Although I should warn that someone I'm
| likely to have a strong rebuttal.
| nitsky wrote:
| The default builds of vscode include telemetry and a non-free
| license.
|
| For a truly free build of vscode, you need to use vscodium.
| See their description:
| https://github.com/VSCodium/vscodium#why-does-this-exist.
|
| I suspect many developers are unaware of this.
| antonvs wrote:
| That's true, although anyone who cares about truly free
| software presumably would look into the details to check.
|
| You can disable the telemetry:
| https://code.visualstudio.com/docs/supporting/faq#_how-to-
| di...
|
| My point was really that it's free and open enough for any
| practical purpose I'm able to discern. Refusing to use it
| on the grounds of insufficient openness or freedom seems to
| me to require an unreasonably absolutist ideological stance
| on the issue.
| opencl wrote:
| The most important practical detail here is that if you run
| vscodium, or download and build the vscode repo from
| microsoft yourself, or use any forks of vscode, you cannot
| install any of the extensions hosted on microsoft's servers
| without violating their license terms.
|
| There are alternative extension marketplaces such as
| https://open-vsx.org/ but they are missing a lot of the
| extensions, some of which are proprietary.
| bobajeff wrote:
| The vscode marketplace also provides a link to download
| extensions as a vsix file on every extension page. So if
| the extension isn't on open-vsx I just download it
| directly and install it.
| emsy wrote:
| I use VSCode with a vim plugin. I'm mostly happy with it. As
| opposed to Vim, VSCode makes it easy to setup as a general
| purpose IDE. The downside is that it doesn't feel as responsive
| (it's not terrible, but noticeable) and has a larger memory
| footprint.
| rcarmo wrote:
| I've tried all of them, and still prefer vim because it's the
| least hassle to install/configure anywhere - my dotfile setup
| installs my plugins automatically, and I'm set.
|
| However, I do use VSCode extensively as well, largely because of
| the language servers. But sometimes it takes so long to start up
| (and nags me to do so many updates to itself and extensions) that
| I just toss the window aside and use a native Mac editor (like
| Textastic) to work while it finishes.
|
| Sometimes I don't go back -- it's all a matter of taste, really.
| earthscienceman wrote:
| Emacs can also install your packages/plugins automagically via
| the wonderfully designed use-package combined with MELPA. It's
| a game changer when it comes to managing an emacs
| configuration, especially if you work across a range of
| servers. Just copy the .emacs, install use-package manually and
| you're off to the races with anything and everything you need.
|
| By the time I discovered use-package I couldn't believe that I
| had been tar-balling a mess of crap around all these years.
| ExcavateGrandMa wrote:
| https://github.com/caseykneale/how-to-exit-vim
|
| krrkrkrkKRKRkRKRkrkr.
| cmlkz wrote:
| The Neovim section participates in the popular sports of ganging
| up on top developers who have spent decades of their life in the
| public interest, for free.
|
| The Neovim developer is called its "author", which is poor form
| and probably a copyright violation. Go and write your own editor
| from scratch.
| mplanchard wrote:
| The only place that the developer of neovim is referred to as
| its "author" is in a quote. But also, I didn't get this
| impression at all while reading the article.
| hklax wrote:
| The article is deliberately using selective quotes to paint
| Bram Molenaar in the worst possible light.
|
| A common tactic among people who take over code bases in
| order to cruise on other people's hard work.
| mplanchard wrote:
| I don't know. I don't think the author paints him in a
| particularly bad light. It mostly seems to be trying to
| point out why neovim was made, specifically that its
| authors valued different things than the author of vim.
|
| I also think the amount of work that's gone into neovim is
| way more than enough to call the authors authors at this
| point. The forking of vim doesn't seem to me to be
| "tak[ing] over code based in order to cruise on other
| people'a hard work," but open source working as intended.
| The neovim authors were able to take a project, adjust it
| to fit with their values, and let people decide which they
| prefer.
| mpalmer wrote:
| You and thread OP seem to have signed up just to make these
| comments. Do you think your obvious bias against Neovim is
| coloring your perceptions of the piece? Because it is not
| about trashing Vim or Moolenaar.
| gspr wrote:
| author (plural authors) The originator or creator
| of a work, especially of a literary composition.
|
| A fair and pretty commonly used word for describing someone who
| wrote something. Are you also pissed off when a group of
| lawmakers are referred to as "the authors of a law"?
| michaelcampbell wrote:
| As opposed the popular sport of denigrating a critique of
| something because the critic hasn't, or doesn't the ability to,
| create the thing themselves?
| signal11 wrote:
| I don't find VS Code to be a good text editor in the sense of a
| tool to wrangle text: the keyboard shortcuts are rather arbitrary
| and don't seem to be logically organised, and it seems not to
| have learnt much from eg modern text editors like Sublime Text
| (even Sublime compatibility isn't as good as the real thing).
|
| That said, for writing code, it's fine because most of the time
| I'm thinking and typing in short runs of text.
|
| I'd love for it to receive a bit of love so it's a better at
| wrangling text out-of-the-box, however.
| slightwinder wrote:
| Shortcuts in VS Code are a setting. Just load which shortcut-
| setup you prefer. That's pretty normal with good dev-tools
| nowadays, because everyone has different preferences and
| habits.
| signal11 wrote:
| > Shortcuts in VS Code are a setting. Just load which
| shortcut-setup you prefer.
|
| There are quite a few shortcuts that cannot be implemented
| due to missing capabilities in VS Code. For example -- this
| list from an author of a VS Code plugin that emulates
| Sublime[1].
|
| [1] https://github.com/Microsoft/vscode/issues/3776
| slightwinder wrote:
| Those are very special and seems most of them are
| fixed/possible already?
| qsort wrote:
| I completely share your sentiment. VSCode is by far my favorite
| programming environment, its killer features as far as I'm
| concerned are its excellent debugging functionality and the
| remote mode (we often work on multiple remote machines
| simultaneously -- being able to have ad-hoc remote configs is a
| life-saver!)
|
| The worst part is, ironically, the editor itself. As a former
| vim user I'd love to have vim keybindings, but the vim
| extensions are painfully slow and unresponsive. I ended up just
| using the default in spite of it being incredibly mediocre.
| busrf wrote:
| Have you tried the vscode-neovim
| (https://github.com/asvetliakov/vscode-neovim) extension? It
| uses an instance of neovim to provide the vim behaviour
| rather than emulating it, and I've found it to be more
| responsive than VsCodeVim.
| ilaksh wrote:
| I use vim frequently. But I think that people should realize and
| be able to admit that vim and emacs are outdated. They can still
| be useful especially for people like me who have a sunk cost in
| learning them. But the honest evaluation is outdated. For
| example, the core modal interface of vim is related to historical
| limitations at the time it was created.
|
| http://xahlee.info/kbd/keyboard_hardware_and_key_choices.htm...
| Basically historical happenstance has become part of multiple
| religions defending dated programs.
|
| My current favorites are Jupyter Notebooks and the combination of
| gedit with fish shell.
|
| VSCode is great but a lot of times feels like overkill and a
| little bloated.
| Jugurtha wrote:
| > _My current favorites are Jupyter Notebooks and the
| combination of gedit with fish shell._
|
| Do you mind elaborating on what you're doing with notebooks?
| ilaksh wrote:
| Just to be clear, those are two separate cases: 1) Jupyter
| and 2) gedit + fish. Two different types of programming
| projects.
|
| I am using Jupyter Notebooks for what they are normally used
| for: machine learning experiments.
|
| But it might be a good idea to try to expand to other use
| cases since its such a powerful concept.
| Jugurtha wrote:
| > _I am using Jupyter Notebooks for what they are normally
| used for: machine learning experiments._
|
| I'm interested to know what kind of problems you may be
| having doing machine learning. Are you doing that as part
| of a team or for fun?
|
| We're making something in that space[0]. It's our machine
| learning platform because we've been doing ML projects for
| many years and are building this to help us. Does the
| description in that post solve some/all/none of your
| problems?
|
| - [0]: https://news.ycombinator.com/item?id=25802764
| u801e wrote:
| > the core modal interface of vim is related to historical
| limitations at the time it was created.
|
| While that's true, the type of text manipulation and navigation
| one can achieve in normal and command mode far exceeds what one
| can do with the standard keyboard shortcuts for text
| manipulation, navigation, and selection in most GUI
| applications using, with or without holding the shift key, the
| arrow, del, home, end, pgdn, and pgup keys, or the
| ctrl-{a,c,f,x,v,y,home,end} key combinations.
| oefrha wrote:
| > It also shines in areas where Emacs doesn't: if you're a
| programmer working on typical contemporary projects, mostly just
| wanting to get stuff done, things usually... just work. You
| install VSCode, open a source code file, get asked to install the
| extension for that particular language, and that's it. You get
| smart completion, static analysis, linting, advanced debugging,
| refactoring tools, _deep integration with git_ , and on top of
| that, great performance and a cohesive user experience.
|
| These days I mostly use VSCode due to great language server
| integration (Pylance, gopls, rust-analyzer, etc.), but I still
| rely on Emacs with Magit for almost all my git interactions. This
| is not helped by VSCode's shitty commit message box, which after
| five years is still this ~250x20px by default input field with
| some after-the-fact validation tossed in. The great thing about
| Emacs is that everything is a buffer, you get the full editing
| power afforded by a buffer, not some second-class input field,
| especially for something as important as commit messages.
| africanboy wrote:
| I use this for git interactions in VSCode
|
| https://github.com/kahole/edamagit
| oefrha wrote:
| Interesting, I'll check it out, thanks.
| thom wrote:
| I have found this mostly good enough that it gives me hope
| for VSCode. I wish more extensions took inspiration from
| Emacs and were implemented in texty ways as editor windows
| though.
| aldanor wrote:
| Same here in regards to Magit. I've tried seriously using Emacs
| (Spacemacs) for a year or two, but something always doesn't
| work as intended, code completion and static analysis is
| extremely hard to configure, especially you have some non-
| standard project setups. Then switched to a mix of vim for
| simple stuff or clion/pycharm in vim mode for
| rust/cpp/python... BUT, subjectively, Magit is the best git
| client ever created; Magit in evil-mode easily beats all of the
| 20+ git clients I've used. So I keep emacs/spacemacs on every
| machine now solely to be able to use magit.
| perryizgr8 wrote:
| Why do you need to use a git "client"? What's wrong with just
| using the standard CLI? I use VS code and never bother with
| its git ui. Just open a terminal and use git commands.
| kubanczyk wrote:
| Git CLI is fantastico if you want to do two things per
| hour. If you want to do twenty, it's just too many
| keystrokes. Even if we only talk basic add/commit/push.
|
| Two especially laborious operations are `git add -p` and
| `git rebase -i`. Try them out on magit, you'll see the
| difference.
| hawski wrote:
| git gui is way to go.
| submeta wrote:
| How do you selectively stage several hunks from command
| line in git? - Imagine you edited a large file, fixed two
| different things, now you'd like to select the changes
| related to one thing first and commit them. And then the
| next changes.
|
| In Magit you visit the file you changed, hit `C-x g' and
| see all diffs. Now you can review and select hunks by
| hitting ,,s" (stage), go to the next relevant hunk and hit
| ,,s" again to mark for staging. And when you're done
| selecting all changes that are relevant for one ticket, you
| hit ,,c" twice to write a commit message. And off to the
| modifications/ hunks regarding second ticket.
|
| So how'd you do this in command line?
| psYchotic wrote:
| This may have been semirecently been added to git, but
| look into [0]: git add -i It launches a fairly simple
| interactive text UI that allows you to select files to
| stage, and it allows one to "patch" into the staging
| area, which works by showing you a bunch of hunks, asking
| for each if you want to stage it (or you can even edit a
| hunk in your $EDITOR).
|
| I'm sure it's not nearly as nice as Magit's UI, but I've
| been a happy user of this feature for a while.
|
| [0]: https://git-scm.com/book/en/v2/Git-Tools-
| Interactive-Staging
| codethief wrote:
| How about
|
| $ git add -p path/to/the/file
|
| ?
|
| Combine this with your favorite tool for command line
| auto-completion of paths (and, maybe, a git alias to
| avoid typing `git add -p` all the time) and it's
| extremely fast.
| submeta wrote:
| I am presented with one hunk at a time, and have to
| decide if I want to stage or not (with a text "menu"
| underneath it: "(2/2) Stage this hunk
| [y,n,q,a,d,k,K,g,/,e,?]?"
|
| And then I navigate with j/k (down/up).
|
| Yes, it does the job. Matter of preference.
|
| But if you worked eagerly on three / four different
| topics and try next to create several different commits
| by getting a visual overview of all hunks with the
| abilitiy to selectively stage is a little more
| comfortable.
| nickjj wrote:
| If you have multiple files then you can choose to omit
| the file name and git will let you decide on each hunk
| for each file.
|
| You can also hit "s" to split a hunk to only commit a
| part of a hunk of if you want fine grained control you
| can hit "e" to edit just that hunk in your $EDITOR to
| only select a specific line or whatever you want.
|
| Personally I tried fugitive and other git clients in the
| past and always come back to git add -p on the command
| line. It just feels the most natural and it also forces
| you to look at the hunks, so there's really no chance
| you'll accidentally forget to add something.
|
| When using GUIs with sidebars showing what files changed,
| etc. it's easy to forget to add something because you
| skim it without really paying attention to what was
| changed.
| [deleted]
| akho wrote:
| Try Magit. You'll know whether it works for you. It clearly
| does for many people.
|
| Or fugitive in Vim.
|
| The difference is like that between using Ed and Vi. Seeing
| things as you do them is valuable.
| [deleted]
| ttt0 wrote:
| Nothing's wrong with using CLI. You might not need it, but
| sometimes it's nice to have something with more. Most
| people on this planet think that managing files from
| terminal is pure insanity, and I do just that, I didn't
| even bothered to install a graphical file manager. And yet
| I use a git client/front-end in my text editor, because
| it's nicer to do some things that way. The most useful
| feature is probably interactively staging hunks just like
| you'd edit a text file over what standard git does.
| beojan wrote:
| Try Doom Emacs (https://github.com/hlissner/doom-emacs)
| instead of Spacemacs. It's much lighter weight and doesn't
| replace the configuration system to nearly the extent
| Spacemacs does.
| slightwinder wrote:
| Doom is not really better than spacemacs. It's just the
| same pain in a different flavor. Sure, in the micro-cosm of
| emacs it's pretty good, but in the macro-cosm it's still a
| pain and can't lift the limitations and problems of emacs.
| moocowtruck wrote:
| sincerely curious, what are the limitations and problems
| of emacs? I use both vs code and emacs. I've been using
| vs code a bit more these days because I feel like the UI
| itself is a bit more powerful and modern. I've also come
| to like that If i want a language support it often
| installs all the things I'd want to make a good
| experience, and I have less to mix and match. I like the
| mix and match approach I've always used in emacs, but it
| turns out there fewer scenario where I want that power
| then I'd have thought, and more where I just want some
| out of the box functionality from an extension author
| simias wrote:
| >The great thing about Emacs is that everything is a
| buffer[...]
|
| It frustrates me endlessly that this one simple, almost self-
| evident piece of Emacs wisdom failed to gain traction almost
| everywhere else. Even the venerable Vim drops the ball hard
| here, with the various "widgets" it uses in its interface which
| have slightly different semantics and behaviours.
|
| Every time I get a shitty modal with some text I can't copy
| paste, every time I have a crappy edit box lacking basic
| editing capabilities, every time I get some large text dump I
| can't search through with normal editing commands, every single
| time that happens I pray to the altar of RMS for him to smite
| the heathens and bring us to the age of enlightenment.
| u801e wrote:
| >>The great thing about Emacs is that everything is a
| buffer[...]
|
| > It frustrates me endlessly that this one simple, almost
| self-evident piece of Emacs wisdom failed to gain traction
| almost everywhere else. Even the venerable Vim drops the ball
| hard here, with the various "widgets" it uses in its
| interface which have slightly different semantics and
| behaviours.
|
| Perhaps I don't understand emacs well enough, but I know that
| every file loaded in vim can be accessed via its buffer
| number. How it's displayed depends on the window and tab
| layout. Quickfix, help, and terminal buffers behave
| differently, but the vast majority of buffers are just
| associated with open files.
| didibus wrote:
| Emacs buffers don't need to be associated with open files.
|
| Basically menus, project trees, terminal tabs, etc. Are all
| just text buffers. So you can navigate them like they were
| a file opened in a regular text buffer.
| u801e wrote:
| The netrw plugin that comes with the default installation
| of vim on many distros allows you to navigate the
| directory listing like a file, but it won't let you edit
| the text. The terminal buffer is similar, but you have to
| enter a special normal mode (ctrl-w N) in order to
| navigate the scrollback like a conventional buffer, but
| you can't change the contents of the buffer.
| simias wrote:
| Yeah quickfix pane is a big annoyance of mine, but you also
| have things like :message that dumps a bunch of text to
| stdout that you can't meaningfully use directly. Compare
| that to Emacs' permanent Messages buffer that is just like
| any other buffer.
|
| Vim is not the worst offender by any mean, but it's
| definitely a lot less uniform than Emacs.
| runiq wrote:
| You can redirect stuff to a register with the following
| dance:
|
| :redir "a :messages :redir END
|
| Then, you can just paste from that register using "ap.
| u801e wrote:
| I've been using vim for decades, but was not aware of the
| messages command. If it's anything like the version
| command or the K key for displaying the man page for a
| keyword under the cursor, that's also an annoyance of
| mine. It's also why I will redirect man page output to a
| standard buffer by running :r !man whatever in a new
| split window.
| justinhj wrote:
| I'm a long time Emacs user and just recently I have been
| learning and using neovim a lot. This is the most jarring
| difference between Emacs and other editors. The second
| biggest issue is Lua instead of Emacs Lisp. s-expressions
| work so well in the editor extension context. Steve Yegge
| wrote a really nice million word essay on this topic.
| moonchild wrote:
| Have you looked into fennel? Is it possible to use that
| within neovim?
| blackrock wrote:
| You wrote a lot here, without saying anything at all.
|
| It's like you're a master at the art of hot air speaking.
| marcmarc wrote:
| I use Emacs inside VSCode's terminal just for Magit. And I've
| configured Emacs to open directly with the magit-status buffer.
| It beats all the VSCode extensions I have tested.
| (when (string-match "code" default-directory) (magit-
| status) (delete-other-windows)) (with-eval-after-
| load 'magit (define-key magit-status-mode-map (kbd "q")
| 'save-buffers-kill-terminal))
| mplanchard wrote:
| Completely agree that magit is superb. The fantastic
| integration with git forges to check out PR branches as
| worktrees has really been a game changer for me. I can see what
| PRs are open, create a worktree with fuzzy selection on PR
| branches, and then switch to that worktree to review changes in
| ediff.
| jackcviers3 wrote:
| Until an editor comes along that is as extensible and keyboard
| efficient as emacs with lsp integration, or I get one of those
| combination mouse/ergonomic keyboard contraptions, I'll stay
| there.
|
| Every other IDE requires mouse usage to accomplish even the most
| basic commands. With helm in emacs, my hands never have to leave
| the keyboard. Vocoder comes really close, but still requires you
| to build a plug in rather than exposing a quick api to do project
| specific one off tasks with eval or macro recording and
| repetitive application without using the mouse for anything.
| cjohansson wrote:
| I don't see why everyone needs to have the same opinion and
| editor, I'm fine with everyone using the editor they like best.
| It's a tiresome endless debate
| submeta wrote:
| When you finally learn to master and config Emacs, you run
| circles around all other editors. Emacs is so much more than just
| an editor. But even if you only use it for coding: Magit is the
| best git client I have used in years (coming from PyCharm + Git
| Tower App, which is nice), then there's Ztree-Diff (excellent
| folder diff tool; previously using Kaleidoscope app), then Eshell
| for interacting with the server from within Emacs
| (programmatically if you like), Tramp for remote editing,
| excellent integration of ripgrep and silversearcher (ag) into
| Emacs for code navigation, yasnippet as an excellent
| templates/snippet manager, and many more packages.
|
| What makes Emacs exceptional is you can link all these packages
| together, create your own workflows by scripting Emacs in Lisp.
| And I write the docu in Emacs in org-mode, with org-babel I can
| run shell-scripts / python-scripts and other code in my org-file
| and see the output underneath it (like Jupyter notebooks), link
| to code fragments in my org files etc
|
| I manage several projects with it and switch contexts with one
| key-combination: Vagrant box is started, project folder is
| changed, necessary files opened, ready to hack, build, deploy, do
| server restarts with a single key stroke.
|
| I think VS Code is a nice coding environment with good defaults
| and many things done right (compare installing packages in VS
| Code to Sublime! What an improvement) but nowhere near the
| capabilities and the productivity of Emacs.
| augustk wrote:
| > When you finally learn to master and config Emacs, you run
| circles around all other editors.
|
| I quit Emacs when I realized that I spent too much time on
| configuration rather than solving first hand problems; it can
| almost become an obsession. Now I use Pluma.
| asddubs wrote:
| pluma is nice, I used it for a really long time but in the
| end having a linter integrated into my editor sold me on
| VSCode
|
| I do still use pluma for just quickly editing files though,
| but for coding I use vscode now
| zenlot wrote:
| What's Pluma?
| monadic3 wrote:
| https://en.wikipedia.org/wiki/Pluma_(editor)
| chishaku wrote:
| > When you finally learn to master
|
| s/When/If
| agumonkey wrote:
| I wonder what other editors allow to dynamically extend/adapt
| much about anything.
|
| I remember trying turbo pascal 7.0 on dosbox. I was shocked by
| how brilliant that tiny program was for its era. So light, so
| packed with features, so fast. Yet at the first editing
| ergonomic need I had, I was stuck.. my brain couldn't stop
| thinking .. 'this would already have been fixed in emacs'.
| higerordermap wrote:
| I don't quite "get" magit, can someone tell what's great about
| it / for what type of git workflow?
| disgruntledphd2 wrote:
| It's much quicker to do simple git things, the logs are
| integrated, it's super easy to stage hunks into separate
| commits, and it seems to make everything possible with git a
| little easier and more consistent (you do still need to know
| git though).
| jpeloquin wrote:
| This is what sold me on magit:
|
| 1. In the magit status buffer (equivalent of git status), you
| can selectively stage changes by highlighting the relevant
| lines and pressing "a". Basically an interactive git add -p.
| There's also line-specific unstage and discard. This makes it
| easy to tidy up before committing.
|
| 2. If the cursor is on a commit, commands (show, interactive
| rebase, push) will take that commit ID as a default argument.
| It feels like you're interacting with the commits directly,
| which makes it easier to reason through an interactive rebase
| or partial push. Simple rebases like reordering or squashing
| recent commits take only a few seconds.
|
| 3. It seems to mostly rely on calling the core git commands
| and parsing their text output. The core git commands are
| reliable. Many git clients will hang on large (> 200 GB)
| repos; magit doesn't. An exception is diff colorization, but
| if colorization is taking too long on a big diff, Ctrl-g will
| make magit fall back instantly to the plain diff.
|
| 4. Has decent submodule support, in that submodules can be
| interacted with much like commits in the parent repo.
|
| 5. Has git annex support. (Technically, I think this is
| provided by another package that extends magit.)
|
| It's not really tailored to any particular git workflow as
| far as I can tell. The design intent seems to be that every
| displayed entity should be interactive, regardless of where
| it is displayed.
| GordonS wrote:
| In VSCode, you can selectively stage lines in files too,
| just select them in the diff, right-click, "stage selected"
| - I love being able to do that so easily within such a nice
| UI.
| cle wrote:
| The big appeal of magit, at least for me, is that I can
| quickly do it with the keyboard. Open magit, press "s" on
| each hunk to stage it and magit moves to the next hunk,
| then "c c" to write a commit message, C-c C-c to commit,
| then "q" and I'm right back in the code. If you need to
| edit a hunk you press enter on it and it drops you into
| the file.
|
| This is much much faster than doing it with the mouse,
| and keeps me more in "the flow". In general Emacs becomes
| powerful because it's full of little tricks that add up
| to much tighter feedback loops which is so helpful when
| coding, to keep your attention on the problem you're
| trying to solve. And it is trivial to add your own
| "little tricks" to tighten the feedback loop for whatever
| you're doing.
| GordonS wrote:
| VSCode has an extension for that too, edamagit[0] :)
|
| One of the big appeals of VSCode for me is the huge
| community around it, and the range of plugins available.
|
| [0] https://github.com/kahole/edamagit
| tyingq wrote:
| To me, it depends on the language. An IDE helps a lot with
| verbose languages that have somewhat complicated environments
| or runtimes. Like Java. I can fly with VIM and Perl though.
| ashtonkem wrote:
| Yeah, this is very language dependent. Trying Emacs with Java
| is pure pain, even if you _love_ Emacs.
|
| Like most open source things, the quality of support maps
| closely to the density of users who are trying to accomplish
| something similar. This is why Emacs has fantastic support
| for languages like JS and Ruby, and massively subpar support
| for Java and C#.
| cle wrote:
| I've been using Emacs for Java dev for a year now using LSP
| and it's been great.
| qppo wrote:
| You can do all that and more in vscode as well... you just have
| to "learn to master and config" it with your own plugins in JS.
| It's not that hard.
| mercer wrote:
| I use VSCode for my day to day coding, so I have nothing
| against it, but explain to me how I can 'do' Magit and the
| like in VSCode...?
| ashtonian2 wrote:
| Literally anything you can do in emcas there is an
| extension for or at least one in dev. Vscode will outgrow
| emcas given its critics mass and momentum.
| BeetleB wrote:
| I'm not a heavy VSCode user, so I don't know much about
| its plugin ecosystem. I'm asking the question below
| sincerely, not to start an argument.
|
| Is there a plugin in VSCode to:
|
| 1. Read, write and send emails?
|
| 2. Have an org mode like system where I can do TODOs, as
| well as link to things in other aspects of VSCode (e.g.
| link to an email - something I do routinely)?
|
| 2b In general, how easy is it to interconnect the
| different plugins? If I have a plugin to handle email,
| and another to do TODOs, can I quickly write something
| that will read an email, and then go and add a TODO in
| the appropriate section of some document based on the
| contents of that email?
|
| 3. Use it as a window manager
|
| 4. Use it as a file manager
| dmitriid wrote:
| You've selected some use cases designed to show that
| VSCode is inferior to emacs. What you failed to realize
| is that your use cases are invalid for probably a vast
| majority of people:
|
| > Read, write and send emails
|
| I prefer to do that in a dedicated app that actually
| knows how to deal with emails, and not from inside my
| text editor/IDE
|
| > can I quickly write something that will read an email,
| and then go and add a TODO in the appropriate section of
| some document based on the contents of that email
|
| I tend to prefer not to spend my time programming things,
| but, you know, enjoy life.
|
| If I need a todo from an email, I'll copy paste it to an
| app that, for example, syncs to my phone
|
| > Use it as a window manager
|
| Why?
|
| > Use it as a file manager
|
| Why?
| kpgiskpg wrote:
| The previous user said that you can do "literally
| anything" in VSCode that you can do in Emacs, I think
| these examples were chosen to prove that statement wrong.
| It doesn't mean that Emacs is better for everyone.
| dmitriid wrote:
| I would also think that no one even cares to write an
| email client or a window manager inside an IDE even if
| that is possible (it probably is).
| BeetleB wrote:
| > > Use it as a window manager
|
| > Why?
|
| Because I need a window manager.
|
| > > Use it as a file manager
|
| > Why?
|
| Because I need a file manager? I can give you an example
| of a time where I needed to examine some files, and
| depending on what I saw, with a keystroke make notes in a
| text file with links to those files, but that's secondary
| to the topic. The simpler answer is that I need things
| like file managers and window managers, and Emacs is
| both. Viewing Emacs as a text editor is a misconception
| you seem to have.
|
| My question was whether there are plugins for VSCode to
| do any of these. You did not address that at all. Your
| comment is noise in this thread.
| bitwize wrote:
| Has NetCraft confirmed that Emacs is dying yet?
|
| I keep reading on Hackernews and elsewhere that VSCode
| will solve world hunger. So I try it. And after a week or
| two, I realize what I'm missing from Emacs and go back.
| This has happened several times, because I keep thinking,
| maybe I didn't give VSCode the fair shake it deserves.
| But VSCode never lives up to the hype, is not
| compellingly better than Emacs such that I want to
| switch, and is in some ways worse. Emacs gives me a
| computing environment that I can shape and mold to my
| needs quickly and directly, as I use it. VSCode is
| extensible; for Emacs, extending it is an integral part
| of working with it.
|
| What's more, VSCode is not even open source. It's more
| like "open core". The editor core is under an MIT
| license, but the binary you download from
| code.visualstudio.com is proprietary, as are many of the
| most useful plug-ins. Source ports like VSCodium are not
| first-class in the extension ecosystem.
|
| Emacs, by contrast, is the next thing beyond open source:
| it's software that describes itself. Whether that be the
| tutorial for new users, built-in documentation for every
| function or variable, or the ability to M-. into the
| implementation, whether in Lisp or C, of any function,
| the guts of Emacs are always at your fingertips. I get
| the feeling RMS intended "free software" to be a
| baseline, a bare minimum for protecting the user's
| freedom. To truly emancipate the user, something like
| Emacs where the software actively aids the user's
| understanding of its internals, is needed.
| akho wrote:
| "Critics mass" of whom? VS Code is very disappointing,
| given the hype. Can you give an example of something in
| the VS Code ecosystem that can impress an Emacs user
| enough to switch, beyond chrome?
|
| Chrome will always attract crowds, of course.
| chimprich wrote:
| Genuine question: is there one for regional undo? That
| is, can you select an arbitrary region of a file and step
| back through modifications that have been made to that
| section of the file only?
|
| This is just one "killer feature" of Emacs for me that I
| have yet to come across in other editors/IDEs (maybe I
| just haven't looked hard enough!)
| indymike wrote:
| The question is will it grow in the right direction? Org-
| mode, magit and a pure terminal interface (can run on
| remotes through an SSH sesion) are still missing. Still
| love the ergonomics of vs code.
| bubblesorting wrote:
| VS Code runs on remote hosts through SSH, containers, or
| WSL: https://code.visualstudio.com/docs/remote/remote-
| overview
|
| Kinda like a parallel universe swank/slime.
| indymike wrote:
| Yes... and has the same limitations of roundtripping
| files in any other IDE.
| bananaquant wrote:
| For display and editing purposes, yes. However, from what
| I understand, the LSP, linters, and auxiliary tools all
| run on remote.
| chishaku wrote:
| The right direction according to who?
|
| For 99% of users, org-mode, magit and a pure terminal
| interface are not hard requirements.
|
| And I'm saying this as an emacs and org-mode user that
| does everything in the terminal.
| BeetleB wrote:
| > The right direction according to who?
|
| You are asking the right question, but it applies to your
| comment equally well.
|
| > For 99% of users, org-mode, magit and a pure terminal
| interface are not hard requirements.
|
| You are narrowly picking the set of users to suit your
| comment. For 99% of users, code completion, syntax
| highlighting, etc are not requirements either, because
| 99% of users do not program.
|
| In retrospect, it should be obvious that Emacs users are
| heavily weighted towards using org mode, because that's
| part of Emacs's value proposition. It makes sense that
| most VSCode users do not need/want org mode, because
| otherwise they'd be using Emacs, and not VSCode.
|
| In almost every thread about Emacs, I always find the
| comparisons with VSCode amusing, given that the two
| programs serve very different purposes. The bulk of my
| Emacs usage has nothing to do with coding, so I
| personally don't see the value of comparing it with
| VSCode, and pointing out that VSCode is better is sort of
| irrelevant. Of course, this being HN, there is a
| programming bias. But it's the equivalent of saying
| "mplayer sucks because it cannot do video editing as good
| as some video editing tool."[1] It's great that you have
| found a good video editing tool, but that tool doesn't do
| much of what I use mplayer for.
|
| [1] mplayer has extremely rudimentary video editing
| capabilities,
| evan_ wrote:
| I'm not familiar with magit but from a quick skim of the
| "visual walkthrough" I think you can get most if not all of
| the functionality either built in to vscode or with the
| free "git lens" plugin, one of the most popular in the
| extension directory.
|
| Here's what's built in:
| https://code.visualstudio.com/docs/editor/versioncontrol
|
| and git lens: https://marketplace.visualstudio.com/items?it
| emName=eamodio....
| moocowtruck wrote:
| https://github.com/kahole/edamagit
| Steltek wrote:
| I use Edamagit but I still find myself popping open
| emacs+magit sometimes. I guess I haven't completed the
| assimilation into VSCode yet.
| umvi wrote:
| I tend to let other people "master and config" VSCode and
| then I just go download their extensions. IMO that's the
| beauty of VSCode - critical mass
| sedev wrote:
| That's also available with emacs, though, it has its own
| extension ecosystem that's about as easy to access as
| VSCode's.
| voxl wrote:
| Yeah no, emacs package system is a giant mess, it's only
| "easy" if you've already drunk the emacs kool aid.
|
| Sorry I just really hate emacs.
| vopi wrote:
| I don't think its as easy imo. vscode auto recommends
| extensions if you open a new file type and from what I
| remember (been a number of years since I installed a
| package in emacs), the extension "browser"/"market" was
| not as user friendly (in terms of raw info about the
| extension and in discoverability).
| thom wrote:
| Have you found that other extension authors have this in
| mind? Most extensions don't seem to be built with hooks in
| mind so you're kinda stuck with either the existing extension
| or rolling your own. There also aren't very good primitives
| for most use cases because of this. I assume VSCode will get
| there though.
| qppo wrote:
| VSCode extensions are driven through "commands" that are
| exposed through the package.json of the plugin (which can
| be parsed by other plugins if you wanted) and issuable
| through another plugin, or using a task (this is kind of
| annoying though and not a first class use of tasks).
| monroewalker wrote:
| Do you mind sharing a bit more about your setup and workflows?
| Or a link to anywhere where you've discussed it before?
| brandonmenc wrote:
| > I manage several projects with it and switch contexts with
| one key-combination: Vagrant box is started, project folder is
| changed, necessary files opened, ready to hack, build, deploy,
| do server restarts with a single key stroke.
|
| When I single-click to open a project in a JetBrains IDE, the
| same sequence of events happens (albeit using Docker Compose
| instead of Vagrant).
| throwawaybchr wrote:
| For many who don't have experience, lisps are intimidating
| ignoramous wrote:
| Reminds me Ryan Dahl's quip from way back when:
|
| > _I love Go so much (SO MUCH), but I cannot get past the
| fact that goroutines share memory or that it 's statically
| typed. I love Erlang but I cannot get the past the syntax. I
| do not like the JVM because it takes too long to startup and
| has a bad history of XML files and IDE integration - which
| give me a bad vibe._
|
| https://news.ycombinator.com/item?id=4310723
| na85 wrote:
| >When you finally learn to master and config Emacs,
|
| Should be "if" and not "when", in my opinion.
|
| It's so incredibly frustrating to watch emacs from the outside.
| Maybe they don't want emacs to become popular? Certainly given
| the state of Hurd that could be true, and perhaps merely the
| fact that a Free editor exists is enough for them.
|
| For me, I really like emacs. It's great. But it has
| flaws/warts/roadblocks that routinely turn away new users and
| the grognards that seem to form the most influential portions
| of the emacs community seem to care more about freedom than
| about making an editor that's welcoming to new users and that
| people actually want to use.
| craigsmansion wrote:
| [Never mind]
| na85 wrote:
| Whether intentionally or not you seem to have directly
| reinforced the argument I was making.
|
| >Why from the outside? You're, quite literally, one command
| away from being on the inside: "M-x ielm"
|
| I have no idea what point you're trying to make here. By
| opening with what I'm sure is an oh-so-witty commit like
| this you signal that you aren't going to engage honestly in
| this debate.
|
| >Emacs is very popular amongst emacs-users
|
| It's like you didn't even read what I wrote, and instead
| you've constructed a straw man to argue with. I think it's
| pretty obvious I was using "more popular" to refer to
| "attracting new emacs users".
|
| >GNU nano, GNU ed, GNU moe, GNU emacs
|
| Again, not sure what the point of just listing a bunch of
| editors is. Your entire comment is pretty much one giant
| non-sequitur.
|
| >Obviously the emacs community is going to care about
| software freedom. I don't understand how anyone would
| expect differently.
|
| Again, it's like you didn't want to respond to what I
| actually wrote. You seem to be responding to what you wish
| I wrote.
|
| I never implied that I expect the Emacs project not to care
| about freedom _at all_ , merely that I think it's silly to
| prioritize freedom at the expense of everything else. Is
| Free Software of any utility if nobody uses it? Or is it
| merely intellectual masturbation?
|
| The default emacs experience is clunky, ugly, and dated. It
| turns people away. This is an objective truth.
|
| I categorically reject the idea that polished software is
| mutually exclusive of free software. I think emacs would do
| a better job of promoting the use of free software if emacs
| had a better onboarding experience and was more user-
| friendly, and I think it can achieve this goal without
| betraying the principles of Freedom on which it was
| founded. And yet at any suggestion of this, RMS and the
| other grognards are content to ridicule and belittle (just
| as you have done here) rather than engage honestly in the
| arguments being presented.
|
| >The very least one can do when addressing perceived
| flaws/warts/roadblocks, is to accompany them with a snippet
| of code, so users/developers can actually experience these
| suggested improvements.
|
| Are you seriously suggesting I should post a patch to HN?
| It's comments like this that leave the very distinct
| impression you're just trying to shield yourself from any
| criticism rather than have to confront viewpoints that
| challenge the status quo of the emacs project.
| diragon wrote:
| Naah, not really. I've done that emacs exercise countless of
| times over a few decades and now I use vscode. I don't feel
| like I'm missing much.
| harrygeez wrote:
| I'm on the same boat as you. I love Emacs, the uniform
| keybindings and especially Magit, I thought I could never use
| anything else until I started working with TypeScript React
| in my current job, which Emacs has very bad support for.
|
| The funny thing is: I don't even consider VSCode a superior
| text editor, it's just that Emacs is _so slow_. I used Emacs
| back then because compared to many other editors and IDE it
| allowed me to work faster, but VSCode despite all its
| shortcomings has done the very same thing Emacs did for me
| previously.
|
| I still use Emacs every day at work just for Magit, but
| whenever Emacs freeze just for a few seconds every time I
| perform a big merge I just feel like finishing up the task in
| VSCode
| Koshkin wrote:
| > _Emacs is _so slow__
|
| That's exactly what it felt like in 1991: "eight megabytes
| and constantly swapping!"
| mtalantikite wrote:
| I had a similar experience recently, where I had to spend
| some time working in TypeScript on a React front-end and my
| emacs really was falling over unfortunately. Tried tide,
| tried the LSP, but ultimately I found myself in VSCode in
| order to make the deadline. Turns out there is a pretty
| great magit layer in VSCode
| (https://github.com/kahole/edamagit), and as a former long
| term vim user that had been using spacemacs, a great
| spacemacs-like bundle for VSCode
| (https://github.com/VSpaceCode/VSpaceCode).
|
| It's the first time I've actually felt like I could drop
| emacs if I wanted to, I actually was enjoying the setup.
| michaelmrose wrote:
| Do you use Emacs in windows?
| harrygeez wrote:
| I've used it on Windows before and I think I know what
| you're talking about. However, right now I'm using it on
| macOS actually, the mac-port to be more specific.
| tyingq wrote:
| I can see that for most people. It is really something,
| though, to watch someone really good with Emacs or Vim fly
| though something like a complex refactoring.
| brandonmenc wrote:
| You can refactor with IDEs too, and I don't remember emacs
| being better at this than JetBrains is.
| tyingq wrote:
| Sure, I assume you can, but since Emacs/Vim is a sort of
| environment that encourages terse keybindings, fast call
| outs to the shell, etc, that's where I've seen more
| people that can seem to do stuff almost subconsciously.
| ddoice wrote:
| Only available resources, modern IDEs are like hardware
| vendors wet dream came true.
| pjmlp wrote:
| Eight MegAbytes of Continuous Swap.
| hollerith wrote:
| It is easy for people who love Emacs to believe that most
| people (or most programmers) would come to love (or prefer)
| Emacs if they would only put in the time to ascend the
| initial learning curve. But this belief is an instance of
| what is sometimes called the "typical-mind fallacy": an
| underestimation of how different people's minds are.
|
| GNU Emacs was my daily driver from 1991 to late last year,
| when I switched to vscode. I wrote many lines of Emacs Lisp
| code -- 20,000 lines of which I "kept": I arranged for those
| lines to get loaded into Emacs every time Emacs starts, and
| since the code was almost all "UI" code, any particular
| function or piece of the code ran on average at least several
| times for every hour I spent using Emacs.
|
| Although I do not regret choosing Emacs in 1991, vscode suits
| my particular mental make-up better than GNU Emacs did.
|
| To take one example, I spent hours configuring Emacs to be
| less chatty. I turned off the bell that sounds every time the
| user makes an error (where for example asking Emacs to scroll
| down when the bottom of the document is already visible in
| the window is considered an "error" -- in contrast to
| vscode's not feeling the need to send a message to the user
| or get the user's attention when that happens). I tried (and
| mostly succeeded) in turning off the repetitive messages
| Emacs displays in the echo area, e.g., displaying "Wrote
| foo.c" any time Emacs writes to file foo.c and, e.g.,
| (particularly distracting to my train of thought) the
| "Autosaving..." message that regularly appears in the Echo
| area X seconds after I stop typing. In contrast, vscode is
| silent (non-chatty) enough to suit me in its default
| configuration -- like most GUI apps since the introduction of
| the Macintosh in 1984 are.
|
| P.S. The way I got rid of the "Autosaving..." message was to
| turn off Emacs's autosaving functionality altogether and add
| my own autosaving functionality, which consisted of a call to
| save-buffers every time the user switches buffers.
| joaogui1 wrote:
| Did you use orgmode and mu4e? If so what are you using in
| their place now?
| hollerith wrote:
| To read mail, I used (version 5 of) Kyle Jones's VM, but
| (out of my being too lazy to configure mail fetching and
| mail sending) switched to gmail.com about 6 years ago.
|
| I never embraced org mode because I didn't want to learn
| another few dozen keyboard shortcuts ("keys" in Emacs
| terminology). There are for example in org mode keyboard
| shortcuts for moving the current line up a line and down
| a line. Even before I saw vscode my reaction to learning
| about those 2 shortcuts was that such functionality would
| be useful (particularly in to-do lists), but I would
| prefer to execute the functionality by dragging with the
| mouse, which it turns out that vscode lets me do (in its
| default configuration): particularly, I click on the
| line's line number to select the line (to set the mark
| and activate the region in Emacs terminology) then move
| the mouse cursor into the selection, then drag. (In
| emacs, I'd kill and yank to move a line relative to the
| other lines -- and I configured my emacs to have a menu
| on the right mouse button with the kill and yank actions
| on it.)
|
| In general, vscode is a nice environment for keeping to-
| do lists. Consider for example this next small
| "hierarchy" of actions: buy milk
| drive to store find car keys
|
| If we replace "find car keys" above with a string of text
| too long to fit on one line, then the basic structure of
| the small hierarchy becomes obscured in Emacs (even with
| visual-line mode on) but not in vscode as I explain in
| greater detail here:
|
| https://news.ycombinator.com/item?id=25311743
| aporetics wrote:
| C-x t
| cercatrova wrote:
| I do something like this in VSCode as well, Markdown todo
| lists: - [ ] Task 1 - [ ]
| Task 1.1 - [x] Task 1.1.1 - [
| ] Task 1.2
|
| etc.
|
| In particular, I break down yearly goals into quarterly,
| monthly, weekly and daily, each another node in the tree
| getting increasingly more specific.
|
| It really helps understand the flow from the highest to
| the lowest levels of details. Only problem is if goals
| change midway, it's not propagating up the tree
| automatically. I just leave it like that though, not
| gonna manually fix that.
| sedev wrote:
| From a recent HN discussion, I learned that emacs has had a
| sampling profiler built in -- not on MELPA or something, first-
| party! -- since about 2013. How many widely-used applications
| these days contain a facility for asking "why is the command I
| just issued executing slowly?" and for _doing something about
| it?_ As far as I'm concerned, that's now table stakes for a
| programming environment: you should be able to not just run a
| profiler on whatever program you're using the editor to
| interact with, but to do robust profiling on your editor
| itself.
| a_e_k wrote:
| There's also M-x emacs-init-time if you want to know how much
| a change to your configuration impacted start-up time.
| mhh__ wrote:
| Automated profiling is one of the best things to get right
| over a few weekends. I'm slowly putting together something
| for the D language to do it but it's a bit of a pain.
|
| Anyone know of CI service that can have use rdpmc/perf_events
| on the cheap?
| lima wrote:
| In terms of IDEs, IntelliJ also comes with built-in
| profiling. And every modern web browser has robust built-in
| profiling tools.
| lordgrenville wrote:
| I think you're referring to (its wrapper around) Python
| cProfile, not a profiler for the IDE itself?
| heartbreak wrote:
| IntelliJ has a profiler for the IDE itself, too.
| hibbelig wrote:
| It's very interesting. I used Emacs for a long time, but slowly
| got weaned off it.
|
| - I used it for email, then I had to collaborate with people
| who wrote "please see my comments in orange below". (Of course,
| they were Outlook users.) Emacs did not show that orange color,
| so I didn't know... Maybe these days it's possible to read
| Outlook emails nicely in Emacs.
|
| - I used it for development, then the Java software I worked on
| got too big to internalize all APIs and Eclipse completion and
| refactoring really helped. I did try to build the Eclipse
| "quickfix" thing in Emacs, but all I got done was to add a
| missing import (because JDEE, I think it was, provided that
| functionality).
|
| - I switched from Linux to Windows because the world around me
| was like that, and so I could help junior colleagues with their
| EOL problems...
|
| - I used Mercurial (hg) for a while and TortoiseHg was really
| nice, so I didn't feel the need to use Emacs for this.
|
| It's a pity, really. Some aspect here, some aspect there, and
| then you get pulled away from Emacs.
|
| Now, with LSP, perhaps Emacs could offer code completion and
| refactoring, but the Java app I work on builds with gradle, and
| I have no clue how to tell the Java/LSP thing about the class
| path... So I'm on IntelliJ...
| emptysongglass wrote:
| I don't understand why people are moving Linux --> Windows.
| At the company I work for everything is native to Linux--I am
| floored by the number of interns we get who are using Windows
| (it's _all_ of them). We have an intake script for getting
| them up on WSL2 with our stack on top but man these graduates
| are CompSci people and they did 4 plus years of CompSci using
| Windows? I can only imagine the pain. Or rather, I know the
| pain since I have occasionally dipped my toes back into that
| world of hurt.
|
| A non-WSL2 Windows person doesn't get the benefits of Nix,
| usually doesn't live life on the shell (since every Windows
| program is gui first), doesn't do dotfiles management (you
| can but paths for the git Atlassian method are non-obvious),
| ssh password protected keys are a PITA...good God I could go
| on ad nauseum.
|
| I work in this industry because I love computing. But these
| Windows jockeys I dunno I get the feeling they don't
| necessarily love computing? Or in the way that it's this
| mundane tool for the production of money-points that they can
| then exchange for money. I also am receiving the money-points
| and it is good. But lemme crack open your head and pour in
| the _magic_ y 'know?
| spamizbad wrote:
| Having used all 3 major platforms, for me the developer
| experience in Linux really is the best. And I say this as
| someone currently trapped on MacOS. For personal hacking I
| use an older Dell XPS15 w/Ubuntu and it's like a breath of
| fresh air every time I dig into a project. Containers just
| seem to work so much faster, there's fewer weird things, no
| hiccups, and things like git and Emacs scream compared to
| Windows.
|
| I totally get why people prefer Mac and Windows outside of
| software development. But as a working developer it's
| really worth the effort, if given the option, to invest in
| learning Linux and developing on it.
|
| Interns doing the whole WSL thing makes me cringe. Not
| great for your career IMO unless you plan on making a quick
| exit from the dev side of things.
|
| This might be a controversial take, but I feel like A
| "worse" developer with a solid workflow in Linux will
| appear more productive than a somewhat more skilled
| developer getting dragged down by WSLisms.
| hazz99 wrote:
| I always felt that Mac struck a good balance between my
| programming productivity and "the rest", because I could
| use some great applications that were otherwise
| unavailable on Linux, sadly.
|
| What pains did you have? Docker support was a big one for
| me, but otherwise I haven't encountered anything too bad.
| spamizbad wrote:
| Docker and occasionally periodic sluggishness that
| includes my pointer skipping on some websites. Also,
| despite a faster CPU and an SSD at only 14% utilization
| things like emacs and Sublime seem more sluggish in terms
| of I/O.
|
| I would probably benefit from a reinstall of Big Sur:
| this machine has gone through 3 OS upgrades.
|
| What I really appreciate on Linux tho is workspace
| ordering and switching. Which I don't think you can
| customize to the degree you can on Linux anymore in Big
| Sur.
| Filligree wrote:
| Speaking as someone who regularly attempts to switch _back_
| to Linux, I did that because the Windows desktop is a
| genuinely nicer experience. In no particular order...
|
| - The traditional start menu / taskbar is genuinely nicer
| than what Gnome attempts to force on me. OS X is also
| genuinely nicer than what Gnome attempts to force on me.
| I'd take either over Gnome.
|
| - The Linux desktop environment is laggy. This is difficult
| to measure objectively, but nothing moves _smoothly_ and
| responsiveness is through the floor. I 'm using a 144Hz
| screen; why can I see windows jerk from position to
| position when I drag them?
|
| The Zen kernel helps with some of that, bringing it about
| to the same responsiveness as Windows -- which is still
| well below OSX. No desktop environment provides it by
| default, and in most it's difficult to install. On NixOS
| it's just "boot.kernelPackages = pkgs.linuxPackages_zen;",
| but it's still not the default.
|
| - nVidia's drivers are poor, and there are a lot of sharp
| edges. I'm using one of their GPUs. No, I can't switch to
| AMD; I need it for CUDA, and anyway GPUs aren't exactly
| cheap.
|
| - AMD's drivers are of inconsistent quality, and I couldn't
| buy a 6800XT even if I'm willing to sell my first-born. Ok,
| that's also true for nVidia's newest GPUs, and Zen 3,
| and... different rant entirely.
|
| - HDR basically doesn't work.
|
| - Mixed-DPI screens basically don't work.
|
| - HiDPI in general is glitchy.
|
| - kanjiTomo doesn't work on Wayland, because there's no
| solid story for the screen capture protocol.
|
| - Bluetooth audio basically doesn't work.
|
| ...
|
| Windows isn't perfect, but for me the Linux desktop died to
| a thousand paper cuts. Every two or three months I make
| another attempt at getting it up to the same standard I get
| from Windows, and every two or three months I fail.
|
| Does the above sound kind of entitled? It's not. I'm not
| demanding that anyone should make this work for free; I've
| never _paid_ for the Linux desktop. The fact is, however,
| that it isn 't good enough to use without unpleasant
| consequences, and I've spent far too much of my life
| fiddling with it already. At this stage I just want
| something that doesn't eat my evenings.
| axaxs wrote:
| Vanilla Gnome is terrible. You must embrace extensions.
| At first I loathed the idea, but it's just become part of
| life. One for a dock, one for weather, one for tray
| icons, and if you prefer, one for top menu that gives you
| your more traditional start menu type thing.
|
| Or, there's always Xfce or KDE, of course.
|
| AMD drivers are now open source and finally working well.
| Nvidia is not, granted.
|
| Bluetooth audio works well, even on rando cheap noname
| devices I've tried. My primary speakers are some Logitech
| bluetooth pair.
|
| Don't use wayland. Run gnome in xorg mode.
|
| In fact, I'd go as far as to say I'm blown away by how
| much -just- works on Linux. My printer is autodetected on
| the network and print. My wireless mouse works. My
| monitor runs at 1440p.
|
| If you're open to it, I always suggest using a modern
| distro that stays up to date because you get better
| hardware support(if using new hardware, that is).
| Typically, that means something Arch based, but there are
| distros around making that simple.
| eeperson wrote:
| > Don't use wayland. Run gnome in xorg mode.
|
| Interestingly, for me, I only see some of the issues the
| GP mention when using xorg instead of wayland.
| no_wizard wrote:
| This all highlights is a lot of choices and "do this
| don't do that" kind of things I don't like about the
| Linux Desktop environment, I don't want to think about
| these kinds of things in my usage of a desktop. It's a
| summation of everything I find lacking in the Linux
| desktop community
| csomar wrote:
| You are doing it wrong. If you are using Linux, use a
| window manager (sway or i3 are a good start). I'm running
| Archlinux with Nvidia and it's going great. No problems
| with the card, performance, and I have 3 screens of
| different DPI. I'm yet to try Bluetooth, though.
|
| ps: If you are using an Nvidia card, you can't,
| unfortunately, use Wayland.
| philderbeast wrote:
| if it doesn't work out of the box, Linux is doing it
| wrong.
|
| why should I have to install an os, then change my
| desktop environment, then spend weeks learning keyboard
| shortcuts for said new environment, to get basic
| functionality working.
| tartoran wrote:
| I use windows for work and as soon as im done I reboot on
| a linux partition. My daily driver is linux as I hate the
| lack of control I have and the insecurity (i feel that
| microsoft does whatever behind the scenes) i get on
| windows. For example after an update windows shoves me an
| edge icon on the desktop. I removed all the bloatware on
| the laptop and multiple times things are re-enabled after
| an update. I also cannot turn off updates if i want to.
| There are a few services for which I as an admin have no
| way of turning off or even change any settings. Wtf! I
| was able to gain some control of my machine with some
| registry settings but at the next update everything was
| overwritten. F that, i don't wanna play whack-a-mole
| anymore. If i need to use some windows software i boot
| the windows partition, then when done boot up on linux.
| Ubuntu these days is low friction, most Hw works out of
| box, etc.
| adrian_b wrote:
| While I have to use occasionally Windows for work, on my
| own desktops and laptops I have used only Linux for
| almost 20 years and I have not seen any of the problems
| encountered by you.
|
| Your problem with Wayland I could not have seen, because
| I have not attempted to use Wayland yet, but most of the
| others seem to be Gnome related.
|
| I have never used Gnome, as I have never liked what I
| have briefly seen in the Linux distributions that default
| to Gnome.
|
| Perhaps that is the reason why I did not have your
| problems.
|
| (While KDE 3.5 was much better than Windows was at that
| time, I have been hugely disappointed by the unbelievable
| regressions in KDE 4, so I have also abandoned KDE at
| that time and I am using XFCE since then. XFCE imposes
| very little restrictions on the desktop applications,
| allowing the free mixing of graphical applications that
| were designed for either Gnome or KDE, so I can choose
| whichever works better.)
|
| Linux is much more diverse than other operating systems
| and there are a lot of alternatives for most components.
|
| Almost all complaints that I have seen about Linux, were
| in fact not applicable to Linux in general, but only to
| certain specific configurations that I would not attempt
| to use, because I agree that they are bad.
|
| Unfortunately, choosing a Linux configuration good for a
| certain purpose and for certain hardware frequently
| requires either a lot of experience or the wasting of
| much time with trying various variants.
| philderbeast wrote:
| "Unfortunately, choosing a Linux configuration good for a
| certain purpose and for certain hardware frequently
| requires either a lot of experience or the wasting of
| much time with trying various variants."
|
| This is why I stay with windows for my dev machines and
| either use WSL or ssh to a linux box. All my machines at
| home have WSL2 installed and I use it as my default
| shell, I never open powershell/cmd, they may as well not
| be on my machine, for all my development needs and use
| all the linux tools that I would be using if I was on a
| native linux desktop.
|
| I can be up and running on a windows dev machine in the
| time it takes me to download VScode and open it, or I can
| spend weeks trying to get a linux environment to the same
| place. With my setup I still have all my linux toolset
| that I would use on a linux desktop, but I don't have to
| contend with all the issues of getting a linux desktop
| environment running.
|
| I have run into all the same problems as the parent of
| this and more, I have tried different desktop
| environments including Gnome, KDE, Mate, Cinnaman, and
| XFCE. I have moved between xorg and wayland more times
| then I care to count, each ended up giving a different
| set of problems.
|
| At the end of the day, I want to spend my time being
| productive and getting work done, not fighting with my OS
| to get the basics running. I love linux but it's just not
| ready to replace windows on the desktop.
| therealmarv wrote:
| I have also 20 years of Linux experience. XFCE (I love
| XFCE btw) does not solve this points mentioned. I think
| you're biased and this are valid points OP mentioned:
|
| - nVidia's drivers are poor, and there are a lot of sharp
| edges. I'm using one of their GPUs. No, I can't switch to
| AMD; I need it for CUDA, and anyway GPUs aren't exactly
| cheap.
|
| - AMD's drivers are of inconsistent quality, and I
| couldn't buy a 6800XT even if I'm willing to sell my
| first-born. Ok, that's also true for nVidia's newest
| GPUs, and Zen 3, and... different rant entirely.
|
| - HDR basically doesn't work.
|
| - Mixed-DPI screens basically don't work.
|
| - HiDPI in general is glitchy.
| inertiatic wrote:
| That's very weird.
|
| I'm using both, Linux for 8 hours at work and then
| Windows for my personal computing needs.
|
| I live mostly in the browser. Both OSes basically work. I
| can move my windows around lag free, entirely, always.
|
| Bluetooth audio works. This 4k screen I'm using now for
| the first time on Linux just worked.
| Ericson2314 wrote:
| That's why I work at a place where devs are basically
| required to use Linux. It's a great filter and training
| mechanism.
| csomar wrote:
| That's what they teach them in University.
| dleslie wrote:
| Most of the world uses Windows.
|
| If you're building software targeted at most of the world
| it makes sense to use Windows.
| inertiatic wrote:
| Most of the world uses Android to run their browsers,
| right? Should I develop on Android?
| pjmlp wrote:
| Actually according to Google own statistics, most of
| Android Studio users are on Windows.
| BeetleB wrote:
| Are you suggesting that most of the existing Windows SW
| out there could be developed on Linux and would just run
| fine on Windows? Can MS reasonably develop MS Office on
| Linux? Can Adobe develop Lightroom on Linux and it'll
| just work on Windows?
|
| For most Windows SW, the answer is no. So the analogy
| with Android doesn't make much sense.
| csomar wrote:
| Not really. Android, Web, Embedded, Networking can be
| done in Linux.
| dleslie wrote:
| I meant desktop software, but even so most Android users
| also use Windows, and pair Android with Windows. Most
| Android developers use Windows.
| pjmlp wrote:
| Back when I did my degree in the mid-90's, our labs were
| running a mix of LC III, Windows 3.11 for Workgroups, the
| recent Windows 95 and terminals for the DG/UX server.
|
| The only classes using UNIX were the ones specific about
| UNIX content.
|
| A the end of the 5 years, the DG/UX server had been
| replaced by a Red-Hat one and most terminals, were dual
| booting between the university own distribution and
| Win95/95 OSR, some of us also had access to the freshly
| released Windows NT.
|
| The large majority of students was still only booting into
| GNU/Linux for the UNIX related labs.
|
| Anything related to graphics programming, Smalltalk,
| databases, AI, engineering tools (UML, Boochs, CASE),
| digital circuits, was done on Windows/Mac OS (System).
| BeetleB wrote:
| > But these Windows jockeys I dunno I get the feeling they
| don't necessarily love computing?
|
| When I was younger, I wanted to work in places that had a
| passion for these types of things.
|
| Older me realized that was a bad idea. It inevitably seeps
| into things unrelated to doing the actual work (even
| performance reviews via 360 feedback). People are paid to
| do a job, and I've found that whether they love computing
| or not is mostly orthogonal. Sure, there are some that are
| wiz's because of it, but they're usually neutralized by
| those who become ideological and inflexible because of it.
|
| Tangentially related: I'm a Linux guy - it's been my
| primary OS for almost 20 years now. However, at my current
| company, I prefer roles that don't involve Linux. The
| reason is they typically will not give me my own machine -
| I'll merely get an account on some server, with a poor
| window manager, and missing a lot of the nicer tools I use
| on my home machine, and no superuser privileges. In the
| last job I had, their provided Emacs was a little too old
| for some of the features I used, and I had to compile my
| own Emacs from scratch (along with tens of other dependent
| packages). This was time wasted for me and the company. At
| least on my Windows machine at work, I have Admin
| privileges and can make things nicer.
|
| Paradoxically, it is _because_ I 'm a "hard core" Linux
| user that I prefer Windows for work. I've optimized my
| Linux workflow, and if my work cannot provide me my
| preferred tools/window managers, I might as well just use
| Windows.
|
| I don't even use WSL. I use xonsh, which works fairly well
| on Windows. I have multiple desktops on Windows. And most
| importantly, I live in Emacs which for the most part works
| just as it would in Linux :-)
|
| (And no, using/installing Emacs on Windows is not a pain,
| despite what you often hear - the last time I did it some
| months ago, it was literally "Download and unzip into
| directory and you're good to go.")
| dleslie wrote:
| > I switched from Linux to Windows
|
| This is where many people leave Emacs. It's not that there's
| better tools on Windows, it's that Emacs on windows is
| terrible.
|
| Magit is orders of magnitude slower, for instance, and
| external tool integration is grossly impeded by the poor
| availability and quality of package management on Windows.
|
| Maintaining Emacs on windows takes considerable effort.
|
| Personally, I make do with WSL1 and Emacs. WSL2 is
| intolerably broken when working on NTFS folders, so it's a
| nonstarter. This means Docker is broken (mounts don't work)
| but Emacs works well.
|
| Yah, it sucks.
| mbrumlow wrote:
| Well with wsl2 I gave windows a go for my work dev
| environment. And so far emacs had been amazing via wsl2 and
| a x server.
|
| I should note I did modify the xserver to allow me to
| toggle individual windows going fullsceen. And am running
| native emacs (which is blazing fast)
| dleslie wrote:
| WSL2 + X server was my go-to for a few weeks, but then a
| rather large repo I access, with git-lfs, became
| corrupted due to WSL2 + NTFS bugs. They've been mentioned
| on HN before.
|
| Thereafter, every day or two the same bug would arise and
| I'd have to lose an hour or two recovering the repo. Just
| a week or so ago I switched back to WSL1, and I ssh into
| an RPi4 to access docker containers, using qemu and
| binfmt to execute x86 code slowly.
|
| Yah, it sucks. ;)
| BeetleB wrote:
| > it's that Emacs on windows is terrible.
|
| I use Emacs on Linux and Windows equally. I've used Emacs
| on Windows at work for a decade. Other than magit, there's
| virtually no difference in experience between the two
| platforms.[1] Of course, perhaps you use a different set of
| features than I do.
|
| > Maintaining Emacs on windows takes considerable effort.
|
| I install it on my work laptop every 2-3 years, and for the
| last 5 or so years, it's literally been "Download, unzip
| and run." Occasionally I have to make registry changes to
| get org-protocol to work. Even 10 years ago, it was still
| fairly simple - just a bit of extra work to get some GTK
| related stuff installed as well. But right now it couldn't
| be easier.[2]
|
| And I don't even use WSL. This is native Windows.
|
| [1] Of course, if your Emacs is calling out to tools like
| grep/find, etc, you'll have issues unless you install those
| tools. Although these days, it's not hard to configure it
| to use ripgrep and fd, which has excellent Windows support.
|
| [2] And perhaps installing LaTeX if you want to export org
| files to PDF.
| tom_ wrote:
| For whatever it's worth, I've found the same thing: that
| the amount of effort required to use Emacs on Windows is
| minimal. Since Windows is non-POSIX, inevitably some
| things are different, but it doesn't take much to deal
| with this.
|
| My .emacs.d folder (now 15 years old, and a bit of a
| monster, a whole git repo with thousands of lines of
| nonsense plus a pile of submodules) has no more than a
| few spot hacks for Windows vs POSIX vs macOS.
|
| (The most annoying bit has probably been keeping on top
| of the font names! - but interestingly these are actually
| super easy to deal with on Windows. It's Unix that's the
| pain in the arse here.)
| dleslie wrote:
| Mostly issues with lsp servers; particularly ccls and
| omnisharp.
| zupatol wrote:
| I've been using the mingw windows version every day for
| years. I used to spend time now and then to make new things
| work, recently I switched to doom emacs, and almost every
| new functionality or package I try works out of the box.
|
| It's true that Magit is slow, but I still prefer it to the
| command line.
| dleslie wrote:
| I'm going to give Doom a shot; I ignored Spacemacs
| because rebinding native keys and forcing evil-mode was a
| nonstarter for me. If I wanted to use Vim then I would,
| and did for a time.
| kenbolton wrote:
| "forcing evil-mode"?! Spacemacs asks if you want to use
| "evil", "holy", or "hybrid" mode early in the process.
| dleslie wrote:
| Interesting, I suppose I missed that when skimming the
| GitHub repo readme.
| dleslie wrote:
| ... and that was an immediately disappointing experience.
|
| 1. Saving customizations didn't work.
|
| 2. Launching Emacs as a client that auto-launches a
| server _always_ failed the first time.
|
| 3. I really don't need a custom package manager built on
| top of another custom package manager to replace the core
| package manager. straight.el would've been enough,
| thanks.
|
| 4. My batteries-included Emacs launches a server in a few
| seconds, a client almost instantaneously; doom took
| minutes to launch a server on my Pinebook Pro and clients
| took a few seconds.
|
| 5. Another needless dotfile dir in my home. ~/.doom.d
| could easily have been ~/.emacs.d/doom.d
| 2pEXgD0fZ5cF wrote:
| Compared to many I am a relatively new emacs user, back when I
| began programming I let myself get intimidated by the scary
| stories told about Emacs and Vim configuration. Turns out a
| huge emacs configuration is not needed, in fact I notice my
| emacs config actually started to become smaller over the recent
| times. It's hard to express how much I value emacs now and the
| only regret I have is that I did not give it a chance earlier
| when I still exclusively used "modern" editors and IDEs.
|
| Another aspect I see rarely mentioned is the emacs evil[1], it
| basicelly provides a full vi layer, it's much more than your
| average "vi keybindings" plugin. Emacs vs Vim? Not a question I
| have to give any thought when I can use both and switch between
| them without much effort.
|
| [1]: https://github.com/emacs-evil/evil
| omaranto wrote:
| Evil is rarely mentioned? I guess we hang out in different
| parts of the internet.
| monadic3 wrote:
| I'm a little suprised they didn't mention DOOM or
| Spacemacs.
| jackcviers3 wrote:
| Yeah, mine is like 500 lines with use-package and lsp-mode.
| And it works on Mac osx, windows, and Linux, works with Java,
| scala, typescript/Javascript, python, yaml,c#, xml, html,
| haskell, ruby, c, and c++. Haven't done any Android or ios
| work, but I'm sure it would work with that as well.
| cannabis_sam wrote:
| I'm kinda in love with VSCode at the moment, even though I have
| used Emacs (or at least some mac customized version, maybe
| SpaceEmacs?) for agda-mode
|
| When I tried to go outside of the agda-mode documentation, to
| try to learn emacs properly, I kinda struggled to find a
| reliable tutorial or introduction that got me started on how
| emacs and the culture/ecosystem works. (Maybe it was just me
| who got tripped up by my unfamiliarity with it.)
|
| Do you have a good recommendation for a way or a book to get
| into emacs?
|
| It does seem nice to run your editors in terminals, instead of
| the other way around.. haha
| monroewalker wrote:
| I've had a similar experience to yours. Even when I'm curious
| and motivated to learn, I find it hard to learn more and
| improve. There seems to be a lot of assumed knowledge from
| most tutorials and articles about where to place code
| snippets, configure things, what ui elements are called, etc.
| One thing I'd recommend is joining the spacemacs
| discord/slack and just asking for help on the questions you
| get stuck on.
| submeta wrote:
| I do admit VSCode is a very polished product. Just like the
| other tools I mentioned (PyCharm, Kaleidoscope for diffs,
| Tower App as git client etc).
|
| What makes Emacs different - when you look beyond the simple
| looking interface - is the possibility to make the packages /
| plugins work together not intended by the original authors by
| creating hooks that change the return value of the packages,
| and you can tie together the tools by writing Elisp scripts.
|
| As to where to start: There are many young and ambitious
| hackers who are re-developing Emacs + Lisp for creating their
| custom dev / hacking / writing environment, and who create
| wonderful youtube videos. Magnar Sveen started doing this
| several years ago (emacsrock.com), then there are (among
| others) Protesilas Stavrou or the channel of "System
| Crafters".
|
| When you prefer reading books: "An Introduction To
| Programming In Emacs Lisp" from Robert Chassell is excellent
| for learning the basics of Elisp. Mickey Petersens "Mastering
| Emacs" is excellent. Harley Hahn's Emacs Field Guide is
| recommended as well.
|
| Also, r/emacs and r/orgmode are excellent communities.
|
| Give yourself time. Don't hurry. Emacs is a tool that will
| keep your company in twenty years from now, when all the
| hyped tools are long gone (Textmate users moved to Sublime,
| then some of them to VS Code, who know's what's next?).
| 1MachineElf wrote:
| >Magnar Sveen started doing this several years ago
| (emacsrock.com)
|
| Great comment! But you were missing an s in this FQDN.
| Here's a working link: http://emacsrocks.com/
| aprdm wrote:
| Textmate users moved to sublime because they felt it was
| better, so did sublime users to vscode.
|
| They could get a better experience with very minimal time
| of training or mastery, because the next tool they used was
| user friendly and better for them.
|
| What's wrong with that ? If new tools that are better and
| easy to use keep coming then that is something to
| celebrate.
| holri wrote:
| Emacs has great interactive tutorials built in: C-h t and has
| a great info system and help functions: C-h h also:
| https://www.gnu.org/software/emacs/tour/ There is really a
| lot of excellent documentation built in and the source code
| is very easy to find and read.
| InvOfSmallC wrote:
| Maybe I'm lazy but I prefer to buy an intellij product.
| taeric wrote:
| Wasn't emacs forked several times in the past? Would be curious
| to see an exploration of the difference and why they converged
| back to mainly one offering. (Or are there others still
| thriving?)
| Macha wrote:
| On vim vs neovim: My deep vim usage hasn't really changed much
| since it stopped being my primary editor usage 5 years ago, so
| this isn't the world's most informed opinion, but I've not
| noticed a drastic difference between vim and neovim. The one
| difference I've noticed and literally the only reason I've moved
| to neovim is that it uses XDG dirs by default and thereby
| clutters my home directory less. Otherwise, the two seemed pretty
| interchangable.
| city41 wrote:
| I essentially treat them as the same thing and will switch back
| and forth as one gets a regression or the other fixes an old
| regression. My config works perfectly in both and frankly I
| can't tell the difference 99.999% of the time.
| caymanjim wrote:
| Vim 8 and neovim don't have any major differences. Even as a
| decades-long Vim power user, I can use either. neovim deserves
| credit for stimulating Bram to accept changes, though. Most
| notably Vim 8's support for async plugins. I don't think Vim 8
| ever would have happened without neovim.
| yudlejoza wrote:
| Well after reading your comment, I thought maybe the big win
| for neovim might be reduced (code-size) complexity. So I
| checked the code sizes for latest versions of both vim and
| neovim (from github):
|
| - vim is at 900k (717k without po files)
|
| - neovim is at 677k (562k without po files)
|
| Savings of only 25% of code size is unfortunate. It's even
| worse if we ignore the po data files (only 22%). I would like
| to see a fully-capable modern editor/IDE for under 100k of
| clean, readable code. Until then, the quest goes on.
| brixie wrote:
| On the discussion of values, I'd also like to submit "(expected)
| longevity" for consideration, which I think is distinct from
| "stability".
|
| I made the switch from Vim to Neovim as soon as I felt confident
| that (1) the project was going to be around for a while, and (2)
| it was on track to "overtake" Vim (you may choose to disagree
| with me on this, I found built-in LSP to be a compelling selling
| point, but the specifics aren't really related to the point I'm
| trying to make). That it was almost completely a drop-in
| replacement, down to the init file, certainly didn't hurt.
|
| Under the author's framework, Neovim apparently prefers
| "progressiveness" while Vim prefers "stability", and those two
| sound dimetrically at odds based on their descriptions; but both
| have large, active communities that aren't going anywhere. I'm
| not sure I can say the same about Kakoune, for example, which is
| a certainly a promising project but hasn't yet convinced me to
| jump the fence.
|
| [edit for Emacs thoughts]: Now that I think about it, "text
| centrism" in my mind is also closely related to longevity. I
| don't care as much about the properties of plain text as I do
| about the fact that I'll be able to open/view/edit them _even if
| the application ecosystem dies_. I find Emacs attractive here
| with org-mode and, to a lesser extent, org-roam (the comparison
| here would be between e.g. SaaS productivity offerings like
| Notion).
| AltruisticGapHN wrote:
| Does neovim have a gvim equivalent nowadays?
|
| The redraw speed for gvim on native ubuntu is awful, you can
| literally distinguish when top and bottom of the window is
| drawn, it doesn't feel good. Sublime Text redraws almost
| instantly the entire window when you page through code.
| moeris wrote:
| > I'm not sure I can say the same about Kakoune, for example,
| which is a certainly a promising project but hasn't yet
| convinced me to jump the fence.
|
| I've made that jump a couple of months ago, and so far I love
| it. There isn't as large of an ecosystem, but Kakoune just
| feels better integrated with the environment. Is your hesitancy
| based on some particular feature, or the ecosystem, or
| something else? Or is there some default that you dislike?
|
| I feel like it doesn't need to have as many maintainers in
| order to be successful, because its philosophy is much more
| spartan. The maintainers pretty aggressively keep the project's
| scope in check.
| brixie wrote:
| I haven't tried Kakoune, so I'm not really qualified to speak
| about its merits or demerits. From a place of limited
| knowledge, I see nothing wrong with it, and want to reiterate
| that it seems really interesting and worth keeping an eye on.
|
| To add some nuance to my earlier comment: I don't really
| worry about the existence of Kakoune (or
| $OPEN_SOURCE_SOFTWARE_PROJECT) in a trivial sense; we'll
| always be able to find a copy somewhere and compile it from
| source, modify it, etc. That being said, I think one of the
| advantages of a large/durable ecosystem is that it lets me
| worry less about problems I don't yet have. I use (neo)vim
| daily, but there are certainly still lots of ways I can
| improve my workflow. Inevitably I'll run into something that
| goes wrong or doesn't work like I want it to, and a larger
| and more active community makes it more likely that someone
| else has already figured out how to fix it.
|
| The (relatively small) differences in keybindings are also
| worth a mention, but I think the vims have a bit of an unfair
| advantage here; IMO learning vim keybindings is almost
| unquestionably a good investment because you'll find them
| everywhere.
|
| > Kakoune just feels better integrated with the environment
|
| Out of curiosity, is this an argument for enjoyment or
| productivity? :) (Either is a fine answer! I frankly can't
| measure the latter so my personal usage of vim is probably
| motivated by the former.)
| moeris wrote:
| > I think one of the advantages of a large/durable
| ecosystem is that it lets me worry less about problems I
| don't yet have.
|
| That's true. If you're finding numerous workflow problems
| with neovim, it'll probably be true of Kakoune, as well.
|
| > > Kakoune just feels better integrated with the
| environment > > Out of curiosity, is this an argument for
| enjoyment or productivity?
|
| Both, though it's a more persuasive argument for
| productivity. Because it's easier to integrate with the
| environment, those workflow problems you mention can be
| solved by delegating to the environment, in some cases. For
| example, kakoune delegates to the environment for window
| management -- so things like resizing windows and switching
| between them is handled through tmux for me. Obviously,
| though, that's could be a poor substitution for some
| dedicated solutions in the editor. But overall, I prefer
| it, as it allows me to get familiar with unix utilities,
| which are useful in a wider range of applications. It also
| means there isn't an arcane scripting language associated
| with using the editor. I have a thing against vimscript.
|
| > differences in keybindings are also worth a mention
|
| I suppose. Having used vim for years, I was able to pick up
| the keybindings relatively quickly (< 1 day); they're
| almost identical. The main difference, that the selection
| comes before the action, also makes it easier to pick up.
|
| But, yeah, that muscle memory is a loss. I find myself
| trying to do multiple selections and use kakoune
| keybindings in bash vi-mode, often.
| abhinav22 wrote:
| VSCode is Slow to me. Emacs is great for lisp programming and I
| like the TODO feature of org mode, there's a lot of useful
| features, however it's a bit too different from modern UI so I
| get a bit jarred using it from time to time --> my job is using
| many programs, of which an editor is one, so I can't happily stay
| in emacs 90% of the time.
|
| I really like Sublime - fast and clean. Currently I use both
| sublime and emacs depending on what I'm doing.
|
| I wish I discovered emacs 20 years ago! How many years I wasted
| without it :(
| the__alchemist wrote:
| I'm curious if the userbase of these have tried a Jetbrains IDE
| (PyCharm, CLion, IntelliJ etc). I've found the Jetbrains IDEs
| understand the language more thoroughly - this means better code
| navigation, error-catching, and refactoring. I've also found the
| implicit project-first focus (as opposed to file-first) to be
| more practical for most things I work on.
| kubanczyk wrote:
| A small gripe for me was startup time of JetBrain IDEs. Another
| small one is that they need /dev/null redirection because they
| spew weird errors to stdout/stderr.
|
| A big one: on Windows, do they have a WSL1 or WSL2 integration
| now, i.e. cam they run/debug the compiled artifact under Linux?
| Use Linux-based compiler/toolchain?
| abhijat wrote:
| Apart from it's fantastic refactoring and everything else i
| really like the progressive selection.
| animal_spirits wrote:
| Pycharm is fantastic for code navigation. Jumping into a new
| codebase can be intimidating but I use Pycharm for the preview
| windows for function definitions, the option+f7 find all usages
| of a variable, and a few other features. IdeaVim is also the
| best vim emulator that I've tried in any IDE. But I'm also too
| deep into neovim to stop using every feature + plugin while
| writing and editing code, so I usually have Neovim running in
| the Pycharm terminal and jump back and forth between the
| Pycharm editor and terminal based on my context (writing or
| reading)
| mcdoker18 wrote:
| The most significant value of Jetbrain IDEs is that all
| programming languages have good support. I switched between
| Java, Python, JS, Typescript, C, Golang, and so on regularly.
| For example, Java and Kotlin support are miles better than all
| other IDEs.
| skjfdoslifjeifj wrote:
| I still use IDEA Ultimate for Java but over the last few years
| I've fallen back to vim or vscode for basically everything else
| since the language servers for Python, Typescript, Go and Rust
| now provide most of the features that I actually use in
| Intellij.
|
| Intellij's performance has never been good but it has
| continuously gotten worse over the years and it's bad enough
| now where I'll probably just cancel my subscription when it
| comes up for renewal.
| sitzkrieg wrote:
| i just wanna know how anyone still uses emacs insanely bad
| movement bindings
| b5n wrote:
| I find them incredibly ergonomic, another bonus is that it
| provides the same defaults found in most terminal emulators.
| Most people try to use pinky for Ctrl, or map to Capslock, but
| using the side of your palm for Ctrl is really comfortable. I
| generally run circles around colleagues in a terminal or
| working with text, especially when utilizing macros, but the
| learning curve is definitely steeper and took some time to get
| used to.
| donio wrote:
| Keyboards that put Ctrl and other important keys under your
| thumb are also great.
| b5n wrote:
| Makes sense. I just use qwerty, side of palm for Ctrl and
| thumb for Alt. I understand if that's not intuitive to new
| users, but it becomes comfortable and efficient pretty
| quickly.
| spudlyo wrote:
| Universally.
|
| Outside of Emacs, I have those "insanely bad" bindings in GUI
| text widgets, my shell prompt, when choosing/searching in in
| fzf, navigating scrollback in tmux, and inside REPLs of all
| flavors. Basically anywhere text is entered, I edit with those
| bindings. My Kinesis keyboard has 12 thumb buttons, and for me
| Control, Meta, Super and Hyper are all easily within reach.
| Ozzie_osman wrote:
| This was really well-written.
|
| One thing I'd recommend is to think more about "principles" than
| "values". The difference, in my mind, is that values are sort of
| ingrained into us as humans, and we can't change them. They
| include good beliefs but also a lot of personal baggage.
|
| Principles, on the other hand, are things we _choose_ to act on.
| Ideally they are the same as our values, but when
| building/designing something, it's best to choose principles.
| tomerbd wrote:
| For some reason the real-estate on vscode like file browser etc
| is really small compared to any other tool, on vs code I always
| have to move scrolls to see anything, I think this is the main
| thing why I don't use it while I really want to.
| jimmyvalmer wrote:
| tldr Neovim is a more actively developed vim. Vscode is a more
| than good enough editor for all seasons. Emacs is both stymied
| and celebrated for its adherence to "software freedom."
|
| Editorial: No one cares about "software freedom." If it takes
| [more than 2000 words](https://www.gnu.org/philosophy/free-
| sw.en.html) to describe what "free" means (another bad case of
| tldr), then forget it.
| 1MachineElf wrote:
| "Maintainability - The degree to which it can be modified without
| introducing faults"
|
| I can see why VS Code might get the Maintainability checkmark in
| the sense that it's hard to break from a user POV, but I wouldn't
| consider it "maintainable" in certain aspects as long as it isn't
| FOSS. Your IDE/editor is subject to the whims of Microsoft's
| release engineering team. If you do want to build from the open-
| source version and have the same experience, then you're going to
| have a bad time:
| https://www.reddit.com/r/linux/comments/k0s8qw/vs_code_devel...
| pmoriarty wrote:
| Emacs _" doesn't, however, affect progressiveness as much as
| freedom. Because of freedom, when faced with a question of using
| technology that is 1. Non-free, but objectively better, 2. Free,
| but objectively worse, the latter will always be picked. Given
| that most technological progress happens through the mechanisms
| of capitalism, "free" alternatives commonly lag behind to a large
| degree."_
|
| Emacs has a degree of integration and customization ability that
| VSCode just can't touch, so all this talk about VSCode being
| "objectively better" is pretty myopically focused on just a
| handful of things geared towards ordinary developers "who mostly
| just want to get stuff done".
|
| Those aren't the only people in existence, and if Emacs doesn't
| cater to those it's not because of its philosophy of Freedom, but
| because it doesn't have enough developers who care to steer it in
| that direction.
|
| Emacs is an editor-creation toolkit which is about customization,
| flexibility, and power. Making it easy to use for people who
| don't want to invest much time crafting their own editor with
| this toolkit is just not a big priority.
|
| That said, there are some packages like Prelude, which aim at
| giving Emacs sane defaults and making it easier to use for
| beginners (though I've never used any of them, so can't vouch for
| how well they achieve this aim, and I doubt that any of them
| would give you a full VSCode-like experience out of the box).
|
| To me the biggest weakness of Emacs, but also a strength, is that
| like a typical large open source meta-project (like Linux, the OS
| including all the software developed for it, not just the kernel)
| it's a multi-directional effort of hundreds of volunteer
| developers each running in their own direction.
|
| There are no orders from the top steering in one direction, no
| army of paid developers to make thorny, decades-old bugs finally
| disappear. Volunteers will get to those if they're interested,
| and go the way their own interests take them.
|
| It just so happens that the stars aligned so that we have the
| Emacs of today, given the volunteers of yesterday. If they were
| different volunteers with different priorities, Emacs would be
| different, and different volunteers tomorrow may steer Emacs in
| yet another direction. There is no plan. It's an anthill without
| a queen, with each ant building what it personally wants.
|
| This is why, like mature languages with large ecosystems, like
| Python, like other flexible editors (ie. vim, with its many
| plugins), and like Firefox (with all of its extensions) you have
| packages that " _interfere with one another, depend on
| functionality from other packages that get deprecated, changed in
| incompatible ways, or removed. "_
|
| You really can't have a large package ecosystem developed
| primarily by volunteers and not have this problem. People work on
| what they want to work on, and if they don't want to spend the
| time maintaining their package or making sure it's compatible
| with whatever package combination any particular user happens to
| be using, then there are going to be incompatibilities.
|
| But I'll take that incompatibility in a heartbeat for the
| enormous flexibility and power it offers, especially if the
| alternative is a meager, inflexible package ecosystem where how I
| edit is dictated from on high by people who cater to the average
| developer who "just wants to get things done".
|
| If you want Emacs to be something else you either have to be
| really good at herding cats, do it yourself, or pay someone to do
| it for you. Even then, you'll have to somehow convince all of its
| users to switch to your "improved" version. Good luck.
| elagost wrote:
| This is really well written and researched but confuses me. Do
| most people not do this - make choices based on values (and
| constantly re-evaluate those choices in the face of new
| information)?
|
| When I decide to use software, move to a new location, purchase
| cereal at the grocery store, buy music, and a variety of other
| daily activities, these are choices I make based on my values.
| Many times I end up picking something that I find slightly less
| convenient or usable because it aligns with my values better, and
| I'm unwilling to compromise my ethical stance for a little bit of
| convenience.
|
| It seems unrealistic to me that people would choose otherwise,
| given enough information.
| indy wrote:
| Most people are creatures of habit. Once they make a decision
| ("this is my brand of toothpaste") they tend to stick to that
| in spite of any new information.
| uncledave wrote:
| There's one exception to that which is that it's sometime
| more fortuitous to throw energy into developing something you
| already know further rather than throwing all existing
| knowledge away and starting again on a whim.
| tjalfi wrote:
| This reminds me of a quote from Surely You're Joking, Mr.
| Feynmann!.
|
| "When you're young, you have all these things to worry about
| - should you go there, what about your mother. And you worry,
| and try to decide, but then something else comes up. It's
| much easier to just plain decide. Never mind - nothing is
| going to change your mind. I did that once when I was a
| student at MIT. I got sick and tired of having to decide what
| kind of dessert I was going to have at the restaurant, so I
| decided it would always be chocolate ice cream, and never
| worried about it again - I had the solution to that problem."
| Ozzie_osman wrote:
| So I view a difference here between choosing a tool and
| designing a tool.
|
| As a user/consumer, sure, you mostly decide pragmatically.
| Though values do come into play. For instance, if you value
| extensibility over approachability, you might be ok choosing a
| more complex tool even if it is more difficult to use at first.
|
| But if you're building or designing a tool and you're making
| trade-offs, your values end up defining what you design and
| build.
| eeZah7Ux wrote:
| Amazing how ethics (especially around software freedom) are
| shunned on "hacker" news.
|
| https://en.wikipedia.org/wiki/Hacker_ethic
|
| [edit: let's the downvote fest begin...]
| bhaak wrote:
| Contrary to the other replies to you I think that most people
| do "make choices based on values" but the crucial problem is
| "given enough information".
|
| Remember that everyone of us is in an information bubble. We
| constantly filter out unimportant information based on our
| experiences.
|
| If you are using Emacs and encounter a new problem you will
| first try to solve it with the tools you are used to (if you
| have a hammer, everything looks like a nail).
|
| Finding new sources of information to change our filters is
| hard. Think back to the last time you came to a completely new
| technology and how lost you feel until you get a good grasp
| about it and how much of an uphill battle this can be.
|
| The sunk cost fallacy runs deep there as well. Going back to
| something you know already well enough is often a tempting
| option.
| irrational wrote:
| I don't have any values that would affect the cereal I buy. I'm
| not even sure what values would come into play. I don't buy
| cereal that isn't magically delicious? I just buy whatever is
| cheapest. Is not having much money a value?
|
| Other than Richard Stallman, I don't think I've ever heard
| anyone talk about how their personal values determine what
| software they will use. If I can afford it (free is better!)
| and it does the job, I use it.
| einpoklum wrote:
| > I don't have any values that would affect the cereal I buy.
|
| * Would you buy cereal made by slaves?
|
| * Would you not prefer cereal made by a small cooperative of
| people you know, over something made by BigCorp inc. ?
|
| etc.
| oblio wrote:
| I can't say I choose based on values, but I can give you an
| example of what people may mean by choosing based on values.
|
| Apparently a Nestle representative recently declared that if
| a law that requires large corporations to disclose and to
| stop getting raw materials from suppliers which use forced
| labor (i.e. slavery) passes, coffee customers might be
| impacted, probably by higher coffee prices. It's at best a
| clumsy statement and at worst an endorsement of slavery (!),
| all for reducing coffee costs by probably a few percent.
|
| A moral choice, based on values, would be to never buy coffee
| from Nestle brands and instead buy from companies that
| guarantee that their suppliers don't use forced labor.
| ohthehugemanate wrote:
| Yes, lowest cost is a value. But there are probably 5 or 6
| cereals at the lowest price point at your local grocery
| store. Which one do you pick, and why? Whatever the answer
| is, reveals your values. (Even "the one at eye level" reveals
| the value of minimum energy expenditure)
|
| > If I can afford it (free is better!) and it does the job, I
| use it.
|
| OK so one value is clear. But there are literally tens of
| software options that fit into those requirements. So why do
| you pick gdocs over libreoffice, or your workplace MS365
| subscription?
|
| Every choice you make is determined by your values, whether
| you're conscious of it or not. Very often, people think they
| hold one set of values (eg "i'm a vegetarian because I value
| animal life") but that is belied by their actions (eg wearing
| leather soled shoes). You can guess which one is a better
| indicator of their real values.
| eigenket wrote:
| Personally I do buy cereal partially based on values. I
| absolutely refuse to buy stuff from nestle.
| oblio wrote:
| No, they don't. You're an exception. Most people choose based
| on practicality or price. Free = even better.
|
| I find that one of the few places where people act based on
| their values is raising children. And even there, a lot of
| people skip raising their children completely.
|
| For everything else: convenience, price, maybe risk.
| erostrate wrote:
| And tech people tend to be much more willing to spend
| time&effort "optimizing" their choices to fit their values
| than the average population. At least for "small to medium"
| choices - not sure about raising children.
| simias wrote:
| Are we? I'm severely skeptical of this. Tech people tend to
| be financially secure so we can afford to pay more for
| stuff we care about, but I doubt we're significantly more
| opinionated and value-driven that the average population on
| average.
| yen223 wrote:
| https://xkcd.com/610/
| erostrate wrote:
| I don't follow? I wasn't implying that this is a good
| thing, or that it makes tech people special, and
| certainly not that it makes them superior.
|
| Edit: here's an xkcd more relevant to what I meant:
| https://xkcd.com/309/
| jrochkind1 wrote:
| I'm not sure and I see your point, but also, you are maybe
| saying that, effectively, "convenience" or "usability" are
| values you (and most people) prioritize.
|
| Which is not so different from when the OP article talks about
| emacs prioritizing "stability" really. "stability" isn't, like
| an _ethical_ value or something really, it 's a practical one,
| as are many of the others listed in OP.
| tome wrote:
| I don't think "convenience" is a _value_ for the buyer of a
| consumer good any more than "going downhill" is a value for
| the designer of a roller coaster. It's just easier.
| yrimaxi wrote:
| Yes. For example I don't buy cereal because of my ethical
| stance of not wanting to feel bloated from a bowl of milk-and-
| starch.
| tpush wrote:
| Most people's moral values don't concern text editors, or
| software in general.
| rusk wrote:
| Software developers aren't most people
| brutal_chaos_ wrote:
| True. Though a lot of tech people value libre software to
| some extent, so morals can often come into play. Even for
| something as simple as a text editor.
| mbrumlow wrote:
| How was "Editing efficiency" measured. I use emacs and seem to be
| able to make changes in fewer keystrokes and time than any other
| editor.
| pedrocr wrote:
| Are powerful editors really that much of a force multiplier? My
| career path has pulled me from a CS degree into loosely related
| fields so I mostly only code as a hobby. I end up using basic
| editors (e.g., gedit) and reaching for grep/sed/etc when I need
| something fancy. Is having that power in the editor versus the
| command line that much of an advantage?
| atarian wrote:
| John Carmack admitted a while back that he's not much of a
| power user when it comes to text editors.
|
| https://twitter.com/ID_AA_Carmack/status/1302651878065475584
| johannes1234321 wrote:
| As always: It depends.
|
| Better be proficient in command line tools and a simple editor
| than not being proficient in an fancy editor.
|
| But once you are used to the fancy editor it can be very
| efficient to be able to lookup a definition, do some
| refactorings, get an code outline view, auto completion,
| editing helps (text templates or the automatic } and indention)
| etc.
| aprdm wrote:
| I believe so, looking for definitions of functions you're using
| and being able to jump to their implementation is great,
| starting a debugger, getting errors as you type... it all saves
| time.
|
| Being able from the same interface to visualize your database
| and state of the program is also good !
| antonvs wrote:
| You can't achieve what a modern IDE can do using a simple
| editor and the command line.
|
| Autocomplete, hinting, type checking, navigation, documentation
| display, automated refactoring, interactive debugging, and
| integration with other tools like test runners and databases,
| are some of the major features which yes, are indeed force
| multipliers.
|
| This all becomes even more important when working on large
| codebases, and/or code you didn't write all yourself.
| intarga wrote:
| You can do all of those things in all four of the editors
| discussed.
| antonvs wrote:
| The comment I replied to was asking about comparing those
| kinds of editor to "basic editors (e.g., gedit) and
| reaching for grep/sed/etc when I need something fancy." You
| certainly can't reasonably do most of those things with
| that toolset.
| Datenstrom wrote:
| My vim configuration, environment, and screen splitting using
| tmux giving me CLI tools in other windows together gives me
| every single feature you listed and more. My shell and
| environment being Turing complete not counting vimscript I
| imagine it would be hard to find anything a IDE could do that
| I can not.
|
| For reference: https://gitlab.com/datenstrom/home
|
| Edit: just saw your response to the sibling reply didn't
| realize you included (enhanced) Vim in IDEs as I haven't
| heard of it referred to as one before, quite the opposite
| usually.
| antonvs wrote:
| It's not so much that I include Vim as an IDE, as that it's
| not a "basic editor" like gedit.
|
| Although I will say that I've been using Vim a lot less
| since I started using VScode.
|
| That looks like an awesome Vim environment though!
| acdha wrote:
| Yes. Switching context is expensive for humans and modern
| editors mean you do it less frequently and with fewer
| conventions to learn. A big one for general editors is that
| they work for everything: you can build, lint, debug, refactor,
| etc. using the same UI for every language which reduces the
| frictional cost significantly in fields like web development.
| Having code-aware auto completion, function signatures, and
| type validation is especially good here since you waste a
| fraction of the time realizing that you were omitting an
| argument by mistake or passing the wrong type - especially when
| that isn't something which a quick compile check will tell you.
|
| Refactoring is a good example: I've noticed that most
| programmers who don't use advanced editors avoid fixing things
| which require analysis because it's tedious to do right. That
| leads to accumulated technical debt over time with variables or
| methods having now-inaccurate names, etc. Nothing critical but
| a frictional cost which goes down when you have easy tools to
| perform language-aware refactoring (e.g. replacing a name in a
| function but not the same name used elsewhere in the same
| file).
| [deleted]
| asdfiuiu77 wrote:
| VSCode sends your private data to Microsoft servers. Emacs and
| Vim don't.
| blackrock wrote:
| Oh snap! Don't leave us hanging! Do explain in details what
| VSCode is sending to Microsoft.
| papaf wrote:
| Shouldn't that be Microsoft's responsibility?
|
| Last time I looked the answer was to "read the code".
| alexisread wrote:
| For me, the value of emacs lies in the fact that it works from
| the cli ie. Ssh, and that I can use it productively from termux
| on my phone- with a Bluetooth keyboard I can do split-screen
| working with ease. Vscode would be considerably harder to setup.
| [deleted]
| AzzieElbab wrote:
| I run neovim within vscode with neovim plugin. Relatively easy
| and fast to get started, takes time to reconfigure lsp and clean
| up shortcuts conflicts, but that is about it
| nednar wrote:
| Is there a way to standardize your fixes for others, e.g.
| through a pull request to teh neovim plugin?
___________________________________________________________________
(page generated 2021-01-17 23:01 UTC)