mailing-list for TeXmacs Users

[Joris van der Hoeven <address@hidden>]

On Wed, Nov 03, 2010 at 01:01:19PM +0100, Alvaro Tejero Cantero wrote:
> > I don't understand. In the SVN version, I manage to select
> > the subexpressions "x", "y", "x,y" and "f(x,y)".
> 
> Yes, but not (x,y), which could be a very long argument that you'd
> like to copy and paste somewhere else, separately from f.

Yes, that might be an option.

> > As a beneficial side-effect, it would become apparent that 1/x*y
> > is parsed as (1/x)*y, since only "1/x" would be selectable and not "x*y".
> 
> The question for the semantic mode is... what is it for?

Trying to guarantee at least syntactic correctness of a document,
in the same way that a spell checker guarantees the existence of
all words in a dictionary (or even grammatic correctness).

Checking some of my existing documents made me discover several typos,
which could have been corrected, so if the semantic mode is not
too much of a burden, then it actually has some immediate advantages.
Not to speak about CAS interfaces.

Of course, there are also several more indirect advantages:
texts become more ssearchable, reusable, and publishers would be
very happy with richer texts.

Apart from that, the semantic mode might also become more efficient
in several respects. Indeed, it makes it possible to operate on formulas
in a reliable way and interact with CAS systems in the background.

Also, if most of the formulas you select are indeed complete subformulas,
then semantic selection will be faster (b.t.w., you may also use
outward selection, C-space).

So there are many potential advantages, and I intend to carefully
investigate whether the semantic mode can be made sufficiently good,
such that some of its less intuitive features are negligible with
respected to the advantages. But this will require a lot of testing.

> do you want to help enter correct expressions for CAS evaluation or do
> you want to 'teach' people what is correct.

No, my intention is definitely not teaching.

> But if the aim is to teach people... well there's going to be a lot of
> frustration. Despite all my dreams of uniformity, semantics and
> parsability, mathematics remains a lot like a 'drawing' and indeed you
> may want to write 1/ x*y with implicit grouping of x*y as denominator,
> e.g. if you're writing 'in line' as opposed to in 'display mode'. Then
> the denominator becomes impossible to select.

You are able to do this by putting invisible parenthesis around x*y
(which should indeed be a simple and well-documented operation).
But: making x*y non selectable by default will hint the user that
this notation is non standard (or at least ambiguous),
so that the formula might actually be misunderstood by readers.
I think that this is useful information, even if it might seem pedantic.

> The answer to the question of the goal also informs the decision
> whether you want to activate the heuristics by default or not. Why run
> any risks changing user documents if the mathematics in them is
> anyways going to remain dead, unevaluated?

The semantic mode does not change any documents. Only the matching
bracket option does (as well as the correcting options, of course).
That is why I ask users to evaluate the matching bracket option separately.
The semantic editing mode will remain optional for a while.

> >> This causes the problem that you cannot first type and then correct
> >> (impossible selections) but rather have to type 'correct' formulas
> >> from the beginning.
> >
> > Yes, probably I should strictly stick to the rule that *any* meaningful
> > subexpression can be selected.
> 
> Please, please, this would help a lot the use of TeXmacs as a
> mathematical scratchpad. This will increase the number of Ctrl-Space
> needed for particular operations, but it is better so. Indeed you
> could think about having "nonsemantic upper selection" and "semantic
> upper selection" and let users map their Ctrl-Space to whatever they
> prefer.

The number of Ctrl-Spaces will probably not increase.
In the formula "a+b+c+d", I was thinking of outward selecting
"a+b-c+d" right after, say "b" (anyway, the decision between "a+b"
and "b-c" would not be clear). On the other hand, you should be
able to select "a+b", "b-c", "a+b-c", "b-c+d" and "a+b-c+d"
using the mouse or S-left, S-right (but not "c+d").

> To me dx looks indeed better without spacing. And yes, it is common
> enough that an exception is in order.

OK.

> >> An idea is that all operators generate (like \sum or \int) their own
> >> scopes and variants were used to put delimiters of different types or
> >> no delimiters at all.
> 
> > This is a bad good idea, because the right hand sides of these scopes
> > have a border with an inside and an outside position. This is acceptable
> > for the exceptional case of big operators, but quickly irritating for
> > more general operators.
> 
> I think the subjective perception of how cumbersome this is may be
> linked to 'how easy is to get out of them from anywhere in the
> argument?'

Not only. As a general rule, invisible borders are confusing,
so one should always try to minimize their usage.
For big sums I do not have an alternative solution,
but for regular operators, we do not really need them.

> My preferred solution to this it to exit innermost environment with
> the Enter key.

That might indeed be a good idea inside mathematical formulas.
And if we want to leave on the left? S-enter?
Notice that this is another example where semantic editing
would probably be more efficient for you.

> This is useful by itself and could also make comfortable enough to use
> invisible delimiters for operators such as sin, <mathd>...

But only intelligible for power users, I fear.

> On sub/superscripts:
> 
> > At the very start of TeXmacs, I experimented
> > markup for subscripts and superscripts with their base and found it
> > less natural than the current solution.
> 
> I don't understand what was the difference. But they are fine now,
> it's only entering multiple indexes that is annoyingly long.

Maybe I should add structured-up and structured-down inside subscripts?

> ',,' indeed is an excellent compromise.

We might also use A-, by the way (or C-, depending on the OS).

> RR for <bbb-R>

This is actually the default behaviour; all bbb-symbols can be entered that 
way.

Best wishes, --Joris