Can't compile

Can't compile

[Germán Arias]

Currently I get the error (revision 104188 and with ./configure
--with-ns):

Compiling /home/german/Instalados/emacs/src/../lisp/minibuffer.el
Wrote /home/german/Instalados/emacs/lisp/minibuffer.elc
make[3]: Leaving directory `/home/german/Instalados/emacs/lisp'
make[3]: Entering directory `/home/german/Instalados/emacs/lisp'
Compiling /home/german/Instalados/emacs/src/../lisp/startup.el
Fatal error (11)Aborted
make[3]: *** [compile-onefile] Error 134
make[3]: Leaving directory `/home/german/Instalados/emacs/lisp'
make[2]: *** [/home/german/Instalados/emacs/src/../lisp/startup.elc]
Error 2
make[2]: Leaving directory `/home/german/Instalados/emacs/src'
make[1]: *** [src] Error 2
make[1]: Leaving directory `/home/german/Instalados/emacs'
make: *** [bootstrap] Error 2

any advice?

Re: Can't compile

[Harald Hanche-Olsen]

[Germán Arias <german@xelalug.org> (2011-05-10 18:12:30 UTC)]

> Currently I get the error (revision 104188 and with ./configure
> --with-ns):

I can't reproduce this (with revision 104190, but it's doubtful that
the intervening updates have any bearing on this).

You might try again from scratch, just to make sure:

make distclean
./autogen.sh
./configure --with-ns
make bootstrap

or (my favourite method):

make distclean
./autogen.sh
mkdir build
cd build
../configure --with-ns
make bootstrap

- Harald

Re: Can't compile

[Germán Arias]

On mié, 2011-05-11 at 13:51 +0200, Harald Hanche-Olsen wrote:
> [Germán Arias <german@xelalug.org> (2011-05-10 18:12:30 UTC)]
> 
> > Currently I get the error (revision 104188 and with ./configure
> > --with-ns):
> 
> I can't reproduce this (with revision 104190, but it's doubtful that
> the intervening updates have any bearing on this).
> 
> You might try again from scratch, just to make sure:
> 
> make distclean
> ./autogen.sh
> ./configure --with-ns
> make bootstrap
> 
> or (my favourite method):
> 
> make distclean
> ./autogen.sh
> mkdir build
> cd build
> ../configure --with-ns
> make bootstrap
> 
> - Harald

Thanks, but even with this I get the same error (revision 104208). Maybe
a problem with my compiler? I have gNweSense Delta H. I will try to
update my compiler.
 

Can't compile

[Germán Arias]

Currently with "make bootstrap" I get a lot of errors (I updated my
local copy of trunk): 

../lib/libgnu.a:1695:1: error: stray '\1' in program
../lib/libgnu.a:1695:1: error: stray '\7' in program
../lib/libgnu.a:1695:558: warning: null character(s) ignored [enabled by
default]
../lib/libgnu.a:1695:1: error: stray '\20' in program
../lib/libgnu.a:1695:561: warning: null character(s) ignored [enabled by
default]
../lib/libgnu.a:1695:1: error: stray '\1' in program
../lib/libgnu.a:1695:1: error: stray '\2' in program
../lib/libgnu.a:1695:566: warning: null character(s) ignored [enabled by
default]
../lib/libgnu.a:1695:1: error: stray '\312' in program
../lib/libgnu.a:1695:569: warning: null character(s) ignored [enabled by
default]
../lib/libgnu.a:1695:1: error: stray '\1' in program
../lib/libgnu.a:1695:1: error: stray '\2' in program
../lib/libgnu.a:1695:574: warning: null character(s) ignored [enabled by
default]
make[2]: *** [etags] Error 1
make[2]: Leaving directory `/home/german/Instalados/emacs/lib-src'
make[1]: *** [lib-src] Error 2
make[1]: Leaving directory `/home/german/Instalados/emacs'
make: *** [bootstrap] Error 2


it show also an error on regex.o. I have a modification in file
configur.in (I'm testing a patch to work with gnustep). But as I can see
this isn't the problem. Any advice?

Re: Can't compile

[Davis Herring]

> ../lib/libgnu.a:1695:1: error: stray '\1' in program

You're compiling a library as if it were source!

> it show also an error on regex.o. I have a modification in file
> configur.in (I'm testing a patch to work with gnustep). But as I can see
> this isn't the problem. Any advice?

Either you do have something misconfigured or it's a recently-committed
Makefile problem or so.  You can try looking at the log for the lib-src
Makefile to see if it's been changed recently, or double-check your
configure.in changes.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Can't compile

[Germán Arias]

On mié, 2011-08-10 at 07:57 -0600, Davis Herring wrote:
> > ../lib/libgnu.a:1695:1: error: stray '\1' in program
> 
> You're compiling a library as if it were source!
> 
> > it show also an error on regex.o. I have a modification in file
> > configur.in (I'm testing a patch to work with gnustep). But as I can see
> > this isn't the problem. Any advice?
> 
> Either you do have something misconfigured or it's a recently-committed
> Makefile problem or so.  You can try looking at the log for the lib-src
> Makefile to see if it's been changed recently, or double-check your
> configure.in changes.
> 
> Davis
> 

Well, after revert the changes all works fine. So definitely is
something wrong in my changes. But since I don't have experience with
autogen, configure scripts, ... I can't see where is the problem. First
I define _NATIVE_OBJC_EXCEPTIONS, according with the value saved in
GSConfig.h. This is necessary, in other way we can't compile gnustep
headers. Second I keep the gnustep flags in CFLAGS and CPPFLAGS, because
these are necessary when execute make. If gnustep is installed using the
fsh layout I suppose this isn't necessary. But if is installed with
gnustep layout, we need these flags. With these changes I can configure
emacs (with gnustep) successfully. But of course there is something
wrong. These are my changes.

=== modified file 'configure.in'
--- configure.in	2011-08-04 17:04:39 +0000
+++ configure.in	2011-08-10 21:38:51 +0000
@@ -219,6 +219,14 @@
 test "X$GNUSTEP_CONFIG_FILE" = "X" && \
      GNUSTEP_CONFIG_FILE=/etc/GNUstep/GNUstep.conf
 
+GNUSTEP_LOCAL_HEADERS="$(. $GNUSTEP_CONFIG_FILE; echo
$GNUSTEP_LOCAL_HEADERS)"
+
+if grep "BASE_NATIVE_OBJC_EXCEPTIONS     1"
${GNUSTEP_LOCAL_HEADERS}/GNUstepBase/GSConfig.h; then
+  AC_DEFINE(_NATIVE_OBJC_EXCEPTIONS, 1, [Syncronize native exceptions
with gnustep-base.])
+else
+  AC_DEFINE(_NATIVE_OBJC_EXCEPTIONS, 0, [Syncronize native exceptions
with gnustep-base.])
+fi
+
 AC_ARG_ENABLE(ns-self-contained,
 [AS_HELP_STRING([--disable-ns-self-contained],
                 [disable self contained build under NeXTstep])],
@@ -1483,8 +1491,6 @@
 HAVE_NS=no
 NS_IMPL_COCOA=no
 NS_IMPL_GNUSTEP=no
-tmp_CPPFLAGS="$CPPFLAGS"
-tmp_CFLAGS="$CFLAGS"
 CPPFLAGS="$CPPFLAGS -x objective-c"
 CFLAGS="$CFLAGS -x objective-c"
 TEMACS_LDFLAGS2="\${LDFLAGS}"
@@ -1551,8 +1557,6 @@
   NS_OBJ="fontset.o fringe.o image.o"
   NS_OBJC_OBJ="nsterm.o nsfns.o nsmenu.o nsselect.o nsimage.o nsfont.o"
 fi
-CFLAGS="$tmp_CFLAGS"
-CPPFLAGS="$tmp_CPPFLAGS"
 AC_SUBST(NS_OBJ)
 AC_SUBST(NS_OBJC_OBJ)
 AC_SUBST(LIB_STANDARD)


What is wrong? Thanks.

Re: Can't compile

[Davis Herring]

> -tmp_CPPFLAGS="$CPPFLAGS"
> -tmp_CFLAGS="$CFLAGS"
>  CPPFLAGS="$CPPFLAGS -x objective-c"
>  CFLAGS="$CFLAGS -x objective-c"

By keeping the "-x objective-c" you're telling the compiler that all
subsequent files are Objective C files, including ../lib/libgnu.a.

You'll have to find some way to restrict those flags to only the actual
source files, perhaps by countermanding them with "-x none" later.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Can't compile

[Germán Arias]

On mié, 2011-08-10 at 16:44 -0600, Davis Herring wrote:
> 
> By keeping the "-x objective-c" you're telling the compiler that all
> subsequent files are Objective C files, including ../lib/libgnu.a.
> 
> You'll have to find some way to restrict those flags to only the actual
> source files, perhaps by countermanding them with "-x none" later.

This solve the problem. Thanks.

> 
> Davis
> 

Re: Can't compile

[Germán Arias]

On mié, 2011-08-10 at 17:59 -0600, Germán Arias wrote: 
> On mié, 2011-08-10 at 16:44 -0600, Davis Herring wrote:
> > 
> > By keeping the "-x objective-c" you're telling the compiler that all
> > subsequent files are Objective C files, including ../lib/libgnu.a.
> > 
> > You'll have to find some way to restrict those flags to only the actual
> > source files, perhaps by countermanding them with "-x none" later.
> 
> This solve the problem. Thanks.
> 
> > 
> > Davis
> > 

Now I have other problem. These are my changes:

=== modified file 'configure.in'
--- configure.in/s /    2011-08-04 17:04:39 +0000
+++ configure.in        2011-08-12 05:07:55 +0000
@@ -219,6 +219,14 @@
 test "X$GNUSTEP_CONFIG_FILE" = "X" && \
      GNUSTEP_CONFIG_FILE=/etc/GNUstep/GNUstep.conf

+GS_LOCAL_HEADERS="$(. $GNUSTEP_CONFIG_FILE; echo
$GNUSTEP_LOCAL_HEADERS)"
+
+if grep "BASE_NATIVE_OBJC_EXCEPTIONS     1"
${GS_LOCAL_HEADERS}/GNUstepBase/GSConfig.h; then
+  AC_DEFINE(_NATIVE_OBJC_EXCEPTIONS, 1, [Synchronize native exceptions
with gnustep-base.])
+else
+  AC_DEFINE(_NATIVE_OBJC_EXCEPTIONS, 0, [Synchronize native exceptions
with gnustep-base.])
+fi
+
 AC_ARG_ENABLE(ns-self-contained,
 [AS_HELP_STRING([--disable-ns-self-contained],
                 [disable self contained build under NeXTstep])],
@@ -1488,6 +1496,9 @@
 CPPFLAGS="$CPPFLAGS -x objective-c"
 CFLAGS="$CFLAGS -x objective-c"
 TEMACS_LDFLAGS2="\${LDFLAGS}"
+if _NATIVE_OBJC_EXCEPTIONS=1; then
+   CFLAGS="$CFLAGS -fobjc-exceptions"
+fi
 dnl I don't think it's especially important, but src/Makefile.in
 dnl (now the only user of ns_appdir) used to go to the trouble of
adding a
 dnl trailing "/" to it, so now we do it here.
@@ -2560,7 +2571,10 @@
     AC_DEFINE(NS_IMPL_GNUSTEP, 1, [Define to 1 if you are using NS
windowing under GNUstep.])
     # See also .m.o rule in Makefile.in */
     # FIXME: are all these flags really needed?  Document here why.  */
-    C_SWITCH_X_SYSTEM="-D_REENTRANT -fPIC -fno-strict-aliasing"
+    C_SWITCH_X_SYSTEM="-D_REENTRANT -fPIC -fno-strict-aliasing -I
${GNUSTEP_SYSTEM_HEADERS} ${GNUSTEP_LOCAL_HEADERS}"
+    if _NATIVE_OBJC_EXCEPTIONS=1; then
+       C_SWITCH_X_SYSTEM="$C_SWITCH_X_SYSTEM -fobjc-exceptions"
+    fi
     GNU_OBJC_CFLAGS="-fgnu-runtime -Wno-import
-fconstant-string-class=NSConstantString -DGNUSTEP_BASE_LIBRARY=1
-DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1 -DGSWARN -DGSDIAGNOSE"
   fi
   if test "${NS_HAVE_NSINTEGER}" = "yes"; then


And I get the error:

Compiling hilit-chg.el
Wrote /home/german/Instalados/emacs/lisp/hilit-chg.elc
Compiling hippie-exp.el
Wrote /home/german/Instalados/emacs/lisp/hippie-exp.elc
Compiling hl-line.el
Wrote /home/german/Instalados/emacs/lisp/hl-line.elc
Compiling htmlfontify.el
Aborted
make[3]: *** [htmlfontify.elc] Error 134
make[3]: Leaving directory `/home/german/Instalados/emacs/lisp'
make[2]: *** [compile-main] Error 2
make[2]: Leaving directory `/home/german/Instalados/emacs/lisp'
make[1]: *** [lisp] Error 2
make[1]: Leaving directory `/home/german/Instalados/emacs'
make: *** [bootstrap] Error 2
german@german-desktop:~/Instalados/emacs$ fmake distclean
bash: fmake: command not found

