Chronological Thread 

< Chronological >      < Thread >

---

On Tue, Aug 19, 2003 at 03:31:01PM +0200, Norbert Nemec wrote:
> Am Dienstag, 19. August 2003 11:43 schrieb David Allouche:
> > By the way, I think the correct name is not "large space" but
> > "invisible large operator" because it is not supposed to insert any
> > visible space, just modify the rendering of delimiters and so on.
>
> perhaps, the menu-button should look a little more informative, maybe
> giving
> that name in the hint?

Having such a long name in a symbol menu would be ugly. But then, it
should indeed be visible. Maybe some icon meaning "invisible"... Any
idea of a picture conveying the idea of something that is invisible
but meaningful?

> > Indeed... it seems the invisible large operator does it. I remember
> > for some reason I deemed this solution unsatisfactory, but I really
> > cannot remember why.
>
> Well - it is a dirty hack far from any sematic meaning of the bar-symbol.
> Anyway, I have no idea what a cleaner solution might look like.

That is an interesting topic of discussion...

The simple answer would is "yes, this is maybe ugly, use a macro to
encapsulate the ugliness and exhibit the structure".

A more complete answer requires a discussion of the structural
semantics of the bar-symbol. To be structurally correct, we need some
way to mark the start of the expression on which the variable
substitution applies. It may be argued that the invisible big operator
does exactly this.

Personally, I would rather feel like using the invisible left
delimiter and the bar right delimiter. However this would render as a
too small bar when the content is simple. This "small bracket"
behavior is correct when the delimiter are parenthesis-like.

Since the variable-substitution operator cannot be treated as a
bracket pair, one might argue it makes sense to consider it as a
postfix big operator (as opposed to Sum, Integral, Product, etc. which
are prefix operators). There is currently no way to express this in
TeXmacs, but using the invisible big operator and a visible right
delimiter is the closest match available.

Some time ago Joris mentioned the plan to redesign the big operator
handling to give operators an explicit range. These problems should be
given some serious thought when this happens.

--
-- ddaa

---

• Integralsign?, Marten Bauer, 08/13/2003
  • Re: Integralsign?, David Allouche, 08/18/2003
    • Re: Integralsign?, Norbert Nemec, 08/19/2003
      • Re: Integralsign?, David Allouche, 08/19/2003
        • Message not available
          • Re: Integralsign?, David Allouche, 08/19/2003
            • Re: Integralsign?, Norbert Nemec, 08/20/2003
              • Re: Integralsign?, David Allouche, 08/21/2003

---

Archive powered by MHonArc 2.6.19.