Daniel Clemente writes:
> Sorry for joining the discussion a bit late. A long time ago I created a
> syntax to be able to mix languages in that way, and a program to separate
> each version into a different file.
>
> Info: https://www.danielclemente.com/dislines/
> Sample:
> I have thought of a syntax that is as least intrusive as possible, so as
> not to make reading uncomfortable. I have tried the following:
>
> :fr{some text in French} :it{some text in Italian} :la{some text in Latin}
Sorry for joining the discussion a bit late. A long time ago I created a
Max Nikulin writes:
>> Anyway, I think your example only makes sense in HTML, or at least I
>> can't make sense of it in LaTeX. Why would anyone want {text} to be
>> passed to LaTeX as \bar{text}, instead of just {text}? In HTML it
>> does seem sensible to me that someone would want to change the
On 29/02/2024 17:41, Juan Manuel Macías wrote:
Max Nikulin writes:
I do not try to dispute \foo and class="foo" as default behavior. I
suggest to implement possibility to override default behavior of
{text} to \bar{text} and text. The same is applicable
for anonymous objects
Max Nikulin writes:
>> the user should expect something like {...} to produce \foo{...} or
>> ..., etc. The only difference is that there would
>> be an anonymous variant &_{...}.
>
> I do not try to dispute \foo and class="foo" as default behavior. I
> suggest to implement possibility to
Juan Manuel,
I am not against optional arguments. The idea is to make the feature
more flexible and convenient for domain-specific documents. I did not
use square brackets in my example to concentrate on the use case of
concise and clear markup.
On 29/02/2024 06:42, Juan Manuel Macías
Max Nikulin writes:
> #+options: custom-object(:type la :latex_element foreignlanguage
> :latex_pre "{latin}")
mmm, I see it as not very flexible and perhaps too complicated for the user.
My idea with the concept of inline-special-block is that it is like the
inline version of its older
On 28/02/2024 20:15, Juan Manuel Macías wrote:
#+options: inline-special-block-aliases:(("latin" :lang "la" :color blue :prelatex "\\itshape "
:html "style=\"font-style:italic;\""))
This is an example of Latin text: &_[@latin@]{lorem ipsum dolor sit amet}.
It is more verbose than {lorem
Max Nikulin writes:
> Juan Manuel your ":fr{}" and similar objects is a domain-specific
> language that is quite different from a generic element proposed by
> Samuel. Do you think it makes sense to modify your inline special
> block patch to allow creation of concise DSL?
>
> Juan Manuel Macías.
On 22/02/2024 06:02, Juan Manuel Macías wrote:
Samuel Wales writes:
:fr{some text in French}
being expressed as
$[lang :fr "bonjour"]
To expand a little more... Another problem I see in your example is
nesting. In my proposal, the blocks can be nested:
:fr{text in French and :it{text in
Juan Manuel Macías writes:
> As I already said, in my local branch I have both elements created,
> based on the same syntax:
>
> - language block: :lang{text}
>
> - special block {text}
Why not &:lang{text} (and/or &:lang[options]{text}) instead? In fact,
it might help (in that it may reduce
Samuel Wales writes:
> for language feature, there are various options here which range from e.g.
> :fr{some text in French}
>
> being expressed as
>
> $[lang :fr "bonjour"]
>
To expand a little more... Another problem I see in your example is
nesting. In my proposal, the blocks can be nested:
yes as i said emphasis is convenient.
On 2/21/24, Juan Manuel Macías wrote:
> Samuel Wales writes:
>
>> for language feature, there are various options here which range from
>> e.g.
>>
>> :fr{some text in French}
>>
>> being expressed as
>>
>> $[lang :fr "bonjour"]
>
> Thanks for your
Samuel Wales writes:
> for language feature, there are various options here which range from e.g.
>
> :fr{some text in French}
>
> being expressed as
>
> $[lang :fr "bonjour"]
Thanks for your interesting comment. However, your example still seems
too verbose to me. There are two elements that,
at risk of being like a broken record [over many years]: i still like
cl lambda lists e.g. $[thing arg :kw value :kw value] or %(thing ...)
for allowing generality to basically all new syntax of most types,
extensibility, user-defined major ["thing"] and minor [":kw"] features
if desired to
Juan Manuel Macías writes:
> Ihor Radchenko writes:
>> This is a good idea, although it would be better to make this new markup
>> element within the framework of more general inline special block we
>> discussed in the past:
>> https://list.orgmode.org/orgmode/87a6b8pbhg@posteo.net/
>
>
Juan Manuel Macías writes:
> I'm dedicating a local branch to developing this proof of concept and
> testing it in my workflow, so far with good results. The basic idea is
> to provide Org with multilingual features and various methods for
> selecting languages.
>
> The inline-language-block is
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>> Ihor Radchenko writes:
>>> This is a good idea, although it would be better to make this new markup
>>> element within the framework of more general inline special block we
>>> discussed in the past:
>>>
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>> I'm dedicating a local branch to developing this proof of concept and
>> testing it in my workflow, so far with good results. The basic idea is
>> to provide Org with multilingual features and various methods for
>> selecting languages.
>>
Juan Manuel Macías writes:
>> We need to finalize inline special block syntax first, and then talk
>> about special cases like inline language markup you propose.
>
> As I already said, in my local branch I have both elements created,
> based on the same syntax:
>
> - language block: :lang{text}
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>>> We need to finalize inline special block syntax first, and then talk
>>> about special cases like inline language markup you propose.
>>
>> As I already said, in my local branch I have both elements created,
>> based on the same syntax:
21 matches
Mail list logo
