[HN Gopher] On the design of text editors (2020)
___________________________________________________________________
On the design of text editors (2020)
Author : signa11
Score : 151 points
Date : 2024-09-28 06:08 UTC (1 days ago)
(HTM) web link (arxiv.org)
(TXT) w3m dump (arxiv.org)
| niobe wrote:
| Some food for thought. Although I think the authors criticisms of
| syntax highlighting are a bit personal and subjective,
| alternative schemes would be interesting to explore.
| teo_zero wrote:
| I share some of TFA criticism: syntax highlighting just
| emphasizes what you should already see without it. The word
| "return" is a keyword of the language, you don't need it to be
| visually different from the rest to recognize it.
|
| On the other hand, highlighting could help you with semantic.
| For example rendering in a different color a word that's not
| been declared/defined before would be greatly valuable. Telling
| a variable from a type would also be helpful in C-like
| languages (no, current syntax highlighting schemes don't do
| this, not even the ones backed by tree-sitter). What about a
| switch to grey out all local/static definitions and thus
| emphasize only exported/public ones?
| msla wrote:
| This, of course, is the _true_ paper on the design of text
| editors:
|
| "Multics Emacs: The History, Design and Implementation",
| Copyright (c) 1979, 1996 Bernard S. Greenberg
|
| https://multicians.org/mepap.html
| benreesman wrote:
| Thank you kindly for that link.
|
| I actually have a link to TFA in the block header in my dots,
| and it seems a crime that one isn't there as well.
| Ferret7446 wrote:
| What about RMS's ACM paper?
|
| https://www.gnu.org/software/emacs/emacs-paper.html
| Chris_Newton wrote:
| I do wish we were more adventurous in how we present our code in
| editors. As the article says, we seem to be stuck in a rut.
| Typography in the main editing area is almost always based on a
| classic monospaced text file. Colours are almost always based on
| "syntax highlighting", which in turn often involves
| distinguishing elements of the language we're looking at whose
| differences aren't very important.
|
| Given the potential of modern graphical environments and
| typography, I'd like to see languages and editors adopt simple
| spacing improvements like elastic tab stops1. I don't want to
| chose between an aesthetically pleasing layout that draws
| attention to patterns and anomalies in my code and a layout with
| completely uniform spacing because anything more carefully
| aligned is a pain to maintain in later edits and adds noise to
| diffs. We could shrink blank lines to half-height as well, which
| would keep the useful visual separation but waste less space.
|
| I'd like to use a (somewhat) wider range of basic symbols than
| whatever we had in ASCII last century. Even allowing comparison
| operators like <=, <, [?] and = that align consistently would be
| a useful start.
|
| I'd like simpler syntax highlighting, concentrating on
| distinguishing major language elements like literals, variables
| and types, and emphasising problems I probably care about like
| unclosed strings and misspelt keywords. I'd also like to see
| colour used more effectively for matching related code like
| opening/closing pairs or the definition of a value and later
| references to it.
|
| I'd like to see a sidebar for documentation, not unlike the
| example for comments in the article, but allowing documentation
| to be attached at different levels from an individual function or
| variable up to an entire file or beyond, then having the editor
| automatically offer all documentation relevant to wherever I am
| in the code and whatever I'm typing there.
|
| If we were designing a UI for another application, we'd always
| consider aspects like spacing, symbols and iconography, colour
| schemes and how to show and navigate related information. It's
| strange that we give so little consideration to them in the tools
| we use ourselves!
|
| (Join me next week for part two of the epic rant, provisionally
| entitled _Why aren't we all using semantic diff tools yet?_ )
|
| 1 https://nick-gravgaard.com/elastic-tabstops/
| vunderba wrote:
| Agreed. There's a great deal of improvement I'd like to see in
| text editors and IDEs.
|
| Collapsible images as inline comments can be _FAR_ more
| effective at embedding relevant information in certain sections
| of code.
|
| As far as "related coloration" - Jetbrains IDEs let you setup
| regex around comments that will color them differently which I
| use in collaborative environments so devs can quickly collate
| their TODOs, etc.
|
| There's also an extension called Rainbow Braces that helps to
| highlight opening/closing pairs with different colors.
|
| https://mordenstar.com/blog/how-to-build-a-better-ide
| kragen wrote:
| rainbow parentheses are mentioned in the paper
| WillAdams wrote:
| Have you considered/looked at Literate Programming?
|
| http://literateprogramming.com/
|
| With a bit of help on tex.stackexchange.com I managed to put
| together a system which allows editing a .tex file (without the
| docstrip mandated almost everything is a comment greyness):
|
| https://tex.stackexchange.com/questions/722886/how-to-write-...
| Chris_Newton wrote:
| Yes, I wrote some literate Haskell professionally a few years
| back. I think it's an interesting and useful concept. In my
| experience, it also fundamentally changed the way I read and
| wrote code, with both pros and cons.
|
| What I'm advocating here is a little different, though. While
| it would certainly be useful to write documentation using
| more expressive formats than plain text, here I'm arguing for
| the ability to (a) attach that documentation to specific
| parts of the code at different scales and then (b) have all
| relevant information at all scales readily available
| depending on what I'm currently editing.
|
| One of the reasons I would like to have this ability in my
| development environment is that I found the literate style to
| be very helpful for writing informative documentation but
| relatively unhelpful for finding it again later. By its
| nature, literate documentation is organised primarily for a
| linear reading flow, like the story in a book, but most of
| the time when I'm editing code, that's not my typical
| searching behaviour.
| yonatan8070 wrote:
| > I'd like to use a (somewhat) wider range of basic symbols
| than whatever we had in ASCII last century. Even allowing
| comparison operators like <=, <, [?] and = that align
| consistently would be a useful start.
|
| Visually, font ligatures do just that, and combine your !=, >=,
| etc. into single elements
| ReleaseCandidat wrote:
| But they don't actually work, because there are many
| ambiguities. Is <= "less than or equal" or an arrow pointing
| to the left? And in the other direction too: is [?] "!=" or
| "/=" or something else? And as soon as you allow 3 or more
| characters to build ligatures, your number of ligatures
| explodes, but you still miss some. For example it doesn't
| matter if <= is an arrow or LTE and => is an arrow, in a <=>
| all are wrong, same as in a >=> or a >>= or...
| setopt wrote:
| The main reason I stopped using programming ligatures that
| much is that many languages actually support Unicode
| characters in the source code, and this is actively used in
| some projects I work on.
|
| It then becomes important to see the difference between
| ASCII approximations and real Unicode symbols, since this
| is relevant e.g. when searching for a symbol in your code
| base or to see at a glance whether usage of Unicode vs.
| ASCII etc. is consistent.
|
| The only spot I still kinda use such a feature (prettify-
| symbols-mode specifically) is in LaTeX, where Unicode math
| is more rare and long equations become nearly unreadable
| without some kind of rendering in the source code.
| kyberias wrote:
| How are those Unicode characters typed in an editor with
| a normal keyboard?
| dpassens wrote:
| Depending on your operating system, you might have (the
| option to remap a key to) a compose key. Then you can
| press compose followed by, for example, <= to make <=.
| This also works for letters with diacritics on them, like
| "o for o or 'o for o, currency like =C for EUR or =L for
| L, or other symbols like tm for (tm).
|
| You might also be able to set up your own compose codes
| in ~/.XCompose, but that didn't work for me. Could be
| another casualty of Wayland or just some quirk in my
| setup.
| tmtvl wrote:
| In my editor I just press Ctrl+x, 8, Enter, and then I
| can look up Unicode codepoints based on either the hex
| code or the name. Alternatively you could do the whole
| Unix 'do one thing and do it well' thing and use a
| character selection program which allows you to look up a
| character (I've got KCharSelect, I believe Windows has a
| similar thing called Charmap or something).
| setopt wrote:
| Many alternatives:
|
| - Like the sibling mentioned, you can use a "compose key"
| (it's built in on Linux and can be installed on other
| platforms). There are other OS-wide options like the TeX
| input method for Gnome, or TextExpander snippets on Mac.
|
| - In Vim, Ctrl-K in insert mode lets you enter
| "digraphs". For instance, Ctrl-K *s will insert a Greek
| letter "sigma".
|
| - In Emacs, C-\ will activate an "input method" such as
| the "TeX" input method that can insert any math or Greek
| Unicode symbol using LaTeX notation. (I personally like
| Emacs' "transient" input method that is activated for one
| symbol at a time, since it interferes less with coding.)
|
| - In Sublime Text and VSCode there are third-party
| plugins that insert Unicode symbols via e.g. TeX
| notation.
|
| - Every Julia editor extension, as well as its REPL, lets
| you press tab to convert a set of LaTeX-like notations
| into Unicode symbols in a common way.
|
| - Most editors have support for snippets of some kind,
| and many have available snippet packs for common math and
| Greek symbols.
| davisoneee wrote:
| For vim/neovim users you can use digraphs, where you
| press `<C-k>` followed by a 2-character code to get a
| symbol (see `:help digraphs` and `:help digraph-table`).
|
| For example, <C-k> -> gives -
| <C-k> => gives = <C-k> d* gives d (greeks are
| generally all _letter_*) <C-k> D* gives D
|
| Some of the combinations are a little weird to rememeber,
| but if you use them regularly then it's easy enough (like
| greek or arrows).
| chipsrafferty wrote:
| I'm a bit confused. My only experience with ligatures is
| in vscode, I don't use them personally, but I've seen it
| where if you type >= then it changes it to look like >=,
| if you hover over it, it shows >=, if you put your cursor
| to the right of it and hit delete, it deletes just the =
| and not the >, in other words, it is just >= except
| visually. On a git diff it would still be >=.
|
| So I understand how you could have confusion in your case
| if you have logical comparators for >= and also have
| strings with ">=" or even variable names, if your
| language is permissive enough to allow that. But if you
| search for ">=" it should not return the ">=" disguised
| as ">=", ...right?
| setopt wrote:
| > But if you search for ">=" it should not return the
| ">=" disguised as ">=", ...right?
|
| That's my issue :). Languages like Julia permit both ">="
| and ">=" in the source code with the same meaning. But if
| you use say search-based navigation of your file, how do
| you know which one to type to get where you want?
|
| Or in Python I've seen some people make "alpha" render as
| a, since it's a common variable name in physics codes.
| But "a" itself is a valid Python variable name, and I
| personally use Greek letters in Python physics code and
| know others do as well. That can again be confusing,
| since in Python "alpha" and "a" are _not_ the same
| variable, so it's crucial to write it correctly.
| chipsrafferty wrote:
| You've highlighted an issue with mapping syntax to
| ligatures in a generic sense, i.e, one that will work for
| programming language. But that's not an issue, because it's
| impossible, and we knew that from the start. When people
| make these stylized symbols, they have to write a parser
| for each individual language that they're applying them to.
| MengerSponge wrote:
| > I'd like to use a (somewhat) wider range of basic symbols
| than whatever we had in ASCII last century. Even allowing
| comparison operators like <=, <, [?] and = that align
| consistently would be a useful start.
|
| Like ALGOL?
| Chris_Newton wrote:
| Not necessarily the exact same symbol set, but yes. Nothing
| too fancy, just using widely recognisable symbols that have
| been supported by Unicode forever instead of half-baked,
| ASCII-centric alternatives that date from last century.
| alextingle wrote:
| > Even allowing comparison operators like <=, <, [?] and = that
| align > consistently would be a useful start.
|
| Every text editor that understands Unicode already allows for
| that. If you want to use <= rather than <=, then you need to
| alter the _language_ , not the editor.
| swiftcoder wrote:
| You don't need to modify the language, and most popular
| editors already support this. You'll need to enable ligature
| support, and install a font that contains the appropriate
| ligatures (as many coding-specific fonts already do)
| auggierose wrote:
| That's not really a solution, is it, for example I don't
| want <= to be confused with <= within a string. What you
| propose is just one more half-baked solution that the
| industry is full of.
| rollcat wrote:
| That's why you need editor support for this; the lexer
| understands the difference between an operator and a
| string literal (that's how syntax highlighting works),
| and should be able to use ligatures in one context but
| not the other.
|
| (BTW I'm not a fan of coding ligatures myself, but they
| seem to be popular.)
| auggierose wrote:
| Yes, if you do it on top of the lexer it starts to make
| sense to me. I still think the language should also
| support the corresponding "ligatures", so that no
| confusion can result if you happen to enter <= directly,
| but this is actually a nice solution to the problem of
| what to do in your language aware editor when the user
| enters <= : nothing! You just assign to different token
| classes different fonts.
| Chris_Newton wrote:
| To clarify, I'm not talking about ligatures in programming
| fonts here. I'd like to use a slightly wider set of Unicode
| characters, for their designated purposes, as the main and
| only way to write those ideas. This could include
| comparison operators, arrows, maybe a few other common and
| easily recognisable operations.
|
| I would like to use those same characters, and where
| applicable with the same sizes and alignments of related
| characters, everywhere -- in my editor, my linters and
| formatters, my diff tools and version control system UIs,
| my greybeard CLI text file batch processing incantations,
| everywhere.
|
| All that really needs is languages that use Unicode
| characters like <=, fonts that include all the relevant
| glyphs, and tools that provide a simple way to enter those
| characters. But all of these are important, because right
| now we don't have simple, standardised ways of doing these
| things, and so we mostly don't do them at all.
|
| It's obviously not a big deal, just a small "quality of
| life" improvement, but it's 2024 and I don't see any good
| reason why we can't have nice things. :-)
| teo_zero wrote:
| The C committee has just deprecated trigraphs. It might
| be the right time to propose [?] as alternative to != and
| then in 40 years we can deprecate != and only keep [?]
| satiric wrote:
| How would you type those characters? For me (on mobile) I
| have a few options: copy it from your message, or google
| "not equals sign" and copy from the browser, or add a new
| keyboard that contains the character. On my desktop, I
| could also memorize windows' alt+x code... none are
| fantastic options.
| teo_zero wrote:
| On mobile I keep "=" pressed for 1 sec and it allows me
| to type [?] [?] and [?].
|
| On Linux I use the sequence Insert, "/", "=", having
| mapped Insert to act as a Compose key (what other use do
| you have for it anyway?).
|
| On Windows I use the same sequence, having installed
| wincompose by Sam Hocevar.
| alextingle wrote:
| If your editor just blithely replaces tokens in code, then
| your alignments are going to be wrong. We write code in
| monospaced fonts for a reason.
| knallfrosch wrote:
| Everything you say is already possible, and done.
|
| I don't know what Notepad you use to write your code, but
| VSCode with font ligatures (for comparison operators) and a
| linter (aligns the same as elastic tabstops) already does the
| 80% of what you want. The 20% rest - sidebar for documentation
| - are not implemented for a reason.
| tmtvl wrote:
| > _The 20% rest - sidebar for documentation - are not
| implemented for a reason._
|
| I mean, keeping an overview of the documentation open on the
| side is something I do every day in GNU Emacs, so I'm a bit
| curious what the reason is why it's not done in Microsoft VS
| Code.
| zarzavat wrote:
| You can do it in VSCode. It's running in a browser. There
| may extensions to do that or if not you could write one
| easily.
|
| The reason it doesn't come with the editor is because every
| language has its own specific documentation format, though
| I do wish that they could create a consistent set of
| keyboard shortcuts, search UI, etc for documentation.
| Chris_Newton wrote:
| _The 20% rest - sidebar for documentation - are not
| implemented for a reason._
|
| The sidebar to show the documentation is just a presentation
| detail. What I'd really like as a developer is (a) the
| ability to attach documentation with a specific scope ranging
| from small things like a function parameter or variable,
| though larger things like a function or a set of related
| functions, up to whole files or packages, and then (b)
| editors that recognise the scoped documentation and present
| it contextually.
|
| I'd like all relevant comments to be easily visible when I
| might want to refer to them. Also, I'd like to know what
| documentation exists in the first place, which is not always
| obvious when we rely on things like big banner comments at
| the top of files/sections or having separate README files
| scattered through the tree.
| practal wrote:
| I've been thinking for quite some time about how to incorporate
| spacing properly into the syntax of a programming language, and
| I now settled for a simple solution: hard-code blocks of texts
| via spacing into the text format itself. I call the result
| Recursive teXt (RX, http://recursivetext.com), and I am using
| it as the basis for the rest of my work on Practal, instead of
| using just plain text. A lot of issues are resolved with this,
| for example it is trivial to have different kinds of syntax
| live next to each other, as they can just occupy separate
| blocks.
| anta40 wrote:
| "I'd like to use a (somewhat) wider range of basic symbols than
| whatever we had in ASCII last century. Even allowing comparison
| operators like <=, <, [?] and = that align consistently would
| be a useful start"
|
| That's already doable on vim/nvim. BTW, I'm on macOS, and
| install them via macport. Or perhaps because I already
| installed some specific fonts....
| chipsrafferty wrote:
| You can customize the syntax highlighting with 15 minutes to 4
| hours of work, depending on your IDE, languages, and particular
| preferences. If it's important enough to you to rant about it
| online, perhaps you should set a new standard to help others
| that also want syntax highlighting the way you do? And you'd
| also be helping yourself for the rest of time.
| getnormality wrote:
| There's no end of unpopular experiments in double pane formats
| where one pane holds text and the other holds comments,
| footnotes, etc.
|
| They're unpopular because they're confusing and brittle. How is
| the relationship between the two maintained when the developer is
| hard at work, when the text is not just a set piece for pretty
| presentation? No answer is given, because there is none.
| ulbu wrote:
| > No answer is given, because there is none.
|
| case closed, guys, we can all go home now.
| FullGarden_S wrote:
| >How is the relationship between the two maintained when the
| developer is hard at work, when the text is not just a set
| piece for pretty presentation?
|
| The text editor or IDE can provide a feature to show(pop up) or
| hide(collapse) the side comment section when needed while
| formatting the comments to make them look bold or italic.
|
| This will become a quality of life improvement if the
| implementation is done right. If not, it will be very confusing
| as you mentioned. I think writing API documentation can become
| very easy and since the function and its comment/description
| align on the same line, generating API documentation will
| become easy as well.
| preommr wrote:
| There's also the issue of screen real estate. I often have
| other windows (terminal, browser, the build application), and
| panels within the editor (git, file explorer, console, etc.).
| It's already a hassle to maintain all this. It would be even
| more annoying if when I am comparing two code blocks side-by-
| side, there's another view for each of those that I'd have to
| either manually handle, or mentally keep in mind to look for
| something.
| knallfrosch wrote:
| I'm just waiting for an AI-generated audio summary of a code
| section ;) Includes auto-play, of course.
|
| Straight from my horror cabinet of ideas!
| zarzavat wrote:
| It's technically doable, the text in the right pane would be
| stored as comments in the source. The editor would parse the
| comments and collapse them into UI elements in the code, so
| that they could still be copy and pasted e.g. how the little
| blue capsules in Xcode work.
|
| It's a bad idea because it's wasteful of space while achieving
| very little over a conventional setup.
| kragen wrote:
| rougier says that on an 80x24+ vt100 40 years ago margins were an
| unthinkable luxury, but as you can see in any photo of a vt100,
| they actually do normally have margins:
| https://datashark.academy/wp-content/uploads/2018/03/DEC_VT1...
|
| a little thought about how crt displays work suffices to see why
| this is the case. if you carefully adjust your deflection coil
| amplifiers to perfectly align the edge of the text with the
| physical edge of the display tube, you will almost certainly cut
| off the edges of the first or last lines or both
|
| marginless displays are a product of flat-panel displays and
| window systems
|
| i'd like to second the recommendation to look at gravgaard's
| elastic tabstops idea
|
| _____
|
| + 25 actually i think
| keyle wrote:
| It is not clear if these implicit choices derive from the
| ignorance of alternatives or if they derive from developers'
| habits, reproducing what they are used to.
|
| Woah there, easy tiger.
|
| The OG literally invented editing text on computers, and since
| then many novels have been written on keyboards and computers.
| The "text" editors have fed back into the more basic code editors
| and we're in a mixed situation between "comfortable to edit code"
| and "comfortable to edit text".
|
| I'd be interesting to explore more visual programming built into
| text editors, as an overview of code flow, because right now the
| best we have is the direct stack trace. In terms of code it would
| be great to have integrated tools that show a visual
| representation "map" of the functions usage and data flow.
|
| As for regular prose, it would be interesting to see editors
| specializing in poems and other use cases. I know some editors
| specialize in novels by having wiki like features of linking
| characters to storyline and research work.
|
| I'm not sure how much of those are used by real world authors
| though, I think they mostly are trying to get closer to the
| "typing machine" as possible, removing any kind of distraction to
| get the X words per day in.
| Chris_Newton wrote:
| _In terms of code it would be great to have integrated tools
| that show a visual representation "map" of the functions usage
| and data flow._
|
| I agree, though there is a lot of subtlety in this problem. I
| tried, with very modest success, to write a tool that would
| overlay some graphics showing these kinds of information on top
| of a regular code listing.
|
| The results were rather satisfying when the structure to be
| illustrated was relatively simple, as it often is in well-
| written code. However, trying to use those visuals to help
| analyse and understand less well-written code with complicated,
| tangled flows felt like looking at spaghetti code in a very
| literal sense.
|
| Qualitatively it made it obvious when code could benefit from
| some cleaning up, but that isn't very useful information unless
| it also provides useful insight into _how_ to clean the code
| up, and I never really found a style /format for the visuals
| that conveyed enough information to provide actionable insights
| but didn't become so busy in bad cases that it became was hard
| to follow.
|
| _I know some editors specialize in novels by having wiki like
| features of linking characters to storyline and research work.
| I 'm not sure how much of those are used by real world authors
| though..._
|
| I've only had this discussion with one author recently, but
| FWIW, they swear by that kind of structured story planning
| software. I'm not sure how many of the concepts or presentation
| details in those applications would translate readily to tools
| for working with code, though.
| mediumsmart wrote:
| There is only one true editor, the design is flawless and it's
| not number six.
| robinsonrc wrote:
| I tend to prefer the visual mode of Ex
| 082349872349872 wrote:
| ed(1) is for those who can _remember_ what they are working
| on.
| d_tr wrote:
| The author is the creator of the nano-emacs package [1], by the
| way.
|
| [1] https://github.com/rougier/nano-emacs
| dang wrote:
| Thanks! Related:
|
| _Nano Emacs - a set of config files to improve the look and
| feel of Emacs_ - https://news.ycombinator.com/item?id=33403169
| - Oct 2022 (4 comments)
|
| _Emacs Notebook_ -
| https://news.ycombinator.com/item?id=29932274 - Jan 2022 (1
| comment)
|
| _GNU Emacs / N L N O - Emacs made simple_ -
| https://news.ycombinator.com/item?id=29373104 - Nov 2021 (1
| comment)
| rossant wrote:
| (2020)
___________________________________________________________________
(page generated 2024-09-29 23:00 UTC)