gdb-ui.el assumes images support

gdb-ui.el assumes images support

[Eli Zaretskii]

This line from gdb-ui.el:

  (define-fringe-bitmap 'breakpoint
         "\x3c\x7e\xff\xff\xff\xff\x7e\x3c")

causes the Emacs build to fail if it is configured --without-x, since
fringe.c is not compiled then.  (gdb-ui.el affects the build because
tooltip.el says "(require 'gdb-ui)".)

I fixed it temporarily by conditioning define-fringe-bitmap by images
being supported, but that's a kludge, as it breaks the possibility to
prepare an Emacs tarball on a system where Emacs is built without X,
which is typical of making a tarball on fencepost.  So a better change
is required (why does tooltip.el need to require gdb-ui, anyway?).

gdb-ui.el assumes images support

[Nick Roberts]

 > ...(why does tooltip.el need to require gdb-ui, anyway?).

tooltip.el doesn't require gdb-ui. 

emacs -q

`C-h v' features

features's value is 
(help-fns help-mode view button tooltip image tool-bar disp-table mwheel x-dnd fontset ediff-hook vc-hooks lisp-float-type lisp-mode register page menu-bar timer select scroll-bar mldrag mouse facemenu font-core frame ucs-tables georgian utf-8-lang misc-lang vietnamese tibetan thai lao korean japanese hebrew greek romanian slovak czech european ethiopic kannada tamil malayalam devanagari indian cyrillic chinese case-table help simple faces cus-face text-properties overlay md5 base64 format mule env custom widget backquote make-network-process x-toolkit)

tooltip is present, while gdb-ui isn't.

You are probably referring to the fact that tooltip does require gdb-ui for
compilation (eval-when-compile). tooltip.el contains lisp functions from
gdb-ui.el like gdb-enqueue-input and as someone had already `required' gud for
compilation I followed suit and added gdb-ui. Is this what is causing the
problem?

I'm not a lisp expert but there is only one macro in tooltip.el
(tooltip-region-active-p) which doesn't use functions from gud or gdb-ui, so
perhaps these requires aren't necessary? Anyone?

Nick

Re: gdb-ui.el assumes images support

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Sun, 7 Nov 2004 13:23:14 +1300
> Cc: emacs-devel@gnu.org
> 
> You are probably referring to the fact that tooltip does require gdb-ui for
> compilation (eval-when-compile).

Yes.

