RE: Casting as wide a net as possible (was: First draft of the Emacs website)

RE: Casting as wide a net as possible (was: First draft of the Emacs website)

[Drew Adams]

> > For those who are interested (eg the 13 year old Drew postulated)
> > there are many easily discovered resources on the web describing
> > Emacs, Lisp, eLisp, etc. We could easily include on our site a
> > curated list of links to the best of such resources. If we feel
> > that there does not yet exist a sufficiently effusive description
> > of (e)Lisp we can write one and link to it.
> 
> We don't want anything even close to a description, we want just a
> hint, to lure them to learn more.  There's no need in external links
> for that, we could manage such a short passage ourselves.  At least we
> should try.

Agreed.  And it's not just about luring potentially interested users.
It's about describing Emacs - its most important features.  No need
to glorify anything; it is sufficient to point out how Emacs is
different.

This description of Emacs includes what you can do with it, at the
most general level.  And this most general level of what-you-can-do
includes some Lisp features.  It does not mean just pointing out
that Emacs has lots of "plug-ins" etc.

RE: Casting as wide a net as possible

[Drew Adams]

> I think we should also mention the huge number of applications and
> packages included or available out there.  I don't think there's a
> computing related job that Emacs does not already do, given the right
> packages are installed.
> 
> Also, the fact that it presents more or less the same behavior on all
> supported platforms (modulo some system-specific features on each
> platform).

+1 to both points.  The latter is less obvious, IMO.

Casting as wide a net as possible (was: First draft of the Emacs website)

[John Yates]

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

Having first raised the issue of the merits of pitching Lisp
on the Emacs website allow me to chime in again.

My thought was that what Emacs needs before all else is more
users.  Period.  A large enthusiastic community of users will
spawn in time more accomplished, more advanced users.  Even if
the vast majority of those users never contribute to FSF nor
write any serious Lisp we still benefit from their spreading
the word.  And the larger the community the more the laws of big
numbers will guarantee we harvest some amount of new, younger
talent.

I would hope that our site would be not just a self-indulgent
love fest, a litany of all the things we - the advanced, deeply
committed users - love about Emacs.  Instead I imagine our site
as the place where a newbie becomes seduced by Emacs' clearly
wonderful and unique functionality, available "out of the box".
The site should make it clear and easy how to try out Emacs and
ensure as much as possible a very positive experience.  That
experience should be good enough to motivate some number of the
site's visitors to abandon permanently their current editor.
There might be some low key mention of future ecstasy to be
discovered down the road.  But the first order of business is
getting our newbie to try Emacs and conclude the (s)he likes it.

Do you seriously want to adopt the stance that if a would be user
does not drink the Lisp CoolAid then (s)he is not welcome to use
our editor?  Or at least (s)he has to get past our proselytizing?

A newbie following up a suggestion that (s)he checkout an editor
called Emacs should not be assailed by a religious pitch about how
(s)he should lust to use Emacs because its extension language is
superior to that used in other editors.  First off most users are
going to assess an editor based on what they came achieve right out
of the box.  After all until one has used a tool for a while one
has little sense of where one's personal itches lie.  Further, to
the extent the our newbie already has a favorable impression of
some other extension language pitching the virtues of Lisp could
well be a turn-off.  Net, we loose a potential convert who at the
least might have been another satisfied Emacs booster, and who
- were (s)he the sort of user prone to modifying tools - might
have come around in time to writing extensions and contributing
them back to the project.

For those who are interested (eg the 13 year old Drew postulated)
there are many easily discovered resources on the web describing
Emacs, Lisp, eLisp, etc.  We could easily include on our site a
curated list of links to the best of such resources.  If we feel
that there does not yet exist a sufficiently effusive description
of (e)Lisp we can write one and link to it.

/john

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

RE: Casting as wide a net as possible (was: First draft of the Emacs website)

[Drew Adams]

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

FWIW, I don't disagree with much of what you said, John. I, for one, never suggested that "if a would be user does not drink the Lisp CoolAid then (s)he is not welcome to use our editor".

 

I also did not suggest that we pit Lisp against other languages with arguments about superiority. (RMS suggested that, to some degree.)

 

