Re: [dev] [st] 0.6 release
On Tue, Jul 7, 2015 at 10:56 PM, FRIGN 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 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] Windows binaries
On Thu, Apr 18, 2013 at 10:34 PM, Noah Birnel wrote: > Static linking needs mingw and I haven't done it. Considering you need X > for the 3 progs mentioned above, I've seen no point in carrying them > around to windows boxes without Cygwin. I don't remember which project had at one point an incomplete implementation of libx11 on top of windows primitives. All I can find now is this. Haven't tested it. http://libw11.sourceforge.net/index.html
Re: [dev] [st] wide characters
On Sat, Apr 13, 2013 at 11:17 PM, Random832 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 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 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 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@suckless.org
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 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
On Sun, Sep 16, 2012 at 12:38 PM, Roberto E. Vargas Caballero wrote: > Main use of this feature (actually) is only helping to debug. When you are > debugging escape sequences is very useful have the ascii sequence that some > program writes to the terminal. I don't know if you can get it with expect. If the only use is to debug it shouldn't be exposed to users and it's doesn't need to be fast. Besides there's already a dump() function you can modify/use. There is also this great tool called teseq [1] to debug escape sequences, I don't know if you've heard of it. Really handy. 1: https://www.gnu.org/software/teseq/
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 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 11:51 AM, Aurélien Aptel 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] Removing timeouts in main loop
On Sun, Sep 16, 2012 at 9:47 AM, Roberto E. Vargas Caballero 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] 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] interested in issue tracker dev
Let's bump this again. Someone might do something about it.
Re: [dev] Line artifacts ST
It looks like there's something wrong with the line height.
[dev] st development
Hi all, As I'm enrolled in Google Summer of Code until the end of summer, updates to st are unlikely. If someone is interested in working on it, ask Anselm for a write access to the repo. If you want some ideas, here are a few a the top of my head: * I think the Xdbe patch is interesting and should be integrated. Any experimentation to make the drawing faster while keeping the terminal logic separated from the drawing is welcome. As I've already said, I'm don't know much about X11. * There are also some bugfixes that have been posted on the list that I have not looked into which should probably be integrated as well. I'm thinking of the the new-output-but-not-refreshing bug which is annoying. * Improve xterm compatibility. * The selection code has to be cleaned up. I've started to commit some things locally but it's not finished. * Merge the Xft branch and refactor code in order to have one interface for both system. Improve the support for unusual glyph in a smart way (switch to another font is not present in the current one, etc). This can be tedious because you have to work around Xlib in weird ways. You can look at urxvt for implementation details. * Implement scrollback buffer. I've never needed this one but it's one of those thing where lot of people ask for it and it's not very hard to implement. * There's more in the TODO and README files.
Re: [dev] [st] selection problem
On Thu, Feb 23, 2012 at 10:02 AM, Martin Kopta 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 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 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 11:31 AM, Martin Kopta 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] terminal capability "cm" required
On Fri, Feb 17, 2012 at 11:18 AM, Aurélien Aptel 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 10:35 AM, Paul Onyschuk 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] Re: [st] 0.2.1 is out
On Thu, Feb 16, 2012 at 12:22 PM, Peter Hartman 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] [st] 0.2.1 is out
On Thu, Feb 16, 2012 at 7:18 PM, Andrew Hills 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] [st] 0.2.1 is out
On Thu, Feb 16, 2012 at 4:11 PM, Andrew Hills 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/.tar.gz http://hg.suckless.org/st/archive/0.2.1.tar.gz
[dev] Re: [st] 0.2.1 is out
On Thu, Feb 16, 2012 at 1:19 AM, Aurélien Aptel 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)
[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.
Re: [dev] ... and then i go and spoil it all by saying something stupid ...
Someone loves me on the internet! *hug back*
Re: [dev] [st] htop, tmux, terminfo
On Sun, Feb 12, 2012 at 9:15 AM, Martin Kopta 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 OS (was About escape sequences and stuff)
On Sat, Feb 11, 2012 at 9:32 PM, Jonathan Slark 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] Suckless.org Man page links
On Sat, Feb 11, 2012 at 5:54 PM, Anselm R Garbe 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] [st] 0.2 is out
On Wed, Feb 8, 2012 at 4:41 PM, ilf 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
Re: [dev] [st] 0.2 is out
On Wed, Feb 8, 2012 at 4:13 PM, Diego Joss 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 3:39 PM, Benjamin R. Haskell wrote: > rxvt-unicode uses the wonderful optimization of not really caring whether > everything gets displayed. As a test, simulate some command that produces > output that can't actually be read -- like from a noisy makefile, the > non-error output of TeX, or an accidental `find`: > > find / | sed 1q > ~/find1 > time cat ~/find1 > > uxterm takes 2.6 seconds to display text I can't possibly read. > urxvt finishes instantly, only taking 0.04 seconds of wall time. > st takes 50.1 seconds. st does the same thing now: cat ~/find1 0.00s user 0.03s system 37% cpu 0.089 total > If you're on the 'xft' branch, you'll need a different format, e.g.: > > #define XFT_FONT "Bitstream Vera Sans Mono-13" Curiously, the xft branch doesn't become unresponsive in the tmux scrolling case.
Re: [dev] [st] 0.2 is out
On Wed, Feb 8, 2012 at 2:49 PM, ilf 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 2:17 PM, ilf 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.
[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 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
...aaand the attachement. *sigh* slowtest.sh Description: Bourne shell script
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 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] new xft branch (FreeType font rendering)
On Fri, Jan 27, 2012 at 3:26 PM, Bryan Bennett wrote: > Just tested using cmus and ncurses line drawing characters seem to be the > problem. If I get a chance this evening/weekend, I'll look into seeing if I > can get a better idea of the problem (and maybe even patching in a solution, > if I'm feeling adventurous). st was using X11 core fonts special characters to draw line drawing chars. We should switch to unicode chars [1]. 1: http://en.wikipedia.org/wiki/Box-drawing_character
Re: [dev] [st] new xft branch (FreeType font rendering)
Oops. Applied, thanks.
Re: [dev] suckless vs. security? - Was: [slock] kill slock with Ctrl+Alt+Multiply
On Mon, Jan 23, 2012 at 10:59 AM, Nick wrote: > More generally, though, I agree, SSL is a good example of a > security technology which is well worth the additional > complexity. It's funny because OpenSSL -- probably the most used implementation of SSL -- is unreadable: http://corte.si//posts/code/reading-code.html
Re: [dev] [st] Drawing optimizations
On Sun, Jan 22, 2012 at 7:22 PM, Peter John Hartman 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
[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 - or :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] font help
On Mon, Jan 23, 2012 at 10:50 AM, Eckehard Berns 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.
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 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 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 > 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 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 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 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 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.
[dev] [st] Drawing optimizations
Hi, I know st rendering is slow. I'm currently trying out different solutions but I can tell you profiling X calls is no fun. tip now uses a simple dirty flag per line algorithm. Each modified line has the flag set to 1. Only dirty lines are drawn and once it's done their flag is set back to 0. I've noticed a significant speed up. I'll try more ideas in the near future.
Re: [dev] Some questions about st and a patch
On Tue, Oct 18, 2011 at 12:27 PM, pancake wrote:
> and type rm -rf ~ ; after the patch is applied
Thank you for your helpful{#`%${%&`+'${`%&NO CARRIER
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:14 PM, Aurélien Aptel 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
On Mon, Oct 17, 2011 at 5:06 PM, Connor Lane Smith 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
wrote:
> Excellent! I shoved this in st.c for now:
>
> 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] st bug report and feature request
Hi, Sorry for the late reply. On Sat, Sep 24, 2011 at 4:57 PM, 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] Patch to remove color limit hardcoding
On Wed, Oct 5, 2011 at 3:00 PM, Nick wrote: > A couple of people recently have wanted to set background > colours different to any colour in the main palette of 16. > > This patch allows that, and is generally sensible. Applied, thanks.
Re: [dev] [st] Scroll selection patch
I may tweak this later, but applied for now. Thanks!
Re: [dev] [st]100% cpu in some cases
On Sat, Sep 17, 2011 at 8:38 AM, Thuban 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] openbsd port
On Sat, Sep 17, 2011 at 11:33 AM, Joerg Zinke 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] bad focus
Ok, I'm back. On Sun, Sep 4, 2011 at 3:19 AM, 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 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] Fix terminfo op for light backgrounds
On Fri, Aug 12, 2011 at 4:05 PM, Rafa Garcia Gallego wrote: > Attached is a tiny change to st's terminfo entry to set 'op' (original > pair) to \E[39;49m. This is akin to what urxvt and xterm do, and fixes > some issues in certain curses apps (e.g. top) if your terminal had a > color scheme other than white on black. Applied, thanks.
Re: [dev] [st] shift-insert patch (more general: key.mask and state)
On Mon, Aug 1, 2011 at 6:14 PM, anonymous 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] [st] shift-insert patch (more general: key.mask and state)
On Mon, Aug 1, 2011 at 5:55 PM, Aurélien Aptel 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 1:34 PM, anonymous 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 , not . 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] macos settings to use wmii in X11
On Mon, Jul 25, 2011 at 9:25 PM, Jhonny Boy 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] macos settings to use wmii in X11
Can you post your .xinitrc? How do you start X?
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 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] fix segfault
Applied, thanks.
Re: [dev] [st] Statusline terminfo entries patch
Applied, thanks.
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] revised mouse handling/reporting
On Wed, Jun 8, 2011 at 10:17 PM, Bert Münnich 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
On Wed, Jun 8, 2011 at 8:38 PM, nodus cursorius wrote: > Very simple in design, an XEmbed patch for st. Felt this would be > useful for tabbed and remove my specific need for a terminal > multiplexer. See attachment. This can be useful. Applied and updated manpage/usage, thanks.
Re: [dev] [st] alternate screen switching
On Wed, Jun 1, 2011 at 9:59 AM, Bert Münnich 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] code cleanup
On Thu, May 26, 2011 at 12:32 PM, anonymous 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] Font issues
On Tue, May 31, 2011 at 3:08 PM, Bryan Bennett 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] Font issues
On Tue, May 31, 2011 at 3:08 PM, Bryan Bennett wrote: > I'm attempting to get st to use Dina as it's font. At first, I couldn't get > st to read the font at all (it would die upon launching, saying it couldn't > find the font), but I've had issues with Dina before - the CP1252 > encoding was giving urxvt problems a while back so I re-encoded it > (to ISO8859-1) and tried again. Now st will launch - but the font looks > terrible.[1] I've uploaded my config.h[2], but the line that should be the > problem is: > > #define FONT "-*-dina-medium-r-*-*-13-*-*-*-*-*-*-*" > #define BOLDFONT "-*-dina-bold-r-*-*-13-*-*-*-*-*-*-*" > > That font declaration works fine in urxvt, though - so I'm lost. Are there > obvious changes that need to be made that I'm apparently missing? Is > there some difference in the way that suckless is doing this that is > affecting the way fonts are rendered or am I just doing it wrong? I'm really not an expert on X11 and fonts. I barely managed to print text on a window with st. I don't know why your font doesn't work. Dina is only available in the form of a Windows© .fon from the author website so I guess all the conversion involved to get it working on X11 doesn't help. Post the font you're using here and I/someone will try to look into it.
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] revised mouse handling/reporting
oops, second screenshot attached. <>
Re: [dev] [st] revised mouse handling/reporting
On Fri, Jun 3, 2011 at 12:41 PM, Bert Münnich 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. <>
Re: [dev] [st] revised mouse handling/reporting
On Thu, Jun 2, 2011 at 2:28 PM, pancake 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 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 8:26 PM, Noah Birnel 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] Sandy editor
On Fri, May 27, 2011 at 10:54 AM, Dieter Plaetinck 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.
