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

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

[Florian von Savigny]

I'm trying to debug a function I have written which is meant to be
called in rmail buffers and basically should sort a message
somewhere. The directory of that somewhere should be returned by
another function which works well on its own:

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

"(current-contract)" returns a two-element list, of a directory name
(without its path) and the full path of this directory - hence, "(nth
1 ..."  returns that full path. This works fine, and up till today I
thought that if an expression returns something, it returns
it. Somehow I seem to have hit upon a proof to the contrary - consider
yourself:

(nth 1 (current-contract)) 

by itself returns (as I explained)

"/home/uebersetzer/auftraege/20040203.hau45147ess"

If this literal value is substituted for (nth 1 (current-contract)) in
the function definition, rmail-output-to-afile outputs the current
message to "/home/uebersetzer/auftraege/20040203.hau45147ess/putmail",
first asking whether it should create the file if it isn't there. This
is what I expect the function to do.

But if the function definition is left as above, it will only go as
far as asking whether it should create the file (if it isn't already
there). Then, it will emit the error "Wrong type argument: stringp,
nil", and stop.

The backtrace says:

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  rmail-output-to-rmail-file("/home/uebersetzer/auftraege/20040203.hau45147ess/putmail")
  rmail-output-to-afile()
* call-interactively(rmail-output-to-afile)
  execute-extended-command(nil)
  call-interactively(execute-extended-command)


This is either a no-brainer, or a deep mystery. To me, it's the
latter. Can anybody help me?

Thanks a lot!

-- 


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.

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

[Florian von Savigny]

Florian von Savigny <sawitzky2000@yahoo.de> writes:

> This is either a no-brainer, or a deep mystery. To me, it's the
> latter. Can anybody help me?

Well ... would anybody care to comment at all? I'd even be grateful
for, say "this can't happen", or whatever - I'm truly clueless.


-- 


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.

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

[FCC]

Florian von Savigny articulated on 01/04/05 20:16:

>Florian von Savigny <sawitzky2000@yahoo.de> writes:
>
>  
>
>>This is either a no-brainer, or a deep mystery. To me, it's the
>>latter. Can anybody help me?
>>    
>>
>
>Well ... would anybody care to comment at all? I'd even be grateful
>for, say "this can't happen", or whatever - I'm truly clueless.
>
>
>  
>
Well, I am not an expert, and I have never used any rmail stuff in
Emacs, but I can't help wondering if you have a permission problem in
creating the rmail file /putmail. According to GNU Emacs 21.3.50.1
(i686-pc-linux-gnu, X toolkit) of 2004-12-07 on I8600:
-----
rmail-output-to-rmail-file is an interactive autoloaded Lisp function in
`rmailout'.
(rmail-output-to-rmail-file file-name &optional count stay)

Append the current message to an Rmail file named file-name.
If the file does not exist, ask if it should be created.
If file is being visited, the message is appended to the Emacs
buffer visiting that file.
If the file exists and is not an Rmail file, the message is
appended in inbox format, the same way `rmail-output' does it.

The default file name comes from `rmail-default-rmail-file',
which is updated to the name you use in this command.

A prefix argument N says to output N consecutive messages
starting with the current one.  Deleted messages are skipped and don't
count.

If optional argument stay is non-nil, then leave the last filed
mesasge up instead of moving forward to the next non-deleted message.
-----

so it seems the file does not exist and it is trying to create it but
failing. So a permission problem? Disk full? Trying to write to an NTFS
partition? What else could it be, I have no idea...

Hope this helps,

-- 
FCC.

===
Another kiddie quote: "Daddy picked them up and looked underneath. I
think it's printed on the bottom." - 3 year old son, when his mother
asked how his father knew the genders of four new baby kittens.
-Anonymous

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

[FCC]

FCC articulated on 01/04/05 20:28:

> Well, I am not an expert, and I have never used any rmail stuff in
>
>Emacs, but I can't help wondering if you have a permission problem in
>creating the rmail file /putmail. According to GNU Emacs 21.3.50.1
>(i686-pc-linux-gnu, X toolkit) of 2004-12-07 on I8600:
>-----
>rmail-output-to-rmail-file is an interactive autoloaded Lisp function in
>`rmailout'.
>(rmail-output-to-rmail-file file-name &optional count stay)
>
>Append the current message to an Rmail file named file-name.
>If the file does not exist, ask if it should be created.
>If file is being visited, the message is appended to the Emacs
>buffer visiting that file.
>If the file exists and is not an Rmail file, the message is
>appended in inbox format, the same way `rmail-output' does it.
>
>The default file name comes from `rmail-default-rmail-file',
>which is updated to the name you use in this command.
>
>A prefix argument N says to output N consecutive messages
>starting with the current one.  Deleted messages are skipped and don't
>count.
>
>If optional argument stay is non-nil, then leave the last filed
>mesasge up instead of moving forward to the next non-deleted message.
>-----
>
>so it seems the file does not exist and it is trying to create it but
>failing. So a permission problem? Disk full? Trying to write to an NTFS
>partition? What else could it be, I have no idea...
>
>Hope this helps,
>
>  
>
On second thought, why don't you try to create /putmail manually and
call the function to see if it will work this time? Just a suggestion...

