[HN Gopher] Emacs: Contextual Interfaces in Casual Calc
___________________________________________________________________
Emacs: Contextual Interfaces in Casual Calc
Author : signa11
Score : 82 points
Date : 2024-08-13 12:05 UTC (10 hours ago)
(HTM) web link (yummymelon.com)
(TXT) w3m dump (yummymelon.com)
| pkkm wrote:
| Thanks for working on these "casual" Emacs packages. I've long
| thought it is lamentable that we mostly have two kinds of UIs:
|
| * Those designed for power user speed, with seemingly little
| regard to novice-friendliness (e.g. bash, tar, find, Emacs calc,
| Vim).
|
| * Those designed for novice-friendliness and aesthetics, with
| seemingly little regard to power user speed (many GUI programs,
| almost all websites, almost all phone apps).
|
| It feels like we're very far from the Pareto frontier, and I wish
| more people thought explicitly in terms of getting closer to that
| frontier - that is, "how can we maximize novice-friendliness
| under the constraint of not lowering the speed ceiling even a
| bit". I think this could be done through some combination of
| autocompletion, cheatsheets that pop up automatically, and
| consistency between programs.
|
| Magit-like UIs are a happy exception to the rule. Their speed
| ceiling is very high because they're completely keyboard-driven
| and have no animations, but their discoverability is good because
| they constantly pop up little cheatsheets of what keys you can
| press to trigger actions. I was able to start using Magit almost
| immediately after installing it, and learn it gradually without
| looking at external resources. Now I fly through the common
| operations on muscle memory, and it feels like it took no effort
| to get there. I hope that more programs copy this UI paradigm.
| agumonkey wrote:
| Magit should be the subject of a book about progressive
| derivative UX enhancement, and even passive pedagogy. Often
| tarsius and the team managed to make you curious and try ideas,
| like selecting a range of lines and hope staging would only
| stage it and not the whole diff range. You don't even make an
| effort cause it's one key down and one key to undo on case it's
| not what you expect. It's cozy to the point of brilliance.
| nickdrozd wrote:
| Well said. The Magit interface is such a pleasure to use,
| sometimes I will modify and rearrange commits just for fun. A
| Magit-style interface for Calc seems like a great idea.
| kickingvegas wrote:
| While I didn't submit this link to HN, I wrote the OP. Thanks
| for the compliment on Casual! It's been an exercise in re-
| litigating my user experience with Emacs this Summer, which
| I've decided early on to share publicly. For folks interested
| learning more about the Casual packages, here's a link to
| Casual Suite (https://github.com/kickingvegas/casual-suite). At
| my blog you can find all my posts on the different Casual
| packages. http://yummymelon.com/devnull/
| nickdrozd wrote:
| Looking at some of these screenshots, this is such a
| fantastic idea that it is surprising it wasn't done earlier.
| Magit has the perfect interface, why shouldn't everything be
| like that? Who wants to read the Info manual anyway? Info,
| Dired, Calc, obviously. Org mode, of course.
|
| Maybe other people have been working separately on similar
| ideas? Really it is extremely obvious in retrospect that
| everything should have a Magit style interface. Ultimately,
| it would be great if that were the default, generally assumed
| style throughout Emacs. It would be great if all that effort
| could be coordinated and merged into the main distribution.
| Built-in, no external packages.
| davisr wrote:
| My opinion is that your ideas of "user friendliness" are
| misguided. I think a better way to phrase what you're trying to
| say is that, there is a class of software that have user
| manuals and require a flip-through, and there is a class of
| software that locks its users into predefined tracks so they
| can only ever pick from the choices presented to them.
|
| I don't think there is anything unfriendly about needing a
| manual. If only all software could be so thoroughly documented!
| It used to be, back in the 80s and 90s, and it was a better
| time. I mean, isn't it a disservice to, in an analogy, give a
| user a kayak without a paddle?
|
| In the 1970s, secretaries who had not used computers found it
| easy to use Emacs and program in LISP. [1] And I, personally,
| was a voracious reader of software manuals when I was a small
| child. And they made the world make sense, and they made me a
| smarter person for it. And I really do believe that people
| waste more of their lives picking ill-suited preset choices
| than they would if they (could have) just read a manual.
|
| [1]: https://www.gnu.org/gnu/rms-lisp.en.html
| gumby wrote:
| I think you misunderstood what rms said there (but if the
| transcript is accurate, he was unclear).
|
| Yes, Multics Emacs was the one used by secretaries (except at
| AI & LCS where they used TECO EMACS on ITS). In both cases
| most of the extending by non-programmers was done with macros
| (`c-X (` which is still that command today).
|
| Multics Emacs had an excellent design and you could in fact
| write some very simple functions with a copy-and-modify rote
| approach (nothing wrong with that!). But beyond that I never
| met one whom one could describe as knowing Lisp. In fact most
| would have been intimidated if you'd told them that they
| could improve the editor by "programming".
|
| This "programming is impossibly hard for a person like me"
| attitude was a bad cultural property of the 1970s, thankfully
| now somewhat in the past. But that change depended on direct
| work on the problem by people like Seymour Papert and Cynthia
| Solomon in the LOGO lab (part of the AI lab).
|
| Excel is a great (in volume and reach) example of this: many
| people write very complex and sophisticated programs in Excel
| and still don't believe they can program. Now Python is
| embedded in Excel some people can be tricked into writing
| real programs. And, presumably, tricked into running
| sophisticated malware!
| BeetleB wrote:
| > I don't think there is anything unfriendly about needing a
| manual.
|
| It is, however, very user friendly if something is designed
| such that a user never has to look at a manual.
|
| If someone makes an interface where you can do quite a bit
| without ever reading one, and you read it only for the finer
| points, that's also pretty user friendly.
|
| I never read a manual to use my smartphone when I bought my
| first one. I think most people will agree that if you buy a
| smartphone and you can't do anything on it until you read a
| _fantastically well written_ manual, they will consider the
| phone to be user unfriendly.
| ashton314 wrote:
| > Magit-like UIs... speed ceiling is very high because they're
| completely keyboard-driven and have no animations, but their
| discoverability is good because they constantly pop up little
| cheatsheets of what keys you can press to trigger actions.
|
| This is the kernel of brilliance: there is _zero_ slowdown when
| using Magit if you 're proficient. Easy for beginners to start
| exploring (it's a very _discoverable_ UI!) and there 's little
| to nothing to do for experts to start using it _faster_. Sure,
| there are some things you can tweak, but the interface is
| already so geared towards efficient use that it just works as-
| is.
|
| I'm very happy that the `transient` package has been merged
| into Emacs; hopefully we'll see more like Magit and Casual
| popping up in the future.
| rssoconnor wrote:
| New spacemacs user here. When I'm on the magit pane (SPC g s)
| what commands are available to me and how am I supposed to
| know? I know I can do 'p' to enter a push menu and 'r' will
| give me a rebase menu, but that's pretty much all I know.
| kragen wrote:
| try the ? key
| struanr wrote:
| If you press '?' in the magit window a popup of available
| commads should appear. If I remember correctly from when I
| used to use DOOM emacs before switching to vanilla, evil (vi
| emulation) keybingings mean the keys listed in the magit
| popup are incorrect, however it should give you an idea of
| what commands are available and you can use other Emacs help
| facilities to find the Spacemacs keybindings.
| phforms wrote:
| Whenever I find myself learning about something where I know that
| I will not use it frequently enough to actually remember its
| keystrokes/commands/etc. I create a new "personal documentation"
| for it as an .org file (I have a central folder and a git repo
| for all of them). Here I'll write all the information (like
| keybindings, details of commands, common procedures, concepts,
| etc.) down that is specific to my own use-cases and organize it
| in a way that makes sense to me.
|
| It takes some time and effort and may seem redundant when there
| is good documentation out there already (as with most of Emacs).
| But still I find myself wasting a lot of time looking for that
| one piece of information in the docs where I forgot how to even
| search for it. Maybe it works so well for me because I kind-of
| enjoy the process of writing it (which many people might not).
| But I feel much less frustrated afterwards when I come back to
| some tool or language after years of not using it and find it
| really easy to remember what was important to me at the time and
| how to do X.
|
| Tools like Casual Calc are great because they reduce the need to
| do that manual work of going through the docs and writing down
| what one want to remember in a (for them) more
| clear/concise/practical way. However, the way they select and
| organize knowledge/commands only reflect the common use cases, so
| there may still be a need to write stuff down.
|
| As a more general helper, I really like to use Emacs Calc with
| `which-key`, which provides a similar interface to see what
| keybindings are available under a specific prefix-key. What also
| helps is if you press `h` and then search for a specific function
| (`h f`), key (`h k`), etc. or just type `x` to enter a function
| name directly (or by keyword using text-completion).
| bowmessage wrote:
| You might like (contributing to) https://github.com/tldr-
| pages/tldr, I'm sure your notes would be helpful to me and
| others! Not sure if they've got a section for specific editor
| packages, yet.
| BeetleB wrote:
| I used to do the same (self document in an org file). With
| Emacs, though, I've found creating hydras[1] to be a better
| approach. It looks a lot more complicated than it is. The first
| time I wrote hydras, it was hard. After that, it's been
| trivial.
|
| Of course, magit like menus are mildly superior to hydras, but
| I don't know if they are as easy to generate.
|
| [1] https://github.com/abo-abo/hydra
___________________________________________________________________
(page generated 2024-08-13 23:01 UTC)