> tooltip.el contains lisp functions from
> gdb-ui.el like gdb-enqueue-input and as someone had already `required' gud for
> compilation I followed suit and added gdb-ui. Is this what is causing the
> problem?

Yes.

> I'm not a lisp expert but there is only one macro in tooltip.el
> (tooltip-region-active-p) which doesn't use functions from gud or gdb-ui, so
> perhaps these requires aren't necessary? Anyone?

Perhaps it is not necessary, but the real problem is that gdb-ui.el
cannot be compiled on a system where define-fringe-bitmap is not
defined.  That is a Bad Thing, IMHO, and that is the problem we should
fix.

Can the use of define-fringe-bitmap moved to the run-time rather than
compile time?

Re: gdb-ui.el assumes images support

[Andreas Schwab]

"Eli Zaretskii" <eliz@gnu.org> writes:

> Perhaps it is not necessary, but the real problem is that gdb-ui.el
> cannot be compiled on a system where define-fringe-bitmap is not
> defined.  That is a Bad Thing, IMHO, and that is the problem we should
> fix.

Actually gdb-ui.el can be compiled (which won't eval such toplevel forms),
but not loaded on such a system.  Maybe we should add a dummy definition
for define-fringe-bitmap when configured without X?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: gdb-ui.el assumes images support

[Eli Zaretskii]

> Cc: Nick Roberts <nickrob@snap.net.nz>, emacs-devel@gnu.org
> From: Andreas Schwab <schwab@suse.de>
> Date: Sun, 07 Nov 2004 11:35:39 +0100
> 
> Actually gdb-ui.el can be compiled (which won't eval such toplevel forms),
> but not loaded on such a system.

Yes, but the problem is, tooltip.el requires gdb-ui.el at compile
time, so tooltip.el cannot be compiled if gdb-ui.el uses
define-fringe-bitmap unconditionally.

> Maybe we should add a dummy definition for define-fringe-bitmap when
> configured without X?

If we did that, and gdb-ui.el is compiled with Emacs built without X,
would the resulting gdb-ui.elc be good for use on X?

Re: gdb-ui.el assumes images support

[Andreas Schwab]

"Eli Zaretskii" <eliz@gnu.org> writes:

>> Maybe we should add a dummy definition for define-fringe-bitmap when
>> configured without X?
>
> If we did that, and gdb-ui.el is compiled with Emacs built without X,
> would the resulting gdb-ui.elc be good for use on X?

Sure, since it's not a macro.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: gdb-ui.el assumes images support

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Date: Mon, 08 Nov 2004 11:15:08 +0100
> Cc: nickrob@snap.net.nz, emacs-devel@gnu.org
> 
> > If we did that, and gdb-ui.el is compiled with Emacs built without X,
> > would the resulting gdb-ui.elc be good for use on X?
> 
> Sure, since it's not a macro.

Then this is an okay solution, I think.

Re: gdb-ui.el assumes images support

[Richard Stallman]

    Yes, but the problem is, tooltip.el requires gdb-ui.el at compile
    time,

Can't we get rid of that dependency?
What is the reason for it anyway?

Re: gdb-ui.el assumes images support

[Nick Roberts]

 >     Yes, but the problem is, tooltip.el requires gdb-ui.el at compile
 >     time,
 > 
 > Can't we get rid of that dependency?
 > What is the reason for it anyway?

Yes. I don't think its needed, but gdb-ui is designed to work on text-only
terminals and presumably it won't currently when configured without X?

Anyway, tooltip.el has:

(eval-when-compile
  (require 'cl)
  (require 'comint)
  (require 'gud)
  (require 'gdb-ui))

I added the last require after Gerd Moellmann included the others. My
understanding now is that a file only requires another, at compilation,
if it uses a macro defined in that other file.

If this is the case, tooltip does not need the last three requires,
and requiring cl just seems to redefine push for compilation, so
perhaps thats not needed either.

It's sometimes hard to see why files are required at compilation, so it may
be good practice to add a comment as in vc.el:

(eval-when-compile
  (require 'cl)
  (require 'compile)
  (require 'dired)      ; for dired-map-over-marks macro
  (require 'dired-aux))	; for dired-kill-{line,tree}

I see that dired is required, but dired-kill-line, dired-kill-tree are not
macros so is dired-aux required? I think not, but if the answer is yes that
would explain the need for the requires in tooltip.

Nick

Re: gdb-ui.el assumes images support

[Kim F. Storm]

Nick Roberts <nickrob@snap.net.nz> writes:

> I added the last require after Gerd Moellmann included the others. My
> understanding now is that a file only requires another, at compilation,
> if it uses a macro defined in that other file.

It may also require another file simply to avoid warnings for using
undefined functions that are defined in that file.  

How else would you avoid such warnings?


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: gdb-ui.el assumes images support

[Kevin Rodgers]

Kim F. Storm wrote:
 > Nick Roberts <nickrob@snap.net.nz> writes:
 >>I added the last require after Gerd Moellmann included the others. My
 >>understanding now is that a file only requires another, at compilation,
 >>if it uses a macro defined in that other file.
 >
 > It may also require another file simply to avoid warnings for using
 > undefined functions that are defined in that file.
 >
 > How else would you avoid such warnings?

With (require 'feature) at the top level, since it is needed at runtime.

-- 
Kevin Rodgers

Re: gdb-ui.el assumes images support

[Nick Roberts]

 >  >>I added the last require after Gerd Moellmann included the others. My
 >  >>understanding now is that a file only requires another, at compilation,
 >  >>if it uses a macro defined in that other file.
 >  >
 >  > It may also require another file simply to avoid warnings for using
 >  > undefined functions that are defined in that file.
 >  >
 >  > How else would you avoid such warnings?
 > 
 > With (require 'feature) at the top level, since it is needed at runtime.

That's my understanding, too. Furthermore, the compiler warnings are
presumably there to help the developer decide if he needs to use "require".
In the case of tooltip.el, the undefind functions from gud and gdb-ui can only
be invoked by using their debugger modes, so, AFAIK, "require" is not needed
for these features. To use (require 'feature) just to eliminate warnings,
would be the wrong thing to do, I think.

Nick

Re: gdb-ui.el assumes images support

[Luc Teirlinck]

Nick Roberts wrote:

   To use (require 'feature) just to eliminate warnings,
   would be the wrong thing to do, I think.

That is exactly why one should use:

(eval-when-compile (require 'feature))

to eliminate compiler warnings.  (Of course after you checked that it
is really not necessary to require the feature at runtime.)

Sincerely,

Luc.

Re: gdb-ui.el assumes images support

[Luc Teirlinck]

Nick Roberts wrote:

   In the case of tooltip.el, the undefind functions from gud and
   gdb-ui can only be invoked by using their debugger modes, so,
   AFAIK, "require" is not needed for these features.

If gud and gdb-ui are always going to be loaded whenever they have to
be (even after possible code changes in tooltip.el), then I believe
that the best way to avoid warnings is:

(eval-when-compile (require 'feature))

Otherwise, you can use things like `(if (fboundp 'myfun) ...)' or, if
necessary, `with-no-warnings'.  That would avoid silencing future
legitimate warnings. 

Sincerely,

Luc.

Re: gdb-ui.el assumes images support

[Luc Teirlinck]

Sorry, I jumped into a thread again without reading the previous
messages in the thread.  I did not realize that requiring gdb-ui at
compile time gave problems.  If necessary, it is possible to get rid
of the require of gdb-ui (without creating compiler warnings) by using
`(if (fboundp ...) ...)' three times.  If the require of gud yields
problems too, then one needs two additional defvar's.

Sincerely,

Luc.

Re: gdb-ui.el assumes images support

[Kim F. Storm]

Kevin Rodgers <ihs_4664@yahoo.com> writes:

> Kim F. Storm wrote:
>  > Nick Roberts <nickrob@snap.net.nz> writes:
>  >>I added the last require after Gerd Moellmann included the others. My
>  >>understanding now is that a file only requires another, at compilation,
>  >>if it uses a macro defined in that other file.
>  >
>  > It may also require another file simply to avoid warnings for using
>  > undefined functions that are defined in that file.
>  >
>  > How else would you avoid such warnings?
>
> With (require 'feature) at the top level, since it is needed at runtime.


file a.el has this:
 (require 'b)
 ;;;#autoload
 (defun a-fun1 ()
   (b-fun))
 (defun a-fun2 ()
   t)
 (provide 'a)

file b.el has this:
 (defun b-fun ()
    (a-fun2))
 (provide 'b)

Assuming that b is never used directly, this works fine.


Now, when you byte-compile b.el, you get warning for a-fun2.

So according to your advise, we add
  (require 'a)
to b.el, and compile again with this result:

b.el:1:2:Error: Recursive `require' for feature `a'


What if

(defun a-fun2)

would be a dummy defun for the byte-compiler just like

(defvar a-var)

?


--
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: gdb-ui.el assumes images support

[Kevin Rodgers]

Kim F. Storm wrote:
 > Kevin Rodgers <ihs_4664@yahoo.com> writes:
 > > Kim F. Storm wrote:
 > > > How else would you avoid such warnings?
 > >
 > > With (require 'feature) at the top level, since it is needed at 
runtime.
 >
 > file a.el has this:
 >  (require 'b)
 >  ;;;#autoload
 >  (defun a-fun1 ()
 >    (b-fun))
 >  (defun a-fun2 ()
 >    t)
 >  (provide 'a)
 >
 > file b.el has this:
 >  (defun b-fun ()
 >     (a-fun2))
 >  (provide 'b)
 >
 > Assuming that b is never used directly, this works fine.
 >
 >
 > Now, when you byte-compile b.el, you get warning for a-fun2.
 >
 > So according to your advise, we add
 >   (require 'a)
 > to b.el, and compile again with this result:
 >
 > b.el:1:2:Error: Recursive `require' for feature `a'

I think that is why Common Lisp recommends putting (provide 'feature)
first rather than last; but (provide 'feature) is last in Emacs Lisp
files to support the unload-feature command.

 > What if
 >
 > (defun a-fun2)
 >
 > would be a dummy defun for the byte-compiler just like
 >
 > (defvar a-var)
 >
 > ?

That seems natural to me.

-- 
Kevin Rodgers

Re: gdb-ui.el assumes images support

[Richard Stallman]

     > What if
     >
     > (defun a-fun2)
     >
     > would be a dummy defun for the byte-compiler just like
     >
     > (defvar a-var)

This is ok with me.
I'd much rather use this method than add require calls
for files that we really would rather not load.

Re: gdb-ui.el assumes images support

[Richard Stallman]

    It may also require another file simply to avoid warnings for using
    undefined functions that are defined in that file.  

This "solution" causes more trouble the problem it is meant to solve;
please don't use it.

Re: gdb-ui.el assumes images support

[Luc Teirlinck]

Richard Stallman wrote:

       It may also require another file simply to avoid warnings for using
       undefined functions that are defined in that file.  

   This "solution" causes more trouble the problem it is meant to solve;
   please don't use it.

I do not know whether you are talking about a _run-time_ require or
about the (eval-when-compile (require ...) ...) _in this particular
file_.

If you are talking about (eval-when-compile (require ...) ...) _in
general_ then the following text from `(elisp)Coding Conventions'
which encourages use of this construct to avoid compiler warnings
should be changed:

     Sometimes adding a `require' for another package is useful to
     avoid compilation warnings for variables and functions defined in
     that package.  If you do this, often it is better if the
     `require' acts only at compile time.  Here's how to do that:

          (eval-when-compile
            (require 'foo)
            (defvar bar-baz))


Sincerely,

Luc.

Re: gdb-ui.el assumes images support

[Stefan Monnier]

>      Sometimes adding a `require' for another package is useful to
>      avoid compilation warnings for variables and functions defined in
>      that package.  If you do this, often it is better if the
>      `require' acts only at compile time.  Here's how to do that:

>           (eval-when-compile
>             (require 'foo)
>             (defvar bar-baz))

At least the (defvar bar-baz) should be removed since it has no effect
inside an eval-when-compile (i.e. it doesn't remove the warning).
The `require' doesn't necessarily remove the warning either, mind you.


        Stefan

Re: gdb-ui.el assumes images support

[Luc Teirlinck]

Stefan Monnier wrote:

   The `require' doesn't necessarily remove the warning either, mind you.

I which situations not?  I believe that it should work as long as you
use it before the first use of the variables or functions in question.

I agree that the defvar inside the `eval-when-compile' should be removed.

Sincerely,

Luc.

Re: gdb-ui.el assumes images support

[Richard Stallman]

    If you are talking about (eval-when-compile (require ...) ...) _in
    general_ then the following text from `(elisp)Coding Conventions'
    which encourages use of this construct to avoid compiler warnings
    should be changed:

	 Sometimes adding a `require' for another package is useful to
	 avoid compilation warnings for variables and functions defined in
	 that package.  If you do this, often it is better if the
	 `require' acts only at compile time.  Here's how to do that:

	      (eval-when-compile
		(require 'foo)
		(defvar bar-baz))

Thanks for finding this.  I think I will rewrite it not to suggest this.

Re: gdb-ui.el assumes images support

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     It may also require another file simply to avoid warnings for using
>     undefined functions that are defined in that file.  
>
> This "solution" causes more trouble the problem it is meant to solve;
> please don't use it.

What about the suggestion to have a "declare only" form of defun:

(defun external-func)

that could be added to a file to avoid compiler warnings?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: gdb-ui.el assumes images support

[Richard Stallman]

    I added the last require after Gerd Moellmann included the others.

It sounds like you don't actually know of a reason for it.

								       My
    understanding now is that a file only requires another, at compilation,
    if it uses a macro defined in that other file.

    If this is the case, tooltip does not need the last three requires,

Please try deleting them and see what happens.

Re: gdb-ui.el assumes images support

[Nick Roberts]

 >     If this is the case, tooltip does not need the last three requires,
 > 
 > Please try deleting them and see what happens.

I've done this, followed by "make bootstrap". Since I can find no problem,
I've committed this change. I think there are many other files with requires
that, similarly, aren't really needed. Possibly because of what Luc has
pointed out it says in the manual:

> Sometimes adding a `require' for another package is useful to
> avoid compilation warnings for variables and functions defined in
> that package.  If you do this, often it is better if the
> `require' acts only at compile time...

I've also deleted the require for cl. Using this at compile time, presumably
compiles in expansions of the Common Lisp macros for push and pop, rather than
those in subr.el, which might be undesirable.

Nick

Re: gdb-ui.el assumes images support

[Richard Stallman]

Maybe we should include fringe.c unconditionally, so that defining and
looking up fringe bitmaps will always work, whether or not Emacs
can actually display them.

Re: gdb-ui.el assumes images support

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: nickrob@snap.net.nz, emacs-devel@gnu.org
> Date: Mon, 08 Nov 2004 11:59:42 -0500
> 
> Maybe we should include fringe.c unconditionally, so that defining and
> looking up fringe bitmaps will always work, whether or not Emacs
> can actually display them.

I don't know if fringe.c will compile and link when no X libraries and
no window-system code is present (Kim?).  In any case, the bodies of
some of the functions should probably be conditioned on window-system,
either via #ifdef or a run-time check, if we include fringe.c.  And if
there's already code that tests whether the primitives defined by
fringe.c are fboundp, that code should now be changed to use some
other predicate.

Otherwise, this could be a solution.

Re: gdb-ui.el assumes images support

[Kim F. Storm]

"Eli Zaretskii" <eliz@gnu.org> writes:

>> From: Richard Stallman <rms@gnu.org>
>> CC: nickrob@snap.net.nz, emacs-devel@gnu.org
>> Date: Mon, 08 Nov 2004 11:59:42 -0500
>> 
>> Maybe we should include fringe.c unconditionally, so that defining and
>> looking up fringe bitmaps will always work, whether or not Emacs
>> can actually display them.
>
> I don't know if fringe.c will compile and link when no X libraries and
> no window-system code is present (Kim?).  

It will compile as the whole file is conditioned by HAVE_WINDOW_SYSTEM :-)

>                                           In any case, the bodies of
> some of the functions should probably be conditioned on window-system,
> either via #ifdef or a run-time check, if we include fringe.c.  And if
> there's already code that tests whether the primitives defined by
> fringe.c are fboundp, that code should now be changed to use some
> other predicate.
>
> Otherwise, this could be a solution.

IMHO, adding a few dummy definitions to subr.el would be less work.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: gdb-ui.el assumes images support

[Richard Stallman]

    > I don't know if fringe.c will compile and link when no X libraries and
    > no window-system code is present (Kim?).  

    It will compile as the whole file is conditioned by HAVE_WINDOW_SYSTEM :-)

The idea is to make most of the functions work just the same
with or without a window system.

Re: gdb-ui.el assumes images support

[Richard Stallman]

    I don't know if fringe.c will compile and link when no X libraries and
    no window-system code is present (Kim?).

I think it can't be too hard to make it compile.  Most of the code is
concerned with constructing and accessing fringe bitmaps, and that doesn't
depend on having a real window system.  If someone just tries compiling
it, you should see soon enough what parts to turn off.

Re: gdb-ui.el assumes images support

[Richard Stallman]

    This line from gdb-ui.el:

      (define-fringe-bitmap 'breakpoint
	     "\x3c\x7e\xff\xff\xff\xff\x7e\x3c")

    causes the Emacs build to fail if it is configured --without-x, since
    fringe.c is not compiled then.

Would moving the definition of this function to another file
solve the problem?

Re: gdb-ui.el assumes images support

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     This line from gdb-ui.el:
>
>       (define-fringe-bitmap 'breakpoint
> 	     "\x3c\x7e\xff\xff\xff\xff\x7e\x3c")
>
>     causes the Emacs build to fail if it is configured --without-x, since
>     fringe.c is not compiled then.
>
> Would moving the definition of this function to another file
> solve the problem?

It is defined in fringe.c when HAVE_WINDOW_SYSTEM, so it's not
easy to move.

Perhaps we could add this to subr.el:

(unless widow-system
  (defun define-fringe-bitmap (&optional rest)
    "Dummy function for text-only terminals."))

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: gdb-ui.el assumes images support

[Stefan]

> (unless widow-system
>   (defun define-fringe-bitmap (&optional rest)
>     "Dummy function for text-only terminals."))

I don't want to enter into arguments about the value of marriage, but I'd
rather replace widow-system by (fboundp 'define-fringe-bitmap) in the above.


        Stefan