Giacomo Boffi | 10 Apr 12:02 2014

(no subject)

Dear Sirs,

I just realized that TeXmacs is not packaged for

Debian Testing (that is, the distribution I use...)

As Texmacs is packaged for everything else,

from old-stable to experimental, I have to ask,

is this omission an accident or the result of a problem?

In the case of an accidental omission, could you take

actions with Debian maintainers to have it fixed?



Texmacs-dev mailing list
Texmacs-dev <at>
Michael Lachmann | 28 Mar 15:47 2014

problems with self compiled versions after upgrading port on OSX

I had a version of TeXmacs I compiled myself from the SVN archive on OSX.
After upgrading my "ports" version on my mac (port selfupdate; port
upgrade updated) TeXmacs wouldn't run anymore. The problem was that
could not be found. I restored those files from a Time Machine backup,
and all seems to work again.
I know I should have done something so the app does not depend on
those external libraries... but in any case, if someone has the same
problem, this is one solution...

Enrique Perez-Terron | 21 Mar 17:56 2014

Bug & crash report


Perusing the source code, I stumbled upon this:


    roman_nr (int nr) {
      if (nr<0) return "-" * roman_nr(nr);

Should't it rather be:

      if (nr<0) return "-" * roman_nr( - nr);

Similarly, in lines 558 through 560:

    alpha_nr (int nr) {
      if (nr<0) return "-" * alpha_nr(nr);

Shouldn't it be "-nr" for the last occurence of "nr"?

I tested it by typing into a document:

   \number <enter> -1 <right> roman <enter>

Texmacs crashed.

taoluo93 | 11 Mar 17:46 2014

one crash issue

Hi Texmacs Dev Team:
   Thank you for creating this marvelous software. My classmates and I use it to type a wide range of Math assignment. But there is one problem when I tried to insert the miscellaneous symbols, like infinity or empty set. that is when I try to click the icon in the toolbar, the Texmacs crashes each time. Although as an alternative and shortcut, I can insert those infinity symbol by type “ <at> <at> ” or insert empty set by type” <at> \” etc. but this crash still makes me a little uncomfortable.

   My computer is running Win 8.1 OS now. I didn’t encounter this problem when I use Win8 before, so I guess this crash may be related to incompatibility with the new OS. Hope this software will become better 😊.

Have a good day

Texmacs-dev mailing list
Texmacs-dev <at>
François Poulain | 7 Mar 14:10 2014

"executables" and "convertibles" don't work ?

Hi all,

Executables and convertibles commutators don't work any more on my
computer. Am I the only one which experiencing this ?

Try e.g. to copy/paste and play with:

<converter-input|latex|$1 \\over x$|>

<script-input|shell|default|echo test|>



François Poulain <fpoulain <at>>
François Poulain | 30 Jan 17:38 2014

Bad size with image printing


Working on converters, I had some ugly behavior with image rendering.

It appears that, inserting an image into TeXmacs leads, by default to a
bad typesetting because the image is stretched by a factor approx 5/3.

To reproduce it, copy paste :


In typeset_image () in src/Typeset/Concat/concat_active.cpp, I don't
understand the line 318 :
 double pt= ((double) env->dpi*PIXEL) / 72.0;

i)   env->dpi is related to font's DPI and I don't know why should it
     imply image resizing.
ii)  I wonder if magnification should not play a role here. 
iii) I suppose that PIXEL is the ratio tmpt / px.
iv)  If we should translate the size from pixels to tmpt, I wonder why
     the calculus "pt= PIXEL * zoom_factor", following the
     documentation (, is wrong (at least, it gives a
     result very different than the current result).
v)   By the way, current calculus on my computer gives pt= 2133.33,
     (with default DPI= 600 and PIXEL= 256) whereas the "wanted size"
     of the picture is obtained with a pt approx 1280.

Any suggest about this ?


François Poulain <fpoulain <at>>
Miguel de Benito Delgado | 12 Jan 09:58 2014

Re: [TeXmacs] minibuffer support in Qt version

Hi Kostas,

  sorry for the delay and glad to see you’re willing to help out. :)

