unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Arthur Miller <arthur.miller@live.com>
To: Eduardo Ochs <eduardoochs@gmail.com>
Cc: "Emacs developers" <emacs-devel@gnu.org>,
	me@wilfred.me.uk, "Stefan Kangas" <stefan@marxist.se>,
	"Daniel Martín" <mardani29@yahoo.es>
Subject: Re: Helpful in Emacs?
Date: Thu, 09 Sep 2021 21:51:08 +0200	[thread overview]
Message-ID: <AM9PR09MB4977ABD398B07EDCBF4F60C096D59@AM9PR09MB4977.eurprd09.prod.outlook.com> (raw)
In-Reply-To: <CADs++6jqNC15ce8Nrf7iEXeSsyAXAs-3Nh1h8-6ETjjJ83JWbg@mail.gmail.com> (Eduardo Ochs's message of "Thu, 9 Sep 2021 16:21:33 -0300")

Eduardo Ochs <eduardoochs@gmail.com> writes:

> On Thu, 9 Sept 2021 at 12:22, Daniel Martín <mardani29@yahoo.es> wrote:
>>
>> Arthur Miller <arthur.miller@live.com> writes:
>>
>> > A week or two ago I was actually looking at Emacs help code. I wanted to bring
>> > in the source code as well as references into help lookup, but honestly, I would
>> > rather prefer to just include helpful instead of re-implementing everything. If
>> > the authors have signed the paperwork, I see no reason why not just include
>> > it. Also original help lookup could be left as low-resource, faster solution for
>> > people who prefer to spend less resources on help lookup, while helpful could be
>> > enabled by a custom variable, something like show extended help or as
>> > a minor mode.
>>
>> Instead of integrating the library as a whole, I'd prefer we extract
>> those features from Helpful that people think are useful and not already
>> available in Emacs.  I don't think that having two separate help systems
>> in core is a good idea, there'll be too much duplication and maintenance
>> burden.
>>
>> Showing references to a symbol is an interesting feature (for example,
>> to learn how to use an ELisp API by looking at examples).  I see that
>> Helpful provides this feature via the separate package elisp-refs
>> (https://github.com/Wilfred/elisp-refs).  The closest package I know
>> that actually understands ELisp is el-search from ELPA, but elisp-refs
>> is a more specific package for the concrete use case of searching for
>> references.
>>
>> If we can get copyright papers, perhaps we could start by integrating
>> the functionality of elisp-refs as an xref backend.  Then the help
>> system could use the new backend to provide a "References" link button.
>
>
> Another vote for "extracting features"/"refactoring helpful" here...
>
> I tried to add support for helpful to eev about a year ago and I got
> lost and stuck - I only had a few hours to play with it, and I was not
> super focused, but was quite frustrated at the end. I was hoping that
> helpful would be structured as a library plus a front-end, and it was
> not.

Of course, it is not a library, it is an application :). That is why I say it is
probably as much work to extract stuff out of it as to rebuild it. Even faster
is just to include it as is and offer a defcustom to switch between old built-in
help and helpful. And once again, if you don't get helpful authors permission,
you can not just "extract", you will have to rebuild it from scratch. It might
not be so difficult to do it, but I would prefer to do some more fun stuff than
to implement funcitonality that already exists if we can just include it. Just
my 2 cents as they say.





  reply	other threads:[~2021-09-09 19:51 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-09 10:57 Helpful in Emacs? Arthur Miller
2021-09-09 11:34 ` Stefan Kangas
2021-09-09 12:35   ` Arthur Miller
2021-09-09 15:21     ` Daniel Martín
2021-09-09 15:48       ` Arthur Miller
2021-09-10  6:20         ` Stefan Kangas
2021-09-10  7:11           ` Arthur Miller
2021-09-10  7:19             ` Stefan Kangas
2021-09-10  7:58               ` Arthur Miller
2021-09-10  8:14                 ` Jean-Christophe Helary
2021-09-10 12:32               ` Stefan Monnier
2021-09-10  7:26             ` Eli Zaretskii
2021-09-10  8:00               ` Arthur Miller
2021-09-10 11:14                 ` Eli Zaretskii
2021-09-10 11:41                   ` Arthur Miller
2021-09-09 19:21       ` Eduardo Ochs
2021-09-09 19:51         ` Arthur Miller [this message]
2021-09-09 20:23       ` Arthur Miller
2021-09-09 22:55         ` Dmitry Gutov
2021-09-10  0:52           ` Arthur Miller
2021-09-10  6:16           ` Eli Zaretskii
2021-09-10  6:06         ` Eli Zaretskii
2021-09-10  6:21           ` Arthur Miller
2021-09-10  6:30       ` Juri Linkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AM9PR09MB4977ABD398B07EDCBF4F60C096D59@AM9PR09MB4977.eurprd09.prod.outlook.com \
    --to=arthur.miller@live.com \
    --cc=eduardoochs@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=mardani29@yahoo.es \
    --cc=me@wilfred.me.uk \
    --cc=stefan@marxist.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).