Bug 172915 - [PATCH] x11/xterm -- Restore 256color option
Summary: [PATCH] x11/xterm -- Restore 256color option
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: Emanuel Haupt
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-20 23:50 UTC by martin
Modified: 2012-10-29 19:10 UTC (History)
1 user (show)

See Also:


Attachments
file.diff (1.25 KB, patch)
2012-10-20 23:50 UTC, martin
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description martin 2012-10-20 23:50:00 UTC
The option to enable/disable 256 colors support was removed about a month ago.
This patch re-adds the option, enabeling it by default.

The commit message says:
``build 256 color support by default and remove it as an option; this change
comes with no price, no additional dependencies''

Well, that's not quite true. All the colors in Vim are now different for the
default colorscheme.
After looking at the same colors for a decade, this was quite the shock!

Perhaps Vim can be re-configured, I'm not sure. But I'd rather just use 16
colors (more colors is not better).

Thanks :)
Martin
Comment 1 Edwin Groothuis freebsd_committer freebsd_triage 2012-10-20 23:50:09 UTC
Responsible Changed
From-To: freebsd-ports-bugs->ehaupt

Over to maintainer (via the GNATS Auto Assign Tool)
Comment 2 Emanuel Haupt 2012-10-21 09:19:08 UTC
Seriously? :-) I'd rather not.

vim allows you to enforce 16 color support by:

- a vim setting:
   :set t_Co=16

- set $TERM to 'xterm'

A better solution might be choosing a more suitable vim color schema:

http://kb.mediatemple.net/questions/1565/Enabling+vi+syntax+colors#gs
Comment 3 Emanuel Haupt freebsd_committer freebsd_triage 2012-10-22 09:57:33 UTC
State Changed
From-To: open->closed

Close.
Comment 4 martin 2012-10-22 10:17:20 UTC
On Sun, Oct 21, 2012 at 10:19:08AM +0200, Emanuel Haupt wrote:
> Seriously? :-) I'd rather not.

The option is enabled by default, and there already a bunch of other options
for this port. There's also no way to disable this option other than at
compile time.

I always assumed that the ability to change compile-time options is the reason
to use ports (well, one of them anyway).

> vim allows you to enforce 16 color support by:
> 
> - a vim setting:
>    :set t_Co=16
> 
> - set $TERM to 'xterm'

Thanks for the tip, setting t_Co=16 works for Vim.

The world of terminal emulators is strange and quirky, so I'm reluctant to
change the TERM environment...

> A better solution might be choosing a more suitable vim color schema:

Well, the point is rather that it stays the same ;-)
Comment 5 Emanuel Haupt 2012-10-23 11:26:24 UTC
Martin Tournoij <martin@arp242.net> wrote:
> On Sun, Oct 21, 2012 at 10:19:08AM +0200, Emanuel Haupt wrote:
> > Seriously? :-) I'd rather not.
> 
> The option is enabled by default, and there already a bunch of other
> options for this port. There's also no way to disable this option
> other than at compile time.
> 
> I always assumed that the ability to change compile-time options is
> the reason to use ports (well, one of them anyway).

That's correct but every option ads complexity in the maintenance
process. Every option should be tested and so on. It's the job of the
maintainer to define somewhat sane options. Not every bit that can be
shifted around makes sense to have as an option.

With pkgng packages will become more and more important and with that
the necessity for sane default options.

If you feel really strongly about this change I can add the option
again as it doesn't add too much complexity. I just fail to understand
why someone would want to revert from 256 to 16 color support (other
than nostalgic reasons).

> > vim allows you to enforce 16 color support by:
> > 
> > - a vim setting:
> >    :set t_Co=16
> > 
> > - set $TERM to 'xterm'
> 
> Thanks for the tip, setting t_Co=16 works for Vim.
> 
> The world of terminal emulators is strange and quirky, so I'm
> reluctant to change the TERM environment...
> 
> > A better solution might be choosing a more suitable vim color
> > schema:
> 
> Well, the point is rather that it stays the same ;-)
Comment 6 martin 2012-10-29 19:01:13 UTC
On Tue, Oct 23, 2012 at 12:26:24PM +0200, Emanuel Haupt wrote:
> Martin Tournoij <martin@arp242.net> wrote:
> > On Sun, Oct 21, 2012 at 10:19:08AM +0200, Emanuel Haupt wrote:
> > > Seriously? :-) I'd rather not.
> > 
> > The option is enabled by default, and there already a bunch of other
> > options for this port. There's also no way to disable this option
> > other than at compile time.
> > 
> > I always assumed that the ability to change compile-time options is
> > the reason to use ports (well, one of them anyway).
> 
> That's correct but every option ads complexity in the maintenance
> process. Every option should be tested and so on. It's the job of the
> maintainer to define somewhat sane options. Not every bit that can be
> shifted around makes sense to have as an option.

Fair enough.

> If you feel really strongly about this change I can add the option
> again as it doesn't add too much complexity. I just fail to understand
> why someone would want to revert from 256 to 16 color support (other
> than nostalgic reasons).

Thank you for the offer.
I've used the `new' 256-xterm for the last week both at home & at work, and
other than Vim I haven't seen any changed in other programs. Assuming no one
else got surprised by this, I would say it's fine as it is :)