desktop-read usage and syntax ::error, strange character

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

desktop-read usage and syntax ::error, strange character

ken-93
For some reason, when booting after a crash, the desktop isn't loaded;
that is, the files which were loaded in the previous (crashed) session
aren't loaded again.  I suspected this was due to
"~/.emacs/.emacs.desktop.lock", so I deleted it.  Then I close emacs and
start it again, but still the desktop isn't loaded.

So then I try to load it by hand, ie, I run "M-x desktop-read"... this
yields the error: "eval-buffer: Symbol's value as variable is void: Î".  
Yes, the last character is a capital "I" with a carot above it.  If,
from the "*scratch*" buffer I run (desktop-read "/home/user/.emacs.d/"),
I get exactly the same error message.

Anyone know what's going on?



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: desktop-read usage and syntax ::error, strange character

Sharon Kimble-2
ken <[hidden email]> writes:

> For some reason, when booting after a crash, the desktop isn't loaded; that is, the files which were
> loaded in the previous (crashed) session aren't loaded again.  I suspected this was due to
> "~/.emacs/.emacs.desktop.lock", so I deleted it.  Then I close emacs and start it again, but still
> the desktop isn't loaded.
>
> So then I try to load it by hand, ie, I run "M-x desktop-read"... this yields the error:
> "eval-buffer: Symbol's value as variable is void: Î".  Yes, the last character is a capital "I" with
> a carot above it.  If, from the "*scratch*" buffer I run (desktop-read "/home/user/.emacs.d/"), I
> get exactly the same error message.
>
> Anyone know what's going on?
I've had the same problem too, and the only thing that I can do is to
restore my buffers from memory. I use tabbar so its a bit easier as I
have tabs grouped by the major mode that they're using.

I also back up my 'emacs.desktop' every night at 1800, along with my
config file and my theme too, so its always possible for me to import
any of these files if the original one gets corrupted.

Thanks
Sharon.
--
A taste of linux = http://www.sharons.org.uk
TGmeds = http://www.tgmeds.org.uk
DrugFacts = https://www.drugfacts.org.uk 
Debian 9.0, fluxbox 1.3.5-2, emacs 25.1.1, org-mode 9.0.9

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: desktop-read usage and syntax ::error, strange character

ken-93
On 07/18/2017 01:07 PM, Sharon Kimble wrote:

> ken <[hidden email]> writes:
>
>> For some reason, when booting after a crash, the desktop isn't loaded; that is, the files which were
>> loaded in the previous (crashed) session aren't loaded again.  I suspected this was due to
>> "~/.emacs/.emacs.desktop.lock", so I deleted it.  Then I close emacs and start it again, but still
>> the desktop isn't loaded.
>>
>> So then I try to load it by hand, ie, I run "M-x desktop-read"... this yields the error:
>> "eval-buffer: Symbol's value as variable is void: Î".  Yes, the last character is a capital "I" with
>> a carot above it.  If, from the "*scratch*" buffer I run (desktop-read "/home/user/.emacs.d/"), I
>> get exactly the same error message.
>>
>> Anyone know what's going on?
> I've had the same problem too, and the only thing that I can do is to
> restore my buffers from memory. I use tabbar so its a bit easier as I
> have tabs grouped by the major mode that they're using.
>
> I also back up my 'emacs.desktop' every night at 1800, along with my
> config file and my theme too, so its always possible for me to import
> any of these files if the original one gets corrupted.
>
> Thanks
> Sharon.

Sharon, thanks for your reply. There's a lot there though which I'm not
understanding.  For instance, what do you meanfur that you 'restore them
from memory'?  And what is tabbar...? and what are tabs?

I also backup my ".emacs.desktop", but just by hand at times that feel
appropriate.  Maybe I should use a cron job like you do.

A cludge I've used in the past to restore my desktop was simple:  in
emacs I created a macro which searched out the next filename in
~/.emacs.d/.emacs.desktop and then simply did "C-f 5" on it. Because the
focus was on the new window/frame, I then had to "Ctrl-Tab" back to the
first window/frame and run the macro again for the next filename.  Not
very streamlined.  Also, I lose the last-known location of the cursor in
each file opened this way. Does anyone know which number (or whatever)
in the stanzas in ~/.emacs.d/.emacs.desktop which represents the point
in the buffer of the file?

