Chronological Thread 

< Chronological >      < Thread >

---

On Wed, Aug 20, 2003 at 07:05:34AM +0200, Norbert Nemec wrote:
> Am Dienstag, 19. August 2003 17:05 schrieb David Allouche:
> > 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?
>
> Something like a thin, dotted rectangle? Maybe even gray, as far as colors
> are
> possible?

Sound like a good idea. And not too difficult to draw :-)

I have put in in my (hopelessly overfull) todo list.


> > > 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 real question is:
>
> * Should the size of an automatic right delimiter be dependant on
> its adjacent indices? Should this happen generally? Only for
> vertical bars? Or by some optional switch?
> or:
> * Should the substitution-operator be a postfix-big-operator,
> conceptually distinct from from a vertical-bar-right-delimiter big
> enough for indices and behaving similar to the prefix-big-operators?
>
> I have the feeling the second is overkill that won't be correctly
> understood by most users.

I feel the TeXmacs Way is the second solution. But you are right in
pointing that is probably too subtle a distinction and that most users
will not get it.


> The first, though, will probably only shift the problem to other cases that
> will suddenly look strange.

Agreed.

Yet the "optional switch" solution is appealing to me, which can be
implemented just in the same way as the "postfix operator" solution...


> Therefore, I would suggest leaving it as it is for the moment and document
> the
> trick somewhere. (Is there a section "assorted bits'n'pieces"?...)

If I understand correctly, no _completely satisfying_ solution has
been found, since the delimiter do not extend to span its index and
exponent.

I dunno about the state of the documentation...


> When it comes to semantics, the correct thing to do in the long run would
> be,
> to have opening and closing delimiter as parts of one entity containing
> everything in between. The menu would then not contain single delimiters at
> all, but a selection of common pairs (matching delimiters and pairs like
> "left-invisible-delimiter <-> right-bar-delimiter") and an additional
> option
> of custom-made-pairs. Typing a single opening delimiter would then
> automatically create a matched pair, which should be correct behaviour in
> 99.9% of the cases. Of course, that's a major change - no idea whether it
> would be worth the hassle?

This has been discussed several times. In a nutshell:

-- Glued delimiters (and other related structures) are better from a
structural standpoint, make conversions easier and help solve a
number of corner cases (like the substitution operator).

-- Independent delimiters yield a more intuitive editor behaviour
and are good enough 90-100% of the time (depending on your
field). It is often useful to cut and paste parts of a
mathematical expression which are not entire logical entities.

So my current policy is:

-- Keep using independent delimiters.

-- Consider implementing converters between the two formats (this
might have to be done come in the road to MathML anyway).

-- Annoy Joris to have him fix the "indices on a macro" bug.

Since you seem to have a pretty clear view of this specific problem
(clearer than mine), I would appreciate if you could synthetize this
discussion in the form "1. Perceived problem. 2. Proposed solution".

Thanks for your help.
--
-- 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.