Prefixed manual describe-function and api overview

Prefixed manual describe-function and api overview

[Philippe Vaucher]

Hello,

Following up on our previous discussions, here is a working
implementation of the completion mechanism based on the manual:

https://github.com/Silex/prefixed-manual.el/blob/master/prefixed-manual.el

At the moment it uses https://melpa.org/#/dash and
https://melpa.org/#/s so make sure you have these dependencies. Then
to try it out, test with `M-x prefixed-manual-describe-function` and
`M-x prefixed-manual-overview`. The later still needs a lot of work
but it gives an idea.

Here are my questions/plans:
- If there is interest for some parts for the core, I'll rewrite this
in vanilla Emacs.
- I'm not sure I like "prefixed-manual", given this is more about
"manual-helpers". Feel free to suggest a better name.
- In `prefixed-manual-overview`, I'd like to display the full
signature of functions. For example display "(substring-no-properties
STRING &optional FROM TO)" instead of "substring-no-properties". If
you know a simple way I'm interested. I tried to use something like
`(get 'substring-no-properties 'function-documentation)` or play with
`documentation-property` but couldn't find easily and gave up.

Kind regards,
Philippe

Re: Prefixed manual describe-function and api overview

[Stefan Monnier]

> - I'm not sure I like "prefixed-manual", given this is more about
> "manual-helpers". Feel free to suggest a better name.

`fixed-manual` ? ;-)

> - In `prefixed-manual-overview`, I'd like to display the full
> signature of functions. For example display "(substring-no-properties
> STRING &optional FROM TO)" instead of "substring-no-properties". If
> you know a simple way I'm interested. I tried to use something like
> `(get 'substring-no-properties 'function-documentation)` or play with
> `documentation-property` but couldn't find easily and gave up.

I think you're looking for `help-function-arglist`, but of course that
only works for those functions already loaded into Emacs.


        Stefan

Re: Prefixed manual describe-function and api overview

[Philippe Vaucher]

> > - In `prefixed-manual-overview`, I'd like to display the full
> > signature of functions. For example display "(substring-no-properties
> > STRING &optional FROM TO)" instead of "substring-no-properties". If
> > you know a simple way I'm interested. I tried to use something like
> > `(get 'substring-no-properties 'function-documentation)` or play with
> > `documentation-property` but couldn't find easily and gave up.
>
> I think you're looking for `help-function-arglist`, but of course that
> only works for those functions already loaded into Emacs.

Thanks. I was beginning to think about having to use
`describe-function`, extract the signature from it, then close the
buffer :-)

I'll incorporate your idea soon and try to make it look pretty, maybe
by generating org-mode blocks instead.

Philippe

Re: Prefixed manual describe-function and api overview

[Philippe Vaucher]

>   > Following up on our previous discussions, here is a working
>   > implementation of the completion mechanism based on the manual:
>
> Could you tell me in 6 lines what it does?

Right sorry, I should have said it anyway. I added the mailing list
for others to have my description as well.

There are several function, but the one I mainly want to show you guys
is `prefixed-manual-describe-function`. It is like `describe-function`
(C-h f), but before you get to select a function you have to select a
"topic" first. The topics are the clickable links at
https://www.gnu.org/software/emacs/manual/html_node/elisp/index.html#Top.
Once you select a topic, then you get to select a function but your
choices are limited to the functions of said topic.

This simulates the experience you get when you have a consistently prefixed api.

If you want to get a quick overview, please eval the following code
and select "Strings and Characters" for the topic (the example is
hardcoded to propose string functions):

(let ((topic (completing-read "Topic: " '("Introduction" "Lisp Data
Types" "Numbers" "Strings and Characters" "Lists" "Sequences Arrays
Vectors" "Records" "Hash Tables" "Symbols" "Evaluation" "Control
Structures")))
      (function  (intern (completing-read "Function: " '("stringp"
"string-or-null-p" "char-or-string-p" "make-string" "string"
"substring" "substring-no-properties" "concat" "split-string"
"store-substring" "clear-string" "char-equal" "string" "string-equal"
"string-collate-equalp" "string" "string-lessp" "string-greaterp"
"string-collate-lessp" "string-version-lessp" "string-prefix-p"
"string-suffix-p" "compare-strings" "assoc-string" "number-to-string"
"string-to-number" "char-to-string" "string-to-char" "format"
"format-message" "downcase" "upcase" "capitalize" "upcase-initials"
"case-table-p" "set-standard-case-table" "standard-case-table"
"current-case-table" "set-case-table" "set-case-syntax-pair"
"set-case-syntax-delims" "set-case-syntax"
"describe-buffer-case-table")))))
  (describe-function function))

Kind regards,
Philippe

Re: Prefixed manual describe-function and api overview

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It is like `describe-function`
  > (C-h f), but before you get to select a function you have to select a
  > "topic" first. The topics are the clickable links at
  > https://www.gnu.org/software/emacs/manual/html_node/elisp/index.html#Top.
  > Once you select a topic, then you get to select a function but your
  > choices are limited to the functions of said topic.

It is worth a try.  Let's see whether users find that helps them
find the information they are looking for.

To find out whether users find it helpful, we might want to publish it
and ask users to try it.

Here's an idea: make describe-function accept topic names as well as function
names.  When the input is a topic name, it would follow up by doing what
you've implemented.  If the minibuffer prompt explains this feature,
users might discover it on their own.  And it won't require a new command.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Prefixed manual describe-function and api overview

[Philippe Vaucher]

>   > It is like `describe-function`
>   > (C-h f), but before you get to select a function you have to select a
>   > "topic" first. The topics are the clickable links at
>   > https://www.gnu.org/software/emacs/manual/html_node/elisp/index.html#Top.
>   > Once you select a topic, then you get to select a function but your
>   > choices are limited to the functions of said topic.
>
> It is worth a try.  Let's see whether users find that helps them
> find the information they are looking for.
>
> To find out whether users find it helpful, we might want to publish it
> and ask users to try it.

Well it is published, and I asked people to try it out? Or did you mean ELPA?

> Here's an idea: make describe-function accept topic names as well as function
> names.  When the input is a topic name, it would follow up by doing what
> you've implemented.  If the minibuffer prompt explains this feature,
> users might discover it on their own.  And it won't require a new command.

I see your point but that'd defeat the purpose of the package for me.
I'd type "string" and have to figure out which one is a function and
which one is a topic.

I want less ambiguity, what you suggest adds more.

Philippe

Re: Prefixed manual describe-function and api overview

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > It is worth a try.  Let's see whether users find that helps them
  > > find the information they are looking for.
  > >
  > > To find out whether users find it helpful, we might want to publish it
  > > and ask users to try it.

  > Well it is published,

You sent mail about it to emacs-devel.  That will inform Emacs
developers, but only a tiny fraction of the uers.  What I mean by 
"publish it" is to inform lots of users.

  > > Here's an idea: make describe-function accept topic names as well as function
  > > names.  When the input is a topic name, it would follow up by doing what
  > > you've implemented.  If the minibuffer prompt explains this feature,
  > > users might discover it on their own.  And it won't require a new command.

  > I see your point but that'd defeat the purpose of the package for me.
  > I'd type "string" and have to figure out which one is a function and
  > which one is a topic.

I can't follow you there.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Prefixed manual describe-function and api overview

[João Távora]

Hello Philippe,

[I take the liberty from answering to emacs-devel, since you
seem to be requesting that I weigh in on your work, which is
public]

> I'm surprised not to hear from you on this. Maybe you missed it?
>
> IIRC you were the one pushing for me to implement it, maybe I misremember.

You don't.  I have variable amounts of energy to invest in Emacs
development, and I didn't think my input would be crucial here.
Sorry about that, and thank you for your work.

I read your email, but was discouraged from trying your program
since you made it depend on s.el and dash.el which are libraries
I don't use and steer clear of. Certainly with 120 lines of code you
can write it without s.el and dash.el, especially now that you've
supposedly become accustomed with Emacs's API's.

But I read the code.

You approach is completely different from what I imagined: I was
thinking of creating new sections in the manual itself, or creating
a whole new manual, without having to actually write the contents
for it.  It could be called the "Elisp API manual", or some better name.
One could visit that API manual from inside and from outside Emacs,
just as one does now with the normal Manual.  A minimal amount of
Elisp code would allow some C-h <key> function to take me there.

In other words, as you know, a manual in Emacs is extracted from the
Texinfo source  (.texi files) into various output formats.  I was thinking
about code that performs this extraction into a new output (a new manual,
or a new section in the existing Elisp manual) including all those formats.
Without needing to touch the (.texi) files themselves.  Maybe this could
be done with a special Texinfo macro, maybe redefining its built-in
@defun macro, which is what Emacs uses to introduce a function
definition.  That was my idea.

Hope this helps,
João Távora

Re: Prefixed manual describe-function and api overview

[Philippe Vaucher]

> [I take the liberty from answering to emacs-devel, since you
> seem to be requesting that I weigh in on your work, which is
> public]
>
> > I'm surprised not to hear from you on this. Maybe you missed it?
> >
> > IIRC you were the one pushing for me to implement it, maybe I misremember.
>
> You don't.  I have variable amounts of energy to invest in Emacs
> development, and I didn't think my input would be crucial here.
> Sorry about that, and thank you for your work.

Thanks for your feedback :-)

