unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Xah Lee" <xah@xahlee.org>
To: "Stefan Monnier" <monnier@iro.umontreal.ca>
Cc: 4367@emacsbugs.donarmstrong.com
Subject: bug#4367: 23.1; unable to view this png image
Date: Fri, 18 Sep 2009 12:27:13 -0700	[thread overview]
Message-ID: <F3ACB88B63984DFB98B82537C619ECF5@xahPC> (raw)
In-Reply-To: <jwvbplbk8xe.fsf-monnier+emacsbugreports@gnu.org>

Adding a bit argument about why i think it is critical for emacs to be able 
to open image files out of the box.

• 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 M-x ffap 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 (Lennarts 
EmacsW32, Aquaemacs 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, e.g. FireFox. 
They don't say: oh, including DLL is a problem, go use your OS's file 
management, or go follow these install and compile instruction 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 download it, and finds 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 i think a 
verifiable fact is that, emacs's users among professional programers has 
reduced to something like 1%. (“professional programers” is here defined as 
those who's main income are from programing or sys admin.)

• The Visual Basic language is not philosophically in sync with FSF, but the 
Visual Basic mode is. 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.

  Xah
∑ http://xahlee.org/

  parent reply	other threads:[~2009-09-18 19:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-14 19:37 bug#4367: 23.1; unable to view this png image Xah Lee
2009-09-16  0:54 ` Stefan Monnier
2009-09-16  1:11   ` Juanma Barranquero
2009-09-18 19:27   ` Xah Lee [this message]
  -- strict thread matches above, loose matches on Subject: below --
2009-09-07 23:37 Xah Lee
2009-09-09  0:20 ` Jason Rumney
2009-09-09  3:32   ` Xah Lee
2009-09-09  8:42     ` Jason Rumney
2009-09-09 16:13     ` Eli Zaretskii
2009-09-14 19:30       ` Xah Lee
2009-09-14 20:02         ` Eli Zaretskii
2009-09-15  0:07           ` Jason Rumney
2009-09-15  8:56             ` Lennart Borgman
2009-09-16  0:52         ` Stefan Monnier
2009-09-09  3:46   ` Xah Lee

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=F3ACB88B63984DFB98B82537C619ECF5@xahPC \
    --to=xah@xahlee.org \
    --cc=4367@emacsbugs.donarmstrong.com \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).