Re: [dev] dwm 6.0 - separate taglists for muli-monitor setup
I recieved an off-list email yesterday from a guy with a patch for my problem. I will try it out and see how it works. Let me know if anyone else is interested in obtaining the patch and trying it. /David
[dev] 9base compilation error
Hi, I am trying to compile 9base, but the compiler throws an error at me which I've never seen before. /usr/bin/ld: cannot find -lm /usr/bin/ld: cannot find -lc Any ideas? I've checked config.mk and can't see any problems with it. Regards, David Lind
[dev] [st] double-width usage
Hello comrades, Here’s some RFC for people using double‐width characters in terminals in their daily life. Which applications do you use that handle double-width as you expect them? Do these applications use the double-width for the layout? Any Chinese or Japanese user? If double-width characters would be drawn to fit the standard cell size of the terminal (drawing them in half the font size) would this suffice your need? This question implies that it is possible to simply increase the average fontsize so the complex glyphs look good. Would this suffice your need? Naming the applications would be important so I can test st to their compatibility. Sincerely, Christoph Lohmann
Re: [dev] 9base compilation error
maybe: /usr/bin/ld: cannot find -lm /usr/bin/ld: cannot find -lc See 'man ld' : The linker is looking for library libc.a libm.a and doesn't find it. i think you need devel package or something On Tue, Apr 23, 2013 at 4:09 PM, David Lind dl...@itsatrap.se wrote: Hi, I am trying to compile 9base, but the compiler throws an error at me which I've never seen before. /usr/bin/ld: cannot find -lm /usr/bin/ld: cannot find -lc Any ideas? I've checked config.mk and can't see any problems with it. Regards, David Lind -- -- Alice Ferrazzi alice.ferra...@gmail.com
RE: [dev] dwm 6.0 - separate taglists for muli-monitor setup
Hey, I sure am! Can you maybe upload it somewhere public so everyone can access it? Thanks, Jente Van: David Lind Verzonden: 23-4-2013 10:08 Aan: dev mail list Onderwerp: Re: [dev] dwm 6.0 - separate taglists for muli-monitor setup I recieved an off-list email yesterday from a guy with a patch for my problem. I will try it out and see how it works. Let me know if anyone else is interested in obtaining the patch and trying it. /David
Re: [dev] [st] double-width usage
Hello, I use st also for read japanese, so i think i can be in the japanese user category. application used: tmux mutt moc music player irssi zathura as pdf viewer On Tue, Apr 23, 2013 at 4:07 PM, Christoph Lohmann 2...@r-36.net wrote: Hello comrades, Here’s some RFC for people using double‐width characters in terminals in their daily life. Which applications do you use that handle double-width as you expect them? Do these applications use the double-width for the layout? Any Chinese or Japanese user? If double-width characters would be drawn to fit the standard cell size of the terminal (drawing them in half the font size) would this suffice your need? This question implies that it is possible to simply increase the average fontsize so the complex glyphs look good. Would this suffice your need? i actually don't know how it will display the character, drawing them half in the font size... but if the character looks good why not Naming the applications would be important so I can test st to their compatibility. Sincerely, Christoph Lohmann -- -- Alice Ferrazzi alice.ferra...@gmail.com
Re: [dev] 9base compilation error
Hi Alice, I solved the problem by installing glibc-static. Regards, David Lind On Tue, 23 Apr 2013, Alice Ferrazzi wrote: maybe: /usr/bin/ld: cannot find -lm /usr/bin/ld: cannot find -lc See 'man ld' : The linker is looking for library libc.a libm.a and doesn't find it. i think you need devel package or something On Tue, Apr 23, 2013 at 4:09 PM, David Lind dl...@itsatrap.se wrote: Hi, I am trying to compile 9base, but the compiler throws an error at me which I've never seen before. /usr/bin/ld: cannot find -lm /usr/bin/ld: cannot find -lc Any ideas? I've checked config.mk and can't see any problems with it. Regards, David Lind -- -- Alice Ferrazzi alice.ferra...@gmail.com
RE: [dev] dwm 6.0 - separate taglists for muli-monitor setup
Hi, http://article.gmane.org/gmane.comp.misc.suckless/4230 This is the link that he gave me, seems legit. He was unsure if this patch would work with the current git head.. we'll just have to try it out. Regards, David Lind On Tue, 23 Apr 2013, Jente Hidskes wrote: Hey, I sure am! Can you maybe upload it somewhere public so everyone can access it? Thanks, Jente __ Van: David Lind Verzonden: 23-4-2013 10:08 Aan: dev mail list Onderwerp: Re: [dev] dwm 6.0 - separate taglists for muli-monitor setup I recieved an off-list email yesterday from a guy with a patch for my problem. I will try it out and see how it works. Let me know if anyone else is interested in obtaining the patch and trying it. /David
Re: [dev] [st] double-width usage
On Tue, Apr 23, 2013 at 09:07:14AM +0200, Christoph Lohmann wrote: Hello comrades, Hi Christoph, Here’s some RFC for people using double‐width characters in terminals in their daily life. Which applications do you use that handle double-width as you expect them? Do these applications use the double-width for the layout? Any Chinese or Japanese user? I use them all the time -- in irssi, vim, ncmpc, ... even mc (in filenames). I have no issues anywhere with xterm. Not sure what 'use double-width for the layout' means but mc has to deal with them somehow because the panels' layout doesn't break... If double-width characters would be drawn to fit the standard cell size of the terminal (drawing them in half the font size) would this suffice your need? This question implies that it is possible to simply increase the average fontsize so the complex glyphs look good. Would this suffice your need? Then the standard western character would be really huge... I currently use an 18px bitmap font (misc-fixed), wide characters taking two cells, and it's so-so -- they're readable and the size of western letters is still acceptable for my taste. I've mentioned this in a dead thread in the past [1]. I saw wide characters using just one standard cell in urxvt long time ago and it looked terrible. Naming the applications would be important so I can test st to their compatibility. Sincerely, Christoph Lohmann Again, thanks for working on this. Petr [1] http://lists.suckless.org/dev/1210/12748.html pgpFMbb8kBqdy.pgp Description: PGP signature
Re: [dev] [st] double-width usage
Christoph Lohmann dixit: Which applications do you use that handle double-width as you expect them? mksh and jupp (though I don’t use st). Do these applications use the double-width for the layout? It’s possible to use Unicode characters, halfwidth or fullwidth, to draw nice boxen in either. If double-width characters would be drawn to fit the standard cell size of the terminal (drawing them in half the font size) would this suffice your need? Absolutely not. You need to distinguish by wcwidth() on the first character whether a given glyph (including the combining characters following it) fits into a halfwidth character cell or into a fullwidth character cell, which is exactly the width of two adjacent halfwidth character cells. Treating fullwidth as halfwidth, or the other way around, will not work. Naming the applications would be important so I can test st to their compatibility. Hrm, a shell and a text editor aren’t that good examples then… and I don’t have any good mixed example textfiles at hand. Sorry. But just this might be a PoC: ┌──┤ U+00A9 ├──┐ │ │ │ ䷀ │ │ ䷀ ䷀ │ │ ䷀ ䷀䷀ ䷀ │ │ ䷀ ䷀ ䷀ │ │ ䷀ ䷀ ䷀ │ │ ䷀ ䷀䷀ ䷀ │ │ ䷀ ䷀ │ │ ䷀ │ └──┘ I’m writing textfiles like that pretty often, and I use the creative heaven and fullwidth space in my own font editing tools (mksh script to convert between that and BDF, while doing the actual editing in a text editor and/or with ed and shell scripts). bye, //mirabilos -- FWIW, I'm quite impressed with mksh interactively. I thought it was much *much* more bare bones. But it turns out it beats the living hell out of ksh93 in that respect. I'd even consider it for my daily use if I hadn't wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh
Re: [dev] [st] [PATCH] 8bit-meta like xterm
Greetings. On Tue, 23 Apr 2013 10:50:32 +0200 Otto Modinos ottomodi...@gmail.com wrote: Howdy Comrades. I'm new to this mailing list. Just found st couple of days back and really loved it. It lacked however the ability to send Meta as the 8th bit, the way xterm does. I needed this because most of the apps I tried didn't recognize the escape sequence st was using. So this little patch adds this. It can be enabled by setting meta8 to true in config.def.h and disabled at runtime with the -8 cmdline switch. Hope you can merge it in st mainline, or at least added in as a patch in the site. I am considering making this the default behaviour of st. Are there any arguments against it? Sincerely, Christoph Lohmann
Re: [dev] [st] double-width usage
On Tue, Apr 23, 2013 at 09:07:14AM +0200, Christoph Lohmann wrote: Which applications do you use that handle double-width as you expect them? I use mutt and vim which handle double-width characters the way I expect them to (using urxvt or lxterm). Do these applications use the double-width for the layout? Yes, I think they do. Any Chinese or Japanese user? I use Japanese regularly (Japanese Studies major; I am not Japanese though). Writing Japanese in Vim is not as easy as I would like it to be so I usually go for a non-modal editor for that use case. If double-width characters would be drawn to fit the standard cell size of the terminal (drawing them in half the font size) would this suffice your need? I think the characters would be squished to an unreadable degree, but I think I have never seen it done in practice. This question implies that it is possible to simply increase the average fontsize so the complex glyphs look good. Would this suffice your need? That would entail that everyone uses a certain (bigger) minimal font size if they want to be able to read width characters, no? Thank you for looking at this! I tried to hack wide-character support into st myself because when that is done, I will use it as my only terminal emulator. Cheers, Silvan
Re: [dev] [st] double-width usage
On 04/23/2013 03:07 AM, Christoph Lohmann wrote: Hello comrades, Here’s some RFC for people using double‐width characters in terminals in their daily life. Which applications do you use that handle double-width as you expect them? Do these applications use the double-width for the layout? Any Chinese or Japanese user? If double-width characters would be drawn to fit the standard cell size of the terminal (drawing them in half the font size) would this suffice your need? This question implies that it is possible to simply increase the average fontsize so the complex glyphs look good. Would this suffice your need? Naming the applications would be important so I can test st to their compatibility. Sincerely, Christoph Lohmann Did you see the st.c I posted a few days ago? The logic for double width is mostly complete in it - I just have to fix a few graphical glitches, and there are a couple of corner cases (mainly regarding erasing a double width character by overwriting with a single width when background colors are involved) that different terminals don't handle the same way, that it's not clear which terminal we should follow or if it's even important to emulate one particular behavior.
Re: [dev] [st] [PATCH] 8bit-meta like xterm
On 04/23/2013 04:50 AM, Christoph Lohmann wrote: I am considering making this the default behaviour of st. Are there any arguments against it? I'm actually confused by what he means by most of the apps I tried didn't recognize the escape sequence, because every app I've ever used recognizes it (which is simply to prefix a character with \033 to represent meta), no app I've ever used recognizes the 8-bit behavior, and an app expecting the 8th bit (which I've never seen) would not handle non-ascii text input properly.
Re: [dev] [st] [PATCH] 8bit-meta like xterm
It means first of all vim. I have also tried mocp, and that didn't work either. What apps are you using that work? On 23 April 2013 14:46, Random832 random...@fastmail.us wrote: On 04/23/2013 04:50 AM, Christoph Lohmann wrote: I am considering making this the default behaviour of st. Are there any arguments against it? I'm actually confused by what he means by most of the apps I tried didn't recognize the escape sequence, because every app I've ever used recognizes it (which is simply to prefix a character with \033 to represent meta), no app I've ever used recognizes the 8-bit behavior, and an app expecting the 8th bit (which I've never seen) would not handle non-ascii text input properly.
Re: [dev] [st] [PATCH] 8bit-meta like xterm
On Tue, Apr 23, 2013 at 10:50:32AM +0200, Christoph Lohmann wrote: Greetings. On Tue, 23 Apr 2013 10:50:32 +0200 Otto Modinos ottomodi...@gmail.com wrote: Howdy Comrades. I'm new to this mailing list. Just found st couple of days back and really loved it. It lacked however the ability to send Meta as the 8th bit, the way xterm does. I needed this because most of the apps I tried didn't recognize the escape sequence st was using. So this little patch adds this. It can be enabled by setting meta8 to true in config.def.h and disabled at runtime with the -8 cmdline switch. Hope you can merge it in st mainline, or at least added in as a patch in the site. I am considering making this the default behaviour of st. Are there any arguments against it? The unique problem is utf8 encoding will put the 8 bit to 1 in some characters, so it is not very clear for me like applications can difference between meta-character and first byte of a utf8 sequence. I can see that terminfo has the following fields: km: Has a meta key rmm: turn off meta mode smm: turn on meta mode And the information about them is: If the terminal has a ``meta key'' which acts as a shift key, setting the 8th bit of any character transmitted, this fact can be indicated with km. Otherwise, software will assume that the 8th bit is parity and it will usually be cleared. If strings exist to turn this ``meta mode'' on and off, they can be given as smm and rmm. xterm has km capability but doesn't have rmm or smm. I suppouse that applications should look in km and doesn't translate if not km. The page http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/meta-bit.html says: xterm itself has relatively little understanding of complex character sets: it operates either in conventional 8bit mode or in UTF-8 mode. In the former, the character set is assumed to be single-byte and the Meta key translates each low-half character into its high-half counterpart in the obvious way. In the latter mode, the Meta key translates ASCII into ISO-8859-1 and then encodes it as UTF-8 (so that, for example, Meta-a sends C3 A1 which is the UTF-8 encoding of U+00E1). xterm supports all other character sets by interposing luit, which means that whether a Meta combination generates anything in (say) Shift-JIS will depend entirely on whether the relevant Unicode value between U+0080 and U+00FF is representable in the target character set. Meanwhile, Meta appears to do nothing at all if combined with anything not in the 00-7F range, be it a character outside that range or a multi-character sequence from a function key. Too much complex for me. I think is better by default send ESC, and add some sequences for rmm and smm (of course add rmm to is2). If a user want activate meta8 mode only has to write: tput smm. And in this case he should know that applications he is using don't deal with utf8 encoding.
Re: [dev] [st] [PATCH] 8bit-meta like xterm
On Tue, Apr 23, 2013 at 02:51:58PM +0300, Otto Modinos wrote: It means first of all vim. I have also tried mocp, and that didn't work either. What apps are you using that work? All the applications which admit a meta-key should accept 8bit, that is the real meaning of meta. Send ESC instead of meta is a GNUish that became very useful when utf8 came, because allows send meta characters in a easy way. This is the reason because today is more common use ESC. You can adjust readline (and it means all the GNU applications ...) using convert-meta, enable-meta-key, input-meta and output-meta variables in .inputrc. Best regards,
Re: [dev] [st] [PATCH] 8bit-meta like xterm
On Tue, Apr 23, 2013, at 7:51, Otto Modinos wrote: It means first of all vim. I have also tried mocp, and that didn't work either. What apps are you using that work? Huh? Vim doesn't have any keybindings that use meta. Wait a minute... what exactly do you _expect_ meta to do? Using (for example) meta-a to type 0xE1 a with acute is _not_, in fact, the expected or intended behavior; it is a bug. And I don't think it will even work with UTF-8 applications, and st is an exclusively UTF-8 terminal. What I expect meta to do is for example in irssi meta-a goes to the next window with activity, meta-1 goes to window 1, etc. -- Random832
Re: [dev] [st] [PATCH] 8bit-meta like xterm
On Tue, Apr 23, 2013 at 08:23:22AM -0400, random...@fastmail.us wrote: Huh? Vim doesn't have any keybindings that use meta. You can bind them.
Re: [dev] [st] [PATCH] 8bit-meta like xterm
No I mean when binding a key to meta, it doesn't work. I have M-j and M-k for example to move lines up and down and well, it doesn't work when sending an escape sequence as meta. On 23 April 2013 15:23, random...@fastmail.us wrote: ** On Tue, Apr 23, 2013, at 7:51, Otto Modinos wrote: It means first of all vim. I have also tried mocp, and that didn't work either. What apps are you using that work? Huh? Vim doesn't have any keybindings that use meta. Wait a minute... what exactly do you _expect_ meta to do? Using (for example) meta-a to type 0xE1 a with acute is _not_, in fact, the expected or intended behavior; it is a bug. And I don't think it will even work with UTF-8 applications, and st is an exclusively UTF-8 terminal. What I expect meta to do is for example in irssi meta-a goes to the next window with activity, meta-1 goes to window 1, etc. -- Random832
Re: [dev] [st] [PATCH] 8bit-meta like xterm
Greetings. On Tue, 23 Apr 2013 15:23:59 +0200 Roberto E. Vargas Caballero k...@shike2.com wrote: On Tue, Apr 23, 2013 at 10:50:32AM +0200, Christoph Lohmann wrote: The unique problem is utf8 encoding will put the 8 bit to 1 in some characters, so it is not very clear for me like applications can difference between meta-character and first byte of a utf8 sequence. I can see that terminfo has the following fields: km: Has a meta key rmm: turn off meta mode smm: turn on meta mode And the information about them is: If the terminal has a ``meta key'' which acts as a shift key, setting the 8th bit of any character transmitted, this fact can be indicated with km. Otherwise, software will assume that the 8th bit is parity and it will usually be cleared. If strings exist to turn this ``meta mode'' on and off, they can be given as smm and rmm. xterm has km capability but doesn't have rmm or smm. I suppouse that The terminfo of my system has smm=\E[?1034h rmm=\E[?1034l I’ve implemented it that way in st plus (as discussed on IRC) do the re‐ set capabilities now unset 8bit mode. For the Op: Please try now, if your applications behave as expected when using tput smm beforehand. Sincerely, Christoph Lohmann
Re: [dev] [st] [PATCH] 8bit-meta like xterm
Using the latest from git and tput smm everything works fine. Thank you very much. That got me wondering though. Since there exists such a terminfo capability, why do apps that except 8bit-as-meta, don't use them? On 23 April 2013 16:23, Christoph Lohmann 2...@r-36.net wrote: Greetings. On Tue, 23 Apr 2013 15:23:59 +0200 Roberto E. Vargas Caballero k...@shike2.com wrote: On Tue, Apr 23, 2013 at 10:50:32AM +0200, Christoph Lohmann wrote: The unique problem is utf8 encoding will put the 8 bit to 1 in some characters, so it is not very clear for me like applications can difference between meta-character and first byte of a utf8 sequence. I can see that terminfo has the following fields: km: Has a meta key rmm: turn off meta mode smm: turn on meta mode And the information about them is: If the terminal has a ``meta key'' which acts as a shift key, setting the 8th bit of any character transmitted, this fact can be indicated with km. Otherwise, software will assume that the 8th bit is parity and it will usually be cleared. If strings exist to turn this ``meta mode'' on and off, they can be given as smm and rmm. xterm has km capability but doesn't have rmm or smm. I suppouse that The terminfo of my system has smm=\E[?1034h rmm=\E[?1034l I’ve implemented it that way in st plus (as discussed on IRC) do the re‐ set capabilities now unset 8bit mode. For the Op: Please try now, if your applications behave as expected when using tput smm beforehand. Sincerely, Christoph Lohmann
Re: [dev] [st] [PATCH] 8bit-meta like xterm
random...@fastmail.us dixit: Wait a minute... what exactly do you _expect_ meta to do? Using (for example) meta-a to type 0xE1 a with acute is _not_, in fact, the expected or intended behavior; it is a bug. And I don't think it will No, it is the intended behaviour. http://fsinfo.noone.org/~abe/typing-8bit.html even work with UTF-8 applications, and st is an exclusively UTF-8 terminal. XTerm handles that transparently: when in UTF-8 mode, Meta-d is still CHR$(ASC(d)+128) = ä, just U+00E4 instead of a raw '\xE4' octet. This is *extremely* useful – especially as it leads people away from national keyboard layouts towards QWERTY while retainig the ability to write business eMails, which require correct spelling. bye, //mirabilos -- 17:57 jtsn Der 25C3 ist lustig. Deutsche Vortragende brechen sich vor deutschen Zuhörern auf Englisch einen ab. ;-) 18:01 jtsn Adolfs Werk war sehr nachhaltig. ;-)18:01 jtsn Das gab's nichtmal in der DDR, das Deutsche mit Deutschen auf Russisch reden. ;-) (10x cnuke@)
RE: [dev] dwm 6.0 - separate taglists for muli-monitor setup
Hi, This looks simple, though not something I could have come up with myself. I don't need the nametag function, so personally I'm going to remove it. It should not be too hard to tweak this for applying to git; it's a small patch. Too bad that at the moment I don't have a second monitor to test this with, but I'm going to apply it to my DWM regardless. I will report back later. Cheers, Jente Date: Tue, 23 Apr 2013 09:29:19 +0200 From: dl...@itsatrap.se To: dev@suckless.org Subject: RE: [dev] dwm 6.0 - separate taglists for muli-monitor setup Hi, http://article.gmane.org/gmane.comp.misc.suckless/4230 This is the link that he gave me, seems legit. He was unsure if this patch would work with the current git head.. we'll just have to try it out. Regards, David Lind On Tue, 23 Apr 2013, Jente Hidskes wrote: Hey, I sure am! Can you maybe upload it somewhere public so everyone can access it? Thanks, Jente __ Van: David Lind Verzonden: 23-4-2013 10:08 Aan: dev mail list Onderwerp: Re: [dev] dwm 6.0 - separate taglists for muli-monitor setup I recieved an off-list email yesterday from a guy with a patch for my problem. I will try it out and see how it works. Let me know if anyone else is interested in obtaining the patch and trying it. /David
Re: [dev] [st] [PATCH] 8bit-meta like xterm
On Tue, Apr 23, 2013, at 10:30, Thorsten Glaser wrote: random...@fastmail.us dixit: Wait a minute... what exactly do you _expect_ meta to do? Using (for example) meta-a to type 0xE1 a with acute is _not_, in fact, the expected or intended behavior; it is a bug. And I don't think it will No, it is the intended behaviour. http://fsinfo.noone.org/~abe/typing-8bit.html The fact that someone discovered it, _thought_ it was intended, and showed other people how to do it does not mean that it actually was intended. even work with UTF-8 applications, and st is an exclusively UTF-8 terminal. XTerm handles that transparently: when in UTF-8 mode, Meta-d is still CHR$(ASC(d)+128) = ä, just U+00E4 instead of a raw '\xE4' octet. If this were an intended feature why would it elevate latin-1 over other unicode characters? This only proves my point. This is *extremely* useful – especially as it leads people away from national keyboard layouts towards QWERTY while retainig the ability to write business eMails, which require correct spelling. And what the heck is wrong with national keyboard layouts that it's useful to lead people away from them?
Re: [dev] [st] double-width usage
On Tue, Apr 23, 2013 at 1:42 PM, Random832 random...@fastmail.us wrote: Did you see the st.c I posted a few days ago? The logic for double width is mostly complete in it - I just have to fix a few graphical glitches, and there are a couple of corner cases (mainly regarding erasing a double width character by overwriting with a single width when background colors are involved) that different terminals don't handle the same way, that it's not clear which terminal we should follow or if it's even important to emulate one particular behavior. I saw, compiled and tested it but when using mutt only half of the (Japanese Kanji) characters would be drawn (so presumably only one character cell of a two-cell double character). If I wasn't at a conference I would deliver some screenshots but as things stand, I can only get back to you after I am back home in a few days.
Re: [dev] [st] double-width usage
On Tue, Apr 23, 2013, at 11:01, Silvan Jegen wrote: I saw, compiled and tested it but when using mutt only half of the (Japanese Kanji) characters would be drawn (so presumably only one character cell of a two-cell double character). If I wasn't at a conference I would deliver some screenshots but as things stand, I can only get back to you after I am back home in a few days. Don't worry about screenshots, I know what it looks like. That is the graphical glitch I was referring to (along with being left-aligned). I'm considering possible ways to fix it - but all I can think of is to rewrite the entire drawregion function to draw all backgrounds first and then all characters.
Re: [dev] [st] [PATCH] 8bit-meta like xterm
On Tue, Apr 23, 2013 at 02:30:29PM +, Thorsten Glaser wrote: [...] XTerm handles that transparently: when in UTF-8 mode, Meta-d is still CHR$(ASC(d)+128) = ä, just U+00E4 instead of a raw '\xE4' octet. This is *extremely* useful – especially as it leads people away from national keyboard layouts towards QWERTY while retainig the ability to write business eMails, which require correct spelling. [...] Just use us intl-unicode as your keymap. That way, the right alt key becomes alt graph and two additional layers with diacritical characters are added to your keyboard layout. Works fine with st, and the regular Left alt sends escape-behaviour stays the same (and works fine with irssi and the like). -- Gregor Best
Re: [dev] dwm 6.0 - separate taglists for muli-monitor setup
there is nothing keeping you from commiting this patch to the patches site http://git.suckless.org/sites/tree/dwm.suckless.org/patches On Tue, Apr 23, 2013 at 10:39 AM, Jente Hidskes jthids...@outlook.com wrote: Hi, This looks simple, though not something I could have come up with myself. I don't need the nametag function, so personally I'm going to remove it. It should not be too hard to tweak this for applying to git; it's a small patch. Too bad that at the moment I don't have a second monitor to test this with, but I'm going to apply it to my DWM regardless. I will report back later. Cheers, Jente Date: Tue, 23 Apr 2013 09:29:19 +0200 From: dl...@itsatrap.se To: dev@suckless.org Subject: RE: [dev] dwm 6.0 - separate taglists for muli-monitor setup Hi, http://article.gmane.org/gmane.comp.misc.suckless/4230 This is the link that he gave me, seems legit. He was unsure if this patch would work with the current git head.. we'll just have to try it out. Regards, David Lind On Tue, 23 Apr 2013, Jente Hidskes wrote: Hey, I sure am! Can you maybe upload it somewhere public so everyone can access it? Thanks, Jente __ Van: David Lind Verzonden: 23-4-2013 10:08 Aan: dev mail list Onderwerp: Re: [dev] dwm 6.0 - separate taglists for muli-monitor setup I recieved an off-list email yesterday from a guy with a patch for my problem. I will try it out and see how it works. Let me know if anyone else is interested in obtaining the patch and trying it. /David
RE: [dev] dwm 6.0 - separate taglists for muli-monitor setup
Actually, I have a question: does this work with the client rules? From: jthids...@outlook.com To: dev@suckless.org Subject: RE: [dev] dwm 6.0 - separate taglists for muli-monitor setup Date: Tue, 23 Apr 2013 16:39:23 +0200 Hi, This looks simple, though not something I could have come up with myself. I don't need the nametag function, so personally I'm going to remove it. It should not be too hard to tweak this for applying to git; it's a small patch. Too bad that at the moment I don't have a second monitor to test this with, but I'm going to apply it to my DWM regardless. I will report back later. Cheers, Jente Date: Tue, 23 Apr 2013 09:29:19 +0200 From: dl...@itsatrap.se To: dev@suckless.org Subject: RE: [dev] dwm 6.0 - separate taglists for muli-monitor setup Hi, http://article.gmane.org/gmane.comp.misc.suckless/4230 This is the link that he gave me, seems legit. He was unsure if this patch would work with the current git head.. we'll just have to try it out. Regards, David Lind On Tue, 23 Apr 2013, Jente Hidskes wrote: Hey, I sure am! Can you maybe upload it somewhere public so everyone can access it? Thanks, Jente __ Van: David Lind Verzonden: 23-4-2013 10:08 Aan: dev mail list Onderwerp: Re: [dev] dwm 6.0 - separate taglists for muli-monitor setup I recieved an off-list email yesterday from a guy with a patch for my problem. I will try it out and see how it works. Let me know if anyone else is interested in obtaining the patch and trying it. /David
Re: [dev] [st] [PATCH] 8bit-meta like xterm
No, it is the intended behaviour. http://fsinfo.noone.org/~abe/typing-8bit.html The fact that someone discovered it, _thought_ it was intended, and showed other people how to do it does not mean that it actually was intended. It is the expected behaviour. As far as I know the first keyboard with meta key was space-cadet keyboard (look it in http://en.wikipedia.org/wiki/File:Space-cadet.jpg), which has meta, control, super, hyper and shift modificator in order can generate all the possible symbols, like for example greek symbols (I don't know how it encoded them). When Stallman wrote emacs he uses the non ascii keys like bindings, but the original function of these keys was only generate the values. In a moderm ascii machine the keys mean: - Shift: reset bit 5 - Control: reset bits 7-5 - meta: set bit 7 - super: (I don't know what did this key) - hyper: (I don't know what did this key) Because ascii was designed in this way, all the control codes are placed in 0-20, A is 41 while a is 61. And you can use meta key for generating iso8859-1 symbols (in the beginning was the unique way), if you know what key has the same value except upper bit. Using meta key for this task is obsolete today, because keyboard controller today work with shift-layout and they don't give a meaning to the modifier, only allow access to other different layout, where you can put the keycodes you want. Other point here is that in pc keyboard there isn't a meta key and usually alt key is used like meta key. XTerm handles that transparently: when in UTF-8 mode, Meta-d is still CHR$(ASC(d)+128) = ä, just U+00E4 instead of a raw '\xE4' octet. Xterm has the Xresources altIsNotMeta, metaSendsEscape and alt altSendsEscape, eightBitInput, eightBitMeta and eightBitOutput that allow you define how you want alt/meta key works. If your xterm generates 8bit meta codes you have it configured for it (or maybe your xterm has a different default configuration mine has). If this were an intended feature why would it elevate latin-1 over other unicode characters? This only proves my point. This is *extremely* useful – especially as it leads people away from national keyboard layouts towards QWERTY while retainig the ability to write business eMails, which require correct spelling. I think it is easier a compose key, which allows you define non ascii characteres using keystrokes (compose-key ' a - á). This is the solution I use in my USA keyboard and could generate spanish accents. And what the heck is wrong with national keyboard layouts that it's useful to lead people away from them? In my case I use a special keyboard which hasn't support for my national layout. Best regards,
Re: [dev] [st] [PATCH] 8bit-meta like xterm
Gregor Best dixit: are added to your keyboard layout. Works fine with st, and the regular Left alt sends escape-behaviour stays the same (and works fine with irssi and the like). On the BSD text console and in default XTerm, the left Alt key acts as 8-bit enabling Meta key, so it’s *not* the same. (Also, I invested large effort to draft a keyboard layout based on this for Windows®, Linux®, XFree86®, etc.) bye, //mirabilos -- [00:02] Vutral gecko: benutzt du emacs ? [00:03] gecko nö [00:03] gecko nur n normalen mac [00:04] Vutral argl [00:04] Vutral ne den editor -- Vutral und gecko2 in #deutsch (NB: Editor? Betriebssystem.)
Re: [dev] [st] [PATCH] 8bit-meta like xterm
random...@fastmail.us dixit:
If this were an intended feature why would it elevate latin-1 over other
unicode characters? This only proves my point.
It doesn’t – it’s just that latin1 is the first 256 chars of Unicode
by accident (or design, don’t know, ask the Unicode people).
And this Meta/8bit thing predates Unicode.
And what the heck is wrong with national keyboard layouts that it's
useful to lead people away from them?
/?\|[]{}';:-_=+
bye,
//mirabilos
--
Yay for having to rewrite other people's Bash scripts because bash
suddenly stopped supporting the bash extensions they make use of
-- Tonnerre Lombard in #nosec
Re: [dev] [st] [PATCH] 8bit-meta like xterm
Greetings. On Tue, 23 Apr 2013 17:49:38 +0200 Thorsten Glaser t...@mirbsd.de wrote: Gregor Best dixit: are added to your keyboard layout. Works fine with st, and the regular Left alt sends escape-behaviour stays the same (and works fine with irssi and the like). On the BSD text console and in default XTerm, the left Alt key acts as 8-bit enabling Meta key, so it’s *not* the same. (Also, I invested large effort to draft a keyboard layout based on this for Windows®, Linux®, XFree86®, etc.) Do you regret the wasted time? Sincerely, Christoph Lohmann
[dev] [st] colors and attributes, general question
I'm planning on reworking xdraws and drawregion to draw the background and text as separate functions. To do this I need to understand some things: As I understand it, the behavior is to have all attribute effects on color (e.g. bold brightening, italic/underline colors) affect only the foreground and not the background when in normal mode, and affect only the background and not the foreground in reverse (ATTR_REVERSE) mode. Is this understanding correct? As I understand it, the behavior for MODE_REVERSE is to use RGB color inversion, and not bg/fg swapping (so yellow-on-red becomes blue-on-cyan, not red-on-yellow) , on all colors _except_ for the default bg/fg colors. Is this understanding correct? Is the above outlined behavior actually correct by the standards / desirable / does it match the behavior of other terminals? config.def.h says Another logic would only make the simple feature too complex. but I find that in making this change supporting the current behavior (my understanding as outlined above) is actually more complex (because it requires me to duplicate attribute color mapping in both functions) There is also, as far as I can tell, no support for brightening the background for ATTR_BLINK. -- Random832
Re: [dev] [st] [PATCH] 8bit-meta like xterm
Roberto E. Vargas Caballero dixit: It is the expected behaviour. As far as I know the first keyboard with meta key was space-cadet keyboard (look it in Ah okay, thanks for the historic backup! meta codes you have it configured for it (or maybe your xterm has a different default configuration mine has). Probably. I think it is easier a compose key, which allows you define non ascii characteres using keystrokes (compose-key ' a - á). This is the solution I use in my USA keyboard and could generate spanish accents. Sure, that works too, and I use it for things like ① but Compose takes three keystrokes (up to five) sequentially, while Meta takes two or three in parallel (the “up to” is the shift key). The nice thing about ASCII and the QWERTY layout is that it has all ASCII characters easily available, so you can enter *all* latin1-subset-of-Unicode characters with just it. (In X11, I have additional mappings for stuff like € and … for which I used that “Caps Lock” key ☺). bye, //mirabilos -- Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL. -- Henry Nelson, March 1999
Re: [dev] [st] [PATCH] 8bit-meta like xterm
The nice thing about ASCII and the QWERTY layout is that it has all ASCII characters easily available, so you can enter *all* latin1-subset-of-Unicode characters with just it. Because all the latin1 symbols begin from a0, that is the smaller value you can generate using a meta key, because 20 first ascii codes are control codes, and you have to generate them using a control combination. Like I said in other mail, this was the original function of meta, and this is the reason latin1 (or iso8859-1) was designed in this way. A funny point is that older keyboard generated all these combinations by hardware, conecting to earth or vcc the lines, so it was very simple design them.
Re: [dev] [st] colors and attributes, general question
Greetings. On Tue, 23 Apr 2013 17:53:47 +0200 random...@fastmail.us wrote: I'm planning on reworking xdraws and drawregion to draw the background and text as separate functions. To do this I need to understand some things: As I understand it, the behavior is to have all attribute effects on color (e.g. bold brightening, italic/underline colors) affect only the foreground and not the background when in normal mode, and affect only the background and not the foreground in reverse (ATTR_REVERSE) mode. Is this understanding correct? ATTR_REVERSE only affects the colors. As I understand it, the behavior for MODE_REVERSE is to use RGB color inversion, and not bg/fg swapping (so yellow-on-red becomes blue-on-cyan, not red-on-yellow) , on all colors _except_ for the default bg/fg colors. Is this understanding correct? MODE_REVERSE is – like it’s name – the reverse of all colors. This is done exactly, except for the default bg and fg, which people configure as being the default fg and default bg. Is the above outlined behavior actually correct by the standards / desirable / does it match the behavior of other terminals? config.def.h says Another logic would only make the simple feature too complex. but I find that in making this change supporting the current behavior (my understanding as outlined above) is actually more complex (because it requires me to duplicate attribute color mapping in both functions) It’s the simple way of doing all the brigthening and reversing. St is keeping to what other terminals do. But since none of them keeps to any standard colors or good behaviour is this what makes st being what it is – a simple terminal. There is also, as far as I can tell, no support for brightening the background for ATTR_BLINK. ATTR_BLINK is by definition not implemented. There shouldn’t be any pseudo color highlight for it; when it’s implemented it should be right. The drawing function shouldn’t be interested in the unused attribute bits. Sincerely, Christoph Lohmann
Re: [dev] [st] colors and attributes, general question
On Tue, Apr 23, 2013, at 11:53, Christoph Lohmann wrote: It’s the simple way of doing all the brigthening and reversing. St is keeping to what other terminals do. But since none of them keeps to any standard colors or good behaviour is this what makes st being what it is – a simple terminal. My point was, it's only the simple way when you've already got both colors calculated because the function draws both. But if drawing backgrounds is moved into a separate function, as I was planning to do, that function would be simpler if it didn't have to think about the effects that bold/italic/underline have on the foreground color. My question was whether this behavior is like this because other terminals do the same thing, or _only_ because it's simpler.
Re: [dev] dwm 6.0 - separate taglists for muli-monitor setup
2013/4/22 Carlos Torres vlaadbr...@gmail.com It has been argued before that the use of named tags is somewhat a misunderstanding of dwm. Yeah, it's was a misnomer. Personally, I was thinking about workspaces, but I always called it tags. Anyway, Jente, did you try it with statuscolors and / or pertag? Kind Regards -- H.Mo.
Re: [dev] [st] [PATCH] 8bit-meta like xterm
Thorsten Glaser writes: I think it is easier a compose key, which allows you define non ascii characteres using keystrokes (compose-key ' a - á). This is the solution use in my USA keyboard and could generate spanish accents. Sure, that works too, and I use it for things like ① but Compose takes three keystrokes (up to five) sequentially, while Meta takes two or three in parallel (the “up to” is the shift key). Well, you can define multiple compose keys to make things easier. I used to have ' ` ^ generate dead accents, so I could get most accented characters in just two keystrokes (e.g., ' e → é), while using the compose key for other things (math symbols, typography, Greek letters…). I don’t do that anymore, since typing ' ' to get a single ' is too hard to get used to. The nice thing about ASCII and the QWERTY layout is that it has all ASCII characters easily available, so you can enter *all* latin1-subset-of-Unicode characters with just it. I can appreciate that but memorizing the layout of ISO-8859-1 to do it seems arcane. The mnemonics I define for compose are easier (if a bit slower to type), and even the X11 defaults aren’t too bad. -- Anthony J. Bentley
[dev] [dwm] usage, was dwm 6.0 - separate taglists for muli-monitor setup
It has been argued before that the use of named tags is somewhat a misunderstanding of dwm. Yeah, it's was a misnomer. Personally, I was thinking about workspaces, but I always called it tags. My tag usage is inspired by this blogpost [0]. I have tags for: * generic terminal usage * web surfing * communication * media * development * office * three other generic tags However i use this tagnames rather as a guideline than as a strict rule. Sometimes when i have filled up my dev-tag with a few terminals, i open another terminal in the web tag (since it mostly only holds my web browser) to write some code with the docu in the browser on the side. This way i don't have the screen filled with unused terminals. Is there an even more efficient way of using dwm? How do _you_ use it? --Markus [0]: http://www.wongdev.com/blog/2013/01/24/dwm-tags-are-not-workspaces/
[dev] [PATCH] Fix selecting clearing and BCE
From: Roberto E. Vargas Caballero k...@shike2.com
The commit b78c5085f72 changed the st behaviour enabling BCE capability,
that means erase regions using background color. Problem comes when you
clear a region with a selection, because in this case the real mode of the
Glyph is not the value of term.line[y][x], due in drawregion we had enabled
the ATTR_REVERSE bit.
---
st.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/st.c b/st.c
index f593302..b8b6f56 100644
--- a/st.c
+++ b/st.c
@@ -1409,7 +1409,7 @@ tsetchar(char *c, Glyph *attr, int x, int y) {
void
tclearregion(int x1, int y1, int x2, int y2) {
- int x, y, temp;
+ int x, y, temp, mask;
if(x1 x2)
temp = x1, x1 = x2, x2 = temp;
@@ -1424,7 +1424,9 @@ tclearregion(int x1, int y1, int x2, int y2) {
for(y = y1; y = y2; y++) {
term.dirty[y] = 1;
for(x = x1; x = x2; x++) {
+ mask = selected(x, y) ? ATTR_REVERSE : 0;
term.line[y][x] = term.c.attr;
+ term.line[y][x].mode ^= mask;
memcpy(term.line[y][x].c, , 2);
}
}
--
1.7.10.4
Re: [dev] [PATCH] Fix selecting clearing and BCE
Greetings. On Tue, 23 Apr 2013 20:36:52 +0200 Roberto E. Vargas Caballero k...@shike2.com wrote: From: Roberto E. Vargas Caballero k...@shike2.com The commit b78c5085f72 changed the st behaviour enabling BCE capability, that means erase regions using background color. Problem comes when you clear a region with a selection, because in this case the real mode of the Glyph is not the value of term.line[y][x], due in drawregion we had enabled the ATTR_REVERSE bit. Thanks, it's been applied. Sincerely, Christoph Lohmann
Re: [dev] [dwm] usage, was dwm 6.0 - separate taglists for muli-monitor setup
On Tue, Apr 23, 2013 at 08:34:14PM +0200, Markus Teich wrote: It has been argued before that the use of named tags is somewhat a misunderstanding of dwm. Yeah, it's was a misnomer. Personally, I was thinking about workspaces, but I always called it tags. My tag usage is inspired by this blogpost [0]. I have tags for: * generic terminal usage * web surfing * communication * media * development * office * three other generic tags However i use this tagnames rather as a guideline than as a strict rule. Sometimes when i have filled up my dev-tag with a few terminals, i open another terminal in the web tag (since it mostly only holds my web browser) to write some code with the docu in the browser on the side. This way i don't have the screen filled with unused terminals. Is there an even more efficient way of using dwm? How do _you_ use it? I don't know why anyone would care, really, but since you ask... I started with a similar arrangement, but after a while I got tired of tweaking things and just defined 30 different tags ( , a through z, 1 through 3).is for my main terminal window (running tmux) and 1 through 3 are places I stick windows to keep them out of the way; the others are topical (c for calendar stuff, m for mail) or host-specific (f for frodo, s for smaug, etc.). It's not perfect but I like having a bunch of tags, and getting back to my main terminal window is quick and easy (Mod4-Space). Also, I normally hide the status bar but occasionally I want to see it, and then the short tag names keep it from being too wide. I've also patched dwm so that a window named +CHAR (e.g., +g) is assigned tag CHAR, which lets me do things like this: $ urxvtc -name +f ...(something that f is a good mnemonic for)... (Yeah, I like st but I'm not ready to switch yet.) Paul. -- Paul Hoffman nkui...@nkuitse.com
Re: [dev] [PATCH] Fix selecting clearing and BCE
On Tue, Apr 23, 2013, at 14:34, Roberto E. Vargas Caballero wrote: From: Roberto E. Vargas Caballero k...@shike2.com The commit b78c5085f72 changed the st behaviour enabling BCE capability, that means erase regions using background color. Problem comes when you clear a region with a selection, because in this case the real mode of the Glyph is not the value of term.line[y][x], due in drawregion we had enabled the ATTR_REVERSE bit. I don't understand the issue. How is this desired behavior? It looks like your change makes it toggle the _real_ ATTR_REVERSE bit on the selected region, making the selection appear to vanish, and it'll end up in the wrong colors once the selection is actually removed.
Re: [dev] [dwm] usage
Is there an even more efficient way of using dwm? How do _you_ use it? I don't know why anyone would care, really, but since you ask... I know, why i care! I am interested in learning new ways to use tools. So thanks for the insight. --Markus
Re: [dev] [PATCH] Fix selecting clearing and BCE
On Tue, Apr 23, 2013 at 03:38:32PM -0400, random...@fastmail.us wrote:
On Tue, Apr 23, 2013, at 14:34, Roberto E. Vargas Caballero wrote:
From: Roberto E. Vargas Caballero k...@shike2.com
The commit b78c5085f72 changed the st behaviour enabling BCE capability,
that means erase regions using background color. Problem comes when you
clear a region with a selection, because in this case the real mode of
the
Glyph is not the value of term.line[y][x], due in drawregion we had
enabled
the ATTR_REVERSE bit.
I don't understand the issue. How is this desired behavior? It looks
like your change makes it toggle the _real_ ATTR_REVERSE bit on the
selected region, making the selection appear to vanish, and it'll end up
in the wrong colors once the selection is actually removed.
In drawregion you have:
3172 bool ena_sel = sel.bx != -1;
3173
3174 if(sel.alt ^ IS_SET(MODE_ALTSCREEN))
3175 ena_sel = 0;
...
3190 if(ena_sel *(new.c) selected(x, y))
3191 new.mode ^= ATTR_REVERSE;
in selclear:
937 sel.bx = -1;
938 tsetdirt(sel.b.y, sel.e.y);
in bpress:
822 if (sel.snap != 0) {
823 tsetdirt(sel.b.y, sel.e.y);
824 draw();
825 }
It means when you select something you modify the attribute of the selected
region. If you clean the region (or a part) the selection will kept
enabled. You can see the problem in these videos:
Xterm: http://www.shike2.com/xterm.ogv
St: http://www.shike2.com/st.ogv
Written this mail I found some problems with the patch I sent, so I am
going to write a second version of it.
Re: [dev] [PATCH] Fix selecting clearing and BCE
On Tue, Apr 23, 2013, at 16:21, Roberto E. Vargas Caballero wrote:
In drawregion you have:
3172 bool ena_sel = sel.bx != -1;
3173
3174 if(sel.alt ^ IS_SET(MODE_ALTSCREEN))
3175 ena_sel = 0;
...
3190 if(ena_sel *(new.c) selected(x, y))
3191 new.mode ^= ATTR_REVERSE;
in selclear:
937 sel.bx = -1;
938 tsetdirt(sel.b.y, sel.e.y);
in bpress:
822 if (sel.snap != 0) {
823 tsetdirt(sel.b.y, sel.e.y);
824 draw();
825 }
It means when you select something you modify the attribute of the
selected
region.
That's not true. Only the attribute passed to xdraws() is altered - the
real attribute stored in the character cell is left alone.
Line 3189 new = term.line[y][x]; makes a _copy_ of
the Glyph structure, and line 3191 only modifies the copy, not the
original.
Re: [dev] [PATCH] Fix selecting clearing and BCE
On Tue, Apr 23, 2013, at 17:05, Roberto E. Vargas Caballero wrote: What _exactly_ is the behavior you are observing? Are you sure it's not _actually_ staying selected, rather than simply drawing that way? If you click the mouse somewhere else, does the original selection go away, or does it stay reversed? If it goes away, what is the problem? Are you expecting it should go away immediately when it is erased? There is some merit to the idea that the selection should go away if any character within it is modified - maybe we should be talking about that. -- Random832
Re: [dev] [PATCH] Fix selecting clearing and BCE
On Tue, Apr 23, 2013 at 05:12:47PM -0400, random...@fastmail.us wrote: On Tue, Apr 23, 2013, at 17:05, Roberto E. Vargas Caballero wrote: What _exactly_ is the behavior you are observing? Are you sure it's not _actually_ staying selected, rather than simply drawing that way? Did you see the videos I linked?. In the st video you can see that when the screen is cleared the selection area is still highlighted, altough nothing is in the area. You can see the difference with the xterm video, and it was the behaviour of st before the commit b78c5085f72. If you click the mouse somewhere else, does the original selection go away, or does it stay reversed? If it goes away, what is the problem? Are you expecting it should go away immediately when it is erased? There is some merit to the idea that the selection should go away if any character within it is modified - maybe we should be talking about that. It is very confusing see a hightlight blank line, that really is selecting the previous content of the line. If the selecting mark keeps in the screen it is only some garbage in it. If you can find other terminal emulator with this behaviour please let me know it.
Re: [dev] [PATCH] Fix selecting clearing and BCE
On 04/23/2013 05:27 PM, Roberto E. Vargas Caballero wrote: It is very confusing see a hightlight blank line, that really is selecting the previous content of the line. If the selecting mark keeps in the screen it is only some garbage in it. If you can find other terminal emulator with this behaviour please let me know it. Maybe the behavior is wrong - but if the problem is that it is _still selected_ (i.e. hilight goes away when you select something else), it's not something that can be solved with anything to do with visual attributes only. That was why I was asking for clarification whether it is _still selected_, or just _still hilighted_. I wasn't able to view the video or run st at the time when you posted the video... now I've run st and confirmed that the problem is that it is _still selected_. I can work on a patch to fix this today. This really has nothing to do with the visual attribute, it's that the logic for removing the selection when its content changes (whether by erasing or by text being printed within it) is broken or missing.
Re: [dev] [PATCH] Fix selecting clearing and BCE
2013/4/24 Random832 random...@fastmail.us: On 04/23/2013 05:27 PM, Roberto E. Vargas Caballero wrote: It is very confusing see a hightlight blank line, that really is selecting the previous content of the line. If the selecting mark keeps in the screen it is only some garbage in it. If you can find other terminal emulator with this behaviour please let me know it. Maybe the behavior is wrong - but if the problem is that it is _still selected_ (i.e. hilight goes away when you select something else), it's not something that can be solved with anything to do with visual attributes only. That was why I was asking for clarification whether it is _still selected_, or just _still hilighted_. I wasn't able to view the video or run st at the time when you posted the video... now I've run st and confirmed that the problem is that it is _still selected_. I can work on a patch to fix this today. This really has nothing to do with the visual attribute, it's that the logic for removing the selection when its content changes (whether by erasing or by text being printed within it) is broken or missing. First, thanks k0ga for reporting redundant 'if' predicate. Second, yes, this is correct, the code for clearing the selection when something is printed into it is currently absent, although should be relatively easy to add.
[dev] [st] [PATCH] Removed redundant check in draw code.
We're now clearing empty areas with spaces, so there is no point to check
if character contains non-empty string.
---
st.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/st.c b/st.c
index 71e5b83..11b9b51 100644
--- a/st.c
+++ b/st.c
@@ -3077,7 +3077,7 @@ drawregion(int x1, int y1, int x2, int y2) {
ic = ib = ox = 0;
for(x = x1; x x2; x++) {
new = term.line[y][x];
- if(ena_sel *(new.c) selected(x, y))
+ if(ena_sel selected(x, y))
new.mode ^= ATTR_REVERSE;
if(ib 0 (ATTRCMP(base, new)
|| ib = DRAW_BUF_SIZ-UTF_SIZ)) {
--
1.7.10.4
Re: [dev] [PATCH] Fix selecting clearing and BCE
Maybe the behavior is wrong - but if the problem is that it is
_still selected_ (i.e. hilight goes away when you select something
else), it's not something that can be solved with anything to do
with visual attributes only.
That was why I was asking for clarification whether it is _still
selected_, or just _still hilighted_.
Ok, I understand your point now. We are mixing two different things
here. The X11 selection will keep until you select other thing clicking in
other point (like you said in your previous mail). But we can control our
Selection data structure (Selection sel).
I wasn't able to view the video or run st at the time when you
posted the video... now I've run st and confirmed that the problem
is that it is _still selected_. I can work on a patch to fix this
today.
You are talking here about our Selection data structure, and you are right,
if we mark it as not enabled (sel.bx = -1), all the problem will be fixed,
and maybe in a cleaner way.
This really has nothing to do with the visual attribute, it's that
the logic for removing the selection when its content changes
(whether by erasing or by text being printed within it) is broken or
missing.
We can test it in tclearregion in this form:
for(y = y1; y = y2; y++) {
term.dirty[y] = 1;
for(x = x1; x = x2; x++) {
if(selected(y, x))
selclear(NULL);
term.line[y][x] = term.c.attr;
memcpy(term.line[y][x].c, , 2);
}
}
If all the people like this solution, I can send the patch.
[dev] [st] [PATCH] Removed redundant check in draw code.
We're now clearing empty areas with spaces, so there is no point to check
if character contains non-empty string.
---
st.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/st.c b/st.c
index 71e5b83..11b9b51 100644
--- a/st.c
+++ b/st.c
@@ -3077,7 +3077,7 @@ drawregion(int x1, int y1, int x2, int y2) {
ic = ib = ox = 0;
for(x = x1; x x2; x++) {
new = term.line[y][x];
- if(ena_sel *(new.c) selected(x, y))
+ if(ena_sel selected(x, y))
new.mode ^= ATTR_REVERSE;
if(ib 0 (ATTRCMP(base, new)
|| ib = DRAW_BUF_SIZ-UTF_SIZ)) {
--
1.7.10.4
Re: [dev] [PATCH] Fix selecting clearing and BCE
2013/4/24 Roberto E. Vargas Caballero k...@shike2.com:
You are talking here about our Selection data structure, and you are right,
if we mark it as not enabled (sel.bx = -1), all the problem will be fixed,
and maybe in a cleaner way.
We can test it in tclearregion in this form:
for(y = y1; y = y2; y++) {
term.dirty[y] = 1;
for(x = x1; x = x2; x++) {
if(selected(y, x))
selclear(NULL);
term.line[y][x] = term.c.attr;
memcpy(term.line[y][x].c, , 2);
}
}
If all the people like this solution, I can send the patch.
Too late -- I already sent almost that exact patch :P.
Yes, I think this is the right thing to do, because st currently
clears selection on putting character inside it. So, changing a
characted with tclearregion() should clear it as well.
Re: [dev] [PATCH] Fix selecting clearing and BCE
We can test it in tclearregion in this form:
for(y = y1; y = y2; y++) {
term.dirty[y] = 1;
for(x = x1; x = x2; x++) {
if(selected(y, x))
selclear(NULL);
term.line[y][x] = term.c.attr;
memcpy(term.line[y][x].c, , 2);
}
}
It is good, and it will catch almost cases, but we can lose other
cases. Maybe it is better in drawregion:
- check if it is selected
- check if the previous content if different to new one
- call to selclear
Re: [dev] [PATCH] Fix selecting clearing and BCE
Too late -- I already sent almost that exact patch :P. Yes, I think this is the right thing to do, because st currently clears selection on putting character inside it. So, changing a characted with tclearregion() should clear it as well. I can not see your patch, I only can see you send twice the same patch, maybe did you mistake the second mail?
[dev] [st] [PATCH] Clear selection when tclearregion() touches its range.
---
st.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/st.c b/st.c
index 11b9b51..7e79358 100644
--- a/st.c
+++ b/st.c
@@ -1425,6 +1425,9 @@ tclearregion(int x1, int y1, int x2, int y2) {
for(x = x1; x = x2; x++) {
term.line[y][x] = term.c.attr;
memcpy(term.line[y][x].c, , 2);
+ if(selected(x, y)) {
+ sel.bx = -1;
+ }
}
}
}
--
1.7.10.4
Re: [dev] [PATCH] Fix selecting clearing and BCE
2013/4/24 Roberto E. Vargas Caballero k...@shike2.com: I can not see your patch, I only can see you send twice the same patch, maybe did you mistake the second mail? Yeah, sorry, accidentally sent the same patch two times. Now it should be correct, I think.
Re: [dev] [st] [PATCH] Clear selection when tclearregion() touches its range.
@@ -1425,6 +1425,9 @@ tclearregion(int x1, int y1, int x2, int y2) {
for(x = x1; x = x2; x++) {
term.line[y][x] = term.c.attr;
memcpy(term.line[y][x].c, , 2);
+ if(selected(x, y)) {
+ sel.bx = -1;
+ }
}
}
}
In your patch you disable the selection, and like the line is dirty is
good. But in the case the selection takes more of one line you can have
problems, because maybe not all the lines of the selection are affected by
the clear command, so we need mark all of them like dirty. This is the
reason my patch calls to selclear and not set the value of sel.bx
directly. I'm sorry but I am going to send my patch :P
[dev] [PATCH] Fix selecting clearing and BCE
From: Roberto E. Vargas Caballero k...@shike2.com
The commit b78c5085f72 changed the st behaviour enabling BCE capability,
that means erase regions using background color. Problem comes when you
clear a region with a selection, because in this case the real mode of the
Glyph is not the value of term.line[y][x], due in drawregion we had enabled
the ATTR_REVERSE bit.
---
st.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/st.c b/st.c
index f593302..90849da 100644
--- a/st.c
+++ b/st.c
@@ -1424,6 +1424,8 @@ tclearregion(int x1, int y1, int x2, int y2) {
for(y = y1; y = y2; y++) {
term.dirty[y] = 1;
for(x = x1; x = x2; x++) {
+ if(selected(x, y))
+ selclear(NULL);
term.line[y][x] = term.c.attr;
memcpy(term.line[y][x].c, , 2);
}
--
1.7.10.4
[dev] st: Large pile of code
First off - nice work! Awhile back I started hacking on st in my spare time. I haven't added anything earth shaking - the majority of what I've been doing has been refactoring and rewriting bits to make the code better. Anyways, the way I've been doing things has diverged enough that I don't know if you'll want to pull in my changes (I follow the linux kernel coding style, for one) - if it's too different a direction from what you guys prefer that's ok. Unfortunately, I think I waited a bit too long to send this so if you guys do want to merge my changes in that's going to be a pain... but, if you like what I've been doing I can start working on that. Also, one of the big things I did was to libraryize the terminal emulation code, and decouple it from the renderer. I figure there's enough terminal emulators out there (including things like tmux) we really should have a good library for this sort of thing instead of reinventing the wheel all the time. Makes the code easier to understand too, I think. If you want to have a look, my git repo is http:/evilpiepirate.org/git/st.git Thanks!
Re: [dev] [dwm] usage, was dwm 6.0 - separate taglists for muli-monitor setup
On 23/04/2013 21:18, Paul Hoffman wrote: On Tue, Apr 23, 2013 at 08:34:14PM +0200, Markus Teich wrote: It has been argued before that the use of named tags is somewhat a misunderstanding of dwm. Yeah, it's was a misnomer. Personally, I was thinking about workspaces, but I always called it tags. My tag usage is inspired by this blogpost [0]. I have tags for: * generic terminal usage * web surfing * communication * media * development * office * three other generic tags However i use this tagnames rather as a guideline than as a strict rule. Sometimes when i have filled up my dev-tag with a few terminals, i open another terminal in the web tag (since it mostly only holds my web browser) to write some code with the docu in the browser on the side. This way i don't have the screen filled with unused terminals. Is there an even more efficient way of using dwm? How do _you_ use it? I don't know why anyone would care, really, but since you ask... I started with a similar arrangement, but after a while I got tired of tweaking things and just defined 30 different tags ( , a through z, 1 through 3).is for my main terminal window (running tmux) and 1 through 3 are places I stick windows to keep them out of the way; the others are topical (c for calendar stuff, m for mail) or host-specific (f for frodo, s for smaug, etc.). It's not perfect but I like having a bunch of tags, and getting back to my main terminal window is quick and easy (Mod4-Space). Also, I normally hide the status bar but occasionally I want to see it, and then the short tag names keep it from being too wide. I've also patched dwm so that a window named +CHAR (e.g., +g) is assigned tag CHAR, which lets me do things like this: $ urxvtc -name +f ...(something that f is a good mnemonic for)... (Yeah, I like st but I'm not ready to switch yet.) Paul. In case of need, I have already applied the patch on my dwm 6 branch and it works like a charm. BTW, I use dwm with multiple monitor with different resolution in a context where the larger screen is used for works (terminal, vim on code source, wireshark, ...) and the other one for personal and support stuff (mail, web, professional chat, mplayer, ...). In other way, the behavior introduce by the patch respond exactly at one of my need. Thks Julien