As you can see, I added flags in C_SWITCH_X_SYSTEM. Instead add these in
a global way. Well, I get a lot of warning about that -fobjc-exceptions
is only for ObjC/ObjC++ files. But all files: nsterm.c, emacs.c .....
where gnustep is used, now compile fine (If I don't add this flag, the
compilation stops and show a message requiring this flag.). But the
compilation suddenly stop in htmlfontify.el without more info. Any
advice? Thanks.

Re: Can't compile

[Joost Kremers]

Xavier Maillard wrote:
> nero.el:2119:1:Error: Symbol's function definition is void: nero-follow-numbers
> make: *** [nero.elc] Error 1
[...]
> nero-follow-numbers is a (defined) function used in a macro.

i had the same problem recently with XEmacs (a defun used in a macro
defined in the same file). i solved it by wrapping the defun in an
eval-and-compile. so you could try:

(eval-and-compile
  (defun nero-follow-numbers (lis handler)
    "Used by `nero-defjump' to add a nested list of actions.
  Each action corresponds to following a given numbered link in LIS.
  The last link in the list is followed using HANDLER."
    (let (ret)
      (nero-recursively-add-number-actions (reverse lis) handler ret))))

no idea if this is the proper way to handle it, but it worked.

the same code compiled without problems on GNU/Emacs 22.0.91.1 (without the
eval-and-compile, i mean). i'm not really sure what the story is there...


