First draft of the Emacs website

First draft of the Emacs website

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 362 bytes --]

Hi guys,

I think I'm ready to show my work on the website of Emacs:

http://nicolas-petton.fr/ressources/emacs-website/

A few notes:

- It's a work in progress
- I only worked on the homepage
- It's not yet responsive
- Many links don't work yet
- I haven't changed much the content of the website itself, it's mostly
  design

Feedback welcome!

Cheers,
Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: First draft of the Emacs website

[Jean-Christophe Helary]

Very nice !

Regarding the original contents and *not* your design :) I was wondering about 3 things:
- the sub-title is weird, can't it be guessed that emacs lisp is a dialect of lisp ? Does "with extensions to support text editing" means that without extensions text editing is not supported?
- the "highly customizable" feature seems to put the GUI and emacs lisp at the same level
- the emphasis on the shortcut for the packaging system (it this indication really necessary?)

Of course, it is a different topic so sorry for the hijacking...

Jean-Christophe 

> On Nov 29, 2015, at 08:29, Nicolas Petton <nicolas@petton.fr> wrote:
> 
> Hi guys,
> 
> I think I'm ready to show my work on the website of Emacs:
> 
> http://nicolas-petton.fr/ressources/emacs-website/

Re: First draft of the Emacs website

[Daniel Pimentel]

Congratulation!

Design is very beautiful.

-- 
Daniel Pimentel (d4n1 3:)

Re: First draft of the Emacs website

[Xue Fuqiao]

On Sun, Nov 29, 2015 at 7:29 AM, Nicolas Petton <nicolas@petton.fr> wrote:
> Hi guys,
>
> I think I'm ready to show my work on the website of Emacs:
>
> http://nicolas-petton.fr/ressources/emacs-website/

Nice work!  I've always thought that the logo of Emacs should be on the
website, and now we have it!

A few comments:

* IMHO the color for the "Download for" links is too dark.  #B67FD6
  looks better to me.

* Why do you put <span> and <a> in `<ul class="links">'?  The content
  model for element `ul' is: "Zero or more li and script-supporting
  elements."[1]

* We don't provide OS X binaries currently.  What would the "MacOS X"
  link link to?

* The "Take the Emacs tour" link is gone.  But I think it's a pretty
  good tour/overview of GNU Emacs.  Do you have plan to rewrite/update it?

* It would be good to add an `alt' attribute for the FSF logo, like the
  original website :-)

[1] http://www.w3.org/html/wg/drafts/html/master/single-page.html#the-ul-element

Re: First draft of the Emacs website

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 1045 bytes --]

Xue Fuqiao <xfq.free@gmail.com> writes:


> Nice work!  I've always thought that the logo of Emacs should be on the
> website, and now we have it!

Thanks!

> A few comments:
>
> * IMHO the color for the "Download for" links is too dark.  #B67FD6
>   looks better to me.

That's strange, but I can give it a try.  Could you send me a screenshot?

> * Why do you put <span> and <a> in `<ul class="links">'?  The content
>   model for element `ul' is: "Zero or more li and script-supporting
>   elements."[1]

It's a mistake, I'll fix it.

>
> * We don't provide OS X binaries currently.  What would the "MacOS X"
>   link link to?

Good question :-) (we do need to fix it, OS X is too popular to be ignored).

> * The "Take the Emacs tour" link is gone.  But I think it's a pretty
>   good tour/overview of GNU Emacs.  Do you have plan to rewrite/update
>   it?

Yes, It's definitely planned.

> * It would be good to add an `alt' attribute for the FSF logo, like the
>   original website :-)

Oops, will fix it.

Thanks for your feedback!

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: First draft of the Emacs website

[Alex Dunn]

Is Aquamacs still popular?  The Emacs subreddit links to
http://emacsformacosx.com, which I had never heard of before.  Homebrew
also provides a decent experience on OS X, though I’m biased since I’m a
maintainer.

Nicolas Petton <nicolas@petton.fr> writes:

> Xue Fuqiao <xfq.free@gmail.com> writes:
>
>> * We don't provide OS X binaries currently.  What would the "MacOS X"
>>   link link to?
>
> Good question :-) (we do need to fix it, OS X is too popular to be ignored).

Re: First draft of the Emacs website

[Jean-Christophe Helary]

> On Nov 29, 2015, at 11:19, Alex Dunn <dunn.alex@gmail.com> wrote:
> 
> 
> Is Aquamacs still popular?  The Emacs subreddit links to
> http://emacsformacosx.com, which I had never heard of before.  Homebrew
> also provides a decent experience on OS X, though I’m biased since I’m a
> maintainer.

Aquamacs is popular but it seems to me that linking to homebrew would be closer to the expectations of Emacs users on OSX.

Jean-Christophe Helary

Re: First draft of the Emacs website

[Random832]

Jean-Christophe Helary <jean.christophe.helary@gmail.com> writes:
>> On Nov 29, 2015, at 11:19, Alex Dunn <dunn.alex@gmail.com> wrote:
>> Is Aquamacs still popular?  The Emacs subreddit links to
>> http://emacsformacosx.com, which I had never heard of before.  Homebrew
>> also provides a decent experience on OS X, though I’m biased since I’m a
>> maintainer.
>
> Aquamacs is popular but it seems to me that linking to homebrew would
> be closer to the expectations of Emacs users on OSX.
>
> Jean-Christophe Helary

The advantage [to the extent that it is an advantage] of the version at
emacsformacosx.com is that it is a self-contained binary distribution
not requiring one to open a terminal and paste magic shell scripts, but
a more or less standard build (vs Aquamacs which is a fairly extensive
patch set).

One disadvantage (well, technically I haven't examined whether any of
the others do anything about this) is that it doesn't do anything to
ensure that "emacs" from the terminal won't run the ancient bundled
Emacs (still 22, I think the last time this came up the theory was that
Apple balked at the GPLv3).

It might be best to have the OSX button to go to a landing page that
outlines all of these options. An off-site link with no explanation
isn't going to inspire confidence at any rate; even if there's no
discussion of options a landing page with "OSX builds are not provided
directly by the FSF, but Emacs is available through [link]Homebrew[/]"
would be a better transition.

Re: First draft of the Emacs website

[David Caldwell]

[-- Attachment #1: Type: text/plain, Size: 2619 bytes --]

On 11/28/15 9:42 PM, Random832 wrote:
> The advantage [to the extent that it is an advantage] of the version at
> emacsformacosx.com is that it is a self-contained binary distribution
> not requiring one to open a terminal and paste magic shell scripts, but
> a more or less standard build (vs Aquamacs which is a fairly extensive
> patch set).
> 
> One disadvantage (well, technically I haven't examined whether any of
> the others do anything about this) is that it doesn't do anything to
> ensure that "emacs" from the terminal won't run the ancient bundled
> Emacs (still 22, I think the last time this came up the theory was that
> Apple balked at the GPLv3).
> 
> It might be best to have the OSX button to go to a landing page that
> outlines all of these options. An off-site link with no explanation
> isn't going to inspire confidence at any rate; even if there's no
> discussion of options a landing page with "OSX builds are not provided
> directly by the FSF, but Emacs is available through [link]Homebrew[/]"
> would be a better transition.

For what it's worth, I run emacsformacosx.com. Your points are spot on.
I'll also mention that Homebrew also currently has the advantage of
being able to link with librsvg, imagemagick, and gnutls—it's on my list
of things to do to figure out how to bundle the dependencies up in
Emacs.app so distribution works seamlessly.

Emacs on OS X is always a little weird, because I tend to see Emacs
users as mostly command-line centric, but Mac users as a whole
definitely are not. When you look at the other Mac editors out there
that people really like, they are all GUI based. SublimeText, TextMate,
Atom, Xcode are the ones I think of.

Homebrew fits with the command line centric view of the world. I love it
and use it for almost all classic unix software I install, but there are
definitely Mac Emacs users out there that do not use it.

I think emacsformacosx.com is popular[1] because it fits with the
thinking of Mac folks (just download a .dmg and drag-to-install) while
still being plain old Emacs.

At any rate, if the FSF wants official Emacs binaries for Mac OS X, I'm
willing to help out. I've been making and distributing them for 15 years
(since the Mac OS X 10.0 Beta) and I'll most likely keep doing it until
I stop using Emacs or my Mac.

-David


[1] It averages about 1000 downloads per day, with odd spikes of about
3x the average. These happen around releases, but also randomly though
the year–I suspect due to links from various blogs that end up on
Twitter or Hacker News or Reddit.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4239 bytes --]

Re: First draft of the Emacs website

[Dmitry Gutov]

On 11/29/2015 10:15 AM, David Caldwell wrote:
> When you look at the other Mac editors out there
> that people really like, they are all GUI based. SublimeText, TextMate,
> Atom, Xcode are the ones I think of.

There's also Vim. It's rather popular in the Ruby hipster community.

Emacs for Mac OS X bundle (was: First draft of the Emacs website)

[John Wiegley]

>>>>> David Caldwell <david@porkrind.org> writes:

> For what it's worth, I run emacsformacosx.com.

Thank you so much for the service you've been providing, David! It really
helps Mac users who want to acquire a modern GNU Emacs in a familiar way.

How hard do you think it would be to get Emacs on the App Store? Would the
sandboxing kill us?

John

Re: Emacs for Mac OS X bundle

[David Caldwell]

