oo]
[(cite): -@doe; @foo]
> Depending on CSL's future development there might well be other
> citations modes. I personally think there's much to learn from
> biblatex, but that's a different debate...
As a related node, from Biblatex, we may also need, e.g., [(Cite):...],
but this was rejected for some reason a long time ago.
Regards,
--
Nicolas Goaziou
nd of first line
> 2. press M-return , that is (org-meta-return)
> 3. return to step 1
>
> You will notice that item numbers will first start to behave weirdly,
> then eventually an error will be thrown.
Indeed. This should now be fixed. Thank you.
Regards,
--
Nicolas Goaziou
ow I remember [@key] is not a shorthand for
[cite:@key]; the former is meant as "author in text" style.
Regards,
--
Nicolas Goaziou
LaTeX
- [ ] ODT
- [ ] Texinfo
4. Anything else?
We need help, or at least opinion, from actual implementors to go
further. I'm CC'ing some of them.
I can take care of the implementation (with some time, my plate is full
at the moment), but I'm mostly incompetent about design issues.
So, what about ticking off some items?
Regards,
--
Nicolas Goaziou
he way
forward, after all. But then? What library is going to use it?
Org Ref is well established and is unlikely to switch to the new syntax.
It would be nice if both syntax could converge at some point, though.
The point of the new syntax is to make it easier for this kind of
extension.
"citeproc-el" is not included in Emacs, so integrating "citeproc-org" in
Org may not be helpful at this point. Since Org is bundled with Emacs,
it cannot use external libraries.
WDYT?
Regards,
--
Nicolas Goaziou
Unfortunately, no one volunteered to fix the issue so far. You may want
to have a look at it, you will certainly get help doing so. Otherwise,
you are welcome to bump the report from time to time.
Regards,
--
Nicolas Goaziou
Heiko Schmidt writes:
> This is exactly the reason why I'd love to have negative values for
> the durations. It would open the possibility of doing something like
> "accounting" of time.
I think you can do accounting of time without introducing negative
duration. Basic accounting implies having
argument from
`org-timestamp-change' (i.e., obey to
`org-time-stamp-rounding-minutes'), but eventually decided to ignore it
for now. We can always reconsider this later on.
Thank you.
Regards,
--
Nicolas Goaziou
, which is
a valid use-case. I fixed it in both maint and master. Thanks to you
two for the report and the debugging help.
Regards,
--
Nicolas Goaziou
is also on newer
> versions.
Effort property accepts a specific, and well defined type of value:
a duration. Such values cannot be negative, as explained in the error
message.
You may, however, use a different property for your use-case, and apply
column view on it.
Regards,
--
Nicolas Goaziou
nging
> `org-element-affiliated-keywords'.
>
> Is this an oversight or am I trying to use this is a way that is
> not intended?
Syntax is not meant to be changed by users. Also,
`org-element-affiliated-keywords' is a defconst.
You might abuse #+header: affiliated keyword to add a reference.
Regards,
--
Nicolas Goaziou
s logical to "repeat, starting from now as the
base date". The attached patch does that.
WDYT?
--
Nicolas Goaziou
>From 19ee311eb35bc4cde08e61bc485a679df2d584dd Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou
Date: Sun, 5 Apr 2020 15:47:45 +0200
Subject: [PATCH] Handle ".+&qu
(org-element-map ast 'headline
(lambda (h)
(when (equal (org-export-get-node-property :A h) "foo")
(org-element-put-property h :title "FOO!")))
info)
ast)))
HTH,
--
Nicolas Goaziou
e of
insertion. It would make sense to have it in `org-table-insert-column',
too. I still think the default should be changed, tho.
Regards,
--
Nicolas Goaziou
Eric S Fraga writes:
> And I believe that a reasonable expectation is symmetry with inserting a
> row. The way I think of it is the arrow indicates to make space by
> moving columns/rows in that direction. Most spreadsheets work in this
> way, in my experience (but I could be wrong).
I
ear the beginning of the first cell.
Does that make sense?
Regards,
--
Nicolas Goaziou
ls'
Regards,
--
Nicolas Goaziou
large, or when it
is located away from the start of a section, typing in the table may
feel sluggish.
Therefore, I wonder if Org should include it unless it is optimized in
most situations.
As a side note, the table doesn't realign when you add a space in
a cell.
Regards,
--
Nicolas Goaziou
Hello,
stardiviner writes:
> Hi, Nicolas, I found the link part is fixed, Another itch is that the link
> description part still contains the statistic cookie [1/2]. For example:
>
> #+begin_src org
> * headline statistics [/]
>
> [[*headline statistics][headline statisti
ymore. Is there a right way to do
> this? (without using delimiters.)
It was not a bad idea. It is not perfect, but it is still better than
what we had, because it is unambiguous.
You can still use <...> delimiters, or, as you noted, [[...]].
I understand it breaks your workflow, but there is no loss of feature,
and no hole either: you can still link to URL with spaces in it.
Regards,
--
Nicolas Goaziou
g m-x fill-paragraph, it fills the planning line also.
>
> perhaps somebody might know what i am doing wrong or if this is a bug.
You are using the wrong function. It should be `org-fill-paragraph'.
`fill-paragraph' knows nothing about Org syntax. Hence the result you
are observing.
Regards,
--
Nicolas Goaziou
Hello,
Augustin Fabre writes:
> Subject: [PATCH] ox-html.el: Use HTTPS for link to W3 HTML validator
>
> * lisp/ox-html.el (org-html-validation-link): Use HTTPS link to W3
> HTML validator.
Applied. Thank you!
Regards,
--
Nicolas Goaziou
Nicolas Goaziou writes:
> This assumes statistics cookie is always located at the end of the
> title, before the tags. This is not required by the syntax.
>
> Syntax can evolve, but it could introduce many backward
> incompatibilities, so it must be discussed first.
Also, note
it could introduce many backward
incompatibilities, so it must be discussed first.
Regards,
--
Nicolas Goaziou
ended change was `org-link-bracket-re', which is
documented in ORG-NEWS.
Regards,
--
Nicolas Goaziou
supposed to do instead.
I'm not sure about what "bunch of regexps" you are talking about.
Regards,
--
Nicolas Goaziou
(org-skip-whitespace)
(looking-at org-ts-regexp-both)))
The (small) issue here is that we cannot properly deprecate a variable
that is not replaced with something else (i.e., we're not using
`define-obsolete-variable-alias' here).
Regards,
--
Nicolas Goaziou
Hello,
"Dauer, Michael" writes:
> worked at least with 9.1.x, but not anymore
>
> * test
> dfgfas
> {{{author}}}
> dasfas
Fixed. Thank you.
Regards,
--
Nicolas Goaziou
ng I'm doing wrong or is this a limitation of org
> 9.2.3?
It is a limitation of Org. Raw results cannot be replaced because Org
cannot know what is the result. You may wrap the output within a drawer.
Regards,
--
Nicolas Goaziou
e \[Gmail\]/
Regards,
--
Nicolas Goaziou
>
> #+BEGIN_SRC elisp :noweb-ref AA
> (ignore)
> #+END_SRC
>
> #+BEGIN_SRC elisp :noweb yes
> <>
> #+END_SRC
>
> the second block is expanded as "(IGNORE)". That probably is a bug.
> FIXEDCASE should be t.
Indeed! Fixed. Thank you.
Regards,
--
Nicolas Goaziou
k just headline text is good. WDYT?
Fixed. Thank you.
Regards,
--
Nicolas Goaziou
Hello,
Tim Visher writes:
> Is there a way to get nested quotes blocks to work?
No, you cannot nest quote blocks.
Regards,
--
Nicolas Goaziou
nymore, I removed it: it is not necessary.
> I'll apply the patch then, unless already taken care of by you or
> Bastien! :)
Applied. Thank you.
Regards,
--
Nicolas Goaziou
ps. Fixed. Thank you!
The link handler is "file", using `org-link-open-as-file' to follow it.
Regards,
--
Nicolas Goaziou
k-set-parameters.
>
> Patch attached if you agree to this.
Of course! This is what I suggested, like, 6 weeks ago (although, at
this time, I was thinking about having the substitution in "ox.el").
Regards,
--
Nicolas Goaziou
"" raw))
> (set-text-properties 0 (length new) nil new)
Why do you remove all text properties? Also, see `org-no-properties'.
Regards,
--
Nicolas Goaziou
ternal to the document.
> Does anyone know why Org is parsing files in random folders when
> I have a bad ID and a <>?
I don't. You may want to check `org-id-files', or walk the hash table
`org-id-locations'.
Regards,
--
Nicolas Goaziou
extension.
> Do you want to do this for 9.4 or can it be done later on?
This can be done later on. I don't have time to work on this. Of course,
if someone wants to do it, that would be great, too.
Regards,
--
Nicolas Goaziou
he box, why
would we provide two of them? I think we should focus on this topic,
rather than personal preferences.
Regards,
--
Nicolas Goaziou
on agenda, otherwise a
> warning message should appear on emacs startup.
>
> Which is the right way of checking org-bbdb-anniversaries is loading my
> entries?
Something like
(let ((date '(2 29 2020))) (org-bbdb-anniversaries))
should do.
Regards,
--
Nicolas Goaziou
Following up,
Nicolas Goaziou writes:
> This is the first part of the suggested changes. These do not touch
> attachment modifications, but rather improve the tooling in "ol.el".
This second patch removes most of the "attachment" leakage in the code
base (mainly &qu
egards,
--
Nicolas Goaziou
t;ol-w3m" could be an external module.
A real issue, however, lies within "ob-*". Many of them require
libraries external to Emacs. There's a running bug report about it,
IIRC. We may not ship them with Emacs.
But, again, this is another topic.
Regards,
--
Nicolas Goaziou
;. It relates to: should Org provide multiple
snippet extensions, knowing this is not a central feature, and Org is
often seen as bloated by Emacs devs? I don't think so, no matter how
useful this feature can be for some users.
Regards,
--
Nicolas Goaziou
(for example, because it would mean
> adding warnings practically everywhere).
I think this is unrealistic. If you need to save match data, execute
non-trivial code, and use the saved match data, I suggest to use
`save-match-data'.
Regards,
--
Nicolas Goaziou
n stick to a single solution, e.g., the
`condition-case' workaround. Therefore we do not need to introduce a new
keyword. However, all "ol-" libraries need to be updated.
I'll do that instead.
Regards,
--
Nicolas Goaziou
> be skipped for description or title?
That non-exportable part is confusing. I think
(org-element-interpret-data auth)
is sufficient. I pushed a change in that direction.
Regards,
--
Nicolas Goaziou
Hello,
Bastien writes:
> FWIW, I'm for delaying the removal for 9.5, not 9.4.
Sure, I added it back.
Regards,
--
Nicolas Goaziou
inter already does this).
I didn't write the required ORG-NEWS entry because we are not settled on
the final design. I agree all the changes discussed here have to be
mentioned in that file.
Regards,
--
Nicolas Goaziou
Hello,
Bastien writes:
>>> Now, I'm not sure who wants to try implementing Nicolas suggestion to
>>> let ox.el expand attachments into file links: since you both know the
>>> issue better than I do, I suggest one of you can try?
>>
>> I will try
ly interprets. I don't know how, and where, it could fit,
tho.
Regards,
--
Nicolas Goaziou
porter
can prevent parsing TITLE keyword.
Regards,
--
Nicolas Goaziou
Completing myself,
Nicolas Goaziou writes:
> General export rules are described in ox.el (org-export-options-alist),
> then each export back-end define its own specificities (look at the
> back-end definition).
This doesn't mean the manual cannot be improved, of course. Imp
ons-alist),
then each export back-end define its own specificities (look at the
back-end definition).
Regards,
--
Nicolas Goaziou
e that I need to slightly improve the tooling in "ol.el", so
I suggest to wait for these changes, as it might make this feature
trivial.
Regards,
--
Nicolas Goaziou
Hello,
Bastien writes:
> Now, I'm not sure who wants to try implementing Nicolas suggestion to
> let ox.el expand attachments into file links: since you both know the
> issue better than I do, I suggest one of you can try?
I will try to propose a patch by tomorrow evening.
Gustav Wikström writes:
> What makes attachment links not be a core link type?
1. Org Attach is not loaded by default
2. Implementing Org syntax doesn't require to implement attachments
Attachment links are in the same category as Docview links, for example.
There is no "docview" occurrence
Gustav Wikström writes:
> Ah, you mean the reference on line 3216. No, I don't think it can be
> removed. And I honestly don't think it should be either. It's there to
> let attachment links mirror the peculiarities of file links. It's
> needed for feature compatibility. I don't see the issue
that be an omission?
Regards,
--
Nicolas Goaziou
f us does some file link refactoring.
There is an "attachement" reference left in "org-element.el" at the
moment. Can it be removed safely?
I'm Cc'ing Bastien because that particular point should be solved before
any release, IMO.
Regards,
--
Nicolas Goaziou
n references to attachment
links.
Regards,
--
Nicolas Goaziou
Hello,
Bastien writes:
> Nicolas Goaziou writes:
>
>> How would I dare to have an opinion m'lord? Only yours matters.
>
> Such sarcastic remarks hurt.
Indeed! But I eventually overcame the pain. Thank you for caring! :)
Last time we disagreed, you grossly conclude
Hello,
Bastien writes:
> Nicolas, does it look good to you?
How would I dare to have an opinion m'lord? Only yours matters.
Christoffer, unfortunately, this patch is incorrect. It doesn't account
for a zero :post-blank value. For the record, (1-
(org-element-property :end ...)) is alw
t, my result type is a link not a drawer (which are mutually
> exclusive). So, to get the same wrapping effect, I need to use the :wrap
> argument. However, the comma escape negates attr_wrap's effect with this
> code
Could you clarify what you obtain, and what is wrong with it?
Thank you!
Regards,
--
Nicolas Goaziou
file
result, which is not sufficient. See commit
26ed66b23335eb389f1f2859e409f46f66279e15
"link" format is only meant to be used with "file" output.
Regards,
--
Nicolas Goaziou
und the link
- parenthesis around the link
I think that `org-store-link' should be careful about it and prevent
these pathological cases if necessary.
In any other situation, however, I think the user is responsible for
not using these specific constructs.
WDYT?
Regards,
--
Nicolas Goaziou
into file links at export time would prevent
some headache in exporters out there. It boils down to adding a function
that transforms "attach" links into "file" links, e.g.,
`org-export--expand-attachments', and insert it in `org-export-as',
right after (org-export--remove-uninterpreted-data tree info).
Regards,
--
Nicolas Goaziou
avoid this.
Regards,
--
Nicolas Goaziou
ves most of the responsibility to
> org-attach.el. The exporters still needs to know to use the new
> function inside org-attach.el though.
Thank you. Please apply it.
Now we can try improving the situation for exporters.
Regards,
--
Nicolas Goaziou
Ihor Radchenko writes:
> Thanks for the clarification. I was not sure if it is intended.
> I was mislead about this 2 times because of docstring, though it is
> clear from the source code.
I fixed the docstring. Thank you.
>> Luckily, headlines are exactly where you do _not_ need Element
Hello,
Ihor Radchenko writes:
>> Probably the docstring needs to be adapted - Nicolas knows this area
>> better than me.
>
> Do you mean that :parent property may not always be present?
`org-element-at-point' returns only a partial parse tree. It never goes
higher than the
You could however, use the parse-tree filter to modify the parse tree
before export.
Regards,
--
Nicolas Goaziou
D writes:
> On 02.02.20 12:59, Nicolas Goaziou wrote:
>> Long story short. Don't use this function, it is not correctly
>> implemented at the moment. The correct way to check if you're in a list
>> is something like:
>>
>> (org-element-lineage (org-element
(org-element-lineage (org-element-at-point) '(plain-list) t)
Regards,
--
Nicolas Goaziou
Bastien writes:
> Future maintainers may of course interpret the recommendations of
> the FSF differently, but that's mine for now.
Of course, sir.
Bastien writes:
> My point is that distinguishing trivial vs. non-trivial parts of a
> change may be subject to interpretation. When in doubt, I recommend
> staying on the safe side of not accepting a change that is more than
> 15 lines of "maybe-significant" changes.
AFACT, there was no doubt
ull
parse-tree, because parsing a whole buffer is too slow. So, because of
these limitations, I wonder if your library can be used efficiently to
alter the buffer.
Regards,
--
Nicolas Goaziou
Hello,
Jack Kamm writes:
> Thank you for reviewing my patch. I'm attaching an updated patch in
> response to your review.
Applied. Thank you.
I also simplified the allowed symbols for the new variable a bit, and
added a docstring for the internal function.
Regards,
--
Nicolas Goaziou
Hello,
Bastien writes:
> Nicolas Goaziou writes:
>
>> TINYCHANGE is only about the number of non-trivial lines of code in
>> your patch (15 or so).
>
> I would not say "non-trivial lines" of code.
>
> The change should be less *than 15 lines o
Hello,
Dan Drake writes:
> Thank you, Nicolas, for the review of my first patch. I've updated my code
> and have the new patch attached.
Thank you!
> I didn't inline the "time to minutes to keep function"; yes, that function
> is very short, but the function name ma
(and (memq ch '(?t ?T))
> +(time-to-mins-to-keep last-valid
See above about inlining.
Would you mind adding an ORG-NEWS entry, and, if possible, writing
a test?
Regards,
--
Nicolas Goaziou
Hello,
stardiviner writes:
> I found I can add property with name input name like "kk", "hello" etc, but
> can't add property "CATEGORY". Is there some limitation on document level
> property?
I still cannot reproduce it.
Regards,
--
Nicolas Goaziou
t; This is unexpected and makes the Taskjuggler export unusable for me in
> the current form. Is there a rationale for this?
I don't know. I removed the transformation.
Thank you for the report.
Regards,
--
Nicolas Goaziou
certainly use a regular footnote containing an Asymptote source
block.
Regards,
--
Nicolas Goaziou
;|" means the cursor point.
>
> Then I press =[C-c C-x p]= again try to add document global properties
> drawer, It
> insert nothing. No modification on buffer at all. Is this a bug?
FWIW, I could not reproduce it.
Regards,
--
Nicolas Goaziou
(concat "Set `org-display-remote-inline-images'"
> + " to display remote images."))
Use continuation delimiter instead.
> + nil)
> + (`skip-silent nil)
> + (_ (message (concat "Invalid value of "
> + "`org-display-remote-inline-images'"))
Ditto.
Regards,
--
Nicolas Goaziou
file foo.pdf]{size(8cm,0); draw (unitcircle);}]
Regards,
--
Nicolas Goaziou
Gustav Wikström writes:
> Ok, noted. To my defense I was thinking more in the terms of subtyping
> then hardcoding. Because we have multiple link types which try to
> share an interface. But the interface isn't perfect for all different
> kinds of links.
Then, I suggest to improve the
hat "attachment" links are just a regular link type,
that can be opened, and exported, like "file" links. They should live in
"org-attach.el", using the provided tools to define new link types, like
almost every other link types do. If those tools are not enough to
exp
Hello,
Gustav Wikström writes:
> Ok, so change pushed...
I'm sorry, but this is going too fast. We're discussing core design here
(the parser), and I couldn't even answer your proposal. Let's at least
reach an agreement on the change to make.
Regards,
--
Nicolas Goaziou
Gustav Wikström writes:
> Hardcoding the translation of attachment-links into file-links in an
> in-between layer (ox.el - that is somewhat complicated as well) is not
> transparent and I think best to avoid. Even if an attachment link is
> /very/ similar to a file link it may be best still to
view, then I suggest to add a phase in ox.el to expand the former into
the latter, before even using export back-ends. This way, there is no
change required in the exporters, shipped in or not.
Regards,
--
Nicolas Goaziou
orted for the list, this is what it
> looks like:
> \begin{enumerate}
> \item
> \item some text \texttt{with code}
> \item some text
> \end{enumerate}
Fixed. Thank you.
Regards,
--
Nicolas Goaziou
Hello,
Duianto - writes:
> Problem:
> The first line of `ol-notmuch.el` shows the filename as: `org-notmuch.el`
> https://code.orgmode.org/bzg/org-mode/src/3a6061e787efc9793ce1b7445a1f2502f679b40e/contrib/lisp/ol-notmuch.el#L1
Fixed. Thank you.
Regards,
--
Nicolas Goaziou
o clue about the reason for this.
Regards,
--
Nicolas Goaziou
since you have signed FSF papers.
Regards,
--
Nicolas Goaziou
]
>
> [![Empty lines method, step 3 - refile][3]][3]
>
> [1]: https://i.stack.imgur.com/6cUlo.png
> [2]: https://i.stack.imgur.com/GPwg8.png
> [3]: https://i.stack.imgur.com/tzAJI.png
FWIW, I cannot reproduce it with your recipe. Maybe someone else could.
Regards,
--
Nicolas Goaziou
divisor n) test-divisor)
(else (find-divisor n (+ test-divisor 1)
(define (divides? a b) (= (remainder b a) 0))
(define (prime? n)
(= n (smallest-divisor n)))
#+end_src
Regards,
--
Nicolas Goaziou
used here and there so it may be better to add a few words in the
appropriate sections, the main one being obviously "Effort Estimates".
Anyway, patches welcome! :)
Regards,
--
Nicolas Goaziou
801 - 900 of 10107 matches
Mail list logo
