[HN Gopher] Emacs is special regarding UIs
___________________________________________________________________
Emacs is special regarding UIs
Author : signa11
Score : 416 points
Date : 2020-09-10 08:25 UTC (14 hours ago)
(HTM) web link (lists.gnu.org)
(TXT) w3m dump (lists.gnu.org)
| code-faster wrote:
| unix is also User Interface Independent, but unlike emacs, it's
| actually used on a wide variety of interfaces: Mainframes,
| microcontrollers, web servers, phones (touch screen) and PCs.
| neolog wrote:
| Pretty sure emacs is used on all of those
| pjmlp wrote:
| It is also the reason why the only desktop based UNIXes that
| achieved any commercial success have full stack frameworks that
| make their UNIX underpinnings irrelevant.
| Cthulhu_ wrote:
| Emacs and org-mode is frequently mentioned on HN as being
| awesome, but I don't feel like I could ever switch; I've got
| enough issues with vim already.
|
| For one, all the keyboard shortcuts and commands that you have to
| learn; I don't know if I have the capacity to learn all that
| anymore, not without deliberate practice, while in modern editors
| you can get by with keyboard + mouse and slowly learn some new
| shortcuts here and there.
|
| Second, it feels like you have to spend a lot of time to set it
| all up.
|
| Third, will it replace an IDE? Error checking / linting,
| autocomplete, fast navigation, auto-imports, loads of things like
| that that seem to just work out-of-the-box in e.g. idea.
| sreevisakh wrote:
| In the past, I have used Emacs and then switched to Neovim. I
| just switched back to Emacs again. I am enjoying both - without
| any friction. To get the best out of both Emacs and (Neo)Vim,
| you have to treat them as different types of software.
|
| > For one, all the keyboard shortcuts and commands that you
| have to learn
|
| That's a valid concern. But if there was one keybinding every
| programmer should learn, it's probably Vim's. And while emacs
| has a default keybinding, it is not tied to it. Vim keybindings
| using evil-mode uses the same elisp interface as the default
| binding. Evil-mode feels very native and at par with Vim user
| experience. (Kakoune's bindings are derived from Vim's and is
| said to be better. But it's immature now. Hope it catches on.)
|
| Emacs is a programming platform and not an editor as such. You
| should simply forget the key bindings (use what you are
| comfortable with- evil or even the Windows bindings) and focus
| on what the platform has to offer. Packages like Org-mode,
| Magit, restclient and a lot of others have no other
| alternatives. Emacs GUI also acts like a terminal emulator far
| more advanced than VT-100 emulators.
|
| (Neo)vim is useful as an editor when you are setting up new
| systems or administering via SSH. Emacs is useful as a personal
| programming environment. With evil-mode, there will be no
| problem using either in the respective context.
|
| > Second, it feels like you have to spend a lot of time to set
| it all up.
|
| I support what everyone else recommends. Start with Doom Emacs
| or Spacemacs if you are a beginner. It does take a lot of time
| to set it up from scratch. I just prefer to set up everything
| from scratch, since I use a dotfiles repo. Improvements in
| configuration are incremental when you have a dotfiles repo.
|
| > Third, will it replace an IDE?
|
| All those are available. Just needs configuration. Or else, use
| Doom Emacs or Spacemacs - they come pre-configured. That really
| isn't the reason Emacs uses love it. It's those features you
| can't get in an IDE. If you have a task for which you need to
| switch out of an IDE, elisp makes it easy to integrate into
| emacs. The package repositories are full of such packages.
| brabel wrote:
| > you can get by with keyboard + mouse and slowly learn some
| new shortcuts here and there.
|
| Agree, but I am extremely used to the trackpad and haven't used
| a mouse in years... because of its closeness to the keyboard
| (in pretty much any laptop) I can do things very quickly when I
| have no shortcut at hand... so much so that I only find it
| worthwhile to memorize a few shortcuts for the tools I use most
| (the terminal, IntelliJ IDEA, and a few for VS Code though I
| find their shortcuts terrible)... but it's unescapable that
| you'll need to use the mouse or trackpad sometimes, especially
| when not using your main tool (things like browsers, photo
| apps, even file managers unfortunately), so getting good at it
| I think is more useful than memorising a million shortcuts for
| a single tool.
| RMPR wrote:
| > and a few for VS Code though I find their shortcuts
| terrible
|
| You might have a better time using
| https://github.com/VSpaceCode/VSpaceCode
| pvg wrote:
| I think your intuition is about right: the IDE is going to
| squish all before it at the environments/runtimes it supports
| well, the vi(m) obsession with modal keyboard golf is a waste
| of time and org mode is a curious subcult of the the already
| weird (but, like, totally different from those vim heretics!)
| emacs cult.
|
| The other things are worth exploring for fun and curiosity but
| it's sensible to look at them as they are - beautiful rainbows
| rather than maps to buried pots of hyper-productivity.
| NateEag wrote:
| As a long-time evil-mode / emacs user, I would say your
| comment is pretty accurate.
|
| Two objections come to mind at the moment::
|
| * vim keybindings have helped my RSI significantly (and
| before you go there, I got RSI when I was an IDE user, before
| I focused on on Emacs)
|
| * Using Emacs and building my own config has not made me
| massively more efficient at the workflow level, but it has
| taught me a great deal about software design and development
| than I would have otherwise learned.
| aliceryhl wrote:
| Regarding RSI, I find vim keybinds critical for voice-based
| interaction with a computer. It really makes a large
| difference when it hears the wrong thing.
| pvg wrote:
| Oh I'm just snarking at 'modal text editing is some
| programming superpower'. I've had RSI scares and similarly
| odd change-of-habit relief.
|
| As to the second thing, it occurred to me recently that my
| .emacs is old enough to vote and probably still contains
| bits of other people's .emacsen that were old enough to
| vote when I first edited it.
| mapolone wrote:
| For the keyboard shortcuts, there's ergo-emacs [1] a minor-mode
| that already rebinds most of the common shortcuts (open,
| copy/paste and so on).
|
| Or, if you like vi(m), evil mode [2] should be good to go.
|
| [1] https://ergoemacs.github.io/
|
| [2] https://github.com/emacs-evil/evil
| gkya wrote:
| > For one, all the keyboard shortcuts and commands that you
| have to learn
|
| > Second, it feels like you have to spend a lot of time to set
| it all up.
|
| You learn a subset that's relevant to you. Also there is which-
| key which helps _a lot_.
|
| But, I mean how do you learn, say, Spanish? Do you just drop
| English and start speaking Spanish to everyone from day one?
| No, it's something that happens in a dedicated time. Once you
| feel comfortable enough, and when the chance presents itself,
| you being integrating it to your daily life.
|
| Similarly with Emacs, you could just start playing with it,
| maybe say editing your personal scripts with it at times, using
| Org mode for some notes. And then slowly integrate it to your
| life.
|
| No matter how much work is done in the UI compartment, a tool
| as comprehensive and customisable as Emacs will never be learnt
| in one day. There won't be any magic bullets. It's always like
| learning a language.
|
| The important consideration is if the returns are worth the
| investments here. Unlike other editors---which are great
| software in their own ways, anybody who says "hackers should
| use Emacs or Vim" or similar BS just don't know what they're
| saying---, Emacs provides some particular opportunities, which
| depending on your workflow might not be worth it.
|
| > Third, will it replace an IDE?
|
| Yes, you can get it to do all that. OOTB is hard, but AFAIU
| projects like Spacemacs and Doom are kinda making that happen.
| auslegung wrote:
| Others have given great recommendations for emacs options that
| lower the learning curve, but if you're interested in vim
| instead of emacs, onivim does the same with vim.
| https://onivim.github.io
| trenchgun wrote:
| There is also Spacevim https://spacevim.org/
| john4532452 wrote:
| Emacs, org-mode, pdf-tool, org-roam. You are set for next 2
| decades IMO for personal knowledge management.
| jwandborg wrote:
| I work daily in vim, emacs and idea (ideavim).
|
| I use emacs for org-mode exclusively. You only need to learn
| the buffer manipulation and org-mode keybinds for this, and the
| configuration.
|
| I use vim for ad-hoc text editing, it's a poor IDE as I've
| configured it.
|
| I use IntelliJ IDEA with IdeaVim for writing code.
|
| I do not consider myself superhuman. A notable fact is that at
| some point previously, I've used every one of these as my main
| development editor.
|
| I couldn't imagine having to maintain configuration for IDE-
| style features in all three editors, so I won't bother, but I
| do bother using the best tool for the job.
| massysett wrote:
| Org mode is the only reason I use Emacs. Nothing comes close to
| Org mode. Actually, I'd say that I use Org mode, and I use
| Emacs only incidentally because Org mode requires it.
|
| Because I used Org mode, for awhile I tried to switch my other
| text editing to Emacs. But without a good mode, it's not worth
| using Emacs. I do all my other text editing in Vim.
| gkya wrote:
| Something like Org mode is only possible in something like
| Emacs tho.
| kristopolous wrote:
| Pretend I have a crashing program and I want something better
| than the GDB repl and I don't want to import/create some
| project.
|
| There's a lot of solutions for this but pretend I want to
| graphically step through, edit the code etc...
|
| Emacs can do this quite well without any special hassle.
|
| Just try using it as a debugger, when you're annoyed, search
| the web and you'll find your answer.
|
| I'm not an emacs user so this is coming from a non koolaid
| drinker but I've been using it more and more for these special
| use cases
|
| Maybe this is just as easy to do in, say, IntelliJ, I just feel
| like emacs will leave a cleaner footprint and have more
| sensible defaults.
|
| So give emacs a try for debugging something (the Google-fu is
| GUD, grand unified debugger), it's not hard to use, the
| learning curve is pretty modest and you may be surprised by how
| sensible it is.
| phist_mcgee wrote:
| They appeal to two different kinds of people. The first set
| (you and I) value the convenience of a job completed with a
| highly tuned and tested tool developed by word leaders in
| programming technology (Jetbrains). The other set of people
| wish to be able to tune things exactly as they wish, and focus
| on hyperoptimization of a set of known tasks that they become
| expert in.
|
| Neither is wrong, but I do believe that when someone goes on
| about how if you just try hard enough to grok emacs, you will
| suddenly get it. Maybe. But I think there is an audience bias
| there, whereby only people who are inherently interested in
| tweaking and fiddling will achieve that benefit, and only
| people who wish to just get things done on a paid tool will be
| OK with using a mouse every so often. Horses for courses.
| ziml77 wrote:
| Personal 4th reason: My mind keeps going back to this when I
| think I want to try Emacs again
|
| > [Every dynamic module] should also export a symbol named
| plugin_is_GPL_compatible to indicate that its code is released
| under the GPL or compatible license; Emacs will signal an error
| if your program tries to load modules that don't export such a
| symbol.
|
| The viral nature of the GPL already bothers me. Emacs trying to
| enforce that I'm only running GPL compatible code is even
| worse.
| ormindo wrote:
| For keybinds / setup time, I'd recommend either Spacemacs or
| Doom emacs. Spacemacs especially is meant to be quite newcomer
| friendly, with things like windows telling you "you pressed
| this key, here are the other keys you can press to complete the
| keybind sequence, and here's what they will do".
|
| As for full fledged IDEs, no, I don't think Emacs can pretend
| to replace those, but you can still make the Emacs experience
| comfier. Linting is pretty good on Emacs with things like
| flycheck (& flyspell for spelling in say comments or commit
| changelogs).
|
| For kernel C development I have a simple flycheck module that
| compiles the edited file and inlines all warnings / errors as
| lints. I also have another one for checkpatch (extra script
| you're meant to run before sending your commits to the mailing
| list); as a result I never have to look at any other window
| than the one where there is code in it.
|
| For Python, pylint is supported out of the box by flycheck.
| Auto-completion is supposed to be feasible, but I had some
| issues with it and gave up - never felt like I _really_ needed
| for what I do in Python anyway.
|
| Fast navigation can be done with the usual cscope / gtags. More
| recently, I've been converted to using ripgrep for most
| searches (https://stegosaurusdormant.com/emacs-ripgrep/) as it
| is crazy fast. You can also directly edit the matches and
| commit the changes, which serves as a project-wide "search and
| replace".
| andreareina wrote:
| If you didn't already know there's a command you can run to
| `find` files and put them in a dired buffer, then from there
| you can run an interactive regexp search/replace on all
| marked files. On mobile so I don't have the command names and
| key bindings available, but it's some combination of dired
| and find.
| hpfr wrote:
| I feel like it's pretty safe to say
| https://github.com/hlissner/doom-emacs mostly solves of these
| concerns for Vim users in 2020. If you really can't spend any
| time learning a few help keys then I guess I can't recommend
| anything, but you're here commenting so I bet you have some
| time :).
|
| Seriously, check out Doom, whether you use neovim, Emacs, VS
| Code, or nano (Doom has quite good Emacs and CUA bindings as
| well). It's brilliant to the point where I'd describe it as
| Emacs with sane defaults. I guess it probably can't match the
| more niche IDE features but LSP and friends are bridging most
| of the gaps.
|
| You can finally safely ignore claims that beginners should roll
| their own emacs configs thanks to Doom. That strategy is good
| for learning if you're used to diving into unfamiliar systems
| but you can learn just as much by starting with Doom and
| working your way inward anyway. The community is great, just
| like the larger emacs community.
|
| I can't stress Doom enough; it gets better often not by the day
| but by the hour. Henrik is a machine.
| RMPR wrote:
| > I feel like it's pretty safe to say
| https://github.com/hlissner/doom-emacs mostly solves of these
| concerns for Vim users in 2020
|
| I use both doom emacs and neovim, and I'd say: not really, at
| least not for me, there are some Vim features evil doesn't
| emulate properly, or at least it doesn't work like in Vim.
| Off the top of my head, I write in many languages, but
| absolutely hate the US international keyboard for accented
| characters, guess what? Vim has built-in support for
| digraph[0] by using Ctrl-k and iirc this is a motion keyboard
| shortcut in emacs, and since I like and use org-mode a lot,
| I'm always frustrated when I have to type in another
| language. Another one was with the various Terminal emulators
| packages in emacs, although this one was solved recently[1],
| whereas in (neo)vim it works flawlessly ootb.
|
| 0: https://vim.fandom.com/wiki/Entering_special_characters
|
| 1: https://news.ycombinator.com/item?id=24243031
| WhatIsDukkha wrote:
| https://github.com/emacs-
| evil/evil/blob/3f3b2fea87172f155e5f...
|
| It's defined in Evil (which Doom uses directly).
|
| Seems like you just need to figure out your bug.
| RMPR wrote:
| Thanks for pointing this out, seems the "bug" is
| exclusively with org-mode, which is too bad because I
| don't usually need this feature outside of org-mode.
| WhatIsDukkha wrote:
| Works for me in my org-mode and evil but I'm not using
| Doom.
|
| Fwiw use-package is pretty magic and reliable these days.
| laex wrote:
| Is Doom better than Spacemacs ?
| hpfr wrote:
| I would say the Emacs user mindshare has shifted somewhat
| to Doom. There are a lot of Doom fans on r/emacs now, and
| the Discord is huge compared to what it was. Many new
| contributors are cropping up. Even some developers of well-
| known packages, like org-roam, have switched to Doom. Take
| it from him, not me!
| https://blog.jethro.dev/posts/migrating_to_doom_emacs/
|
| Compared to Spacemacs, which has complex abstraction layers
| over Emacs, Doom seems to be much lighter. It's easy to get
| into Emacs browsing Doom's modules. Plus, the BDFL model is
| serving Doom quite well since Henrik is a god-tier BDFL.
| He's constantly active and keeps Doom very focused on
| performance with sensible defaults and consistent
| programming style. Docs are a focus and are growing, and
| they're extremely comfortable to browse in Doom Emacs
| itself, as well as the Doom and Emacs source code of
| course.
|
| None of this is meant to attack Spacemacs, it did and does
| much for Emacs, and many swear by it. But I would say Doom
| is better these days.
| kalium-xyz wrote:
| You can just use the things you like from either, thats
| the best part of emacs.
| lvh wrote:
| Jethro moved from a custom init.el to Doom, though, not
| Spacemacs to Doom :)
| Amorymeltzer wrote:
| I've never been a vim user, but regarding keyboard shortcuts,
| there's Evil[1], which is fairly popular.
|
| 1: https://github.com/emacs-evil/evil
| antonvs wrote:
| There's also Spacemacs: "Emacs advanced kit focused on Evil.
| A community-driven Emacs distribution."
| https://www.spacemacs.org/
|
| It made emacs a bit more accessible for me.
| smitty1e wrote:
| For those with wretched joints (me), Spacemacs[1] is a way to
| have all that org-mode[2] functionality, the joys of magit[3] and
| have it all work well over SSH.
|
| Leave all the icons to their fans.
|
| [1] https://www.spacemacs.org/
|
| [2] https://orgmode.org/
|
| [3] https://magit.vc/
| mkesper wrote:
| After finding doom-emacs, I love that even more. Almost instant
| startup, non-broken magit key bindings, doom doctor etc.
|
| https://github.com/hlissner/doom-emacs
| DreamyCori wrote:
| It seems like doom-emacs is the new way to go. I feel quiet
| sad about this cause I spent some time to switch to Spacemacs
| and now I have to move to another emacs distro.
| dunefox wrote:
| Why do you have to move? Are you using the dev-branch
| Spacemacs or master?
| DreamyCori wrote:
| master cause I want something stable.
| dunefox wrote:
| I'm on dev and it's quite stable, imo. Then again I'm not
| a spacemacs poweruser so...
| DreamyCori wrote:
| Anyone is info about the release model of Spacemacs ? It seems
| like nothing is moving. Any news ?
| sseneca wrote:
| The release model is a mess. Most people tend to stick with
| using Spacemacs on the `develop` branch, which means updating
| via `git pull --rebase` every so often as well as the inbuilt
| `SPC f e U`.
|
| I've been using Spacemacs for around a year on the `develop`
| branch. For me it's fine, but for those who want a very
| stable experience I don't recommend it -- it does break
| sometimes.
| DreamyCori wrote:
| This unclear release strategy sends a bad signal to the
| community and pushes people to doom-emacs. Sad to see ...
| krageon wrote:
| Which also has most of the good stuff on the develop
| branch :)
| larsbrinkhoff wrote:
| Emacs is a manifestation of the ITS user interfaces. They all
| relied on text because that's all that was available back then.
| They also used control characters, Altmode/Escape/Meta, and
| prefix arguments.
| benreesman wrote:
| IMHO emacs is kind of a Rorschach test w.r.t. Lisp. Some people
| really like programming in Lisp, and for them getting emacs to do
| what they want is fun and rewarding, particularly but not
| exclusively regarding interface affordances. I personally fall
| into this category. The fact that it has very similar keybindings
| to readline/bash (especially important if you spend a lot of time
| popping on and off servers that don't have your dots and thus
| choose not to customize the shell too much) and macOS is a huge
| bonus.
|
| But I totally get that this is from outer space for another
| group. Vim is a great alternative for people who want a more
| opinionated editing wizard mode, and VSCode is really competent
| at interacting with remote filesystems and supporting lots of
| languages for the GUI crowd. It's a great time to be editing
| text.
| lc9er wrote:
| I'm a (neo)vim user that's been playing around with various
| Lisps lately. CL and Scheme interaction is worlds ahead in
| Emacs, but even with evil-mode, I'm having a hard time. There's
| lots of places where it just stops working, and I have to
| remember Emacs bindings. Emacs 27 and 28 are more responsive,
| especially on Windows, but vim actions are near instantaneous.
|
| A cool project I stumbled across is Aniseed[0], which thanks to
| Neovim's Lua bindings, lets you control neovim with Fennel. I
| haven't done anything noteworthy yet, but for the first time it
| actually seems like it would be fun to write my own plugins.
|
| [0] - https://github.com/Olical/aniseed
| dmortin wrote:
| Emacs is not a text editor, it's a platform independent VM which
| can run your scripts with a text UI.
|
| E.g. do you want keep an eye on some information which can be
| fetched from the net? You just write a script which regularly
| fetches the info and puts it into a buffer, so you can take a
| look at it anytime, and then regardless of platform you have that
| info readily available just by installing your own emacs config
| file.
|
| It's much easier to write such things in emacs than curating
| various different scripts in various languages (python, etc.)
| which all require their specific support which is either
| available or not.
| roydivision wrote:
| > It's much easier to write such things in emacs than curating
| various different scripts in various languages (python, etc.)
| which all require their specific support which is either
| available or not.
|
| I disagree. I've been using Unix/Linux for 25 years, I've met
| maybe 1 or two people who know or use Emacs, whereas almost
| everyone knows enough to do some scripting.
|
| I'm also guessing that installing and configuring Emacs is way
| more work than installing Python. And any gained Python
| knowledge will pay you back tenfold more than learning Emacs.
| rpdillon wrote:
| I think my Emacs knowledge has paid off ten times more than
| any particular language I've picked up. It's my generic
| tooling platform I bring to every job, regardless of platform
| or tech stack.
| saagarjha wrote:
| Bash?
| rpdillon wrote:
| I write Bash in Emacs, and everything else. So for me,
| no. For a sysadmin, perhaps.
| indymike wrote:
| Honestly, getting going with emacs:
|
| $ sudo apt install emacs $ emacs
|
| From there it's learning some keystrokes. Payback? Almost
| immediate. And you can use it to work with Python, or any
| other language. After that, maybe reading a couple of howtos
| and installing a few add-on packages and customizing your
| configuration. Payback? Almost immediate. It's really
| productive.
| jonfw wrote:
| > From there it's learning some keystrokes
|
| Learning Emacs is VERY clearly not this trivial... to use
| Emacs to any extent where it's more useful than it's
| competitors, you have to learn the models it works in, a
| new programming language- and then there are a LOT of
| keystrokes
| BeetleB wrote:
| > to use Emacs to any extent where it's more useful than
| it's competitors, you have to learn the models it works
| in, a new programming language- and then there are a LOT
| of keystrokes
|
| Let's take these claims one by one:
|
| > you have to learn the models it works in
|
| I read a book on Emacs and practiced along all within one
| week. At the end of the week, I was doing more with it
| than with any of the previous text editors I used.
|
| Indeed, my desire to learn Emacs was _explicitly_ to
| replace the other editors I was using - and I succeeded.
| Over the subsequent weeks, every time I encountered a
| situation where I said "Oh, I wish the feature I used in
| editor X existed in Emacs", a quick Google search told me
| how to set it up for Emacs.
|
| > a new programming language
|
| I was a power Emacs user for over 9 years before I
| learned Emacs Lisp. Clearly wrong claim.
|
| > and then there are a LOT of keystrokes
|
| While I'll admit you get more productive the more you
| learn, for most of those 9 years I did _not_ know many
| keystrokes. Instead, you do M-x and the command. With
| completion systems like ido (the "simplest" of the
| powerful completion systems), you can quickly find the
| desired command just by guessing what it will be named.
|
| I only started learning lots of keystrokes recently,
| using flashcard software. And even with _that_ , I
| stopped after about a year once I learned how to use
| hydra.
| pmoriarty wrote:
| Do you want a trivial learning curve or do you want
| power?
|
| The people who Emacs will please most are power users who
| are willing to put in the time to learn it and configure
| it to their liking.
| jerf wrote:
| I... uh... am almost in some sense ashamed to admit this,
| but I've been using emacs for about 23 years now, and I
| still don't program elisp. I can just about diagnose
| errors in my not-very-complicated .emacs with a bit of
| googling, and that's about it. I've read about it, and I
| understand the basics, but I know nothing about the APIs
| and have no experience in it past one-liners.
|
| It probably is a good idea to learn it, in some sense,
| and you'll probably have to pick up at least the basics
| that I've picked up, but it's definitely not a commitment
| to learn a new language.
| joosters wrote:
| Same here, but not ashamed about it at all. If there's
| something I need to automate or change in emacs, it's
| just a web search away and I can find the elisp that I
| need to add into my config files.
|
| I'd consider myself an advanced user of emacs, but that
| still doesn't mean that I have any motivation to _write_
| any new emacs modes or functions, since just about
| everything I could ever want already exists!
| pmontra wrote:
| I got good at elisp in my first years of emacs 30 years
| ago. Tons of customizations. Then I let it go. I remember
| the basics but I never write any serious script. No need
| for that. There are so many packages ready to be
| installed and Stackoverflow. The solutions are already
| there so I can concentrate on my job.
| pmoriarty wrote:
| Using Emacs without knowing eLisp is like owning a race
| car but always driving it in first gear.
| jerf wrote:
| I can deal with that metaphor, if "a race car in first
| gear" is still faster than a lot of other cars.
|
| Plus, it's the same race car. I've programmed half-a-
| dozen languages quite seriously in emacs, and I'm not
| changing editors the whole time. So, while I may not know
| elisp, I do know a fair amount about emacs and don't have
| to relearn how to do a lot of things in a new IDE every
| three years... or, worse yet, discover that entire
| features are missing because "nobody" has ever used an
| editor that had them. (I'm not sure I could live without
| macros of some sort in an editor.)
| dmortin wrote:
| I meant the case when you have to use an other machine and
| naturally emacs users want to use emacs even there, so that's
| given. But on Windows, for example, python may not be
| installed, so that's an extra install, while if you have your
| usual scripts in emacs then it's just a matter of installing
| one's emacs config which one does anyway.
|
| I use python too when it's the less hassle. E.g. when parsing
| a page with BeatifulSoup which would be more cumbersome in
| emacs without BeautifulSoup.
| RMPR wrote:
| > But on Windows, for example, python may not be installed
|
| Actually Python is not a very good example since Windows
| now includes python and python3 commands by default[0]
|
| 0: https://devblogs.microsoft.com/python/python-in-the-
| windows-...
| wiz21c wrote:
| Compiling emacs oneself is certainly easy these days (I just
| tried a month ago, just to make sure of something and I was
| very happy to see that it's just as easy as it can get
| (install just a few dependencies et voila))
| hprotagonist wrote:
| > I'm also guessing that installing and configuring Emacs is
| way more work than installing Python. And any gained Python
| knowledge will pay you back tenfold more than learning Emacs.
|
| I'm a full-time python developer in the sciences and an emacs
| user and neither of those claims are true.
|
| More's the pity.
| justaj wrote:
| I don't know. People keep saying that Emacs can work nice in
| terminals, but there's a specific bot-macro in the #emacs
| channel on Freenode: <user>: ,terminal
| fsbot [->] I heard terminals are [0] Terminals do weird thing
| to your keyboard input:
| http://catern.com/posts/terminal_quirks.html fsbot [1]
| Terminals have limitations compared to the graphical windows;
| it's advisable to use "graphical" Emacs unless one has a good
| reason not to. See ,betterdefaults for disabling scroll bars,
| tool bars, etc. fsbot [2]
| https://garbagecollected.org/2017/01/31/four-column-ascii/ ;;[
| ,more / ,dump]
| Kaze404 wrote:
| As an evil mode user, the keyboard input thing doesn't really
| affect me. That lets me use emacs on the terminal when I'm
| away from my computer no problem.
| pmoriarty wrote:
| Yes, there are many GUI Emacs fans on #emacs, and one of them
| obviously happened to set up this bot message. But not
| everyone agrees that GUI Emacs is better.
|
| Though terminals definitely have their quirks and
| limitations, they have some advantages over GUI Emacs.
|
| For example, I have my Emacs configuration geared towards
| terminal use, and use it from within tmux. Because of this I
| never have to fear losing my Emacs session because X froze or
| crashed (which has happened from time to time). I can also
| use Emacs configured the way I like it even before X has
| started, and on remote systems without X (for which I don't
| like to use TRAMP mode because it also has the potential to
| freeze up).
|
| By running Emacs in a terminal under tmux, I also don't have
| to mentally context-switch between the terminal and a
| separate GUI Emacs session. I have not been satisfied with
| any of Emacs' terminal modes, tough I have heard that
| libvterm is a lot better, so I might give it another go,
| though even if it's great at terminal emulation there are
| some other issues with running a terminal from within Emacs
| which may be insurmountable[1]... which leads me to the next
| point...
|
| With Emacs running under tmux in a terminal rather than the
| other way around, I never have to fear losing all of my
| terminal sessions when Emacs freezes or crashes (which has
| also happened from time to time). By contrast, tmux is super
| stable, and I've never once had it freeze or crash, so I can
| 100% rely on it to keep my terminal sessions running no
| matter what.
|
| [1] - Running a terminal under Emacs (even if it's a proper
| terminal like libvterm) has the issue of conflicting
| keybindings. I already have both Emacs keybindings and tmux
| keybindings that I have to make sure don't conflict, but if I
| add to those keybindings for any app I happen to run under a
| terminal under Emacs then there are bound to be way more
| conflicts. Of course, it's possible to require some extra
| keystroke to be pressed before sending on a raw keystroke to
| the terminal app, but that's just too painful for me to
| bother with except maybe under special circumstances. In the
| general case I prefer to have my shells running directly
| under tmux than in an Emacs terminal.
| andreareina wrote:
| We've been joking about emacs being an OS for a long time. And
| it even reads email (still haven't set that up actually...)
| konjin wrote:
| You can post on hacker news from it too.
|
| Sent from eww.
| jimmyvalmer wrote:
| Or Gnus.
|
| Sent from nnhackernews
| mrspeaker wrote:
| There's also a pretty nifty dedicated hackernews-mode.
|
| Sent from `M-x hackernews`.
| jimmyvalmer wrote:
| That mode is rubbish. You can't reply nor vote, requires
| manual syncing, and renders stories as links rather
| jumping directly to the story.
| jeromenerf wrote:
| > t's much easier to write such things in emacs than curating
| various different scripts in various languages (python, etc.)
| which all require their specific support which is either
| available or not.
|
| Not in my experience.
|
| I much prefer to use the simpler acme / plan9 way, where I am
| free to use the language I prefer or that is better suited for
| the job. Same for vscode, atom, etc.
|
| Vim and neovim are halfway between these extremes and I would
| say easier to bend towards acme than towards emacs.
|
| That being said, I use org mode because it's great, thanks to
| emacs capabilities. I would however also much prefer org mode
| if it was an external pandoc-like program, usable from
| anything.
| pmoriarty wrote:
| I never got the appeal of acme. It's way too mouse-oriented
| for me.
| chrisseaton wrote:
| > Emacs is not a text editor
|
| https://www.gnu.org/software/emacs/:
|
| > [Emacs is] an extensible, customizable, free/libre text
| editor -- and more
| GavinMcG wrote:
| Emacs saying it's a text editor doesn't make it a text editor
| any more than Amazon saying it's a bookseller would make it a
| bookseller. Emacs-as-platform long ago overtook Emacs-as-
| text-editor.
| jmiskovic wrote:
| How does emacs UI work? It seems like each script is registering
| commands it can run in context of mode, and then you can bind key
| combos to commands. How do textual UIs do things like layouting
| of controls, updating of values and handling async requests?
| ywei3410 wrote:
| > How does emacs UI work?
|
| Emacs has the idea of _buffers_ which are the actual window
| panes that you can view. The _buffer_ has data in the form of
| text which has properties in much the same way a block of html
| can have properties. An emacs-lisp function has full access to
| do anything it wants with the buffer. For example it can insert
| contents, change the font family, change the bit of text into a
| button with a callback. This is exactly how syntax
| highlighting/semantic highlighting works in emacs, you just
| change the styling for bits of text [1].
|
| A _mode_ inside emacs is a collection of emacs-lisp functions
| which trigger (usually on a file extension name). Typically
| they will set certain keybindings for specific mode-like
| behaviour. You always have a single _major_ mode and multiple
| _minor_ modes - the vim emulation layer, for example is simply
| a minor mode which adds the vim keybindings and emulates the
| vim state machine inside emacs-lisp.
|
| > It seems like each script is registering commands it can run
| in context of mode
|
| An emacs-lisp file can be _evaluated_ in the same way as a
| python file into emacs. It's like a REPL - you can evaluate a
| file and the functions become available. There's a bit of extra
| behaviour which allows lazy loading et cetera, but user defined
| scripts are first-class and there's no distinction between them
| and those which are "native".
|
| > updating of values
|
| You can update a variable by simply evaluating the appropriate
| lisp function. If you want to update a value in the text
| buffer, you just replace/rerender that chunk.
|
| > handling async requests
|
| A buffer can also have a _process_ running which gets events
| each time the buffer is updated. When you run a command, you
| direct the output to a buffer and you trigger your lisp
| function on certain events. This is sort of how the HTTP
| requests work, but there's libraries which abstract some of it
| for you. Buffers are really just an abstraction for textual
| data.
|
| Some of this is simplified, but I hope it gives you a vague
| idea of what emacs is.
|
| [1]
| https://www.reddit.com/r/emacs/comments/iemo44/wysiwygified_...
| axilmar wrote:
| In other words, Emacs has its own markup language? how does
| emacs know that a specific bit of text is a button, for
| example?
| dmortin wrote:
| Characters can have various properties set. These are
| either built in or you can define your own properties too.
| juxtapose wrote:
| Yes, Emacs supports a limited form of "rich text". See
| text-mode.
|
| It's supported by text properties [1] and overlays [2].
| Character properties are special attributes attached to a
| single character, while overlays can attach attributes to a
| "region" and override old text properties (like div in
| HTML).
|
| In Emacs,
|
| > A button is essentially a set of text or overlay
| properties, attached to a stretch of text in a buffer. [3]
|
| The Emacs display engine is sorta like an HTML render
| engine.
|
| [1] https://www.gnu.org/software/emacs/manual/html_node/eli
| sp/Te...
|
| [2] https://www.gnu.org/software/emacs/manual/html_node/eli
| sp/Ov...
|
| [3] https://www.gnu.org/software/emacs/manual/html_node/eli
| sp/Bu...
| dhosek wrote:
| Wow, it's interesting how many people seem to have their own
| takeaways from this, many of which seem to have missed the
| original point of the post (I wonder how many actually read the
| post). The author of the post on gnu.org is blind (and the
| "Raman" he referred to is T. V. Raman, a blind mathematician who
| I met ages ago when he gave a presentation at the Portland TeX
| Users Group meeting about adapting TeX for presenting mathematics
| to blind readers. Raman, in fact, wrote a reply to the message
| where he wrote:
|
| _> A lot of baggage gets applied today when folks talk about
| "Accessibility", but to me the touch-stone of a truly Accessible
| system is one where you dont have to ask what interaction
| modality someone else is using e.g. witness email, where the
| persons participating in a conversation never need ask "Did the
| person I am talking to use Braille, speech, or something else",
| similarly, someone who has a hearing impairment can send you
| email without you ever needing to know that he cant hear you._
|
| I feel like too many developers treat accessibility as an
| afterthought rather than a central concern.
| sn41 wrote:
| It is an interesting historical note that T. V. Raman won the
| ACM best doctoral dissertation award as a blind scholar [1]. I
| take an active interest in accessibility partly because my
| wrists hurt. Technologies initially meant to help blind people
| have turned out to be useful for people with other conditions
| as well. [1] https://awards.acm.org/award_winners/raman_4110221
| pmoriarty wrote:
| _" I take an active interest in accessibility partly because
| my wrists hurt."_
|
| If we live long enough, each of us will almost certainly have
| accessibility issues.
|
| So improving accessibility helps our future selves.
| PaulDavisThe1st wrote:
| Last year I was 55 and backpacking with my brother (35). I
| was reading a 1st gen Kindle and having problems without my
| reading glasses. He kindly pointed out to me that you could
| change the font size, an idea that absurdly had not occured
| to me. I still don't know what was more remarkable: that it
| didn't occur to me, or the way it saved 16 nights of
| reading for me. It felt a little embarrassing to have to
| take advantage of this feature initially, but it wasn't
| hard to embrace and feel deeply grateful for.
| linkdd wrote:
| Thanks to Chrome which saves the zoom settings per
| domain, I have "configured" every site I read to be at
| the same size (125% for most of them, 110% for some, 200%
| for monsters who put a very small font).
|
| I do this mainly because switching from font size to font
| size actually tires my eyes (they always need to refocus)
| on the long term.
| dhosek wrote:
| This change seems to have made its way upstream into
| Webkit (or perhaps went downstream to Chrome? Who knows,
| probably the former though). It's really nice to have the
| zoom setting preserved on visits rather than on tabs. I'm
| also fond of the two finger double tap on the trackpad to
| zoom into a narrow column of text on a website (I assume
| Chrome also supports this) which is my primary mode of
| reading a lot of websites.
| jannes wrote:
| The zoom level can be read by the website and used for
| fingerprinting, so some browsers see it as a privacy
| issue to preserve it across visits.
|
| Firefox supports both, but the default is to preserve it,
| I think.
| jrockway wrote:
| Chrome has a "minimum font size" setting that overrides
| websites that use small fonts. I set my minimum high (16
| normal, 14 minimum) and haven't run into any breakage.
|
| (I am not sure if the point sizes of fonts have any
| meaning. I like my text a certain size and it's a
| different number in Chrome, Powershell, and Putty, which
| is weird to me...)
| rbanffy wrote:
| IIRC, in typography, a point is 1/72th of an inch.
|
| I don't think desktop computers, with the possible
| exception of the NeXT, ever respected that.
| munificent wrote:
| _> Technologies initially meant to help blind people have
| turned out to be useful for people with other conditions as
| well._
|
| The generalization of this observation is called the curb-cut
| effect:
|
| https://burness.com/blog/the-curb-cut-effect-how-a-fix-
| for-o...
| jberryman wrote:
| Are there any particular technologies that have helped you
| with your wrist issues?
| mercer wrote:
| in my late teens and early twenties my wrists started hurting
| so bad that I could barely use a computer.
|
| While over time things improved to the point where I only
| have pain after doing pixel-style photoshop work with a
| mouse, it made me _painfully_ aware of easy it is to take
| things for granted and not consider accessibility.
| paulryanrogers wrote:
| NIH and others have recommendations that may help. I would
| also suggest seeing a specialist ASAP. A career may last a
| few decades but your body is for life.
| dang wrote:
| Coincidentally, there is a current thread about blind
| mathematicians:
|
| https://news.ycombinator.com/item?id=24429493
| jefftk wrote:
| A website can have this cross-modality UI property too, but most
| sites don't. This is partly cultural (emacs mode developers
| generally caring more) and partly about collaboration (it's much
| easier to upstream issues with an emacs mode than a site).
| robenkleene wrote:
| What's the difference between what's being described here and the
| web?
|
| (In particular, Electron-based local applications which of course
| have a cross-platform web-based UI.)
|
| I'm not saying they aren't different, at the very least, Emacs
| prioritizes text, while the web prioritizes multimedia. But I'd
| love to hear other peoples takes on the differences.
| HelloNurse wrote:
| "Prioritizes"? It's a fundamental difference. If everything is
| text, text processing can process everything; if everything is
| a blob with a MIME type user experience is fragmented into
| whatever more or less integrated clients are able and willing
| to do with each incoming document (usually not much).
| narwally wrote:
| > What's the difference between what's being described here and
| the web?
|
| The web is generally terrible for accessibility. Since emacs
| has always prioritized maintaining compatibility between its
| graphical and text UIs, it words very well with screen readers
| and refreshable braille displays. It's also been designed from
| the beginning with keyboard navigation in mind.
| slightwinder wrote:
| The Webstack is far more complex than anything emacs offers.
| Emacs has just a wall of text with some special markup, but
| there is not concept of layout for this text, and all
| navigation is usually separate from the wall of text, making
| accesability significant simpler to handle.
|
| In emacs there is a beginning and an end, and you just follow
| the flow. In webstack you have elements, which have a position
| and if you are lucky they are tagged with their purpose. If
| not, it's up to you to figure out whether this is for
| navigation or content or advertisement or some other navigation
| or comments, which is more another kind of navigation...
| Basically there is just no really realiable structure with the
| web. Sometimes there is something, sometimes not, sometimes
| it's this way, next week it can be that way...
|
| And even worse are dynamic site where parts of the site are
| loaded on demand. So you need a complex setup of tools to
| handle those content, instead of simple text-search and cursor-
| moving.
| shawnz wrote:
| You could construct the same kinds of problematic UIs in
| Emacs too... it's just that Emacs is not as widely used as
| the Web and its users don't have such varying demands and use
| cases for it, so it's not as common for that to happen.
|
| The Web is also designed around a linear flow of text. The
| Web also provides opportunities to make navigation semantics
| clear. The Web also implicitly supports keyboard navigation
| everywhere. etc. Although many websites try to work around
| those principles, is that a problem with the web or just the
| websites people are using today?
| slightwinder wrote:
| > You could construct the same kinds of problematic UIs in
| Emacs too...
|
| If you do it on purpose, then maybe, but not to the degree
| of what webstack offers. People already have a hard time to
| handle org-mode-hierachies and folding...
|
| > The Web is also designed around a linear flow of text.
|
| No, that went out the door when CSS was added. Now it's
| designed around random positioning of little boxes. Some
| boxes contain linear text, some contain media, most contain
| even more little boxes.
|
| Emacs does not have those boxes in the first place. The
| only boxes it has are outside the document, avoiding this
| whole class of problems for accesability.
| shawnz wrote:
| Sure it does. First of all, you can lay text anywhere you
| want in a buffer, thus letting you create whatever little
| boxes you want. Plus, it has support for images and even
| arbitrary GTK widgets in that buffer too.
|
| Remember before CSS, people just did the same thing
| anyway with tables. CSS only made easier what people were
| already doing. I am sure the same would happen to Emacs
| if it ever became a widely used piece of software.
| taeric wrote:
| I think you have never looked at the customize screens.
|
| Not to mention that many of us have used emacs for email for
| ages. Which, lo and behold, is dynamic with parts loading
| before or after others. Even viewing images inline has been
| doable for a _long_ time.
|
| Don't get me wrong. Emacs has stayed mostly text focused.
| Even mostly linear focused, I would agree. I view that as a
| plus, though. The modern web world? Not so much. And telling
| that most "resurgences" of popular sites and ideas are
| usually a return to a linear treatment of data. Often most of
| the extra crap around are flashy graphics or desperate
| attempts to get more interaction from users.
| blauditore wrote:
| Slightly off-topic, but people here seem to like that stuff: The
| author has a personal website[0], which is a gem from the "old
| internet" - a wild mix of technical stuff, pet cat pictures, and
| some personal history.
|
| [0]: https://delysid.org
| sreevisakh wrote:
| Very interesting! Made me curious about how a blind person
| codes (accessibility technology). Aside from that, I am also
| curious as to why you characterize the website as from the 'old
| internet'. It looks like a modern minimalist static site to me.
| Not what I would expect from a 90s site. What do you consider
| as the distinguishing features of old internet vs the modern
| version?
| submeta wrote:
| Emacs + org has the potential to be the dream environment for
| everybody with a hacker mindset: Automate everything that has to
| do with text: Journaling, writing todo lists, parsing your Kindle
| highlights file (`My Clippings.txt'), writing project outlines,
| doing web research and saving your searches, notes, thoughts,
| summaries in Emacs via org-capture, drafting papers in org-mode,
| creating (text-based) tables and overviews, writing tech
| documentation with embedded screenshots, and many many more.
|
| What ties all these notes and files together is Emacs Lisp: Write
| Lisp functions to automate most of what you do. - Previously I
| used Python for that, but Elisp is so much more fun to automate
| text-based workflows.
|
| I would have to write a book to summarize all the ways this can
| transform your interactions and workflows with your computer and
| especially with everything text.
|
| Edit:
|
| After twenty years of using all sorts of text based databases and
| PIMs (AskSam, NetManages ECCOPro, various outliners, Outlook,
| Evernote, Omni{Focus,Outliner}, Bear Writer App, Ulysses App, and
| half a dozen other tools) I have come to realize that nothing
| beats Emacs + Org + Lisp.
| agumonkey wrote:
| I hate org.
|
| I use emacs 25/7, I hate org.
|
| Something about it rubs me the wrong way, yet I use it but only
| the basic parts. I think it's that I can't wrap my head around
| the mental model of it, and since it encompasses 2000 topics
| (trees, timing, workflow, states, agenda, journaling, tagging)
| it's like a mountain of mud before my eyes.
| BeetleB wrote:
| Dude: It's just a simple outliner with features built on top
| of it. There's not much of a mental model beyond the outline
| aspect (headings and text). Everything else is just a feature
| which you don't need to know to use the basics. As your needs
| go up, you merely learn the feature you want to use. Most
| people use only 10-20% of Org's features.
|
| Seriously, M-Ret, TAB and S-TAB are all you need to get
| going.
|
| I watched the Google Tech Talk on it and was immediately
| productive. Don't bother with the Org manual until you want
| to do more.
| blablablerg wrote:
| Well you don't even have to understand it fully, that is what
| is great about it.
|
| What it is good for is that it gives you maximal freedom in
| organizing things the way you want. When I start out with a
| new org file, I just make lists and add functionality when
| needed.
|
| While with most other todo/organizing applications you tend
| to be forced in some framework. This is how you should
| organize, and when you want to deviate things become
| cumbersome.
|
| And then the other good thing is that editing is FAST (I use
| evil mode), in most other organizing/productivity tools you
| have to click a lot. Simple things become a chore quickly.
|
| Freedom + speed = gold
| agumonkey wrote:
| oh you're assuming that not using org means using another
| organizer[0].. I just stopped organizing :D
|
| who knows, maybe one day I'll finally see the light
|
| [0] and I fully agree that most systems are way less
| ergonomic than emacs
| blablablerg wrote:
| Haha yeah I also never planned, I hated it. Still do
| actually. But one day I was fed up with the chaos in my
| life, dirty house and minimal productivity that I
| decided.. I need structure. I realized that the time I
| invest in structure pays itself out, because I spend less
| time goofing around. And so started the great journey in
| finding the best todo system. I started with paper, then
| google calendar/tasks, todoist and load of other apps
| until I finally went back to paper. The apps were just
| too cumbersome. Paper was simple and worked, but
| unfortunately paper itself is difficult to organize. I
| always avoided orgmode because well.. I was scared of
| emacs but eventually decided to give it a go, see what
| happens. And it was what I have been looking for all
| along: a simple and flexible system. And vim keybindings
| are a big bonus :)
| dmortin wrote:
| You can use as much or as little of org as you want. It's
| perfectly allright to use only a subset of it. I do. I only
| use what I need.
| submeta wrote:
| I started using it as an outliner. Then I added org-agenda to
| it, and migrated all my tasks from Things3 to it. Next I
| added repeated tasks, then org-habits, org-journal and some
| more. Incrementally.
| agumonkey wrote:
| I choked at outliner level
| rgrau wrote:
| I feel ya, my friend.
|
| I also have read the org manual a few times, and it feels so
| big you can't hold a mental model for long enough to make
| sense while incorporating all its features. As you know, org
| mode has too many features to use them all at once (like
| emacs itself).
|
| What (kinda) worked for me was, after knowing "I've read it
| all", to purposefully "downgrade" to a very very basic
| workflow. I thought then I would start adding features on a
| need basis, because I had the perimeter of what it can do.
|
| But it turns out I haven't added anything else to the trivial
| workflow. There's a bit more info here (
| https://puntoblogspot.blogspot.com/2018/12/3-basic-org-
| agend...), but essentially the trick was to use just one
| capture template for everything that just schedules the
| current task for today (so it appears in agendas until I mark
| it as done), and one single file, without different subtrees.
| ("t" "Todo" entry (file+headline "~/org/tasks.org" "Tasks")
| "* %^{title} \n SCHEDULED:%t\n %?\n %i\n %a\nAdded: %U")
|
| I feel safe because in that file, down means "later", so I
| still can rely on my basic common sense.
| etaioinshrdlu wrote:
| Not that it's anything like Emacs, but would SIM Application
| Toolkit be considered kind of similar? It provided almost a
| lowest-common-denominator user interface for apps, which could
| actually run in the smartphone era, although with practically no
| advantages over a native app.
| venamresm__ wrote:
| You'd be surprised to hear STK is still in use even today by
| big mobile operators. Some even go as far as to launch
| campaigns to install STK applets on millions of devices and
| customers have no idea this is happening in the background.
| yaantc wrote:
| Yes, all the "eSIM" over-the-air management uses the STK for
| example. But to be fair, the user interface part is no longer
| used. The part of the STK still in use is what is required to
| support remote management functions between the network
| operator and some applet on the SIM card. The user is out of
| the loop, and it's perfectly fine for a modem not to support
| the user interaction part of the STK.
| venamresm__ wrote:
| I actually work within the eSIM ecosystem and other sim
| related activities. And, yes, some mobile operators do
| indeed use the STK UI today, it's not limited to background
| tasks.
| mullikine wrote:
| I wish to profess my love for terminal emacs. I do not take it
| for granted. Hear ye. Any editor so powerful that also humbles
| itself to a 100x30 terminal without losing any power is pure
| class. This program deserves praise. I pray that GNU emacs will
| continue to support a text-only interface for many years to come
| and when at last the elisp fractal is no longer fit for purpose,
| I pray that its mechanics will be absorbed by the great neural
| network that will learn everything.
| melling wrote:
| Emacs Lisp is slow. There has been a multi-decade effort to make
| Guile support ELisp, and using Guile to make Emacs more
| performant.
|
| Cross platform UI, with a faster Lisp, would allow Emacs to be
| even more special.
| bjoli wrote:
| Guile Emacs will never happen. Robin's work was amazing, but at
| it's absolute height guile Emacs was still a slower and buggier
| version of regular Emacs. I am pretty certain a full guile
| Emacs would be better than current Emacs (guile is actually a
| very neat little VM with lots of cool optimisations going on),
| but that is not where the reality is.
|
| As a guiler I want Emacs to be guile-based, but I totally
| understand the Emacs POV: guile is an external dependency with
| unsecure maintainership.
| pmoriarty wrote:
| Never say never.
|
| Guile Emacs was the work of one (very talented) guy. He's
| moved on to other things, but it's not inconceivable that
| another Guile fan will pick up the torch some day.
|
| If enough Guile/Emacs fans get together this might actually
| turn in to a viable, maintainable project... this is, after
| all, how Neovim started. Just some people who were
| unsatisfied with where Vim itself was going, and teamed up to
| make their alternate vision a reality -- with great success.
|
| Guile Emacs work is actually a much smaller task than Neovim,
| as Neovim's authors rewrote Vim from scratch, whereas Guile
| Emacs has a much more humble aim of simply allowing eLisp to
| be hosted on the Guile VM.
|
| It could still happen.
| bjoli wrote:
| With the direction guile has been going in lately, guile is
| only becoming more attractive.
|
| The problem with integrating it is that you need someone
| with good knowledge about guile (since the elisp
| implementation is pretty bad currently) but even more
| important: someone who know Emacs internals (not many).
| slightwinder wrote:
| Multi-decade effort..wasn't that done by just 2-3 guys as an
| alternative attempt?
|
| Anyway, while elisp might not be the fastest language around,
| it's not the origin of all slowness in emacs. Crufted design is
| also a big culprit. The dated regex-machine is often mentioned
| as a big problem, making syntax highlighting especially
| painful.
| pmoriarty wrote:
| Apparently, Emacs' display code shares the blame, and no one
| wants to touch it as it's written in some really hairy legacy
| C.
|
| Though I'm not a Rust fan, and would infinitely prefer Guile
| Emacs, I am kind of half-hoping Remacs succeeds so Emacs can
| finally put all of that legacy C behind it.
| duckonomy wrote:
| Some people are saying that
| https://github.com/ubolonton/emacs-tree-sitter will
| eventually replace the default regexp-based font-lock for
| syntax highlighting. I'm personally testing it out and it's
| been great!
| LandR wrote:
| My experience on windows is that emacs is unusably slow.
|
| Multi-second lag on type and navigating isn't acceptable. Org-
| mode is especially bad.
| jonrx wrote:
| I think it's related to the fact that emacs has multiple
| (very) small files and short-lived processes, which does not
| work well/fast on Windows. For a while, I ran Xubuntu in a VM
| just to use emacs, because the performance on my Surface book
| 2 was unacceptable.
|
| I ended up going in the other direction: kept emacs, got
| mostly rid of windows (I have it in a VM for the odd occasion
| where I need to use a windows-specific program. The fact that
| my company is flexible on the work OS is a huge bonus for me.
| gpderetta wrote:
| the new AOT compiler seems promising though and has a good
| chance of actually making it into the release.
| globular-toast wrote:
| Yes... but it's not _that_ slow. In practice, emacs works at
| least as fast as I can think most of the time. This is the most
| important thing for me. It 's the reason why I originally
| switched to git from svn (Linus also specifically mentions this
| as a design choice for git). In this day with electron and
| editors like VSCode I wouldn't call emacs particularly slow.
| marcosdumay wrote:
| More important, I never have to wait emacs to fill a buffer
| with the text I've typed.
|
| Yes, on some modes there is a visible delay between pasting
| text and being able to type again, or writing some code and
| it telling me it's wrong. But the one kind of interaction
| that matters is always flawless.
|
| Many editors do not get this right.
| wiredfool wrote:
| I'm not sure about the others, but rjsx mode is slow with
| moderately complicated files, and the (idr which)
| accompanying refactor minor mode is glacial on a mbp.
| morelisp wrote:
| rjsx is based on js2 which makes it unusually slow. js2 was
| a valiant attempt to make a major mode that uses elisp to
| actually parse the language. This gave it tremendous power
| compared to every non-Lisp major mode and most other JS
| editors at the time, but it has not aged especially well in
| modern JS support or performance.
|
| I'd try one of the LSP based approaches instead these days.
| gpderetta wrote:
| I think the reason that emacs feels fine most of the time
| even if elisp is slow is that usually abstractions are fairly
| minimal.
| 5h wrote:
| As a non Emacs user, is the speed of Emacs Lisp a frustration
| in typical day to day usage?
| jsilence wrote:
| For me as a long term Emacs user, started using it 1994ish,
| it is not an issue. I don't mind the occasional minor lag. In
| my usage it is rarely in a range where it actually makes me
| wait.
|
| Emacs has a certain feel to it. Hard to put the finger on,
| but the movement of the cursor and the scrolling, it just
| feels nice for me. Like a well worn favourite T-Shirt.
| monsieurbanana wrote:
| Sometimes. Vanilla emacs is lightning fast, but it's also
| missing critical features for most people.
|
| If you want to use emacs as a an alternative to VSCode, or
| IDE in general, you'll find high quality plugins that will
| enable you to do so. But then you might experience slow
| downs.
|
| As emacs is single-threaded (people will come and tell me
| it's not anymore, I know, but in practice it still is) you'll
| feel any slow downs in those plugins. Emacs typing latency
| isn't great.
|
| It's a mixed bag really. It can be fast, it can be slow. It's
| still my favorite editor.
| jmiskovic wrote:
| What are you using now? If VScode or Atom you won't feel any
| degradation. If vim or SublimeText, some things will take few
| extra dozens of milliseconds. You could test the Doom Emacs,
| which is trying to be a feature-full emacs environment
| optimized for speed.
| 5h wrote:
| I've been using Vim for a very long time now, recently
| adding CoC has slowed things a bit however I am quite fond
| of some of the features, so I might start enabling it only
| when I want those.
|
| I'm not looking to encouragement to change (after 20 years
| in Vim that ship has likely sailed for good), I was just
| curious if the speed of Emacs lisp was a frequent bugbear.
| rossvor wrote:
| Speaking as recent(4-5 months) Emacs(spacemacs) convert - it
| is slower compared to even "decked out" vim. An important
| caveat to mention is that it very much depends on what modes
| you are operating in -- each file type will usually operate
| in its own mode, with varying performance. In my experience
| the lagginess is rare, but its very workflow dependent,
| there's this one large(1.5k line) php file I have to edit
| semi-regularly on which I switch off the php mode, just to
| avoid the pain of jankiness. It isn't very noticeable in
| other, "regular" sized files.
|
| But overall I'm a very happy emacs convert. It's extremely
| malleable and pleasant development environment and I think it
| definitely deserves all the gushing articles/posts its been
| receiving past few years.
| beojan wrote:
| Spacemacs is actually quite a bit slower than it probably
| needs to be (by which I mean "slower than Doom emacs
| [https://github.com/hlissner/doom-emacs]").
| lawn wrote:
| I don't know the reason but for me Emacs is frustratingly
| slow compared to Vim.
| rusk wrote:
| Sometimes. But, in my experience a lot of these advanced
| development environments can be quite hang-ey if you know
| what I mean. It's quite lightweight relatively speaking so
| more than makes up for it.
| tikhonj wrote:
| There's some new development going on that compiles Emacs Lisp
| to native code with GCC and it is a _real_ performance
| improvement. I 've been using it on an unstable Emacs build for
| the past few weeks and I can _feel_ the difference--noticeably
| snappier and more satisfying.
|
| It's not 100% ready for day-to-day use yet--the deferred
| compilation logic seems to be recompiling more often than it
| has to--but I've been quite happy with it so far, and it will
| make a _substantial_ improvement for Emacs users once it 's
| stable and rolled out. Hoping it can be released with Emacs 28
| or 29 at the latest :).
| agumonkey wrote:
| What's your machine specs ?
| anthk wrote:
| Also Emacs can lock the rest of the panes while doing I/O.
|
| How could native code solve that?
|
| Guile at least could.
| II2II wrote:
| Most of the comments seem to be missing a very important point
| from the post:
|
| > As a blind user, I can write a special mode which does
| something specific, say, implement an IRC client. Almost all my
| work can instantaneously be used by sighted people using their
| graphical toolkit.
|
| This goes well beyond the ability of the author to create
| software that is accessible for both sighted and blind users. It
| is stating that support for both audiences is handled elegantly
| by the same toolkit, so you aren't creating an adversarial
| situation where serving the needs of both groups of people
| requires some form of compromise in the user interface or
| necessitating significantly more effort. (I would imagine that
| some care is required, but Emacs developers are going to address
| it anyhow since the program is intended to run in graphical and
| non-graphical environments.)
|
| I suspect this support of multiple environments is part of the
| reason why there is an esoteric collection of applications that
| run within Emacs. As an example: it is possible to read ebooks in
| Emacs, with formatting and images being supported in X and
| gracefully handled in a terminal.
| rleigh wrote:
| Some of its paradigms are plain stupid.
|
| C-Z (in the GUI) triggers minimise of the window.
|
| In a shell, that's fine. It suspends the process. In a GUI it is
| just bloody annoying. There's a perfectly good minimise button if
| I want it. This is just a frustration every time I fat-finger
| C-X. Which is used so frequently it's just asking to be pressed
| by accident.
| tom_ wrote:
| I don't rate this shortcut either, but there's an easy fix for
| your .emacs: (when window-system
| (global-unset-key (kbd "C-z")))
| jancsika wrote:
| > Emacs is the only serious program I know which manages to be
| truely user interface independent, in addition to being platform-
| independent.
|
| So tell me about the UX of free software speech recognition in
| emacs. I want to read about how to set that up and the
| limitations of it as I watch my 5 year-old niece interact with
| Alexa.
| skissane wrote:
| I can think of a few UI styles Emacs doesn't support (to my
| knowledge) - line mode terminals, block mode terminals (such as
| IBM 3270 and 5250), and HTML.
|
| Now, whether any of those UI styles are actually _worth_
| supporting is a completely different question. But it is not
| quite as universal in support of different UIs as this email
| claims.
|
| (You can technically write line mode applications in Emacs Lisp,
| try `emacs -batch -l dunnet` for an example. But most Emacs
| functionality is not available in line mode, the core text
| editing functionality certainly isn't. There is also a HTTP
| server available for Emacs [1], so you could use it to implement
| a HTML-based user interface, but once again the vast majority of
| Emacs functions are not available over HTTP)
|
| [1] https://www.emacswiki.org/emacs/HttpServer
| abdullahkhalids wrote:
| Emacs support of non-fixed width fonts is also pretty bad. My
| language Urdu is basically impossible to write on Emacs - or at
| least it was 5 years ago when I struggled with it a lot.
| ywei3410 wrote:
| The HarfBuzz font engine should help.
|
| What trouble were you having with specifically?
| NateEag wrote:
| Clarification: HarfBuzz is available in Emacs as of the
| recent 27.1 release.
| sreevisakh wrote:
| You should give it another try. My native script is also hard
| to render as fixed-width. But the latest Emacs seems to be
| doing well.
| twic wrote:
| Some time in the late '90s a friend and i sat down and tried to
| design a UI framework that could cover lots of styles. We
| started with GUI and line-mode terminal, but hoped to add
| curses and the web (1.0 of course, so using forms, not
| JavaScript). I didn't know about block-mode terminals at the
| time.
|
| GUIs and line-mode terminals are radically different, so you
| have to think of a language of UI primitives that are high-
| level enough to have a natural implementation in each style.
|
| This is hard! For starters, a GUI is inherently spatial,
| whereas a command line is more temporal. If you want to specify
| a sandwich, say, then in a GUI, you might have three select
| boxes next to each other for the bread, filling, and dressing,
| and a submit button, whereas on a command line, you need to
| prompt three times, and perhaps offer options for going back
| and changing the selection. Or offer internal commands for
| viewing the lists and making a selection, for a more shell-like
| interface.
|
| From what i remember, our API ended up looking a lot like web
| forms - the application presents a series of questions, each
| with a prompt and a structure for the answer (free text, select
| one from a list, etc). The GUI implementation then put together
| a (very ugly) GUI with a elements for each question, the
| command line implementation asked each question in turn.
|
| We never got as far as trying to display rich information. That
| could have been a whole different set of problems.
| [deleted]
| rusk wrote:
| Interesting ... has anybody tried a browser based (which is
| what I presume you mean by HTML) front end for emacs?
|
| EDIT - just to be clear, I'm talking about emacsclient, talking
| to a emacs server. Not an actual full blown emacs
| implementation that's just stupid.
| hpfr wrote:
| Cloudmacs basically puts tty emacs in your browser:
|
| https://github.com/karlicoss/cloudmacs
| skissane wrote:
| I meant old-school pure HTML forms, not a HTML5 app with
| JavaScript+Canvas (or even wasm+Canvas). With the later, you
| could in principle compile GNU Emacs to JavaScript or wasm,
| using e.g. emscripten. (I don't know if anyone has succeeded
| in that yet, but I think it would be in principle
| achievable.)
|
| Old-school pure HTML forms actually has a lot conceptually in
| common with block mode terminals such as IBM 3270. The server
| sends the client a fill-in-form, the user fills it in, the
| client sends it back to the server in one block. Most of the
| logic exists on the server (although some basic very basic
| validations may execute on the client). So, I was actually
| talking about serving up a classic pure HTML form app over
| HTTP as a UI style.
| rusk wrote:
| No, I am specifically not talking about this. I'm actually
| not sure at this point what you mean - I have a vision of
| somebody communicating with an emacs backend via forms?
|
| I'm just talking about a thin client, such as you typically
| use when you have emacs running as a server. You only have
| to manage text and windowing, and capturing user commands
| and communicating with the back end. These are the kind of
| things browsers are good at.
| skissane wrote:
| Well, think of a 3270 editor, such as ISPF EDIT on MVS or
| XEDIT on VM/CMS. Now imagine using that editor through a
| 3270-to-HTML gateway. That's what I was really talking
| about. But, you could actually implement a similar style
| of interaction in pure HTML, without the 3270 layer.
| Indeed, a lot of classic server-side web apps, even if
| they weren't text editors, worked with that UI style.
|
| Of course, Emacs doesn't support 3270. But that was my
| point - that there are UI styles which Emacs doesn't
| support. They might not be _useful_ UI styles, especially
| in 2020. But historically they were important, and any
| suggestion that Emacs is some kind of magic which
| supports all UI styles isn 't really true, although maybe
| it supports all contemporarily practically relevant UI
| styles.
| dheera wrote:
| With the new Chrome filesystem API it should be possible to
| make a full browser implementation.
|
| Let's just hope they don't have annoying GDPR and other
| popups when you're trying to edit a file.
| rusk wrote:
| You shouldn't even have to need filesystem API if you're
| just using it as an emacs client connecting to an emacs
| server.
|
| Your remark about GDPR is kind of strange ... not sure what
| that would have to do with anything ... GDPR applies to
| people and organisations, not their tools.
| NateEag wrote:
| The requirement to advertise "we use cookies" and spam
| you with popups when you visit a site is frustrating for
| highly technical users.
|
| OP is saying that Emacs-as-website would be frustrating
| if it had those popups.
| rusk wrote:
| You don't have to do that unless you're hosting a public
| site ... and even so if it's a private session and you'd
| logged in this wouldn't be required. Logging in is seen
| as a tacit acknowledgment that you consent to being
| tracked, cause how would I have. A personal session
| otherwise.
|
| The cookies warning is all about notifying the casual
| reader who might otherwise believe they were passively
| browsing static content.
| krageon wrote:
| > Logging in is seen as a tacit acknowledgment that you
| consent to being tracked
|
| Logging in means you get a single cookie (a login/session
| cookie), that cookie is necessary and thus a functional
| cookie that you can't say no to. All other cookies (and
| basically every form of tracking) still isn't allowed
| without consent.
| hdjdbtbgwjsn wrote:
| Some people really hate GDPR. It has crushed the AdTech
| industry in Europe - I'm not sad about that but I do hope
| those people found other employment fast.
| rusk wrote:
| There was a thriving industry harvesting and processing
| personal details about people. I think if the true extent
| of it were known most people would warmly embrace GDPR.
| But some people have lost a lot of money and they are
| pissed, but again I kind of feel there is a lot
| unscrupulousness involved so it's hard to feel sympathy.
|
| To a lesser extent, there are people that are concerned
| about "all the extra work" this entails, and the cost it
| adds to their bottom line. But this stuff is important
| nowadays. You really should be taking care of it.
|
| There is some scaremongering about small firms being
| blown out of the water for noncompliance, but really,
| unless you're doing something you shouldn't be doing you
| should be fine. The terms of GDPR though still not
| completely clearly specified are flexible and reasonable.
| The main thing is now, that you can't say you weren't
| aware of it.
| hdjdbtbgwjsn wrote:
| Let's hope the filesystem API does require user permission
| and that anyone building such a service follows the law.
|
| You know that GDPR doesn't require pop ups unless the
| service is doing something that isn't otherwise lawful?
| warpech wrote:
| There must be someone working on Emacs in Electron as we
| speak. I found some gist that's 2 years old: https://gist.g
| ithub.com/chrisdone/f874ac1c872c004d6ce9e3cb20...
| konjin wrote:
| I've ran emacs in cocalc's terminal emulator in the browser,
| non-ironically doing real work.
|
| It works pretty well.
| hosh wrote:
| This is something Richard Stallman has advocated for. Free
| software was not just about the availability of source code, but
| also about making sure software can function well on lower
| powered devices, lower bandwidth environment, or people who
| cannot use the same kind of interfaces.
|
| There was an essay discussing this ... but I do not recall it
| now.
| argb wrote:
| One of the nice things about the terminal is that things stay
| consistent for decades or more - people are not chasing fashion
| trends all the time, as is happening with the Web and graphical
| UIs.
|
| Nobody is being forced to use a particular style and color scheme
| and we don't have repeated redesigns which remove functionality
| for the sake of user friendliness or minimalism.
| wiz21c wrote:
| This. Plugins deliver value much more than graphical design. I
| also often tell myself that working in emacs is exhausting
| because it displays only valuable information => my brain works
| 100% of the time when I'm in front of it :-)
| vbsteven wrote:
| To me the main 2 primitives that make Emacs the extensible
| crossplatform app/platform/os/whatever you want to call it are
| these:
|
| * everything is a buffer, which in essence is a grid of text,
| that's the UI primitive, if you can render a grid of text you can
| probably build an emacs UI easily.
|
| * every action/command is an elisp function that operates on
| these buffers
|
| Combine these two and you can create pretty much anything. Code
| written in elisp that outputs buffers.
|
| An analogy with the modern web as a platform: elisp is the
| JavaScript and buffers are the DOM.
| jwr wrote:
| One begins to understand the advantages of this approach after
| 10-15 years or so.
|
| I feel that I am constantly being forced into new "UI paradigms",
| and it isn't always a change for the better. I started with DOS
| (Norton Commander, anyone? to this day there is no comparable
| tool), then Windows 3.0 and 3.1 (which was mostly garbage and I
| did not enjoy the UI at all). I then started using Linux and
| discovered Emacs. When I could afford the extra megabytes of
| memory, I would also run X11. As years went by, I switched to the
| Mac.
|
| These days I'm worried about what will be taken away from me,
| especially with Apple and their insistence on removing ports, the
| idiotic "Touch Bar" instead of function keys -- but also with
| Linux, where the shift away from X11 means no more remote
| applications, and the (increasingly broken) approach of gluing
| everything together into a big mudball means that if you're
| running anything that isn't "mainstream", things break and you
| are very much on your own.
|
| But I still have Emacs and I'm fairly confident that it will
| remain available and running on every platform I decide to switch
| to. And that I will be able to run it (with reduced
| functionality) on a text terminal.
| drsopp wrote:
| > Norton Commander, anyone? to this day there is no comparable
| tool
|
| Directory Opus. I've used it for nearly 30 years. First thing I
| install on Windows.
| muro wrote:
| Or total commander
| tluyben2 wrote:
| Or FAR.
| bandie91 wrote:
| yeah FAR Commander is an underappreciated pearl
| jjbinx007 wrote:
| The MS-DOS version of XTree Gold was the best piece of
| software I used in the early 90s.
| ungamedplayer wrote:
| So true.
| swiley wrote:
| I really honestly don't like X11. I've poked around in the
| source a couple times and it confuses and scares me. I love the
| idea of moving entirely to just one graphics API and keeping
| the server simple.
|
| Until wayland has decent performance though I don't think I'll
| ever switch. None of the apps I use are native (except possibly
| Firefox and _some_ EDA tools but only if gtk is set up right?)
|
| I thought my new phone would change my mind but surprisingly
| wayland is way way slower than X11 on it (running native gtk
| apps.)
|
| Do keep in mind though that modern X11 doesn't really do remote
| applications either and many aren't letting the server manage
| the scene graph /widgets anyway so remote rendering would be
| very slow.
| akho wrote:
| Network transparency has grown a lot more important for me
| over the last few years. It's not really network
| transparency, though, it's more vm/container transparency: if
| your dev environment is in a vm, and includes anything
| graphical, you need it. With WSL wayland is not even an
| option.
| cmiles74 wrote:
| Microsoft is actively working on adding Wayland support to
| WSL2.
|
| https://www.phoronix.com/scan.php?page=news_item&px=Microso
| f...
| pmoriarty wrote:
| _" I love the idea of moving entirely to just one graphics
| API and keeping the server simple"_
|
| I'm all for that, if and only if Wayland doesn't force me to
| give up what I consider to be important features of X.
|
| Apart from the aforementioned remote access, a post titled
| "Why I'm not going to switch to Wayland yet"[1] goes in to
| some requirements that I also find important:
|
| - Programmatic output configuration (xrandr, arandr, etc.)
|
| - CLI clipboard access (xsel, xclip)
|
| - Third party app launcher/window switcher (rofi, dmenu,
| albert, docky).
|
| - Clipboard managers (parcellite, klipper, Gpaste, clipman,
| etc.)
|
| - Third party screen shot/capture/share (shutter, OBS,
| ffmpeg, import, peek, scrot, VNC, etc.)
|
| - Color picker (gpick, gcolor3, kcolorchooser)
|
| - xdotool
|
| That post is a couple of years old now, and I've been told in
| other HN threads on Wayland that some of this stuff is being
| worked on now, but until it's all there and it is actually
| mature and full-featured, I would not willingly switch to
| Wayland.
|
| [1] - https://old.reddit.com/r/wayland/comments/85q78y/why_im
| _not_...
| voldacar wrote:
| Performance too. Wayland adds at least one extra frame of
| latency and so is unsuitable for gaming and similar
| scenarios where one program needs to monopolize the
| framebuffer
| pmoriarty wrote:
| Is that extra latency an inherent limitation of how
| Wayland is designed, or could future optimizations
| improve Wayland so that its performance is on par with X?
| seba_dos1 wrote:
| > Is that extra latency an inherent limitation of how
| Wayland is designed
|
| No, most Wayland compositors can already skip composition
| and pass the window contents directly to the screen in
| case of displaying just a single fullscreen window. There
| is also work ongoing on utilizing hardware planes when
| possible, to skip composition and improve performance in
| other cases as well - going beyond what was ever possible
| on X. Grandparent comment is simply wrong.
| voldacar wrote:
| Sorry but I have tried wayland multiple times (most
| recent ~12mo ago) and this has never been true in my
| experience. At least on my nvidia card. And the wayland
| people have been saying stuff like "oh we know better
| performance is possible, we just need to implement x, y,
| and z" for many years.
| seba_dos1 wrote:
| It depends on the used compositor. In the wlroots land,
| everything you mentioned is already possible.
| boogies wrote:
| > Norton Commander, anyone? to this day there is no comparable
| tool
|
| What's the problem with Midnight Commander and/or the 23 other
| programs at
| https://en.wikipedia.org/wiki/Norton_Commander#Norton_Comman...
| ?
| oblio wrote:
| Midnight Commander is not covered by the "nostalgia clause"
| :-)
| jwr wrote:
| Midnight Commander is nowhere near where Norton Commander was
| in terms of usability. Some of that is because of platform
| restrictions (terminal and keyboard access limitations) and
| some because of a difference in philosophy.
|
| Norton Commander was simple, but it got the simple things
| right.
| BeetleB wrote:
| While I don't like Midnight Commander's keybindings, do
| note that it can do quite a bit that Norton couldn't (e.g.
| ssh - incredibly handy).
|
| If you want a closer clone to Norton Commander, try FAR
| Manager: https://www.farmanager.com/ (Windows only)
| boogies wrote:
| I don't understand what you're talking about -- my terminal
| accesses as much from my keyboard as I've ever wanted it
| to, and everything I can imagine it wanting to short of
| flashing my (Num|Caps|Scroll) lock lights or something (and
| other terminals support more features than I even use, eg.
| image previews in ranger et. al.) Could you give an even
| more specific and concrete example?
| HeadsUpHigh wrote:
| What exactly was so useable about norton commander? I tried
| a split fm and I just found it cumbersome.
| roel_v wrote:
| "(Norton Commander, anyone? to this day there is no comparable
| tool)"
|
| If you're on Windows, try xyplorer. I can't remember anything
| NC did that xyplorer doesn't, and it does a lot more, too.
| hpfr wrote:
| The shift away from X11 means no more forwarding X11
| applications over ssh, which is slow at best and buggy and
| insecure at worst. A small price to pay for eliminating tearing
| and actually-secure screen locking. There are valid criticisms
| of the move to Wayland but I don't really think this is one of
| them; if you really need remote access to graphical
| applications you almost certainly should not be using X
| forwarding.
| kevin_thibedeau wrote:
| Tearing has nothing to do with network transparency and
| everything to do with crappy closed source drivers. Xorg on
| Windows doesn't have these problems nor does it on Linux with
| supported hardware.
| welterde wrote:
| Until recently there was no real alternative to it though. I
| recently learned about waypipe, so it should be possible to
| run wayland applications remotely over SSH at last (not sure
| how well it works/performs, but it exists).
|
| Granted there is also sixel and tek4014 support in xterm, but
| they are quite limited in what they can do and not too many
| applications have display frontends for that.
| ddingus wrote:
| Depending on how people work, it may be a very high price to
| pay.
|
| And screen tearing? Didn't SGI have that solved in the 90's?
| cat199 wrote:
| the vast number of threads supporting X11/remote and not
| caring about screen tearing in the least would seem to imply
| that your particular prioritization of features is not a
| commonly shared one.
| msla wrote:
| > The shift away from X11 means no more forwarding X11
| applications over ssh
|
| Which works fine and isn't a problem.
|
| > A small price to pay for eliminating tearing and actually-
| secure screen locking.
|
| Not necessarily. Not in all use cases.
| GuB-42 wrote:
| At work, we do X11 forwarding all the times. We have a wide
| variety of UNIX machines and we often need to run several
| graphical applications from different machines (not a remote
| desktop).
|
| X11 forwarding works with the latest Linux distros as well a
| 20+ year old systems running motif apps. Note: the old
| systems are now virtualized but we still need them, I work in
| the aeronautic industry and these are the time scales we are
| working with.
|
| I don't know of any replacement, at least not one with that
| level of adoption. Again, we really want to run graphical
| applications on a server, not a remote desktop.
|
| And BTW, things are getting troublesome. More and more Linux
| apps integrate accelerated web browser components and these
| tend not to play well with X11 forwarding.
|
| Love the irony of using a remote display to show an Electron
| app BTW.
| billfruit wrote:
| Not just Electron, even QT as well performs horrible over
| X11 forwarding in recent versions...
|
| Things seems to be going backwards in this area..
| louai wrote:
| When I was at Qt I spent a decent amount of time porting
| the native rendering engine from Qt4 to Qt5. It should be
| available and work relatively well. I have retired from
| the Qt project, but it looks like the code is still there
| in the repo. [1] You might need to tell the configure
| script to build it. To use it, set the
| QT_XCB_NATIVE_PAINTING environment variable.
|
| [1] https://code.qt.io/cgit/qt/qtbase.git/tree/src/plugin
| s/platf...
| kej wrote:
| Idle curiosity: what kind of applications are these remote
| systems running? You mentioned the aeronautic industry but
| I'm not familiar enough with it to imagine the kinds of
| things you would need to run remotely.
| GuB-42 wrote:
| A big one is a test tool for avionics running on Solaris.
| We are retiring it but some test procedures still require
| a specific version of it. And we don't want to update
| (and recertify) these procedures.
|
| We also have a homemade documentation system, again
| outdated but certified. I don't remember the system but
| it is definitely not a modern Linux. I think there is
| also a Fortran tool used to compute the lifespan of parts
| on the same system.
|
| A bit more recent, we have test benches made of several
| computers, mostly Linux desktops, each one deal with
| different things like real or simulated avionic hardware,
| they can be remote controlled but some apps run locally
| and have their own displays.
|
| We also have certified build chains running on specific
| systems, and while a GUI is typically not needed. It may
| be useful from time to time, mostly for debugging.
|
| We are in a process of modernizing all that stuff, but
| because of certification and the average lifespan of a
| program, it is a very slow process...
| freeone3000 wrote:
| You've listed disadvantages of an existing system but haven't
| listed an alternative. What should we be using for remote
| access to graphical applications?
| jwr wrote:
| > no more forwarding X11 applications over ssh, which is slow
| at best
|
| It was "slow" when I did it over 10Base2 Ethernet spanning an
| entire building. These days our CPUs are several orders of
| magnitude faster, and so are our networks. I don't need it to
| play the latest 3D games, I need it to display a user
| interface to an app that runs on a different machine. It's
| plenty fast enough.
| wazoox wrote:
| Yup. Today I have internet access faster than the LAN I
| used in the 90s and I routinely remotely run apps on my
| office desktop computer, reading my email, etc. from home.
| It works perfectly fine for anything not too graphically
| intensive, and it's way faster than starting a remote
| desktop session (which I use at times, too).
|
| On a local network, it's not significantly slower to run
| most apps through X11 forwarding than running them locally,
| and I use this extensively. The only daily application
| that's too slow is a browser, but Firefox (and before it,
| Mozilla did it too, and before it Netscape) automatically
| opens calls to the browser in the existing local window
| anyway (and there's always some pre-existing Firefox window
| open), even when running on some markedly different system
| (POSIX for the win).
|
| When I used MacOS more regularly, Quartz always was the
| first application I installed.
|
| When I see the comments from philistines unable to
| understand the obvious superiority of the one true Unix
| way, I always think of this Dilbert comic :
| https://dilbert.com/strip/1995-06-24
| znpy wrote:
| > The shift away from X11 means no more forwarding X11
| applications over ssh, which is slow at best and buggy and
| insecure at worst.
|
| Yes but sometimes you really need that and it's a life saver.
|
| EDIT: I just remembered about LTSP (Linux Terminal Server
| Project) which many schools used to lower the TCO of
| computing infrastructure. That relied heavily on Xorg's
| network transparency. I wonder what will happen to LTSP
| hpfr wrote:
| Honestly, I think people's reliance on X forwarding is just
| due to the fact that it happens to exist, not because they
| really need it. There's nothing like X forwarding on
| Windows to my knowledge. If X forwarding didn't exist
| people would have figured out how to do what they needed
| over SSH with text or when GUI's are irreplaceable
| sysadmins would have set up an actual remote desktop
| solution like on other modern operating systems.
| znpy wrote:
| You haven't worked in operations, have you?
| II2II wrote:
| The happens to exist bit turns out to be very important.
| I can login to a machine and run an X client without
| installing and configuring extra software on the server.
| If I am using a desktop with X installed (most *ix based
| systems), there is no extra software to install and
| configure on that end either. The worse case scenario is
| the necessity to install an X server on platforms like
| macOS and Windows.
|
| The same sort of thing can be said for Remote Desktop. If
| you're using a version of Windows that includes it, it is
| wonderful to use because it is just there.
|
| Which is better? It depends on how you're using it. I
| generally prefer Remote Desktop for my use case because
| it takes care of audio and it is easy to resume sessions.
| That being said, those features don't matter to me most
| of the time so X is just as useful.
| Spivak wrote:
| Right, the shift away from X doesn't mean the death of
| using GUI apps remotely, it just means moving to a Remote
| Desktop model instead of telling apps that their render
| target is your X server through a tunnel.
| donio wrote:
| What if I don't want a remote desktop though? 99% of the
| time I only want a the remote application I am interested
| in to seamlessly display on my screen, why do I have to
| bring along a full desktop?
|
| Seems like such a fundamental use case that should be
| made simple but is ignored (or made very difficult) by
| modern systems.
| freeone3000 wrote:
| What implementation of a remote desktop model currently
| exists for Wayland?
| Spivak wrote:
| The "big two" have implementations. Definitely not mature
| but it's getting there.
|
| https://wiki.gnome.org/Projects/Mutter/RemoteDesktop
|
| https://docs.kde.org/trunk5/en/kdenetwork/krfb/krfb-
| configur...
|
| You most likely won't see an implementation "for Wayland"
| because that's like asking for a websocket implementation
| "for HTTP" the actual compositors that _speak_ Wayland
| need to implement remote desktop capabilities and then
| expose an API for managing remote desktop sessions
| (org.freedesktop.portal.RemoteDesktop) to programs that
| want to leverage it.
| [deleted]
| spear wrote:
| I haven't tried it, but there's also this one for
| wlroots-based compositors (eg. sway):
| https://github.com/any1/wayvnc
| pmoriarty wrote:
| Could you flesh this out a bit? What is the official
| Wayland model for doing "Remote Desktop"?
| Spivak wrote:
| I hesitate to call it an official model but the short
| version of the current direction is that the compositor
| acts as the glue -- providing the final rendered scene
| and the final merged audio stream to the client over some
| protocol (like VNC but doesn't have to be) and providing
| inputs and events to itself and the client applications.
|
| How all of this works on the backend is a combination of
| PipeWire to multiplex video sources and PulseAudio to
| multiplex audio sources.
|
| There's nothing outright preventing something like X
| forwarding and https://mstoeckl.com/notes/gsoc/blog.html
| is a really cool project that makes it work.
|
| From that author:
|
| > The main difficulty in producing such a tool is that
| Wayland protocol messages primarily include control
| information, and the large data transfers of graphical
| applications are implemented through shared memory.
| waypipe must then identify and serialize changes to the
| shared memory buffers into messages to be transferred
| over a socket.
| oblio wrote:
| > The same sort of thing can be said for Remote Desktop.
| If you're using a version of Windows that includes it, it
| is wonderful to use because it is just there.
|
| Doesn't every Windows include it? I can't remember the
| last time I used a version of Windows that didn't have
| it, it must have been 20 years ago.
| II2II wrote:
| As far as I can tell, only the client ships with "Home"
| versions. You need to be running Windows Professional or
| Windows Server for the actual server.
| tokenrove wrote:
| No, it was the need for this on Windows that made Citrix
| all its money.
| jimbokun wrote:
| > There's nothing like X forwarding on Windows to my
| knowledge.
|
| Which is why the people who need this functionality run
| Linux, not Windows.
| toast0 wrote:
| > There's nothing like X forwarding on Windows to my
| knowledge.
|
| You can run an X server on Windows, there's a bunch to
| choose from. That lets you run an application on a remote
| unix system and show it on a Windows system in front of
| the user. It might be nice to run an application on a
| remote windows system, but that's always tied to
| expensive licenses; some of those systems sound like they
| could be pretty seamless (at least as seamless as remote
| X), but I don't have experience with them.
|
| Remote X has its problems, but it enables a lot of use
| cases with a minimum amount of hassle. Connect, run the
| application, close it when you're done. Other solutions
| with a remote desktop require starting that session
| somehow, and either leaving it running or shutting it
| down somehow. That can be useful if you want a long
| running session, but is more hassle if you don't.
| bsder wrote:
| > Honestly, I think people's reliance on X forwarding is
| just due to the fact that it happens to exist, not
| because they really need it.
|
| Visual Studio Code has "Remote Development" (which is
| under a Non-Open Source License(!)) because they don't
| have "X11 Forwarding".
|
| Think about the waste of implementing that code--in every
| application--rather than being able to do display
| forwarding.
| worik wrote:
| It was the original reason to invent X. Literally
| oblio wrote:
| And the adoption has been huge outside of Unix circles...
|
| MacOS doesn't use it, Windows doesn't use it. Even Linux
| is moving away from it. That's pretty damning for X as a
| technology during a time when even Windows has started to
| offer native curl and ssh, just saying.
| znpy wrote:
| Still there are xservers for both windows and Mac. How
| comes?
| mcguire wrote:
| Windows and MacOS have been (and are) based on the model
| of buying a copy of a piece of software for each piece of
| hardware. The idea of only buying a copy for one machine
| and running it somewhere else is difficult for that
| model.
|
| Ubiquitous networking is common in the Unix world, but
| much less prevalent in the Microsoft and Apple worlds.
| chipotle_coyote wrote:
| > Windows and MacOS have been (and are) based on the
| model of buying a copy of a piece of software for each
| piece of hardware.
|
| At least anecdotally, I'm not sure I can find a whole lot
| of supporting evidence for this -- the _vast_ majority of
| the commercial applications I use on a daily basis let
| you install them on any compatible system that you own.
| This isn 't just a byproduct of "well, they're not
| checking"; it's usually explicitly written in the
| license, it happens with programs that make you enter
| license codes they validate before running, and notably,
| it's very explicitly the model of the Mac App Store.
| Sometimes the license says only one copy of the program
| can be in use at a time without a site license, but for
| individual use that's generally fine in practice. (I
| haven't seen a program that's actually annoying enough to
| check for running copies of itself on a LAN and shut down
| if you're violating the license in decades at this point,
| although I'm sure they're still lurking out there in
| weird niches. It sounds like something Autodesk software
| would do.)
|
| Anyway -- maybe running programs remotely using the
| Xserver model never took off in the Mac world, even after
| OS X, because there _was_ no prohibition against just
| installing the software on multiple machines? In
| practice, it 's not something I've missed very often, I
| admit; while I sometimes like to edit text files
| remotely, that's not something that feels like it would
| really be improved by this model over using a local
| editor that can open files over the network. (Edited to
| note that I'm not suggesting there aren't still valid use
| cases for X11's server/client model! They're just not
| ones that have impacted me; if they did, I'd run XQuartz,
| which I don't love, but it'd probably get the job done.)
| thekyle wrote:
| Currently the only way to run GUI apps in WSL is x
| forwarding.
| jerf wrote:
| Gosh, the technology only lasted 36 years so far, and
| definitely has a few years left to go in it before it is
| "dead". What a striking condemnation that it only made it
| 40-ish years before being replaced.
| levosmetalo wrote:
| Yet, many people use windows and I still miss X
| forwarding. RDP and VNC are just not a replacement for
| being able to start 3 different programs on 3 different
| remote computers, and have them all sitting together on
| screen next to each other.
| u801e wrote:
| You should look into xrdp. It's like X forwarding, but
| with the ability to detach and reattach to a running
| application like screen or tmux.
| vladvasiliu wrote:
| Technically, RDP allows you to only launch one
| application as opposed to a whole desktop. They call that
| RemoteApp.
|
| That you can't just launch that on every machine you want
| (in particular non server installs) is more a limitation
| of Microsoft's licensing model than of the protocol
| itself.
|
| For me, from a usability point of view, RDP runs circles
| around the other solutions. I've used this fairly often
| during the lockdowns and even over a shitty DSL
| connection there was close to no lag.
| JonathonW wrote:
| You just got me to do a little digging... apparently, as
| of Windows 10, RemoteApp itself isn't restricted by
| licensing (at least, any more than Remote Desktop itself
| is)-- Windows 10 Pro (and Enterprise) can now host
| RemoteApp applications.
|
| The catch is that the UI to configure RemoteApp isn't
| present on client versions of Windows. It can be
| configured manually (by editing the registry then
| creating RDP files by hand), or there are open source
| tools that will do the work themselves:
| https://github.com/kimmknight/remoteapptool
|
| Somewhat outdated Microsoft docs on how to do this by
| hand: https://techcommunity.microsoft.com/t5/microsoft-
| security-an...
| MereInterest wrote:
| RDP works well if you want to connect to a remote
| machine, then work only on that machine for a significant
| amount of time. For me, I need to switch in and out of
| several different RDP sessions, which is a nightmare. Alt
| tab works either within a session if full screened, or
| within the local computer if not full screened. That
| means I need to also periodically use ctrl alt break to
| switch between full screen and windowed.
|
| In windowed mode, I can either have scrollbars to view a
| subsection, or I can scale the window. Doing the right
| thing, changing the size of the remote desktop when the
| local window is resized, isn't an option because that is
| set at connection time.
|
| Sometimes, for firewall reasons, I need to have needed
| RDP sessions. At this point, everything performs poorly,
| and I need to drag the overlayed blue bars off of each
| other, then interact with one or the other.
|
| I miss SSH, and want better support for it. Nested
| connections can be handled with SSH tunnels. Text
| connections are fast enough to do anything on the slowest
| of connections. If I need a GUI, I can open up a single
| window through X11, without additional setup with
| RemoteApp. Windows remote management through RDP is slow,
| clunky, error-prone, and inflexible by comparison.
| JonathonW wrote:
| > In windowed mode, I can either have scrollbars to view
| a subsection, or I can scale the window. Doing the right
| thing, changing the size of the remote desktop when the
| local window is resized, isn't an option because that is
| set at connection time.
|
| Side note: if the server is running Windows 8.1 or later
| (or the equivalent server versions, Server 2012 R2 or
| later), this isn't the case any more-- RDP sessions can
| be resized freely at any time.
|
| Naturally, the built-in RDP _client_ that comes with
| Windows doesn 't support this (because, of course, why
| would it?), but the UWP Remote Desktop app in the Windows
| Store does (as does the current Mac client).
| vladvasiliu wrote:
| My point was that RDP, the protocol, works very well and
| is able to adapt to network conditions.
|
| For your "nested session", the problem is that the
| adaptive nature of the protocol breaks down if the first
| hop has a very good connection to the destination.
| However, you're holding^w using it wrong. In this kind of
| scenario, I think MS recommends using a remote desktop
| gateway, which also works very well. I think one of the
| great advantages of RDP over ssh X forwarding is that it
| can use UDP.
|
| I definitely dislike how you have to have a Windows
| server installation and specific license to set up remote
| app, though. But I've filed this under "it's Microsoft,
| what can you expect?".
|
| I also find windows administration horrible, be it via
| remote desktop or keyboard plugged directly in the
| server. I grew up with Linux and macOS, so it was always
| a pain when I absolutely had to give someone a hand with
| something windows-related (my client has a bunch of
| Windows servers).
|
| But still, I'm not the kind to throw away the baby with
| the bathwater and to think that if I generally dislike
| and would avoid a company's products every single thing
| that they do is bad. I really wish Linux could have
| something similar to RDP in performance. It makes me sad
| when I vnc to a computer across the room and the thing
| lags more than RDP to some windows box in another
| country.
|
| edit: Regarding your having to work with several RDP
| sessions at the same time, it baffles me that the worst
| RDP client I have ever used is the windows one. I don't
| use windows on my machines, and the Linux client
| (Remmina) is absolutely a dream, especially when running
| on i3 (so there's no conflict with win / alt-tab / etc).
| Also, MS's mac client works very well and there's no key
| conflicts there either. You may want to look into the new
| Remote Desktop app on windows (not quite sure what it's
| called, it's on the windows store). It now supports
| window resizing and easier switching between sessions.
| JoBrad wrote:
| RemoteApp mode for RDP lets you interact with server-
| hosted apps like a client-hosted one. Also, I recall
| using apps with rdesktop in seamless mode, which worked
| pretty well.
|
| https://techcommunity.microsoft.com/t5/microsoft-
| security-an...
| jcelerier wrote:
| > There's nothing like X forwarding on Windows to my
| knowledge.
|
| if windows was enough for my needs I'd use it ?
| twic wrote:
| For terminal server use cases, there are things like VNC,
| SPICE, NX, etc. The X11/ssh thing is for when you want to
| run a mix of local and remote applications on a single
| desktop, which i think is pretty unusual these days.
| spear wrote:
| My remaining use case for X11 remote display doesn't
| quite fit in the VNC/etc. remote display paradigm. At
| work, I submit a job to queuing software that picks a
| server (based on load and resource requirements) from a
| pool on the internal network. The GUI for that job then
| pops up on my X11 display. I don't really care which
| server is running the job, and the job is just using
| $DISPLAY -- we don't even forward over ssh.
| Bnshsysjab wrote:
| I'm not an X hater but just know you've given that server
| access to your display socket which is effectively remote
| command execution.
|
| In most cases this could be solved with a good web user
| interface, but you can rest assured X won't be dead in
| the next 5-15 years, and you can use an intermediary box
| w/VNC if security is that much of a concern.
| sildur wrote:
| Wheelchair users are also pretty unusual and we don't go
| removing ramps from everywhere. I'm growing pretty tired
| of the "your use case is unusual, so fuck you" argument.
| jrm4 wrote:
| Despite having felt this way about so _many_ things, I
| have never seen this argument put so well and succinctly.
| I am going to be using this ALL THE TIME.
|
| Also, is this "sildur" of Minecraft shader fame? If so,
| much thanks, you've given me and my daughter many
| instances of "ooh pretty look at our house."
| morelisp wrote:
| Please do not so blithely invoke disability just because
| someone removed the feature you cared about. It sucks,
| but I promise you navigating the world in a wheelchair
| sucks a lot more.
|
| I don't want to speak for anyone in particular but X11
| was definitely not a friend to people who cared about
| a11y or l10n. It wore its origins in "80s MIT students"
| on its sleeve, for good and bad - and for non-English-
| speaking or disabled people, mostly bad.
| sildur wrote:
| Hey, this is not a contest about who had the crappiest
| life, and if it was, I can assure you that there are
| things in life that suck more than navigating the world
| in a wheelchair, and I'm not asking people to stop
| complaining about that just because they happened to me.
|
| Anyways, replace wheelchair users with pregnant women, or
| old people. Ramps help them too, and the argument is
| still valid.
| mcguire wrote:
| Supporting "unusual" cases is difficult and takes more
| effort. In the dog-eat-dog world of commercial
| development, to win you have to get the majority.
|
| Yes, I had that conversation with a friend.
| hyperdimension wrote:
| > "your use case is unusual, so fuck you"
|
| With love, The Chrome Team
| msla wrote:
| > which i think is pretty unusual these days.
|
| You have absolutely no basis for thinking this.
| welterde wrote:
| Is it really that unusual to do some data
| reduction/analysis on a beefy dedicated machine and
| wanting to look at the results right away using the same
| terminal instead of having to copy the result files or
| using a shared network file system? Even more important
| if it involves any graphical interactions.
|
| Sure, one could use a remote desktop to do same thing,
| but it's a bit annoying if all you want is one window
| from the remote machine.
| u801e wrote:
| > it's a bit annoying if all you want is one window from
| the remote machine.
|
| You should try xrdp. It can work like X forwarding
| (single application window forwarding), but you can also
| attach or detach from a running application (like screen
| or tmux for X).
| welterde wrote:
| That's only really an alternative for long-running
| applications since it still seems quite tedious to do if
| I am not missing anything (with modifying initial_program
| and all).
|
| Right now the workflow is simply ssh -X machine and then
| run some scripts that may or may not open interactive
| windows and then look at the result files using some
| graphical application. The same as if I was running it
| locally really (except on a beefy machine)..
| u801e wrote:
| I haven't tried all of the xpra options, but it would be
| a matter of starting an instance on the remote machine
| and then running the command to attach to it in the local
| machine.
|
| I suppose that you could start a terminal session on the
| remote machine and spawn GUI applications from that. I'm
| not sure if xpra allows for a terminal session directly
| from the command line though.
| chriswarbo wrote:
| > For terminal server use cases, there are things like
| VNC, SPICE, NX, etc.
|
| Great. Which of those, if any, do you think might be
| installed on the machines I want access to?
|
| Which of those, if any, do you think might be installed
| on the machines I want access from?
|
| What do you think are the odds that the intersection of
| those is non-empty?
| sz4kerto wrote:
| That means no Linux GUI apps on Windows + WSL2. Sounds like a
| niche, but I see many devs using Windows + WSL2 + X
| forwarding to develop under Linux.
| throwaway8941 wrote:
| I am not sure why desktop Linux experience should suffer to
| make WSL work? Microsoft has the wide pockets to make it
| work if they need to.
| my123 wrote:
| WSL2 has Wayland support upcoming (RDP-RAIL based, to
| integrate them to the regular desktop as separate windows)
| msla wrote:
| > where the shift away from X11 means no more remote
| applications
|
| Plus the death of all non-mainstream window managers, it seems.
|
| Realistically, I'm not moving away from X11 if it will create a
| UI regression for me. This means that unless I can get Window
| Maker and application forwarding, I'm not moving to Wayland,
| and I doubt I'm alone in this general feeling, even though
| other people use different window managers.
| HeadsUpHigh wrote:
| Define mainstream. Most tilling wm we all know have a wayland
| branch now. Some abandonware will probably be lost but
| nothing prevents anyone from re-implementing them.
| WanderPanda wrote:
| What is idiotic about the Touchbar that is not idiodic about
| function keys? You have to look at your keyboard to hit the
| function keys, why not use the glance for a visual feedback
| loop?
| iandinwoodie wrote:
| With regard to accessibility, a blind user can reliably use
| the function keys due to their physical separation. In
| contrast, the Touch Bar removes the separation of individual
| keys and may pose a challenge to sight restricted users.
| jcelerier wrote:
| > You have to look at your keyboard
|
| no
| Symbiote wrote:
| On any reasonable keyboard, the function keys are in groups
| of four (F1-F2-F3-F4 F5-F6-F7-F8 F9-F10-F11-F12), or
| sometimes three. It's not necessary to look to see where the
| keys are.
| brnt wrote:
| You're excluding pretty much every laptop there.
| lallysingh wrote:
| Thinkpads group their function keys. Who outside apple
| doesn't?
| pmontra wrote:
| My HP laptops don't. It's been ages since I used a non
| laptop keyboard and I forgot about grouping. It's a
| useful UX though.
| linspace wrote:
| I don't find laptop keyboards reasonable. They are a last
| resort.
| foobarian wrote:
| I wish the external Mac keyboard had grouped function keys.
| I wish I didn't have to use an external keyboard in the
| first place, but touchbar is even worse. In my case
| debugging stuff becomes annoying with ungrouped keys
| because it's easy to mix up step into / step over /
| continue.
| jwr wrote:
| I definitely did not look at the function keys when working
| with software that I use a lot.
|
| As an example, these days, when routing PCB tracks in KiCad,
| when I need to switch to a different board layer, I need to
| look away from screen and at the keyboard in order to hit the
| right function key. I also have to pray that the TouchBar
| will register my press, as it often likes to go to "sleep". I
| don't know if it did register my press until I look back at
| my screen and check if I'm on the right layer.
|
| Having to look away from the screen when you're in the middle
| of routing a track on a complex multi-layer board is _really_
| annoying.
|
| Plus, it's difficult to keep a hand near the function keys
| without accidentally getting near one of the touchbar areas,
| which results in a keypress, which results in a zoom-out for
| me (F1).
|
| It's an abysmal user experience and a huge regression.
| ch_123 wrote:
| On a physical keyboard, the gaps and contours of the keys
| give your fingers an indication that they are pressing a
| single key, as opposed to a blank space or the gaps between
| two keys. This, combined with the grouping, makes it viable
| to use function keys without looking at them.
| codegladiator wrote:
| > You have to look at your keyboard to hit the function keys
|
| No, you are doing it wrong. Never need to see keyboard except
| when using touchbar thanks to no feedback.
| zwirbl wrote:
| I barely, if ever, have to look at the function keys to hit
| right one
| sevensor wrote:
| > the shift away from X11 means no more remote applications
|
| This is a long, gentle transition. Although I believe it to be
| possible, I still haven't ever run a pure-Wayland system. Most
| graphical applications for Linux still need an X server, and
| Wayland provides one. Under sway, I can still run ssh -Y and
| start X clients on the host I'm connected to. This works just
| fine. It's going to be years until Wayland kills off X11 on the
| wire, and alternatives are already under development. I worry
| about a lot of things, but this isn't one of them.
| chillfox wrote:
| Doesn't Midnight Commander do pretty much everything Norton
| Commander did?
| tartoran wrote:
| Yes it does but the idea was that UI/UX has been in decline
| antonios wrote:
| Sometime I also get in a pessimistic mood. I really would like
| to convince myself that X11 is not going away in the next
| decades.
| Bnshsysjab wrote:
| Esoteric hardware won't work first, then maybe browsers. I'd
| estimate 15 years.
|
| I was not using pulse or systemd until early this year,
| having used Linux since 2008 thats a pretty decent lifespan.
| It was finally required for Bluetooth headphones which
| weren't really around in the age of alsa.
| fierarul wrote:
| I thought it will be a criticism how everything seems _off_ with
| the Emacs GUI from the copy-paste to the font rendering to the
| way scrolling is done, etc. I 'd guess it managed to be so cross-
| platform by re-implementing everything, kinda like Java Swing but
| with less care for design.
|
| Now I understand how having a scriptable and text-based
| foundation would help with accessibility, just Emacs wins no UI
| contest.
| hpfr wrote:
| I don't know if I'd call it _re_ implementation when the
| original Emacs is older than DOS and GNU Emacs, still
| maintained today, is older than Windows (1985). Emacs's
| keybindings, font rendering, and scrolling were just as valid
| then as any other approach. Let's at least avoid comparisons to
| Swing :).
|
| You can bind copy-and-paste as well as any other text wrangling
| functionality to whatever you want and there are ways to make
| it behave like other platforms without too much difficulty. But
| why hamstring Emacs' copy and paste by limiting it to the
| simplistic version we're used to when you can copy to multiple
| registers and have a searchable history of copied text?
|
| Font rendering uses Harfbuzz in the latest version and is quite
| good in my opinion, there's even color emojis. Scrolling is
| certainly better than any terminal emulator I've used, although
| there's no smooth scrolling. I guess everything is _off_ if you
| 're comparing it to a browser, but modern browsers aren't
| exactly paragons of UX either. But if you're comparing
| prettiness options like these, yeah, Emacs loses to VS Code.
| All Microsoft had to do was build a text editor on top of a
| browser engine to get those features :). I'd say Emacs is more
| extensible, though. Lisp machines and all
| mrob wrote:
| Scrolling is broken from the average user's point of view
| because it moves the cursor. If you're typing something, and
| then scroll to reference some other part of the document, you
| can't just start typing again after finding the information
| you need. You have to manually restore the cursor position or
| you'll end up typing in the wrong place. Unlike pretty much
| every other text editor, Emacs's concept of a cursor is
| something that lives in screen space, not document space.
| It's stuck in the VT100 hardware cursor paradigm.
| fierarul wrote:
| I understand, but 35 years have passed, no need to stick to
| the original implementation that long.
|
| I'm a super basic user and nowadays basically have Emacs open
| all day just for org-mode. Nothing else.
|
| To me it seems a terrible text editor and has an UI that's
| foreign on macOS and Ubuntu. It's unclear to me under what
| OS/Window manager/etc Emacs fits right at home. It seems out
| of this world.
|
| I can imagine there may be some configuration that would fix
| some of these problems, but I just use Emacs as it comes out
| of the box.
| Jtsummers wrote:
| A reason to stick so closely to the original model is that
| it has lasted 35 years. There are few other programs that
| have lasted as long without feeling an urgency to change
| with the times, and mostly by the base system being
| similarly stubborn about changing or by being incredibly
| simple.
|
| The fact that it's, essentially, the same on every OS I use
| it on is another selling point. I bring my .emacs file and
| make minor tweaks for different OSes (due to where
| files/programs are if absolute paths or relative paths in
| the user home directory are different). It always works the
| same once I've made those small changes (and they are
| small, and once done my Windows .emacs is good on any
| Windows box). Again, there are few other programs like
| this. At a minimum, you often end up with subtly different
| keybindings (macOS using the command key, Windows using
| control, and Linux using control or alt) and subtly
| different layouts that break workflow and habit.
| newen wrote:
| Yep! Main reason I use emacs is that I can use just about
| the same workflow when I'm programming in python, C++,
| etc. in different environments like windows gui, windows
| WSL, linux GUI, linux terminal, remoting through ssh, ssh
| into docker container, etc.
| taeric wrote:
| For those of us that have used emacs for a long time, it is
| the other items that feel foreign. And, quite frankly, I'm
| not sure I'm missing anything from the others.
|
| It is annoying that Apple has a command key that I have
| mapped as Meta. Since that means if I try to copy something
| in Firefox, closed tab. That said, why are the keyboard
| shortcuts in so many other applications so destructive? And
| crappy? Browsers could be forgiven if they were just for
| viewing, but you edit in them a lot nowadays, such that the
| browser not having easily customized keyboard bindings is a
| laughable insult for user centric design.
|
| (Do they even still pretend to support user stylesheets
| anymore?)
| eatmygodetia wrote:
| In Emacs's defence, it didn't reimplement everything so mich as
| implement it first. When there's very little prior work to go
| on, often parts of the design won't be great, and then it
| becomes hard to move away from them.
| fierarul wrote:
| Interesting how somebody else claimed about the same thing.
|
| Yes, but eons have passed, things are different. Should
| everything else mold to Emacs or should Emacs fit into the
| overall OS/window manager/etc.
|
| Maybe Emacs really is supposed to be an OS. I'm now wondering
| if there's a way to boot straight into Emacs. Clearly we
| could have a slimmer kernel /loader for that. :-)
| rpdillon wrote:
| I think a lot of folks value having their apps 'fit into'
| their OS. For me, I see the constant churn in desktop OS
| patterns as tiring and essentially useless. Emacs provides
| a wonderfully consistent interface no matter where I run
| it. I can see how it seems foreign to others, but it is
| consistent. For me, that's a fantastic trade.
| bartread wrote:
| This is somewhat oblique to the content of the post but "special"
| is about right. "Unnecessarily obtuse", particularly from a
| contemporary perspective, might be a less kind way to describe
| it. I could say the same about the documentation which, frankly,
| is not great at making you immediately productive. It's written
| like an academic treastise, not a tutorial for a piece of
| software that exists to help you get stuff done and where
| learning the software is not an end in itself.
|
| I've recently started making a relatively determined attempt to
| become proficient with emacs due to increasing frustration at
| poor performance from both VSCode and Sublime Text when working
| with larger projects and, I'm not going to lie, it's hard going.
|
| Take something as basic as working with multiple windows. Emacs
| has concepts of buffers, windows, and frames, but windows and
| frames are diametrically opposite in concept to windows and
| frames in client side web development.
|
| That's not too difficult to grasp but, say you're in dired, and
| you want to open a file in a new OS window (in emacs-speak this
| would be a frame). You'd think you could just move the caret over
| the filename and hit some key combination to open that file in
| another window (sorry, I mean frame). Possibly you can but the
| nearest I've managed to get so far is (from memory) C-x 5 f,
| which brings up the minibuffer prefilled with the pathname of the
| directory you're browsing in dired, and then you have to start
| typing the filename (which, granted, will autocomplete), which
| seems somewhat redundant, and only then can you open the file.
|
| It's also full of things to trip you up, like the key bindings
| for switching to another (emacs) window and killing a buffer -
| both fairly common operations - being far too similar and easy to
| confuse for a newbie.
|
| It just seems so deliberately contrary, but I'm hoping the
| investment will pay dividends given time and persistence (this
| is, however, approximately my fourth or fifth attempt in 20 years
| to learn emacs, so we'll see).
| morelisp wrote:
| These are reasonable criticisms of Emacs's interface, but the
| topic of the post is interfaces in Emacs, not Emacs's
| interface. Sublime has no comparison point.
| jimmyvalmer wrote:
| > like the key bindings for switching ... being far too similar
| and easy to confuse for a newbie.
|
| You must be referring to `C-x b` vs. `C-x C-b`. I remember
| getting apoplectic over this in 1995. I remain aggrieved to
| this day.
| morelisp wrote:
| I suspect this is actually `C-x k` vs. `C-x o`.
|
| My recommendation would be to bind `C-x C-k` to `kill-this-
| buffer` and unbind `C-x k`, or bind `C-x C-o` to a hydra that
| lets you repeat `C-o` i.e. hold down ctrl and repeat `o`, to
| cycle windows. Or both.
|
| Alternate, try out `ace-window`.
|
| I'm not sure about "too easy to confuse for a newbie." These
| kind of mistakes only happen when you are switching buffers
| rapidly without checking prompts, and newbies won't be doing
| that. And the default mnemonics are (unlike much of Emacs)
| good for these tasks. So rebinding doesn't feel like a big
| ask.
|
| (Agreed `C-x b` should be removed imo.)
| fennecfoxen wrote:
| As a long time emacs user, I can confirm that emacs is
| terrible... and everything else out there is deficient. I can
| write custom code (ew, elisp) to determine how to switch
| between buffers (test buffer and code under test) and I can run
| my tests and find operations and the like in a first class
| buffer and a dozen things like that which are just incredibly
| painful in other editors.
|
| Also I hit Cx-c by mistake thrice a week.
| joosters wrote:
| ;;; Make it more difficult to kill emacs accidentally
| (defun my-kill-emacs () "Confirm before 'save-
| buffers-kill-emacs'." (interactive) (if
| (y-or-n-p "Really kill Emacs? ") (save-buffers-
| kill-emacs) (message "Aborted") )
| ) (global-set-key "\C-x\C-c" 'my-kill-emacs)
| jimmyvalmer wrote:
| Dude, `M-x custom-set-variable RET confirm-kill-emacs RET
| TAB`
| morelisp wrote:
| Or just unbind it, you won't typo `M-x kill-emacs`...
| TeMPOraL wrote:
| > _Also I hit Cx-c by mistake thrice a week._
|
| Unbind it. Problem solved. That's what I do with my clumsy
| fingers.
| MarcScott wrote:
| Run Emacs as a server. You can kill the client accidentally,
| then just load another client instantly and carry on from
| where you left off.
| momentoftop wrote:
| Exactly.
|
| My emacs uptimes (M-x emacs-uptime) are generally the same
| as my machine's uptime, which is typically months. Emacs is
| one of the most rock-solid pieces of software I have
| running.
|
| It's also great for remote. I have emacs daemons running
| continuously on my remote boxes. To start work on those
| machines, I log in and start my emacs client. I've never
| had a need for things like "screen".
| [deleted]
| rthomas6 wrote:
| That sounds like something you could add to dired mode and bind
| to a key without too much trouble. It's my understanding that
| you sort of have to start molding emacs to your particular
| style, and that the defaults are kind of bad. I have switching
| windows bound to ctrl+direction. Super easy and convenient.
|
| Also some of the plugins augment Emacs so much that some people
| see them as part of emacs rather than an add-on. I don't use
| dired; I use helm/ivy.
|
| I am having good luck with Doom Emacs. You may want to check it
| out, especially if you are used to the Vim keybindings. It
| provides a lot of extra functionality out of the box.
| pmoriarty wrote:
| Yes, the Emacs _defaults_ tend to be pretty awful, but you can
| configure it your liking, given enough time and effort.
|
| I've put in a ton of time and effort configuring Emacs (after
| spending about 25 years on vim and vi), and though it took a
| long time, the results have been well worth it for me.
|
| There's no way I would give that up and go to something with
| more reasonable defaults but which is much more limited in
| customization capabilities and which lacks a Lisp ecosystem
| which has been improved by thousands of people for many
| decades.
| oblio wrote:
| > There's no way I would give that up and go to something
| with more reasonable defaults but which is much more limited
| in customization capabilities and which lacks a Lisp
| ecosystem which has been improved by thousands of people for
| many decades.
|
| You do know that there is a middle ground, right? __Emacs
| __itself could come with reasonable defaults.
|
| You'd still be able to customize it (after all, you probably
| did) and all the newbies wouldn't have to read about 80's
| computing arcana to figure out how to split a window.
| antonvs wrote:
| > Emacs itself could come with reasonable defaults.
|
| You could try Spacemacs. I've only just started seriously
| getting into Emacs, and have found Spacemacs to be a big
| help.
| pmoriarty wrote:
| Oh, I fully agree, and some people have done just this with
| packages like Spacemacs, Doom, Prelude, and probably some
| others.
|
| I've never tried any of them myself, because I already have
| Emacs configured to my liking, but reasonable defaults is
| what these packages aim at.
| morelisp wrote:
| > You do know that there is a middle ground, right? Emacs
| itself could come with reasonable defaults...
|
| That's the rub though. Emacs could change its defaults,
| plan large deprecation and rename, rewrite all its
| documentation and write even more to help migrate. And 20
| years from now someone will be whining about the 2010 "web
| arcana" embedded in some interface and command set.
|
| > newbies wouldn't have to read about 80's computing arcana
|
| Because here's the perfect example. Emacs isn't 80s
| computing arcana, it's _60s computing arcana_ largely
| encoded into it in the 70s. In the early 90s when I first
| picked it up there was a similar push to encode the arcana
| from the 80s instead. "Pick the standard keybinds that
| make sense!" they said. Like Shift-Delete for cut and
| Shift-Insert for paste!
|
| ... oh, that's probably not what you want today either, is
| it?
|
| So here's your options:
|
| - Churn the defaults and everyone's configs every 15ish
| years
|
| - Document as best you can the defaults and how to change
| them, and make the best UIs you can at the time, in fashion
| or not. (Kill rings are still better than cut buffers!)
|
| Universal "reasonable defaults" don't exist in a tool meant
| to last 50 years in an ecosystem of fads.
| paledot wrote:
| I know you're angling for option 2 here, but honestly,
| default churn still sounds like the best choice. Don't
| like it? Have a one-line config Defaults=1980 and let
| people like my father-in-law keep using their Shift-
| Delete, while the rest of us can enjoy an editor that's
| at least usable out of the box.
| morelisp wrote:
| > Have a one-line config Defaults=1980
|
| You could bundle up maybe a dozen keybinds like this, but
| it's not going to scale to even address the complaints we
| see in this thread (window vs. frame terminology), let
| alone the full gamut of mainstream Emacs configuration.
| And it's a massive amount of work to do. And it's not
| fundamentally different than just picking an Emacs-
| distribution-du-jour (Spacemacs, Doom Emacs) right now.
|
| If that's what you want, my view is you might as well be
| churning whole editors. And truthfully, if that's what
| you want, do it! But I want a kill ring, and
| buffer/window management that doesn't presuppose multiple
| frames, and my mode line. I don't want to waste critical
| keybindings like C-x or C-c on weaksauce single-buffered
| text operations. And yeah, there's a lot of things I
| would change if I was doing "Emacs from scratch", but on
| the other hand _I don 't need to_ because I can change
| them now, and easily share them, and still take advantage
| of what everyone else is doing.
| oblio wrote:
| Yeah, but here's the thing. Recently geneticists had to
| start renaming genes because Excel would parse the gene
| names as dates. And Excel is supposed to be "software".
|
| At a certain critical mass, soft-ware stops being soft.
| Other things bend to accommodate the soft-ware.
|
| You know what's even harder than hard soft-ware? Social
| mores and expectations. For example, such as those formed
| by millions upon millions of spreadsheet users.
|
| Or billions and billions of web users.
|
| So, where am I going with this? Emacs has encoded some
| norms from the 60s when the tech community was probably
| 0.1% of what it is now, and when large numbers of those
| 0.1% people were technically adept and very flexible in
| adopting new things.
|
| "Web arcana" has been assimilated by a million more
| applications and systems than those systems that inspired
| Emacs had. It has also been assimilated by billions (!)
| of people.
|
| 60s arcana is not equivalent to web arcana, for this
| reason.
| morelisp wrote:
| Yeah, sorry, you're right. Now is definitely the end of
| history and time to rewrite everything into the dominant
| paradigm.
| oblio wrote:
| So it's better if the end of history was the 60s, when
| there were 10000 programmers, in total, worldwide?
|
| When we hadn't even standardized the keyboard layout and
| the "display" was a dot matrix printer? When there was no
| networking to speak of?
|
| How does that make more sense?
| morelisp wrote:
| It's not like Emacs doesn't deprecate or change anything.
| It's not like its feature set froze in the 60s. And it's
| not like it doesn't document how to turn on CUA bindings,
| or Windows or OS X-compatible bindings, or have special
| builds or distributions where these are defaults. If you
| want C-c, C-x, C-v, you can have it. Today. In many
| distributions, by default. The keybindings are not the
| main issue _either way_ in how "usable" a tool like
| Emacs is. If you think they are, you're missing the
| entire point of how Emacs is special regarding UIs.
|
| I can throw the bullshit rhetoric right back at you: You
| think absolutely nothing was better in the 60s? That
| modern IDEs lost _nothing_ compared to the tools of 10,
| 20, 30, 40, 50 years ago? Why isn 't Emacs like Borland?
| Why isn't Emacs like Visual Studio? Why isn't Emacs like
| Eclipse? Why isn't it like Mosaic, QuickBasic,
| Coldfusion? There are reasonable answers to these
| questions, and they'll tell you also why Emacs isn't like
| whatever you want to compare it to today.
|
| Maybe Emacs already occupies a local maximum, "a middle
| ground", taking some of the best compatible ideas from
| the times it's been alive in. Vi another local maximum.
| IntelliJ or VSCode, others - but emphasis then on _local_
| , and I hope you like retraining.
|
| The problem is not keybindings or what decade its
| metaphors exist in, it's people see Magit or Org or
| whatever high-level fully-integrated tool, and want _just
| that_. And you don 't understand _that_ is an outcome of
| a path that really does require the whole philosophy to
| ingest into your workflow. But you don 't want to learn
| the philosophy, you just want to 10x crush git or
| whatever. No, it won't happen. There's all sorts of
| dumbass metaphors in in this thread now, but in the end
| Emacs is garden, not a hammer or a workbench or an
| oscilloscope or whatever. You get out proportion to what
| you put in, you work with it not just use it.
|
| Shit's just gonna get faster. You need to find ways to
| live with it, not copy it. Talk to your fathers-in-law.
| agumonkey wrote:
| It might be the right timing for an ergonomic revamp. As much
| as I like the old habits, I agree that some parts really need
| to be rebalanced. And emacs is moving faster these days so
| maybe a mutation can happen
|
| A slightly nicer embedded docs. They were great for 80s way of
| life, but it could use a slightly more reply (to stay in the
| context of a live editor / lisp machine). Maybe a text demo
| system.. after all you could script a demo of workflows in
| elisp for newcomers to see rapidly.
|
| - hydras could be extremely useful for newcomers for instance
| (and I'm no fan, but it cuts the chase by a factor of 1000)
|
| - ace-jump
|
| I don't know, I'm just suggesting
| pmoriarty wrote:
| I'm a _huge_ , _huge_ , _huuuge_ fan of hydras.
|
| They're a big part of what make Emacs useable for me.
|
| I have set up hydras for pretty much every major mode I use
| (except magit, which kind of has its own hydra-like menu
| system).
|
| Because of hydras, I don't have to remember all the arcane
| keyboard shortcuts these modes have bound by default, and
| don't have to look up how to run a function that's not bound
| at all.
|
| All I have to remember is one keyboard shortcut which I have
| configured to bring up a hydra in every mode, and it'll show
| me a menu of everything I can do in that mode.
|
| This is really fantastic, has revolutionized the way I use
| Emacs, and has made it 10 times as useable for me as it was
| before I used hydra.
| mercer wrote:
| Whether it's 'hydras' or something similar, the single
| thing that got me into properly using Emacs was this
| feature in Spacemacs. For almost any situation, I can
| either pull up the spacebar 'global' menu, or a context-
| specific quick-menu. Discoverability has been insanely
| good, and I keep finding new tricks just by exploring the
| various menus that pop up.
|
| I wish 'UI autocomplete' like this was a standard feature
| of operating systems. GUI's aside, how nice would it be to
| run a CLI command with some flag that allows you to explore
| the various options and string them together, rather than
| reading the manpage and searching for whatever flag you
| might want to use?
| agumonkey wrote:
| more generally auto-completion helps users go combinatorial
| on new territory
| tzs wrote:
| I think that tools like Emacs and Vim are aimed at people who
| recognize that very often over the next few decades of their
| careers they are going to have a need for powerful, complex,
| flexible text editing, and so even if they have no interest in
| learning the software for its own sake its worth putting in the
| up front effort because it will pay off later.
|
| For a lot of tools, both in software and other fields, there
| are three different classes of user.
|
| 1. Those with fairly straightforward tasks that they just want
| to get done.
|
| 2. Those who mostly have staightforward tasks, but occasionally
| have something a bit more complex but not too complex.
|
| 3. Those that need to handle everything from simple to
| ridiculously complicated.
|
| Take electrical testing tools for example. For a lot of people
| a simple battery tester is all they need (class #1). If you
| want to test a battery and have never used a battery tester
| before, it will either be obvious what to do, or a glance at
| the instructions will tell you.
|
| Some people need a bit more on occasion, and for them we have a
| class #2 tool, the multimeter [1]. You can still pretty easily
| test a battery with one, but the first time you probably will
| have to spend a minute or two in the manual, learning what
| voltage setting you want (the V with the ~ over it, or the V
| with the dashed and non-dashed line over it?) and which holes
| to plug the probes into.
|
| Some people need a lot more. They have a class #3 tool, the
| oscilloscope [2]. You can check a battery with an oscilloscope,
| but if it is your first time you are going to spend a lot of
| time in the manual before you get there.
|
| Emacs and Vim are class #3 tools.
|
| [1]
| https://en.wikipedia.org/wiki/Multimeter#/media/File:Fluke87...
|
| [2] https://www.tequipment.net/Rigol/MSO1104Z-KIT/Mixed-
| Signal-O...
| oblio wrote:
| The thing is, you need AutoCAD (or equivalent) to be a
| productive engineer in certain fields.
|
| You don't need Emacs or Vim to be an incredibly successful
| software engineer. It's actually the opposite, Emacs and Vim
| users are a minority among successful software engineers.
|
| So they are only a specific kind of power tool.
|
| More than that, they can't even handle the "ridiculously
| complicated". Common examples are trying to use them with
| projects containing millions of lines of Java or C# code.
| tzs wrote:
| Yes, you don't need Emacs or Vim to be a successful
| software engineer. If you are good enough you don't need
| anything more than a basic editor, a compiler/interpreter
| for a language, and libraries for that language that let it
| talk to whatever you need to do I/O with.
|
| But using a more advanced editor can make it easier. If you
| are going to be doing software engineering for a few
| decades all the times you have to do some repetitive task
| in a simple editor that would have been quicker in a more
| powerful editor adds up.
| oblio wrote:
| You've misunderstood me. I'm not arguing that Notepad +
| msc.exe are more powerful than Emacs or Vim.
|
| I'm arguing that IntelliJ/Visual Studio are more powerful
| than Emacs or Vim.
|
| The Emacs and Vim architectures are antiquated and the
| volume of effort put into developing them (and their
| ecosystems) are outclassed by modern IDEs, especially for
| languages that scale to large numbers of developers
| working together (Java, C#). Emacs and Vim are poor man's
| IDEs compared to actual IDEs for these cases.
|
| Emacs and Vim are mostly popular amongst C/C++
| developers, where the ecosystems are generally baroque,
| forced by the need to integrate with embedded systems
| with limited toolchains or with libraries/frameworks that
| are very limited, and amongst developers working with
| dynamic languages, where you generally have small teams.
| Or large teams and a ton of headaches :-)
| nikki93 wrote:
| For some people, using a computer is meant to be a
| pleasurable experience, and Vim / Emacs let them build
| this up in ways that personally align with their tastes.
| I've spent years in Visual Studio (not Code -- the older
| one, but also a year or so in Code), and IntelliJ, and
| Vim, and Emacs with Spacemacs. They all felt good for
| when I used them. Like which genre of music I happen to
| be into at the time.
|
| At the end of the day, it's kind of just shifting around
| based on what feels good. It feels similar to sitting in
| a cafe for a bit, but some times working from home, and
| some times in the mountains.
|
| But there's no need to put people down by saying stuff
| like "poor man's" IMO. And if you're restricted to what
| makes C# and Java tolerable, that's a small space.
| There's a lot more stuff out there.
|
| And programming is not as simple as "make decisions that
| optimize your engineering throughput" IMO. Otherwise
| gardening would be agriculture, right? Both are important
| in their own ways.
|
| In any case Vim's terminal emulation and asyncness these
| days along with coc.nvim brings it back on track IMO.
| There was a period where it was behind.
|
| I do think it depends a ton on language. The best
| experience in Vim is editing Go, I think. And then TS and
| C++ have been a close second. Lisps are not great, Emacs
| tends to better. For Java and C# it's definitely IDEs.
| VSCode is also fine for a lot of langs, in a more out of
| the box way. Cursive is also good I hear for Clojures. If
| you need to move between a lot of langs, the only IDEs
| that pan out are IntelliJ mostly, unless you count Code
| as one. But Vim and Emacs have the best multiwindow and
| multi buffer management. And the best git integration for
| patch by patch staging, for sure.
|
| And ofc for ObjC and Swift it tends to be Xcode. If
| you're really into Freepascal then Lazarus etc.
| Smalltalks are their own thing ... it keeps going on.
|
| If all you want to do is work in languages that were 90s
| attempts at doing GC'd VMs that are C++ inspired, to
| deliver internal non-userfacing applets to businesses, by
| all means use a Java or C# IDE.
| pmoriarty wrote:
| _" The Emacs and Vim ... are outclassed by modern IDE"_
|
| Outclassed in what way?
|
| Have you looked at LSP[1] and its support in Emacs[2],
| for instance?
|
| That's not to mention things like SLIME and paredit for
| Lispy languages, or the integration of the rest of the
| Emacs ecosystem in to your development environment, the
| ability to develop and configure all these development
| tools in Lisp instead of being forced to switch to some
| other language, etc.
|
| [1] - https://github.com/Microsoft/language-server-
| protocol/
|
| [2] - https://github.com/emacs-lsp/lsp-mode/
| oblio wrote:
| If you're not a professional Lisp developer, an
| environment extensible in Lisp is not a plus :-)
| MarcScott wrote:
| I'm not a C/C++ developer, but I spend most of my time in
| Emacs. Most of my development time is spent in Python,
| and Emacs serves as an excellent IDE for the language.
|
| However, that in itself is not my reason for preferring
| Emacs. It's also my markdown editor, often my file
| manager, my PDF viewer, my image viewer, my git
| interface, IRC client, email client... I could go on, but
| I'll stop there.
|
| Emacs is not and has never been an IDE, it's a highly
| versatile and extensible text-editor. You can't compare
| apples and oranges.
| [deleted]
| iterativ wrote:
| Well, let's see what software engineers use Emacs.
|
| Donald Knuth. Author of "the art of computer programming"
| and many contributions in computer science.
|
| Linus Torvalds. Original author of Linux (the most widely
| used kernel) & git (most widely distributed version
| control). In fact, he wrote his own version of emacs. He
| doesn't do much, if at all, coding now.
|
| Joe Armstrong. Author of Erlang.
|
| Guido van Rossum. Author of Python.
|
| Yukihiro Matsumoto. Author of Ruby.
|
| Rich Hickey. Author of Clojure.
|
| Andrei Alexandrescu. Author of D.
|
| Xavier Leroy. Author of OCaml.
|
| Michael Widenius. Author of MySQL & MariaDB.
|
| Guy Steele. Co-author of Scheme.
|
| Stephen Wolfram. Physicist, computer scientist & author
| of Mathematica.
|
| Peter Norvig. Research director at Google & well known
| Lisper.
|
| RMS. Well, original author of GCC, Emacs & the GNU
| system.
|
| All of them, apparently, don't require one of those
| "powerful" IDEs.
| TAForObvReasons wrote:
| Those developers by and large were active in software
| development before the creation of VSCode or IntelliJ. If
| you've already invested time and energy to learning the
| ins and outs of one tool, the hurdle to switch is large.
|
| VSCode would need to be 10x better for the seasoned
| veterans to justify switching. If it were only 2x better,
| arguably the investment would not be worth it, but it
| doesn't change the fact that VSCode would be 2x better
| than emacs.
| taeric wrote:
| Your complaint on the documentation reads oddly. You do know
| there is a tutorial included, right? And, it mostly does what
| you are asking. You can even try to speed run through it
| occasionally to make sure you still remember everything.
|
| The straight documentation on the parts? I'm curious how you
| would want those to be otherwise. They mostly read like the
| user's manual of a car. Fairly technical, but at a very high
| level. With occasional tips on how to use the part you are
| reading about.
| bartread wrote:
| > Your complaint on the documentation reads oddly. You do
| know there is a tutorial included, right? And, it mostly does
| what you are asking. You can even try to speed run through it
| occasionally to make sure you still remember everything.
|
| But that's the point: it doesn't.
|
| Maybe it does if you want to invest a few hours getting up
| and running, but I don't have that kind of time: I need to
| get stuff done _now_.
|
| I'm not saying I'm too important, or my time is too valuable,
| or any nonsense like that: I just don't have time to invest
| in spending a day or even half a day learning what are in
| contemporary times the basics of using a _text editor_.
|
| And that's the problem with the tutorial: it doesn't start
| with a quick two page summary of what, in contemporary times,
| are considered the basics of using a text editor. It's long-
| winded and academic and takes way too long to get to the
| point on any and all relevant topics.
|
| The result is that I have to (and not just me: anybody used
| to non-emacs - or perhaps vim - editors) invest non-
| insignificant amounts of time learning basic functionality
| that works in a common way across most other editors and IDEs
| (IDEA, Visual Studio, Rider, VS Code, Sublime, TextPad, XCode
| - heck, even Microsoft Word) and learn completely different
| paradigms for all of it just because emacs is "special". It's
| pretty frustrating because for me the editor is not the
| point. I'm only looking at emacs at all because a lot of
| editors, once you get to a project of any size, become
| absolute CPU hogs and it starts to get in the way. But given
| the grief I may come to the conclusion that a better
| investment is just to buy a faster laptop.
|
| I'm totally happy to be proven, or to prove myself, wrong,
| but right now the whole emacs ecosystem seems unnecessarily,
| contrarily alien simply for the sake of it.
|
| There also seems to be a strong lack of empathy for users.
| Few influential people seem to have given any consideration
| as to how to make the software accessible for newcomers. In
| this day and age that's almost laughable.
| taeric wrote:
| I'm not sure I follow. As a power user of computers for
| years, I would be a liar if I said __any __of those
| programs were "quick to get running." Speaking as someone
| that is getting my kids up and running with computers.
| Training and tutorial running are the norm and should be.
| Expecting proficiency in anything with less than a few
| hours is an exercise in pain.
|
| If you want there to be a new tutorial, I don't know anyone
| that would be against it. The "game to learn vim" was
| popular a few times. Same basic idea. I don't know what I
| would make of it, right off. There are some great typing
| modes that let you quickly type the current document and
| score you on speed/accuracy. Moving to other windows is
| tough in any option. But I could imagine a fun game made to
| navigate through. (Though, with helm, most navigations are
| autocompletes nowadays.)
|
| I hate that it feels like a lack of empathy for you. But I
| really don't see the ecosystem as alien. Any more than I
| see the python ecosystem as alien, or the java, or
| javascript, browsers, etc. They are all just a little
| different. But all have some rough analogs. And all feel
| like they are just trying to shield users from complicated
| problems. Many times making things more complicated in the
| process.
| bartread wrote:
| What I'm trying to say is this: I can pick up almost any
| text editor and be productive immediately, even if I've
| never used that editor before. That is manifestly not
| true with emacs (or vim). Getting back to my point about
| the emacs documentation, it is simply not optimised to
| get me productive in the way I can be with other editors
| anything like as quickly as I can become productive with
| those editors.
|
| Of course you're right, when you start using computers
| everything is hard, but many applications have common
| conventions, even across different authoring
| organisations and people, and even across different
| operating systems.
|
| Emacs has conventions but there's next to no commonality
| with other applications within the same broad class, so
| you are starting from scratch. Emacs makes no affordances
| for people who are already used to using other software,
| whereas much other software _does_ make those
| affordances, and so is easier to pick up as a result.
|
| Maybe you don't see that as a problem, and that's fine,
| but for me - and, I suspect, quite a lot of other people
| - the steep learning curve feels unnecessary and,
| frankly, bizarre to the point of being out of place.
|
| There's no reason Emacs couldn't be easier to use.
| There's no reason the documentation couldn't be written
| to accelerate proficiency with the application. But
| neither of these things is the case, and it's a
| deliberate choice. As I've already implied, it seems
| almost obtuse just for the sake of it.
| taeric wrote:
| And my point is that you have plenty of other training in
| those editors you are ignoring. Not out of malice, but
| because it is second nature. You have done a ton of
| training on them already.
|
| I know it will sound contrived, but when I sit at a
| coworker's desk using sublime, I'm literally lost on how
| to navigate. I don't even know how to get the editor to
| list all open buffers. IDEA? I mean, I know it has the
| functions, but it is a search every time I have to try
| them. (Again at someone else's computer.)
|
| I could think it was just my emacs knowledge not working,
| but I see the same hiccups from folks moving from each.
| So it isn't just me.
|
| Are there affordances that are common? Yeah, but many
| have changed, and not all over long timeframes. Worse,
| many are different from Windows to Mac to Linux. There is
| a good argument for adopting what is native to where you
| are, but the rise of browsers has shown that to not be
| that important, ironically.
|
| I do see it as a problem, if it is keeping folks from
| using computers. Or, if it makes folks build things that
| can't be used from emacs. That said, I don't see it as an
| insult or as a problem if you choose to use something
| else.
|
| Again, for many of us, emacs __is __easy to use. For many
| of us, the documentation __is __written in a way to
| accelerate proficiency. I would love more documentation
| or affordances to help. So not stonewalling, but I
| caution against the attitude that what is there is bad.
|
| And I get it, I think. I have recently tried to plunge
| into Blender and Gimp. Holy crap do I feel punished for
| mistakes there all too easily. :(
| BeetleB wrote:
| > Your complaint on the documentation reads oddly. You do
| know there is a tutorial included, right?
|
| The tutorial covers only the very basics. It's less than 1%
| of the material in the manual. And I definitely agree with
| him - most Emacs manuals (whether for Emacs or for some
| packages) are written more as reference manuals than
| something to learn from. If you're lucky some of them will
| have a tutorial in the beginning.
| taeric wrote:
| But this was my point. Most of the documentation is a
| reference manual. Is why I referenced the user's manual for
| a car. You will not be using that to learn how to drive a
| car. Nor will you use it to learn how to build or maintain
| one, really.
|
| So, to that end, what makes the manual of
| VSCode/Atom/Sublime good? Since there is an implicit
| comparison to those as a good comparison.
| II2II wrote:
| Emacs is an old piece of software that has historical baggage.
| I would imagine that the window and frame terminology is a
| product of their time: the use of window would have made sense
| prior to X. Another term had to be introduced when X support
| came along.
|
| It is also a piece of software where changing the terminology
| is very difficult. While a non-scriptable program could simply
| change the documentation and be done with it, Emacs would
| either have to change the names of exposed functions (breaking
| compatibility) or have one set of terminology for scripting and
| another while discussing the user interface.
|
| Perhaps better choices could have been made, but the issue is
| non-trivial.
| BeetleB wrote:
| Agree on the referenciness of the manuals. They are not the
| best way to learn when new to it (or to a package).
|
| C-x 4 is a prefix for "other window".
|
| C-x 5 is a prefix for "other frame"
|
| (It's OK if you did not know this. I was a heavy Emacs user for
| a decade before I learned this).
|
| For your particular problem, you may want to look into Hydra.
| Setting up your own Hydra for dired-mode will involve some
| basic Elisp, but not much - you can just copy/paste from
| elsewhere. However, you may need to write an Elisp function for
| your particular situation, and then have the Hydra call that
| function.
|
| Similar to another commenter, once I learned hydra, I create my
| own menus for every new mode I want to use. Much easier than
| memorizing keybindings, and you can put your own custom stuff
| there.
|
| Also, I rebound F6 to switching windows. C-x o would drive me
| nuts. F6 is the standard in Windows/DOS, so that's what I was
| used to (I still use it in Outlook for work to avoid the
| mouse).
| tiborsaas wrote:
| At what project size did you notice performance issues? I use
| VSCode as my daily workhorse and I can believe without a doubt
| that it can get into trouble if I forget to gitignore
| node_modules :) But putting ST on the same page got me curious.
|
| I'm on the other end of the spectrum, I'm betting that
| computers will become fast enough with time to run these
| bloated editors that were designed to be usable.
| john4532452 wrote:
| > I seldomly hear this property mentioned by anyone else, so even
| if it scratches OT-ness
|
| What does "OT-ness" stand for ?
| CKN23-ARIN wrote:
| Off-topicness
| john4532452 wrote:
| I could not find that in urban dictionary or google
| results.Is this commonly used in free software or open
| software mailing lists or did you just guessed it ?
| detaro wrote:
| OT for "Off-topic" is a very common abbreviation online,
| yes.
| I_complete_me wrote:
| Is there a common abbreviation online for On-topic? If
| so, what is it?
| CGamesPlay wrote:
| Presumably "off-topic-ness"
___________________________________________________________________
(page generated 2020-09-10 23:01 UTC)