-- 
Joost Kremers                                      joostkremers@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)

Re: Can't compile

[Xavier Maillard]

Joost Kremers <joostkremers@yahoo.com> wrote:

> Xavier Maillard wrote:
> > nero.el:2119:1:Error: Symbol's function definition is void: nero-follow-numbers
> > make: *** [nero.elc] Error 1
> [...]
> > nero-follow-numbers is a (defined) function used in a macro.
> 
> i had the same problem recently with XEmacs (a defun used in a macro
> defined in the same file). i solved it by wrapping the defun in an
> eval-and-compile. so you could try:

[SNIP]

> the same code compiled without problems on GNU/Emacs 22.0.91.1 (without the
> eval-and-compile, i mean). i'm not really sure what the story is there...

Weird since it did not compiler with emacs22 and emacs21 (21.2 to
21.4). I tried with emacs22.0.51 and it failed miserably.

I am pretty lost here. Could it be a bug into Emacs itself ?

Xavier

Re: Can't compile

[Joost Kremers]

Xavier Maillard wrote:
> Weird since it did not compiler with emacs22 and emacs21 (21.2 to
> 21.4). I tried with emacs22.0.51 and it failed miserably.

did the eval-and-compile work?

> I am pretty lost here. Could it be a bug into Emacs itself ?

