"Galileo" <········@macau.ctm.net> writes:
> I am using Allegro CL 5.0.1 for windows. When I get an error, how can I go
> to the top level?
Try ":cont <n>" where <n> is the restat number of the abort restart.
Why they won't adopt :c as a synonym for :cont, and why they don't have
a :a synonym for "get the abort restart and run it" like Harlequin does,
I don't understand. I sent a bug report about this and they sent me
mail saying they didn't see it as a big problem and didn't plan to fix it.
But I consider this a hugely painful feature of the Allegro UI and a
continual source of major frustration.
I yearn for the UI of the Lisp Machine where restarts were all selectable
by a single keystroke (super-A, super-B, super-C, etc.) and where Abort was
its own single key. Even on a remote keyboard over telnet to a Lisp Machine,
the number of keystrokes needed to select a restart via seven-bit ASCII is
fewer than it is in either Franz or Harlequin.
From: Christopher R. Barry
Subject: Re: how can I go to the top level?
Date:
Message-ID: <87aeqj5jda.fsf@2xtreme.net>
Kent M Pitman <······@world.std.com> writes:
> Why they won't adopt :c as a synonym for :cont, and why they don't have
> a :a synonym for "get the abort restart and run it" like Harlequin does,
> I don't understand. I sent a bug report about this and they sent me
> mail saying they didn't see it as a big problem and didn't plan to fix it.
> But I consider this a hugely painful feature of the Allegro UI and a
> continual source of major frustration.
>
> I yearn for the UI of the Lisp Machine where restarts were all selectable
> by a single keystroke (super-A, super-B, super-C, etc.) and where Abort was
> its own single key. Even on a remote keyboard over telnet to a Lisp Machine,
> the number of keystrokes needed to select a restart via seven-bit ASCII is
> fewer than it is in either Franz or Harlequin.
Once you've programmed with one, you never want to use anything
else.... I liked the Super key continuations so much that I was going
to do an Alt key version for Emacs, but that was just one of a million
things I never got around to doing. (Liking making your rubout-handler
code work with Emacs....)
So much to get done, so little time... (why I am spending my time on
USENET??? Guess it's relaxing....)
Christopher
Kent M Pitman <······@world.std.com> writes:
> Why they won't adopt :c as a synonym for :cont, and why they don't have
> a :a synonym for "get the abort restart and run it" like Harlequin does,
> I don't understand. I sent a bug report about this and they sent me
> mail saying they didn't see it as a big problem and didn't plan to fix it.
> But I consider this a hugely painful feature of the Allegro UI and a
> continual source of major frustration.
It needn't be continual ;-)
(top-level:alias "c" (&rest args)
(apply #'top-level:do-command "continue" args))
(top-level:alias "a" (&rest args)
(invoke-restart 'abort))
--
Lieven Marchand <···@bewoner.dma.be>
If there are aliens, they play Go. -- Lasker
Lieven Marchand <···@bewoner.dma.be> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > Why they won't adopt :c as a synonym for :cont, and why they don't have
> > a :a synonym for "get the abort restart and run it" like Harlequin does,
> > I don't understand. I sent a bug report about this and they sent me
> > mail saying they didn't see it as a big problem and didn't plan to fix it.
> > But I consider this a hugely painful feature of the Allegro UI and a
> > continual source of major frustration.
>
> It needn't be continual ;-)
>
> (top-level:alias "c" (&rest args)
> (apply #'top-level:do-command "continue" args))
>
> (top-level:alias "a" (&rest args)
> (invoke-restart 'abort))
Thank you, Lieven, for answering the technical side of this question.
That leaves me only to answer the attitude perception issue, which
seems to be embodied by this:
> > I sent a bug report about this and they sent me
> > mail saying they didn't see it as a big problem and didn't plan to fix it.
I was the person who answered the spr that Kent sent in. I didn't
intend to convey this atttude at all, but I understand the tendency
for email to mask intentions, so that incorrect intentions might be
assumed. Please be assured that it was not my intention in this
case to never do anything about the issue of top-level command
compatibility.
Here is what I believe is the relevant portion of the spr:
=====
>> Harlequin uses :c for its debugger, and I have to say I'm really
>> extremely used to that. I have to do it way too often to be
>> wanting to type :continue or even :cont. I think you should have
>> a :c synonym.
We took the philosophy that our toplevel would be as extensible as
possible, so we encroach on the namespace as little as possible.
The :c command might be used for other things by our users, and many
do define their own commands.
To get what you want, you can extend the toplevel yourself, by using
the tpl:alias macro:
USER(1): (tpl:alias ("con" 0) (&rest args)
(apply #'tpl:do-command "cont" args))
USER(2): x
Error: Attempt to take the value of the unbound variable `X'.
[condition type: UNBOUND-VARIABLE]
Restart actions (select using :continue):
0: Try evaluating X again.
1: Use :X instead.
2: Set the symbol-value of X and use its value.
3: Use a value without setting X.
4: Return to Top Level (an "abort" restart)
[1] USER(3): :c 1
:X
USER(4):
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane Rettig <·····@franz.com> writes:
> > > I sent a bug report about this and they sent me mail
> > > saying they didn't see it as a big problem and didn't plan to
> > > fix it.
>
> I was the person who answered the spr that Kent sent in. I didn't
> intend to convey this atttude at all, but I understand the tendency
> for email to mask intentions, so that incorrect intentions might be
> assumed.
I certainly didn't mean to give the impression that my report was not
answered in detail, etc. However, there are certain things that I
feel really should be part of the basic system and not left as an
exercise to the user. This is one that I feel very, very strongly
about. This is, to me, like debating whether the break and gas pedals
in a car should be on the right or left and saying that you put them
on backwards but that you offer a kit to swap them for people who need
that. I don't like to have a Lisp init file for various reasons; I prefer
to operate with the system often in its native mode. That's part of it.
I also don't like to have to explain certain common things repeatedly
to novices. And I want to have a common set of basic interactions
that work in as many environments as possible since I go back and forth
a lot.
I regard the :cont vs :c distinction as utterly gratuitous and the kind
of thing that just makes interfaces uselessly different and hard to write
books about, as well as painful to type in the case where the longer
name was chosen.
I'm not very sympathetic to the notion of the customizable environment
because it's so utterly easy for anyone who DOES want to customize
their environment to rearrange :c *if* they think that's a good idea,
which I do not. I have a strong theory of defaults that say that defaults
should favor the person who doesn't know how to customize the world. For
example, we existed for YEARS in Maclisp with base 8 the default and some
wizards saying it was "more natural" in spite of mounting bug reports
that (+ 5 5) was broken for returning 12. "It's so simple to change
in your init file, and base 8 is such a more natural base" they would say.
But that was nuts. The fact is that the people who would have found it
simple to fix in their init files were the people who knew about and used
init files already, and the people who didn't know what an init file was
or who wouldn't know what variable to set were the people with the problem.
The same is true here. :c and :a should be there because some set of people
will not know how to set them up, and because those people are as deserving
as any of something easy to type to continue or to abort.
And, finally, although some people do want to customize their environment,
I'm not very sympathetic to having idiosyncratic interfaces take up the
"good namespace". I think languages should give preference to "things
one does all the time" on the short keys, and much though I wish it weren't
so, I think "being in the debugger" is a common thing and deserves very
high priority. I feel people making layered interfaces SHOULD feel like
they should take back seat to this and pick longer names. And I note
that anyone who feels really strongly about this can presumably still
override the default and reclaim :c if they want, they'll just have to
feel they are bucking the trend, which I feel is appropriate.
I apologize for not just feeding this back at the time of your reply
to my bug report. I was really quite upset about the reply to the bug
report and I just didn't have it in me to send something civil. I
regarded that frustration as my problem, not yours, though, exactly
because the reply appeared to have heard my remark and simply said
"this is not our priority". That seemed to end the discussion, and
not happily for me. So I paced for a while in circles and tried to
just let it go. I felt that I had explained the issue as clearly as I
could and that you had either missed or rejected my point of view and
that there was nothing more to be done but to let you go on with a
design decision that I feel is really quite wrong. It is, after all,
not the biggest problem Lisp is facing in the coming decades and warranted
only a certain amount of attention.
In the end, it's just a matter of personal opinion, too. And who's to
say mine is better than someone else's? Certainly not me. Just because
I have reasons for most things I think doesn't mean they're "right"
reasons.
Kent M Pitman <······@world.std.com> wrote in message
····················@world.std.com...
> Duane Rettig <·····@franz.com> writes:
>
> > > > I sent a bug report about this and they sent me mail
> > > > saying they didn't see it as a big problem and didn't plan to
> > > > fix it.
> >
> > I was the person who answered the spr that Kent sent in. I didn't
> > intend to convey this atttude at all, but I understand the tendency
> > for email to mask intentions, so that incorrect intentions might be
> > assumed.
> I have a strong theory of defaults that say that defaults
> should favor the person who doesn't know how to customize the world. For
> example, we existed for YEARS in Maclisp with base 8 the default and some
> wizards saying it was "more natural" in spite of mounting bug reports
> that (+ 5 5) was broken for returning 12. "It's so simple to change
> in your init file, and base 8 is such a more natural base" they would say.
> But that was nuts. The fact is that the people who would have found it
> simple to fix in their init files were the people who knew about and used
> init files already, and the people who didn't know what an init file was
> or who wouldn't know what variable to set were the people with the
problem.
> The same is true here. :c and :a should be there because some set of
people
> will not know how to set them up, and because those people are as
deserving
> as any of something easy to type to continue or to abort.
Hear, hear! Excellently said and i totally agree. The computer world needs
much more thinking along these lines. Too often we allow an "if they are
too stupid to know better, why should we care about them?" attitude to
criple otherwise elegant implementation designs. This goes all the way from
language designs to GUI's.
(please don't that as a personal put down, Duane, it is a broad
generalization and not meant as a characterization of your own motives at
all :)
I would hope that Franz hears the above article and is big enough to
reconsider.
cb
From: Christopher R. Barry
Subject: Re: how can I go to the top level?
Date:
Message-ID: <8790603tbo.fsf@2xtreme.net>
Kent M Pitman <······@world.std.com> writes:
> However, there are certain things that I feel really should be part
> of the basic system and not left as an exercise to the user. This is
> one that I feel very, very strongly about. This is, to me, like
> debating whether the break and gas pedals in a car should be on the
> right or left and saying that you put them on backwards but that you
> offer a kit to swap them for people who need that. I don't like to
> have a Lisp init file for various reasons; I prefer to operate with
> the system often in its native mode. That's part of it. I also don't
> like to have to explain certain common things repeatedly to novices.
> And I want to have a common set of basic interactions that work in
> as many environments as possible since I go back and forth a lot.
>
> I regard the :cont vs :c distinction as utterly gratuitous and the kind
> of thing that just makes interfaces uselessly different and hard to write
> books about, as well as painful to type in the case where the longer
> name was chosen.
>
> I'm not very sympathetic to the notion of the customizable environment
> because it's so utterly easy for anyone who DOES want to customize
> their environment to rearrange :c *if* they think that's a good idea,
> which I do not.
[...]
I'm in partial agreement with you here. I do believe that operations
that are going to be common for nearly all users should be as
efficient and natural as possible for the user to input. I agree that
selecting an arbitrary restart with Allegro Common Lisp involves way
too much typing. You have to:
Reach for shift modifier first to type ":".
Type 5 characters ["cont "].
Type the restart number.
Hit return.
Allegro Common Lisp is the only Lisp system I know of that by default
needs so much typing to select a restart. [A restart other than abort
anyways (which you only need to send the system EOF in a Unix terminal
or Emacs to do).]
I do not agree that it is a bug that Allegro CL does not accept ":c"
as an alias for ":continue", however. I just think it is a bug that a
common operation requires so much typing. CMU Common Lisp has even a
more efficient debugger UI-wise than Harlequin's:
To select a restart, you just type it's number + return. [2 keystrokes.]
To abort up one debug level, you just type "a" + return. [2 keystrokes.]
To completely quit and go to top-level, you just type "q" + return. [2 key..]
And of course, the Lisp Machine could not be any more efficient:
Has special "Abort" and "Resume" keys on the keyboard. [These
debugger operations are one keystroke.]
Labels restarts A, B, C, D, E, etc. To select one, hold the Super
modifier key and press the corresponding letter. [One modified keystroke.]
Anyways, I think init-files and user customizations are very important
because it is impossible to make a UI that is 100% perfect for
everyone. (I'd love to be proved wrong ;-) Emacs, in particular, is
almost unusable in my opinion without a pretty large .emacs file. One
of the things I like about the vi editor is how you can do many common
things with fewer keystrokes than with Emacs. And much faster, easier
keystrokes too. (Many keys are based on their physical keyboard
location rather than what they are a mnemonic of an operation for.)
And you can just sit down at some random machine with vi installed and
productively use it uncustomized. (Unless the Escape key is in the far
upper-left of the keyboard!!!) But I'm not using the vi editor to
compose this very reply nor for any of my programming, because it
lacks critical features and extensibility I need that Emacs provides.
Anyways, I think that debugger operations (particularly restarts) are
so common that every vendor should try to make them as fast as they
possibly can. For example:
Label them A-Z and allow you to select one with the Alt key +
letter. [This would be analogous to what a Symbolics does with the
Super key.]
Provide special keystrokes for operations you can always select in
the majority of cases, namely continue and abort/quit. These could
be mapped to F6/F7, Alt-A/Alt-C/Alt-Q, or whatever.
Christopher
In article <··············@2xtreme.net>,
Christopher R. Barry <······@2xtreme.net> wrote:
....
>
>Anyways, I think init-files and user customizations are very important
>because it is impossible to make a UI that is 100% perfect for
>everyone. (I'd love to be proved wrong ;-) Emacs, in particular, is
I, for one, would much benefit from seeing a good, or even fairly good,
..emacs file.
Would give me LOTS of ideas for mine.
Please, either post here, or email it to me.
Thanks!
(Likewise for anyone else who has one, especially if not too
difficult to read.)
David Combs
* David Combs wrote:
> I, for one, would much benefit from seeing a good, or even fairly good,
> ..emacs file.
I think that you'd be better off asking in one of the emacs
newsgroups.
Back (slightly) on topic, I think it's significant that I have
thousands of lines of emacs init code, but I only ever had about 20 of
zmacs init stuff, and for a long time I had none at all.
--tim
On Tue, 21 Sep 1999 03:44:23 GMT, Kent M Pitman <······@world.std.com>
wrote:
> to novices. And I want to have a common set of basic interactions
> that work in as many environments as possible since I go back and forth
> a lot.
ILD by Jeffrey Mark Siskind, the uniform interface to Lisp debuggers
included with ILISP 5.9 and later, is a first shot at it.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Kent M Pitman <······@world.std.com> writes:
> Duane Rettig <·····@franz.com> writes:
>
> > > > I sent a bug report about this and they sent me mail
> > > > saying they didn't see it as a big problem and didn't plan to
> > > > fix it.
> >
> > I was the person who answered the spr that Kent sent in. I didn't
> > intend to convey this atttude at all, but I understand the tendency
> > for email to mask intentions, so that incorrect intentions might be
> > assumed.
>
> I certainly didn't mean to give the impression that my report was not
> answered in detail, etc. However, there are certain things that I
> feel really should be part of the basic system and not left as an
> exercise to the user. This is one that I feel very, very strongly
> about. This is, to me, like debating whether the break and gas pedals
> in a car should be on the right or left and saying that you put them
> on backwards but that you offer a kit to swap them for people who need
> that.
The automobile provides good analogies, but I don't think that the
position of the gas pedals is an issue, because as far as I know,
everyone does it the same way (it is de-facto standard). However,
there are two major things about automobile manufacture and use that
are anlogous here: the position of the steering wheel, and the side
of the road which is driven on. There are cars that have their
steering wheel on the left side, and cars that have the wheel on the
right side. In the US, most cars have them on the left; this is a
preference issue with a reason; you want your largest forward blind
spot not to be on the side of the car coming toward you. In England,
they tend to be on the right side, for the same reason. However,
this is just preference; I've seen right-wheeled British cars
being driven in the US without much trouble. Another exception is
the US Mail truck; its preference is to have the steering wheel on the
right, so that it can reach the mailboxes on the side of the road without
walking through traffic. And those people who buy such vehicles at
Post Office auctions must either live with what they bought, or indeed
buy a kit and do a conversion.
However, which side of the raod is driven on is much more than a preference
issue; if you try driving on the right side of the road in England, or
on the left side of the road in the US, you will have problems...
> I don't like to have a Lisp init file for various reasons; I prefer
> to operate with the system often in its native mode. That's part of it.
This would have been valuable information to have had in the spr. It
would have explained to me where you were coming from. (we're really
good at support, but we're not mind-readers :-)
> I also don't like to have to explain certain common things repeatedly
> to novices. And I want to have a common set of basic interactions
> that work in as many environments as possible since I go back and forth
> a lot.
But the only way to do this _and_ to disallow any prior action (like
reading an init file, pre-dumping a lisp, or selecting some sort of
build mode) is to make it a standard part of the language. And as far
as I know, it's not.
BTW, I had mentioned in the spr (half jokingly) that you might be willing
to come up with a Symbolics-toplevel compatibility package. I thought
that it was a reasonable thing to do, and that you might have been
interested in creating a preliminary command set for us. What I didn't know
was that the reason you didn't respond was because you don't believe in
init files. So when it became obvious that you weren't going to respond,
we generated an rfe (request for enhancement) to consider doing this.
Unfortunately, if and when we do the rfe, it wouldn't make you happy, since
it would need to be either required or loaded via an init file. But perhaps
others would be interested in such a module.
> I regard the :cont vs :c distinction as utterly gratuitous and the kind
> of thing that just makes interfaces uselessly different and hard to write
> books about, as well as painful to type in the case where the longer
> name was chosen.
But if there's gratuity, which direction is it? Obviously, Symbolics
lisp came before Allegro CL, but Allegro CL didn't come _from_ Symbolics
lisp at all; it's history is in FranzLisp (whose history was indirectly
from Maclisp, through Macsyma). We did change the toplevel from
FranzLisp, but not much, and certainly not gratuitously: the :reset
command carries over, as do others. The :continue command (note that
it is actually 9 letters, abbreviatable to 5) came from FranzLisp's
retbrk command, which needed a new name due to the added flexibility
due to the addition of restarts.
> I'm not very sympathetic to the notion of the customizable environment
> because it's so utterly easy for anyone who DOES want to customize
> their environment to rearrange :c *if* they think that's a good idea,
> which I do not.
I can understand and sympathize with this point.
> I have a strong theory of defaults that say that defaults
> should favor the person who doesn't know how to customize the world.
This is _precisely_ why we chose the defaults the way we did; a novice
needs mnemonic names, which tend to be longer. It is the expert who
can use shorter abbreviations, or, better yet, create their own.
> For
> example, we existed for YEARS in Maclisp with base 8 the default and some
> wizards saying it was "more natural" in spite of mounting bug reports
> that (+ 5 5) was broken for returning 12. "It's so simple to change
> in your init file, and base 8 is such a more natural base" they would say.
> But that was nuts. The fact is that the people who would have found it
> simple to fix in their init files were the people who knew about and used
> init files already, and the people who didn't know what an init file was
> or who wouldn't know what variable to set were the people with the problem.
This was obviusly a case of bad defaulting.
> The same is true here. :c and :a should be there because some set of people
> will not know how to set them up, and because those people are as deserving
> as any of something easy to type to continue or to abort.
> And, finally, although some people do want to customize their environment,
> I'm not very sympathetic to having idiosyncratic interfaces take up the
> "good namespace". I think languages should give preference to "things
> one does all the time" on the short keys, and much though I wish it weren't
> so, I think "being in the debugger" is a common thing and deserves very
> high priority. I feel people making layered interfaces SHOULD feel like
> they should take back seat to this and pick longer names. And I note
> that anyone who feels really strongly about this can presumably still
> override the default and reclaim :c if they want, they'll just have to
> feel they are bucking the trend, which I feel is appropriate.
I know some people who, given the :cf (compile-file) command, establish an
alias of :c to do a compile of a funciton name. Do you intend that we would
say to those people "you can't do that anymore" or "you're bucking the
trend"? If so, that would certainly not be the style for which the
CL community is famous. If, however, there were a standardization effort
on top-levels, this kind of issue would have to be discussed, resolved,
and bought into by those affected (if they want to track the standard).
CL is, after all, an extensible programming language, where everything
not part of the standard is programmable, even the debugger. I can
understand and agree with some of your arguments above, but I am
wondering: aren't you simply making a case that the top-level should
be standardized?
> I apologize for not just feeding this back at the time of your reply
> to my bug report. I was really quite upset about the reply to the bug
> report and I just didn't have it in me to send something civil. I
Even something uncivil would have gotten the point across. We have
fairly tough hides (a must-have for lisp vendors :-)
> regarded that frustration as my problem, not yours, though, exactly
> because the reply appeared to have heard my remark and simply said
> "this is not our priority". That seemed to end the discussion, and
> not happily for me. So I paced for a while in circles and tried to
> just let it go. I felt that I had explained the issue as clearly as I
> could and that you had either missed or rejected my point of view and
> that there was nothing more to be done but to let you go on with a
> design decision that I feel is really quite wrong. It is, after all,
> not the biggest problem Lisp is facing in the coming decades and warranted
> only a certain amount of attention.
Apparently there were things that didn't come across; I am sorry I
missed the signs. The technical issues may or may not be important,
but <cliche> customer satisfaction always is important </cliche>. If
you left the spr unsatisfied, then we didn't finish the job at our end.
On the other hand, we are not mind readers, so you must tell us when
this happens.
> In the end, it's just a matter of personal opinion, too. And who's to
> say mine is better than someone else's? Certainly not me. Just because
> I have reasons for most things I think doesn't mean they're "right"
> reasons.
I agree. But compromises and understanding can still exist in the absence
of total agreement.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane Rettig <·····@franz.com> writes:
> The automobile provides good analogies, but I don't think that the
> position of the gas pedals is an issue,
I do. I type :a and :c at a sub-conscious level. I see an error and my
fingers respond to it. I do not say "what shall I type?" I just type it.
I'm used to a particular interface which is easy to type. I have tried but
cannot become used to the Franz interface both because it is different and
because it is enough characters that it is hard to build into an automatic
response system. It doesn't seem to correctly default the argument either.
Harlequin makes :c with no argument do mostly the right thing, I think,
though I have a vague recollection it screws up the thing that the LispM
gets right where you really want :c to fail if there is an intervening abort
before the first possible continue restart. (I'm also not big on assigning
:c with no argument to any old non-abort restart--I think it should be only
the innermost CONTINUE restart not `shadowed' by an ABORT.) But my real
point is that this is motor level, and that's why I picked the car example.
That is also motor level. And the last thing I need is to be getting error
messages while I'm dealing with error messages.
> However, which side of the raod is driven on is much more than a preference
> issue; if you try driving on the right side of the road in England, or
> on the left side of the road in the US, you will have problems...
You can make this claim, but the fact is that I try very hard never to visit
England over this single preference issue. It is otherwise a nice country
but this one fact of it makes it worth not visiting to me.
> > I don't like to have a Lisp init file for various reasons; I prefer
> > to operate with the system often in its native mode. That's part of it.
>
> This would have been valuable information to have had in the spr. It
> would have explained to me where you were coming from. (we're really
> good at support, but we're not mind-readers :-)
I agree. But it didn't occur to me to say because I would have reported it
if I *did* have an init file, and at the time it seemed to me obvious that
I was not loading an init file and was therefore getting the default behavior.
> > I also don't like to have to explain certain common things repeatedly
> > to novices. And I want to have a common set of basic interactions
> > that work in as many environments as possible since I go back and forth
> > a lot.
>
> But the only way to do this _and_ to disallow any prior action (like
> reading an init file, pre-dumping a lisp, or selecting some sort of
> build mode) is to make it a standard part of the language. And as far
> as I know, it's not.
Right. Consider my efforts on this issue to be toward getting vendors to
agree, which I consider to be a first step toward either standardization or
at least normalization of things that don't need to gratuitously vary,
whether or not standardized. I do not believe standards should lead
practice, as a rule. I think standards should observe common practice and
codify it. But in this case I see no reason for common practice not to agree.
> But if there's gratuity, which direction is it?
The shorter the better is my criterion. I consider that objective.
The choice of it as an objective criterion might be subjective. Such is life.
> > I have a strong theory of defaults that say that defaults
> > should favor the person who doesn't know how to customize the world.
>
> This is _precisely_ why we chose the defaults the way we did; a novice
> needs mnemonic names, which tend to be longer. It is the expert who
> can use shorter abbreviations, or, better yet, create their own.
And only the expert will be efficient. That's sad.
I also don't find "cont" any more mnemonic than "contin", by the way,
and fear it is english-speaker-centric. Speakers of other languages
might not find this mnemonic at all. Which argues in my mind
for not caring about mnemonics and focusing on ease of use.
> I know some people who, given the :cf (compile-file) command,
> establish an alias of :c to do a compile of a funciton name. Do you
> intend that we would say to those people "you can't do that anymore"
> or "you're bucking the trend"?
If they establish their own aliases, it would presumably override the system.
And those people have both the knowledge to in two seconds add a synonym
for the old longer name for :cont, plus they have a file that already has
redefinitions and could easily hold one more. They are not as much at risk
as others.
> If, however, there were a standardization effort
> on top-levels, this kind of issue would have to be discussed, resolved,
> and bought into by those affected (if they want to track the standard).
I am arguing as part of public dialog that the situation is now broken, and
as an independent party not of any vendor that I think the Harlequin way is
the best for a line-at-a-time interface. If I had my way, interfaces would
not be line-at-a-time and it would be a single keystroke. But I understand
the community is scared by character-at-a-time I/O, and I've modified my
personal preference accordingly when making this public request.
> > I apologize for not just feeding this back at the time of your reply
> > to my bug report. I was really quite upset about the reply to the bug
> > report and I just didn't have it in me to send something civil. I
>
> Even something uncivil would have gotten the point across. We have
> fairly tough hides (a must-have for lisp vendors :-)
Well,...
* Duane Rettig wrote:
> The automobile provides good analogies, but I don't think that the
> position of the gas pedals is an issue, because as far as I know,
> everyone does it the same way (it is de-facto standard).
Only people who insist on driving new cars. I've quite often driven a
car with the accelerator (`gas') & brake pedals swapped from the more
usual position. The interesting thing is that it's very easy to
swap -- you make *one* mistake (almost always within a few seconds of
first driving it) and then it's instinctive.
--tim
(OK, it's a nearly-70-year-old car, I admit)
Tim Bradshaw wrote:
> (OK, it's a nearly-70-year-old car, I admit)
Tim, you are the only bloke I know who does stuff this this.
RESPECT!
:) will
From: Howard R. Stearns
Subject: noise (Re: how can I go to the top level?)
Date:
Message-ID: <37EBBA7D.98059EE6@elwood.com>
William Deakin wrote:
>
> Tim Bradshaw wrote:
>
> > (OK, it's a nearly-70-year-old car, I admit)
>
> Tim, you are the only bloke I know who does stuff this this.
>
> RESPECT!
>
> :) will
I suspect that a nontrivial number of Lispers have quirky habits and
hobbies such as an interest in old British cars.
I also suspect a significant number are musicians, too, but I have no
evidence about either. I further wonder how this combines -- for
example, how many play music through tube (valve) amplifiers. There
seemed to be quite a few at LUGM98.
* Howard R Stearns wrote:
> I also suspect a significant number are musicians, too, but I have no
> evidence about either. I further wonder how this combines -- for
> example, how many play music through tube (valve) amplifiers. There
> seemed to be quite a few at LUGM98.
Damn, another direct hit.
--tim
Howard R. Stearns <······@elwood.com> wrote in message
······················@elwood.com...
> I also suspect a significant number are musicians, too, but I have no
> evidence about either. I further wonder how this combines -- for
> example, how many play music through tube (valve) amplifiers. There
> seemed to be quite a few at LUGM98.
Why not use tubes? They sound better.
From: William Deakin
Subject: Re: noise (Re: how can I go to the top level?)
Date:
Message-ID: <37F08E11.B3971209@pindar.com>
I play (played) the bassoon and also fiddle (no pun itended) about a bit
on the GeeTar.
Cheers,
:) will
From: Christopher R. Barry
Subject: Re: how can I go to the top level?
Date:
Message-ID: <87d7vf5jqg.fsf@2xtreme.net>
"Galileo" <········@macau.ctm.net> writes:
> I am using Allegro CL 5.0.1 for windows. When I get an error, how can I go
> to the top level?
Kent already told you how to select restarts, but if you just want to
get out of the debugger and not worry about the restarts then all you
have to do is simply send EOF which is done by:
* Typing (I think) Control-z if you are working from a DOS prompt
(it's Control-d if you are in a terminal on Unix.)
* Typing Control-c Control-d if you are in Emacs. (Unless they
replaced Control-d with Control-z for the Windows port.)
Christopher
······@2xtreme.net (Christopher R. Barry) writes:
>
> "Galileo" <········@macau.ctm.net> writes:
>
> > I am using Allegro CL 5.0.1 for windows. When I get an error, how can I go
> > to the top level?
>
> Kent already told you how to select restarts, but if you just want to
> get out of the debugger and not worry about the restarts then all you
> have to do is simply send EOF which is done by:
>
> * Typing (I think) Control-z if you are working from a DOS prompt
> (it's Control-d if you are in a terminal on Unix.)
>
> * Typing Control-c Control-d if you are in Emacs. (Unless they
> replaced Control-d with Control-z for the Windows port.)
I mostly use the Allegro 5.0's IDE, by the way, and I think neither of
these is available in it. It's not DOS and it isn't well-integrated
with Emacs. I like the interface a lot in many ways, but it's not
in my opinion "keyboard friendly". (Maybe there's a menu command but that
means reaching for the mouse and automatically slows me down a lot,
given how much faster I type than reach. Can't test it, though, to see
if tha'ts there because I'm getting a segmentation violation when I
start Allegro. Not sure what that's about--maybe an expired license
or maybe it's the recent hurricane-related storms having done
something to my disk. But I don't have time to test that just now, so
I'll leave it for someone else to suggest what's "fast" to use in the IDE,
if anything.)
What I really want in Allegro and maybe they'll do in some later release is
a way to get the IDE's power but to tell it to use Emacs as the editor
substrate instead of all those little typescript windows. (Maybe the problem
is that Emacs doesn't offer any ActiveX way to be an arbitrary little editing
area. What I want is what the Lisp Machine called "Zwei", the generic
editing substrate upon which "Zmacs" (the file editor) was built on.)
From: Christopher R. Barry
Subject: Re: how can I go to the top level?
Date:
Message-ID: <87so4a46sf.fsf@2xtreme.net>
Kent M Pitman <······@world.std.com> writes:
> What I really want in Allegro and maybe they'll do in some later release is
> a way to get the IDE's power but to tell it to use Emacs as the editor
> substrate instead of all those little typescript windows. (Maybe the problem
> is that Emacs doesn't offer any ActiveX way to be an arbitrary little editing
> area. What I want is what the Lisp Machine called "Zwei", the generic
> editing substrate upon which "Zmacs" (the file editor) was built on.)
XEmacs can be used as an Xt widget, and can be embedded within another
application. But unfortunately that would mean you would have to run
your app on an X server....
Christopher
"Galileo" <········@macau.ctm.net> writes:
> I am using Allegro CL 5.0.1 for windows. When I get an error, how can I go
> to the top level?
:reset
dave