On 12/5/23 15:36, Scott Lurndal wrote:
> xrn does it perfectly. Opens a new composition window with the
> headers filled in and the cursor positioned after the ':' in
> the Subject: header.

Thunderbird does the same.

The pop-up I'm describing only happens if you send without having filled
in the subject.

--
Grant. . . .

Grant Taylor <gtaylor@tnetconsulting.net> writes:

> On 12/5/23 15:22, Julieta Shem wrote:
>> Let's dig further. How should a mail or a USENET client display a form
>> so that the user fills out the subject only after the whole message is
>> written?
>
> I'm sure there are ways.
>
> I would not choose to use such a client.

Lol.

>> The most obvious approach, I think, is to put the field at the bottom of
>> the message.
>
> I suspect that's going to cause other problems in and of itself. But
> you do you.

I suspect the same.

> I'd be more inclined to have the subject field at both the top and
> bottom if the top wasn't sufficient for some reason.

That's another idea.

>> We can expect users ...
> Nope. No we can't.

We can always expect --- for as long as we live. :-)

>> Many people couldn't care less, of course. Many people must think that
>> subjects are a totally useless thing.
>
> Then there are the opposite that write the entire message in the
> subject and nothing in the body.

Lol! These users think so highly of subjects that they actually think
it should be written seriously and in high-precision. Lol. I've seen
e-mails like that --- they're great.

>> For these people, perhaps the
>> client could write something else that would be minimally useful for us.
>> I don't what would be minimally useful.
>
> Or we could gently use societal push back and ask people to put a
> subject in place.

But we are a minority. It's them pushing us back.

>> In this case T'Bird misses the heart of the problem we're discussing
>> here. We're not discussing how to remember to write a subject, but to
>> only write it after the whole post is written, when it's much easier to
>> describe it in a few words. (Of course, it's nice to be remembered
>> about an empty subject.)
>
> If the subject is blank and you hit send, Thunderbird asks you for a
> subject. -- That sure seem to me like the subject being written
> after the rest of the message.

That is the subject being written after the rest of the message, but it
won't do anything for those people who write the subject first and then
compose the message afterwards.

By the way, I only noticed now that this is going to comp.lang.c. I've
set the follow-up-to header to comp.misc.

Julieta Shem <jshem@yaxenu.org> writes:
[...]
> Let's dig further. How should a mail or a USENET client display a form
> so that the user fills out the subject only after the whole message is
> written?

Perhaps news.software.readers would be a better place for this
discussion.

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

On Tuesday 5 December 2023 at 23:10:14 UTC+1, Julieta Shem wrote:

> By the way, I only noticed now that this is going to comp.lang.c. I've
> set the follow-up-to header to comp.misc.

You sure like the sound of your voice.

*Plonk*

Julio

["Followup-To:" header set to comp.misc.]
2023-12-05, Julieta Shem <jshem@yaxenu.org> schrieb:

[Schnipp]

> Let's dig further.

Please don't, at least not in comp.lang.c.

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

On Wednesday 6 December 2023 at 07:54:57 UTC+1, Jan van den Broek wrote:
> ["Followup-To:" header set to comp.misc.]
> 2023-12-05, Julieta Shem <js...@yaxenu.org> schrieb:
> [Schnipp]
>
> > Let's dig further.
>
> Please don't, at least not in comp.lang.c.

While comp.misc is the free dump for all, right?

I wish you too the "Tai" spammer...

*Plonk*

Julio

Julieta Shem <jshem@yaxenu.org> writes:

> True. Even if you're steeped in EMACS, Gnus is still hard to get to
> grips with. But surely the greatest feature of Gnus is precisely that
> it runs in the GNU EMACS.

Currently it has some 876 interactive (user-callable)
functions. Of these 618 are in the two major modes (Group
and. Summary/Article).

I'm pretty steeped, been using gnus since -- I forget, 1990? When
it first appeared? When it still had Masanobu UMEDA's name on it. --
forever. But I only read, post, occasionally killfile. Don't even
know what most of the other 873 functions are. But posting news is
almost exactly like sending email in Emacs, not at all hard to get to
grips with.

>
> But speaking of offline reading, one feature of Gnus that I really like
> is that when I open the first article on a thread, it downloads some
> subsequent articles, so when I ask for the next it is already there for
> me.

Using a really old version of Emacs, thus also of gnus. I *don't*
like software that downloads *anything* that I haven't explicitly
asked for.

Well, yew know, cranky old people, eh?

--
Mike Spencer Nova Scotia, Canada

Mike Spencer <mds@bogus.nodomain.nowhere> writes:

