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

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

[ken]

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?

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

[Sharon Kimble]

[-- Attachment #1: Type: text/plain, Size: 1349 bytes --]

ken <gebser@mousecar.com> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

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

[ken]

On 07/18/2017 01:07 PM, Sharon Kimble wrote:
> ken <gebser@mousecar.com> 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.

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

[John Mastro]

ken <gebser@mousecar.com> 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

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

[ken]

On 07/18/2017 03:59 PM, John Mastro wrote:
> ken <gebser@mousecar.com> 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.

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

[Yuri Khan]

On Wed, Jul 19, 2017 at 4:10 AM, ken <gebser@mousecar.com> 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.

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

[Sharon Kimble]

[-- Attachment #1: Type: text/plain, Size: 2893 bytes --]

ken <gebser@mousecar.com> writes:

> On 07/18/2017 01:07 PM, Sharon Kimble wrote:
>> ken <gebser@mousecar.com> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

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

[ken]

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)?

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

[ken]

On 07/19/2017 02:46 AM, Yuri Khan wrote:
> On Wed, Jul 19, 2017 at 4:10 AM, ken <gebser@mousecar.com> 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.

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

[Nick Dokos]

ken <gebser@mousecar.com> 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

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

[Sharon Kimble]

[-- Attachment #1: Type: text/plain, Size: 4281 bytes --]

ken <gebser@mousecar.com> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]