-- 
FCC.

===
... they make men small, cowardly and hedonistic--every time it is the
herd animal that triumphs with them. Liberalism: In other words,
herd-animalization.
-Friedrich Nietzsche. - Twilight of the Idols, chap 38, para. 1

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

[Kevin Rodgers]

Florian von Savigny wrote:
 > I'm trying to debug a function I have written which is meant to be
 > called in rmail buffers and basically should sort a message
 > somewhere. The directory of that somewhere should be returned by
 > another function which works well on its own:
 >
 > (defun rmail-output-to-afile ()
 >   (interactive)
 >   (rmail-output-to-rmail-file (concat
 > 			       (nth 1 (current-contract))
 > 			       "/putmail")))
...
 > But if the function definition is left as above, it will only go as
 > far as asking whether it should create the file (if it isn't already
 > there). Then, it will emit the error "Wrong type argument: stringp,
 > nil", and stop.
 >
 > The backtrace says:
 >
 > Debugger entered--Lisp error: (wrong-type-argument stringp nil)
 > 
rmail-output-to-rmail-file("/home/uebersetzer/auftraege/20040203.hau45147ess/putmail")
 >   rmail-output-to-afile()
 > * call-interactively(rmail-output-to-afile)
 >   execute-extended-command(nil)
 >   call-interactively(execute-extended-command)
 >
 >
 > This is either a no-brainer, or a deep mystery. To me, it's the
 > latter. Can anybody help me?

,----[ C-h f rmail-output-to-rmail-file RET ]
| rmail-output-to-rmail-file is an interactive autoloaded Lisp function 
in `rmailout'.
| [Arg list not available until function definition is loaded.]
|
| Append the current message to an Rmail file named FILE-NAME.
| If the file does not exist, ask if it should be created.
| If file is being visited, the message is appended to the Emacs
| buffer visiting that file.
| If the file exists and is not an Rmail file, the message is
| appended in inbox format, the same way `rmail-output' does it.
|
| The default file name comes from `rmail-default-rmail-file',
| which is updated to the name you use in this command.

Hmmm, perhaps that variable isn't set...

| A prefix argument N says to output N consecutive messages
| starting with the current one.  Deleted messages are skipped and don't 
count.
|
| If optional argument STAY is non-nil, then leave the last filed
| mesasge up instead of moving forward to the next non-deleted message.
`----

Then if you look at the source for rmail-output-to-rmail-file, it's
preceded by this comment:

;;; There are functions elsewhere in Emacs that use this function;
;;; look at them before you change the calling method.

I would try binding that variable, which is set by all the Emacs
commands that call rmail-output-to-rmail-file (via
rmail-output-read-rmail-file-name, C-h v):

(defun rmail-output-to-afile ()
   "Append the current message to the \"putfile\" Rmail file
in the `current-contract' directory.
See `rmail-output-to-file'."
   (interactive)
   (let ((rmail-default-rmail-file
          (expand-file-name "putmail" (nth 1 (current-contract)))))
     (rmail-output-to-rmail-file rmail-default-rmail-file)))

-- 
Kevin Rodgers

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

[Florian von Savigny]

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.