~yantar92

Recent activity

Re: [org-mode-mirror] build failed 4 months ago

From Ihor Radchenko to ~bzg/org-build-failures

Bastien Guerry <bzg@gnu.org> writes:

>> Should it be cd org-mode ?
>
> Yes, I've fixed this an hour ago, along with other fixes, the next
> mirroring build should be okay.

Thanks!

Re: [org-mode-mirror] build failed 4 months ago

From Ihor Radchenko to ~bzg/org-build-failures

"builds.sr.ht" <builds@sr.ht> writes:

> org-mode-mirror #1079302: FAILED in 1m15s
>
> https://builds.sr.ht/~bzg/job/1079302
>
> ✗ mirror 

This looks like a problem with manifest:

Cloning into 'org-mode'...
+ cd org-mode.git
.tasks/mirror: line 12: cd: org-mode.git: No such file or directory

Re: compat.el and Emacs unstable master branch features 4 months ago

From Ihor Radchenko to ~pkal/compat-devel

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

>>> Yes, if the Emacs maintainers agree I think this could be done. Take
>>> compat.el, remove the part which requires compat-29, and copy it to
>>> lisp/ or lisp/emacs-lisp/. As you said, if Compat (the package) is
>>> installed it will be preferred over the core compat.el. The advantage of
>>> this move is that core package could require compat directly without
>>> passing a noerror argument to require. Furthermore `compat-call' and
>>> `compat-function' would be available and wouldn't have to be copied as
>>> is currently the case for example in erc-compat.el.
>> 
>> That sounds good!  How does this look like:
>
> Yes, this is what I meant. I forgot to mention one additional advantage

Re: compat.el and Emacs unstable master branch features (was: bug#63513: [PATCH] Make persist-defvar work with records and hash tables) 5 months 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) 5 months 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) 5 months 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) 5 months 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 11 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" 1 year, 5 days 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 1 year, 12 days 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.