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
%m format specifier incorrectly tries to interpret backslashes #9
Comments
telotortium
added a commit
to telotortium/log4e
that referenced
this issue
Aug 24, 2022
Fix aki2o#9. We provide a new custom variable `log4e-log-message-literal-backslash` for clients to disable this new behavior if desired. However, we expect that no client actually desired the old behavior, and warn if they expected it.
telotortium
added a commit
to telotortium/org-gcal.el
that referenced
this issue
Sep 11, 2022
telotortium
added a commit
to telotortium/org-gcal.el
that referenced
this issue
Nov 19, 2022
telotortium
added a commit
to telotortium/org-gcal.el
that referenced
this issue
Nov 19, 2022
telotortium
added a commit
to telotortium/org-gcal.el
that referenced
this issue
Nov 29, 2022
ssl19
added a commit
to ssl19/alert
that referenced
this issue
Apr 3, 2023
When we use log4e to log alert events, alert messages containing backslashes will raise errors. (alert "\\") will raise: log4e--logging: Invalid use of ‘\’ in replacement text Check aki2o/log4e#9 for more information. This commit is a workaround for log4e upstream, and should be removed after aki2o/log4e#9 is resolved.
telotortium
added a commit
to telotortium/org-gcal.el
that referenced
this issue
May 9, 2023
telotortium
added a commit
to telotortium/org-gcal.el
that referenced
this issue
Feb 13, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm trying to run the following code:
The string we're trying to log contains a literal backslash. This throws the following error:
This can be traced to the following code in
log4e--insert-log
:All of these (as well as any use case where
log4e
attempts to use a user-provided string as replacement text) should set the optional 5th argumentLITERAL
toreplace-regexp-in-string
to non-nil to avoid interpreting backslash escapes (such as\1
to match groups in the regexp). It would also be a good idea to set the 4th argumentFIXEDCASE
as well.I will work around it for now in my code by escaping the backslashes myself, but it would be good to fix this. When this is fixed, it would be good to bump the version number, so that clients can selectively escape based on the version number.
log4e commit 737d275 version 0.3.3
Emacs 28.1
The text was updated successfully, but these errors were encountered: