Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #94567 > unrolled thread

Re: Gmail eats Python

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Gmail eats Python Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2015-07-25 20:47 +0300
    Re: Gmail eats Python Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2015-07-25 20:52 +0300
      Re: Gmail eats Python Laura Creighton <lac@openend.se> - 2015-07-25 20:05 +0200
        Re: Gmail eats Python Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2015-07-26 08:26 +0300
    Re: Gmail eats Python Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-07-25 18:44 +0000
    Re: Gmail eats Python Marko Rauhamaa <marko@pacujo.net> - 2015-07-25 22:42 +0300
      Re: Gmail eats Python Ben Finney <ben+python@benfinney.id.au> - 2015-07-26 10:52 +1000
      Re: Gmail eats Python Chris Angelico <rosuav@gmail.com> - 2015-07-26 10:58 +1000
      Re: Gmail eats Python Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2015-07-26 08:01 +0300
        Re: Gmail eats Python Rustom Mody <rustompmody@gmail.com> - 2015-07-25 22:28 -0700
          Re: Gmail eats Python Chris Angelico <rosuav@gmail.com> - 2015-07-26 15:34 +1000
            Re: Gmail eats Python Rustom Mody <rustompmody@gmail.com> - 2015-07-25 23:15 -0700
              Re: Gmail eats Python Chris Angelico <rosuav@gmail.com> - 2015-07-26 16:25 +1000
                Re: Gmail eats Python Marko Rauhamaa <marko@pacujo.net> - 2015-07-26 09:55 +0300
                  Re: Gmail eats Python Rustom Mody <rustompmody@gmail.com> - 2015-07-26 01:20 -0700
                    Re: Gmail eats Python Marko Rauhamaa <marko@pacujo.net> - 2015-07-26 11:35 +0300
                      Re: Gmail eats Python Rustom Mody <rustompmody@gmail.com> - 2015-07-26 01:50 -0700
                        Re: Gmail eats Python alister <alister.nospam.ware@ntlworld.com> - 2015-07-26 09:21 +0000
                          Re: Gmail eats Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-07-26 12:27 +0100
                        Re: Gmail eats Python Marko Rauhamaa <marko@pacujo.net> - 2015-07-26 12:51 +0300
                          Re: Gmail eats Python Chris Angelico <rosuav@gmail.com> - 2015-07-26 20:03 +1000
                            Re: Gmail eats Python Marko Rauhamaa <marko@pacujo.net> - 2015-07-26 13:31 +0300
                            Re: Gmail eats Python Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2015-07-26 14:30 +0300
                              Re: Gmail eats Python Marko Rauhamaa <marko@pacujo.net> - 2015-07-26 14:48 +0300
                                Re: Gmail eats Python random832@fastmail.us - 2015-07-29 10:51 -0400
                                Re: Gmail eats Python Larry Martell <larry.martell@gmail.com> - 2015-07-29 10:53 -0400
                        Re: Gmail eats Python Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2015-07-26 13:43 +0300
                          Re: Gmail eats Python Rustom Mody <rustompmody@gmail.com> - 2015-07-26 06:16 -0700
                          Re: Gmail eats Python Rustom Mody <rustompmody@gmail.com> - 2015-07-28 20:35 -0700
                            Re: Gmail eats Python Laura Creighton <lac@openend.se> - 2015-07-29 18:32 +0200
                Re: Gmail eats Python Grant Edwards <invalid@invalid.invalid> - 2015-07-26 15:42 +0000
              Re: Gmail eats Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-07-26 12:25 +0100
          Re: Gmail eats Python Grant Edwards <invalid@invalid.invalid> - 2015-07-26 15:47 +0000
            Re: Gmail eats Python Rustom Mody <rustompmody@gmail.com> - 2015-07-26 08:59 -0700
              Re: Gmail eats Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-07-26 18:21 +0100
              Re: Gmail eats Python Steven D'Aprano <steve@pearwood.info> - 2015-07-27 03:40 +1000
                Re: Gmail eats Python Rustom Mody <rustompmody@gmail.com> - 2015-07-26 14:34 -0700
                Re: Gmail eats Python Chris Angelico <rosuav@gmail.com> - 2015-07-27 11:47 +1000
              Re: Gmail eats Python Grant Edwards <invalid@invalid.invalid> - 2015-07-26 19:45 +0000
                Re: Gmail eats Python Rustom Mody <rustompmody@gmail.com> - 2015-07-26 14:54 -0700
    Re: Gmail eats Python Steven D'Aprano <steve@pearwood.info> - 2015-07-26 14:49 +1000
      Re: Gmail eats Python Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2015-07-26 08:37 +0300

Page 1 of 3  [1] 2 3  Next page →

#94567 — Re: Gmail eats Python

Zachary Ware writes:

> On Jul 25, 2015 11:35 AM, "Laura Creighton" wrote:
>>
>> Gmail eats Python.
>>
>> We just saw this mail back from Sebastian Luque which says in part:
>>
>> >>> try: all_your_code_which_is_happy_with_non_scalars except
>> >>> WhateverErrorPythonGivesYouWhenYouTryThisWithScalars:
>> >>> whatever_you_want_to_do_when_this_happens
>>
>> Ow!  Gmail is understanding the >>> I stuck in as 'this is
>> from the python console as a quoting marker and thinks it can reflow
>> that.
>>
>> I think that splunqe must already have gmail set for plain text or
>> else even worse mangling must show up.
>>
>> How do you teach gmail not to reflow what it thinks of as
>> 'other people's quoted text'?
>
> Add same whitespace in front of the >'s, in plain text mode:
>
>    >>> def test(): pass
>    ...
>    >>> print('Hi world')
>    Hi world
>    >>>
>
> (Hopefully that will work from my phone)

Just in case anyone cares, Gnus shows me those indentations as octal
codes, \302\240\302\240 (followed by one ASCII space). I guess a
\302\240 is a NO-BREAK SPACE in UTF-8, and I guess Gnus does not know
this because there is no charset specification in the headers. That
seems to be missing whenever I see these codes instead of properly
rendered characters and bother to check the headers.

Has the world adopted UTF-8 as the default charset now or what? (I'll be
only glad to hear that it has, if it has, but a reference to some sort
of internet standard would be nice.)

[toc] | [next] | [standalone]

#94568

Jussi Piitulainen writes:

> Zachary Ware writes:

[snip what I quoted from him]

Oh well - Gnus made me go through some hoops to send the characters that
were in the unknown-to-it encoding, and then mangled them. This is what
I had added:

> Just in case anyone cares, Gnus shows me those indentations as octal
> codes, \302\240\302\240 (followed by one ASCII space). I guess a
> \302\240 is a NO-BREAK SPACE in UTF-8, and I guess Gnus does not know
> this because there is no charset specification in the headers. That
> seems to be missing whenever I see these codes instead of properly
> rendered characters and bother to check the headers.
>
> Has the world adopted UTF-8 as the default charset now or what? (I'll
> be only glad to hear that it has, if it has, but a reference to some
> sort of internet standard would be nice.)

And any information is appreciated. Thanks.

[toc] | [prev] | [next] | [standalone]

#94570

In a message of Sat, 25 Jul 2015 20:52:38 +0300, Jussi Piitulainen writes:
>Jussi Piitulainen writes:
>> Has the world adopted UTF-8 as the default charset now or what? (I'll
>> be only glad to hear that it has, if it has, but a reference to some
>> sort of internet standard would be nice.)

I don't think so.  Americans and other English speakers still love ASCII.
but the ISO charsets are rapidly going the way of the buggywhip. :)
http://www.loc.gov/standards/iso639-2/php/English_list.php

Laura

[toc] | [prev] | [next] | [standalone]

#94592

Laura Creighton writes:

