[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#39121: 27.0.60; occur: Add bindings for next-error-no-select
From: |
Eli Zaretskii |
Subject: |
bug#39121: 27.0.60; occur: Add bindings for next-error-no-select |
Date: |
Sun, 25 Jul 2021 22:23:26 +0300 |
> From: Mattias Engdegård <mattiase@acm.org>
> Date: Sun, 25 Jul 2021 20:54:47 +0200
> Cc: larsi@gnus.org, juri@linkov.net, 39121@debbugs.gnu.org,
> tino.calancha@gmail.com
>
> 25 juli 2021 kl. 18.27 skrev Eli Zaretskii <eliz@gnu.org>:
>
> > The NEWS file doesn't necessarily describe only stuff documented
> > somewhere, it also describes changes that aren't documented anywhere
> > but the source code.
>
> Yes, but then it's always something that affects the user in some way, isn't
> it?
"User" in this case includes Lisp programmers; there's the "Lisp
changes" section in NEWS for that reason.
> Mentioning changed internals doesn't seem to be standard practice, but I
> could be wrong about that.
Text properties are not internals, they are visible to any Lisp
program and to the user.
> Would you point out a few examples of where we described changed aspects of
> undocumented implementation details in NEWS? That would support your view and
> help me understand it better.
Sorry, no, I won't. I think this aspect of the change should be in
NEWS, and I'm asking you to document it there. I don't understand why
I'm required to go to such lengths to justify a simple request. If
you are still not convinced, I will do it myself, because this endless
dispute about a couple of sentences in NEWS is more than I can afford.
> The question is also whether it should be documented at all.
I think it should, and have said so.
> > Since you introduced the new format, you probably thought it to be
> > better than the existing one, right? Then telling others about that
> > would be a good service, IMO.
>
> The change was made exclusively for improving Occur itself, and the external
> packages that I have seen would generally draw little advantage from doing
> anything differently. Of course, I haven't seen them all, but having other
> people depending on implementation details of your software is a maintenance
> burden which either impedes progress.
Please leave the final judgment about that to me. I understand your
point and your doubts, but I still think we should document this
aspect of the change in NEWS. I hope this is enough to convince you.
TIA
- bug#39121: 27.0.60; occur: Add bindings for next-error-no-select, (continued)
- bug#39121: 27.0.60; occur: Add bindings for next-error-no-select, Mattias Engdegård, 2021/07/24
- bug#39121: 27.0.60; occur: Add bindings for next-error-no-select, Lars Ingebrigtsen, 2021/07/25
- bug#39121: 27.0.60; occur: Add bindings for next-error-no-select, Eli Zaretskii, 2021/07/25
- bug#39121: 27.0.60; occur: Add bindings for next-error-no-select, Mattias Engdegård, 2021/07/25
- bug#39121: 27.0.60; occur: Add bindings for next-error-no-select, Basil L. Contovounesios, 2021/07/25
- bug#39121: 27.0.60; occur: Add bindings for next-error-no-select, Mattias Engdegård, 2021/07/25
- bug#39121: 27.0.60; occur: Add bindings for next-error-no-select, Eli Zaretskii, 2021/07/25
- bug#39121: 27.0.60; occur: Add bindings for next-error-no-select, Mattias Engdegård, 2021/07/25
- bug#39121: 27.0.60; occur: Add bindings for next-error-no-select, Eli Zaretskii, 2021/07/25
- bug#39121: 27.0.60; occur: Add bindings for next-error-no-select, Mattias Engdegård, 2021/07/25
- bug#39121: 27.0.60; occur: Add bindings for next-error-no-select,
Eli Zaretskii <=
- bug#39121: 27.0.60; occur: Add bindings for next-error-no-select, Mattias Engdegård, 2021/07/25
- bug#39121: 27.0.60; occur: Add bindings for next-error-no-select, Eli Zaretskii, 2021/07/26
- bug#39121: 27.0.60; occur: Add bindings for next-error-no-select, Mattias Engdegård, 2021/07/25