> Julieta Shem <jshem@yaxenu.org> writes:
>
>> True. Even if you're steeped in EMACS, Gnus is still hard to get to
>> grips with. But surely the greatest feature of Gnus is precisely that
>> it runs in the GNU EMACS.

Ohhhh yes, and too many functions on too many unprefixed keys just
increase the probability of accidentally performing something unwanted
by off-by-one typos. I screw up GNUS much more often than the parts of
emacs/org where functions need C- and/or M- modifiers. Hit shappens!

That's one of my reasons to keep separating my "business" mail and
private mail/news in different clients. Additionally my "business" mail
needs better HTML rendering than GNUS does. Well, I do not need better
HTML in GNUS, but previewing my org-to-html exports in a more capable
way without needing an external browser would be nicer and that probably
would add automagically to improve HTML rendering GNUS.

The occasional mix of some images with lots of plain text is ok with
GNUS, e.g. Hackaday via RSS gated through Gwene[0], but not much more of
HTML complexity than this.

> Using a really old version of Emacs, thus also of gnus. I *don't*
> like software that downloads *anything* that I haven't explicitly
> asked for.

I've not turned off prefetch, I just trust GNUS enough. In other
programs (especially modern blingbling with JS and such) or when
experimenting again with ISDN speed (8kBytes/sec) I would do so.

> Well, yew know, cranky old people, eh?

I only need a mirror to meet one of those.

____________

[0]: <nntp+news.gwene.org:gwene.com.hackaday>

--
1. Hitchhiker 30: (6) "No," said the old man, "that's just perfectly
normal paranoia. Everyone in the Universe has that."

Mike Spencer <mds@bogus.nodomain.nowhere> writes:

> Julieta Shem <jshem@yaxenu.org> writes:
>
>> True. Even if you're steeped in EMACS, Gnus is still hard to get to
>> grips with. But surely the greatest feature of Gnus is precisely that
>> it runs in the GNU EMACS.
>
> Currently it has some 876 interactive (user-callable)
> functions. Of these 618 are in the two major modes (Group
> and. Summary/Article).

Lol. Feature-rich!

It's really not for the new latest type of computer user. The GNU EMACS
seems to preserve a tradition not respected by these more recent system
builders such as Microsoft, Apple, Google et cetera. The GNU EMACS
developers still refuse to adapt the software to the change in computer
usage that took place after the commercialization of the Internet. Part
of the very essence of these new builders is precisely to change culture
if they can.

>> But speaking of offline reading, one feature of Gnus that I really like
>> is that when I open the first article on a thread, it downloads some
>> subsequent articles, so when I ask for the next it is already there for
>> me.
>
> Using a really old version of Emacs, thus also of gnus. I *don't*
> like software that downloads *anything* that I haven't explicitly
> asked for.

You got a point. I'm like that too, specially with graphical user
interfaces. For instance, if my windows are in some places, do keep
them there. If I did not ask for a window to pop-up, do not.

Speaking of which, here's something very annoying about the Python REPL
on the GNU EMACS --- it keeps the prompt at the bottom of the window.
If you C-l so that you move it to the middle of the screen, it goes
there, but type another expression and RET and it moves again to the
bottom. (``Who told you to scroll?'')

> Well, yew know, cranky old people, eh?

I say --- wise people.

yeti <yeti@tilde.institute> writes:

> Mike Spencer <mds@bogus.nodomain.nowhere> writes:
>
>> Julieta Shem <jshem@yaxenu.org> writes:
>>
>>> True. Even if you're steeped in EMACS, Gnus is still hard to get to
>>> grips with. But surely the greatest feature of Gnus is precisely that
>>> it runs in the GNU EMACS.
>
> Ohhhh yes, and too many functions on too many unprefixed keys just
> increase the probability of accidentally performing something unwanted
> by off-by-one typos.

Lol. That happens sometimes.

Speaking of Gnus, let me share some of my customization. The summary
buffer should not let names vary in width because that doesn't let
subjects align very well and the thread shapes are important to be
viewed properly. There should be some order in how we see data on the
screen. It shouldn't be messy.

I think we hardly care with whom we're talking to, so I reduced people's
names to three letters. I also like to see the article number in the
local NNTP server --- it hints you quickly at which articles arrived in
what order. Dates are also important, but usually day and month is
enough.

--8<---------------cut here---------------start------------->8---
(setq gnus-group-line-format "[%4U unread, %T ticked] %G (%t,%SL%L%B)\n")
(setq gnus-group-mode-line-format "%T%:%S")

(setq gnus-summary-line-format "%U%R%z%I%(%[%4L: %-23,23f%]%) %s\n")
(setq gnus-summary-line-format "%z[%U][%N] %d %ua%B%* %(%S%) [L%Lm%Os%i]\n")

