mailing-list for TeXmacs Users

[Henri Lesourd <address@hidden>]

Alvaro Tejero Cantero wrote:

> Hi
>
> Thanks Henri for the detailed (Cartesian reasoning) tutorial!

This is the problem with bugs : if you don't cut them into pieces, step 
by step, and without mercy,
you miss the unexpected things, the things about which in the first 
place you would say that they
are "obviously" not possible. Except the particular case when you are 
able to guess exactly what
happens, these unexpected things are precisely the most important ones : 
they are the things that
you don't know.

> In fact, I almost get what I want now (after editing with emacs the 
> source code for the style file).
>
> But there are two subtle behaviours (bugs?) that still puzzle me:
>
> 1) If I use \bcite to invoke my macro and, by mistake, press return 
> after typing some text as argument, the \bcite macro BREAKS FOREVER!!! 

Yes of course, because when you write :
[[
<bcite|123>
]]

it is not the same as :
[[
<bcite
  123>
]]

the latter is in fact equivalent to :
[[
<bcite|<document|123>>
]]

as you can see above, the real parameter is in fact the markup tree 
'<document|123>', and not just the string "123".
No wonder if the macros that use string processing routines like 
(substring) are broken, then.

But as you can see, the bug is in fact a very small one. Because having :
<bcite   <==>  <bcite|<document|123>>
  123>

is absolutely correct. What is not correct is that when you indent the 
code of the macro, TeXmacs then forces you
into using :
<bcite
  ...>

> Other similar macros go on working, but \bcite complains
>
> <unnamed port>:1:67: In procedure substring in expression (substring s 
> 7 ...):
> <unnamed port>:1:67: Argument 2 out of range: 7
>
> which is the same error I've been having all the time.
>
> More precisely, all instances of \bcite invocation created later than 
> the one with "return" in it are broken, but all the previous remain 
> working. 

I don't have the same behaviour. For example the following markup :
[[
<assign|bcite0|<macro|x|<assign|bibfilename|<find-file|.|/home/henri|<merge|<arg|x>|.txt>>><value|bibfilename>;;<action|
<arg|x>|(with s (get-env "bibfilename")(display* "bname=" (substring s 7 
(string-length s)) "\\n"))>>>

1) <bcite0|test1>

2)

<\bcite0>
 test1
</bcite0>

3) <bcite0|test1>
]]

is displayed as :
[[
1) file:///home/henri/test1.txt;;test1
2)
<error|bad find file>;;test1
3) file:///home/henri/test1.txt;;test1
]]

and I have only the 2nd \bcite broken, as expected ; then, if I 
double-click on "test1" in the
items 1) or 3), it works perfectly (provided that the 
file /home/henri/test1.txt exists) :
[[
bname=<unnamed port>:1:51: In procedure substring in expression 
(substring s 7 ...):
<unnamed port>:1:51: Argument 2 out of range: 7
bname=/home/henri/test1.txt
bname=/home/henri/test1.txt
]]

> 2) I don't really know how to make TeXmacs re-read my style file. Even 
> after restarting it wants to use a previous version of the package 
> file. It's incredible: it doesn't want anymore my macro file, it 
> sticks to a hand-edited one, but not quite the _current one_. It's 
> like if it cached the file somewhat randomly.
>
> When I load the package file back in TeXmacs, it refuses to save (no 
> changes). If I make a tiny change in the package, then it accepts 
> saving, and all changes are taken into account in my files.

There is in effect a cache for styles, in your '~/.TeXmacs/system/cache' 
directory (I think). 'rm -fr ~/.TeXmacs/system/cache/*' should raz the 
cache. If you didn't added anything by hand into
your .TeXmacs, you can even 'rm -fr ~/.TeXmacs'. Next time, it will 
start as if it were the 1st time (and you will have to download again 
the documentation using 'Update from web', and small
things like that. So if it works, the 'rm -fr ~/.TeXmacs/system/cache/*' 
method is better.

There is also the 'Document/Update/All' menu option, which works well. 
It should even work automatically if you open the style file and the 
file itself : as soon as you change (and save) the
style file, the file should be updated.

Don't forget also that the style file should be at the right location : 
in the same directory with the file using it, or either in 
~/.TeXmacs/packages (in this latter case, it is better to use a link
than to put the file itself, in order to avoid to lose it if .TeXmacs is 
destroyed).

> If this is not enough to discourage a would-be package writer, the 
> Remove package option from the menu
>
> (which I wanted to use to refresh the package file TeXmacs is using 
> accordingly to the contents of the one in the disk)
>
> causes a segfault for a rather complex document I'm writing (but it 
> works for small test files.

That should not happen. I use the 1.0.4.5 version, and I never 
encountered this problem. But if you have it on your machine (and if 
your TeXmacs
version is recent, or if you can reproduce this bug on a recent TeXmacs 
version), then you should try to shrink your document step-by-step in order
to build the smallest document that is able to trigger this bug.

> ----Against pretty printing the source of TeXmacs styles (documents?)
>
> Wouldn't it better to turn off the TeXmacs source pretty-printing 
> mechanism (since it breaks more than it helps)? 

How do you edit the macro/style files into TeXmacs, then ?

> It seems reasonable at least for style files, because of the new 'nice 
> graphical' editing mode. 

As far as I know, the style files are just usual TeXmacs files that are 
edited in source mode (Document/View/Edit source tree), and
that have their extension switched to .ts instead of .tm. Is there 
somewhere another 'nice graphical' editing mode that is different from
the source mode ?

> Perhaps the pretty printing could be heuristically applied to only a 
> few tags. Anyway, is there anybody editing TeXmacs files by hand?, is 
> there any reason to keep source pretty-printing? 

Anyway, the bug is not in pretty-printing per se : it is in the 
inputting of macros. As soon as your macro is indented, TeXmacs forces 
you into using
something like :
[[
<bcite
  ...>
]]

instead of :
[[
<bcite|...>
]]

this occurs if you are inputting macros in source mode, but this occurs 
as well when you are in the usual wysiwyg mode.