From the «byebye Calibri» department:
Feed: The Register
Title: Microsoft kicks Calibri to the curb for Aptos as default font
Author: Jude Karabus
Date: Fri, 14 Jul 2023 12:05:06 -0400
Link: https://go.theregister.com/feed/www.theregister.com/2023/07/14/font/

The artist formerly known as Bierstadt

Haters of official Microsoft Office font Calibri finally have their wish – the
infuriatingly 11-point default typeface has been chucked to the bin in favor of
Aptos, the new official font to be used in all the Microsoft Office apps.…

--
I sure wish Usenet were owned by a petulant billionaire shitposter

On Fri, 14 Jul 2023 23:26:44 -0000 (UTC)
Retrograde <fungus@amongus.com.invalid> wrote:

> Haters of official Microsoft Office font Calibri finally have their
> wish – the infuriatingly 11-point default typeface has been chucked
> to the bin in favor of Aptos, the new official font to be used in all
> the Microsoft Office apps.…

I liked Calibri, but I never understood why the default size was 11
instead of 12. I liked Times New Roman too. It's all good.

2023-07-15, Visiblink <visiblink@mail.invalid> schrieb:

[Calibri-schnipp]

> I liked Calibri, but I never understood why the default size was 11
> instead of 12. I liked Times New Roman too. It's all good.

It depends probably on your eyesight, but I prefer 11pt, 12 is slightly
to big for me.

--
Jan v/d Broek balglaas@dds.nl

"Ich kenne das Leben, ich bin im Kino gewesen."

On Sat, 15 Jul 2023 07:15:12 -0000 (UTC)
Jan van den Broek <balglaas@dds.nl> wrote:

> 2023-07-15, Visiblink <visiblink@mail.invalid> schrieb:
>
> [Calibri-schnipp]
>
> > I liked Calibri, but I never understood why the default size was 11
> > instead of 12. I liked Times New Roman too. It's all good.
>
> It depends probably on your eyesight, but I prefer 11pt, 12 is
> slightly to big for me.
>

Very true. My eyesight isn't as good as it once was...