> I read your email, but was discouraged from trying your program
> since you made it depend on s.el and dash.el which are libraries
> I don't use and steer clear of. Certainly with 120 lines of code you
> can write it without s.el and dash.el, especially now that you've
> supposedly become accustomed with Emacs's API's.

Yeah, I can rewrite it without dash/s.el. It was just the fastest way
for me to get something working. As I said if there is interest, I can
rewrite it without these dependencies. So far I'm not sure there is
interest beyond me and probably some people outside of emacs-devel.

> You approach is completely different from what I imagined: I was
> thinking of creating new sections in the manual itself, or creating
> a whole new manual, without having to actually write the contents
> for it.  It could be called the "Elisp API manual", or some better name.
> One could visit that API manual from inside and from outside Emacs,
> just as one does now with the normal Manual.  A minimal amount of
> Elisp code would allow some C-h <key> function to take me there.

Well there's two things: the "prefixed" `C-h f` and the "Elisp API
manual". I think the prefixed `C-h f`
(prefixed-manual-describe-function) is pretty much exactly what I want
as a user.

About the "Elisp API manual" (prefixed-manual-overview), this is
really just a rough draft and it needs much more work. This one I have
less interest in, but thanks for your description of what you'd like
it to be.

> In other words, as you know, a manual in Emacs is extracted from the
> Texinfo source  (.texi files) into various output formats.  I was thinking
> about code that performs this extraction into a new output (a new manual,
> or a new section in the existing Elisp manual) including all those formats.
> Without needing to touch the (.texi) files themselves.  Maybe this could
> be done with a special Texinfo macro, maybe redefining its built-in
> @defun macro, which is what Emacs uses to introduce a function
> definition.  That was my idea.

Well I don't know texi files yet, but I think it'd be fairly easy to
write some helper elisp that generates what you want based on my code,
or some variations of. I'm not sure I have time for that, this project
was more of me musing around with what emacs would look like with a
prefixed api, before resuming with the s.el concrete proposal. I don't
think I have enough time to implement your idea, but we'll see who
knows.

> Hope this helps,
> João Távora

It does ;-)
Philippe

Re: Prefixed manual describe-function and api overview

[João Távora]

Philippe Vaucher <philippe.vaucher@gmail.com> writes:

>> You approach is completely different from what I imagined: I was
>> thinking of creating new sections in the manual itself, or creating
>> a whole new manual, without having to actually write the contents
>> for it.  It could be called the "Elisp API manual", or some better name.
>> One could visit that API manual from inside and from outside Emacs,
>> just as one does now with the normal Manual.  A minimal amount of
>> Elisp code would allow some C-h <key> function to take me there.
>
> Well there's two things: the "prefixed" `C-h f` and the "Elisp API
> manual". I think the prefixed `C-h f`
> (prefixed-manual-describe-function) is pretty much exactly what I want
> as a user.

In my opinion, you're confusing/conflating two things, again:

- The ability to have, at a glance, nicely documented, and nicely
  discoverable, the list of the functions associated with a certain data
  type, or a certain topic.;

- To have that organization be provided by the existing or a new prefix
  convention;

It seems we both want the first objective.  But you seem want it with --
or by means of -- the specific side-effect of the second.  I don't that
side-effect at all, and this was already discussed extensively, I think.
Therefore my proposal, the "thing I was pushing for" is a way to have
the first objective without what I (and others) view as the drawbacks of
the second.