> In a message of Sat, 25 Jul 2015 20:52:38 +0300, Jussi Piitulainen writes:
>>Jussi Piitulainen writes:
>>> Has the world adopted UTF-8 as the default charset now or what?
>>> (I'll be only glad to hear that it has, if it has, but a reference
>>> to some sort of internet standard would be nice.)
>
> I don't think so.  Americans and other English speakers still love
> ASCII.  but the ISO charsets are rapidly going the way of the
> buggywhip. :)
> http://www.loc.gov/standards/iso639-2/php/English_list.php

I thought the ISO-8859 sets are going away in favour of UTF-8, and I
welcome that development. ASCII is still fine as a subset of UTF-8.
What's not fine is the use of encoded characters outside ASCII without a
corresponding declaration (possibly a default) of the encoding (or my
mail reader failing to understand that the declaration is there).

But how is that link to a set of language codes relevant?

[toc] | [prev] | [next] | [standalone]

#94573

On 2015-07-25, Jussi Piitulainen <jpiitula@ling.helsinki.fi> wrote:
> Just in case anyone cares, Gnus shows me those indentations as octal
> codes, \302\240\302\240 (followed by one ASCII space). I guess a
> \302\240 is a NO-BREAK SPACE in UTF-8, and I guess Gnus does not know
> this because there is no charset specification in the headers.

It is not true that there were was no charset specification
in the headers of the post you were responding to. It was
specified as UTF-8.

[toc] | [prev] | [next] | [standalone]

#94576

Jussi Piitulainen <jpiitula@ling.helsinki.fi>:

>>    >>> def test(): pass
>>    ...
>>    >>> print('Hi world')
>>    Hi world
>>    >>>
>
> Just in case anyone cares, Gnus shows me those indentations as octal
> codes, \302\240\302\240 (followed by one ASCII space). I guess a
> \302\240 is a NO-BREAK SPACE in UTF-8, and I guess Gnus does not know
> this because there is no charset specification in the headers. That
> seems to be missing whenever I see these codes instead of properly
> rendered characters and bother to check the headers.
>
> Has the world adopted UTF-8 as the default charset now or what? (I'll
> be only glad to hear that it has, if it has, but a reference to some
> sort of internet standard would be nice.)

The gnus command

   C-u g

displays the raw message.

It demonstrates that the posting was sent as

   Content-Type: multipart/alternative; boundary=001a1134d474c99321051bb5ef45

The first part has:

   Content-Type: text/plain; charset=UTF-8

The second part has:

   Content-Type: text/html; charset=UTF-8
   Content-Transfer-Encoding: quoted-printable