I guess it also depends on your monitor's dpi settings and app zoom
levels too (unless, of course, we're talking about actual paper!).

For me it’s the Go fonts.

Jude Karabus:

> Haters of official Microsoft Office font Calibri
> finally have their wish Ц the infuriatingly
> 11-point default typeface has been chucked to the
> bin in favor of Aptos

The very fact that default settings have so tremen-
dous an impact shows how lazy and careless they are.
In any program I use intensively, including e-mail
and Usenet clients, text editors, IDEs, document
processors, and word processors, most of the de-
faults are redefined to what suits my needs and my
easthetics. The defaults are a minor nuance, only
annoying when a feature is "on" by default rather
then "off", throwing in your face tons of function-
ality you never asked for. The correct approach is
the opposite: turn all bells and whistles off and
let the user feel what they are missing, and encour-
ange them to explore the settings and documentation
in search of it.

Calibri is kindergarten font, and unuitable for se-
rious typography being sans-serif. Times New Roman
was OK for a the London Times, where it was employed
at small point size, at which its unattractive nar-
rowness was simultaneoulsly useful and unobtrusive:

https://typographyforlawyers.com/a-brief-history-of-times-new-roman.html

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
> In any program I use intensively, including e-mail
> and Usenet clients, text editors, IDEs, document
> processors, and word processors, most of the de-
> faults are redefined to what suits my needs and my
> easthetics. The defaults are a minor nuance, only
> annoying when a feature is "on" by default rather
> then "off", throwing in your face tons of function-
> ality you never asked for. The correct approach is
> the opposite: turn all bells and whistles off and
> let the user feel what they are missing, and encour-
> ange them to explore the settings and documentation
> in search of it.
>

So you're saying you *intentionally* enabled this obnoxious text
justification in your post? Different strokes, I guess.

john

John to Anton Shepelev:

> > The very fact that default settings have so
> > tremen dous an impact shows how lazy and care-
> > less they are. In any program I use intensive-
> > ly, including e-mail and Usenet clients, text
> > editors, IDEs, document processors, and word
> > processors, most of the defaults are redefined
> > to what suits my needs and my easthetics. The
> > defaults are a minor nuance, only annoying when
> > a feature is "on" by default rather then "off",
> > throwing in your face tons of function ality you
> > never asked for. The correct approach is the op-
> > posite: turn all bells and whistles off and let
> > the user feel what they are missing, and encour-
> > ange them to explore the settings and documenta-
> > tion in search of it.
>
> So you're saying you *intentionally* enabled this
> obnoxious text justification in your post? Differ-
> ent strokes, I guess.

No, I am not saying that. But my beautiful justifi-
cation is intentional. It is standard in the better
plain-text documents, e.g.:

MODULA: a language for modular multiprogramming
https://www.research-collection.ethz.ch/bitstream/handle/20.500.11850/68669/eth-3057-01.pdf

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

Anton Shepelev <anton.txt@g{oogle}mail.com> wrote:

> John to Anton Shepelev:
>
> > > The very fact that default settings have so tremen dous an impact
> > > shows how lazy and care- less they are. In any program I use
> > > intensive- ly, including e-mail and Usenet clients, text editors,
> > > IDEs, document processors, and word processors, most of the
> > > defaults are redefined to what suits my needs and my easthetics.
> > > The defaults are a minor nuance, only annoying when a feature is
> > > "on" by default rather then "off", throwing in your face tons of
> > > function ality you never asked for. The correct approach is the op-
> > > posite: turn all bells and whistles off and let the user feel what
> > > they are missing, and encour- ange them to explore the settings and
> > > documenta- tion in search of it.
> >
> > So you're saying you *intentionally* enabled this obnoxious text
> > justification in your post? Differ- ent strokes, I guess.
>
> No, I am not saying that. But my beautiful justifi- cation is
> intentional. It is standard in the better plain-text documents, e.g.:
>
> MODULA: a language for modular multiprogramming
> <https://www.research-collection.ethz.ch/bitstream/handle/20.500.11850/68669/eth-3057-01.pdf>
>

Beautiful justification? It isn't beautiful on ~my~ Usenet.
Another nit-pick: you posted an undelimited URL, now corrected.

--
^Ï^. – Sn!pe – <https://youtu.be/_kqytf31a8E>

My pet rock Gordon just is.

Sn!pe

> > But my beautiful justifi- cation is intentional.
>
> Beautiful justification?It isn't beautiful on ~my~ Usenet.

You Usenset reader? MacSOUP? I conjecture it is not, by
default, displaying posts in a monospace font, which it
sould. Hard-wrapped plain-text -- whether justified or
not -- is medium for character-cell devices.

> Another nit-pick: you posted an undelimited URL, now
> corrected.

Oh, I never do it for aesthetical reasons. Whenever I wish
to follow a URL, I manually copy it and paste into the
browser. It is safer, I think.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

Anton Shepelev <anton.txt@g{oogle}mail.com> wrote:

> Sn!pe
>
> > > But my beautiful justifi- cation is intentional.
> >
> > Beautiful justification?It isn't beautiful on ~my~ Usenet.
>
> You Usenset reader? MacSOUP? I conjecture it is not, by
> default, displaying posts in a monospace font, which it
> sould. Hard-wrapped plain-text -- whether justified or
> not -- is medium for character-cell devices.
>

I disagree.

You're misquoting too, see above.

> > Another nit-pick: you posted an undelimited URL, now
> > corrected.
>
> Oh, I never do it for aesthetical reasons. Whenever I wish
> to follow a URL, I manually copy it and paste into the
> browser. It is safer, I think.
>

Nonsense. Whatever, delimiting is in the RFCs.

Consider the case of Thunderbird, which has the bad habit of omitting
a space between the quote chevrons and the quoted text. If the text
quoted is an undelimited URL, it will be broken (non-clickable)

Examples below:-

http://www.example.url.com <~~[original]

becomes (when quoted by Thunderbird):-

>http://www.example.url.com <~~[broken]

If it were delimited it becomes, when quoted:-

><http://www.example.url.com> <~~[works]

Delimiting is required, not optional.

--
^Ï^. – Sn!pe – <https://youtu.be/_kqytf31a8E>

My pet rock Gordon just is.

Sn!pe:
> Anton Shepelev:
> > Sn!pe:
> > > Anton Shepelev:
> > >
> > > > But my beautiful justification is intentional.
> > >
> > > Beautiful justification?It isn't beautiful on ~my~
> > > Usenet.
> >
> > You Usenset reader? MacSOUP? I conjecture it is not, by
> > default, displaying posts in a monospace font, which it
> > sould. Hard-wrapped plain-text -- whether justified or
> > not -- is medium for character-cell devices.
>
> I disagree.

I defend my point with the two arguments:

1. Hard-wrapping splits lines based on their length in
characters, whereas with a proportional font line length
cannot be measured by character count.

2. All formatting, alignment, tables, and diagrams in plain-
text are posssible exclusively with monospace font, e.g.:
<http://inversed.ru/CoreWar/CoreOps_02.txt>

> You're misquoting too, see above.

Yes. I misquoted your quotation of myself -- fixed now.

> > > Another nit-pick: you posted an undelimited URL, now
> > > corrected.
> >
> > Oh, I never do it for aesthetical reasons. Whenever I
> > wish to follow a URL, I manually copy it and paste into
> > the browser. It is safer, I think.
>
> Nonsense. Whatever, delimiting is in the RFCs.

The fact that the delimiter is specified in an RFC does not
render nonsencial my reasons of not following it. I did not
know, however, about an RFC for URL delimiters, nor can I
find one right now. Which RFC is it?

Now that I have enclosed an URI in <> I see that it has
become harder to select and copy.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

Anton Shepelev <anton.txt@g{oogle}mail.com> wrote:

> Sn!pe:

I do not think we will not come to agreement regarding justification
so I have omitted quotation of that part of the preceding articles.

[...]

> > > > Another nit-pick: you posted an undelimited URL,
> > > > now corrected.
> > >
> > > Oh, I never do it for aesthetical reasons. Whenever I
> > > wish to follow a URL, I manually copy it and paste into
> > > the browser. It is safer, I think.
> >
>
> > Nonsense. Whatever, delimiting is in the RFCs.
> >
>
> The fact that the delimiter is specified in an RFC does not
> render nonsencial my reasons of not following it. I did not
> know, however, about an RFC for URL delimiters, nor can I
> find one right now. Which RFC is it?
>
> Now that I have enclosed an URI in <> I see that it has
> become harder to select and copy. <~~ [unnecessary step]
>

Why make work for yourself when you can simply click a URL?

I note that you have silently discarded my comments about
Thunderbird's faulty quoting.

RFC 1738 (and others):

" In addition, there are many occasions when URLs are included in other
kinds of text; examples include electronic mail, USENET news
messages, or printed on paper. In such cases, it is convenient to
have a separate syntactic wrapper that delimits the URL and separates
it from the rest of the text, and in particular from punctuation
marks that might be mistaken for part of the URL. For this purpose,
is recommended that angle brackets ("<" and ">"), along with the
prefix "URL:", be used to delimit the boundaries of the URL. This
wrapper does not form part of the URL and should not be used in
contexts in which delimiters are already specified."

--
^Ï^. – Sn!pe – <https://youtu.be/_kqytf31a8E>

My pet rock Gordon just is.

Anton Shepelev <anton.txt@g{oogle}mail.com> wrote:
> Sn!pe:
>> Anton Shepelev:
>> > Sn!pe:
>> > > Anton Shepelev:
>> > >
>> > > > But my beautiful justification is intentional.
>> > >
>> > > Beautiful justification?It isn't beautiful on ~my~ Usenet.
>> >
>> > You Usenset reader? MacSOUP? I conjecture it is not, by default,
>> > displaying posts in a monospace font, which it sould.
>> > Hard-wrapped plain-text -- whether justified or not -- is medium
>> > for character-cell devices.
>>
>> I disagree.
>
> I defend my point with the two arguments:
>
> 1. Hard-wrapping splits lines based on their length in
> characters, whereas with a proportional font line length
> cannot be measured by character count.

I suspect that Sn!pe's complaint is not the hard-wrap (my own reply
here is also hard wrapped), but instead is about the even right
justification by additional full space insertion plus the
auto-hyphenation. Those two, in a mono-space context, make for
severely ugly wordwrap.

