1. 56

  2. 5

    Every part of this sentence is wrong

    As I write this, it’s been discovered that newer versions of macOS include anti-malware functionality that transmits tracking information almost every time any program is run.

    It’s not anti-malware functionality, it’s verification

    It doesn’t transmit any information other than what it needs to verify, so not really tracking

    It’s only occasionally, again, for verification.

    1. 12

      Uh, no? Almost every part of that sentence is correct. See for yourself, straight from the horse’s mouth.

      Apple explicitly outlines its use for anti-malware purposes. More importantly, while Apple pinky promises that it doesn’t use this information for tracking, such information is more than sufficient for performing tracking, and considering it’s all sent unencrypted via a third-party CDN, Apple’s pinky promises are rendered completely moot anyway. Depending on your threat model, running macOS can be very dangerous.

    2. 3

      Is this not basically just an except from this article: https://www.murilopereira.com/how-to-open-a-file-in-emacs/?

      Shouldn’t the stories get merged?

      1. 9

        I didn’t read that story, as it talks about Emacs for many pages before it gets to this part that’s actually interesting (for me).

        I wanted to submit this story as well (was beaten by a few seconds) and tagged it as culture, as I don’t think it’s really about Emacs or Vim at all, but rather about communities and open source development. Emacs, Vim, and VSCode are just used as examples, but you could just as easily have written this about any two other pieces of software.

        Maybe they should be merged … but IMHO there’s value in just leaving it, as I suspect a lot of people didn’t read the original story as they thought it was going to be about Emacs (which, in large part, it was) and never got to the more interesting part.

        1. 2

          The original article only has an emacs tag, which I mentally filter. I would have not read it but for the vim tag, so I think this is distinct and valuable.

        2. 3

          I completely disagree with the conclusion regarding VSCode extensibility.

          Everything about it can be changed, using scripting languages that have a bigger community and are more familiar to most.

          Just look at the virtually unlimited amount of VSCode extensions! They’re so good that people has made vim plugins to use VSCode extensions!

          1. 10

            Everything about it can be changed,

            This is not true. Emacs plugin model is open – there are no plugins per-se, user code runs in the same environment as Emacs’ own code, and has access to all of the functionality. In contrast, VS Code plugin model is closed: there’s a finite API exposed specifically for the plugins, and this is a different, more restricted, API than the one used by editor’s core. Plugins are isolated even physically – they run in a separate process from the editor. So, for example, it is not possible to implement custom GUI to replace VS Code command pallet.

            That being said, “everything can be changed” is different from “everything I need can be changed”. For me personally, after having discovered edamagit, the only thing that Emacs has and VS Code lacks is wdired and golden-ratio mode.

            1. 2

              This is wrong. You can change anything in VSCode.

              Some extensions that I would consider as proving my point:

              EDIT: Reading your comment more carefully, I now get what you mean, and yes, technically you can’t change everything, but still: this is in no way limiting the creative power of extensions or their capabilities and I would still consider VSCode as incredibly extensible.

              1. 7

                First, sorry for starting with a “this is not true” – if this needed a re-read, I was too direct :) In this comment, I would like to disagree with one specific point, while agreeing with the overall conclusion.

                Specifically, I can’t agree with this one:

                this is in no way limiting the creative power of extensions or their capabilities

                Here are a couple of things I can not do, although I’d very much like to.

                One, there’s no way to show a convenient input box with code completion. I need this to implement “run cargo command” feature in rust-analyzer, which would complete cargo flags based on project info. This is Run Anything from IntelliJ. I can use InputBox, but that doesn’t have completion. I can do anything in a webview, but that won’t be a pop-up.

                It’s interesting that, before Run Anything API existed in IntelliJ, I implemented this feature in IntelliJ for Cargo manually. Like Emacs, IntelliJ is open-API, so that was possible.

                Two, there’s no way to add checkboxes/tabs to workspace symbol search input. I want a convenient way to look only for classes, or only for functions, or only in library code, like I can do in IntelliJ. I would build a custom pop UI for this if I could, but I can’t.

                So no, VS Code is not as extensible as open-API platforms, and this is limiting in practice.

                How does this square with the number of awesome extensions on the marketplace? I think Code doesn’t optimize for extensions power, it optimizes for a vibrant extension ecosystem. This is velocity and maintainability from @mpereira values, and not extensibility.

                VS Code has extensions marketplace, which provide automatic updates, versioning & rollbacks, discoverability and a nudge for writing your own extension. The traditional model in Emacs is that you just dump stuff into your personal .emacs.d and maybe paste some snippets from it to Emacs wiki. These two approaches create different incentives, and the resulting ecosystems are systematically different. I wonder why VS Code doesn’t have init.ts for local scripting? Is it just “only power users need this” low priority item, or is this omission a deliberate design decision to encourage publication of plugins?

                What’s more, limiting extension power by providing a closed API (as opposed to an open API) also serves to systematically improve the ecosystem. This is a feature, it is not a limitation. vscode.d.ts contains the entirety of extension’s API surface, and to me this single file reads like a gem of a great application and systems architecture.

                By not exposing the internal API directly and introducing an explicit interface layer, VS Code achieves the following things.

                First, extensions can’t block UI thread or slow down startup. They are in a separate process! This is a crucial property for extensions ecosystem, as there would be poorly written or buggy extensions which would compromise the overall experience. The parent blog post started with a story of 30 seconds freeze of Emacs. This is impossible by design in VS Code.

                Second, it is easy to provide backwards compatibility. You can freely evolve internal editor impl, concentrating all the backwards compatibility cruft in a single place, the translatation of internal mess to the extensions API.

                Third, it becomes trivially easy for extension authors to learn the API, as the entirety of an API is a single file.

                All three are crucial for a rich ecosystem, and all three require a closed API. I think this architecture is the reason why VS Code was able to replicate and mostly surpass the 40 years of Emacs in such a short term. I bet there are many more VS Code TypeScript code than Emacs elisp code by now.

                1. 2

                  Thanks for your lengthy reply, and I apologize if I too sounded too direct in mine (I was hoping the edit made it better, but I didn’t want to “remove proof” of my original reply), sometimes on the internet it’s too easy to sound harsher then intended.

                  With that aside, you make a very good point, and yeah, this inevitably this means VSCode is not unlimitably extensible, however: do we need such a thing?

                  I’ve seen the VSCode team as very responsive, and given that you have such specific limitations, I wonder if you ever thought about opening an issue (or a PR directly) proposing the required API extensions to make those use-cases work, I’m sure many more extensions would benefit from it.

                  1. 2

                    Yeah, I do raise issues against vscode and (moreso) lsp protocol. Here’s completion and filtering. Implementation wise, I am afraid all my editor support capacity is sucked by rust-analyzer :)

                    1. 1

                      Thanks for all your great work on rust-analyzer by the way! :)

                  2. 2

                    Thanks for your analysis of the collateral effects of the VSCode closed API, you raise interesting points that weren’t very concrete in my head.

                    I’m not sure about there being more TS than Emacs Lisp by now, but maybe I’m just uninformed! :)

                    1. 1

                      Yeah, I don’t know about the amounts, that is my guess. Sadly, this info is hard to collect.

                      By the number of extensions, melpa contains 4800 extensions (https://melpa.org/#/), vscode has 10000 in the other category alone (https://marketplace.visualstudio.com/search?target=VSCode&category=Other&sortBy=Installs) (EDIT: 23k total: https://marketplace.visualstudio.com/search?target=VSCode&category=All%20categories&sortBy=Installs). Of course, many of code extensions are left pads. I am also not sure what’s the total volume of corporate elisp code, a-la JaneStreet’s iron workflow.

                2. 1

                  Only thing really?

                  I suppose: Org-mode + ability to run in a terminal window (+ to run in batch mode?) + the fact that all is text (which we like, or not) + tight integration with a shell (eshell) + on-the-fly configuration and plugins development.

                  also important (to me at least): independent from a vendor.

                  1. 1

                    Well. I did list two things :) I … just don’t understand why people use org mode or any other todo list. For me, maintaining a list means that I am procrastinating. If I am in the flow, I just know what to work on next (i do use paper notebook sometimes). I don’t need integration with the terminal (I do need someone to write a non horrible terminal though ) or the shell.

                    All-is-text and general interactions are fine in vscode: there’s magit clone, it works ok! I do miss golden ratio and wdired.

                    On the fly configuration is a mixed bag: on the one hand, sure, I wish I can just drop a function in my init.ts from time to time, on the other hand, 80% of configurablity is handled by JSON config with auto completion and immediate reload. For those 80%, vscode is significantly better for me than emacs.

                    Now that I think about it, another thing I miss is daemon mode. Immediate startup is a big deal for me personally.

                3. 1

                  Hey Alberto. I’m curious to which “conclusion” regarding VSCode extensibility you disagree with?

                  The post says that extensibility is not one of VSCode’s core values (which is just my opinion anyway), but that is different than saying that VSCode isn’t extensible. It clearly is…

                  1. 2

                    I disagree with the fact that extensibility is not a core value of VSCode

                    • Microsoft themselves are contributing to the most popular community extensions
                    • The extensions API is extremely powerful, and in case what you want to do can’t be done, Microsoft has shown to be very responsive in accepting extensions to the API or contributions that extend the API
                    • VSCode is also built with the same technology and language as their extensions: TypeScript, HTML and CSS, which means that you can create a completely customised component for it

                    Sure, maybe there isn’t a native API that allows you to inject custom CSS to (for example) move the command prompt from the top of the screen to the centre, but somebody made an extension that allows you to inject custom CSS, meaning that when you can’t extend VSCode with it’s native API, you can always hack it (at the expense of maybe causing issues with future updates, but maybe that’s a tradeoff you want to do).

                    Maybe the concept of “extensibility” is not as pure as the Emacs one, but this is software, not a religion: I never once came across something I wanted to do that either wasn’t possible or, more likely, somebody didn’t already built an extension for it.

                    1. 5

                      All free software is extensible. People have taken Acme and modified it, but that doesn’t mean it is a core value. The difference between Emacs and other models, to me, is not one of religion but of who extends it. If I want to add a new feature, to fix an annoyance, I can probably do it myself. I just have to write a few lines of elisp in my *scratch* buffer, evaluate it and there it is. It is my impression that this is the intended way to work with Emacs. My impression of VSCode is that the intended way is to install an extension, or write one by yourself, which raises the barrier. Sure you can do it, it’s a web browser after all.