The text/plain variant expresses the indentations with plain whitespace
(SPC) characters. However, the text/html variant has:

   <p dir=3D"ltr">=C2=A0=C2=A0 &gt;&gt;&gt; def test(): pass<br>
   =C2=A0=C2=A0 ... <br>
   =C2=A0=C2=A0 &gt;&gt;&gt; print(&#39;Hi world&#39;)<br>
   =C2=A0=C2=A0 Hi world<br>
   =C2=A0=C2=A0 &gt;&gt;&gt;</p>

=C2=A0 stands for '\u00a0' (NO-BREAK SPACE).

When I have Gnus display the HTML variant, the indentation is not
displayed at all. I don't know why.

(It's another question what place text/html has on this forum in the
first place.)


Marko

[toc] | [prev] | [next] | [standalone]

#94581

Zachary Ware <zachary.ware+pylist@gmail.com> writes:

> If the gmail app on my phone had the option, I'd only send the plain
> text.

Isn't that a good reason to avoid composing email messages on a program
that lacks the correct capability?

If the GMail app lacks the ability to send plain text, there are better
alternatives (including avoiding GMail entirely).

-- 
 \     “If I had known what it would be like to have it all... I might |
  `\     have been willing to settle for less.” —Jane Wagner, via Lily |
_o__)                                                           Tomlin |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#94583

On Sun, Jul 26, 2015 at 10:52 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
> Zachary Ware <zachary.ware+pylist@gmail.com> writes:
>
>> If the gmail app on my phone had the option, I'd only send the plain
>> text.
>
> Isn't that a good reason to avoid composing email messages on a program
> that lacks the correct capability?
>
> If the GMail app lacks the ability to send plain text, there are better
> alternatives (including avoiding GMail entirely).

Phones suck. If you can't do stuff on your phone because it's all
locked down, take a hammer to your phone and use a device that gives
you more freedom. Most people I know claim to own phones, but really
just use what they're given; the phone provider truly owns those
phones.

ChrisA

[toc] | [prev] | [next] | [standalone]

#94591

Marko Rauhamaa writes:

> Jussi Piitulainen writes:

>> Just in case anyone cares, Gnus shows me those indentations as octal
>> codes, \302\240\302\240 (followed by one ASCII space). I guess a
>> \302\240 is a NO-BREAK SPACE in UTF-8, and I guess Gnus does not know
>> this because there is no charset specification in the headers. That
>> seems to be missing whenever I see these codes instead of properly
>> rendered characters and bother to check the headers.

> The gnus command
>
>    C-u g
>
> displays the raw message.

Thanks! I was just typing t to see what I thought were the full headers.

> It demonstrates that the posting was sent as
>
>    Content-Type: multipart/alternative; boundary=001a1134d474c99321051bb5ef45
>
> The first part has:
>
>    Content-Type: text/plain; charset=UTF-8
>
> The second part has:
>
>    Content-Type: text/html; charset=UTF-8
>    Content-Transfer-Encoding: quoted-printable

Yes, with C-u g, I see them.

> The text/plain variant expresses the indentations with plain
> whitespace (SPC) characters. However, the text/html variant has:
>
>    <p dir=3D"ltr">=C2=A0=C2=A0 &gt;&gt;&gt; def test(): pass<br>
>    =C2=A0=C2=A0 ... <br>
>    =C2=A0=C2=A0 &gt;&gt;&gt; print(&#39;Hi world&#39;)<br>
>    =C2=A0=C2=A0 Hi world<br>
>    =C2=A0=C2=A0 &gt;&gt;&gt;</p>
>
> =C2=A0 stands for '\u00a0' (NO-BREAK SPACE).

I suppose that's a valid HTML fragment when the charset is declared, but
the Gnus version I use fails to use the charset information when it
renders the message. Annoying that it chooses text/html over text/plain
and then fails. (Probably I can customize it now that I have a precise
idea of what it is that is going wrong.)

> When I have Gnus display the HTML variant, the indentation is not
> displayed at all. I don't know why.

So many ways to fail :)

[toc] | [prev] | [next] | [standalone]

#94593

On Sunday, July 26, 2015 at 10:31:20 AM UTC+5:30, Jussi Piitulainen wrote:
> Marko Rauhamaa writes:
> 
> > Jussi Piitulainen writes:
> 
> >> Just in case anyone cares, Gnus shows me those indentations as octal
> >> codes, \302\240\302\240 (followed by one ASCII space). I guess a
> >> \302\240 is a NO-BREAK SPACE in UTF-8, and I guess Gnus does not know
> >> this because there is no charset specification in the headers. That
> >> seems to be missing whenever I see these codes instead of properly
> >> rendered characters and bother to check the headers.
> 
> > The gnus command
> >
> >    C-u g
> >
> > displays the raw message.
> 
> Thanks! I was just typing t to see what I thought were the full headers.
> 
> > It demonstrates that the posting was sent as
> >
> >    Content-Type: multipart/alternative; boundary=001a1134d474c99321051bb5ef45
> >
> > The first part has:
> >
> >    Content-Type: text/plain; charset=UTF-8
> >
> > The second part has:
> >
> >    Content-Type: text/html; charset=UTF-8
> >    Content-Transfer-Encoding: quoted-printable
> 
> Yes, with C-u g, I see them.
> 
> > The text/plain variant expresses the indentations with plain
> > whitespace (SPC) characters. However, the text/html variant has:
> >
> >    <p dir=3D"ltr">=C2=A0=C2=A0 &gt;&gt;&gt; def test(): pass<br>
> >    =C2=A0=C2=A0 ... <br>
> >    =C2=A0=C2=A0 &gt;&gt;&gt; print(&#39;Hi world&#39;)<br>
> >    =C2=A0=C2=A0 Hi world<br>
> >    =C2=A0=C2=A0 &gt;&gt;&gt;</p>
> >
> > =C2=A0 stands for '\u00a0' (NO-BREAK SPACE).
> 
> I suppose that's a valid HTML fragment when the charset is declared, but
> the Gnus version I use fails to use the charset information when it
> renders the message. Annoying that it chooses text/html over text/plain
> and then fails. (Probably I can customize it now that I have a precise
> idea of what it is that is going wrong.)

Emacs belongs to the age when choice (and freedom, and democracy and brotherhood
and ...) are an unqualified good.
A 500-page gnus manual used to be the height of cuteness -- kittens, milk and all.
Not so post https://en.wikipedia.org/wiki/The_Paradox_of_Choice

> So many ways to fail :)
Combinatorially increases with choices... Mostly spurious ones.

JFTR: Ive been using emacs for 20+ years.  And I have the increasing feeling
that my students are getting fedup with it (and me).  Used Idle for my last python
course without too much grief.  If only it were an option for 25 programming languages, and org-mode and unicode/devanagari/tex input and.

[toc] | [prev] | [next] | [standalone]

#94594

On Sun, Jul 26, 2015 at 3:28 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> JFTR: Ive been using emacs for 20+ years.  And I have the increasing feeling
> that my students are getting fedup with it (and me).  Used Idle for my last python
> course without too much grief.  If only it were an option for 25 programming languages, and org-mode and unicode/devanagari/tex input and.

Not sure whether you're making the point deliberately or accidentally,
but that's exactly why emacs is so big and heavy: "if only, if only".
Simpler things do less.

ChrisA

[toc] | [prev] | [next] | [standalone]

#94598

On Sunday, July 26, 2015 at 11:05:14 AM UTC+5:30, Chris Angelico wrote:
> On Sun, Jul 26, 2015 at 3:28 PM, Rustom Mody  wrote:
> > JFTR: Ive been using emacs for 20+ years.  And I have the increasing feeling
> > that my students are getting fedup with it (and me).  Used Idle for my last python
> > course without too much grief.  If only it were an option for 25 programming languages, and org-mode and unicode/devanagari/tex input and.
> 
> Not sure whether you're making the point deliberately or accidentally,
> but that's exactly why emacs is so big and heavy: "if only, if only".
> Simpler things do less.

Well Almost.
Emacs used to stand for "Eight Megabytes And Constantly Swapping"
At a time when 8 MB was large. Is it today?
So let me ask you:
Do you not use ½ dozen (at least) languages?
And their interpreters (when they exist)
And their ancilliary tools (make autoconf etc)
And do you not type plain text?
Emails?
PIM (reminders, timesheets and planning)
Docs (more fancy than plain text, maybe libreoffice/MS/latex...)
Lilypond?
Use, experiment, play-around with (non-ASCII) unicode?

If you have one app to do them all, I'd like (and pay!) for it
If not I bet they are mutually inconsistent.

No...
Emacs is big (its not actually) and heavy (yeah) because there's no BDFL
to clean up the mess and take the flak.
Lehman's law of software deterioration (7th in this list
https://en.wikipedia.org/wiki/Lehman%27s_laws_of_software_evolution )
is about as inexorable as entropy in thermodynamics

[toc] | [prev] | [next] | [standalone]

#94599

On Sun, Jul 26, 2015 at 4:15 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> Well Almost.
> Emacs used to stand for "Eight Megabytes And Constantly Swapping"
> At a time when 8 MB was large. Is it today?
> So let me ask you:
> Do you not use ½ dozen (at least) languages?
> And their interpreters (when they exist)
> And their ancilliary tools (make autoconf etc)
> And do you not type plain text?
> Emails?
> PIM (reminders, timesheets and planning)
> Docs (more fancy than plain text, maybe libreoffice/MS/latex...)
> Lilypond?
> Use, experiment, play-around with (non-ASCII) unicode?
>
> If you have one app to do them all, I'd like (and pay!) for it
> If not I bet they are mutually inconsistent.
>

For the most part, I use a single text editor. But all their ancillary
tools are separate. Emacs tries to be absolutely everything, not just
editing text files; that's why it's big. Size isn't just a matter of
disk or RAM footprint, it's also (and much more importantly) UI
complexity.

It's a trade-off, of course. If you constantly have to switch programs
to do your work, that's a different form of UI complexity.

ChrisA

[toc] | [prev] | [next] | [standalone]

#94601

Chris Angelico <rosuav@gmail.com>:

> Emacs tries to be absolutely everything, not just editing text files;
> that's why it's big.

I use emacs for most of my text inputting needs. Sometimes I even use it
to type in web forms (prepare it in emacs and copy the text over into
the form).

I'm typing now. Hence, I'm using emacs. It's great that I don't have to
settle for less.

No matter what I'm typing, M-$ spell-checks the word under the cursor.
No matter what I'm typing, M-x picture-mode allows me to draw a picture
in ASCII graphics. And C-x ( starts a macro -- immensely useful in many
circumstances.

Emacs also works over text terminal connections. I use it all the time
to access virtual machines at the office as well as my home machine from
overseas.


Marko

[toc] | [prev] | [next] | [standalone]

#94605

On Sunday, July 26, 2015 at 12:25:42 PM UTC+5:30, Marko Rauhamaa wrote:
> Chris Angelico:
> 
> > Emacs tries to be absolutely everything, not just editing text files;
> > that's why it's big.
> 
> I use emacs for most of my text inputting needs. Sometimes I even use it
> to type in web forms (prepare it in emacs and copy the text over into
> the form).
> 
> I'm typing now. Hence, I'm using emacs. It's great that I don't have to
> settle for less.
> 
> No matter what I'm typing, M-$ spell-checks the word under the cursor.
> No matter what I'm typing, M-x picture-mode allows me to draw a picture
> in ASCII graphics. And C-x ( starts a macro -- immensely useful in many
> circumstances.
> 
> Emacs also works over text terminal connections. I use it all the time
> to access virtual machines at the office as well as my home machine from
> overseas.

Emacs 'tries to be everything' in exactly the same way that a 'general purpose
programming language' is too general and by pretending to solve all problems
actually solves none (until you hire a programmer).

Problem with emacs (culture) is that its aficionados assume that a superb 
conceptual design trumps technological relevance, UI clunkiness etc. Which is 
true... within reasonable limits.

For something a little more contemporary (and successful) than mail clients
here's emacs doing git: https://www.youtube.com/watch?v=zobx3T7hGNA

[Did you notice that you used the locutions 'M-$', 'M-x'?
What sense does this 80s terminology make to an emacs uninitiate in 2015?
From seeing my 20-year-olf students suffer all this combined with the 
hopelessness of convincing the emacs folks that we are in 2015, not 1980, I 
conclude this is a losing battle
]

[toc] | [prev] | [next] | [standalone]

#94606

Rustom Mody <rustompmody@gmail.com>:

> Emacs 'tries to be everything' in exactly the same way that a 'general
> purpose programming language' is too general and by pretending to
> solve all problems actually solves none (until you hire a programmer).

Emacs isn't too general. It's just right.

> Problem with emacs (culture) is that its aficionados assume that a
> superb conceptual design trumps technological relevance,

It's relevant to me every day, for business and pleasure.

> [Did you notice that you used the locutions 'M-$', 'M-x'? What sense
> does this 80s terminology make to an emacs uninitiate in 2015?

They can be initiated in mere seconds to that esoteric knowledge.

> From seeing my 20-year-olf students suffer all this

What do your students suffer from? The beauty of the matter is that they
can use any editor they like. They don't have to like or use emacs.

(In some shops you actually virtually *have* to use Eclipse or Visual
Studio or the some such thing. That *is* painful.)

> combined with the hopelessness of convincing the emacs folks that we
> are in 2015, not 1980,

What do you need to convince emacs folks about? Emacs isn't perfect at
everything, but the emacs developers have kept it admirably up to date.
It has been following the quirks of Java, git and MS Exchange even if it
has been an uphill battle.

> I conclude this is a losing battle

What would you like to achieve, exactly?


Marko

[toc] | [prev] | [next] | [standalone]

#94609

On Sunday, July 26, 2015 at 2:06:00 PM UTC+5:30, Marko Rauhamaa wrote:
> Rustom Mody :
> 
> > Emacs 'tries to be everything' in exactly the same way that a 'general
> > purpose programming language' is too general and by pretending to
> > solve all problems actually solves none (until you hire a programmer).
> 
> Emacs isn't too general. It's just right.
> 
> > Problem with emacs (culture) is that its aficionados assume that a
> > superb conceptual design trumps technological relevance,
> 
> It's relevant to me every day, for business and pleasure.
> 
> > [Did you notice that you used the locutions 'M-$', 'M-x'? What sense
> > does this 80s terminology make to an emacs uninitiate in 2015?
> 
> They can be initiated in mere seconds to that esoteric knowledge.

You are being obtuse Marko!

Yeah that 'M-' is what everyone calls Alt can be conveyed in a few seconds
But there are a hundred completely useless pieces of comtemporary-to-emacs
inconsistency:
- What everyone calls a window, emacs calls a frame
- And what emacs calls a window, everyone calls a pane
- What everyone does with C-x emacs does with C-w (and woe betide if you mix that up)
- What everyone calls head (of a list) emacs calls Car (Toyota?)

> 
> > From seeing my 20-year-olf students suffer all this
> 
> What do your students suffer from? The beauty of the matter is that they
> can use any editor they like. They don't have to like or use emacs.
> 
> (In some shops you actually virtually *have* to use Eclipse or Visual
> Studio or the some such thing. That *is* painful.)
> 
> > combined with the hopelessness of convincing the emacs folks that we
> > are in 2015, not 1980,
> 
> What do you need to convince emacs folks about? Emacs isn't perfect at
> everything, but the emacs developers have kept it admirably up to date.
> It has been following the quirks of Java, git and MS Exchange even if it
> has been an uphill battle.
> 
> > I conclude this is a losing battle
> 
> What would you like to achieve, exactly?

Some attitude correction?
That emacs starts its tutorial showing how to use C-p and C-n for what
everyone uses arrows is bad enough.
That the arrow-keys are later found to work quite alright is even worse
and speaks of a ridiculous attitude

[toc] | [prev] | [next] | [standalone]

#94611

On Sun, 26 Jul 2015 01:50:21 -0700, Rustom Mody wrote:

> On Sunday, July 26, 2015 at 2:06:00 PM UTC+5:30, Marko Rauhamaa wrote:
>> Rustom Mody :
>> 
>> > Emacs 'tries to be everything' in exactly the same way that a
>> > 'general purpose programming language' is too general and by
>> > pretending to solve all problems actually solves none (until you hire
>> > a programmer).
>> 
>> Emacs isn't too general. It's just right.
>> 
>> > Problem with emacs (culture) is that its aficionados assume that a
>> > superb conceptual design trumps technological relevance,
>> 
>> It's relevant to me every day, for business and pleasure.
>> 
>> > [Did you notice that you used the locutions 'M-$', 'M-x'? What sense
>> > does this 80s terminology make to an emacs uninitiate in 2015?
>> 
>> They can be initiated in mere seconds to that esoteric knowledge.
> 
> You are being obtuse Marko!
> 
> Yeah that 'M-' is what everyone calls Alt can be conveyed in a few
> seconds But there are a hundred completely useless pieces of
> comtemporary-to-emacs inconsistency:
> - What everyone calls a window, emacs calls a frame - And what emacs
> calls a window, everyone calls a pane - What everyone does with C-x
> emacs does with C-w (and woe betide if you mix that up)
> - What everyone calls head (of a list) emacs calls Car (Toyota?)
> 
> 
>> > From seeing my 20-year-olf students suffer all this
>> 
>> What do your students suffer from? The beauty of the matter is that
>> they can use any editor they like. They don't have to like or use
>> emacs.
>> 
>> (In some shops you actually virtually *have* to use Eclipse or Visual
>> Studio or the some such thing. That *is* painful.)
>> 
>> > combined with the hopelessness of convincing the emacs folks that we
>> > are in 2015, not 1980,
>> 
>> What do you need to convince emacs folks about? Emacs isn't perfect at
>> everything, but the emacs developers have kept it admirably up to date.
>> It has been following the quirks of Java, git and MS Exchange even if
>> it has been an uphill battle.
>> 
>> > I conclude this is a losing battle
>> 
>> What would you like to achieve, exactly?
> 
> Some attitude correction?
> That emacs starts its tutorial showing how to use C-p and C-n for what
> everyone uses arrows is bad enough.
> That the arrow-keys are later found to work quite alright is even worse
> and speaks of a ridiculous attitude

emacs is a great operating system - the only thing it lacks is a good 
text editor ;-)



-- 
Home is the place where, when you have to go there, they have to take you 
in.
		-- Robert Frost, "The Death of the Hired Man"

[toc] | [prev] | [next] | [standalone]

#94621

On 26/07/2015 10:21, alister wrote:
>
> emacs is a great operating system - the only thing it lacks is a good
> text editor ;-)
>

notepad

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#94613

Rustom Mody <rustompmody@gmail.com>:

> You are being obtuse Marko!
>
> Yeah that 'M-' is what everyone calls Alt can be conveyed in a few
> seconds

Often Alt doesn't work. For example, the stupid GUI thinks it can
intercept some Alt key combinations. Then, it's good to know the ESC
prefix functions as Alt.

Also, in some settings, it is not Alt but some other funny Windows or
Mac keyboard key that serves as Meta. It's all explained at the
beginning of the builtin tutorial (C-h t).

> - What everyone calls a window, emacs calls a frame

Emacs called its windows windows long before there were windowing
systems. For example the command M-x other-window (ordinarily bound to
C-x o) would have to be renamed in a radically backward-incompatible
manner if terminology were changed.

> - And what emacs calls a window, everyone calls a pane

Uh, I believe "pane" is used by GUI programmers only. And the meaning is
not exactly the same as the emacs window.

Thing is, an emacs window is a true window in a windowing system
implemented by emacs itself. I must say, too, that it is much more
comfortable to stick to emacs windows in a single frame than working
with multiple frames.

> - What everyone does with C-x emacs does with C-w (and woe betide if you
> mix that up)

I hate typing outside emacs, where the keys mean wrong things.

> - What everyone calls head (of a list) emacs calls Car (Toyota?)

Now you're inventing things.

> That emacs starts its tutorial showing how to use C-p and C-n for what
> everyone uses arrows is bad enough.

From said tutorial:

   Moving from screenful to screenful is useful, but how do you move to
   a specific place within the text on the screen?

   There are several ways you can do this. You can use the arrow keys,
   but it's more efficient to keep your hands in the standard position
   and use the commands C-p, C-b, C-f, and C-n. These characters are
   equivalent to the four arrow keys, like this:

   			  Previous line, C-p
   				  :
   				  :
      Backward, C-b .... Current cursor position .... Forward, C-f
   				  :
   				  :
   			    Next line, C-n

There's nothing I would change in this explanation. I do use the arrow
keys occasionally, but I mostly use the C-p et al.

> That the arrow-keys are later found to work quite alright is even
> worse and speaks of a ridiculous attitude

Please read the tutorial passage again.


Marko

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web