the proper way to disable uniquify?

[Ivan Shmakov]

Since the commit made on 2013-11-29, Emacs' loadup.el
unconditionally loads the 'uniquify feature.

I wonder what's the proper way for disabling it (and are there
any implications of doing so)? As it seems, unload-feature
works, but perhaps there's any other way?

PS. The following code brought my buffer names back to their usual
format.

(dolist (buf (buffer-list))
(let ((name (buffer-name buf)))
(when (string-match "^\\(.*\\)|.*" name)
(let ((new (generate-new-buffer-name (match-string 1 name))))
(with-current-buffer buf
(rename-buffer new))))))

[Teemu Likonen]

Since the commit made on 2013-11-29, Emacs' loadup.el unconditionally
loads the 'uniquify feature.
I wonder what's the proper way for disabling it (and are there any
implications of doing so)? As it seems, unload-feature works, but
perhaps there's any other way?

If you want the original naming style then use this:

(setq uniquify-buffer-name-style nil)

[Ivan Shmakov]

Post by Teemu Likonen

Post by Ivan Shmakov
Since the commit made on 2013-11-29, Emacs' loadup.el
unconditionally loads the 'uniquify feature.
I wonder what's the proper way for disabling it (and are there any
implications of doing so)? As it seems, unload-feature works, but
perhaps there's any other way?

(setq uniquify-buffer-name-style nil)

ACK, thanks!

Any idea on why this feature was added to loadup.el in the first
place? The ChangeLog entry (below) doesn't seem to mention any
reason whatsoever.

2013-11-29 Stefan Monnier <***@iro.umontreal.ca>

* net/newst-reader.el (newsticker-html-renderer): Default to SHR if
available. Suggested by Clément B. <***@etu.univ-lorraine.fr>.

* uniquify.el (uniquify-buffer-name-style): Change default.

* loadup.el: Preload "uniquify".

* time.el (display-time-update): Update all mode lines (bug#15999).

* electric.el (electric-indent-mode): Enable by default.
* loadup.el: Preload "electric".

[Teemu Likonen]

Post by Ivan Shmakov
Any idea on why this feature was added to loadup.el in the first
place? The ChangeLog entry (below) doesn't seem to mention any reason
whatsoever.

There's a short discussion in emacs.devel mailing list about enabling
the feature: <http://thread.gmane.org/gmane.emacs.devel/165631>. I
happen to agree with them. It's a good feature.

[Ivan Shmakov]

Post by Teemu Likonen

Post by Ivan Shmakov
Any idea on why this feature was added to loadup.el in the first
place? The ChangeLog entry (below) doesn't seem to mention any
reason whatsoever.

There's a short discussion in emacs.devel mailing list about enabling
the feature: <http://thread.gmane.org/gmane.emacs.devel/165631>.

ACK, thanks!

Post by Teemu Likonen
I happen to agree with them. It's a good feature.

Good or bad, it seems a bit too obscure for those of us deciding
to live without it. Especially as compared to the other
post-Emacs 20 (or so) features that I’ve ended up disabling
(examples below.)

(mapc (lambda (fn) (and (functionp fn) (funcall fn -1)))
'(;; Some modes get the indentation wrong at times, so I’d
;; rather be explicit.
electric-indent-mode

;; It’s like setting all the prepositions in bold.
;; Besides, it doesn’t always play well with non-default
;; background colors.
global-font-lock-mode

;; Are these of any use on TTYs?
menu-bar-mode
tool-bar-mode

;; Thanks, but I do remember where my marks are.
transient-mark-mode))

(setq ;; Helps to know why Emacs is becoming unresponsive.
garbage-collection-messages t

;; Otherwise, I don’t really “feel” the lines.
line-move-visual nil

;; Too much cruft ended up being here.
find-file-hook '(vc-find-file-hook)

;; Hadn’t the chance to investigate if it’s really secure
;; as of yet.
auth-source-save-behavior nil)

