clarification of our position
Kevin Layer
release manager. The support organization also reports to me.
Contrary to what I've read here, Franz Inc. does not disregard the
standard. In fact, when we find bugs in our conformance we work hard
to fix these bugs. Also, we are very careful when adding new
features--for example or new stream implementation--that we don't
break our conformance.
There are two reasons the mistaken notion that we don't care about the
standard emerged:
1. A bug in readtable-case. We fixed this bug after it was pointed
out. All the while the flame fest raged on c.l.l, I was discussing
with people how to fix it. It was not a trivial fix,
unfortunately. Also, it was discovered too late in the release
cycle of 6.0 to fix it in that release, but a patch was made, after
much development and testing, for 6.0. This was not a statement
that we don't like the standard; it was just a bug. Franz
Inc. remains committed to upholding the CL standard and to always
providing a version of our product which purports to conform to
the standard.
2. The fact that we released our 6.0 Trial Lisp in case sensitive mode
(we call this "Modern" mode, which also caused some friction).
Actually, we only released it this way on Linux. On Windows we
released in ANSI mode. This decision (which I later realized was a
mistake) was mine and mine alone. For what it's worth, we had
always wanted to introduce more people to this mode, and because
building a image in the other mode was easy, I didn't really think
about the consequences. ACL 6.1's Trial will be all ANSI all the
way.
I know of no other way we could have given the wrong impression. The
first was a bug, pure and simple. The second was my fault. So, if
fault has to be found, it should be found with me.
The obvious passion that people feel for CL is understood and
appreciated. We at Franz are passionate about the language as well,
and about the integrity of our products. We will continue to uphold
the CL standard.
I will be happy to provide more details if questions remain.
Eric Moss
>
> [...] ACL 6.1's Trial will be all ANSI [mode] all the way.
>
Bummer, though understandable. I prefer modern mode, and despite the
inconvenience of mentally translating from old texts when trying example
code, it would be nice (IMO) to head toward Franz' example.
For example, my friend is "Bill", while I pay a "bill", and it seems as
though ANSI mode discards information by folding the case. I'd rather
use ANSI mode than Java, but still... :)
Eric
PS. I would trade away if* to get back modern mode as a default. (hee
hee)
Barry Margolin
Eric Moss <eric...@alltel.net> wrote:
>Kevin Layer wrote:
>>
>> [...] ACL 6.1's Trial will be all ANSI [mode] all the way.
>>
>
>Bummer, though understandable. I prefer modern mode, and despite the
>inconvenience of mentally translating from old texts when trying example
>code, it would be nice (IMO) to head toward Franz' example.
>
>For example, my friend is "Bill", while I pay a "bill", and it seems as
>though ANSI mode discards information by folding the case. I'd rather
>use ANSI mode than Java, but still... :)
You can do whatever you want. They're just changing the default setting to
match the Common Lisp spec.
--
Barry Margolin, bar...@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Kevin Layer
> Kevin Layer wrote:
> >
> > [...] ACL 6.1's Trial will be all ANSI [mode] all the way.
> >
>
> Bummer, though understandable. I prefer modern mode, and despite the
> inconvenience of mentally translating from old texts when trying example
> code, it would be nice (IMO) to head toward Franz' example.
Just the default is changing. There will be a `readme' file that
tells how to build the other type of image.
Kent M Pitman
> Kevin Layer wrote:
> >
> > [...] ACL 6.1's Trial will be all ANSI [mode] all the way.
> >
>
> Bummer, though understandable. I prefer modern mode, and despite the
> inconvenience of mentally translating from old texts when trying example
> code, it would be nice (IMO) to head toward Franz' example.
Nothing keeps you from privately deviating from a standard, but the value
of a standard is that it gives someone who knows very little about the
system a reasonable set of expectations. It is *far* more likely that
the uninitiated party will have read somewhere about a standard way of
doing things than about a proprietary way of doing things. If they have
a book in hand about Lisp, it's most likely to be a Common Lisp book, since
Franz doesn't publish a lot of books on "The Franz Way". People are easily
put off if the book they've just spent money on doesn't appear to be
predictive of what really happens.
> For example, my friend is "Bill", while I pay a "bill", and it seems as
> though ANSI mode discards information by folding the case. I'd rather
> use ANSI mode than Java, but still... :)
I'm going to respond to this under separate cover because I imagine a
firestorm of discussion will follow and such discussion ought not detract
from the very welcome message Kevin has posted under this thread.
> PS. I would trade away if* to get back modern mode as a default. (hee
> hee)
Cleverly worded. Beyond that--well, I'll save my comments for other threads.
Kent M Pitman
> Eric Moss <eric...@alltel.net> writes:
>
> > For example, my friend is "Bill", while I pay a "bill", and it seems as
> > though ANSI mode discards information by folding the case. I'd rather
> > use ANSI mode than Java, but still... :)
>
> I'm going to respond to this under separate cover because I imagine a
> firestorm of discussion will follow and such discussion ought not detract
> from the very welcome message Kevin has posted under this thread.
Actually, I decided not to reply publicly on this. I think I have a
solution that might work compatibly with CL but I want to check a few
things first since this is a very tricky area.
Barry Margolin
>though ANSI mode discards information by folding the case. I'd rather
>use ANSI mode than Java, but still... :)
Yet if you were to start an email to him with "hi bill", I doubt he'll
think you're referring to the kind of bill that you pay (unless you owe him
money). Case is something we use to make things easier to read, and can
occasionally disambiguate, but it's not normally considered essential to
understanding. A "NO SMOKING" sign would mean the same thing if it said
"no smoking". Something in written language that doesn't correspond to
anything in spoken language could hardly be that important, since writing
is mostly just a transcription of spoken language.
Evenspacesbetweenwordsarenotcritical.
Kaz Kylheku
>Kevin Layer wrote:
>>
>> [...] ACL 6.1's Trial will be all ANSI [mode] all the way.
>>
>
>Bummer, though understandable. I prefer modern mode, and despite the
>inconvenience of mentally translating from old texts when trying example
>code, it would be nice (IMO) to head toward Franz' example.
>
>For example, my friend is "Bill", while I pay a "bill", and it seems as
There is no phonetic difference between these two, only an orthographic
difference. In the actual English language, that is the spoken thing,
these are the same symbol, whose meanings are distinguished purely by
context.
Kaz Kylheku
>>
>> [...] ACL 6.1's Trial will be all ANSI [mode] all the way.
>>
>
>Bummer, though understandable. I prefer modern mode, and despite the
>inconvenience of mentally translating from old texts when trying example
>code, it would be nice (IMO) to head toward Franz' example.
>
>For example, my friend is "Bill", while I pay a "bill", and it seems as
There is no phonetic difference between these two, only an orthographic
difference. In the actual English language---that is, the spoken
thing---these are the same symbol, whose meanings are distinguished
purely by context.
Hartmann Schaffer
Barry Margolin <bar...@genuity.net> writes:
> In article <3B8D684F...@alltel.net>,
> Eric Moss <eric...@alltel.net> wrote:
>>For example, my friend is "Bill", while I pay a "bill", and it seems as
>>though ANSI mode discards information by folding the case. I'd rather
>>use ANSI mode than Java, but still... :)
>
> Yet if you were to start an email to him with "hi bill", I doubt he'll
> think you're referring to the kind of bill that you pay (unless you owe him
> money). Case is something we use to make things easier to read, and can
> occasionally disambiguate, but it's not normally considered essential to
> understanding. A "NO SMOKING" sign would mean the same thing if it said
> "no smoking". Something in written language that doesn't correspond to
> anything in spoken language could hardly be that important, since writing
> is mostly just a transcription of spoken language.
not necessarily true. e.g. in mathematics it is quite common to
distinguish different symbols by using a different font for the same
letter.
hs
--
Lbh unir whfg ivbyngrq gur Qvtvgny Zvyraavhz Pbclevtug Npg ol oernxvat
gur cebgrpgvba bs pbclevtugrq zngrevny. Vs lbh ner abg n pvgvmra be
erfvqrag bs gur HFN, lbh evfx orvat vzcevfbarq naq uryq jvgubhg onvy
sbe hc gb gjb jrrxf hcba ragel gb gur HFN
(c) Copyright 2001 by Hartmann Schaffer (signature only)
Jochen Schmidt
> In article <G8gj7.44$4j1.840@burlma1-snr2>,
> Barry Margolin <bar...@genuity.net> writes:
>> In article <3B8D684F...@alltel.net>,
>> Eric Moss <eric...@alltel.net> wrote:
>>>For example, my friend is "Bill", while I pay a "bill", and it seems as
>>>though ANSI mode discards information by folding the case. I'd rather
>>>use ANSI mode than Java, but still... :)
>>
>> Yet if you were to start an email to him with "hi bill", I doubt he'll
>> think you're referring to the kind of bill that you pay (unless you owe
>> him
>> money). Case is something we use to make things easier to read, and can
>> occasionally disambiguate, but it's not normally considered essential to
>> understanding. A "NO SMOKING" sign would mean the same thing if it said
>> "no smoking". Something in written language that doesn't correspond to
>> anything in spoken language could hardly be that important, since writing
>> is mostly just a transcription of spoken language.
>
> not necessarily true. e.g. in mathematics it is quite common to
> distinguish different symbols by using a different font for the same
> letter.
I fear listeners will not hear what font was chosen if the symbol is
spelled out...
ciao,
Jochen
Tim Bradshaw
> not necessarily true. e.g. in mathematics it is quite common to
> distinguish different symbols by using a different font for the same
> letter.
>
This is a good point, or at least an interesting one. As an ex
maths/physics person I'm very aware of how much distinctions of case,
typeface and things like underlining matter there. *However* there's
an interesting flip-side to this, which I've never really understood:
people almost always stick to single-character identifiers and use a
huge repertoire of characters, many marked in various ways by typeface
&c (from at least three alphabets - greek, latin, and hebrew (aleph,
at least)). I'm never really sure why it's done - there's the
notational convenience that ab means multiply a by b (or whatever
other operation is useful in context), and it makes large equations
shorter (a big deal). You could argue that these conventions aren't
really relevant to programming languages so you don't need to be so
stressed about all the ways of marking a character.
--tim
Dorai Sitaram
That's right. And that's why I am surprised at
Margolin's claim that if a written something doesn't
correspond to a spoken something, then it couldn't be
that important. There is a lot of communication that
is predominantly in written mode, and has evolved
around the understanding that it will be in written
mode.
--d
Dorai Sitaram
Mathematical notation also appeals to R-mode visual
recognition in a way that a strictly linear notation as
in programming languages cannot -- and in the case of
Lisp, does not really aspire to, because of the other
benefits of a parsimonious syntax. Math notation has
strong elements of drawing to it, instead of simply
being speech recorded on paper.
--d
Tim Bradshaw
> Mathematical notation also appeals to R-mode visual
> recognition in a way that a strictly linear notation as
> in programming languages cannot -- and in the case of
> Lisp, does not really aspire to, because of the other
> benefits of a parsimonious syntax.
>
R-mode (right-brain)?.
> Math notation has
> strong elements of drawing to it, instead of simply
> being speech recorded on paper.
Yes.
One thing that fascinated me, and still does, was that TeX manages to
achieve a linear notation for maths which it is actually possible to
type fluently. When I was younger and poorer I spent some time typing
in mathematical monographs for a publisher from handwritten copy, and
it was really interesting that after a while you could just look at a
- quite hairy - bit of maths and type it in almost as fast as you
could type, and most of the time get it right - sometimes you'd have
to fiddle with some positioning details but generally it would be
OK. There are a lot of things wrong with TeX, but I think it really
shows that it was written by someone who had hundreds of pages of
maths to type in, and who could also type reasonably quickly. So TeX
manages to have this horrible, inconsistent, non-logical, linear
notation for maths which actually works really well in practice.
I always think these palette-based maths typing systems that things
like Word have are a complete joke by comparison: occasionally people
try to show me how fancy they are and it's just hard not to laugh.
They must be an order of magnitude slower (and the output looks worse
too).
Hmm, this is offtopic, sorry.
--tim
Sam Steingold
> * On the subject of "Re: clarification of our position"
> * Sent on 29 Aug 2001 21:44:43 -0400
> * Honorable h...@heaven.nirvananet (Hartmann Schaffer) writes:
>
> In article <G8gj7.44$4j1.840@burlma1-snr2>,
> Barry Margolin <bar...@genuity.net> writes:
> > Something in written language that doesn't correspond to
> > anything in spoken language could hardly be that important, since writing
> > is mostly just a transcription of spoken language.
>
> not necessarily true. e.g. in mathematics it is quite common to
> distinguish different symbols by using a different font for the same
> letter.
Let me clarify my understanding of Barry's words.
Both written and spoken language are just a reflection of "mentalese"
(see Pinker's "the language instinct"), i.e., the "language of ideas".
When a mathematician writes a {\Bbb R} ("blackboard bold") for the set
of reals, he does not read it as "blackboard bold R" but as "the field
of reals" or "the real continuum" or something else depending on the
context. This {\Bbb R} is an abbreviation to the phrase "the field of
reals" and reflects the idea of the real numbers, and its fontification
does correspond to something in the spoken language and in the language
of the ideas.
both CAR and car in
(cons (car '(1 2)) (CAR '(3 4)))
are quite unambiguous, so making them mean different things is
confusing.
LISP has a sufficient tradition to use lower case for code and upper
case for data, like
(car '(CAR FOO))
and using code as data and vice versa, so this reader case conversion is
a feature, not a bug.
as such, this feature should be understood and used productively,
and not discarded (together with gobs of code which rely on it).
Graham's paper has many valuable insights.
Yes, it might turn off some newbie for no good reason (it should have been
"a lisp community internal document", not a widely distributed text :-)
This is unfortunate, but the damage has already been done - live with it!
IMO, we should concentrate on getting the positive ideas out of it.
--
Sam Steingold (http://www.podval.org/~sds)
Support Israel's right to defend herself! <http://www.i-charity.com/go/israel>
Read what the Arab leaders say to their people on <http://www.memri.org/>
When we break the law, they fine us, when we comply, they tax us.
Eric Moss
Hi everyone,
Thanks for pointing out that I can change a default setting. I
understand the value of standards, as well. I was just adding my vote to
the modern-mode pile, hoping it would start some discussion. Who knows,
maybe others on this list felt the same but were afraid to be the first
to say. ;)
Eric
Barry Margolin
I suspect terseness is one of the main reasons for this type of
mathematical notation. If you have complex formulas, you need a compact
notation so that they'll fit on a blackboard, piece of paper, etc. And
when mathematicians or physicists are working together, they spend much of
their time writing out equations, and any time wasted writing extra letters
takes away from the time they can spend discussing what it means.
Since mathematics is primarily written, rather than spoken, it is optimized
for the former. This means that when mathematicians are talking over the
phone they may have to say things like "capital-R", although I suspect what
they actually do is use the word that this symbol stands for
(e.g. "reals").
Kent M Pitman
> Since mathematics is primarily written, rather than spoken, it is optimized
> for the former. This means that when mathematicians are talking over the
> phone they may have to say things like "capital-R", although I suspect what
> they actually do is use the word that this symbol stands for
> (e.g. "reals").
This explanation gets my vote for why math is anomalous in this regard.
Also, it implicitly explains why many people think math comes from an
alien planet--that the notation encodes things in places they have learned
to ignore, and that they cannot figure out how to speak it (or cannot
hear it and turn it back into anything).
I can say for sure that the first time I ever ran into case dyslexia
(where I'd used "kill" instead of "KILL" on Unix, and was corrected
for it by someone voicing "you must use capital-k-i-l-l"), I resolved
never to let case be the deciding distinctino in my code because itw
as just plain ugly. I think the main reason that most
people tolerate case in language is that it's arranged to be redundant
in most languages, primarily implementing namespacing; e.g., as in Java
where case CAN be used to distinguish functions or variables but more
often there is exactly one variable and one function etc. for each letter
spelling, and where context is adequate to keep you from pronouncing stuff.
In this regard, I would make an analogy to the issue of special variable
names, where we often don't pronounce the *'s because most of us assume
people will name their special vars by convention; even hyphens in ordinary
lexical names we tend not to pronounce because we know how word breaks
are spelled.
Studies in human language show that, in spite of what grammar teachers
may think as they insist on this and that comma and period to be
placed just so in order to avoid catastrophic confusion, language is
communicated among and experiences changes along the lines of its
auditory form. I've always held it as a primary principle of
programming language design that pronounceability be taken into
account. It is for this reason, for example, that I wanted
pronunciations added to certain operators in the ANSI CL spec. I
think the need to efficiently discuss support problems over a phone
line to a support person or design programs under chinese food is of
critical importance.
Thomas F. Burdick
> Barry Margolin <bar...@genuity.net> writes:
>
> > Since mathematics is primarily written, rather than spoken, it is optimized
> > for the former. This means that when mathematicians are talking over the
> > phone they may have to say things like "capital-R", although I suspect what
> > they actually do is use the word that this symbol stands for
> > (e.g. "reals").
I once saw two biology professors trying to talk about an equation,
part of which involved a big letter with hats, etc, on top, stuff on
all four corners and on the left of the letter. It was hilarious until
they gave up and found some paper.
> I can say for sure that the first time I ever ran into case dyslexia
> (where I'd used "kill" instead of "KILL" on Unix, and was corrected
> for it by someone voicing "you must use capital-k-i-l-l"), I resolved
> never to let case be the deciding distinctino in my code because itw
> as just plain ugly. I think the main reason that most
> people tolerate case in language is that it's arranged to be redundant
> in most languages, primarily implementing namespacing; e.g., as in Java
> where case CAN be used to distinguish functions or variables but more
> often there is exactly one variable and one function etc. for each letter
> spelling, and where context is adequate to keep you from pronouncing stuff.
> In this regard, I would make an analogy to the issue of special variable
> names, where we often don't pronounce the *'s because most of us assume
> people will name their special vars by convention; even hyphens in ordinary
> lexical names we tend not to pronounce because we know how word breaks
> are spelled.
Although esthetically I'd prefer it if CL downcased everything rather
than upcased it, I like the lack of case sensitivity in the reader.
What you lose with it is the ability to namespace things like
ClassName, methodName, variable_or_function_name, etc., but I've been
known to make prodigious use of other ways of namespacing (!foo! =foo=
>>foo<< etc.) that are made possible by the fact that almost all of
ascii is available in identifiers. (Plus some more weird shit in
Latin-1 if you're not caring about portability). And I find the
(funny-symbol)...(funny-symbol) namespacing technique a *lot* more
readable than futzing with capitalization. Plus, I can't pronounce
capitalization in my head, but I can make up all sorts of funny sounds
for symbols (bang, pow, swoosh, shiik, etc.)
Kalle Olavi Niemitalo
> LISP has a sufficient tradition to use lower case for code and upper
> case for data, like
> (car '(CAR FOO))
Could you point me to some program written in that style?
Christopher Stacy
Sam> LISP has a sufficient tradition to use lower case for code and upper
Sam> case for data, like
Sam> (car '(CAR FOO))
Bletch!
I've been programming in Lisp for over 20 years, and have not
seen it done that way, so I am left wondering where this
alleged tradition comes from. Where did you get that idea?
Barry Margolin
The closest thing I can think of is that it's common to type code in lower
case, but since everything is upcased internally, when the printer displays
data it's in upper case, e.g.
*foo* => (FOO BAR)
Peter Wood
> Although esthetically I'd prefer it if CL downcased everything rather
> than upcased it, I like the lack of case sensitivity in the reader.
(setf *print-case* :downcase) ??
regards,
Peter
Kent M Pitman
This controls the typeout case, not the internal case. My impression is
that some people are miffed at having to write "FOO" rather than "foo"
in program code, or #\F rather than #\f.
Thomas F. Burdick
Yep, it's the gripe about how |CAR| takes the car of a list, not
|car|. It's not that I mind my Caps-Lock key, it's that capital
letters are more difficult to read, so of course I type my code in
lower case. And once in a while I'll type "foo" instead of "FOO" and
give myself an annoying bug.
Deepak Goel
episode---
I would be working happily in emacs,and would need to run some
common-lisp, and would invoke franz' emacs-lisp interface. All of a
sudden, many of my user-keys C-c <letter> <any more stuff> would stop
working.. for franz had bound those keys even though the convention is
to leave those for the user.
I emailed franz, and got no response. Finally, i made a change to
fi-keys.el and posted it to this newsgroup. Franz then responded to
my original email: ' we have been following up yr discussion on NG,
and see that you already solved yr problem'. I replied, requesting
that such a change be made to subsequent versions of fi-keys.el, but
never heard back, would still like Franz to make sure it does not
break emacs-conventions in subsequent versions, either by making my
fi-keys the default, or improving its own.
Ps: Getting your new fi-keys.el to work was itself quite a pain---the
only way out is to replace the original fi-keys.el with the new
one---something not easily possible unless you are the root.. This is
because, somehow even if i make sure my fi-keys is loaded, the "eli"
insists on all fi-files being in one directory and goes and loads the
original.
Deepak <URL:http://www.glue.umd.edu/~deego>
--
You know you've spent too much time on the emacs when you spill
milk and the first thing you think is "C-_"
Kevin Layer
> Speaking of Franz's (dis?)regard for standards, here is a little
> episode---
>
> I would be working happily in emacs,and would need to run some
> common-lisp, and would invoke franz' emacs-lisp interface. All of a
> sudden, many of my user-keys C-c <letter> <any more stuff> would stop
> working.. for franz had bound those keys even though the convention is
> to leave those for the user.
>
> I emailed franz, and got no response. Finally, i made a change to
> fi-keys.el and posted it to this newsgroup. Franz then responded to
> my original email: ' we have been following up yr discussion on NG,
> and see that you already solved yr problem'. I replied, requesting
> that such a change be made to subsequent versions of fi-keys.el, but
> never heard back, would still like Franz to make sure it does not
> break emacs-conventions in subsequent versions, either by making my
> fi-keys the default, or improving its own.
Some clarifications:
* Our interface pre-dates the GNU Emacs convention--not a
standard--regarding the C-c prefix. Our interface goes back to
around '87, or earlier. I don't remember when the C-c convention
came into being, but I'll guess sometime in the early '90s. Because
it does, we have the problem of compatibility. If we change it now,
people that are used to the old way will be annoyed.
* Your message was sent in on 5/27/01 (a Sunday). Tuesday morning
(02:06) you posted a message about it to c.l.l while we were
discussing this internally. On Wednesday, after the c.l.l
discussion died down, our support staff contacted you, acknowledged
the c.l.l disussion and your assertion that you had a fix for the
problem. The "got no response" is misleading and untrue.
* A request to address this issue in our interface was filed before
the spr was closed. You were not, unfortunately, informed of this
action. For that, I apologize.
I do not see "disgard" in any of these actions. At most, we didn't
communicate something we could have, and are between a rock and a hard
place because of the age of our interface and when the convention came
into being.
> Ps: Getting your new fi-keys.el to work was itself quite a pain---the
> only way out is to replace the original fi-keys.el with the new
> one---something not easily possible unless you are the root.. This is
> because, somehow even if i make sure my fi-keys is loaded, the "eli"
> insists on all fi-files being in one directory and goes and loads the
> original.
You could load fi-site-init and load your version of fi-keys after.
That should do the trick.
Kevin
Deepak Goel
> Around '87, or earlier. I don't remember when the C-c convention
I didn't know that. Thanks for clearing this up.
> Discussing this internally. On Wednesday, after the c.l.l
> discussion died down, our support staff contacted you, acknowledged
I don't remember the dates; but that is what i remembered--- a long
time elapsed between my email to franz and a response. And IIRC, this
was the first and only time franz responded to any cl-related email
from me.. And when they did, my intuitive conclusion was that i got a
response because i had publicized the issue.. But, thanks for
responding.
> * A request to address this issue in our interface was filed before
I am glad about that.
> The spr was closed. You were not, unfortunately, informed of this
> You could load fi-site-init and load your version of fi-keys after.
> That should do the trick.
Kevin, thanks a lot for this suggestion and your help, i will try it out.
Again, i am sorry i had no idea that franz's keybindings precede
gnu-emacs convention. Such a possibility of a 'solution' preceding a
'convention' just didn't occur to me..
I also see your point that changing the conventions now would annoy
older users.. Here's a suggestion though:
You could include an option that when set, would change all franz's
keybindings from
C-c <letters..> to
C-c C-x <letters>
Kevin Layer
> > Around '87, or earlier. I don't remember when the C-c convention
>
> I didn't know that. Thanks for clearing this up.
>
> > Discussing this internally. On Wednesday, after the c.l.l
> > discussion died down, our support staff contacted you, acknowledged
>
> I don't remember the dates; but that is what i remembered--- a long
> time elapsed between my email to franz and a response. And IIRC, this
> was the first and only time franz responded to any cl-related email
> from me.. And when they did, my intuitive conclusion was that i got a
> response because i had publicized the issue.. But, thanks for
> responding.
We do try to respond to customer email within 24 hours. I doesn't
always happen. In this case, only 8 work hours had elapsed from the
time of your first email to us and your posting to c.l.l., and less
than 16 work hours until our response to you.
Kevin
Craig Brozefsky
> Some clarifications:
>
> * Our interface pre-dates the GNU Emacs convention--not a
> standard--regarding the C-c prefix. Our interface goes back to
> around '87, or earlier. I don't remember when the C-c convention
> came into being, but I'll guess sometime in the early '90s. Because
> it does, we have the problem of compatibility. If we change it now,
> people that are used to the old way will be annoyed.
The solution for ILISP was to allow user control of the prefix
character for these bindings, and to provide a way of specifying that
theconvention should be observed.
> I do not see "disgard" in any of these actions. At most, we didn't
> communicate something we could have, and are between a rock and a hard
> place because of the age of our interface and when the convention came
> into being.
Make it user determinable.
--
Craig Brozefsky <cr...@red-bean.com>
http://www.red-bean.com/~craig
The outer space which me wears it has sexual intercourse. - opus
Mark Hulme-Jones
>I would be working happily in emacs,and would need to run some
>common-lisp, and would invoke franz' emacs-lisp interface. All of a
>sudden, many of my user-keys C-c <letter> <any more stuff> would stop
>working.. for franz had bound those keys even though the convention is
>to leave those for the user.
Afaik, the Emacs convention is that the C-c keys are bound by the
current major mode (in this case Franz's Common Lisp mode), and not that
they are left for user bindings. Most other major modes follow this
convention, not the one that you suggest.
--
Mark Hulme-Jones <mjo...@frottage.org>
Raymond Wiker
The major mode would be lisp-mode; the Franz-supplied bits are
for communicating with the lisp process.
--
Raymond Wiker
Raymon...@fast.no
Erik Naggum
> Afaik, the Emacs convention is that the C-c keys are bound by the
> current major mode (in this case Franz's Common Lisp mode), and not that
> they are left for user bindings. Most other major modes follow this
> convention, not the one that you suggest.
From (emacs)Keymaps:
As a user, you can redefine any key; but it might be best to stick to
key sequences that consist of `C-c' followed by a letter. These keys
are "reserved for users," so they won't conflict with any properly
designed Emacs extension. The function keys <F5> through <F9> are also
reserved for users. If you redefine some other key, your definition
may be overridden by certain extensions or major modes which redefine
the same key.
From (emacs)Rebinding:
The two-character keys consisting of `C-c' followed by a letter are
reserved for user customizations. Lisp programs are not supposed to
define these keys, so the bindings you make for them will be available
in all major modes and will never get in the way of anything.
///
Mark Hulme-Jones
I stand corrected then, and I shall point this out to the person who
mis-informed me. Doesn't this mean however that other modes such as
c-mode, c++-mode and cperl-mode are all equally at fault for binding
things to the C-c keymap?
--
Mark Hulme-Jones <mjo...@frottage.org>
Ingvar Mattsson
> In article <32085063...@naggum.net>, Erik Naggum wrote:
[SNIP]
> > From (emacs)Rebinding:
> >
> > The two-character keys consisting of `C-c' followed by a letter are
> >reserved for user customizations. Lisp programs are not supposed to
> >define these keys, so the bindings you make for them will be available
> >in all major modes and will never get in the way of anything.
>
> I stand corrected then, and I shall point this out to the person who
> mis-informed me. Doesn't this mean however that other modes such as
> c-mode, c++-mode and cperl-mode are all equally at fault for binding
> things to the C-c keymap?
C-c C-<something> is for mode-specific binding.
C-c [azA-Z] are for user bindings.
//Ingvar
--
"I'm in 386 enchanted mode."
Erik Naggum
> I stand corrected then, and I shall point this out to the person who
> mis-informed me. Doesn't this mean however that other modes such as
> c-mode, c++-mode and cperl-mode are all equally at fault for binding
> things to the C-c keymap?
Please pay closer attention. C-c <letter> is reserved for the user. The
rest of the C-c keymap is available to various modes. In particular, C-c
C-<letter> is available to modes.
///
Jon K Hellan
MH> I stand corrected then, and I shall point this out to the person who
MH> mis-informed me. Doesn't this mean however that other modes such as
MH> c-mode, c++-mode and cperl-mode are all equally at fault for binding
MH> things to the C-c keymap?
This has been said before, but never mind. C-c C-a is OK for a mode,
but C-c a is reserved for the user.
Jon Kåre