JARZz writes:
> I don't know what happens behind the scenes exactly, but it takes a good
> minute or to load my agenda with all the files, and it can take 10-15 minutes
> to search through them for a specific string. This problem also happens when
> I used sshfs, which makes me believe more st
No Wayman writes:
> I can confirm the issue you've outlined on latest 'main'.
> To me it looks like the problem is in `org-inline-hide-tasks'.
> I don't use inline tasks, so I'm not sure what the exact expected
> behavior is,
> but that function uses a `while' during `org-cycle-hook' to
> itera
JARZz writes:
> Hello all,
>
> I have a case of a somewhat irregular org mode setup. Here are the givens:
>
> 1 I have many org files. One for each week of the year, including a
> couple of generic ones, IE journal.org, routines.org, wiki.org,
> etc. All in all it's about 120 files or so, all l
Nicolas Goaziou writes:
> I'm not sure. I wrote this some years ago. I guess the rationale at that
> time was that it didn't feel useful to apply a format to an empty cell.
> For example, if you use `:fmt "$%s$"', I assume you wouldn't want to get
> "$$" in otherwise empty cells.
Also makes sens
Bastien writes:
> Org 9.5 is out, available from GNU ELPA.
Exciting!
I just ran 'git pull' and got a warning and an error:
warning: redirecting to https://git.savannah.gnu.org/git/emacs/org-mode.git/
Your configuration specifies to merge with the ref 'refs/heads/maint'
from the remote, but no
Ihor Radchenko writes:
> The attached patch should fix the issue, though it may be more
> reasonable to fix orgtbl-to-generic logic.
Given Nicholas' reply, changing orgtbl-to-generic may not be a good idea
and break other code using orgtbl-to-generic.
Applied as ddee7b617 on bugfix
Best,
Ihor
I can confirm the issue you've outlined on latest 'main'.
To me it looks like the problem is in `org-inline-hide-tasks'.
I don't use inline tasks, so I'm not sure what the exact expected
behavior is,
but that function uses a `while' during `org-cycle-hook' to
iterate through all of the headings
Hi Kyle,
Kyle Meyer writes:
> Thanks for the heads up.
>
> I monitor Org-related changes to the Emacs repo and port them to Org's.
> Entering into Emacs release periods, I tend to look at least once a day
> so that porting doesn't hold up cutting a bugfix release and syncing.
> Other times, it's
Hello all,
I have a case of a somewhat irregular org mode setup. Here are the givens:
- I have many org files. One for each week of the year, including a couple of
generic ones, IE journal.org, routines.org, wiki.org, etc. All in all it's
about 120 files or so, all loaded to my org-agenda.
- I
Adam Porter writes:
> I noticed this recent commit on emacs.git making a change to
> org-element.el:
>
> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=58102466e32d4dd9c7d816cdc3f4595a2145f332
Thanks for the heads up.
I monitor Org-related changes to the Emacs repo and port them to Org's
Hi Bastien, et al,
I noticed this recent commit on emacs.git making a change to
org-element.el:
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=58102466e32d4dd9c7d816cdc3f4595a2145f332
I don't see that change in org-mode.git, and it seems like it could be
an important one, so I wanted to
I strongly oppose this patch. It adds far too much complexity to the
org grammar. Representation of numbers is an extremely nasty part of
nearly every language, and I suggest that org steer well clear of
trying to formalize this. With an eye to future portability I suggest
that no special cases be
Hello,
Ihor Radchenko writes:
> Nicolas,
>
> Is there a rationale behind bypassing :fmt and :hfmt for empty table
> cells in `org-table--to-generic-cell'? In this patch, I have to work
> around this using :raw parameter in `orgtbl-to-generic' call. I do not
> feel like such workaround should be
Timothy writes:
> I think there are also some relevant points which I haven’t mentioned so far,
> separate from my thoughts that since we’re using the LaTeX syntax we should be
> consistent with how LaTeX treats this.
I'm not convinced about this. I don't think it is even possible.
>> As I wrot
Nicolas Goaziou writes:
> Hello,
>
> Colin Baxter writes:
>
>>> Nicolas Goaziou writes:
>>
>> > Timothy writes:
>> >> Nicolas Goaziou writes:
>> >>
>> >>> I strongly disagree with this. \[...\] is an inline element, not
>> >>> a block element. As such, it can be fil
Hello,
Colin Baxter writes:
>> Nicolas Goaziou writes:
>
> > Timothy writes:
> >> Nicolas Goaziou writes:
> >>
> >>> I strongly disagree with this. \[...\] is an inline element, not
> >>> a block element. As such, it can be filled, and filling function
> >>> shoul
Hi Nicolas,
I think there are also some relevant points which I haven’t mentioned so far,
separate from my thoughts that since we’re using the LaTeX syntax we should be
consistent with how LaTeX treats this.
> As I wrote above, they do not belong to the same category of syntax.
> There’s no reaso
The attached patch addresses org-src.el's checkdoc warnings spare
the following (IMO spurious) warnings:
>158 0 notee-f-cLisp symbol ‘split-window-below’
>should appear in quotes
split-window-below is a value used in org-src-window-setup (along
with split-window-righ
Nicolas Goaziou writes:
>> Given that \[ ... \] is an alias for \begin{equation*} ...
>> \end{equation*}
>
> This is true in LaTeX, not in Org, obviously.
Isn't the whole point of the \[ ... \], \( ... \), $ ... $, $$ ... $$,
and \begin{env} ... \end{env} and constructs in Org to be consistent
> Nicolas Goaziou writes:
> Timothy writes:
>> Nicolas Goaziou writes:
>>
>>> I strongly disagree with this. \[...\] is an inline element, not
>>> a block element. As such, it can be filled, and filling function
>>> should obey to the inner structure of the document
This looks correct. Some people prefer to use named functions for this,
so it is easier to remove them, but this works fine.
Alper Alimoglu writes:
> Thank you Professor Kitchin. Would something like follows would work?
> #+BEGIN_SRC emacs-lisp :results silent
> (add-hook 'org-mode-hook (lambda
Timothy writes:
> Nicolas Goaziou writes:
>
>> I strongly disagree with this. \[...\] is an inline element, not a block
>> element. As such, it can be filled, and filling function should obey to
>> the inner structure of the document.
>>
>> You can use a real block element here, e.g.,
>> \begin{
Nicolas Goaziou writes:
> I strongly disagree with this. \[...\] is an inline element, not a block
> element. As such, it can be filled, and filling function should obey to
> the inner structure of the document.
>
> You can use a real block element here, e.g.,
> \begin{equation*}...\end{equatio
Hello,
Timothy writes:
> If a displayed equation (`\[ ... \]') starts on its own line, I don’t think it
> should be filled into the rest of the text. I.e.,
>
> ┌
> │ some nice text
> │ \[
> │ 1+1=2
> │ \]
> │ more text.
> └
> should not become,
> ┌
> │ some nice text \[ 1+1=3 \] mo
Hello,
Currently, the only way to set a file mode when tangling seems to be
:tangle-mode (identity #o755)
In a [prior thread], Jeremy proposed that :tangle-mode should convert octal
number strings to the required decimal form. I think we should go further, and
so have prepared the attached patch
Hi Jeremy,
> I love it! Much better than my proposed patch.
I’m about to send a patch based on my snippet, so I’m marking this patch as
cancelled.
All the best,
Timothy
The initial patch was just slightly off. Here's a correct version.
Timothy writes:
> As such, I have attached a patch which adds fill “cuts” around `\[' and
> `\]', when `\[' occurs at the start of a line. This leaves the display
> equation
> delimiters on their own line.
>From d6d2221a7a9bf5e
Hi All,
If a displayed equation (`\[ ... \]') starts on its own line, I don’t think it
should be filled into the rest of the text. I.e.,
┌
│ some nice text
│ \[
│ 1+1=2
│ \]
│ more text.
└
should not become,
┌
│ some nice text \[ 1+1=3 \] more text.
└
While the above example ma
> Org 9.5 is out, available from GNU ELPA.
I bow to the ground in utter and humble gratitude!
> Enjoy!
I will, that is as certain as taxes and death!
Cheers
Rasmus
We have some initial documentation for org-cite included in the manual
to accompany the release of Org 9.5.
https://orgmode.org/manual/Citation-handling.html#Citation-handling
But it still needs a fair bit of work.
Questions:
1. What else should/must be added to the manual?
2. What might we ins
Hi Max,
Max Nikulin writes:
> It seems, something is wrong with worg deployment
https://builds.sr.ht/~bzg/job/598512 hints that a link was unresolved.
I just fixed this link, the export should process fine.
Thanks for reporting this!
--
Bastien
Hi Sébastien,
Sébastien Miquel writes:
> I've rebased the patch on main. It is still relevant (Ihor and I have
> provided
> reproducers earlier in the thread).
Applied in bugfix, thanks!
--
Bastien
Hi Pankaj,
Pankaj Jangid writes:
> One Q: what is the schedule for 9.5 to be included in Emacs-28?
Org 9.5 have been merged in the Emacs master branch, from which the
Emacs release branch for 28.1 will be cut anytime soon.
Then we will work on 9.5.1 for important bugfixes and merge 9.5.1
in th
Am 30.09.2021 um 09:23 schrieb Nicolas Goaziou:
Hello,
Denis Maier writes:
Well, there are even cases like this one:
[cite:@doe especially 4, 12, and 15]
[cite:@doe e.g. 4, 12, and 15]
[cite:@doe among others 4, 12, and 15]
[cite:@doe 4, but also 12 and 15]
AFAIU, all these cases are
>>> "MN" == Max Nikulin writes:
> On 29/09/2021 11:07, Timothy wrote:
>>
>>> Any idea how to export checkboxes to odt?
>>> I mean not just simply having [ ] in the odt document but having them
>>> translated as actual boxes.
>>>
>>> Either using latex ⊠
>>> or UTF8 ☒
>> I’m wondering, would
On 26/09/2021 15:52, Bastien wrote:
stardiviner writes:
Here is the new patch which invokes notifications though Emacs
built-in API `ns-do-applescript`.
Applied in the main branch, thanks.
Notice that applied patch has a minor issue: backslashes are not escaped
before argument is passed to
On 27/09/2021 00:05, Léo Ackermann wrote:
Le 26 sept. 2021 à 19:01, Timothy a écrit :
You write:
Nevertheless, I think that this bug has been introduced recently (I never
noticed it before) and has to be corrected properly (as this is a really basic
use of
org-mode).
Unfortunately, I can barel
On 25/09/2021 23:04, Bastien wrote:
(I'm marking this as a confirmed bug, even if a first patch as been applied.)
Since it was there earlier, it is tracked twice now:
- User input is combined with format string in org-latex-src-block
- Bug: Percentage in caption does not work in LaTeX export
L
Sébastien Miquel writes:
> I had done some testing, and some more recently. The patch only affects
> latex-fragments and org entities to be edited which do not need to start
> at a
> beginning of line (latex-fragments, inline src blocks, footnote
> definitions).
Also looks fine for me.
Best,
Robert Klein writes:
> When trying to run a table with missing values with ob-gnuplot.el
> there's a “:missing value” option. ob-gnuplot is supposed to put the
> “value” into the place of empty cell values before calling on gnuplot.
> It doesn't do this currently.
Confirmed
The problem is part
Bastien writes:
> Hi André,
>
> I agree this change is a welcome improvement: thanks a lot for working
> on this patch. I would like to suggest a step by step approach:
>
> 1. Updating occurrences in the documentation: manual, guide,
>docstrings, worg occurences, etc.
>
> 2. Updating Org int
It seems, something is wrong with worg deployment
curl -I https://orgmode.org/worg/org-contrib/org-protocol.html
HTTP/1.1 404 Not Found
Server: nginx/1.14.2
Date: Thu, 30 Sep 2021 12:10:08 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 169
Connection: keep-alive
org-contrib/org-proto
Timothy writes:
> Sorry that you haven’t heard anything in a while. I’ve been hoping that
> Bastien
> or Nicolas might have been able to take a look at this and give their
> thoughts,
> but unfortunately judging from their recent activity they both seem to be
> quite
> busy as of late. I dream
Hi Bastien,
Bastien writes:
Sébastien, have you been able to test this patch heavily and is it
still needed, or has it been made somehow irrelevant? (I see it does
apply well on the bugfix branch, but not on main.)
Thanks for any feedback,
I've rebased the patch on main. It is still relevant
On Thursday, 30 Sep 2021 at 18:59, Ihor Radchenko wrote:
> However, the problem is not reproducible. Are you able to provide a
> recipe?
For the record, I see the same as the OP: alignment on the first
character of the time string, not on the :.
However, my org is not quite up to date and don't w
tumashu writes:
> Hello:
>
>
> When I update to org 9.5, I find that the align of time like "7:00" has
> been changed.
>
> I think the new style is not beautiful as old style.
>
> 1. New style look like not align to the first char, for the width of 9 looks
> like > 1
> 2. the old style is
Max Nikulin writes:
> - I am in doubts whether "emacs -Q -L ~/src/org-mode/lisp" way to try
> version from git is important enough for the manual. I have added a
> separate patch however to discuss such change.
I feel that it should not be in the manual. However, it may be helpful
addition to
Michael Dauer writes:
> I wanted to help you with testing. But I could not find a branch dev in
> that repo.
I did not mean literally "dev" branch. The default branch there is my
local patches I plan to merge to Org eventually.
> Anyway, I'll wait for it to be populated into the main repo. When
Bastien writes:
> Org 9.5 is out, available from GNU ELPA.
>
> Thanks a lot to every contributor.
>
Thanks a lot for your work, Bastien. I want to thank all the
contributors.
One Q: what is the schedule for 9.5 to be included in Emacs-28?
Regards ~Pankaj
Hello,
Denis Maier writes:
> Well, there are even cases like this one:
>
> [cite:@doe especially 4, 12, and 15]
>
> [cite:@doe e.g. 4, 12, and 15]
>
> [cite:@doe among others 4, 12, and 15]
>
> [cite:@doe 4, but also 12 and 15]
AFAIU, all these cases are already handled by the locator parsing
a
Timothy,
> If you use mu4e, the following may be of some interest:
> ┌
> │ (defun +mu4e-ml-message-link (msg)
> │ (cond
> │((string= "emacs-orgmode.gnu.org" (mu4e-message-field msg :mailing-list))
> │ (message "Link %s copied to clipboard" (gui-select-text (format
> "https://list.or
51 matches
Mail list logo
