Re: [O] BUG? WAS: Re: Painfully Slow Export
> On Jun 23, 2018, at 2:06 PM, Nicolas Goaziou wrote: > > Hello, > > "Berry, Charles" writes: > >> tl;dr: `:exports results :noweb no-export :eval never-export' needlessly >> expands <> code causing massive slowdowns on export. > > I think this is now fixed. I think so, too. Thanks, Chuck
Re: [O] Patch adding from-logo commentary ox-koma-letter.el
On Thu, Jun 21, 2018 at 4:37 AM, Nicolas Goaziou wrote: > Grant Rettke writes: >> If you like the additional documentation, then I will update it with >> this and send a new patch. > > Let's first merge the complete documentation, then apply it, if you > don't mind. Happy to, mistakenly said patch. Here is the new version. I included detail and examples. The first one I sent was, well, woefully inadequate! 0001-ox-koma-letter.el-Adds-FROM_LOGO-example.patch Description: Binary data
Re: [O] coderef does not provide file path for org-insert-link when not in original buffre
Hello, stardiviner writes: > `org-insert-link` should be smart on decide whether current buffer is the > same buffer with `org-store-link` source buffer, if yes, use [[(set the temp > buffer to unibyte)]]. If no, use: > > [[file:~/Org/elquery.org::(set%20the%20temp%20buffer%20to%20unibyte)][(set > the temp buffer to unibyte)]] > > WDYT? It sounds like a good idea. Do you want to implement it? Regards, -- Nicolas Goaziou
Re: [O] Bug: org-clock-display conflicts link display in headline [9.1.9 (release_9.1.9-65-g5e4542 @ /usr/share/emacs/26.1/lisp/org/)]
Hello, "Sheng Yang (杨圣)" writes: > I was trying the beloved clock feature of org-mode, and tried > `org-clock-display` on an org file. A total time is added to each > headline as expected, but it is not the case for headlines with a link > in it. The whole link is displayed as if `org-toggle-link-display` is > called. > > Minimum file to reproduce the problem: > > * [[https://www.google.com][google]] > :LOGBOOK: > CLOCK: [2018-06-03 Sun 22:15]--[2018-06-03 Sun 22:25] => 0:10 > :END: > > Steps to reproduce: > 1. Open an org file whose headline contains link > 2. Add some clock for this headline > 3. Call `org-clock-display` > > Expected behavior: > > Looks like: > > * google ..10 > :LOGBOOK:... > > What I get: > > * [[https://www.google.com][google]] ..10 > :LOGBOOK:... > > Note: If I call `org-clock-remove-overlay` to remove clock display, the > clock displayed is removed, and link display is restored. Fixed. Thank you. Regards, -- Nicolas Goaziou
Re: [O] Speeding up agenda custom command with org-agenda-earlier & org-agenda-later
Hello, Zongheng Yang writes: > Cool, looking forward to see the rewrite! So do I. But I'm not volunteering :) Regards, -- Nicolas Goaziou
Re: [O] Speeding up agenda custom command with org-agenda-earlier & org-agenda-later
hehe we don't know if the rewrite will occur, or when. :]
> I don't think is it planned. Feel free to implement it, if you want to.
> I consider Org agenda in dire need of rewriting, though. for better
> scalability and easier maintenance.
for me, the biggest problem in all of emacs is the speed of 1-day and
2-day org agenda. [i never need 30 days, or if i do, i'm willing to
have that take quite a few minutes just so that the 1-day and 2-day
speeds are maximized.] i've done all of bastien's recommended speed
hacks and a couple more like turning off diary [which doesn't do much
but still].
regular text search is ok. it's only the one that has to parse
timestamps that is slow. profiling reveals nothing obvious so i
imagine it has been optimized thoroughly.
so for me, scalability means only scaling to more files [threading
useful here?] and larger files, and only for the daily agenda "a".
but i imagine a rewrite would maybe start from scratch.
On 6/22/18, Zongheng Yang wrote:
> Cool, looking forward to see the rewrite!
>
> On Fri, Jun 22, 2018 at 1:49 PM Nicolas Goaziou
> wrote:
>
>> Hello,
>>
>> Zongheng Yang writes:
>>
>> > Here's an agenda custom command that acts as the main interface I
>> interact
>> > with org (in fact, emacs :)).
>> >
>> > (setq org-agenda-custom-commands
>> > '(("c" "Simple agenda view"
>> >((agenda "")
>> > (tags "PRIORITY=\"A\""
>> > ((org-agenda-files '("~/org/work.org"
>> > "~/org/ideas.org
>> "))
>> >(org-agenda-skip-function '(org-agenda-skip-entry-if
>> > 'todo 'done))
>> >(org-agenda-overriding-header "High-priority
>> > tasks:")
>> >))
>> > (tags-todo "PRIORITY=\"C\""
>> >((org-agenda-files '("~/org/work.org" "~/org/
>> > ideas.org"))
>> > (org-agenda-overriding-header "Long-term:")))
>> > (alltodo ""
>> > ((org-agenda-skip-function
>> >'(or (zongheng-org-skip-subtree-if-priority ?A)
>> > (zongheng-org-skip-subtree-if-priority ?C)
>> > (org-agenda-skip-if nil '(scheduled
>> deadline
>> > (org-agenda-overriding-header "Other tasks:")))
>> >
>> >
>> > After I get into this view, I frequently issue many
>> > "org-agenda-earlier"
>> &
>> > "org-agenda-later" commands, often in a back-and-forth fashion, to
>> inspect
>> > what I've done around certain periods.
>> >
>> > In such a use case, it seems there's *no reason to not cache results*.
>> > Without such caching currently *the latency of switching is really
>> > high*;
>> > with such a caching, I'm happy to pay an one-time latency/CPU cost for
>> the
>> > first command, as long as successive commands can be sped up.
>> >
>> > Is a feature like this planned?
>>
>> I don't think is it planned. Feel free to implement it, if you want to.
>>
>> I consider Org agenda in dire need of rewriting, though. for better
>> scalability and easier maintenance.
>>
>> Regards,
>>
>> --
>> Nicolas Goaziou
>>
>
--
The Kafka Pandemic:
The disease DOES progress. MANY people have died from it. And ANYBODY
can get it at any time.
"You’ve really gotta quit this and get moving, because this is murder
by neglect." ---
.
Re: [O] [bug] ox-koma-letter.el: Double translation of the signature to LaTeX
Hello, Tobias Zawada writes: > org-export-data for the signature causes double LaTeX translation at > https://emacs.stackexchange.com/questions/42200/prevent-org-export-from-expanding-as-backslash/42207?noredirect=1#comment66334_42207. > > The translator for the headlines org-koma-letter-headline is used to > extract the :closing: headline and to put its stuff into > org-koma-letter-special-contents. org-koma-letter--get-tagged-contents > retrieves the closing from there. I have the impression that > org-koma-letter-headline already gets the translated headline contents > and translating it again with org-export-data is a bad idea. Correct. > (org-trim > - (org-export-data > - (org-koma-letter--get-tagged-contents 'closing) > - info) > + (org-koma-letter--get-tagged-contents 'closing) > + info This will fail if `org-koma-letter--get-tagged-contents' returns a nil value. I applied a slightly different patch. Thank you for the analysis and the patch. Regards, -- Nicolas Goaziou
Re: [O] BUG? WAS: Re: Painfully Slow Export
Hello, "Berry, Charles" writes: > tl;dr: `:exports results :noweb no-export :eval never-export' needlessly > expands <> code causing massive slowdowns on export. I think this is now fixed. Thank you. Regards, -- Nicolas Goaziou
[O] [bug] ox-koma-letter.el: Double translation of the signature to LaTeX
Hello, org-export-data for the signature causes double LaTeX translation at https://emacs.stackexchange.com/questions/42200/prevent-org-export-from-expanding-as-backslash/42207?noredirect=1#comment66334_42207. The translator for the headlines org-koma-letter-headline is used to extract the :closing: headline and to put its stuff into org-koma-letter-special-contents. org-koma-letter--get-tagged-contents retrieves the closing from there. I have the impression that org-koma-letter-headline already gets the translated headline contents and translating it again with org-export-data is a bad idea. Regards, Tobias The following changes since commit 96b9166cf47e33a0e0292eee0eb8f42190c9c9fd: Add header argument :save-windows. (2018-06-20 00:21:09 +0200) are available in the Git repository at: https://code.orgmode.org/TobiasZawada/org-mode.git HEAD for you to fetch changes up to 69ee47c34bb0c857b2db2433b38c2ba980ea3905: Avoid double data export on :closing: header content (2018-06-23 22:13:00 +0200) Tobias Zawada (1): Avoid double data export on :closing: header content contrib/lisp/ox-koma-letter.el | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el index fc6599fe7..8d9b5ef6b 100644 --- a/contrib/lisp/ox-koma-letter.el +++ b/contrib/lisp/ox-koma-letter.el @@ -820,9 +820,8 @@ a communication channel." (and (plist-get info :with-headline-opening) (org-string-nw-p (org-trim - (org-export-data - (org-koma-letter--get-tagged-contents 'closing) - info) + (org-koma-letter--get-tagged-contents 'closing) + info (signature (org-string-nw-p (plist-get info :signature))) (signature-scope (funcall check-scope 'signature))) (and (or (and signature signature-scope)
Re: [O] Bug: org-babel-tangle sometimes does not respect header-args property [9.1.9 (release_9.1.9-65-g5e4542 @ /usr/share/emacs/26.1/lisp/org/)]
Hello, Gennady Uraltsev writes: > Running =(org-babel-tangle)= from inside a =src= block ignores > =header-args= properties > Consider the following org-mode file set for tangling. > > This code should run the command =org-babel-tangle= > > #+BEGIN_SRC emacs-lisp :results silent > (org-babel-tangle) > #+END_SRC > > that should tangle the stuff in the next header. > > ** Observed behaviour > Running the first code block tangles only the first code block below > Running =org-babel-tangle= tangles both code blocks below > > > ** Expected behaviour > Running the above code block or =org-babel-tangle= tangles both code > blocks below > > > * Code to tangle > ** Because of =:tangle= parameter > This block gets tangled both by executing =org-babel-tangle= from the > =src= code block or directly via M-x. > > #+BEGIN_SRC emacs-lisp :tangle yes > (message "This should be tangled because of :tangle parameter") > #+END_SRC > > > > > ** Because of properties > :PROPERTIES: > :header-args: :tangle yes > :END: > > This block gets tangled only by executing =org-babel-tangle= directly > via M-x but it *doesn't* get tangled by executing =org-babel-tangle= > from the =src= code block. > > #+BEGIN_SRC emacs-lisp > (message "This should be tangled because of property list") > #+END_SRC FWIW, I cannot reproduce your issue, i.e., both blocks are tangled. Regards, -- Nicolas Goaziou
Re: [O] Bug: org-babel-tangle sometimes does not respect header-args property [9.1.9 (release_9.1.9-65-g5e4542 @ /usr/share/emacs/26.1/lisp/org/)]
I did some additional testing, and found some interesting results that
appear to
point to the =org-babel-get-src-block-info= function as the culprit.
Depending on
whether this function is evaluated directly, or executed in source blocks in
different locations through this file, the function returns different
results.
Running this block does indeed result in an incorrectly tangled file.
However,
jumping down to the nearly identical block named =correct-tangle= at the
end of
the file and running it generates a correctly tangled file.
#+BEGIN_SRC emacs-lisp :results silent
(org-babel-tangle)
#+END_SRC
Digging into the function, the problem seems to stem from the value
returned by
=org-babel-get-src-block-info=. Running the following block, we see that the
=:tangle= property is ="no"= for the blocks that should be tangled due to
the header
property list.
Note the correct value of ="yes"= for the =correct-block-info= source block
towards
the end of the file.
#+BEGIN_SRC emacs-lisp :results pp
(let (blocks)
(org-babel-map-src-blocks (buffer-file-name)
(push (org-babel-get-src-block-info 'light)
blocks))
blocks)
#+END_SRC
#+RESULTS:
#+begin_example
(("emacs-lisp" "(org-babel-tangle)"
((:results . "silent")
(:exports . "code")
(:lexical . "no")
(:tangle . "no")
(:hlines . "no")
(:noweb . "no")
(:cache . "no")
(:session . "none"))
"" nil 5378 "(ref:%s)")
("emacs-lisp" "(let (blocks)\n (org-babel-map-src-blocks
(buffer-file-name)\n(push (org-babel-get-src-block-info 'light)\n
blocks))\n blocks) "
((:results . "pp replace")
(:exports . "code")
(:lexical . "no")
(:tangle . "no")
(:hlines . "no")
(:noweb . "no")
(:cache . "no")
(:session . "none"))
"" nil 3102 "(ref:%s)")
("emacs-lisp" "(message \"This should be tangled because of property
list\")"
((:results . "replace")
(:exports . "code")
(:lexical . "no")
(:tangle . "no")
(:hlines . "no")
(:noweb . "no")
(:cache . "no")
(:session . "none"))
"" nil 2850 "(ref:%s)")
("emacs-lisp" "(message \"This should be tangled because of :tangle
parameter\")"
((:results . "replace")
(:exports . "code")
(:tangle . "yes")
(:lexical . "no")
(:hlines . "no")
(:noweb . "no")
(:cache . "no")
(:session . "none"))
"" nil 2649 "(ref:%s)")
("emacs-lisp" "(let (blocks)\n (org-babel-map-src-blocks
(buffer-file-name)\n(push (org-babel-get-src-block-info 'light)\n
blocks))\n blocks) "
((:results . "pp replace")
(:exports . "code")
(:lexical . "no")
(:tangle . "no")
(:hlines . "no")
(:noweb . "no")
(:cache . "no")
(:session . "none"))
"" nil 975 "(ref:%s)")
("emacs-lisp" "(org-babel-tangle)"
((:results . "silent")
(:exports . "code")
(:lexical . "no")
(:tangle . "no")
(:hlines . "no")
(:noweb . "no")
(:cache . "no")
(:session . "none"))
"" nil 563 "(ref:%s)"))
#+end_example
* Code to tangle
** Because of =:tangle= parameter
#+BEGIN_SRC emacs-lisp :tangle yes
(message "This should be tangled because of :tangle parameter")
#+END_SRC
** Because of properties
:PROPERTIES:
:header-args: :tangle yes
:END:
#+BEGIN_SRC emacs-lisp
(message "This should be tangled because of property list")
#+END_SRC
The following block, when executed, results in the correct values for
each
source blocks =:tangle= property.
#+name correct-block-info
#+BEGIN_SRC emacs-lisp :results pp
(let (blocks)
(org-babel-map-src-blocks (buffer-file-name)
(push (org-babel-get-src-block-info 'light)
blocks))
blocks)
#+END_SRC
#+RESULTS:
#+begin_example
(("emacs-lisp" "(org-babel-tangle)"
((:results . "silent")
(:exports . "code")
(:tangle . "yes")
(:lexical . "no")
(:hlines . "no")
(:noweb . "no")
(:cache . "no")
(:session . "none"))
"" nil 3281 "(ref:%s)")
("emacs-lisp" "(let (blocks)\n (org-babel-map-src-blocks
(buffer-file-name)\n(push (org-babel-get-src-block-info 'light)\n
blocks))\n blocks) "
((:results . "pp replace")
(:exports . "code")
(:tangle . "yes")
(:lexical . "no")
(:hlines . "no")
(:noweb . "no")
(:cache . "no")
(:session . "none"))
"" nil 2987 "(ref:%s)")
("emacs-lisp" "(message \"This should be tangled because of property
list\")"
((:results . "replace")
(:exports . "code")
(:tangle . "yes")
(:lexical . "no")
(:hlines . "no")
(:noweb . "no")
(:cache . "no")
(:session . "none"))
"" nil 2850 "(ref:%s)")
("emacs-lisp" "(message \"This should be tangled because of :tangle
parameter\")"
((:results . "replace")
(:exports . "code")
(:tangle . "yes")
(:lexical . "no")
(:hlines . "no")
(:noweb . "no")
(:cache . "no")
(:session . "none"))
"" nil 2649 "(ref:%s)")
("emacs-lisp" "(let
[O] Bug: org-babel-tangle sometimes does not respect header-args property [9.1.9 (release_9.1.9-65-g5e4542 @ /usr/share/emacs/26.1/lisp/org/)]
Running =(org-babel-tangle)= from inside a =src= block ignores
=header-args= properties
Consider the following org-mode file set for tangling.
This code should run the command =org-babel-tangle=
#+BEGIN_SRC emacs-lisp :results silent
(org-babel-tangle)
#+END_SRC
that should tangle the stuff in the next header.
** Observed behaviour
Running the first code block tangles only the first code block below
Running =org-babel-tangle= tangles both code blocks below
** Expected behaviour
Running the above code block or =org-babel-tangle= tangles both code
blocks below
* Code to tangle
** Because of =:tangle= parameter
This block gets tangled both by executing =org-babel-tangle= from the
=src= code block or directly via M-x.
#+BEGIN_SRC emacs-lisp :tangle yes
(message "This should be tangled because of :tangle parameter")
#+END_SRC
** Because of properties
:PROPERTIES:
:header-args: :tangle yes
:END:
This block gets tangled only by executing =org-babel-tangle= directly
via M-x but it *doesn't* get tangled by executing =org-babel-tangle=
from the =src= code block.
#+BEGIN_SRC emacs-lisp
(message "This should be tangled because of property list")
#+END_SRC
--
Emacs : GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
of 2018-05-29
Package: Org mode version 9.1.9 (release_9.1.9-65-g5e4542 @
/usr/share/emacs/26.1/lisp/org/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-after-todo-state-change-hook '(org-clock-out-if-current)
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-mode-hook '(#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-show-block-all append
local]
5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-babel-show-result-all
append local]
5]
org-babel-result-hide-spec org-babel-hide-all-hashes)
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3
"\n\n(fn ENTRY)"]
org-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-occur-hook '(org-first-headline-recenter)
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("id" :follow org-id-open)
("rmail" :follow org-rmail-open :store
org-rmail-store-link)
("mhe" :follow org-mhe-open :store org-mhe-store-link)
("irc" :follow org-irc-visit :store org-irc-store-link)
("info" :follow org-info-open :export org-info-export
:store org-info-store-link)
("gnus" :follow org-gnus-open :store
org-gnus-store-link)
("docview" :follow org-docview-open :export
org-docview-export :store org-docview-store-link)
("bibtex" :follow org-bibtex-open :store
org-bibtex-store-link)
("bbdb" :follow org-bbdb-open :export org-bbdb-export
:complete org-bbdb-complete-link :store
org-bbdb-store-link)
("w3m" :store org-w3m-store-link) ("file+sys")
("file+emacs") ("doi" :follow org--open-doi-link)
("elisp" :follow org--open-elisp-link)
("file" :complete org-file-complete-link)
("ftp" :follow
(lambda (path) (browse-url (concat "ftp:" path
("help" :follow org--open-help-link)
("http" :follow
(lambda (path) (browse-url (concat "http:" path
("https" :follow
(lambda (path) (browse-url (concat "https:" path
("mailto" :follow
(lambda (path) (browse-url (concat "mailto:; path
("news" :follow
(lambda (path) (browse-url (concat "news:; path
("shell" :follow org--open-shell-link))
)
Re: [O] Org Mode Documentation Patch
"Siraphob (Ben) Phipathananunth" writes: > I just sent an email to ass...@gnu.org with my information, Great! > how will I know when copyright assign is completed? They will let you know. Then, you may let me know. :)
Re: [O] Babel: Why does noweb work differently depending on 'call depth'?
Hello, "jhe...@t-online.de" writes: > Hi list, > > have spent hours with trying to de-mystify this issue, but no chance to get > it. > Any hints or doc references are welcome. > > > Given a src block with a simple if clause depending on parameter p1: > > #+NAME: decider > #+BEGIN_SRC emacs-lisp :var p1="tbd" :results output > > (cond ((equal p1 "valA")(print "VALUE A")) > ((equal p1 "valB")(print "B VALUE")) > (t (print (concat "ERROR: p1=>|" p1 "|< not handled" ))) ) > #+END_SRC > > > Why does the following noweb call result in the t condition (and not in valB > as expected) > although the p1 value seems to be received by the decider block: > > #+BEGIN_SRC shell :var x="valB" :noweb yes :results output raw > echo -n <> > #+END_SRC > > == ERROR: p1=>|valB|< not handled > > > while hard coded param value will work (valA chosen to differentiate from x): > > #+BEGIN_SRC shell :var x="valB" :noweb yes :results output raw > echo -n <> > #+END_SRC > > #+RESULTS: > VALUE A > > Hard coded "valB" will work as well. Noweb expansion is done before references in the current source block are resolved. You are sending p1="$x" instead of p1="valB". Regards, -- Nicolas Goaziou
Re: [O] Org Mode Documentation Patch
Thank you very much for accepting the patch. Nicolas Goaziou wrote: > BTW, what is your status wrt FSF papers? I just sent an email to ass...@gnu.org with my information, how will I know when copyright assign is completed? Thank you again, -- Siraphob (Ben) Phipathananunth
[O] Babel: Why does noweb work differently depending on 'call depth'?
Hi list, have spent hours with trying to de-mystify this issue, but no chance to get it. Any hints or doc references are welcome. Given a src block with a simple if clause depending on parameter p1: #+NAME: decider #+BEGIN_SRC emacs-lisp :var p1="tbd" :results output (cond ((equal p1 "valA")(print "VALUE A")) ((equal p1 "valB")(print "B VALUE")) (t (print (concat "ERROR: p1=>|" p1 "|< not handled" ))) ) #+END_SRC Why does the following noweb call result in the t condition (and not in valB as expected) although the p1 value seems to be received by the decider block: #+BEGIN_SRC shell :var x="valB" :noweb yes :results output raw echo -n <> #+END_SRC == ERROR: p1=>|valB|< not handled while hard coded param value will work (valA chosen to differentiate from x): #+BEGIN_SRC shell :var x="valB" :noweb yes :results output raw echo -n <> #+END_SRC #+RESULTS: VALUE A Hard coded "valB" will work as well. Different Linux Emacsen with org-mode 9+ show same results. Thank you very much in advance, Jherek
Re: [O] Org Mode Documentation Patch
Hello, "Siraphob (Ben) Phipathananunth" writes: > I've begun reading the Org Mode manual, and noticed that the wording > in some places could be improved (so far I've read up to Section 4.8). > I've attached my patch. Some of the more drastic changes: > > - Changed all occurrences of "the cursor" to "point", I thought the > inconsistency was confusing, especially since the Emacs manual > maintains usage of "point" throughout, so too should the Org Mode > manual. Thank you. I applied your patch. I'm not totally convinced by the change from "function" to "Lisp function", since, in the context of Org, an Elisp library, there is no ambiguity. But I have no strong opinion, so I didn't remove the occurrences in your patch. BTW, what is your status wrt FSF papers? > Section 4.6 "Link abbreviations" in the Org Mode manual link to > websites that have and/or promote non-free software. The URLs are > used to illustrate link abbreviations in Org Mode, but I suppose this > was purely coincidental because long URLs to websites such as > gnu.org/some/long/path could be used instead. Would it be appropriate > to change the examples in a later patch? Sure. However, for the sake of clarity, it would be better if not all examples are similar, i.e., no "gnu.org/some/long/path" everywhere. > When the PDF version of the Org Mode manual is generated with "make > docs", the footnotes (3 and 4) around Section 4.3 are incorrectly > indented, can anyone reproduce this? I don't see anything like that in the PDF. You may want to try deleting it and re-generate it. > Should I submit my patches as smaller ones as I read sections of the > manual or bulk them together into a larger patch, or is it just a > matter of preference? As you wish. > Please let me know if you have any comments about the patch. It's my > first one, I hope I have followed the CONTRIBUTING guide properly. I fixed a couple of missing capitalization (point at the beginning of a sentence) and filled modified paragraphs. I also slightly modified your commit message. Regards, -- Nicolas Goaziou
