Re: [dev] [st] 0.6 release
On Tue, Jul 7, 2015 at 10:56 PM, FRIGN d...@frign.de wrote: Thank you guys for working on st! Yep, thanks to everyone involved in st nowadays. I've moved to other things but I'm glad the project has gone this far.
Re: [dev] [st] Need help implementing combining characters
On Sun, Apr 21, 2013 at 7:02 PM, Random832 random...@fastmail.us wrote: I'm also having drawing issues with double-width characters that I don't know how to fix, so maybe it would be best if I just send what I have. Should I send it in the form of a patch or just my st.c? Send what is the most convenient to you. I think it doesn't matter as long as you only send the changes limited to the double-width char feature. st is small enough.
Re: [dev] [st] wide characters
On Sat, Apr 13, 2013 at 11:17 PM, Random832 random...@fastmail.us wrote: I am forced to ask, though, why character cell values are stored in utf-8 rather than as wchar_t (or as an explicitly unicode int) in the first place, particularly since the simplest way to detect a wide character is to call the function wcwidth. What was the reason for this design decision? It doesn't save any space, since on most systems UTF_SIZ == sizeof(int) == sizeof(wchar_t). The ISO/IEC 10646:2003 Unicode standard 4.0 says that: The width of wchar_t is compiler-specific and can be as small as 8 bits. Consequently, programs that need to be portable across any C or C++ compiler should not use wchar_t for storing Unicode text. The wchar_t type is intended for storing compiler-defined wide characters, which may be Unicode characters in some compilers. utf-8 is rather straightforward to handle and process.
Re: [dev] [st] windows port?
You might me interested in ConEmu http://code.google.com/p/conemu-maximus5/
Re: [dev] cannot run st
On Thu, Jan 24, 2013 at 6:47 PM, pancake panc...@youterm.com wrote: i've been quite busy these last months.. so i was a little disconnected from the suckless development... but several months ago i tried to run st on OSX without success.. and today i tried to run it on linux (voidlinux) without much more luck. Thank you for reporting this. The error I get is this: $ st XOpenIM failed. Could not open input device. So.. I tried to find the bug and here it is: run: //setlocale(LC_CTYPE, ); XSetLocaleModifiers(); tnew(80, 24); just commenting the setlocale() makes st to run, so XOpenIM fails because of that. (wtf) I guess this is not the correct solution, what is the purpose of this setting the locales? Look at the setlocale(1) man page of your system. On linux here's the relevant part: If locale is , each part of the locale that should be modified is set according to the environment variables. The details are implementation-dependent. For glibc, first (regardless of category), the environment variable LC_ALL is inspected, next the environment variable with the same name as the category (LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY, LC_NUMERIC, LC_TIME) and finally the environ‐ ment variable LANG. The first existing environment vari‐ able is used. If its value is not a valid locale specifi‐ cation, the locale is unchanged, and setlocale() returns NULL. PD: the default font is not installed on OSX by default and without antialias it looks like crap Feel free to add some hints in the FAQ regarding config.h on OSX. PD: i wrote a terminal image viewer (tiv) just to have fun with some ascii-art rendering algorithms, so i did it in Vala and uses Gdk to load images (yeah, i will rewrite it in C at some point, but just wanted to do it fast and focus in the image processing code). The program renders the pictures in plain text, ansi16, greyscale and ansi256. Works fine in st :) you may find the source here: https://github.com/radare/tiv Cool!
Re: [dev] [suckless] Migration to git
I don't think using git will solve anything because there's no problem to solve. That being said, I don't mind using either git or mercurial. The official repo should stay on suckless.org, though.
Re: [dev] [st] 0.3 release
On Fri, Nov 2, 2012 at 8:12 PM, Christoph Lohmann 2...@r-36.net wrote: Greetings comrades. St 0.3 has been released and much has changed. Thank you Christoph --and everybody involved in this new release-- for keeping st alive :) I've a lot of work this year and I can't find the time nor the energy to focus on my personal projects, sorry. The biggest changes are: * New drawing code, which is way more faster and comparable to the other terminals out there. * Many new escape sequences are supported: * setting the title * LNM, KAM, SI, SO, SUB, CAN, DA, DECID. OSC, DSC, PM, APC, CHT, HTS, CBT, SM, RM, standout mode … (See st.info.) * Linedrawing is now supported * Xft and Fontcache is now used to draw fonts. * support for italic and bold italic font drawing * Some more commandline parameters are available. (See manpage.) * easy debugging with: st -o - | cat -v * nyancat(1) works. * external support of utmp entries by using utmp(1)[1] We should try to improve and cleanup the selection code. It has not changed much since pancake initial PoC and it lacks several features like the support of very common/basic Atoms like STRING (try pasting xfontsel result in st).
Re: [dev] [st] toggle font
On Thu, Oct 11, 2012 at 6:13 PM, Roberto E. Vargas Caballero k...@shike2.com wrote: St, like all others graphic terminal emualtors, receive escape sequences which configure it, change color, set tittle screen, set blink ..., so add new private sequences for things like chage font is not only no stupid, is the correct way in this case. Urxvt has this [1], we can use the same. 1: http://unix.stackexchange.com/a/14431
Re: [dev] [st] Tip adds non-existing trailing whitespace upon mouse selection + fix
On Tue, Oct 9, 2012 at 7:03 PM, Roberto E. Vargas Caballero k...@shike2.com wrote: Solution of copying all the characters needs some work, because I agree it sucks when you copy this non existing leading paces. I think the solution should be a variable by line saying maximum column written in it. I think other terminal emulators do something like this. Of course actual solution converts all tabs into spaces, but fix this is reallt complex and I think all the emulator take this aproach. The GLYPH_SET flag can be used to compute the end of the line or we could add another flag like GLYPH_TAB when appropriate and test it in the copy function when it loops over the selection.
Re: [dev] [st] Patches
I don't think the DEC alignment test is necessary. Please read LEGACY in st repo.
[dev] [st] tty widthheight
Changeset 317 (14adb004eb78) introduced tw and th in the XWindow struct. They are currently equivalent to the window width and height (x.w and x.h). What are their purpose?
Re: [dev] [st] Removing timeouts in main loop
On Sun, Sep 16, 2012 at 9:47 AM, Roberto E. Vargas Caballero k...@shike2.com wrote: This serie of patches try fix the problem of the timeout in main loop, which causes st wakeup each 20 ms even thare is noting to do. The timeout problem was introduced to speed up the rendering when a lot of text is printed. The logic is basically to not redraw on every read when the throughput is high: - try to read data for SELECT_TIMEOUT ms max - if something was read, handle it in the term - if something was read and the last call to draw was more than DRAW_TIMEOUT ms ago then redraw. I don't have a unix machine at the moment but here is a simple testcase: $ dd if=/dev/random bs=4K count=100 | hexdump Increase the count and compare with other terms if necessary.
Re: [dev] [st] Removing timeouts in main loop
On Sun, Sep 16, 2012 at 11:51 AM, Aurélien Aptel aurelien.ap...@gmail.com wrote: - try to read data for SELECT_TIMEOUT ms max - if something was read, handle it in the term - if something was read and the last call to draw was more than DRAW_TIMEOUT ms ago then redraw. In retrospect, the Right Thing would be to have the SELECT_TIMEOUT only if something is waiting to be redrawn i.e. after a call to draw, always use select() with a NULL timeout.
Re: [dev] [st] New patches
I'm not exactly sure what this feature will be used for. If you want to script something around a program expecting to run in a term there are already better tools for that like expect [1]. I'm not the one who added this goal. On Wed, Sep 12, 2012 at 8:22 PM, Roberto E. Vargas Caballero k...@shike2.com wrote: I agree with you that it is a bit stupid, and maybe we should use directly write. Look these new patches. I was thinking of using the dup2 syscall in the shell process (fork child) to make the the stderr/stdout redirect to the file. That way you don't even need to call write explicitely. But I'm not sure you can do this since I'm already redirecting them to the cmdfd. I don't know if it's faster either. Hence my previous comment in the form of a question :) Since we're dealing with a hdd, my guess would be that buffered io is faster given you buffer more than 1 character (which was not the case the first patch). It really all depends on what this feature is for. To me it just look like some kind debug tool for st. 1: http://en.wikipedia.org/wiki/Expect
Re: [dev] [st] Removing timeouts in main loop
On Sun, Sep 16, 2012 at 12:26 PM, Christoph Lohmann 2...@r-36.net wrote: If there is something to read from the tty, handle it, then wait for five microseconds in select() and see if the buffer filled again. If yes, handle this and do it again. After a certain amount of such loops (1000) break and redraw the terminal. This arbitary break is there be‐ cause without it the user would see a stuttering in the output and it seems to go wrong. This loop number is related to my development machine and a better solution to calculate or replace it with a more natural value would be more fitting solution. I'm not really sure it's simpler then. I will look into it tonight. In the benchmark you proposed (count=500) I could reproduce the same times as urxvt with the above changes. I've made a mistake in the command, you should use /dev/urandom instead of /dev/random because the latter can block on read, see $ man 4 random.
Re: [dev] [st] New patches
Couldn't the file output feature be implemented with dup2 in the child process? Using the buffered IO API and flushing at every character is stupid.
Re: [dev] Line artifacts ST
It looks like there's something wrong with the line height.
Re: [dev] interested in issue tracker dev
Let's bump this again. Someone might do something about it.
Re: [dev] [st] selection problem
On Thu, Feb 23, 2012 at 10:02 AM, Martin Kopta mar...@kopta.eu wrote: Expected result: one click does nothing, two select word, three select line. Observed result: one click selects whole line. I get the same behaviour. I'll look at it.
Re: [dev] smessage
On Mon, Feb 27, 2012 at 12:14 AM, Florian Limberger f...@snakeoilproductions.net wrote: width of your fixed font. If you use a proportinal font, I have no solution at the moment. I guess you could find the right amount of characters to draw to fill a line using (dichotomously) XmbTextExtents().
Re: [dev] smessage
On Tue, Feb 21, 2012 at 11:55 AM, Florian Limberger f...@snakeoilproductions.net wrote: I have hacked up a simple xmessage replacement which looks neater, has dmenu-like handling and supports unicode. Nice code. If you want to replace xmessage, you should make text scrollable and selectable.
Re: [dev] [st] terminal capability cm required
On Fri, Feb 17, 2012 at 10:35 AM, Paul Onyschuk bl...@bojary.koba.pl wrote: On Fri, 17 Feb 2012 10:20:22 +0100 Martin Kopta wrote: Before I get into solving this, have anyone seen this? What is cm? # vi -u NONE E437: terminal capability cm required Press ENTER or type command to continue man xterm(1) No, I think it's a termcap/terminfo entry. From man terminfo(5): cursor_addresscupcmmove to row #1 columns #2 cup is already in st.info. Did you compiled the terminfo entry? ($ tic -s st.info)
Re: [dev] [st] terminal capability cm required
On Fri, Feb 17, 2012 at 11:18 AM, Aurélien Aptel aurelien.ap...@gmail.com wrote: cup is already in st.info. Did you compiled the terminfo entry? ($ tic -s st.info) If you compile the terminfo as a user, it will go in the local terminfo database (~/.terminfo). You need to install it in the system database to make it available to every user. Run (as root) # tic -s st.info
Re: [dev] [st] terminal capability cm required
On Fri, Feb 17, 2012 at 11:31 AM, Martin Kopta mar...@kopta.eu wrote: st.info' into /usr. It is a CentOS 5.7. I have no problem with that on CentOS 6.2, Ubuntu 11.10 and Archlinux. I guess it is because of ancient Vim. Maybe this version of vim doesn't support terminfo? This is very unlikely but who knows... Can you show the output of :version? It's supposed [1] to confim this. 1: http://vimdoc.sourceforge.net/htmldoc/term.html#startup-terminal
Re: [dev] [st] 0.2.1 is out
On Thu, Feb 16, 2012 at 4:11 PM, Andrew Hills hills...@gmail.com wrote: Will this be released/available at http://dl.suckless.org/st/? I don't have Mercurial access at work. You don't need mercurial to get a tarball from the repo. http://hg.suckless.org/st/archive/revison or tag.tar.gz http://hg.suckless.org/st/archive/0.2.1.tar.gz
Re: [dev] [st] 0.2.1 is out
On Thu, Feb 16, 2012 at 7:18 PM, Andrew Hills hills...@gmail.com wrote: Thanks. It looks like the SHELL macro is still in config.h and still doesn't do anything. Should it replace sh on line 712 of st.c? Yep, forgot about that.
Re: [dev] Re: [st] 0.2.1 is out
On Thu, Feb 16, 2012 at 12:22 PM, Peter Hartman peterjohnhart...@gmail.com wrote: So I take it the xft stuff didn't make it. In addition to fixing some I'll try to keep the xft branch up to date. I may even merge it by designing a generic font interface. problems, I also liked it because I could do st -f (rather than compiling a million little st's, st-terminus-12, st-terminus-14, etc.) Yes it's pretty useful. I'll add that.
Re: [dev] ... and then i go and spoil it all by saying something stupid ...
Someone loves me on the internet! *hug back*
[dev] [st] 0.2.1 is out
Hi all, I've pushed a few local changes and decided to bump the version a bit. * support for dim/bright colors * unfocused cursor is now visible with a different color * using index 16 for default colors now works properly * various code cleanup, rewrite, indented and named enum definitions. * VERSION updated in config.mk (I usually fuck this up everytime :p) enjoy.
[dev] Re: [st] 0.2.1 is out
On Thu, Feb 16, 2012 at 1:19 AM, Aurélien Aptel aurelien.ap...@gmail.com wrote: * support for dim/bright colors * unfocused cursor is now visible with a different color * using index 16 for default colors now works properly * various code cleanup, rewrite, indented and named enum definitions. * VERSION updated in config.mk (I usually fuck this up everytime :p) I've also changed some things in config.def.h, you'll have to update your config.h accordingly (or overwrite it with $ make -B)
Re: [dev] [st] htop, tmux, terminfo
On Sun, Feb 12, 2012 at 9:15 AM, Martin Kopta mar...@kopta.eu wrote: I hoped for easy solution where I won't have to modify all the hosts I know and all the hosts I will ever meet in the future. Thank you however for your proposed solution. The easiest solution is to set TERM to xterm in your config.h. One of the principal goal of st was to have good xterm compliance.
Re: [dev] Suckless.org Man page links
On Sat, Feb 11, 2012 at 5:54 PM, Anselm R Garbe garb...@gmail.com wrote: Actually I conclude that the current wman apps for werc sucks big time. All I really want is, that if there is a *.[1-9] file in the directory, it will be formatted using troff instead markdown. That's much simpler and the man pages would appear in the site menu. I will hack this and get rid of wman. Could you also display man pages in full? There's no reason to split them in pages on a browser. This has always bothered me.
Re: [dev] Suckless OS (was About escape sequences and stuff)
On Sat, Feb 11, 2012 at 9:32 PM, Jonathan Slark jonathan.sl...@gmail.com wrote: Has the suckless community considered starting an operating system from scratch? Linux/BSD etc suck by default as they are evolutions of software from the 1970s and have all the legacy baggage that comes with that. Even Plan 9 dates back to the 1980s. See: http://groups.google.com/group/wmii/browse_thread/thread/505f5e1af5a969fd/95ef2714fc0a98b0?lnk=gst http://groups.google.com/group/wmii/browse_thread/thread/712bca45b5a91c8b/ddde6ba726fb897a?lnk=gst http://groups.google.com/group/wmii/browse_thread/thread/de501b1bfdf13c11/db0613ec061ac965?lnk=gst http://groups.google.com/group/wmii/browse_thread/thread/91bcadcdf45aad82/ad7f12095a0b2fc1?lnk=gst
Re: [dev] [st] 0.2 is out
On Wed, Feb 8, 2012 at 2:17 PM, ilf i...@zeromail.org wrote: Care to update the website? http://st.suckless.org/ And add a post to the News section of http://suckless.org/? I did but the wiki has moderation.
Re: [dev] [st] 0.2 is out
On Wed, Feb 8, 2012 at 2:49 PM, ilf i...@zeromail.org wrote: I am running the same tmux session in both rxvt-unicode and st next to each other. The drawing speed of st does indeed feel better than before, but it's still way slower than rxvt in everything I have tried. This is one of the issues still holding me back from switching to st as my main terminal emulator. Do other terms have magic in their rendering code for extra speed? It's strange because fast scrolling in tmux seems to be the only case where st is unbearably slow. I've tried to profile this [1] but I've not found anything conclusive... Second thing to notice is the font height. st displays six more lines than rxvt, with tmux padding them. I changed $FONT in config.h: -#define FONT -*-*-medium-r-*-*-*-120-75-75-*-60-*-* +#define FONT -*-terminus-*-*-*-*-*-*-*-*-*-*-*-* But it has no effect. Where do I change this? You have to change FONT and BOLDFONT. To get a valid XLFD (the string with all the *-*-*) you can use xfontsel(1). You will particularly want to change the family (fmly) and height (pxlsz) field. Last, has anyone managed to adjust the transparency patch to this version? http://lists.suckless.org/dev/1009/6046.html https://gist.github.com/1432900 I don't know. But you can be sure it will trigger another troll-fest. 1: see this thread http://lists.suckless.org/dev/1201/10814.html
Re: [dev] [st] 0.2 is out
On Wed, Feb 8, 2012 at 4:13 PM, Diego Joss diego.j...@hispeed.ch wrote: there is a minor error on the website in the News section for the announcement: Pushed a fix, waiting for moderation, thanks.
Re: [dev] [st] 0.2 is out
On Wed, Feb 8, 2012 at 4:41 PM, ilf i...@zeromail.org wrote: Using radeon driver, but this should be irrelevant, right? You're not the first one to have performance problem with it [1], I'm afraid :/ 1: https://www.google.com/search?q=site%3Alists.suckless.org+radeon
[dev] [st] 0.2 is out
Hi all, As I said previously somewhere on the list, I've tagged the last changeset of the default branch as 0.2.
Re: [dev] [st] VT100 Emulation
On Sun, Feb 5, 2012 at 12:27 AM, Bjartur Thorlacius svartma...@gmail.com wrote: Žann lau 4.feb 2012 23:05, skrifaši Kurt H Maier: There are already terminals that care about such bullshit; why write another? Actually, st does not implement every VT100/VT102/xterm escape sequence.
Re: [dev] interested in issue tracker dev
So, how are things going? I guess setting up an existing BTS on suckless.org while waiting is out of the question? I'm already using some sort of TODO/XXX in comment but it could be better... For what it's worth, here's my usecase/design/whatever. I don't need much: - basic interface (cli, mail, http, ...) really don't care as long as it's usable and not too complex - title, description, status, comments - *every* field above should be editable
Re: [dev] [st] Drawing performance
First, thank you for the time you spent on st. On Sun, Jan 29, 2012 at 11:48 AM, Galos, David galos...@students.rowan.edu wrote: I've written a patch which drastically improves st's performance in interactive console applications, like htop, vim or alsamixer. However, catting /dev/urandom is actually worsened , because of XCopyArea overhead. The method used was actually to make st dumber. Rather than doing any accounting, in every function which updates the terminal model, I make an analogous X11 call, to update the pixmap. The calls to draw are then replaced by xrefresh, which simply XCopyArea's the pixmap onto the window. Have you tried a more recent st? IMO, we've reached a point where interactive application are fast enough and it's the bursting usecase we have to speed up. One particular case is tmux (look at Peter Hartman's previous posts on this list) for which I've made a simple test attached (slowtest.sh). The patch also reworks the Selection code, both for clarity, and to let you see what you select as you drag your mouse around. Your selection/cleanup code looks good. If you can adapt it to the tip of the default branch I'll apply it. Note that selection already changes as you drag your mouse around. 0.1.1 is old :) In case you're not familiar with mercurial here's the basics commands you'll need: get the repo $ hg clone http://hg.suckless.org/st update working directory to last changeset of the default branch $ hg up -C default Note: the -C overwrites any change you've made to the working directory version when updating. Be careful. I also suggest compiling with $ make -B in order to have an up-to-date config.h (overwritten by the current version config.def.h) make your change and get a diff file you can send $ hg diff If you feel adventurous you can set up a name, commit your change and send the output of $ hg export tip :)
Re: [dev] [st] Drawing performance
...aaand the attachement. *sigh* slowtest.sh Description: Bourne shell script
Re: [dev] [st] new xft branch (FreeType font rendering)
Oops. Applied, thanks.
Re: [dev] [st] font help
On Mon, Jan 23, 2012 at 10:50 AM, Eckehard Berns ecki-suckl...@ecki.to wrote: From your screenshot I would guess that the font pattern you specified isn't strict enough. St uses the maximum width of all characters in all fonts in the font set to calculate how wide the characters are. That's why you have these gaps between the different batches of chars. I usually specify at least the first four sections, the pxlsize and maybe the avgWidth, e.g. --misc-fixed-medium-r-*-*-14-*-*-*-*-70-*-* You might have to specify the sWdth and adstyl also (part 5 and 6): -misc-fixed-medium-r-normal--14-*-*-*-*-70-*-* Always leave the last two parts unspecified so that the font system can load the fonts for different encodings. If you don't know the font patterns for your font you can use xfontsel to construct them. I think this is correct. Also, these font-patterns are called XLFD. Google it if you need more information.
[dev] [st] new xft branch (FreeType font rendering)
Hi all, Due to popular demand and being fed up with x11 core fonts, I've made a new branch xft. X11 core fonts are still used in the default branch and this new branch is just an experiment. It might be merged back in default depending on how things go. As of now, the code is still a bit messy but it should work. * the font can be set in config.h (XFT_FONT) or via the -f flag. * the fonts usable on your system can be listed with $ fc-list : family * the font format is family-size or family:size=size * only works with mono-spaced fonts * if a bad font name is given, a default one is used without any err-ing (it's just how XftFontOpenName() works) so be careful.
Re: [dev] [st] Drawing optimizations
On Sun, Jan 22, 2012 at 7:22 PM, Peter John Hartman peterjohnhart...@gmail.com wrote: Hi, Unfortunately, the tmux-split-pane problem still persists. The tmux-split-pane problem is this: if one pane in tmux is spitting out a bunch of text (e.g. a sudo cat /var/log/messages or most compilations) you can't really switch panes or do much of anything at all. I remember this and I can confirm this problem. I'm using [1] which is pretty hardcore. I don't where this lag comes from. Strangely enough, it's working correctly on the xft branch... 1: $ dd if=/dev/urandom | od
Re: [dev] [st] Drawing optimizations
Hi all, I've made st ~10x faster on my computer. If there are no major bugs I will tag tip as version 0.2. Here's the relevant commit message: * add a timeout value (SELECT_TIMEOUT) of 20ms in the select() call * wait at least 20ms (DRAW_TIMEOUT) between draw() calls * only copy dirty lines from the buffer to the screen what draw() does: * clears dirty lines in the buffer * draws the longest same-attributes string of each dirty line to the buffer with multiple xdraws() call * copies the current dirty line from buffer to the screen with a single xcopy() call this changeset makes st run ~10x faster.
Re: [dev] st: Font problem
On Tue, Jan 17, 2012 at 10:38 AM, François Chaix pe...@fchaix.eu wrote: So, it works, st launches, but it is very slow. 1s to display a full man page, 3s to display a ncurses-based interface (tested with mocp). What do you think this comes from ? st is slow, yes, but it should be faster than that. What is the size (columns*rows) of your term? Also, try the tip of the repo, I implemented few optimisations since 0.1.1. Btw, I think I'll tag the next changeset as 0.2.
Re: [dev] st: Font problem
On Mon, Jan 16, 2012 at 7:15 PM, François Chaix pe...@fchaix.eu wrote: I would like to report and ask for help about a problem I have executing st. I get this message : --- ego@Bidule:~$ ./compil/suckless/st-0.1.1/st st: missing fontset: ISO10646-1 st: missing fontset: JISX0201.1976-0 st: missing fontset: GB2312.1980-0 snip I think as long as you have ISO10646-1 of your font (which is utf8 basically) you can ignore those missing xxx fontset messages. That being said, I hate this xfont system and I don't know much about it: I just got it (barely) working. I tested to configure st with #define FONT -*-terminus-medium-r-*-*-8-*-*-*-*-*-*-* witch is the font I use in dwm (and it works, dwm find the font). Same output error. See Eckehard's post. I am sorry if my question is a litle noob-like, but I am one… I am also sorry for my possible bad english: it is not my native language. T'embêtes pas avec ça ;)
Re: [dev] st: nano-paste fix
On Wed, Jan 11, 2012 at 12:33 PM, Martti Kühne mysat...@gmail.com wrote:
Debugging ttywrite() got me thinking, why is it that pressing Enter will not
result in what would seem logical '\n' but '\r' as well instead?
tty(1) mentions CR, though I'm completely lost if/why that be the right place.
See http://vt100.net/docs/vt102-ug/chapter3.html#S3.6.3.11
--- st/st.c 2011-11-02 21:24:08.893374099 +0100
+++ st-nanopaste/st.c 2012-01-11 12:13:15.011070888 +0100
@@ -500,7 +500,7 @@
void
selnotify(XEvent *e) {
unsigned long nitems, ofs, rem;
- int format;
+ int format, i;
unsigned char *data;
Atom type;
@@ -512,6 +512,9 @@
fprintf(stderr, Clipboard allocation failed\n);
return;
}
+ for(i = 0; i nitems * format / 8; i++)
+ if(data[i] == '\n')
+ data[i] = '\r';
ttywrite((const char *) data, nitems * format / 8);
XFree(data);
/* number of 32-bit chunks returned */
I'll have a look at this.
Re: [dev] st: equivalent fixes: st-sel-fix
On Tue, Jan 10, 2012 at 10:04 PM, Martti Kühne mysat...@gmail.com wrote: anyway, the problem is that XChangeProperty() will cause a segfault if it gets NULL - or strlen. I'm slightly in favor of the former, as it will allow sel.clip to be any value at any time, which is good. Thoughts? Good catch. Let's go with the former.
Re: [dev] [st] Patch to fix selection rendering
Thanks, applied.
Re: [dev] [dwm] 2000 SLOC
On Mon, Oct 31, 2011 at 9:38 AM, Anselm R Garbe garb...@gmail.com wrote: * skvm (who uses this? development seems dead) I use it. I installed it 1 or 2 years ago, never bothered to update it since it works. I also think libixp and ii should stay. I don't use them personally but I think they follow the suckless philosophy.
Re: [dev] [dwm] 2000 SLOC
Some of us are socially retarded, excuse them. On Sun, Oct 30, 2011 at 8:53 AM, Martin Kopta mar...@kopta.eu wrote: 2) Does that mean dwm won't gain any more features? 3) Does that mean the code will be cut short to make place for another features? dwm won't gain any big features. Generally, if you want something in dwm you hack its source then you make it available as a patch which is eventually shared on this ML or the wiki. 4) Should be the code made smaller by witty constructions or do you prefer boring and obvious constructions (which are generaly longer)? I'm guessing witty means clever here. The code has to remain simple and understandable in order to be hackable but keep in mind that it's still targeted to experienced hackers. 5) Will be the limit of 2 kSLOC lifted up? Maybe it will when support for Xinerama in Xorg will finally end. I think it used to be 1k not so long ago.
Re: [dev] Some questions about st and a patch
On Mon, Oct 17, 2011 at 5:06 PM, Connor Lane Smith c...@lubutu.com wrote:
I'm not a st developer, but I've had a look at this. Arrow keys do
need to be handled in a special way, but the arrow keys don't work
with any modifier keys.
Currently st handles an arrow key by printing, eg, \033[D. With
shift it is \033[1;2D, with alt \033[1;3D, and so on. So it needs
to detect bucky bits and react accordingly.
Unfortunately, it's not that simple.
Modifiers in terminals are handled differently in each terminal.
Sometime they are added as a parameter, sometime it's a key on its
own.
Start cat with no argument and try pressing any combination of
modifier with any arrow key in xterm and urxvt.
note: ^[ is \033 aka ESC
It seems that ncurses (which is maintained by xterm folks mind you)
doesn't even try to handle this clusterfuck [1].
On Mon, Oct 17, 2011 at 5:20 PM, Stephen Paul Weber
singpol...@singpolyma.net wrote:
Excellent! I shoved this in st.c for now:
snip
And it works! :D
It works in irssi? This is weird.
I've attached a patch to handle modifiers like xterm. Of course
modified arrow keys still don't work in emacs... Ugh. This is really
depressing.
Can anyone please try it with his favourite modifed-arrow-key-using
software with TERM=st and TERM=xterm?
Reminder:
$ hg clone http://hg.suckless.org/st
$ patch -p1 xterm-arrow-keys.diff
$ make
$ ./st
(in st window) TERM=xterm yourapp
or, for TERM=st-xxx
(in st window) yourapp
1: http://invisible-island.net/ncurses/ncurses.faq.html#modified_keys
diff -r 704261718508 st.c
--- a/st.c Thu Oct 06 21:32:34 2011 +0200
+++ b/st.c Tue Oct 18 12:02:40 2011 +0200
@@ -208,6 +208,7 @@
static void ttyread(void);
static void ttyresize(int, int);
static void ttywrite(const char *, size_t);
+static void ttyprintf(const char *, ...);
static void xdraws(char *, Glyph, int, int, int, int);
static void xhints(void);
@@ -733,10 +734,27 @@
void
ttywrite(const char *s, size_t n) {
- if(write(cmdfd, s, n) == -1)
+ if(write(cmdfd, s, n) 0)
die(write error on tty: %s\n, SERRNO);
}
+/* tty helper: slow, use it for non-frequent small stuff */
+void
+ttyprintf(const char *f, ...) {
+ char buf[1024];
+ va_list ap;
+ int n = 0;
+
+ va_start(ap, f);
+ n = vsnprintf(buf, sizeof(buf), f, ap);
+ va_end(ap);
+
+ if(n 0 || n = sizeof(buf))
+ die(ttyprintf: vnsprintf failed (%d/%d), n, sizeof(buf));
+
+ ttywrite(buf, strlen(buf));
+}
+
void
ttyresize(int x, int y) {
struct winsize w;
@@ -1890,8 +1908,10 @@
int len;
int meta;
int shift;
+ int ctrl;
Status status;
+ ctrl = e-state ControlMask;
meta = e-state Mod1Mask;
shift = e-state ShiftMask;
len = XmbLookupString(xw.xic, e, buf, sizeof(buf), ksym, status);
@@ -1905,11 +1925,21 @@
case XK_Up:
case XK_Down:
case XK_Left:
- case XK_Right:
- /* XXX: shift up/down doesn't work */
- sprintf(buf, \033%c%c, IS_SET(MODE_APPKEYPAD) ? 'O' :
'[', (shift ? dacb:DACB)[ksym - XK_Left]);
- ttywrite(buf, 3);
+ case XK_Right: {
+ char cursor = (shift ? dacb : DACB)[ksym - XK_Left];
+ char mode = IS_SET(MODE_APPKEYPAD) ? 'O' : '[';
+ int n = 1;
+
+ if(shift) n += 1;
+ if(meta) n += 2;
+ if(ctrl) n += 4;
+
+ if(n 1)
+ ttyprintf(\033%c1;%d%c, mode, n, cursor);
+ else
+ ttyprintf(\033%c%c, mode, cursor);
break;
+ }
case XK_Insert:
if(shift)
selpaste();
Re: [dev] Some questions about st and a patch
On Tue, Oct 18, 2011 at 12:14 PM, Aurélien Aptel aurelien.ap...@gmail.com wrote: Reminder: $ hg clone http://hg.suckless.org/st $ patch -p1 xterm-arrow-keys.diff You need to cd in st after hg clone, obviously.
Re: [dev] Some questions about st and a patch
Attached wrong patch; use this one, sorry.
diff -r 704261718508 st.c
--- a/st.c Thu Oct 06 21:32:34 2011 +0200
+++ b/st.c Tue Oct 18 12:20:03 2011 +0200
@@ -208,6 +208,7 @@
static void ttyread(void);
static void ttyresize(int, int);
static void ttywrite(const char *, size_t);
+static void ttyprintf(const char *, ...);
static void xdraws(char *, Glyph, int, int, int, int);
static void xhints(void);
@@ -733,10 +734,27 @@
void
ttywrite(const char *s, size_t n) {
- if(write(cmdfd, s, n) == -1)
+ if(write(cmdfd, s, n) 0)
die(write error on tty: %s\n, SERRNO);
}
+/* tty helper: slow, use it for non-frequent small stuff */
+void
+ttyprintf(const char *f, ...) {
+ char buf[1024];
+ va_list ap;
+ int n = 0;
+
+ va_start(ap, f);
+ n = vsnprintf(buf, sizeof(buf), f, ap);
+ va_end(ap);
+
+ if(n 0 || n = sizeof(buf))
+ die(ttyprintf: vnsprintf failed (%d/%d), n, sizeof(buf));
+
+ ttywrite(buf, strlen(buf));
+}
+
void
ttyresize(int x, int y) {
struct winsize w;
@@ -1890,8 +1908,10 @@
int len;
int meta;
int shift;
+ int ctrl;
Status status;
+ ctrl = e-state ControlMask;
meta = e-state Mod1Mask;
shift = e-state ShiftMask;
len = XmbLookupString(xw.xic, e, buf, sizeof(buf), ksym, status);
@@ -1905,11 +1925,21 @@
case XK_Up:
case XK_Down:
case XK_Left:
- case XK_Right:
- /* XXX: shift up/down doesn't work */
- sprintf(buf, \033%c%c, IS_SET(MODE_APPKEYPAD) ? 'O' :
'[', (shift ? dacb:DACB)[ksym - XK_Left]);
- ttywrite(buf, 3);
+ case XK_Right: {
+ char cursor = DACB[ksym - XK_Left];
+ char mode = IS_SET(MODE_APPKEYPAD) ? 'O' : '[';
+ int n = 1;
+
+ if(shift) n += 1;
+ if(meta) n += 2;
+ if(ctrl) n += 4;
+
+ if(n 1)
+ ttyprintf(\033%c1;%d%c, mode, n, cursor);
+ else
+ ttyprintf(\033%c%c, mode, cursor);
break;
+ }
case XK_Insert:
if(shift)
selpaste();
Re: [dev] Some questions about st and a patch
On Tue, Oct 18, 2011 at 12:27 PM, pancake panc...@youterm.com wrote:
and type rm -rf ~ ; after the patch is applied
Thank you for your helpful{#`%${%`+'${`%NO CARRIER
Re: [dev] st bug report and feature request
Hi, Sorry for the late reply. On Sat, Sep 24, 2011 at 4:57 PM, u-st-j...@aetey.se wrote: Having compiled and tested st, I would like to contribute a report. That's great, thank you. Utf-8 and line graphics symbols' handling looks broken on bold text (?). E.g. mutt shows kanji in From correctly unless the entry is highlighted. Selecting text which contains kanji may lead to the line being redrawn with characters on different horisontal positions. Moving the selection pointer right and left makes characters to move either left or right. This depends also on which font has been picked by st at start, which in turn depends on the font collection being available at the X11 server. The more important issue, choice of the fonts: With some fonts (depending on the actual server) the display is totally broken, cursor being misplaced to the right and characters appearing in two places/halves or like that. In general it looks like wrong font width calculation. With many other fonts the displayed characters are far from being pretty and/or convenient for long use. My experience (not only with st) says that core fonts are harmful and unreliable. If you prefer a different expression, they suck. :) I wonder if there is any intention to use a different rendering tool? Most of the bugs have to do with X core fonts. st default font is the same as xterm/urxvt. Since it's also the one I use, it's the font with the best support. That being said, I _hate_ with passion Xlib, Xft and Xcore font system. It's either broken and obsolete or convolted to use, painful to write and modern documentation is nonexistant. Sometime, I manage to gather enough motivation to work on it, so I start by looking at rxvt-unicode code. Throughout the development of st I've looked at a lot of code and urxvt -- the rewrite of rxvt with unicode in mind -- is the most helpful. It uses a somewhat sane and readable subset of C++, works well with a lot of font rendering system and generally tries hard to please the user eg. looking for unicode chars in different fonts if it's not present on the current one. All of this by working around some of the most repulsive API ever made. I don't know how many developers are working on it but it's a lot of dedication. And _every time_ I get overwhelmed by this and just give up on st. I'm no font expert and I'm not especially interested by it. The only previous experience I had in this was SDL_ttf on one of my pet project, which is ridiculously simple and straightforward to use albeit not very fast I guess. st will never work as well as the next emulator as long as I limit myself to X11 core libs. It's just too much work and more importantly it will end up littered with boiler plate code and workaround of X11 apis. I won't do it. st has already too much of it. So if anyone has preference towards another font system, let's talk about it. A nice approach, not implying any dependency on Xft/fontconfig can be seen being used by http://www.etalabs.net/uuterm.html Wonder if this can be useful for st. The ytty font looks good. I'd like to know what everyone on the list thinks about this. I've come across uuterm several times. It's a good piece of software but having yet another font file format is too much imho. The work on unicode/input is impressive nonetheless. Thanks for working on suckless projects. Thank you for using them and for giving some feedback :)
Re: [dev] [st] Patch to remove color limit hardcoding
Actually, I think Anselm has not transferred by public key on the new host. I can't push my changes for now.
Re: [dev] [st] Scroll selection patch
I may tweak this later, but applied for now. Thanks!
Re: [dev] [st] openbsd port
On Sat, Sep 17, 2011 at 11:33 AM, Joerg Zinke m...@umaxx.net wrote: So my question is: are there any attempts made to push st.info to ncurses upstream? None. I think it won't be the nicest way because the terminfo entry is subject to change as some capacities are not implemented yet (see TODO). I think it's better to compile it with tic when installing for now.
Re: [dev] [st]100% cpu in some cases
On Sat, Sep 17, 2011 at 8:38 AM, Thuban thu...@singularity.fr wrote: So, here is the problem. St uses a lot of cpu with some apps that need refresh, such as top or mutt. The system becomes very slow, and Xorg show a 100% cpu. This problem only happen when I use the radeon driver, with firmware-linux-nonfree. I mean, there is no such problem without gpu acceleration (without firmware-linux-nonfree), or with the proprietary fglrx. As I don't experience this issue, I'll go with Kurt explanation. Try to run $ aafire -driver curses for some extreme fire action cpu usage.
Re: [dev] [st] bad focus
Ok, I'm back. On Sun, Sep 4, 2011 at 3:19 AM, ingol...@gmail.com wrote: According to the documentation[^1], the embedding application is supposed to send a ClientMessage XEvent with major opcodes of XEMBED_FOCUS_IN and XEMBED_FOCUS_OUT. I've attached a patch that should add detection of these events to st. Unfortunately, I'm unable to properly test them with tabbed because it seems tabbed doesn't send any XEMBED_FOCUS_OUT events. The current effect in tabbed is that the cursor is always shown, which seems an acceptable state until tabbed can be improved. This xembed client message seems to be the only thing vaguely standard concerning this focus issue thus I think tabbed should be patched to support it. Your C-fu is fine by me but like I've said before on this list, I'm no X wizard so if there's a problem in your X code I'm afraid I won't notice it. I'm applying your patch. Thanks :)
Re: [dev] [st] bad focus
Hi, I currently have no *nix computer at hand to test your patch. This behaviour was introduced to make focus work inside tabbed. It has the side effect your describing. I didn't find the right way to know whether the window has *keyboard* focus or not when it's embed. I you manage to make it work in every case I'll apply your patch.
Re: [dev] [st] shift-insert patch (more general: key.mask and state)
On Mon, Aug 1, 2011 at 6:32 PM, Aurélien Aptel aurelien.ap...@gmail.com wrote: I've used it in my patch attached to match XK_ANY_MOD. I'd like to have some feedback/testing before applying it. I've pushed my patch.
Re: [dev] [st] shift-insert patch (more general: key.mask and state)
On Mon, Aug 1, 2011 at 1:34 PM, anonymous p37si...@lavabit.com wrote: I think my patch is better. There is no special case for 0 mask and state and when we match for Ctrl and Shift it works only when they both are pressed. With your patch it will work for Ctrl only or for Shift only. When a key in config.h has mask = 0 it's matched with any modifier, not no modifier. Instead we could: #define XK_NO_MOD UINT_MAX #define XK_ANY_MOD 0 When numlock is on, each keypress has a state of 0x10. I suppose nobody actually use keybindings involving numlock so kmap() could clear the numlock mask from state before looking for a match in key[].
Re: [dev] [st] shift-insert patch (more general: key.mask and state)
On Mon, Aug 1, 2011 at 5:55 PM, Aurélien Aptel aurelien.ap...@gmail.com wrote: When numlock is on, each keypress has a state of 0x10. I suppose nobody actually use keybindings involving numlock so kmap() could clear the numlock mask from state before looking for a match in key[]. And handle the special case when mask = XK_NO_MOD. Also anonymous forgot to attach his second patch.
Re: [dev] [st] shift-insert patch (more general: key.mask and state)
On Mon, Aug 1, 2011 at 6:14 PM, anonymous p37si...@lavabit.com wrote: With my patch it is matched with any modifier too, because (key 0) == 0. Yes but it doesn't fix the problem of redefining what XK_Insert sends while keeping shift + insert to paste. I've used it in my patch attached to match XK_ANY_MOD. I'd like to have some feedback/testing before applying it. shift-insert-fix.diff Description: Binary data
Re: [dev] macos settings to use wmii in X11
Can you post your .xinitrc? How do you start X?
Re: [dev] macos settings to use wmii in X11
On Mon, Jul 25, 2011 at 9:25 PM, Jhonny Boy jhonny...@ymail.com wrote: Well I tried different .xinitrc right now I have : exec wmii I just try to launch X11 using the X11.app Is wmii in your PATH? Do you have any error/log when you start X? You need to be a lot more precise if you want some help.
Re: [dev] [st] mutt and cursor
It's definitely a bug in st. I'll fix this when I get home next week.
Re: [dev] Microsoft considers harmful...
On Tue, Jun 21, 2011 at 5:11 PM, hiro 23h...@googlemail.com wrote: I'm not dracula! Count Orlok then. Way more badass.
Re: [dev] Experimental editor
On Fri, Jun 10, 2011 at 9:54 AM, Rafa Garcia Gallego rafael.garcia.gall...@gmail.com wrote: I like the idea of structural regex, but I haven't used sam much. The match buffer sounds a bit emacs-y for my taste. I doubt emacs has something exactly like that; then again I am more of a vi(m) guy so emacs is really a myth for me. And a scary one at it. Good ol' M-x occur
Re: [dev] st - XEmbed patch
Ok I fixed it in tip. When st has its own window, focus change is notified with the FocusIn/FocusOut event. Now when st is embed, it just receives EnterNotify/LeaveNotify event.
Re: [dev] [st] revised mouse handling/reporting
On Fri, Jun 3, 2011 at 12:41 PM, Bert Münnich be...@gmx.com wrote: rxvt-unicode is a lot more simpler. It behaves in the same way as my patch: simply reversing the default fg and bg colors. All the others fg and bg colors remain untouched. ok A nice example to see the difference is alsamixer, which uses a black bg on the whole screen. My patched st and rxvt-unicode display it as black in normal and reverse mode, whereas xterm flips the background to white Your patch still doesn't make st behave like urxvt. See first screenshot attached. The problem is that st has no way to tell the default bg from black (if your default bg is black). See second screenshot attached. attachment: fail.png
Re: [dev] [st] revised mouse handling/reporting
oops, second screenshot attached. attachment: blackdefault.png
Re: [dev] [st] revised mouse handling/reporting
Thanks for all the patches :) I've created a new terminal states (MODE_xxx) for the different kind of mouse reporting instead of the global var. I've also removed the first MODE_MOUSE check from mousereport() since it's tested by every calling function that uses it. Tell me if everything works correctly.
Re: [dev] [st] Font issues
On Tue, May 31, 2011 at 3:08 PM, Bryan Bennett bbenn...@gmail.com wrote: terrible.[1] I've uploaded my config.h[2], but the line that should be the Also, I don't know if changing the value of TAB is recommended. I think it may lead to some strange bugs. Thus, we should move TAB definition to st.c
Re: [dev] [st] code cleanup
On Thu, May 26, 2011 at 12:32 PM, anonymous p37si...@lavabit.com wrote: Attached. Applied without the fputs/fputc. It's really not critical (performance wise) and inconsistent with the rest of the code.
Re: [dev] [st] alternate screen switching
On Wed, Jun 1, 2011 at 9:59 AM, Bert Münnich be...@gmx.com wrote:
Hi,
attached is a patch, that adds support for the deprecated '\E[?47h' and
'\E[?47l' control sequences, which are used when $TERM == xterm-color.
I've also added {rm,sm}cup entries to st.info, so that switching between
normal and alternate screen now works when $TERM == st[-256color].
Thanks.
What's the difference between 1047 and 47? st now use the same code
for both, but it can be changed.
I would also like to look into the scrollback buffer goal. How do you
want to achieve an unlimited scrollback buffer? Writing every line to a
file and printing its content instead of the current buffer when
scrolling back? What are the cons to just having a fixed amount of lines
(simply a bigger Line *line), memmoving them when input arrives and
normally displaying only the row-1 last ones?
It could be done that way, yes.
Personally, I don't need the scollback buffer but from what I've
gathered there are more people who want it than people who don't.
It's even written here http://st.suckless.org/goals
It would be great if st could export an interface to it so things
like URL selecting/launching in browser could be done via scripts.
Something like a plan9 file hierarchy. I would like to hear someone
else thoughts about that.
Re: [dev] [st] revised mouse handling/reporting
On Wed, Jun 8, 2011 at 10:17 PM, Bert Münnich be...@gmx.com wrote: I'm using a light background, so I didn't notice these differences--I guess I have to test things a bit more in the future... The problem is that st has no way to tell the default bg from black (if your default bg is black). See second screenshot attached. So there's no easy way of implementing the reverse video mode? I We have to change the way the default bg is stored. couldn't find a decent text, which describes what exactly has to be done in reverse video mode. The only thing I've found was the mention of using light on dark by default and dark on light when in reverse video. I've not look very far either, *but* it seems that RV is not really used like this anyway. The only time the escseq is mentioned in xterm terminfo entry is at the flash cap which, as its name suggest, just flash the screen by quickly enabling and disabling RV. ( \e[?5h\e[?5l ) But apart from it not working in the same way as xterm and urxvt, I think that my patch actually works kind of in the expected way. I've used it from time to time in the past few days and couldn't find a showstopper (again not really looking closely, only on light default bg). So we can use it for the moment or forget about it altogether, I'm fine with it. I don't know, what we could easily do to make it work in another way. I've reached the same conclusion, aka fuck that shit (i'm going to space [1]). 1: http://i.imgur.com/Jcn9Z.jpg
Re: [dev] st - XEmbed patch
New bug though. Once embed in tabbed, st seems to not always receive the focus event because the cursor is still hidden.
Re: [dev] [st] Statusline terminfo entries patch
Applied, thanks.
Re: [dev] [st] revised mouse handling/reporting
On Thu, Jun 2, 2011 at 2:28 PM, pancake panc...@youterm.com wrote: I wonder if those patches are going to be commited.. I find them right. But it's about the third patch in a week without any reply.. I've already committed some of them them locally, not finished yet. The reverse video one doesn't behave like xterm on my machine. /me pings Aurélien? I'm really busy right now (exams and reports deadline). It's almost finished : if everything goes right I'll be free next tuesday.
Re: [dev] [st] Font issues
There is a patch to support Xft somewhere (but it's slow). We have to re-implement the GLYPH_DIRTY trick to speed the rendering. On Tue, May 31, 2011 at 3:46 PM, Le Tian tiane...@gmail.com wrote: Well, when I got tired of urxvt, aterm and xterm, I switched to terminal and then sakura, both very lightweight and easy on your fonts, plus sakura uses gtk and vte. It's not exactly lightweight. transparency support. In my opinion st seems like not very stable now, If you found a bug, please report it. It's the only way we can fix it. moreover, it is slow, when comes to lines of code, Rendering is slow, I'll give you that. But for normal, day-to-day tasks, it's acceptable for me. As for the lines of code, what about them? and btw, I'm not sure there are ppl out here who actually use it that much;) ok.
Re: [dev] Sandy editor
On Fri, May 27, 2011 at 4:52 AM, John Matthewman jmatthew...@gmail.com wrote: Yea, probably a good idea (of course, ignoring Emacs' chained keybindings). Sandy would benefit from a better set of default bindings. Though for reference you might want to look at something like mg [http://www.openbsd.org/cgi-bin/man.cgi?query=mg], or one of the other micro Emacs implementations, as they'll have the most important bindings and commands, and you won't have to sift through all of the extra garbage that is Emacs. *Please*, use sane keybindings. Emacs and vi were made with a specific keyboard from the 70s in mind. A time were the hjkl keys had little arrows on them. A triangle layout (wqsd or ijkl for example) is much easier to type. Highly recommended readings from the (in?)famous Xah Lee: http://xahlee.org/emacs/keyboard_hardware_and_key_choices.html http://xahlee.org/kbd/vi_emacs_keybinding_design.html http://xahlee.org/comp/keyboard_shortcut_design.html Keyboard related (prepare for some time warp if you start reading): http://xahlee.org/Periodic_dosage_dir/keyboarding.html
Re: [dev] Sandy editor
On Fri, May 27, 2011 at 10:54 AM, Dieter Plaetinck die...@plaetinck.be wrote: how ironic you pledge for sane keybindings and suggest bindings optimized for qwerty users... I've used qwerty bindings for the example so anyone could follow. I don't use qwerty myself.
Re: [dev] Sandy editor
On Fri, May 27, 2011 at 8:26 PM, Noah Birnel nbir...@gmail.com wrote: Puke. Triangle layout may be more intuitive to learn for single char/line movement, but is probably not easier to type. Certainly not WASD layout, laying on the weak fingers of the left hand. wasd is only an example... Pick another triangle layout if this one doesn't suit you. Besides, I use the same fingers with hjkl and ijkl so I really don't know what you're talking about. Does anyone *know* what sane keybindings are? Vi seems less insane than most to me (once you restore @ and ESC to their 70's positions, and swap That's a good improvement. Update the default layout to the most common keyboard type: ibm pc keyboard clone.
Re: [dev] [st] maps window before setting the title, confuses dwm's matching
Applied, thanks.
Re: [dev] TermKit
On Fri, May 20, 2011 at 2:26 PM, Connor Lane Smith c...@lubutu.com wrote: I think the way to solve this problem is not to add structure to pipes (which tend to be simple to use *because* they have no real structure), but to allow commands to draw directly to the terminal if they wanted. So the standard input / output piping system would remain unchanged, and all commands -- except those which rely on unhygienic escape codes, like curses -- would work just like normal. rxvt implements basic drawing primitives via escape codes[1]. It's disabled at compile time by default but you can find some poc in the source distribution that plots stuff. I think it has been dropped in urxvt. It's ok for very simple stuff but I really don't think it's scalable for anything remotely useful. 1: http://www.usf.uos.de/infoservice/doc/localhtml/rxvt/refer.html#Graphics
Re: [dev] [st] Mouse usage in Vim
Mouse support is not implemented but it seems rather straightforward to do [1]. I'll have a look at it. 1: http://www.usf.uni-osnabrueck.de/infoservice/doc/localhtml/rxvt/refer.html#Mouse
Re: [dev] [st] Mouse usage in Vim
Ok, it's in tip. I have not modified st terminfo entry so be sure to test with $ TERM=xterm vim /tmp/foo Tell me if works correctly for you.
Re: [dev] Why dwm or wmii over xmonad, etc., or not?
On Fri, May 6, 2011 at 3:18 AM, Nathan Neff nathan.n...@gmail.com wrote: 2.5) Easy / sensible defaults. Sorry but Emacs-style shortcut keys are an oxymoron. Any window manager that uses Emacs Key Chords is immediately disqualified. With wmii you switch between windows and tags with 2 keystrokes max. It's a no-brainer. The default shortcut to close a window is really bad. Something used that often shouldn't be as complex as Mod-Shift-C.
Re: [dev] [dwm] devilspie doesn't work
hilarious argument about transparency that somehow derived to AIDS I love this mailing list. Leon Winter made a patch to support transparency in st few months ago [1]. It should'nt be hard to adapt it to tip if you want it. 1: http://lists.suckless.org/dev/1009/6046.html
[dev] [wmii][rumai] Error using default wmiirc
Hi,
I wanted to try the ruby wmiirc, so I followed the steps in the
README, installed latest wmii/libixp from the repo, installed rumai
3.3.1 (since wmiirc require 4), checkout the strict branch (default
config.yaml) and when I startx, I get this on the xmessage-thingy:
#Rumai::IXP::Error: bad value -- in reply to
#Rumai::IXP::Twrite:0x9575810
@fields=[#Rumai::IXP::Struct::Field:0x93e8a38 @name=:tag, @format=2,
@countee=nil, @counter=nil, #Rumai::IXP::Struct::Field:0x93b40f8
@name=:fid, @format=4, @countee=nil, @counter=nil,
#Rumai::IXP::Struct::Integer8Field:0x93b3be4 @name=:offset,
@format=8, @countee=nil, @counter=nil,
#Rumai::IXP::Struct::Field:0x93b3658 @name=:count, @format=4,
@countee=#Rumai::IXP::Struct::Field:0x93b3130 @name=:data,
@format=nil, @countee=nil,
@counter=#Rumai::IXP::Struct::Field:0x93b3658 ..., @counter=nil,
#Rumai::IXP::Struct::Field:0x93b3130 @name=:data, @format=nil,
@countee=nil, @counter=#Rumai::IXP::Struct::Field:0x93b3658
@name=:count, @format=4,
@countee=#Rumai::IXP::Struct::Field:0x93b3130 ..., @counter=nil],
@values={:fid=6, :offset=0, :count=25, :data=#00 #c1c48b
#81654f 1, :tag=1}
/usr/lib/ruby/gems/1.9.1/gems/rumai-3.3.1/lib/rumai/ixp/transport.rb:158:in
`block in recv'
/usr/lib/ruby/gems/1.9.1/gems/rumai-3.3.1/lib/rumai/ixp/transport.rb:121:in
`loop'
/usr/lib/ruby/gems/1.9.1/gems/rumai-3.3.1/lib/rumai/ixp/transport.rb:121:in
`recv'
/usr/lib/ruby/gems/1.9.1/gems/rumai-3.3.1/lib/rumai/ixp/transport.rb:176:in
`talk'
/usr/lib/ruby/gems/1.9.1/gems/rumai-3.3.1/lib/rumai/ixp/transport.rb:341:in
`write'
/usr/lib/ruby/gems/1.9.1/gems/rumai-3.3.1/lib/rumai/ixp/transport.rb:376:in
`block in write'
/usr/lib/ruby/gems/1.9.1/gems/rumai-3.3.1/lib/rumai/ixp/transport.rb:220:in
`open'
/usr/lib/ruby/gems/1.9.1/gems/rumai-3.3.1/lib/rumai/ixp/transport.rb:376:in
`write'
/usr/lib/ruby/gems/1.9.1/gems/rumai-3.3.1/lib/rumai/fs.rb:116:in `write'
/home/knarf/.wmii-hg/config.yaml:control:event:CreateTag:4:in `block in main'
/home/knarf/.wmii-hg/config.rb:34:in `call'
/home/knarf/.wmii-hg/config.rb:34:in `block in handle'
/home/knarf/.wmii-hg/config.rb:33:in `each'
/home/knarf/.wmii-hg/config.rb:33:in `handle'
/home/knarf/.wmii-hg/config.rb:53:in `event'
/home/knarf/.wmii-hg/wmiirc:63:in `block in main'
/home/knarf/.wmii-hg/wmiirc:63:in `each'
/home/knarf/.wmii-hg/wmiirc:63:in `main'
Re: [dev] [wmii][rumai] Error using default wmiirc
On Wed, Apr 27, 2011 at 9:00 PM, Suraj Kurapati sun...@gmail.com wrote: It seems you are using the ruby wmiirc that was shipped with wmii (which is ancient!) because the current ruby wmiirc on GitHub[1] no longer maintains the strict branch and requires Rumai 4.1.2, so try [1] instead. Yep, works better now, thanks :)
Re: [dev][st] Approach to adding -bg colour option to st
On Mon, Apr 25, 2011 at 12:03 PM, David Tweed david.tw...@gmail.com wrote:
(As
background, I currenlty use a hacked aterm which changes the
background colour according to the cwd. This works for changing hte
colours, but the codebase and aterms behaviour on resize is poor, so
long term I'd like to move to a better terminal codebase where I can
hack in my colour functionality.)
The simplest way to achieve this is to implement the xterm esc and
script your shell prompt so it prints the esc followed by your regular
prompt.
Not tested:
settermbg() {
echo -ne \e]49;$1\a
}
dirbg() {
case $PWD in
/mydir*) settermbg 1 ;;
/foobar*) settermbg 42 ;;
*)settermbg 0 ;;
esac
}
# the \$(cmd) in PS1 is probably bash-only
# maybe PROMPT_COMMAND is more portable
PS1=\$(dirbg)\u \w $
Re: [dev] [st] cleanup patch
On Tue, Apr 26, 2011 at 5:13 PM, anonymous p37si...@lavabit.com wrote: It would be also nice to remove debugging code from st.c: oops, it shouldn't be there sorry. Applied some of the cleanup.
Re: [dev][st] Approach to adding -bg colour option to st
On Tue, Apr 26, 2011 at 11:07 AM, Aurélien Aptel
aurelien.ap...@gmail.com wrote:
# the \$(cmd) in PS1 is probably bash-only
# maybe PROMPT_COMMAND is more portable
PS1=\$(dirbg)\u \w $
It seems you need to enclose non-printing characters in \[\] on bash
and %{%} on zsh.
So for bash: PS1=\[\$(dirbg)\] \u \w $
For zsh you have to setopt promptsubst in order to substiture \$(cmd), so:
setopt promptsubst
PS1=%{\$(dirbg)%}%n %~ $
Voilà. It works on urxvt and xterm, for the rest YMMV.
