Re: patch to support 256 colors in fbterm
Nicholas Marriott nicholas.marriott at gmail.com writes: At the moment tmux assumes that 256 colours are set using \033[38;5;Xm. This is definitely not ideal. However it is definitely fine to assume that the 256 colour palette is fixed. But I'm not sure it's fine to assume the aixterm colours are fixed or that they are the same as colours 8-15. And definitely not ok to assume the standard ANSI colours are the same as colours 0-7 in the 256 colour palette. Of course you're right it's not ideal to assume that aixterm sequence is \033[9Xm either. Dunno, might be best to just map everything to setaf and assume it'll do the right thing with colours 0-15. Is there any update on this? I'm hoping to run tmux in fbterm, but forcing 256 colour support doesn't work. Or, is this something you think the fbterm devs should fix? There's too many conflicting implementations in terminals these days, it makes setting up things like tmux very time consuming. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
Re: patch to support 256 colors in fbterm
Any progress with this? I'm one of those who would like to see it implemented. Can't help with the patch though. -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
Re: patch to support 256 colors in fbterm
Hi Sorry for the delay. On Sat, Feb 11, 2012 at 01:51:15PM -0500, Peter Lustig wrote: On 2/9/2012 4:00 AM, Nicholas Marriott wrote: I'd rather not translate aixterm colours on terminals that support them: - They are fewer bytes than the 256 colour equivalents. - We can't predict what configuration options terminals have - some may have the ability to alter the palette for aixterm colours independent of the 256 colour palette. I'd rather they were passed through unaltered except on 8 colour terminals. I see your reasoning with the second point: tmux should make as few assumptions as possible regarding the underlying terminal. But, if you decide to accept my (original) patch, wouldn't tmux then be making the implicit assumption that all 256-colour terminals use the same palette as xterm-256 (and all 88-colour terminals the same as xterm-88)? For example, that the indices 8-15 correspond to the aixterm colours? (Actually, this assumption is still there in the current version of tmux; all the patch does is remove another assumption regarding the actual _format_ of the 256/88-colour escape sequences.) At the moment tmux assumes that 256 colours are set using \033[38;5;Xm. This is definitely not ideal. However it is definitely fine to assume that the 256 colour palette is fixed. But I'm not sure it's fine to assume the aixterm colours are fixed or that they are the same as colours 8-15. And definitely not ok to assume the standard ANSI colours are the same as colours 0-7 in the 256 colour palette. Of course you're right it's not ideal to assume that aixterm sequence is \033[9Xm either. Dunno, might be best to just map everything to setaf and assume it'll do the right thing with colours 0-15. That being said, perhaps the better way of resolving the issue would be for tmux to have its own termcap/terminfo entries (I see from the TODO file that you have been considering this). As it stands right now, tmux assumes that all 256/88/16-colour terminals support aixterm colours. At least one 256-colour terminal (i.e. fbterm) does not. This wouldn't be an issue if not for the fact that 256-colour tmux relies on the 'screen-256color' termcap/terminfo entry, which yields ANSI colours for indices 0-7, aixterm colours for indices 8-15, and xterm-256 colours for indices 16-255 (for the sake of saving characters). Were tmux to have its own 256-colour termcap/terminfo entry it would seem best to use the same set of escape sequences (i.e. xterm-256) for all colours (or at least for non-ANSI colours). Then applications running in tmux and relying on termcap/terminfo would not be coerced into using aixterm colours, but the aixterm colours would be still be available for explicit use. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
Re: patch to support 256 colors in fbterm
On 2/9/2012 4:00 AM, Nicholas Marriott wrote: I'd rather not translate aixterm colours on terminals that support them: - They are fewer bytes than the 256 colour equivalents. - We can't predict what configuration options terminals have - some may have the ability to alter the palette for aixterm colours independent of the 256 colour palette. I'd rather they were passed through unaltered except on 8 colour terminals. I see your reasoning with the second point: tmux should make as few assumptions as possible regarding the underlying terminal. But, if you decide to accept my (original) patch, wouldn't tmux then be making the implicit assumption that all 256-colour terminals use the same palette as xterm-256 (and all 88-colour terminals the same as xterm-88)? For example, that the indices 8-15 correspond to the aixterm colours? (Actually, this assumption is still there in the current version of tmux; all the patch does is remove another assumption regarding the actual _format_ of the 256/88-colour escape sequences.) That being said, perhaps the better way of resolving the issue would be for tmux to have its own termcap/terminfo entries (I see from the TODO file that you have been considering this). As it stands right now, tmux assumes that all 256/88/16-colour terminals support aixterm colours. At least one 256-colour terminal (i.e. fbterm) does not. This wouldn't be an issue if not for the fact that 256-colour tmux relies on the 'screen-256color' termcap/terminfo entry, which yields ANSI colours for indices 0-7, aixterm colours for indices 8-15, and xterm-256 colours for indices 16-255 (for the sake of saving characters). Were tmux to have its own 256-colour termcap/terminfo entry it would seem best to use the same set of escape sequences (i.e. xterm-256) for all colours (or at least for non-ANSI colours). Then applications running in tmux and relying on termcap/terminfo would not be coerced into using aixterm colours, but the aixterm colours would be still be available for explicit use. -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
Re: patch to support 256 colors in fbterm
IIRC I sent some comments and heard nothing more. On Sat, Jan 21, 2012 at 10:50:04PM -0500, Peter Lustig wrote: Sorry to resurrect an old thread. Does anyone know what became of this patch? I found no more discussion of it after this thread, and see no traces of it in the trunk. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
Re: patch to support 256 colors in fbterm
Sorry to resurrect an old thread. Does anyone know what became of this patch? I found no more discussion of it after this thread, and see no traces of it in the trunk. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
Re: patch to support 256 colors in fbterm
On Thu, Jan 20, 2011 at 04:31:22PM -0600, Stephen Prater wrote: I have completed a patch to tmux which enables 256 color support in fbterm (or any other term that uses non standard 256 color escape sequences) as well as xterm / etc. It does this by honoring terminfo setaf / setab entries for escape sequences on 256 / 88 color terminals. This works, but I'm not sure it goes far enough. I had another look and if we are going to use setaf/setab directly for 256 colour terminals, then I think that really tty_check_fg should do the translation, like it does when trying to display a 256 colour on a 16 colour terminal. So as well as the first if statement which checks for 256-on-!(256||88) and converts to 16, there should be a statement to check for 256-on-88 and pass through colour_256to88 (in fact they could be the other way round, if 256-on-88 else if 256-on-16). Then tty_colours_fg just needs to skip the aixterm check on 256 colour terminals and pass through to setaf. i have a few questions. - should there be a ignore-terminfo switch to forcibly set the escape sequences to the xterm-256color standard? I think either we use terminfo or we don't, no option for this. - i didn't change any of the stuff with aix terms because I have no way of testing this to make sure I didn't break it. aixterm colours are bright version of the ANSI colours, set by using 90-97 and 100-107 to SGR, they are supported by most modern terminals try eg this in xterm: $ printf \033[93mabc\033[0;33mabc\033[0m\n terminfo has no way to detect it so as a best effort tmux assumes all terminals which advertise =16 colours support the aixterm set (so all 256 and 88 colour terminals). - it seems odd to have the magical mystery 48 / 38 numbers in calls to tty_try_256 now. I replaced them with #defines but left the values as 48/38 is there a better way to do this? I don't think we need defines here, they are only used once and will never change. Better to extend the comment above where they are used, but we don't need them anymore if using setaf/setab anyway. - is there a test suite I ought to run? it works for me on both xterm256-color, 16 color console and fbterm - but that's about all I've got to test on. No, no test suite. secondarily - how does one submit a patch to this project? Send it to the mailing list ;-). -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