[-- Attachment #1: Type: text/plain, Size: 1480 bytes --]

On 11/30/15 9:49 AM, John Wiegley wrote:
>>>>>> David Caldwell <david@porkrind.org> writes:
> 
>> For what it's worth, I run emacsformacosx.com.
> 
> Thank you so much for the service you've been providing, David! It really
> helps Mac users who want to acquire a modern GNU Emacs in a familiar way.

Thanks for the kind words.

> How hard do you think it would be to get Emacs on the App Store? Would the
> sandboxing kill us?

There's potentially a lot to sandboxing, but I don't think it is
insurmountable.

The main/most obvious issue is making find-file work inside the sandbox.
I've actually thought about this a little. I think it could be done with
the addition of a small bit of code that runs once after install. I got
the idea from the "Vox" app (which I believe is free on the store if
you'd like to try it). They open a little window into which you are
instructed to drag your hard disk from Finder. This gives them access to
the whole disk and they go off searching for music. In Emacs's case it
would hold on to that opaque token and use it as the root directory for
all filesystem related things.

Also, from my reading of it a couple years ago, the Mac App Store
licensing appears compatible with the GPL, unlike the iOS App Store. But
of course IANAL, etc.

There are probably some more sandboxed APIs that I haven't thought about
(like networking). Probably the best way is to just go for it and see
what happens.

-David



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4239 bytes --]

Re: Emacs for Mac OS X bundle

[Xue Fuqiao]

On Tue, Dec 1, 2015 at 4:02 AM, David Caldwell <david@porkrind.org> wrote:

> Also, from my reading of it a couple years ago, the Mac App Store
> licensing appears compatible with the GPL, unlike the iOS App Store. But
> of course IANAL, etc.

Wikipedia[1] says that free software licensed only under the GPL is
disallowed in Mac App Store.

[1] https://en.wikipedia.org/wiki/Mac_App_Store#Regulations

Re: Emacs for Mac OS X bundle

[David Caldwell]

[-- Attachment #1: Type: text/plain, Size: 1132 bytes --]

On 11/30/15 4:15 PM, Xue Fuqiao wrote:
> On Tue, Dec 1, 2015 at 4:02 AM, David Caldwell <david@porkrind.org> wrote:
> 
>> Also, from my reading of it a couple years ago, the Mac App Store
>> licensing appears compatible with the GPL, unlike the iOS App Store. But
>> of course IANAL, etc.
> 
> Wikipedia[1] says that free software licensed only under the GPL is
> disallowed in Mac App Store.
> 
> [1] https://en.wikipedia.org/wiki/Mac_App_Store#Regulations

One of the sited articles looks to be discussing "the iTunes App Store"
which (AFAIK) is what we now call the iOS App Store (which has
completely different licensing than the Mac App Store).

The other article is from 2011. I believe I read the license in detail
in the 2013-ish time frame, so it may have changed since the Adium folks
looked into it. I wouldn't trust me but I wouldn't immediately pooh-pooh
the idea either. Let's at least have someone knowledgeable look into the
current licensing before we decide it's a no-go.

It's too bad they don't have a source code repo for the license
somewhere so we can look at the diffs.

-David



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4239 bytes --]

Re: First draft of the Emacs website

[Xue Fuqiao]

[-- Attachment #1: Type: text/plain, Size: 396 bytes --]

On Sun, Nov 29, 2015 at 9:26 AM, Nicolas Petton <nicolas@petton.fr> wrote:

Hi Nicolas,

>> * IMHO the color for the "Download for" links is too dark.  #B67FD6
>>   looks better to me.
>
> That's strange, but I can give it a try.  Could you send me a screenshot?

OK.  I've attached the screenshots of the original color and my
suggestion.  IMHO the original one is too dark and a little hidden.

[-- Attachment #2: 9041BD.png --]
[-- Type: image/png, Size: 125562 bytes --]

[-- Attachment #3: B67FD6.png --]
[-- Type: image/png, Size: 120377 bytes --]

Re: First draft of the Emacs website

[Przemysław Wojnowski]

To me it looks great! I'm not an artist, but I like the colors.

One thing I would change is the screenshot at the top - the current one
is simple like Notepad. IMHO it would be good if it would show more
reach/appealing content. Is GIF an option? If so, it would be possible
to show some action, like tricks from http://emacsrocks.com, but on
code.

Cheers,
Przemysław

Re: First draft of the Emacs website

[Zack Piper]

On Sun, Nov 29, 2015 at 09:06:42AM +0100, Przemysław Wojnowski wrote:
> 
> To me it looks great! I'm not an artist, but I like the colors.
> 
> One thing I would change is the screenshot at the top - the current one
> is simple like Notepad. IMHO it would be good if it would show more
> reach/appealing content. Is GIF an option? If so, it would be possible
> to show some action, like tricks from http://emacsrocks.com, but on
> code.

Perhaps a "Before and after configuration" comparison might be good.

-- 
Zack Piper <zack@apertron.net> http://apertron.net

Re: First draft of the Emacs website

[Rasmus]

Zack Piper <zack@apertron.net> writes:

> On Sun, Nov 29, 2015 at 09:06:42AM +0100, Przemysław Wojnowski wrote:
>> 
>> To me it looks great! I'm not an artist, but I like the colors.
>
>> 
>> One thing I would change is the screenshot at the top - the current one
>> is simple like Notepad. IMHO it would be good if it would show more
>> reach/appealing content. Is GIF an option? If so, it would be possible
>> to show some action, like tricks from http://emacsrocks.com, but on
>> code.
>
> Perhaps a "Before and after configuration" comparison might be good.

What do you have in mind?  Except for the toolbar and the menu bar my
Emacs looks pretty much like the screenshot "after configuration"...

It would be nice to have a "carousel" of "screenshots" (or htmlized
buffers?) displaying e.g. a lisp-mode, C-buffer, Python-mode together with
Python REPL, an Org buffer, message-mode etc.  Or perhaps a section of the
website dedicated to some examples of Emacs modes, like the "Applications
using Guile" on http://gnu.org/software/guile/.

Nicolas:

First, thanks for the effort.

When I put the browser in half width (so 960 px) the download buttons flow
into the text and the page generally doesn’t work out.  But probably you
are already aware and it re the "not responsive yet".

I don’t think the sand color used for the release notes works as well as
the other colors.  The charcoal and the purple are very pleasant.

Rasmus

-- 
This is the kind of tedious nonsense up with which I will not put

Re: First draft of the Emacs website

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 562 bytes --]

Rasmus <rasmus@gmx.us> writes:

> First, thanks for the effort.
>
> When I put the browser in half width (so 960 px) the download buttons flow
> into the text and the page generally doesn’t work out.  But probably you
> are already aware and it re the "not responsive yet".

Exactly, I will work on that next.

> I don’t think the sand color used for the release notes works as well as
> the other colors.

Hmmm, I obviously like it, but I'll see if I can darken it a bit.

> The charcoal and the purple are very pleasant.

Thanks.

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: First draft of the Emacs website

[Marcin Borkowski]

On 2015-11-29, at 13:36, Rasmus <rasmus@gmx.us> wrote:

> It would be nice to have a "carousel" of "screenshots" (or htmlized
> buffers?) displaying e.g. a lisp-mode, C-buffer, Python-mode together with
> Python REPL, an Org buffer, message-mode etc.  Or perhaps a section of the
> website dedicated to some examples of Emacs modes, like the "Applications
> using Guile" on http://gnu.org/software/guile/.

What about something like p. 51 of this pdf:
http://mbork.pl/download/Slides_about_LaTeX_editing.pdf ?

> Nicolas:

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: First draft of the Emacs website

[David Engster]

Nicolas Petton writes:
> Hi guys,
>
> I think I'm ready to show my work on the website of Emacs:
>
> http://nicolas-petton.fr/ressources/emacs-website/

Nice. Most importantly, it displays pretty well with eww. :-)

But please don't use Google Webfonts.

-David

Re: First draft of the Emacs website

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 265 bytes --]

David Engster <deng@randomsample.de> writes:

> Nice. Most importantly, it displays pretty well with eww. :-)

Good, I try to use decent HTML markup :)

> But please don't use Google Webfonts.

I'm actually not using them, I'll remove the line from the head.

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: First draft of the Emacs website

[Dmitry Gutov]

Hi Nicolas,

On 11/29/2015 01:29 AM, Nicolas Petton wrote:

> I think I'm ready to show my work on the website of Emacs:
>
> http://nicolas-petton.fr/ressources/emacs-website/

Thank you for your efforts.

I think the current look is already better that the homepage we have 
now, but nevertheless, I think it exemplifies one of my pet peeves in UI 
design: using different contrast levels in different parts of a web page 
(or an application).

Every part, by itself, looks very nice (*): I like the colors chosen for 
every section, and the dashed look of the download buttons makes a good 
impression if I just narrow my attention to that part of the web page.

But if we look at the first page, the "GNU Emacs" logo, and the 
screenshot, are much brighter than the rest of the section. Which makes 
the download buttons fade into background. That might complicate life 
for vision-impaired visitors, for instance.

The rest of the sections are clear, but as I scroll down the page, my 
eyes have to adjust to a different level of contrast as I look at each 
new section.

I usually shy away from dark themes (and dark designs in general), 
because most websites and applications use light-background themes, but 
I think a design should at least be consistent internally, and pick just 
one side.

Just my opinion.

Cheers,
Dmitry.

(*) Regarding the "Releases" color set, I think it's good, and I'd 
rather you did something to the second section: it jumps out as very 
high-contrast, for some reason.

Re: First draft of the Emacs website

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 1019 bytes --]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Thank you for your efforts.

You're welcome!

> I think the current look is already better that the homepage we have 
> now, but nevertheless, I think it exemplifies one of my pet peeves in UI 
> design: using different contrast levels in different parts of a web page 
> (or an application).

I understand what you mean, but disagree with you.  Each section has on
purpose its own set of primary and secondary colors, going from a dark
grey with the Emacs colors (slightly warmer set of colors), down to the
red of the FSF.

> (*) Regarding the "Releases" color set, I think it's good

Thank you, I will see about making the "Releases" section darker though,
and see if and how I can adjust the secondary colors of this section.

> , and I'd rather you did something to the second section: it jumps out
> as very high-contrast, for some reason.

I can try to lower the contrast of the background gradient a bit, but I 
won't do it too much.

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: First draft of the Emacs website

[Dmitry Gutov]

On 11/29/2015 09:38 PM, Nicolas Petton wrote:

> I understand what you mean, but disagree with you.  Each section has on
> purpose its own set of primary and secondary colors, going from a dark
> grey with the Emacs colors (slightly warmer set of colors), down to the
> red of the FSF.

I'm not saying that the set of colors is arbitrary.

>> , and I'd rather you did something to the second section: it jumps out
>> as very high-contrast, for some reason.
>
> I can try to lower the contrast of the background gradient a bit, but I
> won't do it too much.

Gradient? The background looks solid to me.

I think you can just darken the text color a bit (e.g. to #ddd), and 
it'll help the situation.

Re: First draft of the Emacs website

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 330 bytes --]

Dmitry Gutov <dgutov@yandex.ru> writes:

> I'm not saying that the set of colors is arbitrary.

Ok :-)

> Gradient? The background looks solid to me.

Well, it is a gradient :).

> I think you can just darken the text color a bit (e.g. to #ddd), and 
> it'll help the situation.

Thanks, it's indeed better.

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: First draft of the Emacs website

[Christopher Allan Webber]

Nicolas Petton writes:

> Hi guys,
>
> I think I'm ready to show my work on the website of Emacs:
>
> http://nicolas-petton.fr/ressources/emacs-website/
>
> A few notes:
>
> - It's a work in progress
> - I only worked on the homepage
> - It's not yet responsive
> - Many links don't work yet
> - I haven't changed much the content of the website itself, it's mostly
>   design
>
> Feedback welcome!
>
> Cheers,
> Nico

Holy FRELL that looks nice!

I can't wait to see this implemented! :)

Re: First draft of the Emacs website

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 107 bytes --]

Christopher Allan Webber <cwebber@dustycloud.org> writes:

> Holy FRELL that looks nice!

Thank you!

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: First draft of the Emacs website

[Artur Malabarba]

Nicolas Petton <nicolas@petton.fr> writes:

> Hi guys,
>
> I think I'm ready to show my work on the website of Emacs:
>
> http://nicolas-petton.fr/ressources/emacs-website/

Hi Nico. Big thanks for your work on this.

> A few notes:
> - I haven't changed much the content of the website itself, it's mostly
>   design

Are you taking suggestions on content changes?

> Feedback welcome!

1. The “Download for” buttons are a little hidden. I'd give them a light
background and dark foreground, so they'd really look like buttons.

2. Everything is a little too spaced apart IMO. My laptop has a 17 inch
monitor and neither of the first two sections fit in one screen for me.
Can we make it more compact?

3. I'm also not a big fan of the way each section has it's own color
palette (although each individual palette is very pretty). I've been
seeing this style in a lot of websites lately, but I always find it
distracting.

4. The links on the “Features” section are very hard to identify. Took
me a while to realise they were links.

> Cheers,
> Nico

Cheers 

Re: First draft of the Emacs website

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 1274 bytes --]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

> Hi Nico. Big thanks for your work on this.

You're welcome :)

> Are you taking suggestions on content changes?

Not at this point (well, you can send your suggestions anyway, I'll keep
them for later).

> 1. The “Download for” buttons are a little hidden. I'd give them a light
> background and dark foreground, so they'd really look like buttons.

Ok, I'll try to make them more visible.

> 2. Everything is a little too spaced apart IMO. My laptop has a 17 inch
> monitor and neither of the first two sections fit in one screen for me.
> Can we make it more compact?

I'll give it a try, for the first 2 sections but space is an important
part of this design.

> 3. I'm also not a big fan of the way each section has it's own color
> palette (although each individual palette is very pretty). I've been
> seeing this style in a lot of websites lately, but I always find it
> distracting.

Well, can we just agree to disagree here?  :)

> 4. The links on the “Features” section are very hard to identify. Took
> me a while to realise they were links.

You are right, I'll improve that.

>
>> Cheers,
>> Nico
>
> Cheers 

-- 
Nicolas Petton
http://nicolas-petton.fr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: First draft of the Emacs website

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 846 bytes --]

On 29 Nov 2015 10:11 pm, "Nicolas Petton" <nicolas@petton.fr> wrote:
> > 1. The “Download for” buttons are a little hidden. I'd give them a light
> > background and dark foreground, so they'd really look like buttons.
>
> Ok, I'll try to make them more visible.

You can probably find a better solution than my suggestion. 😁
I just meant we can afford to make those buttons stand out more.

> > 3. I'm also not a big fan of the way each section has it's own color
> > palette (although each individual palette is very pretty). I've been
> > seeing this style in a lot of websites lately, but I always find it
> > distracting.
>
> Well, can we just agree to disagree here?  :)

Sure. You're doing a great job so your judgement should definitely take
precedence over mine, and it's up to you how to weigh other's opinions.

[-- Attachment #2: Type: text/html, Size: 1087 bytes --]

Re: First draft of the Emacs website

[Alex Dunn]

The light colors of the “Releases” section is a tad jarring after the
three dark panels; but maybe that could be used to draw attention to the
“Downloading” panel, which is currently pretty muted.

Or is the “Releases” section more important, since most people looking
for downloads will use the buttons at the top of the page?

Artur Malabarba <bruce.connor.am@gmail.com> writes:

> On 29 Nov 2015 10:11 pm, "Nicolas Petton" <nicolas@petton.fr> wrote:
>> > 1. The “Download for” buttons are a little hidden. I'd give them a light
>> > background and dark foreground, so they'd really look like buttons.
>>
>> Ok, I'll try to make them more visible.
>
> You can probably find a better solution than my suggestion. 😁
> I just meant we can afford to make those buttons stand out more.
>
>> > 3. I'm also not a big fan of the way each section has it's own color
>> > palette (although each individual palette is very pretty). I've been
>> > seeing this style in a lot of websites lately, but I always find it
>> > distracting.
>>
>> Well, can we just agree to disagree here?  :)
>
> Sure. You're doing a great job so your judgement should definitely take
> precedence over mine, and it's up to you how to weigh other's opinions.

