Emacs Does Not Support Viewing Images Files In Windows

In Emacs's Dired mode for viewing directories, you can press Enter on a image file to view the image file. (this is a new feature in at least emacs 22) When working in HTML, you can also press Alt+x find-file-at-point on a inline image link and view that image. This is very convenient. However, viewing image does not work out of the box in the GNU Emacs binary for Windows downloaded from FSF's website.

I thought this is a show-stopping bug. I filed a bug report to FSF. (see: bug#4367 ) However, they don't think this is a bug, and refuse to fix it.

The argument from the few replies of Emacs developers, in summary, are:

• Bundling DLL is problematic. It is problematic due to licensing issues, and or creates a maintenance problem.
• This is not a bug, and not important. If users want image support for Windows, they can download them elsewhere. It's a third-party tool.

I cannot believe how emacs developers cannot see this is a critical problem, and actually consider it not a problem.

Here's parts of my argument sent to the bug list:

• Viewing image files right inside emacs is very convenient, and a common operation. For example, for web developers, it is often needed to quickly see the image files, either in dired or with Alt+x find-file-at-point in inline images. Web app programers are today perhaps more than 50% of professional programers (or some large percentage.)

• I disagree about the argument that including DLL is too much work or problematic. For example, all popularly used emacs distros (Lennart's EmacsW32, Aquamacs Mac, Carbon Emacs), all support viewing images out of the box. They mostly have just 1 core developer. If they can do it, GNU emacs with its tens of developers certainly can manage.

• Perhaps there's licensing problem to include image DLL in GNU Emacs. If i'm correct, this might be because things bundled with GNU Emacs require signed copyright transfer agreement due to FSF's policy, or some complexity related to this. If so, i do think this is a problem that harms GNU Emacs. Again, if the issue of bundling image DLL for emacs does have something to do with licensing, then perhaps this licensing issue needs to be reconsidered. I'm aware this is a controversial and has been debated for long. I do not wish to suggest FSf people to re-exam old policies, but if this particular problem of not able to open image files in emacs out of the box is related to this, thus i mentions this.

• Considered from user point of view… if emacs does support viewing images, and does support Windows, then it must support it out of the box. For example, compare other successful Open Source projects, example: Firefox. They don't say: oh, including DLL is a problem, and it's considered a 3rd party tool. If you are on Windows and need it, go use your Operating System's file management to view images, or go follow these install and compile instructions on how to get it to work.

• Consider the related issue of emacs not supporting editing PHP or Visual Basic code. Consider this: average programer, hear that emacs is a great editor, she downloads it, and find out it simply doesn't support 2 of the MOST popular languages. This alienates a big chuck of potential users.

Yes, FSF has a philosophy in supporting only Free Software. However, consider the user point of view again. In the 1980s and 1990s, where perhaps more than 50% of programers uses emacs. In those era, emacs works out of the box for what they need to do. This quality, helped spread GNU and FSF's philosophies. But, the computing landscape has changed a lot in the past 20 years, and emacs does not work out of the box for most professional programer's needs today. For whatever philosophical or political problems today to include Visual Basic, this situation is a problem for emacs. If emacs still have a lot users, then it isn't a problem, but a verifiable fact is that, emacs's users among professional programers has reduced to something like 1%. (“professional programers” is here defined as those whose main income is from programing or sys admin.)

• Microsoft's Visual Basic, the most popular version of Basic, its license is not philosophically in sync with FSF's philosophy on software licenses, but Visual Basic mode for emacs is Free Software. So, whether to bundle the Visual Basic mode shouldn't be a problem if FSF is willing to consider effective ways to spread its philosophy by making emacs more usable for majority of professional programers on a practical basis.

Sorry if this report is tangential or perhaps not useful at all. But i tried to detail this specific problem of not able to open image files in emacs on Windows with reasons i think are pertinent that are mentioned by developers.

Addendum.

“laurus” on irc alerted to me that printing doesn't work on Linux by default. Apparently, he spend a lot time to figure this out, and can't find a solution on the web. The solution he finally found was, set the variable ps-printer-name to your printer name, then call ps-print-buffer to print. To find the printer name on Linux, use “lpstat -v”. (Note: ps-print-buffer is not the same commpand from the Print menu. The Print menu invokes “print-buffer”. The other print menu is “Print (font+color)”, but when i pulled it, i got this error “Symbol's function definition is void: ps-print-buffer-faces”)

I recall reading a thread about printing problems on the emacs dev list in about 2008 or 2009. It is typical. The developers debate, for whatever technical or social reasons, all intended for the betterment of emacs, but at the end, effectively, emacs isn't going anywhere, or, very, very, slowely.