F***ing Iambic pentameter (was Re: Great SWT Program)

On 2007-11-30 18:01:04 -0800, nebulous99@gmail.com said:


Arguably the "most vanilla" is GNU Emacs, as it is often the variant
that comes preinstalled or comes packaged as "emacs"; it's also
primarily maintained by the same guy who wrote the original EMACS:
Richard Stallman. It's had GUI support since 1993 and was the variant
I provided screenshots of.

The only other variant that comes close to the same popularity is
XEmacs (nee Lucid Emacs), which has had a GUI since 1992.

Given your relatively brief experience with Unix and emacs, I find it
very unlikely you used some other variant; on most distributions you
have to actively seek out other variants or be told they exist. Did
you have a specific variant in mind when you said "more vanilla"?

Incidentally, if you hate emacs and vi so much, you might want to
reconsider your career as a Java programmer. Of the four people who
designed the language, Guy L. Steele wrote one of the original EMACS's
predecessors and contributed directly to Stallman's original EMACS,
James Gosling wrote a C port (GOSMACS) from scratch (and if JWZ's
timeline is to be believed, GNU Emacs is partially derived from it),
and Bill Joy is the author of vi.


Here, find short a list of tools that tell
ways to shape and form the machine's thinking,
brought from the west coast by NeXT and Apple.
Starting with Automator, for linking
packaged parts, themselves provided
by others. Applescript complements it,
a complete language for people who
don't write "real code." The traditional bits
are there, two shells, two gems, under one snake
perl for the terse, ruby for the hip, and
python for people who can't decide.
Edit with emacs or vi, at hand.
Out of the box, you have Java SE
And a native SDK and IDE.

Apple is doing an extremely good job of making the transition from mere
automation to programming to development as seamless and gradiential as
possible. Automator and Script Editor both enable relatively
inexperienced users to create small tools of their own, starting with
existing software as a base. Script Editor is sufficient to write new
programs; the Applescript language is complete, if rather verbose.
They've also provided a set of more traditional programming tools, out
of the box, comparable to any other Unix, and dwarfing those available
for Windows (off the top of my head, Windows Scripting Host and cmd.exe
are built-in; all others are either separate downloads or products you
pay for).


I am unable to locate any passages in the Apple HIG that either state
or imply that searches should ignore whitespace. That would also
contradict the behaviour of Apple's own applications (the showcase for
the Apple HIG rules), which treat leading spaces in search queries as
part of the search. The only Apple program I can think of that doesn't
behave like this when searching is Spotlight, which uses whitespace to
delimit search terms (and doesn't fit the same UI model as
application-managed searches, anyways); searching for " some text",
however, matches files with exactly that string in them, indicating
that when it encounters leading whitespace within a search atom it
leaves it alone.

Controls that do not accept leading whitespace should instead not allow
it to be entered in the first place, or the UI should prevent the input
from being acted on at all (say, by disabling the "Search" button and
displaying a small warning under the search prompt explaining why), and
should not silently alter the user's input. Silently modifying the
input prior to processing it makes an application less predictable,
which is contrary to the whole spirit of consistent UI guidelines.

Unless you are able to support your assertion that the Apple HIG
recommends stripping whitespace from control inputs after the fact, or
recommends ignoring leading whitespace in searches with evidence (for
which I have already searched and come up empty-handed), I will
conclude that your claim is a lie meant to give your other assertions
an illusion of support.