Re: First draft of the Emacs website

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 300 bytes --]

On 30 Nov 2015 1:29 am, "Alex Dunn" <dunn.alex@gmail.com> wrote:
>
>
> The light colors of the “Releases” section is a tad jarring after the
> three dark panels;

Oh yes, I forgot to mention. This bright background right after dark
backgrounds hurts my pretty little eyes (at night). :-)

[-- Attachment #2: Type: text/html, Size: 423 bytes --]

Re: First draft of the Emacs website

[Dani Moncayo]

>> The light colors of the “Releases” section is a tad jarring after the
>> three dark panels;
>
> Oh yes, I forgot to mention. This bright background right after dark
> backgrounds hurts my pretty little eyes (at night). :-)

FWIW: I'd prefer a "light theme", that is, dark text over light
background.  This is the look of the rest of my desktop, so my eyes
are used to it.

(I'd say this is the case for many users too.)

-- 
Dani Moncayo

RE: First draft of the Emacs website

[Drew Adams]

> FWIW: I'd prefer a "light theme", that is, dark text over light
> background.  This is the look of the rest of my desktop, so my eyes
> are used to it.
> 
> (I'd say this is the case for many users too.)

+1

Re: First draft of the Emacs website

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 175 bytes --]

Hi guys,

I updated the website based on (some of) your feedback.  I also added
initial support for mobile devices.

nicolas-petton.fr/ressources/emacs-website/

Cheers,
Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: First draft of the Emacs website

[Yuri Khan]

On Mon, Nov 30, 2015 at 10:06 PM, Nicolas Petton <nicolas@petton.fr> wrote:

> I updated the website based on (some of) your feedback.  I also added
> initial support for mobile devices.

What about not breaking support for desktops? Particularly, the
focused button or hyperlink should be visually distinct from other
buttons or hyperlinks.

> nicolas-petton.fr/ressources/emacs-website/

Re: First draft of the Emacs website

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 211 bytes --]

Yuri Khan <yuri.v.khan@gmail.com> writes:

> What about not breaking support for desktops? Particularly, the
> focused button or hyperlink should be visually distinct from other
> buttons or hyperlinks.

Fixed.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: First draft of the Emacs website

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Could you make sure the site works well in lynx on a Linux console?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: First draft of the Emacs website

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 144 bytes --]

Richard Stallman <rms@gnu.org> writes:

> Could you make sure the site works well in lynx on a Linux console?

Yes, it's planned already.

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: First draft of the Emacs website

[Milan Zamazal]

Thank you for your effort!

When designing the pages (and not only you and only these ones!), please
don't forget about our handicapped fellows and try to comply with Web
Accessibility Guidelines (see e.g. http://www.w3.org/WAI/intro/wcag.php
for start).

Quickly looking at the present state, there are probably some problems
with contrast and maybe with fonts.  (Rule of thumb if nothing else: If
something is not very easy to read for a perfectly sighted person then
it's probably hard to read or unreadable for visually impaired visitors,
dyslectics or other handicapped people.)  It's also very good to skim
through the page with a screen reader, if you have the opportunity, to
discover possible problems for the blind visitors.

RE: First draft of the Emacs website

[Drew Adams]

> Thank you for your effort!
> 
> When designing the pages (and not only you and only these ones!), please
> don't forget about our handicapped fellows and try to comply with Web
> Accessibility Guidelines (see e.g. http://www.w3.org/WAI/intro/wcag.php
> for start).
> 
> Quickly looking at the present state, there are probably some problems
> with contrast and maybe with fonts.  (Rule of thumb if nothing else: If
> something is not very easy to read for a perfectly sighted person then
> it's probably hard to read or unreadable for visually impaired visitors,
> dyslectics or other handicapped people.)  It's also very good to skim
> through the page with a screen reader, if you have the opportunity, to
> discover possible problems for the blind visitors.

FWIW, this is the most helpful feedback about the website, I think.
And here is a one-page overview: http://www.w3.org/WAI/WCAG20/glance/.

Trying to improve accessibility will likely automatically address
some of the other suggestions/concerns that people have raised.
Most of the things that make for an accessible site also make
sense in terms of general UI sanity and ease of use.

RE: First draft of the Emacs website

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 212 bytes --]

Drew Adams <drew.adams@oracle.com> writes:


> FWIW, this is the most helpful feedback about the website, I think.
> And here is a one-page overview: http://www.w3.org/WAI/WCAG20/glance/.

Thanks, I agree.

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: First draft of the Emacs website

[Random832]

On 2015-11-28, Nicolas Petton <nicolas@petton.fr> wrote:
> http://nicolas-petton.fr/ressources/emacs-website/

I did a test of disabling CSS and Javascript to see how well it degrades
(also tested in lynx), and noticed the following artifacts:

- Caused by non-hidden "nav-mobile" section:
  - Two copies of the Emacs logo and page heading
  - Unsightly "nav-toggle" button element.
- As a decorative image, the Emacs logo and screenshot should have a
  blank alt text. Saying "Emacs" and "Screenshot" doesn't provide any
  accessibility benefit, though maybe the screenshot could instead have
  a longer description.
- "Learn More" link appears inline directly after the screenshot, and is
  useless without javascript.
- Suggestions for better semantic markup:
  - Use an unordered list element instead of a sequence of inline links
    for the navigation and the download link list.
  - Use kbd rather than code elements for M-x instructions.
  - FSF logo alt text should be Free Software Foundation.
- FSF logo is completely invisible on a white background.
- "Verbatim" copying permission statement is non-free.

Re: First draft of the Emacs website

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 1158 bytes --]

Random832 <random832@fastmail.com> writes:

> On 2015-11-28, Nicolas Petton <nicolas@petton.fr> wrote:
>> http://nicolas-petton.fr/ressources/emacs-website/
>
> I did a test of disabling CSS and Javascript to see how well it degrades
> (also tested in lynx), and noticed the following artifacts:
>
> - Caused by non-hidden "nav-mobile" section:
>   - Two copies of the Emacs logo and page heading
>   - Unsightly "nav-toggle" button element.

Thank you, I noticed it already, and will fix this.

> - As a decorative image, the Emacs logo and screenshot should have a
>   blank alt text. Saying "Emacs" and "Screenshot" doesn't provide any
>   accessibility benefit, though maybe the screenshot could instead have
>   a longer description.
> - "Learn More" link appears inline directly after the screenshot, and is
>   useless without javascript.

I'll add an href, thanks!

>   - FSF logo alt text should be Free Software Foundation.
> - FSF logo is completely invisible on a white background.

I'll change it to a light grey.

> - "Verbatim" copying permission statement is non-free.

This is on the current website as well.

Thanks for your feedback!
Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: First draft of the Emacs website

[Yuri Khan]

On Wed, Dec 2, 2015 at 11:12 PM, Nicolas Petton <nicolas@petton.fr> wrote:

>> - FSF logo is completely invisible on a white background.
>
> I'll change it to a light grey.

Then it will be completely invisible on a light grey background.

There are two reliable ways of ensuring visibility:

* fill the whole background; or
* add an outline at least 2px thick, of a color which gives good
contrast with the foreground color.

Re: First draft of the Emacs website

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 198 bytes --]

Yuri Khan <yuri.v.khan@gmail.com> writes:

> There are two reliable ways of ensuring visibility:
>
> * fill the whole background; or

The background is filled, or did you mean something else?

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: First draft of the Emacs website

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 140 bytes --]

Yuri Khan <yuri.v.khan@gmail.com> writes:

> * fill the whole background; or

You meant the background of the png file itself, right?

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: First draft of the Emacs website

[Yuri Khan]

On Thu, Dec 3, 2015 at 12:29 AM, Nicolas Petton <nicolas@petton.fr> wrote:

>> * fill the whole background; or
>
> You meant the background of the png file itself, right?

Of course. That’s the only thing that you can control when the user
turns off or overrides your CSS.

Re: First draft of the Emacs website

[Xue Fuqiao]

On Thu, Dec 3, 2015 at 12:36 AM, Random832 <random832@fastmail.com> wrote:

> - "Verbatim" copying permission statement is non-free.

The standard copyright terms for GNU web pages is now the Creative
Commons Attribution-NoDerivs 3.0 United States License.[1] It used to be
(and for a few pages still is): "Verbatim copying and distribution of
this entire article are permitted worldwide, without royalty, in any
medium, provided this notice is preserved."

[1] https://creativecommons.org/licenses/by-nd/3.0/us/

Re: First draft of the Emacs website

[Random832]

On 2015-12-02, Xue Fuqiao <xfq.free@gmail.com> wrote:
> On Thu, Dec 3, 2015 at 12:36 AM, Random832 <random832@fastmail.com> wrote:
>> - "Verbatim" copying permission statement is non-free.
>
> The standard copyright terms for GNU web pages is now the Creative
> Commons Attribution-NoDerivs 3.0 United States License.

That's also non-free. Why not the GFDL, or CC-BY-SA?

http://www.gnu.org/licenses/license-list.en.html specifically recommends
against this license. It's not clear why website text (or layout, etc)
is so different from documentation as to require different principles.

License of the Emacs website (was: Re: First draft of the Emacs website)

[Chad Brown]

Subject changed.

> On 03 Dec 2015, at 19:57, Random832 <random832@fastmail.com> wrote:
> 
> On 2015-12-02, Xue Fuqiao <xfq.free@gmail.com> wrote:
>> On Thu, Dec 3, 2015 at 12:36 AM, Random832 <random832@fastmail.com> wrote:
>>> - "Verbatim" copying permission statement is non-free.
>> 
>> The standard copyright terms for GNU web pages is now the Creative
>> Commons Attribution-NoDerivs 3.0 United States License.
> 
> That's also non-free. Why not the GFDL, or CC-BY-SA?
> 
> http://www.gnu.org/licenses/license-list.en.html specifically recommends
> against this license. It's not clear why website text (or layout, etc)
> is so different from documentation as to require different principles.

That’s interesting, because
http://www.gnu.org/licenses/licenses.en.html says:

    The standard copyright terms for GNU web pages is now the Creative
    Commons Attribution-NoDerivs 3.0 United States License.