it's not a bug in emacs, it's a think-o on my part... the code compiled
fine in my running instance of Emacs, because while developing that code,
and had manually compiled/eval'ed the relevant defun. then when i
byte-compiled the entire file, the defun was known, and Emacs did not
complain.

i just quit Emacs completely and reloaded the relevant file, got rid of the
eval-and-compile and byte-compiled the file. now, Emacs complains in the
same way as XEmacs did before.


-- 
Joost Kremers                                      joostkremers@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)

Re: Can't compile

[Xavier Maillard]

Joost Kremers <joostkremers@yahoo.com> wrote:

> Xavier Maillard wrote:
> > Weird since it did not compiler with emacs22 and emacs21 (21.2 to
> > 21.4). I tried with emacs22.0.51 and it failed miserably.
> 
> did the eval-and-compile work?

Yes and no. Yes it worked after having added several eval-when
forms but no, I am really not satisfied by this solution.

I would like to know why it solely happens with this defmacro :)
 
> > I am pretty lost here. Could it be a bug into Emacs itself ?
> 
> it's not a bug in emacs, it's a think-o on my part... the code compiled
> fine in my running instance of Emacs, because while developing that code,
> and had manually compiled/eval'ed the relevant defun. then when i
> byte-compiled the entire file, the defun was known, and Emacs did not
> complain.
> 
> i just quit Emacs completely and reloaded the relevant file, got rid of the
> eval-and-compile and byte-compiled the file. now, Emacs complains in the
> same way as XEmacs did before.

