public inbox for guile-emacs@sourceware.org
 help / color / mirror / Atom feed
* automating %load-path
@ 2000-03-26  8:45 Kalle Olavi Niemitalo
  2000-03-26 10:51 ` Keisuke Nishida
                   ` (2 more replies)
  0 siblings, 3 replies; 12+ messages in thread
From: Kalle Olavi Niemitalo @ 2000-03-26  8:45 UTC (permalink / raw)
  To: guile-emacs

I would like to make Guile Emacs automatically insert its Scheme
directories in the %load-path of Guile, so that users don't have
to do that in ~/.emacs.scm.  My plan:

1. Add a new variable $schemepath in configure.in.

2. Add a new macro PATH_SCMLOADSEARCH in src/epaths.in.  If we
   don't support Scheme in temacs, we don't need
   PATH_SCMDUMPLOADSEARCH.

3. Make the epaths-force target in Makefile.in store $schemepath
   in epaths.h.

4. Make init_guileapi() in src/guileapi.c add the
   PATH_SCMLOADSEARCH directories in %load-path.  I'm not very
   familiar with Guile's C API but I'll learn.  :-)

5. Create a new module (emacs init) and place all Scheme
   initialization code there.  This could load (emacs io).

6. Load (emacs init) from lisp/startup.el.

The Emacs files src/epaths.in and Makefile.in would have to be
added in CVS.  I currently have only Emacs 20.5, not 20.6 so
could you add those files, Keisuke?  I can insert the
modification comments.

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

* Re: automating %load-path
  2000-03-26  8:45 automating %load-path Kalle Olavi Niemitalo
@ 2000-03-26 10:51 ` Keisuke Nishida
  2000-03-27  9:08   ` Kalle Olavi Niemitalo
  2000-04-09 12:46 ` Makefile preprocessing trouble " Kalle Olavi Niemitalo
  2000-04-14  0:29 ` automating %load-path Kalle Olavi Niemitalo
  2 siblings, 1 reply; 12+ messages in thread
From: Keisuke Nishida @ 2000-03-26 10:51 UTC (permalink / raw)
  To: Kalle Olavi Niemitalo; +Cc: guile-emacs

Kalle Olavi Niemitalo <tosi@ees2.oulu.fi> writes:

> I would like to make Guile Emacs automatically insert its Scheme
> directories in the %load-path of Guile, so that users don't have
> to do that in ~/.emacs.scm.  My plan:

I think it is more convenient to set the path explicitly in the init file
than to specify it with the configure program, unless we automatically
install all scheme programs in that directory and most users are just to
use them.  Should we really do this right now?

(I personally add the local cvs directory to %load-path, so I don't need
to install scheme files.)

> 5. Create a new module (emacs init) and place all Scheme
>    initialization code there.  This could load (emacs io).

This is a good idea.  But ~/.emacs.scm is still beneficial as an example
of how to use/setup Guile Emacs.

I haven't have time to work on Guile Emacs these days and will not for
more one month...  Since you Kalle have added some useful features,
including complete-symbol and import-macro, I would like to release
Guile Emacs 0.3.  Could you write some documentation, especially NEWS
file as a function introduction for that?

-- Kei

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

* Re: automating %load-path
  2000-03-26 10:51 ` Keisuke Nishida
@ 2000-03-27  9:08   ` Kalle Olavi Niemitalo
  2000-03-27 17:28     ` Keisuke Nishida
  0 siblings, 1 reply; 12+ messages in thread
From: Kalle Olavi Niemitalo @ 2000-03-27  9:08 UTC (permalink / raw)
  To: Keisuke Nishida; +Cc: guile-emacs

Keisuke Nishida <kxn30@po.cwru.edu> writes:

> I think it is more convenient to set the path explicitly in the init file
> than to specify it with the configure program, unless we automatically
> install all scheme programs in that directory and most users are just to
> use them.  Should we really do this right now?

If users add their own Scheme files in different directories,
they still can alter %load-path in their .emacs.scm.  I think
this would be a step in the right direction.  I would also like
automatic installation, but that may be a little difficult to
implement.  The easiest way might be to put the Scheme files
under src/emacs-20.6 too.

> (I personally add the local cvs directory to %load-path, so I don't need
> to install scheme files.)

(I personally make ${prefix}/share/emacs/20.5/scheme a symlink to
the local CVS directory.)

> Could you write some documentation, especially NEWS file as a
> function introduction for that?

I'll write a NEWS file based on ChangeLog and recent mails.
What other documentation do you have in mind: a complete manual
in Texinfo?  I'm not sure I could manage that.

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

* Re: automating %load-path
  2000-03-27  9:08   ` Kalle Olavi Niemitalo
@ 2000-03-27 17:28     ` Keisuke Nishida
  2000-03-29  2:33       ` before the 0.3 release (was %load-path) Kalle Olavi Niemitalo
  0 siblings, 1 reply; 12+ messages in thread
From: Keisuke Nishida @ 2000-03-27 17:28 UTC (permalink / raw)
  To: Kalle Olavi Niemitalo; +Cc: guile-emacs

Kalle Olavi Niemitalo <tosi@ees2.oulu.fi> writes:

> If users add their own Scheme files in different directories,
> they still can alter %load-path in their .emacs.scm.  I think
> this would be a step in the right direction.  I would also like
> automatic installation, but that may be a little difficult to
> implement.  The easiest way might be to put the Scheme files
> under src/emacs-20.6 too.

That is right.  I am not going to demotivate you.  I have added
the two files (Makefile.in and src/epath.in) just now.

From your past mail:
| 2. Add a new macro PATH_SCMLOADSEARCH in src/epaths.in.  If we
|    don't support Scheme in temacs, we don't need
|    PATH_SCMDUMPLOADSEARCH.

I think we don't need PATH_SCMDUMPLOADSEARCH.

| 5. Create a new module (emacs init) and place all Scheme
|    initialization code there.  This could load (emacs io).
| 
| 6. Load (emacs init) from lisp/startup.el.

I agree with this.  Maybe we don't need to load ~/.emacs.scm
in lisp/startup.el.

> I'll write a NEWS file based on ChangeLog and recent mails.
> What other documentation do you have in mind: a complete manual
> in Texinfo?  I'm not sure I could manage that.

A list of functions/features might be helpful.  Not necessary to
be written precisely because they will possibly change soon.

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

* before the 0.3 release (was %load-path)
  2000-03-27 17:28     ` Keisuke Nishida
@ 2000-03-29  2:33       ` Kalle Olavi Niemitalo
  0 siblings, 0 replies; 12+ messages in thread
From: Kalle Olavi Niemitalo @ 2000-03-29  2:33 UTC (permalink / raw)
  To: Keisuke Nishida; +Cc: guile-emacs

Keisuke Nishida <kxn30@po.cwru.edu> writes:

> I have added the two files (Makefile.in and src/epath.in) just
> now.

Thank you.  However I'm going to have an exam on 2000-04-03 and I
don't know if I can make the changes before that.  So, I think
you should release Guile Emacs 0.3 without waiting for me.

> A list of functions/features might be helpful.  Not necessary to
> be written precisely because they will possibly change soon.

There is already a list of new primitives in the README.  Do you
mean Scheme procedures should be listed too?

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

* Makefile preprocessing trouble (was %load-path)
  2000-03-26  8:45 automating %load-path Kalle Olavi Niemitalo
  2000-03-26 10:51 ` Keisuke Nishida
@ 2000-04-09 12:46 ` Kalle Olavi Niemitalo
  2000-04-10  3:47   ` Kalle Olavi Niemitalo
  2000-04-14  0:29 ` automating %load-path Kalle Olavi Niemitalo
  2 siblings, 1 reply; 12+ messages in thread
From: Kalle Olavi Niemitalo @ 2000-04-09 12:46 UTC (permalink / raw)
  To: guile-emacs

I have implemented points 1-4 of my %load-path plan at home.
However, I haven't been able to test the code because I hit some
trouble with GUILE_LDFLAGS.  I have the Guile libraries at
/home/kalle/i386-pc-linux-gnu/lib/, and when that goes through
the C preprocessor (which Emacs uses for some makefiles), the
"i386" turns to " 1 " which the linker doesn't like at all.

It seems Emacs has had this problem before (with other
variables), and configure.in contains code to add -U options on
the preprocessor command line to get rid of predefined symbols.
(Search for "the horror".)  I tried adding $GUILE_CFLAGS and
$GUILE_LDFLAGS in the list of protected variables, but that
didn't work out because the commands are run in config.status and
the variables are not defined there.

Any suggestions how to tackle this problem?

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

* Re: Makefile preprocessing trouble (was %load-path)
  2000-04-09 12:46 ` Makefile preprocessing trouble " Kalle Olavi Niemitalo
@ 2000-04-10  3:47   ` Kalle Olavi Niemitalo
  0 siblings, 0 replies; 12+ messages in thread
From: Kalle Olavi Niemitalo @ 2000-04-10  3:47 UTC (permalink / raw)
  To: guile-emacs

Kalle Olavi Niemitalo <tosi@ee.oulu.fi> writes:

> the "i386" turns to " 1 " which the linker doesn't like at all.

Solved!  This was a bug in Emacs: config.status tried to protect
the words of $configuration, but that variable was not passed
from configure so the value was empty and nothing was protected.

I'll commit the changes soon.

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

* Re: automating %load-path
  2000-03-26  8:45 automating %load-path Kalle Olavi Niemitalo
  2000-03-26 10:51 ` Keisuke Nishida
  2000-04-09 12:46 ` Makefile preprocessing trouble " Kalle Olavi Niemitalo
@ 2000-04-14  0:29 ` Kalle Olavi Niemitalo
  2000-04-29  1:21   ` Kalle Olavi Niemitalo
  2 siblings, 1 reply; 12+ messages in thread
From: Kalle Olavi Niemitalo @ 2000-04-14  0:29 UTC (permalink / raw)
  To: guile-emacs

Kalle Olavi Niemitalo <tosi@ee.oulu.fi> writes:

> 5. Create a new module (emacs init) and place all Scheme
>    initialization code there.  This could load (emacs io).
> 
> 6. Load (emacs init) from lisp/startup.el.

I have committed these changes.

There is a bug; I now get the following error on startup:
> No such function: scheme-interaction-mode

This message comes from Guile.  `scheme-interaction-mode' exists
as a Lisp function, and in the (emacs guile) module as a Scheme
function, but the default module does not use (emacs guile) and
so the Lisp-to-Scheme call fails.  This can be worked around by
doing M-: (scheme-eval '(use-modules (emacs guile))) after
getting the error.

I guess a real fix involves changing `define-command' so that it
makes the Lisp part of the command always call the Scheme part
from the correct module.  I haven't yet figured out how to do
this.  This will perhaps be affected when Guile gets its new
module system, but I don't think we should wait for that.

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

* Re: automating %load-path
  2000-04-14  0:29 ` automating %load-path Kalle Olavi Niemitalo
@ 2000-04-29  1:21   ` Kalle Olavi Niemitalo
  2000-04-29  1:46     ` Keisuke Nishida
  0 siblings, 1 reply; 12+ messages in thread
From: Kalle Olavi Niemitalo @ 2000-04-29  1:21 UTC (permalink / raw)
  To: guile-emacs

Kalle Olavi Niemitalo <tosi@ee.oulu.fi> writes:

> There is a bug; I now get the following error on startup:
> > No such function: scheme-interaction-mode

Fixed.  See `define-command'.

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

* Re: automating %load-path
  2000-04-29  1:21   ` Kalle Olavi Niemitalo
@ 2000-04-29  1:46     ` Keisuke Nishida
  2000-04-29 11:37       ` Kalle Olavi Niemitalo
  0 siblings, 1 reply; 12+ messages in thread
From: Keisuke Nishida @ 2000-04-29  1:46 UTC (permalink / raw)
  To: guile-emacs

Kalle Olavi Niemitalo <tosi@ees2.oulu.fi> writes:

> > There is a bug; I now get the following error on startup:
> > > No such function: scheme-interaction-mode
> 
> Fixed.  See `define-command'.

What was wrong with the previous definition?  i.e.,
(set-current-module the-root-module)

It worked fine.  Did the latest Guile change the behavior?

I'll resume working on this project in mid May...

-- Kei

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

* Re: automating %load-path
  2000-04-29  1:46     ` Keisuke Nishida
@ 2000-04-29 11:37       ` Kalle Olavi Niemitalo
  2000-04-29 12:27         ` Keisuke Nishida
  0 siblings, 1 reply; 12+ messages in thread
From: Kalle Olavi Niemitalo @ 2000-04-29 11:37 UTC (permalink / raw)
  To: guile-emacs

Keisuke Nishida <kxn30@po.cwru.edu> writes:

> What was wrong with the previous definition?  i.e.,
> (set-current-module the-root-module)

It assumed that the commands had been imported to the root
module.

Before my emacs/init.scm changes, .emacs.scm used to be loaded in
the root module.  When .emacs.scm used modules such as (emacs
guile), the public commands defined there were imported to the
root module and the Lisp side could find them.

Nowadays, .emacs.scm is loaded from emacs/init.scm so the root
module is not current.  If .emacs.scm uses (emacs guile), its
variables get imported to (emacs init).  The Lisp stubs defined
by `define-command' couldn't find them from there.

One could have worked around this problem by making
emacs/init.scm switch to the root module before loading
.emacs.scm.  But I think my solution is better, as it also takes
care of the case where .emacs.scm uses one module which uses
another module where commands are defined.

Now, `define-command' always makes the command available in Lisp,
whether or not anything uses the containing Scheme module.

> It worked fine.  Did the latest Guile change the behavior?

No, it was my fault.

I hope this won't break again when Guile gets its new module
system....

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

* Re: automating %load-path
  2000-04-29 11:37       ` Kalle Olavi Niemitalo
@ 2000-04-29 12:27         ` Keisuke Nishida
  0 siblings, 0 replies; 12+ messages in thread
From: Keisuke Nishida @ 2000-04-29 12:27 UTC (permalink / raw)
  To: guile-emacs

Kalle Olavi Niemitalo <tosi@ees2.oulu.fi> writes:

> Before my emacs/init.scm changes, .emacs.scm used to be loaded in
> the root module.  When .emacs.scm used modules such as (emacs
> guile), the public commands defined there were imported to the
> root module and the Lisp side could find them.
> 
> Nowadays, .emacs.scm is loaded from emacs/init.scm so the root
> module is not current.  If .emacs.scm uses (emacs guile), its
> variables get imported to (emacs init).  The Lisp stubs defined
> by `define-command' couldn't find them from there.
> 
> One could have worked around this problem by making
> emacs/init.scm switch to the root module before loading
> .emacs.scm.  But I think my solution is better, as it also takes
> care of the case where .emacs.scm uses one module which uses
> another module where commands are defined.
> 
> Now, `define-command' always makes the command available in Lisp,
> whether or not anything uses the containing Scheme module.

I see, and I agree with you.  I guess we could define
`lisp-export-environment' for this purpose in the future when
the environment patch is merged into Guile.

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

end of thread, other threads:[~2000-04-29 12:27 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-03-26  8:45 automating %load-path Kalle Olavi Niemitalo
2000-03-26 10:51 ` Keisuke Nishida
2000-03-27  9:08   ` Kalle Olavi Niemitalo
2000-03-27 17:28     ` Keisuke Nishida
2000-03-29  2:33       ` before the 0.3 release (was %load-path) Kalle Olavi Niemitalo
2000-04-09 12:46 ` Makefile preprocessing trouble " Kalle Olavi Niemitalo
2000-04-10  3:47   ` Kalle Olavi Niemitalo
2000-04-14  0:29 ` automating %load-path Kalle Olavi Niemitalo
2000-04-29  1:21   ` Kalle Olavi Niemitalo
2000-04-29  1:46     ` Keisuke Nishida
2000-04-29 11:37       ` Kalle Olavi Niemitalo
2000-04-29 12:27         ` Keisuke Nishida

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).