bye for now....
Ray Dillinger
Yesterday I had a Profound Idea.
One of those ideas that comes along maybe six or seven times
in a lifetime, if you're smart and think a lot about programming
languages and systems.
As a consequence of this Profound Idea, I think I know a way to
do what nobody has been able to do for forty years - make a
computer language fundamentally more powerful and expressive
than any other Lisp dialect which has ever existed, but which
is also scalable to large projects and amenable to separate
compilation.
Therefore I will be spending the next few months tinkering with
fundamentals deep inside the heart of a Lisp compiler.
The roguelike game I've worked on, currently about half-finished,
goes on a back burner, and I will probably quit reading here in
a couple of weeks. I'll be back in about six months or a year
from now when I have a functioning demo of a new programming
language.
Bear
The Sheep
Ray Dillinger napisal(a):
> As a consequence of this Profound Idea, I think I know a way to
> do what nobody has been able to do for forty years - make a
> computer language fundamentally more powerful and expressive
> than any other Lisp dialect which has ever existed, but which
> is also scalable to large projects and amenable to separate
> compilation.
Take your chance, we're holding our thumbs for you.
We'reawaiting the new language with anxiety :)
--
Radomir @**@_ Bee! .**._ .**._ .**._ .**._ zZ
`The Sheep' ('') 3 (..) 3 (..) 3 (..) 3 (--) 3
Dopieralski .vvVvVVVVVvVVVvVVVvVvVVvVvvVvVVVVVVvvVVvvVvvvvVVvVVvv.v.
ABCGi
> Dnia Sun, 13 Mar 2005 16:05:54 GMT,
> Ray Dillinger napisal(a):
>
>>As a consequence of this Profound Idea, I think I know a way to
>>do what nobody has been able to do for forty years - make a
>>computer language fundamentally more powerful and expressive
>>than any other Lisp dialect which has ever existed, but which
>>is also scalable to large projects and amenable to separate
>>compilation.
>
> Take your chance, we're holding our thumbs for you.
> We'reawaiting the new language with anxiety :)
Good luck!
--
ABCGi (geek) http://codemonkey.sunsite.dk S14 D15 C13 I17 W9 c12
GCS/IT$/L/B$ d+(-) s: a? C++ ULUSU-- P+ L+>++ E- W++$ N+ o+ K--
w+++(--)$ O- !M- V PS++(+) PE-@ Y+(++) PGP>++ t++ 5+ X R(+++) tv
b++(+) DI++++ D+++ G e++>+++ h++(home office!) r++ y++* BAS-----
Hansjoerg Malthaner
> As a consequence of this Profound Idea, I think I know a way to
> do what nobody has been able to do for forty years - make a
> computer language fundamentally more powerful and expressive
> than any other Lisp dialect which has ever existed, but which
> is also scalable to large projects and amenable to separate
> compilation.
Wow! I wish you success for your new project. I, too, think current
languages are very restricted, yet I don't have an idea how to change
that. If you can, all power to you :)
> Bear
--
c.u. Hajo
Twisted One
> Wow! I wish you success for your new project. I, too, think current
> languages are very restricted, yet I don't have an idea how to change
> that. If you can, all power to you :)
Adding the ability to define scoped language extensions via a grammar
and translation rules to the original language, perhaps. Maybe the
language should use XML, and XSLT? Then any higher level structure you
can dream of, just about, can be created.
--
http://www.gnu.org/philosophy/right-to-read.html
Palladium? Trusted Computing? DRM? Microsoft? Sauron.
"One ring to rule them all, one ring to find them
One ring to bring them all, and in the darkness bind them."
Hansjoerg Malthaner
> Hansjoerg Malthaner wrote:
>
>> Wow! I wish you success for your new project. I, too, think current
>> languages are very restricted, yet I don't have an idea how to change
>> that. If you can, all power to you :)
>
> Adding the ability to define scoped language extensions via a grammar
> and translation rules to the original language, perhaps. Maybe the
> language should use XML, and XSLT? Then any higher level structure you
> can dream of, just about, can be created.
Evolution:
1) Simple stuff, simple use
2) Complex features, diffucult use
3) Complex features, simple use
XML and XSLT are not yet in the "Complex features, simple use" phase, I
think.
--
c.u. Hajo
Jakub Debski
> As a consequence of this Profound Idea, I think I know a way to
> do what nobody has been able to do for forty years - make a
> computer language fundamentally more powerful and expressive
> than any other Lisp dialect which has ever existed, but which
> is also scalable to large projects and amenable to separate
> compilation.
Beeing always pesimistic ;) I think you should answer a few question before
you'll start :)
1. Is creating a completely new language necessary?
2. Is that new language has a chance to become popular?
3. Who will write compilers for it?
4. There are already a lot of Lips dialects. Will your language be so
original and powerful?
http://en.wikipedia.org/wiki/Lisp_programming_language#Genealogy_and_variants
5. Have you ever tried to write your own compiler? I did. It's a really
hard and time consuming work...
Well... it's of course your time and your ideas :)
If these thoughts don't let you sleep, then realise them.
regards,
Jakub
--
"We're just toys in the hands of Xom"
xenocide.e-plan.pl - SF roguelike in development
www.graveyard.uni.cc - visit Roguelike Graveyard
www.alamak0ta.republika.pl - my other projects
Jeff Lait
> Yesterday I had a Profound Idea.
>
> One of those ideas that comes along maybe six or seven times
> in a lifetime, if you're smart and think a lot about programming
> languages and systems.
>
> As a consequence of this Profound Idea, I think I know a way to
> do what nobody has been able to do for forty years - make a
> computer language fundamentally more powerful and expressive
> than any other Lisp dialect which has ever existed, but which
> is also scalable to large projects and amenable to separate
> compilation.
>
> Therefore I will be spending the next few months tinkering with
> fundamentals deep inside the heart of a Lisp compiler.
Please let us know how this turns out. Even if it turns out not to
work. In that case I want to be forewarned in case I ever think of
that idea myself... :>
To make it scalable to large projects I think you are going have to
invest in bondage and discipline programming techniques, however.
There are somethings in the world I'd like to be proven wrong about,
however.
--
Jeff Lait
(POWDER: http://wwww.zincland.com/powder0
Ray Dillinger
>
> Evolution:
>
> 1) Simple stuff, simple use
> 2) Complex features, diffucult use
> 3) Complex features, simple use
>
> XML and XSLT are not yet in the "Complex features, simple use" phase, I
> think.
Good ideas make good things better. Great ideas make better
things simple.
Bear
Ray Dillinger
> Dnia Sun, 13 Mar 2005 16:05:54 GMT, Ray Dillinger napisał(a):
>
>>As a consequence of this Profound Idea, I think I know a way to
>>do what nobody has been able to do for forty years - make a
>>computer language fundamentally more powerful and expressive
>>than any other Lisp dialect which has ever existed, but which
>>is also scalable to large projects and amenable to separate
>>compilation.
>
>
> Beeing always pesimistic ;) I think you should answer a few question before
> you'll start :)
> 1. Is creating a completely new language necessary?
Nope. :-) It's a "bug-fix" to the idea of what Lisp is.
In theory, I could adapt an existing Common Lisp or Scheme
to have new and radically different function call semantics
that only become apparent when the new capabilities are
specifically invoked. Although it is not possible to do
what I intend and remain strictly conformant to the
standard for either language, the differences could be
made subtle enough not to impact most extant code.
> 2. Is that new language has a chance to become popular?
Not terribly likely. It will most likely appeal to a subset
of those who currently like Lisps, which is a small minority
of programmers. Maybe a hundred or two hundred Lisp programmers
will understand what the hell happened and get really fanatical
about it, about another thousand will get it and protest by
saying "but that's totally insane!" and the vast majority,
even of LISP programmers, will go, "Huh? I don't get it."
And then there will be a half-dozen university papers and
maybe in ten years or so people will be saying it was
obvious all along and building the idea into other new
lisps, a few of which will eventually become popular.
> 3. Who will write compilers for it?
Like I care? Me, I guess. Hmmm. Actually, I think 3 or 4 of
"mad-scientist-tinkering-in-the-basement" types, like myself,
will "get it", get really fanatical about it and think it's
insanely great and just HAVE TO write their own implementation.
But that'll be it, until time mellows the strangeness of it and
people start thinking it was obvious the whole time.
> 4. There are already a lot of Lips dialects. Will your language be so
> original and powerful?
:-) Yes.
> http://en.wikipedia.org/wiki/Lisp_programming_language#Genealogy_and_variants
> 5. Have you ever tried to write your own compiler? I did. It's a really
> hard and time consuming work...
I've done it twice now. And you're right, it's hard and time-consuming.
I've got a head start on this because my last compiler was a lisp system
in the first place, and supported a lot of different macrology and mu
functions; most of the infrastructure is already in place.
Bear
Ray Dillinger
> The Sheep wrote:
>
>> Take your chance, we're holding our thumbs for you.
>> We'reawaiting the new language with anxiety :)
>
>
> Good luck!
Thanks.
Bear
Ray Dillinger
> Hansjoerg Malthaner wrote:
>
>> Wow! I wish you success for your new project. I, too, think current
>> languages are very restricted, yet I don't have an idea how to change
>> that. If you can, all power to you :)
Thanks, Hajo. I appreciate the good wishes.
> Adding the ability to define scoped language extensions via a grammar
> and translation rules to the original language, perhaps. Maybe the
> language should use XML, and XSLT? Then any higher level structure you
> can dream of, just about, can be created.
Nah. Lisp already had that. You'd just use the readtable with a
macro or two to implement it.
My epiphany was that functions and macros don't have to be different
things. I figured out how to make first order (code-transforming)
functions (which have up till now been macros in lisp) first-class
values in the language as well, that you can pass to or return from
functions, store in structures, call dynamically, apply, map, etc,
just like any other function.
This will eliminate some kinds of namespace conflicts, eliminate
all intermodule compile-time interdependencies, eliminate the
need for a separate defmacro form, etc, while also making
functions more fundmentally powerful by giving them control not
only of when, but how and in what environment their arguments
are evaluated.
It's like fixing a crack in the mathematical foundations of the
language. most of the "wizardly" uses of it will also be terribly
expensive in CPU, which is why I expect controversy - but it's the
first thing since lisp macros were introduced almost 45 years ago
that substantively *ADDS* capabilities that weren't already there.
Bear
Twisted One
> Nope. :-) It's a "bug-fix" to the idea of what Lisp is.
I hope it's more human-readable than the original, and people can use
their choice of text editor. ;)
Ray Dillinger
> Ray Dillinger wrote:
>
>> Nope. :-) It's a "bug-fix" to the idea of what Lisp is.
>
>
> I hope it's more human-readable than the original, and people can use
> their choice of text editor. ;)
Sorry, still going to stick with the fully-parenthesized prefix
notation and code-data correspondence. Which is what most people
are complaining about when they say it's hard to read Lisps.
Lisp code is a direct expression of a data representation of
its own parse tree. The ability to manipulate that data using
the same language that manipulates any data is why a Lisp can
rewrite its own code. Lots of people who "don't get it" about
Lisp macros have tried to get rid of the parens, and in every
case they've sacrificed this ability; they wind up with
something like Dylan or ML, which, although cool, don't have
the fundamental metacoding abilities of a Lisp.
And it is those abilities, which depend on the code being its
own parse tree, that are what I'll be making more intense. The
parens aren't going away. In fact the reasons for them will
be getting stronger.
Bear
Twisted One
> And it is those abilities, which depend on the code being its
> own parse tree, that are what I'll be making more intense. The
> parens aren't going away. In fact the reasons for them will
> be getting stronger.
No wonder nobody uses lisp anymore, if it's not only write-only and
self-modifying, but it's supposed to stay that way, or even get worse.
:) That's the surest route to unmaintainability I know of.
Doesn't help that the only lisp environments I've seen seem to use their
own little command line environment, with no full-screen code editing or
other capabilities, so it's like using a late-70s BASIC. And, of course,
there's usually less capability than ANSI C, which was designed with
text terminal systems in mind making programming portable graphical
apps, network apps etc. nigh-impossible. At least with pointers and
other low level features programming *non-portable* graphical apps in C
is possible. LISP, however...
MSCHAEF.COM
Ray Dillinger <be...@sonic.net> wrote:
...
>My epiphany was that functions and macros don't have to be different
>things. I figured out how to make first order (code-transforming)
>functions (which have up till now been macros in lisp) first-class
>values in the language as well, that you can pass to or return from
>functions, store in structures, call dynamically, apply, map, etc,
>just like any other function.
Have you seen this:
http://www.linearity.org/bawden/mtt/
-Mike
--
http://www.mschaef.com
Martin Read
>Doesn't help that the only lisp environments I've seen seem to use their
>own little command line environment, with no full-screen code editing or
>other capabilities, so it's like using a late-70s BASIC.
One of the two full-screen text editors at the incandescent heart of the
text editor holy wars is a lisp environment, although it implements a
somewhat crippled dialect of lisp.
--
Martin Read - my opinions are my own. share them if you wish.
My roguelike games page (including my BSD-licenced roguelike) can be found at:
http://www.chiark.greenend.org.uk/~mpread/roguelikes.html
NP: Maruta Kommand - Mass Grave (Melek-Tha Remix)
Twisted One
> twist...@gmail.invalid wrote:
>
>>Doesn't help that the only lisp environments I've seen seem to use their
>>own little command line environment, with no full-screen code editing or
>>other capabilities, so it's like using a late-70s BASIC.
>
> One of the two full-screen text editors at the incandescent heart of the
> text editor holy wars is a lisp environment, although it implements a
> somewhat crippled dialect of lisp.
Elisp doesn't count, since it's just being used as a scripting language,
and emacs doesn't count as a proper editor anyway, since it's not a
graphical editor with all the nice features one expects such as the
ability to select text with the mouse or to actually accomplish stuff
without ever having to hold more than 3 keys down at one time. :P
:)
Ray Dillinger
Oh yeah. Been all over it. He has first-class macros, but
they're very limited. Compile-time only, not runtime, and
still not unified with functions. It's good work though.
Bear
Glen Wheeler
"Twisted One" <twist...@gmail.invalid> wrote in message
news:X6WdnabAFrm...@rogers.com...
> Martin Read wrote:
>> twist...@gmail.invalid wrote:
>>
>>>Doesn't help that the only lisp environments I've seen seem to use their
>>>own little command line environment, with no full-screen code editing or
>>>other capabilities, so it's like using a late-70s BASIC.
>>
>> One of the two full-screen text editors at the incandescent heart of the
>> text editor holy wars is a lisp environment, although it implements a
>> somewhat crippled dialect of lisp.
>
> Elisp doesn't count, since it's just being used as a scripting language,
> and emacs doesn't count as a proper editor anyway, since it's not a
> graphical editor with all the nice features one expects such as the
> ability to select text with the mouse or to actually accomplish stuff
> without ever having to hold more than 3 keys down at one time. :P
>
> :)
>
So says you. I say you don't know how to use emacs if that is the case.
Both the aforementioned editors have many more abilities than most graphical
utilities.
--
Glen
L:Pyt E+++ T-- R+ P+++ D+ G+ F:*band !RL RLA-
W:AF Q+++ AI++ GFX++ SFX-- RN++++ PO--- !Hp Re-- S+
Twisted One
> So says you. I say you don't know how to use emacs if that is the case.
> Both the aforementioned editors have many more abilities than most graphical
> utilities.
Yeah but you can't see what you can do at a glance, there's no online
help in hypertext format in a separate window, and more generally you
can't just sit down at it and bang away and be productive in almost no
time, the way you can with a *real* graphical editor.
David Damerell
>Glen Wheeler wrote:
>>So says you. I say you don't know how to use emacs if that is the case.
>>Both the aforementioned editors have many more abilities than most graphical
>>utilities.
>Yeah but you can't see what you can do at a glance, there's no online
>help in hypertext format in a separate window,
No. There's help in the _same_ window, conveniently divided into two parts
so you may continue to read it while looking at what you are doing.
> and more generally you
>can't just sit down at it and bang away and be productive in almost no
>time, the way you can with a *real* graphical editor.
Unfortunately, ease of initial approach often seems to work against
ultimate power, and that is certainly the case here.
--
David Damerell <dame...@chiark.greenend.org.uk> Distortion Field!
Today is First Gouday, March.
Twisted One
>>Yeah but you can't see what you can do at a glance, there's no online
>>help in hypertext format in a separate window,
>
> No. There's help in the _same_ window, conveniently divided into two parts
> so you may continue to read it while looking at what you are doing.
Only now you have to look at both of them through keyholes, about 50
characters wide and five high. That's a lot of fun. No hyperlinks, and
nothing like normal window pane behavior (e.g. control-tab to switch
panes, click in a pane to switch to it, arrow key navigation, etc.) adds
to the fun. It's much quicker to alt-tab to a separate window and have
both maximized IMO.
A major part of the problem with apps like emacs is that they use legacy
UIs and bindings instead of industry standard ones. It's like learning a
whole new operating system just to learn one app. And with a bunch of
unix-heritage apps, it's like learning a whole new operating system for
each and every one of them, because unlike all Windows programs, all
Unix programs don't use standard bindings and UI metaphors for standard
actions. If two Windows apps both have a particular feature or function,
you can bet unless it's rather esoteric or the resemblance is
superficial, they are achievable using the same inputs. If two unix apps
have a particular feature or function, you can bet they go to great
lengths to make the user accomplish this one task as differently as
possible in the two apps, and force them to use both hands, their nose,
and their tongue holding down keys in at least one of them.
> Unfortunately, ease of initial approach often seems to work against
> ultimate power, and that is certainly the case here.
It doesn't have to. Basic functionality can be done in a standardized
way while still having advanced functionality.
David Damerell
>David Damerell wrote:
>>>Yeah but you can't see what you can do at a glance, there's no online
>>>help in hypertext format in a separate window,
>>No. There's help in the _same_ window, conveniently divided into two parts
>>so you may continue to read it while looking at what you are doing.
>Only now you have to look at both of them through keyholes, about 50
>characters wide and five high.
If by that you mean 80x40 or so, yes. The editor can use as much of your
screen real estate as you like. What it doesn't do (although one could
make it do so) is demand varying amounts of it based on what it is doing,
which is a recipe for Windows-style annoyance where you are never able to
see everything you are doing at once.
>to the fun. It's much quicker to alt-tab to a separate window and have
>both maximized IMO.
That's completely braindead. You can't even see what you are doing at the
same time as reading the documentation!
>>Unfortunately, ease of initial approach often seems to work against
>>ultimate power, and that is certainly the case here.
>It doesn't have to.
It doesn't have to be that way, maybe, but it _is_ that way. If you choose
an editor that is initially easy to learn it will never be as good as
Emacs in the hands of an expert - or as lightning fast for simple editing
as vi in the hands of an expert.
Twisted One
> If by that you mean 80x40 or so, yes.
How do you get that from dividing 80x25 into two panes?!
> It doesn't have to be that way, maybe, but it _is_ that way. If you choose
> an editor that is initially easy to learn it will never be as good as
> Emacs in the hands of an expert - or as lightning fast for simple editing
> as vi in the hands of an expert.
Lightning fast? Are you mad? Spending 1/4 of your time attempting to
actually perform your main task and 3/4 attempting to navigate
documentation in an arcane interface with no hyperlinking isn't my idea
of "lightning fast" -- or "fun", for that matter. I'd rather get some
actual work done than spend literally days attempting to grok what
amounts to an entire new operating system.
The Sheep
Twisted One napisal(a):
> David Damerell wrote:
>> It doesn't have to be that way, maybe, but it _is_ that way. If you choose
>> an editor that is initially easy to learn it will never be as good as
>> Emacs in the hands of an expert - or as lightning fast for simple editing
>> as vi in the hands of an expert.
>
> Lightning fast? Are you mad? Spending 1/4 of your time attempting to
> actually perform your main task and 3/4 attempting to navigate
> documentation in an arcane interface with no hyperlinking isn't my idea
> of "lightning fast" -- or "fun", for that matter. I'd rather get some
> actual work done than spend literally days attempting to grok what
> amounts to an entire new operating system.
Note the word `expert' used here, which clearly indicates a person who
already knows how to use thosepowerful tools and thus doesn't have to
navigate any documentation.
By the way, I find the vim's online help very comfortable and easy to
use. And pretty complete.
Twisted One
> Note the word `expert' used here, which clearly indicates a person who
> already knows how to use thosepowerful tools and thus doesn't have to
> navigate any documentation.
The problem being you can't *become* an expert, at least not via the
normal, painless route of using it for basic stuff and then slowly
adding more complex stuff to your repertoire. Like a lot of
unix-associated stuff, it lacks a shallow end.
The Sheep
Twisted One napisal(a):
> The Sheep wrote:
>> Note the word `expert' used here, which clearly indicates a person who
>> already knows how to use thosepowerful tools and thus doesn't have to
>> navigate any documentation.
> The problem being you can't *become* an expert, at least not via the
> normal, painless route of using it for basic stuff and then slowly
> adding more complex stuff to your repertoire. Like a lot of
> unix-associated stuff, it lacks a shallow end.
I wonder where those experts are popping from then. Alternative
dimensions, probably.
Be warned that it's for people who want (and can) learn new things.
If you start with this kind of attitude (I don't like it but I have to
learn it), then you can give it up. It's kind of... you've got to love
your editor ;)
Twisted One
> Be warned that it's for people who want (and can) learn new things.
> If you start with this kind of attitude (I don't like it but I have to
> learn it), then you can give it up. It's kind of... you've got to love
> your editor ;)
Where I come from, you get to know someone *first*; *then* maybe you
fall in love. I guess in your country it's the reverse? You fall in
love, and then you get to know whoever it is you love? :P
Erik Hesselink
> The Sheep wrote:
>
>> Be warned that it's for people who want (and can) learn new things.
>> If you start with this kind of attitude (I don't like it but I have to
>> learn it), then you can give it up. It's kind of... you've got to love
>> your editor ;)
>
> Where I come from, you get to know someone *first*; *then* maybe you
> fall in love. I guess in your country it's the reverse? You fall in
> love, and then you get to know whoever it is you love? :P
Ever hear of love at first sight? ;) And you know, it is possible to
learn vim through use. Once you learn four commands, 'i' to enter insert
mode and 'ESC' to leave it, plus ':w' and ':q' to save and quit, you can
use it for simple editing. Then, once you find something you think could
be easier with a different command, the command almost always exists.
Look it up in the reference, and voila, another command learned.
Erik
Twisted One
> Ever hear of love at first sight? ;) And you know, it is possible to
> learn vim through use.
Really. I ran into it once. Opened it and attempted to type something
in, and it went nuts. An editor you don't edit by typing into is
definitely not the most perverse thing I've ever encountered, but it
ranks up there with such gems as the 2000 Florida election, the Catholic
concept of "transubstantiation", and the whole phenomeonon of Bobbit
jokes...
Point, click, type is the most basic imaginable functionality for an
editor. If something as cheap and shitty as MS Notepad can get *that*
much right, why can't the unix whizzes? I've never seen an open source
editor where the most basic editing tasks were as easy. The only thing I
can think of is that Microsoft has a software patent for "editing by
simply typing in what you want to type in" and they're afraid of running
afoul of it. ("A paint program whose user interface a normal human being
can actually navigate with both hands and a map" being the gist of an
Adobe patent probably likewise explains the perverstrosity that is the
GIMP's UI.)
> Look it up in the reference, and viola...
Why do I get the feeling that that seemingly simple and innocuous
phrase, "look it up in the reference", involves a whole new layer of
heretofore unimagined perversity accompanied by exquisite pain,
insomnia, and cerebral hemmorhage? :)
At the very least, I suspect it's not as simple as "hit F1 and navigate
with arrow and enter keys some hypertext", let alone "hit F1 and
navigate some hypertext with the FUCKING MOUSE" ... :) I'll bet there's
also a search capability, but there's no handy "Help" menu with a
"Search..." item, or any other advertisement that this exists or how to
get to it, and it doesn't work by simply typing a word or three into a
box and hitting enter. At a bare minimum, I'd expect a unix app to
expect me to learn a whole new programming language just to search its
online documentation, and undoubtedly it will differ idiosyncratically
from every other unix app and from every windows app in regards to
searching the help as well. A separate programming language for every
app's help would be about right for the typical unix environment
learning curve. There's a definite pattern of active newbie-hostility to
most unix associated things after all. Plus a generous helping of the
"not invented here" syndrome to ensure that although everything on the
machine interoperates in some technical sense, none of it actually does
anything in one standard way, however basic, so there's one key
component none of it interoperates well with -- THE USER! :)
Jeff Lait
Erik Hesselink wrote:
> Twisted One wrote:
> > The Sheep wrote:
> >
> >> Be warned that it's for people who want (and can) learn new
things.
> >> If you start with this kind of attitude (I don't like it but I
have to
> >> learn it), then you can give it up. It's kind of... you've got to
love
> >> your editor ;)
> >
> > Where I come from, you get to know someone *first*; *then* maybe
you
> > fall in love. I guess in your country it's the reverse? You fall in
> > love, and then you get to know whoever it is you love? :P
Where I come from, you get to know someone *first*; then maybe you
learn to hate them. If you are willing to give vi a fair chance, it
can sink its claws into you. At a minimum, you could come up with a
less superficial reason for your dislike than: "It has a different
paradigm for text editting than I'm used to!" If all text editors used
the same approach to editting text, we wouldn't need more than one
editor, would we? Do you write code in Word? I've tried, but the
auto-capitalization of 'i' drives me nuts.
> Ever hear of love at first sight? ;) And you know, it is possible to
> learn vim through use. Once you learn four commands, 'i' to enter
insert
> mode and 'ESC' to leave it, plus ':w' and ':q' to save and quit, you
can
> use it for simple editing. Then, once you find something you think
could
> be easier with a different command, the command almost always exists.
> Look it up in the reference, and voila, another command learned.
I didn't love vi at first sight. My first exposure was when I was
given this horridly complicated sheet of paper which neatly summarized
every possible vi command and somehow neglected to tell you how to save
things.
At some point, however, I decided to give it a good try. This time I
learned the practical approach - learn the four needed commands
(though, for some reason I always have used :x for write & quit rather
than :wq) and expand from there. Haven't wanted to look back.
To me, vi's strength is very apparent if you are editting over a
high-latency connection. With most editors you spend half your time
cursoring, with vi, you describe where you want to go and make your
change, so do not require as much feedback from the other end. If
you've ever tried to edit something with 2-3 second latency on key
presses, you'll know what I mean :>
On the other hand, I have never been a mouse person. In DOS days, my
mouse was trapped in a drawer by my computer and only extricated when
necessary. Nowadays it's primary use is to select which window I will
type in by the simple expedient of bludgeoning it into the correct
pane. I have seen skilled mouse users edit text very efficiently. It
always sort of surprises me - I guess probably for the same reason that
they'd doubt that one could edit text without a mouse to do the cursor
positioning.
Mind you, I'm not one to complain about people refusing to try new
things. My ideal desktop layout, two 80x50 consoles beside each other,
each running seperate editors split vetically once, has remained
unchanged since I discovered it when using OS/2 Warp.
I recently altered my colour scheme as it was a bit dark on my laptop,
so I do admit a small modicum of change... (Forest green title bars
with the active window border being red. The one true colour scheme!)
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
Max Bolingbroke
> Erik Hesselink wrote:
> Point, click, type is the most basic imaginable functionality for an editor. If something as cheap and shitty as MS Notepad can >get *that* much right, why can't the unix whizzes? I've never seen an
open source editor where the most basic editing tasks were
> as easy
Might I reccomend the "nano" editor? You can type straight into it, and
the key shortcuts for common commands are accessed with Ctrl and
displayed at the bottom of the screen. This includes a Help command, so
you can find out about the others at any time.
Max Bolingbroke
Twisted One
> Might I reccomend the "nano" editor? You can type straight into it, and
> the key shortcuts for common commands are accessed with Ctrl and
> displayed at the bottom of the screen. This includes a Help command, so
> you can find out about the others at any time.
Does it have a modern GUI? (Let me guess: no, since a modern GUI puts
menus with shortcut key info at the *top* of the *window*, not the
*bottom* of the *screen*.)
Twisted One
> To me, vi's strength is very apparent if you are editting over a
> high-latency connection. With most editors you spend half your time
> cursoring, with vi, you describe where you want to go and make your
> change, so do not require as much feedback from the other end. If
> you've ever tried to edit something with 2-3 second latency on key
> presses, you'll know what I mean :>
In other words, it was designed for the 1970s dumb terminals-smart
mainframes paradigm of computing; not optimized for a modern setup where
a developer has a box by his knee containing the equivalent of three
1970s supercomputers, and a full graphical interface in front of him.
> I recently altered my colour scheme as it was a bit dark on my laptop,
> so I do admit a small modicum of change... (Forest green title bars
> with the active window border being red. The one true colour scheme!)
Uh, d00d, christmas was three months ago, and it's the only permissible
excuse for such a clashing color scheme. In fact, in some jurisdictions,
your color scheme could get you fined up to $50,000 and imprisoned up to
six months.
The Sheep
Twisted One napisal(a):
> Max Bolingbroke wrote:
>> Might I reccomend the "nano" editor? You can type straight into it, and
>> the key shortcuts for common commands are accessed with Ctrl and
>> displayed at the bottom of the screen. This includes a Help command, so
>> you can find out about the others at any time.
Hey, it looks a lot like pico and pine's internal editor ;)
> Does it have a modern GUI? (Let me guess: no, since a modern GUI puts
> menus with shortcut key info at the *top* of the *window*, not the
> *bottom* of the *screen*.)
...
>In other words, it was designed for the 1970s dumb terminals-smart
>mainframes paradigm of computing; not optimized for a modern setup where
>a developer has a box by his knee containing the equivalent of three
>1970s supercomputers, and a full graphical interface in front of him.
>
>> I recently altered my colour scheme as it was a bit dark on my laptop,
>> so I do admit a small modicum of change... (Forest green title bars
>> with the active window border being red. The one true colour scheme!)
>
>Uh, d00d, christmas was three months ago, and it's the only permissible
>excuse for such a clashing color scheme. In fact, in some jurisdictions,
>your color scheme could get you fined up to $50,000 and imprisoned up to
>six months.
I see you've got a very strong idea how a `modern' interface looks like.
Wonder where you learned that.
Now think about how `proffessional' interface should look like and whether
it should be `modern'.
Note also, that there are lots of simple editors, with GUI you describe.
In fact, it takes about 5 lines of code to write one using gnome.
Jeff Lait
Inquiring minds want to know. Do you plan on contributing to this
group at some point? Or are you just here to pick fights?
Twisted One
> Now think about how `proffessional' interface should look like and whether
> it should be `modern'.
Any app should have a "shallow end" and a "deep end", not only one or
the other. This is something people in the endless
editor/gui/userfriendliness wars don't seem to get, in their constant
battles over whether shallow apps are better or deep ones. Apps with
sloping learning curves are better.
Also, there seems to be this perception that you're "pandering to the
lowest common denominator" or some such if you don't make your user
interface arcane and as different as possible from everyone else's, and
heaven help you if basic tasks are actually accomplished in the *same
way as another app in the same genre*! This seems to come from a sort of
geek machismo or even elitism -- since rocket science is cool, it should
take rocket science to type and save a short letter or do some quick and
dirty code hacking and not just to fly to the Moon, or worse, the UI
should separate the n00bs from the Real Geeks(tm) or even actively
discourage participation by the Uninitiated.
I hold no truck with this sort of elitism. When it comes to software and
user interface design I'm a populist the whole way. Basic functionality
should be basic to use, and standard stuff should be done in a standard
way across applications. The defacto standard most people have prior
experience with being Windows and very similar GUI systems, this is the
UI paradigm that should be followed, even if there are advanced features
that take more effort to learn and use their own paradigms. Somehow
there's this perception that providing a GUI and standard ways of
getting basic tasks accomplished somehow prevents the inclusion in your
software of an "Advanced" menu, a Preferences dialog with an "Advanced"
tab, some underlying scripting system, or what-have-you. This is
emphatically not the case. There's no reason you can't even retrofit a
legacy UI with a bolt-on Windows interface. Actually I've seen this
done, but it's usually done badly. It can be done well, if all basic
stuff can be done by typical methods Windows users use across apps. All
it requires is a translation layer between the GUI and the underlying,
legacy UI, as well as advanced options to enable the user to directly
access the legacy UI. (Documentation in a modern, standard format such
as HTML, with proper hyperlinks and browseable by the user's choice of
methods and in a separate window if the user so chooses is good too.)
The Sheep
Twisted One napisal(a):
> Also, there seems to be this perception that you're "pandering to the
> lowest common denominator" or some such if you don't make your user
> interface arcane and as different as possible from everyone else's, and
> heaven help you if basic tasks are actually accomplished in the *same
> way as another app in the same genre*! This seems to come from a sort of
> geek machismo or even elitism -- since rocket science is cool, it should
> take rocket science to type and save a short letter or do some quick and
> dirty code hacking and not just to fly to the Moon, or worse, the UI
> should separate the n00bs from the Real Geeks(tm) or even actively
> discourage participation by the Uninitiated.
> I hold no truck with this sort of elitism. When it comes to software and
> user interface design I'm a populist the whole way. Basic functionality
> should be basic to use, and standard stuff should be done in a standard
> way across applications. The defacto standard most people have prior
> experience with being Windows and very similar GUI systems, this is the
> UI paradigm that should be followed, even if there are advanced features
> that take more effort to learn and use their own paradigms.
vi has set it's standards long time before Windows even existed.
Even rogue inherits some of them -- they are really standard standards.
Why should it change it's UI to comply to some new, silly and totally
unintuitive interface (my favorite is a combination of ctrl+a space,
which I usually use to switch between screens, and which will replace
whole text I just type with a space in your `modern' editors).
I refuse to cripple my editor this way.
People who's first editor is vi (or any editor with similar interface,
there are whole lots of them) has absolutely no problem with them.
However they have lots of problems while using `windows' editors.
Just allow people to use the editor they like.
Martin Read
>The Sheep wrote:
>> Note the word `expert' used here, which clearly indicates a person who
>> already knows how to use thosepowerful tools and thus doesn't have to
>> navigate any documentation.
>
>The problem being you can't *become* an expert, at least not via the
>normal, painless route of using it for basic stuff
This turns out not to be the case, Neo; I know quite a large number of
people who learned to use vi and/or emacs in precisely that way.
Maybe the bug is in you.
Martin Read
>David Damerell wrote:
>> If by that you mean 80x40 or so, yes.
>
>How do you get that from dividing 80x25 into two panes?!
I don't use 80x25 terminals (except when I'm playing roguelikes in a
Linux console window rather than starting up X, or when I'm talking to
the CompactPCI single-board computers next to me at work). I use 80x55
terminals at home and 80x50 terminals at work; if my display was larger,
I'd use even larger terminals.
David, I'd guess, uses 80x80 terminals.
>> It doesn't have to be that way, maybe, but it _is_ that way. If you choose
>> an editor that is initially easy to learn it will never be as good as
>> Emacs in the hands of an expert - or as lightning fast for simple editing
>> as vi in the hands of an expert.
>
>Lightning fast? Are you mad? Spending 1/4 of your time attempting to
>actually perform your main task and 3/4 attempting to navigate
>documentation in an arcane interface with no hyperlinking isn't my idea
>of "lightning fast" -- or "fun", for that matter. I'd rather get some
>actual work done than spend literally days attempting to grok what
>amounts to an entire new operating system.
I don't like emacs very much as a text editor; if I wanted to put in
bizarre sequences of combined presses to do not-terribly-complex things,
I'd turn on my PS2 and play Mortal Kombat. But, people who do like
emacs as a text editor can do utterly terrifyingly complex things quite
easily with it.
I do like vim, and I'm very good at using it, and it has the glorious
merit that I never have to take my hands off the main part of my
keyboard.
David Damerell
>David Damerell wrote:
>>If by that you mean 80x40 or so, yes.
>How do you get that from dividing 80x25 into two panes?!
I don't. Why do I have to use 80x25?
Of course, unlike an editor surrounded by GUI junk, if I have better uses
for my screen real estate, I _can_ practically run Emacs in an 80x25
window.
>>Emacs in the hands of an expert - or as lightning fast for simple editing
>>as vi in the hands of an expert.
>Lightning fast? Are you mad? Spending 1/4 of your time attempting to
>actually perform your main task and 3/4 attempting to navigate
>documentation
An expert. An expert vi user is phenomenally quick; I'm pretty quick with
it myself, but I've seen guys do what would seem like moderately complex
tasks in less time than it would take to move your hand to the mouse and
start your fancy GUI editor.
--
David Damerell <dame...@chiark.greenend.org.uk> Kill the tomato!
Today is First Chedday, March - a public holiday.
David Damerell
>Any app should have a "shallow end" and a "deep end", not only one or
>the other.
This is true, but it isn't a choice you have at the moment. You can
either use a powerful editor or one which is easy to learn. Deal.
Also, sometimes, it's not as simple of that. Much of vi's power for
experts stems directly from the way that there _are_ insert commands
(contrary to popular belief, thinking of "insert mode" is not ultimately
helpful), and that does produce the result that you can't just start it
and type into it.
Hansjoerg Malthaner
> Quoting Twisted One <twist...@gmail.invalid>:
>
>>David Damerell wrote:
>>>Emacs in the hands of an expert - or as lightning fast for simple editing
>>>as vi in the hands of an expert.
>>
>>Lightning fast? Are you mad? Spending 1/4 of your time attempting to
>>actually perform your main task and 3/4 attempting to navigate
>>documentation
>
> An expert. An expert vi user is phenomenally quick; I'm pretty quick with
> it myself, but I've seen guys do what would seem like moderately complex
> tasks in less time than it would take to move your hand to the mouse and
> start your fancy GUI editor.
I want to second that. I'm just a beginner, but vi is ok even for me,
and I know a few people - senior programmers and sysadmins - who can
work magic with it.
--
c.u. Hajo
Ray Dillinger
> Also, there seems to be this perception that you're "pandering to the
> lowest common denominator" or some such if you don't make your user
> interface arcane and as different as possible from everyone else's, and
> heaven help you if basic tasks are actually accomplished in the *same
> way as another app in the same genre*! This seems to come from a sort of
> geek machismo or even elitism -- since rocket science is cool, it should
> take rocket science to type and save a short letter or do some quick and
> dirty code hacking and not just to fly to the Moon, or worse, the UI
> should separate the n00bs from the Real Geeks(tm) or even actively
> discourage participation by the Uninitiated.
Dude, forgive me for saying this, but this is sounding more and more
like you have some unresolved issues with something here. Learning
a new app just isn't that big a deal. Why you've blown it up into one
in your mind I don't know. But if you want something with a GUI that
works in a way "familiar" to you, you can use Kwrite or something.
This stuff does exist for unix/linux; but it's not as if anybody
who uses unix/linux cares that much about it.
> I hold no truck with this sort of elitism.
It's okay, you don't have to. It will go on existing whether you
hold truck with it or not. If you want to kill emacs, you have
to write something that's better. And I mean better in the eyes
of the people now using emacs. No amount of diatribing about
it will do squat if you don't write something better.
> When it comes to software and
> user interface design I'm a populist the whole way.
Then do what everybody else who uses Unix does: Use software
designed the way you like it. There's enough. Some stuff
you don't like happens to be popular with other Unix users.
But that's no big deal, you don't have to use it. Popularity
just doesn't count in whether something is good or not.
Bear
konijn_
I dont get it, is this is a hidden joke on windows software, or are
there 'text editing domain' specific shortcuts ? If it's just stuff
like regexp ( does vi/emacs have that ? ) or go-line; regular editors
like EditPlus have that as well.
No bashing, just curious and not willing to do man vi ;)
T.
> c.u. Hajo
David Damerell
>I dont get it, is this is a hidden joke on windows software, or are
>there 'text editing domain' specific shortcuts ? If it's just stuff
>like regexp ( does vi/emacs have that ? ) or go-line; regular editors
>like EditPlus have that as well.
Does Emacs have regular expressions? That's a new one on me - a bit like
asking if IBM have ever built a computer.
One example of how vi is very quick is that the commands are highly
orthogonal. For example, any command that acts on a block of text will
accept any cursor movement command as an argument; and there are lots of
cursor movement commands.
Slash
Yesterday I had a Profound Idea.
One of those ideas that comes along maybe sixty or seventy times in a
lifetime, if you're tired and work a lot on programming languages and
systems.
As a consequence of this Profound Idea, I think I know a way to do what
I have not been able to do for three years - make a vacation trip for a
week fundamentally more relaxing than any other trip which has ever
existed, but which also lets me have enough fun for a while.
Therefore I will be spending the next week tinkering with fundamentals
deep inside the heart of a beach.
The roguelike game I've worked on, currently about half-finished, goes
on a back burner, and I will probably quit reading here in a day. I'll
be back in about one week or two from now when I have a refreshed mind
ready to finish all my projects.
--
Slash
"I am removing Slashing Dragon and X-Dimensional Dragon from the roster.
This is supposed to be a fan club about a game devoted to virtues, not a
place to cause strife and turmoil. We don't like trolls."
Jeff Lait
> Hansjoerg Malthaner wrote:
> > David Damerell wrote::
> quick with
> > > it myself, but I've seen guys do what would seem like moderately
> complex
> > > tasks in less time than it would take to move your hand to the
> mouse and
> > > start your fancy GUI editor.
> >
> > I want to second that. I'm just a beginner, but vi is ok even for
me,
> > and I know a few people - senior programmers and sysadmins - who
can
> > work magic with it.
>
> I dont get it, is this is a hidden joke on windows software, or are
> there 'text editing domain' specific shortcuts ? If it's just stuff
> like regexp ( does vi/emacs have that ? ) or go-line; regular editors
> like EditPlus have that as well.
>
> No bashing, just curious and not willing to do man vi ;)
A man vi won't help you very much :>
First, vi is a modal editor. You are either in "command mode" or
"insert mode". The second mode is what people are used to in editors -
typing normal keys types them. The first is what confuses new users,
as regular keys are all special commands.
This means if you don't like having to hold down multiple keys to do
something, vi is for you. The keys for editting are the same as for
typing.
Second, vi's commanda are very orthogonal. They almost all take a
count and a destination. The destination can be any movement command.
Let's look at some examples...
For cursor movement, consider a quick list of commands:
$ - Move to end of line
^ - Start of line
% - Move to matching brace
w - Move to start of next word
[return] - Move down a line
[space] - Move forward a space
Some take extra arguments.
fa - Move to the next occurance of a on this line
/foo - Move to the next occurance of foo in the file
n - Repeat the last / command.
Each of these can take a count in front of them. We then have
5w - Move to start of fifth word from here
10[return] - Move down 10 lines
6fa - Move to 6th a on this line.
Now let us consider a command that does something. 'd' is the
delete-to command. As such, it takes one argument which is where to
delete to. This can be almost any movement command!
d$ - Delete to end of line
d[space] - Delete next character
d% - Delete this block of the program.
dw - Delete word
dfa - Delete up to and including the next a on this line
There is a convention that repeating the command means to apply to the
entirety of the current line:
dd - Delete this line.
Note that both the delete command, and the movement part of it can take
counts:
2dfa - Delete up to and including the next a, but do this twice.
d2fa - Delete up to and including the second a
The neat things about this 'd' command, and indeed, all the delete
commands, is that the text isn't discarded. Instead, it is put into a
buffer. The last thing deleted (or yanked with the 'y' command, that
acts like 'd' but doesn't delete the text) can be retrieved with the
'p' command. Each of the examples above can have 'd' changed with 'y'
and become a yank-to command. Or with 'c' and become a change-to
command.
To cut and paste one line is thus: ddp
To copy and paste one line is: yyp
Another deletion command is 'x' which is delete-this-character. An
example of the synergy of vis command set can be seen with this. Say I
have a tyop where I have reversed two letters.
If I move over the 'o' in the tyop, and type "xp", I will delete the o
and then put it back after the p, switching the two letters. While
there is no command "Swap two letters beside each other" in the vi
bindings that I know of, such a command can be fashioned trivially.
Twisted One
> For cursor movement, consider a quick list of commands:
> $ - Move to end of line
> ^ - Start of line
> % - Move to matching brace
> w - Move to start of next word
> [return] - Move down a line
> [space] - Move forward a space
So far it's got nothing on GUI editors save that it might be slightly
easier to use on a chicklet keyboard on a laptop that doesn't have HOME,
END, DOWNARROW, RIGHTARROW and similar keys. Aside from matching brace
and start of next word, which are, respectively, provincial to a
specific programming language family (e.g. useless if you're writing
text, or HTML, or Python code) and ambiguous. (What is a "word"?
White-space-delimited? Punctuation? Will it consider "3.14159" to be one
word or two, due to the period? Unless your idea of "words" exactly fits
the software author's, you'll be fighting this feature or simply
avoiding it rather than simply using it. Microsoft's editors keep
capitalizing an isolated letter 'i', which is a pain if you're writing
mathematics; its assumption that you're writing grammatical English /and
nothing else/ make this feature one you may end up fighting or, if you
can find out how, turning off.)
> d$ - Delete to end of line
In most windows editors, with no selection initially, SHIFT+END, DEL.
Still two keypresses. And the same two work in Thunderbird's compose
window, in Notepad, in Word, in Wordpad, in Pegasus mail's compose
window, in XNews's compose window, in a text input box in an IE window
where you're posting to a Webboard, in a text input box in a Firefox
window where you're posting to a Webboard, and so on.
Guess where "d$" does this? In vi. And *nowhere else*.
If all you ever do is text editing local files on your hard drive, then
maybe vi is for you. If you ever post to web forums, send email, post to
Usenet (which you, specifically, the poster I'm following up to,
obviously do do), or do much of anything else, then vi is different and
strange. If you use a large number of different apps to do numerous
different tasks of many different kinds, then having most apps do most
things in a standard way is far, far superior to having to learn a
separate idiosyncratic interface for every last one of them. As far as a
"modern" person who grew up with GUI workstations is concerned, learning
basic tasks like text editing/selection basics, interface and help
navigation, and so forth is part of learning the *operating system*, and
normally only needs to be done once to become productive with a huge
number of apps; with each app all that must additionally be learned is
stuff specific to that app's task domain, and mainly only to the extent
that it doesn't overlap with any other. Coding therefore boils down to
learning the language and compiler; text editing you have for free, and
a decent IDE will respect the usual text editing idioms such as
SHIFT+END, DELETE to delete to the end of the line. If of course you
don't prefer just using Notepad and compiling from a command prompt.
The unix world however effectively has a n00b learn a whole new
operating system to edit text in vi; another to edit code in some IDE;
another to compose mail; another to compose news; another to browse vi's
documentation; another to browse the IDE's documentation; another to
browse the mail app's documentation; another to browse the newsreader's
documentation; and another to set up the network connection and hardware
so that the mail app and newsreader actually work. And of course, if you
decide you prefer emacs, then you have to learn another operating
system, and a programming language (elisp), and ...
Need I go on?
The user must relearn some things separately for every app, which slows
down new-user productivity drastically, and knocks them all the way back
to square one if they start using a different app.
Familiar with Notepad, unfamiliar with Word -> productive with Word in
minutes. Later want to switch to WordPerfect -> productive with
WordPerfect in minutes. If you learned Word advanced features, many of
them will work sufficiently similarly in WordPerfect that you can be
more productive in WordPerfect in one hour with prior knowledge of Word
and Notepad than with prior knowledge of only Notepad.
Familiar with vi, unfamiliar with emacs -> productive with emacs exactly
as soon as if you had never heard of a computer before last week.
Familiar with both, unfamiliar with OpenOffice -> productive with
OpenOffice sometime next month.
Learn how to navigate Notepad's help, and you can navigate Word's,
WordPerfect's, photoshop's, the network setup wizard's, Thunderbird's,
Firefox's, IE's, Outlook's, XNews's, and so on. Learn how to navigate
vi's help, and you can navigate vi's help. Learn how to navigate emacs'
help, and now you can navigaye vi's help and emacs' help. Learn how to
navigate the gimp's help (which didn't exist the last time I had access
to a machine with the gimp installed) and now you can navigate the help
for the following: vi, emacs, and the gimp. Want to navigate the help
for the network setup now? You'll have to learn to navigate *that* help now.
The upshot: Unix can stand to learn some interoperability lessons from
Windows, as well as the other way around.
> Note that both the delete command, and the movement part of it can take
> counts:
> 2dfa - Delete up to and including the next a, but do this twice.
> d2fa - Delete up to and including the second a
These have the same effect, though. :)
> The neat things about this 'd' command, and indeed, all the delete
> commands, is that the text isn't discarded. Instead, it is put into a
> buffer. The last thing deleted (or yanked with the 'y' command, that
> acts like 'd' but doesn't delete the text) can be retrieved with the
> 'p' command.
In other words, you can't delete text *without* clobbering the text in
the clipboard. Wonderful. In Notepad, SHIFT-END, DEL doesn't clobber the
clipboard. This doesn't stop you fixing it if it was a mistake: hit
CTRL+Z to Undo, rather than CTRL+V to Paste.
> If I move over the 'o' in the tyop, and type "xp", I will delete the o
> and then put it back after the p, switching the two letters. While
> there is no command "Swap two letters beside each other" in the vi
> bindings that I know of, such a command can be fashioned trivially.
And in emacs, you do it totally differently -- you make an elisp macro
and bind it to a key. And in Notepad, you see what letter it is, hit
del, right-arrow, and type the letter, or you hit shift-arrow,
control-X, right-arrow, control-V -- okay, four keypresses instead of
two, but I assume that enter command mode, "xp", exit command mode is
*at least* four keypresses in vi!
Twisted One
> Dude, forgive me for saying this, but this is sounding more and more
> like you have some unresolved issues with something here. Learning
> a new app just isn't that big a deal.
No; learning a new operating system is. And learning a new operating
system for each and every app is a REALLY big deal. It's like being
thrown back to the 1970s or something.
Graeme Dice
> twist...@gmail.invalid wrote:
>
>>The Sheep wrote:
>>
>>>Note the word `expert' used here, which clearly indicates a person who
>>>already knows how to use thosepowerful tools and thus doesn't have to
>>>navigate any documentation.
>>
>>The problem being you can't *become* an expert, at least not via the
>>normal, painless route of using it for basic stuff
>
>
> This turns out not to be the case, Neo; I know quite a large number of
> people who learned to use vi and/or emacs in precisely that way.
If I have a text document to work on, then the vast majority of people
require that they should be able to spend less time learning the
interface than working on the document. Savings that happen down the
road don't actually matter to them.
Antoine
Twisted One wrote:
> [snip]
>
> Need I go on?
No!!
Martin Read
>If I have a text document to work on, then the vast majority of people
>require that they should be able to spend less time learning the
>interface than working on the document. Savings that happen down the
>road don't actually matter to them.
Learning enough vi to write a document doesn't take very long at all.
Graeme Dice
> Graeme Dice <grd...@NOSPAM.sasktel.net> wrote:
>
>>If I have a text document to work on, then the vast majority of people
>>require that they should be able to spend less time learning the
>>interface than working on the document. Savings that happen down the
>>road don't actually matter to them.
>
>
> Learning enough vi to write a document doesn't take very long at all.
Learning it well enough to make one want to use it instead of simply
loading up a standard editor certainly does.
Twisted One
>> Learning enough vi to write a document doesn't take very long at all.
>
> Learning it well enough to make one want to use it instead of simply
> loading up a standard editor certainly does.
It must be like tobacco, then. The first few tries are horrible, but if
you keep at it, you become addicted?
Jim Strathmeyer
> Hansjoerg Malthaner wrote:
>> Wow! I wish you success for your new project. I, too, think current
>> languages are very restricted, yet I don't have an idea how to change
>> that. If you can, all power to you :)
>
> Adding the ability to define scoped language extensions via a grammar
> and translation rules to the original language, perhaps. Maybe the
> language should use XML, and XSLT? Then any higher level structure you
> can dream of, just about, can be created.
You realize you just suggested XML to a Lisp programmer, right?
Glen Wheeler
"Twisted One" <twist...@gmail.invalid> wrote in message
news:tIydnQWdW87...@rogers.com...
> Ray Dillinger wrote:
>> Dude, forgive me for saying this, but this is sounding more and more
>> like you have some unresolved issues with something here. Learning
>> a new app just isn't that big a deal.
>
> No; learning a new operating system is. And learning a new operating
> system for each and every app is a REALLY big deal. It's like being thrown
> back to the 1970s or something.
>
What a ridiculous statement; *every* app is learning a new OS? I haven't
seen proof of that. If you're talking about emacs, I don't personally know
much about it (except that I have tried it for a few minutes. If you're
talking about vi, Vim (gvim exists for you GUI folk) or elvis....
Unless you're computer illiterate, learning vi or vim (I don't know about
emacs) is not ``as hard as learning a new OS''. Vim is not from the 70s.
Vim has been around for 13 years; younger than windows! *gasp* If you're
serious about text editing, Vim (and perhaps elvis) are easy to learn.
There is a wonderful book about it, and many communities set up to support
the new user. I don't know how slow I would be without the smart completion
of Vim and integrated features such as :make and text markers. Ever edited
a 10,000 line file? I'd go crazy without Vim.
I've managed to get my girlfriend from word to LaTeX, using the editor
TextPad for windows. She's a history major, back at uni to write a thesis.
It was hard, but it was worth it...she swears by it now. Just like most
people who graduate to a real text editor.
--
Glen
L:Pyt E+++ T-- R+ P+++ D+ G+ F:*band !RL RLA-
W:AF Q+++ AI++ GFX++ SFX-- RN++++ PO--- !Hp Re-- S+
Glen Wheeler
"Graeme Dice" <grd...@NOSPAM.sasktel.net> wrote in message
news:H%X_d.725360$8l.725223@pd7tw1no...
Not really. It only takes one command that your previous editor didn't
have to make it preferable. (And there are plenty of those.)
For me, it was only a few weeks.
Graeme Dice
> "Graeme Dice" <grd...@NOSPAM.sasktel.net> wrote in message
> news:H%X_d.725360$8l.725223@pd7tw1no...
>
>>Martin Read wrote:
<snip>
>>Learning it well enough to make one want to use it instead of simply
>>loading up a standard editor certainly does.
>
>
> Not really. It only takes one command that your previous editor didn't
> have to make it preferable. (And there are plenty of those.)
Hardly. That one command has to be simple enough to use, and it has to
be presented to the new user in an obvious enough manner that you don't
have to search for it. The other commands that your old editor has also
have to be present, have to be just as simple to use (and more
importantly to find).
> For me, it was only a few weeks.
Exactly. It took you a few weeks, which is far more than the few hours
that the vast majority of people are willing to spend learning something.
Graeme Dice
> "Twisted One" <twist...@gmail.invalid> wrote in message
> news:tIydnQWdW87...@rogers.com...
<snip>
> I've managed to get my girlfriend from word to LaTeX, using the editor
> TextPad for windows. She's a history major, back at uni to write a thesis.
> It was hard, but it was worth it...she swears by it now. Just like most
> people who graduate to a real text editor.
This might be relevant were LaTeX a text editor and not a programming
language. The actual editor you use to write LaTeX code is pretty much
irrelevant to the final outcome.
Glen Wheeler
It's relevant since *TeX dialects are seen as ``too hard'' and ``elitist''
by many. Until they actually try to do it.
Glen Wheeler
> Glen Wheeler wrote:
>> "Graeme Dice" <grd...@NOSPAM.sasktel.net> wrote in message
>> news:H%X_d.725360$8l.725223@pd7tw1no...
>>
>>>Martin Read wrote:
>
> <snip>
>
>>>Learning it well enough to make one want to use it instead of simply
>>>loading up a standard editor certainly does.
>>
>>
>> Not really. It only takes one command that your previous editor didn't
>> have to make it preferable. (And there are plenty of those.)
>
> Hardly. That one command has to be simple enough to use, and it has to be
> presented to the new user in an obvious enough manner that you don't have
> to search for it. The other commands that your old editor has also have
> to be present, have to be just as simple to use (and more importantly to
> find).
>
For programmers, I doubt a :make command exists in their (shoddy) editors.
Or gd, gD, :clist. Just the fact that you can go :make then step throught
the lines with errors with that error at the bottom of the screen is an
incentive. Even the indentation features are far superior, with =<motion>.
Of course all the standard commands exist, syntax highlighting, folding,
etc.
As I said in another subthread, the Vim book (which is really just an
introduction) is quite good. There is a chapter devoted to programming
where (if I'd actually read the Vim book before starting to use it) the
author divulges many useful commands.
>> For me, it was only a few weeks.
>
> Exactly. It took you a few weeks, which is far more than the few hours
> that the vast majority of people are willing to spend learning something.
At that time I was also a rather annoyed university student who couldn't
understand why his lecturer wanted him to use this artifact-like editor.
How many people can drive cars? They take a while to learn. I dare say
the skill of Vim is more important to me than driving as well.
Graeme Dice
> "Graeme Dice" <grd...@NOSPAM.sasktel.net> wrote in message
> news:tD2%d.730924$8l.637752@pd7tw1no...
<snip>
>>Hardly. That one command has to be simple enough to use, and it has to be
>>presented to the new user in an obvious enough manner that you don't have
>>to search for it. The other commands that your old editor has also have
>>to be present, have to be just as simple to use (and more importantly to
>>find).
>>
>
>
> For programmers, I doubt a :make command exists in their (shoddy) editors.
Why is it that people think that IDE's lack features that they've had
for decades? Go all the way back to something like Turbo Pascal 5, and
it still has single keystrokes for building entire projects efficiently.
VC++ 6 has, without going into the use of external makefiles, F7
(compile if needed), Ctrl-F5 (compile if needed and then run), F5
(compile and run in debug mode) just off the top of my head. It also
has fairly smart indenting and allows you to go directly to the compiler
errors as well.
>>Exactly. It took you a few weeks, which is far more than the few hours
>>that the vast majority of people are willing to spend learning something.
>
>
> At that time I was also a rather annoyed university student who couldn't
> understand why his lecturer wanted him to use this artifact-like editor.
I played with vi for about an hour, emacs for about the same amount of
time. Once I realized that the documentation wasn't going to tell me
how to select blocks of text, then copy and paste in either of the
editors I just went back to notepad style editors like Kedit, that don't
try and hide their commands or force you to reprogram the editor to be
useful.
Twisted One
Twisted One
> What a ridiculous statement; *every* app is learning a new OS?
It might as well be, if every app has its own idiosyncratic UI utterly
different from every other.
Twisted One
> "Graeme Dice" <grd...@NOSPAM.sasktel.net> wrote in message
> news:H%X_d.725360$8l.725223@pd7tw1no...
>
>>Martin Read wrote:
>>
>>>Graeme Dice <grd...@NOSPAM.sasktel.net> wrote:
>>>
>>>
>>>>If I have a text document to work on, then the vast majority of people
>>>>require that they should be able to spend less time learning the
>>>>interface than working on the document. Savings that happen down the
>>>>road don't actually matter to them.
>>>
>>>
>>>Learning enough vi to write a document doesn't take very long at all.
>>
>>Learning it well enough to make one want to use it instead of simply
>>loading up a standard editor certainly does.
>
> Not really. It only takes one command that your previous editor didn't
> have to make it preferable. (And there are plenty of those.)
>
> For me, it was only a few weeks.
A few WEEKS?
sheesh.
Weeks of unproductive time spent fighting an unfamiliar UI and
helpsystem instead of getting something *done* is not my idea of a good
time.
Twisted One
> At that time I was also a rather annoyed university student who couldn't
> understand why his lecturer wanted him to use this artifact-like editor.
> How many people can drive cars? They take a while to learn. I dare say
> the skill of Vim is more important to me than driving as well.
Don't get me started on *cars*. Those have atrocious UI as well, and
failing to use them correctly can actually kill someone for God's sake.
There's another example of a whole industry of idiots that never heard
of www.asktog.com -- add to it the makers of light aircraft, and Unix
software. :)
The Sheep
Graeme Dice napisal(a):
> Glen Wheeler wrote:
>> For programmers, I doubt a :make command exists in their (shoddy) editors.
> Why is it that people think that IDE's lack features that they've had
> for decades? Go all the way back to something like Turbo Pascal 5, and
> it still has single keystrokes for building entire projects efficiently.
> VC++ 6 has, without going into the use of external makefiles, F7
> (compile if needed), Ctrl-F5 (compile if needed and then run), F5
> (compile and run in debug mode) just off the top of my head. It also
> has fairly smart indenting and allows you to go directly to the compiler
> errors as well.
Ok. So I want to write a Turbo Pascal program, I have to learn Borldan's
UI and shortcuts. I switch to Microsft Visual C++, I have to learn whole
new GUI and shortcuts. I want to try .NET, I've got to learn how to use
that obscure interface of Visual Studio. I have to write a logo program to
show it as a demo, I have to use some 10 years old editor using outdated
`modern' standards.
With vim, I just use the same editor for any text I happen to write,
including mail, news, web pages, ascii-art, latex, source codes in several
dozens different languages, config files, maps for roguelikes, etc.
And I can stil benefit from syntax highlighting, autocompletion,
autoindentation (or even more advanced automatic formatting),
spellchecking, error checking, etc.
Even when there is no syntax highlighting for some obscure text format
I happen to use (ie. my own format), I can write several lines of syntax
file and have it highlighted just the way I want.
--
Radomir @**@_ Bee! .**._ .**._ .**._ .**._ zZ
`The Sheep' ('') 3 (..) 3 (..) 3 (..) 3 (--) 3
Dopieralski .vvVvVVVVVvVVVvVVVvVvVVvVvvVvVVVVVVvvVVvvVvvvvVVvVVvv.v.
Glen Wheeler
"Twisted One" <twist...@gmail.invalid> wrote in message
> Glen Wheeler wrote:
>> "Graeme Dice" <grd...@NOSPAM.sasktel.net> wrote in message
>> news:H%X_d.725360$8l.725223@pd7tw1no...
>>
>>>Martin Read wrote:
>>>
>>>>Graeme Dice <grd...@NOSPAM.sasktel.net> wrote:
>>>>
>>>>
>>>>>If I have a text document to work on, then the vast majority of people
>>>>>require that they should be able to spend less time learning the
>>>>>interface than working on the document. Savings that happen down the
>>>>>road don't actually matter to them.
>>>>
>>>>
>>>>Learning enough vi to write a document doesn't take very long at all.
>>>
>>>Learning it well enough to make one want to use it instead of simply
>>>loading up a standard editor certainly does.
>>
>> Not really. It only takes one command that your previous editor didn't
>> have to make it preferable. (And there are plenty of those.)
>>
>> For me, it was only a few weeks.
>
> A few WEEKS?
>
> sheesh.
> Weeks of unproductive time spent fighting an unfamiliar UI and helpsystem
> instead of getting something *done* is not my idea of a good time.
>
A few weeks until I could seriously say ``Yes, Vim is more productive for
me than what I have used for the last X years.'' I wasn't fighting an
unfamiliar UI during that time, I was just learning a new UI. Only about,
say, 90% productivity for those weeks.
Twisted One
> With vim, I just use the same editor for any text I happen to write,
> including mail, news, web pages, ascii-art, latex, source codes in several
> dozens different languages, config files, maps for roguelikes, etc.
Ugh. External editing your mail and news and pasting into your mail/news
program? What a nuisance. Extra task switching, especially if you first
have to copy quoted material out, then your composed post back in ...
gah, why go to so much bother?
The Sheep
Twisted One napisal(a):
> The Sheep wrote:
>> With vim, I just use the same editor for any text I happen to write,
>> including mail, news, web pages, ascii-art, latex, source codes in several
>> dozens different languages, config files, maps for roguelikes, etc.
>
> Ugh. External editing your mail and news and pasting into your mail/news
> program? What a nuisance. Extra task switching, especially if you first
> have to copy quoted material out, then your composed post back in ...
> gah, why go to so much bother?
Your mind is backwards, windows addict ;)
Offcourse my news and mail programs allow me to select which editor to
use to edit the posts.
Krice
> A few weeks until I could seriously say ``Yes, Vim is more
productive for
> me than what I have used for the last X years.'' I wasn't fighting
an
> unfamiliar UI during that time, I was just learning a new UI.
So what makes the difference? I can't imagine how writing source code
could suddenly become more "productive" with UI from 70's when mouse
wasn't yet invented and all computer users were mad professors.
I think learning zillions of key commands, shortcuts and power macros
is one of the things for Unix people.
Twisted One
> Offcourse my news and mail programs allow me to select which editor to
> use to edit the posts.
w0t? as in, some sort of plugins? In my experience, plugins or
extensions of any kind are a fruitful source of bugs, indeterministic
behavior, and other weirdness. Ever wonder why everyone with windows has
wacky problems sometimes in Explorer, and everyone has *different* wacky
problems? It's because of "shell extensions"...
Jeff Lait
I shall treat this question seriously. Please do not think this is a
bashing of non-vi editors or mindless extolling of vi. Please also do
not think this is a chance to make cheap anti-vi comments; editor flame
wars are so last century.
Despite being a lover of vi, I could not honestly say there is an
increase in productivity.
Most programmers I know do not spend most of their time typing. Thus,
even if they had an inefficient method for typing, they'd likely
produce just as much code. Indeed, one may even argue it should be
*harder* for programmers to type, as that would result in them being
more careful with the lines they do type.
To be more explicit: Programmer productivity, in terms of "fully
debugged lines of code", would be the same if we had to chisel our code
out of granite.
I mean, we can argue till we are blue in the face if having a 'skip to
the next word command' is useful. (I don't know why we would, after
all, even notepad has Ctrl-Right to skip to the next word. People who
haven't mastered Notepad shouldn't dis vi, IMHO)
To me, the advantage of vi is quality-of-life. Out of all of the
editors I have used, and there have been many, vi has been the most
rewarding. Most editors you will feel that you have fully mastered in
a month or two. With vi, it feels like it is always providing you room
to grow.
This allows for a nice balance. If one is doing some complicated code,
one just uses dumb typing to get the job done, using all one's mind to
the task of solving the problem. But, when you are faced with a boring
sweep, one can still be entertained with the meta-game of how to
optimize the sweep. As an added bonus, those techniques you learn on
the boring sweep become part of your vocabulary, to be used
unconciously in your next complicated code edit.
The reason why I'd rather use vi than chisel out code from granite is
not because I'll get more code written. It's because I'd have more fun
doing it.
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
Krice
> It's because I'd have more fun doing it.
Having fun is always a good excuse to do things;)
I don't like to struggle with the editor or typing, I like to
save my brain cells to developing the actual program.
Graeme Dice
> Dnia Sun, 20 Mar 2005 02:10:39 GMT,
> Graeme Dice napisal(a):
>
>
>>Glen Wheeler wrote:
>>
>>> For programmers, I doubt a :make command exists in their (shoddy) editors.
>>
>>Why is it that people think that IDE's lack features that they've had
>>for decades? Go all the way back to something like Turbo Pascal 5, and
>>it still has single keystrokes for building entire projects efficiently.
>> VC++ 6 has, without going into the use of external makefiles, F7
>>(compile if needed), Ctrl-F5 (compile if needed and then run), F5
>>(compile and run in debug mode) just off the top of my head. It also
>>has fairly smart indenting and allows you to go directly to the compiler
>>errors as well.
>
>
> Ok. So I want to write a Turbo Pascal program, I have to learn Borldan's
> UI and shortcuts. I switch to Microsft Visual C++, I have to learn whole
> new GUI and shortcuts. I want to try .NET, I've got to learn how to use
> that obscure interface of Visual Studio.
Well you have to use their shortcuts, but, unlike the standard *nix
behaviour, these sortcuts are displayed in the easily accesible menu at
the top of the screen.
> With vim, I just use the same editor for any text I happen to write,
> including mail, news, web pages, ascii-art, latex, source codes in several
> dozens different languages, config files, maps for roguelikes, etc.
I still have no idea how to get wither vi or emacs to allow me to select
an contiguous arbitrary length block of characters, then copy those
characters, then paste them somewhere else without deleting the original
characters. This should be a piece of basic functionality that you
don't need to spend more than 30 seconds looking up the keyboard
shortcuts for, but after an hour of searching, I decided that I had
better ways to spend my time than in dealing with archaic interfaces
that refuse to use all of the keys available on modern keyboards.
The Sheep
Graeme Dice napisal(a):
> The Sheep wrote:
>> Dnia Sun, 20 Mar 2005 02:10:39 GMT,
>> Graeme Dice napisal(a):
>>>Why is it that people think that IDE's lack features that they've had
>>>for decades? Go all the way back to something like Turbo Pascal 5, and
>>>it still has single keystrokes for building entire projects efficiently.
>>> VC++ 6 has, without going into the use of external makefiles, F7
>>>(compile if needed), Ctrl-F5 (compile if needed and then run), F5
>>>(compile and run in debug mode) just off the top of my head. It also
>>>has fairly smart indenting and allows you to go directly to the compiler
>>>errors as well.
>> Ok. So I want to write a Turbo Pascal program, I have to learn Borldan's
>> UI and shortcuts. I switch to Microsft Visual C++, I have to learn whole
>> new GUI and shortcuts. I want to try .NET, I've got to learn how to use
>> that obscure interface of Visual Studio.
> Well you have to use their shortcuts, but, unlike the standard *nix
> behaviour, these sortcuts are displayed in the easily accesible menu at
> the top of the screen.
I don't care, I don't even look at the screen when I'm typing. I'm used to
the shortcuts (that's their purpose), and even displaying other ones with
42 point font on the screen won't help. I'm still regurally substituting
my whole text with space (ctrl-a space) whenever I'm forced to use
`modern' editor, even when I know exactly what will happen. I do it before
I can even think about it -- that's why it's fast.
>> With vim, I just use the same editor for any text I happen to write,
>> including mail, news, web pages, ascii-art, latex, source codes in several
>> dozens different languages, config files, maps for roguelikes, etc.
> I still have no idea how to get wither vi or emacs to allow me to select
> an contiguous arbitrary length block of characters, then copy those
> characters, then paste them somewhere else without deleting the original
> characters.
The [y]ank command have been already mentioned in this thread. If you
combine it with [v]isual selection and [p]aste, it should do the trick.
But it's not the fastest way to copy and paste text -- visual selection
is something that users not really used to vi yet need. It's slow and it
depends on feedback.
> This should be a piece of basic functionality that you
> don't need to spend more than 30 seconds looking up the keyboard
> shortcuts for, but after an hour of searching, I decided that I had
> better ways to spend my time than in dealing with archaic interfaces
> that refuse to use all of the keys available on modern keyboards.
I somehow don't spend an hour looking for it -- I just know.
And how could I learn that? Well, it's described on the `howto' page of
vim help (try :he howto). And it took me about 2 seconds to find it.
Also, in gvim you can just select with your mouse and then select `copy'
from the `edit' menu, but that's hard to find and obscure ;)
Martin Read
>The Sheep wrote:
>> Offcourse my news and mail programs allow me to select which editor to
>> use to edit the posts.
>
>w0t? as in, some sort of plugins? In my experience, plugins or
>extensions of any kind are a fruitful source of bugs, indeterministic
>behavior, and other weirdness. Ever wonder why everyone with windows has
>wacky problems sometimes in Explorer, and everyone has *different* wacky
>problems? It's because of "shell extensions"...
Not plugins. Standalone programs which the news/mail agent
automatically invokes based on the value of an environment variable.
I read news in trn, a newsreader. When I want to write a followup, I
press 'F' and it invokes Pnews, a news posting agent. Pnews creates a
temporary file containing the text of the followup, then invokes the
editor specified in the EDITOR environment variable, passing the
filename of the temporary file as a command-line argument, to allow me to
compose my post, add any additional headers necessary, etc. When I save
and quit from the editor, Pnews resumes control of the terminal and
presents me with some options, including (a)bort post, and if I select
(s)end it transmits my post to the news server and exits, returning
control of the terminal to trn.
I use vim as my editor, but other people might use nano, nvi, elvis, ae,
emacs, jed, joe, ...
Graeme Dice
> Dnia Sun, 20 Mar 2005 18:27:33 GMT,
> Graeme Dice napisal(a):
<snip>
>>Well you have to use their shortcuts, but, unlike the standard *nix
>>behaviour, these sortcuts are displayed in the easily accesible menu at
>>the top of the screen.
>
>
> I don't care, I don't even look at the screen when I'm typing.
What does this have to do with learning the editor in the first place?
Unless you are copying text from a written document, you should never be
looking anywhere but the screen.
> I'm used to
> the shortcuts (that's their purpose), and even displaying other ones with
> 42 point font on the screen won't help.
The world has moved on from orange and black, 80X25 displays in the past
20 years.
> I'm still regurally substituting
> my whole text with space (ctrl-a space) whenever I'm forced to use
> `modern' editor, even when I know exactly what will happen. I do it before
> I can even think about it -- that's why it's fast.
That's a problem with your knowledge of the interface, not the interface
itself. Vi refuses to move on and use meta keys, which might be
sensible were we still in 1985 and were using 120 baud connections.
>>I still have no idea how to get wither vi or emacs to allow me to select
>>an contiguous arbitrary length block of characters, then copy those
>>characters, then paste them somewhere else without deleting the original
>>characters.
>
>
> The [y]ank command have been already mentioned in this thread. If you
> combine it with [v]isual selection and [p]aste, it should do the trick.
That allows you to cut and paste text. That's not copy and paste.
> But it's not the fastest way to copy and paste text -- visual selection
> is something that users not really used to vi yet need. It's slow and it
> depends on feedback.
Who said anything about "visual selection"? Is there any way to
accomplish the equivalent of holding down shift to select text, pressing
ctrl-x to copy, and then ctrl-v to paste? Note that this has to be done
without having to press a key to go into some other kind of editing mode.
>>This should be a piece of basic functionality that you
>>don't need to spend more than 30 seconds looking up the keyboard
>>shortcuts for, but after an hour of searching, I decided that I had
>>better ways to spend my time than in dealing with archaic interfaces
>>that refuse to use all of the keys available on modern keyboards.
>
>
> I somehow don't spend an hour looking for it -- I just know.
That's because you already know how to use the program.
> And how could I learn that? Well, it's described on the `howto' page of
> vim help (try :he howto). And it took me about 2 seconds to find it.
And where is it in the vi help then?
> Also, in gvim you can just select with your mouse and then select `copy'
> from the `edit' menu, but that's hard to find and obscure ;)
That vim exists doesn't help when somebody has to use the dinosaur that
is vi.
Twisted One
> I don't care, I don't even look at the screen when I'm typing. I'm used to
> the shortcuts (that's their purpose)
Then why are they different in every single app, even for identical
functions? On Windows, where many are universal, it's a lot easier to
end up with them memorized and be able to use them purely from memory,
and *there* you actually get decent help to see what one is if you
forgot it, or it's fairly esoteric and infrequently used (at least, by a
particular user if not generally).
> and even displaying other ones with
> 42 point font on the screen won't help. I'm still regurally substituting
> my whole text with space (ctrl-a space) whenever I'm forced to use
> `modern' editor, even when I know exactly what will happen. I do it before
> I can even think about it -- that's why it's fast.
And people forced to use an 'archaic' editor have similar experiences --
they expect ctrl+V to paste and the editor freaks out. Or they expect
simply *typing* to insert text and the editor freaks out(!). Or
something. Believe me, in that regard the situation is quite symmetrical.
> The [y]ank command have been already mentioned in this thread. If you
> combine it with [v]isual selection and [p]aste, it should do the trick.
> But it's not the fastest way to copy and paste text -- visual selection
> is something that users not really used to vi yet need. It's slow and it
> depends on feedback.
We in the usability camp believe that feedback is a *good* thing. No
feedback means the computer can do something drastically wrong and
clobber hours of work before we even realize what is happening, and too
fast to stop it before it's too late. :) Using unix-style tools is like
walking through a minefield -- blindfolded. You can take off the
blindfold to read a map and memorize some mine positions, but you have
to put it back on again before you can walk. Get it wrong and your data
goes bang, rather than your foot going bang, but still...
Using a modern UI is like stepping into a nicely laid out park equipped
with a map, guidebook, and metal detector and no blindfold.
Twisted One
> I read news in trn, a newsreader. When I want to write a followup, I
> press 'F' and it invokes Pnews, a news posting agent. Pnews creates a
> temporary file containing the text of the followup, then invokes the
> editor specified in the EDITOR environment variable, passing the
> filename of the temporary file as a command-line argument, to allow me to
> compose my post, add any additional headers necessary, etc. When I save
> and quit from the editor, Pnews resumes control of the terminal and
> presents me with some options, including (a)bort post, and if I select
> (s)end it transmits my post to the news server and exits, returning
> control of the terminal to trn.
Three separate apps to do newsreading? And what about concurrency, and
what if something breaks this chain? What if the temporary file is
cleaned up? What if the user picks "Save as..." in the editor? What if
the editor ends abnormally? There's no integration between the browser
and the process that actually accesses the network?! How can you
possibly browse groups efficiently then? An internally layered
architecture is one thing, but this ... this Rube Goldberg apparatus
looks precarious as hell. Too easy for a change in one app to break one
or both of the other two, or something that happens to the interprocess
communication.
The Sheep
Graeme Dice napisal(a):
> The Sheep wrote:
>> Dnia Sun, 20 Mar 2005 18:27:33 GMT,
>> Graeme Dice napisal(a):
>>>Well you have to use their shortcuts, but, unlike the standard *nix
>>>behaviour, these sortcuts are displayed in the easily accesible menu at
>>>the top of the screen.
>> I don't care, I don't even look at the screen when I'm typing.
> What does this have to do with learning the editor in the first place?
> Unless you are copying text from a written document, you should never be
> looking anywhere but the screen.
First you say that vi sucks because it's hard to learn, and then you tell
me I should learn a dozen other editors instead?
>> I'm used to
>> the shortcuts (that's their purpose), and even displaying other ones with
>> 42 point font on the screen won't help.
> The world has moved on from orange and black, 80X25 displays in the past
> 20 years.
I mean the shortcut keys are learned, I have proper reflexes, and those
reflexes are physical thing -- just telling me to use different shortcut
key (even if you do it very loud or with large letters displayed on the
screen) won't help here -- you can only change reflexes by training.
Changing them often, however, leads to not using them at all.
> > I'm still regurally substituting
>> my whole text with space (ctrl-a space) whenever I'm forced to use
>> `modern' editor, even when I know exactly what will happen. I do it before
>> I can even think about it -- that's why it's fast.
> That's a problem with your knowledge of the interface, not the interface
> itself.
I'm not saying it's a problem with the interface itself. The problem is
that the interfaces change depending on which `modern' (and how `modern')
application I'm using. My knowledge doesn't help much here -- Word's
shortcuts even change from version to version. Ha, they even change
depending on the translation you use.
> Vi refuses to move on and use meta keys, which might be
> sensible were we still in 1985 and were using 120 baud connections.
Vi refuses to change it's interface from version to version, which is
a GoodThing(tm) because once you invest your time in learning such
a complicated interface, you don;t want to do it again.
As a side note -- you can use any keys you like -- if your keyboard has
them, you can easily bind them to any commands you feel useful. Same
with combinations.
>>>I still have no idea how to get wither vi or emacs to allow me to select
>>>an contiguous arbitrary length block of characters, then copy those
>>>characters, then paste them somewhere else without deleting the original
>>>characters.
>> The [y]ank command have been already mentioned in this thread. If you
>> combine it with [v]isual selection and [p]aste, it should do the trick.
> That allows you to cut and paste text. That's not copy and paste.
No, you're not paying attention. [d]elete allows you to cut. [y]ank only
copies text to the buffer -- it doesn' delete it.
>> But it's not the fastest way to copy and paste text -- visual selection
>> is something that users not really used to vi yet need. It's slow and it
>> depends on feedback.
> Who said anything about "visual selection"? Is there any way to
> accomplish the equivalent of holding down shift to select text, pressing
> ctrl-x to copy, and then ctrl-v to paste? Note that this has to be done
> without having to press a key to go into some other kind of editing mode.
There are no modes in vi -- it's a fake to make it easier to learn.
There are only commands. There is a command for selecting text.
Your requirement for `anchoring' one of your finger to the keyboard while
you select the text serves no purpose.
>>>This should be a piece of basic functionality that you
>>>don't need to spend more than 30 seconds looking up the keyboard
>>>shortcuts for, but after an hour of searching, I decided that I had
>>>better ways to spend my time than in dealing with archaic interfaces
>>>that refuse to use all of the keys available on modern keyboards.
>> I somehow don't spend an hour looking for it -- I just know.
> That's because you already know how to use the program.
Exactly -- and that's how 90% users are. The rookies will learn fast.
You don't want to reduce you'r editor's effectiveness only to help
newbies.
Look -- once you learn something about vim, you already know it, so
there's no use annoying you with this information reminded over and over
again. If you somehow forget it -- there's help.
>> And how could I learn that? Well, it's described on the `howto' page of
>> vim help (try :he howto). And it took me about 2 seconds to find it.
> And where is it in the vi help then?
I don't know, I don't use it. I guess you only have to read it in one
place to know it.
In fact I haven't seen the `original' vi in quite some time.
You can't require that all the programs that have similar interface (which
is de facto standard) share the same documentation, right?
>> Also, in gvim you can just select with your mouse and then select `copy'
>> from the `edit' menu, but that's hard to find and obscure ;)
>
> That vim exists doesn't help when somebody has to use the dinosaur that
> is vi.
Once you learned to use vim, learning to use vi is simple.
Offcourse, I'm not telling you to use vi. I'm not telling you to use
any editor at all, or any software at all.
I'm just telling you why I find vim (and similar interface, also used in
vi and other editors) comfortable and efficient, and how it would be
crippled if they tried to resemble `modern' editors.
I guess this thread has gone too far already, we should move to
rec.editor.ui.advocacy or something like that ;)
The Sheep
Twisted One napisal(a):
> Martin Read wrote:
>> I read news in trn, a newsreader. When I want to write a followup, I
>> press 'F' and it invokes Pnews, a news posting agent. Pnews creates a
>> temporary file containing the text of the followup, then invokes the
>> editor specified in the EDITOR environment variable, passing the
>> filename of the temporary file as a command-line argument, to allow me to
>> compose my post, add any additional headers necessary, etc. When I save
>> and quit from the editor, Pnews resumes control of the terminal and
>> presents me with some options, including (a)bort post, and if I select
>> (s)end it transmits my post to the news server and exits, returning
>> control of the terminal to trn.
> Three separate apps to do newsreading? And what about concurrency, and
> what if something breaks this chain? What if the temporary file is
> cleaned up? What if the user picks "Save as..." in the editor? What if
> the editor ends abnormally? There's no integration between the browser
> and the process that actually accesses the network?! How can you
> possibly browse groups efficiently then? An internally layered
> architecture is one thing, but this ... this Rube Goldberg apparatus
> looks precarious as hell. Too easy for a change in one app to break one
> or both of the other two, or something that happens to the interprocess
> communication.
Somehow it only happends under Windows.
You seem to be terribly afraid of all that good old solutions.
Try it sometimes, it's really comfortable to use one and the same
application when you're doing similar things.
Judging just from `what you heard' and `what you imagine', and on top of
that `what could possibly be broken but is not' is not going to lead you
far.
Do you know how many separate protocols you use when using e-mail? ;)
The Sheep
Twisted One napisal(a):
> The Sheep wrote:
>> I don't care, I don't even look at the screen when I'm typing. I'm used to
>> the shortcuts (that's their purpose)
>
> Then why are they different in every single app, even for identical
> functions? On Windows, where many are universal, it's a lot easier to
> end up with them memorized and be able to use them purely from memory,
> and *there* you actually get decent help to see what one is if you
> forgot it, or it's fairly esoteric and infrequently used (at least, by a
> particular user if not generally).
I'd rather memorize and use all the useful shortcuts, not only those that
happen to be `common' in the applications I use. And, as a bonus, I use
the same ui and the same settings.
>> and even displaying other ones with
>> 42 point font on the screen won't help. I'm still regurally substituting
>> my whole text with space (ctrl-a space) whenever I'm forced to use
>> `modern' editor, even when I know exactly what will happen. I do it before
>> I can even think about it -- that's why it's fast.
> And people forced to use an 'archaic' editor have similar experiences --
> they expect ctrl+V to paste and the editor freaks out.
It's supposed to. The *standard* in moder UIs is to use shift-insert for
paste. It's this way in Windows, MacOs, Solaris, Linux, etc.
And ctrl-c will halt your application on any POSIX-compliat system.
Talking about good windows standards, eh?
> Or they expect
> simply *typing* to insert text and the editor freaks out(!). Or
> something. Believe me, in that regard the situation is quite symmetrical.
Only they are not forced to use vim or vi. You don't have them embedded
into your rogramming GUI or mail program, with no chance to replace them
with something else.
>> The [y]ank command have been already mentioned in this thread. If you
>> combine it with [v]isual selection and [p]aste, it should do the trick.
>> But it's not the fastest way to copy and paste text -- visual selection
>> is something that users not really used to vi yet need. It's slow and it
>> depends on feedback.
> We in the usability camp believe that feedback is a *good* thing.
Yes, it's good when it's available. But requiring the user to be
constantly focused and to pay attention whether the computer didnt do
something wrong is just plain cruel.
It's good when you give the user apropriate feedback, but it's bad when
you rely on the feedback too much.
It's like playing `Gotcha! You haven't noticed that!' game.
> No
> feedback means the computer can do something drastically wrong and
> clobber hours of work before we even realize what is happening, and too
> fast to stop it before it's too late. :)
There's unlimited undo in vim and it will never do anything unexpectedly,
I mean things like popping up an `assistant' to steal focus and allow you
to type a whole paragraph into void, or some `did you know?' window.
Twisted One
> You seem to be terribly afraid of all that good old solutions.
> Try it sometimes, it's really comfortable to use one and the same
> application when you're doing similar things.
When I'm editing news I want to see that I'm in a newsreader; when I'm
editing code I want to see that I'm in a programmer's editor; etc.
How can you come back to the machine and properly orient yourself if
there's just one big full screen generic text editing window with a
random alphanumeric temp file's name in the title bar?
Why does unix insist on making the user grope about in the dark and
memorize a shitload of stuff, generally, instead of letting them turn on
the freakin' lights like any modern system, for that matter? After years
of using GUI systems, including unfamiliar ones with shoddy
documentation, being dropped into a unix setup with *decent*
documentation (if one even exists!) feels like suddenly being a
paratrooper dropped into an unfamiliar territory with a crude Braille
map, and usually results in promptly discovering the shortest route to
being hip-deep in mud in a swamp somewhere. And did I mention you
somehow have mysteriously gone blind?
> Judging just from `what you heard' and `what you imagine', and on top of
> that `what could possibly be broken but is not' is not going to lead you
> far.
Looking at a rickety house of cards architecture that has three apps,
possibly all from different vendors, doing one job and predicting that
something, somewhere, will go wrong is not exactly wild blue-sky
speculation. It's a straightforward application of Murphy's Law in fact,
and it's probably why unix systems are brittle in certain ways while
Windows is brittle in others. Unix systems can have just about any
component substituted, and what you normally think of as a single
application with a single task domain such as "a newsreader" is actually
made of separate components that are mixed and matched. The
proliferation of possible permutations and combinations makes weird
incompatibilities inevitable, and so besides the UI/usability problems
that run rampant, unix is also known for weird incompatibilities -- rpms
you install that just plain don't work, hardware that just plain isn't
detected, strange network errors that just plain aren't self-explanatory
and aren't even coming from the process that is displaying the user
interface, which means that the user interface can't tell you much more
than "something, somewhere, went wrong"; and so forth. Windows, of
course, being closed source, has lots more bugs and severe security
holes; light being the scourge of error, open source tends to have
fewer. And the undocumented APIs and legacy APIs proliferating in
Windows make all kinds of weird interactions possible. And there's the
plugin factor, which introduces the same potential wacky configuration
idiosyncrasies seen under unix -- install a paint program and it's
likely to install a shell extension and if this has a bug, Explorer now
has a new bug nobody else's Explorer has. Likewise under unix if your
editor has a bug, it sounds like your newsreader now has a bug, and so
does darn near everything else!
> Do you know how many separate protocols you use when using e-mail? ;)
POP, SMTP, and DNS I expect. I don't see how it's relevant though.
Twisted One
> Dnia Sun, 20 Mar 2005 19:28:48 -0500,
> Twisted One napisal(a):
>
>
>>The Sheep wrote:
>>
>>>I don't care, I don't even look at the screen when I'm typing. I'm used to
>>>the shortcuts (that's their purpose)
>>
>>Then why are they different in every single app, even for identical
>>functions? On Windows, where many are universal, it's a lot easier to
>>end up with them memorized and be able to use them purely from memory,
>>and *there* you actually get decent help to see what one is if you
>>forgot it, or it's fairly esoteric and infrequently used (at least, by a
>>particular user if not generally).
>
> I'd rather memorize and use all the useful shortcuts, not only those that
> happen to be `common' in the applications I use. And, as a bonus, I use
> the same ui and the same settings.
But *every single unix app does everything totally differently*! Instead
of one standard GUI toolkit all apps use (except for ones that suck,
like Quicktime and even MSOffice), every last one of them has its own,
utterly idiosyncratic UI and you have to learn them all. If Windows was
the same way, instead of "learning Windows" once and being productive
with many apps quickly, you'd have to "learn Windows" once for each app
you wanted to use -- gah, no freaking thanks!
And on top of that, those are pretty much never discoverable interfaces.
Most of the *graphical* apps aren't even discoverable interfaces (the
gimp comes to mind yet again). It's the difference between being sighted
and being blind for Christ's sake. Being blind doesn't hamper your
navigation much at home, or in other frequented settings, but it makes
every new or infrequently visited location a big pain to navigate. Ask
any blind person. Having to feel your way around or ask frequently for
directions or get someone to guide you is the result, as opposed to
being able to actually see where the hell you're going and WTF you're doing.
> It's supposed to. The *standard* in moder UIs is to use shift-insert for
> paste. It's this way in Windows, MacOs, Solaris, Linux, etc.
> And ctrl-c will halt your application on any POSIX-compliat system.
> Talking about good windows standards, eh?
Which came first is irrelevant. Which has the bigger market share is
what matters. Also which is typical on the platform most of your
prospective new users will migrate from.
I hope you don't think I dislike Linux or unix. I don't -- but I don't
like the current so-called state of the art in UI, usability,
documentation, or navigation there. My criticism is based on wanting to
see these things improved so that these systems can start to really gain
momentum on the desktop and take market share away from the big evil
Microsoft. Even they aren't perfect in the UI department, but they get
the basic stuff right -- let users actually see where the fuck they're
going and what they're doing and what the hell is going on, and let them
browse and navigate stuff visually, as well as RTM. And let them RTM in
a decent hyperlink-aware, search-capable browser -- one where links are
underlined and you can simply click them to follow them, and where you
can just type into a "search" box and hit "enter" to search, rather than
being stuck in the classic unix catch-22 of "OK, here's an unfamiliar
new app...nope, none of these keystrokes do anything analogous to the
functions they have in the other app ... let's search the help ... hmm,
I need to search the help for how to search the help. Uh-oh."
> Yes, it's good when it's available. But requiring the user to be
> constantly focused and to pay attention whether the computer didnt do
> something wrong is just plain cruel.
I don't like apps that steal the focus, squawk, and otherwise demand
attention either. On the other hand, I don't like apps that expect me to
submit a batch to them and pick up the job results, likely just an
obscure and cryptic error message, next Tuesday either. This isn't the
1960s and the era of time-sharing after all. I've got a graphical
workstation here that has the power of fifty 1960s supercomputers. I
want it to act like one, not like a 1960s-era dumb terminal.
> There's unlimited undo in vim and it will never do anything unexpectedly
Why did it do things unexpectedly the one (one!) time I attempted to use
it then? :/
And, no doubt, the unlimited undo is (in practise, if not in principle)
only available to an 8th level blackbelt with sixty years of arduous
training and (possibly expensive, or otherwise difficult to obtain)
tutelage by a master in the arcane art.
> I mean things like popping up an `assistant' to steal focus and allow you
> to type a whole paragraph into void, or some `did you know?' window.
An excellent reason to stick to Notepad and give Word a miss. Microsoft
makes mistakes too. At least they actually sometimes recognize them, and
their user base *invariably* recognizes them. Within days of that one
coming out, every MSWord user had realized "The paperclip fucking
sucks!" and most had figured out how to turn it off. Some MS employees
even realized it was a blunder. Meanwhile, vi users and other
grope-in-the-dark-interface-paradigm fans like yourself are still
defending comparable lunacy, forty years after the lunacy began. It's
like some kind of weird religious fanaticism, no doubt coupled with a
healthy dose of elitism -- you want the interface to be difficult and
the application to be all-but-unusable so that you have extra macho
points for toughing it out and using it makes you seem to be some
amazing wizard or something. It's like Tog says on his site about the
arcane user interfaces of light aircraft, despite the toll (in that case
in *human lives*) it exacts. The same psychology is clearly operating
in both cases. There's probably also some resistance to change because
you can't bear the thought that maybe your hard struggling and eventual
mastery of a cryptic, ancient interface *wasn't worth it* if it turns
out there's a far simpler and better way, and the very thought that it
might not have been worth it is one you refuse to even contemplate, so
any suggestion that might lead to having to contemplate it is resisted
as violently as if it were someone trying to shove your hand onto a hot
stove element. Unfortunately, it's actually more akin to someone trying
to jab you with a needle -- it would be just a pinprick, and it would
vaccinate you against being a complete and utter wackjob for life. :)
Ray Dillinger
> The Sheep wrote:
>
>> Dnia Sun, 20 Mar 2005 19:28:48 -0500,
>> Twisted One napisal(a):
>>
>>
>>> The Sheep wrote:
>>>
>>>> I don't care, I don't even look at the screen when I'm typing. I'm
>>>> used to
>>>> the shortcuts (that's their purpose)
>>>
>>>
>>> Then why are they different in every single app, even for identical
>>> functions? On Windows, where many are universal, it's a lot easier to
>>> end up with them memorized and be able to use them purely from
>>> memory, and *there* you actually get decent help to see what one is
>>> if you forgot it, or it's fairly esoteric and infrequently used (at
>>> least, by a particular user if not generally).
>>
>>
>> I'd rather memorize and use all the useful shortcuts, not only those that
>> happen to be `common' in the applications I use. And, as a bonus, I use
>> the same ui and the same settings.
>
>
> But *every single unix app does everything totally differently*! Instead
> of one standard GUI toolkit all apps use (except for ones that suck,
> like Quicktime and even MSOffice), every last one of them has its own,
> utterly idiosyncratic UI and you have to learn them all.
Uh, no, you don't. If you are on a unix system you have to know
exactly one text editor. Doesn't really matter whether it's
emacs or vi, because every application that needs text edited can
invoke whatever text editor you tell it to invoke whenever you
tell it you want to edit text.
In the Unix world, what's typical is for one application to do
exactly one job, and do it very very well, and pay no attention
at all to doing any other job. If you're writing a unix app that
does something else, but also needs to edit text, you check
the value of the EDITOR environment variable and invoke the
appropriate editor. You don't have to write the editor, and
the user gets the editor he's used to -- every time, all the
time, with all of his preferred customizations active.
From the user's POV, every tool that edits text edits text in
exactly the same way, using his preferred editor. If any
application invokes the "wrong" text editor or one the user's
not used to, it's because they blew it w/r/t the UI guidelines
and didn't read the user's environment settings. And Unix
users get just as angry about code that flouts UI guidelines
and conventions as Windows or Mac users, it's just that the
UI guidelines are not the ones Windows and Mac use.
You should *hear* the wailing and gnashing of teeth that accompanies
some company's release of an "IDE" that uses its own editor; it's
a strict violation of the UI convention and an insult and hindrance
to people who've been using their favorite editor for everything for
a dozen years or more and know absolutely everything about how to
edit anything using it. There's a slick IDE for C++ apps on Linux
named Kdevelop. Nobody uses it, mainly because it fails UI
conformance by not letting people invoke their preferred editors.
The "UI community" has taught us that good UI is UI which does
what the user expects. In Unix, the user expects any software
that requires text editing to invoke the user's preferred text
editor.
Bear
Glen Wheeler
"Twisted One" <twist...@gmail.invalid> wrote in message
> The Sheep wrote:
>> You seem to be terribly afraid of all that good old solutions.
>> Try it sometimes, it's really comfortable to use one and the same
>> application when you're doing similar things.
>
> When I'm editing news I want to see that I'm in a newsreader; when I'm
> editing code I want to see that I'm in a programmer's editor; etc.
>
A decent editor can be customised to be great at many things. For
example, the gggqG command (which is interpreted as gg = go to line 1, then
gq<motion> = format the <motion> text in pararaphs with fixed width
justification, then G (meaning the last line) as <motion> to specify the
entire text file) is invaluable when writing e-mail.
> [snip sillyness]
Glen Wheeler
"Twisted One" <twist...@gmail.invalid> wrote in message
> The Sheep wrote:
>> The [y]ank command have been already mentioned in this thread. If you
>> combine it with [v]isual selection and [p]aste, it should do the trick.
>> But it's not the fastest way to copy and paste text -- visual selection
>> is something that users not really used to vi yet need. It's slow and it
>> depends on feedback.
>
> We in the usability camp believe that feedback is a *good* thing. No
> feedback means the computer can do something drastically wrong and clobber
> hours of work before we even realize what is happening, and too fast to
> stop it before it's too late. :) Using unix-style tools is like walking
> through a minefield -- blindfolded. You can take off the blindfold to read
> a map and memorize some mine positions, but you have to put it back on
> again before you can walk. Get it wrong and your data goes bang, rather
> than your foot going bang, but still...
>
Vim saves all changes up to (minimum) the last write. If your editor does
something you don't want, then keep hitting u until you get back to what you
want (even if that goes as far back as the original document).
It is faster to simply type and check the screen intermittently than to
type and read everything that is going on, continual verification is very
slow and should be minimised.
> Using a modern UI is like stepping into a nicely laid out park equipped
> with a map, guidebook, and metal detector and no blindfold.
>
A modern UI would be great. If it had the power of vim, then I'd be over
the moon.
Wait, that exists. It's called gvim. What are you complaining about
again?
The Sheep
Twisted One napisal(a):
> But *every single unix app does everything totally differently*! Instead
> of one standard GUI toolkit all apps use (except for ones that suck,
> like Quicktime and even MSOffice), every last one of them has its own,
> utterly idiosyncratic UI and you have to learn them all. If Windows was
> the same way, instead of "learning Windows" once and being productive
> with many apps quickly, you'd have to "learn Windows" once for each app
> you wanted to use -- gah, no freaking thanks!
Have you even ever seen any unixs applications, or are you judging only
from a description of interface of a single text editor?
Try to examine this paper:
http://developer.gnome.org/projects/gup/hig/
Martin Read
>Martin Read wrote:
>> I read news in trn, a newsreader. When I want to write a followup, I
>> press 'F' and it invokes Pnews, a news posting agent. Pnews creates a
>> temporary file containing the text of the followup, then invokes the
>> editor specified in the EDITOR environment variable, passing the
>> filename of the temporary file as a command-line argument, to allow me to
>> compose my post, add any additional headers necessary, etc. When I save
>> and quit from the editor, Pnews resumes control of the terminal and
>> presents me with some options, including (a)bort post, and if I select
>> (s)end it transmits my post to the news server and exits, returning
>> control of the terminal to trn.
>
>Three separate apps to do newsreading?
One app to do newsreading. One app to do news composition. One app to
do news posting.
>And what about concurrency, and
>what if something breaks this chain?
How, pray tell, is it going to break this chain? There's not much to
break in:
int pid;
int status;
int wp_ret;
pid = fork();
if (pid == 0)
{
/* Child process; code to exec the relevant program. */
}
else if (pid == -1)
{
perror("mynewsreader: Couldn't fork");
return -1;
}
else
{
/* parent process; wait for child to exit. */
wp_ret = waitpid(pid, &status, 0);
/* Do stuff based on wp_ret and status */
}
and if any of that breaks, well, something is broken, and it's probably
something more important than your newsreader.
I don't see a concurrency problem.
>What if the temporary file is
>cleaned up?
If a tempfile with a recent timestamp gets cleaned up, your sysadmin
is a reinforced moron and you should get a better one. Furthermore,
this temporary file is created in your home directory, not /tmp, so if
it breaks, it's almost certainly your fault.
>What if the user picks "Save as..." in the editor?
That... may be inadvisable. But, you don't "Save as..." accidentally in
vim, emacs, or nano. If the user intentionally does something silly,
then the computer will do something they didn't want it to; beyond a
certain point, this is impossible to prevent.
>What if
>the editor ends abnormally?
Then you swear, and file a bug against the editor. I have never seen
vim crash on functioning hardware; I don't think I've seen GNU emacs
crash on functioning hardware, either.
>There's no integration between the browser
>and the process that actually accesses the network?!
The newsreader only *reads* news, by sucking it down off the network or
reading it from the local news spool. It doesn't post it. The news
posting agent only *posts* news.
>How can you
>possibly browse groups efficiently then? An internally layered
>architecture is one thing, but this ... this Rube Goldberg apparatus
>looks precarious as hell. Too easy for a change in one app to break one
>or both of the other two, or something that happens to the interprocess
>communication.
The interprocess communication consists of command-line arguments, the
creation of a file with a fixed name (By default, "$HOME/.article"; if
someone else who isn't the sysadmin can cause this file to exist, you
have other, larger problems), and the return information passed back to
the parent process via waitpid(). If any of these break, you probably
have bigger problems than your newsreader being broken.
If your editor changes in a way that breaks trn/Pnews's operation, your
editor has changed in a way that breaks normal operation as a text
editor, so you have bigger problems than being unable to post news.
If some reinforced moron changes Pnews in such a way as to break its
interoperation with trn then, well, they're a reinforced moron and need
to have their workstation plugged into an etherkiller.
Ah, I notice I left out a step: Pnews is in fact a friendly wrapper
around inews, which does the actual news posting step.
Martin Read
>The Sheep wrote:
>> You seem to be terribly afraid of all that good old solutions.
>> Try it sometimes, it's really comfortable to use one and the same
>> application when you're doing similar things.
>
>When I'm editing news I want to see that I'm in a newsreader; when I'm
>editing code I want to see that I'm in a programmer's editor; etc.
When I flip to a window containing a text editor, I can readily
determine what I'm doing in that window just by, well, looking at the
text in the window.
If I'm editing a news post, I'll see something that looks like the body
and headers of a news post.
If I'm editing a web page, I'll see something that looks like HTML.
If I'm editing English prose, I'll see something that looks like English
prose.
If I'm writing an e-mail, I'll see something that looks like the body
and headers of an e-mail.
If I'm editing Martin's Dungeon Bash, I'll see something that looks like
C code.
If I'm editing my employer's software, I'll see something that looks
like either C code or assembler.
>How can you come back to the machine and properly orient yourself if
>there's just one big full screen generic text editing window with a
>random alphanumeric temp file's name in the title bar?
If I'm using trn/Pnews/vim, I have a terminal window displaying (most
of; Message-ID: gets generated automatically) the headers of the news
article I'm composing, and the quoted text of the article I'm replying
to if my post is a followup. When I leave the editor, I get Pnews's
confirmation prompt.
Jeff Lait
>
> How can you come back to the machine and properly orient yourself if
> there's just one big full screen generic text editing window with a
> random alphanumeric temp file's name in the title bar?
No need to keep trying. I think you successfully proved yourself an
idiot quite a few posts ago.
The answer, to what I assume is supposed to be a rhetorical question,
is to lay off the hard drugs when away from the keyboard.
In penance for rising to the bait, I shall add a Useful Trick.
While anyone who can't tell a half finished newspost apart from a half
finished piece of code is clearly engaging in some form of illicit mind
altering activity, one may come back to a terminal and be faced with
two identical pieces of code which reside in entirely different
locations.
This will occur if you have the misfortune to be working on different
copies of the same software. Why would someone do this? Well, you may
have your current development copy as well as the forked release copy.
Both copies thus have similar directory structures, filenames, and
mostly identical code.
We thus may come back to our machine with one editor reading:
c:/dev_release/src/reallylongpathhere/foobar.cpp
and another
c:/dev/src/reallylongpathhere/foobar.cpp
Things will get ugly if you start working on the wrong foobar.cpp!
The solution for this is different shell colours.
First, make seperate shortcuts for each baseline (one likely already
has this). Next, right click on the shortcut, Properties, then Colors.
Pick a different background/foreground pair for each of your
shortcuts.
Now, your Green window can be your Release build and your Black window
your development build. Any good text editor will inherit this colour
choice. Thus, when you come back to your computer after some research
at the pub, you can tell immediatley which baseline's foobar.cpp you
see in the screen.
Unix systems have shell commands to change the colour, so you can do it
as part of your baselines setup script.
Now, a plea for help. In MSVC, how do you create get the solution name
to be different from the directory name? You Only Live Once, for
example, has its solution in the "winport" subdirectory of "liveonce".
This is so the main directory isn't cluttered with Windows specific
files. Unfortunately it seems that the solution is then called
"winport", which is rather cryptic. Indeed, POWDER's build is called
"windows", which is why I didn't use a "windows" subdirectory for You
Only Live Once - I dreaded having to tell two identical "windows"
project files apart.
Twisted One
> Uh, no, you don't. If you are on a unix system you have to know
> exactly one text editor.
So? There are other applications than text editing a user'll do.
> And Unix
> users get just as angry about code that flouts UI guidelines
> and conventions as Windows or Mac users, it's just that the
> UI guidelines are not the ones Windows and Mac use.
Evidently. For one thing, "usability research" is not involved in unix
UI guidelines.
Can you at least make all apps use KWrite or something else a little bit
sane?
> There's a slick IDE for C++ apps on Linux
> named Kdevelop. Nobody uses it, mainly because it fails UI
> conformance by not letting people invoke their preferred editors.
And I thought it was because the help files didn't work out of the box.
> The "UI community" has taught us that good UI is UI which does
> what the user expects. In Unix, the user expects any software
> that requires text editing to invoke the user's preferred text
> editor.
That makes a certain amount of sense, although it seems to require app
developers jump through hoops dealing with temporary files and
interprocess synchronization and such. It's a shame it is also part of
the unix guidelines to make the UI for, e.g., text editors cryptic and
difficult to learn. Too much fumbling in the dark required for my
tastes. Maybe the intent is to require people to have a tutor or
something? Either to boost the wizards' egos, or to raise the barrier to
entry for n00bs and keep unix a more-or-less exclusive club, which
amounts to the same thing...
Twisted One
> Vim saves all changes up to (minimum) the last write. If your editor does
> something you don't want, then keep hitting u until you get back to what you
> want (even if that goes as far back as the original document).
> It is faster to simply type and check the screen intermittently than to
> type and read everything that is going on, continual verification is very
> slow and should be minimised.
But with a wonky and unfamiliar interface that is difficult to navigate,
continual verification is exactly what users end up doing, until and
unless they eventually get used to the klunky UI.
> A modern UI would be great. If it had the power of vim, then I'd be over
> the moon.
>
> Wait, that exists. It's called gvim. What are you complaining about
> again?
I am deeply suspicious. Does it follow all the normal window-UI
conventions? Or is it just vi with a box drawn around it, as is all too
often the case with so-called gui ports of unix tools? In which case you
might as well invoke the thing in a terminal window for all the added
help you'll get. You can still have a second terminal window open on the
help concurrently. :)
Twisted One
> Have you even ever seen any unixs applications, or are you judging only
> from a description of interface of a single text editor?
I have -- and always end up gnashing my teeth wondering why after most
desktop operating systems have made leaps and bounds in usability in the
last thirty years, unix on the desktop still looks like something out of
the (fumbling around in the) dark ages. Why are commands, user
interfaces, and even help navigation invariably so damned *opaque* over
there?
Twisted One
>>There's no integration between the browser
>>and the process that actually accesses the network?!
>
> The newsreader only *reads* news, by sucking it down off the network or
> reading it from the local news spool. It doesn't post it. The news
> posting agent only *posts* news.
Why separate them? Sending and receiving messages of a particular type
are tasks that logically belong together. I've never seen a Windows
system where you use one program to browse news, but switch to a
different one when you want to reply. If I did, I'd say "How awkward"
and reach for the "uninstall" option.
> The interprocess communication consists of command-line arguments, the
> creation of a file with a fixed name (By default, "$HOME/.article"; if
> someone else who isn't the sysadmin can cause this file to exist, you
> have other, larger problems), and the return information passed back to
> the parent process via waitpid(). If any of these break, you probably
> have bigger problems than your newsreader being broken.
This limits the user feedback from any nested process to a cryptic
numeric error code. No dialog box, no way for the user to tell it to try
again or whatever, nothing but cursing and fumbling for whatever passes
for documentation.
Martin Read
>Glen Wheeler wrote:
>> Wait, that exists. It's called gvim. What are you complaining about
>> again?
>
>I am deeply suspicious. Does it follow all the normal window-UI
>conventions? Or is it just vi with a box drawn around it, as is all too
>often the case with so-called gui ports of unix tools? In which case you
>might as well invoke the thing in a terminal window for all the added
>help you'll get. You can still have a second terminal window open on the
>help concurrently. :)
*opens gvim*
Well, it seems to respond to the standard windows shortcut of Ctrl-S for
save (even during an (i)nsert command), it has pull-down menus (with
tearoffs, no less!), it has a toolbar, it has some major configuration
options available in the "Edit>Global Settings" menu, it has a
configuration-editing option, it has click-and-drag selection
highlighting, the menus activate when you press Alt, ... It doesn't
respond to Ctrl-O for "open", but that's because Ctrl-O is already mapped
in vim's standard command set.
But you can still fly it like terminal-mode vim if you want.
Martin Read
>Can you at least make all apps use KWrite or something else a little bit
>sane?
You can set EDITOR to be bloody /bin/true if you bloody well want.