What I suggested it that Emacs is particularly about customizing, and Lisp, yes, is a part of that. And it is a part not because one has to code Lisp to customize Emacs (that's false), but because one can customize Emacs more powerfully and more flexibly using Lisp.

 

I said that I think that we should mention what some important Lisp features offer to Emacs - essential features that make Emacs what it is.

 

I think your post indicates a somewhat black-&-white, and limiting, view of both the newbies we should be welcoming and how we should do so.

 

My only point is that Lisp features really do make Emacs what it is. To point out what Emacs is necessarily means pointing out some of those features (IMO). 

 

This does not imply a language war or an electric kool-aid acid test. Nor does it imply that potential users who might never be interested in some of those features will be, or should be, excluded or turned off. Far from it.

 

I would hope that our site would be not just a self-indulgent
love fest, a litany of all the things we - the advanced, deeply
committed users - love about Emacs....
Do you seriously want to adopt the stance that if a would be user
does not drink the Lisp CoolAid then (s)he is not welcome to use
our editor?  Or at least (s)he has to get past our proselytizing?


A newbie following up a suggestion that (s)he checkout an editor
called Emacs should not be assailed by a religious pitch about how
(s)he should lust to use Emacs because its extension language is
superior to that used in other editors.  

...

For those who are interested (eg the 13 year old Drew postulated)
there are many easily discovered resources on the web describing
Emacs, Lisp, eLisp, etc.  We could easily include on our site a
curated list of links to the best of such resources.  If we feel
that there does not yet exist a sufficiently effusive description
of (e)Lisp we can write one and link to it.

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

Re: Casting as wide a net as possible

[John Wiegley]

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

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

> My only point is that Lisp features really do make Emacs what it is. To
> point out what Emacs is necessarily means pointing out some of those
> features (IMO).

I agree. The things that make Emacs great:

  1. Highly consistent syntax.
  2. Self-documenting.
  3. Integrated debugger.
  4. Ability to re-evaluate functions in a running environment.
     (i.e., everything that made Lisp Machines great)
  5. Natural syntax for scoping resources (`with-temp-buffer ...')
  6. Large and well documented API
  7. Stable and mature concepts evolved over decades
  8. Huge, HUGE community of cargo-cultable examples, for those just learning

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

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

Re: Casting as wide a net as possible

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Date: Thu, 10 Dec 2015 11:02:06 -0800
> Cc: Emacs developers <emacs-devel@gnu.org>, John Yates <john@yates-sheets.org>
> 
> I agree. The things that make Emacs great:
> 
>   1. Highly consistent syntax.
>   2. Self-documenting.
>   3. Integrated debugger.
>   4. Ability to re-evaluate functions in a running environment.
>      (i.e., everything that made Lisp Machines great)
>   5. Natural syntax for scoping resources (`with-temp-buffer ...')
>   6. Large and well documented API
>   7. Stable and mature concepts evolved over decades
>   8. Huge, HUGE community of cargo-cultable examples, for those just learning

I think we should also mention the huge number of applications and
packages included or available out there.  I don't think there's a
computing related job that Emacs does not already do, given the right
packages are installed.

Also, the fact that it presents more or less the same behavior on all
supported platforms (modulo some system-specific features on each
platform).

Re: Casting as wide a net as possible

[David Kastrup]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Drew Adams <drew.adams@oracle.com> writes:
>
>> My only point is that Lisp features really do make Emacs what it is. To
>> point out what Emacs is necessarily means pointing out some of those
>> features (IMO).
>
> I agree. The things that make Emacs great:
>
>   1. Highly consistent syntax.

Lisp does not have a program syntax.  Its data structures have a fairly
primitive read syntax, and you write down your parse trees in that
syntax.

That's what makes people hate reading Lisp code (since code is expressed
only in terms of lists, the punctuation is not useful for helping humans
parse the input, letting part of their trained pattern recognition in
the context of reading natural language go waste).  It's also what makes
programmatic manipulation of Lisp code including macro programming quite
more powerful and structure-preserving than macro programming in C or
other languages.

It's a tradeoff, and a good tradeoff at that, but I consider it silly to
try selling the downside of the tradeoff as an advantage.  The upside is
worth it without smokescreen.

-- 
David Kastrup

Re: Casting as wide a net as possible

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Thu, 10 Dec 2015 20:48:05 +0100
> Cc: Emacs developers <emacs-devel@gnu.org>, John Yates <john@yates-sheets.org>
> 
> >   1. Highly consistent syntax.
> 
> Lisp does not have a program syntax.

Then how about

  1. Highly consistent lack of syntax.

?

Re: Casting as wide a net as possible

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Thu, 10 Dec 2015 20:48:05 +0100
>> Cc: Emacs developers <emacs-devel@gnu.org>, John Yates <john@yates-sheets.org>
>> 
>> >   1. Highly consistent syntax.
>> 
>> Lisp does not have a program syntax.
>
> Then how about
>
>   1. Highly consistent lack of syntax.
>
> ?

Kind of unconventional as an advertisement though it has its charm.  But
there is a (rather simple) _read_ syntax for data structures.  Just no
separate program syntax.

-- 
David Kastrup

Re: Casting as wide a net as possible

[John Wiegley]

>>>>> David Kastrup <dak@gnu.org> writes:

> Kind of unconventional as an advertisement though it has its charm. But
> there is a (rather simple) _read_ syntax for data structures. Just no
> separate program syntax.

This distinction is meaningless to those we're trying to attract. What I meant
is "what you type". It's highly consistent in that regard, whatever you choose
to call it.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Casting as wide a net as possible

[David Kastrup]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> David Kastrup <dak@gnu.org> writes:
>
>> Kind of unconventional as an advertisement though it has its
>> charm. But there is a (rather simple) _read_ syntax for data
>> structures. Just no separate program syntax.
>
> This distinction is meaningless to those we're trying to attract. What
> I meant is "what you type".  It's highly consistent in that regard,
> whatever you choose to call it.

Regarding readability to humans, it's a disadvantage and I don't think
we will gain points by trying to sell it as an advantage.  If we want to
sell an advantage, it is the easy structure-preserving manipulation of
Lisp code that Lisp code can do.  That's the cart, and the simple read
syntax is the horse pulling it.

I mean, I don't sell Modern Greek as "highly consistent vowel
pronunciation" because all of ει, υ, υι, η, ῃ, αι, οι, ι (did I forget
any?) are pronounced the same.

