~yantar92

Recent activity

Re: compat.el and Emacs unstable master branch features (was: bug#63513: [PATCH] Make persist-defvar work with records and hash tables) 12 days ago

From Ihor Radchenko to ~pkal/compat-devel

Daniel Mendler <mail@daniel-mendler.de> writes:

> ... Providing a public API won't work
> since Compat is not included in Emacs itself. A design criterion of
> Compat is also to keep the public API surface as small as possible.

Maybe it is the time to consider including the compat.el API into Emacs?
We are getting a number of :core packages published on ELPA and
naturally having to solve various compatibility problems.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.

compat.el and Emacs unstable master branch features (was: bug#63513: [PATCH] Make persist-defvar work with records and hash tables) 14 days ago

From Ihor Radchenko to ~pkal/compat-devel

Daniel Mendler <mail@daniel-mendler.de> writes:

> On 9/9/23 13:35, Ihor Radchenko wrote:
>>> So using Compat here has to wait until compat-30.x is released.
>> 
>> And do I understand correctly that compat-30 will only be released after
>> Emacs 30 is released? If so, it is awkward for :core packages.
>
> compat-30 can be released as soon as Emacs 30 has been reasonably
> stabilized, e.g., when the emacs-30 branch has been frozen, or a bit
> before that. We cannot release much earlier since APIs may still change
> and it is probably undesired to release unfinished APIs to the public
> too early. For reference, I've created the compat-29.1.1 release around
> the day that Eli announced the emacs-29 branch freeze.

Re: [FR] Indicate filter syntax in search field (was: Choice of bug tracker) 21 days ago

From Ihor Radchenko to ~bzg/woof

Dmitry Gutov <dmitry@gutov.dev> writes:

> Oh, thanks. And I figured you moved off emacs-devel by accident, but I 
> guess we're having this conversation on sourcehut?

Sorry, I forgot to put a notice that I converted this into Woof! feature
request (https://woof.bzg.fr/source/woof/requests?sorting-by=date) and
dropped emacs-devel as this branch of the discussion does not seem even
remotely relevant to the already too off-topic discussion there.

>> A button or maybe background text like inhttps://lists.sr.ht/~bzg/woof
>> would indeed be helpful.
>
> Very much.

[FR] Indicate filter syntax in search field (was: Choice of bug tracker) 22 days ago

From Ihor Radchenko to ~bzg/woof

Dmitry Gutov <dmitry@gutov.dev> writes:

>>> The web page design looks a little better than mumi (which is to be
>>> expected of the Org crowd), but it seems leaner on the functionality
>>> (e.g. search).
>> May you elaborate about the missing search functionality?
>> CCing Bastien, the author of Woof!
>
> Click the "Hint" button below the search bar here: 
> https://issues.guix.gnu.org/
>
> It describes a certain search syntax. Woof could use a similar help 
> button, at least. And if it had, we could compare the capabilities.

Re: RFC: Organizations 6 months ago

From Ihor Radchenko to ~sircmpwn/sr.ht-discuss

"Adnan Maolood" <adnan@maolood.com> writes:

> In the end it might be better to use the same prefix "~" for both users
> and organizations. We would lose the ability to distinguish between
> users and organizations at a glance, but it spares us the burden of
> finding another suitable prefix.

What about using "~~" double prefix?

-- 
Ihor Radchenko // yantar92

[FR] Marking bugs as "easy" 7 months ago

From Ihor Radchenko to ~bzg/woof

It would be useful to have an ability for potential contributors to
search for entry-level bugs. That way, people who are interested to
contribute, but are not yet familiar with code base, may easily find how
to help.

I suggest allowing tagging bug reports as "easy" and/or "no code
needed". Then, a dedicated tab in woof overview page could show only the
easy bugs.

WDYT?

-- 
Ihor Radchenko // yantar92,

Re: [FR] On supporting functions that contained bugs in previous Emacs versions 7 months ago

From Ihor Radchenko to ~pkal/compat-devel

Daniel Mendler <mail@daniel-mendler.de> writes:

> Hopefully the situation will improve in the future, where we will get a
> minimal version of compat.el within Emacs core itself. There is the
> difficulty that this core Compat would then have to require
> `compat-<VERSION>' where VERSION is from the future. I could require
> `compat-future' with noerror, which is only provided by the Compat
> package itself. Another alternative would be to simply add compat-call
> and compat-function to subr.el. But before starting any such
> discussions, Compat must be adopted by core packages, such that there is
> a point in even discussing this.

As you have seen from the poll, Org is going for it. So, you can already
claim that core packages will need compat.

Re: [FR] On supporting functions that contained bugs in previous Emacs versions 7 months ago

From Ihor Radchenko to ~pkal/compat-devel

Daniel Mendler <mail@daniel-mendler.de> writes:

>> Emacs does have tests in general. May you elaborate?
>
> It does not have a test for this particular `combine-change-calls'
> macro. If a function has a test in Emacs, of course we copy the test
> over to compat-tests.el. In this case we would have to come up with our
> own tests, in particular if we don't only provide a stub, which wouldn't
> require much testing.

https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=b2fda50178b8151c3fe707d1a1b6b11f0c1eca12

> Okay, my suggestion would then be to implement your own
> `org-compat-call' macro which can do such an extended lookup, if it

Re: [FR] On supporting functions that contained bugs in previous Emacs versions 7 months ago

From Ihor Radchenko to ~pkal/compat-devel

Daniel Mendler <mail@daniel-mendler.de> writes:

> However I've recently looked into `combine-change-calls' (when we first
> talked about Org and Compat), and I am not overly optimistic that this
> macro can be backported easily and robustly given its complexity and
> dependence on undo internals. Unfortunately Emacs lacks tests, so we
> cannot just copy the macro and tests over.

Emacs does have tests in general. May you elaborate?

> ...  Maybe using a stub with
> degraded functionality would be the way to go in this case?

For Org, a stub will do.

[FR] On supporting functions that contained bugs in previous Emacs versions 7 months ago

From Ihor Radchenko to ~pkal/compat-devel

Hi,

In Org mode, we have recently encountered a bug in
`combine-change-calls' macro. See
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=60467

If we want to use `combine-change-calls' in the earlier versions of
Emacs, it may or may not be a good idea to use the buggy old version.

The usual solution to this problem we use in Org is defining a custom
`org-combine-change-calls' that will either provide a fixed version of
the macro for older Emacs or simply implement a stub macro that will not
trigger the bug in old Emacs at the expense of degraded functionality.