Thank you so much for explaining all of that! There is some good information
there I was missing. I think the most important bit I was missing is the
post-blank stuff. I was only looking at begin->end but I think digging into the
post-blank is what makes this consistent.
I've got 2 separate
On Mon, 30 Jan 2023 14:41:18 +0100 Ihor Radchenko wrote ---
> The following libraries have no maintainer or author active on the list:
> ob-comint, ob-core, ...
I'm interested (and technically still maintainer of ob-shell). ob-comint and
ob-core are both used by ob-shell, so I've
Thanks, will continue there.
On Tue, Aug 15, 2023 at 6:11 PM Ihor Radchenko wrote:
> Hrvoje Nikšić writes:
>
> > Can we discuss the technical details in a separate email thread or
> ticket?
>
> I opened an issue on github:
> https://github.com/hniksic/emacs-htmlize/issues/47
>
> --
> Ihor
Sławomir Grochowski writes:
> I thought it would get lost in the many thousands of other TODOs you have
> on your plate.
> Thank you.
Merging contributed patches is high priority. I either have them
scheduled in agenda or they are the next thing to do upon clearing the
scheduled tasks.
The
Liu Hui writes:
> I think these objects need to be shown in a single column rather than
> two. Besides, if the python code becomes too complex finally, I think
> maintaining the python code outside the ob-python.el, as suggested by
> Ihor, is a good idea.
Thanks for reporting these misbehaving
Jack Kamm writes:
> In the meantime, I'm thinking to squash and apply my patch as is. Then
> afterwards, I can start working on a followup patch to move some Python
> code into a separate file (and coordinate with emacs-devel if
> necessary).
+1
Don't forget to update
Jack Kamm writes:
> Ihor Radchenko writes:
>
>> Similar to the existing LaTeX formatters, one may write a Python package
>> that will pretty-print Org markup as text.
>
> This sounds interesting -- are these LaTeX formatters external to Org?
> Could you provide a link/reference?
Ihor Radchenko writes:
> We might add the code into a separate proper python file. Then, we can
> use the contents of that file to retrieve the variable value.
>
> We already do the same thing for CSL style files and odt schema/style.
Thanks, I think this is a good idea, and will make the
Ihor Radchenko writes:
> Similar to the existing LaTeX formatters, one may write a Python package
> that will pretty-print Org markup as text.
This sounds interesting -- are these LaTeX formatters external to Org?
Could you provide a link/reference?
I thought it would get lost in the many thousands of other TODOs you have
on your plate.
Thank you.
But to my another surprise you have fixed the bug that was killing me
everyday 'org-insert-heading: Fix when folded text is kept right at the new
heading'.
Thank you very much.
Regards,
Sławomir
"Samuel Banya" writes:
> In my actual phone notes file, I have this for an example:
>
> ```
>
> Title: 08-15-2023
>
> Recorded music
>
> ```
>
> With this in mind, how do I facilitate the ability to routinely ingest any of
> the notes that are date based on the phone note title itself from
On 20/08/2023 13:32, Ihor Radchenko wrote:
Max Nikulin writes:
* Sec1
** SubSec1
** SubSec2
* |* Sec2
Wonderful... an no single test has failed.
Fixed the fix, on bugfix, adding a test for this.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=7b38670e6
Thank you, Ihor. It
Hey there,
So I'm in the process of figuring out how I can sync my phone notes to my local
file server with Syncthing occasionally. Basically 'phonenotes.org' from one
machine to another. That being noted, I have another file called notes.org on
my file server that basically lists completed
Jonathan Gregory writes:
> On 20 Aug 2023, Ihor Radchenko wrote:
>
>> Jonathan Gregory writes:
>>
>>> ob-doc-lilypond.html looks good, but I changed lilypond.org in:
>>>
>>> https://git.sr.ht/~bzg/worg/commit/6b9da77c8078be183971575fdc79d402bf6184c2
>>
>>> - b c d e
>>> + b4 c d e
>>
>> Is
On 20 Aug 2023, Ihor Radchenko wrote:
Jonathan Gregory writes:
ob-doc-lilypond.html looks good, but I changed lilypond.org in:
https://git.sr.ht/~bzg/worg/commit/6b9da77c8078be183971575fdc79d402bf6184c2
- b c d e
+ b4 c d e
Is there any specific reason for this change?
This is to
> > Here we can use '{}'.format(df.index.name) to show the name of index
>
> Patch has been updated to print the index name when it is non-None.
Thanks! It would be nice to also support MultiIndex names using
`result.index.names', e.g.
#+begin_src python :results table
import numpy as np
import
Ihor Radchenko writes:
> I suspect that it is something with overlay boundaries. AFAIR, some org
> subtree motion functions use `insert-before-markers', which may be
> tricky when we insert right at the beginning/end of an overlay.
It was totally unrelated bug on Org side.
Applied, onto main,
Ihor Radchenko writes:
>> ... Also, I don't usually use the mouse
>> much (actually I only use it in Gimp and the like) and the combination
>> of popup.el with hyperbole is more comfortable and keyboard-centric for
>> me.
>
> By default, context menu is bound to S-. Who cares about mouse XD
Oh I
Jakob Schöttl writes:
> * Table
> #+BEGIN: columnview :format "%a %b %c %d %e %f %g %h"
> #+END:
> ** foo
> :PROPERTIES:
> :a: a
> :b: b
> :c: c
> :d: d
> :e: e
> :f: f
> :g: g
> :h: h
> :END:
>
> The first call to org-dblock-update adds some spaces and only has one
> empty line of data in the
Am 20.08.23 um 08:56 schrieb Ihor Radchenko:
Jakob Schöttl writes:
So, org-update-dblock or org-dblock-write:columnview is adding trailing
spaces in the org file. These spaces change the behavior of subsequent
calls which will add even more spaces.
Confirmed.
Unimportant.
Got one:
*
Am 20.08.23 um 08:56 schrieb Ihor Radchenko:
Jakob Schöttl writes:
So, org-update-dblock or org-dblock-write:columnview is adding trailing
spaces in the org file. These spaces change the behavior of subsequent
calls which will add even more spaces.
Confirmed.
Unimportant.
The internal
Juan Manuel Macías writes:
>> Since Emacs 28, Emacs has built-in context menu. (terminal is also
>> supported) Moreover, major modes are encouraged to add support for
>> context menus.
>
> Thanks for the information. Do you mean context-menu-mode?
Yes.
> ... I'll keep an
> eye on it. When you
Jonathan Gregory writes:
> ob-doc-lilypond.html looks good, but I changed lilypond.org in:
>
> https://git.sr.ht/~bzg/worg/commit/6b9da77c8078be183971575fdc79d402bf6184c2
> - b c d e
> + b4 c d e
Is there any specific reason for this change?
--
Ihor Radchenko // yantar92,
Org mode
Jakob Schöttl writes:
> So, org-update-dblock or org-dblock-write:columnview is adding trailing
> spaces in the org file. These spaces change the behavior of subsequent
> calls which will add even more spaces.
Confirmed.
Unimportant.
The internal implementation details of colview demand
James Harkins writes:
> Let's say I have, at the bottom of a document:
> ...
> Somewhere else in the document, I do C-c C-x f.
> ...
>
> [fn:-]
> [fn:..] lorem ipsum...
> ```
>
> I believe it would make more sense like this:
>
> ```
> * Footnotes
>
> [fn:-]
>
> [fn:..]
Max Nikulin writes:
>> Fixed, on bugfix.
>> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=52bc95676
>
> Ihor, I have tried "main" and I confirm that at the end of file behavior
> has become better. Unfortunately newline is not added in the case of an
> intermediate headings
>
26 matches
Mail list logo
