Re: [Texmacs-dev] Patch TeXmacs-1.0.0.11-da1

[Joris van der Hoeven]

> I have been away a for quite some time, now here come the release of
> my works during that duration. That is one big patch, mainly related
> to menu capitalization and check-marking, and a bunch of proposals.
> 
> The patch is downloadable at:
> 
>     http://ddaa10.free.fr/texmacs/patch/1.0.0.11/TeXmacs-1.0.0.11-da1.patch.gz

I incorporated half of the patch in the new distribution:
the new menus are incorporated, but not menu.scm.
Even though menu.scm seems to be good enough to be included,
I postpone this change to the moment when the entire guile/scheme
interface will be reorganized. Indeed, before that others will
contribute more important parts of scheme code, I would like to
set up some general coding guidelines, about which more soon.

> I changed the previous convention for multiple-choice list with
> default values, mostly document settings. Before, only one item
> (including the Default) was checkmarked with "o". So, when the default
> value was selected, the user could not see what was the default
> value... The new convention is to have the Default item marked with
> "v" when appropriate, and always have the menu item associated to the
> current value marked with "o" even if it is the default value. That
> way it is easy to know what is the current value in all cases and the
> user still know if it is the inherited default or a local value.

I will adopt this, but rather mark "Default" with * (this is what has
been selected) and the corresponding choice with o (for information).

> The use of implicit checkmarking has been generalized using GUILE's
> procedure properties.

This is indeed very good and part of a far more general scheme that
I plan to adopt since a while. More about that later.

> Fixed long lasting bug of init-page-margins. Incidentally added GUILE
> functions to perform length arithmetic.

I will look at that later.

> Added support for several new types in glue.cc for length arithmetic
> and menu generation.

As to setting and getting properties of views and windows,
this will have to be done in a more uniform way:
have a hashmap associated to each view, window (buffer?) and
possibly (user modifyable) callbacks for some variables.

> Fixed some typos related to BOT_MARGIN and PAGE_EXTEND in
> env_default.cc and env_semantics.cc.

I will look at this later.

> Changed some unecessary friend declarations into regular function
> declarations. This is part of a medium-term plan to change the
> refcounting system.

I will look at this later too.

> Probably some other fixes which got lost in the crowd.

Yes, and that is a problem: if you send me/us patches which contain too
many things, then it is *very hard* for me to check and integrate them;
it took me almost half a day for only a part of your patch.

You should make it a general habit to construct independent patches
for independent changes and decompose big changes is smaller parts.
Otherwise, I am obliged to break the parts up myself, without having
understood all of the code and without being sure that nothing
important has been left out. It also slows down the incorporation
of patches in new distributions, which may oblige you to sync
the patch with newer versions. All this wastes our time.

In order words: please keep patches as small as possible.