On Fri, Dec 15, 2023 at 05:41:10PM -0700, David Snyder wrote:
> Not the correct solution, but I was able to get vile to work on macOS
> Sonoma with this change:
>
> $ git diff
> diff --git a/eightbit.c b/eightbit.c
> index f5b0b158..24e9f617 100644
> --- a/eightbit.c
> +++ b/eightbit.c
> @@ -616,6 +616,7 @@ vl_get_encoding(char **target, const char *locale)
> } else {
> #ifdef HAVE_LANGINFO_CODESET
> result = nl_langinfo(CODESET);
> + result = utf_eight;
> #else
> if (vl_is_utf8_encoding(locale)) {
> result = utf_eight;
>
> For some reason, nl_langinfo(CODESET) returns an empty string when locale
> is "en_US""en_US" would be ISO-8859-1 Actually I'd expect "en_US.UTF-8", since that's what locale shows me on a command-line (in Ventura). If Apple removed the data for non-Unicode locales, I suppose it could return an empty string. I dimly recall some long-ago discussion of how Apple sets the locale, but in the settings I see only "English (US) -- Primary" for the Language & Region This still applies to Ventura (perhaps your problem): https://blog.remibergsma.com/2012/07/10/setting-locales-correctly-on-mac-osx-terminal-application/ or it may be in your /etc/profile (I don't see it there): https://stackoverflow.com/questions/7165108/in-os-x-lion-lang-is-not-set-to-utf-8-how-to-fix-it > * thread #1, queue = 'com.apple.main-thread', stop reason = step over > frame #0: 0x000000010007ecd4 > vile`vl_get_encoding(target=0x00000001000cc1c8, locale="en_US") at > eightbit.c:618:11 [opt] > 615 endofDisplay(); > 616 } else { > 617 #ifdef HAVE_LANGINFO_CODESET > -> 618 result = nl_langinfo(CODESET); > 619 result = utf_eight; > 620 #else > 621 if (vl_is_utf8_encoding(locale)) { > Target 0: (vile) stopped. > (lldb) p (char *) nl_langinfo(0) > (char *) 0x000000018b435db8 "" > > Hope this helps you work out a proper solution. > > > On Fri, Dec 15, 2023 at 4:15 PM David Snyder <dsnyder0...@gmail.com> wrote: > > > Not surprisingly, installing vile via Homebrew produces the same results. > > > > ==> Downloading https://ghcr.io/v2/homebrew/core/vile/manifests/9.8y > > ######################################################################### > > 100.0% > > ==> Fetching vile > > ==> Downloading > > https://ghcr.io/v2/homebrew/core/vile/blobs/sha256:9c04feee9958f > > ######################################################################### > > 100.0% > > ==> Pouring vile--9.8y.arm64_sonoma.bottle.tar.gz > > 🍺 /opt/homebrew/Cellar/vile/9.8y: 223 files, 7.9MB > > ==> Running `brew cleanup vile`... > > Disable this behaviour by setting HOMEBREW_NO_INSTALL_CLEANUP. > > Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`). > > $ vile > > Cannot setup translation from to UTF-8 > > > > On Fri, Dec 15, 2023 at 9:24 AM David Snyder <dsnyder0...@gmail.com> > > wrote: > > > >> Hi Thomas, > >> > >> Thanks for your reply. I was hoping that would work, but no luck so far: > >> > >> $ LC_ALL=en_US.UTF-8 vile > >> Cannot setup translation from to UTF-8 > >> > >> It seems odd that vl_narrow_enc.encoding is *empty* in the error message > >> above. > >> > >> For locale, I see the same as you: > >> > >> $ locale -a | wc -l > >> 203 > >> > >> Output of locale: > >> > >> $ locale > >> LANG="en_US.UTF-8" > >> LC_COLLATE="en_US.UTF-8" > >> LC_CTYPE="en_US.UTF-8" > >> LC_MESSAGES="en_US.UTF-8" > >> LC_MONETARY="en_US.UTF-8" > >> LC_NUMERIC="en_US.UTF-8" > >> LC_TIME="en_US.UTF-8" > >> LC_ALL= > >> > >> However, as I showed above, even explicitly setting LC_ALL has no effect: > >> > >> $ export LC_ALL="en_US.UTF-8" > >> $ locale > >> LANG="en_US.UTF-8" > >> LC_COLLATE="en_US.UTF-8" > >> LC_CTYPE="en_US.UTF-8" > >> LC_MESSAGES="en_US.UTF-8" > >> LC_MONETARY="en_US.UTF-8" > >> LC_NUMERIC="en_US.UTF-8" > >> LC_TIME="en_US.UTF-8" > >> LC_ALL="en_US.UTF-8" > >> > >> $ vile > >> Cannot setup translation from to UTF-8 > >> > >> > >> On Thu, Dec 14, 2023 at 6:44 PM Thomas Dickey <dic...@his.com> wrote: > >> > >>> ----- Original Message ----- > >>> | From: "David Snyder" <dsnyder0...@gmail.com> > >>> | To: "Vile mailing list" <vile@nongnu.org> > >>> | Sent: Thursday, December 14, 2023 7:51:46 PM > >>> | Subject: Encoding translation error on macOS Sonoma 14.2 > >>> > >>> | After upgrading to macOS Sonoma 14.2 (MacBook Pro with Apple M1 Pro > >>> | processor), I can't seem to get vile to run. Even after a fresh build, > >>> I > >>> | see the following error: > >>> > >>> hmm - I've 3 macs that I intend upgrading to Sonoma, but as usual put it > >>> off. > >>> One is an M2 (the others are Intel). Those are all on Ventura, and > >>> locales work. > >>> > >>> "locale -a |wc -l" lists 203 settings. > >>> > >>> What does "locale" print for your environment? > >>> The message indicates that there's no locale set. > >>> > >>> If Apple's lobotomized locale support, you might just as well set > >>> > >>> LC_ALL=en_US.UTF-8 > >>> > >>> (that would probably even work with something like OpenBSD). > >>> > >>> | > >>> | $ vile > >>> | Cannot setup translation from to UTF-8 > >>> | > >>> | Looking at the source I see this function in eightbit.c: > >>> | > >>> | static void > >>> | open_encoding(char *from, char *to) > >>> | { > >>> | if (!try_encoding(from, to)) { > >>> | fprintf(stderr, "Cannot setup translation from %s to %s\n", > >>> from, > >>> | to); > >>> | tidy_exit(BADEXIT); > >>> | } > >>> | } > >>> | > >>> | I also tried rebuilding using --with-locale: > >>> | > >>> | $ ./configure -v --with-locale > >>> | > >>> | Unfortunately, the same result. Also, this is on an M1 MacBook Pro, so > >>> I > >>> | don't have gdb handy. > >>> | > >>> | Compiling using --with-trace, I see these warnings, which look > >>> | disconcerting: > >>> | > >>> | trace.c:488:59: warning: overflow in expression; result is 2147483647 > >>> with > >>> | type 'int' [-Winteger-overflow] > >>> | int c = buffer[j] & ((1 << (8 * sizeof(VIDEO_TEXT))) - 1); > >>> | ^ > >>> | trace.c:488:30: warning: shift count >= width of type > >>> | [-Wshift-count-overflow] > >>> | int c = buffer[j] & ((1 << (8 * sizeof(VIDEO_TEXT))) - 1); > >>> | ^ ~~~~~~~~~~~~~~~~~~~~~~~~ > >>> | > >>> | Hoping someone with better development tools on Apple silicon can > >>> reproduce > >>> | this issue and provide more helpful debugging info. Thanks. > >>> | > >>> | -- David > >>> > >>> -- > >>> Thomas E. Dickey <dic...@invisible-island.net> > >>> https://invisible-island.net > >>> > >> -- Thomas E. Dickey <dic...@invisible-island.net> https://invisible-island.net
signature.asc
Description: PGP signature
