Skip to Content.
Sympa Menu

texmacs-users - Re: [TeXmacs] Cancellation of terms

Subject: mailing-list for TeXmacs Users

List archive

Re: [TeXmacs] Cancellation of terms


Chronological Thread 
  • From: Miguel de Benito Delgado <address@hidden>
  • To: "address@hidden" <address@hidden>
  • Subject: Re: [TeXmacs] Cancellation of terms
  • Date: Fri, 20 Mar 2015 19:19:25 +0100

Awesome!

I really like not having to hardcode more stuff.

What about using text-at to place the superindex as well? It should be a matter of adding a second argument to the macros and resizing the drawing area (using phantom and rsup?)

On the other hand, won't draw-over have performance issues?

--
Miguel de  Benito.

On Fri, Mar 20, 2015 at 5:06 PM, Sam Liddicott <address@hidden> wrote:
I should explain; <phantom|<arg|text>> makes the graphics area big enough for the text - which was a problem I had on mine. Combined with your draw-over we now have a graphics whose width and height are equal to the box, thus we know the size of the box.

Were did you learn draw-over?

Sam

On Fri, Mar 20, 2015 at 4:04 PM, Sam Liddicott <address@hidden> wrote:
That's great. I never knew about draw-over.

Some more tips: to make it so you can type-in a draw-over you need to do 2 things.

1. get rid if the <if> clause containing the x argument, or the x won't be editable = I use compound for this and let the if clause help compute the compund name
2. don't have the text as the first argment to draw-over... because it still won't be editable

Instead let the <if> work out a macro name to use with <compound>
e.g. see the new draw-over-editable function and the new slash definition that uses it in the attached file.

You can now type:

\slash ENTER hello
and watch the word build up as the slash changes angle.

NOTE in the new draw-over-editable function that the text-at vertical position is a bit hackey, -0.17gh is a silly vertical position, there must be a better way than having to do that...

Sam


On Fri, Mar 20, 2015 at 3:30 PM, Martial Tarizzo <address@hidden> wrote:
Following the idea of Nicola Mingotti, I wrote 4 macros, which work
reasonably well (to put the symbol at the end of the arrow, I use a
'move'... not so good. It is still the same problem : size of the box ?)

see attached files.

Martial


Le vendredi 20 mars 2015 à 12:26 +0000, Sam Liddicott a écrit :
> I attach my best attempt.
>
>
> The problem is as you indicate, Miguel, that box length units are not
> available, so in this case I have hard wired to 1ex, 1fn just to show.
>
>
> Perhaps we need a width & height function that text or part of the
> tree can be passed to?
>
>
> Or maybe the repeat function should also set the box units, so that we
> can have a gr-geometry tuple set to 1w 1h in a repeat box, guaranteed
> to repeat only once but fill the whole block?
> then we can have <repeat|x|<with|gr-frame|<tuple|scale|1gw|<tuple|0gw|
> 1gh>>|gr-geometry|<tuple|geometry|1w|1h|center>|<line|<point|
> 0|-1>|<point|1|0>>>>
>
>
> I prefer that option. On the other hand, that is how datoms ought to
> be working, why can't datoms provide those values?
>
>
> Sam
>
>
>
>
>
> On Thu, Mar 19, 2015 at 11:17 PM, Miguel de Benito Delgado
> <address@hidden> wrote:
>         I've actually wanted this for some time and never found the
>         motivation to try it.
>
>         On Wed, Mar 18, 2015 at 5:34 PM, Martial Tarizzo
>         <address@hidden> wrote:
>                 It would be great to compute these coordinates (i.e
>                 the position, width
>                 and height of the box), but I didn't find a way to get
>                 them .
>
>         AFAIK box length units like "1l", "1w" are only available
>         within some specific macros like resize, move, etc. Search the
>         doc for more info.
>
>
>         I see three possible venues for implementing this:
>
>
>         1. Try something with virtual fonts. Some single characters
>         are indeed negated this way, but I wouldn't know how to extend
>         this to arbitrary content. Come to think of it, it doesn't
>         make much sense.
>
>
>         2. Try to coerce the box dimensions of the content to be
>         cancelled out of the macros I mentioned above, somehow storing
>         its value for later use. Out of the top of my head I don't see
>         how this would work, though.
>
>
>         3. Implement a new wide_box in C++ (see e.g. wide_bar_box,
>         wide_vect_box, etc.) I've attached a proof-of-concept patch
>         for those willing to hack around a bit. Apply it and then,
>         with some selection made in your document, run the scheme
>         command (make-wide "<cancelled>"), e.g. by clicking
>         Tools->Execute->Evaluate scheme _expression_
>
>
>         If someone finds the time to properly adjust the margins, and
>         this turns out to be the best solution we can think of
>         committing it. Of course, the other cancellations would be
>         cool as well, or maybe a more general mechanism which would
>         allow for easy user customization (different/multiple arrows,
>         etc.). Replacement of the super/lower indices would be nice
>         too...
>
>
>         But it's late...
>
>
>         Best,
>         --
>         Miguel de  Benito.
>
>







Archive powered by MHonArc 2.6.19.

Top of Page