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 __ ___ ________ ____ ______. 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 1 of 3  [1] 2 3  Next page →

#26850 — ed __ ___ ________ ____ ______.

ed is the standard text editor.
right now, i am using ed to edit this post!
nvim is based on vim is based on vi is based on ex is based on ed
sed and grep are also based off of ed
ed was created from qed (from which sed takes some extra commands not in
 ed!)
ed was created by ken thompsom and dennis ritchie
https://x.com/ed1conf
https://linux.die.net/man/1/ed
https://wiki.c2.com/?EdIsTheStandardTextEditor
https://en.wikipedia.org/wiki/Ed_(text_editor)
ed, man! !man ed (or i guess really !info ed)
using ed is a little like using a shell.
first show the prompt (optional) by typing P and hitting enter.
now, here are some commands than can be ran in ed:
[type a number] - go to that line number (1 is first line)
a - append text in lines after the line you were on
to stop appending, type a single period in a line by itself, and hit ent
er.
you can put a line number before a command to go there before running it
.
. can also stand for a line number to mean the current line you are on.
[line number],[line number]d - deleter text from the first to second lin
e number inclusive.
e - chooses a file to edit
p - print the line you are on in case you forgot
! - runs a command.
you can use ! to edit the file you are inside by using %.
e.g. !fold -n 67 %
you can also use it with e: e !ncal
r - like e, buts appends instead of replaces
= - shows how many lines there are in the file.
you can put . before it to show what line number you are currently on. (
.=)
s/regex/regex/ - substitutes the first instances of the first regex's ma
tch
with the second one. this command is used a lot in grep and sed, so it m
ay seem familiar.
newline by itself - go to the next line and print it (like the more comm
and)
these are just a few commands in ed. the see them all, along with more h
elp,
simply run `info ed'!
i think that's all.
reply here if you use ed and would like to talk about it, or if your nam
e is ed!

[toc] | [next] | [standalone]

#26851

On 2026-06-08 04:16, Zayd Mohammed wrote:
> ed is the standard text editor.

'ed' is _a_ standard text editor; on Unixes. Though a very primitive
one.

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

(I wonder why one would make ones life harder than necessary.)

Is that the reason why the formatting of your post is corrupt?
(Or is it your newsreader settings?)

> nvim is based on vim is based on vi is based on ex is based on ed

I think "based on" may be a misleading formulation here.

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.

Maybe modulo the very first beginning (when vi was added to ex as a
visual mode) mode, ex and vi are just two modes of the same editor.

> [...]

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

I suggest to talk about editors in comp.editors (not primarily here).

Janis

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

#26852

In article <1105ae4$1naub$1@dont-email.me>,
Janis Papanagnou  <janis_papanagnou+ng@hotmail.com> wrote:
>On 2026-06-08 04:16, Zayd Mohammed wrote:
>> ed is the standard text editor.
>
>'ed' is _a_ standard text editor; on Unixes. Though a very primitive
>one.

Saying, "`ed` is the standard text editor" on Unix systems is an
old joke.

	- Dan C.

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

#26853

In article <1106h0l$lb$1@reader1.panix.com>,
Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>In article <1105ae4$1naub$1@dont-email.me>,
>Janis Papanagnou  <janis_papanagnou+ng@hotmail.com> wrote:
>>On 2026-06-08 04:16, Zayd Mohammed wrote:
>>> ed is the standard text editor.
>>
>>'ed' is _a_ standard text editor; on Unixes. Though a very primitive
>>one.
>
>Saying, "`ed` is the standard text editor" on Unix systems is an
>old joke.

Indeed.  And the joke works better if you base it on and sing it to the
tune of "Mr Ed".

-- 
The randomly chosen signature file that would have appeared here is more than 4-ish
lines long.  As such, it violates one or more Usenet RFCs.  In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
	http://user.xmission.com/~gazelle/Sigs/LadyChatterley

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

#26854 — Re: ed.

In article <1106ijl$1h9mu$1@news.xmission.com>,
Kenny McCormack <gazelle@shell.xmission.com> wrote:
>In article <1106h0l$lb$1@reader1.panix.com>,
>Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>>In article <1105ae4$1naub$1@dont-email.me>,
>>Janis Papanagnou  <janis_papanagnou+ng@hotmail.com> wrote:
>>>On 2026-06-08 04:16, Zayd Mohammed wrote:
>>>> ed is the standard text editor.
>>>
>>>'ed' is _a_ standard text editor; on Unixes. Though a very primitive
>>>one.
>>
>>Saying, "`ed` is the standard text editor" on Unix systems is an
>>old joke.
>
>Indeed.  And the joke works better if you base it on and sing it to the
>tune of "Mr Ed".

(Those in the know refer to it as e-d, pronounced "ee dee", not
"Ed" as in the short form of Edward. :-))

	- Dan C.

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

#26855

cross@spitfire.i.gajendra.net (Dan Cross) writes:
> In article <1105ae4$1naub$1@dont-email.me>,
> Janis Papanagnou  <janis_papanagnou+ng@hotmail.com> wrote:
>>On 2026-06-08 04:16, Zayd Mohammed wrote:
>>> ed is the standard text editor.
>>
>>'ed' is _a_ standard text editor; on Unixes. Though a very primitive
>>one.
>
> Saying, "`ed` is the standard text editor" on Unix systems is an
> old joke.

I recall that some versions of the ed(1) man page started with
"ed is the standard text editor".

I can't find that line on any system I have access to, or anywhere
in the history of GNU ed (which is of course not the original ed),
but a web search turns it up as a line from old man pages.
The current GNU ed man page says:

    Ed is the ’standard’ text editor in the sense that it is the
    original editor for Unix, and thus widely available. For most
    purposes, however, it is superseded by full-screen editors.

which is an implicit reference to the old wording.

-- 
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]

#26857

In article <1107cro$3hr0r$1@kst.eternal-september.org>,
Keith Thompson  <Keith.S.Thompson+u@gmail.com> wrote:
>I recall that some versions of the ed(1) man page started with
>"ed is the standard text editor".

<URL:https://man.freebsd.org/cgi/man.cgi?query=ed&apropos=0&sektion=0&manpath=Unix+Seventh+Edition&format=html>
| Ed is the standard text editor.

John
groenveld@acm.org

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

#26858

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> I recall that some versions of the ed(1) man page started with "ed is
> the standard text editor". [...] a web search turns it up as a line
> from old man pages.

Very old man pages -- it's had that wording since Unix V1:
  http://squoze.net/UNIX/v1man/man1/ed

Because the early Unix manuals are often influenced by CTSS and Multics,
I was curious as to whether similar wording showed up anywhere else. The
1973 Multics Programmer's Manual (revision 14) says:

  The two standard editors are named edm and qedx.

And by 1981, editing.gi.info says about qedx:

  This is the standard Multics editor.

-- 
Adam Sampson <ats@offog.org>                         <http://offog.org/>

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

#26867

On 2026-06-08 23:40, Keith Thompson wrote:
> cross@spitfire.i.gajendra.net (Dan Cross) writes:
>> In article <1105ae4$1naub$1@dont-email.me>,
>> Janis Papanagnou  <janis_papanagnou+ng@hotmail.com> wrote:
>>> On 2026-06-08 04:16, Zayd Mohammed wrote:
>>>> ed is the standard text editor.
>>>
>>> 'ed' is _a_ standard text editor; on Unixes. Though a very primitive
>>> one.
>>
>> Saying, "`ed` is the standard text editor" on Unix systems is an
>> old joke.
> 
> I recall that some versions of the ed(1) man page started with
> "ed is the standard text editor".
> 
> I can't find that line on any system I have access to, or anywhere
> in the history of GNU ed (which is of course not the original ed),
> but a web search turns it up as a line from old man pages.
> The current GNU ed man page says:
> 
>      Ed is the ’standard’ text editor in the sense that it is the
>      original editor for Unix, and thus widely available. For most
>      purposes, however, it is superseded by full-screen editors.
> 
> which is an implicit reference to the old wording.

So this specific meaning of "standard" predates what's now, in POSIX
era, considered standard.

But thanks for the hints to the joke; it wasn't obvious to me. And I
certainly thought that above statement, if anything, was just a part
of a more complete joke concerning editors; along the line that 'cat'
is the standard editor to create text. So 'ed' is probably overkill.

Janis

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

#26873

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]
> But thanks for the hints to the joke; it wasn't obvious to me. And I
> certainly thought that above statement, if anything, was just a part
> of a more complete joke concerning editors; along the line that 'cat'
> is the standard editor to create text. So 'ed' is probably overkill.

`cat`?  I always use `gzip -df` to save keystrokes.

8-)}

-- 
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]

#26866

On 2026-06-08, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
> In article <1105ae4$1naub$1@dont-email.me>,
> Janis Papanagnou  <janis_papanagnou+ng@hotmail.com> wrote:
>>On 2026-06-08 04:16, Zayd Mohammed wrote:
>>> ed is the standard text editor.
>>
>>'ed' is _a_ standard text editor; on Unixes. Though a very primitive
>>one.
>
> Saying, "`ed` is the standard text editor" on Unix systems is an
> old joke.
>
> 	- Dan C.

Here's a sequel:

gopher://tilde.pink/I/~bencollver/files/dos/editor/oed/ed-joke.jpg

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

#26859

with <1105ae4$1naub$1@dont-email.me> Janis Papanagnou wrote:
> On 2026-06-08 04:16, Zayd Mohammed wrote:

*SKIP* [  5 lines   2 levels deep]
>> right now, i am using ed to edit this post!
*SKIP* [  1 line   1 level deep]
> Is that the reason why the formatting of your post is corrupt?  (Or is
> it your newsreader settings?)

(on parentheses)  No.  slrn doesn't post format;  it will complain about
technical netiquette (if configured), but otherwise just accept whatever
is '.article' or '.followup'.  Sure, elaborate schemes can be
implemented (it's scriptable after all, so to speak (from experience)).
But I don't think that's what has happened.

Speculation.  What is present is result of (1) type some letters in
'ed';  (2) '%p';  (3) copy-paste result to whatever slrn (that's
debatable) has picked as 'editor';  (4) post that marvel to Usenet.

Elaborate line-wrapping comes from interfering terminal -- it wraps
lines hard instead of being intelligent about it.

*CUT* [ 11 lines   2 levels deep]

And speaking of terminals.  There's that long forgotten saying:  "Put
the Subject of Your Message in the Subject of Your Message".  Fscked up
encodings?  In the day and age?  We all gonna die.

-- 
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

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

#26860

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.

> 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 :)

> 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.  But, the
  original vi  editors, I  would say they  were very
  close  to  ed indeed.   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.  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.

>> reply here if  you use ed and would  like to talk
>> about it, or if your nam e is ed!
>
> I suggest  to talk  about editors  in comp.editors
> (not primarily here).

        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.


Best Regards,
Lumin Etherlight

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

#26864

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

Lumin Etherlight <lumin+usenet@etherlight.link> writes:

> 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.
>
>> 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 :)
>
>> 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.  But, the
>   original vi  editors, I  would say they  were very
>   close  to  ed indeed.   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.  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.
>
>>> reply here if  you use ed and would  like to talk
>>> about it, or if your nam e is ed!
>>
>> I suggest  to talk  about editors  in comp.editors
>> (not primarily here).
>
>         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.

Cheers for Freedom,

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

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

#26865

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.

The bound emacs command is `shell-command-on-region´ for further
information.

