I'm trying to print few lisp files for good bed time reading but the
result is grayscale when printing from LW or ACL editor. Tryong copy
pasting from the editor and it's text again.
How to print syntax colored version?
thanks
Slobodan
On Dec 2, 4:05 pm, Slobodan Blazeski <·················@gmail.com>
wrote:
> I'm trying to print few lisp files for good bed time reading but the
> result is grayscale when printing from LW or ACL editor. Tryong copy
> pasting from the editor and it's text again.
> How to print syntax colored version?
>
> thanks
> Slobodan
It would require some copy/pasting, but lispdoc has an htmlize
feature:
http://www.lispdoc.com/htmlize
//J
On Dec 2, 1:14 pm, Joshua Taylor <···········@gmail.com> wrote:
> On Dec 2, 4:05 pm, Slobodan Blazeski <·················@gmail.com>
> wrote:
>
> > I'm trying to print few lisp files for good bed time reading but the
> > result is grayscale when printing from LW or ACL editor. Tryong copy
> > pasting from the editor and it's text again.
> > How to print syntax colored version?
>
> > thanks
> > Slobodan
>
> It would require some copy/pasting, but lispdoc has an htmlize
> feature:
>
> http://www.lispdoc.com/htmlize
>
> //J
Thanks. I already found workaround by shamelessly misusing lisp paste
but wonder is any way to do it within lisp editor, any editor.
Slobodan
In article
<····································@f3g2000hsg.googlegroups.com>,
Slobodan Blazeski <·················@gmail.com> wrote:
> On Dec 2, 1:14 pm, Joshua Taylor <···········@gmail.com> wrote:
> > On Dec 2, 4:05 pm, Slobodan Blazeski <·················@gmail.com>
> > wrote:
> >
> > > I'm trying to print few lisp files for good bed time reading but the
> > > result is grayscale when printing from LW or ACL editor. Tryong copy
> > > pasting from the editor and it's text again.
> > > How to print syntax colored version?
> >
> > > thanks
> > > Slobodan
> >
> > It would require some copy/pasting, but lispdoc has an htmlize
> > feature:
> >
> > http://www.lispdoc.com/htmlize
> >
> > //J
>
> Thanks. I already found workaround by shamelessly misusing lisp paste
> but wonder is any way to do it within lisp editor, any editor.
>
> Slobodan
Send a feature request to LispWorks and Franz.
Makes sense to have a switch to print the source colored.
I just tried it in Aquamacs (a version of GNU Emacs) on my Mac.
It is able to print colored source text. Just created a PDF file.
Looks fine.
--
http://lispm.dyndns.org/
On Dec 2, 10:34 pm, Rainer Joswig <······@lisp.de> wrote:
> In article
> <····································@f3g2000hsg.googlegroups.com>,
> Slobodan Blazeski <·················@gmail.com> wrote:
>
>
>
> > On Dec 2, 1:14 pm, Joshua Taylor <···········@gmail.com> wrote:
> > > On Dec 2, 4:05 pm, Slobodan Blazeski <·················@gmail.com>
> > > wrote:
>
> > > > I'm trying to print few lisp files for good bed time reading but the
> > > > result is grayscale when printing from LW or ACL editor. Tryong copy
> > > > pasting from the editor and it's text again.
> > > > How to print syntax colored version?
>
> > > > thanks
> > > > Slobodan
>
> > > It would require some copy/pasting, but lispdoc has an htmlize
> > > feature:
>
> > >http://www.lispdoc.com/htmlize
>
> > > //J
>
> > Thanks. I already found workaround by shamelessly misusing lisp paste
> > but wonder is any way to do it within lisp editor, any editor.
>
> > Slobodan
>
> Send a feature request to LispWorks and Franz.
> Makes sense to have a switch to print the source colored.
It not that important, they should rather focus efforts in more
critical things, than on something witn priority - it would be nice to
have.
>
> I just tried it in Aquamacs (a version of GNU Emacs) on my Mac.
> It is able to print colored source text. Just created a PDF file.
> Looks fine.
I envy you. :)
cheers
Slobodan
>
> --http://lispm.dyndns.org/
In article
<····································@l1g2000hsa.googlegroups.com>,
Slobodan Blazeski <·················@gmail.com> wrote:
> On Dec 2, 10:34 pm, Rainer Joswig <······@lisp.de> wrote:
> > In article
> > <····································@f3g2000hsg.googlegroups.com>,
> > Slobodan Blazeski <·················@gmail.com> wrote:
> >
> >
> >
> > > On Dec 2, 1:14 pm, Joshua Taylor <···········@gmail.com> wrote:
> > > > On Dec 2, 4:05 pm, Slobodan Blazeski <·················@gmail.com>
> > > > wrote:
> >
> > > > > I'm trying to print few lisp files for good bed time reading but the
> > > > > result is grayscale when printing from LW or ACL editor. Tryong copy
> > > > > pasting from the editor and it's text again.
> > > > > How to print syntax colored version?
> >
> > > > > thanks
> > > > > Slobodan
> >
> > > > It would require some copy/pasting, but lispdoc has an htmlize
> > > > feature:
> >
> > > >http://www.lispdoc.com/htmlize
> >
> > > > //J
> >
> > > Thanks. I already found workaround by shamelessly misusing lisp paste
> > > but wonder is any way to do it within lisp editor, any editor.
> >
> > > Slobodan
> >
> > Send a feature request to LispWorks and Franz.
> > Makes sense to have a switch to print the source colored.
> It not that important, they should rather focus efforts in more
> critical things, than on something witn priority - it would be nice to
> have.
Oh, I find it quite important. The request makes perfect sense.
Reading code is one of the typical activities of software
developers. If source coloring helps (I think so) to make
source a bit more readable, then we should have color
also for the printed version.
> >
> > I just tried it in Aquamacs (a version of GNU Emacs) on my Mac.
> > It is able to print colored source text. Just created a PDF file.
> > Looks fine.
>
> I envy you. :)
;-)
>
> cheers
> Slobodan
> >
> > --http://lispm.dyndns.org/
--
http://lispm.dyndns.org/
Rainer Joswig <······@lisp.de> wrote:
+---------------
| Reading code is one of the typical activities of software
| developers. If source coloring helps (I think so) to make
| source a bit more readable, then we should have color
| also for the printed version.
+---------------
Though bear in mind that this a very personal preference
that is not at all universally shared. I, for one, find great
difficulty in reading "colorized" or "font-enhanced" source
code. It's terribly distracting and pulls my eyes away from
the important stuff. Similarly, "unset LS_COLORS" is the very
first thing I add to my "~/.bashrc" on any new Linux login I get.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
In article <································@speakeasy.net>,
····@rpw3.org (Rob Warnock) wrote:
> Rainer Joswig <······@lisp.de> wrote:
> +---------------
> | Reading code is one of the typical activities of software
> | developers. If source coloring helps (I think so) to make
> | source a bit more readable, then we should have color
> | also for the printed version.
> +---------------
>
> Though bear in mind that this a very personal preference
> that is not at all universally shared.
That's why I mentioned a 'switch' in my first post.
For Aquamacs (GNU Emacs) I would guess that it
prints in color when font-lock-mode is on.
Plus some people are color-blind and color-coding would
be a waste.
> I, for one, find great
> difficulty in reading "colorized" or "font-enhanced" source
> code. It's terribly distracting and pulls my eyes away from
> the important stuff. Similarly, "unset LS_COLORS" is the very
> first thing I add to my "~/.bashrc" on any new Linux login I get.
Really? Maybe it's the chosen colors? The visual system
might need some time to adapt and needs to get trained.
I have used some color-coded editors lately and for
Clozure CL went back to b&w, since it doesn't have
color coding yet. I feel sometimes a bit helpless, since
the visual clues (color) are not there. I'm not that
a fan of styled (bold, italic, underlined) code or
code in proportional fonts, but color I found useful.
On the Lisp Machine I have seen more the use of styled
code (color was not available on most consoles), but
unfortunately the styles were added to the files via
special codes and not computed on the fly. So one
ended up with text files with embedded style
information. Bad.
Code in an editor has the advantage that you can find
out the s-expressions by selecting them, using blinking
parentheses and similar tools. With printed code, this
is not possible. Color-coding can help to identify the
structure in printed - this static - text.
I was also thinking lately that a programming language
like Common Lisp might need some standard color table,
so that in publications, web pages, text editors, ... one
sees the same type of constructs (class, method, function,
macro, ...) with the same color.
I have also seen a tool where you get a visual overview of
a file by seeing a condensed version where for every
code line or definition a colored line is printed.
This gives a colored pattern of the file - different
files have different color-patterns (given that you
not just write functions in your file ;-) ). You
could immediately see if a file contains class definitions
and in what part of the file they are.
In some more GUI-advanced editors one might have a region left
to the text where some added information is displayed.
Apple's XCode does that for example. Information could be icons
for annotations, break points, and so on. I could think
that one had a colored line on the left, where the color
indicates what kind of construct the thing on the right is,
whether it is external (normal color) or internal (pale color).
I've also seen color shades used for indicating aging of
code lines of files in versioned code repositories. Lines that
have been added or changed lately would have some different
background shade.
But, I can easily see that not everyone likes it. Some
are just using vi plus a terminal. Strange. But true. ;-)
>
>
> -Rob
>
> -----
> Rob Warnock <····@rpw3.org>
> 627 26th Avenue <URL:http://rpw3.org/>
> San Mateo, CA 94403 (650)572-2607
--
http://lispm.dyndns.org/
On Dec 3, 1:35 pm, Rainer Joswig <······@lisp.de> wrote:
> In article <································@speakeasy.net>,
> ····@rpw3.org (Rob Warnock) wrote:
>
> > Rainer Joswig <······@lisp.de> wrote:
> > +---------------
> > | Reading code is one of the typical activities of software
> > | developers. If source coloring helps (I think so) to make
> > | source a bit more readable, then we should have color
> > | also for the printed version.
> > +---------------
>
> > Though bear in mind that this a very personal preference
> > that is not at all universally shared.
>
> That's why I mentioned a 'switch' in my first post.
> For Aquamacs (GNU Emacs) I would guess that it
> prints in color when font-lock-mode is on.
>
> Plus some people are color-blind and color-coding would
> be a waste.
>
> > I, for one, find great
> > difficulty in reading "colorized" or "font-enhanced" source
> > code. It's terribly distracting and pulls my eyes away from
> > the important stuff. Similarly, "unset LS_COLORS" is the very
> > first thing I add to my "~/.bashrc" on any new Linux login I get.
>
> Really? Maybe it's the chosen colors? The visual system
> might need some time to adapt and needs to get trained.
> I have used some color-coded editors lately and for
> Clozure CL went back to b&w, since it doesn't have
> color coding yet. I feel sometimes a bit helpless, since
> the visual clues (color) are not there. I'm not that
> a fan of styled (bold, italic, underlined) code or
> code in proportional fonts, but color I found useful.
> On the Lisp Machine I have seen more the use of styled
> code (color was not available on most consoles), but
> unfortunately the styles were added to the files via
> special codes and not computed on the fly. So one
> ended up with text files with embedded style
> information. Bad.
>
> Code in an editor has the advantage that you can find
> out the s-expressions by selecting them, using blinking
> parentheses and similar tools. With printed code, this
> is not possible. Color-coding can help to identify the
> structure in printed - this static - text.
>
> I was also thinking lately that a programming language
> like Common Lisp might need some standard color table,
> so that in publications, web pages, text editors, ... one
> sees the same type of constructs (class, method, function,
> macro, ...) with the same color.
I support standard color table 100%.
>
> I have also seen a tool where you get a visual overview of
> a file by seeing a condensed version where for every
> code line or definition a colored line is printed.
> This gives a colored pattern of the file - different
> files have different color-patterns (given that you
> not just write functions in your file ;-) ). You
> could immediately see if a file contains class definitions
> and in what part of the file they are.
>
> In some more GUI-advanced editors one might have a region left
> to the text where some added information is displayed.
> Apple's XCode does that for example. Information could be icons
> for annotations, break points, and so on. I could think
> that one had a colored line on the left, where the color
> indicates what kind of construct the thing on the right is,
> whether it is external (normal color) or internal (pale color).
>
> I've also seen color shades used for indicating aging of
> code lines of files in versioned code repositories. Lines that
> have been added or changed lately would have some different
> background shade.
>
> But, I can easily see that not everyone likes it. Some
> are just using vi plus a terminal. Strange. But true. ;-)
>
>
>
> > -Rob
>
> > -----
> > Rob Warnock <····@rpw3.org>
> > 627 26th Avenue <URL:http://rpw3.org/>
> > San Mateo, CA 94403 (650)572-2607
>
> --http://lispm.dyndns.org/
Den Mon, 03 Dec 2007 05:28:45 -0800 skrev Slobodan Blazeski:
>> I was also thinking lately that a programming language like Common Lisp
>> might need some standard color table, so that in publications, web
>> pages, text editors, ... one sees the same type of constructs (class,
>> method, function, macro, ...) with the same color.
> I support standard color table 100%.
I support truncating your quotes so I don't have to scroll 3 screens down
just to see your stupid AOL.
Besides, it'd work poorly. I for one have the standard (white) colour
scheme in my emacs, but very many people work with predominantly dark
colours. I used to too, actually, until I hit a bug that made tooltips
take 5s to appear once you define too many customised faces. So with the
standard table, you'd have to magically make it support environments that
are each other's opposite, or it'd be pointless.
Cheers,
Maciej
On Dec 3, 6:02 pm, Maciej Katafiasz <········@gmail.com> wrote:
> > I support standard color table 100%.
>
> I support truncating your quotes so I don't have to scroll 3 screens down
> just to see your stupid AOL.
Sorry about that. Google groups spoiled me so I forget that there are
people who use different setups to view c.l.l posts
>
> Besides, it'd work poorly. I for one have the standard (white) colour
> scheme in my emacs, but very many people work with predominantly dark
> colours. I used to too, actually, until I hit a bug that made tooltips
> take 5s to appear once you define too many customised faces. So with the
> standard table, you'd have to magically make it support environments that
> are each other's opposite, or it'd be pointless.
I don't see that what's the problem. With either black letters on a
white background or white letters on a black background, meaning of
the colored code like comments, user defined symbols etc will be the
same.
Beside you could never please everybody, those who don't want it will
just tweak per their liking, but standard must be establshed sometimes
or everybody will suffer.
I guess veterans have tehir favourite features from MAcLisp or
ZataLisp taht didn't make it in cltl. Or take the situation with FFI,
every lisp implementation has one but unless you really need some
specific feature in you lisp ffi, you should use cffi for your
libraries. The bottom line is that specific features of all lisp ffi
implementations got rarely used, and somebody have to spent time on
developing the bridge. And though cffi authors are doing great job
they would be doing great job elsewhere if ffi were standardized.
Users don't care what kind of features our language has, they only
want usefull applications.
Slobodan
Slobodan Blazeski schrieb:
Hallo
There is scite Editor out for win and lin. As I remember you can choose
your own color schemata for most languages. So, download and try.
But what about colors for the keywords in groups (system-symbols,
package-symbols...) or for debuging? Lets say you want all lines your
symbol apears in red color, or you can make all your methodes the same
color than your background so you will not see that and you can
consentrade on whatever.
Asume, you watch 3 sides of code and you can dynamicly see where the
interpreter works right now? Debuging, hm? fadeout=90
if you find errors, fill your bags.
Rainer Joswig wrote:
> In article <································@speakeasy.net>,
> ····@rpw3.org (Rob Warnock) wrote:
>
>> Rainer Joswig <······@lisp.de> wrote:
>> +---------------
>> | Reading code is one of the typical activities of software
>> | developers. If source coloring helps (I think so) to make
>> | source a bit more readable, then we should have color
>> | also for the printed version.
>> +---------------
>>
>> Though bear in mind that this a very personal preference
>> that is not at all universally shared.
>
> That's why I mentioned a 'switch' in my first post.
> For Aquamacs (GNU Emacs) I would guess that it
> prints in color when font-lock-mode is on.
>
> Plus some people are color-blind and color-coding would
> be a waste.
>
>> I, for one, find great
>> difficulty in reading "colorized" or "font-enhanced" source
>> code. It's terribly distracting and pulls my eyes away from
>> the important stuff. Similarly, "unset LS_COLORS" is the very
>> first thing I add to my "~/.bashrc" on any new Linux login I get.
>
> Really? Maybe it's the chosen colors?
That's what I was thinking, too. A good code-coloring
system let you pick what colors to use for each type
of code. And you might decide to pick the same color
more more than one type.
The visual system
> might need some time to adapt and needs to get trained.
> I have used some color-coded editors lately and for
> Clozure CL went back to b&w, since it doesn't have
> color coding yet. I feel sometimes a bit helpless, since
> the visual clues (color) are not there. I'm not that
> a fan of styled (bold, italic, underlined) code or
> code in proportional fonts, but color I found useful.
> On the Lisp Machine I have seen more the use of styled
> code (color was not available on most consoles)
It was the Olden Days when color displays cost a
great deal. Yes, there was such a time. :)
, but
> unfortunately the styles were added to the files via
> special codes and not computed on the fly. So one
> ended up with text files with embedded style
> information. Bad.
>
> Code in an editor has the advantage that you can find
> out the s-expressions by selecting them, using blinking
> parentheses and similar tools. With printed code, this
> is not possible. Color-coding can help to identify the
> structure in printed - this static - text.
The blinking parens were one of the first features
that I added to the Lisp machine's Emacs that had
not been in the original Emacs, because the hardware
that the original Emacs ran on, old-style computer
terminals, couldn't do that. Later on RMS put in
the thing that moves your cursor back temporarily,
but that always confused me; I'd see the cursor
back there and try to move it and then it would
jump back, etc. But some people like it.
>
> I was also thinking lately that a programming language
> like Common Lisp might need some standard color table,
> so that in publications, web pages, text editors, ... one
> sees the same type of constructs (class, method, function,
> macro, ...) with the same color.
>
> I have also seen a tool where you get a visual overview of
> a file by seeing a condensed version where for every
> code line or definition a colored line is printed.
> This gives a colored pattern of the file - different
> files have different color-patterns (given that you
> not just write functions in your file ;-) ). You
> could immediately see if a file contains class definitions
> and in what part of the file they are.
>
> In some more GUI-advanced editors one might have a region left
> to the text where some added information is displayed.
> Apple's XCode does that for example. Information could be icons
> for annotations, break points, and so on. I could think
> that one had a colored line on the left, where the color
> indicates what kind of construct the thing on the right is,
> whether it is external (normal color) or internal (pale color).
>
> I've also seen color shades used for indicating aging of
> code lines of files in versioned code repositories. Lines that
> have been added or changed lately would have some different
> background shade.
In the Subversion user interface that we use (Trac, I think
it's called?) they use color very nicely when displaying
diffs between versions.
>
> But, I can easily see that not everyone likes it. Some
> are just using vi plus a terminal. Strange. But true. ;-)
And as you point out, there always has to be some other
way to convey the information. Some very large fraction
of males (did I read 10% once?) have some degree of
red-green color blindness.
>
>>
>> -Rob
>>
>> -----
>> Rob Warnock <····@rpw3.org>
>> 627 26th Avenue <URL:http://rpw3.org/>
>> San Mateo, CA 94403 (650)572-2607
>
Daniel Weinreb <···@alum.mit.edu> writes:
>> That's why I mentioned a 'switch' in my first post.
>> For Aquamacs (GNU Emacs) I would guess that it
>> prints in color when font-lock-mode is on.
>>
>> Plus some people are color-blind and color-coding would
>> be a waste.
>>
>>> I, for one, find great
>>> difficulty in reading "colorized" or "font-enhanced" source
>>> code. It's terribly distracting and pulls my eyes away from
>>> the important stuff. Similarly, "unset LS_COLORS" is the very
>>> first thing I add to my "~/.bashrc" on any new Linux login I get.
>>
>> Really? Maybe it's the chosen colors?
>
> That's what I was thinking, too. A good code-coloring
> system let you pick what colors to use for each type
> of code. And you might decide to pick the same color
> more more than one type.
Yuck! Down that path lies madness, I say. I'm with Rob here. No colour
with my 'ls'.
>> Code in an editor has the advantage that you can find
>> out the s-expressions by selecting them, using blinking
>> parentheses and similar tools. With printed code, this
>> is not possible. Color-coding can help to identify the
>> structure in printed - this static - text.
>
> The blinking parens were one of the first features
> that I added to the Lisp machine's Emacs that had
> not been in the original Emacs, because the hardware
> that the original Emacs ran on, old-style computer
> terminals, couldn't do that. Later on RMS put in
> the thing that moves your cursor back temporarily,
> but that always confused me; I'd see the cursor
> back there and try to move it and then it would
> jump back, etc. But some people like it.
Just to prove that customization is the key; The only of those features
that I think helps is the one where the matching parenthesis is shown in
inverse video. Make sure the user can choose! :-)
/andreas
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?