I am using a Makefile to byte-compile and thus I am using -q -Q
as my command line switches.

Xavier

Re: Can't compile

[Robert Thorpe]

On Feb 24, 10:28 am, Xavier Maillard <z...@gnu.org> wrote:
> Hi,
>
> I am trying to byte-compile nero.el[1] but it just fails with
> this error:
>
> In nero-restore-match:
> nero.el:1526:17:Warning: `string-to-int' is an obsolete function (as of Emacs
>     22.1); use `string-to-number' instead.
> nero.el:2119:1:Error: Symbol's function definition is void: nero-follow-numbers
> make: *** [nero.elc] Error 1
>
> The first warning is easy to fix (and I fixed it) but what about
> the second error ?

I don't know anything about this code, but what is shown here is a
rather common lisp error.

The function nero-follow-numbers is used in a macro.  This macro is
used in the file/compilation block nero.elc.
The bytecompiler works on a per file basis.  It compiles each of the
defuns to bytecodes completing it's actions once the file is
finished.  Macros though must be expanded when the code is being read,
at this stage the defuns in the file have not yet been finalised.

This works fine for the normal evalutator because it finalises and
installs a function at the end of the defun form.

This is why "eval-and-compile" is needed.

Re: Can't compile

[Xavier Maillard]

Robert Thorpe <rthorpe@realworldtech.com> wrote:

> This is why "eval-and-compile" is needed.

This is a neat explanation Robert. Thank you very much.

Problem with this code is that even with a "eval-and-compile"
there are several other places where I have to add this clause or
the "eval-when-compile" form. That's why it is sucky ;)

Xavier

Re: Can't compile

[Robert Thorpe]

On Feb 26, 6:31 pm, Xavier Maillard <z...@gnu.org> wrote:
> Robert Thorpe <rtho...@realworldtech.com> wrote:
> > This is why "eval-and-compile" is needed.
>
> This is a neat explanation Robert. Thank you very much.

I hope it's correct.

> Problem with this code is that even with a "eval-and-compile"
> there are several other places where I have to add this clause or
> the "eval-when-compile" form. That's why it is sucky ;)

Yes.  Have a look at how some other modes deal with it, often you can
get away with only a few mentions of eval-when-compile or eval-and-
compile. One way to do it is to put all the functions used in macros
into a separate file and then load that file inside eval-when-compile.

Re: Can't compile

[Xavier Maillard]

Robert Thorpe <rthorpe@realworldtech.com> wrote:

> > Problem with this code is that even with a "eval-and-compile"
> > there are several other places where I have to add this clause or
> > the "eval-when-compile" form. That's why it is sucky ;)
> 
> Yes.  Have a look at how some other modes deal with it, often you can
> get away with only a few mentions of eval-when-compile or eval-and-
> compile. One way to do it is to put all the functions used in macros
> into a separate file and then load that file inside eval-when-compile.