(defun gnus-user-format-function-o (headers)
(letrec ((date-string (aref headers 3)))
(format-time-string "%m-%d %H.%M.%S" (date-to-time date-string))))

(defun name-clean-up (name)
(defun alphanum-p (c)
(or (and (<= 65 c) (<= c 90)) (and (<= 97 c) (<= c 122))))
(remove-if-not 'alphanum-p name))

(defun gnus-user-format-function-a (headers)
(letrec ((from (aref headers 2))
(names (split-string from))
(last-name (car (last names))))
(upcase (if (< (length from) 3) "XXX" (substring (name-clean-up from) 0 3)))))
--8<---------------cut here---------------end--------------->8---

Julieta Shem <jshem@yaxenu.org> writes:

> The summary buffer should not let names vary in width because that
> doesn't let subjects align very well and the thread shapes are
> important to be viewed properly.

Yip. I've constant width for names:

-----------------------------------8<-----------------------------------
O 20230908T145052 [Sn!pe ][ 0] +-> How to change the Subject of a Usenet article (Was: Re: Recent spam on comp.lang.c)
O 20230908T232734 [candycanearter0][ 0] | +-> Re: How to change the Subject of a Usenet article (Was: Re: Recent spam on comp.lang.c)
O 20230909T085712 [Sn!pe ][ 0] | | \-> Re: How to change the Subject of a Usenet article
O 20230909T205426 [candycanearter0][ 0] | | \->
O 20230909T210819 [Ben Bacarisse ][ 0] | | +->
----------------------------------->8-----------------------------------

The score shall shrink, but I haven't made up my mind about the width.
Probably I'll try to use only positive numbers to save the space for the
sign.

> I think we hardly care with whom we're talking to, so I reduced
> people's names to three letters.

I rarely expunge someone, but use scores instead to flag whom not to
reply. I may react differently depending on a mix of mood, daytime and
score to different names. When I don't remember any more which incident
caused that score for that user, I drop it. I just sometimes need a
break from someone. So the name still is needed.

> I also like to see the article number in the local NNTP server --- it
> hints you quickly at which articles arrived in what order. Dates are
> also important, but usually day and month is enough.

Article number ... nice idea! I cannot imagine to shorten the date any
further, not even the constant leading 20, so maybe I can drop the time
part for the article sequence number.

I'll let that ferment for a while before I try the next changes.

--
I tried to forget [Henry Kissinger], but instead I forgot why I wanted
to forget [Henry Kissinger]. -- yeti, 20231130T031316

My server buffer looks like this (only some nntp: entries copied):

-----------------------------------8<-----------------------------------
(closed) (agent) {nntp:nntp.aioe.org}
(opened) (agent) {nntp:news.eternal-september.org}
(opened) (agent) {nntp:news.gmane.io}
(opened) (agent) {nntp:news.gwene.org}
(opened) (agent) {nntp:news.sdf.org}
(opened) (agent) {nntp:news.tilde.club}
(closed) {nntp:news.uni-stuttgart.de}
(offline) (agent) {nntp:retrobsd.ddns.net}
(offline) (agent) {nntp:swarm0}
----------------------------------->8-----------------------------------

Loosely related:

I miss aioe, so I keep it in the config for nostalgia. Despite only
having posted very infrequently via aioe, waiting for it to come up
again made me realise how much I missed Usenet and so I looked for two
alternatives for not having that situation again.

--
( Are we there yet? )
\ ( Be patient! )
\ \
_______________________ _@o ____________ _@o _@o _______________________

Julieta Shem <jshem@yaxenu.org> writes:

> Speaking of which, here's something very annoying about the Python REPL
> on the GNU EMACS --- it keeps the prompt at the bottom of the window.
> If you C-l so that you move it to the middle of the screen, it goes
> there, but type another expression and RET and it moves again to the
> bottom. (``Who told you to scroll?'')

There are two variables with which you can change this behaviour:

comint-scroll-to-bottom-on-output and
comint-scroll-to-bottom-on-input

I guess you want to setq them to nil.

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

> Julieta Shem <jshem@yaxenu.org> writes:
>
>> Speaking of which, here's something very annoying about the Python REPL
>> on the GNU EMACS --- it keeps the prompt at the bottom of the window.
>> If you C-l so that you move it to the middle of the screen, it goes
>> there, but type another expression and RET and it moves again to the
>> bottom. (``Who told you to scroll?'')
>
> There are two variables with which you can change this behaviour:
>
> comint-scroll-to-bottom-on-output and
> comint-scroll-to-bottom-on-input
>
> I guess you want to setq them to nil.

It does look like I want to set them to nil, but so far no effect on the
*Python* buffer, having closed it restarted it. (Thanks!)

--8<---------------cut here---------------start------------->8---
comint-scroll-to-bottom-on-output is a variable defined in ‘comint.el’.
Its value is nil
Local in buffer *Python*; global value is the same.

This variable is an alias for ‘comint-move-point-for-output’.
You can customize this variable.
Probably introduced at or before Emacs version 19.23.
--8<---------------cut here---------------end--------------->8---

--8<---------------cut here---------------start------------->8---
comint-scroll-to-bottom-on-input is a variable defined in ‘comint.el’.
Its value is nil

This variable’s value is permanent if it is given a local binding.
You can customize this variable.
Probably introduced at or before Emacs version 19.23.
--8<---------------cut here---------------end--------------->8---

Julieta Shem <jshem@yaxenu.org> writes:

> Joerg Mertens <joerg-mertens@t-online.de> writes:
>
>> Julieta Shem <jshem@yaxenu.org> writes:
>>
>>> Speaking of which, here's something very annoying about the Python
>>> REPL
>>> on the GNU EMACS --- it keeps the prompt at the bottom of the
>>> window.
>>> If you C-l so that you move it to the middle of the screen, it goes
>>> there, but type another expression and RET and it moves again to
>>> the
>>> bottom. (``Who told you to scroll?'')
>>
>> There are two variables with which you can change this behaviour:
>>
>> comint-scroll-to-bottom-on-output and
>> comint-scroll-to-bottom-on-input
>>
>> I guess you want to setq them to nil.
>
> It does look like I want to set them to nil, but so far no effect on
> the
> *Python* buffer, having closed it restarted it. (Thanks!)

You're right. The variables that works here (for shell mode, at least) is

comint-scroll-show-maximum-output

I also set the other two but they default to nil anyway so
they dont't change anything.

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

> Julieta Shem <jshem@yaxenu.org> writes:
>
>> Joerg Mertens <joerg-mertens@t-online.de> writes:
>>
>>> Julieta Shem <jshem@yaxenu.org> writes:
>>>
>>>> Speaking of which, here's something very annoying about the Python
>>>> REPL
>>>> on the GNU EMACS --- it keeps the prompt at the bottom of the
>>>> window.
>>>> If you C-l so that you move it to the middle of the screen, it goes
>>>> there, but type another expression and RET and it moves again to
>>>> the
>>>> bottom. (``Who told you to scroll?'')
>>>
>>> There are two variables with which you can change this behaviour:
>>>
>>> comint-scroll-to-bottom-on-output and
>>> comint-scroll-to-bottom-on-input
>>>
>>> I guess you want to setq them to nil.
>>
>> It does look like I want to set them to nil, but so far no effect on
>> the
>> *Python* buffer, having closed it restarted it. (Thanks!)
>
> You're right. The variables that works here (for shell mode, at least) is
>
> comint-scroll-show-maximum-output
>
> I also set the other two but they default to nil anyway so
> they dont't change anything.

A little reflection shows that the motion is relative to the window.
It's seems more like the effect of (recenter -1). Evaluate this
function on your GNU EMACS. It'll recenter your buffer moving your
point to the base of the window.

We could now read the Python mode and see whether it recenters at any
point in the code. Indeed, we find...

--8<---------------cut here---------------start------------->8---
(defun python-comint-postoutput-scroll-to-bottom (output)
"Faster version of `comint-postoutput-scroll-to-bottom'.
Avoids `recenter' calls until OUTPUT is completely sent."
(when (and (not (string= "" output))
(python-shell-comint-end-of-output-p
(ansi-color-filter-apply output)))
(comint-postoutput-scroll-to-bottom output))
output)

(defun comint-postoutput-scroll-to-bottom (_string)
"Go to the end of buffer in some or all windows showing it.
Do not scroll if the current line is the last line in the buffer.
Depends on the value of `comint-move-point-for-output' and
`comint-scroll-show-maximum-output'.

This function should be in the list `comint-output-filter-functions'."
(let* ((current (current-buffer))
(process (get-buffer-process current)))
(unwind-protect
(cond
((null process))
((bound-and-true-p follow-mode)
(follow-comint-scroll-to-bottom))
(t
(dolist (w (get-buffer-window-list current nil t))
(comint-adjust-window-point w process)
;; Optionally scroll to the bottom of the window.
(and comint-scroll-show-maximum-output
(eq (window-point w) (point-max))
(with-selected-window w
(recenter (- -1 scroll-margin)))))))
(set-buffer current))))
--8<---------------cut here---------------end--------------->8---

So the culprit is comint-scroll-show-maximum-output. I get what I like
with

(setq comint-scroll-show-maximum-output nil).

Thank you so much.