Re: [dev] [st] UTF-8 not working

2022-04-24 Thread Страхиња Радић
On 22/04/24 02:53, Robert Winkler wrote:
> Hi, thanks for all the hints I got from the [st] [dev]!
> Anyway, I still cannot sort it out; hopefully the following information
> helps that someone can spot the problem:
> As I mentioned, the UTF-8 symbols work in other terminals such as
> lxterminal.

How have you set up your input method? Try using setxkbmap(1) to set X input 
method. Also make sure that st's terminfo entries are installed
(make && sudo make install from st repository) and you have

export TERM=st-256color


signature.asc
Description: PGP signature


Re: [dev] [st] UTF-8 not working

2022-04-24 Thread Robert Winkler
On Wed Apr 20, 2022 at 2:29 AM CDT, Hiltjo Posthuma wrote:
> On Tue, Apr 19, 2022 at 07:09:57PM -0500, Robert Winkler wrote:
> > 
> > 
> > On April 15, 2022 2:23:36 PM CDT, Quentin Rameau  wrote:
> > >Hi Robert,
> > >
> > >> Hi, according to the st Status, UTF-8 should be working. Much needed for
> > >> multilingual typing with ú, ü, ß, µ, ¿ etc.
> > >> However, I only get 00e9 if I type é; anything, I need to specify in
> > >> config.h?
> > >
> > >No, you just should only need to declare correctly your LC_CTYPE
> > >
> > 
> > Sorry, but I don't get it fixed. I rebuilt the locals with dpkg-reconfigure 
> > locales, with the US UTF-8 as default.
> > 
> > On lxterminal, the characters é, ö etc. work. In st they don't.
> > 
> > 
> > 
>
> It works in st. It's a misconfiguration on your system.
>
> If you provide more information, not the bare minimum, maybe some people are
> kind enough to help you.
>
> -- 
> Kind regards,
> Hiltjo

Hi, thanks for all the hints I got from the [st] [dev]!
Anyway, I still cannot sort it out; hopefully the following information
helps that someone can spot the problem:
As I mentioned, the UTF-8 symbols work in other terminals such as
lxterminal.

1) The locales seem to be fine:
~~~
rob@pop-os ~> locale
LANG=en_US.UTF-8
LANGUAGE=en_US
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
rob@pop-os ~>
~~~

2) Fonts. The liberation font is installed (see `config.h` below).
~~~
rob@pop-os ~> apt search liberation
Sorting... Done
Full Text Search... Done
fonts-liberation/impish,impish,now 1:1.07.4-11 all [installed,automatic]
  Fonts with the same metrics as Times, Arial and Courier

  fonts-liberation2/impish,impish,now 2.1.3-1 all [installed,automatic]
Fonts with the same metrics as Times, Arial and Courier (v2)
~~~
btw. I tested Liberation Mono in `lxterminal`, and UTF-8 works.

3) `config.h`
~~~
/* See LICENSE file for copyright and license details. */

/*
 * appearance
 *
 * font: see http://freedesktop.org/software/fontconfig/fontconfig-user.html
 */
static char *font = "Liberation Mono:pixelsize=18:antialias=true:autohint=true";
static int borderpx = 2;

/*
 * What program is execed by st depends of these precedence rules:
 * 1: program passed with -e
 * 2: scroll and/or utmp
 * 3: SHELL environment variable
 * 4: value of shell in /etc/passwd
 * 5: value of shell in config.h
 */
static char *shell = "/bin/sh";
char *utmp = NULL;
/* scroll program: to enable use a string like "scroll" */
char *scroll = NULL;
char *stty_args = "stty raw pass8 nl -echo -iexten -cstopb 38400";

/* identification sequence returned in DA and DECID */
char *vtiden = "\033[?6c";

/* Kerning / character bounding-box multipliers */
static float cwscale = 1.0;
static float chscale = 1.0;

/*
 * word delimiter string
 *
 * More advanced example: L" `'\"()[]{}"
 */
wchar_t *worddelimiters = L" ";

/* selection timeouts (in milliseconds) */
static unsigned int doubleclicktimeout = 300;
static unsigned int tripleclicktimeout = 600;

/* alt screens */
int allowaltscreen = 1;

/* allow certain non-interactive (insecure) window operations such as:
   setting the clipboard text */
int allowwindowops = 0;

/*
 * draw latency range in ms - from new content/keypress/etc until drawing.
 * within this range, st draws when content stops arriving (idle). mostly it's
 * near minlatency, but it waits longer for slow updates to avoid partial draw.
 * low minlatency will tear/flicker more, as it can "detect" idle too early.
 */
static double minlatency = 8;
static double maxlatency = 33;

/*
 * blinking timeout (set to 0 to disable blinking) for the terminal blinking
 * attribute.
 */
static unsigned int blinktimeout = 800;

/*
 * thickness of underline and bar cursors
 */
static unsigned int cursorthickness = 2;

/*
 * bell volume. It must be a value between -100 and 100. Use 0 for disabling
 * it
 */
static int bellvolume = 0;

/* default TERM value */
char *termname = "st-256color";

/*
 * spaces per tab
 *
 * When you are changing this value, don't forget to adapt the »it« value in
 * the st.info and appropriately install the st.info in the environment where
 * you use this st version.
 *
 *  it#$tabspaces,
 *
 * Secondly make sure your kernel is not expanding tabs. When running `stty
 * -a` »tab0« should appear. You can tell the terminal to not expand tabs by
 *  running following command:
 *
 *  stty tabs
 */
unsigned int tabspaces = 8;

/* Terminal colors (16 first used in escape sequence) */
static const char *colorname[] = {
/* 8 normal colors */
"black",
"red3",
"green3",
"yellow3",
"blue2",
"magenta3",
"cyan3",
"gray90",

/* 8 bright colors */
"gray50",
  

Re: [dev] [dwm] possible regression in 8806b6e

2022-04-24 Thread Ethan Marshall
Just re-ran the bisection and got 8806b6e on both stock dwm and my
build. Reverting this commit fixes this change in both. Reverting
bece862 has no change in either, so I would assume we can eliminate that
commit as the issue.

Could this be related to the handling of fixed-size windows? I was under
the impression that windows of a fixed size are treated as automatically
floating by dwm. Could that have been thrown off by this new size logic?

Ethan

On 23/04/22 10:16am, Chris Down wrote:
> Hi Ethan,
> 
> Just checking, are you sure this bisects to 8806b6e23793 ("manage:
> propertynotify: Reduce cost of unused size hints")? I saw this issue prior
> to making this patch and bisected to bece862a0fc4 ("manage: For
> isfloating/oldstate check/set, ensure trans client actually exists"). I
> reported this last month here[0].
> 
> I would be surprised if this commit is the cause because I use gpg-askpass
> and the Chromium system printing dialog fairly regularly, although of course
> anything is possible.
> 
> If you're sure it bisects to this commit and not bece862a0fc4, let me know.
> Thanks!
> 
> Chris
> 
> 0: https://lists.suckless.org/hackers/2203/18220.html
>