Was noch gefehlt hat:
Eine Alternative zu TeXstudio für diejenigen, die lieber groff als LaTeX verwenden möchten.

Also habe ich mal eine gebaut. Verwendete Komponenten: Nur das, was Lazarus bereits mitliefert.

Quellcode, kompilierte Pakete und FAQ:

Website.

Update: Version 0.9.9.1.

Die Liste an Änderungen ist - abzüglich der automatisch generierten Änderungen - überschaubar klein, daher auch der kleine Versionssprung:

• Ich habe die macOS-Unterstützung verbessert (bzw. überhaupt erst eingebaut), hierfür ein paar Windows-Spezifika in ein $IFDEF geschoben und die Versionsprüfung für macOS implementiert.
  
• Auf der Website gibt es jetzt ein vorkompiliertes Paket (macOS 12), das auch das systemeigene groff richtig zu erkennen scheint.

Ich musste dafür Lazarus "trunk" installieren, also die neueste Version (zzt. 2.3.0) selbst kompilieren, weil Bug #37977 in FPC 3.2.2 noch nicht gefixt ist, was zu fiesen Fehlern beim Start geführt hat. Seufz.
(Ich bin sehr dankbar für fpcup. Das senkt wenigstens dafür den Aufwand...)

Update: Version 0.10.0.

Das Statusfenster ist jetzt nur noch ein ... naja, Statusfenster.
Wer eine Logausgabe haben will, der kann jetzt mit einem Häkchen eine Logdatei erstellen lassen. Nebenbei einen Absturz unter Windows korrigiert.

Nächster Schritt: Meine Versionsprüfung(sanzeige) geht - unter Windows - irgendwie noch nicht so richtig. Mal sehen, was das wieder soll...

Nachtrag:
Korrigiert. Version 0.10.1.

Update: Version 0.11.0.

Die Versionsprüfung ist jetzt abschaltbar (Standard: aus) und die Windowspakete haben jetzt OpenSSL an Bord. (Man denkt ja auch nicht immer daran, dass das unter Windows nicht üblich ist.)

Ich will mal etwas Feedback zur weiteren "Motivation" geben. Durchaus interessantes Projekt, aber ich verstehe das nicht.

Du beschreibst groff als Alternative für LaTeX, und das scheint irgendwie auch so zu sein. Aber wenn ich da hinterhergoogele, dann bekomme ich so Infos wie "wird hauptsächlich für die Erstellung von Manpages für Linux benutzt". Diese Manpages sind aber doch eher hübsch formatierte Text-Dateien. Das ist doch was völlig anderes als das, wofür man LaTex in der Regel benutzt - also z.B. wissenschaftliche Paper im Bereich Mathematik/Physik/Informatik, oder Abschlussarbeiten im Studium dieser Bereiche.

Könntest du da etwas Licht in mein Dunkel bringen?

Hurra! Motivation!

Wie LaTeX kreist auch groff um das Konzept der Makropakete. Im deutschsprachigen Raum ist (war?) etwa KOMA ein beliebtes Makropaket für LaTeX, das unter anderem standardkonforme Briefe einfacher gemacht hat. Ein typischer Anwendungsfall für groff ist in der Tat das Schreiben von manpages (Makropaket „man“) - aber mit dem Makropaket „mom“ zum Beispiel sieht die Sache schon ganz anders aus.

Und auch wissenschaftliche Arbeiten sind mit groff möglich - wie LaTeX beherrscht groff die Nutzung von Präprozessoren, also das Parsen des Codes vor dem Erzeugen der Ausgabe. Für mathematische Formeln ist zum Beispiel der Präprozessor „eqn“ da. Praktischerweise hat groffstudio Auswahlboxen für beides…

Dass die deutschsprachige Literatur zum Thema groff sich in Grenzen hält und es ohne ersichtlichen Grund - naja, vielleicht tatsächlich wegen der fehlenden Editoren? - mittlerweile überwiegend von LaTeX abgelöst worden ist, ist etwas bedauerlich, aber an der unterschiedlichen Ausrichtung liegt es meiner Meinung nach nicht.

Update: Version 0.12.0.

Vorbereitungen für die Paketierung unter Linux, UNIX und BSD, das Hauptfenster geht jetzt auf dem primären Monitor auf, sonst nur Kleinigkeiten.

