Apologies for the empty report text; somewhere between reportbug,
emacsclient and vi, I wasn't given the opportunity to edit the report
before sending it ! My EDITOR=emacsclient didn't work, for reasons
unknown (and, apparently, specific to emacs23) so I told reportbug to
use vi; but (I now know) it somehow managed to invoke vi in a way that
left me editing a file called -c (in reportbug's working directory),
that didn't contain the package description; and, when saved, hadn't
changed the file reportbug was expecting me to edit; so I was obliged
to over-ride reportbug's unwillingness to submit the bug without an
edited body.
When I came to report the bug in reportbug, it threw me into
emacsclient (now working, as I've exited emacs23 and fallen back on
emacs22), but I found myself editing a buffer called -dir, on a file
in the working directory of reportbug - and, alongside it, was a file
named -c that contained the text I'd prepared, using vi, for this bug:
here's what it said <quote>
*sigh*
Additionally, I must sadly add that emacsclient doesn't seem to be working.
I *would* be editing this using emacsclient otherwise, but I'm forced to
use vi, because that at least *works* (damnit).
I restarted emacsclient in my running emacs23, to no avail.
Anyway, the error message I get when I try to load my mailbox says:
Wrote /disk/home/eddy/.sys/tmp/rmail738ElS
Writing messages to /disk/home/eddy/.sys/tmp/rmail738mIt...
byte-code: Removing old name: no such file or directory,
/disk/home/eddy/.sys/tmp/rmail738mIt
and I'm left with the babyl file loaded but not processed in rmail mode.
Trying to M-x rmail-mode in it, I get
Wrote /disk/home/eddy/.sys/tmp/rmail738M7U
Writing messages to /disk/home/eddy/.sys/tmp/rmail738ZFb...
byte-code: Removing old name: no such file or directory,
/disk/home/eddy/.sys/tmp/rmail738ZFb
so it seems the problem is really rmail-mode.
This (taken together with the failure of emacsclient) is fatal for
my use of emacs23; I'll go back to emacs22 in the mean time.
</quote> (I note that there is ample space on /tmp/:
<quote src="df /tmp">
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 9614116 6778496 2347248 75% /
</quote> so the problem wasn't that it'd run out of diskspace.)
<aside subject="emacsclient issues">
So I ran ps | grep to find out how emacsclient had been invoked:
emacsclient +6 /tmp/reportbug-reportbug-20090826-847-7U03sn
Perfectly sensible. So I opened that file, only to find I already had
an open buffer on it (that simply hadn't been visible, presumably
because -dir was opened in the same window later). I also turned out
to have an open buffer in dired-mode on the working directory of the
reportbug process; and C-x C-b also found the following:
-file 0 Fundamental /tmp/-file
-position 0 Fundamental /tmp/-position
screen.rxvt 0 Fundamental /tmp/screen.rxvt
% 4 0 Fundamental /dev/pts/4
% -tty 0 Fundamental /dev/pts/-tty
% -current-frame 0 Fundamental /dev/pts/-current-frame
I was, at least, able to edit the right file to cause that bug-report
to be submitted correctly; although I had to C-x # every one of the
buffers mentioned, before emacsclient returned to reportbug. This is
probably a mis-interaction between emacs23's emacsclient (which the
alternatives system has selected for me) and emacs22 - which I'm now
running, since emacs 23 doesn't work with rmail; I can't function
without that ! It works *better* with emacs22 than with emacs23, but
is still behaving strangely ... however, the evidence from emacs22
looks like it should give you some information on what emacsclient was
trying to do, that failed to work with emacs23.
</aside>
Eddy.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
