* lexical-binding questions @ 2012-05-05 6:30 Thierry Volpiatto 2012-05-05 6:45 ` Thierry Volpiatto ` (2 more replies) 0 siblings, 3 replies; 105+ messages in thread From: Thierry Volpiatto @ 2012-05-05 6:30 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: lexical-binding questions 2012-05-05 6:30 lexical-binding questions Thierry Volpiatto @ 2012-05-05 6:45 ` Thierry Volpiatto 2012-05-05 8:16 ` BEGIN_SRC..END_SRC (was: lexical-binding questions) Eli Zaretskii 2012-05-05 13:29 ` lexical-binding questions Stefan Monnier 2012-05-05 13:26 ` Stefan Monnier 2012-05-14 3:57 ` egnarts-ms 2 siblings, 2 replies; 105+ messages in thread From: Thierry Volpiatto @ 2012-05-05 6:45 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* BEGIN_SRC..END_SRC (was: lexical-binding questions) 2012-05-05 6:45 ` Thierry Volpiatto @ 2012-05-05 8:16 ` Eli Zaretskii 2012-05-05 8:39 ` BEGIN_SRC..END_SRC Tom Rauchenwald 2012-05-05 13:29 ` lexical-binding questions Stefan Monnier 1 sibling, 1 reply; 105+ messages in thread From: Eli Zaretskii @ 2012-05-05 8:16 UTC (permalink / raw) To: Thierry Volpiatto; +Cc: emacs-devel > 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? ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-05 8:16 ` BEGIN_SRC..END_SRC (was: lexical-binding questions) Eli Zaretskii @ 2012-05-05 8:39 ` Tom Rauchenwald 2012-05-05 8:54 ` BEGIN_SRC..END_SRC Eli Zaretskii 0 siblings, 1 reply; 105+ messages in thread From: Tom Rauchenwald @ 2012-05-05 8:39 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-05 8:39 ` BEGIN_SRC..END_SRC Tom Rauchenwald @ 2012-05-05 8:54 ` Eli Zaretskii 2012-05-05 13:38 ` BEGIN_SRC..END_SRC Bastien 2012-05-05 14:35 ` BEGIN_SRC..END_SRC Drew Adams 0 siblings, 2 replies; 105+ messages in thread From: Eli Zaretskii @ 2012-05-05 8:54 UTC (permalink / raw) To: Tom Rauchenwald; +Cc: emacs-devel > 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? ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-05 8:54 ` BEGIN_SRC..END_SRC Eli Zaretskii @ 2012-05-05 13:38 ` Bastien 2012-05-05 17:02 ` BEGIN_SRC..END_SRC Eli Zaretskii 2012-05-05 14:35 ` BEGIN_SRC..END_SRC Drew Adams 1 sibling, 1 reply; 105+ messages in thread From: Bastien @ 2012-05-05 13:38 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Tom Rauchenwald, emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-05 13:38 ` BEGIN_SRC..END_SRC Bastien @ 2012-05-05 17:02 ` Eli Zaretskii 2012-05-06 16:03 ` BEGIN_SRC..END_SRC Bastien 0 siblings, 1 reply; 105+ messages in thread From: Eli Zaretskii @ 2012-05-05 17:02 UTC (permalink / raw) To: Bastien; +Cc: emacs-devel > 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? ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-05 17:02 ` BEGIN_SRC..END_SRC Eli Zaretskii @ 2012-05-06 16:03 ` Bastien 2012-05-06 16:46 ` BEGIN_SRC..END_SRC Eli Zaretskii 0 siblings, 1 reply; 105+ messages in thread From: Bastien @ 2012-05-06 16:03 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-06 16:03 ` BEGIN_SRC..END_SRC Bastien @ 2012-05-06 16:46 ` Eli Zaretskii 2012-05-06 17:03 ` BEGIN_SRC..END_SRC Lars Magne Ingebrigtsen 0 siblings, 1 reply; 105+ messages in thread From: Eli Zaretskii @ 2012-05-06 16:46 UTC (permalink / raw) To: Bastien; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-06 16:46 ` BEGIN_SRC..END_SRC Eli Zaretskii @ 2012-05-06 17:03 ` Lars Magne Ingebrigtsen 0 siblings, 0 replies; 105+ messages in thread From: Lars Magne Ingebrigtsen @ 2012-05-06 17:03 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Bastien, emacs-devel 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/ ^ permalink raw reply [flat|nested] 105+ messages in thread
* RE: BEGIN_SRC..END_SRC 2012-05-05 8:54 ` BEGIN_SRC..END_SRC Eli Zaretskii 2012-05-05 13:38 ` BEGIN_SRC..END_SRC Bastien @ 2012-05-05 14:35 ` Drew Adams 2012-05-05 15:10 ` BEGIN_SRC..END_SRC Antoine Levitt ` (3 more replies) 1 sibling, 4 replies; 105+ messages in thread From: Drew Adams @ 2012-05-05 14:35 UTC (permalink / raw) To: 'Eli Zaretskii', 'Tom Rauchenwald'; +Cc: emacs-devel > > > 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-05 14:35 ` BEGIN_SRC..END_SRC Drew Adams @ 2012-05-05 15:10 ` Antoine Levitt 2012-05-05 15:57 ` BEGIN_SRC..END_SRC Drew Adams 2012-05-05 15:48 ` BEGIN_SRC..END_SRC Yann Hodique ` (2 subsequent siblings) 3 siblings, 1 reply; 105+ messages in thread From: Antoine Levitt @ 2012-05-05 15:10 UTC (permalink / raw) To: emacs-devel 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? ^ permalink raw reply [flat|nested] 105+ messages in thread
* RE: BEGIN_SRC..END_SRC 2012-05-05 15:10 ` BEGIN_SRC..END_SRC Antoine Levitt @ 2012-05-05 15:57 ` Drew Adams 2012-05-05 17:00 ` BEGIN_SRC..END_SRC Peter Münster 2012-05-06 14:17 ` BEGIN_SRC..END_SRC Ted Zlatanov 0 siblings, 2 replies; 105+ messages in thread From: Drew Adams @ 2012-05-05 15:57 UTC (permalink / raw) To: 'Antoine Levitt', emacs-devel > 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-05 15:57 ` BEGIN_SRC..END_SRC Drew Adams @ 2012-05-05 17:00 ` Peter Münster 2012-05-05 17:35 ` BEGIN_SRC..END_SRC Drew Adams 2012-05-05 21:38 ` BEGIN_SRC..END_SRC John Wiegley 2012-05-06 14:17 ` BEGIN_SRC..END_SRC Ted Zlatanov 1 sibling, 2 replies; 105+ messages in thread From: Peter Münster @ 2012-05-05 17:00 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* RE: BEGIN_SRC..END_SRC 2012-05-05 17:00 ` BEGIN_SRC..END_SRC Peter Münster @ 2012-05-05 17:35 ` Drew Adams 2012-05-05 21:38 ` BEGIN_SRC..END_SRC John Wiegley 1 sibling, 0 replies; 105+ messages in thread From: Drew Adams @ 2012-05-05 17:35 UTC (permalink / raw) To: 'Peter Münster', emacs-devel > > 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-05 17:00 ` BEGIN_SRC..END_SRC Peter Münster 2012-05-05 17:35 ` BEGIN_SRC..END_SRC Drew Adams @ 2012-05-05 21:38 ` John Wiegley 2012-05-07 2:25 ` BEGIN_SRC..END_SRC Ted Zlatanov 1 sibling, 1 reply; 105+ messages in thread From: John Wiegley @ 2012-05-05 21:38 UTC (permalink / raw) To: emacs-devel >>>>> 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-05 21:38 ` BEGIN_SRC..END_SRC John Wiegley @ 2012-05-07 2:25 ` Ted Zlatanov 2012-05-07 6:23 ` BEGIN_SRC..END_SRC Miles Bader 0 siblings, 1 reply; 105+ messages in thread From: Ted Zlatanov @ 2012-05-07 2:25 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-07 2:25 ` BEGIN_SRC..END_SRC Ted Zlatanov @ 2012-05-07 6:23 ` Miles Bader 2012-05-07 9:37 ` BEGIN_SRC..END_SRC Thien-Thi Nguyen 0 siblings, 1 reply; 105+ messages in thread From: Miles Bader @ 2012-05-07 6:23 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-07 6:23 ` BEGIN_SRC..END_SRC Miles Bader @ 2012-05-07 9:37 ` Thien-Thi Nguyen 0 siblings, 0 replies; 105+ messages in thread From: Thien-Thi Nguyen @ 2012-05-07 9:37 UTC (permalink / raw) To: Miles Bader; +Cc: emacs-devel () 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. ;-] ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-05 15:57 ` BEGIN_SRC..END_SRC Drew Adams 2012-05-05 17:00 ` BEGIN_SRC..END_SRC Peter Münster @ 2012-05-06 14:17 ` Ted Zlatanov 1 sibling, 0 replies; 105+ messages in thread From: Ted Zlatanov @ 2012-05-06 14:17 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-05 14:35 ` BEGIN_SRC..END_SRC Drew Adams 2012-05-05 15:10 ` BEGIN_SRC..END_SRC Antoine Levitt @ 2012-05-05 15:48 ` Yann Hodique 2012-05-05 16:43 ` BEGIN_SRC..END_SRC Stephen J. Turnbull 2012-05-05 19:48 ` BEGIN_SRC..END_SRC Martyn Jago 2012-05-06 14:15 ` BEGIN_SRC..END_SRC Ted Zlatanov 3 siblings, 1 reply; 105+ messages in thread From: Yann Hodique @ 2012-05-05 15:48 UTC (permalink / raw) To: emacs-devel [-- 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-05 15:48 ` BEGIN_SRC..END_SRC Yann Hodique @ 2012-05-05 16:43 ` Stephen J. Turnbull 2012-05-05 17:12 ` BEGIN_SRC..END_SRC Yann Hodique 2012-05-05 17:36 ` BEGIN_SRC..END_SRC Drew Adams 0 siblings, 2 replies; 105+ messages in thread From: Stephen J. Turnbull @ 2012-05-05 16:43 UTC (permalink / raw) To: Yann Hodique; +Cc: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-05 16:43 ` BEGIN_SRC..END_SRC Stephen J. Turnbull @ 2012-05-05 17:12 ` Yann Hodique 2012-05-07 8:57 ` BEGIN_SRC..END_SRC Julien Danjou 2012-05-05 17:36 ` BEGIN_SRC..END_SRC Drew Adams 1 sibling, 1 reply; 105+ messages in thread From: Yann Hodique @ 2012-05-05 17:12 UTC (permalink / raw) To: emacs-devel >>>>> "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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-05 17:12 ` BEGIN_SRC..END_SRC Yann Hodique @ 2012-05-07 8:57 ` Julien Danjou 2012-05-07 9:46 ` BEGIN_SRC..END_SRC Yann Hodique 0 siblings, 1 reply; 105+ messages in thread From: Julien Danjou @ 2012-05-07 8:57 UTC (permalink / raw) To: Yann Hodique; +Cc: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-07 8:57 ` BEGIN_SRC..END_SRC Julien Danjou @ 2012-05-07 9:46 ` Yann Hodique 0 siblings, 0 replies; 105+ messages in thread From: Yann Hodique @ 2012-05-07 9:46 UTC (permalink / raw) To: emacs-devel >>>>> "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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* RE: BEGIN_SRC..END_SRC 2012-05-05 16:43 ` BEGIN_SRC..END_SRC Stephen J. Turnbull 2012-05-05 17:12 ` BEGIN_SRC..END_SRC Yann Hodique @ 2012-05-05 17:36 ` Drew Adams 1 sibling, 0 replies; 105+ messages in thread From: Drew Adams @ 2012-05-05 17:36 UTC (permalink / raw) To: 'Stephen J. Turnbull', 'Yann Hodique'; +Cc: emacs-devel > > 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.) ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-05 14:35 ` BEGIN_SRC..END_SRC Drew Adams 2012-05-05 15:10 ` BEGIN_SRC..END_SRC Antoine Levitt 2012-05-05 15:48 ` BEGIN_SRC..END_SRC Yann Hodique @ 2012-05-05 19:48 ` Martyn Jago 2012-05-05 20:00 ` BEGIN_SRC..END_SRC Drew Adams 2012-05-07 5:44 ` BEGIN_SRC..END_SRC Stephen J. Turnbull 2012-05-06 14:15 ` BEGIN_SRC..END_SRC Ted Zlatanov 3 siblings, 2 replies; 105+ messages in thread From: Martyn Jago @ 2012-05-05 19:48 UTC (permalink / raw) To: emacs-devel "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! ^ permalink raw reply [flat|nested] 105+ messages in thread
* RE: BEGIN_SRC..END_SRC 2012-05-05 19:48 ` BEGIN_SRC..END_SRC Martyn Jago @ 2012-05-05 20:00 ` Drew Adams 2012-05-07 5:44 ` BEGIN_SRC..END_SRC Stephen J. Turnbull 1 sibling, 0 replies; 105+ messages in thread From: Drew Adams @ 2012-05-05 20:00 UTC (permalink / raw) To: 'Martyn Jago', emacs-devel > 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-05 19:48 ` BEGIN_SRC..END_SRC Martyn Jago 2012-05-05 20:00 ` BEGIN_SRC..END_SRC Drew Adams @ 2012-05-07 5:44 ` Stephen J. Turnbull 2012-05-07 14:23 ` BEGIN_SRC..END_SRC Wolfgang Jenkner 1 sibling, 1 reply; 105+ messages in thread From: Stephen J. Turnbull @ 2012-05-07 5:44 UTC (permalink / raw) To: Martyn Jago; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-07 5:44 ` BEGIN_SRC..END_SRC Stephen J. Turnbull @ 2012-05-07 14:23 ` Wolfgang Jenkner 2012-05-08 4:08 ` BEGIN_SRC..END_SRC Stephen J. Turnbull 0 siblings, 1 reply; 105+ messages in thread From: Wolfgang Jenkner @ 2012-05-07 14:23 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Martyn Jago, emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-07 14:23 ` BEGIN_SRC..END_SRC Wolfgang Jenkner @ 2012-05-08 4:08 ` Stephen J. Turnbull 2012-05-08 7:37 ` BEGIN_SRC..END_SRC Bastien 0 siblings, 1 reply; 105+ messages in thread From: Stephen J. Turnbull @ 2012-05-08 4:08 UTC (permalink / raw) To: Wolfgang Jenkner; +Cc: Martyn Jago, emacs-devel 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-08 4:08 ` BEGIN_SRC..END_SRC Stephen J. Turnbull @ 2012-05-08 7:37 ` Bastien 2012-05-08 11:41 ` BEGIN_SRC..END_SRC Juanma Barranquero 0 siblings, 1 reply; 105+ messages in thread From: Bastien @ 2012-05-08 7:37 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Martyn Jago, Wolfgang Jenkner, emacs-devel "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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-08 7:37 ` BEGIN_SRC..END_SRC Bastien @ 2012-05-08 11:41 ` Juanma Barranquero 2012-05-08 12:17 ` BEGIN_SRC..END_SRC Stefan Monnier 0 siblings, 1 reply; 105+ messages in thread From: Juanma Barranquero @ 2012-05-08 11:41 UTC (permalink / raw) To: Bastien; +Cc: Stephen J. Turnbull, Wolfgang Jenkner, Martyn Jago, emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-08 11:41 ` BEGIN_SRC..END_SRC Juanma Barranquero @ 2012-05-08 12:17 ` Stefan Monnier 2012-05-08 14:32 ` BEGIN_SRC..END_SRC Andreas Röhler 2012-05-09 0:47 ` BEGIN_SRC..END_SRC Ted Zlatanov 0 siblings, 2 replies; 105+ messages in thread From: Stefan Monnier @ 2012-05-08 12:17 UTC (permalink / raw) To: Juanma Barranquero Cc: Bastien, Stephen J. Turnbull, Wolfgang Jenkner, Martyn Jago, emacs-devel > 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-08 12:17 ` BEGIN_SRC..END_SRC Stefan Monnier @ 2012-05-08 14:32 ` Andreas Röhler 2012-05-09 1:23 ` BEGIN_SRC..END_SRC Stephen J. Turnbull 2012-05-09 0:47 ` BEGIN_SRC..END_SRC Ted Zlatanov 1 sibling, 1 reply; 105+ messages in thread From: Andreas Röhler @ 2012-05-08 14:32 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-08 14:32 ` BEGIN_SRC..END_SRC Andreas Röhler @ 2012-05-09 1:23 ` Stephen J. Turnbull 2012-05-09 17:31 ` BEGIN_SRC..END_SRC Stefan Monnier 0 siblings, 1 reply; 105+ messages in thread From: Stephen J. Turnbull @ 2012-05-09 1:23 UTC (permalink / raw) To: Andreas Röhler; +Cc: emacs-devel 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> ;-) ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-09 1:23 ` BEGIN_SRC..END_SRC Stephen J. Turnbull @ 2012-05-09 17:31 ` Stefan Monnier 0 siblings, 0 replies; 105+ messages in thread From: Stefan Monnier @ 2012-05-09 17:31 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Andreas Röhler, emacs-devel > 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-08 12:17 ` BEGIN_SRC..END_SRC Stefan Monnier 2012-05-08 14:32 ` BEGIN_SRC..END_SRC Andreas Röhler @ 2012-05-09 0:47 ` Ted Zlatanov 2012-05-09 3:50 ` BEGIN_SRC..END_SRC Miles Bader ` (3 more replies) 1 sibling, 4 replies; 105+ messages in thread From: Ted Zlatanov @ 2012-05-09 0:47 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-09 0:47 ` BEGIN_SRC..END_SRC Ted Zlatanov @ 2012-05-09 3:50 ` Miles Bader 2012-05-09 11:35 ` BEGIN_SRC..END_SRC Ted Zlatanov 2012-05-09 4:45 ` BEGIN_SRC..END_SRC Eli Zaretskii ` (2 subsequent siblings) 3 siblings, 1 reply; 105+ messages in thread From: Miles Bader @ 2012-05-09 3:50 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-09 3:50 ` BEGIN_SRC..END_SRC Miles Bader @ 2012-05-09 11:35 ` Ted Zlatanov 2012-05-09 12:23 ` BEGIN_SRC..END_SRC Stephen J. Turnbull ` (2 more replies) 0 siblings, 3 replies; 105+ messages in thread From: Ted Zlatanov @ 2012-05-09 11:35 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-09 11:35 ` BEGIN_SRC..END_SRC Ted Zlatanov @ 2012-05-09 12:23 ` Stephen J. Turnbull 2012-05-09 13:43 ` BEGIN_SRC..END_SRC Lars Magne Ingebrigtsen 2012-05-09 13:52 ` BEGIN_SRC..END_SRC Tassilo Horn 2012-05-09 17:33 ` BEGIN_SRC..END_SRC Stefan Monnier 2 siblings, 1 reply; 105+ messages in thread From: Stephen J. Turnbull @ 2012-05-09 12:23 UTC (permalink / raw) To: emacs-devel Ted Zlatanov writes: > We don't want to bother with MIME for short snippets. Then what do you think your MUA is there for? ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-09 12:23 ` BEGIN_SRC..END_SRC Stephen J. Turnbull @ 2012-05-09 13:43 ` Lars Magne Ingebrigtsen 2012-05-09 14:57 ` BEGIN_SRC..END_SRC Eric Schulte 2012-05-16 14:00 ` BEGIN_SRC..END_SRC Ted Zlatanov 0 siblings, 2 replies; 105+ messages in thread From: Lars Magne Ingebrigtsen @ 2012-05-09 13:43 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: emacs-devel "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/ ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-09 13:43 ` BEGIN_SRC..END_SRC Lars Magne Ingebrigtsen @ 2012-05-09 14:57 ` Eric Schulte 2012-05-09 17:08 ` BEGIN_SRC..END_SRC Yann Hodique 2012-05-10 7:28 ` BEGIN_SRC..END_SRC Stephen J. Turnbull 2012-05-16 14:00 ` BEGIN_SRC..END_SRC Ted Zlatanov 1 sibling, 2 replies; 105+ messages in thread From: Eric Schulte @ 2012-05-09 14:57 UTC (permalink / raw) To: Lars Magne Ingebrigtsen; +Cc: Stephen J. Turnbull, emacs-devel [-- 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/ ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-09 14:57 ` BEGIN_SRC..END_SRC Eric Schulte @ 2012-05-09 17:08 ` Yann Hodique 2012-05-09 16:06 ` BEGIN_SRC..END_SRC Eric Schulte 2012-05-10 7:28 ` BEGIN_SRC..END_SRC Stephen J. Turnbull 1 sibling, 1 reply; 105+ messages in thread From: Yann Hodique @ 2012-05-09 17:08 UTC (permalink / raw) To: emacs-devel >>>>> "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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-09 17:08 ` BEGIN_SRC..END_SRC Yann Hodique @ 2012-05-09 16:06 ` Eric Schulte 2012-05-09 18:20 ` BEGIN_SRC..END_SRC Yann Hodique 2012-05-10 7:44 ` BEGIN_SRC..END_SRC Stephen J. Turnbull 0 siblings, 2 replies; 105+ messages in thread From: Eric Schulte @ 2012-05-09 16:06 UTC (permalink / raw) To: Yann Hodique; +Cc: emacs-devel 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/ ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-09 16:06 ` BEGIN_SRC..END_SRC Eric Schulte @ 2012-05-09 18:20 ` Yann Hodique 2012-05-09 16:30 ` BEGIN_SRC..END_SRC Eric Schulte 2012-05-10 7:44 ` BEGIN_SRC..END_SRC Stephen J. Turnbull 1 sibling, 1 reply; 105+ messages in thread From: Yann Hodique @ 2012-05-09 18:20 UTC (permalink / raw) To: Eric Schulte; +Cc: emacs-devel >>>>> "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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-09 18:20 ` BEGIN_SRC..END_SRC Yann Hodique @ 2012-05-09 16:30 ` Eric Schulte 2012-05-09 18:44 ` BEGIN_SRC..END_SRC Yann Hodique 0 siblings, 1 reply; 105+ messages in thread From: Eric Schulte @ 2012-05-09 16:30 UTC (permalink / raw) To: Yann Hodique; +Cc: Eric Schulte, emacs-devel 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/ ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-09 16:30 ` BEGIN_SRC..END_SRC Eric Schulte @ 2012-05-09 18:44 ` Yann Hodique 0 siblings, 0 replies; 105+ messages in thread From: Yann Hodique @ 2012-05-09 18:44 UTC (permalink / raw) To: Eric Schulte; +Cc: emacs-devel >>>>> "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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-09 16:06 ` BEGIN_SRC..END_SRC Eric Schulte 2012-05-09 18:20 ` BEGIN_SRC..END_SRC Yann Hodique @ 2012-05-10 7:44 ` Stephen J. Turnbull 1 sibling, 0 replies; 105+ messages in thread From: Stephen J. Turnbull @ 2012-05-10 7:44 UTC (permalink / raw) To: Eric Schulte; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-09 14:57 ` BEGIN_SRC..END_SRC Eric Schulte 2012-05-09 17:08 ` BEGIN_SRC..END_SRC Yann Hodique @ 2012-05-10 7:28 ` Stephen J. Turnbull 2012-05-10 7:59 ` BEGIN_SRC..END_SRC Yann Hodique 2012-05-10 9:02 ` BEGIN_SRC..END_SRC René Kyllingstad 1 sibling, 2 replies; 105+ messages in thread From: Stephen J. Turnbull @ 2012-05-10 7:28 UTC (permalink / raw) To: Eric Schulte; +Cc: Lars Magne Ingebrigtsen, emacs-devel 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-10 7:28 ` BEGIN_SRC..END_SRC Stephen J. Turnbull @ 2012-05-10 7:59 ` Yann Hodique 2012-05-10 12:35 ` BEGIN_SRC..END_SRC Stephen J. Turnbull 2012-05-10 9:02 ` BEGIN_SRC..END_SRC René Kyllingstad 1 sibling, 1 reply; 105+ messages in thread From: Yann Hodique @ 2012-05-10 7:59 UTC (permalink / raw) To: emacs-devel >>>>> "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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-10 7:59 ` BEGIN_SRC..END_SRC Yann Hodique @ 2012-05-10 12:35 ` Stephen J. Turnbull 2012-05-10 13:28 ` BEGIN_SRC..END_SRC Yann Hodique ` (2 more replies) 0 siblings, 3 replies; 105+ messages in thread From: Stephen J. Turnbull @ 2012-05-10 12:35 UTC (permalink / raw) To: Yann Hodique; +Cc: emacs-devel 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! ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-10 12:35 ` BEGIN_SRC..END_SRC Stephen J. Turnbull @ 2012-05-10 13:28 ` Yann Hodique 2012-05-10 13:51 ` BEGIN_SRC..END_SRC Miles Bader 2012-05-10 15:21 ` BEGIN_SRC..END_SRC Davis Herring 2 siblings, 0 replies; 105+ messages in thread From: Yann Hodique @ 2012-05-10 13:28 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: emacs-devel >>>>> "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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-10 12:35 ` BEGIN_SRC..END_SRC Stephen J. Turnbull 2012-05-10 13:28 ` BEGIN_SRC..END_SRC Yann Hodique @ 2012-05-10 13:51 ` Miles Bader 2012-05-15 3:30 ` BEGIN_SRC..END_SRC Stephen J. Turnbull 2012-05-10 15:21 ` BEGIN_SRC..END_SRC Davis Herring 2 siblings, 1 reply; 105+ messages in thread From: Miles Bader @ 2012-05-10 13:51 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Yann Hodique, emacs-devel "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.... ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-10 13:51 ` BEGIN_SRC..END_SRC Miles Bader @ 2012-05-15 3:30 ` Stephen J. Turnbull 0 siblings, 0 replies; 105+ messages in thread From: Stephen J. Turnbull @ 2012-05-15 3:30 UTC (permalink / raw) To: Miles Bader; +Cc: Yann Hodique, emacs-devel 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-10 12:35 ` BEGIN_SRC..END_SRC Stephen J. Turnbull 2012-05-10 13:28 ` BEGIN_SRC..END_SRC Yann Hodique 2012-05-10 13:51 ` BEGIN_SRC..END_SRC Miles Bader @ 2012-05-10 15:21 ` Davis Herring 2012-05-15 3:56 ` BEGIN_SRC..END_SRC Stephen J. Turnbull 2 siblings, 1 reply; 105+ messages in thread From: Davis Herring @ 2012-05-10 15:21 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Yann Hodique, emacs-devel > 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-10 15:21 ` BEGIN_SRC..END_SRC Davis Herring @ 2012-05-15 3:56 ` Stephen J. Turnbull 0 siblings, 0 replies; 105+ messages in thread From: Stephen J. Turnbull @ 2012-05-15 3:56 UTC (permalink / raw) To: Davis Herring; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-10 7:28 ` BEGIN_SRC..END_SRC Stephen J. Turnbull 2012-05-10 7:59 ` BEGIN_SRC..END_SRC Yann Hodique @ 2012-05-10 9:02 ` René Kyllingstad 2012-05-10 13:05 ` BEGIN_SRC..END_SRC Stephen J. Turnbull 1 sibling, 1 reply; 105+ messages in thread From: René Kyllingstad @ 2012-05-10 9:02 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Lars Magne Ingebrigtsen, Eric Schulte, emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-10 9:02 ` BEGIN_SRC..END_SRC René Kyllingstad @ 2012-05-10 13:05 ` Stephen J. Turnbull 2012-05-10 13:55 ` BEGIN_SRC..END_SRC René Kyllingstad 0 siblings, 1 reply; 105+ messages in thread From: Stephen J. Turnbull @ 2012-05-10 13:05 UTC (permalink / raw) To: René Kyllingstad; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-10 13:05 ` BEGIN_SRC..END_SRC Stephen J. Turnbull @ 2012-05-10 13:55 ` René Kyllingstad 2012-05-15 3:52 ` BEGIN_SRC..END_SRC Stephen J. Turnbull 0 siblings, 1 reply; 105+ messages in thread From: René Kyllingstad @ 2012-05-10 13:55 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-10 13:55 ` BEGIN_SRC..END_SRC René Kyllingstad @ 2012-05-15 3:52 ` Stephen J. Turnbull 0 siblings, 0 replies; 105+ messages in thread From: Stephen J. Turnbull @ 2012-05-15 3:52 UTC (permalink / raw) To: Rene; +Cc: emacs-devel 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). ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-09 13:43 ` BEGIN_SRC..END_SRC Lars Magne Ingebrigtsen 2012-05-09 14:57 ` BEGIN_SRC..END_SRC Eric Schulte @ 2012-05-16 14:00 ` Ted Zlatanov 1 sibling, 0 replies; 105+ messages in thread From: Ted Zlatanov @ 2012-05-16 14:00 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-09 11:35 ` BEGIN_SRC..END_SRC Ted Zlatanov 2012-05-09 12:23 ` BEGIN_SRC..END_SRC Stephen J. Turnbull @ 2012-05-09 13:52 ` Tassilo Horn 2012-05-09 17:44 ` BEGIN_SRC..END_SRC Tassilo Horn 2012-05-09 17:33 ` BEGIN_SRC..END_SRC Stefan Monnier 2 siblings, 1 reply; 105+ messages in thread From: Tassilo Horn @ 2012-05-09 13:52 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-09 13:52 ` BEGIN_SRC..END_SRC Tassilo Horn @ 2012-05-09 17:44 ` Tassilo Horn 0 siblings, 0 replies; 105+ messages in thread From: Tassilo Horn @ 2012-05-09 17:44 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-09 11:35 ` BEGIN_SRC..END_SRC Ted Zlatanov 2012-05-09 12:23 ` BEGIN_SRC..END_SRC Stephen J. Turnbull 2012-05-09 13:52 ` BEGIN_SRC..END_SRC Tassilo Horn @ 2012-05-09 17:33 ` Stefan Monnier 2 siblings, 0 replies; 105+ messages in thread From: Stefan Monnier @ 2012-05-09 17:33 UTC (permalink / raw) To: emacs-devel > 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-09 0:47 ` BEGIN_SRC..END_SRC Ted Zlatanov 2012-05-09 3:50 ` BEGIN_SRC..END_SRC Miles Bader @ 2012-05-09 4:45 ` Eli Zaretskii 2012-05-09 6:28 ` BEGIN_SRC..END_SRC Tassilo Horn 2012-05-09 17:36 ` BEGIN_SRC..END_SRC Stefan Monnier 3 siblings, 0 replies; 105+ messages in thread From: Eli Zaretskii @ 2012-05-09 4:45 UTC (permalink / raw) To: emacs-devel > 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-09 0:47 ` BEGIN_SRC..END_SRC Ted Zlatanov 2012-05-09 3:50 ` BEGIN_SRC..END_SRC Miles Bader 2012-05-09 4:45 ` BEGIN_SRC..END_SRC Eli Zaretskii @ 2012-05-09 6:28 ` Tassilo Horn 2012-05-09 9:30 ` BEGIN_SRC..END_SRC Peter Münster 2012-05-09 17:36 ` BEGIN_SRC..END_SRC Stefan Monnier 3 siblings, 1 reply; 105+ messages in thread From: Tassilo Horn @ 2012-05-09 6:28 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-09 6:28 ` BEGIN_SRC..END_SRC Tassilo Horn @ 2012-05-09 9:30 ` Peter Münster 2012-06-08 0:20 ` BEGIN_SRC..END_SRC Lars Magne Ingebrigtsen 0 siblings, 1 reply; 105+ messages in thread From: Peter Münster @ 2012-05-09 9:30 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-09 9:30 ` BEGIN_SRC..END_SRC Peter Münster @ 2012-06-08 0:20 ` Lars Magne Ingebrigtsen 0 siblings, 0 replies; 105+ messages in thread From: Lars Magne Ingebrigtsen @ 2012-06-08 0:20 UTC (permalink / raw) To: Peter Münster; +Cc: emacs-devel 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/ ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-09 0:47 ` BEGIN_SRC..END_SRC Ted Zlatanov ` (2 preceding siblings ...) 2012-05-09 6:28 ` BEGIN_SRC..END_SRC Tassilo Horn @ 2012-05-09 17:36 ` Stefan Monnier 2012-05-10 0:56 ` BEGIN_SRC..END_SRC Miles Bader 2012-05-16 14:51 ` BEGIN_SRC..END_SRC Ted Zlatanov 3 siblings, 2 replies; 105+ messages in thread From: Stefan Monnier @ 2012-05-09 17:36 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-09 17:36 ` BEGIN_SRC..END_SRC Stefan Monnier @ 2012-05-10 0:56 ` Miles Bader 2012-05-16 14:51 ` BEGIN_SRC..END_SRC Ted Zlatanov 1 sibling, 0 replies; 105+ messages in thread From: Miles Bader @ 2012-05-10 0:56 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-09 17:36 ` BEGIN_SRC..END_SRC Stefan Monnier 2012-05-10 0:56 ` BEGIN_SRC..END_SRC Miles Bader @ 2012-05-16 14:51 ` Ted Zlatanov 2012-05-16 13:05 ` BEGIN_SRC..END_SRC Eric Schulte 1 sibling, 1 reply; 105+ messages in thread From: Ted Zlatanov @ 2012-05-16 14:51 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-16 14:51 ` BEGIN_SRC..END_SRC Ted Zlatanov @ 2012-05-16 13:05 ` Eric Schulte 2012-05-16 15:17 ` plain-text markdown handler for Gnus (was: BEGIN_SRC..END_SRC) Ted Zlatanov 0 siblings, 1 reply; 105+ messages in thread From: Eric Schulte @ 2012-05-16 13:05 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* plain-text markdown handler for Gnus (was: BEGIN_SRC..END_SRC) 2012-05-16 13:05 ` BEGIN_SRC..END_SRC Eric Schulte @ 2012-05-16 15:17 ` Ted Zlatanov 2012-05-16 14:21 ` plain-text markdown handler for Gnus Eric Schulte 0 siblings, 1 reply; 105+ messages in thread From: Ted Zlatanov @ 2012-05-16 15:17 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: plain-text markdown handler for Gnus 2012-05-16 15:17 ` plain-text markdown handler for Gnus (was: BEGIN_SRC..END_SRC) Ted Zlatanov @ 2012-05-16 14:21 ` Eric Schulte 2012-05-16 16:29 ` Ted Zlatanov 0 siblings, 1 reply; 105+ messages in thread From: Eric Schulte @ 2012-05-16 14:21 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: plain-text markdown handler for Gnus 2012-05-16 14:21 ` plain-text markdown handler for Gnus Eric Schulte @ 2012-05-16 16:29 ` Ted Zlatanov 0 siblings, 0 replies; 105+ messages in thread From: Ted Zlatanov @ 2012-05-16 16:29 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-05 14:35 ` BEGIN_SRC..END_SRC Drew Adams ` (2 preceding siblings ...) 2012-05-05 19:48 ` BEGIN_SRC..END_SRC Martyn Jago @ 2012-05-06 14:15 ` Ted Zlatanov 2012-05-06 14:18 ` BEGIN_SRC..END_SRC Lennart Borgman 3 siblings, 1 reply; 105+ messages in thread From: Ted Zlatanov @ 2012-05-06 14:15 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-06 14:15 ` BEGIN_SRC..END_SRC Ted Zlatanov @ 2012-05-06 14:18 ` Lennart Borgman 2012-05-06 14:33 ` BEGIN_SRC..END_SRC Alan Mackenzie 2012-05-06 18:57 ` BEGIN_SRC..END_SRC Ted Zlatanov 0 siblings, 2 replies; 105+ messages in thread From: Lennart Borgman @ 2012-05-06 14:18 UTC (permalink / raw) To: emacs-devel 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? ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-06 14:18 ` BEGIN_SRC..END_SRC Lennart Borgman @ 2012-05-06 14:33 ` Alan Mackenzie 2012-05-06 14:43 ` BEGIN_SRC..END_SRC Lennart Borgman 2012-05-06 18:57 ` BEGIN_SRC..END_SRC Ted Zlatanov 1 sibling, 1 reply; 105+ messages in thread From: Alan Mackenzie @ 2012-05-06 14:33 UTC (permalink / raw) To: Lennart Borgman; +Cc: emacs-devel 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). ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-06 14:33 ` BEGIN_SRC..END_SRC Alan Mackenzie @ 2012-05-06 14:43 ` Lennart Borgman 0 siblings, 0 replies; 105+ messages in thread From: Lennart Borgman @ 2012-05-06 14:43 UTC (permalink / raw) To: Alan Mackenzie; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-06 14:18 ` BEGIN_SRC..END_SRC Lennart Borgman 2012-05-06 14:33 ` BEGIN_SRC..END_SRC Alan Mackenzie @ 2012-05-06 18:57 ` Ted Zlatanov 2012-05-06 23:20 ` BEGIN_SRC..END_SRC Lennart Borgman 2012-05-07 11:04 ` BEGIN_SRC..END_SRC Stephen J. Turnbull 1 sibling, 2 replies; 105+ messages in thread From: Ted Zlatanov @ 2012-05-06 18:57 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-06 18:57 ` BEGIN_SRC..END_SRC Ted Zlatanov @ 2012-05-06 23:20 ` Lennart Borgman 2012-05-07 2:21 ` BEGIN_SRC..END_SRC Ted Zlatanov 2012-05-07 11:04 ` BEGIN_SRC..END_SRC Stephen J. Turnbull 1 sibling, 1 reply; 105+ messages in thread From: Lennart Borgman @ 2012-05-06 23:20 UTC (permalink / raw) To: emacs-devel 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.) ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-06 23:20 ` BEGIN_SRC..END_SRC Lennart Borgman @ 2012-05-07 2:21 ` Ted Zlatanov 2012-05-07 9:56 ` BEGIN_SRC..END_SRC Lennart Borgman 0 siblings, 1 reply; 105+ messages in thread From: Ted Zlatanov @ 2012-05-07 2:21 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-07 2:21 ` BEGIN_SRC..END_SRC Ted Zlatanov @ 2012-05-07 9:56 ` Lennart Borgman 0 siblings, 0 replies; 105+ messages in thread From: Lennart Borgman @ 2012-05-07 9:56 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-06 18:57 ` BEGIN_SRC..END_SRC Ted Zlatanov 2012-05-06 23:20 ` BEGIN_SRC..END_SRC Lennart Borgman @ 2012-05-07 11:04 ` Stephen J. Turnbull 1 sibling, 0 replies; 105+ messages in thread From: Stephen J. Turnbull @ 2012-05-07 11:04 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: lexical-binding questions 2012-05-05 6:45 ` Thierry Volpiatto 2012-05-05 8:16 ` BEGIN_SRC..END_SRC (was: lexical-binding questions) Eli Zaretskii @ 2012-05-05 13:29 ` Stefan Monnier 2012-05-05 17:59 ` Thierry Volpiatto ` (2 more replies) 1 sibling, 3 replies; 105+ messages in thread From: Stefan Monnier @ 2012-05-05 13:29 UTC (permalink / raw) To: Thierry Volpiatto; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: lexical-binding questions 2012-05-05 13:29 ` lexical-binding questions Stefan Monnier @ 2012-05-05 17:59 ` Thierry Volpiatto 2012-05-06 0:08 ` Miles Bader 2012-05-06 6:00 ` Thierry Volpiatto 2 siblings, 0 replies; 105+ messages in thread From: Thierry Volpiatto @ 2012-05-05 17:59 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: lexical-binding questions 2012-05-05 13:29 ` lexical-binding questions Stefan Monnier 2012-05-05 17:59 ` Thierry Volpiatto @ 2012-05-06 0:08 ` Miles Bader 2012-05-06 2:43 ` Stefan Monnier 2012-05-06 6:00 ` Thierry Volpiatto 2 siblings, 1 reply; 105+ messages in thread From: Miles Bader @ 2012-05-06 0:08 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel, 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. 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: lexical-binding questions 2012-05-06 0:08 ` Miles Bader @ 2012-05-06 2:43 ` Stefan Monnier 0 siblings, 0 replies; 105+ messages in thread From: Stefan Monnier @ 2012-05-06 2:43 UTC (permalink / raw) To: Miles Bader; +Cc: emacs-devel, Thierry Volpiatto >>> 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: lexical-binding questions 2012-05-05 13:29 ` lexical-binding questions Stefan Monnier 2012-05-05 17:59 ` Thierry Volpiatto 2012-05-06 0:08 ` Miles Bader @ 2012-05-06 6:00 ` Thierry Volpiatto 2 siblings, 0 replies; 105+ messages in thread From: Thierry Volpiatto @ 2012-05-06 6:00 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: lexical-binding questions 2012-05-05 6:30 lexical-binding questions Thierry Volpiatto 2012-05-05 6:45 ` Thierry Volpiatto @ 2012-05-05 13:26 ` Stefan Monnier 2012-05-05 15:57 ` Thierry Volpiatto 2012-05-14 3:57 ` egnarts-ms 2 siblings, 1 reply; 105+ messages in thread From: Stefan Monnier @ 2012-05-05 13:26 UTC (permalink / raw) To: Thierry Volpiatto; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: lexical-binding questions 2012-05-05 13:26 ` Stefan Monnier @ 2012-05-05 15:57 ` Thierry Volpiatto 2012-05-07 15:19 ` Stefan Monnier 0 siblings, 1 reply; 105+ messages in thread From: Thierry Volpiatto @ 2012-05-05 15:57 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: lexical-binding questions 2012-05-05 15:57 ` Thierry Volpiatto @ 2012-05-07 15:19 ` Stefan Monnier 2012-05-07 15:39 ` Drew Adams 2012-05-15 6:40 ` egnarts-ms 0 siblings, 2 replies; 105+ messages in thread From: Stefan Monnier @ 2012-05-07 15:19 UTC (permalink / raw) To: Thierry Volpiatto; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* RE: lexical-binding questions 2012-05-07 15:19 ` Stefan Monnier @ 2012-05-07 15:39 ` Drew Adams 2012-05-15 6:40 ` egnarts-ms 1 sibling, 0 replies; 105+ messages in thread From: Drew Adams @ 2012-05-07 15:39 UTC (permalink / raw) To: 'Stefan Monnier', 'Thierry Volpiatto'; +Cc: emacs-devel > > 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? ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: lexical-binding questions 2012-05-07 15:19 ` Stefan Monnier 2012-05-07 15:39 ` Drew Adams @ 2012-05-15 6:40 ` egnarts-ms 2012-05-15 13:55 ` Stefan Monnier 1 sibling, 1 reply; 105+ messages in thread From: egnarts-ms @ 2012-05-15 6:40 UTC (permalink / raw) To: Emacs-devel 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: lexical-binding questions 2012-05-15 6:40 ` egnarts-ms @ 2012-05-15 13:55 ` Stefan Monnier 0 siblings, 0 replies; 105+ messages in thread From: Stefan Monnier @ 2012-05-15 13:55 UTC (permalink / raw) To: egnarts-ms; +Cc: Emacs-devel > 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: lexical-binding questions 2012-05-05 6:30 lexical-binding questions Thierry Volpiatto 2012-05-05 6:45 ` Thierry Volpiatto 2012-05-05 13:26 ` Stefan Monnier @ 2012-05-14 3:57 ` egnarts-ms 2012-05-14 4:55 ` Stefan Monnier 2 siblings, 1 reply; 105+ messages in thread From: egnarts-ms @ 2012-05-14 3:57 UTC (permalink / raw) To: Emacs-devel 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: lexical-binding questions 2012-05-14 3:57 ` egnarts-ms @ 2012-05-14 4:55 ` Stefan Monnier 2012-05-14 17:09 ` Johan Bockgård 0 siblings, 1 reply; 105+ messages in thread From: Stefan Monnier @ 2012-05-14 4:55 UTC (permalink / raw) To: egnarts-ms; +Cc: Emacs-devel > 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: lexical-binding questions 2012-05-14 4:55 ` Stefan Monnier @ 2012-05-14 17:09 ` Johan Bockgård 2012-05-15 17:54 ` egnarts-ms 0 siblings, 1 reply; 105+ messages in thread From: Johan Bockgård @ 2012-05-14 17:09 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: lexical-binding questions 2012-05-14 17:09 ` Johan Bockgård @ 2012-05-15 17:54 ` egnarts-ms 2012-05-15 20:14 ` Stefan Monnier 0 siblings, 1 reply; 105+ messages in thread From: egnarts-ms @ 2012-05-15 17:54 UTC (permalink / raw) To: Emacs-devel 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. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: lexical-binding questions 2012-05-15 17:54 ` egnarts-ms @ 2012-05-15 20:14 ` Stefan Monnier 2012-05-15 22:59 ` Johan Bockgård 0 siblings, 1 reply; 105+ messages in thread From: Stefan Monnier @ 2012-05-15 20:14 UTC (permalink / raw) To: egnarts-ms; +Cc: Emacs-devel >> 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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: lexical-binding questions 2012-05-15 20:14 ` Stefan Monnier @ 2012-05-15 22:59 ` Johan Bockgård 2012-05-16 2:05 ` Stefan Monnier 0 siblings, 1 reply; 105+ messages in thread From: Johan Bockgård @ 2012-05-15 22:59 UTC (permalink / raw) To: emacs-devel 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*. ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: lexical-binding questions 2012-05-15 22:59 ` Johan Bockgård @ 2012-05-16 2:05 ` Stefan Monnier 0 siblings, 0 replies; 105+ messages in thread From: Stefan Monnier @ 2012-05-16 2:05 UTC (permalink / raw) To: emacs-devel >>>> (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 ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC @ 2012-05-08 22:24 Martyn Jago 2012-05-09 17:33 ` BEGIN_SRC..END_SRC Stefan Monnier 0 siblings, 1 reply; 105+ messages in thread From: Martyn Jago @ 2012-05-08 22:24 UTC (permalink / raw) To: emacs-devel Nice diversion about the ugliness of Org-mode code delimitation. In the mean time, wouldn't it be prudent to answer the OP's question? ..." 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 " ^ permalink raw reply [flat|nested] 105+ messages in thread
* Re: BEGIN_SRC..END_SRC 2012-05-08 22:24 BEGIN_SRC..END_SRC Martyn Jago @ 2012-05-09 17:33 ` Stefan Monnier 0 siblings, 0 replies; 105+ messages in thread From: Stefan Monnier @ 2012-05-09 17:33 UTC (permalink / raw) To: Martyn Jago; +Cc: emacs-devel > Nice diversion about the ugliness of Org-mode code delimitation. > In the mean time, wouldn't it be prudent to answer the OP's question? I did that a long time ago. Stefan ^ permalink raw reply [flat|nested] 105+ messages in thread
end of thread, other threads:[~2012-06-08 0:20 UTC | newest] Thread overview: 105+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-05-05 6:30 lexical-binding questions Thierry Volpiatto 2012-05-05 6:45 ` Thierry Volpiatto 2012-05-05 8:16 ` BEGIN_SRC..END_SRC (was: lexical-binding questions) Eli Zaretskii 2012-05-05 8:39 ` BEGIN_SRC..END_SRC Tom Rauchenwald 2012-05-05 8:54 ` BEGIN_SRC..END_SRC Eli Zaretskii 2012-05-05 13:38 ` BEGIN_SRC..END_SRC Bastien 2012-05-05 17:02 ` BEGIN_SRC..END_SRC Eli Zaretskii 2012-05-06 16:03 ` BEGIN_SRC..END_SRC Bastien 2012-05-06 16:46 ` BEGIN_SRC..END_SRC Eli Zaretskii 2012-05-06 17:03 ` BEGIN_SRC..END_SRC Lars Magne Ingebrigtsen 2012-05-05 14:35 ` BEGIN_SRC..END_SRC Drew Adams 2012-05-05 15:10 ` BEGIN_SRC..END_SRC Antoine Levitt 2012-05-05 15:57 ` BEGIN_SRC..END_SRC Drew Adams 2012-05-05 17:00 ` BEGIN_SRC..END_SRC Peter Münster 2012-05-05 17:35 ` BEGIN_SRC..END_SRC Drew Adams 2012-05-05 21:38 ` BEGIN_SRC..END_SRC John Wiegley 2012-05-07 2:25 ` BEGIN_SRC..END_SRC Ted Zlatanov 2012-05-07 6:23 ` BEGIN_SRC..END_SRC Miles Bader 2012-05-07 9:37 ` BEGIN_SRC..END_SRC Thien-Thi Nguyen 2012-05-06 14:17 ` BEGIN_SRC..END_SRC Ted Zlatanov 2012-05-05 15:48 ` BEGIN_SRC..END_SRC Yann Hodique 2012-05-05 16:43 ` BEGIN_SRC..END_SRC Stephen J. Turnbull 2012-05-05 17:12 ` BEGIN_SRC..END_SRC Yann Hodique 2012-05-07 8:57 ` BEGIN_SRC..END_SRC Julien Danjou 2012-05-07 9:46 ` BEGIN_SRC..END_SRC Yann Hodique 2012-05-05 17:36 ` BEGIN_SRC..END_SRC Drew Adams 2012-05-05 19:48 ` BEGIN_SRC..END_SRC Martyn Jago 2012-05-05 20:00 ` BEGIN_SRC..END_SRC Drew Adams 2012-05-07 5:44 ` BEGIN_SRC..END_SRC Stephen J. Turnbull 2012-05-07 14:23 ` BEGIN_SRC..END_SRC Wolfgang Jenkner 2012-05-08 4:08 ` BEGIN_SRC..END_SRC Stephen J. Turnbull 2012-05-08 7:37 ` BEGIN_SRC..END_SRC Bastien 2012-05-08 11:41 ` BEGIN_SRC..END_SRC Juanma Barranquero 2012-05-08 12:17 ` BEGIN_SRC..END_SRC Stefan Monnier 2012-05-08 14:32 ` BEGIN_SRC..END_SRC Andreas Röhler 2012-05-09 1:23 ` BEGIN_SRC..END_SRC Stephen J. Turnbull 2012-05-09 17:31 ` BEGIN_SRC..END_SRC Stefan Monnier 2012-05-09 0:47 ` BEGIN_SRC..END_SRC Ted Zlatanov 2012-05-09 3:50 ` BEGIN_SRC..END_SRC Miles Bader 2012-05-09 11:35 ` BEGIN_SRC..END_SRC Ted Zlatanov 2012-05-09 12:23 ` BEGIN_SRC..END_SRC Stephen J. Turnbull 2012-05-09 13:43 ` BEGIN_SRC..END_SRC Lars Magne Ingebrigtsen 2012-05-09 14:57 ` BEGIN_SRC..END_SRC Eric Schulte 2012-05-09 17:08 ` BEGIN_SRC..END_SRC Yann Hodique 2012-05-09 16:06 ` BEGIN_SRC..END_SRC Eric Schulte 2012-05-09 18:20 ` BEGIN_SRC..END_SRC Yann Hodique 2012-05-09 16:30 ` BEGIN_SRC..END_SRC Eric Schulte 2012-05-09 18:44 ` BEGIN_SRC..END_SRC Yann Hodique 2012-05-10 7:44 ` BEGIN_SRC..END_SRC Stephen J. Turnbull 2012-05-10 7:28 ` BEGIN_SRC..END_SRC Stephen J. Turnbull 2012-05-10 7:59 ` BEGIN_SRC..END_SRC Yann Hodique 2012-05-10 12:35 ` BEGIN_SRC..END_SRC Stephen J. Turnbull 2012-05-10 13:28 ` BEGIN_SRC..END_SRC Yann Hodique 2012-05-10 13:51 ` BEGIN_SRC..END_SRC Miles Bader 2012-05-15 3:30 ` BEGIN_SRC..END_SRC Stephen J. Turnbull 2012-05-10 15:21 ` BEGIN_SRC..END_SRC Davis Herring 2012-05-15 3:56 ` BEGIN_SRC..END_SRC Stephen J. Turnbull 2012-05-10 9:02 ` BEGIN_SRC..END_SRC René Kyllingstad 2012-05-10 13:05 ` BEGIN_SRC..END_SRC Stephen J. Turnbull 2012-05-10 13:55 ` BEGIN_SRC..END_SRC René Kyllingstad 2012-05-15 3:52 ` BEGIN_SRC..END_SRC Stephen J. Turnbull 2012-05-16 14:00 ` BEGIN_SRC..END_SRC Ted Zlatanov 2012-05-09 13:52 ` BEGIN_SRC..END_SRC Tassilo Horn 2012-05-09 17:44 ` BEGIN_SRC..END_SRC Tassilo Horn 2012-05-09 17:33 ` BEGIN_SRC..END_SRC Stefan Monnier 2012-05-09 4:45 ` BEGIN_SRC..END_SRC Eli Zaretskii 2012-05-09 6:28 ` BEGIN_SRC..END_SRC Tassilo Horn 2012-05-09 9:30 ` BEGIN_SRC..END_SRC Peter Münster 2012-06-08 0:20 ` BEGIN_SRC..END_SRC Lars Magne Ingebrigtsen 2012-05-09 17:36 ` BEGIN_SRC..END_SRC Stefan Monnier 2012-05-10 0:56 ` BEGIN_SRC..END_SRC Miles Bader 2012-05-16 14:51 ` BEGIN_SRC..END_SRC Ted Zlatanov 2012-05-16 13:05 ` BEGIN_SRC..END_SRC Eric Schulte 2012-05-16 15:17 ` plain-text markdown handler for Gnus (was: BEGIN_SRC..END_SRC) Ted Zlatanov 2012-05-16 14:21 ` plain-text markdown handler for Gnus Eric Schulte 2012-05-16 16:29 ` Ted Zlatanov 2012-05-06 14:15 ` BEGIN_SRC..END_SRC Ted Zlatanov 2012-05-06 14:18 ` BEGIN_SRC..END_SRC Lennart Borgman 2012-05-06 14:33 ` BEGIN_SRC..END_SRC Alan Mackenzie 2012-05-06 14:43 ` BEGIN_SRC..END_SRC Lennart Borgman 2012-05-06 18:57 ` BEGIN_SRC..END_SRC Ted Zlatanov 2012-05-06 23:20 ` BEGIN_SRC..END_SRC Lennart Borgman 2012-05-07 2:21 ` BEGIN_SRC..END_SRC Ted Zlatanov 2012-05-07 9:56 ` BEGIN_SRC..END_SRC Lennart Borgman 2012-05-07 11:04 ` BEGIN_SRC..END_SRC Stephen J. Turnbull 2012-05-05 13:29 ` lexical-binding questions Stefan Monnier 2012-05-05 17:59 ` Thierry Volpiatto 2012-05-06 0:08 ` Miles Bader 2012-05-06 2:43 ` Stefan Monnier 2012-05-06 6:00 ` Thierry Volpiatto 2012-05-05 13:26 ` Stefan Monnier 2012-05-05 15:57 ` Thierry Volpiatto 2012-05-07 15:19 ` Stefan Monnier 2012-05-07 15:39 ` Drew Adams 2012-05-15 6:40 ` egnarts-ms 2012-05-15 13:55 ` Stefan Monnier 2012-05-14 3:57 ` egnarts-ms 2012-05-14 4:55 ` Stefan Monnier 2012-05-14 17:09 ` Johan Bockgård 2012-05-15 17:54 ` egnarts-ms 2012-05-15 20:14 ` Stefan Monnier 2012-05-15 22:59 ` Johan Bockgård 2012-05-16 2:05 ` Stefan Monnier -- strict thread matches above, loose matches on Subject: below -- 2012-05-08 22:24 BEGIN_SRC..END_SRC Martyn Jago 2012-05-09 17:33 ` BEGIN_SRC..END_SRC Stefan Monnier
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).