Omar Antolín Camarena
Omar Antolín Camarena
> The issue, as I understand it, is that updating a package which depends on compat does not automatically update compat to meet the dependent's declared compat version. Is this...
> Should we just update to 2.0 and have the user report bugs to the other packages? I believe this is the only reasonable strategy. As far as I know,...
OK, how about this wording? > dependency conflict: "A" requires compat 2.0, "B", "C", "D", "E" claim to work with compat >=1.0, but do you believe them? 😛
I'm only half-joking. I'd personally like such a tongue-in-cheek error message.
> I think it'd be better to consider a major version change a boundary. This is also very sensible.
As I mentioned above, there is *no way at all* to say you require version exactly 28.x.y, only a way to say you require *at least* 28.x.y, therefore package.el just...
For @vizs's problem with recursive minibuffers I think it should work to use `setq-local` in the minibuffer on `completion-styles` rather than binding it with `let`.
Perfect timing, @unhammer! I added support for extended menu-items *yesterday*! Those have a `:filter` property which you can use (among other things) to conditionally enable them only in certain situations....
True, @minad. Maybe embark-org's link target finder should find links in all buffers and use org-global-open-at-point instead of the non-global one.
I am interested in working on Embark support. For actions on the org-ql-find completion candidates I think the just-merged org-marker text properties are enough. With that I can have Embark...