[HN Gopher] Emacs Modernization: Simple Changes Emacs Should Ado...
___________________________________________________________________
Emacs Modernization: Simple Changes Emacs Should Adopt (2006)
Author : AJRF
Score : 92 points
Date : 2021-08-28 09:16 UTC (13 hours ago)
(HTM) web link (ergoemacs.org)
(TXT) w3m dump (ergoemacs.org)
| bitwize wrote:
| Emacs has already been rewritten as a completely modern
| application in a modern programming language (JavaScript). It's
| called Visual Studio Code. We can now safely deprecate the
| original.
| sullyj3 wrote:
| Title could probably use a (2006)
| mcc1ane wrote:
| or (2015)
| mleonhard wrote:
| I've been using Emacs for 17 years. I want every change suggested
| in the article, especially 'redo'. A few additional ones:
|
| - After pressing Alt-X, show a list of recently used commands.
| Allow moving between them with the up/down keys. Show a docs pane
| which explains what the command does, how to use it, and has an
| example. For new users, pre-populate the recently-used commands
| list with common commands. This is like the auto-complete
| "intellisense" function that saves me so much time when using
| JetBrains & VSCode.
|
| - When opening/saving a file and typing the path, automatically
| show the directory contents and hi-light entries that match the
| path. Show recently opened files and directories in bold. Scroll
| the listing with PGUP/PGDN/mouse-wheel. I often use emacs to open
| log files which contain long unique prefixes which are error-
| prone to type. Allow using the mouse & arrows keys to select the
| file.
|
| - Auto-save and auto-format. I love this mode when editing Rust
| code with CLion. It gives me something I've wanted for a long
| time: to write code without thinking about formatting. There's
| probably already some complicated way to get this to work in
| Emacs. Ideally, emacs would check if appropriate tools (rustfmt)
| are installed and make it just work automatically.
|
| - Allow using ENTER to add newlines to a search-replace command.
| I can rarely remember whether it's CTRL-Q, CTRL-J, or both and
| frequently make mistakes.
|
| - Allow writing Emacs commands in popular languages like Python 3
| or JavaScript. Include a tutorial for each supported language.
| The lisp bigots will be angry about this.
|
| - Create a public issue tracker for emacs, ideally on GitHub.
| This will let users help each other and participate in setting
| issue priorities. Include a code of conduct. Do not auto-lock old
| issues like Flutter Team does. Old issues are findable by search
| engines. Workarounds and error messages change over time. When
| issues are unlocked, users will add comments like "The fix now
| requires change X. Here's the new command that worked for me ..."
| Locking old issues saves the dev team some effort but destroys a
| lot of the utility for users.
| tgbugs wrote:
| > especially 'redo'
|
| undo-redo is in emacs-28 now, though not the default behavior.
|
| > Allow writing Emacs commands in popular languages like Python
| 3 or JavaScript.
|
| For js see https://github.com/emacs-ng/emacs-ng
|
| Integrating additional runtimes into the Emacs core, especially
| ones that also have a single main thread are likely to be a
| complete nightmare. There are already insane and undebugable
| performance issues with things that run on the main graphics
| event loop or on timers.
|
| If elisp can somehow be made multi-threaded there might be a
| chance. However, there is SO much elisp code that assumes
| synchronous ordered execution that will break in subtle and
| unexpected ways when that restriction is lifted I expect it
| will take even longer than the transition to lexical scoping
| (and that is just in the core). I would love to be wrong
| though.
|
| With respect to Python, the cpython runtime and semantics for
| redefinition are likely even more nighmareish because it is so
| easy for classes and instances to become out of sync and you
| wind up having to restart the whole environment just to clear
| out the bad state or risk creeping insanity. Also the churn in
| the Python ecosystem is likely far too high for Emacs to be
| able to maintain. So there are both technical and process
| mismatches. You could always run python in a separate process
| and use message passing though. Work to support LSP certainly
| paves the way for it, and elpy has fully interop with python as
| well, so you could use that machinery to operate on buffers in
| languages beyond python. So if all this is possible why isn't
| anyone doing it?
| daly wrote:
| I've been using emacs for 35+ years. It does everything I need to
| do. If it doesn't, it has lisp. And then it does.
|
| I only use fundamental-mode.
|
| Emacs, like lisp, is "clay for the mind". You can adapt it to any
| task easily.
| greggman3 wrote:
| I've been using programmable editors for 35+ years. They all do
| everything emacs does and more and are just as adaptable.
| agumonkey wrote:
| and emacs is already so packed.. even after rtfm 3 times
| thoroughly (or so I thought) I learn there's something else I
| didn't know about
|
| maybe the only thing I'd like to see more center, is a blend of
| crdt / live-notebook in simple buffers. This could be very
| benefitial to newcomers too.. you can pair tutor, enjoy things
| in teams right inside your window
| Scarbutt wrote:
| _I only use fundamental-mode._
|
| Why? do you use emacs for programming (besides elisp)?
| brlewis wrote:
| I'd be interested to see an exhaustive list of computer programs
| that are as old as emacs that people still complain about today.
| mark_l_watson wrote:
| I bought the Emacs Manual from Richard Stallman and friends, so
| many years ago, and I still rely on it, especially with Mosh+tmux
| for working in remote servers.
|
| Off topic, but I have been trying to figure out why Emacs startup
| got faster and editing seems snappier on an M1 MacBook. The M1 is
| generally faster but not enough to account for the difference.
| Maybe some engineers at Apple in some way optimized the Emacs
| that ships with macOS? The speed up has increased my use of Emacs
| locally on my laptop.
|
| EDIT: I love Common Lisp, but probably it is not worth the effort
| to replace Emacs Lisp.
| agigao wrote:
| Emacs did speed-up on M1? When/How? :D
|
| Which Emacs distribution are you using?
| mark_l_watson wrote:
| I just noticed that I am now running the Home Brew built for
| M1 install of Emacs: /opt/homebrew/bin/emacs
|
| It is really nice to be able to have Brew installs for Intel
| (Rossetta) and M1 side by side (in different root
| directories).
| tsuujin wrote:
| I agree with basically everything in this article. Emacs needs
| new users, and to get them we need to reduce the barriers and
| user friction. In fact, increasing adoption through reducing user
| friction is a very well known topic in software design; this
| shouldn't really be a topic for debate.
|
| But god help you if you suggest changing Emacs to conform with
| modern standards. I still maintain that the worst part of Emacs
| is the vocal minority of evangelicals in the community.
|
| I've been using Emacs as a daily driver for years, but it also
| took me years to adopt fully because the mental overhead of
| learning new terms for things I already knew drove me to ask for
| help from the community, and the community routinely made me not
| want to be any part of it.
|
| It sucks, because most of the community is fine, but the very
| loud voices of a minority group of purists who have built their
| identities around being "Emacs people" are incredibly
| aggravating.
| toolslive wrote:
| what a lot of people fail to realise is that emacs key bindings
| *are* consistent with other tools. Take a look at bash (or the
| korn shell): begin of line (C-a); end of line (C-e); kill rest of
| line (C-k). Emacs key bindings are the same.
|
| Not everybody grew up using windows.
| yakubin wrote:
| C-w doesn't work the same. In bash it will delete the word
| before the cursor. In Emacs it will cut selection (which is
| always there, just sometimes invisible and then C-w does
| unpredictable things).
| kmstout wrote:
| And then there's the experience of using Jupyter's terminals,
| where you reflexively C-w to delete the last word, but the
| tab closes. You then reopen the terminal, which has helpfully
| retained its state--including the word you just tried to
| delete.
|
| Alas.
| bodhiandpysics1 wrote:
| note unix shells allow you to choose your keybindings! It's
| just as common for people to use vi keys as emacs
| oblio wrote:
| It's not. I don't read have numbers but my anecdata (of
| probably hundreds of people across several continents) is
| that maybe 1% of users switch to vi mode and most revert
| after a while.
| still_grokking wrote:
| That's because GNU ReadLine uses Emacs key-bindings. It's not
| the other way around.
| toolslive wrote:
| I think these key bindings go (at least) back to csh.
| ByteJockey wrote:
| csh's initial release was 2 years after emacs.
| Veen wrote:
| > Not everybody grew up using windows.
|
| No, but almost everybody did. Very few people grew up using
| korn, readline, and emacs.
| G3rn0ti wrote:
| But I'd argue learning basic Emacs key bindings gives you the
| benefit of becoming better on any Linux terminal. Going
| through the tutorial does not take much time.
|
| I think the author is right about the arcane terminology
| (,,meta key", ,,buffer", ,,window", ,,frame" etc) that should
| be changed and, too, configuring CUA Mode by default to help
| newbies a bit. I personally prefer using ,,control c" and
| ,,control v" for copy and pasting. Mind you if you like to
| use keyboard macros, you can't use CUA mode copy/cut/paste
| bindings in them. That confused me quite a bit as beginner.
| However, I don't think I ever got confused by Emacs undo
| system. It basically does the same thing as in other editors,
| just the key binding is different.
| Veen wrote:
| > It basically does the same thing as in other editors,
| just the key binding is different
|
| I think it's the way redo works that's confusing, not
| necessarily undo itself. The way you have to undo, then use
| another command so the undos themselves become undoable,
| and redo by undoing the previous undos. That's not how most
| editors work.
| Decabytes wrote:
| I posted a link here to a Reddit post that said "if you could
| change one thing about emacs what would it be?" It had almost 200
| comments. Some answers definitely touched on these points. But
| for the most part, what Emacs users wanted was for the Gnu Emacs
| maintainers to do was...
|
| 1. Switch out Elisp for a Common Lisp or Scheme
|
| 2. Update the way Emacs Ui Core so it used standard GTK or
| something better. (The current implementation uses a lot of ugly
| hacks to support a subset of GTK)
|
| 3. Ability to scroll without bringing point along with me so I
| can quickly check something off screen then just continue typing
| where I left off.
|
| 4. Improve threading so that things like TRAMP didn't freeze when
| you were connecting
|
| 5. Fast/Arbitrary graphics support
|
| I think for most Emacs users it's a performance thing. Though the
| improvements to the GUI code would go a long way to making it
| easier to make Emacs be more user friendly.
|
| In terms of this article. I think all of this is possible in a
| separate distribution of Emacs right now. Emacs will never turn
| on most of these things by default. But maybe if a version of
| Emacs that makes these changes becomes wildly popular, the
| current maintainers would be more amenable to it.
|
| https://old.reddit.com/r/emacs/comments/padv22/if_you_could_...
| creamytaco wrote:
| I've been using Emacs for more than 20 years, these are all
| (for the most part) non-issues, brought up by folks who either
| are new to Emacs or never read the documentation / dived below
| the surface.
|
| 1. Emacs Lisp is great (for the problem domain), exists and
| works. Common Lisp could work but then given how close Emacs
| Lisp and CL are, there's no clear benefit, especially with
| Emacs getting native compilation. Scheme was proposed, some POC
| code written and failed because nobody was interested. It
| doesn't fit and fragmenting one of Emacs's greatest strengths
| (consistent ecosystem of working Emacs Lisp code) is a terrible
| idea.
|
| 2. The Emacs UI core is completely toolkit-agnostic. It doesn't
| use GTK on Windows. It doesn't use GTK on macOS. You can run
| _graphical_ Emacs without GTK or any toolkit whatsoever on
| Linux, and not lose any functionality. Therefore what you write
| makes no sense (ugly hacks to support a subset of GTK).
|
| 3. There are multiple ways to do this. Read up on setting the
| mark.
|
| 4. Threading has nothing to do with TRAMP freezing, bad
| configuration does. TRAMP documentation (does anyone that bring
| up these points ever read it?) has multiple sections on
| improving performance. Check "SSH control master" and
| "Improving performance of asynchronous remote processes".
|
| 5. SVG support is already there and more is on the pipeline.
|
| What I've noticed during my 40 year computing career is that
| folks get lazier and lazier. Few read manuals / documentation
| anymore but most are quick to jump to superficial conclusions
| without any substantial time investment in trying to figure
| things out. Spoonfed knowledge is the order of the day, and the
| folks doing the spooning are usually not far from clueless
| themselves (the blind leading the blind). This leads to
| generational gaps and rapid propagation of erroneous ideas
| amidst the newbie masses, very similar to what you laid out.
|
| Emacs mastery requires commitment and time investment in order
| to understand (at least) the basic models and the trade-offs
| involved. If that doesn't take place, one can start going down
| paths that are entirely irrelevant ("Emacs needs threads so
| that it doesn't freeze!", "Let's use JavaScript so we can do
| non-blocking IO!", "Let's rewrite Emacs in Rust!")
| chriswarbo wrote:
| The fact there are known workarounds for certain problems
| shouldn't prevent us improving and fixing the underlying
| causes (in a step-by-step, backwards-compatible way).
|
| With that said, I'd rather not see Emacs go all-in on threads
| or GTK, since they generally feel like WorseIsBetter anti-
| patterns:
|
| - GTK 2 seemed OK, but unusable for me due to the 'display
| disconnection' bug. GTK 3 is full of red flags: a constantly
| moving target, little thought given to third-party
| applications, pretty much killed off third-party theming,
| etc.
|
| - Threading is famously error-prone, which is completely
| unnecessary for high-level languages like Emacs Lisp. Co-
| routines, async/await macros, delimited continuations; even
| an actor model would all seem like better fits.
| CJefferson wrote:
| 2. What you wrote makes no sense. If linking to gtk provides
| nothing at all, why is the code even there?
|
| 3. Why is the default config for TRAMP so bad? It isn't
| spoonfeeding for everyone to not want to reconfigure it.
| creamytaco wrote:
| 2. It makes perfect sense if you actually learn how Emacs
| works. It provides superficial elements like GTK-look-and-
| feel (scrollbars, menubars). Most Emacs experts disable all
| of these anyway, thus nothing of value is lost. On the
| other hand, toolkit-less Emacs tends to be a lot more
| stable. That was definitely the case for GTK since it had
| well-known bugs that the GTK developers refused to fix that
| would crash Emacs. I suggest you compile graphical Emacs on
| Linux without any toolkit (or with Athena/Lucid/Motif) to
| see for yourself.
|
| 3. Because there are trade-offs involved and the (informed)
| user should be responsible for enabling them.
| lytefm wrote:
| > What I've noticed in my 40 year computing career is that
| folks get lazier and lazier. Few read manuals / documentation
| anymore but most are quick to jump to superficial conclusions
| without any substantial time investment in trying to figure
| things out.
|
| The problem is being used to software that "just works".
|
| I've tried out to figure out how to to stuff with Emacs
| multiple times, but apart from sticking with org-mode for
| some use cases, I always have up after a while.
|
| I don't see why I should "master Emacs" when there are
| usually better tools for any given task.
| creamytaco wrote:
| Emacs is a tool with an enormous set of available
| functionality that has been continuously developed for 35
| years. Moreover, its major strength is its programmable and
| nearly infinitely-extensible nature.
|
| And yet, it does "just work", from the moment you first run
| it -no previous experience needed- it does present you with
| a familiar "editor skin". It does offer you an interactive
| tutorial. It does come with comprehensive offline
| documentation. It does come with the best interactive
| querying and documentation capabilities of any software
| system in wide-use today.
|
| So, taking all of that into account, when you say "just
| works", I read "I don't want to spend any time whatsoever
| to learn 35 years of features and a software system that is
| by far the most user-empowering in existence today". Your
| loss.
| pjmlp wrote:
| For me Emacs was only something I used when I couldn't have
| access to XEmacs, which was the best workaround for the lack of
| IDEs in 1990's UNIX.
|
| Nowadays I just use IDEs.
| clircle wrote:
| Hopefully pure-gtk branch will be merged prior to Emacs 28,
| addressing (2).
|
| On (1), I'm not much of a programmer, but Emacs-lisp fine, so
| I'm not sure what benefit changing languages could bring.
| b3morales wrote:
| There are a good number of Emacs users who also use a Lisp
| dialect such as Scheme for their day-to-day work. Emacs Lisp
| has enough small, slightly strange differences from more
| mainstream Lisps that I can imagine that being kind of
| frustrating.
|
| For myself I think that Emacs Lisp is a pretty good language
| _for configuring a text editor_. A lot of its warts actually
| make it easy to use in that context, in my opinion.
| Personally I wouldn 't mind moving closer to Scheme or CL.
| Though I wouldn't want to lose "special" variables (with
| dynamic binding) no matter what happens -- they're a key tool
| in tweaking behavior to get it just how you want. But for
| people who are trying to build packages, especially large
| ones on the order of Org or Magit, I can see having a more,
| let's say production code oriented language, being a nice
| prospect.
| slightwinder wrote:
| Is the pure-gtk-branch really working on switching the
| underlying UI-architecture? Or just removing the hacks for
| X11 and moving them to gtk?
| clircle wrote:
| pure-gtk doesn't decouple ui process from editor, if that's
| what you're asking about.
| slightwinder wrote:
| No, I mean emacs was designed for terminals. The whole
| GUI is build ontop of this and is suffering from it. Is
| pure-gtk changing this and decouple from the terminal-
| design or still working with it, replicating the same
| hacks just in a different GUI?
| clircle wrote:
| Sorry, I just don't understand. I don't really use
| terminals except to do a system update. Is there a
| specific issue?
| slightwinder wrote:
| Terminals work with characters, meaning, lines, columns,
| fontsize. GUIs usually are working with pixel, meaning
| x/y-coordinates and free sizes.
|
| In case of emacs this means there is a bunch of hacks to
| translate pixel-coordinates to line/column-coordinates.
| This often are working well enouhg, but sometimes not.
| For example, with my emacs there is always a free space
| at the bottom when maximising the window, Resizing the
| window also works in terms of lines, not pixels.
| Positioning of completion-dialogs is linked to chars, not
| the pixel-coordinates of a the word which in certain
| cases get's ugly.
|
| It's overall not what I would call a hard issue, but
| still ugly. But it also kinda limits what you could do
| with Emacs in GUI-world. As Emacs has no understanding of
| z-axis, there are overlapping widgets and free-
| positioning of elements outside the text-flow.
|
| An additionally, it seems the too many laysers and
| additional complexity has some speed-impact in GUIs which
| the terminal-version has not.
| chriswarbo wrote:
| Would this pure-gtk branch avoid GTK's famous X11 connection
| bug? https://gitlab.gnome.org/GNOME/gtk/-/issues/221
|
| Every few years I'm tempted to try the GTK version of Emacs,
| but it doesn't take long before this bites me and I go back
| to Lucid!
| Finnucane wrote:
| Yes, if you ask people who know how to use emacs what they
| would change, the answer is going to be _very_ different from
| the answer you'd get asking people who have tried to use emacs
| and gave up.
|
| The documentation does really suck. The terminology makes no
| sense to users not used to it. It does not explain that to make
| this into a functional system, some configuration needs to be
| done. It is terrible out-of-the-box. 'Because this is how rms
| did it 45 years ago' is not really a good excuse.
| Abhinav2000 wrote:
| The documentation does _not_ suck. It it literally the most
| well documented software in existence, a reason for which it
| has been used for many different things outside its original
| purpose of text editing.
|
| Yes, it may not be for everyone. But just say that, that it
| uses certain conventions that are likely outdated for a
| reasonable set of the population. But you can't say the
| documentation sucks when you have the below:
|
| https://www.gnu.org/software/emacs/manual/html_node/emacs/in.
| ..
|
| https://www.gnu.org/software/emacs/manual/html_node/elisp/in.
| ..
| phist_mcgee wrote:
| `You can also type Meta characters using two-character
| sequences starting with ESC. Thus, you can enter M-a by
| typing ESC a. You can enter C-M-a (holding down both Ctrl
| and Alt, then pressing a) by typing ESC C-a. Unlike Meta,
| ESC is entered as a separate character. You don't hold down
| ESC while typing the next character; instead, press ESC and
| release it, then enter the next character. This feature is
| useful on certain text terminals where the Meta key does
| not function reliably.`
|
| Taken from: https://www.gnu.org/software/emacs/manual/html_
| node/emacs/Us...
|
| I'm really not sure that this counts as 'well documented'.
| cge wrote:
| That documentation is _thorough_ does not mean that it is
| _good_.
|
| If anything, one might argue that Emacs documentation being
| so extensive while buing built around idiosyncratic
| conventions makes it worse, not better, for many cases: it
| means it is even harder for people to actually find
| relevant parts of the documentation.
| otabdeveloper4 wrote:
| Emacs itself is idiosyncractic. Being cute and using
| "standard" terminology would just confuse users.
| otabdeveloper4 wrote:
| Emacs is great out-of-the-box.
|
| Really its only problem is the annoying bugs you frequently
| run into. (Emacs Lisp really isn't meant for programming
| large, stable systems.)
| Bost wrote:
| > Emacs is great out-of-the-box.
|
| Sure. And because the out-of-the-box is so great: 1. people
| actually create emacs distributions(!) like spacemacs,
| doom-emacs, etc. 2. the emacs wiki has
| https://www.emacswiki.org/emacs/DotEmacsBankruptcy
| mlang23 wrote:
| Emacs is the self-documenting editor for a reason. I always
| found the documentation very good. I submit that every
| sufficiently complex system will need some terminology
| specific to the system the user will have to learn. Not
| wanting to do so if a form of lazyness that the developers
| cant really do anything about.
| oblio wrote:
| Dude, Emacs had its own terminology for text editing, the
| rest of the world moved on, another terminology won.
|
| If Emacs would be solving protein folding, I'd maybe
| understand the need for unique terminology, but this is
| just unnecessary smugness.
|
| At this point Emacs is only doing a few user facing things
| which are unique, and I'm not even sure about those.
| 908B64B197 wrote:
| > 3. Ability to scroll without bringing point along with me so
| I can quickly check something off screen then just continue
| typing where I left off.
|
| https://ftp.gnu.org/old-gnu/Manuals/emacs-20.7/html_chapter/...
|
| > 4. Improve threading so that things like TRAMP didn't freeze
| when you were connecting
|
| You really want this, as well as the low level functions to
| support TRAMP to be written in C.
|
| https://code.visualstudio.com/docs/remote/remote-overview
| rusk wrote:
| > 3. Ability to scroll without bringing point
|
| You could probably do this with a transparent indirect buffer
| with a special "scroll only" mode that reverts once you start
| typing again.
| vvillena wrote:
| Well, yes, it's Emacs, we can probably do anything we can
| imagine, but that's beside the point. This particular
| behavior is stupidly annoying for both newbies and old-
| timers.
|
| Even if Emacs works internally with the concept of a
| "point" that is always set to a position in the visible
| part of a window, text editors evolved over time to adopt
| the concept of a "cursor" that always stays in place unless
| the user moves it. It's about time Emacs adopts the concept
| too, and sets a well-thought default behavior for it.
| JadeNB wrote:
| > Even if Emacs works internally with the concept of a
| "point" that is always set to a position in the visible
| part of a window, text editors evolved over time to adopt
| the concept of a "cursor" that always stays in place
| unless the user moves it. It's about time Emacs adopts
| the concept too, and sets a well-thought default behavior
| for it.
|
| I'm a Vim user, not an Emacs user, which likely means my
| opinion isn't worth much; but I think the point I'm about
| to make is the same.
|
| I use Vim because I like its user interaction paradigm.
| It is badly out of sync with modern text-editing
| paradigms, and that's fine. I would be _very_ upset if it
| started updating to stay relevant. If someone wants an
| editor that behaves more like modern editors, then they
| can use a modern editor; and, if they want the best of
| both worlds, then they can fork Vim and modify it (and
| there are successful projects doing exactly that).
| There's no need to modify core Vim to attract new users
| while alienating old ones.
| michaelmrose wrote:
| If you are thinking of a mouse oriented text editing gui
| where one scrolls with the scroll wheel and then clicks
| somewhere and starts typing from there this might make
| perfect sense. In fact you can of course use Emacs like
| that if you prefer but for keyboard oriented operation it
| would be absolutely odd if operations that moved the view
| didn't also move point and in fact other functionality
| depends on this. Presumably making visual point from
| internal point different would complexity and work and I
| have no idea to what end this work would be.
|
| It would be equally weird if scrolling with a mouse wheel
| worked differently than scrolling with page down for
| example. In fact in many applications I now realize it
| does work differently. It's likely that I and many others
| are not likely to notice because when we do scroll with
| the scroll wheel in an editable field or document we
| immediately follow a series of scroll operations with a
| click in the appropriate location where we intend to
| insert text. That is to say people are unlikely to
| exploit the fact that visual point and point are
| different as a deliberate feature because its awkward.
| It's spacebar heating.
|
| https://xkcd.com/1172/
|
| I would also venture to guess people are vastly more
| likely to scroll documents in emacs via keys compared to
| the scroll wheel in part because mouse scrolling emacs
| isn't awesome. That is a better thing to improve.
| rusk wrote:
| > It's about time Emacs adopts the concept
|
| I find this kind of thinking interesting. Like Emacs is a
| bold child that needs to shape up ... rather than a
| conintiually evolving codebase developed by enthusiasts.
| If it doesn't do "this thing" it's probably because it
| doesn't need to. There's probably better ways to do this
| that experienced users are comfortable with. For the
| newbies then you only need workarounds to make them
| comfortable, such as that which I described.
| michaelmrose wrote:
| This is especially true of functionality that could be
| implemented in 15 minutes by users that so desire.
| michaelmrose wrote:
| Regarding 3. Ability to scroll without bringing point along.
|
| You can duplicate the buffer side by side with the original
| buffer and in each window point will be at a different
| location. This is fundamentally just better than such a peek
| mode as you can see two different segments of the same file
| side by side. If you do want to peek and return you can use
| goto-last-change to return to where you were last typing. In
| evil this is bound to g; no idea about a binding in plain
| emacs but nothing is stopping you from using and binding such
| a thing.
|
| https://github.com/emacs-evil/goto-chg/blob/master/goto-
| chg....
|
| You can also use marks in evil m[a-z] to set a mark '[a-z] to
| go back to that mark. so for example ma 'a to go back.
|
| Consider the alternative. Since you don't want scroll to
| always leave point behind you must have a special binding to
| enter peek mode and thereafter you scroll as normal. Then one
| of two things has to happen. Either you decide point really
| ought to be here now and you have to hit a key combo bound to
| end-peek-at-current-location or another key bound to end-
| peek-return-to-point. I would suggest escape/q for end-peek-
| return-to-point and return for end-peek-at-current-location.
| You can also do end-peek-return-to-point if you just start
| typing obviating the need for an additional binding but I
| think this would be a little weird because there would be a
| slight hitch while it pops back to prior location.
|
| The biggest defect with this compared to goto-last-change is
| that it is ironically given the alternative being part of
| evil modal. You have to decide to use peek ahead of time and
| then you have to remember you are in that mode and do
| something to get out of it should you decide you actually
| want to do something different like exit with point at the
| new location. With goto-last-change you don't have to decide
| ahead of time you can simply decide to go back after the fact
| without needing to attend to any state in between.
|
| Multiple windows on the same file and marks require attention
| ahead of time but are far more general and powerful than
| peeking.
|
| Sometimes what people want and what is most useful are
| different things. Fortunately Emacs is simple enough and
| powerful enough for you to implement peek mode trivially if
| you like but I don't think it would be worth using compared
| to the alternatives. Logically you could implement it by
| remembering present point and making local bindings to go
| back to prior point example esc to go back enter to remove
| local binding to esc.
| na85 wrote:
| >You can duplicate the buffer side by side with the
| original buffer and in each window point will be at a
| different location.
|
| I actually attempted that last night. It doesn't work
| unless you disable completion frameworks like company/LSP
| because as soon as a completion event triggers, both
| buffers snap to the completion location.
| brlewis wrote:
| I was unable to reproduce this just now in emacs 26.3
| using company/tide. I've been thinking about moving from
| tide to LSP, but that bug would drive me crazy so maybe I
| should wait for it to be fixed.
| gpderetta wrote:
| this is very odd. I both routinely have duplicate buffers
| visiting the same file and use LSP with company mode. I
| have never seen the snap effect you are describing. Why
| would completion trigger in both buffers? Maybe it is
| company vs ac-mode or some other completion system?
| rusk wrote:
| To me this seems like the answer. We don't need to change
| the way emacs works, we just need a standard way to do this
| that is familiar to people coming at emacs from other
| environments.
| [deleted]
| guessbest wrote:
| I've seen all these before and it makes me wonder why someone
| doesn't just make a different version of emacsen like guile-
| emacs. There must be a lot of inertia behind emacs and
| substantial amount of development effort to make all these
| changes that keeps competitors to gnu emacs from progressing to
| replace it.
| slightwinder wrote:
| Because of GNU Emacs biggest strenght, which is also it's
| biggest flaw: the mountains of existing code. Any new emacs
| must support what emacs already offers. And this means not
| just to be able to run the code, but to also support the huge
| amount of special and exotic features that Emacs offers.
| Guile-emacs for example has a pretty long history on fighting
| emacs-strings and it's special features.
|
| There is the general believe that users don't wanna change
| from emacs away and any new emacs should be ~100% compatible
| to old emacs. But history has shown, people will not settle
| with inferiour clones. So many work will be neccessary,
| whatever someone will build to replace emacs.
| slightwinder wrote:
| Be aware that this are comments from people who use emacs. It
| does'nt mean that implementing these wishes will also lead to
| more users coming to emacs. Even the low hanging fruits from
| the article are barely something that will bring in new users.
|
| Though, distributions like spacemacs and doom-emacs have shown
| that they are bait working well to get new users. Investing
| more in that directions should pay out to some degree.
| acomjean wrote:
| I used Aquaemacs on my work machine. It wasn't perfect but it
| really did integrate well with macOS. the command key doesn't
| overlap with and native emacs commands which helped.
|
| Im using IDEs more these days but still drop text into emacs if
| on a remote terminal or need to use it's macro feature.
|
| Installing emacs plugins or extending the application always
| seems daunting and seems to always involve manual king editing a
| list config file....
| b5n wrote:
| Lately there's been a lot of talk about what Emacs needs, written
| mostly by people who don't understand Emacs.
|
| Emacs is more of a journey than an application. It's similar to a
| blacksmith forging their own tools - Emacs is the metaphorical
| ingot, waiting to be transformed and molded by the user.
|
| If you're happy with what you're using then you don't need Emacs,
| and Emacs doesn't need to appeal to that crowd. Emacs isn't a
| VSCode competitor, it's something entirely different, and it's
| waiting for those who desire transcendence - shedding the limits
| imposed by other tools.
|
| You can install and use Emacs as quickly as any other
| application, but to truly reap its benefit you must go deeper. I
| don't see the need to cater to people who clearly want something
| else, those tools already exist, please leave Emacs to those of
| us who appreciate it for what it is.
|
| I disagree with all the reccomendations made in this article, all
| these changes are easy to implement, and the user is encouraged
| to do so - one of the main selling points of Emacs.
|
| That doesn't mean there is not room for improvement, Emacs is
| still constantly improving. Additionally, I've encountered many
| instances where a colleague or friend introduces me to some new
| feature in their preferred application, the majority of the time
| it's a feature that's been available in Emacs for years if not
| decades.
|
| I'd prefer we continue to focus on the needs of Emacs users
| rather than the wants of non-emacs users. Emacs will still be
| waiting for them when they're ready.
| greggman3 wrote:
| Seems like you completely missed the point of the article.
|
| The article called out that none of the changes make emacs any
| less powerful nor do any of the changes remove any
| functionality. Users can still do everything they could always
| do with emacs. They can still take this "journey" you mention.
| All the changes do is let them get started quicker and jump in
| with at least some familiarity.
|
| Old emacs users such as yourself can keep on using your non-
| standard keys and old terminology. For you, nothing would
| change. For new users, they'd be productive quicker and still
| able to take advantage of all the things that keep fans of
| emacs using to emacs.
| b5n wrote:
| I can't help but feel that you missed the point of my
| comment. New users should be encouraged to make those changes
| themselves if they feel the need to. If that's not something
| they're interested in, why use Emacs?
|
| Anyone can publish a config and distribute it. For instance,
| the author of this article could create a 'new user friendly'
| config and distribute it just like doom, spacemacs, etc. If
| it's popular enough it will see a lot of use, but my guess is
| it would most likely wallow.
|
| Making those changes default would require existing users to
| update their configs, not necessarily a big deal, but for
| what? So a new user can download Emacs, play with it for a
| minute, and still conclude that Emacs is a dusty relic
| because they don't understand the philosophy?
|
| The whole idea of chasing new Emacs users is kind of silly,
| Emacs is more popular than it has ever been, and if a new
| user doesn't come to Emacs for what Emacs offers they were
| never going to stay.
|
| Out of the box solutions already exist, Emacs is in a
| different category, and need not compete in that arena -
| especially at the expense of current users.
|
| Appreciate the reply, cheers.
| SeanLuke wrote:
| > I can't help but feel that you missed the point of my
| comment. New users should be encouraged to make those
| changes themselves if they feel the need to. If that's not
| something they're interested in, why use Emacs?
|
| This whole response is the reason Emacs is rapidly
| approaching EOL.
|
| You're putting the onus on _new users_ to modify Emacs into
| a more beginner-friendly, standards-friendly editor? Their
| response would be: thanks, but I 'll go try out Eclipse
| instead.
|
| It's not that new users desperately want to use Emacs. It's
| that emacs is losing userbase at a tremendous clip because
| its UI and design is so ancient and crufty and because the
| community leaders think that's Just Fine for Them. If the
| emacs community wants new blood, it's _they_ who have to
| implement changes to attract it.
| ashton314 wrote:
| Inspired in part by this article, I put together a quasi-Emacs
| distribution for my wife who is a writer. It turns on several of
| the suggestions in this article by default, such as CUA mode,
| etc.
|
| https://github.com/ashton314/amethyst
| titzer wrote:
| FTA:
|
| > Thus, every program had to be learned individually and its
| complete user interface memorized. It was a sign of expertise to
| have learned the UIs of dozens of applications, since a novice
| user facing a new program would find their existing knowledge of
| a similar application absolutely no use whatsoever.
|
| Hello, web, looking at you. Except that no UI is stable long
| enough that people ever bother mastering it.
| roenxi wrote:
| Interesting commentary. I do think this is a little harsh on the
| poor Emacs undo system.
|
| I can't really push back on the idea that Emacs' undo system is
| excessively confusing, because I use Emacs and I don't understand
| it. I usually save text in a second buffer if I think I'll need
| it later.
|
| But the solution should be to improve the UI rather than remove
| functionality. Consider what magit did to a similar problem in
| git - git is powerful with a weirdly crippled CLI. Magit adds a
| great ... Emacs User Interface? EUI? and all is well.
|
| There is a probably a similar solution to the Emacs Undo problem.
| uselesscynicism wrote:
| The author has a reputation for being an asshole among the
| Emacs community; notably he is banned from #emacs on Libera,
| formerly Freenode.
|
| He isn't always wrong, but his personality is a little harsh,
| as you put it, and it's worth keeping in mind when you read his
| commentary.
| psychstudio wrote:
| Given your current situation, undo-tree-visualize will change
| your life.
| medo-bear wrote:
| wow. is there something like this but for a whole project ?
| blahgeek wrote:
| I think that something is "git" :)
| karatinversion wrote:
| > I usually save text in a second buffer if I think I'll need
| it later.
|
| I use the kill ring for this.
| abdullahkhalids wrote:
| Doesn't the kill ring also behave similarly. That if you move
| through the kill ring and stop, next time it will start from
| that point, rather than the latest killed text?
|
| I always get confused if I use too much of it.
| lvass wrote:
| I think the default M-y does that and it's confusing. helm-
| show-kill-ring or counsel-yank-pop makes this much more
| manageable kind of like how undo-tree makes undoing
| simpler.
| Guthur wrote:
| Just add undo-tree and blow everyone's mind :)
| mlang23 wrote:
| The title is rather strange considering Emacs is Free Software.
| Forks are fine. So why not UX forks. But demanding changes to the
| original without going through the dev process as everyone else
| would need to do is rather weird. "X should do Y" seems to be the
| new way of treating eachother...
|
| If you ask me, Emacs is fine as it is. In fact, I have been
| bitten by two changes over the time which come from the "better
| UI" camp. matching-paren-mode stopped to do the jumping cursor
| thing, which I totally rely on working with a braille display. I
| luckily caught this during the dev process and managed to submit
| a patch which adds a flag to force the "old" behaviour. And
| frankly, the guy who forced transient-mark mode on the world
| needs to hugs till he feels the pain. I am always bewildered when
| something I just marked suddenly vanishes just because I hit del.
| Move cursor a bit and DEL suddenly does something different
| again.
|
| IOW, I am a long-time Emacs user, and really, stop breaking the
| world just because you think something needs to be "modernized".
| Breaking the user experience of long-term users in order to cater
| to newbies is rather rude to those who have invested considerable
| time to learn the system so they can use it as effectively as
| possible.
| bjourne wrote:
| Xah Lee and friends maintains a mode called ErgoEmacs that
| implements most of the changes he proposed:
| https://github.com/ergoemacs/ergoemacs-mode
| h2odragon wrote:
| Why should emacs have to adopt _your_ changes (or mine)?
|
| Make a "Modern-Emacs" and make it what _you_ want, make it
| something you and others can love. Maybe others will love it
| enough to contribute, maybe no one but you will ever use it.
| Either way is great, and you still have your ideal tool.
| medo-bear wrote:
| i initially hated emacs' non-CUA bindings. now my thoughts are
| opposite and because i spend so much time in emacs, when I need
| to go to CUA it's quite annoying. i agree that CUA should be made
| default, but with immediate option on start-up to use original
| emacs bindings. i think it will put off far fewer people
| cheezymoogle wrote:
| To makes Emacs popular again, the core team needs to realize that
| their actual competitors are desktop environments, window
| managers, and automation tools rather than text editors and IDEs
| at this point. Programmers know what they want in an editor--the
| general populace doesn't (beyond a bare minimum of having it work
| like Google Docs or Microsoft Word). Emacs doesn't need to change
| at all, it just needs tools that go a few levels deeper in its
| philosophy. That is to say, first make Emacs capable of
| controlling non-Emacs GUIs and piloting web browsers. Second,
| improve automation tooling that so that individuals can make and
| share no-code macros for simple tasks. EXWM, an Emacs-based
| window manager has already taken a great first step towards
| accomplishing this.
|
| Emacs is a keyboard macro editor stuck in a mouseless era where
| Lisp Enlightenment was still a thing. It's great, but it's niche.
| Most people don't actually want or need that (or to be more
| specific, they don't know that they need or want it).
|
| The way to directly grow the user-base is to get the general
| population on board Emacs first, then evangelize for the idea
| underlying open software afterwards.
|
| You do that by solving the problems that they already have more
| efficiently than their present solutions. Org-mode really nailed
| it in this department. I switched to Emacs for org-mode, but
| stayed for vanilla Emacs and EXWM. If Emacs were just Emacs, I'd
| probably be using a different editor. Without definitive hooks,
| Emacs is esoteric, opaque, and frightening to the general
| population, if they know about Emacs at all besides vim's evil
| rival. They just don't need Emacs in its current state.
|
| What they do need is something that makes it trivial to automate
| the dumb and repetitive tasks that they have to do every day on a
| computer using a browser. This is no longer shell or plaintext
| processing for the majority of non-IT users. It's interfacing
| with GUIs. They need middleware to automate interfacing with
| kludgy enterprise software. They need middleware to speed up
| internet browsing.
|
| If Emacs were a blank slate project today, fulfilling the same
| type of needs, I could see it being a mashup of EXWM, Selenium,
| and AutoIt. Its killer features would be a guarantee that the
| same controls (that the user selected from a common set e.g.
| Microsoft Word, Firefox, Vim, Emacs, etc.) worked functioned
| between applications. Having the ability to record mouse and
| keyboard macros without ever needing to see a line of code, but
| also providing the ability to drive using the DOM, OCR, or
| whatever niche smart interface is needed would be a second killer
| feature. These coupled with the already standard Emacs and EXWM
| features would attract a ton of new users that would actually
| have a compelling reason to learn how to use it and then later
| adopt to the Emacs paradigm.
|
| EXWM is already 70% of the way for a minimum viable product for
| something like this. It just needs to be bundled with more mature
| macro tooling beyond 90s relics like xdotool and xautomation
| along with a distro with sane defaults. Having a single
| abstraction layer to control everything from userland on through
| web platforms would be a dream for accessibility and returning a
| semblance of control to users.
| ycstohley wrote:
| Do nothing. It's awesome.
| giancarlostoro wrote:
| I would love Emacs to get a facelift in the UI aspect. I like
| what Neovim is doing for UI stuff. Maybe Remacs can head a
| similar direction.
| smackeyacky wrote:
| Given that emacs just needs a good editor, maybe get them to
| integrate neovim?
|
| ;-)
| wiz21c wrote:
| been using emacs for several years... What could be improved is
| speed. Too many times it doesn't see some keys combinations I
| hit. Screen redraw should be faster too (I spend a lot of time in
| front of it so that kind of "detail" is actually important).
| Loading big files is slow. Editing long lines is slow. Of course
| it doesn't happen often but when it happens it's annoying. Emacs
| could also propose options to better align on common behaviors
| (for example C-left/right arrow) doesn't behave like in other
| editors.
|
| It could also be more "discoverable". There are hundreds of
| functions so that 100% of my needs are covered. But every now and
| then, when I want to find a command, I DuckDuckGo it... It'd be
| nicer if somehow there would be an assisted navigation in the
| commands (or a pointer to that assistance I've been sorely
| missing :-))
|
| But I like it anyway. 'cos it's faithful, community grown, etc.
|
| And if I had time I would contribute. But emacs is an old
| platform so there are many choices buried in and reaching the
| level of knowledge necessary to contribute is probably very
| high...
| Tomte wrote:
| > What could be improved is speed.
|
| Native compilation is coming in the next version and should
| help quite a bit.
| wiz21c wrote:
| I'm already on the 28.0 branch, makes no visible difference
| (my workflow is rather basic : editing lots of code, bits of
| org mode, bits of WL)
| daptaq wrote:
| Are you sure you have libgccjit installed and configure
| found it?
| wiz21c wrote:
| My configure's config.log says :
|
| #define HAVE_LIBGCCJIT 1 #define HAVE_LIBGCCJIT_H 1
|
| So, yep it has it.
| medo-bear wrote:
| i think running as a server should be made default. i imagine
| that alot of people are opening alot of seperate instances
| lloda wrote:
| I don't run Emacs as a server because it freezes
| occasionally and it's very painful to have a couple dozen
| windows in eight workspaces go down.
|
| If I could rely on Emacs never freezing, I'd be happy to
| run it as a server.
| lvass wrote:
| I have init manage an emacs daemon but open separate
| emacs instances if it's doing something important, even
| though it practically never freezes for me. I think this
| works fine as long as you don't have server-start in your
| config.
| rightbyte wrote:
| Have you tried "native Emacs", AoT compiled with libgccjit?
| kryptiskt wrote:
| "Buttery Smooth Emacs" contains some insight into what goes on
| under the surface of Emacs and is a great read:
| https://m.facebook.com/notes/daniel-colascione/buttery-smoot...
| abdullahkhalids wrote:
| > It could also be more "discoverable".
|
| I definitely agree that I want to type some string and it
| should show a fuzzy search from all available commands and
| their descriptions. That would be huge timesaver for
| functionality I know exist, but I forgot the exact commands.
| uncletaco wrote:
| This is literally what `M-x` does. You want to do the same
| for functions? `C-h f`. Variables? `C-h v`. Keybindings for
| the current mode? `C-h ?`.
|
| If I'm not mistaken when you install vanilla Emacs the screen
| even includes a tutorial and guided tour that both tell you
| these commands.
| trey-jones wrote:
| Yes, once you make the connection between every single
| keypress invoking an elisp function, and the various help
| combinations (variables, functions, keystrokes as you
| mention), I think Emacs is actually the _most_
| "discoverable" editor that I've used.
| wiz21c wrote:
| Except when the name of what you look for doesn't match
| your mental model (yep, I'm in the group of people who
| think software should adapt to human and not the other way
| around)
|
| Example : I want to change the encoding of a file when I
| load it... Good luck figuring that out without resorting to
| reading the documentation.
| uncletaco wrote:
| And here I would argue that, since the documentation is
| included _with_ Emacs and can be pulled up _in_ the
| editor, this is still a point towards its inherent
| discoverability.
|
| Again when you load emacs there's a link to the manual on
| its splash screen and as a guided tour. A lot of people
| rush to turn off this screen or suppress the menues on
| startup (which I get, the menu bar is pretty ugly) but
| they do have useful functionality for someone who doesn't
| know Emacs.
| b3morales wrote:
| M-x completions aren't really "fuzzy" out of the box.
| `partial-completion` is in default `completion-styles`,
| yes, but then you have to do word breaks with dashes
| manually.
| vvillena wrote:
| Discoverability is a key part of larger addons such as
| Spacemacs and Doom Emacs. They come configured out-of-the-box
| with nice completion panels for command and function search
| panels.
| yakubin wrote:
| _> been using emacs for several years... What could be improved
| is speed._
|
| Same here. Long lines are especially painful. And it's quite
| surprising what Emacs considers a "long line". I have a file in
| my project with tests, where I have an array, with each element
| of the array on a separate line, averaging at around 125
| characters per line (some of them weird Unicode characters, so
| not just ASCII). There are 52 lines of it. And when I scroll
| down the file with C-v (Page Down basically) it scrolls quickly
| up until I get close to this place, then I get something like
| 1.5 seconds delay while it's hanging there. It's ridiculous.
|
| Another thing is how easy it is to freeze Emacs into being
| completely unusable when editing files over Tramp (with remote
| work it's the go-to solution), caused by an unreliable
| connection. Mostly it happens when the underlying VPN
| connection is dropped. When that happens, Emacs freezes with no
| explanation whatsoever. I can only guess what happened. C-g,
| Esc, nothing works, regardless whether the VPN connection is
| restored or not. The only solution at this point is killing
| this instance of Emacs. Specifically for this purpose I crafted
| a one-liner to kill the right instance of Emacs[1] (the one
| under the mouse pointer): kill $(xdotool
| getwindowpid $(xdotool getmouselocation | cut -d : -f 5))
|
| Also, magit is painfully slow. When using it, I always wonder
| if Emacs is frozen again, or if it's just magit being magit.
| It's a shame Fork is not available for Linux.
|
| [1]: The other instance of Emacs is used for tracking in org-
| mode the time I spend on different tasks. I used to do it all
| in a single instance, but then I kept losing that data due to
| Emacs freezing like that, so I started using a separate
| instance for the time-tracking. I really think Emacs should be
| a multi-process application to prevent such situations.
| mattmein wrote:
| Regarding your long lines issue - from your description it
| sounds instead like an unicode issue which I also ran into a
| while back.
|
| What happens is that your main programming font does not have
| the unicode characters, so Emacs falls back to searching all
| your fonts for each character it can't find, which is slow if
| it has to search through many different fonts.
|
| The solution is to ensure you have symbol fonts installed -
| see the list of fonts here:
| https://github.com/rolandwalker/unicode-fonts
| jpeloquin wrote:
| > some of them weird Unicode characters, so not just ASCII
|
| This makes me suspicious that it's the font cache causing the
| slowdown (assuming Windows), not long lines. I saw similar
| symptoms a couple years ago and fixed it with (setq inhibit-
| compacting-font-caches t).
|
| You could also try increasing the garbage collection
| threshold on the theory that the lag is a gc pause. I've
| used: (setq gc-cons-threshold (* 511 1024
| 1024)) (setq gc-cons-percentage 0.5) (run-with-
| idle-timer 5 t #'garbage-collect)
| lloda wrote:
| xkill ?
|
| But I agree. Emacs should be faster.
| yakubin wrote:
| I didn't know of xkill. Thanks!
| shrimpx wrote:
| > Too many times it doesn't see some keys combinations I hit.
|
| This caught my eye because I tend to think _the opposite_ of
| this statement. Emacs doesn 't skip a beat on text input --
| unlike say VSCode which has perceivable input lag. In my
| experience, when Emacs gets slow it's a configuration problem,
| like flychecking on every keystroke, or a slow/poorly written
| third-party package. Raw emacs is blazing fast.
|
| Disclaimer: I use `emacs -nw` -- no GUI toolkits.
| pjmlp wrote:
| Not sure what might still be missing, but I add the ones from
| XEmacs for graphical tooling integration, that might still be
| missing.
|
| By the way, Gosling now rather uses IDEs.
| vkazanov wrote:
| He is THE Java guy, and java is pain without massive IDEs.
|
| What I find here funny is that Netbeans is dead, and nobody
| ever mentions it on HN. And we still talk about emacs.
| bitwize wrote:
| NetBeans is dead because JetBrains was a better NetBeans.
| SeanLuke wrote:
| NetBeans was killed by competition with Eclipse. IDEA had
| nothing to do with it.
| erlkonig wrote:
| TL;DR * Don't change any of the naming, Emacs's naming is either
| better than what the article proposes, or cannot be changed
| everywhere it would need to be * Don't push for CUA copy/paste
| unless there's a plan for where to put both the C-x and C-c
| keymaps, and NOT on Alt (more info below) - if you have one, add
| a menu item to turn it and similar things on together, with help
| about it. * Add to the top of NEWS (C-h n) how to kill the NEWS
| buffer
|
| The article's point that Emacs's use of "frame" and "window" are
| quirky is true, but running it on a true terminal would mean the
| standard use of a the word "window" wouldn't even apply. However,
| since few people do that now, I agree that "window" to describe
| the view of Emacs overall on a terminal, or in a desktop window,
| and "pane" for the subsections (NOT "frame") sounds reasonable.
| EXCEPT that this would break the name usage in a staggeringly
| large amount of LISP code, and thereby add cognitive dissonance
| when reading code, documentation, function calls and so on. So
| sadly, I think being resigned to being consistent instead of
| having different terminology for a beginner vs advanced user is a
| better call.
|
| I've mapped keys for Alt, Meta, Super, and Hyper to my keyboard.
| Since Alt key (and AltGr) are, as far as I know, notionally for
| typing glyphs that aren't on the keyboard, it would be stupid to
| mix the Alt and Meta concepts - those need to be on different
| keys. All the article is doing by arguing that Alt should be
| hardwired in to the default emacs keymap is going down the same
| annoying path we did with backspace-vs-delete: Eternally
| confusing two different things over a keyboard layout peculiarity
| NOT shared by all users.
|
| Yes, the Scratch buffer should default to text mode. Experienced
| users who like the current default can configure for it.
|
| C-k and C-y are named mnemonically, so unless one wants to move
| copy to "Ctrl+c" and paste to "Ctrl+p" (which are both harder to
| read, btw, thana C-c and C-p), don't break one feature (mnemonic
| names) for another feature only some people prefer. Also, the
| kill-ring system does NOT work like copy+paste, and there are a
| number of complexities around X cut buffers the article author
| may not be aware of where something you kill/copy may not end up
| in the buffer the other app can yank/paste.
|
| There also nothing wrong with "buffers" - a editor with a concept
| lacking in the UX many other editors is certainly allowed to
| apply a single consistent name to it. It's unfortunate that this
| use of the word is unique to software (compare "buffer zone" in
| normal English)... "stash" at least had a concrete meaning to
| non-devs ("working copy" doesn't work since the in-RAM could be
| the original, "draft" doesn't work because it may have been saved
| to disk, etc, etc). "slate" would have been an amusing choice. As
| with the discussion on "window"/"frame", changing "buffer"
| consistently would be a nightmare.
|
| To the user complaining about copy/paste/etc not being all
| together, they are in contrast, bound to mnemonically reasonable
| keys. Also, Dvorak. Also, a huge number of PC users don't use the
| Ctrl+{C,V,X} anyway, and don't understand that complaint to begin
| with.
|
| "Keybind" is a pretty commonly used term in PC games, and is a
| superset of "Keyboard shortcut" since it's understood by PC
| gamers to include mouse buttons and so on as well. It's
| notionally hard to apply "keyboard shortcut" to the act of
| binding a function to a _mouse_ key, so the "keyboard shortcut"
| falls short of the concept and will just cause confusion. Now
| saying a key is "bound" to an action may be confusing, sure, and
| what's funny is that saying a key is "tied" to an action would
| probably make sense to most users. Yet those are synonyms. Go
| figure.
|
| Having taught users how to use editors in Unix for years, my
| students only complained about one thing in Emacs - getting stuck
| in NEWS and not knowing how to get out. Usually this happened
| _before_ they knew how to kill /switch buffers. Nothing else
| really bothered them, and they largely learned by using the in-
| editor tutorial. (those users were also taught vi, which is
| unquestionably harder to get started in, though vim today now
| points users at a tutorial)
___________________________________________________________________
(page generated 2021-08-28 23:00 UTC)