Thanks to any and all with further clues.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: desktop-read usage and syntax ::error, strange character

John Mastro
In reply to this post by ken-93
ken <[hidden email]> wrote:

> For some reason, when booting after a crash, the desktop isn't loaded;
> that is, the files which were loaded in the previous (crashed) session
> aren't loaded again. I suspected this was due to
> "~/.emacs/.emacs.desktop.lock", so I deleted it. Then I close emacs
> and start it again, but still the desktop isn't loaded.
>
> So then I try to load it by hand, ie, I run "M-x desktop-read"... this
> yields the error: "eval-buffer: Symbol's value as variable is void:
> Î". Yes, the last character is a capital "I" with a carot above it.
> If, from the "*scratch*" buffer I run (desktop-read
> "/home/user/.emacs.d/"), I get exactly the same error message.

I can't offer any specific help, but if your desktop file is corrupted
(which is what it sounds like), it's probably worth reporting that as a
bug. Perhaps that's can't be reasonably avoided after a crash, but
perhaps it can, and the Emacs developers would know best.

        John

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: desktop-read usage and syntax ::error, strange character :: half-SOLVED!!!

ken-93
On 07/18/2017 03:59 PM, John Mastro wrote:

> ken <[hidden email]> wrote:
>> For some reason, when booting after a crash, the desktop isn't loaded;
>> that is, the files which were loaded in the previous (crashed) session
>> aren't loaded again. I suspected this was due to
>> "~/.emacs/.emacs.desktop.lock", so I deleted it. Then I close emacs
>> and start it again, but still the desktop isn't loaded.
>>
>> So then I try to load it by hand, ie, I run "M-x desktop-read"... this
>> yields the error: "eval-buffer: Symbol's value as variable is void:
>> Î". Yes, the last character is a capital "I" with a carot above it.
>> If, from the "*scratch*" buffer I run (desktop-read
>> "/home/user/.emacs.d/"), I get exactly the same error message.
> I can't offer any specific help, but if your desktop file is corrupted
> (which is what it sounds like), it's probably worth reporting that as a
> bug. Perhaps that's can't be reasonably avoided after a crash, but
> perhaps it can, and the Emacs developers would know best.
>
>          John

Yeah, that's pretty vague... I'd think the people fielding bug reports
would toss such a report without a lot more to help track it down.  
However, you were spot on.  Here's the deal:

Most of the info in .emacs.desktop is inscrutable... I don't know what
the bejesus it is.  I even saw a bunch of lines like this:

