zsh-workers
 help / color / mirror / code / Atom feed
From: Mikael Magnusson <mikachu@gmail.com>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: Michele Venturi <dardo82@gmail.com>,
	Peter Stephenson <p.w.stephenson@ntlworld.com>,
	zsh-workers@zsh.org
Subject: Re: How to fix run-help-* functions?
Date: Mon, 13 Mar 2023 19:19:33 +0100	[thread overview]
Message-ID: <CAHYJk3R4T82A_SYQfqhmd+h8EN6QwCmPmTjMUSZZ4x-LkEzcMw@mail.gmail.com> (raw)
In-Reply-To: <CAH+w=7Zf8S_eCgvYjTV3sp5h8ApXwy9SduMKViBe+hha0_OZHg@mail.gmail.com>

On 3/13/23, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Mon, Mar 13, 2023 at 4:14 AM Michele Venturi <dardo82@gmail.com> wrote:
>>
>> On Tue, Mar 7, 2023, 18:41 Bart Schaefer <schaefer@brasslantern.com>
>> wrote:
>>>
>>> If you don't do the "make install" part, you get an error about a
>>> "shift" count being wrong, which probably looks like a bug rather than
>>> a usage problem.
>>
>> I've tried this but it doesn't make any difference,
>
> When you "configure" or by passing an environment variable to "make"
> you can specify a custom location for the help files.
>
> Because run-help is a shell function, it doesn't have a "source file"
> and an "object file" so the source itself contains a replacement
> string @runhelpdir@ which is updated by the installfns.sh script
> during "make install".  Yes, we could have put a "run-help.in" file
> somewhere and processed that at a different build step to create
> run-help, but that complicates installing the rest of the functions.
>
> The help directory is populated by the Util/helpfiles script, which is
> run by "make install" in the Doc subdirectory (but I do not recommend
> attempting to run make in individual subdirectories rather than
> letting the top-level Makefile drive it.)
>
> However, all of that turns out to be necessary but secondary, because
> the real problem is that you're using run-help wrong.
[moved this part to after]
> Question for the audience is whether we want to consider this a bug
> and make it possible to use run-help as a standalone function.

It could/should at least output some diagnostic, because it is very
easy for an end-user (or very confused developer) to do this:
% git<invoke run-help>
[git manpage is shown]
# above prompt has now changed to this:
% run-help git
% git<now press page up and enter which changes this line to:>
% run-help git
git is /usr/bin/git
run-help:shift:106: shift count must be <= $#


> You're not intended to type out "run-help sudo" and hit enter, you're
> intended to type "sudo" and then invoke the run-help ZLE widget
> (normally ESC h or Alt+h), which then calls the run-help function with
> some preliminary setup having been done.

Looking at the code for processcmd it seems to literally only insert
the string "run-help git" on the command line, so what exactly is this
preliminary setup? I can't find it. The comment for the function is:
/* Run '$WIDGET $commandword' and then restore the command-line using
push-line. */
which is missing some key piece of information.

-- 
Mikael Magnusson


  reply	other threads:[~2023-03-13 18:19 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-07 14:30 Michele Venturi
2023-03-07 17:13 ` Philippe Troin
2023-03-13 11:09   ` Michele Venturi
2023-03-07 17:22 ` Bart Schaefer
2023-03-07 17:31   ` Peter Stephenson
2023-03-07 17:40     ` Bart Schaefer
2023-03-07 18:34       ` Michele Venturi
2023-03-08  0:03         ` Bart Schaefer
2023-03-13 11:14       ` Michele Venturi
2023-03-13 16:06         ` Bart Schaefer
2023-03-13 18:19           ` Mikael Magnusson [this message]
2023-03-13 20:31             ` Bart Schaefer
2023-03-13 20:41               ` Bart Schaefer
2023-03-20 14:37                 ` Michele Venturi
2023-03-21  1:05                   ` Bart Schaefer

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

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

  git send-email \
    --in-reply-to=CAHYJk3R4T82A_SYQfqhmd+h8EN6QwCmPmTjMUSZZ4x-LkEzcMw@mail.gmail.com \
    --to=mikachu@gmail.com \
    --cc=dardo82@gmail.com \
    --cc=p.w.stephenson@ntlworld.com \
    --cc=schaefer@brasslantern.com \
    --cc=zsh-workers@zsh.org \
    /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.vuxu.org/mirror/zsh/

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 NNTP newsgroup(s).