# in .emacs_workgroup causes parsing error

This is a re-opening of a bug from back in 2014. I saved an org-agenda file which resulted in this string in the workgroup file:

#<buffer etc.

This gave a syntax read error whenever trying to create or open a new workgroup. It turns out the '#' needs to be escaped and then all is well.

This hackish rewrite of wg-write-sexp-to-file appears to fix the issue. It could surely be done better but it works for me.

(defun wg-write-sexp-to-file (sexp file)
"Write a printable (and human-readable) representation of SEXP to FILE."
(with-temp-buffer
(wg-insert-and-indent sexp)
;;; rjn
(goto-char (point-min))
(while (search-forward " #<" nil t)
(replace-match " \#<" nil t))
;;; rjn
(write-file file)))

The space in " #<" is necessary to avoid re-doing previous edits on future invocations.

I hope this will be of some use.

thanks , could you send me a pull request?

I can go and send pull request but not sure what to do after that? Sorry I am not so familiar with how GitHub works. Bob Newell

…

On Sat, Mar 5, 2022 at 6:44 PM Chen Bin ***@***.***> wrote: thanks , could you send me a pull request? — Reply to this email directly, view it on GitHub <#113 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJELKTW5MPR562QNFQSEQTU6QZZPANCNFSM5P4Q4I7A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>

-- Bob Newell Honolulu, Hawai`i Via Linux/Emacs/Gnus/BBDB.

I might need a bit more understanding about below code,

(while (search-forward " #<" nil t)
  (replace-match " \#<" nil t))

Why this code work?

A minimum case to reproduce the problem is also very helpful.

Chen Bin ***@***.***> writes:

I need a bit more understanding about below code, (while (search-forward " #<" nil t) (replace-match " \#<" nil t)) Why this code works?

The problem I ran into was this. Let's say I have an Org Agenda buffer showing and I do wg-create-workgroup (and I don't yet have an .emacs_workgroup file). The .emacs_workgroup is created but it contains a string that looks partially like #<buffer followed by other stuff. This happens with buffers that are not visiting a file. Now, later when I try to wg-open-workgroup or wg-create-workgroup or anything that tries o read .emacs_workgroup then I will get a syntax read error because it doesn't like the '#' character in .emacs_workgroup. So I found by experimenting that if I escape the "#" by making it into "\#" then the file will be read correctly. So the code I added searches for #< and replaces it with \#<. It has to search for " #<" to find instances of " #<buffer" because there can be # present elsewhere which don't need to have escape like many "#s" occurrences. Of course search and replace is a very crude solution. Really the right way would have been to write out the \# in the first place rather than fixing it later on. But I didn't figure out how to do it the right way :( Thank you for your time and attention and I hope this explains a little better.

…

-- Bob Newell Honolulu, Hawai`i - Via GNU/Linux/Emacs/Gnus/BBDB

It's because there is no wg-deserialize-org-agenda-mode-buffer,

Ah, thank you, I see, and this is symptomatic of a bigger problem with buffers not visiting a file. However, a user (like me!) who may create a workgroup with Org Agenda or similar will then have the .emacs_workgroups file made unreadable because of the bare "#" character in front of "<buffer Org Agenda>". This seems like harsh punishment to lose all the saved workspaces!

342fc30 store buffer name instead of buffer object (Chen Bin)

Navigation Menu

Repository navigation

# in .emacs_workgroup causes parsing error #113

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

# in .emacs_workgroup causes parsing error #113

Description

Activity

redguardtoo commented on Mar 6, 2022

chipschap commented on Mar 6, 2022

redguardtoo commented on Mar 6, 2022

chipschap commented on Mar 6, 2022

redguardtoo commented on Mar 7, 2022

chipschap commented on Mar 7, 2022

redguardtoo commented on Mar 8, 2022

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions