[HN Gopher] Mle is a small, flexible, terminal-based text editor...
___________________________________________________________________
Mle is a small, flexible, terminal-based text editor written in C
Author : AlexeyBrin
Score : 88 points
Date : 2022-10-01 11:50 UTC (11 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| mysterydip wrote:
| How do I say it? mlee? mleh? mlay? em-el-ee?
| printf_alex_ wrote:
| I'm a "mleh" person
| onlyrealcuzzo wrote:
| I think it's supposed to be Emily.
| drekipus wrote:
| Melee
| Aperocky wrote:
| Looks much like vim, what's the differentiation?
|
| vim is also super extensible with plugins - one of the biggest
| reason to use it.
| forgotpwd16 wrote:
| It isn't anything like vim since it doesn't utilize a modal
| paradigm. Rather what mle means with modes is different keymaps
| depending on context, i.e. replace grep with git grep if .git
| exists. If you want to compare to something else, it can said
| it's a more advanced (aforementioned keymaps, splittable
| windows, and others) Lua-extensible nano.
| ghosty141 wrote:
| My guess is the idea is that you can easily extend and
| customize it since the code base is kept small and simple (10k
| loc seems quite neat).
|
| I'm personally not the crowd who'd use this kind of software.
| My preference is emacs which has a different philosophy when it
| comes to "hacking" the editor.
|
| This project might be something for the suckless crowd.
| frou_dh wrote:
| I saw this editor recently as a consequence of noticing that
| there seems to be a rewrite of the _termbox_ library (ncurses
| alternative) in progress: https://github.com/termbox/termbox2
| haunter wrote:
| Love when projects use asciinema to show a quick demo. It's
| incredibly useful tool
| kazinator wrote:
| A better alternative is to record the window with a screen
| recorder. Here is why, point by point:
|
| * You get a video in a standard container and modern
| compression format you can host anywhere, and edit with video
| editing tools.
|
| * Screen recorders can capture the microphone too, so you can
| explain what you're doing.
|
| * Importantly, they can also capture the mouse cursor, which is
| useful even in a demo of a TTY app that has no built-in mouse
| support, because you can point to things in the terminal and
| highlight them as you speak. Mouse-based copy and paste actions
| are easier for the viewer to follow when there is a cursor.
|
| * Everything you see is captured, pixel for pixel (other than
| very very fast, fleeting actions that are quicker than the
| frame rate, obviously).
|
| * If in the demo you need to scroll up through the TTY history
| with the scrollbar or Shift-PgUp, that is all nicely captured.
| Your scrollbar is included in the video.
|
| I can't recommend asciinema becuase while the tools to record
| TTY sessions are free, the animated rendering is done by
| uploading to the website. There are ways to self-host
| asciicast, but that looks like a huge PITA compared to a video
| file you can send to someone as a mail mail attachment, drop
| into a Slack channel, or put into a shared file directory. I
| don't want to become a host to give someone a file.
|
| I tried alternatives to asciicast like ttystudio; they are all
| a hassle compared to even the most basic screen recording app
| like kazaa on Ubuntu, and lose on all the above points. But at
| least some of the alternatives give you a GIF file you can put
| anywhere.
|
| Some work by simulating an ANSI terminal internally, rendering
| it to pixels and taking snapshots of that state --- which is
| just a form of screen recording!
|
| I would say it's fair to TTY specific recording an anti-
| pattern. It seems cool and everyone is doing it, until they
| slap themselves on the forehead one day.
| ducktective wrote:
| that reply....omg! kazinator is a man of focus, commitment
| and sheer f*king will
| dbttdft wrote:
| What's with the hacker community and their obsession with a
| terminal emulator? You're just writing to a framebuffer when you
| call printf. You may as well cut out the middleman and get
| better, more responsive controls and rendering of a GUI (and
| let's not pretend this application is not a GUI). I prefer nedit,
| just wish it would support Unicode. Or maybe I don't and Unicode
| should just stop existing. I also notice nedit has less input
| latency than vim on most terminal emulators.
| pjmlp wrote:
| They are easier to implement than yet another X Windows clone,
| so that is why, they go with the easier path.
| stjohnswarts wrote:
| there's xnedit, but I think you'll have to compile it yourself.
| I only had to do "apt install libmotif-dev" to get it to build
| with "make linux"
| benreesman wrote:
| Decoupling the machine where you do the edit/build/run cycle
| from the machine where you get your key presses and mouse
| movements processed has a number of advantages in the general
| case and is practically non-negotiable in a subset of cases.
|
| By having my editor (and the LSP servers, etc.) running on a
| different machine I can afford to have it be a big, high core
| count Linux machine maybe with GPUs in it that is arbitrarily
| hot or loud or heavy. For many languages (C/C++, Haskell, Rust,
| there are others) either the build or the go-to-definition or
| some other frequently-done thing are slow on even the best
| laptop / quiet PC.
|
| By having the client machine be an appliance running a terminal
| emulator, my colleagues and I can be indifferent to one
| another's choices in desktop environment: there can be Mac
| people and Windows people and desktop Linux people etc. In my
| case I can have a slim little MacBook Air that can drive a big
| display, play sound properly out of the box, wake/sleep
| properly out of the box, and otherwise get out of the way while
| I work on the "real" computer, which can be anywhere with a
| manageable ping from here.
|
| There are disadvantages too: mostly that networks go down, GUIs
| are nice for some things, and others. It's not a free lunch.
|
| It's a tradeoff (and I'm aware that it's surprising to many
| that regular computers still aren't fast enough for many
| hackers), buts it's not just Luddism.
| fpoling wrote:
| One can run GUI editor just as well either directly via ssh
| -Y or via VNC. So this is not an argument for a terminal
| editor.
| jbverschoor wrote:
| Terminal / monospaced font gives a lot of calmness to your
| screen. It also forced you to think about keyboard shortcuts
| and controls in general.
| 9dev wrote:
| But why would I want to think about keyboard shortcuts and
| remember controls, if we can have better, self-discoverable
| interfaces rather than something designed in the 1970ies?
| [deleted]
| jbverschoor wrote:
| Doesnt have to be shortcuts. You know where the items are.
| Press menu -> 3x down, enter, enter, tab, tab, type
| something, done. Compare that to the same by mouse.
|
| This is why old cashier systems are so super fast.
| chrsig wrote:
| I find they're _very_ different parts of memory. Keyboard
| shortcuts live in your hands -- they 're muscle memory.
|
| Trying to remember where some option in a cluttered
| dropdown menu you used 20 minutes ago is working memory,
| something I'm personally terrible with. It's either
| whiplash out of a flow state, or risks sidetracking me.
|
| It takes practice to build muscle memory, but it's
| something that generally stays with you for a long time, so
| it's an investment.
|
| The point is that you _don 't_ think about keyboard
| shortcuts. You just think about the thing you need to do,
| and let your hands do it.
| pjmlp wrote:
| I have already done enough of it since Timex 2068 was
| considered modern.
| hobo_mark wrote:
| You might not have the luxury of a GUI in many (most?)
| production (or staging, for that matter) environments.
| 9dev wrote:
| Because what, you sit in the server room with a monitor
| plugged into the rack and work on production code?
|
| If something can open a shell remotely, it can show a GUI
| remotely.
| quesera wrote:
| > If something can open a shell remotely, it can show a GUI
| remotely.
|
| Secure servers do not include GUI packages. They are
| enormous, require elevated privileges, and have a poor
| security history.
| pjmlp wrote:
| And secure containers also don't allow shell access, so.
| quesera wrote:
| There are gradients of "secure" in servers.
|
| No reasonably quasi-secure server in the last 25 years
| has included GUI packages, but has allowed and often
| depended on shell access.
|
| Modern deployment regimes which include ephemeral
| instances sometimes do not permit shell access.
|
| These are not the same things!
| Kwpolska wrote:
| Should you be spending a lot of time in the production
| environment though? Also, in many places, the list of things
| you can do in the production environment is quite short
| (viewing logs or reconfiguring things), because the app runs
| off a Docker-or-whatever container and is written in a
| compiled language (so you can't just hack together a bugfix
| in vim on the production server).
| ziml77 wrote:
| This explanation doesn't do it for me because you also
| wouldn't be able to run any text editor you like. Basically
| you're going to be using vi (or possibly vim or nano). It
| also shouldn't be a daily activity to be poking around
| directly on a production machine, and if it is then why not
| setup something like sshfs and use a local text editor on the
| file? Then you can use whatever GUI or TUI editor you'd like.
| petee wrote:
| If you're not poking around often like you say, then
| something like vim is more than acceptable. And some people
| prefer that to a gui editor anyway.
| karteum wrote:
| > What's with the hacker community and their obsession with a
| terminal emulator?
|
| Because unlike web apps, terminal apps are often fast (and even
| faster when the terminal has HW acceleration, see for example
| https://alacritty.org). Unlike native GUIs, they can easily go
| through a low-bandwidth network connection (e.g. ssh). They are
| often portable and can be easily made stable without a huge
| stack of dependencies.
| eikenberry wrote:
| Terminal emulators, IMO, have 2 big reasons they are popular.
| First is that they work like a better, more stable web browser
| in the sense that they provide a standard platform to develop
| UIs on. Second is that the command shell is arguably the best
| general purpose UI we have for computers today and it lives in
| the terminal.
| c0mptonFP wrote:
| Because our main work environment is the shell..? Writing code
| in a terminal is seamless and fast, and it fits very well in a
| tmux workflow.
| pjmlp wrote:
| Mine is the IDE and whatever a shell can do, a language REPL
| does X times better.
| amelius wrote:
| > Favor simplicity over portability
|
| Not sure if I'd go with that one.
| forgotpwd16 wrote:
| Unless you plan to run it on some exotic Unix, why you'ld
| prefer portability over simplicity?
| kazinator wrote:
| How about:
|
| For an interactive program, favor simplicity over portability
| to more than a handful popular platforms that people are
| actually using.
|
| Do not favor simplicity over portability to more than one
| platform. (Feel free to ignore this if you work for
| Microsoft, as the maintainer of calculator.exe, and similar
| work.)
|
| Definitely favor simplicity over portability to systems that
| use sign-magnitude integer representations, or have 36 bit
| words and 9 bit bytes, or binary files that add extra zeros
| to pad your file to a full sector, or have no POSIX or
| Windows API whatsoever, or whose null pointer is not an all-
| zero bit pattern, ... even if your program runs on some
| computer they have in the basement of the Smithsonian, they
| are not going to to risk installing it there, and if they do,
| nobody will use it.
| [deleted]
| rkta wrote:
| > Stackable key maps (modes)
|
| Does this mean I can have a vi-like experience, but I have to
| configure it myself? A quick look into the help page of mle was
| not very helpful.
| KMnO4 wrote:
| Modes doesn't mean Vi-like; just that you can have multiple
| commands on the same bindings.
|
| The power of Vi is in the grammar. It's fairly intuitive to
| combine motions with verbs, and you can string together chains
| of commands without much thought.
|
| For example, "04wd$VU" would uppercase the first four words in
| a line and delete the rest of the line.
|
| I don't think something like that would be achievable with the
| basic key mapping that Mle has.
| jbverschoor wrote:
| I always liked the way Borland C++, Power Menu, and Norton
| Commander worked.
| hobo_mark wrote:
| Does there exist a terminal-based editor with VS Code shortcuts?
| 90% of the time all I want is the multi-cursor mode (Ctrl-D etc).
|
| Vim colleagues insist I could just write macros, yeah no.
| Brian_K_White wrote:
| "I want X"
|
| "Here you go"
|
| "Yeah no"
| gilnaa wrote:
| "I want X" "Here's Y" "Yeah no"
| amadeuspagel wrote:
| > The default key bindings are intuitive. Input text as normal,
| use directional keys to move around, use Ctrl-S to save, Ctrl-O
| to open, Ctrl-X to exit.
|
| Ctrl-X to exit is not intuitive. That's used to cut text almost
| everywhere. Instead, use Ctrl-Q (quit).
|
| It's been 35 years since CUA[1]. Another terminal editor,
| micro[2], already adopted these conventions--Ctrl-C to copy,
| Ctrl-X to cut, Ctrl-V to paste--other terminal editors should as
| well.
|
| [1]: https://en.wikipedia.org/wiki/IBM_Common_User_Access
|
| [2]: https://micro-editor.github.io/
| Andoryuuta wrote:
| From my perspective of using nano for all simple text editing
| on linux, ctrl-X to exit seems very intuitive to me.
|
| Plus it's even used in that one famous Matrix scene[1] where he
| is trying to close out of whatever he sees open on his
| computer. ;)
|
| [1]: https://youtu.be/sjoad6gcRzs?t=31 (31 ~ 50s)
| amadeuspagel wrote:
| But nano doesn't use Ctrl-S to save and Ctrl-O to open, so
| Mle already breaks with nano.
| sigzero wrote:
| Nano should not be the "standard" as that community is small.
| 9dev wrote:
| Is it, though? I'd argue that nano is the most accessible,
| easily discoverable, and usable editor _for simple text
| editing_ available on almost any Linux system out there.
|
| It's no IDE, but it never claimed it was either. It doesn't
| require a manual, as even the shortcuts are shown at the
| bottom of the screen for reference. And it includes syntax
| highlighting, tab handling, and basic cut/copy/paste
| handling.
|
| What is it you're missing from a standard text editor?
| janderland wrote:
| When I moved from Win to Linux (as a beginner
| programmer), nano was my go to for quick edits in the
| terminal. Then I found vim....
| quesera wrote:
| > Ctrl-C to copy, Ctrl-X to cut, Ctrl-V to paste--other
| terminal editors should as well.
|
| Blasphemy. Especially in a terminal environment.
|
| Ctrl-C has meant "Interrupt" since the 1960s.
|
| IBM and MSFT decided to bastardize the Macintosh's Cmd-C into
| Ctrl-C for "Copy", but this is a historical tragedy that should
| not be propagated.
|
| Ctrl-S means "XOFF ~(Pause output)", and Ctrl-Q means "XON
| ~(Resume output)".
| pjmlp wrote:
| Back in those days Mac OS didn't had a terminal, unless for
| developers using MPW.
| quesera wrote:
| But Mac OS (Xerox PARC) invented cut/copy/paste/undo, and
| defined the keys to be Cmd-X/C/V/Z. Instead of trodding
| upon well-established conventions (including those in use
| in the Apple II-][-// world), they made their own new ones.
|
| Microsoft didn't make their own keyboards (at the time), so
| was at a bit of a disadvantage when they copied the
| functionality from Apple. They didn't have to choose Ctrl,
| but they apparently decided that multitasking and job
| control were the domain of non-personal computers and not
| their problem.
| alpaca128 wrote:
| > Ctrl-C has meant "Interrupt" since the 1960s.
|
| Terminal != Terminal application
|
| Would you really want your SSH connection or editor session
| with unsaved changes just exit after pressing one key
| combination? Interactive applications have different
| requirements than a commandline with much more limited
| inputs. There's no reason to be against Ctrl-C for copy in a
| text editor.
| quesera wrote:
| ssh is a transport method. Of course it should not
| interpret in-line application commands.
|
| xterm should also not respond to an application command.
|
| An editor is an application, and it should respond. You can
| choose to handle interrupts instead of immediately exiting
| of course. But the meaning is intact.
|
| A well-behaved application in a POSIX environment will not
| fight the well-established conventions. There are many
| reasons for this, but the two most obvious are:
|
| - The implementation of the expected behavior might be
| outside of your control. Try pressing Ctrl-S in some
| terminals, and you will find that it does not reach the
| application because flow control is handled at a lower
| layer. By convention.
|
| - Just don't abuse your users! If they get accustomed to
| using the non-standard Ctrl-C for copy, and then use that
| same action in another application, they might lose data
| and it will be your fault.
| amadeuspagel wrote:
| > If they get accustomed to using the non-standard Ctrl-C
| for copy, and then use that same action in another
| application, they might lose data and it will be your
| fault.
|
| That ship has sailed. Today, most people are accustomed
| to using Ctrl-C to copy.
| quesera wrote:
| > Today, most people are accustomed to using Ctrl-C to
| copy.
|
| That is not true, in the relevant context: that within
| which this software is released.
| otikik wrote:
| I am a heavy terminal user and I am fine with an editor using
| ctrl c,x,v and for copy,cut,paste. It isn't "Blasphemy",
| there's plenty of ways to send a signal to a process if you
| really need that. It's an editor. Let's chill a bit.
| jcelerier wrote:
| What a something means is defined by how many people use it
| for a given definition. If tomorrow half the earth starts
| saying "fork" for knife then that is what "fork" will mean -
| the ratio for ctrl-c meaning copy vs its Unix meaning is even
| stronger. Being there first has exactly zero importance
| kazinator wrote:
| > _What a something means is defined by how many people use
| it for a given definition_
|
| Ctrl-C means interrupt to everyone in Unix, since the dawn
| of Unix.
| quesera wrote:
| > What a something means is defined by how many people use
| it for a given definition.
|
| Only in context.
|
| I don't really care what Windows people do with their Ctrl
| keys.
|
| But using Ctrl-C for copy in a terminal environment (from
| TOPS-20 to Linux and macOS, and whatever MSFT calls its
| captive Linux env) is wrong.
|
| It is wrong because Ctrl-C already performs another
| critical (more important) system function. It can't do
| both, and forking (knifing?) up the UI to have it do
| different things is a mistake.
| fnordpiglet wrote:
| Sometimes standards emerge rather than from formal bodies
| but by broad experience and consensus. The Microsoft
| operating systems dominated human experience for decades.
| I'm sorry that other systems did different things, but on
| the basis of cumulative human experience, these key
| bindings are in fact standard. Any variance, no matter
| how ideologically pure, is opposed to the collective
| human experience of cut and paste key bindings. Why do
| that to people? Because of some market outcomes from 30
| years ago didn't go the way you prefer so we should
| impose confusing experiences on everyone? That's
| audacious.
| quesera wrote:
| This is silly.
|
| Ctrl-C for copy is not a standard in the UNIX/POSIX
| terminal environment, and it cannot become so, due to the
| preexisting meaning. Any other usage in that context is
| wrong and will fail.
|
| Your bias is in your experience too. There may be more of
| you than there are of me, globally, but your language (UX
| expectations) is not universal, and will fail in other
| places.
| torstenvl wrote:
| > _Ctrl-C for copy is not a standard . . . and it cannot
| become so, due to the preexisting meaning._
|
| This is a non-sequitur. Standards change all the time,
| even things with a preexisting meaning.
|
| I also seriously doubt you believe it yourself. You
| brought up the example of Ctrl-Q earlier. Is it truly
| your position that it's _not possible_ for the standard
| meaning of Ctrl-Q to be something other than XON?
| quesera wrote:
| It is my contention that, in a terminal environment, any
| attempts to redefine the standard meaning of Ctrl-Q as
| something other than XON will fail because it is
| impossible to do so consistently.
|
| Ctrl-Q does not even reach the application in a standard
| terminal configuration. It is possible to configure the
| terminal to allow it, of course, and some existing
| applications do so.
|
| However, it will not become "standard" because it cannot
| be ubiquitous, or even common except in certain classes
| of application.
|
| And what would you do with Ctrl-Q? Quit? Ctrl-C has you
| covered there (retroactive mnemonic: "Cancel").
|
| So don't bother trying to redefine Ctrl-C either, you
| will only cause unnecessary pain for your users, and
| adoption hassles for your software.
|
| Windows users are not your target market for terminal-
| based software. So instead of inventing your own creole
| Esperanto patois, just speak the local language!
| torstenvl wrote:
| Thank you for confirming.
| Kamq wrote:
| Exactly, and this is a generally posix terminal application
| (windows only under cygwin/wsl).
|
| Let's ask users of the unix style terminal what ctrl-c
| means there.
| fnordpiglet wrote:
| But a text editor is not an interactive operating system
| repl for controlling jobs and files. Why would it matter?
| I don't think the key bindings in Kerbal Space Program
| have much to do with the key bindings in Factorio either.
| Kamq wrote:
| > Why would it matter?
|
| Because that's the intuitive behavior in the terminal.
| The other programs you listed launch their own window and
| are obviously a different context.
|
| Even things like vim and emacs (the foundational terminal
| editors) will give you a message that ctrl+c doesn't work
| the way you expect (admittedly in emacs you have to hit
| it repeatedly), because it's so expected that it's
| assumed that's what you're going to try.
|
| You can have different behavior with ctrl + c, but it's
| going to be confusing enough that you're also going to
| have to print a message for everyone else.
| MobiusHorizons wrote:
| Because it runs in a terminal, and that's how programs
| are supposed to behave when stdin is a tty.
| fnordpiglet wrote:
| No, that's how certain type of OS launched jobs behave,
| specifically pipes or daemons in foreground. There have
| always been programs that have very different behavior in
| their interaction that do not honor the job control
| binding. Emacs comes to mind, almost all Usenet readers,
| etc.
| amadeuspagel wrote:
| Emacs is a terrific example here, and of course vim as
| well. "How to exit vim?" wouldn't be such a meme question
| if you could do it with Ctrl-C.
| quesera wrote:
| Emacs does nothing when you press Ctrl-C. Try it. Then do
| it again. It isn't "copy"!
|
| And when was the last time you tried pressing Ctrl-C in
| vim?
|
| It's evidently been many years.
|
| Here, I'll save you a few keystrokes: vim
| /tmp/sigh ^C Type :qa! and press <Enter>
| to abandon all changes and exit Vim
| amadeuspagel wrote:
| In fact this proves my point better. "How to exit vim?"
| wouldn't be such a meme question if people tried Ctrl-C.
| quesera wrote:
| This proves only that people like to complain even if
| their complaints are uninformed. We knew that already.
|
| Vim added Ctrl-C messaging because people complained
| about remembering :q.
|
| Anyone complaining about that today is just drafting off
| the historic humor and making a show of their ongoing
| ignorance.
| quesera wrote:
| That is how _all_ launched executables behave, in the
| terminal environment.
|
| After loaded, _some_ executables install their own
| handlers for Ctrl-C. None of them are copy /paste.
|
| Emacs does nothing on a single Ctrl-C, and a double
| Ctrl-C evokes a "this does nothing" message. Vim prints a
| "how to quit" message.
|
| I'm sure you can find an example of a terminal based
| program that does something less reasonable with Ctrl-C.
| I'm _not_ sure you can find an example that treats Ctrl-C
| as copy. But you could certainly write one. You should
| expect people to complain if you do!
| qualudeheart wrote:
| I would just use the emacs defaults.
| t43562 wrote:
| I don't want to be mean. I do notice sometimes that "small text
| editors" have a habit of becoming more and more "fully featured"
| until they're not small anymore.
| bitwize wrote:
| Written in C! I see you like to live... _dangerously._
| Gualdrapo wrote:
| Made me doubt about my fidelity towards vis[0] but then realized
| mle does not have vi-like modal editing.
|
| [0] https://github.com/martanne/vis
| williamstein wrote:
| I randomly stumbled on Vis a week ago and have been pretty
| obsessed with it. It's amazing how little code it is (eg builds
| from source in a couple seconds), and the Lua integration is
| really cool! Also, Vis has really cool structural support for
| multiple cursors. I'm working on a WebAssembly port of Vis...
| [deleted]
___________________________________________________________________
(page generated 2022-10-01 23:01 UTC)