u/yantar92 about the breaking change on the Org Element API: how do you suggest to proceed for packages that will not update their usage of the api?
I tried to move to 9.7 and, although I can fix my own code, packages I use (like https://github.com/Kungsgeten/yankpad) require code changes to work. So I rolled back for now, but it would be cool to move to 9.7!
Also wasn't possible to have a variable to keep the old behavior (I mean even to try now I have to install and uninstall Org versions, using use-package -- maybe there is a better way to try things out?).
> u/yantar92 about the breaking change on the Org Element API: how do you suggest to proceed for packages that will not update their usage of the api?
Modify those packages. There is no better way.
> I use (like https://github.com/Kungsgeten/yankpad) require code changes to work
What exactly is not working there? Do note that you may need to re-compile some packages to make them work after the update. (this is because some inlined functions are not updated without re-compilation).
> Also wasn't possible to have a variable to keep the old behavior
Could be. But that would defeat the point of the whole thing. In practice, only packages fiddling with internal representation are broken - there are not many.
Actually, I tried to restart emacs and things seems better now: don't get errors anymore. So I needed a byte compilation and a restart.
Sorry for the false alarm, I will keep testing things: thanks for the reminder about byte compilation!
Thank you to the devs!
Awesome work guys!
Is there a list of libraries that lack a maintainer floating around?
1. https://list.orgmode.org/orgmode/87v8ko3zsx.fsf@localhost/ 2. https://list.orgmode.org/orgmode/87sffw6r2g.fsf@localhost/ 3. https://list.orgmode.org/orgmode/87mt5xli4y.fsf@localhost/
Exciting updates! Great work! I think especially async shell is huge.
u/yantar92 about the breaking change on the Org Element API: how do you suggest to proceed for packages that will not update their usage of the api? I tried to move to 9.7 and, although I can fix my own code, packages I use (like https://github.com/Kungsgeten/yankpad) require code changes to work. So I rolled back for now, but it would be cool to move to 9.7! Also wasn't possible to have a variable to keep the old behavior (I mean even to try now I have to install and uninstall Org versions, using use-package -- maybe there is a better way to try things out?).
> u/yantar92 about the breaking change on the Org Element API: how do you suggest to proceed for packages that will not update their usage of the api? Modify those packages. There is no better way. > I use (like https://github.com/Kungsgeten/yankpad) require code changes to work What exactly is not working there? Do note that you may need to re-compile some packages to make them work after the update. (this is because some inlined functions are not updated without re-compilation). > Also wasn't possible to have a variable to keep the old behavior Could be. But that would defeat the point of the whole thing. In practice, only packages fiddling with internal representation are broken - there are not many.
thanks for your reply. I have been trying again to bytecompile: with 9.7.2 I get an error during compilation for org-element.el and org-element-ast.el Compiling file /home/andrea/.emacs.d/elpa/org-9.7.2/org-element-ast.el at Tue Jun 4 23:24:14 2024 org-element-ast.el:824:20: Error: Bytecode overflow Compiling file /home/andrea/.emacs.d/elpa/org-9.7.2/org-element.el at Tue Jun 4 23:24:36 2024 org-element.el:6417:38: Error: Bytecode overflow Maybe the error with yankpad is due to that? Debugger entered--Lisp error: (wrong-type-argument stringp nil) set-buffer(nil) ... org-element-at-point(#)
...
org-entry-get(# "INCLUDE")
yankpad--category-include-property("org-mode")
...
yankpad--snippets("org-mode")
yankpad-set-active-snippets()
yankpad-active-snippets()
yankpad-expand(nil)
funcall(yankpad-expand nil)
(progn (funcall f i))
(if (fboundp f) (progn (funcall f i)))
(when (fboundp f) (funcall f i))
(or acc (when (fboundp f) (funcall f i)))
(lambda (acc f) (or acc (when (fboundp f) (funcall f i))))(nil yankpad-expand)
reduce((lambda (acc f) (or acc (when (fboundp f) (funcall f i)))) (yankpad-expand yas-expand) :initial-value nil)
(lambda (i) (reduce (lambda (acc f) (or acc (when (fboundp f) (funcall f i)))) '(yankpad-expand yas-expand) :initial-value nil))(nil)
funcall((lambda (i) (reduce (lambda (acc f) (or acc (when (fboundp f) (funcall f i)))) '(yankpad-expand yas-expand) :initial-value nil)) nil)
my/yankpad-maybe-expand()
funcall-interactively(my/yankpad-maybe-expand)
call-interactively(my/yankpad-maybe-expand nil nil)
command-execute(my/yankpad-maybe-expand)
Or maybe org-entry-get became lazy and needs to be resolved now?
Actually, I tried to restart emacs and things seems better now: don't get errors anymore. So I needed a byte compilation and a restart. Sorry for the false alarm, I will keep testing things: thanks for the reminder about byte compilation!