[dev] [tabbed][PATCH] Resize clients that notify about WM_NORMAL_HINTS
Signed-off-by: S Gilles
---
Fixes the following program. This could probably also be done be
adjusting configurerequest.
/* cc -o mwe mwe.c $(pkg-config --cflags --libs gtk+-2.0) */
#include
#include
static int x, y;
static gboolean tick(gpointer p)
{
gtk_entry_progress_pulse(GTK_ENTRY((GtkWidget *) p));
if (x++ > 99)
gtk_main_quit();
return 1;
}
static gboolean tock(gpointer p)
{
gtk_image_set_from_icon_name(GTK_IMAGE((GtkWidget *) p),
"text-x-generic", (y++ % 2) ?
GTK_ICON_SIZE_DIALOG :
GTK_ICON_SIZE_MENU);
return 1;
}
int main(int argc, char **argv)
{
GtkWidget *w, *h, *e, *i;
gtk_init(0, 0);
w = (argc == 2) ? gtk_plug_new(strtoll(argv[1], 0, 0)) :
gtk_window_new(GTK_WINDOW_TOPLEVEL);
gtk_window_set_default_size(GTK_WINDOW(w), 1024, 800);
h = gtk_hbox_new(0, 0);
e = gtk_entry_new();
i = gtk_image_new();
gtk_container_add(GTK_CONTAINER(w), h);
gtk_box_pack_start(GTK_BOX(h), e, 0, 0, 0);
gtk_box_pack_start(GTK_BOX(h), i, 0, 0, 0);
g_timeout_add(100, tick, (gpointer) e);
g_timeout_add(550, tock, (gpointer) i);
gtk_widget_show_all(w);
gtk_main();
return 0;
}
tabbed.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tabbed.c b/tabbed.c
index ff3ada0..7bb16e3 100644
--- a/tabbed.c
+++ b/tabbed.c
@@ -859,6 +859,9 @@ propertynotify(const XEvent *e)
}
}
XFree(wmh);
+ } else if (ev->state == PropertyNewValue && ev->atom ==
XA_WM_NORMAL_HINTS &&
+ (c = getclient(ev->window)) > -1) {
+ resize(c, ww, wh - bh);
} else if (ev->state != PropertyDelete && ev->atom == XA_WM_NAME &&
(c = getclient(ev->window)) > -1) {
updatetitle(c);
--
2.19.1
Re: [dev] [st] Hardcoded colors. Can I change them runtime?
On 2018-07-30T18:52:11+0200, Timur Fayzrakhmanov wrote:
> Halo!
>
> I've tried to change color scheme using the following project
> https://github.com/chriskempson/base16-shell. But I didn't get a success.
> It seems like the colors are hardcoded at config.def.h and can not be
> changed then. Unfortunately, I don't know well internals of the st nor the
> terminal emulators in general so I hope to get a hint.
> Thank you all.
As others have said, the right way to do this is to change config.h
and recompile. However:
The 256-color palette of st is mutable, since st supports the
can-change-color property. Try something like
printf '\033]4;0;rgb:10/20/30\033\\'
That should change all black in the current window to a sort of
dark blue. The syntax is
printf '\033]4;N;rgb:R/G/B\033\\'
where N is a number from 0 to 255 (the color index), and R, G, B
are hex numbers from 0 to ff specifying the intensity of the color.
If you have 256color.pl (or a variation), you can run
256color.pl
for x in $(seq 0 255); do
r=$(head -c 1 /dev/urandom | od -t u1 -A n | tr -d ' ')
g=$(head -c 1 /dev/urandom | od -t u1 -A n | tr -d ' ')
b=$(head -c 1 /dev/urandom | od -t u1 -A n | tr -d ' ')
printf '\033]4;%s;rgb:%2x/%2x/%2x\033\\' ${x} ${r} ${g} ${b}
done
This is handled in st.c around line 1858, if you want to see more.
--
S. Gilles
Re: [dev] [st] Emojis
On 2017-09-17T14:16:15+, Janne Heß wrote: > Hello everyone, > > I just wanted to ask if anyone has managed to properly display emojis in st. > I know this is potentially sucky feature, but I read my mail in mutt and > some companies think it's a good idea to put emojis into their subjects. > Currently, it looks like the emojis consisting of 2 characters escape > the character grid. I'm not sure if this is a bug or just a > not-implemented feature. > > Is there anybody here who has experience with displaying such characters > in st? The crash has come up a few times: https://lists.suckless.org/dev/1707/31965.html https://lists.suckless.org/dev/1610/30710.html https://lists.suckless.org/dev/1612/30836.html https://lists.suckless.org/dev/1608/30245.html Nobody seems to be able to pin down the way to break a working system. The "escaping the grid" has also come up at least once: https://lists.suckless.org/dev/1604/28689.html , particularly https://lists.suckless.org/dev/1604/28698.html -- S. Gilles
Re: [dev] pids for surf, webkit instances
On 2017-09-06T07:14:21+0300, Greg Minshall wrote: > hello. > > every now and then some browser instance goes resource wild. top(1) or > ps(1) show the PID consuming all the resources (normally a webkit > instance), but i haven't figured out a way to go from that to knowing > which instance to kill off, given that most often i start surf from > dwm(1), which starts surf on a generic search engine page, and then i go > from there. is there an obvious method for correlating a PID to an > actual instance? xprop | grep PID ? -- S. Gilles
[dev] [st] [PATCH] Remove expose() to prevent unresponsiveness
---
Doc, it hurts when I do this:
- have a huge st (say, 100 x 200 rows x cols?)
- take a floating window and gently wave it over st for a second
or two, generating lots of Expose events
- switch to st and try to type
- wait for 20+ seconds for all the damn redraw()s to finish
- see typing finally show up
The first thing I tried was to delete expose() from x.c, which has
been working perfectly for the past hour or so: st is responsive
and I haven't seen any visual issues.
Since it seems to work for my specific setup, I'm proposing this
patch, but I'm sort of expecting/hoping that somebody who knows
more than I do (so anything at all) about X11/xcb will explain why
handling Expose events is actually needed. In that case, I'll try
something more complicated to limit an Expose cascade to a single
expose().
Thanks,
S. Gilles
x.c | 8
1 file changed, 8 deletions(-)
diff --git a/x.c b/x.c
index fbfd350..434217b 100644
--- a/x.c
+++ b/x.c
@@ -90,7 +90,6 @@ static int xgeommasktogravity(int);
static int xloadfont(Font *, FcPattern *);
static void xunloadfont(Font *);
-static void expose(XEvent *);
static void visibility(XEvent *);
static void unmap(XEvent *);
static void kpress(XEvent *);
@@ -115,7 +114,6 @@ static void (*handler[LASTEvent])(XEvent *) = {
[ConfigureNotify] = resize,
[VisibilityNotify] = visibility,
[UnmapNotify] = unmap,
- [Expose] = expose,
[FocusIn] = focus,
[FocusOut] = focus,
[MotionNotify] = bmotion,
@@ -1440,12 +1438,6 @@ drawregion(int x1, int y1, int x2, int y2)
}
void
-expose(XEvent *ev)
-{
- redraw();
-}
-
-void
visibility(XEvent *ev)
{
XVisibilityEvent *e = >xvisibility;
--
2.13.1
Re: [dev] [announce] mle: a small terminal-based text editor
On 2017-04-10T11:54:29+, Cág wrote: > S. Gilles wrote: > > > I wrote a patch[0] for mg which sort of adds Unicode support a while > > back via wchar_t. Upstream interest was low, as they were just about > > to release 6.0 and I got the impression they'd rather write it > > themselves, but as far as I can tell it works. At the very least, > > it could be used as a guide towards which parts of mg need to be > > ripped out and rewritten. > > Do you have a .diff file? I keep Alpine ports locally, so I could've > added it without copying the whole tree. > > Does mg in 6.0 support Unicode? For some reason our version is > 20140414 and I can't compile 20170401: > --- > fileio.c:104:17: error: 'DEFFILEMODE' undeclared (first use in this function) > > fileio.c: In function 'copy': > fileio.c:384:17: error: 'DEFFILEMODE' undeclared (first use in this function) > > fileio.c: In function 'make_file_list': > fileio.c:504:25: error: 'MAXNAMLEN' undeclared (first use in this function) > --- > > with warnings before. I've attached the patch I'm using against hboetes' portable branch (rebased just now). I also run a few musl machines, and for them I have a patches for the issue you describe. The patches aren't anything clever (I just give definitions for MAXNAMELEN and DEFFILEMODE), but it works as of 2017-04-10. - It should just work by default. - If you want to restore old octal expansion behavior, run `M-x show-raw-mode'. - If you want to insert a character by unicode codepoint, run `M-x insert-char' (I have `global-set-key "\^x\^i" insert-char' in my .mg). - Motion is on a byte-by-byte level, which for some reason I thought was a good idea (so you can wade into the middle of a wide character and insert bytes in the middle). (I predict you'll get fed up with this and change it.) - If you have a silly machine where wchar_t doesn't hold unicode codepoints, the results will be silly. -- S. Gilles diff --git a/README.md b/README.md index 994d6be..2f5d2c1 100644 --- a/README.md +++ b/README.md @@ -1,49 +1,50 @@ -# PORTING MG AND USING LIBBSD +# mg with wide display support. -I've maintained and ported mg for quite some time now and at first it -was easy recently it got harder and harder since it was a moving -target. Especially the inclusion of some system specific libraries since -about 2 years ago made it too much of an effort for my humble coding -skills. - -So recently Jasper Lievisse Adriaanse asked me to try it again and I -restarted working on the project and ran into exactly the same problems -again. While googling for solutions I ran into libbsd: - - http://libbsd.freedesktop.org/wiki/ - -It's a porting library for OpenBSD code! And after installing that it -was a piece of pie to get mg ported again. - -## PORTING TO ALL OTHER PLATFORMS - -Okay, that was debian. Now I have to get the rest of all the previously -suported platforms working again. All help is welcome and as always: -Please provide patches that do not break stuff for other platforms. - -## BUILDING MG - -So, basic instructions for building mg: - - - Get libbsd installed. - - Run the following commands: +I just received this amazing patch from S. Giles. For those impatient +people: check it out (tihihi) and add this line to your `.mg` ``` -make -sudo make install +set-default-mode "wide" ``` -## USING CVS - -This code is the cvs checkout from the OpenBSD project so if you install -cvs you can see what I changed to port mg. Like this: - -``` -cvs diff -uw -``` - -## ABOUT fgetln() - -Incase you are wondering about that deprecation warning, here is a nice explanation about why it is hard to fix: - - http://niallohiggins.com/2009/10/03/read-a-file-line-by-line-in-c-secure-fgets-idiom/ +## Introduction by S. Giles + +Hi, + +I've got a patch that allows mg to display wide characters, if you're +interested. + +It can be turned on by show-wide-mode (better name welcome), and is +fairly limited in regard to what types of wide characters are +displayed. Everything goes through mbrtowc(3), so you get exactly one +supported encoding: whatever LC_* says. Everything else is displayed +as octal escape sequences (as normal current behavior). Motion is +still on a byte level, so multibyte characters are slow to travel +through, and you can insert bytes in the middle of them (which works +fine). A limited version of insert-char is also included, which works +through wchar_t, so that on any system with __STDC_ISO_10646__ set, +inserting unicode codepoints by number is possible. + +It also fixes some odd bugs related to wide character display and +extended lines. For example: in a file with enough wide characters +(such as ＡＢＣ) to make a line extend far (say, 200 characters on an +80-wide display), moving to the right one character at a time will (in +20160118) corrupt the display, then eventua
Re: [dev] [announce] mle: a small terminal-based text editor
On 2017-03-29T19:00:03+, Cág wrote: > Wolfgang Corcoran-Mathe wrote: > > > mle is too complex for my taste (scripting and syntax highlighting > > seem unecessary, though I’m in the grumpy minority here) > > Personally I'd like to see more of something like mg or busybox' vi. > Unfortunately they both don't support UTF-8. nvi is pretty good as > well. I wrote a patch[0] for mg which sort of adds Unicode support a while back via wchar_t. Upstream interest was low, as they were just about to release 6.0 and I got the impression they'd rather write it themselves, but as far as I can tell it works. At the very least, it could be used as a guide towards which parts of mg need to be ripped out and rewritten. [0] https://github.com/hboetes/mg/tree/display-wide-characters -- S. Gilles
Re: [dev] Re: Linux distros that don't suck too too much
On 2017-02-01T08:35:32+, Cág wrote: > Marc Collin wrote: > > > Gentoo's init system (OpenRC) could soon > > move from Makefiles to Meson and add > > python3 and ninja to dependencies because > > of it. > > https://github.com/OpenRC/openrc/issues/116 > > Isn't Portage written in Python? Gentoo uses > glibc, coreutils, the package manager is in Python > and now there will be Python in the init system. > That's too much for a suckless distribution, > in my humble opinion. For what it's worth, 2/3 of my Gentoo machines use musl, and 2/3 use s6 as the init system. Parts of Portage do have a hard dependency on bash, though, which really sucks. -- S. Gilles
Re: [dev] Re: [st] Crash on middle finger character
On 2016-12-18T16:36:04+0100, Hadrien Lacour wrote: > On Sun, Dec 18, 2016 at 03:19:11PM +, Amadeusz Żołnowski wrote: > > I have forgot to attach the "utftest1.txt" file. Sorry. Here it goes. > > > > Cheers, > > -- Amadeusz Żołnowski > > > > > REVERSED HAND WITH MIDDLE FINGER EXTENDED: > > Work here. Using GNU Unifont and st-0.7 It also displays just fine for me, using either 0.7 or latest git (c63a87cd936c1eeef14c4c21572e5b782d3df4bc), with static char font[] = "Terminus:pixelsize=12:antialias=false:autohint=false"; -- S. Gilles
Re: [dev] Shell style guide
On 2016-09-06T11:35:35-0700, Evan Gates wrote: > Please discuss, Perhaps http://www.etalabs.net/sh_tricks.html might be a useful reference to add? There's some detail there that might be valuable, or at least sobering to anyone who wants to write some complicated sh. -- S. Gilles signature.asc Description: Digital signature
Re: [dev] [scc] typeof is a gcc keyword
On 2016-07-05T16:00:11-0300, Marc Collin wrote: > > I don't think this does what you expect it to do. At least looking at > > the 8cc makefile, the compiler is hardcoded as `cc', not the expansion > > of the variable `cc'. > > You are right. > But the CC flag is accepted. > Try "make CC=clang" and it will work. Excellent. Make moves in mysterious ways, its wonders to perform. > But "make CC=../1c/8cc" fails. Any idea how to use relative paths like that? Stick a $(pwd) in there, as in make CC=$(pwd)/../1c/8cc ? That blows up for me because of the CFLAGS, but at least it seems like a step towards doing what you want. > > On my system, the resulting binaries include references to the path they > > were compiled at. > > That could be the reason then. > Let's try to test on the same absolute paths. I'm not entirely sure that that the paths are the only environmental pollutants in the result (in particular, I suspect the system time might make its way in somehow, though I have very little evidence to support this). There's a lot of confusing hype around `reproducible builds', but the `Tips & help' section of http://reproducible-builds.org/docs/ might be useful. Your script will be able to ignore things like Locales or Time zones, of course, since the machine will be constant. -- S. Gilles
Re: [dev] [scc] typeof is a gcc keyword
On 2016-07-05T15:31:57-0300, Marc Collin wrote: > I did some tests with 8cc (because it's easier to build than scc for me). > My results are that the binaries aren't identical. > Here's a script so you can try to reproduce it. > > #!/bin/sh > mkdir test_comp > cd test_comp > git clone https://github.com/rui314/8cc > mv 8cc 1c > cp -r 1c 2c > cp -r 1c Ac > cp -r 1c Bc > > # compile 8cc with gcc > cd 1c > make cc=gcc > > # compile 8cc with clang > cd ../2c > make cc=clang I don't think this does what you expect it to do. At least looking at the 8cc makefile, the compiler is hardcoded as `cc', not the expansion of the variable `cc'. Try make cc=/bin/false or such. > # compile 8cc with 8cc > # using the binary that > # was compiled with gcc > cd ../Ac > make cc=../1c/8cc > > # compile 8cc with 8cc > # using the binary that > # was compiled with clang > cd ../Bc > make cc=../2c/8cc > > cd .. > > # compare binaries > md5sum Ac/8cc Bc/8cc > On my system, the resulting binaries include references to the path they were compiled at. $ ls */8cc 8cc/8cc other_8cc/8cc $ strings 8cc/8cc | grep home /home/sgilles/temp/a/8cc/include #include /home/sgilles/temp/a/8cc $ strings other_8cc/8cc | grep home /home/sgilles/temp/a/other_8cc/include #include /home/sgilles/temp/a/other_8cc I suspect this is what actually causes the differences in md5sums. -- S. Gilles
