unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* dired.c
@ 2011-04-23  8:57 Andrea Crotti
  2011-04-25  6:08 ` dired.c Paul Eggert
  0 siblings, 1 reply; 6+ messages in thread
From: Andrea Crotti @ 2011-04-23  8:57 UTC (permalink / raw)
  To: emacs-devel

I was looking around the C code trying to understand better how
everything works and I noticed the following thing.

In the file dired.c there is an
#include <setjmp.h>

But no symbols in dired.c depend from that header, so I tried to remove
it and it turns out that it's needed in lisp.h, which is included later.

So why is not included in lisp.h instead?
What's the reason to do such a thing?

-- 
GNU Emacs 24.0.50.1 (x86_64-apple-darwin10.7.0, NS apple-appkit-1038.35)
of 2011-04-23



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: dired.c
  2011-04-23  8:57 dired.c Andrea Crotti
@ 2011-04-25  6:08 ` Paul Eggert
  2011-04-25  6:50   ` dired.c Eli Zaretskii
  2011-04-25 13:40   ` dired.c Stefan Monnier
  0 siblings, 2 replies; 6+ messages in thread
From: Paul Eggert @ 2011-04-25  6:08 UTC (permalink / raw)
  To: Andrea Crotti; +Cc: emacs-devel

On 04/23/11 01:57, Andrea Crotti wrote:
> #include <setjmp.h>

> So why is not included in lisp.h instead?
> What's the reason to do such a thing?

I expect this has to do with how Emacs was configured,
long ago, and that whatever reasons applied way back then
are no longer relevant.

Perhaps we should move the setjmp-related part of lisp.h
into a different header, anyway, for modularity purposes?
Only a few modules (alloc.c and eval.c come to mind)
need to know about the internals of struct handler and
struct catchtag, surely.  We could call this new header
"throw-catch.h", say.  Then, throw-catch.h could include
setjmp.h and we could banish setjmp.h from most of Emacs's
source code.



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: dired.c
  2011-04-25  6:08 ` dired.c Paul Eggert
@ 2011-04-25  6:50   ` Eli Zaretskii
  2011-04-25 13:40   ` dired.c Stefan Monnier
  1 sibling, 0 replies; 6+ messages in thread
From: Eli Zaretskii @ 2011-04-25  6:50 UTC (permalink / raw)
  To: Paul Eggert; +Cc: andrea.crotti.0, emacs-devel

> Date: Sun, 24 Apr 2011 23:08:50 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> Cc: emacs-devel@gnu.org
> 
> Perhaps we should move the setjmp-related part of lisp.h
> into a different header, anyway, for modularity purposes?
> Only a few modules (alloc.c and eval.c come to mind)
> need to know about the internals of struct handler and
> struct catchtag, surely.

Yes, that'd be a very good change, thanks.

In general, any modularization of lisp.h are very welcome, since
lisp.h is included by every Emacs source file, and so any changes in
it trigger massive recompilations.

When I was young, tall, and blond (and our compilation machines were a
lot slower), I suggested that to Richard, and he said it would be a
good job, but he doubted it would be easy.  Alas, I never got to do
that.



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: dired.c
  2011-04-25  6:08 ` dired.c Paul Eggert
  2011-04-25  6:50   ` dired.c Eli Zaretskii
@ 2011-04-25 13:40   ` Stefan Monnier
  2011-04-26 11:58     ` dired.c Andrea Crotti
  1 sibling, 1 reply; 6+ messages in thread
From: Stefan Monnier @ 2011-04-25 13:40 UTC (permalink / raw)
  To: Paul Eggert; +Cc: Andrea Crotti, emacs-devel

> Perhaps we should move the setjmp-related part of lisp.h
> into a different header, anyway, for modularity purposes?
> Only a few modules (alloc.c and eval.c come to mind)
> need to know about the internals of struct handler and
> struct catchtag, surely.  We could call this new header
> "throw-catch.h", say.  Then, throw-catch.h could include
> setjmp.h and we could banish setjmp.h from most of Emacs's
> source code.

Actually, IIUC we could move it all to eval.c.


        Stefan



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: dired.c
  2011-04-25 13:40   ` dired.c Stefan Monnier
