Re: [dwm] [dvtm] scrollback and 256color support
On Thu, Aug 28, 2008 at 03:56:04PM -0700, Donald Chai wrote:
Thanks for the patches, scrollback is probably the most requested
dvtm feature. You introduced a separate buffer for the scrollback
data, did you consider allocating more space for the main buffer and
just adjusting the scroll_{top,bot} pointers and using them in
madtty_draw to draw only the currently visible area?
I did consider that, actually. Several reasons why I use a separate
buffer:
- From what I understand of vt100/xterm behavior, you can use DECSTBM
to
set the scrolling region. If the top line of the screen is *not* in the
scrolling region, you'd need to do some extra work to have text scroll
offscreen.
- The scrollback buffer is a circular buffer for runtime efficiency,
while the screen is a regular array.
- I'd like to add some kind of compression for the scrollback buffer
(e.g. run length encoding for character attributes, convert from wchar_t
using wcsrtombs).
Ok i see, makes sense. I have commited your patch and added the
possibility to set the size of the scroll back history buffer at
runtime. Hope I didn't screw it up ;)
Thanks,
Marc
--
Marc Andre Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dwm] dwm: request to discuss
2008/8/29, Anselm R Garbe [EMAIL PROTECTED]: I like simplicity. I like simple applications. But few LOCs don't mean that application is simple. It means only that it has few LOCs. I only argue that few LOCs is a good indicator of simplicty, not the only one, though. I see. To be simple application must be simple in use, simple in extensioning, simple in hacking, simple in configurating. In my opinion dwm as it is meets these ideals quite well. No doubt. Otherwise dwm would be different. Why you trying to escape just two optional operations of nav.? Let's be honest, it's not two operations in the end. Introducing workspaces means, that you need more than just navigation, you also need moving clients between workspaces, etc. Of course, I may be wrong. But for now I see just two ops: next and previous workspace. You don't need to move somehow a client between workspaces: you just need to use already exist ops---tag and untag. Workspace is just a set of settings such as selected tags, layout and layout parameters. You have such tags: www, mail, irc, im, dev. The most time you spend on developing something. But from time to time you want to check irc and mail, maybe serf smth. And all the time you want to see your im client. What you do? Untag www, mail, irc; tag dev; change layout; change order of windows... ouch. No no -- in this situation you define your im client being floating and tagged with all tags (~0). To check from time to time irc and mail you just toggle your irc and mail tags into the view -- you could bind a special key to do this -- and for toggling between this you can use Alt-Tab afterwards. The order of windows will be preserved if you Alt-Tab btw, as long as you do not perform zoom(). I understand all this as a workaround. Too much actions for me. I have already written about it: Mod+Tab switches between _two_ sets of tags. Just two and just tags. Binding a key via config.h makes it hardcoded, not dynamic. d in dwm stands for dynamic (; Now you have two workspaces/desktops: one for the Internet (irc, im, www, mail), another one for a work (dev, im). The first has rstack layout with corresponding master width and windows order. The second has bstack layout with an editor in master area and two terminals on the bottom: one is tagged as dev (for output, debug...), another one is tagged as im. Now you use just one key to change between these desktops. Each one is comfortable for its purposes. No need to rearrange windows and so on. Well you don't need a workspace for this. What you want is remembering the layout in use on a tagset basis. That's easy to patch in. It remembers just a layout? If yes, then again it is not what I want. Ok, you have two sets of tags and switch between them with a help of Mod+Tab and that patch makes dwm to remember layout per tags sets, right? Does it remember master width per sets? -- Hoc est simplicissimum! maxim.vuets.name
Re: [dwm] dwm hg
On Sat, Aug 30, 2008 at 08:39:05AM +0100, Filippo Erik Negroni wrote: From looking at the log, Anselm apparently has been working on branch 'merge', but forgot to integrate back into default ever since. When you clone, you are by default placed in the 'default' branch, which you can identify using $ hg identify Until Anselm integrates 'merge' into 'default', you can do either of two things: $ hg up merge or $ hg up -r tip Ever since I started using mercurial, there has been a debate whether named branches are a good thing. Mercurial originally was only supporting branching by cloning, which is what I always do (apart from using MQueues). -- Cheers, Filippo Thanks for the hg lesson, it was very helpful. -- James Turner BSD Group Consulting http://www.bsdgroup.org
Re: [dwm] dwm: request to discuss
2008/8/30 Maxim Vuets [EMAIL PROTECTED]: 2008/8/29, yy [EMAIL PROTECTED]: Just to show you (and all the people who come here asking for workspaces from time to time) I have attached a config.h with a workspaces implementation. It hasn't been tested very much, but I think it works. Now you can change workspace with Mod+Tab (and Mod+Shift+Tab) or with the mouse wheel on the tags. Cool patch. Thank you. Almost that I want (: Add to the wiki. -- Hoc est simplicissimum! maxim.vuets.name http://www.suckless.org:8000/dwm/patches/workspaces.html There was a bug in the config.h that I attached to my other message, it was not setting mfact to 0 for non tiled layouts. -- - yiyus || JGL .
Re: [dwm] dwm: request to discuss
On Sat, Aug 30, 2008 at 2:11 AM, Maxim Vuets [EMAIL PROTECTED] wrote: 2008/8/29, Matthias-Christian Ott [EMAIL PROTECTED]: Apache httpd with threads and mod_*.so, PAM... So every You are using Apache? Shame on you ;). Seriously Apache is definitively not suckless. (: propose something less sucker, please. I'll take a look. lighttpd - definitely sucks less Hmmm, I think threads make it just easier to write software that does several things concurrently. Makes easier to write? Oh man, I think you just have not ever write and debug real multi-threaded application (; Just for a note: yes, .so for dwm is evil. I've already said it. But unix-way IPC---looks not so bad, I think. Do you mean pipes or sockets? Pipe are definitely suckless. But this whole UNIX socket API sucks really. Yes, I meant pipes. I like pipes. Cannot understand why socket API sucks. -- Hoc est simplicissimum! maxim.vuets.name
Re: [dwm] dwm: request to discuss
On 8/30/08, Chris Monson [EMAIL PROTECTED] wrote: On Sat, Aug 30, 2008 at 2:11 AM, Maxim Vuets [EMAIL PROTECTED] wrote: 2008/8/29, Matthias-Christian Ott [EMAIL PROTECTED]: You are using Apache? Shame on you ;). Seriously Apache is definitively not suckless. (: propose something less sucker, please. I'll take a look. lighttpd - definitely sucks less try thttpd nhttpd hiawatha
Re: [dwm] dwm: request to discuss
If you are looking for a non-app-server http server, look for 'publicfile'. 2008/8/30 Antoni Grzymala [EMAIL PROTECTED] Chris Monson dixit (2008-08-30, 13:55): You are using Apache? Shame on you ;). Seriously Apache is definitively not suckless. (: propose something less sucker, please. I'll take a look. lighttpd - definitely sucks less Seems to be a bit of an urban legend. Both resource-wise and code-wise. -- [a] -- Cheers, Filippo
