Mogan 1.1.0: the faster GNU TeXmacs

#1

Two major changes:

  • Fixed a lot of BibTeX related bugs
  • Support Unicode for TM format, say goodbye to cork encoding
7 Likes
#2

I am very curious on the performance benefits of using real Unicode instead of cork, and will it be upstreamed?

#3

No much. It is on upstream for a long time. But GNU TeXmacs 2.1.3 has not been released.

#4

It would be nice if you could include an appimage for those of us on Linux.

#5

Not so hard to build Mogan because Mogan does not depends on GNU Guile.

As there are limits on Appimage, I will not provide AppImage for Mogan.

#6

Thanks for your response. I just don’t like building stuff. It requires too much mental effort to figure out what’s wrong when the build fails. For instance, I’ve manager managed to build texmacs from source as it always fails at one point.

#7

Well, for a non-developer user, using GNU TeXmacs on Windows or on macOS is a better idea.

Otherwise, you have to make your hands dirty. To take advantage of GNU/Linux, one has to learn about programming.

#8

If you are using Ubuntu, here is a detailed compile guide by CI:

Just install the dependencies hinted in CI, and then

packages/debian/package.sh

and then use dpkg to install the deb packages.

TeXmacs s7 Windows build with msys64
#9

I do not know if that is the official position of the developer’s team. This said, I completely disagree with it. Its consequence is that many people will keep away from TeXmacs; I think that, on the opposite, TeXmacs will benefit from having users in the Linux OS.
I think that a potential consequence of having Linux users will also be that some new developers will come forward.

#10

That’s a condescending way to talk. What has programming got to do with linux or building from source? Unlike you, I don’t have a fetish for building from source.

#11

I do not think it is condescending, but I do think that a different approach would benefit TeXmacs more.

#12

It is not an opinion. I’m just trying to show a fact as a Linux user.

Otherwise, you have to make your hands dirty. To take advantage of GNU/Linux, one has to learn about programming.

Have to does not mean you should. It is a compromise of the reality.

And, I’m trying my best to bring GNU TeXmacs back to Debian. And I think AppImage is not a good solution.

2 Likes
#13

On Linux, building from source is much more easier than Windows in general.

I also do not have a fetish for building from source. I’m a human being, not a coding machine.

DO NOT JUDGE!

#14

Well, could you tell me which Operating System you are using?

I’d like to help you build it if you want to try Mogan. Especially for Debian and Debian derivatives, because I’m using it.

If you are using OpenSUSE, here is a packaged one of Mogan:

https://software.opensuse.org/download/package?package=Mogan&project=home%3Aiphelf

#15

I’m on endevouros. Besides, how did you interprete my statement as me judging you. I simply avoid building anything that is not trivial from source because (1) it takes too long (2) it spins my laptop fans (3) most of the time you have to read a lot of things to set up the build process correctly (4) when something fails, it can take hours to fix (if you can fix).

#16

I do think this is as important as having a well-written software (which is already true) and would deserve full attention from all the developers (so , let me add the handles @vdhoeven and @mgubi).
One potential good consequence of letting Linux users install easily TeXmacs could be to have more developers.

#17

Of course, there is not one single Linux. The distro landscape is very fragmented, meaning a non-negligible amount of effort is required from developers to produce various packages.

One way in which the current situation could be improved is by better focusing our efforts. There are the official builds on the website, the ones provided by @pjoyez and I have my own repository for Fedora. The builds on the website seem to regularly break and get outdated. Using the official static builds is cumbersome compared to AppImages. My feeling is the website should just point to @pjoyez’s repository. I would be happy to help maintain it, if this could be useful.

It would be great if we could reduce the workload by targeting solutions like AppImage, Flatpak and Snaps. However, AppImages don’t provide automatic updates, Snaps are tied to a proprietary distribution channel and Flatpaks don’t provide a straightforward mechanism to detect and run programs outside of the sandbox.

We can also try to get more up to date packages into the distro repositories. For Debian and derivatives the blocker is mainly the dependency on Guile 1.8, I believe, so the work by @mgubi on S7 and the testing of this by @darcy are great developments in that respect.

2 Likes
#18

We should check how other programs like VSCode, LyX or OpenOffice handle cross-platform builds and distribution. I guess otherwise we risk to reinvent the wheel. I found AppImage quite practical, and its disadvantages are similar to those of the App bundles on Mac and the packages on Windows (i.e. no automatic updates). So we could try just to correct this problem.

1 Like
#19

I have just compiled Mogan under Android and Debian on arm64. It seems that there is no difference from that on x86. Maybe @pjoyez could simply to enable the architecture arm64 in their repo to see whether it compiles directly without human intervention?