First login?
Lost password?
 
 
 
mailing-list for TeXmacs Users

Text archives Help


Re: [TeXmacs] Re: Bugs?


Chronological Thread 
  • From: Alvaro Tejero Cantero <address@hidden>
  • To: address@hidden
  • Subject: Re: [TeXmacs] Re: Bugs?
  • Date: Wed, 3 Nov 2010 13:01:19 +0100
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=KHwNe91OG6yH8/tueCgv/Tux721MM35P6rWh6ST7Kosj6FpXjohRZZjDDkV/dMuFuf vrggo0+dTQCYAjuHbkEiHGodKuQ6K/YDEYhzN9ZB83bspw0MV+8x4Ro9Li5ID3KNejXb yJ35mWulYLI3UBqp2ChER1bq5VfVBALnTKxXw=
I will consolidate in this e-mail all the comments about the
selectability of subexpressions and move the other issues to separate
e-mails.

>> * Expressions such as f(x,y) don't allow separate selection of the
>> argument of the function (e.g. for changing the color)
>
> 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.

>> * and sometimes the new rules disallow selections e.g. in 1/x*y:
>> you cannot select the product to parenthesize it.
>
> It is not clear to me yet if it is more natural to select operators
> together with their arguments or not. This can be easily changed though.

> On the other hand, you are *not* allowed to select "x*" or even "x*y",
> but only full subexpressions (indeed, 1/x*y is traditionally
> parsed as (1/x)*y).
>
> In fact, even in x*y*z, it is not possible to select "x*y",
> because associative operators select all their arguments at once.
> This decision may be more controversal. With some effort,
> it would be possible to select both "x*y" and "y*z".

This would be definitely better.

> 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?

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

If the aim is CAS input, I would suggest to leave it activated by
default only on CAS input fields or to activate it (+ the correcting
heuristics) whenever a math environment is selected for evaluation.
Then you have the red boxes as nice unobstrusive feedback and you're
willing to satisfy the parser because you're going to get an immediate
benefit (=evaluation will be possible).

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.

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?

>> 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.

It is becoming very nearly perfect with that, and the new fast
selections allowed by the semantic mode really contribute in that
direction.

On the <mathd> issue:

>> I think in this case practicality beats purity, because the variants
>> are a fast access mechanism and, in fact, they are not a possibility
>> for entering sin. Furthermore, one may want to type sin(a+b) but the
>> overwhelming majority of uses of <mathd> are with a single character
>> as argument.

> Yes, maybe I should make an exception for <mathd>,
> or simply consider it as a prefix which does not require any space.

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


On scopes for operators

>> 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?' This is difficult in TeXmacs because the key that does it,
i.e. right arrow is a) small and b) very far from the home row c)
reached by the pinky (weakest finger) and d) not predictably placed
(i.e. different relative position on full keyboards, laptop keyboards,
etc.

My preferred solution to this it to exit innermost environment with
the Enter key. I do already this in mathematics and I would find it
also helpful i.e. to get out of parentheses in text or to get out of a
paragraph (Enter outside of paragraph would then insert newline).

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


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.

>> Another context where a faster solution would be very welcome is the
>> subindexes (currently ', TAB TAB'). It might be a macro that maps * or
>> an accesible key to invisible , when the cursor is in a sub/super
>> index.

> I am reluctant to make important keys behave in a special way inside
> scripts,
> but agree that ', tab tab' might be too long. I am not sure whether decimal
> commas are used more or less often than invisible commas; ', tab' should
> be an acceptable solution. Maybe ', ,'; I don't know.

',,' indeed is an excellent compromise. I use '- -' for unary minus
<um> or RR for <bbb-R> (the Reals) and am very satisfied with these
fast shortcuts. It is very seldom that you want to enter 2 commas in a
row and you can enter one, space, delete, enter another or create a
macro for that.

I am sending a separate mail about brackets.

Álvaro.

Archive powered by MHonArc 2.6.19.

Top of page