-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
# in .emacs_workgroup causes parsing error #113
Comments
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,
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
|
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) |
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.
The text was updated successfully, but these errors were encountered: