texmacs-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Texmacs-dev] Some thoughts about the redesign of the Guile interface


From: Joris van der Hoeven
Subject: [Texmacs-dev] Some thoughts about the redesign of the Guile interface
Date: Thu, 6 Feb 2003 10:55:08 +0100 (MET)

Local scoping
-------------

As a general rule, the code has to be reorganized in such a way
to use local scoping whenever possible (always). This occurs at
two important places:

1) Menu and keyboard actions, dispatchers
   Currently, most actions are stored as unevaluated expressions,
   which are evaluated using 'eval' whenever needed.
   If we want to use the Guile/Scheme module system,
   it will be important to construct the closures of
   all actions at the time that they are being defined.
   Otherwise, certain actions will not be evaluated using
   the right context.

2) Implicit environment information.
   In order to avoid subtle bugs and make everything thread-safe,
   it will be good to let all TeXmacs commands which use implicit
   environment information (like the current window or cursor position)
   depend explicitly on an environment. As David has pointed out before,
   this can be done using a clever use of macros.
   However, this also requires many changes in the C++ code.

Debugging facilities
--------------------

It becomes quite urgent to have better debugging facilities
for Guile/Scheme programs. The problem is that I did not
manage to find in the docs how to retrieve the file name and
line number where an error occurred. Someone has an idea?

More generally, it would be good if we could automatically
retrieve the file name(s) and line number(s) of a piece of code.
This would allow us to create hyperlinks to the definitions
of functions in the online documentation.

Function properties
-------------------

It will be convenient to associate properties to functions
inside their body. This is useful for documentation purposes,
associating types to functions (for interfaces with other systems),
for setting editor properties (interactive arguments, checkmarks),
and for the relation with the DRD system.

Unfortunately, scheme only allows us to specify help strings
in function bodies. We may either create new macros for defining
functions, or hack the 'define' macro, or hack the ways files
are loaded. Probably macros for function and macro definitions
are the cleanest solution.

Proposal
--------

In the future, we will use the scheme module system in order to
prevent name clashes and improve the debugging tools. We will define
a few powerful macros for TeXmacs-specific language extensions and
provide a corresponding syntax highlighting and automatic indentation
file for emacs.

Here are some of the keywords I am thinking of:

  tm-define             define a function or symbol
  tm-command            define a function with an implicit environment
  tm-macro              define a macro
  tm-menu               define a menu
  tm-keymap             define or extend a keymap

The will also be several keywords related to the DRD extension and
pattern matching, but more on this later.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]