Bug 1251754 - default.el contains disruptive set of frame-title-format
Summary: default.el contains disruptive set of frame-title-format
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: emacs
Version: 20
Hardware: All
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Petr Hracek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-08-09 16:11 UTC by Bryan Ischo
Modified: 2016-01-26 09:38 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-01-26 09:38:24 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Bryan Ischo 2015-08-09 16:11:18 UTC
Description of problem:

Emacs includes functionality to load a site-wide 'default.el' file on startup.  This file has been configured by Fedora maintainers to include this line:

(setq-default frame-title-format (concat "%b - emacs@" (system-name)))

This causes the window title for my emacs to change as I change buffer contents.  This is disruptive to my workflow as my window manager (twm - yes, ancient, I know) ends up re-ordering the window within its icon manager as the window name changes.

I have no problem with this setting as something that Fedora is trying to add to normalize the user experience (I guess lots of programs change their window titles dynamically to try to represent the current 'state' of the program), but I don't think this change should be in default.el, and here is why:

default.el is loaded *after* your own personal configuration files (.emacs) are loaded.  Therefore, this change to frame-title-format cannot be controlled by the user because any change made in a .emacs file to try to defeat it, is undone when default.el is loaded.

It is true that I can disable the loading of default.el in emacs via the inhibit-default-init setting, but I don't want to set that just to avoid this particular issue, because if useful defaults appear in default.el, I don't want to miss them.  I've been using emacs for about 25 years now and this is the first time I've ever encountered an environment where someone has made a change to default.el that requires such gynmastics on my part, which I think is pretty good evidence that this change is just not right.

I can think of two ways that this could be done differently:

1. Put the setting into site-start.el instead of default.el.  site-start.el is loaded *before* my own personal .emacs file (instead of *after* like default.el is), which gives me an opportunity to overwrite the frame-title-format variable in my own .emacs and all is well.  I think this is the best solution.

2. Add a variable to default.el called something like 'inhibit-default-frame-title-format' and only set frame-title-format if this variable is not set.  Then I can set inhibit-default-frame-title-format in my .emacs and not get this undesired behavior.

Version-Release number of selected component (if applicable):

I run Fedora 20 still, but I suspect the problem is endemic to the emacs package regardless of Fedora version in use, as it only started occurring on a recent update to the emacs package, which is probably duplicated in all emacs packages for all fedora core versions.

How reproducible:

100%

Steps to Reproduce:
1. Run emacs
2. Find that window titles are suddenly changing with buffer contents
3.

Actual results:

Window titles change and there is no way to disable this because the configuration setting was placed in default.el instead of site-start.el.

Expected results:

Able to disable this behavior by setting frame-title-format in my .emacs file and have this setting take effect instead of being overwritten by default.el.

Additional info:

Comment 1 Petr Hracek 2015-12-18 14:08:50 UTC
This version is already closed. Please update to the latest one version.

If the bug is still present feel free to reopen it.

Comment 2 Jonathan Underwood 2015-12-26 01:09:40 UTC
This line is still in default.el in Fedora 23 in emacs-24.5-6.fc23.x86_64


Note You need to log in before you can comment on or make changes to this bug.