Rich <rich@example.invalid> wrote:

> Anton Shepelev <anton.txt@g{oogle}mail.com> wrote:
> > Sn!pe:
> >> Anton Shepelev:
> >> > Sn!pe:
> >> > > Anton Shepelev:
> >> > >
> >> > > > But my beautiful justification is intentional.
> >> > >
> >> > > Beautiful justification?It isn't beautiful on ~my~ Usenet.
> >> >
> >> > You Usenset reader? MacSOUP? I conjecture it is not, by default,
> >> > displaying posts in a monospace font, which it sould.
> >> > Hard-wrapped plain-text -- whether justified or not -- is medium
> >> > for character-cell devices.
> >> >
> >>
> >> I disagree.
> >>
> >
> > I defend my point with the two arguments:
> >
> > 1. Hard-wrapping splits lines based on their length in
> > characters, whereas with a proportional font line length
> > cannot be measured by character count.
> >
>
> I suspect that Sn!pe's complaint is not the hard-wrap (my own reply
> here is also hard wrapped), but instead is about the even right
> justification by additional full space insertion plus the
> auto-hyphenation. Those two, in a mono-space context, make for
> severely ugly wordwrap.
>

I think we agree, Rich. If one cares enough about formatting to try
to achieve block (brick) text when monospaced, the classical way is
to use synonyms and word order, not the facile method of inserting
extraneous spaces and hyphens. That merely looks ridiculous when
applied to Usenet News, particularly if quoted or read using a
proportional font.