>> In other words, as you know, a manual in Emacs is extracted from the
>> Texinfo source  (.texi files) into various output formats.  I was thinking
>> about code that performs this extraction into a new output (a new manual,
>> or a new section in the existing Elisp manual) including all those formats.
>> Without needing to touch the (.texi) files themselves.  Maybe this could
>> be done with a special Texinfo macro, maybe redefining its built-in
>> @defun macro, which is what Emacs uses to introduce a function
>> definition.  That was my idea.
>
> Well I don't know texi files yet, but I think it'd be fairly easy to
> write some helper elisp that generates what you want based on my code,

That would be very strange IMO, to write this in Elisp.  It would be
even stranger to write it based on your code.  That said, everything can
be written in anything.

> or some variations of. I'm not sure I have time for that, this project
> was more of me musing around with what emacs would look like with a
> prefixed api

Indeed, that's nothing like I want.  I don't want a "prefixed API" at
all.  I want a nicely documented and discoverable API.  Personally,
except for some cases here and there, I think this already exists.  I
don't have much trouble navigating the existing manual and the
documentation mechanisms, I'm personally fine with the ones I know.

But that's not the case with you.  You were (or still are) very
confounded by them.

Therefore, I suggested a documentation source that would help you, and
presumably many more users like you, to learn Emacs's existing Elisp
API.  I suggested this because that would presumably solve your
difficulties and wouldn't interfere negatively on the organization and
working methods of users like me.

Furthermore, I also suggested you do that work yourself, because you're
the person that originally brought the problem to the table and argued
extensively about it.

João

Re: Prefixed manual describe-function and api overview

[Philippe Vaucher]

> >> You approach is completely different from what I imagined: I was
> >> thinking of creating new sections in the manual itself, or creating
> >> a whole new manual, without having to actually write the contents
> >> for it.  It could be called the "Elisp API manual", or some better name.
> >> One could visit that API manual from inside and from outside Emacs,
> >> just as one does now with the normal Manual.  A minimal amount of
> >> Elisp code would allow some C-h <key> function to take me there.
> >
> > Well there's two things: the "prefixed" `C-h f` and the "Elisp API
> > manual". I think the prefixed `C-h f`
> > (prefixed-manual-describe-function) is pretty much exactly what I want
> > as a user.
>
> In my opinion, you're confusing/conflating two things, again:
>
> - The ability to have, at a glance, nicely documented, and nicely
>   discoverable, the list of the functions associated with a certain data
>   type, or a certain topic.;
>
> - To have that organization be provided by the existing or a new prefix
>   convention;

I understand the distinction. I agree to a certain degree. I just find
it inefficient to implement these separately. The discoverability
should be in the language itself. The more it is in the language, the
less you need to document and maintain it, and all tooling benefit
from it.

I understand it's the point of view of a minority around here, that's ok.

> It seems we both want the first objective.  But you seem want it with --
> or by means of -- the specific side-effect of the second.  I don't that
> side-effect at all, and this was already discussed extensively, I think.
> Therefore my proposal, the "thing I was pushing for" is a way to have
> the first objective without what I (and others) view as the drawbacks of
> the second.

Yes. I think implementing the first objective without the second is
just more work and more things to maintain. and because I'm lazy I
prefer to do less work.

> >> In other words, as you know, a manual in Emacs is extracted from the
> >> Texinfo source  (.texi files) into various output formats.  I was thinking
> >> about code that performs this extraction into a new output (a new manual,
> >> or a new section in the existing Elisp manual) including all those formats.
> >> Without needing to touch the (.texi) files themselves.  Maybe this could
> >> be done with a special Texinfo macro, maybe redefining its built-in
> >> @defun macro, which is what Emacs uses to introduce a function
> >> definition.  That was my idea.
> >
> > Well I don't know texi files yet, but I think it'd be fairly easy to
> > write some helper elisp that generates what you want based on my code,
>
> That would be very strange IMO, to write this in Elisp.  It would be
> even stranger to write it based on your code.  That said, everything can
> be written in anything.

Okay, I guess that's because Texinfo is a language of its own. Yeah ok
then I understand your point, you want a texinfo macro that generates
the "elisp api overview" so you have the manual-first option. I prefer
the code-first option, where the code is the source of truth and
things are generated the maximum possible from it instead of having to
maintain two separate systems, which can easily become out of sync.

