Re: helpex.el 0.2 --- useful extensions for the C-h prefix

Re: helpex.el 0.2 --- useful extensions for the C-h prefix

[Stefan Monnier]

> (defun helpex-find-library (library)

Emacs-CVS has `find-library' which does the same (with completion and all).

> (defun helpex-locate-library (library)
>   "Show the precise file name of Emacs library LIBRARY.
> This command uses `locate-library', so see there for more
> information.  The only difference is that it uses completion when
> called interactively."

In Emacs-CVS, locate-library does completion as well.

I think (fboundp 'locate-file-completion) is a good way to tell whether to
use your own code or the built-in one (I think the built-in's completion is
slightly better because it is more complete (e.g. works when the user has
entered /foo/bar/baz<TAB>) and it is "on-the-fly" (i.e. it only searches the
file-system when you press TAB rather than when you call locate-library)).


        Stefan

Re: helpex.el 0.2 --- useful extensions for the C-h prefix

[Michael Schierl]

Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>> (defun helpex-find-library (library)
>
>Emacs-CVS has `find-library' which does the same (with completion and all).

Nice. I don't have Emacs CVS ;)

Does that break helpex in any way on Emacs-CVS or do you just don't
like having redundant code loaded?

>> (defun helpex-locate-library (library)
>>   "Show the precise file name of Emacs library LIBRARY.
>> This command uses `locate-library', so see there for more
>> information.  The only difference is that it uses completion when
>> called interactively."
>
>In Emacs-CVS, locate-library does completion as well.

Nicer.

Is there a good solution for the Info-goto-node "problem" as well?
(And, if not, does Info-goto-node work properly w/
partial-completion-mode now? ATM I have quite a dirty hack in my
.emacs for that problem)

IOW: If you have an info file called "foo" with a node "Bar Baz" (e.g.
"(elisp)Regular Expressions"), can you type 

C-h i g (foo)Bar SPC Baz RET 

while p-c-m is enabled, *without* making Emacs barf about no
completion when hitting SPC?

>I think (fboundp 'locate-file-completion) is a good way to tell whether to
>use your own code or the built-in one (I think the built-in's completion is
>slightly better because it is more complete (e.g. works when the user has
>entered /foo/bar/baz<TAB>) and it is "on-the-fly" (i.e. it only searches the
>file-system when you press TAB rather than when you call locate-library)).

Since you don't have to bind my functions to any key, it should not
make any problems to the "minority" using CVS versions, does it? Or
are the key bindings used by helpex (C-h L, C-h o) used by CVS emacs
by default as well?

BTW: If someone uses CVS, he should be able to rebind the keys to the
"origininal" functions himself...

Michael
-- 
"New" PGP Key! User ID: Michael Schierl <schierlm@gmx.de>
Key ID: 0x58B48CDD    Size: 2048    Created: 26.03.2002
Fingerprint:  68CE B807 E315 D14B  7461 5539 C90F 7CC8
http://home.arcor.de/mschierlm/mschierlm.asc

Re: helpex.el 0.2 --- useful extensions for the C-h prefix

[Stefan Monnier]

>>> (defun helpex-find-library (library)
>> Emacs-CVS has `find-library' which does the same (with completion and all).
> Nice. I don't have Emacs CVS ;)

I assumed that much.  Just letting you know.

> Does that break helpex in any way on Emacs-CVS or do you just don't
> like having redundant code loaded?

It doesn't break anything, but you might want to only use your definition if
the underlying Emacs does not offer its own (unless yours has some extra
feature, of course).

> Is there a good solution for the Info-goto-node "problem" as well?

IIRC, the goto-node code in CVS does completion within the parenthesese,
but it does not do completion of the node name afterwards (this requires
looking inside the Info file and I didn't bother writing it up).

> IOW: If you have an info file called "foo" with a node "Bar Baz" (e.g.
> "(elisp)Regular Expressions"), can you type

> C-h i g (foo)Bar SPC Baz RET

> while p-c-m is enabled, *without* making Emacs barf about no
> completion when hitting SPC?

I haven't used p-c-m in a while and I use C-a SPC to insert a space, so
I wouldn't know.  If it works without p-c-m, then it's a bug in p-c-m,
otherwise it's a misfeature.

>> I think (fboundp 'locate-file-completion) is a good way to tell whether to
>> use your own code or the built-in one (I think the built-in's completion is
>> slightly better because it is more complete (e.g. works when the user has
>> entered /foo/bar/baz<TAB>) and it is "on-the-fly" (i.e. it only searches the
>> file-system when you press TAB rather than when you call locate-library)).

> Since you don't have to bind my functions to any key, it should not
> make any problems to the "minority" using CVS versions, does it? Or
> are the key bindings used by helpex (C-h L, C-h o) used by CVS emacs
> by default as well?

Oh, no, as I said, there's no problem whatsoever.  I was just advocating my
own code, hoping you'd try it out and improve it further rather than just
replicate it in your own corner with just slightly different limitations.


        Stefan

Re: helpex.el 0.2 --- useful extensions for the C-h prefix

[Kevin Rodgers]

Stefan Monnier wrote:

>Michael Schierl writes:
>>Is there a good solution for the Info-goto-node "problem" as well?
> 
> IIRC, the goto-node code in CVS does completion within the parenthesese,
> but it does not do completion of the node name afterwards (this requires
> looking inside the Info file and I didn't bother writing it up).

That's a feature I've always wanted.  In fact, I think I hacked it up in a
previous lifetime, but I lost it...

-- 
Kevin Rodgers

Re: helpex.el 0.2 --- useful extensions for the C-h prefix

[Michael Schierl]

Hmm, unannounced Followup-To. Is that best current practice here in
gnu.*?

Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>> Is there a good solution for the Info-goto-node "problem" as well?
>
>IIRC, the goto-node code in CVS does completion within the parenthesese,
>but it does not do completion of the node name afterwards (this requires
>looking inside the Info file and I didn't bother writing it up).
>
>> IOW: If you have an info file called "foo" with a node "Bar Baz" (e.g.
>> "(elisp)Regular Expressions"), can you type
>
>> C-h i g (foo)Bar SPC Baz RET
>
>> while p-c-m is enabled, *without* making Emacs barf about no
>> completion when hitting SPC?
>
>I haven't used p-c-m in a while and I use C-a SPC 

Do you mean C-q SPC?

>to insert a space, so
>I wouldn't know.  If it works without p-c-m, then it's a bug in p-c-m,
>otherwise it's a misfeature.

It's most likely a bug in p-c-m. On the other hand, without p-c-m,
when you hit TAB twice after entered the full file name (e.g.
"(emacs)"), you first get "[Complete, but not unique]" and on the
second try "[No completions]". Maybe that's irritating p-c-m.

Michael
-- 
"New" PGP Key! User ID: Michael Schierl <schierlm@gmx.de>
Key ID: 0x58B48CDD    Size: 2048    Created: 26.03.2002
Fingerprint:  68CE B807 E315 D14B  7461 5539 C90F 7CC8
http://home.arcor.de/mschierlm/mschierlm.asc

Re: helpex.el 0.2 --- useful extensions for the C-h prefix

[Stefan Monnier]

> Hmm, unannounced Followup-To. Is that best current practice here in gnu.*?

I sometimes get tired of writing the same stuff over and over again, so
when redirecting discussions from gnu.emacs.sources to gnu.emacs.help,
I don't always do it "properly".  Especially because I think it's the role
of the newsreader to announce when followup is set to something else.

>> I haven't used p-c-m in a while and I use C-a SPC 
> Do you mean C-q SPC?

Oops, yes, indeed.  Sorry for the typo.

>> to insert a space, so
>> I wouldn't know.  If it works without p-c-m, then it's a bug in p-c-m,
>> otherwise it's a misfeature.
> It's most likely a bug in p-c-m. On the other hand, without p-c-m,
> when you hit TAB twice after entered the full file name (e.g.
> "(emacs)"), you first get "[Complete, but not unique]" and on the
> second try "[No completions]".  Maybe that's irritating p-c-m.

Sounds like a problem indirectly due to the fact that the completion
commands like TAB do not know how to deal with a completion-table that
"doesn't work".  Or seen from the other side, there's no way for the
completion table to tell the completion commands that "completion doesn't
work here".  So instead, the completion table lies and says things like
"this is valid text" (since potentially all is valid) but it also returns
an empty list of possible completions (even though the first response
implies that the current text is one valid completion).

Maybe we should extend `try-completion's interface to return `no-completion'
when completion is unavailable, so the completion commands can then output
some more meaningful message.


        Stefan