Hello
Just found a minor issue about the org-goto interface. When I set
`org-goto-auto-isearch' as `t', the number keys should also be part of
isearch, not treated as "digit argument". However, the current version
(9.7-pre) of OrgMode I am using treat the number keys as digit argument
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
Juan Manuel Macías writes:
> Syntax:
>
> &[optional parameters]{contents}
Correction:
[optional parameters]{contents}
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
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 {lorem ipsum dolor} is exported to
LaTeX as \foo{lorem ipsum dolor}.
Blocks can be nested, e.g.: {lorem ipsum
On 21.02.2024 10:40, Ihor Radchenko wrote:
gerard.vermeu...@posteo.net writes:
Still failing on my side (when running tests non-interactively from
command line). To fix the problem, please use the approach from
`test-org-list/indent-item':
(transient-mark-mode 1)
Hi,
I started getting an error after updating to the latest commit on main:
Invalid capture target specification: (file+headline org-default-notes-file
"Tasks")
I bisected it down to 0a58a53edac955381266e49bd68d1140fbece33e, but I can't
tell from the commit what's wrong with my definition or
Hi Ihor,
Ihor Radchenko writes:
>
> Thanks for the code!
> It is a lot more that I expected.
Note that only the first 5 patchs are real patchs. The remaining things
are just a demo how it could be used. The current async (ob-comint)
depends on writing UUIDs in org files, and, that's why I
Awesome work! Thanks for tracking that down!
On Wed, Feb 21, 2024 at 6:17 AM Ihor Radchenko wrote:
> John Kitchin writes:
>
> > However, if I edebug `calendar-make-temp-face' and step through each
> line,
> > then it works the same as using a face. And, after that it seems to work
> > most of
Hi Jack,
Jack Kamm writes:
> Bruno Barbier writes:
>
>> I'm not using it with official org backends (yet). I'm using it with
>> several custom backends that I'm working on. One of the backend
>> delegate the block executions to emacs subprocesses: so I have a kind of
>> asynchronous
John Kitchin writes:
> However, if I edebug `calendar-make-temp-face' and step through each line,
> then it works the same as using a face. And, after that it seems to work
> most of the time.
It turned out that the problem is caused by interaction between Org
mode's overlay and calendar.el's
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/
>
>
Leo Butler writes:
> Thanks for your comments.
>
> I think the attached patch addresses each of your points. It's not clear
> to me what you mean by "link(ing) this org-lint warning to the
> `org-beamer-frame-environment' docstring", but I have expanded the
> warning include mention of this
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
On 19/02/2024 02:36, Martin Edström wrote:
+Since this is a shell-command, remember to use single-quotes
+around \\='%i\\=', not double-quotes! Else a math fragment such
+as \"$y = 200$\" gets butchered into only \" = 200\"."
I am afraid, the code, not the docstring must be fixed. I have not
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}
Hi Matt,
Thanks for your answer.
Matt writes:
> ...
> If I understand correctly, there are several independent topics the code
> addresses:
>
> | topic| manner addressed |
> |--+|
> |
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:
gerard.vermeu...@posteo.net writes:
>>> Still failing on my side (when running tests non-interactively from
>>> command line). To fix the problem, please use the approach from
>>> `test-org-list/indent-item':
>>>
>>> (transient-mark-mode 1)
>>> (push-mark (point) t t)
>>>
>>>
24 matches
Mail list logo
