mailing-list for TeXmacs Users

[Miguel de Benito Delgado <address@hidden>]

On Mon, Oct 29, 2012 at 2:41 PM, Michael Lachmann <address@hidden> wrote:
> Thanks for the answers!

Gerne.

> When I tried fixed(0)->accessible(0)
> TeXmacs crashed before opening the first window...

?? Weird.

> Ok, I started using <next-line> ;)

Deprecated as well... :(

> But I would much prefer if <\around> would allow line breaks.... I
> haven't figured out how to do that.

I don't know, it's surely an easy thing once you know how to do it... ;)

>> A last comment: if you match brackets using <around>, you'll have to
>> rewrite the procedures to convert from and to code snippets to
>> correctly copy and paste inside code fragments, code files and
>> sessions.
>
> I'm not sure I fully understand what you mean... Do you mean that when
> I copy and paste as verbatim, for example,
> <next-line> is not converted to \n ? That should be easy...
> Or do you mean that once I use <\around> then copying code snipplets
> is a bit of a pain, because I can only select the whole <\around>, not
> parts of it?  I'll have to start using it to see how much I hate it.

I meant that in order to properly support all the "copy to", "paste
from" commands you'll have to write procedures to sometimes edit the
<around> tags away when copying or add them whenever necessary while
pasting.

Take for instance "copy to verbatim", that should work more or less
out of the box, but "paste from verbatim" should be the inverse
function, i.e. around tags should be added.

Look for clipboard-* procedures and their related c++ functions. I
think you need to define a new format / edit one present with
define-format, but I'm not sure right now. In order to isolate and
test your changes, you could define a format "R-code" following some
example, then write those routines and also make your kbd-maps be
active only when editing something in this format (I think the
predicates "in-something?" are automagically built using macros out of
the defined formats so you won't find their definitions easily, but
again, I haven't checked (sorry!))

>> The <nobracket>'s appearing when brackets don't match might
>> also be replaced by some better visual cue.
>
> Yes. I wonder what I should use. It seems in math nothing is displayed....
> Another option I thought about was that if you delete a bracket, then
> the <\around| ( | "body" | ) > would be replaced by just "body".

But then you loose both brackets, and that's not what one would
expect. However if you leave the other bracket in place when the user
deletes one, when he re-inputs it you can do some basic bracket
matching (i.e. look for the first/previous n-th bracket, etc.) then
insert an <around>. I think this would also solve the problem with the
input of just one bracket, i.e. only inserting the <around> tag when
the user closes the brackets.

An afterthought: things could get tricky inserting tags, which leads
me to wonder if <around> is the best solution... An alternative, if
you expect the code snippets to be relatively small (a few tens of
lines) is to define a packrat grammar. This works very nicely and
gives you pretty and configurable syntax highlighting. But it's not
intended for live editing, i.e. it's very slow. For a few lines it's
ok, but it quickly becomes noticeable (I tried with the scheme
language and editing source files was impossibly slow). Hmm, maybe
it's not such a good idea.

Best,
________________
Miguel de  Benito.