mirror of
https://github.com/cy384/ssheven.git
synced 2026-05-15 06:05:53 -06:00
[GH-ISSUE #26] Rendering errors in emacs #24
Labels
No labels
bug
documentation
enhancement
enhancement
pull-request
question
upkeep
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/ssheven#24
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @kpmgeek on GitHub (Jul 24, 2023).
Original GitHub issue: https://github.com/cy384/ssheven/issues/26
Having unexpected malignment of characters in emacs.
Using xterm-color on a MacOs Ventura host, client is iMac G3 running 9.2.2.
I know a bunch of the misrendered symbols are unicode characters (would love a fix, i wonder if on OS9 it'd be as simple as building with a more complete unicode font), but we're also seeing characters it can render be severely misaligned.
The divider bar in treemacs is totally misaligned on several lines, and the menu-bar on line 1 only intermittently appears.
Including a comparison with xterm running on linux with xterm-color 16-color mode to the same server (although proper unicode support minus the nerd-fonts characters).
@cy384 commented on GitHub (Jul 24, 2023):
Thank you for the report.
Right now, ssheven only supports ASCII (actually, MacRoman). Last time I looked, even on OS 9 unicode support in the system libraries is very weak. Also I'm not sure how well the terminal escape code library I'm using does with unicode. I spent an afternoon trying to just make ssheven strip out non-ascii characters but it ended up being a big hassle.
Anyway, I do want to get unicode support. Unfortunately, unicode text rendering is pretty complicated, so I will need to spend some time finding suitable libraries and fonts, along with reworking how ssheven renders text in general.
In short: I do want to address this, but it will take quite a while.
@kpmgeek commented on GitHub (Jul 24, 2023):
Upon further texting the character alignment issues are entirely related to non-visible unicode codes. So yeah, entirely related to unicode.
I'll do some digging into the old unicode support documentation.
@kpmgeek commented on GitHub (Apr 3, 2024):
http://oldvcr.blogspot.com/2023/08/maclynx-beta-5-utf-8-pull-down-menus.html MacLynx has implemented a fairly detailed but fast UTF-8 to macroman conversion.
@heavyimage commented on GitHub (Jan 14, 2025):
Following with interest -- I'd love to setup an old mac as a distraction free terminal to access various CLI / TUI apps I use but the lack of unicode support in ssheven sadly gives me tons of rendering errors like the ones shown in @kpmgeek's screenshots.
Really really really appreciate this project!
@kpmgeek commented on GitHub (Jan 14, 2025):
As awesome as getting unicode support would be, there are solutions. NetBSD runs on anything SE/30 and faster and if you setup X11 to just open "Suckless Terminal" compiled with unicode support without a window manager its ram usage can fit into less than 20mb. Windows NT for PPC or BeOS are also great unicode friendly options for machines that can run that.
The alternative is setting up a vm environment that has a native locale of legacy ISO 8859-1, which largely matches MacRoman. This locale has been dropped in some newer linux distros. And then I have a project that is far from perfect but tries to be a minimal config for writing in emacs without using any plugins that require unicode characters and substituting common things like curly quotes in documents: https://github.com/kpmgeek/RetroWritingEMacs
@heavyimage commented on GitHub (Jan 15, 2025):
I appreciate all that, for sure, but I think:
a) if you're going to be using
sshevenyou want to be on some sort of aged mac and not just some minimal linux / BSD box (I already run st as the default terminal app on my linux boxes -- it's so great!)b) I don't know a lot about emacs but it seems like forking the application seems like the wrong approach as you'd have to do this for every app / plugin you'd want to support in the future (I'm interested in a text editor, for sure, but also other apps like
tootorncmpcpp!)I think your idea of trying to construct a VM or container to run apps I care about in a legacy locale might be the best path forward for now -- I'll try to experiment. For example,
tootuses theurwidlibrary which I think respects locale.That said, I'm hopeful that @cy384 (or others if they're looking for contributors) could help integrate some 'native' utf-8 "support", perhaps in the form of that library you linked to!
@kpmgeek commented on GitHub (Jan 15, 2025):
I think you misunderstood, a. I mean an alternative is not using ssheven for your distraction free environment and using a BSD or other OS on your retro mac that can present unicode characters properly. B. I didn't fork emacs, I made my own config that I distributed, just like a lot of common distros circulate. Just with sane defaults since not a lot of thought is given in common distros like Spacemacs or Doom Emacs to making them friendly to non-unicode environments.
@heavyimage commented on GitHub (Jan 15, 2025):
A) I think at least for me (and possibly other folks interested in
ssheven) being on the mac isn't just about the hardware; it's about the other mac software / OS / environment too -- I have a lot of nostalgia for that!B) Sorry, you're right -- I'm tired and it's late -- I didn't mean forking the app. But having to have prepared a special config for every app in case it tries to use unicode still feels like an inflexible approach - - I'm hoping something else is possible :-) Maybe our use cases are different since it seems like you're mostly interested in one very configurable app!
@kpmgeek commented on GitHub (Jan 15, 2025):
I agree on that point, but its a good stopgap solution if you absolutely need uicode.
And yeah, there's few apps as complicated as emacs.
@kpmgeek commented on GitHub (Jan 15, 2025):
Also forgot to mention once you have your locale and termcap setup correctly running things through GNU Screen can clean up some programs that don't behave correctly. But it can also introduce weird keymapping behavior with the termcap you might not expect so some config can be necessary.
@kpmgeek commented on GitHub (Jan 15, 2025):
As far as true unicode support, ATSUI which is the unicode engine on 8.5+ would require basically a fork dropping 68k support and the documentation is super spotty. Plus some modern unicode fonts would need to be built as classic Mac fonts.
@cy384 commented on GitHub (Jan 17, 2025):
It's an awkward situation, the options all have tradeoffs:
In the medium term, I'll be doing option 2, and in the long term I'd like freetype-based text rendering as an option.
@kpmgeek commented on GitHub (Jan 17, 2025):
I'd suggest a toggle implementing also ISO8859-1 to MacRoman translation since they are mostly identical but not mapped the same. This allows at least some useful non-ASCII characters to work in apps that play nicely with locale settings.
I didn't realize freetype builds on classic mac os, I wonder how usable that would be on lower end powerpc machines.
@kpmgeek commented on GitHub (Jan 17, 2025):
Also re: point 1: Wouldn't a modern unicode font address the changes in unicode? But again, it'd basically have to be a PPC-only fork for 8.5+.
@cy384 commented on GitHub (Jan 17, 2025):
it almost certainly does not, so I'd need to do some work porting it. But it's probably possible.
@kpmgeek commented on GitHub (Jan 17, 2025):
At least at one point it did: https://github.com/erikdahlstrom/freetype2/tree/master/builds/mac
@heavyimage commented on GitHub (Jan 18, 2025):
I tried to compile ssheven myself to play with this a bit but I couldn't get it to work. The compiler couldn't find "Threads.h" or the YieldToAnyThread() in the transport-mbdtls function. Let me know if I can do anything to help out though!
@cy384 commented on GitHub (Feb 16, 2025):
For the basic unicode workaround mentioned above, would yall prefer replacing un-renderable characters as spaces or as a placeholder like the apple character?
e.g.
@heavyimage commented on GitHub (Feb 16, 2025):
I think a placeholder is best -- not sure the apple logo is the best
substitute though -- maybe that old question mark / diamond character from
the classic mac era that meant something encoding wise had gone very wrong?
On Sun, Feb 16, 2025 at 8:32 PM cy384 @.***> wrote:
--
Jesse Spielman
Computer Science Researcher
uk +44 (0)7808 861922
mastodon @@.***l
@kpmgeek commented on GitHub (Feb 16, 2025):
Placeholder like the question mark/diamond character would be ideal.
Substituting smart quotes to plain quotes would also solve a lot of common issues.
@heavyimage commented on GitHub (Feb 16, 2025):
ban smart quotes
On Sun, Feb 16, 2025 at 9:12 PM Kyle Mahaney @.***>
wrote:
--
Jesse Spielman
Computer Science Researcher
uk +44 (0)7808 861922
mastodon @@.***l
@cy384 commented on GitHub (Feb 16, 2025):
OK, of the characters available, I'm going with the lozenge, which is probably most likely to make people recognize it as a missing glyph.
When I get around to it, the next step will probably be a mapping of some easy/common unicode characters into something printable.
@kpmgeek I have a test build available if you want to confirm the fix for the original alignment issue http://www.cy384.com/media/bin/ssheven/ssheven-fat-unicode.bin
@heavyimage commented on GitHub (Feb 16, 2025):
This looks much better for one CLI app I was hoping to use,
toot:Compare that against the current release (very similar to @kpmgeek's issue):
@heavyimage commented on GitHub (Feb 21, 2025):
(anything I can help you with @cy384 ?)