Re: [Texmacs-dev] Applied patches

[David Allouche]

On Fri, Feb 13, 2004 at 08:06:11PM +0100, Joris van der Hoeven wrote:
> 
> The following patches have been applied on our CVS:
> 
> 2406 (both branches), 2542, 2555, 2560 (plus improvement),
> 2564, 2566, 2577, 2581, 2582, 2610, 2629.

Nice to see that the page-breaking, stacking and float related patches
are all applied. There are still many problems with floats in multicol
text, but at least the basic functionality is fixed.

> Patch 2590 is refused (see previous discussion on this list).
> 
> Patches 2454, 2552, 2573, 2592 and 2607 will be studied
> in more detail later. A few comments:
> 
> 2552: this patch is hard to read for me. Must it be a shell script?

That has to be a modification of build system.

This allows building texmacs with:
  mkdir +build
  cd +build
  ../configure --prefix `dirname $PWD`/+install
  make && make install
which makes it _much_ easier to use tla with the texmacs source code. If
you are interested in the specific problems that fixes, I can give more
detailed explanations.

Incidentally, that make cleaning the source tree trivial (just remove
the +build directory), solving the problem of occasional junk files
slipping in the distribution. The only drawback so far is that texmacs
must be installed to run, that could be fixed by making TEXMACS_PATH and
friends accept a colon-separated list of path, so files could be found
in the build tree as well as in the build tree.

The core of the modification is using the built-in macros @srcdir@ (the
directory where the template file resides, relative to the directory
where configure is run) and @abs_top_srcdir@ (the absolute path of the
configure script) and not the `pwd` hack used previously. Check the
autoconf documentation for details.

This feature is not present in autoconf 2.13, which you seem to be still
using on one of your workstations, and which is the cause that
interesting CVS log message: "???!!!".

> 2573: I am OK with the principle of having different quoting routines.
>   However, this still needs further fine-tuning. I just noticed that
>   wildcards in filenames were erroneously quoted. Maybe the quoting
>   or maybe escaping for sh_quote should rather be done at the level
>   of concretize or url->string conversion instead of a specific
>   routine sh_quote.

I do not know what is the specific problem with url quoting. I guessed
that the quoting was required to escape special shell characters in file
names so they do not get expanded by the sh spawn by the system()
function.

If something more involved is needed, the code could be placed anywhere,
but it must be implemented very carefully.

> 2454, 2607: I really need some time to check these...

You can inspect the full history of those patches in my public tla
archive.

Some changes in the keyboard wildcards patch may not be needed any
longer. For example, the memoization hack may no longer be needed now
that unusued modifiers are dropped before wildcard resolution, but I
left it in because it can only improve responsiveness and not cause any
problem.

A future step in improving the modifiers handling would be sorting
modifiers, so M-A-a would be the same thing as A-M-a. Currently, the
ordering is dependent on the ordering of the xlib modifiers. Actually,
my intuition is that they should not be ordered at all (i.e. a keypress
should be a struct), that would allow substitutions which are not purely
textual (e.g. matching S-A in a S-C-A-x kepress) but that would have
required an even more considerable revision of the wildcard handling
code.

I believe that many users did not complain about wildcard problems, and
especially about the broken variants, because they did not know how it
was supposed to work, but that the problem is nonetheless very common.

The indentation handling patch seems trustworthy to me. I have spent a
lot of time figuring out how the line typesetting works and I am pretty
sure I have not modified the markup semantics which are currently
depended upon in style files

But since it is all but impossible to grep meaningfully in style files
(because most of them use the old output layout with the obnoxious
line-breaking) I was not able to make sure that some obscure macro was
not broken. I did make some grepping though so I have a reasonable
conviction that this is not the case.

-- 
                                                            -- ddaa