Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.unix.shell > #26850 > unrolled thread

ed __ ___ ________ ____ ______.

Back to article view | Back to comp.unix.shell

Contents

  ed __ ___ ________ ____ ______. Zayd Mohammed <zaydm@172.24.208.1> - 2026-06-08 02:16 +0000
    Re: ed __ ___ ________ ____ ______. Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-08 04:46 +0200
      Re: ed __ ___ ________ ____ ______. cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 13:44 +0000
        Re: ed __ ___ ________ ____ ______. gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-08 14:12 +0000
          Re: ed. cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 19:30 +0000
        Re: ed __ ___ ________ ____ ______. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-08 14:40 -0700
          Re: ed __ ___ ________ ____ ______. groenveld@acm.org (John D Groenveld) - 2026-06-09 00:04 +0000
          Re: ed __ ___ ________ ____ ______. Adam Sampson <ats@offog.org> - 2026-06-09 01:50 +0100
          Re: ed __ ___ ________ ____ ______. Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-09 16:47 +0200
            Re: ed __ ___ ________ ____ ______. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 16:41 -0700
        Re: ed __ ___ ________ ____ ______. Ben Collver <bencollver@tilde.pink> - 2026-06-09 14:27 +0000
      Re: ed __ ___ ________ ____ ______. Eric Pozharski <apple.universe@posteo.net> - 2026-06-08 22:28 +0000
      Re: ed __ ___ ________ ____ ______. Lumin Etherlight <lumin+usenet@etherlight.link> - 2026-06-09 03:25 +0300
        Re: ed __ ___ ________ ____ ______. Daniel Cerqueira <dan.list@lispclub.com> - 2026-06-09 09:47 +0100
          Re: ed __ ___ ________ ____ ______. Joerg Mertens <joerg-mertens@t-online.de> - 2026-06-09 15:53 +0200
            Re: ed __ ___ ________ ____ ______. Daniel Cerqueira <dan.list@lispclub.com> - 2026-06-09 21:00 +0100
            Re: ed __ ___ ________ ____ ______. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 16:29 -0700
              Re: ed __ ___ ________ ____ ______. Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 08:39 +0200
                Re: ed __ ___ ________ ____ ______. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 13:40 -0700
                  Re: ed __ ___ ________ ____ ______. Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-12 16:56 +0200
                    Re: ed __ ___ ________ ____ ______. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-12 15:22 -0700
                      Re: ed __ ___ ________ ____ ______. Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-13 00:58 +0200
            Re: ed __ ___ ________ ____ ______. Daniel Cerqueira <dan.list@lispclub.com> - 2026-07-03 00:55 +0100
              Re: ed Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-03 00:47 +0000
                Re: ed John McCue <jmclnx@gmail.com.invalid> - 2026-07-03 01:32 +0000
                  Re: ed Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-03 04:11 +0000
                    Re: ed Nuno Silva <nunojsilva@invalid.invalid> - 2026-07-03 07:57 +0100
                      Re: ed Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-07-03 09:32 +0200
              Re: ed __ ___ ________ ____ ______. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-02 20:30 -0700
        Re: ed __ ___ ________ ____ ______. Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-09 17:57 +0200
    Re: ed __ ___ ________ ____ ______. John McCue <jmclnx@gmail.com.invalid> - 2026-06-08 22:57 +0000
    Re: ed __ ___ ________ ____ ______. Lumin Etherlight <lumin+usenet@etherlight.link> - 2026-06-09 03:02 +0300
    Re: ed __ ___ ________ ____ ______. gmc@metro.cx (Koen Martens) - 2026-06-09 06:17 +0000
      Re: ed __ ___ ________ ____ ______. Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 06:55 +0000
      Re: ed __ ___ ________ ____ ______. John McCue <jmclnx@gmail.com.invalid> - 2026-06-09 19:44 +0000
        Re: ed __ ___ ________ ____ ______. Top Dead Ctr <tdc@invalid.invalid> - 2026-06-09 14:09 -0600
        Re: ed __ ___ ________ ____ ______. Christian Weisgerber <naddy@mips.inka.de> - 2026-06-09 23:52 +0000
          Re: ed Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-10 00:40 +0000
        Re: ed Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-10 00:38 +0000
          Re: ed John McCue <jmclnx@gmail.com.invalid> - 2026-06-10 22:01 +0000
            Re: ed Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 16:43 -0700
              Re: ed Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 16:50 -0700
              Re: ed cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 23:53 +0000
                Re: ed Eli the Bearded <*@eli.users.panix.com> - 2026-06-11 00:12 +0000
                  Re: ed Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-11 00:55 +0000
                  Re: ed cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-11 02:00 +0000
                    Re: ed Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 19:30 -0700
                      Re: ed cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-11 11:31 +0000
                      Re: ed Christian Weisgerber <naddy@mips.inka.de> - 2026-06-11 15:02 +0000
                Re: ed Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 08:46 +0200
              Re: ed John McCue <jmclnx@gmail.com.invalid> - 2026-06-11 14:28 +0000
            Re: ed cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 23:48 +0000
            Re: ed Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-06-11 00:24 +0000
              Re: ed John McCue <jmclnx@gmail.com.invalid> - 2026-06-11 14:11 +0000
                Re: ed Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-12 00:22 +0000
            Re: ed Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-11 00:53 +0000
              Re: ed Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 09:02 +0200
      Re: ed __ ___ ________ ____ ______. Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-10 11:03 +0100
        Re: ed __ ___ ________ ____ ______. Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 09:12 +0200
          Re: ed __ ___ ________ ____ ______. Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-12 09:44 +0100
            Android editor (Was: ed __ ___ ________ ____ ______.) gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-12 09:03 +0000
              Re: Android editor Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-12 12:01 +0100

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#26915

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 2026-06-11 22:40, Keith Thompson wrote:
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>> On 2026-06-10 01:29, Keith Thompson wrote:
>> [...]
>>>> The par program by default does not format text the way
>>>> Lumin Etherlight does.  They might be using par with options.
>>>> "par -j" formats paragraphs by inserting spaces so the text is
>>>> right-justified. "par -j -w50" does the same, but with 50-character
>>>> lines.  I don't see an option to insert two leading spaces on
>>>> each line.
>>>
>>> (I'm a bit astonished that Vim doesn't natively support that. -
>>> Or does it, and I just don't know about it?)
>> It does, and I didn't know about it either.  "gq" followed by a
>> motion command formats text, possibly using a configured external
>> program.  ":help gq" in vim for more information.  (I've been using
>> key mappings to invoke "fmt" since before I'd even heard of vim.)
>
> Oh, I obviously was unclear. - I had been talking about the
> left-and-right block-alignment; the format we saw in Lumin's post.
>
> 'fmt' does *not* support that functionality. But 'par' *does*.

No I don't think you were unclear.  I use "fmt" rather than
"par" because (a) "par" probably didn't exist when I started
using "fmt" (and I'm not sure "vim" did), and (b) I don't *want*
left-and-right-justified text.  I'm now aware that vim has a built-in
feature for formatting paragraphs, but as Darth Vader would say,
"The intertia is strong with this one".

> Both can be used from within Vi or Vim with its _external filter_
> interface. But both are not *natively* supported in Vi. And 'gq'
> in Vim supports *native* formatting like 'fmt', but not like 'par'.
>
> You can also configure external commands. But my question was about
> a "native" support; because I like editing functions independent
> of environmental support, and I don't like plugins (which would be
> another options for those who think plugins are a good idea).

Quoting the vim documentation:
"""
JUSTIFYING TEXT         *justify* *:Justify* *Justify()* *package-justify*

Vim has no built-in way of justifying text.  However, there is a neat macro
package that does the job.  To use this package, execute the following
command: >vim

        :packadd justify

Or put this line in your |vimrc|: >vim

        :packadd! justify
"""

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#26916

On 2026-06-13 00:22, Keith Thompson wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> On 2026-06-11 22:40, Keith Thompson wrote:
>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>>> On 2026-06-10 01:29, Keith Thompson wrote:
>>> [...]
>>>>> The par program by default does not format text the way
>>>>> Lumin Etherlight does.  They might be using par with options.
>>>>> "par -j" formats paragraphs by inserting spaces so the text is
>>>>> right-justified. "par -j -w50" does the same, but with 50-character
>>>>> lines.  I don't see an option to insert two leading spaces on
>>>>> each line.
>>>>
>>>> (I'm a bit astonished that Vim doesn't natively support that. -
>>>> Or does it, and I just don't know about it?)
>>> It does, and I didn't know about it either.  "gq" followed by a
>>> motion command formats text, possibly using a configured external
>>> program.  ":help gq" in vim for more information.  (I've been using
>>> key mappings to invoke "fmt" since before I'd even heard of vim.)
>>
>> Oh, I obviously was unclear. - I had been talking about the
>> left-and-right block-alignment; the format we saw in Lumin's post.
>>
>> 'fmt' does *not* support that functionality. But 'par' *does*.
> 
> No I don't think you were unclear.  I use "fmt" rather than
> "par" because (a) "par" probably didn't exist when I started
> using "fmt" (and I'm not sure "vim" did), and (b) I don't *want*
> left-and-right-justified text.  I'm now aware that vim has a built-in
> feature for formatting paragraphs, but as Darth Vader would say,
> "The intertia is strong with this one".

Then we were (and probably still are!) talking at cross purposes.

I had been asking for a built-in 'par' like function; there isn't
one. (And I thought you had been trying to support my request with
the hints to 'fmt' in your post. - So *I* probably misinterpreted
your post as being an answer to my question.)

I also don't like block-formatting for posts. But it's useful for
specific purposes, and since it's an common editing/presentation
task it should (as Vim's 'gq') be a Vim built-in, in my opinion.

('gq' I'm actually using with Vim already for a very long time.
It's very useful and easy to type and use.)

> 
>> Both can be used from within Vi or Vim with its _external filter_
>> interface. But both are not *natively* supported in Vi. And 'gq'
>> in Vim supports *native* formatting like 'fmt', but not like 'par'.
>>
>> You can also configure external commands. But my question was about
>> a "native" support; because I like editing functions independent
>> of environmental support, and I don't like plugins (which would be
>> another options for those who think plugins are a good idea).
> 
> Quoting the vim documentation:
> """
> JUSTIFYING TEXT         *justify* *:Justify* *Justify()* *package-justify*
> 
> Vim has no built-in way of justifying text. 

Vim has 'gq' formatting natively; see point 3. below (:help gq).

     gq{motion}    Format the lines that {motion} moves over.
                   Formatting is done with one of three methods:
                   1. If 'formatexpr' is not empty the expression is
                      evaluated.  This can differ for each buffer.
                   2. If 'formatprg' is not empty an external program
                      is used.
                   3. Otherwise formatting is done internally.

In my standard Vim environment, the settings of 1. and 2. are empty.
So internal (native) formatting is used.

> However, there is a neat macro
> package that does the job.  To use this package, execute the following
> command: >vim
> 
>          :packadd justify
> 
> Or put this line in your |vimrc|: >vim
> 
>          :packadd! justify
> """

Yes, and this is plugin! - I said that I don't like to use plugins.
I use Vim *natively* with what it comes; it's extremely powerful as
it is already, and I want to avoid dependencies like external 'par'
commands or any plugins!

I've got an answer to my original "native block-formatting question"
("Or does it, and I just don't know about it?") also from the Vim
mailing list:

     There is no built-in command but there is a plugin distributed
     with vim. See ":help justify".

So I'm fine with my curiosity about that. And we can close the topic
(at least as far as my question goes). :-)

Janis

[toc] | [prev] | [next] | [standalone]

#26928

[Multipart message — attachments visible in raw view] — view raw

Joerg Mertens <joerg-mertens@t-online.de> writes:

> Daniel Cerqueira <dan.list@lispclub.com> writes:
>
>> Lumin Etherlight <lumin+usenet@etherlight.link> writes:
>>
>>>         Perhaps, better  yes.  But if one  editor is
>>>   worthy of being discussed in comp.unix.shell, it's
>>>   ed, because ed is almost completely useless if not
>>>   for the shell.  I spell  check in ed by calling to
>>>   a shell  program !aspell %,  I format the  post by
>>>   doing the same !par, when  I want a calendar in my
>>>   task file  I !cal, etc. etc.   Personally, I think
>>>   ed  is  the  only  editor that  follows  the  UNIX
>>>   philosophy closely, it applies  edits to text, and
>>>   it does so very well.
>>>
>>>   When I want to edit text, ed is my shell.
>>
>> I love the way your text is formatted.  Lumin, how have you formatted
>> the text above? :-) .
>>
>> I do use GNU Emacs, and I think you made a good argument for 'ed' in me.
>> If anyone here know how to format like the text above, but in GNU Emacs,
>> I would like to know how.
>
> Daniel wrote that he uses a program called "par" to format his texts.
> You should be able to use it in emacs, too.  Just mark your text and
> type
>
> C-u M-| par <ENTER>
>
> assumed "par" is installed on your system.

Actually, 'par'  is not giving good  results, so I stopped  using it (it
was recommended to  me) and, by contrast,  I started using C-u  M-q on a
middle of a paragraph  text, to do the job I was  trying to achieve with
'par'.

M-q is  the 'fill-paragraph'  function.  With a  prefix (C-u  before the
call) it justifies and fills the paragraph.

-- 
A little Consideration, a little Thought for Others, makes
all the difference. ~ Alan Alexander Milne

[toc] | [prev] | [next] | [standalone]

#26929 — Re: ed

On Fri, 03 Jul 2026 00:55:34 +0100, Daniel Cerqueira wrote:

> M-q is the 'fill-paragraph' function.

And a very versatile one it is, too. It copes with indented text,
preserves quoting or comment prefixes, and also helpfully removes
redundant spaces. ;)

[toc] | [prev] | [next] | [standalone]

#26930 — Re: ed

Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
> On Fri, 03 Jul 2026 00:55:34 +0100, Daniel Cerqueira wrote:
> 
>> M-q is the 'fill-paragraph' function.

I use this a lot :)

> And a very versatile one it is, too. It copes with indented text,
> preserves quoting or comment prefixes, and also helpfully removes
> redundant spaces. ;)

A little warning about M-q.  In GNU Emacs 30+, the scratch
buffer's M-q is redefined to something else.  If you want
to use 'fill-paragraph' in the scratch buffer you may
need to add these to ~/.emacs:

;; Map M-q in *scratch* buffer
(add-hook 'lisp-interaction-mode-hook
(lambda ()
(local-set-key (kbd "M-q") 'fill-paragraph)))

FWIW, I tend to use 'fill-paragraph' a lot in scratch.

-- 
[t]csh(1) - "An elegant shell, for a more... civilized age."
                        - Paraphrasing Star Wars

[toc] | [prev] | [next] | [standalone]

#26932 — Re: ed

On Fri, 3 Jul 2026 01:32:46 -0000 (UTC), John McCue wrote:

> A little warning about M-q. In GNU Emacs 30+, the scratch buffer's
> M-q is redefined to something else.

I didn’t notice this (running Emacs 30.2, since that’s what was in
Debian Unstable on my last upgrade), because I run with Emacs’ entire
mode system disabled.

> FWIW, I tend to use 'fill-paragraph' a lot in scratch.

So do I.

Oh, and I also added a buffer-protection mechanism, because I have a
shortcut (super-W) for closing the current buffer, and I was losing
the scratch buffer too often from this. ;)

[toc] | [prev] | [next] | [standalone]

#26933 — Re: ed

On 2026-07-03, Lawrence D’Oliveiro wrote:

> On Fri, 3 Jul 2026 01:32:46 -0000 (UTC), John McCue wrote:
>
>> A little warning about M-q. In GNU Emacs 30+, the scratch buffer's
>> M-q is redefined to something else.
>
> I didn’t notice this (running Emacs 30.2, since that’s what was in
> Debian Unstable on my last upgrade), because I run with Emacs’ entire
> mode system disabled.
>
>> FWIW, I tend to use 'fill-paragraph' a lot in scratch.
>
> So do I.
>
> Oh, and I also added a buffer-protection mechanism, because I have a
> shortcut (super-W) for closing the current buffer, and I was losing
> the scratch buffer too often from this. ;)

After spending way too long dealing with the consequences of *scratch*
not being backed up, I went with this:

    (setq initial-buffer-choice "/home/[...]/scratch.org")

The point being that I use the initial buffer more for quick
note-keeping that ought to be transitory until saved in a more
appropriate fashion, but I kept getting bitten by bugs of the following
species - not saying it happened often enough, but still it happening
once an year or so would pose an issue:

* Drosophila Segmentationum Faltum

* Aedes Blackoutitis


Now more seriously, the point here is that, if that buffer is backed by
a file, it does get auto-saved and can be restored to at least a
somewhat recent copy in case of an improper Emacs shutdown.

If you rely on it for Elisp interaction, I suppose you could as well as
make it an Elisp file. I have the following, but I'm not sure the mode
still needs to be set after the buffer is set to open a file matching
.*\.org:

    (setq initial-major-mode 'org-mode [...] )

Now I'm not sure this matters at all with a shortcut to close the buffer
- but I suppose that, if it's a buffer with a file, it may prompt you
before killing it? (It'd otherwise not protect as much as your
protection, I guess, because there'd still be a gap between the last
auto-save and it being killed?)

(Meanwhile, I set Emacs on Android the same way, so I can start typing
notes in the buffer it opens when it starts, and just do C-x C-s,
without having to open a file first.)

-- 
Nuno Silva

[toc] | [prev] | [next] | [standalone]

#26934 — Re: ed

On 2026-07-03 08:57, Nuno Silva wrote:
> [...]
> 
> The point being that I use the initial buffer more for quick
> note-keeping that ought to be transitory until saved in a more
> appropriate fashion, but I kept getting bitten by bugs of the following
> species - not saying it happened often enough, but still it happening
> once an year or so would pose an issue:
> 
> * Drosophila Segmentationum Faltum
> 
> * Aedes Blackoutitis
> 

A vimcination with linucillin is known to help against all that.

> 
> Now more seriously, [...]

Nah!

Janis :-)

[toc] | [prev] | [next] | [standalone]

#26931

Daniel Cerqueira <dan.list@lispclub.com> writes:
[...]
> Actually, 'par'  is not giving good  results, so I stopped  using it (it
> was recommended to  me) and, by contrast,  I started using C-u  M-q on a
> middle of a paragraph  text, to do the job I was  trying to achieve with
> 'par'.
>
> M-q is  the 'fill-paragraph'  function.  With a  prefix (C-u  before the
> call) it justifies and fills the paragraph.

And the result is that your paragraphs have extra spaces inserted
just to make the text both left- and right-justified.

My advice is to drop the prefix and fill the paragraphs *without*
right-justifying them.  Right-justified lines are fine with
variable-width fonts, but with fixed-width fonts I find them
distracting and unhelpful.  (Note that you are almost the only
person who posts like this.)

I know I've mentioned this before.  I'm not planning to do so again.
And thank you for left-justifying your text.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#26868

On 2026-06-09 02:25, Lumin Etherlight wrote:
> Janis  Papanagnou  <janis_papanagnou+ng@hotmail.com>
> writes:
> 
>> 'ed'  is  _a_  standard text  editor;  on  Unixes.
>> Though a very primitive one.
> 
>    It is indeed primitive, in the way a chisel is.
> 
>> (I wonder why one would make ones life harder than
>> necessary.)
> 
>          It is not harder with  ed.  As a user of ed,
>    who also  used emacs  and vim  for over  a decade,
>    (and many others) I don't view ed as a lesser tool
>    that is "behind" "modern" editors, I think ed is a
>    different mindset for editing, in the same vain as
>    vim being different from Visual Studio.  If a user
>    of Visual Studio says in relation to learning vim:
>    "Why make  one's life harder than  necessary", the
>    answer would  be very similar.  It  is harder only
>    because it didn't "click" for you yet.

These comparisons ignore some facts and put others in
one bag in an undifferentiated way. I disagree in most
of what you say here.

Line oriented editing (with 'ed' or 'ex' mode of 'vi')
is different from editing larger/other entities of text.
(You may not have used those "higher-level editing" in
your time of Vi/m (or Emacs) use, I have to presume. If
you'd have done you'd probably have missed them after
your switch back to a more primitive form of editing.)

Note that I'm not saying that you couldn't do a lot of
things in line oriented mode, or in sections that are
identified by ranges (lines or patterns). There's even
things that we can do only in ex-mode of vi.[*]

And as a valid sensible comparison of 'ed' and 'vi' the
only true point is pointing out the equivalences of Vi's
'ex'-mode and 'ed'.

For me an editor is "harder" (to fulfill some task) if I
need much more key-strokes, and/or if I have to switch
to the mouse or use menus, etc., or if I just cannot do
the editing with a specific tool. And I'm only speaking
about editing here, not about any IDE-functions or other
functionality outside editing.

(Your comparisons with the MS products make no sense to
me when it's about efficient editing. - I wouldn't start
an argument and won't follow your attempt.)

> 
>> Is that the reason why the formatting of your post
>> is corrupt?  (Or is it your newsreader settings?)
> 
>          Unlikely.  I'm also writing  this in ed, and
>    I don't think my formatting will be corrupt :)

To be frank, I also haven't expected that. Neither that
the 'slrn' would produce such results; quite some use
that newsreader and create clean posts. I was teasing!
But thanks for the confirmation.

(Though I'm still a bit curious what the actual reason
for his malformed post was.)

> 
>> Vim  is  not  based   on  the  Vi  code  base. But
>> functionally  yes,  mostly.   And you  won't  gain
>> anything  if  trying  to  somehow  relate  Vim  to
>> Ed;  these are  functionally completely  different
>> things.
> 
>          Vim, perhaps not.  As the culture around vim
>    is  no  longer similar  at  all  to what  ed  was.
>    People installing a 120  plugins to turn their vim
>    into an IDE  is exactly not what ed  is. 

I'm not sure what sick preconception you presume here.

I've certainly never installed any plugins in Vim. And
I started using Vi more than four decades ago, and I'm
using Vim almost since its beginning (without plugins).

Native Vim is still completely different to Ed (modulo
the Ex subset that has similarities with Ed, of course).

>    But, the
>    original vi  editors, I  would say they  were very
>    close  to  ed indeed.

You can say that for 'ex' mode but certainly not for
'vi'-mode or Vim's "visual" mode, ...

>    Screen  editing  is a  big
>    difference of course, but  with vi, you were still
>    meant to  integrate your  editor into the  rest of
>    your UNIX  environment using the vi  command mode,
>    you don't install  a plugin to wrap  lines in vim,
>    but you pass the text to fmt from vi.

...and picking a singular external filter doesn't make
the argument any better.

It's fine that the Vi concept allows to apply external
filters. (And for that specific 'fmt' example it's also
not necessary any more in Vim, of course, since it's a
builtin.)

'vi'-mode allows more than ex-mode functions and use of
external filters. And Vim makes it less necessary to use
external tools for editing purposes; but still possible.

>    With ed, it
>    is a  very similar approach.   The power of  ed is
>    that it is  open to the rest of  UNIX, and through
>    that integration, you gain great productivity.

Yes, indeed. (This is a feature that 'ed' also and still
has, as 'ex'/'vi' have it.)

But editing text is generally more than being able to use
external filters.

> [...]
> 
>    When I want to edit text, ed is my shell.

If it's sufficient for all you want to do with an editor
it's fine.

Janis

[*] A complex example from a Vi/Vim course I once gave
:/^Start$/,$g/^# Key//Control-Key/s/Hello/Hello World/

[toc] | [prev] | [next] | [standalone]

#26856

Zayd Mohammed <zaydm@172.24.208.1> wrote:
> ed is the standard text editor.

<snip>

Surprised no one posted this old link :)

https://www.gnu.org/fun/jokes/ed-msg.html

-- 
[t]csh(1) - "An elegant shell, for a more... civilized age."
                        - Paraphrasing Star Wars

[toc] | [prev] | [next] | [standalone]

#26861

Zayd Mohammed <zaydm@172.24.208.1> writes:

> reply here if you use ed and would like to talk
> about it, or if your nam e is ed!

        Yup,  ed man!   I  really  enjoy working  in
  ed.  It is  comfy, and helps with focus  a lot.  I
  find myself  preferring it to Emacs  sometimes.  I
  cheat  a  little  by  running  it  inside  rlwrap,
  providing  some  additional   features  like  line
  editing, keyboard macros, and  a shortcut to clean
  the screen.  The power  of piping text to external
  utilities cannot be understated.   I like using it
  with `par'[1] to fold lines  and align them, and I
  use aspell from the command line to spellcheck.  I
  also  like running  !make  and  other commands  to
  build  and run  and test  projects from  inside ed
  itself.  I think it  fits perfectly with the "UNIX
  as IDE"  mindset.  Oh, and  this is not  a repost,
  I'm actually writing this message in ed right now~
  Oh, and did  I tell you about the  power of search
  backwards when using rlwrap with ed?  If I've done
  something before,  I don't have to  remember it or
  retype it, I just C-r to search my command history
  and repeat  the action very quickly.   Good stuff.
  All the  docs are  in ed too!  !man or  !info, you
  have it all at your fingertips.

        Sadly,  I always  end  up  in emacs  anyway,
  because it is a lot more than an editor to me (I'm
  using  GNUS  to  browse  and post  on  Usenet  for
  example), plus, no editor I've used supports other
  languages, especially  RTL ones, as much  as emacs
  does.  And I  need to be able to write  my RTL TeX
  documents.  In a way ed /does/ support RTL, if the
  underlying  terminal does,  but  no terminal  I've
  seen  ever supported  Arabic well  for that.   The
  closest was  mlterm iirc,  but still, it  felt off
  the whole time.

  So yeah, if anyone would like to talk about it~


PS. Replied here and on comp.editors, didn't realize
    it was a repost from your own post 20 hours ago,
    I thought it was  some old circulating post.  My
    apologies.


Best Regards,
Lumin Etherlight

[toc] | [prev] | [next] | [standalone]

#26862

Zayd Mohammed <zaydm@172.24.208.1> wrote:
> ed is the standard text editor.

Ed made sense when your only way to interact with a system
was through a line printer (such as a DECwriter), but when
terminals with a screen and a cursor were invented, it was
rapidly supplanted by more usable editors.

> right now, i am using ed to edit this post!

And it shows ;)

Cheers,

Koen

-- 
Software architecture & engineering: https://www.sonologic.se/
Sci-fi: https://www.koenmartens.nl/
Retrocomputing videos: https://retroscandinavian.eu/

[toc] | [prev] | [next] | [standalone]

#26863

On Tue, 9 Jun 2026 06:17:10 -0000 (UTC), Koen Martens wrote:

> Ed made sense when your only way to interact with a system was
> through a line printer (such as a DECwriter) ...

Let me suggest that TECO might be a more powerful editing system for
such an interface.

The earliest versions of Emacs were written in TECO.

[toc] | [prev] | [next] | [standalone]

#26869

Koen Martens <gmc@metro.cx> wrote:
> Zayd Mohammed <zaydm@172.24.208.1> wrote:
>> ed is the standard text editor.
> 
> Ed made sense when your only way to interact with a system
> was through a line printer (such as a DECwriter), but when
> terminals with a screen and a cursor were invented, it was
> rapidly supplanted by more usable editors.

There is one use for ed(1), when I boot NetBSD into single
user mode, ed(1) is the only one available without jumping
through hoops. To use it I just need to mount /tmp or / as
rw.

Not sure if that is the case with the Other BSDs.

<snip>

-- 
[t]csh(1) - "An elegant shell, for a more... civilized age."
                        - Paraphrasing Star Wars

[toc] | [prev] | [next] | [standalone]

#26871

On 6/9/26 1:44 PM, John McCue wrote:
>>> <snip>
>>
>> Ed made sense when your only way to interact with a system
>> was through a line printer (such as a DECwriter), but when
>> terminals with a screen and a cursor were invented, it was
>> rapidly supplanted by more usable editors.
> 
> There is one use for ed(1), when I boot NetBSD into single
> user mode, ed(1) is the only one available without jumping
> through hoops. To use it I just need to mount /tmp or / as
> rw.
> 
> Not sure if that is the case with the Other BSDs.
> 
> <snip>
> 

I've run into that as well.  Usually this works:

   $ TERM=vt100 vi <some_file>

-tdc

[toc] | [prev] | [next] | [standalone]

#26875

On 2026-06-09, John McCue <jmclnx@gmail.com.invalid> wrote:

> There is one use for ed(1), when I boot NetBSD into single
> user mode, ed(1) is the only one available without jumping
> through hoops. To use it I just need to mount /tmp or / as
> rw.
>
> Not sure if that is the case with the Other BSDs.

Same there.  Very useful when you screwed up /etc/fstab.

The OpenBSD installer is a ksh script running in a very limited
environment on a ramdisk.  The only editor there is ed and you can
use it to debug or directly modify the installer.  Been there, done
that.

Also, ed can be used to _portably_ edit a file in-place in a script.
For instance, the Game of Trees regression tests use it for that.

"And the next time you're at a job interview where you need to
demonstrate your skills by sharing your screen, establish your
dominance early. Use ed."
https://mwl.io/static/books/ed-mastery.html

-- 
Christian "naddy" Weisgerber                          naddy@mips.inka.de

[toc] | [prev] | [next] | [standalone]

#26877 — Re: ed

On Tue, 9 Jun 2026 23:52:03 -0000 (UTC), Christian Weisgerber wrote:

> The OpenBSD installer is a ksh script running in a very limited
> environment on a ramdisk. The only editor there is ed and you can
> use it to debug or directly modify the installer. Been there, done
> that.

Is there a BSD equivalent of this <https://www.system-rescue.org/>?

[toc] | [prev] | [next] | [standalone]

#26876 — Re: ed

On Tue, 9 Jun 2026 19:44:19 -0000 (UTC), John McCue wrote:

> There is one use for ed(1), when I boot NetBSD into single user
> mode, ed(1) is the only one available without jumping through hoops.

Why is that? Is it because NetBSD still has the legacy root-versus-usr
separation of executables and libraries?

[toc] | [prev] | [next] | [standalone]

#26879 — Re: ed

Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
> On Tue, 9 Jun 2026 19:44:19 -0000 (UTC), John McCue wrote:
> 
>> There is one use for ed(1), when I boot NetBSD into single user
>> mode, ed(1) is the only one available without jumping through hoops.
> 
> Why is that? Is it because NetBSD still has the legacy root-versus-usr
> separation of executables and libraries?

From what I have seen, seems Linux does not have a real single
user mode.  But I think that is OK for Linux.

NetBSD and the other BSDs have real single user mode where no
file systems are mounted, no daemons are started and root is
mounted RO.  NetBSD boots into /bin/sh or a shell of your
choice and you work from that, no login needed.  Also I think
only static executables are available for use.

I do not know what "legacy root-versus-usr" means, I would
never want a system that does not have a clear separation
between root and users.

-- 
[t]csh(1) - "An elegant shell, for a more... civilized age."
                        - Paraphrasing Star Wars

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.unix.shell

csiph-web