That's an idea but this is not my code :) I can only make changes
onto my local copy. I hope Joe will see this discussion or even
better, answer to my application to maintain this code ;)

Once again, thank you.

Xavier

Re: Can't compile

[Kevin Rodgers]

Robert Thorpe wrote:
> On Feb 24, 10:28 am, Xavier Maillard <z...@gnu.org> wrote:
>> Hi,
>>
>> I am trying to byte-compile nero.el[1] but it just fails with
>> this error:
>>
>> In nero-restore-match:
>> nero.el:1526:17:Warning: `string-to-int' is an obsolete function (as of Emacs
>>     22.1); use `string-to-number' instead.
>> nero.el:2119:1:Error: Symbol's function definition is void: nero-follow-numbers
>> make: *** [nero.elc] Error 1
>>
>> The first warning is easy to fix (and I fixed it) but what about
>> the second error ?
> 
> I don't know anything about this code, but what is shown here is a
> rather common lisp error.
> 
> The function nero-follow-numbers is used in a macro.  This macro is
> used in the file/compilation block nero.elc.
> The bytecompiler works on a per file basis.  It compiles each of the
> defuns to bytecodes completing it's actions once the file is
> finished.  Macros though must be expanded when the code is being read,
> at this stage the defuns in the file have not yet been finalised.
> 
> This works fine for the normal evalutator because it finalises and
> installs a function at the end of the defun form.
> 
> This is why "eval-and-compile" is needed.

A cleaner design would be for the macro to return a form that contains a
call to the function, rather calling the function during macro expansion
to generate the returned form.

-- 
Kevin Rodgers
Denver, Colorado, USA

Re: Can't compile

[Xavier Maillard]

Kevin Rodgers <kevin.d.rodgers@gmail.com> wrote:

> > This is why "eval-and-compile" is needed.
> 
> A cleaner design would be for the macro to return a form that contains a
> call to the function, rather calling the function during macro expansion
> to generate the returned form.

Do you mean a funcall call ?

Xavier

Re: Can't compile

[Robert Thorpe]

On Feb 28, 3:16 am, Kevin Rodgers <kevin.d.rodg...@gmail.com> wrote:
> Robert Thorpe wrote:
<snip>
> > I don't know anything about this code, but what is shown here is a
> > rather common lisp error.
>
> > The function nero-follow-numbers is used in a macro.  This macro is
> > used in the file/compilation block nero.elc.
> > The bytecompiler works on a per file basis.  It compiles each of the
> > defuns to bytecodes completing it's actions once the file is
> > finished.  Macros though must be expanded when the code is being read,
> > at this stage the defuns in the file have not yet been finalised.
>
> > This works fine for the normal evalutator because it finalises and
> > installs a function at the end of the defun form.
>
> > This is why "eval-and-compile" is needed.
>
> A cleaner design would be for the macro to return a form that contains a
> call to the function, rather calling the function during macro expansion
> to generate the returned form.

Yes, but that depends on what the function does, if it does a
significant amount of computation then running it only at
macroexpansion time will make the program faster.

Can't compile

[Xavier Maillard]

Hi,

I am trying to byte-compile nero.el[1] but it just fails with
this error:

In nero-restore-match:
nero.el:1526:17:Warning: `string-to-int' is an obsolete function (as of Emacs
    22.1); use `string-to-number' instead.
nero.el:2119:1:Error: Symbol's function definition is void: nero-follow-numbers
make: *** [nero.elc] Error 1

The first warning is easy to fix (and I fixed it) but what about
the second error ?

nero-follow-numbers is a (defined) function used in a macro.

Here is the defun:

(defun nero-follow-numbers (lis handler)
  "Used by `nero-defjump' to add a nested list of actions.
Each action corresponds to following a given numbered link in LIS.
The last link in the list is followed using HANDLER."
  (let (ret)
    (nero-recursively-add-number-actions (reverse lis) handler ret)))

And the macro:

