Problems of Emacs Supporting Obsolete Systems
Emacs people are trying to make emacs still working on DOS, a technology that has been practically obsolete for about 10 or 15 years.
http://lists.gnu.org/archive/html/emacs-devel/2009-08/msg01214.html
What a idiocy.
The problem is that nothing you or me can do about it. If you join the dev list, even if you are recognized as having made major contributions to emacs, your opinion or suggestion on this will be debated in the list. (in emacs dev community, and probably many FSF dev communities, you are a nobody, and can never be proven otherwise, unless you are Richard Stallman, who has been out of touch with coding for perhaps 15 years) Typically, at the end, nothing will be done, or some other compromised botched up shit will be taking place.
The support of obsolete technologies do harm. In this case, forcing file names to DOS's file name limitation makes them less readable, and also of course takes a lot time to re-code and debug CEDET. Short files names strains emacs lisp's many deficiencies of no namespace, no lexical scope, and no qualified module/packaging support.
This is just one example. In emacs, and in general in unix communities, the mentality of backward compatibility is to a degree harmful, at the cost of harming progress of the software. There are lots of other examples in emacs too. Quick examples off my head: in emacs manual, there are lots verbiage to obsolete systems that a average professional programer never heard of today. This harms the efficiency of the manual. (no wonder nobody reads it) Also, somewhere in elisp manual it suggest programers to use file names not longer than 32. (file systems on Windows, Mac, Linux, has supported 255 chars out of the box for about at least 7 years.)
In practice, nobody uses those systems, maybe 0.0001% of those in computing industry. And if the world has say 10 people using such obsolete systems, and if one of them made a vocalization, then it'll be be supported. (due to the we-all-democratic Freedom and Equality mentality faak commonly implicit in open sources.)
Any existing DOS users, for whatever reasons or history studying reasons or what not, emacs 22 is still there.
Emacs Modernization
- Emacs Modernization: Simple Changes Emacs Should Adopt
- Why Emacs Keys are Painful
- Emacs: Problems of the Scratch Buffer
- Emacs Modernization: Meta Key Notation
- Emacs Menu Usability Problem
- Emacs Mode Line Problem
- Emacs cua-mode Problems
- Emacs: Inconsistency of Search Features
- Problems of grep in Emacs
- Emacs: Usability Problems of Mode Documentation
- Problems of Emacs Manual
- Emacs Manual Sucks by Examples
- Emacs: kill-buffer Induces Buffer Accumulation
- Emacs Spell Checker Problems
- Emacs: Form Feed ^L Problem
- Emacs: Single Key to Delete Whole Line
- Emacs HTML Mode Sucks
- Emacs Does Not Support Viewing Images Files In Windows
- Emacs Should Adopt HTML as Texinfo Replacement
- Emacs Should Support HTML Mail
- Problems of Emacs's βmanβ Command
- Emacs Lisp Mode Syntax Coloring Problem
- Emacs AutoHotkey Mode Problems
- Elisp: Ban Syntax Table
- Emacs: Make elisp-index-search use Current Symbol
- Emacs GNU Texinfo Problems; Invalid HTML
- A Record of Frustration in IT Industry; Disappearing FSF URLs, 2006
- Emacs Manual Node Persistency Issues
- Emacs: dired-do-query-replace-regex Replace ALL (fixed)
- Problems of Emacs Supporting Obsolete Systems
- Elisp: Function to Copy/Delete a Dir Recursively (fixed)
- Thoughts on Common Lisp Scheme Lisp Based Emacs
- Text Editors Popularity and Market Research
- Text Editor's Cursor Movement Behavior (emacs, vi, Notepad++)
- Emacs: Usability Problems of Letter-Case Changing Commands
- Emacs Select Word Command Problem
- Emacs: Search Current Word π
- Emacs fill-paragraph Problem