From: Jens J. M. <je...@fy...> - 2005-01-26 12:57:21
|
If I use a role with a long name often, then it would be nice if I could=20 write simply `hrmpf` instead of :role-with-a-long-name:`hrmpf` all the ti= me. Is it possible to specify which role to use as default for interpreted te= xt? Jens J=C3=B8rgen |
From: Felix W. <Fel...@gm...> - 2005-02-02 11:43:30
|
Jens Jorgen Mortensen <jensj <at> fysik.dtu.dk> writes: > If I use a role with a long name often, then it would be nice if I could > write simply `hrmpf` instead of :role-with-a-long-name:`hrmpf` all the time. > > Is it possible to specify which role to use as default for interpreted text? Not yet, but I think it will be implemented sooner or later. (Also for directives it might be convenient to have a default directive.) |
From: David G. <go...@py...> - 2005-02-11 15:37:49
Attachments:
signature.asc
|
> Jens Jorgen Mortensen <jensj <at> fysik.dtu.dk> writes: >> Is it possible to specify which role to use as default for >> interpreted text? [Felix Wiemann] > Not yet, but I think it will be implemented sooner or later. Correct. It's on the to-do list, and may be implemented sooner than later. > (Also for directives it might be convenient to have a default > directive.) I don't follow this. Could you explain your meaning? -- David Goodger <http://python.net/~goodger> |
From: Felix W. <Fel...@gm...> - 2005-02-11 16:21:19
|
David Goodger wrote: > Felix Wiemann wrote: > >> (Also for directives it might be convenient to have a default >> directive.) > > I don't follow this. Could you explain your meaning? I'm thinking of something like this: "Marked directive" (activated with double colon):: This is currently a literal_block doctree element. "Unmarked directive" (without double colon): Currently a block_quote doctree element. For both literal_block and block_quote there is no directive creating these elements, but it should be easy to write such directives (let's call them "literal" and "quote"). The "literal" directive would be the default marked directive, and the "quote" directive would be the default unmarked directive. So if someone wants to have parsed literal blocks by default, like this:: This is a text with *emphasis*. The user wants the emphasized word to be recognized here. he would just make "parsed-literal" the default marked directive (e.g. with ".. marked-directive:: parsed-literal"). Naming ("marked/unmarked") will probably need some improvement, but generally that's what I was thinking of. -- When replying to my email address, please ensure that the mail header contains 'Felix Wiemann'. http://www.ososo.de/ |
From: Beni C. <cb...@us...> - 2005-02-12 20:29:05
|
Felix Wiemann wrote: > > I'm thinking of something like this: > > "Marked directive" (activated with double colon):: > > This is currently a literal_block doctree element. > > "Unmarked directive" (without double colon): > > Currently a block_quote doctree element. > > For both literal_block and block_quote there is no directive creating > these elements, but it should be easy to write such directives (let's > call them "literal" and "quote"). The "literal" directive would be the > default marked directive, and the "quote" directive would be the default > unmarked directive. > > So if someone wants to have parsed literal blocks by default, like > this:: > > This is a text with *emphasis*. The user wants the emphasized word > to be recognized here. > > he would just make "parsed-literal" the default marked directive > (e.g. with ".. marked-directive:: parsed-literal"). > > Naming ("marked/unmarked") will probably need some improvement, but > generally that's what I was thinking of. > The "marked" :: literal blocks currently correspond 1:1 to ``double-backquote`` literal text. So I think that if you allow choosing the directive called for both "marked" and "unmarked" blocks, you should allow choosing the roles called for both ``marked`` and `unmarked` interpreted text. And vice versa: if you don't allow customizing ``literal`` text, don't allow customizing literal blocks. I'm -0 on allowing customization of both literal blocks and text on grounds of the "0, 1, infinity" rule -- if we have 2 hookable constructs, we should have many more. -- Beni Cherniavsky <cb...@us...>, who can only read email on weekends. |
From: Felix W. <Fel...@gm...> - 2005-02-12 21:16:07
|
Beni Cherniavsky wrote: > The "marked" :: literal blocks currently correspond 1:1 to > ``double-backquote`` literal text. So I think that if you allow > choosing the directive called for both "marked" and "unmarked" blocks, > you should allow choosing the roles called for both ``marked`` and > `unmarked` interpreted text. Yes, that would be a good idea. > I'm -0 on allowing customization of both literal blocks and text on > grounds of the "0, 1, infinity" rule -- if we have 2 hookable > constructs, we should have many more. But what other constructs could be hooked at all? I see only four: marked role, unmarked role, marked directive, unmarked directive. Or do you mean we should have a uniform hooking interface? Like :: .. set-default:: marked role: somerole .. set-default:: unmarked directive: somedirective (I'm not sure if I understand you correctly.) -- When replying to my email address, please ensure that the mail header contains 'Felix Wiemann'. http://www.ososo.de/ |
From: Beni C. <cb...@us...> - 2005-02-12 22:48:47
|
Felix Wiemann wrote: > Beni Cherniavsky wrote: > >>The "marked" :: literal blocks currently correspond 1:1 to >>``double-backquote`` literal text. So I think that if you allow >>choosing the directive called for both "marked" and "unmarked" blocks, >>you should allow choosing the roles called for both ``marked`` and >>`unmarked` interpreted text. >> >>I'm -0 on allowing customization of both literal blocks and text on >>grounds of the "0, 1, infinity" rule -- if we have 2 hookable >>constructs, we should have many more. > > But what other constructs could be hooked at all? I see only four: > marked role, unmarked role, marked directive, unmarked directive. > If you can hook literal text, why not hook other things like emphasis or bullet lists? The fact that literal text uses backquotes doesn't make it special in any way. Single backquotes aren't very special either, except that they are the barest grouping syntax in reST and were always intended to become hookable. Blockquotes were never intended to be hookable but are undeniably the barest block syntax in reST. I feel that we should have exactly one construct hookable construct (per {role,directive} kind) or we would have to allow hooking everything, and while that would be nice in some sense, I'm not sure it would be reST any longer. It's quite a subjective call, so I'm only -0 on more than "unmarked" hooking. > Or do you mean we should have a uniform hooking interface? Like :: > > .. set-default:: marked role: somerole > .. set-default:: unmarked directive: somedirective > I didn't mean the interface at all. If you only have 2 hookable constructs, this seems like an overkill. If you have many, some generic interface will be in order. -- Beni Cherniavsky <cb...@us...>, who can only read email on weekends. |
From: Felix W. <Fel...@gm...> - 2005-02-13 16:42:07
|
Beni Cherniavsky wrote: > If you can hook literal text, why not hook other things like emphasis I don't see much point in changing the meaning of emphasized text. > or bullet lists? Impossible to hook, I suppose. You might very well want to change the meaning of ``double-backquoted`` text from "literal" to "option", "regular-expression", "method" etc. But as I said, I don't know what I would want to change the meaning of *emphasis* to. > The fact that literal text uses backquotes doesn't make it special in > any way. Literal text *is* special, because no further inline markup recognition is done. While this currently only means that backslashes aren't interpreted as escape characters, it will make more of a difference as soon as nested inline markup is implemented. I just get the following idea: All roles which request to receive unparsed contents (like "literal", or a LaTeX math role) could be surrounded by double-backquotes (:literal:``some text``), and all roles with nested parsing (like "emphasis" or "subscript") could be surrounded by single backquotes (:emphasis:`some text`). The former type of role (with unparsed contents) is currently unsupported, but I'm quite sure we will need support for it. E.g., the latex-math role (which needs to have the original backslashes) currently works around this limitation by using the "rawsource" parameter, but that's a hack and nothing more. We will need the distinction between parsed-content and unparsed-content roles at the latest when nested inline markup is supported, because if we don't support these two kinds of roles by then, any role content would be required to be valid reST: :some-role:`*foo` would be impossible. So we'll need a double-backquote syntax: :some-role:``*foo`` -- When replying to my email address, please ensure that the mail header contains 'Felix Wiemann'. http://www.ososo.de/ |
From: David G. <go...@py...> - 2005-02-16 02:56:51
Attachments:
signature.asc
|
I don't see any need to "hook" the markup currently used for literal blocks (i.e. "default directive"), block quotes, or inline literals (let alone any other basic markup). Without a clear and persuasive need, I don't see the point. Just because something *can* be done, doesn't mean it *should* be done. The interpreted text markup was always meant to be "hookable". A role is required and a default role exists (allowing the explicit role to be omitted). Allowing the author to change the default role for a document is a logical convenience. [Felix Wiemann] > I just get the following idea: All roles which request to receive > unparsed contents (like "literal", or a LaTeX math role) could be > surrounded by double-backquotes (:literal:``some text``), and all > roles with nested parsing (like "emphasis" or "subscript") could be > surrounded by single backquotes (:emphasis:`some text`). The :role:``literal`` syntax has actually been proposed before, by Alan Isaac on 2004-11-11 in a docutils-users post. It's an interesting and potentially useful idea for additional functionality -- an idea that almost falls naturally out of the markup spec (i.e., it's additional functionality without [much] additional semantic load). Rather than having some roles work with `single backquotes` and others work with ``double``, I think all roles should work with both. The choice would be up to the author, depending on the content and desired processing. +1 on the :role:``unparsed`` syntax. -- David Goodger <http://python.net/~goodger> |
From: Felix W. <Fel...@gm...> - 2005-02-16 13:27:13
|
David Goodger wrote: > I don't see any need to "hook" the markup currently used for literal > blocks (i.e. "default directive"), block quotes, or inline literals > (let alone any other basic markup). Without a clear and persuasive > need, I don't see the point. When writing documents about mathematics or physics, you could want math equations without explicitly specifying it each time. So instead of :: Pythagoras's theorem says: .. latex-math:: a^2 + b^2 = c^2 I'd want to write :: Pythagoras's theorem says: a^2 + b^2 = c^2 You can probably find other use cases as well. > The :role:``literal`` syntax [is] an interesting and potentially > useful idea for additional functionality [...]. Rather than having > some roles work with `single backquotes` and others work with > ``double``, I think all roles should work with both. The choice would > be up to the author, depending on the content and desired processing. The roles which expect literal text (say, the math role) can't process a node tree (and a node tree is what you'd eventually get, at the latest when there's nested inline markup). So you'd *have* to use :math:``somemath``, and :math:`somemath` would be forbidden. OTOH when we have a typewriter role, the author should be able to use both :tt:``some *literal \text`` as well as :tt:`text with *emphasis*`. So roles should probably specify whether they expect a node list or literal text; and if a role takes a node list, the reST parser can helpfully allow :role:``literal *text`` and convert it to a single Text node before passing it to the role handler. -- When replying to my email address, please ensure that the mail header contains 'Felix Wiemann'. http://www.ososo.de/ |
From: David G. <go...@py...> - 2005-02-16 15:24:42
Attachments:
signature.asc
|
> David Goodger wrote: >> I don't see any need to "hook" the markup currently used for >> literal blocks (i.e. "default directive"), block quotes, or inline >> literals (let alone any other basic markup). Without a clear and >> persuasive need, I don't see the point. [Felix Wiemann] > When writing documents about mathematics or physics, you could want > math equations without explicitly specifying it each time. So > instead of :: > > Pythagoras's theorem says: > > .. latex-math:: > > a^2 + b^2 = c^2 > > I'd want to write :: > > Pythagoras's theorem says: > > a^2 + b^2 = c^2 > > You can probably find other use cases as well. -1. Too implicit for my taste ("explicit is better than..."), and not compelling. >> The :role:``literal`` syntax [is] an interesting and potentially >> useful idea for additional functionality [...]. Rather than having >> some roles work with `single backquotes` and others work with >> ``double``, I think all roles should work with both. The choice >> would be up to the author, depending on the content and desired >> processing. > > The roles which expect literal text (say, the math role) can't > process a node tree (and a node tree is what you'd eventually get, > at the latest when there's nested inline markup). Not necessarily. Depends on the when the nested parsing takes place: before the role code is called, or after/during (i.e., nested parsing initiated *by* the role code). I'd say that because of this issue, the role code *must* initiate the nested parse. > So you'd *have* to use :math:``somemath``, and :math:`somemath` > would be forbidden. IMO, such a restriction would place an unneccessary burden on the author. Custom roles based on the "raw" role work fine with single-backquotes now, and should continue to work in future. > OTOH when we have a typewriter role, the author should be able to > use both :tt:``some *literal \text`` as well as :tt:`text with > *emphasis*`. Right. That's the author's choice, because :tt: can handle both cases. > So roles should probably specify whether they expect a node list or > literal text; and if a role takes a node list, the reST parser can > helpfully allow :role:``literal *text`` and convert it to a single > Text node before passing it to the role handler. Rather than specifying what they expect, roles should process their content appropriately. Think outside-in instead of inside-out. No "helpful conversion" required or desired, I think. -- David Goodger <http://python.net/~goodger> |
From: Felix W. <Fel...@gm...> - 2005-02-17 15:05:05
|
David Goodger wrote: > Felix Wiemann wrote: > >> I'd want to write :: >> >> Pythagoras's theorem says: >> >> a^2 + b^2 = c^2 >> >> You can probably find other use cases as well. > > -1. Too implicit for my taste ("explicit is better than..."), and not > compelling. I'm not suggesting heuristics; of course you'd have to declare the latex-math directive as default "unmarked" directive before, like :: .. default:: unmarked directive: latex-math So it would be explicit, actually. If you have to write ".. latex-math::" in front of every equation, native reST becomes de-facto unusable for mathematical document authoring, and you have to use hacks again. >>> Rather than having some roles work with `single backquotes` and >>> others work with ``double``, I think all roles should work with >>> both. >> >> The roles which expect literal text (say, the math role) can't >> process a node tree (and a node tree is what you'd eventually get, >> at the latest when there's nested inline markup). > > Not necessarily. Depends on the when the nested parsing takes place: > before the role code is called, or after/during (i.e., nested parsing > initiated *by* the role code). Then you complicate the parser spec, because you can't allow things like this:: :role:`some :otherrole:`nested` content` The parser wouldn't know where the end the role content is, because it doesn't know whether it's literal or parsed content. So knowing at parse-time if the role content is parsed or literal seems indeed necessary. >> So you'd *have* to use :math:``somemath``, and :math:`somemath` >> would be forbidden. > > IMO, such a restriction would place an unneccessary burden on the > author. Custom roles based on the "raw" role work fine with > single-backquotes now, and should continue to work in future. I'm not convinced that maintaining compatibility in this regard is worth the tradeoffs we'd have to make. -- When replying to my email address, please ensure that the mail header contains 'Felix Wiemann'. http://www.ososo.de/ |
From: David G. <go...@py...> - 2005-02-17 16:54:45
Attachments:
signature.asc
|
Felix Wiemann wrote: >>> I'd want to write :: >>> >>> Pythagoras's theorem says: >>> >>> a^2 + b^2 = c^2 >>> >>> You can probably find other use cases as well. David Goodger wrote: >> -1. Too implicit for my taste ("explicit is better than..."), and not >> compelling. Felix Wiemann wrote: > I'm not suggesting heuristics; of course you'd have to declare the > latex-math directive as default "unmarked" directive before, like :: > > .. default:: unmarked directive: latex-math Yes, I realized that an explicit declaration would be needed. I meant that the usage was too implicit, since there's no explicit directive. > So it would be explicit, actually. Perhaps, but in an indirect and confusing way. I think block quotes and literal blocks are too basic to mess with. > If you have to write ".. latex-math::" in front of every equation, > native reST becomes de-facto unusable for mathematical document > authoring, and you have to use hacks again. I disagree. I don't think requiring an explicit directive makes reST unusable at all, and I do think that making block quotes and literal blocks jump through hoops would make reST more complex and surprising. I think the potential damage from confusion far outweighs any gain. >>> The roles which expect literal text (say, the math role) can't >>> process a node tree (and a node tree is what you'd eventually get, >>> at the latest when there's nested inline markup). >> >> Not necessarily. Depends on the when the nested parsing takes >> place: before the role code is called, or after/during (i.e., >> nested parsing initiated *by* the role code). > > Then you complicate the parser spec, because you can't allow things > like this:: > > :role:`some :otherrole:`nested` content` > > The parser wouldn't know where the end the role content is, because > it doesn't know whether it's literal or parsed content. Anything in single-backquotes will be able to contain nested content (once reST supports nested inline markup, of course). True, the parser will have to traverse such content in order to determine its end. But some roles simply won't be able to handle a node tree, and what the role does with its content is determined by the role code. Anyhow, this is all just so much hand-waving. > So knowing at parse-time if the role content is parsed or literal > seems indeed necessary. I think we're way ahead of ourselves here. I don't see the point in debating a potential problem with an as-yet-unimplemented future feature. >>> So you'd *have* to use :math:``somemath``, and :math:`somemath` >>> would be forbidden. >> >> IMO, such a restriction would place an unneccessary burden on the >> author. Custom roles based on the "raw" role work fine with >> single-backquotes now, and should continue to work in future. > > I'm not convinced that maintaining compatibility in this regard is > worth the tradeoffs we'd have to make. It's too early to tell. All I have is a gut instinct. I vote we drop the discussion until we have something concrete to discuss. -- David Goodger <http://python.net/~goodger> |
From: Alan G I. <ai...@am...> - 2005-02-17 15:08:33
|
On Wed, 16 Feb 2005, Felix Wiemann apparently wrote: > I'd want to write :: > Pythagoras's theorem says: > a^2 + b^2 = c^2 David nixed this as too implicit. Might the following new syntax be considered? :: Pythagoras's theorem says::: a^2 + b^2 = c^2 Here ':::' would call on a declared directive, which might be different in each document. Since the directive would be declared, this becomes perhaps less "implicit"? fwiw, Alan Isaac |
From: David G. <go...@py...> - 2005-02-17 16:55:54
Attachments:
signature.asc
|
> On Wed, 16 Feb 2005, Felix Wiemann apparently wrote: >>I'd want to write :: >> >> Pythagoras's theorem says: >> >> a^2 + b^2 = c^2 [Alan G Isaac] > David nixed this as too implicit. I only voiced my opinion, which is not written in stone. > Might the following new syntax be considered? :: > > Pythagoras's theorem says::: > > a^2 + b^2 = c^2 > > Here ':::' would call on a declared directive, > which might be different in each document. Since > the directive would be declared, this becomes perhaps > less "implicit"? Throwing out new implicit syntax is not a solution. It's simply a matter of the surprise/confusion/complexity outweighing the convenience. -- David Goodger <http://python.net/~goodger> |
From: Beni C. <cb...@us...> - 2005-02-18 13:59:25
|
David Goodger wrote: >> On Wed, 16 Feb 2005, Felix Wiemann apparently wrote: >> >>> I'd want to write :: >>> >>> Pythagoras's theorem says: >>> >>> a^2 + b^2 = c^2 > > [Alan G Isaac] > >> David nixed this as too implicit. > > I only voiced my opinion, which is not written in stone. > Thinking again, I also feel that hooking existing constructs, e.g. indented blocks, is too implicit. I felt that syntactically they parallel single backquotes (the way ``::`` literate blocks parallel double backquotes) but it's not precise syntactically and certainly not precise sematically. Indented blocks always had a well-defined meaning as block quotes (whose closest inline parallels is simple "quoted text") and it remains useful in all documents. >> Might the following new syntax be considered? :: >> >> Pythagoras's theorem says::: >> >> a^2 + b^2 = c^2 >> >> Here ':::' would call on a declared directive, >> which might be different in each document. Since >> the directive would be declared, this becomes perhaps >> less "implicit"? > > Throwing out new implicit syntax is not a solution. > > It's simply a matter of the surprise/confusion/complexity outweighing > the convenience. > Why is:: text `math` text less surprising/confusing/complex or gives more convenience gain than:: text text ::: math formula text text ? I'm not asking about the ``:::`` syntax specifically. I'm asking about the idea of having *some* shorthand syntax (whether existing or new) that can stand for a directive of the author's choice. The problem can be expressed thus: if a document is littered with one role (say inline math), it'll usually be littered with the corresponding directive (say display math). Therefore, if writing the name of the role every time is annoying, then writing the name of the directive is equally annoying. Can you explain your feeling that a default role syntax is good but a default directive syntax is too implicit? I can see only two points: - A default role syntax was invented long ago and we are all used to it. No default directive syntax was invented long ago. => Not a reason. - The reading clutter of ``:role-name:`` is higher than that of ``.. directive name::`` because the latter is not inline in the middle of the text and is better visually separated from the text and so is easier to skip when reading. => Doesn't convince me. -- Beni Cherniavsky <cb...@us...>, who can only read email on weekends. |
From: Aahz <aa...@py...> - 2005-02-18 14:35:47
|
On Fri, Feb 18, 2005, Beni Cherniavsky wrote: > > - The reading clutter of ``:role-name:`` is higher than that of > ``.. directive name::`` because the latter is not inline in the > middle of the text and is better visually separated from the text > and so is easier to skip when reading. => Doesn't convince me. However, it convinces me. ;-) Also, I think the mechanics of using a text editor to insert boilerplate are easier/simpler for lines of text compared to in-line snippets. -- Aahz (aa...@py...) <*> http://www.pythoncraft.com/ "The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code -- not in reams of trivial code that bores the reader to death." --GvR |
From: Felix W. <Fel...@gm...> - 2005-02-18 15:23:34
|
Aahz wrote: > Beni Cherniavsky wrote: > >> - The reading clutter of ``:role-name:`` is higher than that of >> ``.. directive name::`` because the latter is not inline in the >> middle of the text and is better visually separated from the text >> and so is easier to skip when reading. => Doesn't convince me. > > However, it convinces me. ;-) Also, I think the mechanics of using a > text editor to insert boilerplate are easier/simpler for lines of text > compared to in-line snippets. True. Using boilerplates is no problem, and the reader can easily skip unnecessary text when reading the document. > -- > Aahz (aa...@py...) <*> http://www.pythoncraft.com/ > > "The joy of coding Python should be in seeing short, concise, readable > classes that express a lot of action in a small amount of clear code -- > not in reams of trivial code that bores the reader to death." --GvR Ummm... WHAT? :-) SCNR, really. (Yes, I was being ironic.) -- When replying to my email address, please ensure that the mail header contains 'Felix Wiemann'. http://www.ososo.de/ |
From: Alan G I. <ai...@am...> - 2005-02-18 17:56:27
|
On Fri, 18 Feb 2005, Felix Wiemann apparently wrote: > True. Using boilerplates is no problem, and the reader > can easily skip unnecessary text when reading the > document. 1. easily != costlessly 2. Apply this reasoning to blockquote and ... Indeed, given relative frequency of need, making blockquote explicit and latex-math implicit would be reasonable. However allowing the preferred implicit use to be declared seems nicest (to this user). fwiw, Alan Isaac |
From: Felix W. <Fel...@gm...> - 2005-02-18 15:01:26
|
Beni Cherniavsky wrote: > Thinking again, I also feel that hooking existing constructs, > e.g. indented blocks, is too implicit. I felt that syntactically they > parallel single backquotes (the way ``::`` literate blocks parallel > double backquotes) but it's not precise syntactically and certainly > not precise sematically. No, but do they have to be parallel? > Indented blocks always had a well-defined meaning as block quotes > (whose closest inline parallels is simple "quoted text") and it > remains useful in all documents. In many documents you need only few block quotes, or none at all. However, in some documents you have many equations, and indentation is also natural for equations. There's often text like this: So as long as sqrt(npq) >= 9 we can safely assume that f_B(k, n, p) = 1/sigma * phi((k - mu) / sigma) and F_B(k, n, p) = Phi((k + 0.5 - mu) / sigma) with reasonable accuracy. This is often easier to calculate than f_B(k, n, p) = (n atop k) p^k q^(n-k) or f_B(k, n, p) = sum from i=0 to k ((n atop i) p^k q^(n-i)), especially for large `n`. This is perfectly well-readable and anything but confusing or implicit, and prepending each equation with a ".. ascii-math::" would clutter up things terribly. No, I don't want to add explicit hints in front of the equations (like "::" or ":::") either. I mean, it's just my choice as a document author if I want indented blocks to indicate equations (or, more precisely, equation lists) instead of block quotes. If I misuse the feature so that my document becomes confusing and unreadable, that's my own problem. It's not reStructuredText's job to prevent me from doing stupid things; and especially reST should *not* prevent me from doing useful things. The same applies to "::"-marked blocks. David Abrahams used a *lot* of parsed-literals in his book, and I could imagine that a possibility to make parsed-literal the default directive would have made the source a lot more readable. > Why is:: > > text `math` text > > less surprising/confusing/complex or gives more convenience gain than:: > > text text ::: > > math formula > > text text The latter adds yet another syntax construct. I think it's a bad idea to add more syntax. -- When replying to my email address, please ensure that the mail header contains 'Felix Wiemann'. http://www.ososo.de/ |
From: G. M. <g....@we...> - 2005-02-25 14:25:34
|
On 18.02.05, Felix Wiemann wrote: > Beni Cherniavsky wrote: Explicit defining math as default role and making the math role "block aware" would IMHO be a good compromise between readability/ease of use and explicity. As long as `sqrt(npq) >= 9` we can safely assume that `f_B(k, n, p) = 1/sigma * phi((k - mu) / sigma)` and `F_B(k, n, p) = Phi((k + 0.5 - mu) / sigma)` with reasonable accuracy. Seems consistent and easily understandable to me. Problems: --------- equation arrays: math blocks over several lines numbering: could we use something like As long as `sqrt(npq) >= 9` we can safely assume that `f_B(k, n, p) = 1/sigma * phi((k - mu) / sigma)` (#) and `F_B(k, n, p) = Phi((k + 0.5 - mu) / sigma)` (#) with reasonable accuracy. Sincerely Günter -- G.Milde web.de |
From: Felix W. <Fel...@gm...> - 2005-02-25 15:39:46
|
G. Milde wrote: > Explicit defining math as default role and making the math role "block > aware" would IMHO be a good compromise between readability/ease of use > and explicity. > > As long as `sqrt(npq) >= 9` we can safely assume that > > `f_B(k, n, p) = 1/sigma * phi((k - mu) / sigma)` This is not a viable solution; the equation would still be a block quote (which is plain wrong in this context), and there'd be no distinction between inline formulas and block-level equations. -- When replying to my email address, please ensure that the mail header contains 'Felix Wiemann'. http://www.ososo.de/ |
From: G. M. <g....@we...> - 2005-02-28 13:01:08
|
On 25.02.05, Felix Wiemann wrote: > G. Milde wrote: > > As long as `sqrt(npq) >= 9` we can safely assume that > > > > `f_B(k, n, p) = 1/sigma * phi((k - mu) / sigma)` > > This is not a viable solution; the equation would still be a block quote > (which is plain wrong in this context), and there'd be no distinction > between inline formulas and block-level equations. It would not be a solution currently, but my proposal was > > ... making the math role "block aware" What I meant by this is: Translate a block-quote that contains only math to display-math (in latex: equation environment). I cannot imagine a case where a block quote with inline math would be needed (or intended) by an author. Maybe this is due to my limited imagination, but however I am confident that these cases (if existend) will be rare. IMHO, the conversion of a math-block-quote to display math is "natural", i.e. follows the principle of least surprise. Günter -- G.Milde web.de |
From: Felix W. <Fel...@gm...> - 2005-03-04 21:38:38
|
G. Milde wrote: > What I meant by this is: Translate a block-quote that contains only > math to display-math (in latex: equation environment). As soon as you have another extension which wants to support it (e.g. "ascii-math"), you get code duplication. It's too hackish IMO. -- When replying to my email address, please ensure that the mail header contains 'Felix Wiemann'. http://www.ososo.de/ |
From: G. M. <g....@we...> - 2005-03-07 08:20:58
|
On 4.03.05, Felix Wiemann wrote: > G. Milde wrote: > > > What I meant by this is: Translate a block-quote that contains only > > math to display-math (in latex: equation environment). > > As soon as you have another extension which wants to support it > (e.g. "ascii-math"), you get code duplication. It's too hackish IMO. Well, I would like all "math-roles" (latex-math, ascii-math, math-ml, ...) to display a block-quote as 'equation' environment. (Setting some math-role as default-role should just keep this behaviour.) Maybe there could be an option in the role-defining interface where a role would define its "latex-block-quote-environment" (defaulting to 'quote' or 'quotation'). This would add fexibility and prevent code duplication. Sincerely Günter -- G.Milde web.de |