Update: Version 0.13.0.

Nachdem ich freundliches Feedback zu meiner Windowsversion bekommen hatte, habe ich mir 2-3 Dinge noch mal angesehen. Die wesentlichen Änderungen:
- Multi-Select für die diversen Parameter (wurde sonst zu voll mit den Checkboxen)
- unter macOS sieht die Schrift nicht mehr *mist*e aus
- groff wird jetzt weniger wahrscheinlich nicht gefunden

Komplettes Diff:
code.rosaelefanten.o...;to=8bb30e04bd97756c

Update: Version 0.13.1. Groff wird jetzt im Thread gesucht.

Komplettes Diff:
code.rosaelefanten.o...;to=3b615f92bd879d7f

Ich habe mir mal deinen Diff-Code angeschaut.
Mußt du nicht, wie bei der VCL mittels TThread.Synchronize, die UI-Aufrufe im UI-Thread ausführen?
Für Lazarus (bzw. FreePascal) habe ich gleiches gelesen: Multithreaded Application Tutorial: The TThread Class:

Zitat:

As we explained earlier, the thread should not interact with the visible components. Updates to visible components must be made within the context of the main thread. To do this, a TThread method called Synchronize exists. Synchronize requires a method within the thread (that takes no parameters) as an argument. When you call that method through Synchronize(@MyMethod), the thread execution will be paused, the code of MyMethod will be called from the main thread, and then the thread execution will be resumed.

Einerseits:
Anscheinend schon. Zu meiner Verteidigung: Ist nach über 20 Jahren meine erste Multithreadanwendung in Pascal.

Andererseits:
Muss ich nicht unbedingt, geht anscheinend auch so.
Eine andere Anwendung, die ich parallel entwickle und die erst mal nur für interne Zwecke verwendet wird, macht grob Folgendes:



Und es funktioniert. Frage: Ist es ein Fehler, dass das funktioniert?

(Ich finde Synchronize() irgendwie unschön. Gerade groffstudio hat ja mehr als bloß 1 UI-Element, an dem das logisch dranhängt.)

Das ist ja das Unvorhersehbare, daß es nicht gleich zum Absturz o.ä. kommt, sondern meistens zu funktionieren scheint.
Wenn du jedoch parallel im UI-Thread dieselben UI-Elemente bearbeitest (egal ob per Code oder vom Benutzer), dann kann es jedoch zu Fehlverhalten kommen.

Du kannst auch mehrere UI-Aktionen in der bei Synchronize angegebenen Funktion hintereinander ausführen (bei deinem Code also alles nach dem RunCommand - also auch der ShowMessage-Aufruf etc. - du mußt nur GroffOutputVersion als Klassenmember anlegen).

Edit: Wenn ich das in Functional programming in Pascal richtig verstehe, dann unterstützt FPC auch Lambda-Ausdrücke (d.h. anonyme Funktionen), so daß du den Code inline lassen kannst - anstatt in einer eigenen extra Funktion:

Th69 hat folgendes geschrieben :

Wenn ich das in Functional programming in Pascal richtig verstehe, dann unterstützt FPC auch Lambda-Ausdrücke (d.h. anonyme Funktionen)

Ja, aber erst in FPC 3.3.x, das mit macOS Sonoma noch nicht so recht klarkommt. (Für 3.2 musste ich lokal einen Patch basteln, 3.3 wirft mit Lazarus direkt einen Laufzeitfehler beim Start.)

Na gut, ich baue das für die nächste Version um. Danke für die Ergänzung. (Nur dafür mach' ich aber kein Update. )

Update: Version 0.13.2.

Ist jetzt mit einer neueren Version von Lazarus kompiliert und Synchronize() ist jetzt drin...

... Weiß zufällig einer der Mitlesenden, ob (und wie) ich RunCommand() dazu bewegen kann, den Befehl mit der Umgebung des aktuellen Nutzers auszuführen? Momentan ist groffstudio nicht so recht kompatibel mit "groff aus Homebrew installiert", weil /opt/homebrew naturgemäß nicht im Standardpfad ist, sondern i.d.R. in der lokalen .profile o.dgl. definiert wird - und die wird von RunCommand() ja nicht geladen.

Update: Version 0.14.0. Unter Windows wird für PDF-Ausgabe jetzt Ghostscript vorausgesetzt. Aus Gründen.