Perhaps Anton is more concerned about how his words look on his own
screen rather than how they appear to his readers.

--
^Ï^. – Sn!pe – <https://youtu.be/_kqytf31a8E>

My pet rock Gordon just is.

Sn!pe to Anton Shepelev:

> > Now that I have enclosed an URI in <> I see that it has
> > become harder to select and copy. <~~ [unnecessary step]
>
> Why make work for yourself when you can simply click a URL?

Since Usenet predates web, clients need not be aware of URLs
to such a degree as to make them clickable (presumably to
open them in the default browser). I don't think such
newsreaders as tin, trn, or slrn recognise URLs at all.

Yes, copying the URL and inserting it into the browser is
more work than simply clicking on it in the client, but at
the same time it is less dangerous, in that one can click on
a URL by accident.

> I note that you have silently discarded my comments about
> Thunderbird's faulty quoting.

I have read your example, though, but had nothing to say to
it. One possible suggestion is to fix TB so that it will
detect and parse URLs propertly even when they are at the
beginning of a quoted line. I see no reason why TB should
fail with:

>http://www.example.url.com

Another -- not to rely on this funcionality, as I do,
preferring the freedom of treating the message as uniform
text.

> RFC 1738 (and others)

Indeed, but please observe that according the examples in
RFC the major funciton of those delimiters seems to leting
the client pars URLs <https://that.are.split.over.several.
lines>, whereas I myself never ever post such URLs,
preferring rather to exceed the recommended line length
limit of 78 characters. Keep URLs on a single line helps
with both readablity and usability, i.e. copying the entire
URL.

