mailing-list for TeXmacs Users

Text archives Help


Re: [TeXmacs] Help on action


Chronological Thread 
  • From: Henri Lesourd <address@hidden>
  • To: Alvaro Tejero Cantero <address@hidden>
  • Cc: address@hidden
  • Subject: Re: [TeXmacs] Help on action
  • Date: Sat, 29 Jan 2005 14:36:49 +0100



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.




Archive powered by MHonArc 2.6.19.

Top of page