From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Florian von Savigny Newsgroups: gmane.emacs.help Subject: Re: very mysterious behaviour from rmail-output-to-rmail-file Date: Fri, 07 Jan 2005 21:42:51 +0100 Organization: 1&1 Internet AG Message-ID: References: <340lgqF44rhsnU1@individual.net> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1105130927 8866 80.91.229.6 (7 Jan 2005 20:48:47 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 7 Jan 2005 20:48:47 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Jan 07 21:48:41 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Cn12H-0002Jb-00 for ; Fri, 07 Jan 2005 21:48:41 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Cn1Dd-0004I9-K0 for geh-help-gnu-emacs@m.gmane.org; Fri, 07 Jan 2005 16:00:25 -0500 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!feed.news.tiscali.de!blackbush.cw.net!cw.net!feed.news.schlund.de!schlund.de!news.online.de!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 96 Original-NNTP-Posting-Host: pd9502779.dip0.t-ipconnect.de Original-X-Trace: online.de 1105130618 19043 217.80.39.121 (7 Jan 2005 20:43:38 GMT) Original-X-Complaints-To: abuse@einsundeins.com Original-NNTP-Posting-Date: Fri, 7 Jan 2005 20:43:38 +0000 (UTC) User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) Cancel-Lock: sha1:a8LttPblPZQ7YtRGQSqbMgi21A8= Original-Xref: shelby.stanford.edu gnu.emacs.help:127729 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.help:23200 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:23200 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.