Re: [proof of concept] inline language blocks

2024-03-31 Thread Ihor Radchenko
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: https://www.danielcleme

Re: [proof of concept] inline language blocks

2024-03-31 Thread Daniel Clemente
> 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 syntax

Re: [proof of concept] inline language blocks

2024-02-29 Thread Juan Manuel Macías
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 &foo{text} to be >> passed to LaTeX as \bar{text}, instead of just &bar{text}? In HTML it >> does seem sensible to me that someone would want to cha

Re: [proof of concept] inline language blocks

2024-02-29 Thread Max Nikulin
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 &foo{text} to \bar{text} and text. The same is applicable for anonymous objects &_[:late

Re: [proof of concept] inline language blocks

2024-02-29 Thread Juan Manuel Macías
Max Nikulin writes: >> the user should expect something like &foo{...} 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 over

Re: [proof of concept] inline language blocks

2024-02-28 Thread Max Nikulin
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 wrote:

Re: [proof of concept] inline language blocks

2024-02-28 Thread 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 brother

Re: [proof of concept] inline language blocks

2024-02-28 Thread Max Nikulin
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 &la{lorem ip

Re: [proof of concept] inline language blocks

2024-02-28 Thread Juan Manuel Macías
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.

Re: [proof of concept] inline language blocks

2024-02-28 Thread Max Nikulin
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 Ita

Re: [proof of concept] inline language blocks

2024-02-21 Thread Suhail Singh
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 &type{text} Why not &:lang{text} (and/or &:lang[options]{text}) instead? In fact, it might help (in that it may redu

Re: [proof of concept] inline language blocks

2024-02-21 Thread Juan Manuel Macías
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:

Re: [proof of concept] inline language blocks

2024-02-21 Thread Samuel Wales
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 interesting

Re: [proof of concept] inline language blocks

2024-02-21 Thread Juan Manuel Macías
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, in

Re: [proof of concept] inline language blocks

2024-02-21 Thread Samuel Wales
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 support

[proof of concept] inline-special-block (was: [proof of concept] inline language blocks)

2024-02-21 Thread Juan Manuel Macías
I am attaching a patch in case anyone wants to try this proposal. A function for ox-latex is included. Syntax: &[optional parameters]{contents} With this patch, something like &foo{lorem ipsum dolor} is exported to LaTeX as \foo{lorem ipsum dolor}. Blocks can be nested, e.g.: &foo{lorem ipsum &

Re: [proof of concept] inline language blocks

2024-02-21 Thread Ihor Radchenko
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/ > > Fun

Re: [proof of concept] inline language blocks

2024-02-21 Thread Ihor Radchenko
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 i

Re: [proof of concept] inline language blocks

2024-02-21 Thread Juan Manuel Macías
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: >>> https://list.orgmode.org/orgmode/87

Re: [proof of concept] inline language blocks

2024-02-21 Thread Juan Manuel Macías
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. >>

Re: [proof of concept] inline language blocks

2024-02-21 Thread Ihor Radchenko
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}

Re: [proof of concept] inline language blocks

2024-02-21 Thread Juan Manuel Macías
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: >>

[proof of concept] inline language blocks

2024-02-20 Thread Juan Manuel Macías
Hi, 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 intended for small segments of text