Bug#291137: /usr/X11R6/bin/luit: luit sometimes doesn't restore terminal settings or hangs
On Wed, Jan 19, 2005 at 02:58:44PM +0500, Alexander E. Patrakov [EMAIL PROTECTED] wrote: and exits. It looks like there is a race condition inside luit. It is likely an upstream issue because similar behaviour can be demonstrated ona fedora 3 system. Sounds suspiciously similar to this bug: http://bugs.xfree86.org/show_bug.cgi?id=1093 Does the patch from there help? Indeed, sounds very suspiciously like that bug (and thomas dickey stil assumes that the race in ncurses is a bug elsehwere, argh). I'll try to apply the patch and build luit, but cannot say when I am able to do so :( -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#259828: example implementation
If anybody cares, here is how rxvt-unicode-3.8 implements HT characters now, plus some initial experience on the effects. When rxvt-unicode-3.8 received a HT, it first calculates the tab movement (which is a relative cursor movement). *Iff* all characters skipped over are spaces with the same attributes as the first space, it will replace these spaces by a (very) wide tab character (which is easy to do in the way rxvt-unicode handles wide characters, so the code changes were limited to less than 15 lines within the scr_tab method). If any of the characters are not spaces, or if there are attribute changes (e.g. colour), it will only move the cursor. i.e. printf 'aaa\tbbb\n' will result in: aaaTbbb ^ one wide tab character While printf 'aaa\r\tbbb\n' will result in: aaa bbb In addition, some care is required when updating such wide tabs (i.e. when replacing the 3rd cell of the tab character by a normal character). Rxvt-unicode handles this similar to other wide characters: when part of a wide character is being overwrtten, the whole character is being replaced by spaces. (it seems xterm doesn't handle this case, so would need to be fixed there first). This seems to work rather fine, the only cases where the user sees an obvious chane is when the cursor is positioned on such a tab character (it will be very wide then, wich imho is correct but somewhat surprising). The only program where I could see this effect, however, is xjdic, which does very strange things when editing (like outputting tab characters at the end of the current line when deleting parts of the input :) -- The choice of a | -==- _GNU_ | ==-- _ generation Marc Lehmann +-- ---==---(_)__ __ __ [EMAIL PROTECTED] |e| --==---/ / _ \/ // /\ \/ / http://schmorp.de/ --+ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE| |
Bug#259828: tabs mangled to spaces when copying from xterm - ideas on semantics
I thought about implementing this in rxvt-unicode: tabs could be represented trivially in rxvt-unicode's data structure. However, there are semantic problems: Tabs are not characters, but cursor movements. As such, there is no good way to represent them as tab characters, just as cursor up or goto 5,6 will not be represented in the selection text. Here are some problematic examples (case 1) echo $'hi\r\tho' This might print: hi ho Now, what should be in the selection when this is selected? hi\tho? If you think so, then this example is more problematic: echo $'01234567\r\t89' This might output (case 2) 0123456789 Where is the tab now, when this is selected? I have thought about usign a heuristic. There are, however, many ways to do this. For example: a) check wether we tab over spaces, when yes, make it a real tab, otherwise leave it as spaces. Neither case 1 nor case 2 will have a tab than. b) replace spaces (if any) before the tab position by a tab. This will create a tab in case 1, but no tab in case 2. b2) replace spaces (if more than 2)... this will use a space when there is only a single space. c) something else...? So before implementing this, one should decide (and think) about the semantics that this should have, especially when more terminals want to do this, so that they can be consistent (and i want rxvt-unicode to be consistent to xterm in this respect :) -- The choice of a | -==- _GNU_ | ==-- _ generation Marc Lehmann +-- ---==---(_)__ __ __ [EMAIL PROTECTED] |e| --==---/ / _ \/ // /\ \/ / http://schmorp.de/ --+ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE| |
Bug#241717: xterm: various colour problems (mouse cursor color, text colours)
On Mon, Apr 12, 2004 at 07:33:58PM -0400, Thomas Dickey [EMAIL PROTECTED] wrote: On Thu, Apr 08, 2004 at 05:31:09PM +0200, Marc Lehmann wrote: framebuffer: #aa (standard vga actually, and real vt100 AFAICR) vt100's do not, never have done color. The ones with the advanced video option had. Call them vt102, or whatever you like, I do not care. A reasonable alternate choice (still improving contrast for blue/black) might for instance be blue2, which is a little brighter (0xee) than the value used by pterm. On the other hand, it might not display well with a blue/white combination on a low-quality display (I recall some issues about that). On low quality displays people will not use blue/white, as it is very straining for the eyes to have white backgrounds anyways. On Tue, Apr 13, 2004 at 10:15:51AM -0400, Thomas Dickey [EMAIL PROTECTED] wrote: The vt100 colours look very similar everywhere, so programs had ample time to find combinations that work, as opposed to ones that do not work. but as long as you insist on referring to vt100 colours, I'm regarding the report only as an attempt to annoy people. Well, you can research this easily yourself. I don't care how you regard my report, as you can check everything I said for yourself, and I hope you did. Disregarding a perfectly fine bugreport just because I am not 100% precise in my naming conventions is rather idiotic, but it's you to chose. I am absolutely sure that you understood my points, and you understood all the problems I am talking about. The solution, or the way to proceed, is entirely up to your decision (or the debian X maintainers). If you are looking for reasons to disregard my report, there are easier ways than being a hipocrite :( On Tue, Apr 13, 2004 at 03:04:43PM -0500, Branden Robinson [EMAIL PROTECTED] wrote: problem, not the terminal emulator, which, after all, just offers a fairly standardized colour set. But it's not standardized. I would call that pretty much standardized. What you mean is probably that there is no real standard the mandates that with force. That is of course true. Neither the w3c nor the ietf nor... will care a bit which exact colour is used in xterm or elsewhere :) That's common practice, not standardization. It is common practise, and also standardization. Please do not think that only official standard bodies can create standards, that's not what the word standard means (see, for example, de-factor standards or industry standards which might or might not be standardized by a standards body like iso, but are beverteheles standards, as long as they are documented). I think that arguing about words (as this is the level both of you are approaching here) is not useful, and I have nothing more to day about this issue. I would be glad if you would discuss or decide according to the technical issues and problems I brought up. Arguing about words or word usage is secondary to the problem, and will neither help you nor me. With proper standardization comes expert advice. I don't think the xterm color defaults, or the defaults used by other terminal emulators, were selected with the aid of expert advice. True. And neither was expert advice sought when changing these. The problem is that a large body of software has inherent knowledge of these colours (by using them in certain combinations to get certain effects, e.g. use red for warnings). Obviously it would be bad to give some colour codes (former red) completey new colours. It's much less bad to change them subtly, and I think the xterm colour change is somewhere in the middle: It's not terribly problematic, but certainly a drawback for common existing applications, while improving the situation for some others. My point is that this is unexpected, and it's not a very intelligent idea to make colours incompatible in xterm compared to other terminals or terminal emulators by changing readable combinations. Existing terminals have lots of combinations that are marginally readable, not readable, or well readable. The xterm change does not improve the situation, it just changes it by making some combinations more readable and others less. And I argue precisely that this change is unexpected and not good, from a standardization side, as apps must be rewritten with knowledge about xterm colour combinations that are readable, as opposed to all other terminals. And if I haven't made this completely clear: I do not care about rgb bit values used for colours, I only care about readability, which, overall, seems to have been decreased rather than increased by xterms changes. They were picked because they were color values close to some ANSI terminal standard (I don't know which one) -- and which could be easily encoded in a 4-bit colormap. This is factually wrong. I think the colors in common practice were the product initially of technological constraints, and subsequently due to
Bug#241717: xterm: various colour problems (mouse cursor color, text colours)
On Tue, Apr 13, 2004 at 05:41:04AM -0400, Thomas Dickey [EMAIL PROTECTED] wrote: On Tue, Apr 13, 2004 at 02:00:13AM +0200, Thomas Dickey wrote: A reasonable alternate choice (still improving contrast for blue/black) might for instance be blue2, which is a little brighter (0xee) than the value used by pterm. On the other hand, it might not display well with a blue/white combination on a low-quality display (I recall some issues about that). I note also: black text on blue2 background is unreadable. Dodger blue is readable. That is a very uncommon combination (I have not seen that used, and after all, xterm has high-intensity colours, so it would be asking for unreadable colours when you use two low-intensity colours together). You will always find colour combimations that are unreadable. The point of changing (or better: not canging colours) with respect to other terminals is not to introduce more or different combinations that are hard to read. The vt100 colours look very similar everywhere, so programs had ample time to find combinations that work, as opposed to ones that do not work. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Bug#241717: xterm: various colour problems (mouse cursor color, text colours)
On Fri, Apr 09, 2004 at 05:58:00AM -0400, Thomas Dickey [EMAIL PROTECTED] wrote: of longstanding bugs. However, in the discussion so far, it is not clear whether you are referring to the text cursor or the mouse pointer. Yes. I was refering to the mouse-cursor. You have probably missed the remaining dialogue in the debian bug-report. The maintainer kept replies off-list, and so I did the same. The mails in the bug report detail the two problems quite thoroughly, so if you ae interested in theese arguments you might want to read them. If an app uses it as fg and this is bad, then I think that app has a problem, not the terminal emulator, which, after all, just offers a fairly standardized colour set. But it's not standardized. Depends. It's standardized in some local standards, used in about all existing implementations (see the bug report for a comparison between terminal emulators on unix) and was documented for many years. I would call that pretty much standardized. What you mean is probably that there is no real standard the mandates that with force. That is of course true. Neither the w3c nor the ietf nor... will care a bit which exact colour is used in xterm or elsewhere :) I wonder if it shouldn't default to the VT100 widget's text foreground and background colors instead. What do you think? I tend to agree. That is (I think) how rxvt does it and (definitely) how I could revisit this issue. When I first looked at it (probably 1997), xterm was using Xt to lookup resource values automatically. Now it delays some of those til they're needed (so it would be possible to detect cases where a resource value was not set, and modify its default value dynamically). Well, I would be fine with whoever changing the text fg/bg would also need to adjust the mouse cursor colours, too, to get standard behaviour. So the defaults in the binary and the debain appdefaults would need to be corrected. It's probably more user-friendly to make this automatically when unset, but I am mainly concerned about default settings. Changing the defaults is certainly the easiest fix for this very minor problem. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