The web page you site also includes this:

    Works that express someone's opinion—memoirs, editorials, and
    so on—serve a fundamentally different purpose than works for
    practical use like software and documentation. Because of
    this, we expect them to provide recipients with a different
    set of permissions: just the permission to copy and
    distribute the work verbatim. Richard Stallman discusses this
    frequently in his speeches.

    Because so many licenses meet these criteria, we cannot list them all.
    If you are looking for one to use yourself, however, there are two
    that we recommend:

    * GNU Verbatim Copying License (#GNUVerbatim) This was the license used
      throughout the GNU web site for many years. It is very simple, and
      especially well-suited to written works.

    * Creative Commons Attribution-NoDerivs 3.0 license (a.k.a. CC BY-ND)
      (#ccbynd) This is the license used throughout the GNU and FSF web
      sites. This license provides much the same permissions as our verbatim
      copying license, but it's much more detailed. We particularly
      recommend it for audio and/or video works of opinion. Please be
      specific about which Creative Commons license is being used.

This seems like a discussion for someplace other than the emacs-devel
list, so I tried (perhaps crudely?) to redirect it to emacs-tangents.

Thanks,
~Chad

Re: First draft of the Emacs website

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Pages whose purpose is educational should carry free licenses.
Pages that state our point of view, our message, should carry
licenses that do not permit modification.

  > http://www.gnu.org/licenses/license-list.en.html specifically recommends
  > against this license.

That's in the section on licenses for documentation.  I will clarify
the text there to make it clear the non-recommendation is about
documentation only.  Thanks for showing me this could be
misunderstood.

  >  It's not clear why website text (or layout, etc)
  > is so different from documentation as to require different principles.

Some of the pages might be documentation -- if so, they should
be under a free license.  We should use the GFDL for compatibility
with the Emacs manuals.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: First draft of the Emacs website

[Clément Pit--Claudel]

[-- Attachment #1: Type: text/plain, Size: 570 bytes --]

Hi Nicolas,

The new website looks wonderful; I love it :) Thanks for your work!

Clément.

On 11/29/2015 12:29 AM, Nicolas Petton wrote:
> Hi guys,
> 
> I think I'm ready to show my work on the website of Emacs:
> 
> http://nicolas-petton.fr/ressources/emacs-website/
> 
> A few notes:
> 
> - It's a work in progress
> - I only worked on the homepage
> - It's not yet responsive
> - Many links don't work yet
> - I haven't changed much the content of the website itself, it's mostly
>   design
> 
> Feedback welcome!
> 
> Cheers,
> Nico
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: First draft of the Emacs website

[John Yates]

[-- Attachment #1: Type: text/plain, Size: 2573 bytes --]

Who is your primary audience?  There is no point preaching to your choir.
 (Here your choir consists of you yourself, Emacs users and Lisp fans.)

I would argue that the site should be focused on persuading those who know
little or nothing about Emacs to give it a try.  Such a person is likely to
be someone who has been weened on a combination of GUI and command-line
tools.  (My assumption is that anyone who does not already have some
exposure to the command-line is a lost cause, but I would be happy to be
corrected.)

Do not pitch as virtues aspects that a newbie most likely will perceive as
a barrier to entry:
* Hence any mention of Lisp seems inappropriate.  We had better hope that
Emacs' Out-Of-Box impression is good enough to motivate - in time - an
interest in Lisp, rather than presume it.  Even more off-putting are the
fine points of various Lisp dialects and Lisp extensions.
* Displaying Lisp code is probably not a great "come-on".
* The parenthetical "M-x list-packages" makes sense only to someone already
familiar with Emacs.

Do not pitch as virtues packages that actually compare poorly to the
competition:
* Notably Emacs' support for gdb pales before most IDEs.
* Newbies likely have a long, long road to travel before they will ever
consider discarding their current GUI / WYSIWYG / web-based productivity
tools for Emacs' text-only calendar, mail project planning packages.

Style:
* Generally brevity is a virtue.  The text below the circular icons tends
to be wordy.  It feels like you are trying to persuade me by overwhelming
me via "featuritis".
* Excessive use of 'including'.
* "Content-sensitive editing modes, including syntax coloring, for a
variety of file types including plain text, source code, and HTML."
(Awkward and - with two use of 'including' - hard to parse. What is a
'mode' to a newbie?)
* "Complete built-in documentation, including a tutorial for new users."
 (Those are two separate items.)
* "Full Unicode support for nearly all human languages and their scripts."
(Language support is a bit of a stretch.  The distinction between language
and script is unnecessarily technical.  I would mention support for editing
of bi-directional text and support for additional encodings beyond Unicode
(e.g. DOS code pages, ISO-8859-*, etc).)
* "Highly customizable, using Emacs Lisp code or a graphical interface."
 (A casual reader might take that as claiming we have a configuration GUI.
Customize is really little more than a text-based forms package.  It is
better than nothing but I would avoid over-selling it.)

/john

[-- Attachment #2: Type: text/html, Size: 2944 bytes --]

Re: First draft of the Emacs website

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 776 bytes --]

John Yates <john@yates-sheets.org> writes:

> Do not pitch as virtues aspects that a newbie most likely will perceive as
> a barrier to entry:
> * Hence any mention of Lisp seems inappropriate.  We had better hope that
> Emacs' Out-Of-Box impression is good enough to motivate - in time - an
> interest in Lisp, rather than presume it.  Even more off-putting are the
> fine points of various Lisp dialects and Lisp extensions.
> * Displaying Lisp code is probably not a great "come-on".
> * The parenthetical "M-x list-packages" makes sense only to someone already
> familiar with Emacs.

[...]

Thanks John.  I focused for now on re-designing the current website,
without touching its contents, but I will do it in a second step and
your feedback is definitely useful!

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

RE: First draft of the Emacs website

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]

FWIW -

 

(My assumption is that anyone who does not already have some exposure to the command-line is a lost cause, but I would be happy to be corrected.)

 

I disagree. You do not need to be familiar with using a CLI to use Emacs. (I use M-x grep, and that's about it, these days.)

 

* Hence any mention of Lisp seems inappropriate.  We had better hope that Emacs' Out-Of-Box impression is good enough to motivate - in time - an interest in Lisp, rather than presume it.  Even more off-putting are the fine points of various Lisp dialects and Lisp extensions.

 

Not presuming "an interest in Lisp" is not the same as forbidding "any mention of Lisp". And I disagree that any mention of Lisp is inappropriate. 

 

I agree that no mention need be made of different Lisps or dive into specific aspects of Lisp. 

 

But it can be mentioned that you have available a powerful, easy-to-use (yes), very high-level programming language to extend and interact with Emacs. And yes, this is end-user stuff. (IMHO)

 

* Displaying Lisp code is probably not a great "come-on".

 

Simple Lisp code need not be a giant turn-off either, and need not be verboten in this context.

[-- Attachment #2: Type: text/html, Size: 4811 bytes --]

Re: First draft of the Emacs website

[John Yates]

[-- Attachment #1: Type: text/plain, Size: 1821 bytes --]

Drew,

You and I are old "grey beards".  My point was that mentioning things that
we - as seasoned users of Emacs - like is quite a bit different from
imagining the website as a sales pitch to someone who has not used Emacs
but _might_ - given an appropriate message - be coaxed into trying it.  If
you accept such messaging as the site's first goal then you have to try to
put yourself in the mindset of such a viewer.

Your comments suggest that perhaps you do not buy into that being the first
goal.

/john

On Thu, Dec 3, 2015 at 5:57 PM, Drew Adams <drew.adams@oracle.com> wrote:

> FWIW -
>
>
>
> (My assumption is that anyone who does not already have some exposure to
> the command-line is a lost cause, but I would be happy to be corrected.)
>
>
>
> I disagree. You do not need to be familiar with using a CLI to use Emacs.
> (I use M-x grep, and that's about it, these days.)
>
>
>
> * Hence any mention of Lisp seems inappropriate.  We had better hope that
> Emacs' Out-Of-Box impression is good enough to motivate - in time - an
> interest in Lisp, rather than presume it.  Even more off-putting are the
> fine points of various Lisp dialects and Lisp extensions.
>
>
>
> Not presuming "*an interest in Lisp*" is not the same as forbidding "*any
> mention of Lisp*". And I disagree that any mention of Lisp is
> inappropriate.
>
>
>
> I agree that no mention need be made of different Lisps or dive into
> specific aspects of Lisp.
>
>
>
> But it can be mentioned that you have available a powerful, easy-to-use
> (yes), very high-level programming language to extend and interact with
> Emacs. And yes, this is end-user stuff. (IMHO)
>
>
>
> * Displaying Lisp code is probably not a great "come-on".
>
>
>
> Simple Lisp code need not be a giant turn-off either, and need not be
> verboten in this context.
>

[-- Attachment #2: Type: text/html, Size: 4562 bytes --]

RE: First draft of the Emacs website

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 3414 bytes --]

John,

 

My comments might have suggested that to you, but I don't think they suggest that.

 

I too think the site should address itself to, among others, and in particular, new users and young new users.

 

I disagree that mention of Lisp need be offputting to such people. On the contrary, I think that we can point to the advantages of Emacs being a Lisp environment and being user-extensible by way of Lisp (among other advantages).

 

We can agree to disagree about that. But I, no less than you, I think, have new users and young users in mind. 

 

Just because I have a grey beard, that does not mean that my suggestions are not aimed at those without grey beards and those (with or without beard, and regardless of color) who might be new users.

 

If I were a 13-year old, and I knew little or nothing about Lisp or Emacs, I would be interested to hear something about Emacs being bathed in Lisp and being, in fact, a Lisp environment, and that I (yes, as only a newbie Emacs user) could use some simple Lisp to extend and customize Emacs to fit my 13-year-old self. 

 

That would be something that attracted me, as one 13 year-old, not something that put me off. All newbies, and all 13 year-olds, are not the same.

 

It has to be presented carefully, of course. There should be no impression that one has to know Lisp to use Emacs. That doesn't mean that we can't mention Lisp as one of the BIG advantages that Emacs has to offer. Not to mention that would be, well, burying the lead - the main story. IMHO.

 

Drew,

 

You and I are old "grey beards".  My point was that mentioning things that we - as seasoned users of Emacs - like is quite a bit different from imagining the website as a sales pitch to someone who has not used Emacs but _might_ - given an appropriate message - be coaxed into trying it.  If you accept such messaging as the site's first goal then you have to try to put yourself in the mindset of such a viewer.

 

Your comments suggest that perhaps you do not buy into that being the first goal.

 

/john

 

On Thu, Dec 3, 2015 at 5:57 PM, Drew Adams <HYPERLINK "mailto:drew.adams@oracle.com" \ndrew.adams@oracle.com> wrote:

FWIW -

(My assumption is that anyone who does not already have some exposure to the command-line is a lost cause, but I would be happy to be corrected.)

I disagree. You do not need to be familiar with using a CLI to use Emacs. (I use M-x grep, and that's about it, these days.)

* Hence any mention of Lisp seems inappropriate.  We had better hope that Emacs' Out-Of-Box impression is good enough to motivate - in time - an interest in Lisp, rather than presume it.  Even more off-putting are the fine points of various Lisp dialects and Lisp extensions.

Not presuming "an interest in Lisp" is not the same as forbidding "any mention of Lisp". And I disagree that any mention of Lisp is inappropriate. 

I agree that no mention need be made of different Lisps or dive into specific aspects of Lisp. 

But it can be mentioned that you have available a powerful, easy-to-use (yes), very high-level programming language to extend and interact with Emacs. And yes, this is end-user stuff. (IMHO)

* Displaying Lisp code is probably not a great "come-on".

Simple Lisp code need not be a giant turn-off either, and need not be verboten in this context.

[-- Attachment #2: Type: text/html, Size: 9995 bytes --]

Re: First draft of the Emacs website

[Valentijn]

[-- Attachment #1: Type: text/plain, Size: 3226 bytes --]

On 03/12 16:58, Drew Adams wrote: 
> John,
> My comments might have suggested that to you, but I don't think they suggest that.
>
> I too think the site should address itself to, among others, and in particular, new users and young new users.
>
> I disagree that mention of Lisp need be offputting to such people. On the contrary, I think that we can point to the advantages of Emacs being a Lisp environment and being user-extensible by way of Lisp (among other advantages).
>
> We can agree to disagree about that. But I, no less than you, I think, have new users and young users in mind. 
> Just because I have a grey beard, that does not mean that my suggestions are not aimed at those without grey beards and those (with or without beard, and regardless of color) who might be new users.
>
> If I were a 13-year old, and I knew little or nothing about Lisp or Emacs, I would be interested to hear something about Emacs being bathed in Lisp and being, in fact, a Lisp environment, and that I (yes, as only a newbie Emacs user) could use some simple Lisp to extend and customize Emacs to fit my 13-year-old self. 
> That would be something that attracted me, as one 13 year-old, not something that put me off. All newbies, and all 13 year-olds, are not the same.
> It has to be presented carefully, of course. There should be no impression that one has to know Lisp to use Emacs. That doesn't mean that we can't mention Lisp as one of the BIG advantages that Emacs has to offer. Not to mention that would be, well, burying the lead - the main story. IMHO.
> Drew,

Drew,

I'm might be able, as a seventeen year old (since two days!), to a somewhat interesting perspective on this. Some background information which might be useful:  I'm a GNU/Linux user for the past two/threeish years, emacs user since a year, a ex-vim user and tend to use the commandline a lot.

You're on the right track with the lisp thing and it's a very important thing to talk about but you're forgetting that the word Lisp doesn't really mean anything to people as young as me. I mostly know it as the thing that powers in Emacs and the old AI labs. What Lisp was to you is what Python is for us (at least I assume). Putting the emphasis on Emacs having a full porgramming language which just happens to be Lisp is, in my opinion, a better idea.

One of the biggest, if not the biggest, things that made me interested in Emacs was the ease of customization and the high amount of plugins available. One of the biggest thing that annoyed me with vim is how slow it would get if you tried to install any plugin on it. It would take a minute to start up. 

Another thing are the great tools that Emacs has. Things like org-mode, eshell/ansi-term, gnus, etc... are one of the things we really should be spending more time on promoting. Recently I at least got one of my friends to try Emacs simply because he liked org-mode so much. Somewhat related is the fact that Emacs is such a powertool also helps. It really does feel like you can do anything and more with it.

Thank you for your time,

Valentijn

-- 
BOFH excuse #122:

because Bill Gates is a Jehovah's witness and so nothing can work on St. Swithin's day.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

RE: First draft of the Emacs website

[Drew Adams]

> > If I were a 13-year old, and I knew little or nothing about Lisp or
> > Emacs, I would be interested to hear something about Emacs being
> > bathed in Lisp and being, in fact, a Lisp environment, and that I
> > (yes, as only a newbie Emacs user) could use some simple Lisp to
> > extend and customize Emacs to fit my 13-year-old self.  That would
> > be something that attracted me, as one 13 year-old, not something
> > that put me off. All newbies, and all 13 year-olds, are not the same.
> >
> > It has to be presented carefully, of course. There should be no
> > impression that one has to know Lisp to use Emacs. That doesn't mean
> > that we can't mention Lisp as one of the BIG advantages that Emacs
> > has to offer. Not to mention that would be, well, burying the lead -
> > the main story. IMHO.
> 
> Drew,
> 
> I'm might be able, as a seventeen year old (since two days!), to a
> somewhat interesting perspective on this. Some background information
> which might be useful:  I'm a GNU/Linux user for the past two/threeish
> years, emacs user since a year, a ex-vim user and tend to use the
> commandline a lot.
> 
> You're on the right track with the lisp thing and it's a very important
> thing to talk about but you're forgetting that the word Lisp doesn't
> really mean anything to people as young as me. I mostly know it as the
> thing that powers in Emacs and the old AI labs. What Lisp was to you is
> what Python is for us (at least I assume). Putting the emphasis on Emacs
> having a full porgramming language which just happens to be Lisp is, in my
> opinion, a better idea.
> 
> One of the biggest, if not the biggest, things that made me interested in
> Emacs was the ease of customization and the high amount of plugins
> available. One of the biggest thing that annoyed me with vim is how slow
> it would get if you tried to install any plugin on it. It would take a
> minute to start up.
> 
> Another thing are the great tools that Emacs has. Things like org-mode,
> eshell/ansi-term, gnus, etc... are one of the things we really should be
> spending more time on promoting. Recently I at least got one of my friends
> to try Emacs simply because he liked org-mode so much. Somewhat related is
> the fact that Emacs is such a powertool also helps. It really does feel
> like you can do anything and more with it.
> 
> Thank you for your time,
> 
> Valentijn

That all sounds good to me!  I think we agree on what's important
wrt the language environment for this editor, and wrt whether that
is something to point out to newbies, old and new alike.

At the end of the day, we do need to refer to the language by its
name, I think, but we could stress that it is a "Python-like"
language, to connect with what people might be more familiar with.
Concentrate on its features rather than its name: Why someone
should want to know that it is part of Emacs, even at the outset.
What it brings to Emacs and its users.

Point out that the extensive ability to customize Emacs, as well as
the plethora of available "plug-ins", are thanks to its Python-like
extension language (Lisp).

Re: First draft of the Emacs website

[Spencer Boucher]

[-- Attachment #1: Type: text/plain, Size: 0 bytes --]



[-- Attachment #2.1: Type: text/plain, Size: 776 bytes --]


> At the end of the day, we do need to refer to the language by its
> name, I think, but we could stress that it is a "Python-like"
> language, to connect with what people might be more familiar with.

Calling elisp "python-like" might be a bit of a stretch :)

> Concentrate on its features rather than its name: Why someone
> should want to know that it is part of Emacs, even at the outset.
> What it brings to Emacs and its users.

Exactly. The fact that elisp is not Python is a GOOD thing. Even though I love Python and use it in my work (it was also my first real programming language), I wouldn't WANT it to be the language behind my editor. We should emphasize the things about lisp that make it the best choice for powering an editor (macros, homoiconicity, etc.).

[-- Attachment #2.2.1: Type: text/html, Size: 885 bytes --]

[-- Attachment #3.1: Type: text/html, Size: 2224 bytes --]

Re: First draft of the Emacs website

[David Kastrup]

Spencer Boucher <spencer@spencerboucher.com> writes:

> <#multipart type=alternative><#part type=text/plain>
>
>
>> At the end of the day, we do need to refer to the language by its
>> name, I think, but we could stress that it is a "Python-like"
>> language, to connect with what people might be more familiar with.
>
>
> Calling elisp "python-like" might be a bit of a stretch :)

adjust-parens is an installed package.

     Status: Installed in ‘adjust-parens-3.0/’ (unsigned). Delete
    Version: 3.0
    Summary: Indent and dedent Lisp code, automatically adjust close parens
   Homepage: http://elpa.gnu.org/packages/adjust-parens.html
Other versions: 3.0 (gnu).

This package provides commands for indenting and dedenting Lisp
code such that close parentheses and brackets are automatically
adjusted to be consistent with the new level of indentation.

When reading Lisp, the programmer pays attention to open parens and
the close parens on the same line. But when a sexp spans more than
one line, she deduces the close paren from indentation alone. Given
that's how we read Lisp, this package aims to enable editing Lisp
similarly: automatically adjust the close parens programmers ignore
when reading. A result of this is an editing experience somewhat
like python-mode, which also offers "indent" and "dedent" commands.
There are differences because lisp-mode knows more due to existing
parens.

To use:
  (require 'adjust-parens)
  (add-hook 'emacs-lisp-mode-hook #'adjust-parens-mode)
  (add-hook 'clojure-mode-hook #'adjust-parens-mode)
  ;; etc

This binds two keys in Lisp Mode:
  (local-set-key (kbd "TAB") 'lisp-indent-adjust-parens)
  (local-set-key (kbd "<backtab>") 'lisp-dedent-adjust-parens)

lisp-indent-adjust-parens potentially calls indent-for-tab-command
(the usual binding for TAB in Lisp Mode). Thus it should not
interfere with other TAB features like completion-at-point.

Some examples follow. | indicates the position of point.

  (let ((x 10) (y (some-func 20))))
  |

After one TAB:

  (let ((x 10) (y (some-func 20)))
    |)

After three more TAB:

  (let ((x 10) (y (some-func 20
                             |))))

After two Shift-TAB to dedent:

  (let ((x 10) (y (some-func 20))
        |))

When dedenting, the sexp may have sibling sexps on lines below. It
makes little sense for those sexps to stay at the same indentation,
because they cannot keep the same parent sexp without being moved
completely. Thus they are dedented too. An example of this:

  (defun func ()
    (save-excursion
      (other-func-1)
      |(other-func-2)
      (other-func-3)))

After Shift-TAB:

  (defun func ()
    (save-excursion
      (other-func-1))
    |(other-func-2)
    (other-func-3))

If you indent again with TAB, the sexps siblings aren't indented:

  (defun func ()
    (save-excursion
      (other-func-1)
      |(other-func-2))
    (other-func-3))

Thus TAB and Shift-TAB are not exact inverse operations of each
other, though they often seem to be.

[back]

-- 
David Kastrup

Re: First draft of the Emacs website

[Marcin Borkowski]

On 2015-12-08, at 16:21, Spencer Boucher <spencer@spencerboucher.com> wrote:

>> At the end of the day, we do need to refer to the language by its
>> name, I think, but we could stress that it is a "Python-like"
>> language, to connect with what people might be more familiar with.
>
> Calling elisp "python-like" might be a bit of a stretch :)

Well, as Peter Norvig put it, "Basically, Python can be seen as
a dialect of Lisp with «traditional» syntax" (see
http://norvig.com/python-lisp.html).

I think Drew meant something along the lines "a stable, dynamically
typed language with a bunch of built-in datatypes, a rich library, an
(optional) object system and integrated tools like a bytecode compiler,
interactive debugger, a docstring conformance checker etc."

Regards,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

RE: First draft of the Emacs website

[Drew Adams]

> I think Drew meant something along the lines "a stable, dynamically
> typed language with a bunch of built-in datatypes, a rich library, an
> (optional) object system and integrated tools like a bytecode compiler,
> interactive debugger, a docstring conformance checker etc."

Sort of.  Yes, concentrate on the _features_ that Lisp has to
offer, not on the name.  (We might not agree on which features
are most important, but that's what discussion is for.)

And point out _how_ these features are important to Emacs -
(1) as a text editor and (2) as everything else that Emacs is,
from a multi-language programming environment to a calendar,
email client, personal organizer, whatever.

The point is not to describe Lisp features.  It is to
describe Lisp features that particularly benefit Emacs,
and to point out how so.  "Why mention Lisp?" is really
the same question here as "Why is Lisp helpful to Emacs?"

Without giving an idea of _how_ Lisp features help, a
feature list is not so useful.  A different supporting
language could still let you define your own commands,
and bind keys, and customize faces or whatever.  But the
high-level, functional nature of Lisp lets you do those
things more easily than some languages might.

We don't want to set Lisp up against other languages.
We do want to get across what it offers that benefits
an editor and environment such as Emacs.

And we can mention _Emacs_ "oddities" that (IMHO)
contribute to Lisp's usefulness for Emacs, including:

. Abundant hooks, which you can use to can tie in your
  own code at expected places, to extend behavior.

. An advice system that more generally lets you reuse
  code, adapting it to your needs.

. Dynamic binding (in addition to lexical), which lets
  you reuse and adapt code just by dynamically binding
  variables to different values.

IOW, from the outset, Emacs intends for you to modify its
behavior.  This is perhaps the main thing that sets Emacs
apart.  And it takes this very seriously.  On purpose,
almost nothing in Emacs behavior is carved in stone.

Lisp is in large part what gives Emacs its power and makes
it more than a mere text editor, even one that is highly
customizable.  Features of the language are behind this:
code as data, flexible ability to define macros, recursive
functions (including higher-order), and whatever else we
decide is important to point out.

We haven't necessarily thought much about _how Lisp
contributes_ to what makes Emacs Emacs, but it might be
good to do so now.  Even a noisy argument about what is
important, and why, could be useful in deciding what to
tell people about what makes Emacs special.

Personally, I would _not_ insist upon the stability of the
language, the presence of an object system, the extensive
integrated tools, or even the rich library.  Aside from the
object system, those are expected of a mature language and
are not particular to Lisp.  (Maybe mention the object system
but, so far, it is not used much, AFAIK, especially by users.) 

We need not focus on the name "Lisp"; it is the features
that count.  But neither should we shy away from mentioning
"Lisp", IMO.

RE: First draft of the Emacs website

[Drew Adams]

After I sent the last reply it occurred to me that it might be
useful to take a look at some of the things that RMS has written
about the development of Emacs in conjunction with Lisp.

A quick google pointed to this article.  I know there are others
as well; this just happened to be the second Google hit for
"richard stallman emacs".  It is mostly history, but there is
some info here about the relation between Emacs and Lisp features.

http://www.gnu.org/gnu/rms-lisp.en.html

And of course there is this, about the importance of dynamic
binding to Emacs:

https://www.gnu.org/software/emacs/emacs-paper.html#SEC17

Re: First draft of the Emacs website

[Marcin Borkowski]

On 2015-12-08, at 22:51, Drew Adams <drew.adams@oracle.com> wrote:

>> I think Drew meant something along the lines "a stable, dynamically
>> typed language with a bunch of built-in datatypes, a rich library, an
>> (optional) object system and integrated tools like a bytecode compiler,
>> interactive debugger, a docstring conformance checker etc."
>
> Sort of.  Yes, concentrate on the _features_ that Lisp has to
> offer, not on the name.  (We might not agree on which features
> are most important, but that's what discussion is for.)

Yes.

> And point out _how_ these features are important to Emacs -
> (1) as a text editor and (2) as everything else that Emacs is,
> from a multi-language programming environment to a calendar,
> email client, personal organizer, whatever.
>
> The point is not to describe Lisp features.  It is to
> describe Lisp features that particularly benefit Emacs,
> and to point out how so.  "Why mention Lisp?" is really
> the same question here as "Why is Lisp helpful to Emacs?"
>
> Without giving an idea of _how_ Lisp features help, a
> feature list is not so useful.  A different supporting
> language could still let you define your own commands,
> and bind keys, and customize faces or whatever.  But the
> high-level, functional nature of Lisp lets you do those
> things more easily than some languages might.
>
> We don't want to set Lisp up against other languages.
> We do want to get across what it offers that benefits
> an editor and environment such as Emacs.
>
> And we can mention _Emacs_ "oddities" that (IMHO)
> contribute to Lisp's usefulness for Emacs, including:
>
> . Abundant hooks, which you can use to can tie in your
>   own code at expected places, to extend behavior.
>
> . An advice system that more generally lets you reuse
>   code, adapting it to your needs.
>
> . Dynamic binding (in addition to lexical), which lets
>   you reuse and adapt code just by dynamically binding
>   variables to different values.
>
> IOW, from the outset, Emacs intends for you to modify its
> behavior.  This is perhaps the main thing that sets Emacs
> apart.  And it takes this very seriously.  On purpose,
> almost nothing in Emacs behavior is carved in stone.

This is especially important.  Maybe it might even be a good idea to
tell people that Emacs is a "framework" (whatever that means) to write
custom text editors, which happen to contain two very good default
editors as a template and an example;-).

> Lisp is in large part what gives Emacs its power and makes
> it more than a mere text editor, even one that is highly
> customizable.  Features of the language are behind this:
> code as data, flexible ability to define macros, recursive
> functions (including higher-order), and whatever else we
> decide is important to point out.
>
> We haven't necessarily thought much about _how Lisp
> contributes_ to what makes Emacs Emacs, but it might be
> good to do so now.  Even a noisy argument about what is
> important, and why, could be useful in deciding what to
> tell people about what makes Emacs special.

Hear, hear!

> Personally, I would _not_ insist upon the stability of the
> language, the presence of an object system, the extensive
> integrated tools, or even the rich library.  Aside from the
> object system, those are expected of a mature language and
> are not particular to Lisp.  (Maybe mention the object system
> but, so far, it is not used much, AFAIK, especially by users.) 

I'm not sure whether I agree.  You're right that those are expected of
a mature language; the point is, that Emacs "extension language" _is_
mature (IOW, it is not a "toy language").

OTOH, many editors nowadays allow scripting in Python or JS, which are
very mature languages, too.  So maybe I'm wrong after all.

And when I think of it, I guess that it _might_ be a good idea to stress
that there is no such thing as an Emacs "plugin".  In other tools,
plugins are sometimes a second-category citizen, while in Emacs, the
user's code has access to the same things as Emacs native code.  IOW,
Emacs is a very primitive (in terms of usability as a text editor) core,
and 90% (or more) of functionality is a huge pile of "plugins", i.e.,
functions, which can be advised, redefined - all this on the fly.

Of course, my wording here is not very good, I'd have to think about it
a lot more, but you get the idea.

> We need not focus on the name "Lisp"; it is the features
> that count.  But neither should we shy away from mentioning
> "Lisp", IMO.

Yes.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: First draft of the Emacs website

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > We don't want to set Lisp up against other languages.
  > We do want to get across what it offers that benefits
  > an editor and environment such as Emacs.

Yes we do, to some extent.  The Emacs web site should say this:

Lisp is the most powerful and elegant of programming languages.  If
you want to see how powerful and elegant a programming language can
be, you need to learn Lisp.  It will give you standard for measuring
other languages.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: First draft of the Emacs website

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > We don't want to set Lisp up against other languages.
>   > We do want to get across what it offers that benefits
>   > an editor and environment such as Emacs.
>
> Yes we do, to some extent.  The Emacs web site should say this:
>
> Lisp is the most powerful and elegant of programming languages.  If
> you want to see how powerful and elegant a programming language can
> be, you need to learn Lisp.  It will give you standard for measuring
> other languages.

It's more like a family of elegance rather than Lisp being its most
elegant member.

For example, a symbol has all of a function cell, a value cell (give and
take lexical binding semantics), a property list (which is global and
O(n) in access), a print name.  How do you lexically scope function cell
features?

In Guile, for comparison, a symbol has a print name.  Period.  Bindings
are either lexical or established in module variables.  There is no
difference between value/function cell, so you can just call whatever
you want without using FUNCALL.

I still don't really know what Lisp's LAMBDA special form is supposed to
return.  You can store the result in a variable, so it seems to be data,
but you can also call it without using FUNCALL, so it seems to have a
function cell.  If you store it anywhere, you can no longer call it
without FUNCALL.  So it seems to have some duplicitous value of which it
loses half whenever you do anything with it.

So I don't buy that Lisp is elegance incarnated.  There is some beauty
running in its family but I don't really think any member got all of it.

-- 
David Kastrup

Re: First draft of the Emacs website

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Well, as Peter Norvig put it, "Basically, Python can be seen as
  > a dialect of Lisp with «traditional» syntax" (see
  > http://norvig.com/python-lisp.html).

I looked at this some years ago, and I concluded there is only a
little validity in it.  The main essential features of Lisp are not
present in Python.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Python vs Lisp (followups to -tangents)

[Random832]

On 2015-12-10, Richard Stallman <rms@gnu.org> wrote:
> I looked at this some years ago, and I concluded there is only a
> little validity in it.  The main essential features of Lisp are not
> present in Python.

For some clue of what you're talking about, your previous
statement on this matter was:

> I skimmed documentation of Python after people told me it was
> fundamentally similar to Lisp. My conclusion is that that is
> not so. `read', `eval', and `print' are all missing in Python.

I must admit, I don't fully understand what you mean by this.

Print is the most confusing. As a feature, Lisp's 'print' can be
described as: Produce a string representation which can be read
back of some objects (certainly not *all* objects - not buffers
or subroutines, for example, and it's not structure-preserving
for lists of lists), and display it on standard output.
Python's 'repr' could be regarded as an exact match in concept
for prin1-to-string, a building block from which Lisp's 'print'
can be trivially made. The essential feature - that there is a
way to get a string that can be read back for objects for which
it is reasonable/easy - is present.

Python's 'eval'/'exec' normally evaluates code directly from a
string, skipping the need for 'read' entirely. However, if
desired, the 'ast' module provides a rich framework for working
with expression trees - the only difference is that they're
built from class-based objects instead of just being a list of
lists/symbols/literals.

Re: Python vs Lisp (followups to -tangents)

[Sam Steingold]

> * Random832 <enaqbz832@snfgznvy.pbz> [2015-12-10 16:13:30 +0000]:
>
> On 2015-12-10, Richard Stallman <rms@gnu.org> wrote:
>
>> I skimmed documentation of Python after people told me it was
>> fundamentally similar to Lisp. My conclusion is that that is
>> not so. `read', `eval', and `print' are all missing in Python.
>
> I must admit, I don't fully understand what you mean by this.
>
> Print is the most confusing. As a feature, Lisp's 'print' can be
> described as: Produce a string representation which can be read
> back of some objects (certainly not *all* objects - not buffers
> or subroutines, for example, and it's not structure-preserving
> for lists of lists), and display it on standard output.

This is false.
Nested lists are certainly printed readably:

--8<---------------cut here---------------start------------->8---
(defvar l '(1 (2 3) 4 (5 (6 (7 (8))))))
(equal l (read (prin1-to-string l)))
==> t
--8<---------------cut here---------------end--------------->8---


> Python's 'repr' could be regarded as an exact match in concept
> for prin1-to-string, a building block from which Lisp's 'print'
> can be trivially made. The essential feature - that there is a
> way to get a string that can be read back for objects for which
> it is reasonable/easy - is present.

True, but irrelevant.
An important feature is missing: repr is not defined for classes
automatically.

> Python's 'eval'/'exec' normally evaluates code directly from a
> string, skipping the need for 'read' entirely.

A string is too unstructured.

> However, if desired, the 'ast' module provides a rich framework for
> working with expression trees - the only difference is that they're
> built from class-based objects instead of just being a list of
> lists/symbols/literals.

These class-based objects cannot be printed readably (IIUC).

The point Richard is making is that Python lacks macros, i.e., you
cannot easily write code which writes code.
You have to either operate at the level of strings (which is hard to get
right) or at the level of AST (which is even harder).

Even more succinctly, in Lisp data and code are the same: lists of
lists, symbols, strings &c.
In Python, data is (mostly) strings and code is AST.


-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 15.10 (wily) X 11.0.11702000
http://www.childpsy.net/ http://memri.org http://islamexposedonline.com
http://truepeace.org http://www.dhimmitude.org http://camera.org
Old Age Comes at a Bad Time.

Re: Python vs Lisp (followups to -tangents)

[Random832]

On 2015-12-10, Sam Steingold <sds@gnu.org> wrote:
> This is false.
> Nested lists are certainly printed readably:

What I meant by "not structure-preserving" is that the output is
the same, ((1 2) (1 2)), for these lists:

(let  ((x '((1 2) (1 2))))         (eq (car x) (cadr x))) ==> nil
(let* ((a '(1 2)) (x `(,a ,a)))    (eq (car x) (cadr x))) ==> t
(let  ((x (read "((1 2) (1 2))"))) (eq (car x) (cadr x))) ==> nil

(Or for that matter, let*
 ((b '(2)) (x (list (cons 1 b) (cons 1 b))))...)

> True, but irrelevant.
>An important feature is missing: repr is not defined for classes
> automatically.

Sure it is. It's just defined to the same kind of useless value
that Lisp has for buffers and subroutines.

>> Python's 'eval'/'exec' normally evaluates code directly from a
>> string, skipping the need for 'read' entirely.
>
> A string is too unstructured.
>
>> However, if desired, the 'ast' module provides a rich framework for
>> working with expression trees - the only difference is that they're
>> built from class-based objects instead of just being a list of
>> lists/symbols/literals.
>
> These class-based objects cannot be printed readably (IIUC).

It's unfortunate that this is not their repr output, but the
ast.dump function provides this:

>>> ast.dump(ast.parse("1 + 1"))
'Module(body=[Expr(value=BinOp(left=Num(n=1), op=Add(), right=Num(n=1)))])'
>>> eval(ast.dump(ast.parse("1 + 1")), ast.__dict__)
<_ast.Module object at 0x7fcd79b24908>

> The point Richard is making is that Python lacks macros, i.e., you
> cannot easily write code which writes code.
> You have to either operate at the level of strings (which is hard to get
> right) or at the level of AST (which is even harder).

I don't see how operating at the level of AST is harder than
operating at the level of lists (backquote operates above the
level of lists; it automatically searches the code you give it
for placeholders to substitute values in. It probably wouldn't
be hard to write an equivalent in Python.)

> Even more succinctly, in Lisp data and code are the same: lists of
> lists, symbols, strings &c.
> In Python, data is (mostly) strings and code is AST.

I guess I don't see how being a little rough around the edges or
not working exactly the same way is the same thing as missing
the essential features entirely.

And this really isn't a valid objection to the claim being
discussed, which is that Python is similar to a hypothetical
M-expression lisp.

Re: Python vs Lisp (followups to -tangents)

[Sam Steingold]

> * Random832 <enaqbz832@snfgznvy.pbz> [2015-12-10 22:31:49 +0000]:
>
> On 2015-12-10, Sam Steingold <sds@gnu.org> wrote:
>> This is false.
>> Nested lists are certainly printed readably:
>
> What I meant by "not structure-preserving" is that the output is
> the same, ((1 2) (1 2)), for these lists:
>
> (let  ((x '((1 2) (1 2))))         (eq (car x) (cadr x))) ==> nil
> (let* ((a '(1 2)) (x `(,a ,a)))    (eq (car x) (cadr x))) ==> t
> (let  ((x (read "((1 2) (1 2))"))) (eq (car x) (cadr x))) ==> nil
>
> (Or for that matter, let*
>  ((b '(2)) (x (list (cons 1 b) (cons 1 b))))...)

please examine the `print-circle' variable.

>> True, but irrelevant.
>>An important feature is missing: repr is not defined for classes
>> automatically.
>
> Sure it is. It's just defined to the same kind of useless value
> that Lisp has for buffers and subroutines.

The #<...> format is reserved for objects which cannot be meaningfully
read back. Still, it contains plenty of information for a human.

Python prints junk when it could have been printing machine-readable info.

>>> Python's 'eval'/'exec' normally evaluates code directly from a
>>> string, skipping the need for 'read' entirely.
>>
>> A string is too unstructured.
>>
>>> However, if desired, the 'ast' module provides a rich framework for
>>> working with expression trees - the only difference is that they're
>>> built from class-based objects instead of just being a list of
>>> lists/symbols/literals.
>>
>> These class-based objects cannot be printed readably (IIUC).
>
> It's unfortunate that this is not their repr output, but the
> ast.dump function provides this:
>
>>>> ast.dump(ast.parse("1 + 1"))
> 'Module(body=[Expr(value=BinOp(left=Num(n=1), op=Add(), right=Num(n=1)))])'
>>>> eval(ast.dump(ast.parse("1 + 1")), ast.__dict__)
> <_ast.Module object at 0x7fcd79b24908>

yep, with some additional cruft Python can almost do something that Lisp
does for free.

>> The point Richard is making is that Python lacks macros, i.e., you
>> cannot easily write code which writes code.
>> You have to either operate at the level of strings (which is hard to get
>> right) or at the level of AST (which is even harder).
>
> I don't see how operating at the level of AST is harder than
> operating at the level of lists (backquote operates above the
> level of lists; it automatically searches the code you give it
> for placeholders to substitute values in. It probably wouldn't
> be hard to write an equivalent in Python.)

I am afraid you do not quite understand what you are talking about.

>> Even more succinctly, in Lisp data and code are the same: lists of
>> lists, symbols, strings &c.
>> In Python, data is (mostly) strings and code is AST.
>
> I guess I don't see how being a little rough around the edges or
> not working exactly the same way is the same thing as missing
> the essential features entirely.
>
> And this really isn't a valid objection to the claim being
> discussed, which is that Python is similar to a hypothetical
> M-expression lisp.

You have seen a car but never rode or driven one and you are trying to
convince me that your tricycle is better.

Seriously, this is the wrong forum for this discussion.
I suggest that you learn more about Lisp (see, e.g., Paul Graham's "On
Lisp", or http://letoverlambda.com/).

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 15.10 (wily) X 11.0.11702000
http://www.childpsy.net/ http://think-israel.org http://americancensorship.org
http://openvotingconsortium.org http://memri.org http://mideasttruth.com
"A pint of sweat will save a gallon of blood."          -- George S. Patton

Re: Python vs Lisp (followups to -tangents)

[Christopher Allan Webber]

Random832 writes:

>> The point Richard is making is that Python lacks macros, i.e., you
>> cannot easily write code which writes code.
>> You have to either operate at the level of strings (which is hard to get
>> right) or at the level of AST (which is even harder).
>
> I don't see how operating at the level of AST is harder than
> operating at the level of lists (backquote operates above the
> level of lists; it automatically searches the code you give it
> for placeholders to substitute values in. It probably wouldn't
> be hard to write an equivalent in Python.)

So, I think this thread is getting fairly off topic for the list, but I
can't resist chiming in here.

A project I've contributed to occasionally is Hy, which is sort of a
lisp that uses s-expressions (yes, you do need them if you want
homoiconic properties) which compiles down to Python's AST.  It's pretty
cool, because you can now write macros for Python and do other sorts of
lispy things that are impossible otherwise.  See:

  http://hy.readthedocs.org/en/latest/tutorial.html

Doing this required building a lisp like system on top of Python though.
To add new operations to the language meant making the language
homoiconic in some way, and yes, that meant using Python lists to make
s-expressions.  And yeah, you could compose with Python then.

I think in most ways, Hy was a real lisp, just one that used cpython as
a virtual machine.

However, there are downsides to using a lisp on top of something that
was never intended to be a lisp, which I learned the hard way.  I tried
writing a serious system in Hy, and eventually had to move to Guile
instead.  Why?  Because once you have macros, it becomes very difficult
to tell what line number you're on in (the level of transformations we
did made it so we couldn't keep around that information by the time we
got to the AST, and it was hard to reason about what was going on
there).  This meant debugging was nearly impossible, because when
debugging in Python, line numbers is your primary context for
determining where you are.  I'm not just talking about pdb.set_trace()
(though that too); even tracebacks became impossible to deal with.

Thus Hy is a pretty cool toy to play with, and kind of nice for writing
a quick DSL on top of Python.  And it *has* proven that you could treat
the Python AST as something to compile down to and have macros.  But
even there, it looked like lisp, and even once you had that, underlying
decisions about the implementation you're building on top of can make
things difficult.

Still fun to work on though!  Also a great community and a great route
for Python type people who want to dip their toe into lisp-land.  And a
good chance to learn the above lessons the hard way. :)

 - Chris

Re: First draft of the Emacs website

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > At the end of the day, we do need to refer to the language by its
  > > name, I think, but we could stress that it is a "Python-like"
  > > language, to connect with what people might be more familiar with.

  > Calling elisp "python-like" might be a bit of a stretch :)

Calling Emacs Lisp "python-like" is derogatory to Emacs Lisp.
Python has some of the characteristics that make Lisp superior,
but not all of them.  

Lisp is the most elegant and powerful programming language.  That is
what we should say.  In Lisp, programs are structured data and it is
easy to write other Lisp programs to operate on them.

Programmers that don't know Lisp do not realize what is missing in
other prograamming languages.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: First draft of the Emacs website

[David Kastrup]

John Yates <john@yates-sheets.org> writes:

> Drew,
>
> You and I are old "grey beards".  My point was that mentioning things that
> we - as seasoned users of Emacs - like is quite a bit different from
> imagining the website as a sales pitch to someone who has not used Emacs
> but _might_ - given an appropriate message - be coaxed into trying it.  If
> you accept such messaging as the site's first goal then you have to try to
> put yourself in the mindset of such a viewer.
>
> Your comments suggest that perhaps you do not buy into that being the first
> goal.

Why would a newcomer be interested in an old tool that merely does what
the new tools already do?  "Run with the herd like an octogenarian" is
not a sales pitch.  For better or worse, the reason to choose Emacs over
other options is for the things it does differently, not the things it
tries doing the same.

-- 
David Kastrup

Re: First draft of the Emacs website

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Fri, 04 Dec 2015 07:06:38 +0100
> Cc: Drew Adams <drew.adams@oracle.com>, Emacs developers <emacs-devel@gnu.org>
> 
> Why would a newcomer be interested in an old tool that merely does what
> the new tools already do?

Because all the cool guys use it?

Re: First draft of the Emacs website

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Fri, 04 Dec 2015 07:06:38 +0100
>> Cc: Drew Adams <drew.adams@oracle.com>, Emacs developers <emacs-devel@gnu.org>
>> 
>> Why would a newcomer be interested in an old tool that merely does what
>> the new tools already do?
>
> Because all the cool guys use it?

You got me there.

-- 
David Kastrup

Re: First draft of the Emacs website

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: john@yates-sheets.org,  drew.adams@oracle.com,  emacs-devel@gnu.org
> Date: Fri, 04 Dec 2015 10:42:37 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: David Kastrup <dak@gnu.org>
> >> Date: Fri, 04 Dec 2015 07:06:38 +0100
> >> Cc: Drew Adams <drew.adams@oracle.com>, Emacs developers <emacs-devel@gnu.org>
> >> 
> >> Why would a newcomer be interested in an old tool that merely does what
> >> the new tools already do?
> >
> > Because all the cool guys use it?
> 
> You got me there.

Maybe the Web site should have this somewhere, then.

Re: First draft of the Emacs website

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 192 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Because all the cool guys use it?
>> 
>> You got me there.
>
> Maybe the Web site should have this somewhere, then.

Haha, why not!

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: First draft of the Emacs website

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Cc: john@yates-sheets.org,  drew.adams@oracle.com,  emacs-devel@gnu.org
>> Date: Fri, 04 Dec 2015 10:42:37 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: David Kastrup <dak@gnu.org>
>> >> Date: Fri, 04 Dec 2015 07:06:38 +0100
>> >> Cc: Drew Adams <drew.adams@oracle.com>, Emacs developers
>> >> <emacs-devel@gnu.org>
>> >> 
>> >> Why would a newcomer be interested in an old tool that merely does what
>> >> the new tools already do?
>> >
>> > Because all the cool guys use it?
>> 
>> You got me there.
>
> Maybe the Web site should have this somewhere, then.

Shrug.  Emacs is where the cool guys go when they have work to do.  In
particular, Emacs is not what the "cool guys" call a "chick magnet".
The Emacs developer list is less frequented by women in my impression
than the average gay bar.  In Victorian England.

So while we all love each other dearly, I am not sure we'd be doing us
much of a favor by overadvertising how uniformly wonderful all of us
are.  Give people a chance to discover it on their own.

-- 
David Kastrup

Re: First draft of the Emacs website

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: john@yates-sheets.org,  drew.adams@oracle.com,  emacs-devel@gnu.org
> Date: Fri, 04 Dec 2015 11:44:47 +0100
> 
> So while we all love each other dearly, I am not sure we'd be doing us
> much of a favor by overadvertising how uniformly wonderful all of us
> are.  Give people a chance to discover it on their own.

What I actually had in mind is showing a list of well-known names of
people who are Emacs users.

Re: First draft of the Emacs website

[Paul Eggert]

On 12/04/2015 02:44 AM, David Kastrup wrote:
> The Emacs developer list is less frequented by women in my impression
> than the average gay bar.  In Victorian England.

I'm afraid you'll need a better analogy, as it was reasonably common for 
women to *run* the gay bars and meeting houses in Victorian England. For 
example, see Martha Stacey's well-known house in Wakefield Street, 
Bloomsbury, circa 1870. Going back further in time, perhaps the 
best-known molly-house in all of pre-Victorian England was the one run 
by Margarat Clap in Field Lane, Holborn, circa 1725.

Re: First draft of the Emacs website

[David Kastrup]

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 12/04/2015 02:44 AM, David Kastrup wrote:
>> The Emacs developer list is less frequented by women in my impression
>> than the average gay bar.  In Victorian England.
>
> I'm afraid you'll need a better analogy, as it was reasonably common
> for women to *run* the gay bars and meeting houses in Victorian
> England. For example, see Martha Stacey's well-known house in
> Wakefield Street, Bloomsbury, circa 1870. Going back further in time,
> perhaps the best-known molly-house in all of pre-Victorian England was
> the one run by Margarat Clap in Field Lane, Holborn, circa 1725.

emacs-devel: whenever you need it, someone will be there to prove you
wrong.

-- 
David Kastrup

Re: First draft of the Emacs website

[Eli Zaretskii]

> Date: Thu, 3 Dec 2015 18:26:16 -0500
> From: John Yates <john@yates-sheets.org>
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> You and I are old "grey beards". My point was that mentioning things that we -
> as seasoned users of Emacs - like is quite a bit different from imagining the
> website as a sales pitch to someone who has not used Emacs but _might_ - given
> an appropriate message - be coaxed into trying it. If you accept such messaging
> as the site's first goal then you have to try to put yourself in the mindset of
> such a viewer.
> 
> Your comments suggest that perhaps you do not buy into that being the first
> goal.

FWIW, I don't think there should be "the goal", in singular, for such
a Web site.  The stuff there should try to target diverse interests,
and let everyone pick up what they are most interested in.  Trying to
target some virtual newbie, and pretend we know very well what will
turn them on or off is bound to break at some point, IMO.

For example, the GDB front-end might very well interest someone who
needs to debug C/C++/Fortran code on GNU/Linux, where there's no
alternative, at least not out of the box, that is better.  I remember
showing that UI (when it was still not the default one) to several
developers that came from VS, and they never wanted anything else ever
since.  So mentioning it doesn't sound such a silly idea to me, after
all.

I believe the same could be true with other aspects.  E.g., is it such
a preposterous assumption that someone might be interested in coding
in Lisp, instead of all the ad-hoc extension languages invented by
other editors?

In sum, it might be TRT to diversify a bit.

Re: First draft of the Emacs website

[Clément Pit--Claudel]

[-- Attachment #1: Type: text/plain, Size: 1108 bytes --]

Hi John,

I'm not sure if you were answering Nicolas or me; my comments applied to the redesign, which I feel is a great step in making the website more welcoming.

On 12/04/2015 12:26 AM, John Yates wrote:
> My point was that mentioning things that we - as seasoned users of
> Emacs - like is quite a bit different from imagining the website as a
> sales pitch to someone who has not used Emacs but _might_ - given an
> appropriate message - be coaxed into trying it.  If you accept such
> messaging as the site's first goal then you have to try to put
> yourself in the mindset of such a viewer.

Well, I only started using Emacs seriously a year and a half ago :)

On 12/03/2015 11:17 PM, John Yates wrote:
> * Newbies likely have a long, long road to travel before they will
> ever consider discarding their current GUI / WYSIWYG / web-based
> productivity tools for Emacs' text-only calendar, mail project
> planning packages.

And even seasoned users still use graphical tools sometimes, judging by the fact that you write to this list from GMail's web interface :)

Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: First draft of the Emacs website

[H.Tsurumoto]

[-- Attachment #1: Type: text/plain, Size: 348 bytes --]

Hi Everyone, I think very nice design too.

By the way, I tried to access this web site by Firefox with LibreJS,
it blocked "animation.js <http://animation.js>" and "jquery.min.js
<http://jquery.min.js>".

"animation.js <http://animation.js>" was licensed by GPLv3+, but LibreJS
didn't detect the license.

Someone know how to solve this problem?


[-- Attachment #2: Type: text/html, Size: 735 bytes --]

Re: First draft of the Emacs website

[David Kastrup]

"H.Tsurumoto" <fortune.rocket42@gmail.com> writes:

> Hi Everyone, I think very nice design too.
>
> By the way, I tried to access this web site by Firefox with LibreJS,
> it blocked "animation.js <http://animation.js>" and "jquery.min.js
> <http://jquery.min.js>".
>
> "animation.js <http://animation.js>" was licensed by GPLv3+, but LibreJS
> didn't detect the license.
>
> Someone know how to solve this problem?

Frankly, my preferred approach for solving problems with JavaScript
animations would be license-agnostic.  I don't want web pages to change
while I am looking at them.  If the content is not important enough to
stay until I (rather than the script) am finished with it, it is not
important enough to be there in the first place.

-- 
David Kastrup

Re: First draft of the Emacs website

[Random832]

On 2015-12-02, David Kastrup <dak@gnu.org> wrote:
> Frankly, my preferred approach for solving problems with JavaScript
> animations would be license-agnostic.  I don't want web pages to change
> while I am looking at them.  If the content is not important enough to
> stay until I (rather than the script) am finished with it, it is not
> important enough to be there in the first place.

As far as I can tell, the mockup page only uses animation for smooth
transitions into (acceptably subtle) hover states, smooth scrolling
after clicking internal links, etc.

Re: First draft of the Emacs website

[David Kastrup]

Random832 <random832@fastmail.com> writes:

> On 2015-12-02, David Kastrup <dak@gnu.org> wrote:
>> Frankly, my preferred approach for solving problems with JavaScript
>> animations would be license-agnostic.  I don't want web pages to change
>> while I am looking at them.  If the content is not important enough to
>> stay until I (rather than the script) am finished with it, it is not
>> important enough to be there in the first place.
>
> As far as I can tell, the mockup page only uses animation for smooth
> transitions into (acceptably subtle) hover states, smooth scrolling
> after clicking internal links, etc.

The browser is in control of the client's computing resources,
compositing managing, window rendition, realtime.  If it (or the user
settings controlling it) or the page description language does not
consider animating changes a good idea, the web page author is not
really in a position to know better.

The user has nothing to gain from every web page inventing its own
human-computer interface.  The whole point of HTML is to package content
in a way where the rendition is matched to the platform's capabilities.

-- 
David Kastrup

RE: First draft of the Emacs website

[Drew Adams]

> The user has nothing to gain from every web page inventing its own
> human-computer interface.  The whole point of HTML is to package content
> in a way where the rendition is matched to the platform's capabilities.

Well put.

(Not a comment on the new Emacs page.)

Re: First draft of the Emacs website

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 1200 bytes --]

David Kastrup <dak@gnu.org> writes:

> The browser is in control of the client's computing resources,
> compositing managing, window rendition, realtime.  If it (or the user
> settings controlling it) or the page description language does not
> consider animating changes a good idea, the web page author is not
> really in a position to know better.

> The user has nothing to gain from every web page inventing its own
> human-computer interface.

Oh my gosh, the entire www has been wrong all this time!

On a more serious note, animations have been well defined in the CSS
standard for years[1], as well as through very common JS libraries[2],
SVG animations[3], the HTML Canvas, etc.

All of these are part of the web stack of every graphical web browser
out there, I didn't invent anything here.

> The whole point of HTML is to package content in a way where the
> rendition is matched to the platform's capabilities.

Come on, you very well know that HTML is about the content. Formatting,
appearance, animations and such should be handled in CSS, JS, etc.

Cheers,
Nico

[1] http://www.w3.org/TR/css3-transitions/
[2] http://api.jquery.com/animate/
[3] http://www.w3.org/TR/SVG/animate.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: First draft of the Emacs website

[David Kastrup]

Nicolas Petton <nicolas@petton.fr> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> The browser is in control of the client's computing resources,
>> compositing managing, window rendition, realtime.  If it (or the user
>> settings controlling it) or the page description language does not
>> consider animating changes a good idea, the web page author is not
>> really in a position to know better.
>
>> The user has nothing to gain from every web page inventing its own
>> human-computer interface.
>
> Oh my gosh, the entire www has been wrong all this time!

Not the "entire www", but yes, a good deal of it has been a nuisance.
Partly to the degree where pages are simply unusable because of invalid
assumptions about the human-computer interface.  There is a reason ad
blockers are widely used in order to systematically deal with some of
the worst misconceptions of page authors about their users' needs.

-- 
David Kastrup

Re: First draft of the Emacs website

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 610 bytes --]

David Kastrup <dak@gnu.org> writes:

> There is a reason ad blockers are widely used in order to
> systematically deal with some of the worst misconceptions of page
> authors about their users' needs.

Is my Emacs website so wrong because I added transitions to anchors?  I
really wonder why Firefox has JS support at all.

Ads on the web (as well as tracking) are a huge annoyance, but it's
totally unrelated to my animations (which degrades to regular anchors
BTW on browsers with no JS support).

Have you turned on `trolling-mode' today?

I'm sorry but I won't participate in this discussion anymore.
Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: First draft of the Emacs website

[Yuri Khan]

On Wed, Dec 2, 2015 at 9:42 PM, Nicolas Petton <nicolas@petton.fr> wrote:

> Oh my gosh, the entire www has been wrong all this time!

And we have known that all this time.

> Come on, you very well know that HTML is about the content. Formatting,
> appearance, animations and such should be handled in CSS, JS, etc.

Yes, and CSS, JS and WOFF constitute programs. And programs should be
subject to the four Freedoms, at least if served from a FSF’s site.
Right?

Re: First draft of the Emacs website

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 436 bytes --]

Yuri Khan <yuri.v.khan@gmail.com> writes:

> Yes, and CSS, JS and WOFF constitute programs. And programs should be
> subject to the four Freedoms, at least if served from a FSF’s site.
> Right?

I don't understand your point.  They are, or am I missing something?

I wrote the JS file myself, and the copyright is even assigned to the
FSF:
http://nicolas-petton.fr/ressources/emacs-website/javascript/animations.js

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: First draft of the Emacs website

[David Kastrup]

Nicolas Petton <nicolas@petton.fr> writes:

> Yuri Khan <yuri.v.khan@gmail.com> writes:
>
>> Yes, and CSS, JS and WOFF constitute programs. And programs should be
>> subject to the four Freedoms, at least if served from a FSF’s site.
>> Right?
>
> I don't understand your point.  They are, or am I missing something?

You are missing that the thread length has surpassed the message
horizon.  That means that people's and web archives' memories of it have
diverged.  Yuri is talking about something entirely different from what
you are talking about, but both of you try interpreting the respective
other's mails in the context you consider relevant.

-- 
David Kastrup

Re: First draft of the Emacs website

[Yuri Khan]

On Wed, Dec 2, 2015 at 9:57 PM, Nicolas Petton <nicolas@petton.fr> wrote:

>> Yes, and CSS, JS and WOFF constitute programs. And programs should be
>> subject to the four Freedoms, at least if served from a FSF’s site.
>> Right?
>
> I don't understand your point.  They are, or am I missing something?
>
> I wrote the JS file myself, and the copyright is even assigned to the
> FSF:
> http://nicolas-petton.fr/ressources/emacs-website/javascript/animations.js

AFAIR this subthread started from someone saying animations.js is not
detected as Free by a browser extension which would facilitate
exercising the freedom to modify.

Re: First draft of the Emacs website

[Random832]

On 2015-12-02, Yuri Khan <yuri.v.khan@gmail.com> wrote:
> Yes, and CSS, JS and WOFF constitute programs. And programs should be
> subject to the four Freedoms, at least if served from a FSF’s site.
> Right?

A summary of the discussion to this point:

- The page uses a script to enable animations.
- That script is in fact licensed under GPLv3
  - And uses jQuery, which is in fact licensed under the MIT license.
- The scripts fail to have whatever metadata is necessary for LibreJS to
  detect it as such.
  - No-one has objected to making whatever changes are necessary to
    rectify this situation.
- Someone did object to the entire concept of animation, irrespective of
  the use of free software to produce the animations.

I'm not sure how your point is relevant in response to any of this.

Re: First draft of the Emacs website

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Please minimize JS code in GNU web pages, and make sure the pages work
fully even if JS is disabled.

Everything written in JS is a program, and programs should be free.
All web sites should put free licenses on their JS code, if any.  See
http://gnu.org/philosophy/javascript-trap.html.  The sites should also
work with JS disabled.

Thus, if there is any JS code in a GNU web page, it should carry a
free license, and that license should be presented in a way that
LibreJS can recognize.

CSS is not really a programming language.  Yes, someone found a way to
make it Turing-complete, but CSS in ordinary use only specifies
format parameters.

Ordinary use of CSS in GNU web pages is not an ethical issue, but
please keep in mind that some browsers don't process CSS, so please
make sure your pages are readable and clear without the CSS.

I don't know what WOFF is.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: First draft of the Emacs website

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 1193 bytes --]

Richard Stallman <rms@gnu.org> writes:

Hi Richard,

> Please minimize JS code in GNU web pages,

Why? The file is 1.5kB, there's no need to minimize it.  Does LibreJS
require minification?

> and make sure the pages work fully even if JS is disabled.

That's the case already, please try it.

> Thus, if there is any JS code in a GNU web page, it should carry a
> free license,

It does, it's GPL, and the copyright is assigned to the FSF, you can
read the file, it's only 5 small functions:
http://nicolas-petton.fr/ressources/emacs-website/javascript/animations.js

> and that license should be presented in a way that
> LibreJS can recognize.

Shouldn't LibreJS (a web browser extension, in no way a web standard) be
able to recognize GPL files by itself?

Else it seems to me that this extension does not fit the real world, it
looks like it's even blocking jQuery, probably the most used JS library,
which is MIT.

> Ordinary use of CSS in GNU web pages is not an ethical issue, but
> please keep in mind that some browsers don't process CSS, so please
> make sure your pages are readable and clear without the CSS.

Of course, that will be done!

Thanks for your feedback Richard,
Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: First draft of the Emacs website

[Alexis]

Nicolas Petton <nicolas@petton.fr> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> Please minimize JS code in GNU web pages,
>
> Why? The file is 1.5kB, there's no need to minimize it.  Does 
> LibreJS require minification?

My guess is that Richard meant "Use as little JS code in GNU Web 
pages as possible", not "Use a minifier on the JS source".


Alexis.

Re: First draft of the Emacs website

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 681 bytes --]

Alexis <flexibeast@gmail.com> writes:

>> Richard Stallman <rms@gnu.org> writes:
>>
>>> Please minimize JS code in GNU web pages,
>>
>> Why? The file is 1.5kB, there's no need to minimize it.  Does 
>> LibreJS require minification?
>
> My guess is that Richard meant "Use as little JS code in GNU Web 
> pages as possible", not "Use a minifier on the JS source".

Ok, I understand now.

Richard, minimizing the use of JS code doesn't look like a viable option
in 2015.

Having free JavaScript code, as well as making sure the website is
functional with no JavaScript makes much more sense to me though, and I
will definitely enforce it in this website.

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: First draft of the Emacs website

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Richard, minimizing the use of JS code doesn't look like a viable option
  > in 2015.

You can try to convince me, but since most of gnu.org uses no JS code
at all, I am very skeptical.  I'm willing to listen to your arguments,
but in the mean time this is our policy.
-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: First draft of the Emacs website

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 419 bytes --]

Richard Stallman <rms@gnu.org> writes:

>   > Richard, minimizing the use of JS code doesn't look like a viable option
>   > in 2015.
>
> You can try to convince me, but since most of gnu.org uses no JS code
> at all, I am very skeptical.  I'm willing to listen to your arguments,
> but in the mean time this is our policy.

We can talk about this, but I think this is off-topic, I'll send you an
email off-list.

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: First draft of the Emacs website

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > and that license should be presented in a way that
  > > LibreJS can recognize.

  > Shouldn't LibreJS (a web browser extension, in no way a web standard) be
  > able to recognize GPL files by itself?

The only way it can recognize that certain JS code carries a
particular license is if the pages state the license in a mechanically
recognizable way.

With C and Lisp code, only humans check the licenses on those
programs.  Thus, when I worked out the way to state the GPL on source
files, I did not try to make it mechanically recognizable.  But
LibreJS needs to recognize license notices mechanically, so we need to
state the licenses in a format that is mechanically recognizable.

LibreJS knows about some programs specially.  For instance, it
recognizes many versions of Jquery by checksumming the text.  If you
have a standard version of Jquery that it does not recognize, please
report a bug in LibreJS.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: First draft of the Emacs website

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 307 bytes --]

Richard Stallman <rms@gnu.org> writes:

> LibreJS knows about some programs specially.  For instance, it
> recognizes many versions of Jquery by checksumming the text.  If you
> have a standard version of Jquery that it does not recognize, please
> report a bug in LibreJS.

I will double-check that.

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: First draft of the Emacs website

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > "animation.js <http://animation.js>" was licensed by GPLv3+, but LibreJS
  > > didn't detect the license.
  > >
  > > Someone know how to solve this problem?

See http://gnu.org/philosophy/javascript-trap.html for info on this.
We have two ways to indicate the license of JS code; use whichever
one is more convenient.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: First draft of the Emacs website

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 428 bytes --]

"H.Tsurumoto" <fortune.rocket42@gmail.com> writes:

> Hi Everyone, I think very nice design too.
>
> By the way, I tried to access this web site by Firefox with LibreJS,
> it blocked "animation.js <http://animation.js>" and "jquery.min.js
> <http://jquery.min.js>".
>
> "animation.js <http://animation.js>" was licensed by GPLv3+, but LibreJS
> didn't detect the license.

No clue.  And BTW, jQuery is also free software.

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: First draft of the Emacs website

[David Engster]

Nicolas Petton writes:
> "H.Tsurumoto" <fortune.rocket42@gmail.com> writes:
>
>> Hi Everyone, I think very nice design too.
>>
>> By the way, I tried to access this web site by Firefox with LibreJS,
>> it blocked "animation.js <http://animation.js>" and "jquery.min.js
>> <http://jquery.min.js>".
>>
>> "animation.js <http://animation.js>" was licensed by GPLv3+, but LibreJS
>> didn't detect the license.
>
> No clue.

It seems jslibre is pretty picky what kind of license blurbs it expects
at the top [1].

However, you can use the rel=jslicense attribute. See

  https://www.fsf.org/blogs/licensing/rel-jslicense

-David

[1] https://fossies.org/dox/librejs-6.0.10/license__definitions_8js_source.html