(defmacro nero-defjump (name baseurl 
                             &optional handler run-after-load 
                             &rest numbers)
  "Create a jump to be used with nero.
Nero jumps are like bookmarks or \"webjumps\", but they can
do a bit more.  The most basic nero jump is essentially just
a bookmark.

The reason you might want more is that sometimes urls change, you
know a consistent way to find them, starting from some
\"landmark\".  You don't want to redefine your bookmark every
time the url changes, but you don't want to physically go through
the process of browsing to the final url either.  What to do?
This macro takes the approach of having nero do the browsing for
you.

NAME is how you might refer to this jump in prose.  BASEURL
is the URL to start from. NUMBERS, if present, indicate the
numbered links to follow, in order.

A function called \"nero-jump-to-\" NAME (suitably marked up)
will be created when this macro runs.

HANDLER can be used to specify alternative instructions on how to
load the final page accessed by the jump.  For one example,
see `nero-oddmuse-recent-changes-handler'."
  (declare (indent defun))
  `(add-to-list 
    'nero-jumps
    (cons ,name 
          (defun ,(intern
                   (concat "nero-jump-to-"
                           (downcase
                            (replace-regexp-in-string
                             " " "-" name))))
            (&optional insert)
            (interactive "P")
            (if insert
                (insert ,baseurl)
              (nero-browse-url 
               ,baseurl
               nil
               ;; this is last,
               ;; use the handler 
               (unless 
                   ,(car numbers)
                 ,handler)
               nil 
               ;; the action we take once the page has loaded
               ;; (typically involves following numbered links)
               ,(nero-follow-numbers numbers handler)
               ;; the first page is not the last page; be ephemeral
               (when ,(car numbers) t)
               ;; maybe revise, otherwise, add.
               (when ,(equal (nero-current-url) baseurl) t)))))))

I can not find a way to "silent" the byte-compiler. Can you help
?

Thank you

Footnotes: 
[1]  http://www.ma.utexas.edu/~jcorneli/a/elisp/nero.el

Re: Can't compile

[Peter Dyballa]

Am 24.02.2007 um 11:28 schrieb Xavier Maillard:

> nero.el:2119:1:Error: Symbol's function definition is void: nero- 
> follow-numbers

I think there is one argument too much in the "Musical Letters" ...

--
Mit friedvollen Grüßen

   Pete

With Capitalism man exploits man. With communism it's the exact  
opposite.

Re: Can't compile

[Xavier Maillard]

Hi,

Peter Dyballa <Peter_Dyballa@Web.DE> wrote:

> Am 24.02.2007 um 11:28 schrieb Xavier Maillard:
> 
> > nero.el:2119:1:Error: Symbol's function definition is void: nero- 
> > follow-numbers
> 
> I think there is one argument too much in the "Musical Letters" ...

Yep but it is not the error reported when byte-compiling. I fixed
the "Musical Letters" entry but it still reports a void function
definition.

Xavier

Re: Can't compile

[Peter Dyballa]

Am 25.02.2007 um 09:08 schrieb Xavier Maillard:

> Peter Dyballa wrote:
>
>> Am 24.02.2007 um 11:28 schrieb Xavier Maillard:
>>
>>> nero.el:2119:1:Error: Symbol's function definition is void: nero-
>>> follow-numbers
>>
>> I think there is one argument too much in the "Musical Letters" ...
>
> Yep but it is not the error reported when byte-compiling. I fixed
> the "Musical Letters" entry but it still reports a void function
> definition.
>

The error must be in nero-defjump then, but I don't understand enough  
of Emacs Lisp to be able to find it. Could be the way the function is  
used is inappropriate ...

--
Greetings

   Pete

The human animal differs from the lesser primates in his passion for  
lists of "Ten Best".
                                      -- H. Allen Smith

Re: Can't compile

[Xavier Maillard]

Peter Dyballa <Peter_Dyballa@Web.DE> wrote:

> The error must be in nero-defjump then, but I don't understand enough
> of Emacs Lisp to be able to find it. Could be the way the function is
> used is inappropriate ...

Sure it has to be with the way it is called. I emailed Joe to ask
him but as of today, I did not receive any answer from him.

Xavier