is this a bug?

is this a bug?

[David Roderick]

9.2.4 Symbol Function Indirection
---------------------------------

 -- Function: indirect-function function &optional noerror
     This function returns the meaning of FUNCTION as a function.  If
     FUNCTION is a symbol, then it finds FUNCTION's function definition
     and starts over with that value.  If FUNCTION is not a symbol,
     then it returns FUNCTION itself.

     This function signals a `void-function' error if the final symbol
     is unbound and optional argument NOERROR is `nil' or omitted.
     Otherwise, if NOERROR is non-`nil', it returns `nil' if the final
     symbol is unbound.

     It signals a `cyclic-function-indirection' error if there is a
     loop in the chain of symbols.

     Here is how you could define `indirect-function' in Lisp:

          (defun indirect-function (function)
            (if (symbolp function)
                (indirect-function (symbol-function function))
              function))


shouldn't this be? 

          (defun indirect-function (function)
            (if (symbolp function)
                (symbol-function function)
              (function))


-- 
from 
David Roderick

Re: is this a bug?

[Pascal Bourguignon]

David Roderick <angel_ov_north@tiscali.co.uk> writes:

> 9.2.4 Symbol Function Indirection
> ---------------------------------
>
>  -- Function: indirect-function function &optional noerror
>      This function returns the meaning of FUNCTION as a function.  If
>      FUNCTION is a symbol, then it finds FUNCTION's function definition
>      and starts over with that value.  If FUNCTION is not a symbol,
>      then it returns FUNCTION itself.
>
>      This function signals a `void-function' error if the final symbol
>      is unbound and optional argument NOERROR is `nil' or omitted.
>      Otherwise, if NOERROR is non-`nil', it returns `nil' if the final
>      symbol is unbound.
>
>      It signals a `cyclic-function-indirection' error if there is a
>      loop in the chain of symbols.
>
>      Here is how you could define `indirect-function' in Lisp:
>
>           (defun indirect-function (function)
>             (if (symbolp function)
>                 (indirect-function (symbol-function function))
>               function))
>
>
> shouldn't this be? 
>
>           (defun indirect-function (function)
>             (if (symbolp function)
>                 (symbol-function function)

That wouldn't be the same thing.

(setf (symbol-function 'c) (symbol-function 'car)
      (symbol-function 'b) (symbol-function 'c)
      (symbol-function 'a) (symbol-function 'b))

(indirect-function 'a) --> #<subr car> ; is more usefull than b

>               (function))

Is invalid, function is a special operator that takes one argument, a
symbol or a lambda form.


Note that in emacs lisp, function == quote, but is a hint for the
compiler that the argument of function shall be compiled.


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

HANDLE WITH EXTREME CARE: This product contains minute electrically
charged particles moving at velocities in excess of five hundred
million miles per hour.

Re: is this a bug?

[Barry Margolin]

In article <ur6du1quj.fsf@tiscali.co.uk>,
 David Roderick <angel_ov_north@tiscali.co.uk> wrote:

> 9.2.4 Symbol Function Indirection
> ---------------------------------
> 
>  -- Function: indirect-function function &optional noerror
>      This function returns the meaning of FUNCTION as a function.  If
>      FUNCTION is a symbol, then it finds FUNCTION's function definition
>      and starts over with that value.  If FUNCTION is not a symbol,
>      then it returns FUNCTION itself.
> 
>      This function signals a `void-function' error if the final symbol
>      is unbound and optional argument NOERROR is `nil' or omitted.
>      Otherwise, if NOERROR is non-`nil', it returns `nil' if the final
>      symbol is unbound.
> 
>      It signals a `cyclic-function-indirection' error if there is a
>      loop in the chain of symbols.
> 
>      Here is how you could define `indirect-function' in Lisp:
> 
>           (defun indirect-function (function)
>             (if (symbolp function)
>                 (indirect-function (symbol-function function))
>               function))
> 
> 
> shouldn't this be? 
> 
>           (defun indirect-function (function)
>             (if (symbolp function)
>                 (symbol-function function)
>               (function))

No, because the description says it "starts over with that value", not 
"returns that value".  It follows a chain of indirections, not just one 
level.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***

Is this a bug?

[Leo]

Hi there,

I am running Emacs from CVS2009-08-10. Do you think the following is a
bug?

When a variable is locally safe when it satisfies a predicate, it is
still treated as unsafe in .dir-locals.el.

For example using the following .dir-locals.el and open a .TeX file in
the same dir and you will see a warning about enabling unsafe local
variable.

  ((LaTeX-mode . ((reftex-vref-is-default t))))

Best,

Leo

Is this a bug ?

[horse_rivers]

hi:

   I  use  emacs  gdb  to  debug  ,and find  a  problem  when  I  use  the  gdb-disassembly-buffer   , which  is described  below :

   I stepi the  progremme, the  gdb-disassembly-buffer  should  follow  with  $ip  , but  I  find  it  changes to  another  function's 

  disassembly code  after  a  "mov"  instrution.  this means the  gdb-disassembly-buffer can not  follow  the $ip.
 
  or  amy other  reasons?


thanks!

Re: Is this a bug ?

[Eli Zaretskii]

> Date: Thu, 27 Sep 2012 17:36:42 +0800 (CST)
> From: horse_rivers <horse_rivers@126.com>
> 
>    I  use  emacs  gdb  to  debug  ,and find  a  problem  when  I  use  the  gdb-disassembly-buffer   , which  is described  below :
> 
>    I stepi the  progremme, the  gdb-disassembly-buffer  should  follow  with  $ip  , but  I  find  it  changes to  another  function's 
> 
>   disassembly code  after  a  "mov"  instrution.  this means the  gdb-disassembly-buffer can not  follow  the $ip.

Does this happen if you run GDB outside Emacs, from the shell, with
the same program you debug?  If it happens outside Emacs, then you
should ask this question on the GDB mailing list, gdb@sourceware.org.

In any case, please show the details of the commands you type and what
you see as result in the disassembly buffer.

Re: Is this a bug ?

[Eli Zaretskii]

> Date: Fri, 28 Sep 2012 08:27:17 +0800 (CST)
> From: horse_rivers  <horse_rivers@126.com>
> 
> oh，yes,I  run gdb  within  emacs 

I understand that.  But I asked whether the same problem happens if
you try the same outside Emacs.

Is this a bug?

[Perry Smith]

[-- Attachment #1: Type: text/plain, Size: 1480 bytes --]

First, the working case:

emacs -q
C-h f load
switch to the help buffer.  
Hit tab to get to the button that says "C source code" and hit return.  
I get the file.

Now the non-working case.  Repeat the above after adding advice:

(defadvice load (before load-log activate)
  (message "Loading %s" (ad-get-arg 0)))

and I get an error with the stack:

Debugger entered--Lisp error: (wrong-type-argument subrp (lambda (file &optional noerror nomessage n$
  subr-name((lambda (file &optional noerror nomessage nosuffix must-suffix) #("Advice doc string" 0 $
  help-C-file-name((lambda (file &optional noerror nomessage nosuffix must-suffix) #("Advice doc str$
  #[(fun file) "\303\304!\210^H\305=\203^Q^@\306\307    !\301\"^P\310   \311^H#^Z\312\n@!\210\nA\203$
  apply(#[(fun file) "\303\304!\210^H\305=\203^Q^@\306\307      !\301\"^P\310   \311^H#^Z\312\n@!\21$
  help-do-xref(33 #[(fun file) "\303\304!\210^H\305=\203^Q^@\306\307    !\301\"^P\310   \311^H#^Z\31$
  help-button-action(#<marker (moves after insertion) at 33 in *Help*>)
  push-button(33)
  call-interactively(push-button nil nil)

This is emacs 24.3

What is also curious is once I get one of these buttons to work, e.g. I do the same sequence with autoload
and view the file, then the button changes from "C source code" to the name of the file and at that point, 
the problem goes away for "load"

This isn't bothersome but I thought I'd ask / report it.

Thank you,
Perry



[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: Is this a bug?

[Tassilo Horn]

Perry Smith <pedzsan@gmail.com> writes:

Hi Perry,

> Now the non-working case.  Repeat the above after adding advice:
>
> (defadvice load (before load-log activate)
>   (message "Loading %s" (ad-get-arg 0)))
>
> and I get an error with the stack:
>
> Debugger entered--Lisp error: (wrong-type-argument subrp (lambda (file
> &optional noerror nomessage n$
>   subr-name((lambda (file &optional noerror nomessage nosuffix must-suffix)

It seems like a bug in 24.3 since your example now works with the
current bzr trunk.  Nevertheless, the docs explicitly warn about
advising subrs like `load':

,----[ (info "(elisp)Advising Functions") ]
|    Unless you know what you are doing, do _not_ advise a primitive
| (*note What Is a Function::).  Some primitives are used by the advice
| mechanism; advising them could cause an infinite recursion.  Also, many
| primitives are called directly from C code.  Calls to the primitive from
| Lisp code will take note of the advice, but calls from C code will
| ignore the advice.
`----

The concrete problem is that `help-C-file-name' assumes that a function
defined in C is a subr.  But when you add a piece of advice, the subr
is wrapped in a lisp function, and then `subr-name' fails.

--8<---------------cut here---------------start------------->8---
ELISP> (symbol-function 'load)
#<subr load>
ELISP> (defadvice load (before load-log activate)
  (message "Loading %s" (ad-get-arg 0)))
load
ELISP> (symbol-function 'load)
#[128 "\300\301\302.#\207"
      [apply ad-Advice-load #<subr load> nil]
      5
      #("Advised function" 0 16
	(dynamic-docstring-function advice--make-docstring))]
--8<---------------cut here---------------end--------------->8---

After defining the advice with the current bzr version, the help buffer
states "load is a compiled Lisp function" without any file link.  That's
better than an error, but still not perfect.  One could get the original
subr with (ad-get-orig-definition 'load) to also include a link to the C
source.

I just checked: with emacs 23, when you advised load or any other subr,
C-h f still had a link to the C source, so IMHO that counts as a
regression.

Bye,
Tassilo

Re: Is this a bug?

[Tassilo Horn]

Perry Smith <pedzsan@gmail.com> writes:

Hi again,

> This is emacs 24.3

Strange, I don't get that error with

  GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.20)
  of 2013-08-18 on thinkpad

Bye,
Tassilo

Is this a bug?

[hput]

I compiled emacs today and eventually got a clean ./configure run

 ./configure --prefix=/usr/local/src/git/test --with-x=yes \
 --with-x-toolkit=athena --with-imagemagick --with-gnutls \
 --with-sound=no --without-selinux --no-create --no-recursion

The process added the last three up there.

All was good.

But then I ran "make bootstrap" and that process turned up the fact
that I did not have "makeinfo".  That used to get cleared or halted
during ./configure and I've hit a number of times my self during
./configure.

It seems there should not be tools turning up missing in "make
bootstrap" if ./configure showed good to go.

Is that an actual bug or something else?