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
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
>
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.
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
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
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
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
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,
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
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
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
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
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
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
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
>>> "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
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
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
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
> 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
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
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
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
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
> 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
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
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
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
> >>>
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 \]
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.,
>
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.,
>>
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
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
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 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
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
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
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
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
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
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
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
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
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,
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
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
49 matches
Mail list logo