Joerg

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

#26870

[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.
>
> The bound emacs command is `shell-command-on-region´ for further
> information.

Awesome!

I know it is not costume to use a whole article reply to say this in
Usenet, but thanks Joerg! :-))) .

Now I have to read some more of man par(1).

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

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

#26872

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.
>
> The bound emacs command is `shell-command-on-region´ for further
> information.

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.

Personally, I find Lumin's formatting distracting.  For fixed-width
characters, right-justifying text by inserting blanks makes the text
more difficult to read, IMHO with no real benefit.  (It tends to work
better with variable-width fonts.)  Leading spaces typically denote
quoted text; adding using them on original text is unconventional,
and therefore distracting.  50 or 52 columns is much narrower than
most articles, which I also find distracting.  (I use 70 or so,
typically via "fmt -w 70" or the equivalant "fmt -70".)

Lumin's formatting is clever.  Clever is not always good.

-- 
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]

#26890

On 2026-06-10 01:29, Keith Thompson wrote:
> 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? :-) .
>>> [...]
>> Daniel wrote that he uses a program called "par" to format his texts.
>> [...]
> 
> 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?)

> 
> Personally, I find Lumin's formatting distracting.  For fixed-width
> characters, right-justifying text by inserting blanks makes the text
> more difficult to read, IMHO with no real benefit.  (It tends to work
> better with variable-width fonts.)  Leading spaces typically denote
> quoted text; adding using them on original text is unconventional,
> and therefore distracting.  50 or 52 columns is much narrower than
> most articles, which I also find distracting.  (I use 70 or so,
> typically via "fmt -w 70" or the equivalant "fmt -70".)
> 
> Lumin's formatting is clever.  Clever is not always good.

