bug#9054: [External] : bug#9054: 24.0.50; show source in other window

[Drew Adams <drew.adams@oracle.com>]

>> All I do is check whether there is such a thing-at-point.
>> If not, I don't enable the menu item for acting on that
>> kind of thing-at-point.
> 
> If the thing-at-point is nowhere defined, its context
> menu should not show an entry for going to the
> definition of the thing-at-point.

The choice between :visible and :enable is just that:
a choice.  Do what you want.

I chose to show those menu items, possibly disabled,
to let users know they exist, and so they can easily
see when the pointer is over a thing to which the
item applies.

You can instead choose to not show the item at all
when it can't be used for the thing under the pointer.

IMO, the UI state change for :visible is a big one,
and it removes helpful info.  It also provides some
other info, but only by _recognizing absence_.  I
tend to use :enable much more than :visible.  YMMV.

> If the thing-at-point has no manual entry, its
> context menu should not show an entry for looking
> up the manual entry for the thing-at-point.

All but one of the functions I mentioned don't
concern manual entries.  They concern *Help* output.
They're `describe-*' commands.

The exception is `Look Up Symbol in Manual', whose
:enable test is just (symbol-at-point).  That was
my choice.  Yes, the command used for that is
`info-lookup-symbol', and yes, it can result in
a message `Not documented as a symbol: whizbang'.

Do you prefer to search the manual unconditionally
all the time, for eah thing under the pointer?
Will you then complain to yourself that that slows
things down too much?  (Then just don't do that.)

Again, do whatever you want - these are design
choices - judgments.  There's no hard-and-fast
rule that governs such things.  (Try XYZ, and see
what users think.)

> Ideally.  Unfortunately, it sometimes may be too
> time consuming to tell on the fly whether the
> thing-at-point is defined and/or has a manual entry.

Yes.  In which case the design question can become
whether it helps users to provide such a menu item
without strict, 100% certainty that it's applicable,
or to just not give users such a menu item at all.
If the perfect test is too costly, do you give up
or use an imperfect test that at least lets users
try for themselves?

Again, your choice.  I made mine, for my code.