The problem is that the QTMLineWidget, which implements the line inputs uses Qt standard shortcuts. Basically Joris says that in order to solve this it’s best to ignore TeXmacs' keyboard shortcut system and hardcode a few standard shortcuts for the line inputs in each “look and feel”.

I think this is not such a great idea so he suggests we provide some method for the user to change the shortcuts for those line inputs only. Probably through standard preferences in preferences.scm. 

I think it’d be best if the QTMLineWidget used the current shortcuts (that it can understand) to ensure consistency. This can be done calling (for instance in the widget's constructor) the scheme function kbd-find-rev-binding. To test it, in a scheme session type:

(kbd-find-rev-binding "(kbd-end-line)")

Notice that we use the string representation of the command, as given in the kbd-map. You can see all relevant shortcuts in progs/generic/generic-kbd.scm.

In Qt we need to reimplement the KeyEvent handler in QTMLineWidget and filter those key presses configured for left, right, end, start, etc.

If you finally find time to work on this don't hesitate to ask for help.

Miguel de  Benito.

On Mon, Jan 6, 2014 at 11:58 PM, Kostas Oikonomou <ko <at>> wrote:
Hi Miguel,

Glad to see you're the responsible party :-)

I read the link you sent, and I am willing to help.  (Though my abilities in C++ are limited.) 
As a first step, however, I am not sure exactly what is the solution you and Joris have agreed upon.
Could you please summarize?

I am not cc'ing the list, should I?


On 01/06/2014 13:04, Miguel de Benito Delgado wrote:
Hi Kostas,

  this would be:

and yes, it is assigned to yours truly... Patches are welcome! ;-D

Miguel de  Benito.

On Mon, Jan 6, 2014 at 4:46 PM, Kostas Oikonomou <ko <at>> wrote:

Given that the X version of TeXmacs seems to be on its way out, can someone comment on what it would take to make the minibuffer in the Qt version behave like the minibuffer of the X version?  In particular, to have C-g work, and to have the ability to move around in the minibuffer line, and to edit it?

In my view, minibuffer support is the only significant feature missing from the Qt version for it to be a compete replacement of the X version.


Texmacs-dev mailing list
Texmacs-dev <at>
Michael Lachmann | 10 Jan 12:05 2014

OSX compile

I had some problems with the OSX compile on 10.9 using Xcode 4.3.6
(Apple switched compilers, and lots of things broke.)
compiling when using the configure flag --enable-macosx-distr fails.

One of the errors looks like this:
g++ -ISystem -ISystem/Boot -ISystem/Classes -ISystem/Files -ISystem/Link -ISystem/Misc
-ISystem/Language -IKernel/Abstractions -IKernel/Containers -IKernel/Types -IData/Convert
-IData/Drd -IData/History -IData/Observers -IData/Document -IData/String -IData/Tmfs
-IData/Tree -IScheme -IGraphics/Bitmap_fonts -IGraphics/Fonts -IGraphics/Gui
-IGraphics/Mathematics -IGraphics/Renderer -IGraphics/Handwriting -IGraphics/Types
-IGraphics/Pictures -IGraphics/Spacial -IPlugins -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB
-DQT_SHARED -I/opt/local/share/qt4/mkspecs/macx-g++ -I. -I.
-I/opt/local/Library/Frameworks/QtGui.framework/Versions/4/Headers -I.
-I/opt/local/Library/Frameworks/QtCore.framework/Versions/4/Headers -I/opt/local/include
-F/opt/local/Library/Frameworks -F/opt/local/lib -DQTTEXMACS -Wall -Wno-return-type -O2
-fno-rtti -INONE/include -mmacosx-version-min=10.4 -DMACOSX_DEPLOYMENT_TARGET=10.4 -c
./Plugins/MacOS/HIDRemote.m -o Objects/HIDRemote.o
cc1obj: warning: command line option "-fno-rtti" is valid for C++/ObjC++ but not for ObjC
<built-in>:0: warning: Mac OS X version 10.5 or later is needed for use of the new objc abi
In file included from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:161,
                 from /System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12,
                 from ./Plugins/MacOS/HIDRemote.h:56,
                 from ./Plugins/MacOS/HIDRemote.m:52:
/System/Library/Frameworks/Foundation.framework/Headers/NSUserNotification.h:16: error:
expected ‘,’ or ‘}’ before ‘__attribute__’
make[1]: *** [Objects/HIDRemote.o] Error 1
(the problem only occurs when the -mmacosx-version-min= flag is used)

