help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: problem reading ~/.emacs.desktop


From: ken
Subject: Re: problem reading ~/.emacs.desktop
Date: Wed, 16 Sep 2009 04:14:56 -0400
User-agent: Thunderbird 2.0.0.22 (X11/20090625)

On 09/15/2009 05:37 AM Juanma Barranquero wrote:
> On Tue, Sep 15, 2009 at 11:24, ken <gebser@mousecar.com> wrote:
> 
>> My (uneducated) hunch is that desktop-create-buffer doesn't like the
>> first argument.  This argument is a number (which in my email client is
>> displayed as an 'I' with a diacritical mark above it). When the above
>> Debugger output is displayed in emacs the number is '\315'.  If I look
>> at this ~/.emacs.desktop file with the "less" command, it is displayed
>> as "<81><CD>"... for every instance of a buffer.  (?)
>>
>> According to the emacs doc on "desktop-create-buffer", this first arg is
>> "desktop-file-version"; I don't know what that is and have no idea why
>> the function "desktop-file-version" doesn't like it.
>>
>> Anybody able to figure out what this problem is?
> 
> Can you edit the desktop file and change these Í to 205 (the literal
> string "205", I mean)? The version number should be a literal, for
> example:
> 
> (desktop-create-buffer 206
>   "c:/my-file"
>   ... etc)
> 
> Can you move aside your current desktop file and recreate one with
> `desktop-save' (or `desktop-save-in-desktop-dir') to see whether it is
> correctly created?
> 
>     Juanma

Juanma,

Thanks much for replying.  You and I are thinking the same.  But emacs
isn't thinking like either of us.

The "desktop-file-version" argument *is* an integer... but in our email
clients it is being *displayed* as a character.  In emacs as I view the
old ".emacs.desktop" on my system (not in the Debugger, but as a normal
file/buffer), it displays as "205" (without the quotes).  The Linux
"less" command displays the same.

In the newly created ".emacs.desktop" file (created by the upgraded
version of emacs), this same argument is displayed as an 'I' with a
diacritical mark over it-- the same as the old one was in the Debugger.
  (?)  The value of that character (as determined by "C-x =") is 205.
This I don't understand: it's as if the Debugger incorrectly interpreted
the correct integer as a character and then complained about it.

Well, I used another workaround: I found that if I loaded the old
".emacs.desktop" into a buffer and then did "C-x e" at the end of each
"(desktop-create-buffer ...)", it would properly load each buffer....
Well, there were a couple files (out of over 100) which, for irrelevant
reasons, were absent from my system.  But none of the missing files were
what the Debugger complained about-- and the message which the Debugger
gave said nothing about a missing file, but rather indicated that the
first argument somehow was incorrect.  See my previous email.

Using the above workaround, I successfully load (nearly) all files
listed in ".emacs.desktop" into emacs buffers.  And I can see them all
using "C-x b" and I can visit them all.  But then I do a "desktop-save"
as you recommended, quit emacs, start emacs again, and get the same
Debugger error message again.

So then I edited ".emacs.desktop" to replace the 'I' with the
diacritical mark with "205" (without the quotes).  And I comment out the
code in ~/.emacs which invokes "desktop-read" and "desktop-save" and
reload emacs and run these by hand.  I find that emacs has changed "205"
to "206".  And though the files are read into emacs fine, I get this
different error from Debugger:

Debugger entered--Lisp error: (error "Local variables entry is missing
the suffix")
  signal(error ("Local variables entry is missing the suffix"))
  error("Local variables entry is missing the suffix")
  hack-local-variables()
  normal-mode(t)
  after-find-file(nil t)
  find-file-noselect-1(#<buffer g-mob> "~/pub/g-mob" nil nil
"~/pub/g-mob" (38245125 64771))
  find-file-noselect("/home/zl/pub/g-mob")
  desktop-restore-file-buffer("/home/zl/pub/g-mob" "g-mob" nil)
  #[nil "      A

This error isn't clear enough for me to figure out.  And it's probably
over the head of most, if not all, of the people on this list.  But if
anyone has a cogent guess as to how to fix this, I'd be willing to give
it a try.

Thanks again, Juanma, for your help.  It got me a little further toward
resolution.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]