emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: info-look for things other than elisp lookup


From: Richard Kim
Subject: Re: info-look for things other than elisp lookup
Date: Sat, 15 Jan 2022 21:54:15 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.90 (gnu/linux)

"T.V Raman" <raman@google.com> writes:

> info-look works for elisp symbols, but apparently for nothing else,
> though the docs indicate it should be able to lookup things in all of
> the installed files.
>
> Is the above expectation true?
>
> As an example, try C-h S in a python buffer -- it can find none of the
> Python symbols in the installed python info pages.
> The Messages buffer shows:
>
> Not documented as a symbol: round
>  Not documented as a symbol: list
>
> Interestingly, when you look up an elisp symbol, you see it searching
> through emacs and cl info pages according to the Messages log.

I used org-mode markup below.  Please let me know if this is not appropriate 
for this list.

When ~C-h S~ key, bound to ~info-lookup-symbol~, is hit with the cursor over
"round" symbol, then it is reasonable to expect this to bring up Python info
document and put the cursor on the line that documents ~round()~ python 
function.
However we encounter this error:

: Not documented as a symbol: round

I believe this is due to the absence of "round" item in the menu at
~(python)Index~ info node. Instead of item named "round" I see menu time named
"round() (built-in function)". I have ~python.info~ file installed via
https://github.com/Wilfred/python-info.git package.

The problem seems to be the following code near the top of ~info-lookup~ 
function:
: (assoc (if ignore-case (downcase item) item) completions)
where we try to find item named "round" when the ~completions~ alist only has
item named "round() (built-in function)". 

I think python.info is generated from python.texi which in turn is generated
from python rst documents via sphinx.

Could it be that sphinx or sphinx configuration was modified to generate more
verbose index entries and so broke info-lookup? Regardless should info-lookup
be modified so that when there is no exact match of menu items, then it should
relax the criteria and see if there are other menu items? For example if
"round" does not match, then look for menu items that match ~^round\b~ regexp.

If I manually select "round() (built-in function)" menu item in (python)Index
node, then emacs brings up "Built-in Functions" node and places the cursor at
the first line of the following:

#+begin_example
 -- Function: round (number[, ndigits])

     Return the floating point value `number' rounded to `ndigits'
     digits after the decimal point.  If `ndigits' is omitted, it
     defaults to zero.  The result is a floating point number.  Values
     are rounded to the closest multiple of 10 to the power minus
     `ndigits'; if two multiples are equally close, rounding is done
     away from 0 (so, for example, ‘round(0.5)’ is ‘1.0’ and
     ‘round(-0.5)’ is ‘-1.0’).

          Note: The behavior of *note round(): 1c6. for floats can be
          surprising: for example, ‘round(2.675, 2)’ gives ‘2.67’
          instead of the expected ‘2.68’.  This is not a bug: it’s a
          result of the fact that most decimal fractions can’t be
          represented exactly as a float.  See *note Floating Point
          Arithmetic; Issues and Limitations: 634. for more information.
#+end_example

Thus it seems like to me that modifying info-lookup to relax node name matching
criteria could be very helpful in this case.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]