If you google this type of error, you'll see that many projects encountered the problem.
It could be that updating to a new version of QT will fix the problem.

A fix that worked for me is following:

and adding 
-isysroot /Applications/

to the CXX_FLAGS and BFLAGS.
MacOSX10.7.sdk worked for me for compiling with min version 10.4, but I haven't actually checked the
result on 10.4 -- I don't have earlier versions of the sdk installed on my system. I'm also not sure that the
path to the sdk
will always be the same - on my system it is in the Xcode app, but the web site above had it in 

So, I'm not sure what is the best way to fix the configure script.
But, using this change, 
configure --enable-macosx-distr   --enable-macosx-extensions --enable-qtpipes --enable-pdf-renderer
finished successfully.

Here's a diff of my configure script:
Index: configure
--- configure	(revision 8129)
+++ configure	(working copy)
 <at>  <at>  -7666,8 +7666,8  <at>  <at> 

 if test "$enable_macosx_distr" != "no" ; then
-mmacosx-version-min=10.4 -DMACOSX_DEPLOYMENT_TARGET=10.4"
-mmacosx-version-min=10.4 -DMACOSX_DEPLOYMENT_TARGET=10.4"
     if test "$enable_macosx_distr" != "yes" -a "$enable_macosx_distr" != "" ; then
   	    { $as_echo "$as_me:${as_lineno-$LINENO}: result: enabling Mac OSX distribution for architecture
$enable_macosx_distr" >&5

Michael Lachmann | 10 Jan 00:07 2014

DYLD_LIBRARY_PATH for sessions


(Just for background: I just compiled the latest version from the svn for OSX 10.9
I used:
configure --enable-macosx-distr   --enable-macosx-extensions --enable-qtpipes --enable-pdf-renderer --disable-macosx-distr
The --disable-macosx-distr was because otherwise the minimum version would be required to be 10.4, which doesn't compile on 10.9, or my Xcode)

In this version, starting an R session gives the following error:
dyld: lazy symbol binding failed: Symbol not found: _iconv_open  Referenced from: /Library/Frameworks/R.framework/Resources/lib/x86_64/libR.dylib
The reason, I think, is that R calls libiconv.2.dylib which now is also used and included in the TeXmacs app.
And, the TeXmacs version is incompatible with the R one. When TeXmacs starts, it sets DYLD_LIBRARY_PATH to the libraries used in TeXmacs, and when R is started, it tries to load its libs from there.

A simple solution is to call
unsetenv( "DYLD_LIBRARY_PATH") ;

inside the program that starts the R session (tm_r.c).
But this seems a hack (for example because maybe I need to also change other PATHs that I still don't know about...) . What would be the right way to do things? Who is responsible for environment variables inside sessions?


Texmacs-dev mailing list
Texmacs-dev <at>
Michael Lachmann | 5 Jan 00:57 2014

Windows compile

I'm trying to compile the latest svn on windows following
compile fails complaining about FreeType fonts.
configure:7752: error: cannot find FreeType or your version is < 2.4.8.
If you have several versions installed please use the proper freetype-config script to set
the environment variables FREETYPE_CFLAGS and FREETYPE_LDFLAGS.
Attached is config.log
I'm doing this because I'd like to try to make the R interface work on windows, too. Though I've no idea what I'm doing. So if anyone has a hint, that would be great, too.


Attachment (config.log.gz): application/x-gzip, 11 KiB
Texmacs-dev mailing list
Texmacs-dev <at>
Michael Lachmann | 4 Jan 02:40 2014

menu updates?

The R plugin has a command for updating the top menu of TeXmacs, the R menu,
with entries for each library installed in R.
This used to work using the command t.update.menus()
which builds the menus and sends them to TeXmacs,
something like 
\2(command:(menu-bind ….)\5

I just tried it on a freshly compiled svn copy, and the menu doesn't seem to update.
Am I doing something wrong? Has something changed?


Texmacs-dev mailing list
Texmacs-dev <at>