GNU bug report logs - #1849
Windows 7 Taskbar Support

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (Emacs bug Tracking System)
To: "Michael Kleehammer" <michael <at> kleehammer.com>
Subject: bug#1849 closed by Jason Rumney <jasonr <at> f2s.com> (Re: bug#1849:
 emacs on Windows 7)
Date: Tue, 30 Jun 2009 16:05:08 +0000

[Message part 1 (text/plain, inline)]

This is an automatic notification regarding your bug report
which was filed against the emacs,w32 package:

#1849: Windows 7 Taskbar Support

It has been closed by Jason Rumney <jasonr <at> f2s.com>.

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Jason Rumney <jasonr <at> f2s.com> by
replying to this email.


-- 
1849: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=1849
Emacs Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Jason Rumney <jasonr <at> f2s.com>
To: 1849-done <at> debbugs.gnu.org
Cc: Ben Straub <ben <at> straubnet.net>
Subject: Re: bug#1849: emacs on Windows 7
Date: Tue, 30 Jun 2009 23:57:19 +0800

Jason Rumney wrote:
> Ben Straub wrote:
>>  I've submitted a patch to emacs-devel
>> (http://lists.gnu.org/archive/html/emacs-devel/2009-05/msg00461.html),
>> though I wasn't aware this bug existed then.
>>   
>
> Thanks, we'll probably install it as soon as the 23.1 branch is cut.

A similar patch is now installed.

[Message part 3 (message/rfc822, inline)]

From: "Michael Kleehammer" <michael <at> kleehammer.com>
To: emacs-pretest-bug <at> gnu.org
Subject: Windows 7 Taskbar Support
Date: Sat, 10 Jan 2009 12:33:36 -0600

To work well with the upcoming Windows 7, the Windows version of emacs will need
to start from emacs.exe without allocating the extra console window.  This means
it will need to be linked as a GUI program instead of a console program.

In previous versions of Windows, the Quick Launch shortcuts were small icons
that launched programs.  The programs were then allocated a new button in the
taskbar.  Windows 7 consolidates these: the shortcuts are also the taskbar
buttons.  Similar to the Mac OS/X dock, when a program that has a shortcut is
run, it is not allocated a new taskbar button - instead, the shortcut is
highlighed differently.

This obviously assumes that the program consists of a single main executable
that the shortcut launches.  Unfortunately, emacs on Windows is a console
program which creates an unwanted "DOS" window.  To run as a GUI, a special GUI
launcher named runemacs.exe is used which hides the console window.

To launch emacs, the user will need to pin runemacs.exe.  When launched, it
starts emacs.exe and immediately exits, causing two problems: (1) the shortcut
does not stay highlighted to indicate the program is running and (2) a 2nd
taskbar button is created for emacs.exe.

If a user pins emacs.exe, it will always create an extra console window, so that
is not an option either.

The proper "fix" is to compile the Windows version of emacs.exe as a GUI
program, not a console program, which is a very simple change.  It would
eliminate the ability to run emacs on Windows in a console window, however.

First, this is probably acceptable to 99% of users.  In fact, I don't know of
anyone that runs emacs on Windows in a console, but I'm sure someone does.
(Remember, there is no SSH or the like; we're talking Windows here ;)

If needed, the makefile could be updated to build either or both.

I think it would be simple to compile the program as a GUI program but have the
-nw flag allocate a console when needed.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.