Gentoo: Сборка GCC 3.2 в современном окружении

В Gentoo есть ebuild-ы для GCC старых версий, однако GCC 3.2 не собирается последними версиями GCC, в том числе текущим стабильным 4.6. Возможное решение следующее: с помощью GCC 4.6 собрать GCC 3.4, а с помощью GCC 3.4 уже собрать GCC 3.2.

Шаг 1: версия bison

GCC 3.2 не собирается текущим стабильным bison 2.x. Для bison слотов нет, так что для сборки GCC можно просто замаскировать новые версии. У меня работает bison-1.875d.

/etc/portage/package.mask

>=sys-devel/bison-2.0

# emerge -u sys-devel/bison

Шаг 2: настройка окружения

См. /etc/portage/env.

1. Во-первых, GCC версии 3.x могут не поддерживать ваши CFLAGS (в частности -march=native), поэтому отключим их для этих пакетов.
2. Во-вторых, мы должны указать, что для сборки GCC 3.2 будет использоваться GCC 3.4.

/etc/portage/package.env

# Отключаем CFLAGS для GCC 3.x
=sys-devel/gcc-3* use-simple-cflags.conf

# Включаем использование GCC 3.4 для GCC 3.2
=sys-devel/gcc-3.2* use-gcc-3.4.conf

 /etc/portage/env/use-simple-cflags.conf 

CFLAGS="-O2"
CXXFLAGS="-O2"

/etc/portage/env/use-gcc-3.4.conf 

CC="gcc-3.4.6"

Шаг 3: сборка GCC 3.4

# emerge sys-devel/gcc:3.4

Шаг 4: сборка GCC 3.2

# emerge sys-devel/gcc:3.2
# /usr/i686-pc-linux-gnu/gcc-bin/3.2/gcc --version

Emacs, tramp: File ... is read-only on disk. Change buffer mode?

Это сообщение может появиться, если соединение разорвалось и tramp не может установить повторное соединение самостоятельно.

Решение:

M-x tramp-cleanup-all-connections

Затем можно обновить буфер в dired или повторно сохранить файл.

Emacs: тормоза, плавная прокрутка

Ссылки

1. Возможные причины медленной работы
2. Плавная прокрутка

Возможные симптомы и их причины

1. Задержки при наборе текста

Это возможно при использовании модуля tabbar, старый баг. AFAIK, его мало кто использует.

2. Задержки при прокрутке и построчном перемещении курсора

Возможные причины:

1. Самое главное, из-за linum-mode (нумерация строк).
2. Из-за font-lock-mode (применение цветов и шрифтов к тексту), когда в буфере слишком много разноцветных жирных шрифтов.
3. Из-за hl-line-mode (подсветка текущей строки).

Плавная прокрутка без тормозов и без отключения перечисленных режимов возможна, но, как и положено, опциональна и отключена по-дефолту.

Настройки прокрутки

;; При прокрутке применять font-lock не сразу, а после небольшой задежки.
(setq jit-lock-defer-time 0.01)

;; Эту опцию часто советуют выставлять в t, но я не заметил разницы с nil.
;(setq redisplay-dont-pause t)

;; Опционально: медленная плавная прокрутка колесиком.
(setq mouse-wheel-scroll-amount '(2 ((shift) . 2)))   ; Прокручивать по 2 строки.
(setq mouse-wheel-progressive-speed nil)
(setq mouse-wheel-follow-mouse 't)

;; Опционально: никогда не прокручивать более, чем на 1 строку при перемещении курсора за
;; нижнюю или верхнюю границу экрана.
(setq scroll-conservatively 10000)

;; Опционально: отступ от верха и низа экрана в 1 строку, при попадании курсора за отступ
;; происходит прокрутка.
(setq scroll-margin 1)

См. также Bug #12936.

Настройки нумерации строк

Дело в том, что linum-mode перерисовывает номера строк во время прокрутки, из-за чего она и тормозит. Мне известны 2 альтенативы:

1. nlinum-mode: успешно решает в точности описанную проблему. Доступен на github.
2. setnu-mode: предшественник linum-mode, работает почти без задержек, но есть баги, в том числе при использовании совместно с модулем auto-complete.

Стандартный linum позволяет установить hook на генерацию формата номеров строк и face для них, причем они могут быть свои для каждой строки. В nlinum это на данный момент не поддерживается, но такую возможность легко добавить, см. nlinum--region.

Справедливости ради замечу, что на 8-ядерном компьютере прокрутка у меня все же немного плавнее, чем на 2-х ядерном.