Is there any editor that colorizes the code (keywords, parenthesis, strigns
, etc,.) ?
I found a freeware editor SynEdit that allows for partial coloring but not
enough, Also, Allegro CL doesn't do that - does it ?
Nir
"Nir Sullam" <······@actcom.co.il> writes:
> Is there any editor that colorizes the code (keywords, parenthesis, strigns
> , etc,.) ?
>
> I found a freeware editor SynEdit that allows for partial coloring but not
> enough, Also, Allegro CL doesn't do that - does it ?
From the names you mention I'm implying you work under some form of
Windows, so I don't know what kind of editor Franz supplies with
Allegro CL for that plattform. But on Unix/Linux, Allegro CL works
with Emacs, which not only has the syntax-coloring you mention, but a
whole host of other features you'll want with a Lisp editor (or for
that matter most other kinds of editing tasks), especially in
combination with Franz's Emacs Lisp Interface. So the first thing I'd
try would be to get either GNU/NT Emacs or XEmacs[1] running on
Windows, and check out whether Franz's interface doesn't also work
under Windows.
Regs, Pierre.
Footnotes:
[1] The new XEmacs release over at http://www.xemacs.org/ should work
with Windows out of the box, I hear...
--
Pierre Mai <····@acm.org> http://home.pages.de/~trillian/
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
····@acm.org (Pierre R. Mai) writes:
> From the names you mention I'm implying you work under some form of
> Windows, so I don't know what kind of editor Franz supplies with
> Allegro CL for that plattform. But on Unix/Linux, Allegro CL works
> with Emacs, which not only has the syntax-coloring you mention, but a
> whole host of other features you'll want with a Lisp editor
The Windows version is the same. Emacs cross-platform is highly
compatible. The issue is not whether it has the capability, though,
but which Allegro releases have the Emacs support at all. My
Enterprise Edition at home has the Emacs support, but as nearly as I
can tell (unless I installed it wrong) the Personal Edition (low-end
for-$ edition) we have at my office did not come with the Emacs
support. I haven't needed it because I use the IDE with the personal
edition and that's not Emacs-based, so I don't know if it's a bug or a
feature that the Emacs was not found when I installed Allegro's 5.0
Personal Edition on Windows. (The IDE does not use coloring; I happen
not to mind that. The coloring in the Emacs interface, which I think
is called ELI, is tastefully done, so I just grin and bear it. But I
have no use for it. I know others like it, so I haven't complained to
Franz about its being on by default. It's probably a good marketing
choice to have it on by default, actually. People love glitz.)
From: Christopher R. Barry
Subject: Re: CL syntax coloring editor ?
Date:
Message-ID: <87lney2bhq.fsf@2xtreme.net>
Kent M Pitman <······@world.std.com> writes:
[...]
> (The IDE does not use coloring; I happen not to mind that. The
> coloring in the Emacs interface, which I think is called ELI, is
> tastefully done, so I just grin and bear it. But I have no use for
> it. I know others like it, so I haven't complained to Franz about
> its being on by default. It's probably a good marketing choice to
> have it on by default, actually. People love glitz.)
Glitz?? I really think it helps readability to at least have the
comments a different color than the code. Having string constants a
different color is also nice, though not as important as the
comments. I don't think syntax coloring is as important with the
uniform, readable syntax of Lisp code as it is with say, Java.
As for coloring on a form-by-form basis: I don't think IF, LOOP,
etc. need coloring but it's nice to have arguments to def* forms
colored when you're quickly scrolling a buffer (Emacs doesn't do the
right thing with (defun (setf ...)) coloring though).
Syntaxing coloring is where you see some big differences in the
default conventions between GNU and X Emacs. Syntax-highlighted GNU
Emacs buffers have a paler look with purple-bluish tones while XEmacs
buffers are brighter with more usage across the spectrum. I think the
biggest difference is that GNU Emacs uses this pale "RosyBrown" color
for string constants in all modes that doesn't contrast well with a
white background and XEmacs uses a green one. They both use a reddish
color for comments (XEmacs uses a brighter variant).
Christopher
······@2xtreme.net (Christopher R. Barry) writes:
> Kent M Pitman <······@world.std.com> writes:
> > It's probably a good marketing choice to
> > have it on by default, actually. People love glitz.
>
> Glitz?? I really think it helps readability to at least have the
> comments a different color than the code.
The reason I do not like color is that some colors are inherently more
visible than others. When you want things to be in the foreground,
you want them a certain color. When you want them in the background,
you want a different color. But most color interfaces don't provide
instantaneous focus alteration, so in practice color interfaces give
me too much visibilty of certain code some of the time and too little
other times. I'd rather have it uniformly blah. As I said, just a
personal preference. I didn't even say it was a prevailing personal
preference. However, saying you want to distinguish these things is
not a proof that it is good human engineering. People routinely say
that things they can articulate are good for the reason that they can
articulate them. For example, your claim here implicitly says that
because it allows you to distinguish two things, there is some
inherent goodness. Either you didn't say what you really mean, or
else your claim is not really supported. I accept that you like color,
but I am hard-pressed to believe you like it because it allows you to
distinguish these two things absent a further claim that
distinguishing these two things is (a) a common operation, (b) hard to
do in present code, and (c) the only kind of distinction you want to
make.
This last point (c) leads me to my other objection. Sometimes you may
want to highlight comments, and sometimes code. But sometimes you may
want a completely different partition. Color use also implies not only
good choice of colors, but good and even unique delineations between
things that need color and things that do not. If I am doing Meta-.
for example, and I want to be prompted for a function name, as on Genera,
the things I want to see are "function names" and I'm not partial to
whether they are mentioned in code or comment. But if the code is busy
making comments bright and code dim or code bright and comments dim,
the partition is not even along the axis which is useful to me.
I would personally prefer to have an interface that uses color dynamically
by context to highlight based on some actual knowledge of what I am trying
to do.
> Having string constants a
> different color is also nice, though not as important as the
> comments.
Depends on what I'm doing. Certainly the degree of truth or falsity
of this remark is not invariant with the activity that I am doing at
any given moment.
> I don't think syntax coloring is as important with the
> uniform, readable syntax of Lisp code as it is with say, Java.
I very much disagree with this. Highlighting syntax keywords in Java
gives undue attention to the least relevant part of the program: the
connective structure. It makes it harder and harder to ever see the
program in a way that rises above this connective glue because it puts
the connective glue always in the prominent position.
Incidentally, I also don't like the style where the "definition name"
is highlighted because it is not always what I am trying to pick out.
Same issue: it emphasizes program structure as relevant rather than
acknowledging that sometimes I am doing different things with the program
and want to see different things highlighted.
> As for coloring on a form-by-form basis: I don't think IF, LOOP,
> etc. need coloring but it's nice to have arguments to def* forms
> colored when you're quickly scrolling a buffer (Emacs doesn't do the
> right thing with (defun (setf ...)) coloring though).
I agree that if you're in some sort of scroll mode this could
sometimes be nice, but I'd rather have the option to enable this while
I had the mouse over the scroll bar and have it go away when I stopped
scrolling. Again, an issue of what my focus is.
> Syntaxing coloring is where you see some big differences in the
> default conventions between GNU and X Emacs. Syntax-highlighted GNU
> Emacs buffers have a paler look with purple-bluish tones while XEmacs
> buffers are brighter with more usage across the spectrum. I think the
> biggest difference is that GNU Emacs uses this pale "RosyBrown" color
> for string constants in all modes that doesn't contrast well with a
> white background and XEmacs uses a green one. They both use a reddish
> color for comments (XEmacs uses a brighter variant).
As Stallman used to tell me about Emacs, the point is not the initial
command set--it's the user's ability to change it. If either of these
doesn't make it 100% easy to change the colors used, it is not emacs-like.
As such, the choice of colors used is somewhat of an irrelevancy.
My focus is on "when is color used" and "what is colored when", not on
"what color". The main thing that good color choice does is it makes
me less irritated if I'm too lazy to go learn how to turn it off. Sigh.
Kent M Pitman (······@world.std.com) wrote:
: I would personally prefer to have an interface that uses color dynamically
: by context to highlight based on some actual knowledge of what I am trying
: to do.
Any time I think I've gotten my mind around Lisp, I can always remind
myself that *real* Lispers can handle, and in fact prefer, things that
would make my head explode.:-) Although I like some syntax
highlighting (especially for decorations on the main program, like
comments, assertions, and declarations; and to a lesser extent for
different reader modes, like strings and block comments), and although
I know at an intellectual level that everything I work with is
software layered on top of wavefunctions, there are a dozen or so
layers in my visual cortex which are considerably happier with the
abstraction that the characters in my program are static, concrete
objects which don't magically do psychadelic things.
: ······@2xtreme.net (Christopher R. Barry) writes:
: > I don't think syntax coloring is as important with the
: > uniform, readable syntax of Lisp code as it is with say, Java.
: I very much disagree with this. Highlighting syntax keywords in Java
: gives undue attention to the least relevant part of the program: the
: connective structure. It makes it harder and harder to ever see the
: program in a way that rises above this connective glue because it puts
: the connective glue always in the prominent position.
I agree with this.
: Incidentally, I also don't like the style where the "definition name"
: is highlighted because it is not always what I am trying to pick out.
: Same issue: it emphasizes program structure as relevant rather than
: acknowledging that sometimes I am doing different things with the program
: and want to see different things highlighted.
To me highlighting the definition name is redundant partly for KMP's
reason (since I might be e.g. looking for all DEFCONSTANTs instead of
whatever form it is that defines FOO) and partly because it's so easy
for me to pick out the definition name anyway, because of Lisp's
relatively regular syntax. If I had to use a language where the
definition syntax was more irregular, I might be more interested
in this kind of highlighting.
: > As for coloring on a form-by-form basis: I don't think IF, LOOP,
: > etc. need coloring but it's nice to have arguments to def* forms
: > colored when you're quickly scrolling a buffer (Emacs doesn't do the
: > right thing with (defun (setf ...)) coloring though).
: I agree that if you're in some sort of scroll mode this could
: sometimes be nice, but I'd rather have the option to enable this while
: I had the mouse over the scroll bar and have it go away when I stopped
: scrolling. Again, an issue of what my focus is.
I played with syntax highlighting for control forms, never found
something I really liked, and turned it off. I'm still playing with
syntax highlighting for macro syntax (commas, backquotes, and quotes):
I'm far from completely satisfied, but I like what I have better than
nothing at all.
Bill Newman
·······@netcom.com
·······@netcom.com (Bill Newman) writes:
> I played with syntax highlighting for control forms, never found
> something I really liked, and turned it off. I'm still playing with
> syntax highlighting for macro syntax (commas, backquotes, and quotes):
> I'm far from completely satisfied, but I like what I have better than
> nothing at all.
I prefer flashing parens when I'm actually at a paren, but not always.
Likewise, for Teco-based Emacs I implemented flashing backquote (where
typing a "," momentarily blinked the matching "`" by doing [approximately]
backward-up-s-expression (control-meta-u) until it found the relevant
backquote. This is nice because it's helpful when you need it and goes
away right after. Persistent coloring of commas or whatever would bug me.
From: Christopher R. Barry
Subject: Coloring not based on syntax and hard vs. mnemonic bindings (was Re: CL syntax coloring editor ?)
Date:
Message-ID: <87btfs2j5c.fsf_-_@2xtreme.net>
Kent M Pitman <······@world.std.com> writes:
[...]
> I would personally prefer to have an interface that uses color dynamically
> by context to highlight based on some actual knowledge of what I am trying
> to do.
How specifically would the editor gain knowledge of what you are
trying to do? For example, would you want Meta-, (next-definition...)
to highlight definitions (this doesn't seem _that_ useful)? I can't
imagine the specifics of the functionality concept you have
introduced, but if you go into detail you might inspire someone with
some Emacs Lisp knowledge to try to do an implementation. ;-)
> > Having string constants a
> > different color is also nice, though not as important as the
> > comments.
>
> Depends on what I'm doing. Certainly the degree of truth or falsity
> of this remark is not invariant with the activity that I am doing at
> any given moment.
>
> > I don't think syntax coloring is as important with the
> > uniform, readable syntax of Lisp code as it is with say, Java.
>
> I very much disagree with this. Highlighting syntax keywords in Java
> gives undue attention to the least relevant part of the program: the
> connective structure. It makes it harder and harder to ever see the
> program in a way that rises above this connective glue because it puts
> the connective glue always in the prominent position.
I don't see how the editor can highlight code in such a way as to rise
above anything other than syntax details (but wouldn't mind an
example). Personally, the syntax highlighting of JDE-mode really helps
me to read Java code faster. I should have emphasized that the only
real benefit of syntax highlighting to me is when I am quickly
scanning code for a specific thing. If I'm looking for where I've
created an object in a body of Java code I know I only need to look at
orange code for the "new" operator and when I'm trying to find the
string that an ActionCommand sends I only need to read the green
code. I think this saves my eyes and mind (brain?) a lot of strain.
So since I've said it only really helps when scanning, which in a way
implies that it's not needed and perhaps even a distraction when not
scanning, this perhaps means that it should only be turned on when
scanning. But how is the editor to determine when you are doing this?
To turn it on when you start scrolling and then fade it away a moment
after you stop isn't good enough, because you may want to scan what is
currently visible. Sure, you could scroll up a screenful and then back
down to get the color refreshed with this harebrained scheme but for
that ammount of trouble it isn't worth it. The more I think about it,
the more I think the color isn't _that_ big of deal, but to me
personally I still find it is more helpful when on than off.
> Incidentally, I also don't like the style where the "definition name"
> is highlighted because it is not always what I am trying to pick out.
I think coloring the definition name is a double-edged sword. As long
as the definition name contrasts well with the surrounding words I
think it is easy to either pick it out or avoid it.
> Same issue: it emphasizes program structure as relevant rather than
> acknowledging that sometimes I am doing different things with the program
> and want to see different things highlighted.
Again, I find the concept that coloring can mean more than
syntax-coloring fascinating, but don't see how this could be made to
work usefully.
> As Stallman used to tell me about Emacs, the point is not the
> initial command set--it's the user's ability to change it.
A big problem with this is that many programmers give bindings to
their packages that are heavily based on default Emacs bindings, and
this can cause really difficult to solve problems when you are in
certain situations. I'll go into detail about what I mean.
One thing I like about the vi editor is that a lot of bindings were
chosen because of their physical layout on the keyboard; you can for
example move the cursor up/down/left/right with only your right hand
on the home row. With vi, you do nearly all things by touch rather
than by associating a mnemonic with the action. A while back I
experimented with the Dvorak keyboard layout (great for Lisp: they put
"-" on the home row!). If you are a Dvorak-layout user you can shuffle
the vi bindings around without too much difficulty and be right back
in business. Many emacs bindings were chosen because of their mnemonic
value, and others because of their physical layout. Switching to
Dvorak is a big mess. Leaving C-n/C-p/C-b/C-f and the C-x/C-c prefix
keys as they are is really weird for reasons that I hope are
self-evident. Attempting to remap the C-x/C-c keymaps to the
equivalent Dvorak keys and then remapping the cursor-motion keys to
their previous hard-layout just causes problems which when "fixed"
cause more problems and the madness has no end.
The Dvorak example is a little extreme. Even just remapping the cursor
motion keys to the vi bindings causes a huge number of problems if you
use Control as the modifier (which is most natural). So to use this
example; C-h, C-j, C-k and C-l would now be the cursor motion
keys. Now nearly all of the Emacs modes respect and leave alone the
default 4 cursor keys, but many of them do their own thing with the
new vi cursor keys and will overide your binding until you manually
re-overide their binding. Lisp interaction mode redefines C-j as
"eval-print-last-sexp". So the second you enter this mode you will no
longer be able to move the cursor down one line until you've swapped
the keys locally. Gnus rebinds C-k and C-l in summary mode so you must
again swap them and their new equivalents. Other modes like to take
default Emacs bindings and make them do the same thing but add a
mode-specific feature or property so that the global command is
overidden which means that the locally-overidden command must again be
locally-overidden by the user on a case-by-case basis and it all is
just a real pain.
It would be cool if bindings had attributes like "mnemonic" or "hard"
and if there was a system in place that could allow someone to
redefine one binding and have the right thing done to automatically
resolve all the kinds of conflicts described above.
[All of this discussion may be of interest to Emacs group readers.]
> If either of these doesn't make it 100% easy to change the colors
> used, it is not emacs-like. As such, the choice of colors used is
> somewhat of an irrelevancy.
I think it is relevant, because I speculate plenty of people never get
around to changing it for the reason you mention below [ ;-) ] or
because they have faith that the people that set the defaults the way
they are really knew what they were doing. As an example of the
latter, I think globally binding shift-space to "scroll-up",
shift-backspace to "scroll-down", and shift-enter to "scroll up one
line" is more consistent with the bindings Unix pagers and gnus and
many mailers use for scrolling instead of Control-v and Meta-v. But
since shift-space and shift-enter are so easy and rapid to type,
perhaps they have better use being bound another way (for completer
code perhaps), and perhaps Control-v and Meta-v really is the Right
Way to scroll buffers that are writable when you can't just type
space, backspace and enter to scroll.
> My focus is on "when is color used" and "what is colored when", not on
> "what color". The main thing that good color choice does is it makes
> me less irritated if I'm too lazy to go learn how to turn it off. Sigh.
So the $100,000 question is: "When is color used" and "what is colored
when"?
Christopher
From: Kent M Pitman
Subject: Re: Coloring not based on syntax and hard vs. mnemonic bindings (was Re: CL syntax coloring editor ?)
Date:
Message-ID: <sfwyaiwdpwz.fsf@world.std.com>
[ replying to comp.lang.lisp only
http://world.std.com/~pitman/pfaq/cross-posting.html ]
······@2xtreme.net (Christopher R. Barry) writes:
> How specifically would the editor gain knowledge of what you are
> trying to do? For example, would you want Meta-, (next-definition...)
> to highlight definitions (this doesn't seem _that_ useful)? I can't
> imagine the specifics of the functionality concept you have
> introduced, but if you go into detail you might inspire someone with
> some Emacs Lisp knowledge to try to do an implementation. ;-)
Anyone wanting inspiration is welcome to purchase and study a Lisp Machine.
> > I very much disagree with this. Highlighting syntax keywords in Java
> > gives undue attention to the least relevant part of the program: the
> > connective structure. It makes it harder and harder to ever see the
> > program in a way that rises above this connective glue because it puts
> > the connective glue always in the prominent position.
>
> I don't see how the editor can highlight code in such a way as to rise
> above anything other than syntax details (but wouldn't mind an
> example).
In part, this is why I prefer it not to highlight anything. However,
if you saw a Lisp Machine environment, you would understand what I mean
by things lighting up in a context-sensitive way. It didn't use color
but instead used rectangles around things as the mouse waved around,
but that was because color was expensive back then and few people had it.
> [...] But how is the editor to determine when you are doing this?
By letting me say when. If I don't say when, it should do nothing.
When I press Meta-. and am in a context-wait to type a function name,
for example, function names should light up. If I'm doing Variable
Apropos, variable names should light up. If I'm being prompted for a
filename, filenames should light up. If I define that a certain
gesture is done with Hyper-Control-Meta- something, then when I press
Hyper-Control-Meta, the system should become alert to the fact that I
might be about to click something using those shifts and should light
up what's relevant for those shifts and my given input context. The
Lisp Machine had a lot of stuff like this that was entirely adequate
to my needs. I could not in a single post nor in 20 explain to you
why what it did was right, but it was, and it's the only computer I
know that still today, 7 years after I bought it, I could still
imagine voluntarily using in spite of its size, speed, and noise
because it is still smarter and more user-friendly than anything on
the market today. Not because other things couldn't emulate what it
did--just because no one seems to care to bother.
> Again, I find the concept that coloring can mean more than
> syntax-coloring fascinating, but don't see how this could be made to
> work usefully.
On the Lisp Machine, when I press and hold the Meta key, things that
are sensitive to any Meta command light up. Usually "Edit" commands
are on Meta, and so holding Meta and waving the mouse around will
light up things I can edit as the mouse tracks across them. When I
press and hold Super, anything that is a presentation (a la Dynamic
Windows or CLIM) tends to light up because the presentation-inspector
commands are on Super-this and Super-that. For example, in a buffer
listing in Zmacs, waving the mouse over a buffer name lights up the
buffer name as a thing I can click on to select the buffer. But if I
hold down Super, the same thing lights up [in certain contexts] but
for a different reason: to allow me to select the buffer object in a
lisp listener, e.g., so I can inspect it as a lisp object.
From: Christopher R. Barry
Subject: Re: Coloring not based on syntax and hard vs. mnemonic bindings (was Re: CL syntax coloring editor ?)
Date:
Message-ID: <87yaiw0zns.fsf@2xtreme.net>
Kent M Pitman <······@world.std.com> writes:
> [ replying to comp.lang.lisp only
> http://world.std.com/~pitman/pfaq/cross-posting.html ]
I've read this. I think your reply would have been of great interest
and value to Emacs users, since to all of us in commodity
hardware/software Land, GNU/X Emacs is the most powerful, functional,
extensible and useful piece of software ever made and available to us
and is intended to serve largely the same purpose, but seems to pale
in comparison.
By the way, a few months back when you last advocated and explained
some of Lisp machine functionality (mostly in reply to posts of mine),
I started looking around for one. Peter Paine in the UK has 3620 to
sell me but shipping w/ insurance is just as much as the machine
(around $300 IIRC) and the combined cost breaks my
19-year-old-full-time-college-freshman budget for now and sending your
money to another country is weird anyways. I live in the SF Bay Area
and he told me a lot of 3D/animation shops in this area used them and
to look around. So I politely emailed a lot of them and actually got
this reply from one:
I do. It works fine. Make me an offer and I will consider giving up
the stand for my conference table.... It actually works really nice
with a big piece of glass on it!
Cheers.
Mark T. Davis
So that made me grin a bit and I thought I'd found a
too-good-to-be-true setup, but then I was really, really stupid in my
reply. I had already been quoted the $300 or so for the 3620 (minus
shipping of course) so I asked the guy what the model was and
mentioned that if it was an old plain old 36xx series that a few
hundred should be fair. And apparently "a few hundred" completely
scared the guy away (no reply to that email and a subsequent
one). Actually, I guess it's not that big of deal since either:
1. It was a plain old 36xx and he wanted way too much for it.
2. It was a load XL1200 or similar with all the 3D graphics add-ons
and $10,000+ anyways (or even only a nice 36xx with color graphics
but still too much for me right now).
3. I really did only _have_ a few hundred anyways....
4. He died in a tragic accident shortly after replying to my first
email.
Sigh. Still looking....
Christopher
From: thi
Subject: Re: Coloring not based on syntax and hard vs. mnemonic bindings (was Re: CL syntax coloring editor ?)
Date:
Message-ID: <m2rpv48t5kv.fsf@netcom9.netcom.com>
······@2xtreme.net (Christopher R. Barry) writes:
> So the $100,000 question is: "When is color used" and "what is colored
> when"?
color is used when you open your eyes. then there is foreground and
background at a minimum. in console mode this is all you have. so color is
used when the machine has the right kind (and amount) of memory (so that you
don't have to).
all things are colored at the time of perception.
thi
From: ···············@CS.Uni-Dortmund.DE
Subject: Re: Coloring not based on syntax and hard vs. mnemonic bindings (was Re: CL syntax coloring editor ?)
Date:
Message-ID: <vaf6760dmz7.fsf@petty.cs.uni-dortmund.de>
······@2xtreme.net (Christopher R. Barry) writes:
> [...] Many emacs bindings were chosen because of their mnemonic
> value, and others because of their physical layout. [...]
I can't think of any bindings, other than the cursor keys, which were
chosen for layout. Can you give examples of layout-oriented
keybindings in Emacs?
kai
--
Abort this operation? [Abort] [Cancel]
From: Christopher R. Barry
Subject: Re: Coloring not based on syntax and hard vs. mnemonic bindings (was Re: CL syntax coloring editor ?)
Date:
Message-ID: <87lnewj607.fsf@2xtreme.net>
···············@CS.Uni-Dortmund.DE writes:
> ······@2xtreme.net (Christopher R. Barry) writes:
>
> > [...] Many emacs bindings were chosen because of their mnemonic
> > value, and others because of their physical layout. [...]
>
> I can't think of any bindings, other than the cursor keys, which were
> chosen for layout. Can you give examples of layout-oriented
> keybindings in Emacs?
I think the cursor keys were chosen mnemonically. It's IMHO nicer to
have them all on the right side.
Many of the layout-oriented keys might also have some mnemonic value
(coincidentally or otherwise). What is "mnemonic" is kinda a
subjective, cognitive thing I suppose. If you ever actually try
Dvorak, you'll see that keys that were previously sanely located are
now not.
C-x, C-c prefix keys (C-x has mnemonic value to, but z x c v are the
only real candidates for prefix keys that are accessed extremely
often)
C-_, C-/ undo
C-m, C-j newline and newline-and-indent (was kinda forced to inherit
these though)
C-x C-c quit-emacs (some older emacsen did C-x C-z, same feeling)
C-x C-v find-alternative-file (in general, all file/close/quit
operations can be done on the left side of the keyboard)
C-g keyboard-quit
C-] abort-recursive-edit (mnemonically this has a feeling of
"containing" or "enclosing")
M-C-[ : eval-expression
M-C-[ C-[ keyboard-escape-quit
C-space set-mark-command (faster than ··@, but same with dvorak anyways)
C-l recenter
C-v, M-v, M-V scrolling
M-/ dabbrev-expand
M-: eval-expression
M-q fill-paragraph
Most shifted number-row stuff.
This is only half of the global map stuff, all the local modes have
plenty to....
Christopher
From: ···············@CS.Uni-Dortmund.DE
Subject: Re: Coloring not based on syntax and hard vs. mnemonic bindings (was Re: CL syntax coloring editor ?)
Date:
Message-ID: <vaf90avrg8o.fsf@petty.cs.uni-dortmund.de>
······@2xtreme.net (Christopher R. Barry) writes:
For me, all of the following are mnemonic, not chosen because of
layout. Except, possibly, for C-c...
> C-x, C-c prefix keys (C-x has mnemonic value to, but z x c v are the
> only real candidates for prefix keys that are accessed extremely
> often)
x == extended
> C-_, C-/ undo
Hm. Dunno why this is. Possible choice for C-_ could be
layout-oriented: _ is same key as -, the latter somehow indicating
backwards.
> C-m, C-j newline and newline-and-indent (was kinda forced to inherit
> these though)
Hm. Layout. Hm. Yes, RET is probably chosen by layout, but what
about LFD? Hm. I think SPC, RET, TAB, LFD and maybe ESC are special
-- these are keys with conventional meaning in other programs.
> C-x C-c quit-emacs (some older emacsen did C-x C-z, same feeling)
Ctrl-C is quit in Unix, that's the mnemonic I see.
> C-x C-v find-alternative-file (in general, all file/close/quit
> operations can be done on the left side of the keyboard)
v == visit
> C-g keyboard-quit
Hm. C-g being interrupt is no more intuitive than C-c being
interrupt, but surely this is not because of layout, is it?
> C-] abort-recursive-edit (mnemonically this has a feeling of
> "containing" or "enclosing")
>
> M-C-[ : eval-expression
> M-C-[ C-[ keyboard-escape-quit
M-C-[ C-[ is the same as ESC ESC ESC which is rather mnemonic I'd say.
> C-space set-mark-command (faster than ··@, but same with dvorak anyways)
Hm. Yes, maybe this was chosen for layout reasons.
> C-l recenter
>
> C-v, M-v, M-V scrolling
The shape of v suggests down...
> M-/ dabbrev-expand
Dunno.
> M-: eval-expression
Same as : command in vi? Or vice versa...
> M-q fill-paragraph
Yeah, this could be by layout.
> Most shifted number-row stuff.
Hm. Turns out a few of them are actually from layout after all. Thanks!
kai
--
Abort this operation? [Abort] [Cancel]
From: Rob Hodges
Subject: Re: Coloring not based on syntax and hard vs. mnemonic bindings (was Re: CL syntax coloring editor ?)
Date:
Message-ID: <m3iu9z1up8.fsf@phaedrus.zen.xom>
···············@CS.Uni-Dortmund.DE writes:
> ······@2xtreme.net (Christopher R. Barry) writes:
>
> For me, all of the following are mnemonic, not chosen because of
> layout. Except, possibly, for C-c...
>
> > C-x, C-c prefix keys
> x == extended
But just imagine for a moment that the 'y' key was the perfect
mnemonic for "extended". And no matter how much you strained your
brain, you couldn't see how any of the keys close to the Ctrl key
could be a mnemonic for "extended". Would you put all of the extended
commands under 'C-y'? Not unless you have hands like Rachmaninov. If
you change keyboard layouts to something that puts 'x' where 'y' is on
a qwerty board, you're definitely not going to be happy with C-x, no
matter how mnemonic it is.
The other thing is that after the first hundred times, there's no way
you're trying to remember "what is the mnemonic for extended
commands?". You type C-x, and you don't even think about what you're
doing; the muscle movements have become hard-coded into your brain.
So if you learned to type in a new keyboard layout, you'd have trained
yourself to relocate 'x' when you were typing, but when you tried to
hit Ctrl-x in Emacs, you'd still go for the letter where x used to be.
So I think Christopher's point is a very good one. The question is
how to get the effect of what he's asking for without requiring any
rewriting of the many packages that are out there. I can only think
that you'd have to write a minor mode that grabbed all of the
keystrokes, changed the ones that you'd changed in an alist somewhere,
and then passed them on. I have no idea whether this would be
possible. Or even desirable :)
On the other hand, it really is only a matter of convenience. You
*can* change the key bindings in every single mode individually. God
knows, I've changed the colours in just about every mode that offers
syntax colouring, since so few actually respect the value of
frame-background-mode. But that's another story...
-Rob
--
A scarecrow looking for a bonfire to sleep on...
From: Kent M Pitman
Subject: Re: Coloring not based on syntax and hard vs. mnemonic bindings (was Re: CL syntax coloring editor ?)
Date:
Message-ID: <sfwemknhajl.fsf@world.std.com>
[ replying to comp.lang.lisp only
http://world.std.com/~pitman/pfaq/cross-posting.html ]
Rob Hodges <·······@student.uq.edu.au> writes:
> So I think Christopher's point is a very good one. The question is
> how to get the effect of what he's asking for without requiring any
> rewriting of the many packages that are out there.
I think this is not a very intellectually interesting question, though it
may have practical consequence. A better question is how to structure
code in the future so that desires like this can be met without rewriting
code that intended to accomodate such needs.
His desire to separate the various "reasons" for attaching key
bindings in order to cue programs about which keys were ok to redefine
and which were not is interesting. But really no software that does
not anticipate a need like this is going to accomodate the addition
without at least some upheaval. You can't really plan for the totally
unknown. The real question is whether you can learn to plan for the
things you come to know or whether you refuse to learn from history.
From: ···············@CS.Uni-Dortmund.DE
Subject: Re: Coloring not based on syntax and hard vs. mnemonic bindings (was Re: CL syntax coloring editor ?)
Date:
Message-ID: <vafk8ufo79g.fsf@petty.cs.uni-dortmund.de>
Rob Hodges <·······@student.uq.edu.au> writes:
> But just imagine for a moment that the 'y' key was the perfect
> mnemonic for "extended". And no matter how much you strained your
> brain, you couldn't see how any of the keys close to the Ctrl key
> could be a mnemonic for "extended". Would you put all of the extended
> commands under 'C-y'?
No, one would try to find another lame excuse^H^H^H^H^H^H^H^H^H^H^Hmnemonic
for `y' :-)
> So I think Christopher's point is a very good one. The question
> is how to get the effect of what he's asking for without requiring
> any rewriting of the many packages that are out there. I can only
> think that you'd have to write a minor mode that grabbed all of
> the keystrokes, changed the ones that you'd changed in an alist
> somewhere, and then passed them on. I have no idea whether this
> would be possible. Or even desirable :)
How about doing it in the keyboard-translate-table? I think you could
do, say:
(unless keyboard-translation-map
(setq keyboard-translation-map (make-keymap)))
(define-key keyboard-translation-map (kbd "C-y") (kbd "C-x"))
(define-key keyboard-translation-map (kbd "C-x") (kbd "C-y"))
I think this swaps C-x and C-y in all respects. I.e. before, you
typed C-x C-c to exit Emacs, now it is C-y C-c. Before, you might
type C-z C-x, now it is C-z C-y. And so on.
I did it for the DEL key and C-d, and even typing ESC DEL made Emacs
believe it saw ESC C-d.
It would not require any changes in modes.
Does this work?
kai
--
Abort this operation? [Abort] [Cancel]
From: Rob Hodges
Subject: Re: Coloring not based on syntax and hard vs. mnemonic bindings (was Re: CL syntax coloring editor ?)
Date:
Message-ID: <m3n1zbwgq1.fsf@phaedrus.zen.xom>
···············@CS.Uni-Dortmund.DE writes:
> How about doing it in the keyboard-translate-table? I think you could
> do, say:
>
> (unless keyboard-translation-map
> (setq keyboard-translation-map (make-keymap)))
> (define-key keyboard-translation-map (kbd "C-y") (kbd "C-x"))
> (define-key keyboard-translation-map (kbd "C-x") (kbd "C-y"))
Unless I set the first line to...
(unless (boundp 'keyboard-translation-map)
...I get a "value as variable is void". I think this must work
differently in 20.4 to 20.3, because even then, it makes no change.
This works though:
(keyboard-translate ?\C-y ?\C-x)
(keyboard-translate ?\C-x ?\C-y)
Yet I now notice that someone was saying in an earlier thread that
swapping keys this way doesn't work in 21.0.
I hope this is useful to Christopher in some way. Myself, I think
I'll stick with qwerty until I get RSI...
-Rob
(This is pretty XEmacs-specific so I've dropped the other groups.)
--
A scarecrow looking for a bonfire to sleep on...
From: [Invalid-From-Line]
Subject: Re: Coloring not based on syntax and hard vs. mnemonic bindings (was Re: CL syntax coloring editor ?)
Date:
Message-ID: <wtk8uetx1o.fsf@vesta.rts.tu-harburg.de>
>>>>> "Christopher" == Christopher R Barry <······@2xtreme.net> writes:
Christopher> layout. Switching to Dvorak is a big mess. Leaving
Christopher> C-n/C-p/C-b/C-f and the C-x/C-c prefix keys as they
Christopher> are is really weird for reasons that I hope are
Christopher> self-evident.
not really i am afraid. ok, i went dvorak years ago, and i honestly
forgot most of querty, but i find most control sequences rather
handy. i have never used C-n etc, since i prefer cursor keys. and
while i can see that C-x and c are somewhat special, i don't thing it
has to be this way. ok, on dvorak you need 2 hands to type extended
command, but it isn't necessarily slower.
Christopher> The Dvorak example is a little extreme. Even just
Christopher> remapping the cursor motion keys to the vi bindings
Christopher> causes a huge number of problems if you use Control
Christopher> as the modifier (which is most natural).
all you need is a true Alt key, and you have all the bindings for
yourself :-) it might not be very helpful, but that's the way it
is. apart from a few prefice (C-c letter ?) the emacs-keymap is
full. so you either have to remove things you don't need (like C-o) or
you have to define a new modifier.
Thomas <·········@tu-harburg.de>
--
We regret to announce that Windows 2000 wont be ready before 1901.
In article <··············@2xtreme.net>,
Christopher R. Barry <······@2xtreme.net> wrote:
>default conventions between GNU and X Emacs. Syntax-highlighted GNU
>Emacs buffers have a paler look with purple-bluish tones while XEmacs
>buffers are brighter with more usage across the spectrum. I think the
>biggest difference is that GNU Emacs uses this pale "RosyBrown" color
>for string constants in all modes that doesn't contrast well with a
>white background and XEmacs uses a green one. They both use a reddish
>color for comments (XEmacs uses a brighter variant).
Emacs 19.34.1, at least, allows the user to conveniently
tinker with the color choices for various things. Read
faces.el and font-lock.el. After some fooling around to see
what I liked, I added the following to my .emacs file:
(setq font-lock-face-attributes
'((font-lock-comment-face nil "peachpuff1")
(font-lock-string-face "ForestGreen")
(font-lock-keyword-face "Red")
(font-lock-function-name-face "Blue")
(font-lock-variable-name-face "DarkOrchid3")
(font-lock-type-face "DarkOliveGreen4")
(font-lock-reference-face "DarkSlateBlue")))
You can also decide to put stuff in bold or italics, underline
it, or mess with the choice of fonts in exotic ways.
--
John E. Doner, UCSB Math. Dept., ·····@math.ucsb.edu
"Nir Sullam" <······@actcom.co.il> writes:
> Is there any editor that colorizes the code (keywords, parenthesis, strigns
> , etc,.) ?
(X)Emacs.
(BTW, there's now a native windows version of XEmacs as well as Emacs.)
On Sat, 8 May 1999 22:21:40 GMT, Nir Sullam wrote:
>Is there any editor that colorizes the code (keywords, parenthesis, strigns
>, etc,.) ?
>
>I found a freeware editor SynEdit that allows for partial coloring but not
>enough, Also, Allegro CL doesn't do that - does it ?
www.vim.org
Groetjes, Peter
--
It's logic Jim, but not as we know it. | ········@debian.org for pleasure,
"God, root, what is difference?",Pitr | ········@inthan.be for more pleasure!
From: Christopher R. Barry
Subject: Re: CL syntax coloring editor ?
Date:
Message-ID: <8790aw2iuz.fsf@2xtreme.net>
········@mail.inthan.be (Peter Van Eynde) writes:
> On Sat, 8 May 1999 22:21:40 GMT, Nir Sullam wrote:
> >Is there any editor that colorizes the code (keywords, parenthesis, strigns
> >, etc,.) ?
> >
> >I found a freeware editor SynEdit that allows for partial coloring but not
> >enough, Also, Allegro CL doesn't do that - does it ?
>
> www.vim.org
For old-times sake I fired up my copy of vim and it doesn't do any
Lisp syntax highlighting nor does it seem to have any kind of Lisp
mode support.
Why did you recommend vim??
Christopher
On Tue, 11 May 1999 06:55:03 GMT, Christopher R. Barry wrote:
>········@mail.inthan.be (Peter Van Eynde) writes:
>
>> On Sat, 8 May 1999 22:21:40 GMT, Nir Sullam wrote:
>> >Is there any editor that colorizes the code (keywords, parenthesis, strigns
>> >, etc,.) ?
>> >
>> >I found a freeware editor SynEdit that allows for partial coloring but not
>> >enough, Also, Allegro CL doesn't do that - does it ?
>>
>> www.vim.org
>
>For old-times sake I fired up my copy of vim and it doesn't do any
>Lisp syntax highlighting nor does it seem to have any kind of Lisp
>mode support.
>
>Why did you recommend vim??
My copy of vim (5.3). Has reasonable syntax-highlighting for a lot of
languages. Let me see, there are 120 syntax files[1], lisp has cl-functions
that are called in brown, string litterals in purple, *vars* in green,
symbols and keywords in yukky-green, and comments in blue. The only
thing I miss is indenting.[0]
Hey. I just found it :-). You just have to so
:set autoindent
:set lisp
mark a region with C-v and press =
I use it to do quick fixes to files, most of the time I use Xemacs, but
as I can't seem to find the NT version of 21 yet, I'm using this.
I also likes that it starts pretty fast. Even on NT...
Groetjes, Peter
[0] Please note that my color vision isn't 100% correct.
[1] They are:
2html.vim ada.vim amiga.vim asm.vim asmh8300.vim asmselect.vim asn.vim atlas.vim
awk.vim basic.vim bib.vim c.vim clean.vim clipper.vim cobol.vim colortest.vim
cpp.vim
csh.vim css.vim cterm.vim dcl.vim diff.vim dosbatch.vim dosini.vim dracula.vim
dtd.vim eiffel.vim elmfilt.vim esqlc.vim expect.vim exports.vim fortran.vim
fvwm.vim gp.vim help.vim hitest.vim html.vim idl.vim inform.vim java.vim
javacc.vim
javascript.vim jgraph.vim lace.vim lex.vim lilo.vim lisp.vim lite.vim lotos.vim
lss.vim mail.vim make.vim man.vim maple.vim matlab.vim mf.vim mib.vim model.vim
modula2.vim mp.vim msql.vim muttrc.vim nasm.vim nosyntax.vim nroff.vim objc.vim
ocaml.vim pascal.vim pcap.vim perl.vim php3.vim phtml.vim pike.vim pmfile.vim
po.vim
pod.vim postscr.vim pov.vim procmail.vim prolog.vim purifylog.vim python.vim
rc.vim rexx.vim sather.vim scheme.vim scripts.vim sdl.vim sgml.vim sh.vim
sicad.vim simula.vim skill.vim slang.vim slrnrc.vim slrnsc.vim sm.vim spec.vim
sql.vim st.vim syntax.vim tags.vim tcl.vim tex.vim tf.vim tsalt.vim uil.vim
verilog.vim vgrindefs.vim vhdl.vim vim.vim viminfo.vim vrml.vim whitespace.vim
xdefaults.vim xmath.vim xml.vim xpm.vim yacc.vim zsh.vim
--
It's logic Jim, but not as we know it. | ········@debian.org for pleasure,
"God, root, what is difference?",Pitr | ········@inthan.be for more pleasure!
From: Christopher R. Barry
Subject: Re: CL syntax coloring editor ?
Date:
Message-ID: <87iua0j5iq.fsf@2xtreme.net>
········@mail.inthan.be (Peter Van Eynde) writes:
> My copy of vim (5.3). Has reasonable syntax-highlighting for a lot of
> languages. Let me see, there are 120 syntax files[1], lisp has cl-functions
> that are called in brown, string litterals in purple, *vars* in green,
> symbols and keywords in yukky-green, and comments in blue. The only
> thing I miss is indenting.[0]
>
> Hey. I just found it :-). You just have to so
> :set autoindent
> :set lisp
Not bad. Can't figure out paren-blinking though. Coloring doesn't work
with my copy either (works with C and sh scripts still).
Christopher
······@2xtreme.net (Christopher R. Barry) writes:
> ········@mail.inthan.be (Peter Van Eynde) writes:
>
...
> > symbols and keywords in yukky-green, and comments in blue. The only
> > thing I miss is indenting.[0]
> >
> > Hey. I just found it :-). You just have to so
> > :set autoindent
> > :set lisp
>
> Not bad. Can't figure out paren-blinking though. Coloring doesn't work
> with my copy either (works with C and sh scripts still).
>
Even in some older versions of vi (and, of course, vim), one finds
:set showmatch
for paren-matching.
Chris.
--
Chris Kirkwood-Watts
········@raytheon.com
On 11 May 1999 08:37:01 -0500, Chris Kirkwood-Watts wrote:
>Even in some older versions of vi (and, of course, vim), one finds
> :set showmatch
>for paren-matching.
That's only when you insert parens. I would like the other paren to be
indicated when I just pass over the other one. Like emacs'
show-paren-mode.
Groetjes, Peter
--
It's logic Jim, but not as we know it. | ········@debian.org for pleasure,
"God, root, what is difference?",Pitr | ········@inthan.be for more pleasure!
"Nir Sullam" <······@actcom.co.il> writes:
>
> Is there any editor that colorizes the code (keywords, parenthesis, strigns
> , etc,.) ?
Font lock mode in Emacs with do syntax coloring.
(Although you probably don't want to color the parentheses)
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu