lexical-binding questions

lexical-binding questions

[Thierry Volpiatto]

Hi,
it seem C-M-x is not working as expected in a `lexical-binding' enabled
buffer:

#+BEGIN_SRC emacs-lisp
;; -*- lexical-binding: t -*-

(defun foo ()
  (declare (special bar))
  (let ((bar 2)
        (baz 3))
    #'(lambda () (+ bar baz))))

;; I expect this:

;; (funcall (foo))
;;=>Symbol's value as variable is void: bar

#+END_SRC

However, (funcall (foo)) return 5 until I byte-compile and load the
file.

So my question is how do you evaluate such code when working in a
`lexical-binding' enabled buffer?

Thanks.

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: lexical-binding questions

[Thierry Volpiatto]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> Hi,
> it seem C-M-x is not working as expected in a `lexical-binding' enabled
> buffer:
>
> #+BEGIN_SRC emacs-lisp
> ;; -*- lexical-binding: t -*-
>
> (defun foo ()
>   (declare (special bar))
>   (let ((bar 2)
>         (baz 3))
>     #'(lambda () (+ bar baz))))
>
> ;; I expect this:
>
> ;; (funcall (foo))
> ;;=>Symbol's value as variable is void: bar
>
> #+END_SRC
>
> However, (funcall (foo)) return 5 until I byte-compile and load the
> file.
>
> So my question is how do you evaluate such code when working in a
> `lexical-binding' enabled buffer?
>
> Thanks.

Also, in CL, the declare spec is placed at the beginning of the let
form:

#+BEGIN_SRC lisp
(defun foo ()
  (let ((bar 2)
        (baz 3))
    (declare (special bar))
    #'(lambda () (+ bar baz))))
(foo)
;; => #<FUNCTION (LAMBDA () :IN FOO) {B08BF6D}>
(funcall (foo))
;; =>The variable BAR is unbound.
;;    [Condition of type UNBOUND-VARIABLE]

#+END_SRC

In elisp the declare form need to be placed BEFORE the let form (see
above), otherwise it have no effect.

the manual say:

--8<---------------cut here---------------start------------->8---
 -- Special Form: declare decl-specs...
     This macro is used to make declarations within functions and other
     code.  Common Lisp allows declarations in various locations,
     generally at the beginning of any of the many "implicit `progn's"
     throughout Lisp syntax, such as function bodies, `let' bodies,
     etc.  Currently the only declaration understood by `declare' is
     `special'.
--8<---------------cut here---------------end--------------->8---

So where is the beginning of a let/progn form?

;; here ?
(let ((bar 2))
;; or here ?

Why does it behave differently from CL?

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

BEGIN_SRC..END_SRC (was: lexical-binding questions)

[Eli Zaretskii]

> From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
> Date: Sat, 05 May 2012 08:45:43 +0200
> 
> #+BEGIN_SRC emacs-lisp
> ;; -*- lexical-binding: t -*-
>
> (defun foo ()
>   (declare (special bar))
>   (let ((bar 2)
>         (baz 3))
>     #'(lambda () (+ bar baz))))
>
> ;; I expect this:
>
> ;; (funcall (foo))
> ;;=>Symbol's value as variable is void: bar
>
> #+END_SRC

Do these BEGIN_SRC and END_SRC marks serve some useful purpose in mail
messages?

Re: BEGIN_SRC..END_SRC

[Tom Rauchenwald]

Eli Zaretskii <eliz@gnu.org> writes:

> Do these BEGIN_SRC and END_SRC marks serve some useful purpose in mail
> messages?

In recent Gnus builds it will font lock that part off the message
appropriatly, making it look pretty.

-tom

-- 
Before you diagnose yourself with depression or low self-esteem, 
first make sure that you are not, in fact, simply surrounded by assholes.
                -- William Gibson

Re: BEGIN_SRC..END_SRC

[Eli Zaretskii]

> From: Tom Rauchenwald <sehnsucht.nach.unendlichkeit@quantentunnel.de>
> Date: Sat, 05 May 2012 10:39:32 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Do these BEGIN_SRC and END_SRC marks serve some useful purpose in mail
> > messages?
> 
> In recent Gnus builds it will font lock that part off the message
> appropriatly, making it look pretty.

Thanks, but why isn't this done in general-purpose font-lock of email
messages?  Why limit this to Gnus?

Re: BEGIN_SRC..END_SRC

[Bastien]

Hi Eli,

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Tom Rauchenwald <sehnsucht.nach.unendlichkeit@quantentunnel.de>
>> Date: Sat, 05 May 2012 10:39:32 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Do these BEGIN_SRC and END_SRC marks serve some useful purpose in mail
>> > messages?
>> 
>> In recent Gnus builds it will font lock that part off the message
>> appropriatly, making it look pretty.
>
> Thanks, but why isn't this done in general-purpose font-lock of email
> messages?  Why limit this to Gnus?

Here is the relevant code in lisp/gnus/mm-view.el:

(defun mm-display-org-inline (handle)
  "Show an Org mode text from HANDLE inline."
  (mm-display-inline-fontify handle 'org-mode))

I don't if we can use mm-view.el outside Gnus but if so, it would
be great.

-- 
 Bastien

Re: BEGIN_SRC..END_SRC

[Eli Zaretskii]

> From: Bastien <bzg@gnu.org>
> Cc: Tom Rauchenwald <sehnsucht.nach.unendlichkeit@quantentunnel.de>,  emacs-devel@gnu.org
> Date: Sat, 05 May 2012 15:38:24 +0200
> 
> >> In recent Gnus builds it will font lock that part off the message
> >> appropriatly, making it look pretty.
> >
> > Thanks, but why isn't this done in general-purpose font-lock of email
> > messages?  Why limit this to Gnus?
> 
> Here is the relevant code in lisp/gnus/mm-view.el:
> 
> (defun mm-display-org-inline (handle)
>   "Show an Org mode text from HANDLE inline."
>   (mm-display-inline-fontify handle 'org-mode))
> 
> I don't if we can use mm-view.el outside Gnus but if so, it would
> be great.

It looks like the above fontifies the snippet in a separate buffer
(switching that buffer to the requested major mode), then copies the
result as a string to the display buffer.  But won't the string be
immediately re-fontified in the buffer that displays the email, as
appropriate for the major mode in the email buffer?

Re: BEGIN_SRC..END_SRC

[Bastien]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Bastien <bzg@gnu.org>
>> Cc: Tom Rauchenwald <sehnsucht.nach.unendlichkeit@quantentunnel.de>,  emacs-devel@gnu.org
>> Date: Sat, 05 May 2012 15:38:24 +0200
>> 
>> >> In recent Gnus builds it will font lock that part off the message
>> >> appropriatly, making it look pretty.
>> >
>> > Thanks, but why isn't this done in general-purpose font-lock of email
>> > messages?  Why limit this to Gnus?
>> 
>> Here is the relevant code in lisp/gnus/mm-view.el:
>> 
>> (defun mm-display-org-inline (handle)
>>   "Show an Org mode text from HANDLE inline."
>>   (mm-display-inline-fontify handle 'org-mode))
>> 
>> I don't if we can use mm-view.el outside Gnus but if so, it would
>> be great.
>
> It looks like the above fontifies the snippet in a separate buffer
> (switching that buffer to the requested major mode), then copies the
> result as a string to the display buffer.  

Yes.

> But won't the string be
> immediately re-fontified in the buffer that displays the email, as
> appropriate for the major mode in the email buffer?

I don't think so but I'm not sure.  

From what I understand, Gnus takes care of fontifying at the right
moment, i.e. as the final stage of rendering the message.

-- 
 Bastien

Re: BEGIN_SRC..END_SRC

[Eli Zaretskii]

> From: Bastien <bzg@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Sun, 06 May 2012 18:03:06 +0200
> 
> From what I understand, Gnus takes care of fontifying at the right
> moment, i.e. as the final stage of rendering the message.

If the font-lock is active in the buffer that displays the message, it
will immediately refontify the inserted text.  That is fundamental to
Emacs redisplay.

Re: BEGIN_SRC..END_SRC

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> If the font-lock is active in the buffer that displays the message, it
> will immediately refontify the inserted text. 

Gnus doesn't use font-lock for any of its buffers.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

RE: BEGIN_SRC..END_SRC

[Drew Adams]

> > > Do these BEGIN_SRC and END_SRC marks serve some useful 
> > > purpose in mail messages?
> > 
> > In recent Gnus builds it will font lock that part off the message
> > appropriatly, making it look pretty.

Will the next Gnus version randomly inject spinning globes, "You've WON!!"
banners, and other 1990s animelia?  Can't wait!  Wonder what that will look like
as markup...  Should liven up (and prettify!) the GNU mailing lists.

> Thanks, but why isn't this done in general-purpose font-lock of email
> messages?  Why limit this to Gnus?

Bzzzzt - wrong question.  The question is NOT why we don't extend or generalize
it to other Emacs email paraphernalia besides Gnus.  The question is why we send
this crap at all in plain-text messages?

That such markup might be useful within Org mode or Gnus or even Emacs generally
is no reason to expose it in plain-text mail.

We discourage the use of HTML messages in GNU mailing lists.  But then
Gnus/Org/Emacs goes and rolls its own simulacrum?  And then everyone who is not
using Emacs for mail has the obligatory privilege of seeing the markup?

If Gnus/Emacs wants to render HTML or XML markup, great.  Email clients of many
stripes generally know how to do that, so users do not see the markup itself.

But whatever Gnus/Emacs decides to do about markup and "looking pretty", please
keep the markup out of plain-text messages.  Some mailing list subscribers read
and write mail outside of Emacs (imagine that).  And some mailing lists are
mirrored to newsgroups and websites that can also be accessed without Emacs
(imagine that).

"Font-lock" prettifying doesn't mean a whole lot to the outside world.

(Note: I would have no problem with the GNU mailing lists NOT discouraging HTML
messages.  My point is that we should not (a) discourage HTML and then (b) bring
in some artisanal, Emacs-specific markup through the back door.  HTML and XML at
least provide (more or less) standard markup that is supported by many clients.)

#+END_GNUS

Re: BEGIN_SRC..END_SRC

[Antoine Levitt]

05/05/12 16:35, Drew Adams
>> Thanks, but why isn't this done in general-purpose font-lock of email
>> messages?  Why limit this to Gnus?
>
> Bzzzzt - wrong question.  The question is NOT why we don't extend or generalize
> it to other Emacs email paraphernalia besides Gnus.  The question is why we send
> this crap at all in plain-text messages?
>
> That such markup might be useful within Org mode or Gnus or even Emacs generally
> is no reason to expose it in plain-text mail.
>
> We discourage the use of HTML messages in GNU mailing lists.  But then
> Gnus/Org/Emacs goes and rolls its own simulacrum?  And then everyone who is not
> using Emacs for mail has the obligatory privilege of seeing the markup?
>
> If Gnus/Emacs wants to render HTML or XML markup, great.  Email clients of many
> stripes generally know how to do that, so users do not see the markup itself.
>
> But whatever Gnus/Emacs decides to do about markup and "looking pretty", please
> keep the markup out of plain-text messages.  Some mailing list subscribers read
> and write mail outside of Emacs (imagine that).  And some mailing lists are
> mirrored to newsgroups and websites that can also be accessed without Emacs
> (imagine that).
>
> "Font-lock" prettifying doesn't mean a whole lot to the outside world.
>
> (Note: I would have no problem with the GNU mailing lists NOT discouraging HTML
> messages.  My point is that we should not (a) discourage HTML and then (b) bring
> in some artisanal, Emacs-specific markup through the back door.  HTML and XML at
> least provide (more or less) standard markup that is supported by many clients.)
>
> #+END_GNUS

The main problem with HTML emails is that they may be rendered
completely garbled depending on the viewer. You can't look at a HTML
message in plain text and make sense of it (of course, these days, HTML
messages usually include a sensible multipart plain text). You're very
welcome to completely ignore two lines of the mail. Then again, you're
just looking for a fight (again?) I'm not willing to get into, so feel
free to ignore this message as well.

Presumably it could be implemented by making it a minor mode that is
turned on by gnus/org by default and can also be turned on by other
modes or by the user?

RE: BEGIN_SRC..END_SRC

[Drew Adams]

> The main problem with HTML emails is that they may be rendered
> completely garbled depending on the viewer. You can't look at a HTML
> message in plain text and make sense of it...

I did not at all argue that the mailing list should encourage HTML.

I made the same point, about Org/Gnus/Emacs markup, that YOU are making about
HTML markup: When viewed as plain text, markup is noise/garbage/nonsense.

> You're very welcome to completely ignore two lines of the mail.

Why should users of plain-text email have to see and then mentally "ignore" any
markup at all?  That's the point.

IOW, I apply your feeling about HTML markup to all markup, including stuff like
#+BEGIN_SRC that Emacs might throw into the mix.

> Presumably it could be implemented by making it a minor mode that is
> turned on by gnus/org by default and can also be turned on by other
> modes or by the user?

You are trying to solve the wrong problem, there.

The question is about what actually gets _sent_ in the email.  It is not about
how to turn on/off markup rendering in Emacs.

It's about people who might not use Gnus or any Emacs mail paraphernalia to read
their mail.  Hard to conceive, no doubt, but there are a few.  Your minor mode
means nothing to them.

Can you say "parochial"?  Using Emacs to read/write mail is not the only way to
do so.

Re: BEGIN_SRC..END_SRC

[Peter Münster]

On Sat, May 05 2012, Drew Adams wrote:

> When viewed as plain text, markup is noise/garbage/nonsense.

What about

,----
| code...
`----

or

--8<---------------cut here---------------start------------->8---
code...
--8<---------------cut here---------------end--------------->8---

?


Aren't these even more noise/garbage/nonsense than

#+BEGIN_SRC emacs-lisp
code...
#+END_SRC

then?

-- 
           Peter

RE: BEGIN_SRC..END_SRC

[Drew Adams]

> > When viewed as plain text, markup is noise/garbage/nonsense.
> 
> What about
> ,----
> | code...
> `----
> or
> --8<---------------cut here---------------start------------->8---
> code...
> --8<---------------cut here---------------end--------------->8---
> ?

What about it?

Is someone arguing that those are expected to be rendered specially by email
clients instead of appearing as plain text?  Not I, at least.
 
> Aren't these even more noise/garbage/nonsense than
> #+BEGIN_SRC emacs-lisp
> code...
> #+END_SRC
> then?

We come back to Eli's original question:

 "Do these BEGIN_SRC and END_SRC marks serve
  some useful purpose in mail messages?"

If such scribblings are added by someone in order, as visible text, to point
something out, then it could be argued that yes, the writer at least thought
they added something.

If they are added automatically as markup that is NOT intended to be seen as
such, but is intended to be rendered by an email client, then the answer could
also be yes.  But only if most email clients actually render the markup instead
of showing it as text.  If they show it as text and that was not the intention
then the answer is no, it does not serve a useful purpose.

IOW, if it was intended as plain text then fine (though the writer's judgment
might be questioned).  If it was intended as markup to be rendered then it needs
to be judged as effective markup.  Is it in fact rendered by most email clients?
And do we even want markup messages in this mailing list?  Both questions apply,
if the intention is rendered markup.

This mailing list has decided that users should use plain text instead of
relying on such rendering.  At least in the case of HTML.  And I would hope that
what applies to HTML markup applies a fortiori to much less commonly handled
markup, such as #+BEGIN_SRC.

What if someone intended it to be rendered if possible but otherwise be shown as
plain text - IOW, showing it as plain text was part of the intention?  Can't
argue with that.  If that's what the writer wanted then so be it - see above.

But that's not the answer that was given to Eli's question.  The answer given
was that this markup is intended to be rendered by Gnus, to prettify things.

To that answer I said, (a) in most mail clients it does not work (the intention
is thwarted) and (b) in this mailing list we do not encourage messages that
require rendering.  That's all.

Re: BEGIN_SRC..END_SRC

[John Wiegley]

>>>>> Peter Münster <pmlists@free.fr> writes:

> On Sat, May 05 2012, Drew Adams wrote:
> > When viewed as plain text, markup is noise/garbage/nonsense.
> 
> What about
> 
> ,----
> | code...
> `----
> 
> or
> code...
> ?
> 
> Aren't these even more noise/garbage/nonsense than
> #+BEGIN_SRC emacs-lisp
> code...
> #+END_SRC
> then?

Why not just indent code blocks with space, the way that Markdown does?  It's
readable to all parties.

John

Re: BEGIN_SRC..END_SRC

[Ted Zlatanov]

On Sat, 05 May 2012 16:38:49 -0500 John Wiegley <jwiegley@gmail.com> wrote: 

JW> Why not just indent code blocks with space, the way that Markdown does?  It's
JW> readable to all parties.

It makes copy+paste harder, especially with embedded newlines, and you
can't specify the language[1].  JIRA's {code:LANGUAGE} and {code}
markers are much more sensible.

Ted

[1] http://daringfireball.net/projects/markdown/syntax#precode

Re: BEGIN_SRC..END_SRC

[Miles Bader]

Ted Zlatanov <tzz@lifelogs.com> writes:
> On Sat, 05 May 2012 16:38:49 -0500 John Wiegley <jwiegley@gmail.com> wrote: 
> JW> Why not just indent code blocks with space, the way that
> JW> Markdown does?  It's readable to all parties.
>
> It makes copy+paste harder, especially with embedded newlines, and
> you can't specify the language[1].  JIRA's {code:LANGUAGE} and
> {code} markers are much more sensible.

Still, as something to aid human comprehension -- which is presumably
the main intent (even if not the only one) -- the indented form seems
much better...

I don't really buy the copy-paste argument.  For inserting code into a
message, none of these methods is effort-free; you either intent the
code, or insert some magic strings around it (indenting is probably
easier, at least in Emacs, unless there are special commands to deal
with the situation, in which case all methods are equal).  For
extracting code into a file to test or something, indented code _may_
be more problematic, if indentation is significant (bad Python, bad!),
but in the majority of cases, I think it isn't -- e.g. it's usually
fine to compile a C program where every line has 4 spaces added...

-miles

-- 
Bacchus, n. A convenient deity invented by the ancients as an excuse for
getting drunk.

Re: BEGIN_SRC..END_SRC

[Thien-Thi Nguyen]

() Miles Bader <miles@gnu.org>
() Mon, 07 May 2012 15:23:52 +0900

   Still, as something to aid human comprehension -- which is
   presumably the main intent (even if not the only one) -- the
   indented form seems much better...

How about indented but w/ only opening markup, minus the org-mode
syntax and plus language-specific comment syntax (redundant, but
that's good) as the first line.  Something like:

  ;; -*- emacs-lisp -*-
  (setq confused (not confused))

Here is an intervening column-0 text blurb that also serves to
delimit the code block.

  # -*- shell-script -*-
  confused=`expr 1 - ${confused-1}`
  
This makes copy/paste even more straightforward, and is
recognizable by humans and programs alike (w/ some simple
heuristics, begged/borrowed/stolen from Emacs itself, bonus!).

[Insert your choice of Antoine de Saint-Exupéry quote here. ;-]

Re: BEGIN_SRC..END_SRC

[Ted Zlatanov]

On Sat, 5 May 2012 08:57:29 -0700 "Drew Adams" <drew.adams@oracle.com> wrote: 

DA> I made the same point, about Org/Gnus/Emacs markup, that YOU are making about
DA> HTML markup: When viewed as plain text, markup is noise/garbage/nonsense.

That's entirely untrue.  In plain text, the org-mode markers look very
clean and are easy to ignore AND parse mentally.  MIME and HTML markups
are complete garbage in plain text mode.

DA> Can you say "parochial"?  Using Emacs to read/write mail is not the
DA> only way to do so.

True.  Some people use XEmacs.

Ted

Re: BEGIN_SRC..END_SRC

[Yann Hodique]

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

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

> Bzzzzt - wrong question.  The question is NOT why we don't extend or
> generalize it to other Emacs email paraphernalia besides Gnus.
> The question is why we send this crap at all in plain-text messages?

> That such markup might be useful within Org mode or Gnus or even Emacs
> generally is no reason to expose it in plain-text mail.

> We discourage the use of HTML messages in GNU mailing lists.  But then
> Gnus/Org/Emacs goes and rolls its own simulacrum?  And then everyone
> who is not using Emacs for mail has the obligatory privilege of seeing
> the markup?

Although the comparison with HTML is probably not that fair, I do agree
that it's bad email practice. More importantly, I'm wondering how it
would not be better to leverage the existing RFC1341 that any decent
mailer should implement.

I mean, doing something like this (in gnus mml markup)
<#multipart type=alternative>
<#part type="text/plain" disposition=inline>
(defun plop ()
  nil)
<#/part>
<#part type="application/emacs-lisp" disposition=inline>
(defun plop ()
  nil)
<#/part>
<#/multipart>

that should be rendered as nicely depending on the mailer
capabilities. Like, with lisp fontification in Emacs (Gnus at least),
and in pure-text style in Gmail for example


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

(defun plop ()
  nil)

[-- Attachment #2.2: Type: application/emacs-lisp, Size: 24 bytes --]

[-- Attachment #3: Type: text/plain, Size: 349 bytes --]


So maybe gnus should just make it easier to compose such multipart
messages, and potentially define missing mime types if need be ?
Unless that message is broken in some widely used mailer, that is :)

Yann.

-- 
We say of Muad'dib that he has gone on a journey
into that land where we walk without footprints.

  -- Preamble to the Qizarate Creed

Re: BEGIN_SRC..END_SRC

[Stephen J. Turnbull]

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

Yann Hodique writes:

 > Although the comparison with HTML is probably not that fair,

No, and I would think Drew in particular would avoid comparing a
properly standardized vulgarity to a complete atrocity.  But them's
the breaks.

 > I do agree that it's bad email practice. More importantly, I'm
 > wondering how it would not be better to leverage the existing
 > RFC1341 that any decent mailer should implement.

Good idea, but poor implementation.  IMSEO this:

 > 

[-- Attachment #2: Type: application/emacs-lisp, Size: 752 bytes --]

Re: BEGIN_SRC..END_SRC

[Yann Hodique]

>>>>> "Stephen" == Stephen J Turnbull <stephen@xemacs.org> writes:

> Yann Hodique writes:

>> I do agree that it's bad email practice. More importantly, I'm
>> wondering how it would not be better to leverage the existing
>> RFC1341 that any decent mailer should implement.

> Good idea, but poor implementation.  IMSEO this:

Definitely. That was only meant as a quick and dirty POC. For real life
usage, I'd definitely rather rely on some program (gnus) doing the right
and clean thing :)
Btw I would even be perfectly happy with writing org-mode blocks and
letting gnus figure out how to make it nice.

The point of using application/emacs-lisp was just to demonstrate
something that works *today*. text/lisp or text/emacs-lisp would
definitely be cleaner, but they're not recognized as elisp code by gnus
as of now.

> Now, RFC 2046 section 4.1.4 strongly recommends that an unrecognized
> text type be treated as text/plain, so the multipart alternative
> structure is redundant with my preferred content type of
> text/emacs-lisp.  So any MUA that properly respects the standard will
> just DTRT at no cost.

Yep, except that at least GMail doesn't, and it definitely qualifies as
"widely used". Instead, it displays its infamous "noname"
pseudo-attachment, even though the part was supposed to be inlined in
the first place (which is broken in so many ways it's not even
funny). So I agree in theory, but that doesn't seem practical.

Yann.

-- 
Seek freedom and become captive of your desires.
Seek discipline and find your liberty.

  -- The Coda

Re: BEGIN_SRC..END_SRC

[Julien Danjou]

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

On Sat, May 05 2012, Yann Hodique wrote:

> The point of using application/emacs-lisp was just to demonstrate
> something that works *today*. text/lisp or text/emacs-lisp would
> definitely be cleaner, but they're not recognized as elisp code by gnus
> as of now.

I'm not sure what yo mean by "not recognized", but for me your example
mail shows with the Emacs Lisp code inlined and font-locked by Gnus. And
the result is indeed cleaner than with tags.

-- 
           Julien

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: BEGIN_SRC..END_SRC

[Yann Hodique]

>>>>> "Julien" == Julien Danjou <julien@danjou.info> writes:

> On Sat, May 05 2012, Yann Hodique wrote:
>> The point of using application/emacs-lisp was just to demonstrate
>> something that works *today*. text/lisp or text/emacs-lisp would
>> definitely be cleaner, but they're not recognized as elisp code by gnus
>> as of now.

> I'm not sure what yo mean by "not recognized", but for me your example
> mail shows with the Emacs Lisp code inlined and font-locked by Gnus. And
> the result is indeed cleaner than with tags.

Well, I tried 2 (actually more :)) versions of my mail, and only the one
with application/emacs-lisp MIME type was fontified by Gnus. The same
approach with text/emacs-lisp type didn't show any color in the
article buffer. So I sent the former to the list.

But then maybe my Emacs or Gnus is slightly outdated. I should probably
retry after updating.

Yann.

-- 
Paired opposites define your longings and those longings imprison you.

  -- The Zensunni Whip

RE: BEGIN_SRC..END_SRC

[Drew Adams]

>  > Although the comparison with HTML is probably not that fair,
> 
> No, and I would think Drew in particular would avoid comparing a
> properly standardized vulgarity to a complete atrocity.  But them's
> the breaks.

I'm having trouble telling which, in your eyes, is the "properly standardized
vulgarity" and which is the "complete atrocity".  Does it matter?

In any case, I did not compare HTML markup with Org/Gnus/Emacs markup, however
you might characterize either of them.

What I did was to ask that all such markup be kept out of plain-text messages.

I do not _see_ HTML markup displayed as such in mail messages (instead it is
rendered), but that's because my email client, like _most_, takes care of that.


And that was my other point: Emacs mail clients are not the only mail clients,
or even the most commonly used mail clients.  And even Emacs mail clients
presumably do not display HTML markup in plain-text messages.  Most mail clients
most often DTRT with most HTML markup - they can tell the difference from plain
text.

That's the comparison I made and the one that matters here: not the markup
itself but how it is handled by most email clients.  HTML markup is handled
relatively well by the world; Org/Gnus markup is not.

If most email clients in the wide world recognized Org/Gnus markup and performed
Emacs font-locking on it, then I would not be arguing the second point.  (I
would still argue that such markup does not belong in a message purporting to be
plain text.)

Re: BEGIN_SRC..END_SRC

[Martyn Jago]

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

> Will the next Gnus version randomly inject spinning globes, "You've WON!!"
> banners, and other 1990s animelia?  Can't wait!  Wonder what that will look like
> as markup...  Should liven up (and prettify!) the GNU mailing lists.

Its plain text. And its the sort of thing any org-mode user would do to
identify emacs-lisp without even thinking about it, and its explanatory.

#+begin_src emacs-lisp

(message "hi")

#+end_rrc

If you are aiming to ban the use of plain text because it doesn't appeal
to you, then I will question that. 

Org-mode is a very healthy Emacs library, and a lot of people use it.

Best, Martyn

--

I can say its because I'm British!

RE: BEGIN_SRC..END_SRC

[Drew Adams]

> Its plain text. And its the sort of thing any org-mode user 
> would do to identify emacs-lisp without even thinking about
> it, and its explanatory.

Sure, and there's absolutely nothing wrong with that.

You apparently misunderstood.

> If you are aiming to ban the use of plain text

No.  Again, you apparently misunderstood.  Completely.

> because it doesn't appeal to you,

Plain text does appeal to me.  You apparently misunderstood.

> then I will question that.

Question rather your reading.  Or perhaps your knee-jerking.
Dunno where the problem lies, but something is clearly off.

> Org-mode is a very healthy Emacs library, and a lot of
> people use it.

Of course they do.  And I'm all in favor of it.
Including its markup and other annotations.

You simply misunderstood, clearly.

Re: BEGIN_SRC..END_SRC

[Stephen J. Turnbull]

Martyn Jago writes:

 > [org-mode idioms are] plain text.

If it gets interpreted by a program and concealed because humans
really aren't interested in it, it's not plain text, it's markup.

It's no crime for you to like and advocate this idiom.  But please
don't tell us that white is black, nor that markup is plain text.

Re: BEGIN_SRC..END_SRC

[Wolfgang Jenkner]

On Mon, May 07 2012, Stephen J. Turnbull wrote:

> Martyn Jago writes:
>
>  > [org-mode idioms are] plain text.
>
> If it gets interpreted by a program and concealed because humans
> really aren't interested in it, it's not plain text, it's markup.

Except that it isn't.  Gnus article mode does not hide the #+begin_src /
#+end_src markers.

Wolfgang

Re: BEGIN_SRC..END_SRC

[Stephen J. Turnbull]

Wolfgang Jenkner writes:
 > On Mon, May 07 2012, Stephen J. Turnbull wrote:
 > 
 > > Martyn Jago writes:
 > >
 > >  > [org-mode idioms are] plain text.
 > >
 > > If it gets interpreted by a program and concealed because humans
 > > really aren't interested in it, it's not plain text, it's markup.
 > 
 > Except that it isn't.  Gnus article mode does not hide the #+begin_src /
 > #+end_src markers.

Surely you don't expect that to convince anybody!  The important part
of my sentence is "humans really aren't interested in it".  And they
aren't.  It's not part of the code, it's markup.

There's nothing sinful about having markup in plain text, as Ted Z
pointed out.  The problem here is that this markup is annoying or
ugly to many humans, and doesn't contribute to better understanding
when interpreted as plain text.  It doesn't even make it easier to
type, since it *will* be interpreted as text/plain in many
subscribers' MUAs, so it *must* be preformatted as code.

You can and should argue that some annoyance to the many is justified
by the benefits to the org-mode/Gnus users.  But I find that rather
unconvincing, because there are alternative, less obtrusive, ways to
get (code-aware) MUAs (eg, Gnus) to format code specially, such as a
private text/program-code MIME type, or use of a "-*- <mode> -*-"
comment.  These would be more generally useful, and maybe non-Emacs
MUAs would implement them.  As you probably suspect, I prefer the MIME
type approach (it's invisible to users of MIME-capable MUAs) but the
"-*-" convention might work too.  (It has been adopted as a protocol
by other projects, including Python's PEP 263).

My suggestion doesn't even prevent org-mode users from using that
convention, as long as message-mode recognizes it and converts it to a
MIME part.  Sure, this will take a bit of effort since Gnus did it the
other way around, but that was a suboptimal.  It should be improved.

Re: BEGIN_SRC..END_SRC

[Bastien]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Wolfgang Jenkner writes:
>  > On Mon, May 07 2012, Stephen J. Turnbull wrote:
>  > 
>  > > Martyn Jago writes:
>  > >
>  > >  > [org-mode idioms are] plain text.
>  > >
>  > > If it gets interpreted by a program and concealed because humans
>  > > really aren't interested in it, it's not plain text, it's markup.
>  > 
>  > Except that it isn't.  Gnus article mode does not hide the #+begin_src /
>  > #+end_src markers.
>
> Surely you don't expect that to convince anybody!  The important part
> of my sentence is "humans really aren't interested in it".  And they
> aren't.  It's not part of the code, it's markup.

This markup easily reads as "This is the beginning/end of source code
written in Emacs lisp".  I think this is useful and readable information
for a human.

-- 
 Bastien

Re: BEGIN_SRC..END_SRC

[Juanma Barranquero]

On Tue, May 8, 2012 at 9:37 AM, Bastien <bzg@gnu.org> wrote:

> This markup easily reads as "This is the beginning/end of source code
> written in Emacs lisp".  I think this is useful and readable information
> for a human.

Not useful, because the human already can see that it is Emacs Lisp
code. And if by "readable" you mean "it's not so ugly and intrusive
that makes the whole message unparsable", well, yeah, not *that* ugly
and intrusive. It's still pretty ugly and makes reading the message
harder.

    Juanma

Re: BEGIN_SRC..END_SRC

[Stefan Monnier]

> Not useful, because the human already can see that it is Emacs Lisp
> code. And if by "readable" you mean "it's not so ugly and intrusive
> that makes the whole message unparsable", well, yeah, not *that* ugly
> and intrusive. It's still pretty ugly and makes reading the message
> harder.

Yes, it has 2 problems:
1- it's ugly.
2- it does make the code harder to read.
Separators like "---------------------" work much better in this
respect, because they don't contain words and so they're much more
easily abstracted away by your "eyes".


        Stefan

Re: BEGIN_SRC..END_SRC

[Andreas Röhler]

Am 08.05.2012 14:17, schrieb Stefan Monnier:
>> Not useful, because the human already can see that it is Emacs Lisp
>> code. And if by "readable" you mean "it's not so ugly and intrusive
>> that makes the whole message unparsable", well, yeah, not *that* ugly
>> and intrusive. It's still pretty ugly and makes reading the message
>> harder.
>
> Yes, it has 2 problems:
> 1- it's ugly.
> 2- it does make the code harder to read.
> Separators like "---------------------" work much better in this
> respect, because they don't contain words and so they're much more
> easily abstracted away by your "eyes".
>
>
>          Stefan
>
>

why not have just another exporter into plain-message-style or whatever?


Cheers

Andreas

Re: BEGIN_SRC..END_SRC

[Stephen J. Turnbull]

Andreas Röhler writes:

 > why not have just another exporter into plain-message-style or whatever?

Where?  As Ted Z pointed out, this is a plain text convention, so some
author deliberately put it there.  There no "exporter" present.

Anyway, there is no technical solution to this discussion, as the
org-mode crowd seems to *want* to see this markup.

<rant>I'd rather see XML!  But YMMV...</rant>  ;-)

Re: BEGIN_SRC..END_SRC

[Stefan Monnier]

> org-mode crowd seems to *want* to see this markup.

This discussion has nothing to do with Org, but about email messages.
So if the org-mode crowd wants to see this markup in their Org buffers,
all the more power to them, but it doesn't have to imply anything on the
side of email messages.


        Stefan

Re: BEGIN_SRC..END_SRC

[Ted Zlatanov]

On Tue, 08 May 2012 08:17:37 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> 1- [org-mode source markup]'s ugly.

I sort of agree, and like the JIRA {code:LANGUAGE} ... {code} markup
better.  Visually they are very clean.

SM> 2- it does make the code harder to read.
SM> Separators like "---------------------" work much better in this
SM> respect, because they don't contain words and so they're much more
SM> easily abstracted away by your "eyes".

The problem with those separators is just that they say nothing about
the contents, so the presenter (MUA) has to guess the content type,
which requires some parsing and can easily result in a wrong guess.

If you are going to ask emacs-devel posters not to use org-mode markup,
go ahead.  A better alternative may be to consider it an individual
choice, like quoting with spaces ala RMS or using Supercite
initial-based quotes as I do.  On the Gnus side it would be nice to
start recognizing Markdown and JIRA source code markup, which would make
the org-mode markup less necessary.  And maybe the other Emacs-based
MUAs could reuse whatever code interprets the markup, so it would be
good to write it as a parser.

In the context of an Emacs markup parser library, do you agree or would
you rather I keep the work only on the Gnus side?  And is there an
existing library to do this job?  I'm not aware of one.

Thanks!
Ted

Re: BEGIN_SRC..END_SRC

[Miles Bader]

Ted Zlatanov <tzz@lifelogs.com> writes:
> The problem with those separators is just that they say nothing about
> the contents, so the presenter (MUA) has to guess the content type,
> which requires some parsing and can easily result in a wrong guess.

Why it important for the MUA to know the content type of embedded code
snippets?

The main target is human readers, who can figure out that stuff with
almost zero effort from context and/or looking at the code.

AFAICT, this sort of feature stems more from "OMGWIBN" ("OMG, wouldn't
it be neat!") syndrome than actual demand...

Given the lack of actual demand, even a minor impact on readability is
too much.  [The current behavior of Gnus, certainly, is just awful in
this respect -- not only are the delimiters ugly and detrimental to
readability, but so is the visual highlighting (on my system, a wacky
bright green color) that seems to be the only thing Gnus does with
it...!]

-Miles

-- 
Fast, small, soon; pick any 2.

Re: BEGIN_SRC..END_SRC

[Ted Zlatanov]

On Wed, 09 May 2012 12:50:20 +0900 Miles Bader <miles@gnu.org> wrote: 

MB> Ted Zlatanov <tzz@lifelogs.com> writes:
>> The problem with those separators is just that they say nothing about
>> the contents, so the presenter (MUA) has to guess the content type,
>> which requires some parsing and can easily result in a wrong guess.

MB> Why it important for the MUA to know the content type of embedded code
MB> snippets?

So they can be colored properly, mostly.  I can imagine other uses like
saving, parsing, and a "run this" buttong for Emacs Lisp code, but it's
presentational so far.

MB> AFAICT, this sort of feature stems more from "OMGWIBN" ("OMG, wouldn't
MB> it be neat!") syndrome than actual demand...

You know we're talking about Gnus, right?

In any case, there is demand, at least 10 users like the markup and use
it, including myself.  We don't want to bother with MIME for short snippets.

MB> Given the lack of actual demand, even a minor impact on readability is
MB> too much.  [The current behavior of Gnus, certainly, is just awful in
MB> this respect -- not only are the delimiters ugly and detrimental to
MB> readability, but so is the visual highlighting (on my system, a wacky
MB> bright green color) that seems to be the only thing Gnus does with
MB> it...!]

The coloring is done by whatever mode is used for whatever language is
specified in the markup.  So the green color is your fault ;)

The key question is, do you disagree with any delimiters, including the
JIRA {code:LANGUAGE} ... {code} markers?  So far most people have said
the org-mode markers specifically are ugly, but some kind of marker is
OK.  So in my followup to Stefan Monnier I proposed a parser library to
identify markup generically.

On Wed, 09 May 2012 07:45:41 +0300 Eli Zaretskii <eliz@gnu.org> wrote: 

EZ> FYI: That's not "quoting ala RMS", that's simply the default quoting
EZ> style of Rmail.

OK; my point was that it's unusual and only RMS uses it in this
newsgroup or anywhere else I've seen in mailing lists or newsgroups, so
it's unique in that context.

Ted

Re: BEGIN_SRC..END_SRC

[Stephen J. Turnbull]

Ted Zlatanov writes:

 > We don't want to bother with MIME for short snippets.

Then what do you think your MUA is there for?

Re: BEGIN_SRC..END_SRC

[Lars Magne Ingebrigtsen]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

>  > We don't want to bother with MIME for short snippets.
>
> Then what do you think your MUA is there for?

The support for embedding small snippets via MIME is dicey in some mail
readers, last time I looked.  They present(ed) the first textual part as
the only visible text, and presented the rest as attachments.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: BEGIN_SRC..END_SRC

[Eric Schulte]

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

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> "Stephen J. Turnbull" <stephen@xemacs.org> writes:
>
>>  > We don't want to bother with MIME for short snippets.
>>
>> Then what do you think your MUA is there for?
>
> The support for embedding small snippets via MIME is dicey in some mail
> readers, last time I looked.  They present(ed) the first textual part as
> the only visible text, and presented the rest as attachments.

To contribute to the bikeshedding [1], I've composed an example email in
gnus with inline Org-mode-syntax code, inline mime-annotated code, and
attached (disposition=inline) code.  The results as displayed by gnus,
gmail and gmx are shown [2].  I don't know if gnus should limit itself
based on the limitations of non-standards-compliant commercial software,
but at the least it would seem that while the mime approach /should/ be
the most portable it will in fact not be portable to many (maybe most)
other MUAs.

Since the only non-mime option is some sort of inline markup, although I
personally don't mind the Org-mode syntax, I also like the indentation
based suggestion as shown here.

    ;; -*- emacs-lisp -*-
    (defun foo () "bar" :baz)

The only question there being how often would indented non-code be
accidentally interpreted by gnus as code?  Also, this solution is
potentially more Emacs-specific than the existing Org-mode syntax.  The
following (attached disposition=inline) elisp works as an initial
implementation of this behavior on my system.


[-- Attachment #2: indented-code.el --]
[-- Type: application/emacs-lisp, Size: 1020 bytes --]

[-- Attachment #3: Type: text/plain, Size: 128 bytes --]


Best,

Footnotes: 
[1]  http://bikeshed.com/

[2]  http://i.imgur.com/FBA53.png

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: BEGIN_SRC..END_SRC

[Yann Hodique]

>>>>> "Eric" == Eric Schulte <eric.schulte@gmx.com> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>> "Stephen J. Turnbull" <stephen@xemacs.org> writes:
>> 
>>> > We don't want to bother with MIME for short snippets.
>>> 
>>> Then what do you think your MUA is there for?
>> 
>> The support for embedding small snippets via MIME is dicey in some mail
>> readers, last time I looked.  They present(ed) the first textual part as
>> the only visible text, and presented the rest as attachments.

> To contribute to the bikeshedding [1], I've composed an example email in
> gnus with inline Org-mode-syntax code, inline mime-annotated code, and
> attached (disposition=inline) code.  The results as displayed by gnus,
> gmail and gmx are shown [2].  I don't know if gnus should limit itself
> based on the limitations of non-standards-compliant commercial software,
> but at the least it would seem that while the mime approach /should/ be
> the most portable it will in fact not be portable to many (maybe most)
> other MUAs.

Note that it's the reason why my initial proposal was based on inline
multipart alternative. Providing a MIME fallback that any MUA should
recognize (such as text/plain) should increase vastly the chances of
proper formatting. At least GMail behaves "correctly" when the
text/plain alternative is provided.

Yann.

-- 
We do what we must.  Friendship and loyalty be damned.  We do what we must!

  -- LADY HELENA ATREIDES,
her personal journals

Re: BEGIN_SRC..END_SRC

[Eric Schulte]

Yann Hodique <yann.hodique@gmail.com> writes:

>>>>>> "Eric" == Eric Schulte <eric.schulte@gmx.com> writes:
>
>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>>> "Stephen J. Turnbull" <stephen@xemacs.org> writes:
>>> 
>>>> > We don't want to bother with MIME for short snippets.
>>>> 
>>>> Then what do you think your MUA is there for?
>>> 
>>> The support for embedding small snippets via MIME is dicey in some mail
>>> readers, last time I looked.  They present(ed) the first textual part as
>>> the only visible text, and presented the rest as attachments.
>
>> To contribute to the bikeshedding [1], I've composed an example email in
>> gnus with inline Org-mode-syntax code, inline mime-annotated code, and
>> attached (disposition=inline) code.  The results as displayed by gnus,
>> gmail and gmx are shown [2].  I don't know if gnus should limit itself
>> based on the limitations of non-standards-compliant commercial software,
>> but at the least it would seem that while the mime approach /should/ be
>> the most portable it will in fact not be portable to many (maybe most)
>> other MUAs.
>
> Note that it's the reason why my initial proposal was based on inline
> multipart alternative. Providing a MIME fallback that any MUA should
> recognize (such as text/plain) should increase vastly the chances of
> proper formatting. At least GMail behaves "correctly" when the
> text/plain alternative is provided.
>

Yes, and gmx displays text/plain alternatives as well (although it also
includes the text as an attachment).  Unfortunately when the text/plain
alternative is provided Gnus does *not* fontify the text/x-sh preferred
alternative but instead renders the plain text -- which sort of defaults
the purpose of the whole exercise.

Also, this approach requires either some explicit function call or some
new markup to mime-encode code examples as part of message composition.

Best,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: BEGIN_SRC..END_SRC

[Yann Hodique]

>>>>> "Eric" == Eric Schulte <eric.schulte@gmx.com> writes:

> Yann Hodique <yann.hodique@gmail.com> writes:
>> 
>> Note that it's the reason why my initial proposal was based on inline
>> multipart alternative. Providing a MIME fallback that any MUA should
>> recognize (such as text/plain) should increase vastly the chances of
>> proper formatting. At least GMail behaves "correctly" when the
>> text/plain alternative is provided.
>> 

> Yes, and gmx displays text/plain alternatives as well (although it also
> includes the text as an attachment).  Unfortunately when the text/plain
> alternative is provided Gnus does *not* fontify the text/x-sh preferred
> alternative but instead renders the plain text -- which sort of defaults
> the purpose of the whole exercise.

Really ? that sounds like a gnus bug then. I mean, if the text/plain
alternative is positioned correctly (meaning *first*), and there's no
fancy customization of `mm-discouraged-alternatives', the text/x-sh one
should indeed be preferred.
At least it worked as expected with the application/emacs-lisp pieces.

Yann.

-- 
Nature commits no errors; right and wrong are human categories.

  -- PARDOT KYNES, Arrakis Lectures

Re: BEGIN_SRC..END_SRC

[Eric Schulte]

Yann Hodique <yann.hodique@gmail.com> writes:

>>>>>> "Eric" == Eric Schulte <eric.schulte@gmx.com> writes:
>
>> Yann Hodique <yann.hodique@gmail.com> writes:
>>> 
>>> Note that it's the reason why my initial proposal was based on inline
>>> multipart alternative. Providing a MIME fallback that any MUA should
>>> recognize (such as text/plain) should increase vastly the chances of
>>> proper formatting. At least GMail behaves "correctly" when the
>>> text/plain alternative is provided.
>>> 
>
>> Yes, and gmx displays text/plain alternatives as well (although it also
>> includes the text as an attachment).  Unfortunately when the text/plain
>> alternative is provided Gnus does *not* fontify the text/x-sh preferred
>> alternative but instead renders the plain text -- which sort of defaults
>> the purpose of the whole exercise.
>
> Really ? that sounds like a gnus bug then. I mean, if the text/plain
> alternative is positioned correctly (meaning *first*), and there's no
> fancy customization of `mm-discouraged-alternatives', the text/x-sh
> one should indeed be preferred.  At least it worked as expected with
> the application/emacs-lisp pieces.
>

OK, I had mixed up the first/second priority.  If I swap the order and I
switch from text/x-emacs-lisp to text/x-sh I can get gnus to fontify the
results, although there is also a "[2. text/x-sh]" button included in my
buffer.  Regardless, some additional work will be required.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: BEGIN_SRC..END_SRC

[Yann Hodique]

>>>>> "Eric" == Eric Schulte <eric.schulte@gmx.com> writes:

> OK, I had mixed up the first/second priority.  If I swap the order and I
> switch from text/x-emacs-lisp to text/x-sh I can get gnus to fontify the
> results, although there is also a "[2. text/x-sh]" button included in my
> buffer.  Regardless, some additional work will be required.

Probably you also have "multipart/alternative" in your
`gnus-buttonized-mime-types' list (as do I), but that's not the
default :)

Yann.

-- 
What senses do we lack that we cannot see or hear another world all around us?

  -- The Orange Catholic Bible

Re: BEGIN_SRC..END_SRC

[Stephen J. Turnbull]

Eric Schulte writes:

 > Yes, and gmx displays text/plain alternatives as well (although it also
 > includes the text as an attachment).  Unfortunately when the text/plain
 > alternative is provided Gnus does *not* fontify the text/x-sh preferred
 > alternative but instead renders the plain text -- which sort of defaults
 > the purpose of the whole exercise.

No, it doesn't, because Gnus can be fixed to conform.  In this case, I
suspect that either the message was improperly composed with the
alternatives in the wrong order[1] (ie, Gnus behaves correctly on the
reading end at least), or Gnus doesn't handle text/x-sh but only
application/x-sh or text/sh or something like that.

 > Also, this approach requires either some explicit function call or some
 > new markup to mime-encode code examples as part of message composition.

The (non-alternative) 'type="text/whatever"' approach doesn't require
either, and even if Gnus currently doesn't handle it correctly, adding
a check for "text/emacs-lisp" etc in the same place where it currently
checks for "application/emacs-lisp" will make it work fine.

Footnotes: 
[1]  Order matters because "the alternatives appear in an order of
increasing faithfulness to the original content.  In general, the
best choice is the LAST part of a type supported by the recipient
system's local environment." -- RFC 2046

Re: BEGIN_SRC..END_SRC

[Stephen J. Turnbull]

Eric Schulte writes:

 > To contribute to the bikeshedding [1],

No discussion of MIME can reasonably be characterized as bikeshedding.
There's another kind of discussion that can be abbreviated to BS
that's often an appropriate description, but not bikeshedding.

You see, in Parkinson's original fable, the bikeshed is something
everybody has knowledge of, and therefore was competent to offer
comment.  But the litmus test for being competent to discuss MIME (or
any mail RFC, for that matter) is the sinking feeling that you're
beyond your depth.  And even if you feel that way, you still might not
qualify! ;-)

 > I've composed an example email in gnus with inline Org-mode-syntax
 > code, inline mime-annotated code, and attached (disposition=inline)
 > code.  The results as displayed by gnus, gmail and gmx are shown
 > [2].  I don't know if gnus should limit itself based on the
 > limitations of non-standards-compliant commercial software,

No, at least in this case Gmail and gmx are behaving conformantly;
there is no requirement that an MUA implement any kind of behavior for
the "application" content type, except providing a way to save the
media to a file.  Which they did.

Gnus is not incorrect, but it *is* behaving non-portably by providing
a display method for the rare and non-portable (and probably
unregistered) MIME type "application/emacs-lisp".

Use "Content-Type: text/emacs-lisp" and see what happens.

 > but at the least it would seem that while the mime approach /should/ be
 > the most portable it will in fact not be portable to many (maybe most)
 > other MUAs.

The MIME *approach* probably *is* portable; you didn't test it.

The MIME *type* application/emacs-lisp is *non*-portable.  That's
exactly what the "application" type is for.

Re: BEGIN_SRC..END_SRC

[Yann Hodique]

>>>>> "Stephen" == Stephen J Turnbull <stephen@xemacs.org> writes:

> No, at least in this case Gmail and gmx are behaving conformantly;
> there is no requirement that an MUA implement any kind of behavior for
> the "application" content type, except providing a way to save the
> media to a file.  Which they did.

> Gnus is not incorrect, but it *is* behaving non-portably by providing
> a display method for the rare and non-portable (and probably
> unregistered) MIME type "application/emacs-lisp".

> Use "Content-Type: text/emacs-lisp" and see what happens.

As I said in a previous mail, it doesn't change anything for GMail, and
that is also (unfortunately) conformant.

Basically GMail displays *any* content-type it doesn't know about
(including the text/emacs-lisp or text/lisp variants) as an attachment
named "noname", exactly as shown in Eric's screenshot. That's obviously
a bad idea and not in the spirit of RFC 2046 (which says in 4.1.4 that
those *should* be treated as text/plain), but I'm not sure anybody at
Google really cares :)
A fallback to application/octet-stream, which is probably what's
happening here, is indeed correct...

> The MIME *approach* probably *is* portable; you didn't test it.

> The MIME *type* application/emacs-lisp is *non*-portable.  That's
> exactly what the "application" type is for.

Agreed, and again we should definitely teach Emacs/Gnus to recognize
some text/something for elisp code.
As of today, when attaching or inlining emacs-lisp code in a Gnus
message, the default value for mime type is that application/emacs-lisp,
and that's a bug.

Only that last part we can fix. So in any case, I don't believe we can
ever afford not to emit the text/plain alternative for dumb (yet
potentially even conformant) MUAs.

Given that, since Emacs is probably the only "MUA" that will ever
implement a handler for any elisp-related MIME type, whether it's
text/emacs-lisp or application/emacs-lisp is probably not that much of
an issue (but again, we should use the former)

Yann.

-- 
The capacity to learn is a gift; The ability to learn is a skill; The 
willingness to learn is a choice.

  -- REBEC OF GINAZ

Re: BEGIN_SRC..END_SRC

[Stephen J. Turnbull]

Yann Hodique writes:
 >>>>> "Stephen" == Stephen J Turnbull <stephen@xemacs.org> writes:

 > > Use "Content-Type: text/emacs-lisp" and see what happens.
 > 
 > As I said in a previous mail, it doesn't change anything for GMail, and
 > that is also (unfortunately) conformant.

I disagree.  It may be unfortunate, but it is not conformant.  To
quote the RFCs:

4.1.4.  Unrecognized Subtypes

   Unrecognized subtypes of "text" should be treated as subtype "plain"
   as long as the MIME implementation knows how to handle the charset.
   Unrecognized subtypes which also specify an unrecognized charset
   should be treated as "application/octet-stream". -- RFC 2046

The word "should" in an RFC has a precise (and to many, surprisingly
strong) meaning:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course. -- RFC 2119

So it isn't optional behavior.  It's required.  It's simply the case
that the authors of RFC 2046 could imagine stuff like Microsoft HTML,
in which case you probably want to treat text/html as binary if you
don't have a decent HTML rendering engine to use.  However, "should"
in the section 4.1.4 is not blanket permission to treat all unknown
text/* as application/octet-stream, as Gmail apparently does.

 > Only [Gnus] we can fix. So in any case, I don't believe we can
 > ever afford not to emit the text/plain alternative for dumb (yet
 > potentially even conformant) MUAs.

Maybe.

But given that we know that Gmail deliberately goes out of its way to
suck in our community (eg, encouraging top-posting, which has its
place but it ain't here[1]), I don't really think we should consider
problems with Gmail an argument against using standard constructs.  If
Thunderbird or nmh or mutt has issues or whatever-the-GNOMEish-MUA-is
does, that's another matter.

 > Given that, since Emacs is probably the only "MUA" that will ever
 > implement a handler for any elisp-related MIME type, whether it's
 > text/emacs-lisp or application/emacs-lisp is probably not that much of
 > an issue (but again, we should use the former)

No, it's the *only* issue here.  If we use text/emacs-lisp, people who
use conformant MUAs have a choice of font-locked display or plain
text.  If we use application/emacs-lisp, people who use conformant
MUAs have a choice of font-locked display or saving it to a file.


Footnotes: 
[1]  Tevye: Rabbi, is there a blessing for the Czar?
     Rabbi: Of course, my son.  (sonorously) May God bless and keep
     the Czar ... (with emphasis) far away from us!

Re: BEGIN_SRC..END_SRC

[Yann Hodique]

>>>>> "Stephen" == Stephen J Turnbull <stephen@xemacs.org> writes:

> Yann Hodique writes:
>> 
>> As I said in a previous mail, it doesn't change anything for GMail, and
>> that is also (unfortunately) conformant.

> I disagree.  It may be unfortunate, but it is not conformant.  To
> quote the RFCs:

[...]

> So it isn't optional behavior.  It's required.  It's simply the case
> that the authors of RFC 2046 could imagine stuff like Microsoft HTML,
> in which case you probably want to treat text/html as binary if you
> don't have a decent HTML rendering engine to use.  However, "should"
> in the section 4.1.4 is not blanket permission to treat all unknown
> text/* as application/octet-stream, as Gmail apparently does.

Well, let's not go to nit-picking about issues we can't solve anyway :)
The behavior is clearly broken, and I'm also not confident anybody will
fix it (they might even pretend that's intentional for whatever twisted
reason, or that the phrasing doesn't have to respect an RFC that was
written at a later point in time). I personally wouldn't fight for
a "should".

>> Only [Gnus] we can fix. So in any case, I don't believe we can
>> ever afford not to emit the text/plain alternative for dumb (yet
>> potentially even conformant) MUAs.

> Maybe.

> But given that we know that Gmail deliberately goes out of its way to
> suck in our community (eg, encouraging top-posting, which has its
> place but it ain't here[1]), I don't really think we should consider
> problems with Gmail an argument against using standard constructs.  If
> Thunderbird or nmh or mutt has issues or whatever-the-GNOMEish-MUA-is
> does, that's another matter.

Let's focus on the matter at hand :)
The fact is people use GMail to access the mailing list, and I don't see
a point in annoying them gratuitously. By gratuitously I mean choosing
a standard construct they (and probably others) don't recognize over
another standard construct they (and probably others) do recognize.
That's an argument *for* using standard constructs, just not *any*
standard construct.

>> Given that, since Emacs is probably the only "MUA" that will ever
>> implement a handler for any elisp-related MIME type, whether it's
>> text/emacs-lisp or application/emacs-lisp is probably not that much of
>> an issue (but again, we should use the former)

> No, it's the *only* issue here.  If we use text/emacs-lisp, people who
> use conformant MUAs have a choice of font-locked display or plain
> text.  If we use application/emacs-lisp, people who use conformant
> MUAs have a choice of font-locked display or saving it to a file.

That's not what I mean. What I'm saying is:

1. "application/emacs-lisp" will work mostly (only?) in Gnus

2. "text/emacs-lisp" will work on conformant MUAs, but is broken in
   common ones. It might also be font-locked in some MUAs, eventually

3. "text/plain + application/emacs-lisp" will work (potentially
   sub-optimally) on conformant MUAs and in common ones. It is also
   font-locked in Gnus

4. "text/plain + text/emacs-lisp" will work on conformant MUAs and in
   common ones. It might also be font-locked in some MUAs, eventually

You're saying 2. is better that 1., which I totally agree with.
What I'm saying is that 4. is even better because it's just as standard,
and better supported overall.

And as a side note, I'm saying that the MUAs that might do something
fancy with an elisp MIME type are probably all running in Emacs, so that
realistically 3. and 4. are not that different. Meaning that 3. is
probably kind of acceptable in the short term (as long as Gnus is not
fixed) even though it's dodgy.

Also note that none of application/emacs-lisp or text/emacs-lisp are
registered MIME types. That's *also* something that should be fixed,
and presumably before Gnus starts getting fixed.

Yann.

-- 
Heaven must be the sound of running water.

  -- Fremen Saying

Re: BEGIN_SRC..END_SRC

[Miles Bader]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
>  > Only [Gnus] we can fix. So in any case, I don't believe we can
>  > ever afford not to emit the text/plain alternative for dumb (yet
>  > potentially even conformant) MUAs.
>
> Maybe.
>
> But given that we know that Gmail deliberately goes out of its way
> to suck in our community (eg, encouraging top-posting, which has its
> place but it ain't here[1]), I don't really think we should consider
> problems with Gmail an argument against using standard constructs.
> If Thunderbird or nmh or mutt has issues or
> whatever-the-GNOMEish-MUA-is does, that's another matter.

That doesn't make any sense at all.... Gmail doesn't "go out of it's
way to suck in our community" any more than any other popular mail
client does; AFAICT, its main sin is that they too readily follow bad
examples set by _other_ popular mail MUAs...  [Top-posting being the
obvious example:  annoying may it be, it's pretty much the way things
are done everywhere except the hardcore ye-olde-unix-users community;
people _expect_ it.]

Gmail is representive of "the unwashed wider world", although it's far
better than many other common examples of such.  Much of the fancy
cool stuff Gnus does correctly is badly supported _everywhere_, not
just by gmail.  So while I think it's silly to ignore gmail, because
it's vastly more popular than Gnus, if you still want to for whatever
reason, it _still_ seems a bad idea to ignore the general class of
mail clients it represents....

I think that basically, unless you _know_ that most of your readership
is using Gnus or some other client that properly handles all these
funny cases, you have to be kind of conservative in what you send.

It sucks I suppose, but whatever.  To be honest, correct font-locking
of Emacs lisp is such a fringe issue that it's hard to care very
much...

-miles

-- 
We live, as we dream -- alone....

Re: BEGIN_SRC..END_SRC

[Stephen J. Turnbull]

Miles Bader writes:

 > That doesn't make any sense at all.... Gmail doesn't "go out of it's
 > way to suck in our community" any more than any other popular mail
 > client does; AFAICT, its main sin is that they too readily follow bad
 > examples set by _other_ popular mail MUAs...

OK, I'll concede that.  Nevertheless, it does suck in our community,
on *both* ends.  It encourages posting practices poorly adapted to
technical discussion, and it sucks as a list-traffic reader.  (I know,
because for several weeks it was my list-traffic reader.)

 > just by gmail.  So while I think it's silly to ignore gmail, because
 > it's vastly more popular than Gnus, if you still want to for whatever
 > reason, it _still_ seems a bad idea to ignore the general class of
 > mail clients it represents....

In general, yes.  On emacs-devel (and other technically-oriented lists
I frequent), I would say the balance between pointless annoyance and
the irritability that proves you're alive (and induces you to make a
change for the better) is a net zero.  Using the standard as intended
and thus setting a good example tips the balance *for me*.  IMHO YMMV
FWIW and all those other good 4-letter acronyms.

Re: BEGIN_SRC..END_SRC

[Davis Herring]

> 4.1.4.  Unrecognized Subtypes
> 
>    Unrecognized subtypes of "text" should be treated as subtype "plain"
>    as long as the MIME implementation knows how to handle the charset.
>    Unrecognized subtypes which also specify an unrecognized charset
>    should be treated as "application/octet-stream". -- RFC 2046
> 
> The word "should" in an RFC has a precise (and to many, surprisingly
> strong) meaning:
> 
> 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>    may exist valid reasons in particular circumstances to ignore a
>    particular item, but the full implications must be understood and
>    carefully weighed before choosing a different course. -- RFC 2119

As RFC 2046 doesn't contain the "are to be interpreted as described in
RFC 2119." verbiage (which is not surprising, since it's older!), it
doesn't seem so plain to me that the (lowercase) "should" in 2046/4.1.4
should (hah!) be interpreted so strongly.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: BEGIN_SRC..END_SRC

[Stephen J. Turnbull]

Davis Herring writes:

 > As RFC 2046 doesn't contain the "are to be interpreted as described in
 > RFC 2119." verbiage (which is not surprising, since it's older!), it
 > doesn't seem so plain to me that the (lowercase) "should" in 2046/4.1.4
 > should (hah!) be interpreted so strongly.

You'd have to specifically ask the authors of RFC 2046.  Nevertheless,
I stand by my interpretation, because RFC 2119, like all RFCs, is
based on best practice.  I think it likely that RFC 2046 conforms to
best practice of its time, which is contemporaneous with 2119.

Re: BEGIN_SRC..END_SRC

[René Kyllingstad]

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

On Thu, May 10, 2012 at 9:28 AM, Stephen J. Turnbull <stephen@xemacs.org>wrote:
>
> The MIME *approach* probably *is* portable; you didn't test it.
>
> The MIME *type* application/emacs-lisp is *non*-portable.  That's
> exactly what the "application" type is for.
>

What is the MIME approach to handling text that is perfectly fine to
display plainly, but can be optionally enhanced with for example syntax
highlighting?

Are MUAs supposed to have a list of all of them? Wouldn't it be better with
"Content-type: text/plain/elisp" or some such?

Naïvely,


-- René

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

Re: BEGIN_SRC..END_SRC

[Stephen J. Turnbull]

René Kyllingstad writes:

 > What is the MIME approach to handling text that is perfectly fine to
 > display plainly, but can be optionally enhanced with for example syntax
 > highlighting?

The MIME approach is to *define* "text" as "content that is perfectly
fine to display plainly"!

From RFC 2046:

   Beyond plain text, there are many formats for representing what might
   be known as "rich text".  An interesting characteristic of many such
   representations is that they are to some extent readable even without
   the software that interprets them.  It is useful, then, to
   distinguish them, at the highest level, from such unreadable data as
   images, audio, or text represented in an unreadable form. In the
   absence of appropriate interpretation software, it is reasonable to
   show subtypes of "text" to the user, while it is not reasonable to do
   so with most nontextual data.

Later it defines text/plain, and imposes the requirement that if the
MUA encounters a text/whatever it doesn't understand, it should treat
it as text/plain (unless it can't determine the character set).

This is exactly what you said, translated to RFC-ese.  Unusually sane
for an RFC. ;-)

 > Are MUAs supposed to have a list of all of them?

Yes!  In the sense that if the MUA wants to do something special with
the subtypes of text, then it needs to know what they all are.  If it
doesn't care, it should treat them all as text/plain.

 > Wouldn't it be better with "Content-type: text/plain/elisp" or some such?

The "plain" is redundant, because all subtypes of text fall back to
text/plain anyway.

Re: BEGIN_SRC..END_SRC

[René Kyllingstad]

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

On Thu, May 10, 2012 at 3:05 PM, Stephen J. Turnbull <stephen@xemacs.org>wrote:

> René Kyllingstad writes:
>
>  > What is the MIME approach to handling text that is perfectly fine to
>  > display plainly, but can be optionally enhanced with for example syntax
>  > highlighting?
>
> The MIME approach is to *define* "text" as "content that is perfectly
> fine to display plainly"!
>
> From RFC 2046:
>
>   Beyond plain text, there are many formats for representing what might
>   be known as "rich text".  An interesting characteristic of many such
>   representations is that they are to some extent readable even without
>   the software that interprets them.  It is useful, then, to
>   distinguish them, at the highest level, from such unreadable data as
>   images, audio, or text represented in an unreadable form. In the
>   absence of appropriate interpretation software, it is reasonable to
>   show subtypes of "text" to the user, while it is not reasonable to do
>   so with most nontextual data.
>
> Later it defines text/plain, and imposes the requirement that if the
> MUA encounters a text/whatever it doesn't understand, it should treat
> it as text/plain (unless it can't determine the character set).
>
> This is exactly what you said, translated to RFC-ese.  Unusually sane
> for an RFC. ;-)
>

IMHO there is a crucial difference between "perfectly fine" and "to some
extent readable". It seems the MIME authors disagree.


>   > Are MUAs supposed to have a list of all of them?
>
> Yes!  In the sense that if the MUA wants to do something special with
> the subtypes of text, then it needs to know what they all are.  If it
> doesn't care, it should treat them all as text/plain.


>  > Wouldn't it be better with "Content-type: text/plain/elisp" or some
> such?
>
> The "plain" is redundant, because all subtypes of text fall back to
> text/plain anyway.
>

Redundant seems a bit harsh to me.

I would prefer Gmail to treat text/rtf different from text/elisp: text/rtf
should by default either be displayed with the markup interpreted or as a
download, whereas text/elisp should be displayed as text/plain.

This changes the implementation from a simple catch-all to a white-list or
black-list, a far less slam-dunk proposal for an esoteric MUA feature. Sigh.


-- René

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

Re: BEGIN_SRC..END_SRC

[Stephen J. Turnbull]

René Kyllingstad writes:

 > IMHO there is a crucial difference between "perfectly fine" and "to some
 > extent readable". It seems the MIME authors disagree.

I rather doubt that they disagree with you. The MIME authors simply
thought about it carefully and came to the conclusion that (1)
subtypes of text are necessary for enhanced display, which is *very*
desirable, while (2) implementation costs imply that not all MUAs will
implement all subtypes, and (3) the dividing line between "perfectly
fine" (and therefore not urgent to implement) subtypes and "to some
extent readable" (and therefore of relatively high implementation
priority) can and must be delegated to implementers, both of the types
themselves (who are the ones who register the MIME content type, see
below) and of the MUAs that interpret them.

 > >  > Wouldn't it be better with "Content-type: text/plain/elisp" or some
 > > such?
 > >
 > > The "plain" is redundant, because all subtypes of text fall back to
 > > text/plain anyway.
 > 
 > Redundant seems a bit harsh to me.
 > 
 > I would prefer Gmail to treat text/rtf different from text/elisp: text/rtf
 > should by default either be displayed with the markup interpreted or as a
 > download, whereas text/elisp should be displayed as text/plain.

Sure, but that's up to Gmail; if Gmail doesn't do it your way, you can
(a) live with it, (b) get Gmail to change it, (c) change to a
different MUA that does it your way, or (d) write your own MUA that
gets it right.  The needed information is there; adding yet another
level of subtype doesn't improve the situation.  Note that you just
can't win: if the designers of RTF agreed with you, they would have
registered the content type as application/rtf rather than text/rtf.
I gather that they disagree with you, and so if there *were* a
text/plain/emacs-lisp, you'd also see text/plain/rtf, and there's no
improvement.

That is, you *can* get what you want under the standard as written, at
some cost.  And the way the standard is written, in any standard-
conforming MUA, we both get something we can work with, even though we
don't agree on optimal behavior (I want to see text/rtf, you don't).

Re: BEGIN_SRC..END_SRC

[Ted Zlatanov]

On Wed, 09 May 2012 15:43:57 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> "Stephen J. Turnbull" <stephen@xemacs.org> writes:
>> > We don't want to bother with MIME for short snippets.
>> 
>> Then what do you think your MUA is there for?

LMI> The support for embedding small snippets via MIME is dicey in some mail
LMI> readers, last time I looked.  They present(ed) the first textual part as
LMI> the only visible text, and presented the rest as attachments.

Seconded, from experience with many MUAs.

Ted

Re: BEGIN_SRC..END_SRC

[Tassilo Horn]

Ted Zlatanov <tzz@lifelogs.com> writes:

> MB> Given the lack of actual demand, even a minor impact on
> MB> readability is too much.  [The current behavior of Gnus,
> MB> certainly, is just awful in this respect -- not only are the
> MB> delimiters ugly and detrimental to readability, but so is the
> MB> visual highlighting (on my system, a wacky bright green color)
> MB> that seems to be the only thing Gnus does with it...!]
>
> The coloring is done by whatever mode is used for whatever language is
> specified in the markup.  So the green color is your fault ;)

Really?  By default?  I'm running emacs from bzr and gnus from git, and
it's all green.

Bye,
Tassilo

Re: BEGIN_SRC..END_SRC

[Tassilo Horn]

Tassilo Horn <tassilo@member.fsf.org> writes:

>> MB> Given the lack of actual demand, even a minor impact on
>> MB> readability is too much.  [The current behavior of Gnus,
>> MB> certainly, is just awful in this respect -- not only are the
>> MB> delimiters ugly and detrimental to readability, but so is the
>> MB> visual highlighting (on my system, a wacky bright green color)
>> MB> that seems to be the only thing Gnus does with it...!]
>>
>> The coloring is done by whatever mode is used for whatever language is
>> specified in the markup.  So the green color is your fault ;)
>
> Really?  By default?  I'm running emacs from bzr and gnus from git, and
> it's all green.

Ah, my fault.  I had some code in my ~/.gnus.el which made those org
source blocks show up as verbatim text.  That was from the time before
Gnus handled those.

Bye,
Tassilo

Re: BEGIN_SRC..END_SRC

[Stefan Monnier]

> We don't want to bother with MIME for short snippets.

Assuming a nice command (or even textual convention in your message-mode
buffer) to "mark this chunk as MIME element of type <foobar>", I can't
see why you wouldn't be happy with this solution which will work nicely
in many more MUAs.


        Stefan

Re: BEGIN_SRC..END_SRC

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Tue, 08 May 2012 20:47:41 -0400
> 
> A better alternative may be to consider it an individual choice,
> like quoting with spaces ala RMS

FYI: That's not "quoting ala RMS", that's simply the default quoting
style of Rmail.

Re: BEGIN_SRC..END_SRC

[Tassilo Horn]

Ted Zlatanov <tzz@lifelogs.com> writes:

> SM> 1- [org-mode source markup]'s ugly.
>
> I sort of agree, and like the JIRA {code:LANGUAGE} ... {code} markup
> better.  Visually they are very clean.
>
> SM> 2- it does make the code harder to read.
> SM> Separators like "---------------------" work much better in this
> SM> respect, because they don't contain words and so they're much more
> SM> easily abstracted away by your "eyes".
>
> The problem with those separators is just that they say nothing about
> the contents, so the presenter (MUA) has to guess the content type,
> which requires some parsing and can easily result in a wrong guess.

I'm usually able to infer the content type from the sender or mailing
list.  If it's on emacs-devel, it's most probably emacs lisp or C.

That said, I'm not annoyed by the org babel delimiters, but at the same
time, I don't see any benefit in them.  If Gnus would actually use the
explicitly stated language to fontify the snippet with the corresponding
emacs mode, that would be a big benefit.  That seems feasible, because
Org mode does so if `org-src-fontify-natively' is non-nil.

But as it is right now, it's just as fine as the usual:

--8<---------------cut here---------------start------------->8---
foo = bar + baz
--8<---------------cut here---------------end--------------->8---

Bye,
Tassilo

Re: BEGIN_SRC..END_SRC

[Peter Münster]

On Wed, May 09 2012, Tassilo Horn wrote:

> But as it is right now, it's just as fine as the usual:
>
> --8<---------------cut here---------------start------------->8---
> foo = bar + baz
> --8<---------------cut here---------------end--------------->8---

The funny thing is, that Gnus and Gmane do not agree about the markup:
http://article.gmane.org/gmane.emacs.devel/150384

(look at the "start" and the "end", Lars ;)

-- 
           Peter

Re: BEGIN_SRC..END_SRC

[Lars Magne Ingebrigtsen]

Peter Münster <pmlists@free.fr> writes:

> The funny thing is, that Gnus and Gmane do not agree about the markup:
> http://article.gmane.org/gmane.emacs.devel/150384
>
> (look at the "start" and the "end", Lars ;)

:-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: BEGIN_SRC..END_SRC

[Stefan Monnier]

SM> 2- it does make the code harder to read.
SM> Separators like "---------------------" work much better in this
SM> respect, because they don't contain words and so they're much more
SM> easily abstracted away by your "eyes".

> The problem with those separators is just that they say nothing about
> the contents, so the presenter (MUA) has to guess the content type,
> which requires some parsing and can easily result in a wrong guess.

That can be fixed without making the whole thing illegible.
E.g.

-------------------------------------------------------- emacs-lisp
(defun sm-foo ()
  (try that))
--------------------------------------------------------

This said, I find

   (defun sm-foo ()
     (try that))

to be a lot more legible anyway, even without any fancy coloring.
If we want to get more fancy, then I think MIME is a good solution.


        Stefan

Re: BEGIN_SRC..END_SRC

[Miles Bader]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
> This said, I find
>
>    (defun sm-foo ()
>      (try that))
>
> to be a lot more legible anyway, even without any fancy coloring.

This.

"fancier" is not synonymous with "more readable", and even fairly
minimal markup can be distracting, _especially_ for short code
snippets.

-miles

-- 
Neighbor, n. One whom we are commanded to love as ourselves, and who does all
he knows how to make us disobedient.

Re: BEGIN_SRC..END_SRC

[Ted Zlatanov]

On Wed, 09 May 2012 13:36:33 -0400 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 

SM> This said, I find

SM>    (defun sm-foo ()
SM>      (try that))

SM> to be a lot more legible anyway, even without any fancy coloring.

OK, so inline Markdown markup looks good to you.  I think Gnus can
support it together with JIRA-style tags ({code:LANGUAGE}...{code}).

Ted

Re: BEGIN_SRC..END_SRC

[Eric Schulte]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Wed, 09 May 2012 13:36:33 -0400 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 
>
> SM> This said, I find
>
> SM>    (defun sm-foo ()
> SM>      (try that))
>
> SM> to be a lot more legible anyway, even without any fancy coloring.
>
> OK, so inline Markdown markup looks good to you.  I think Gnus can
> support it together with JIRA-style tags ({code:LANGUAGE}...{code}).
>

FWIW, I've been using the indented markup implementation from my
previous email for a week or so now and it seems fairly robust (it
hasn't trashed any mail so far).  I'll include it here if there is any
interest in using it.  After loading the following and re-viewing this
email in gnus, the code will be font-locked.

    ;; -*- emacs-lisp -*-
    (require 'mm-uu)

    (defvar indented-src-code-start-regexp
      "^    .*-\\*- \\(mode:\\)?\\([^[:space:]]+?\\)\\(-mode\\)? -\\*-")

    (defvar indented-src-code-end-regexp
      "^ ? ? ?[^[:space:]].*$")

    (defvar indented-src-code-lang)

    (defun mm-uu-indented-src-code-test ()
      (setq indented-src-code-lang
            (and (save-excursion (goto-char (point-at-bol))
                                 (looking-at indented-src-code-start-regexp))
                 (match-string 2))))

    (defun mm-uu-indented-src-code-extract ()
      (if indented-src-code-lang
          (mm-make-handle (mm-uu-copy-to-buffer start-point end-point)
                          (list (concat
                                 (if (string= indented-src-code-lang "emacs-lisp")
                                     "application/" "text/x-")
                                 indented-src-code-lang) ))
        (mm-uu-verbatim-marks-extract 0 0)))

    (add-to-list 'mm-uu-type-alist
                 `(indented-src-code
                   ,indented-src-code-start-regexp
                   ,indented-src-code-end-regexp
                   mm-uu-indented-src-code-extract
                   mm-uu-indented-src-code-test))

    (mm-uu-configure)

>
> Ted
>
>

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

plain-text markdown handler for Gnus (was: BEGIN_SRC..END_SRC)

[Ted Zlatanov]

On Wed, 16 May 2012 09:05:09 -0400 Eric Schulte <eric.schulte@gmx.com> wrote: 

ES> Ted Zlatanov <tzz@lifelogs.com> writes:
>> On Wed, 09 May 2012 13:36:33 -0400 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 
>> 
SM> This said, I find
>> 
SM> (defun sm-foo ()
SM> (try that))
>> 
SM> to be a lot more legible anyway, even without any fancy coloring.
>> 
>> OK, so inline Markdown markup looks good to you.  I think Gnus can
>> support it together with JIRA-style tags ({code:LANGUAGE}...{code}).
>> 

ES> FWIW, I've been using the indented markup implementation from my
ES> previous email for a week or so now and it seems fairly robust (it
ES> hasn't trashed any mail so far).  I'll include it here if there is any
ES> interest in using it.  After loading the following and re-viewing this
ES> email in gnus, the code will be font-locked.

[general mm-uu handler omitted]

This is very nice but I think it's also nice to use the `markdown'
processor directly (as markdown-mode does).  It will handle more of the
Markdown markup and generates HTML which we can then inline.  I'm not
sure--can anyone with Markdown experience comment?  This would be
Gnus-specific because the HTML result would then be part of the article
buffer.

Also it would be very useful to detect Markdown automatically based on
some traits, like 4-space indented quotes and the other Markdown markup.

Ted

Re: plain-text markdown handler for Gnus

[Eric Schulte]

Ted Zlatanov <tzz@lifelogs.com> writes:

>
> [general mm-uu handler omitted]
>
> This is very nice but I think it's also nice to use the `markdown'
> processor directly (as markdown-mode does).  It will handle more of the
> Markdown markup and generates HTML which we can then inline.

Oh, I thought the goal was a message fontification tool, but it sounds
like you're proposing a tool for composing HTML email.

> I'm not sure--can anyone with Markdown experience comment?  This would
> be Gnus-specific because the HTML result would then be part of the
> article buffer.
>

There does exist a very similar Org-mode based tool for composing and
sending HTML email [1].  This tool converts inline Org-mode to HTML
(with a plain text multipart/alternative) inline in the message and the
results render correctly (including attached HTML images) in at least
gnus, Thunderbird and Gmail.

>
> Also it would be very useful to detect Markdown automatically based on
> some traits, like 4-space indented quotes and the other Markdown markup.
>

Maybe automatically converting indented code to the relevant text/x-lang
mime type (with a text alternative) would be simpler but achieve much of
the desired effect?

Best,

>
> Ted
>
>


Footnotes: 
[1]  http://orgmode.org/worg/org-contrib/org-mime.html

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: plain-text markdown handler for Gnus

[Ted Zlatanov]

On Wed, 16 May 2012 10:21:58 -0400 Eric Schulte <eric.schulte@gmx.com> wrote: 

ES> Ted Zlatanov <tzz@lifelogs.com> writes:
>> 
>> [general mm-uu handler omitted]
>> 
>> This is very nice but I think it's also nice to use the `markdown'
>> processor directly (as markdown-mode does).  It will handle more of the
>> Markdown markup and generates HTML which we can then inline.

ES> Oh, I thought the goal was a message fontification tool, but it sounds
ES> like you're proposing a tool for composing HTML email.

I mean that if we detect Markdown in the text message, we can pick that
up, pipe it through `markdown', take the resulting HTML, and splice that
into the text as fontified HTML.  No composition support is implied, and
the message should be plain text only.

Ted

Re: BEGIN_SRC..END_SRC

[Ted Zlatanov]

On Sat, 5 May 2012 07:35:29 -0700 "Drew Adams" <drew.adams@oracle.com> wrote: 

DA> We discourage the use of HTML messages in GNU mailing lists.  But then
DA> Gnus/Org/Emacs goes and rolls its own simulacrum?  And then everyone who is not
DA> using Emacs for mail has the obligatory privilege of seeing the
DA> markup?

Yup.

DA> (Note: I would have no problem with the GNU mailing lists NOT discouraging HTML
DA> messages.  My point is that we should not (a) discourage HTML and then (b) bring
DA> in some artisanal, Emacs-specific markup through the back door.  HTML and XML at
DA> least provide (more or less) standard markup that is supported by many clients.)

Nope.

Ted

Re: BEGIN_SRC..END_SRC

[Lennart Borgman]

On Sun, May 6, 2012 at 4:15 PM, Ted Zlatanov <tzz@lifelogs.com> wrote:
> On Sat, 5 May 2012 07:35:29 -0700 "Drew Adams" <drew.adams@oracle.com> wrote:
>
> DA> We discourage the use of HTML messages in GNU mailing lists.  But then
> DA> Gnus/Org/Emacs goes and rolls its own simulacrum?  And then everyone who is not
> DA> using Emacs for mail has the obligatory privilege of seeing the
> DA> markup?
>
> Yup.

Free software is dependent on standard, or??

> DA> (Note: I would have no problem with the GNU mailing lists NOT discouraging HTML
> DA> messages.  My point is that we should not (a) discourage HTML and then (b) bring
> DA> in some artisanal, Emacs-specific markup through the back door.  HTML and XML at
> DA> least provide (more or less) standard markup that is supported by many clients.)
>
> Nope.

Which commonly used mail clients (outside of Emacs) does not support html today?

Re: BEGIN_SRC..END_SRC

[Alan Mackenzie]

Hi, Lennart.

On Sun, May 06, 2012 at 04:18:03PM +0200, Lennart Borgman wrote:
> On Sun, May 6, 2012 at 4:15 PM, Ted Zlatanov <tzz@lifelogs.com> wrote:
> > On Sat, 5 May 2012 07:35:29 -0700 "Drew Adams" <drew.adams@oracle.com> wrote:

> > DA> We discourage the use of HTML messages in GNU mailing lists.  But then
> > DA> Gnus/Org/Emacs goes and rolls its own simulacrum?  And then everyone who is not
> > DA> using Emacs for mail has the obligatory privilege of seeing the
> > DA> markup?

> > Yup.

> Free software is dependent on standard, or??

> > DA> (Note: I would have no problem with the GNU mailing lists NOT discouraging HTML
> > DA> messages.  My point is that we should not (a) discourage HTML and then (b) bring
> > DA> in some artisanal, Emacs-specific markup through the back door.  HTML and XML at
> > DA> least provide (more or less) standard markup that is supported by many clients.)

> > Nope.

> Which commonly used mail clients (outside of Emacs) does not support html today?

mutt.  At least, not without dreary configuration.

I'm all for keeping HTML strictly out of GNU list messages.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: BEGIN_SRC..END_SRC

[Lennart Borgman]

On Sun, May 6, 2012 at 4:33 PM, Alan Mackenzie <acm@muc.de> wrote:
> Hi, Lennart.
>
> On Sun, May 06, 2012 at 04:18:03PM +0200, Lennart Borgman wrote:
>> On Sun, May 6, 2012 at 4:15 PM, Ted Zlatanov <tzz@lifelogs.com> wrote:
>> > On Sat, 5 May 2012 07:35:29 -0700 "Drew Adams" <drew.adams@oracle.com> wrote:
>
>> > DA> We discourage the use of HTML messages in GNU mailing lists.  But then
>> > DA> Gnus/Org/Emacs goes and rolls its own simulacrum?  And then everyone who is not
>> > DA> using Emacs for mail has the obligatory privilege of seeing the
>> > DA> markup?
>
>> > Yup.
>
>> Free software is dependent on standard, or??
>
>> > DA> (Note: I would have no problem with the GNU mailing lists NOT discouraging HTML
>> > DA> messages.  My point is that we should not (a) discourage HTML and then (b) bring
>> > DA> in some artisanal, Emacs-specific markup through the back door.  HTML and XML at
>> > DA> least provide (more or less) standard markup that is supported by many clients.)
>
>> > Nope.
>
>> Which commonly used mail clients (outside of Emacs) does not support html today?
>
> mutt.  At least, not without dreary configuration.
>
> I'm all for keeping HTML strictly out of GNU list messages.

I am also for keeping the messages as plain text.

Re: BEGIN_SRC..END_SRC

[Ted Zlatanov]

On Sun, 6 May 2012 16:18:03 +0200 Lennart Borgman <lennart.borgman@gmail.com> wrote: 

LB> On Sun, May 6, 2012 at 4:15 PM, Ted Zlatanov <tzz@lifelogs.com> wrote:
>> On Sat, 5 May 2012 07:35:29 -0700 "Drew Adams" <drew.adams@oracle.com> wrote:
>> 
DA> We discourage the use of HTML messages in GNU mailing lists.  But then
DA> Gnus/Org/Emacs goes and rolls its own simulacrum?  And then everyone who is not
DA> using Emacs for mail has the obligatory privilege of seeing the
DA> markup?
>> 
>> Yup.

LB> Free software is dependent on standard, or??

"The nice thing about standards is that you have so many to choose from."
Andrew S. Tanenbaum, Computer Networks, 2nd ed.

Please realize Drew is grandstanding about two extra lines in e-mail
messages, *voluntarily* placed there by the author.

Now go read the MIME standard in its entirety and weep.

DA> (Note: I would have no problem with the GNU mailing lists NOT discouraging HTML
DA> messages.  My point is that we should not (a) discourage HTML and then (b) bring
DA> in some artisanal, Emacs-specific markup through the back door.  HTML and XML at
DA> least provide (more or less) standard markup that is supported by many clients.)
>> 
>> Nope.

LB> Which commonly used mail clients (outside of Emacs) does not support html today?

HTML and XML are a complex framework of standards and I'm willing to bet
very few mail clients support them fully or need to.

Drew was probably talking about MIME as a way to identify and tag
attachments, but has merged that notion with HTML because his argument
works better against HTML (meaning, MIME is not discouraged on the GNU
mailing lists AFAIK).  Regardless, Gnus supports inlined MIME
attachments and will highlight them correctly, so there's no implicit
endorsement by Gnus of either the org-mode or the MIME way to inline
code.

Very few mail clients don't support MIME, but the org-mode markup is
much more like Markdown and such light wiki-style languages[1] than
MIME.  In other words, you may as well complain about *emphasis*,
_underline_, `quote', and such ad-hoc ways to highlight content.

I hope this clears things up.

Ted

[1] e.g. JIRA uses {code:LANGUAGE} and {code} to indicate the beginning
and end of code blocks, while Markdown indents code blocks 4 spaces
without indicating the specific language.

Re: BEGIN_SRC..END_SRC

[Lennart Borgman]

On Sun, May 6, 2012 at 8:57 PM, Ted Zlatanov <tzz@lifelogs.com> wrote:
> On Sun, 6 May 2012 16:18:03 +0200 Lennart Borgman <lennart.borgman@gmail.com> wrote:
>
>
> LB> Which commonly used mail clients (outside of Emacs) does not support html today?
>
> HTML and XML are a complex framework of standards and I'm willing to bet
> very few mail clients support them fully or need to.

How much? ;-)

I believe most mail clients uses HTML libraries that are available for
developers. (Free and non-free.)

Re: BEGIN_SRC..END_SRC

[Ted Zlatanov]

On Mon, 7 May 2012 01:20:00 +0200 Lennart Borgman <lennart.borgman@gmail.com> wrote: 

LB> On Sun, May 6, 2012 at 8:57 PM, Ted Zlatanov <tzz@lifelogs.com> wrote:
>> On Sun, 6 May 2012 16:18:03 +0200 Lennart Borgman <lennart.borgman@gmail.com> wrote:
>> 
LB> Which commonly used mail clients (outside of Emacs) does not support html today?
>> 
>> HTML and XML are a complex framework of standards and I'm willing to bet
>> very few mail clients support them fully or need to.

LB> How much? ;-)

LB> I believe most mail clients uses HTML libraries that are available for
LB> developers. (Free and non-free.)

I don't think the full extent of the nightmarish HTML standards (there
are several) needs to be discussed, though you should look at them if
only for your amusement.  It's just hard to support HTML fully in a MUA
without turning it into a web browser.

(Microsoft Outlook, for instance, has terrible HTML support for several
releases that are still commonly used.  Many CSS attributes just don't
work in the preview pane.  This is relevant because it's hard to fontify
code reliably in the Outlook preview pane without explictly stating the
font color and style for each span.  This was my experience 4 years
ago.)

But as I said already, we're really talking about MIME attachments and
how the org-mode ad-hoc markup compares to them, not HTML.  My comment
was tangential.

Ted

Re: BEGIN_SRC..END_SRC

[Lennart Borgman]

On Mon, May 7, 2012 at 4:21 AM, Ted Zlatanov <tzz@lifelogs.com> wrote:
> On Mon, 7 May 2012 01:20:00 +0200 Lennart Borgman <lennart.borgman@gmail.com> wrote:
>
> LB> On Sun, May 6, 2012 at 8:57 PM, Ted Zlatanov <tzz@lifelogs.com> wrote:
>>> On Sun, 6 May 2012 16:18:03 +0200 Lennart Borgman <lennart.borgman@gmail.com> wrote:
>>>
> LB> Which commonly used mail clients (outside of Emacs) does not support html today?
>>>
>>> HTML and XML are a complex framework of standards and I'm willing to bet
>>> very few mail clients support them fully or need to.
>
> LB> How much? ;-)
>
> LB> I believe most mail clients uses HTML libraries that are available for
> LB> developers. (Free and non-free.)
>
> I don't think the full extent of the nightmarish HTML standards (there
> are several) needs to be discussed, though you should look at them if
> only for your amusement.  It's just hard to support HTML fully in a MUA
> without turning it into a web browser.

If you use the same HTML libraries as the web browser it is just as
hard as in a web browser.

> (Microsoft Outlook, for instance, has terrible HTML support for several
> releases that are still commonly used.  Many CSS attributes just don't
> work in the preview pane.  This is relevant because it's hard to fontify
> code reliably in the Outlook preview pane without explictly stating the
> font color and style for each span.  This was my experience 4 years
> ago.)

IE did not follow standards very good at that time.

> But as I said already, we're really talking about MIME attachments and
> how the org-mode ad-hoc markup compares to them, not HTML.  My comment
> was tangential.

Ok.

Re: BEGIN_SRC..END_SRC

[Stephen J. Turnbull]

Ted Zlatanov writes:

 > Please realize Drew is grandstanding about two extra lines in e-mail
 > messages, *voluntarily* placed there by the author.

Top-posting is also a voluntary act of the author, but we don't
hesitate to criticize that.

I think the right question to ask is whether relaxing the restriction
to plain text for the sake of nicer presentation for org-mode/Gnus
users is good for Emacs.

 > [Y]ou may as well complain about *emphasis*,
 > _underline_, `quote', and such ad-hoc ways to highlight content.

Your point about the definition of "markup" is very well-taken; these
ad-hoc highlights are indeed markup.

However, there is an important difference.  A human being has very
little trouble detecting code injected into the flow of a narrative
text, and authors do format code to look like code, so as to be
readable in plain text MUAs.  Thus, the org-mode code markers are
primarily *presentation* markup for the benefit of programs.

On the contrary, it is often impossible (without markup) for human
beings to determine where emphasis in plain text is, so (like smileys)
such *semantic* markup is for humans, and appropriate in plain text,
just as punctuation, such as colons and quotations marks, is
appropriate in plain text.  Nor is MIME useful for such markup: it can
only provide a container (ie, a text/$MARKUP body part) to pass to the
actual markup interpreter.

Re: lexical-binding questions

[Stefan Monnier]

> Also, in CL, the declare spec is placed at the beginning of the let
[...]
> Why does it behave differently from CL?

Because it forces the interpreter to check for the presence of
a `declare' every time it sees a `let', even though it will only find
one once per century or so.
It's an OK design for a language where there's always going to be
a pre-processing of some sort before evaluation but for Emacs's pure
naive interpreter it's inconvenient.


        Stefan

Re: lexical-binding questions

[Thierry Volpiatto]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Also, in CL, the declare spec is placed at the beginning of the let
> [...]
>> Why does it behave differently from CL?
>
> Because it forces the interpreter to check for the presence of
> a `declare' every time it sees a `let', even though it will only find
> one once per century or so.
> It's an OK design for a language where there's always going to be
> a pre-processing of some sort before evaluation but for Emacs's pure
> naive interpreter it's inconvenient.
Ok, thanks for explanations.

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: lexical-binding questions

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Also, in CL, the declare spec is placed at the beginning of the let
> [...]
>> Why does it behave differently from CL?
>
> Because it forces the interpreter to check for the presence of
> a `declare' every time it sees a `let', even though it will only find
> one once per century or so.
> It's an OK design for a language where there's always going to be
> a pre-processing of some sort before evaluation but for Emacs's pure
> naive interpreter it's inconvenient.

It doesn't seem _that_ inconvenient (or inefficient)...

-miles

-- 
Conservative, n. A statesman enamored of existing evils, as opposed to a
Liberal, who wants to replace them with new ones.

Re: lexical-binding questions

[Stefan Monnier]

>>> Also, in CL, the declare spec is placed at the beginning of the let
>> [...]
>>> Why does it behave differently from CL?
>> Because it forces the interpreter to check for the presence of
>> a `declare' every time it sees a `let', even though it will only find
>> one once per century or so.
>> It's an OK design for a language where there's always going to be
>> a pre-processing of some sort before evaluation but for Emacs's pure
>> naive interpreter it's inconvenient.
> It doesn't seem _that_ inconvenient (or inefficient)...

We could live with it if we had no choice, yes.  But given the fact that
current Elisp already uses (defvar <foo>) for that purpose and that
Elisp has no intention to morph into CL, I think the current design
makes a lot more sense.


        Stefan

Re: lexical-binding questions

[Thierry Volpiatto]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Because it forces the interpreter to check for the presence of
> a `declare' every time it sees a `let', even though it will only find
> one once per century or so.
Maybe not now we have lexical-binding, the use of `declare' would become
more common.


-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: lexical-binding questions

[Stefan Monnier]

> it seem C-M-x is not working as expected in a `lexical-binding' enabled
> buffer:

> #+BEGIN_SRC emacs-lisp
> ;; -*- lexical-binding: t -*-

> (defun foo ()
>   (declare (special bar))
>   (let ((bar 2)
>         (baz 3))
>     #'(lambda () (+ bar baz))))

> ;; I expect this:

> ;; (funcall (foo))
> ;;=>Symbol's value as variable is void: bar

> #+END_SRC

> However, (funcall (foo)) return 5 until I byte-compile and load the
> file.

What makes you think this has something to do with C-M-x?  AFAICT it's
just a difference between interpreted and compiled code, because
CL's (declare (special bar)) has not been adapted to lexical-binding.

> So my question is how do you evaluate such code when working in a
> `lexical-binding' enabled buffer?

You don't use (declare (special bar)).


        Stefan

Re: lexical-binding questions

[Thierry Volpiatto]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> it seem C-M-x is not working as expected in a `lexical-binding' enabled
>> buffer:
>
>> #+BEGIN_SRC emacs-lisp
>> ;; -*- lexical-binding: t -*-
>
>> (defun foo ()
>>   (declare (special bar))
>>   (let ((bar 2)
>>         (baz 3))
>>     #'(lambda () (+ bar baz))))
>
>> ;; I expect this:
>
>> ;; (funcall (foo))
>> ;;=>Symbol's value as variable is void: bar
>
>> #+END_SRC
>
>> However, (funcall (foo)) return 5 until I byte-compile and load the
>> file.
>
> What makes you think this has something to do with C-M-x?

Nothing, I was just saying the evaluation of function is not working as
expected, i.e the behavior of the function is different if one use C-M-x
or if one compile/load code.

> AFAICT it's just a difference between interpreted and compiled code,
> because CL's (declare (special bar)) has not been adapted to
> lexical-binding.

Now we have lexical-binding in Emacs, it could be nice to implement the
declare features of CL. (inline too)

>> So my question is how do you evaluate such code when working in a
>> `lexical-binding' enabled buffer?
>
> You don't use (declare (special bar)).

Of course.

Thanks.

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: lexical-binding questions

[Stefan Monnier]

> Now we have lexical-binding in Emacs, it could be nice to implement the
> declare features of CL. (inline too)

Just because CL has lexical-scoping doesn't mean that Elisp added
lexical scoping to be more like CL ;-)

Regarding `inline': I hate defsubst and would rather encourage people
not to use it, because Elisp supports much too poorly (it doesn't do
what you want when you try to use ELP, trace-function, debug-on-entry,
defadvice, etc...).

A much more productive patch would be to speed up function calls from
byte-code functions to byte-code functions by performing them without
leaving the byte-code interpreter (currently the code does a ridiculous
dance where the byte-code interpreter takes the args from the byte-code
stack, passes them to Ffuncall which calls funcall_lambda which then
calls exec_byte_code which sets up a new byte-code stack and copies the
args to this new stack, to finally run the destination byte-code).


        Stefan

RE: lexical-binding questions

[Drew Adams]

> > Now we have lexical-binding in Emacs, it could be nice to 
> > implement the declare features of CL. (inline too)
> 
> Just because CL has lexical-scoping doesn't mean that Elisp added
> lexical scoping to be more like CL ;-)

Agreed.  Not "just because".  But similarly, just because Emacs Lisp is not
Common Lisp does not mean that it should always do things differently. ;-)

IOW, I think (hope) we agree that there should be good, preferably
Emacs-specific reasons why we choose to do things differently (or even the
same).

But when other things are equal (which they seldom but sometimes are), it can
help users who are familiar with Common Lisp if we do things similarly.  CL is
perhaps the closest well-known Lisp to Emacs Lisp in both design and aims.

And there are usually good reasons why CL defines & handles things the way it
does.  That can serve as a starting point for whatever you decide for Elisp.
IOW, what CL does is always worth looking at, before deciding how to roll your
own.

> Regarding `inline': I hate defsubst and would rather encourage people
> not to use it, because Elisp supports much too poorly (it doesn't do
> what you want when you try to use ELP, trace-function, debug-on-entry,
> defadvice, etc...).

+1  (but one could give a similar parenthetical remark about `defadvice')

> A much more productive patch would be to speed up function calls from
> byte-code functions to byte-code functions by performing them without
> leaving the byte-code interpreter

Sounds good.

> (currently the code does a ridiculous dance where the byte-code
> interpreter takes the args from the byte-code stack, passes them
> to Ffuncall which calls funcall_lambda which then calls
> exec_byte_code which sets up a new byte-code stack and copies the
> args to this new stack, to finally run the destination byte-code).

Any reason for that as far as you can tell, apart from hysterical raisins?

Re: lexical-binding questions

[egnarts-ms]

Stefan Monnier wrote:
> 
> A much more productive patch would be to speed up function calls from
> byte-code functions to byte-code functions by performing them without
> leaving the byte-code interpreter (currently the code does a ridiculous
> dance where the byte-code interpreter takes the args from the byte-code
> stack, passes them to Ffuncall which calls funcall_lambda which then
> calls exec_byte_code which sets up a new byte-code stack and copies the
> args to this new stack, to finally run the destination byte-code).
> 

You know, it is not quite clear (at least to me) how it is possible to speed
up this mechanism. exec_byte_code currently allocates stack frames on a
per-call basis, according to what a byte-code object says about its max
stack depth. So,

1) doing direct call from exec_byte_code to exec_byte_code would most
evidently imply the same procedure: creating a new stack frame and copying
all the arguments (as Lisp_Objects) to it;

2) besides the above, going through Ffuncall does some additional things,
like checking lisp_eval_depth and performing GC if necessary, plus updating
the backtrace_list global variable. By all evidence, all these things must
also be performed when a byte-compiled function calls directly another
byte-compiled function, as you suggest, 'cause otherwise Emacs's behavior
would be significantly changed. This creates additional difficulties, as
Ffuncall is located in "eval.c" (and exec_byte_code -- in "bytecode.c").

Maybe there's some info I'm not aware of, or just misunderstanding something
? I'm really interested in this question.
-- 
View this message in context: http://old.nabble.com/lexical-binding-questions-tp33799305p33844651.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: lexical-binding questions

[Stefan Monnier]

> exec_byte_code currently allocates stack frames on a per-call basis,
> according to what a byte-code object says about its max stack depth.

It doesn't have to stay that way.

> 1) doing direct call from exec_byte_code to exec_byte_code would most
> evidently imply the same procedure: creating a new stack frame and copying
> all the arguments (as Lisp_Objects) to it;

You would call exec_byte_code but either call some new function or make
no function call at all (thought that would probably require manually
handling a separate "return address stack").

> 2) besides the above, going through Ffuncall does some additional things,
> like checking lisp_eval_depth and performing GC if necessary, plus updating
> the backtrace_list global variable. By all evidence, all these things must
> also be performed when a byte-compiled function calls directly another
> byte-compiled function, as you suggest,

Yes, we'd have to duplicate some code and we can't eliminate all
the overhead.  Like all optimizations, it's difficult to know beforehand
whether it will be worthwhile, but I think there are some significant
savings to be had.

In the same area, providing some way to do tail-call-optimization would
be very welcome (tho only for lexical-binding code).


        Stefan

Re: lexical-binding questions

[egnarts-ms]

Thierry,

I hope the article named "Lexical scope" in my 
http://prog-elisp.blogspot.com/ blog  might be useful for you.

Thanks,
egnarts-ms.
-- 
View this message in context: http://old.nabble.com/lexical-binding-questions-tp33799305p33827449.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: lexical-binding questions

[Stefan Monnier]

> I hope the article named "Lexical scope" in my 
> http://prog-elisp.blogspot.com/ blog  might be useful for you.

Indeed, this points to some further bugs in the byte-compiler's handling
of (defvar <foo>).


        Stefan

Re: lexical-binding questions

[Johan Bockgård]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I hope the article named "Lexical scope" in my 
>> http://prog-elisp.blogspot.com/ blog  might be useful for you.
>
> Indeed, this points to some further bugs in the byte-compiler's handling
> of (defvar <foo>).

Also, it reminded my of this:

     (setq lexical-binding t)

     (let ((t 0)) t)      => error

     (let ((nil 0)) nil)  => 0

Re: lexical-binding questions

[egnarts-ms]

Johan Bockgård-4 wrote:
> 
> Also, it reminded my of this:
> 
>      (setq lexical-binding t)
> 
>      (let ((t 0)) t)      => error
> 
>      (let ((nil 0)) nil)  => 0
> 

Thanks Johan, a very good observation.. I don't think this is a very serious
bug, but nevertheless. Quite an inconsistent behavior.
-- 
View this message in context: http://old.nabble.com/lexical-binding-questions-tp33799305p33849639.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: lexical-binding questions

[Stefan Monnier]

>> Also, it reminded my of this:
>> (setq lexical-binding t)
>> (let ((t 0)) t)      => error
>> (let ((nil 0)) nil)  => 0

Funnily enough, the byte-compiler behaves pretty much the same, and yet
the underlying reasons are completely different.

Basically: nil and t are not marked as special-variable-p, so they are
considered candidates for lexical scoping; but t is used as the last
element of the interpreter's lexical environment (basically because
a nil lexical environment is used to mean "lexical-binding = nil"), so
it behaves as if there'd been a (defvar t) earlier, which in turns
explains why the error is signalled since we then try to set the global
variable `t' which is immutable.

For nil, this doesn't show up, so it's treated as a lexically
scoped var.

for the compiler case, byte-compile-not-lexical-var-p actually
special-cases t and nil so they're treated as dynamically bound, but in
your nil case above, we never even attempt to bind nil because the "let body
is nil" triggers an optimization (which (c|sh)ould also apply to the
"let body is t" case, but that's not implemented).

Anyway, I guess nil and t should be marked as special-variable-p, if for
no other reason than because they are pretty damn special.


        Stefan

Re: lexical-binding questions

[Johan Bockgård]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> (setq lexical-binding t)
>>> (let ((nil 0)) nil)  => 0
>
> Anyway, I guess nil and t should be marked as special-variable-p, if for
> no other reason than because they are pretty damn special.

The problem also applies to keyword symbols.

I was thinking

      if (!NILP (lexenv) && SYMBOLP (var)
+         && !SYMBOL_CONSTANT_P (var)
	  && !XSYMBOL (var)->declared_special
	  && NILP (Fmemq (var, Vinternal_interpreter_environment)))
	/* Lexically bind VAR by adding it to the lexenv alist.  */
	lexenv = Fcons (Fcons (var, tem), lexenv);

in let/let*.

Re: lexical-binding questions

[Stefan Monnier]

>>>> (setq lexical-binding t)
>>>> (let ((nil 0)) nil)  => 0
>> Anyway, I guess nil and t should be marked as special-variable-p, if for
>> no other reason than because they are pretty damn special.
> The problem also applies to keyword symbols.

Indeed, except it's a lot less likely that people will try to let-bind
a keyword symbol (it happens to me several times a year to choose `t'
for a variable name, only to find it doesn't work, but I never suffered
from that problem with a keyword symbol).

> I was thinking
>       if (!NILP (lexenv) && SYMBOLP (var)
> +         && !SYMBOL_CONSTANT_P (var)
> 	  && !XSYMBOL (var)->declared_special
> 	  && NILP (Fmemq (var, Vinternal_interpreter_environment)))
> 	/* Lexically bind VAR by adding it to the lexenv alist.  */
> 	lexenv = Fcons (Fcons (var, tem), lexenv);

It would be more efficient to set declared_special on keyword symbols.


        Stefan