> (desktop-create-buffer <81><CE>
(81x = 129d ; CEx = 206d !!!)


and didn't think it terribly odd.  But then I compared that file to one
of the backups I have of previous versions of the same file and, instead
of the "<81><CE>", there was "206"... in every case.  So I did a
search-and-replace on the weird characters, making them into "206", then
ran (desktop-read "/home/user/.emacs.d") again, and, viola, all my
desktop files were properly loaded.  So, thanks, thanks, thanks... I can
get back to work now.

I can say with certainty that the garbage characters (in the stead of
"206") weren't due to the crash; my last ".emacs.desktop" saved was over
a week ago, well before the crash.  Secondly, I don't see how a system
crash would change every instance of "206" interspersed throughout a
file to "<81><CE>".  I think that's pretty much infunkingpossible to happen.

Moreover, after all my desktop files were loaded, I ran "M-x
desktop-save" and looked to the new .emacs.desktop file, and no more
"<81><CE>" characters.  But emacs seems to be having sporadic problems
correctly representing characters, so that's a possibility.

Thanks again, John, for the suggestion.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: desktop-read usage and syntax ::error, strange character :: half-SOLVED!!!

Yuri Khan-2
On Wed, Jul 19, 2017 at 4:10 AM, ken <[hidden email]> wrote:

> Most of the info in .emacs.desktop is inscrutable... I don't know what the
> bejesus it is.  I even saw a bunch of lines like this:
>
>> (desktop-create-buffer <81><CE>
>
> (81x = 129d ; CEx = 206d !!!)
>
> and didn't think it terribly odd.  But then I compared that file to one of
> the backups I have of previous versions of the same file and, instead of the
> "<81><CE>", there was "206"... in every case.

The docstring for ‘desktop-create-buffer’ calls its first argument
FILE-VERSION. It is reasonable to expect that it’s an integer such as
206.

However, integers are also used as character codes, and 206 is the
character code of Î (U+00CE Latin capital letter I with circumflex).
In the UTF-8 encoding, this character is represented by two bytes 0x81
0xCE.

It is as if under some circumstances the code that saves the desktop
file writes the version as a character code instead of a decimal
integer.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: desktop-read usage and syntax ::error, strange character

Sharon Kimble-2
In reply to this post by ken-93
ken <[hidden email]> writes:

> On 07/18/2017 01:07 PM, Sharon Kimble wrote:
>> ken <[hidden email]> writes:
>>
>>> For some reason, when booting after a crash, the desktop isn't loaded; that is, the files which were
>>> loaded in the previous (crashed) session aren't loaded again.  I suspected this was due to
>>> "~/.emacs/.emacs.desktop.lock", so I deleted it.  Then I close emacs and start it again, but still
>>> the desktop isn't loaded.
>>>
>>> So then I try to load it by hand, ie, I run "M-x desktop-read"... this yields the error:
>>> "eval-buffer: Symbol's value as variable is void: Î".  Yes, the last character is a capital "I" with
>>> a carot above it.  If, from the "*scratch*" buffer I run (desktop-read "/home/user/.emacs.d/"), I
>>> get exactly the same error message.
>>>
>>> Anyone know what's going on?
>> I've had the same problem too, and the only thing that I can do is to
>> restore my buffers from memory. I use tabbar so its a bit easier as I
>> have tabs grouped by the major mode that they're using.
>>
>> I also back up my 'emacs.desktop' every night at 1800, along with my
>> config file and my theme too, so its always possible for me to import
>> any of these files if the original one gets corrupted.
>>
>> Thanks
>> Sharon.
Hi Ken, answers in line.

> Sharon, thanks for your reply. There's a lot there though which I'm not understanding.  For
> instance, what do you meanfur that you 'restore them from memory'?  And what is tabbar...? and what
> are tabs?

I remember what files I had open before the 'emacs.desktop' corruption
and I then use that memory to help me load them back into emacs. It just
uses brain power and brain memory to tell me what buffers I had open,
and which I therefore need to reload.

Tabbar and tabbar-ruler [fn:1] help you by having each buffers title
shown in tabs at the top of the emacs buffer. These tabs are similar to
the tabs you can find in most internet browsers, think firefox,
chromium, Vivaldi, etc. You can move very easily between them by using
your mouse, or perhaps keyboard but I'm not sure of that. Anyway, every
buffer is a tab, and tabs are grouped together dependant on their major
mode. So all elisp buffers are grouped together, and ditto with
org-mode, etc. Both programs are available from ELPA, and if you're
still using your mouse then they're very worthwhile.

>
> I also backup my ".emacs.desktop", but just by hand at times that feel appropriate.  Maybe I should
> use a cron job like you do.

Its saved my bacon on several occasions! I can recommend it </advert end> :)

Thanks
Sharon.

[fn:1] http://github.com/mlf176f2/tabbar-ruler.el
--
A taste of linux = http://www.sharons.org.uk
TGmeds = http://www.tgmeds.org.uk
DrugFacts = https://www.drugfacts.org.uk 
Debian 9.0, fluxbox 1.3.5-2, emacs 25.1.1, org-mode 9.0.9

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: desktop-read usage and syntax ::error, strange character

ken-93
On 07/19/2017 07:11 AM, Sharon Kimble wrote:
>> Sharon, thanks for your reply. There's a lot there though which I'm not understanding.  For
>> instance, what do you meanfur that you 'restore them from memory'?  And what is tabbar...? and what
>> are tabs?
> I remember what files I had open before the 'emacs.desktop' corruption
> and I then use that memory to help me load them back into emacs. It just
> uses brain power and brain memory to tell me what buffers I had open,
> and which I therefore need to reload.

:-D  That was my second choice for interpretations.  The first was that
you had an app to search through RAM.  Back in the DOS days there was
such a thing.  Haven't heard of such a creature for Linux (though it
wouldn't be a huge job to code it).

> Tabbar and tabbar-ruler [fn:1] help you by having each buffers title
> shown in tabs at the top of the emacs buffer. These tabs are similar to
> the tabs you can find in most internet browsers, think firefox,
> chromium, Vivaldi, etc. You can move very easily between them by using
> your mouse, or perhaps keyboard but I'm not sure of that. Anyway, every
> buffer is a tab, and tabs are grouped together dependant on their major
> mode. So all elisp buffers are grouped together, and ditto with
> org-mode, etc. Both programs are available from ELPA, and if you're
> still using your mouse then they're very worthwhile.

Okay, thanks.  That sounds cool.  Yeah, I'm well aware of tabs in
general, but had never seen or heard of them for emacs.  Sounds like
that would be handy in situations... though many times I need to have
two buffers visible at the same time, or also one and the same buffer
open in two different frames, both visible at the same time. So do
tabbar/tabbar-ruler allow that as well, say, by doing "C-x 5 b
chosen-buf"...? or is it mandated that henceforth all buffers will be
tabbed and only so (so long as tabbar/tabbar-ruler is invoked)?


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: desktop-read usage and syntax ::error, strange character :: half-SOLVED!!!

ken-93
In reply to this post by Yuri Khan-2
On 07/19/2017 02:46 AM, Yuri Khan wrote:

> On Wed, Jul 19, 2017 at 4:10 AM, ken <[hidden email]> wrote:
>
>> Most of the info in .emacs.desktop is inscrutable... I don't know what the
>> bejesus it is.  I even saw a bunch of lines like this:
>>
>>> (desktop-create-buffer <81><CE>
>> (81x = 129d ; CEx = 206d !!!)
>>
>> and didn't think it terribly odd.  But then I compared that file to one of
>> the backups I have of previous versions of the same file and, instead of the
>> "<81><CE>", there was "206"... in every case.
> The docstring for ‘desktop-create-buffer’ calls its first argument
> FILE-VERSION. It is reasonable to expect that it’s an integer such as
> 206.
>
> However, integers are also used as character codes, and 206 is the
> character code of Î (U+00CE Latin capital letter I with circumflex).
> In the UTF-8 encoding, this character is represented by two bytes 0x81
> 0xCE.

Agreed.  That's what I was suggesting above when showing the hex and
decimal equivalences.

> It is as if under some circumstances the code that saves the desktop
> file writes the version as a character code instead of a decimal
> integer.

Agreed again... well, I'd use different terminology, but I know what you
mean.  I've noticed too that emacs has had some problems regarding the
representation of characters in text.  I've been having a longterm issue
with the German characters: ä ö ü, their capitalized equivalents and ß.  
I can type them into an emacs buffer (and obviously into an email
composed in Tbird).  But if I copy text with any of these characters
from somewhere else and paste it into emacs, I get "garbage" characters
in their stead; not so if I paste the same text into any other
application on my system, e.g., Tbird, vi, bash shell, even
LibreOffice's Calc.  So there's something shakey going on with emacs
there.  I can't say this problem and the one original to this email
thread come out of the same code, but they do bear some resemblance.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: desktop-read usage and syntax ::error, strange character :: half-SOLVED!!!

Nick Dokos-3
ken <[hidden email]> writes:


> ...
> I've been having a longterm
> issue with the German characters: ä ö ü, their capitalized equivalents
> and ß.  I can type them into an emacs buffer (and obviously into an
> email composed in Tbird).  But if I copy text with any of these
> characters from somewhere else and paste it into emacs, I get
> "garbage" characters in their stead; not so if I paste the same text
> into any other application on my system, e.g., Tbird, vi, bash shell,
> even LibreOffice's Calc.  So there's something shakey going on with
> emacs there.  I can't say this problem and the one original to this
> email thread come out of the same code, but they do bear some
> resemblance.
>

You probably have to specify the correct encoding of the X selection: go to

   Options / Multilingual Environment / Set Coding Systems/ For X Selections/Clipboard

or "C-x RET x" for short. You'll probably have to guess what the encoding should be
based on whatever the previous, unsuccessful, paste did to your buffer :-)

Personally, I set everything to use UTF-8 and have very little trouble, but I cannot
control what some random website will do, so if I need to cut and paste from there
the above method might come in handy.

--
Nick


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: desktop-read usage and syntax ::error, strange character

Sharon Kimble-2
In reply to this post by ken-93
ken <[hidden email]> writes:

> On 07/19/2017 07:11 AM, Sharon Kimble wrote:
>>> Sharon, thanks for your reply. There's a lot there though which I'm not understanding.  For
>>> instance, what do you meanfur that you 'restore them from memory'?  And what is tabbar...? and what
>>> are tabs?
>> I remember what files I had open before the 'emacs.desktop' corruption
>> and I then use that memory to help me load them back into emacs. It just
>> uses brain power and brain memory to tell me what buffers I had open,
>> and which I therefore need to reload.
>
> :-D  That was my second choice for interpretations.  The first was that you had an app to search
> through RAM.  Back in the DOS days there was such a thing.  Haven't heard of such a creature for
> Linux (though it wouldn't be a huge job to code it).
>
>> Tabbar and tabbar-ruler [fn:1] help you by having each buffers title
>> shown in tabs at the top of the emacs buffer. These tabs are similar to
>> the tabs you can find in most internet browsers, think firefox,
>> chromium, Vivaldi, etc. You can move very easily between them by using
>> your mouse, or perhaps keyboard but I'm not sure of that. Anyway, every
>> buffer is a tab, and tabs are grouped together dependant on their major
>> mode. So all elisp buffers are grouped together, and ditto with
>> org-mode, etc. Both programs are available from ELPA, and if you're
>> still using your mouse then they're very worthwhile.
>
> Okay, thanks.  That sounds cool.  Yeah, I'm well aware of tabs in general, but had never seen or
> heard of them for emacs.  Sounds like that would be handy in situations... though many times I need
> to have two buffers visible at the same time, or also one and the same buffer open in two different
> frames, both visible at the same time. So do tabbar/tabbar-ruler allow that as well, say, by doing
> "C-x 5 b chosen-buf"...? or is it mandated that henceforth all buffers will be tabbed and only so
> (so long as tabbar/tabbar-ruler is invoked)?
Yes you can have two buffers open at the same time, if your monitor is
big enough to display them without the text being so miniscule that it
hurts your eyes! :) I regularly have two buffers open, either side by
side or one above the other when I'm writing an ebook in org-mode and I
want to add a reference to the bibliography or a reference in the
glossary.

--8<---------------cut here---------------start------------->8---
#+BEGIN_SRC emacs-lisp
(defun carve-up-soldier18-bib ()
  (interactive)
  (delete-other-windows)
  (split-window-right)
  (other-window 1)
 (find-file "~/research/soldier/soldier-1939-1945/soldier18.bib"))

(global-set-key (kbd "C-c C-0") 'carve-up-soldier18-bib)
#+end_src
[2017-06-13 Tue 16:09]

#+begin_src emacs-lisp
(defun carve-up-soldier18-glos ()
  (interactive)
  (delete-other-windows)
  (split-window-below)
  (other-window 1)
 (find-file "~/research/soldier/soldier-1939-1945/soldier18.glos"))
 
(global-set-key (kbd "C-c C-1") 'carve-up-soldier18-glos)
#+END_SRC
[2017-06-13 Tue 16:08]
--8<---------------cut here---------------end--------------->8---

That's the code for just one of my books to split the screen, and then
just use 'Remove other windows' from the "File" menu to revert back to
your main working buffer. Once you get the hang of it, you'll start
moving just using the keyboard and your mouse usage decreases.

And yes, you can have the same buffer opened in different views
(side-by-side or one above the other) and showing different places in
the same file. I find that in that situation its easiest to use org-mode
so you can then easily get to the section that you want to work on. I
also use 'multiple cursors' from ELPA to help in navigating round a big
document to the various sections that you might be using all at the same
time. Imenu also helps a lot too.

It is possible to 'turn off' tabbar by toggling the tabs, and I've done
it occasionally but I find them so useful that I don't generally bother.

Hope this helps?

Thanks
Sharon.
--
A taste of linux = http://www.sharons.org.uk
TGmeds = http://www.tgmeds.org.uk
DrugFacts = https://www.drugfacts.org.uk 
Debian 9.0, fluxbox 1.3.5-2, emacs 25.1.1, org-mode 9.0.9

signature.asc (847 bytes) Download Attachment
Loading...