I talked to someone about the extensibility of emacs, but the person I was speaking to assumed that any IDE is just as extensible by using Plug Ins.

Without turning the conversation into a university style lecture, what is one or two simple actions I can do in emacs to show someone what separates it from other IDES.

  • ClerkOfCopmanhurst@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    11 months ago

    It’s the always-on REPL that’s the kicker.

    (defun invert-case ()
      (backward-delete-char-untabify 1)
      (insert (funcall (if (< last-command-event ?a)
    		       #'downcase
    		     #'upcase)
    		   last-command-event)))
    
    (add-hook 'post-self-insert-hook #'invert-case)
    

    Then C-u C-M-x on invert-case to convey the larger point that emacs is always running within a gdb-like harness. Your buddy will immediately bristle at the prohibitive investment necessary to achieve this pointless and trivial hack, at which point he’ll have truly grokked emacs.

  • worthyl2000@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    11 months ago

    Not the best person to answer - glanced the replies, and seeing people who seem very articulate so definitely read their points of view.

    My personal thought is being a “literate programmer” - I should be able to understand what my tools are doing and how it affects things. If I spend to much time with plugins - I sort of miss exactly what they do. With emacs - I have the code and I have a community.

  • no_good_names_avail@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    11 months ago

    First I wouldn’t concern myself too much with trying to explain what differentiates Emacs from an IDE. Life is too short to get into such debates. I can’t really summarize why anyone should care about Emacs vs their IDE of choice.

    For me what separates Emacs from vscode for instance is not the IDE aspects but the integration with the broader ecosystem. I’m a PM that works with technical and data heavy products. The details matter. I frequently walk through the pipelines and code of my product to understand how it is implemented by the team(s).

    For example you can break my underlying product down into 3-4 large blocks of pipelines. Each pieline has 6-7 stages that mix Spark and other Python jobs. For each pipeline and stage I have my own little literate org file that points to code, has small samples of inputs and outputs, and generally speaking allows a non data engineering professional such as myself keep up with people that are far better and keeping this all in their head.

    I write down questions as I do this to browse and/or raise with the team. I can, when questioned by our senior leadership, truly explain what it is our team did and the impact it had.

    I can’t do that with an IDE. I can’t see an easy way to do that with any of the other note taking tools. I can’t jump between code browsing, executing and writing as seamlessly anywhere else.

    • ClerkOfCopmanhurst@alien.topB
      link
      fedilink
      English
      arrow-up
      1
      ·
      11 months ago

      For each pipeline and stage I have my own little literate org file

      Damn, your verbose description checks all the boxes for a bullshit job.

      • no_good_names_avail@alien.topB
        link
        fedilink
        English
        arrow-up
        2
        ·
        11 months ago

        Haha, why is that? To be clear that’s not an expectation of the job. It’s a self imposed process so that I understand wtf is going on. I enjoy it personally and feel it makes me better at what I do. Why do you think it’s bullshit?

        • C0ntentFree@alien.topB
          link
          fedilink
          English
          arrow-up
          1
          ·
          11 months ago

          PM as in “project” or “product” manager? I’ve never experienced the former that wasn’t an oxygen thief, but I’ve heard unicorns exist. My current product manager is quite good imo: shields engineers from idea ferries from all levels; talks to support and customers; has good track record of picking projects that successfully increases product adoption; etc. I wish our product manager took the time to understand our codebases as the op here does. I think with that knowledge it would be easier to convince the PM of the importance of certain refactors and why certain requests estimates are more difficult and or tedious that the PM expects.

          • no_good_names_avail@alien.topB
            link
            fedilink
            English
            arrow-up
            1
            ·
            11 months ago

            Product. To be fair to project managers it’s even more nebulous than our role. I have only worked with one project manager who was invaluable for my day to day. Sadly didn’t get to work with her for long but would jump to do so again.

    • rebcabin-r@alien.topB
      link
      fedilink
      English
      arrow-up
      1
      ·
      11 months ago

      I’d rate this as a story about the benefits of literate programming, and emacs org-babel is certainly best-of-breed for that. A more mainstream workflow for it might be through Jupyter notebooks, but they have several deficiencies compared to org-babel, chief of which is that one can’t present blocks out-of-order in Jupyter, but can do with org-babel-tangle. as far as I know, no literate-programming solution can pull code off disk and put it in a document (the anti-tangle direction), let alone update a doc when code is modified. It’s doable (start with git-actions, maybe?) but difficult. The lack of anti-tangle stopped my team from adopting literate programming as a collaboration tool, but it’s still great in the downward direction, i.e., from doc to code.

      • no_good_names_avail@alien.topB
        link
        fedilink
        English
        arrow-up
        1
        ·
        11 months ago

        I’d agree but it goes a bit beyond. Each file has pointers to the source code that is locally checked out. Sure it’s not dynamic (e.g. my comments and understanding of what’s going on don’t sync with the codebase as it changes), but it still allows me to keep a mental map of what’s going on and where each piece of the pipeline resides.

        It’s a mixture of roam, literate programming and an IDE for me. E.g. I can easily spin up a vterm, ssh into a spark node and test some of the code if I don’t understand what it’s doing thoroughly or to check if something isn’t doing what is intended.

        In my use case, collaboration is not required. I’m doing it for me so there’s no real cost to the documentation and understanding getting out of date. I find emacs an invaluable tool to deepen my understanding and test things in the codebase. An IDE just doesn’t fit the bill in that regard.

      • chandaliergalaxy@alien.topB
        link
        fedilink
        English
        arrow-up
        1
        ·
        11 months ago

        I’m hoping Quarto will Jupiter - it’s still not as flexible as org-babel but better version-controlled than Jupiter.

        Pluto.jl apparently is reactive and immediately updates.

    • banister@alien.topB
      link
      fedilink
      English
      arrow-up
      1
      ·
      11 months ago

      True. I kind of fake it in notion by linking to the file and line on github, but it isn’t as good

  • PittaMan_@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    11 months ago

    I don’t. I dont care what other people use. Folks noticing I have language server support in a terminal editor is funny though.

  • sleekelite@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    11 months ago

    I mean, as a practical matter they are correct - most things people care about IDEs doing are just built in in other IDEs or doable via plugins. emacs is extremely niche and most people are correct to use something else.

    It is an important skill to not care what other people use and not care what they think about what you use.

  • Horrih@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    11 months ago

    For me, it is not the ability to write plugins : most editors have those to some extent.

    For me it’s more about the ease of writing your own customizations and not be limited to those provided by your plugins.

    A few examples

    • don’t like some built in or plugin behavior ? Copy paste the original source code, tweak it to your likint and use add-advice to use your new version
    • just yesterday i had some tests which generated a log in a temporary folder, 5 folders deep. I wrote a new command and bound it to a shortcut that looked for the new log file and opened it after running my tests
    • i wrote a simple log browser : use a few commands to preformat the file with query/replace, and boom with emacs’ outline mode i can fold sections /subsections. This command is 10 lines long.

    The strength of emacs is not its plugins, it’s your ease of making it your own

    • darcamo@alien.topB
      link
      fedilink
      English
      arrow-up
      1
      ·
      11 months ago

      A great example of this is this video https://youtu.be/w3krYEeqnyk?si=JKvVsgMO89DbCkhF

      Besides being easy to extend, there are also small general features that are very useful and I haven’t found anywhere else, such as narrowing. And these small features can be combined and composed. For example, suppose you just learned you can use dired to rename a file, now whatever you have already learned to edit text can be used to mass rename files, which could be using macros, using multiple cursors, using a regex query and replace, etc.

    • codemuncher@alien.topB
      link
      fedilink
      English
      arrow-up
      1
      ·
      11 months ago

      VSCode plug-ins is definitely playing in a rich man’s garden: https://code.visualstudio.com/api/extension-capabilities/overview

      You’re allowed to do what they say you can do. There’s a list and it’s not infinite.

      Part of the reason is VScode is very complex. Whereas the core of emacs is a lot simpler. It’s significantly easier to hook into the core of emacs and also safer too.

      The emacs source code has about 250,00 lines of C. And about 1 million lines of elisp (including all bundled packages). You can change all of that elisp at run time.

  • emaxor@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    11 months ago

    The lisp environment of Emacs makes it unique. Also it’s support for dynamic modules gives you a TON of extra power for certain cases where lisp is not appropriate; integrating 3rd party software like web browsers in a performant way.

    If your goal is to simply use the editor then the lisp environment doesn’t give you an advantage. But if you want to treat the editor as a tool you mold like clay to your tiniest yak shaving need then it gives you a LOT.

    For comparison, let’s look at Netbeans. A stereotypical traditional IDE. . If you try to write a plugin Netbeans you are first met with boilerplate. Menus, a bunch of strange plugin related code generated. You have to learn the plugin boilerplate system to get started. Now you wrote a little code and are ready to test/observe it’s behavior! how do you do that? you build/run and spawn YET-ANOTHER-NETBEANS which may take a few minutes. The write/observe feedback loop is painfully slow. (FYI I love and use Netbeans. I’m dunking on it but it has some advantages even over modern IDEs like Jetbrains).

    Now let’s look at Emacs. We start by writing a function. Then immediately observing/testing their behavior. There is no boiler plate. We are not cordoned off to a special “plugins” area. We just straight to the good stuff, the functionality. Instead of waiting 5 minutes to build/observe what we wrote, it happens IMMEDIATELY as we write it using lisp’s EVAL-loop. It affects our running Emacs instance, no need to spawn another.

    I lied a little bit. Emacs packages DO have boiler plate that you should conform to before publishing. But it’s not required, and not where you start. For your personal stuff, it may simply be a collection of functions. Then bind appropriate functions to keys.

    An anecdote. Just yesterday I was writing some Go (lang) code and running the linter. Most of the time I like to run the linter at the project root folder. But at that moment I only care about the package I’m working on in the current folder or maybe 1 level up. I whipped up a little helper function where I can select 1 of 3 options: current folder, project-root folder, Custom folder. The project root folder is detected by heuristics using Emacs project library. If I choose Custom, then i input a folder via completing read. This little fn scratches MY itch. A tiny little inconvenience solved in 5 minutes. If i tried to solve that in Netbeans… it would take 5 minutes just to build it and spawn another Netbeans instance.

  • Psionikus@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    11 months ago

    Emacs is a programmable interface to a computer. While it is frequently used to program itself to program other things, it is a foundational bootstrap tool.

    IDE’s seek to present a set of features that fills that domain of work. You hit a ceiling in that world. With Emacs, you continue molding it to things you get value out of years and decades later, after that IDE went away when its most popular language or framework went into decline.

    In the upcoming landscape of AI’s with more well-defined type interfaces and symbolic representations, tools like Emacs will be at the forefront of composing these tools into the long tail of cottage industries of what will amount to a revolution in IP, programming, and human-computer interfaces.

      • Psionikus@alien.topB
        link
        fedilink
        English
        arrow-up
        1
        ·
        11 months ago

        Have them show their IDE’s scripting environment and how they can quickly prototype an automation for something annoying without even going the distance to write a full plugin and then bind that automation to a key.

        Then open org or something and show how you can write a version of Lispy for org outlines based on some predicates like org-at-heading-p.

  • SegFaultHell@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    11 months ago

    You might get pretty far just by explaining that all emacs “plugins” use the same language as the editor, and then explaining the C-h family of keybinds that let you see documentation for every variable and function.

    Then open one of those help pages for a package to show it and highlight the part where it tells you what file the function comes from, even for 3rd party packages. Then highlight how you can extend emacs in the same way, just writing some elisp on a file instead of needing to create an entire plugin.

    A lot of emacs really needs to be discovered, but I’d imagine most developers could appreciate good documentation, the ability to see exactly what code is doing, and the option to override or extend that functionality very easily.

  • 00-11@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    11 months ago

    any IDE is just as extensible by using Plug Ins

    Lisp. Up, down, around, inside, across, between, under, at, through, into.

  • a-concerned-mother@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    11 months ago

    Probably the most simple examples for me are

    1. Showing the multitude of packages for something like an email client, Margit, etc and how you can mix them together with org linking, using babel, etc. showing the deep level of integration you get

    2. Simply show functionality in the editor and how you would like it to change. Rather that writing a whole package to do it. Use the help to go to the source and redefine that function in your config. Doesn’t require them to know elisp to understand but it gets the point across that everything is at your fingertips.

  • arthurno1@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    11 months ago

    It is not so much about other tools or languages not being extensible; most quality ones are extensible. It is about how easy is to extend it since the text editor, debugging tools, and some other useful stuff like shell integration (process control, I/O), networking for example, are built into the extension language.

    It is very easy to write a small tool that automates something, like a say project creation for Emacs compared to for example Eclipse, Netbeans, or VisualStudio. Since Emacs GUI is in essence a glorified console, it is relatively easy to integrate CLI, text-based tools with Emacs.

  • blikjeham@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    11 months ago

    One of the junior coders was using vscode but with vi keybindings. He heard one of the seniors talk about their love of vi and he thought he had to learn it as well. I told him that, learning vi is handy because it is often one of the only editors you find on a freshly installed GNU/Linux system, but in the end VSCode is very capable without learning silly shortcuts. I know that, if I had to pick an IDE now I would definitely choose VSCode. I have spent so much time configuring my EMacs that it would be a waste of time to start it again.