I understand that's not how Emacs works and it's not conceivable to
change this, but I hope you understand where I come from.

We'll see if I find time to write that texinfo macro.

Regards,
Philippe

Re: Prefixed manual describe-function and api overview

[João Távora]

Philippe Vaucher <philippe.vaucher@gmail.com> writes:

>> >> You approach is completely different from what I imagined: I was
>> >> thinking of creating new sections in the manual itself, or creating
>> >> a whole new manual, without having to actually write the contents
>> >> for it.  It could be called the "Elisp API manual", or some better name.
>> >> One could visit that API manual from inside and from outside Emacs,
>> >> just as one does now with the normal Manual.  A minimal amount of
>> >> Elisp code would allow some C-h <key> function to take me there.
>> >
>> > Well there's two things: the "prefixed" `C-h f` and the "Elisp API
>> > manual". I think the prefixed `C-h f`
>> > (prefixed-manual-describe-function) is pretty much exactly what I want
>> > as a user.
>>
>> In my opinion, you're confusing/conflating two things, again:
>>
>> - The ability to have, at a glance, nicely documented, and nicely
>>   discoverable, the list of the functions associated with a certain data
>>   type, or a certain topic.;
>>
>> - To have that organization be provided by the existing or a new prefix
>>   convention;
>
> I understand the distinction. I agree to a certain degree. I just find
> it inefficient to implement these separately.

They _are_ separate things.  When you call a plumber to your house, do
you expect him to install the deluxe cable package?

> The discoverability should be in the language itself. The more it is
> in the language, the less you need to document and maintain it, and
> all tooling benefit from it.

You're going in circles, again.  You don't recognize that Elisp, in its
current namespaceless form, doesn't lend itself to this as well as you
would wish.  And you don't recognize the drawbacks that your proposal
would bring upon others.

It is somewhat tiring to try to make progress, because you mis-state
your goals: you don't want to make this API more discoverable: you want
to change the API.

> I understand it's the point of view of a minority around here, that's ok.

It's not a question of majorities it's a question of the moral
imperative: we agree about problem A, we find solutions for problem A
Doing otherwise amounts to a trojan horse, and you face resistance.

>> It seems we both want the first objective.  But you seem want it with --
>> or by means of -- the specific side-effect of the second.  I don't that
>> side-effect at all, and this was already discussed extensively, I think.
>> Therefore my proposal, the "thing I was pushing for" is a way to have
>> the first objective without what I (and others) view as the drawbacks of
>> the second.
>
> Yes. I think implementing the first objective without the second is
> just more work and more things to maintain. and because I'm lazy I
> prefer to do less work.

You're mistaken.  The solution I gave doesn't require any maintenance
beyond what is already done, unless you're proposing we cease to
document functions in the manual altogether.

>> >> In other words, as you know, a manual in Emacs is extracted from the
>> >> Texinfo source  (.texi files) into various output formats.  I was thinking
>> >> about code that performs this extraction into a new output (a new manual,
>> >> or a new section in the existing Elisp manual) including all those formats.
>> >> Without needing to touch the (.texi) files themselves.  Maybe this could
>> >> be done with a special Texinfo macro, maybe redefining its built-in
>> >> @defun macro, which is what Emacs uses to introduce a function
>> >> definition.  That was my idea.
>> >
>> > Well I don't know texi files yet, but I think it'd be fairly easy to
>> > write some helper elisp that generates what you want based on my code,
>>
>> That would be very strange IMO, to write this in Elisp.  It would be
>> even stranger to write it based on your code.  That said, everything can
>> be written in anything.
>
> Okay, I guess that's because Texinfo is a language of its own. Yeah ok
> then I understand your point, you want a texinfo macro that generates
> the "elisp api overview" so you have the manual-first option. I prefer
> the code-first option, where the code is the source of truth and
> things are generated the maximum possible from it instead of having to
> maintain two separate systems, which can easily become out of sync.

You seem to be proposing to abolish or abandon the Elisp manual.  You
don't understand its function and utility, is my opinion.

> I understand that's not how Emacs works and it's not conceivable to
> change this, but I hope you understand where I come from.

I understand where you come from, but not where you want to go to.  And
neither do you, I suspect.  You should state your difficulties clearly
and think about them without the prejudice of some foreign predilection.

João

