headers
Joris van der Hoeven | 1 Nov 2010 21:43

Re: [TeXmacs] Subject: Texmacs 1.0.7.7 crashes in ubuntu 10.10 when trying to draw a picture.

Dear Adrian,

I have been trying to reproduce this bug for a few days,
but I did not succeed yet on my virtual Ubuntu machine.
I installed a fresh Ubuntu 10.10 (32 bits) from the Ubuntu website.
The standard binary package (version 1.0.7.4) provided by Ubuntu works for me,
and so does the static binary version 1.0.7.7 from the TeXmacs website.
The current SVN version compiled from the sources also works for me.
I assume that the TeXmacs version 1.0.7.4 you have tried is the one provided by Ubuntu?
Could you please try the SVN source version of TeXmacs and check whether it works?
If not, then it would be nice to have additional information about your Ubuntu installation.
E.g., did you follow the standard installation procedure? Do you use the 32 bit or
64 bit version? Did you do something special concerning the X setup?

Best wishes, --Joris

On Tue, Oct 26, 2010 at 04:43:41PM -0600, Adrian S. wrote:
> I am using ubuntu 10.10 (Maverick Meerkat) and downloaded the binary
> for Texmacs 1.0.7.7.  When I try to draw o picture or edit one that is
> already drawn, Texmacs crashes and gives me the error
> 
> X Error:  BadPixmap
>  Request Major code 93 ()
>  ResourceID 0x0
>  Error Serial #136392
>  Current Serial #138224
> 
> Any ideas how to solve the problem?  I have used the Texmacs version
> for Maverick (1.0.7.4) without this problem. Any ideas?
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Adrian S. | 2 Nov 2010 01:26
Picon

Re: [TeXmacs] Subject: Texmacs 1.0.7.7 crashes in ubuntu 10.10 when trying to draw a picture.

I think I know what happened:

I booted a live usb and then set-up the binary.  It  worked without
problem, so it had to be something from my configuration.  I removed
the package for texmacs 1.0.6.4 from software center, and then I tried
it.  It crashed again.

After asking which texmacs,

it replied /home/soto/Downloads/TeXmacs-1.0.7.7-static-gnu-linux//bin/texmacs

I noticed the two slashes before bin.  I removed the slash in .bashrc
so it says now
export TEXMACS_PATH=/home/soto/Downloads/TeXmacs-1.0.7.7-static-gnu-linux

instead of
export TEXMACS_PATH=/home/soto/Downloads/TeXmacs-1.0.7.7-static-gnu-linux/

That resolved the issue!!!!
By the way, a long time ago I had the same issue in Solaris, so I
guess the reason was the same....

By the way, why does it take so long for texmacs to start up in 1.0.7.7??

I love the program.  Soon, the math department will switch from
solaris to ubuntu, and now we will be using Texmacs more amongst the
department, I hope.

Thanks!!!
-Adrián.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alvaro Tejero Cantero | 2 Nov 2010 16:00
Picon

[TeXmacs] Bugs?

svn 3522 compiled on Ubuntu Lucid Lynx 64 bit with gcc 4.4.3, guile
1.8.7, Emacs look and feel, all experimental options active.

* I cannot map Meta anymore to my windows key. What is the recommended
way now? Also, 'Meta' does not appear in the minibuffer (entering it
via Esc), only '+'.

* The table shortcut appears in the menus as M+T,N,T
   I only manage to get 'Table command' in the minibuffer using M+t
(lowercase). Further keypresses are just entered i.e. the table is not
inserted.

* The icons for paragraph centering, ragged right, justified, ragged
left are not shown in the menubar (this was already present in
1.0.7.4).

* Hovering on the font submenus of Document or Format causes a silent
false freeze of TeXmacs. It's not evident to me if fonts are being
compiled at that time.

* References to tables and equations don't show automatically resolved
in the docs, maybe they should suffer always an update pass before
being shown?

* when typing an upright operator (e.g. 'erf') in math mode without an
argument, an extra space is present and obvious in the text (this is
not the case if one types an argument, e.g. 'erf x').

* semantic parsing: the parenthesized expression (a+b) is
upward-selectable with Ctrl-Space, but it is not accesible anymore as
(Continue reading)

Permalink | Reply | 12 comments |
headers
Alvaro Tejero Cantero | 2 Nov 2010 16:07
Picon

[TeXmacs] Re: Bugs?

Sorry, this one is bogus:

> * when typing an upright operator (e.g. 'erf') in math mode without an
> argument, an extra space is present and obvious in the text (this is
> not the case if one types an argument, e.g. 'erf x').

the space was residual and could be eliminated by deleting twice.
Permalink | Reply | 0 comments |
headers
Alvaro Tejero Cantero | 2 Nov 2010 17:37
Picon

[TeXmacs] Re: Bugs?

> These are all minor issues, but some of them are annoying. Otherwise
> the experience is quite smooth!