Observe also that the RFC recommends not only to delimit
URLs with <>, but also to preped them with the `URL:'
prefix, which you do not seem to require. I wonder if your
TB will handle <URL:https://fusionanomaly.net/
EssenceNode.html>. I see that you or your client reflow
text, so that my URL may not appear split across two lines
on your side.

Observe thirdly, that according to GNKSA, a newsreader
should preserve line breaks while displaying a message:

Any line breaks shown to the user while she is editing
her article SHOULD still be present when the article is
actually posted to the Net. The software SHOULD NOT show
the user four 75-character lines while actually posting a
single 300-character line. Nor should it show the user a
series of 100-character lines while actually posting
alternating lines of 80 and 20 characters each.

So I hope your TB shows my articles as they are meant to be
viewed.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

Rich:

> I suspect that Sn!pe's complaint is not the hard-wrap (my
> own reply here is also hard wrapped), but instead is about
> the even right justification by additional full space
> insertion plus the auto-hyphenation. Those two, in a
> mono-space context, make for severely ugly wordwrap.

Did you mean /non/-monospace context, wherein this format is
indeed horrible?

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

Sn!pe <snipeco.2@gmail.com> wrote:
> Consider the case of Thunderbird, which has the bad habit of omitting
> a space between the quote chevrons and the quoted text. If the text
> quoted is an undelimited URL, it will be broken (non-clickable)
>
> Examples below:-
>
> http://www.example.url.com <~~[original]
>
> becomes (when quoted by Thunderbird):-
>
>>http://www.example.url.com <~~[broken]
>
> If it were delimited it becomes, when quoted:-
>
>><http://www.example.url.com> <~~[works]

Who died and made you net.cop? In any case, if your newsreader can't handle
a URL within plain text, perhaps you should get a better newsreader. tin
(to name just one example) has no problem with either of the URLs given
above (or below, in my sig).

Bear in mind that Usenet predates the Web by several years. I've been
posting here since 1989, and it had already been around for a few years
before that.

--
_/_
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( https://alfter.us/ Top-posting!
\_^_/ >What's the most annoying thing on Usenet?

Anton Shepelev <anton.txt@g{oogle}mail.com> wrote:
> Sn!pe to Anton Shepelev:
>
>> > Now that I have enclosed an URI in <> I see that it has
>> > become harder to select and copy. <~~ [unnecessary step]
>>
>> Why make work for yourself when you can simply click a URL?
>
> Since Usenet predates web, clients need not be aware of URLs
> to such a degree as to make them clickable (presumably to
> open them in the default browser). I don't think such
> newsreaders as tin, trn, or slrn recognise URLs at all.

I switched over to tin a while back when I could no longer get trn to
compile. I have it running on a VPS that hosts my mail and websites. I
ssh into that VPS, whether from a Konsole (KDE terminal) window under Linux
or a WSL window running Gentoo Linux under Windows 11. In either case,
double-clicking a URL will select it, upon which I can copy-and-paste it to
transfer it into whatever browser I'm using.

Whether this behavior is part of tin or part of the host terminal, I
couldn't say. I think I could highlight and copy URLs out of trn in the
same way, though, so it's likely a feature of the local host and its
software, not the newsreader running on a remote host.

--
_/_
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( https://alfter.us/ Top-posting!
\_^_/ >What's the most annoying thing on Usenet?

Anton Shepelev <anton.txt@g{oogle}mail.com> wrote:

> Sn!pe to Anton Shepelev:
>
> > > Now that I have enclosed an URI in <> I see that it has
> > > become harder to select and copy. <~~ [unnecessary step]
> >
> > Why make work for yourself when you can simply click a URL?
>
> Since Usenet predates web, clients need not be aware of URLs
> to such a degree as to make them clickable (presumably to
> open them in the default browser). I don't think such
> newsreaders as tin, trn, or slrn recognise URLs at all.
>

What about News Message-IDs and References? If properly delimited,
MacSOUP can automatically search its stored articles for a match on
M-IDs.

>
> Yes, copying the URL and inserting it into the browser is
> more work than simply clicking on it in the client, but at
> the same time it is less dangerous, in that one can click on
> a URL by accident.
>
> >
> > I note that you have silently discarded my comments about
> > Thunderbird's faulty quoting.
> >
>
> I have read your example, though, but had nothing to say to
> it. One possible suggestion is to fix TB so that it will
> detect and parse URLs propertly even when they are at the
> beginning of a quoted line. I see no reason why TB should
> fail with:
>
> >http://www.example.url.com
>
> Another -- not to rely on this funcionality, as I do,
> preferring the freedom of treating the message as uniform
> text.
>

You have identified yourself as a dinosaur.

> > RFC 1738 (and others)
>
> Indeed, but please observe that according the examples in
> RFC the major funciton of those delimiters seems to leting
> the client pars URLs <https://that.are.split.over.several.
> lines>, whereas I myself never ever post such URLs,
> preferring rather to exceed the recommended line length
> limit of 78 characters. Keep URLs on a single line helps
> with both readablity and usability, i.e. copying the entire
> URL.
>
> Observe also that the RFC recommends not only to delimit
> URLs with <>, but also to preped them with the `URL:'
> prefix, which you do not seem to require. I wonder if your
> TB will handle <URL:https://fusionanomaly.net/
> EssenceNode.html>.
>