Re: Prefixed manual describe-function and api overview

[Philippe Vaucher]

> > The discoverability should be in the language itself. The more it is
> > in the language, the less you need to document and maintain it, and
> > all tooling benefit from it.
>
> You're going in circles, again.  You don't recognize that Elisp, in its
> current namespaceless form, doesn't lend itself to this as well as you
> would wish.  And you don't recognize the drawbacks that your proposal
> would bring upon others.

Well, yes I do see the drawbacks for you, that's why I'm not proposing
it anymore? If I didn't recognize them I'd still be pushing.
Maybe you want me to actually agree that these are also drawbacks for
me, that sorry I cannot do.

> It is somewhat tiring to try to make progress, because you mis-state
> your goals: you don't want to make this API more discoverable: you want
> to change the API.

At some point I wanted to add aliases (that's not really "changing the
API" in my book but I can understand it is in yours), and that was
seen as disruptive so I gave up.

Anyway, I wanted to make the API more discoverable for me and those
who think like me. I understand my definition of "discoverable" is
different from yours and because of that we run in circles. You think
improving discoverability by adding more manuals is sufficient, I
believe it's not.

It's ok, we don't need to agree. I don't know why we are talking about
this again.

> > I understand it's the point of view of a minority around here, that's ok.
>
> It's not a question of majorities it's a question of the moral
> imperative: we agree about problem A, we find solutions for problem A
> Doing otherwise amounts to a trojan horse, and you face resistance.

But we don't agree on problem A :-) That's the crux, for most of the
people here there's no problem to fix.

> >> It seems we both want the first objective.  But you seem want it with --
> >> or by means of -- the specific side-effect of the second.  I don't that
> >> side-effect at all, and this was already discussed extensively, I think.
> >> Therefore my proposal, the "thing I was pushing for" is a way to have
> >> the first objective without what I (and others) view as the drawbacks of
> >> the second.
> >
> > Yes. I think implementing the first objective without the second is
> > just more work and more things to maintain. and because I'm lazy I
> > prefer to do less work.
>
> You're mistaken.  The solution I gave doesn't require any maintenance
> beyond what is already done, unless you're proposing we cease to
> document functions in the manual altogether.

Hum, you are correct.

What I meant is that because I'll implement the "better C-h f" anyway,
implementing the manual is "more work". Because I'm lazy I'd prefer to
implement only the first and rip the benefits of the second for free.

> > Okay, I guess that's because Texinfo is a language of its own. Yeah ok
> > then I understand your point, you want a texinfo macro that generates
> > the "elisp api overview" so you have the manual-first option. I prefer
> > the code-first option, where the code is the source of truth and
> > things are generated the maximum possible from it instead of having to
> > maintain two separate systems, which can easily become out of sync.
>
> You seem to be proposing to abolish or abandon the Elisp manual.  You
> don't understand its function and utility, is my opinion.

No, I was hinting at having more parts of the manual be generated from
the code. But that's such a wide topic that I don't even want to
start.

> > I understand that's not how Emacs works and it's not conceivable to
> > change this, but I hope you understand where I come from.
>
> I understand where you come from, but not where you want to go to.  And
> neither do you, I suspect.  You should state your difficulties clearly
> and think about them without the prejudice of some foreign predilection.

I think what happened is: I explained clearly where I wanted to go, I
was told "no" and thus moved on to other things. I don't understand
what you are talking about with me not knowing where I want to go.

I don't think discussing this topic will bring anything new, I came in
this thread asking for feedback on a new library I work on, to get
ideas and test the water about what might get considered for inclusion
in Emacs. From what I understand a .texi "elisp api overview" might be
considered for inclusion in the manual, the rest not so much.

I thank you for your feedback, but re-discussing previous discussions
seems pointless to me.

Regards,
Philippe

Re: Prefixed manual describe-function and api overview

[Dmitry Gutov]

On 13.06.2020 18:46, Philippe Vaucher wrote:
>>> I understand it's the point of view of a minority around here, that's ok.
>> It's not a question of majorities it's a question of the moral
>> imperative: we agree about problem A, we find solutions for problem A
>> Doing otherwise amounts to a trojan horse, and you face resistance.
> But we don't agree on problem A:-)  That's the crux, for most of the
> people here there's no problem to fix.

I think that really depends on how one would count the voices here.