In fact is a bit more complicated for the semantic mode.

* Expressions such as f(x,y) don't allow separate selection of the
argument of the function (e.g. for changing the color)

* and sometimes the new rules disallow selections e.g. in 1/x*y: you
cannot select the product to parenthesize it.
This causes the problem that you cannot first type and then correct
(impossible selections) but rather have to type 'correct' formulas
from the beginning.

It quite changes the way one types expressions and I'd say it will be
a no-go for many people. Is there a workaround that makes everybody
happy?
Permalink | Reply | 7 comments |
headers
Alvaro Tejero Cantero | 2 Nov 2010 17:46
Picon

[TeXmacs] Re: Bugs?

Another problematic case if you do your mathematics interactively (as
opposed to transcribing):

a*b*c

it is impossible to select just two factors to enclose them in parentheses.

-á.

On Tue, Nov 2, 2010 at 17:37, Alvaro Tejero Cantero <alvaro <at> minin.es> wrote:
>> These are all minor issues, but some of them are annoying. Otherwise
>> the experience is quite smooth!
>
> In fact is a bit more complicated for the semantic mode.
>
> * Expressions such as f(x,y) don't allow separate selection of the
> argument of the function (e.g. for changing the color)
>
> * and sometimes the new rules disallow selections e.g. in 1/x*y: you
> cannot select the product to parenthesize it.
> This causes the problem that you cannot first type and then correct
> (impossible selections) but rather have to type 'correct' formulas
> from the beginning.
>
> It quite changes the way one types expressions and I'd say it will be
> a no-go for many people. Is there a workaround that makes everybody
> happy?
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joris van der Hoeven | 2 Nov 2010 18:11

Re: [TeXmacs] Bugs?

Dear Alvaro,

Thanks for your feedback.

On Tue, Nov 02, 2010 at 04:00:15PM +0100, Alvaro Tejero Cantero wrote:
> svn 3522 compiled on Ubuntu Lucid Lynx 64 bit with gcc 4.4.3, guile
> 1.8.7, Emacs look and feel, all experimental options active.
> 
> * I cannot map Meta anymore to my windows key. What is the recommended
> way now? Also, 'Meta' does not appear in the minibuffer (entering it
> via Esc), only '+'.

I just fixed this problem.

> * The table shortcut appears in the menus as M+T,N,T
>    I only manage to get 'Table command' in the minibuffer using M+t
> (lowercase). Further keypresses are just entered i.e. the table is not
> inserted.

Probably fixed as well.

> * The icons for paragraph centering, ragged right, justified, ragged
> left are not shown in the menubar (this was already present in
> 1.0.7.4).

I only observe this in the Qt version and already reported
a similar bug to Massimiliano.

> * Hovering on the font submenus of Document or Format causes a silent
> false freeze of TeXmacs. It's not evident to me if fonts are being
(Continue reading)

Permalink | Reply | 2 comments |
headers
Joris van der Hoeven | 2 Nov 2010 18:27

Re: [TeXmacs] Re: Bugs?

Dear Alvaro,

On Tue, Nov 02, 2010 at 05:37:40PM +0100, Alvaro Tejero Cantero wrote:
> > These are all minor issues, but some of them are annoying. Otherwise
> > the experience is quite smooth!
> 
> In fact is a bit more complicated for the semantic mode.
> 
> * 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)".

> * 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".
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".
(Continue reading)

Permalink | Reply | 5 comments |
headers
Joris van der Hoeven | 2 Nov 2010 18:31

Re: [TeXmacs] Re: Bugs?

On Tue, Nov 02, 2010 at 06:27:57PM +0100, Joris van der Hoeven wrote:
> I am also interested to know whether the "automatic upgrading" options
> work well. I intend to apply all of them by default, except for
> "Insert missing invisible operators", which might be a bit too agressive.

And also the "automatic bracket matching", which should also become the default.
Please let me know if it behaves as expected for the current SVN version.

Best wishes, --Joris
Permalink | Reply | 0 comments |
headers
Alvaro Tejero Cantero | 2 Nov 2010 18:32
Picon

Re: [TeXmacs] Bugs?

Thanks Joris!

>> * semantic parsing: the parenthesized expression (a+b) is
>> upward-selectable with Ctrl-Space, but it is not accesible anymore as
>> a separate entity once one adds a factor of the form: (a+b)*<mathd>x.
>> -- This happens because a space is required after an operator like
>> mathd or upright d. If this is the typographically correct thing to
>> do, then I suggest to include the space in the variants mechanism just
>> after the <mathd>.

> I prefer to be systematic: we also do not insert space after, say, 'sin'.

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.

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.

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.

>> * in the documentation one reads that the upright e,i,pi are entered
>> with variants, but the e,i,p that appear are in uppercase.
>
(Continue reading)

Permalink | Reply | 1 comment |

Gmane