Emacs can use the native windowing system on every major platform. It still *looks* like a terminal app, but doesn't have to be one.
Pretty much everything you are saying here doesn't apply to Emacs at all, and you would know it's all false if you knew anything about Emacs. On Wednesday, April 1, 2015 at 4:55:08 PM UTC-7, Fluid Dynamics wrote: > > On Tuesday, March 31, 2015 at 8:45:31 AM UTC-4, Phillip Lord wrote: >> >> The benefit is that Emacs is that its not constantly changing, and it >> gives you some stability over the years. I like latex, for instance, for >> the same reason. I can still access a 10 year old document and use it. >> > > First of all, there are other posts in this thread complaining about > constantly changing stuff breaking things! One such post is by Colin Yates. > > Second, to the extent that it isn't changing, it is legacy. Which helps to > explain the Wordperfect for DOS style of UI, which is dependent on vast > numbers of complex key-combinations being memorized by the user, instead of > a just-sit-down-and-start-using-it UI like everything originating after, > say, 1995 or so has tended to have. Of course, the result is that > Wordperfect (and emacs) seemed to require a great deal of specialized > training just to accomplish even the most basic tasks, whereas with modern > interfaces the way to do such basic tasks (save, open, copy and paste, move > around, select, etc.) tends to be obvious and special training can focus > exclusively on doing advanced things (scripting, complicated Photoshop > filters and tricks, things like those). > > Legacy also, obviously, tends to present problems in other areas besides > UI-boneheadedness: > > * I18n and l10n > * Compatibility, with modern hardware and with modern operating systems, > though that can be alleviated by people porting the code > * Boneheaded internal limits, along the same general lines as "640K ought > to be enough for anybody". It may be unable to use more than a small > fraction of what modern hardware can offer it in the way of memory, > storage, cores, ... > * Accessibility. Interposing a terminal emulator between the app and > screen reading software might cause problems, though on the other hand a > text mode app may ultimately have advantages in that area too. On the other > hand, it may not play well with accessibility tools > that rely on standard UI conventions. Anything that responds to some > voice command by generating control-V keystrokes to paste, or that relies > on the presence of normal menus and/or mouse support is going to blow up > spectacularly when used with 1980s-vintage Unix > (or MS-DOS) software, or at best will end up controlling the > xterm/Command Prompt window instead of the underlying app. > * Interoperation with other (non-operating-system) software. On Windows it > won't speak OLE, DDE, OCX, or etc., and copying text in it and attempting > to paste into something else (web browser, calculator, etc.) is doomed to > failure. This is a general problem with > pre-window-system software, much like the stuff listed under > Accessibility, with no easy solution. Terminal emulators tend to provide > some way to copy from their display into the host-native clipboard, but it > tends to be clunky (the Windows command prompt appears to > require mouse use, with no keyboard shortcuts) and runs into the obvious > difficulties as soon as you want to copy more than will fit on one screen. > Ironically, really primitive stuff like ls and dir that just dump > possibly-paginated noninteractive listings to the term are easier > to make big copies from than text-mode, interactive applications like > screen-oriented editors, because you can copy from the backscroll buffer of > the terminal emulator in the first case. Pre-window-system *graphical* apps > are the absolute worst, e.g. later, WYSIWYG > word processor versions on MS-DOS, or pre-window-system X applications. > No internal support for the host clipboard and, at the same time, nothing > the emulator will recognize as text, meaning if you try to native copy and > paste you'll end up with a PNG or something. > OCR might work on that, if you can find cheap or free OCR software > that's any good. Your better bet would be to save the document as some > format that can be read by a native windowed app and then open the file in > that, then copy, and at that point you might as well > edit in the native windowed app and throw out the legacy cruft entirely, > since you'll have to deal with the native app anyway, and the cost of > switching between them constantly, reloading in the native app so it sees > changes, and re-locating the places you want to copy > from in the native app will quickly grow to outweigh any advantage the > legacy app might somehow have due to some feature it has that you haven't > found in any native app. > > Put more simply, there are giant costs to not playing well with others, > and these are inevitably incurred by all applications developed prior to > the advent of a) window systems with window managers, systemwide > copy/paste, and etc. and b) widespread user-interface standards for common > cross-domain tasks like save and paste. Ultimately, the costs incurred > every time you or some data need to cross the boundary between the legacy > application and the modern world are likely to vastly outweigh whatever few > missing features you can find only in legacy applications and never in any > of their modern counterparts, as moving anything across that boundary is > likely to be fiddly at best (e.g., mark/copy from Command Prompt window) > and require saving a file manually and manually opening it in another > application at worst (e.g. copying text from a pre-Windows *graphical* > version of WordPerfect into a Firefox form box to use in a blog comment or > something.) Maintaining and learning virtual machine software is likely to > be necessary as an additional overhead, for legacy applications that can't > be run natively at all anymore (most pre-Windows graphical apps and > anything that assumes it can talk directly to the hardware), and even > terminal emulators add a smaller amount of such overhead for the user. > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
