Dave's difficulties with manual activities
in [Lisp]
|
Prev: Symbol reader macros
Next: Read CSV in SBCL
From: Dave Searles on 13 Sep 2009 05:40 Alan Mackenzie wrote: > In comp.emacs Dave Searles <searles(a)hoombah.nurt.bt.uk> wrote: > >> I will take that as your conceding that you still don't have a logical >> argument against what I've said. > > You know, if you were using Emacs, you could bind that string to a key > sequence, and that would save you a _lot_ of time. ;-) I can do that anyway, in any powerful Windows editor -- yes, including plenty with sane user interfaces. I can't do that in Thunderbird's built-in editor, exactly, but then there's not much that can be done about that, short of doing a bunch of tedious copying and pasting between a separate editor and Thunderbird. But I can control-C that into the clipboard and control-V it anywhere I need it so long as I'm not needing the clipboard for much else for a while. (And when I do need it for something else, I can either paste a copy to cut back later, or keep track of a copy, perhaps in an already-posted article I can easily find and copy from every few tens of minutes or whenever.) The beauty of it is I can do this without leaving a very small, orthogonal set of commands; without learning tons of arcana or a different and complex UI for every application I use; without giving up Thunderbird for some newsreader that has a fancier editor but does a shoddier job of handling browsing and reading posts, which I do far more of than composing posts of my own, believe it or not; or whatever other sacrifice or problem.
From: Dave Searles on 13 Sep 2009 05:41 Espen Vestre wrote: > Dave Searles <searles(a)hoombah.nurt.bt.uk> writes: > >> I will take that as your conceding that you still don't have a logical >> argument against what I've said. > > There's no point in trying to argue with you before you behave like a > grown-up. [rest of personal attack deleted] I will take that as your conceding that you still don't have a logical argument against what I've said.
From: Dave Searles on 13 Sep 2009 06:07 David Kastrup wrote: > "John Thingstad" <jpthing(a)online.no> writes: > >> P� Fri, 11 Sep 2009 06:11:19 +0200, skrev Dave Searles >> <searles(a)hoombah.nurt.bt.uk>: >> >>> John Thingstad wrote: >>>> P� Thu, 10 Sep 2009 10:03:39 +0200, skrev Dave Searles >>>> <searles(a)hoombah.nurt.bt.uk>: >>>> This drivel [rest deleted unread] >>> I will take that as your conceding that you still don't have a >>> logical argument against what I've said. >> The reason would be that it easier to write a whole new editor than >> change it in the manner you suggested. >> There is some 1000 modes that require things to work the way they do >> now. If you were to, say, remove the minibuffer which you seem to >> hate, it breaks everything. > > I don't see that. I doubt there is much code at all that works with the > minibuffer explicitly. If you wanted everything to go to popups or > separate windows or whatever, almost no code except that specifically > implementing the minibuffer should be affected. If the code is properly modularized, yes. The chances of that being unguessable, though. Unfortunately code quality is a highly variable thing in practice. Anyone who's had to maintain (part of) a pre-existing code base on the job surely knows that. > But I have not seen an understandable gain Usability, and further progress on the ongoing project of modernizing its user interface for the 21st century. So maybe it will be fully "caught up" to the contemporary state of the art in time for the dawn of the 22nd. I would suggest, though, that the modes be updated anyway. You won't want to replace the minibuffer with a freefloating window frame that just has a label and an input field. That's basically just putting the minibuffer into its own window rather than making a *deep* change. A *deep* change would be replacing various uses of the minibuffer for prompting with distinct, specialized dialogs that can provide actual gains, such as using checkboxes and other such input methods instead of typed text where appropriate, providing drop-down lists of recent choices or other such enhancements, providing groups of related knobs and dials in one place instead of having a variety of arcane key-bindings to each prompt for something in the minibuffer to tweak each separate thing, and providing wizards to walk users through a particular sequential process, again instead of just a bunch of arcane key-bindings and separate minibuffer promptings, plus this time a note buried in the massive help file stating when to use these and to use them in a particular sequence. (Or, if it was sophisticated enough, maybe a single arcane key binding that triggers a series of minibuffer promptings that proceed automatically; that's almost a proper wizard, save the awkward method of invoking it to begin with and the fact that each step can only give a very brief bit of instruction and prompt for a short-ish line of text rather than display more detailed instructions, permit other forms of input than manual typing of a textual representation of the input, permit long inputs, permit a complex input to be provided through several separate widgets each suited to its part of the task rather than as a single monolithic text string with some arcane syntax, etc.) >> Similarly C-C is bound to made specific commands. So changing it >> wrecks havoc with all mode specific commands. > > Yes. No. If the system was designed at all intelligently, that "the key for this is C-c" fact is specified in exactly one place in the code, and can be changed there (and global search and replaced in the documentation), and I win. On the other hand, if the system was designed unintelligently enough that "the key for this is C-c" is specified redundantly all over the editor's code base (or worse, in the code bases for all the modes!) then this fact of extremely unintelligent design supports a contention of "emacs sucks, it has boneheaded design and makes it impossible to update it in some ways or fix some legacy issues with it, which wouldn't have been a problem if its code had been better-modularized and had adhered to the principle of specifying each fact in only one place" and I win again, by a different path. Checkmate.
From: Dave Searles on 13 Sep 2009 06:43 Turgut Durduran wrote: > On 2009-09-11, Dave Searles <searles(a)hoombah.nurt.bt.uk> wrote: >> Turgut Durduran wrote: >>> On 2009-09-10, Dave Searles <searles(a)hoombah.nurt.bt.uk> wrote: >>>>> What you say is, in its own terms, true, but we don't accept these terms. >>>> Tough. Objective ones are the only terms I'm offering. >>> "objective"? I never seen you give the list of standards or a methodology >>> to judge them. >> Then perhaps you ought to reread the thread. > > [says I'm a liar] I will take that as your conceding that you still don't have a logical argument against what I've said. >>>> Any key sequence is the equal of any other key sequence that's no >>>> longer, so the only way they can be "essential to emacs" in a way that >>>> is damaged by simply moving one or two of them away from keys like >>>> control-C that are supposed to do something else is if it is "essential >>>> to emacs" that users struggle with its interface and have problems with >>>> simple actions like cut, copy, and paste. >>> Why should I use non-standard things like control-C in my text-editor >>> when it matches how everything else works? >> Huh? Control-C for copy is quite standard. Text editors that bind >> control-C to copy comprise 99.99%+ of the text-editor market share. It >> doesn't get much more defacto standard than that. > > You defined "standard" as how everything else that I use behaves No, I defined "standard" as how everything that normal users use behaves. >> As for dejure, there's >> a written CUA standards document out there somewhere. > > I am sure there is. So, you have accepted the truth.
From: Dave Searles on 13 Sep 2009 06:50
Alan Mackenzie wrote: > In comp.emacs Dave Searles <searles(a)hoombah.nurt.bt.uk> wrote: >> Alan Mackenzie wrote: > >>> but the fact it[Emacs]'s got a substantial enthusiastic following is >>> good evidence for its intrinsic goodness. > >> Don't be ridiculous. Radium watches had a substantial enthusiastic >> following in the 50s. So did thalidomide. In the 30s it was Nazism. > > What's this? Are you trying to demonstrate Godwin's law? No, I am trying to rebut the ludicrous claim that something having an enthusiastic following is evidence that it is intrinsically good. And I am fairly sure I succeeded. That your response is a random hodgepodge of irrelevancies lacking even an internally consistent topic, let alone having any bearing whatsoever upon the point actually at issue, I shall take as strong evidence that you are incapable of formulating a cogent, logical rebuttal to my previous statement; most likely because no such rebuttal is capable of existing, and emacs's "enthusiastic following" (which appears at this time to consist of maybe a few hundred, maybe up to a few thousand geeks mentally masturbating in their mommies' basements and vigorously flaming people on usenet) is in fact evidence of absolutely nothing. > Look, Dave, I do hope you manage to find a job soon. I really do. I believe I mentioned in another post that I have a job. Perhaps you did not read that one. Certainly you seem not to have read (or at least comprehended) much of this thread, and certainly its length and the size of some of the individual posts makes it not unreasonable that someone might have bothered themselves to read only some branch or another of it. Regardless, though, I do have one, though your remark seems to be apropos of nothing, neither bearing obvious relation to my prior statements nor having anything to do with your own immediately-preceding sentences. |