[dev] Space to advance to the next slide
Hi,
Thank you very much for sent, it's awesome! Since Space is very common
in other presentation tools to advance to the next slide it would be a
great default for sent as well. The attached patch adds the Space key
as another way to advance to the next slide.
Regards,
Jan Christoph
--
Jan Christoph Ebersbach
I didn’t want some petty, inferior brand of righteousness that comes
from keeping a list of rules when I could get the robust kind that comes
from trusting Christ - God’s righteousness. Phil 3:9
From ca10921d45d1605647a882e101a52d612033640b Mon Sep 17 00:00:00 2001
From: Jan Christoph Ebersbach
Date: Tue, 17 Nov 2015 06:33:46 +0100
Subject: [PATCH] Register Space to advance to the next slide
---
config.def.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/config.def.h b/config.def.h
index 39772fb..6ecc267 100644
--- a/config.def.h
+++ b/config.def.h
@@ -29,6 +29,7 @@ static Shortcut shortcuts[] = {
{ XK_Right, advance,{.i = +1} },
{ XK_Left,advance,{.i = -1} },
{ XK_Return, advance,{.i = +1} },
+ { XK_space, advance,{.i = +1} },
{ XK_BackSpace, advance,{.i = -1} },
{ XK_l, advance,{.i = +1} },
{ XK_h, advance,{.i = -1} },
--
2.6.2
signature.asc
Description: PGP signature
[dev] [sent] "Terminal doesn't support images" isn't quite true
Hi, I had found these in sent example: also: terminal presentations don't support images… In My Humble Opinion, terminal indeed can display images, look at w3m although it is badly designed. I think that it can be something such as "terminal has bad support for images" instead of »terminal don't support images« -- _ < Do what you like, like what you do. > - \ ^__^ \ (oo)\___ (__)\ )\/\ ||w | || ||
Re: [dev] [sent] 0.1 release
KIMURA Masaru wrote: > > ... takahashi style presentations ... > > you might also check monta method? Heyho, Interesting. Just set the first font to something like `dejavu sans mono` then you can duplicate the slides where you want to apply the monta method and use `_` as a placeholder for the characters to be revealed on the next slide. --Markus
Re: [dev] sent-0.1 or libxft bug
Heyho, v4hn wrote: > > and what you think was causing it. > > On Tue, Nov 17, 2015 at 01:34:30AM +0300, ret set wrote: > >> Subject: [dev] sent-0.1 or libxft bug > >> [...] > >> Program received signal SIGSEGV, Segmentation fault. > >> 0x77529980 in XftCharExists () from > >> /usr/lib/x86_64-linux-gnu/libXft.so.2 Yeah right, so we just have to put a `if (addr == 0x77529980)` check in there to fix it… (that was sarcasm) > I do think the current behavior w.r.t. long lines or long paragraphs could be > improved though. > > Over here using the latest HEAD ret set's example yields a slide with *one* > rather small "A" at the top center. Also I just noticed that `./sent <(python > -c 'print "A"*4000')` (might vary with screen size/available fonts?) gives me > a number of rather big As partially overlaying each other, whereas `./sent > <(python -c 'print "A"*400')` works pretty much as expected: the line is too > long for the screen with a reasonable font size, so a long string of rather > small As is printed from side to side. You are welcome to work on this, but huge patches just to fix non-usecases would not be helpful and be rejected. However if the fix is simple enough, I would merge it. The font sizes are calculated with the formula given in config.h so you can adjust them to your screen size/resolution and font settings. You should make sure the biggest Font size fits the usableheight of your screen (Just one 'A' and see, if it gets bigger when you increase NUMFONTSCALES) and the smallest one should fill the longest line in the usablewidth and also the slide with the most lines vertically (If these two test cases are not rendered within the usable space of your screen, then you have to modify the FONTSZ function to start at even smaller font sizes). The default values work well for me with a 1366x768 screen and the default dejavu font. On my larger 2560x1440 screen the largest fontsize produced by FONTSZ is too small, so I just increased NUMFONTSCALES accordingly. --Markus
Re: [dev] [sent] 0.1 release
You're welcome -- glad I could help. On 11/17 00:38, Markus Teich wrote: > I also remind you, that this is a developers list and not a user > support list (suckless has no users, just developers). Just sending in > bug reports without at least a proposal of how to fix it is seen as > rude. So, to confirm my understanding: if I don't have the time or expertise to fix a bug I've found, I should refrain from communicating its existence to its developer community, and hope that a) someone else finds the bug and b) is capable and inclined to fix it? I hope I don't sound facetious, but I'm trying to understand if this is truly the intent. Wouldn't this reduce bug discovery drastically? > This is the correct list, but as already explained you should have submitted a > patch with the bug report. The bug really was not that hard to find, so please > at least try to find a solution next time. ;) I haven't written any C for a while and have never worked with X libraries; "not that hard" is very relative. Stephen
Re: [dev] sent-0.1 or libxft bug
Sorry in advance in case my sarcasm detector failed me... On Mon, Nov 16, 2015 at 11:43:30PM +, Nick wrote: > Quoth ret set: > > > At least describe in one sentence what you mean. > > Segmentation fault in in sent-0.1. > > Christoph is right, you really should have provided more description > of what the fault is, On Tue, Nov 17, 2015 at 01:34:30AM +0300, ret set wrote: >> Subject: [dev] [...] bug >> [...] >> Segmentation fault > how to reproduce it, On Tue, Nov 17, 2015 at 01:34:30AM +0300, ret set wrote: >> $ make && ./sent <(python -c 'print "A\n"*4000') >> sent build options: >> CFLAGS = -g -std=c99 -pedantic -Wall -I. -I/usr/include >> -I/usr/include/freetype2 -I/usr/X11R6/include -DVERSION="0.1" >> -D_XOPEN_SOURCE=600 >> LDFLAGS = -g -L/usr/lib -lc -lm -L/usr/X11R6/lib -lXft -lfontconfig -lX11 >> -lpng >> CC = cc >> Segmentation fault > and what you think was causing it. On Tue, Nov 17, 2015 at 01:34:30AM +0300, ret set wrote: >> Subject: [dev] sent-0.1 or libxft bug >> [...] >> Program received signal SIGSEGV, Segmentation fault. >> 0x77529980 in XftCharExists () from >> /usr/lib/x86_64-linux-gnu/libXft.so.2 Everything you requested was there in the first mail and I would send pretty much the same message if I didn't have the time to fix this myself. > But regardless, as far as I can see this is fixed in the latest code > in git, aa713a8a342ec0e6eca173cd4489834f8baa0a86. Yes, there is no segmentation fault anymore. I do think the current behavior w.r.t. long lines or long paragraphs could be improved though. Over here using the latest HEAD ret set's example yields a slide with *one* rather small "A" at the top center. Also I just noticed that `./sent <(python -c 'print "A"*4000')` (might vary with screen size/available fonts?) gives me a number of rather big As partially overlaying each other, whereas `./sent <(python -c 'print "A"*400')` works pretty much as expected: the line is too long for the screen with a reasonable font size, so a long string of rather small As is printed from side to side. v4hn signature.asc Description: PGP signature
Re: [dev] sent-0.1 or libxft bug
Nick wrote: > But regardless, as far as I can see this is fixed in the latest code > in git, aa713a8a342ec0e6eca173cd4489834f8baa0a86. Heyho, Yes indeed, it was the same segfault mentioned earlier. I replied to both of them, but probably your MUA does not show my reply in both threads in threading view. --Markus
Re: [dev] sent-0.1 or libxft bug
Quoth ret set: > > At least describe in one sentence what you mean. > Segmentation fault in in sent-0.1. Christoph is right, you really should have provided more description of what the fault is, how to reproduce it, and what you think was causing it. But regardless, as far as I can see this is fixed in the latest code in git, aa713a8a342ec0e6eca173cd4489834f8baa0a86.
Re: [dev] [sent] 0.1 release
Heyho, ret set wrote: > $ make && ./sent <(python -c 'print "A\n"*4000') > … > Segmentation fault Stephen Whitmore wrote: > When running the example presentation, I hit a segfault when I reached the > first slide with an image (@nyan.png). See attached for backtrace. This only > seems to happen if the window is smaller than certain dimensions. > I can repro for large text lines in small windows, too. Thanks for submitting the bug report. They should be fixed in the latest commit. I could not reproduce the image problem, but it should also be fixed, please test, Stephen. I also remind you, that this is a developers list and not a user support list (suckless has no users, just developers). Just sending in bug reports without at least a proposal of how to fix it is seen as rude. > Tangential nit: The README still seems to say that slides are per-line vs > per-paragraph. Also fixed. > Please let me know if there's a better place for me to post this -- I didn't > see a specific mailing list mentioned on the project page. This is the correct list, but as already explained you should have submitted a patch with the bug report. The bug really was not that hard to find, so please at least try to find a solution next time. ;) Thanks anyway. --Markus
Re: [dev] sent-0.1 or libxft bug
> At least describe in one sentence what you mean. Segmentation fault in in sent-0.1. 17.11.2015, 01:43, "Christoph Lohmann" <2...@r-36.net>: > Greetings. > > On Mon, 16 Nov 2015 23:40:41 +0100 ret set wrote: >> $ make && ./sent <(python -c 'print "A\n"*4000') >> sent build options: >> CFLAGS = -g -std=c99 -pedantic -Wall -I. -I/usr/include >> -I/usr/include/freetype2 -I/usr/X11R6/include -DVERSION="0.1" >> -D_XOPEN_SOURCE=600 >> LDFLAGS = -g -L/usr/lib -lc -lm -L/usr/X11R6/lib -lXft -lfontconfig -lX11 >> -lpng >> CC = cc >> Segmentation fault > > please learn to keep to a netiquette. Even AI mailing bots have a better > behaviour than you. At least describe in one sentence what you mean. > > Sincerely, > > Christoph Lohmann
Re: [dev] sent-0.1 or libxft bug
Greetings. On Mon, 16 Nov 2015 23:40:41 +0100 ret set wrote: > $ make && ./sent <(python -c 'print "A\n"*4000') > sent build options: > CFLAGS = -g -std=c99 -pedantic -Wall -I. -I/usr/include > -I/usr/include/freetype2 -I/usr/X11R6/include -DVERSION="0.1" > -D_XOPEN_SOURCE=600 > LDFLAGS = -g -L/usr/lib -lc -lm -L/usr/X11R6/lib -lXft -lfontconfig -lX11 > -lpng > CC = cc > Segmentation fault please learn to keep to a netiquette. Even AI mailing bots have a better behaviour than you. At least describe in one sentence what you mean. Sincerely, Christoph Lohmann
[dev] sent-0.1 or libxft bug
$ make && ./sent <(python -c 'print "A\n"*4000') sent build options: CFLAGS = -g -std=c99 -pedantic -Wall -I. -I/usr/include -I/usr/include/freetype2 -I/usr/X11R6/include -DVERSION="0.1" -D_XOPEN_SOURCE=600 LDFLAGS = -g -L/usr/lib -lc -lm -L/usr/X11R6/lib -lXft -lfontconfig -lX11 -lpng CC = cc Segmentation fault ~/src/sent-0.1$ ~~~ $ gdb ./sent (gdb) r /tmp/bug Starting program: /home/again/src/sent-0.1/sent /tmp/bug [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x77529980 in XftCharExists () from /usr/lib/x86_64-linux-gnu/libXft.so.2 (gdb) bt #0 0x77529980 in XftCharExists () from /usr/lib/x86_64-linux-gnu/libXft.so.2 #1 0x004056e1 in drw_text (drw=0x640ea0, x=0, y=0, w=4294967295, h=0, text=0x60a280 "A", invert=0) at drw.c:273 #<--- w - !? #2 0x00405c2f in drw_fontset_getwidth (drw=0x640ea0, text=0x60a280 "A") at drw.c:381 #3 0x004031ad in getfontsize (s=0x608250, width=0x7fffe128, height=0x7fffe12c) at sent.c:334 #4 0x00403e05 in xdraw () at sent.c:524 #5 0x0040471e in expose (e=0x7fffe170) at sent.c:644 #6 0x00403d77 in run () at sent.c:509 #7 0x00404a8f in main (argc=1, argv=0x7fffe370) at sent.c:690 1$ dpkg -l | grep libxft ii libxft-dev 2.3.2-1 amd64 FreeType-based font drawing library for X (development files) ii libxft2:amd64 2.3.2-1 amd64 FreeType-based font drawing library for X cat /etc/os-release PRETTY_NAME="Debian GNU/Linux 8 (jessie)" NAME="Debian GNU/Linux" VERSION_ID="8" VERSION="8 (jessie)" ID=debian ... ... ... --- @ret5et
[dev] Re: [sbase] cal doesn't highlight current day
Manu Raster writes: > Marc Collin writes: > >> It's one of the commands I use the most, and having the current day >> highlighted is a pretty great feature. > > Another really useful function would be an optional column in the > calendar displaying 'ISO week dates' (DIN ISO 8601). They are quite > common in business parlance but I haven't seen them in any cal command > yet. > > It would save a lot of time awkwardly searching for it elsewhere. util-linux cal has -w -- Christian Neukirchenhttp://chneukirchen.org
Re: [dev] [sbase] cal doesn't highlight current day
Hi * Manu Raster 2015-11-16 22:45 > Another really useful function would be an optional column in the > calendar displaying 'ISO week dates' (DIN ISO 8601). They are quite > common in business parlance but I haven't seen them in any cal command > yet. you might give ncal a try. (it comes from FreeBSD.) ncal prints weeks vertically, rather than horizontally, and with an optional row(s) for the week number. cheers --s
[dev] Re: [sbase] cal doesn't highlight current day
Marc Collin writes: > It's one of the commands I use the most, and having the current day > highlighted is a pretty great feature. Another really useful function would be an optional column in the calendar displaying 'ISO week dates' (DIN ISO 8601). They are quite common in business parlance but I haven't seen them in any cal command yet. It would save a lot of time awkwardly searching for it elsewhere.
Re: [dev] a suckless hex editor
Agreed. Besides if xxd is installed, one can do something like this in vi/vim: :%!xxd make changes :%!xxd -r. Is a shell script really necessary? On 13/11/15 11:45am, Alex Pilon wrote: > On Fri, Nov 13, 2015 at 11:28:36AM -0500, Greg Reagle wrote: > > What do you think? > > > > […] > > > > #!/bin/sh > > > > […] > > dump="xxd -g1" > > dedump="xxd -r" > > xxd's provided by vim. As convenient as it is, should a "suckless hex > editor" really depend on that? It should be the user's choice or not to > install vim, regardless of anybody's feeling's on this list *either* way.