At any rate, I don't think I have anything worthwhile to add that I
didn't say already, and I am not the one writing the advertisement
either.

-- 
David Kastrup

Re: Casting as wide a net as possible

[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. ]]]

  > Lisp does not have a program syntax.  Its data structures have a fairly
  > primitive read syntax, and you write down your parse trees in that
  > syntax.

  > That's what makes people hate reading Lisp code

We Lispers consider this simple syntax one of Lisp's great strengths.

Of course, there are some who disagree.  But that's not the viewpoint
the Emacs web pages should take.  They should take a _favorable_
stance towards this aspect of Lisp, to encourage others to see the
beauty in it.

People who disagree will have to state their views somewhere else.

-- 
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: Casting as wide a net as possible

[covici]

hmmm, I might disagree about the debugger -- one problem when I have
tried to use it, is that apparently it has problems interpreting
compiled code -- I am not sure if it should, but it makes it hard to
use.  I am not sure how well documented it is, seemed pretty sparse to
me.  I am glad I have not had to use it too much, emacs has done well
for me for many years.

John Wiegley <jwiegley@gmail.com> wrote:

> >>>>> Drew Adams <drew.adams@oracle.com> writes:
> 
> > My only point is that Lisp features really do make Emacs what it is. To
> > point out what Emacs is necessarily means pointing out some of those
> > features (IMO).
> 
> I agree. The things that make Emacs great:
> 
>   1. Highly consistent syntax.
>   2. Self-documenting.
>   3. Integrated debugger.
>   4. Ability to re-evaluate functions in a running environment.
>      (i.e., everything that made Lisp Machines great)
>   5. Natural syntax for scoping resources (`with-temp-buffer ...')
>   6. Large and well documented API
>   7. Stable and mature concepts evolved over decades
>   8. Huge, HUGE community of cargo-cultable examples, for those just learning
> 
> -- 
> John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
> http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

Re: Casting as wide a net as possible

[Marcin Borkowski]

On 2015-12-10, at 20:02, John Wiegley <jwiegley@gmail.com> wrote:

>>>>>> Drew Adams <drew.adams@oracle.com> writes:
>
>> My only point is that Lisp features really do make Emacs what it is. To
>> point out what Emacs is necessarily means pointing out some of those
>> features (IMO).
>
> I agree. The things that make Emacs great:
>
>   1. Highly consistent syntax.
>   2. Self-documenting.
>   3. Integrated debugger.
>   4. Ability to re-evaluate functions in a running environment.
>      (i.e., everything that made Lisp Machines great)
>   5. Natural syntax for scoping resources (`with-temp-buffer ...')
>   6. Large and well documented API
>   7. Stable and mature concepts evolved over decades
>   8. Huge, HUGE community of cargo-cultable examples, for those just learning

9. Lots and lots of functions to peform common (and even not-so-common)
tasks in an automated way.  (transpose-.*, I'm looking at you!)

10. Lots of well-thought-of functions, resulting from gathering over
three decades of experience: if you _want_ Emacs to be able to do
something useful (however small or big), it probably already can.  (See
beginning-of-buffer with a prefix arg, for instance.)

Best,

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

Re: Casting as wide a net as possible

[Adrian.B.Robert]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Drew Adams <drew.adams@oracle.com> writes:
>
>> My only point is that Lisp features really do make Emacs what it is. To
>> point out what Emacs is necessarily means pointing out some of those
>> features (IMO).
>
> I agree. The things that make Emacs great:
>
>   1. Highly consistent syntax.
>   2. Self-documenting.
>   3. Integrated debugger.
>   4. Ability to re-evaluate functions in a running environment.
>      (i.e., everything that made Lisp Machines great)
>   5. Natural syntax for scoping resources (`with-temp-buffer ...')
>   6. Large and well documented API
>   7. Stable and mature concepts evolved over decades
>   8. Huge, HUGE community of cargo-cultable examples, for those just learning

These are all good, but, aside from #2 and #3, relatively deep and
sophisticated.  The simpler aspects that keep driving me back to use Emacs
even as good IDEs and other tools proliferate, and the reasons I encourage
others to try it:

    1. Do things that often *can't be done* in other editors:
       - *everything* from the keyboard
       - fast, low-overhead keyboard navigation (faster than any IDE)
       - split windows for multiple spots in file or multiple files
       - clean, complete l10n handling
       - regex search/replace
       - keyboard macros

    2. Do things *more easily* than other editors
       - discovery: M-x command completion and shortcut hinting (part
           of self-documenting, means can learn to use keyboard easily)
       - swiss-army knife: learn once, edit many types of content
           (rather than dealing with a new tool for every job)
       - works same on any desktop box
       - works same on remote *nix machines as in a local desktop
           (rather than suffering with vi etc.)
       - emacsclient (big when working with command-line shells in a
           desktop environment)

    3. Better *customization* than other editors
       - menu options plus straightforward simple customization
       - full programmability for complex cases
       - *easily* migrate customization from environment to environment


Overall, due to excellent design philosophy and a highly extensible
foundation, Emacs delivers an unparalleled environment for focusing on what
you want to do, rather than spending time fiddling and fighting with your
tools.

Re: Casting as wide a net as possible

[raman]

Adrian.B.Robert@gmail.com writes:


And a couple more:

1. All content is structure aware --- so the same set of navigation /
cut/copy commands work across a wide variety of content. Lacking this,
other environments force users to select based on what they see on the
screen with a mouse -- and though that might give instant gratification,
it breaks down when the unit of information you want doesn't fit on the
screen.

2. That all content is in a single consistent environment makes sharing
content across various purposes easy -- write  some code, copy a piece
that is causing problems into a chat/mail buffer, get a response --
easily paste it back (except when some WebApp at the other end ruins it
with non-breaking invisible spaces -- but I digress).

>
>>>>>>> Drew Adams <drew.adams@oracle.com> writes:
>>
>>> My only point is that Lisp features really do make Emacs what it is. To
>>> point out what Emacs is necessarily means pointing out some of those
>>> features (IMO).
>>
>> I agree. The things that make Emacs great:
>>
>>   1. Highly consistent syntax.
>>   2. Self-documenting.
>>   3. Integrated debugger.
>>   4. Ability to re-evaluate functions in a running environment.
>>      (i.e., everything that made Lisp Machines great)
>>   5. Natural syntax for scoping resources (`with-temp-buffer ...')
>>   6. Large and well documented API
>>   7. Stable and mature concepts evolved over decades
>>   8. Huge, HUGE community of cargo-cultable examples, for those just learning
>
> These are all good, but, aside from #2 and #3, relatively deep and
> sophisticated.  The simpler aspects that keep driving me back to use Emacs
> even as good IDEs and other tools proliferate, and the reasons I encourage
> others to try it:
>
>     1. Do things that often *can't be done* in other editors:
>        - *everything* from the keyboard
>        - fast, low-overhead keyboard navigation (faster than any IDE)
>        - split windows for multiple spots in file or multiple files
>        - clean, complete l10n handling
>        - regex search/replace
>        - keyboard macros
>
>     2. Do things *more easily* than other editors
>        - discovery: M-x command completion and shortcut hinting (part
>            of self-documenting, means can learn to use keyboard easily)
>        - swiss-army knife: learn once, edit many types of content
>            (rather than dealing with a new tool for every job)
>        - works same on any desktop box
>        - works same on remote *nix machines as in a local desktop
>            (rather than suffering with vi etc.)
>        - emacsclient (big when working with command-line shells in a
>            desktop environment)
>
>     3. Better *customization* than other editors
>        - menu options plus straightforward simple customization
>        - full programmability for complex cases
>        - *easily* migrate customization from environment to environment
>
>
> Overall, due to excellent design philosophy and a highly extensible
> foundation, Emacs delivers an unparalleled environment for focusing on what
> you want to do, rather than spending time fiddling and fighting with your
> tools.
>
>

-- 

Re: Casting as wide a net as possible

[John Wiegley]

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

>>>>> raman  <raman@google.com> writes:

> And a couple more:

We should compile everything people have contributed into a
WhatMakesEmacsGreat page for the Emacs Wiki...

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

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

Re: Casting as wide a net as possible (was: 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. ]]]

  > My thought was that what Emacs needs before all else is more
  > users.  Period.

We would like more people to use Emacs, but we should never think
that we _need_ more users.  When developers of a free software package
think they _need_ more users, it is a lever that can be used
to push them into bad decisions.

When some people use Emacs, they are getting benefit from our work.
We are glad it benefits them, we intended it to benefit users, and we
hope to make it benefit them more, but we don't _need_ them to be
pleased with our work.  We're the ones who did them a favor -- not
vice versa.

Likewise, when some people don't use Emacs, that's their loss, not our
loss.

-- 
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: Casting as wide a net as possible

[raman]

Richard Stallman <rms@gnu.org> writes:

well said! > [[[ 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. ]]]
>
>   > My thought was that what Emacs needs before all else is more
>   > users.  Period.
>
> We would like more people to use Emacs, but we should never think
> that we _need_ more users.  When developers of a free software package
> think they _need_ more users, it is a lever that can be used
> to push them into bad decisions.
>
> When some people use Emacs, they are getting benefit from our work.
> We are glad it benefits them, we intended it to benefit users, and we
> hope to make it benefit them more, but we don't _need_ them to be
> pleased with our work.  We're the ones who did them a favor -- not
> vice versa.
>
> Likewise, when some people don't use Emacs, that's their loss, not our
> loss.

-- 

Re: Casting as wide a net as possible

[Filipp Gunbin]

On 10/12/2015 11:46 -0500, John Yates wrote:

> I would hope that our site would be not just a self-indulgent
> love fest, a litany of all the things we - the advanced, deeply
> committed users - love about Emacs.  Instead I imagine our site
> as the place where a newbie becomes seduced by Emacs' clearly
> wonderful and unique functionality, available "out of the box".

When I started using Emacs, it attracted me with the ease of working
with codings.  I've tried some editors at that time, of course
(including well-known IDEs, for years), but never before it was so easy
to just open a file in a given coding, or re-open it in another.  We,
non-English-natives, still have problems with different encodings (yes,
KOI8-R, CP-1251 and CP-866 for Russian are still here) and Emacs helped
me to learn more clearly what the encoding is.

Another thing that impressed was set of advanced general text-editing
capabilities (someone mentioned transpose-* functions here) and their
infrastructure, including syntax tables.

These and other things made me sure that, although the my work language
(Java) support is lacking many things IDEs have, Emacs will be my editor
of choice.

Maybe it makes sense to underline this versatility and good accessible
infrastructure in addition to features most users expect to see in an
"ad" for a text editor.

Filipp

Re: Casting as wide a net as possible

[Yuri Khan]

On Mon, Dec 14, 2015 at 8:41 PM, Filipp Gunbin <fgunbin@fastmail.fm> wrote:

> When I started using Emacs, it attracted me with the ease of working
> with codings.  I've tried some editors at that time, of course
> (including well-known IDEs, for years), but never before it was so easy
> to just open a file in a given coding, or re-open it in another.  We,
> non-English-natives, still have problems with different encodings (yes,
> KOI8-R, CP-1251 and CP-866 for Russian are still here) and Emacs helped
> me to learn more clearly what the encoding is.

English natives have worse problems with encodings.

When we screw up the encoding, it is at least visible immediately.

Re: Casting as wide a net as possible

[Filipp Gunbin]

On 14/12/2015 21:01 +0600, Yuri Khan wrote:

> On Mon, Dec 14, 2015 at 8:41 PM, Filipp Gunbin <fgunbin@fastmail.fm> wrote:
>
>> When I started using Emacs, it attracted me with the ease of working
>> with codings.  I've tried some editors at that time, of course
>> (including well-known IDEs, for years), but never before it was so easy
>> to just open a file in a given coding, or re-open it in another.  We,
>> non-English-natives, still have problems with different encodings (yes,
>> KOI8-R, CP-1251 and CP-866 for Russian are still here) and Emacs helped
>> me to learn more clearly what the encoding is.
>
> English natives have worse problems with encodings.

What do you mean?  Just interesting.

Filipp

Re: Casting as wide a net as possible

[Random832]

Filipp Gunbin <fgunbin@fastmail.fm> writes:
> On 14/12/2015 21:01 +0600, Yuri Khan wrote:
>> On Mon, Dec 14, 2015 at 8:41 PM, Filipp Gunbin <fgunbin@fastmail.fm> wrote:
>>> When I started using Emacs, it attracted me with the ease of working
>>> with codings.  I've tried some editors at that time, of course
>>> (including well-known IDEs, for years), but never before it was so easy
>>> to just open a file in a given coding, or re-open it in another.  We,
>>> non-English-natives, still have problems with different encodings (yes,
>>> KOI8-R, CP-1251 and CP-866 for Russian are still here) and Emacs helped
>>> me to learn more clearly what the encoding is.
>>
>> English natives have worse problems with encodings.
>
> What do you mean?  Just interesting.

The definition of "worse" is subjective, but I think what he's
referring to is the fact that someone might open a file in the
wrong encoding, without noticing or caring that some accented
word or punctuation symbol in some paragraph deep within the
file looks wrong, add more content in the new encoding, save
it... then you have a file which has a mixture of bytes in
different encodings, which is very difficult to fix
automatically.

Whereas, if you open a file in Cyrillic (or, say, Japanese), you
know immediately that it's in the wrong encoding and won't do
any editing until the coding situation is fixed.

Re: Casting as wide a net as possible

[Yuri Khan]

On Mon, Dec 14, 2015 at 11:59 PM, Random832 <random832@fastmail.com> wrote:

>>> English natives have worse problems with encodings.
>>
>> What do you mean?  Just interesting.
>
> The definition of "worse" is subjective, but I think what he's
> referring to is the fact that someone might open a file in the
> wrong encoding, without noticing or caring that some accented
> word or punctuation symbol in some paragraph deep within the
> file looks wrong, add more content in the new encoding, save
> it... then you have a file which has a mixture of bytes in
> different encodings, which is very difficult to fix
> automatically.
>
> Whereas, if you open a file in Cyrillic (or, say, Japanese), you
> know immediately that it's in the wrong encoding and won't do
> any editing until the coding situation is fixed.

That’s exactly what I meant.

Re: Casting as wide a net as possible

[Filipp Gunbin]

On 15/12/2015 00:19 +0600, Yuri Khan wrote:

> On Mon, Dec 14, 2015 at 11:59 PM, Random832 <random832@fastmail.com> wrote:
>
>>>> English natives have worse problems with encodings.
>>>
>>> What do you mean?  Just interesting.
>>
>> The definition of "worse" is subjective, but I think what he's
>> referring to is the fact that someone might open a file in the
>> wrong encoding, without noticing or caring that some accented
>> word or punctuation symbol in some paragraph deep within the
>> file looks wrong, add more content in the new encoding, save
>> it... then you have a file which has a mixture of bytes in
>> different encodings, which is very difficult to fix
>> automatically.
>>
>> Whereas, if you open a file in Cyrillic (or, say, Japanese), you
>> know immediately that it's in the wrong encoding and won't do
>> any editing until the coding situation is fixed.
>
> That’s exactly what I meant.

I see.  However, this doesn't seem to affect English and American
English languages, but rather European ones.

Honestly, I always though that those languages do not have many
encodings in use, probably I'm wrong.

Filipp

Re: Casting as wide a net as possible

[Random832]

Filipp Gunbin <fgunbin@fastmail.fm> writes:
> I see.  However, this doesn't seem to affect English and American
> English languages, but rather European ones.

There are occasional accented words e.g. naïve, borrowed from
other languages. And also punctuation marks (more common with
people who use certain word processing software packages that
automatically replace typewriter quotes with them).

> Honestly, I always though that those languages do not have many
> encodings in use, probably I'm wrong.

Well, obviously there’s Latin-1 and UTF-8. There’s also
Windows-1252, which is semi-compatible with Latin-1. You can
sometimes end up with the Windows-1252 bytes treated as if they
were Latin-1 C1 controls (and perhaps encoded further into
UTF-8). There are also older encodings that aren’t used much
anymore e.g. DOS 437/850, MacRoman, etc.

I¹ve also seen content that was mechanically translated from one
to another using an 8-bit mapping table, with incompatible
characters mapped arbitrarily. For example, if you ever see
something with quotes/apostrophes replaced with superscripts,
like in this paragraph, this probably means the text originated
in MacRoman and was translated to Latin-1 with the ³André
Pirard² mapping.

Anyway, the point is, since non-ASCII characters aren’t
pervasive, it’s easy to miss noticing that something’s wrong
with them. For one last demo, this paragraph features UTF-8,
treated as Windows-1252, and then re-encoded as UTF-8 again.

Re: Casting as wide a net as possible

[Random832]

I’ve been too clever for my own good. My “C1 controls” example
was not properly encoded as UTF-8, and I ignored the warnings
provided by Gnus for this situation. Below is, I hope, my
message as it was intended to appear (all properly encoded as
UTF-8).

Random832 <random832@fastmail.com> writes:
> There are occasional accented words e.g. naïve, borrowed from
> other languages. And also punctuation marks (more common with
> people who use certain word processing software packages that
> automatically replace typewriter quotes with them).
>
> Well, obviously there’s Latin-1 and UTF-8. There’s also
> Windows-1252, which is semi-compatible with Latin-1. You can
> sometimes end up with the Windows-1252 bytes treated as if they
> were Latin-1 C1 controls (and perhaps encoded further into
> UTF-8). There are also older encodings that aren’t used much
> anymore e.g. DOS 437/850, MacRoman, etc.
>
> I¹ve also seen content that was mechanically translated from one
> to another using an 8-bit mapping table, with incompatible
> characters mapped arbitrarily. For example, if you ever see
> something with quotes/apostrophes replaced with superscripts,
> like in this paragraph, this probably means the text originated
> in MacRoman and was translated to Latin-1 with the ³André
> Pirard² mapping.
>
> Anyway, the point is, since non-ASCII characters aren’t
> pervasive, it’s easy to miss noticing that something’s wrong
> with them. For one last demo, this paragraph features UTF-8,
> treated as Windows-1252, and then re-encoded as UTF-8 again.

P.S.  It may be instructive to note that my message was
apparently detected by Gnus as being in some kind of Japanese
encoding.