🚀 go-pugleaf

In article <GROSSJOH.92Oct1135811@lucy.ls6.informatik.uni-dortmund.de>, Kai Grossjohann writes:

> I use VM 5.31 and Supercite 2.2. They do not work well together because:

I use SC 2.1, and have the same problem.

> Sometimes a message does not have a "From:" field displayed. Then
> Supercite does not know who the message is from and so all headers
> (it's got 7 different headers) are empty. There is always a "From "
> field (note the space!), though it is not displayed.

In addition, when you reply to this message using 'R', or use C-c C-y to
yank the text into a messafe, the included text is preceded by "from
writes:".

Either VM or SC should read the "From " line and display it if there is
no "From:" line.

--
David Grabiner, grabiner@zariski.harvard.edu
"We are sorry, but the number you have dialed is imaginary."
"Please rotate your phone 90 degrees and try again."
Disclaimer: I speak for no one and no one speaks for me.

I found out that VM 5.31 deletes the "From:" line somehow. I sent a message to
myself and then looked at /var/spool/mail/grossjoh. It contained the message
including a "From:" line.

Then I told VM to "g"et new mail and looked at my INBOX file. It did not contain
the "From:" line any more. So I think that somehow at sometime VM automagically
deletes some headers and I could not find out anything about this looking at the
source code and documentation.

How can I turn this off, if there is a way to do it?

        Kai
--
--
  Kai Grossjohann            Phone (voice): 49 231 75 30 15
  Baroper Str. 331 App. 510  E-Mail: 
  W-4600 Dortmund 50         grossjoh@ls6.informatik.uni-dortmund.de
  Germany                    
--
This sentence was in the past tense.
                        -- D. Hofstadter

I just took a look at this thread so let me make a few comments.  The
first thing to understand is that supercite *by definition* doesn't
really know anything about VM (or GNUS, RMAIL, or any other reader it
can be connect to).  There is a well defined interface which SC
expects and which VM meets as distributed (yay Kyle!).  Other readers,
such as GNUS need certain functions to be overloaded in order to meet
this interface.  See the SC2.2 texinfo document for more information
on this interface.

SC is only called on a region of the reply buffer; ie point and mark
delineate the area that SC will cite.  The mail headers which SC will
use to extract information must be at the top of this region, and this
is the only information that SC parses before it starts to do its
thing.  So looking at the "From " line (no colon) isn't an option. SC
never sees the original mail or news article that might contains this
line.

SC expects that *all* mail headers be inserted into the reply buffer
region.  Its SC's job to remove what's not wanted based on the user's
preferences (there are sc-* variables for controlling this). I don't
know why your VM would not be including the From: line in the reply,
but it should.  You can take a look at the mail headers inserted by
toggling sc-nuke-mail-headers-p to nil (you may also want to setq
sc-auto-fill-region-p to nil, then once the article is cited, hit undo
once).  If the From: line's not there, its a problem with VM, but
you're right, SC won't be able to figure out things like the author's
name and email address if there's no From: line.  SC2.2 should be a
bit saner than 2.1 in writing the header when there's no From: line.

Also, I don't like the idea of SC parsing the X-VM-v5-Data for
information.  SC is supposed to be a general package, not specific to
VM, and I don't want to have to track any future changes to this that
Kyle may implement for VM enhancements.

First figure out why there's no From: line in your reply buffer, and
we'll go from there.

-Barry

PS. I personally use VM 5.32 (and GNUS 3.14) with SC 2.2, so I *know*
it works :-)

>>>>> On 7 Oct 92 01:10:54 GMT, warsaw@nlm.nih.gov (Barry A. Warsaw) said:

In article <WARSAW.92Oct6201054@anthem.nlm.nih.gov> warsaw@nlm.nih.gov (Barry A. Warsaw) writes:

Hello there,

I feel very much ashamed. Supercite not working together with VM was ENTIRELY
and utterly my fault:

> SC expects that *all* mail headers be inserted into the reply buffer
> region.  Its SC's job to remove what's not wanted based on the user's
> preferences (there are sc-* variables for controlling this). I don't
> know why your VM would not be including the From: line in the reply,
> but it should.  

Well, I know. I was really stupid there.

> Also, I don't like the idea of SC parsing the X-VM-v5-Data for
> information.  SC is supposed to be a general package, not specific to
> VM, and I don't want to have to track any future changes to this that
> Kyle may implement for VM enhancements.

> First figure out why there's no From: line in your reply buffer, and
> we'll go from there.

The reason is:

I added a hack to VM to have it read mail from a certain computer. Here at
Dortmund University, we have a network of several computers with an NFS-mounted
/home file system. I have a ~/.forward file directing my mail to a certain
computer. I did not like the idea of always starting an Emacs on my "mail host"
just for reading mail. Thus the hack.

The hack basically works by calling a subshell remotely on my "mail host". There
the Unix program "mail" is called and told to save the mail in a spool file in
my home directory. Then, the usual VM procedures take over.

Now, when "mail" is told to save the mail in a file, and if the variable
"alwaysignore" has been set, the From: lines are deleted from the messages
before saving. Therefore, VM never sees the From: line.

I changed "vm-check-for-spooled-mail" to always return "t" if Emacs is not
running on the "mail host". Otherwise it just does what it usually does.
"vm-get-spooled-mail"  has been changed to calling the subshell remotely on the
"mail host".

Is there anybody with a cleaner solution to reading mail on a remote host than
mine?

                Kai
--
  Kai Grossjohann            Phone (voice): 49 231 75 30 15
  Baroper Str. 331 App. 510  E-Mail: 
  W-4600 Dortmund 50         grossjoh@ls6.informatik.uni-dortmund.de
  Germany