First login?
Lost password?
 
 
 
mailing-list for TeXmacs Users

Text archives Help


Re: TeXmacs UI issues (was: Re: [TeXmacs] Fundraising)


Chronological Thread 
  • From: Henri Lesourd <address@hidden>
  • To: Yin Wang <address@hidden>
  • Cc: address@hidden
  • Subject: Re: TeXmacs UI issues (was: Re: [TeXmacs] Fundraising)
  • Date: Fri, 28 Apr 2006 14:52:48 +0200
Yin Wang wrote:

On 4/28/06, Henri Lesourd <address@hidden> wrote:

David MENTRE wrote:


Henri Lesourd <address@hidden> writes:




lot of annoying details plague the life of users. As far
as the users I know react, the main problems (stated using
an approximate order of importance) are :



Number one for me:

* slowness of TeXmacs, the interface is not reactive enough, especially
compared to Emacs.




Argh ;-) !!! This improvement is hard, and even impossible to
do --stricto sensu--, because TeXmacs does (and will always do)
much more calculations than emacs...

This is really the kind of area where *some* improvements can
be expected, and where an increase in the speed of machines
should do the rest !


I think for most users, Emacs like functions such as "C-h c" and "C-h
w" is of most importance, since they enables the users to get
immediate help on "what key is for the purpose of...", and "What's the
function of this hotkey?". And I didn't find anything about changing
keybindings in TeXmacs.


There is something like that in TeXmacs, but it's not as sophisticated
as in Emacs. In particular, we would need to annotate all the functions
of the library, to be able to have a good apropos.

Lots of things are hardcoded. For example, the font "fireflysung". It
takes too much to add a new font to TeXmacs.


True.

I guess there is something fatal in Guile. Scheme is clean, but it
lacks too many features of elisp and common lisp that will make the
user comfortable. Even with librep, users can use "describe" and
"apropos" to know "what is what", that's implemented by all
implementations of Common Lisp and librep, but I found this function
is not present in Guile.

Maybe Scheme is a bad choice. The purpose of it is for education. I
see the Scheme community is confused with different standardization
problems.

Most of the things you need are standardized as Scheme SRFIs. It is
true that some things are currently missing, like a good support for
multithreading, for example. It is also true that the Guile implementation
of Scheme we use in TeXmacs is interpreted, therefore it is much slower
than compiled Common Lisp code.

But as far as being easily accessible for new users, Scheme is good,
because the amount of things to know is **much** smaller than all the
uberredundant things you have in Common Lisp.

Indeed, Common Lisp itself is not devoid of standardization problems.
For example, tell me about a portable way to get the pid of the current
process (this is just an example among others) :

-> CMUCL : (unix:unix-getpid) ;
-> Allegro : (excl::getpid) ;
-> Some other Lisps : (getpid) ;

Another well-known example of such problems is all the mess with programming
the reader. Also, the semantics of Lisp, with (for example) its two different
kinds of values for symbols (functional, and data), is also an endless source
of confusing problems, etc.

I would rather say that for some reason, all the Lisp-like languages
seem to have failed in achieving a complete standardization. In this
respect, although quite imcomplete, the Scheme approach seems a step
in the right direction.

But why not Common Lisp? We don't like a thousand different
interface with things like hash tables...


Another problem with Common Lisp is that it is really heavywheight.
As far as a good embedded scripting language, Scheme is much more
appropriate.

The problems you raise are real, indeed, but it seems to me that
they are rather linked to a lack of documentation and standardization
in the TeXmacs API. Therefore, it seems rather likely that we could
solve this problem by improving things small step after small step,
without upsetting everything.

Comparing SCWM--the Scheme Contraint Window Manager and Sawfish, you
can find this problem. Scheme is not really for use in a real world.
We don't want to implement another Common Lisp with Scheme again.


Here, we (could :-) go into the debate of Scheme vs. Common Lisp. I would
just say that the philosophy of using Scheme inside TeXmacs is rather, in
any case, to **avoid** implement another Common Lisp : namely, the set of
Scheme functions which are provided to the user is definitely intended to
remain small.


Archive powered by MHonArc 2.6.19.

Top of page