MacSOUP, my User-Agent (which you would know if you had
bothered to inspect the headers) certainly does follow that URL
correctly.

I do not use Thunderbird, which I see as a being a more or less
competent emailer that has been pressed into service as a
half-arsed Newsreader (Hey! News looks like Mail, they must be
the same thing...)

>
> I see that you or your client reflow text, so that my URL may
> not appear split across two lines on your side.
>

MacSOUP has a hard line-length limit, but it can make an exception
for long URLs. I prefer to make my own CR-LFs at a place in the line
that suits me. Even if a URL is broken across more than one line
MacSOUP can parse it ~if the URL is properly delimited.~ I do not
approve of "format-flowed" on Usenet.

If a quoted post is ill-formatted, MacSOUP can automatically reflow
that text ~if asked to.~

MacSOUP also has an ~excellent~ GNKSA score.

>
> Observe thirdly, that according to GNKSA, a newsreader
> should preserve line breaks while displaying a message:
>
> Any line breaks shown to the user while she is editing
> her article SHOULD still be present when the article is
> actually posted to the Net. The software SHOULD NOT show
> the user four 75-character lines while actually posting a
> single 300-character line. Nor should it show the user a
> series of 100-character lines while actually posting
> alternating lines of 80 and 20 characters each.
>
> So I hope your TB shows my articles as they are meant to be
> viewed.
>

Again: It is not my Thunderbird, I eschew TB. MacSOUP displays
your "beautifully formatted" text as you have sent it. It also quotes
your text according to custom and usage. That quotation process
makes your "beautiful" text look like a dogs dinner.

I've done with this now, if you have?

--
^Ï^. – Sn!pe – <https://youtu.be/_kqytf31a8E>

My pet rock Gordon just is.

<scott@alfter.diespammersdie.us> wrote:

> Sn!pe <snipeco.2@gmail.com> wrote:
> > Consider the case of Thunderbird, which has the bad habit of omitting
> > a space between the quote chevrons and the quoted text. If the text
> > quoted is an undelimited URL, it will be broken (non-clickable)
> >
> > Examples below:-
> >
> > http://www.example.url.com <~~[original]
> >
> > becomes (when quoted by Thunderbird):-
> >
> >>http://www.example.url.com <~~[broken]
> >
> > If it were delimited it becomes, when quoted:-
> >
> >><http://www.example.url.com> <~~[works]
> >
>
> Who died and made you net.cop? In any case, if your newsreader can't handle
> a URL within plain text, perhaps you should get a better newsreader. tin
> (to name just one example) has no problem with either of the URLs given
> above (or below, in my sig).
>
> Bear in mind that Usenet predates the Web by several years. I've been
> posting here since 1989, and it had already been around for a few years
> before that.
>