;; C-a, C-e are already convenient; M-<, M-> are not; C-home,
;; C-end are impossible on TTYs (e. g.: under GNU Screen.)
(define-key global-map [home] 'beginning-of-buffer)
(define-key global-map [end] 'end-of-buffer)

;; May be handy to a new user, but I know about C-g.
(define-key global-map "\e\e\e" 'undefined)

;; Menus tend to contain up to 99% of choices one never uses.
;; (And lack ones one uses really often.)
(define-key global-map [f10] 'undefined)

[Ivan Shmakov]

One more surprise that caught me off-guard [1, 2]. Well, as
I’ve already mentioned [3], I tend to use non-default colors for
Emacs (such as white on blue, blue on white, or, although now
only occasionally, — “wheat” on “dark slate gray.”)

Now, given that tweaking all the faces to match these colors may
be a bit too tedious a work (if not a Sisyphean labor outright,
as they keep introducing new ones!), I’d rather simply turn the
XTerm’s support for colors off. Surely, some faces may still
need to be adjusted to use inverse video or weight to stand out,
but the result is still often quite clean and decent.

… But naturally, in this XTerm’s mode, trying to set the opening
brace’s background to ‘cyan’ is essentially a no-op!

Now, that’s one more feature there’s no obvious way to disable.
(Apart from redefining blink-matching-open, that is.)

[1] http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=8790bb2a326c505b70b0
[2] http://lists.gnu.org/archive/html/emacs-devel/2013-12/msg00333.html
[3] news:***@violet.siamics.net

[Emanuel Berg]

Post by Ivan Shmakov
But naturally, in this XTerm’s mode, trying to set
the opening brace’s background to ‘cyan’ is
essentially a no-op!

I found that the face

show-paren-match

always works if point is to the right of the right
bracket, but if it is to the left of the left bracket,
it works only for the right bracket.

[Ivan Shmakov]

Post by Emanuel Berg

Post by Ivan Shmakov
But naturally, in this XTerm’s mode, trying to set the opening
brace’s background to ‘cyan’ is essentially a no-op!

I found that the face
show-paren-match
always works if point is to the right of the right bracket, but if it
is to the left of the left bracket, it works only for the right
bracket.

With show-paren-mode enabled, both braces are highlighted in
both the “to the right of the closing” and “on the opening”
cases, as of Emacs 24.3.1 and a recent Git. (FTR: the face is
used /outside/ of show-paren-mode only on the latter.)

[Emanuel Berg]

Post by Ivan Shmakov
With show-paren-mode enabled, both braces are
highlighted in both the “to the right of the closing”
and “on the opening” cases, as of Emacs 24.3.1 and a
recent Git. (FTR: the face is used /outside/ of
show-paren-mode only on the latter.)

I use

GNU Emacs 24.3.1 (i486-pc-linux-gnu, GTK+ Version 3.8.4)
of 2013-10-01 on biber, modified by Debian

And it looks like this [1] with

'(show-paren-match-face ((t (:foreground "white" :background "blue"))))

and point just before the opening paren.

[1] Loading Image...

[Ivan Shmakov]

With show-paren-mode enabled, both braces are highlighted in both
the “to the right of the closing” and “on the opening” cases, as of
Emacs 24.3.1 and a recent Git. (FTR: the face is used /outside/ of
show-paren-mode only on the latter.)

I use
GNU Emacs 24.3.1 (i486-pc-linux-gnu, GTK+ Version 3.8.4) of
2013-10-01 on biber, modified by Debian

Almost the same here (apart from the x86_64-pc-linux-gnu bit.)

And it looks like this [1] with
'(show-paren-match-face ((t (:foreground "white" :background
"blue"))))
and point just before the opening paren.
[1] http://user.it.uu.se/~embe8573/paren.png

Looks like the ‘cursor’ face overrides ‘show-paren-match-face’.

I’ve done my tests on a tty, where ‘cursor’ is not used, so this
should explain the difference. Alas, I see little reason to use
“native” Emacs X support (now that XTerm’s Unicode support is so
good), so I can’t probably help with this one. It may make
sense to check how is the ‘cursor’ face defined, I guess, and
tweak it not to get in the way.

[Emanuel Berg]

Post by Ivan Shmakov

Post by Emanuel Berg
[1] http://user.it.uu.se/~embe8573/paren.png

Looks like the ‘cursor’ face overrides
‘show-paren-match-face’.

Yes, and that makes sense, because otherwise you
wouldn't know where the cursor is.

Post by Ivan Shmakov
Alas, I see little reason to use “native” Emacs X
support

"native" Emacs X support?

Post by Ivan Shmakov
(now that XTerm’s Unicode support is so good), so I
can’t probably help with this one.

Actually, I'm not unhappy with the situation. Like I
said, it makes sense as otherwise the cursor would be
hidden behind the left paren.

Post by Ivan Shmakov
It may make sense to check how is the ‘cursor’ face
defined, I guess, and tweak it not to get in the way.

I found that this -

(custom-set-faces
'(default ((t (:foreground "cyan" :background "black" :bold nil))))
;; ... )

- sets the cursor face whenever there is no face color
beneath it (otherwise, the cursor assumes that face as
*background*, and displays the char with black as
*foreground*). The :background "black" is important,
without it you won't get a cyan cursor whenever there
is no face color specified underneath. I don't know how
all that works, but it works the way I like it to, so
I'm happy.