4 ms·

Are there any ed users that can speak to what they like about it? I have written ed scripts, but actually using it as an editor just felt like vim but with fog

• agumonkey 3y ago
  I like fog of war, it keeps me sharp
• Ferret7446 3y ago
  It works in dumb terminals. A notable side effect is that it lets you see previous terminal output so you can reference it while you're editing, and use Ctrl-Z and fg to swap back and forth. (Although usually I prefer to run my shells in Emacs instead)
• PhilipRoman 3y ago
  I've used it once on an embedded device, which had neither ssh nor telnet. Luckily, it had bash available, so I set up something like this: /bin/bash <> /dev/tcp/... With netcat listening my side. Most things kind of worked (no way to send ctrl-c though) but vi couldn't properly redraw it's screen. So I had to use ed.
• geocar 3y ago
  I don’t edit files for no reason, so the context of what I am doing is lost when a screen editor takes over the window; ed/ex keeps that on-screen, which keeps quick edits quick. I also like being able to see my changes as I work.
  • avgcorrection 3y ago
    This could be pretty useful for writing shorter commit messages (even up to a subject + paragraph). Like a more powerful `cat`.
• pram 3y ago
  Well, it is the standard text editor after all.
• sidju 3y ago
  The original inspiration was part annoyance at how badly most editor's keybindings map to dvorak and part how modern editors sometimes crash. With a command based editor you just type commands, no fancy keybindings that get jumbled when you have a different layout. (And I have plans for writing fired, which is basically hired with a window to see the state of the buffer. It would still be strictly command based though, so not a vim remake.)
  • sidju 3y ago
    Oh, yes. I find ed to be excellently usable since the most common code editing operations are (in my perception) well supported in ed: - moving or copying chunks of code (`m` and `t` commands) - deleting or replacing chunks of code (`d` and `c`) - writing new code (`a` and `i`) - renaming stuff (`s` and `g`) - and rarely, small edits to existing code (`s` and `C` in hired) As long as you write your code with plenty line-breaks it is often easy to just replace a line to make the change you want, so `s` and `C` are rarely needed (though I am weak and tend to use `C` quite often, for example to get the indentation right when adding lines).
• cturner 3y ago
  It is useful when you have typed some commands, and then want to edit a text file without losing the text. Consider if you are working on text that you will want to copy+paste into a jira/bugzilla ticket as an evidence-of-work. Or if a second person is watching your screen as you work. It is useful when you are operating over a high-latency connection. As long as you do not send newline by mistake, you can form the command you want to dispatch with confidence. You do not have to worry about where your cursor is, and you won't find yourself in an unexpected mode, or having done the wrong number of undos or redos. For a while I used it to write C for a hobby-project on the train, using an android phone and screen keyboard. Simple keypresses are easier than control characters in that setting. If you are interacting with a remote unix system from an ipad, you may find it useful for the same reason. About once a year I find it useful in situations where I have some kind of broken or low-function TTY, or library problems and want to make an edit. At times, it would be useful to have an ed-like mode available in bash, so that you could have access to an editor when your system was preventing you from spawning new processes.
• soveran 3y ago
  I use it daily. I run a slightly modified version: I added line editing capabilities with linenoise and I use EREs. The most common use case for me is editing with :g/re, which allows me to see only the matching lines. If I want to keep only those lines, I type :v/re/d, and so on. I also invoke it regularly from my main editor when I find it more efficient for modifying some file or some region.
• mbivert 3y ago
  Not a user, but I've decided at some point to use it to write a `.tex` report. Insightful experience: (i) fixing mistakes is costly: one needs to think more/be more cautious; (ii) one needs to grow a "mental image" of the codebase; (iii) which encourages to be more regular and austere/simpler, while training memory; (iv) the lack of features encourages creativity, e.g. using "good" regexps to navigate the code; a common example is for C functions to be essentially uniquely identified with `^foo\(`, when the functions are defined with: int foo(…) { … The dumber the tool, the more intelligent the user has to be, and reciprocally. Of course, there are practical limits; that's just the general idea.