Well you've beaten me, Scott, I've only been on Usenet since it became
commercially available here in the UK in 1994. Congratulations!
I won't count my years on Compu$erve before they were borged by AOL.

--
^Ï^. – Sn!pe – <https://youtu.be/_kqytf31a8E>

My pet rock Gordon just is.

Anton Shepelev <anton.txt@g{oogle}mail.com> wrote:
> Rich:
>
>> I suspect that Sn!pe's complaint is not the hard-wrap (my own reply
>> here is also hard wrapped), but instead is about the even right
>> justification by additional full space insertion plus the
>> auto-hyphenation. Those two, in a mono-space context, make for
>> severely ugly wordwrap.
>
> Did you mean /non/-monospace context, wherein this format is indeed
> horrible?

No, I meant exactly what I wrote. A mono-space context, as in a fixed
width font, which is how I read Usenet (tin, running in a urxvt, using
a fixed width font).

Your initial post, that started this discussion, appeared like this
(small quote, not the entire part, with "> " prefixed to demarcate it
as a "quote"):

> The very fact that default settings have so tremen-
> dous an impact shows how lazy and careless they are.
> In any program I use intensively, including e-mail
> and Usenet clients, text editors, IDEs, document
> processors, and word processors, most of the de-
> faults are redefined to what suits my needs and my
> easthetics. The defaults are a minor nuance, only
> annoying when a feature is "on" by default rather
> then "off", throwing in your face tons of function-

It has both auto-hyphenation, and insertion of extra full spaces (the
double spaces between some words) in order to make for an even right
margin.

This is common for variable width fonts, and esp. so for paper
publishing, but for those contexts, the even right margin edge is
created by inserting small amounts of space within the line to even up
the right edge, not full space characters between words. So in a paper
publishing context, it often does look superior because the extra
inserted space is subtle enough to not be noticable.

Performing auto-hyphenation and space stuffing to make an even right
edge with a fixed width font and a character cell terminal produces a
very ugly output.

snipeco.2@gmail.com (Sn!pe) writes:

> What about News Message-IDs and References? If properly delimited,
> MacSOUP can automatically search its stored articles for a match on
> M-IDs.

| group local.test
| 211 1 1 1 local.test
| post
| 340 Ok, recommended Message-ID <ucl...s$1@himalaya6...5id.onion>

Do message IDs ever appear without <...>?

Even digging back to RFC822 they seem to be always defined including
<...> so I wouldn't read that as optionally delimiting them and as
necessary part instead.

--
|rom The Future. +++ Breaking News From The Future. +++ Breaking News F|
| The USoA are switching to the binary number system because |
| having more than 1+1 distinct digits is far too woke. |
|+ #MABA + #makeAmericaBinaryAgain + #USA + #USoA + #woke + #MABA + #ma|

yeti <yeti@tilde.institute> wrote:

> snipeco.2@gmail.com (Sn!pe) writes:
>
> > What about News Message-IDs and References? If properly delimited,
> > MacSOUP can automatically search its stored articles for a match on
> > M-IDs.
>
> | group local.test
> | 211 1 1 1 local.test
> | post
> | 340 Ok, recommended Message-ID <ucl...s$1@himalaya6...5id.onion>
>
> Do message IDs ever appear without <...>?
>
> Even digging back to RFC822 they seem to be always defined including
> <...> so I wouldn't read that as optionally delimiting them and as
> necessary part instead.
>

Fair comment.

> --
> |rom The Future. +++ Breaking News From The Future. +++ Breaking News F|
> | The USoA are switching to the binary number system because |
> | having more than 1+1 distinct digits is far too woke. |
> |+ #MABA + #makeAmericaBinaryAgain + #USA + #USoA + #woke + #MABA + #ma|

--
^Ï^. – Sn!pe – <https://youtu.be/_kqytf31a8E>

My pet rock Gordon just is.

Sn!pe wrote:

> Examples below:-
>
> http://www.example.url.com <~~[original]

That's me quoting your non-delimited URL in thunderbird