I agree with most of what you say. And especially concerning the
right-alignment with spurious spaces. (The indent I think is only
mildly annoying; usually you can identify the indent-level by the
number of '>'.) Narrower line-lengths (50-76) is okay for me; I
find the (widespread!) use of using no line-length limits at all
to be the much more annoying formatting habit.

Janis

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

#26898

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.)

>> Personally, I find Lumin's formatting distracting.  For fixed-width
>> characters, right-justifying text by inserting blanks makes the text
>> more difficult to read, IMHO with no real benefit.  (It tends to work
>> better with variable-width fonts.)  Leading spaces typically denote
>> quoted text; adding using them on original text is unconventional,
>> and therefore distracting.  50 or 52 columns is much narrower than
>> most articles, which I also find distracting.  (I use 70 or so,
>> typically via "fmt -w 70" or the equivalant "fmt -70".)
>> Lumin's formatting is clever.  Clever is not always good.
>
> I agree with most of what you say. And especially concerning the
> right-alignment with spurious spaces. (The indent I think is only
> mildly annoying; usually you can identify the indent-level by the
> number of '>'.) Narrower line-lengths (50-76) is okay for me; I
> find the (widespread!) use of using no line-length limits at all
> to be the much more annoying formatting habit.

Indentation is commonly used to mark text quoted from a source other
than the parent article (at least I do that).  It's also sometimes
used for code samples.

-- 
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]

#26912

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*.

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).

Janis

> [...]

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web