Re: very mysterious behaviour from rmail-output-to-rmail-file

[Florian von Savigny <sawitzky2000@yahoo.de>]

Hi Kevin and "FCC" ;-)


I thought I might rephrase the problem because I seem to be sure to
have pinpointed it:


---- buffer *scratch* ----

(current-contract)
--> ("auftrag" "/home/uebersetzer/auftraege/auftrag")


(defun rmail-output-to-afile ()
  (interactive)
  (rmail-output-to-rmail-file (concat 
			       (nth 1 (current-contract))
			       "/putmail")))


(defun rmail-output-to-a-certain-file ()
  (interactive)
  (rmail-output-to-rmail-file (concat 
			       "/home/uebersetzer/auftraege/auftrag"
			       "/putmail")))

---- snap ----



(concat (nth 1 (current-contract)) "/putmail") and (concat
"/home/uebersetzer/auftraege/auftrag" "/putmail") should return
exactly the same, as long as (current-contract) returns the list
specified above (and this it does; the function also does not behave
differently in RMAIL buffers - I've checked this by making it
interactive and instructing it to print the list instead of just
returning it if called interactively).

Yet, of the two functions specified above, only
rmail-output-to-a-certain-file works as expected (adding the message
to "/home/uebersetzer/auftraege/auftrag/putmail"); the other one
causes the error already described. Since both functions write to the
same file, and were repeatedly tested in the same buffer, I cannot see
how this could be a problem with file permissions (it's the same file,
the same user, the same instance of emacs, the same buffer inside
emacs, the same person typing the keyboard - ... er, never mind).

Very curiously, _both_ functions offer to create the rmail file
putmail if it does not yet exist in the directory, and _both_
functions do in fact create it. This seems to back up what I said in
the last but one paragraph. And yet, there MUST be some difference
between the thingy returned by the expression using the function
current-contract and the thingy returned by the expression
concatenating the two literal strings. And it must be _after_
rmail-output-to-file creates the rmail file (if not yet there) that it
suddenly gets into problems with the thingy returned by the former
expression.

I've also tested your proposal, Kevin, which regrettably hasn't
fulfilled my wild hopes (sometimes things I don't understand work
perfectly, so I wouldn't have been surprised too much). The variable
rmail-default-rmail-file has the value "~/XMAIL", and binding it
temporarily to the desired value as you have suggested hasn't changed
things. The error message is still: "Wrong type argument: stringp,
nil". -- What is rmail-output-read-rmail-file-name? I haven't found a
function or variable of that name on my system.

If there is anything wrong with the data type, what could it be?
Because testing in the rmail buffer is of course not as easy as in the
*scratch* buffer, I'm still unsure whether there isn't some subtle
difference. (equal )'ing both expression returns t in both buffers,
though [for the rmail buffer, I've again simply wrapped this into
(defun () (interactive) (print ...))]. Or is the error simply a
complaint of getting nil instead of a string?

This is somewhat preliminary - yes, I will have a look at the source
code of rmail-output-to-rmail-file (I wouldn't know how to find out
which other functions use it, though).

Lastly: if there is anything wrong with my reasoning, I'd be very
grateful to be pointed to the error...



-- 


Florian v. Savigny

If you are going to reply in private, please be patient, as I only
check for mail something like once a week. - Si vous allez répondre
personellement, patientez s.v.p., car je ne lis les courriels
qu'environ une fois par semaine.