@ 2011-04-26 11:58     ` Andrea Crotti
  2011-05-04 19:53       ` dired.c Stefan Monnier
  0 siblings, 1 reply; 6+ messages in thread
From: Andrea Crotti @ 2011-04-26 11:58 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Paul Eggert, emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>
> Actually, IIUC we could move it all to eval.c.
>
>
>         Stefan

I just tried out what you suggested and it compiles to me with these changes:
(sorry it's not a right bzr patch format I still have to check how to do it)

crotti@plaetekopp:~/trunk$ bzr diff src/lisp.h
=== modified file 'src/lisp.h'
--- src/lisp.h	2011-04-15 08:22:34 +0000
+++ src/lisp.h	2011-04-26 11:51:36 +0000
@@ -1966,40 +1966,6 @@
     struct handler *next;
   };
 
-/* This structure helps implement the `catch' and `throw' control
-   structure.  A struct catchtag contains all the information needed
-   to restore the state of the interpreter after a non-local jump.
-
-   Handlers for error conditions (represented by `struct handler'
-   structures) just point to a catch tag to do the cleanup required
-   for their jumps.
-
-   catchtag structures are chained together in the C calling stack;
-   the `next' member points to the next outer catchtag.
-
-   A call like (throw TAG VAL) searches for a catchtag whose `tag'
-   member is TAG, and then unbinds to it.  The `val' member is used to
-   hold VAL while the stack is unwound; `val' is returned as the value
-   of the catch form.
-
-   All the other members are concerned with restoring the interpreter
-   state.  */
-
-struct catchtag
-{
-  Lisp_Object tag;
-  Lisp_Object val;
-  struct catchtag *next;
-  struct gcpro *gcpro;
-  jmp_buf jmp;
-  struct backtrace *backlist;
-  struct handler *handlerlist;
-  int lisp_eval_depth;
-  int pdlcount;
-  int poll_suppress_count;
-  int interrupt_input_blocked;
-  struct byte_stack *byte_stack;
-};
 
 extern Lisp_Object memory_signal_data;
 

crotti@plaetekopp:~/trunk$ bzr diff src/dired.c
=== modified file 'src/dired.c'
--- src/dired.c	2011-04-14 19:34:42 +0000
+++ src/dired.c	2011-04-26 11:51:08 +0000
@@ -22,7 +22,7 @@
 #include <stdio.h>
 #include <sys/types.h>
 #include <sys/stat.h>
-#include <setjmp.h>
+/* #include <setjmp.h> */
 
 #ifdef HAVE_PWD_H
 #include <pwd.h>

-- 
GNU Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.22.0)
 of 2011-03-04 on plaetekopp



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: dired.c
  2011-04-26 11:58     ` dired.c Andrea Crotti
@ 2011-05-04 19:53       ` Stefan Monnier
  0 siblings, 0 replies; 6+ messages in thread
From: Stefan Monnier @ 2011-05-04 19:53 UTC (permalink / raw)
  To: Andrea Crotti; +Cc: Paul Eggert, emacs-devel

>> Actually, IIUC we could move it all to eval.c.
> I just tried out what you suggested and it compiles to me with these changes:
> (sorry it's not a right bzr patch format I still have to check how to do it)

I don't believe it compiles with your change.  You must have done
a "recompile" which ended up deciding that nothing significant needed to
be done.


        Stefan



^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2011-05-04 19:53 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-04-23  8:57 dired.c Andrea Crotti
2011-04-25  6:08 ` dired.c Paul Eggert
2011-04-25  6:50   ` dired.c Eli Zaretskii
2011-04-25 13:40   ` dired.c Stefan Monnier
2011-04-26 11:58     ` dired.c Andrea Crotti
2011-05-04 19:53       ` dired.c Stefan Monnier

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).