Bug: table odt export ignores relative column width hints [9.4.6 (9.4.6-13-g4be129-elpa @ /home/hp/.emacs.d/elpa/org-20210920/)]
Let the content of a file 'test.org' be the following: | | | |--+---| | 2 | 10| Observed behavior: test.odt with identical column widths - note, that vs. seems to work |+-| |2 | 10 | Expected behavior: test.odt width ratio 1/5 |---+-| | 2 | 10 | Best Reagards Hanspeter --- Emacs : GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.27, cairo version 1.17.4) of 2021-03-26 Package: Org mode version 9.4.6 (9.4.6-13-g4be129-elpa @ /home/xx/.emacs.d/elpa/org-20210920/) Output of *Messages*: (New file) Saving file /home/xx/yy/test.org... Wrote /home/xx/yy/test.org ODT Zip Dir is /tmp/odt-WAWq3N/ LaTeX to MathML converter not available. Formatting LaTeX using verbatim ox-odt: Content template file is /home/xx/.emacs.d/elpa/ox-odt-9.3.7.339/etc/styles/OrgOdtContentTemplate.xml Using schema ~/.emacs.d/elpa/ox-odt-9.3.7.339/etc/schema/od-schema.rnc Saving file /tmp/odt-WAWq3N/content.xml... Wrote /tmp/odt-WAWq3N/content.xml ox-odt: Styles file is /home/xx/.emacs.d/elpa/ox-odt-9.3.7.339/etc/styles/OrgOdtStyles.xml Using schema ~/.emacs.d/elpa/ox-odt-9.3.7.339/etc/schema/od-schema.rnc Saving file /tmp/odt-WAWq3N/styles.xml... Wrote /tmp/odt-WAWq3N/styles.xml Using schema ~/.emacs.d/elpa/ox-odt-9.3.7.339/etc/schema/od-schema.rnc Saving file /tmp/odt-WAWq3N/meta.xml... Wrote /tmp/odt-WAWq3N/meta.xml Wrote /tmp/odt-WAWq3N/mimetype Using schema ~/.emacs.d/elpa/ox-odt-9.3.7.339/etc/schema/od-manifest-schema.rnc Saving file /tmp/odt-WAWq3N/META-INF/manifest.xml... Wrote /tmp/odt-WAWq3N/META-INF/manifest.xml Create OpenDocument file ‘test.odt’... Using schema ~/.emacs.d/elpa/ox-odt-9.3.7.339/etc/schema/od-schema.rnc Running zip -mX0 test.odt mimetype Running zip -rmTq test.odt . Created /home/xx/yy/test.odt Quit
C-c C-* causes "org-element--cache: Unregistered buffer modifications detected."
Another case of Warning (emacs): org-element--cache: Unregistered buffer modifications detected. Resetting. If this warning appears regularly, please report it to Org mode mailing list (M-x org-submit-bug-report). The buffer is: c-star.org Current command: nil Backtrace: nil Org main, Emacs-26.3 c-star.org file: >8 Ф Put cursor on this line and hit =C-c C-*= to make it a heading 8< Notice a Cyrillic letter that causes a problem with `org-ctrl-c-star'.
table and Cyrillic characters: org-element--cache: Unregistered buffer modifications detected. Resetting
On 11/11/2021 13:50, Vladimir Lomov wrote: ** Ihor Radchenko: Vladimir Lomov writes: Warning (emacs): org-element--cache: Unregistered buffer modifications detected. Resetting. Are you able to reproduce with emacs -Q? I can confirm it starting with a simple file >8 | 1 | 8< LANG=en_US.UTF-8 emacs -Q -L ~/src/org-mode/lisp/ cyrtable.org C-\ russian-computer RET to switch input method TAB to create a new cell Any letter Warning (emacs): org-element--cache: Unregistered buffer modifications detected. Resetting. If this warning appears regularly, please report it to Org mode mailing list (M-x org-submit-bug-report). The buffer is: cyrtable.org Current command: org-self-insert-command Backtrace: nil Org main, Emacs-26.3 There is no such problem if Russian keyboard layout is switched at XOrg level using xkb.
Re: table and Cyrillic characters: org-element--cache: Unregistered buffer modifications detected. Resetting
Max Nikulin writes: > On 11/11/2021 13:50, Vladimir Lomov wrote: >> ** Ihor Radchenko: >> >>> Vladimir Lomov writes: Warning (emacs): org-element--cache: Unregistered buffer modifications detected. Resetting. >> >>> Are you able to reproduce with emacs -Q? > > I can confirm it starting with a simple file > > >8 > | 1 | > 8< > > LANG=en_US.UTF-8 emacs -Q -L ~/src/org-mode/lisp/ cyrtable.org > > C-\ russian-computer RET to switch input method > TAB to create a new cell > Any letter Confirmed I can also reproduce with russian-computer and at least arabic. Seems to be an issue with non-latin input methods. The warning is triggered because return value of buffer-chars-modified-tick with non-latin input method changes _before_ text is inserted. If I add debug-on-entry for self-insert-command or org-self-insert-command, buffer-chars-modified-tick changes twice: (1) some time after pressing the keyboard key but before entering self-insert function (symbol is not inserted into buffer); (2) after actual insertion. The problem happens in non-Org buffers as well and with emacs -Q. org-element-cache relies on the return value of buffer-chars-modified-tick to control if all the changes in buffer are reflected in the cache. The docstring says: >> By comparing the values returned by two individual calls of >> buffer-chars-modified-tick, you can tell whether a character change >> occurred in that buffer in between these calls So, what we observe looks like a Emacs bug. On Org side, this bug is very bad news. We cannot wait for the Emacs fixing the bug - older Emacs versions will still be affected. Alternative ways to control buffer modifications are buffer-hash and secure-hash. In the past, I had some random failures when buffer-hash did not reliably reflect buffer updates. The only alternative is secure-hash, but I am not sure about it's performance. buffer-hash docstring says that "It should be somewhat more efficient on larger buffers than secure-hash is, and should not allocate more memory.". So, I need to test the actual performance on large buffers before switching from buffer-chars-modified-tick to secure-hash. Also, I am somehow unable to reproduce the problem in my private Org branch. Maybe there is some alternative fix without getting rid of buffer-chars-modified-tick. Vladimir, if the issue is affecting your workflows, you can disable org-element-cache until we fix the bug. Just set org-element-use-cache to nil in your config before loading Org. Best, Ihor
execute src block during export (Re: Worg HTML export problem?)
On 11/11/2021 04:24, Thomas S. Dye wrote: Max Nikulin writes: On 08/11/2021 05:46, Thomas S. Dye wrote: to fail, but AFAICT ob-doc-org.org doesn't have this affliction--it exports locally. Have you tried to export it from "emacs -Q -L /path/to/org-mode/lisp"? I think, you just have "org" in customized "org-babel-load-languages". I've likely made some other error, but I don't have clue what it might be. I don't know how to debug this. Can someone help, please? https://builds.sr.ht/~bzg/job/623225 [exporting] org-contrib/babel/languages/ob-doc-org.org No org-babel-execute function for org! However I do not see explicit load/require for particular language in sibling files. I expected something like #+begin_src emacs-lisp :exports none (require 'ob-org) #+end_src Thanks for looking into this. Is the problem something I can fix in ob-doc-org.org? Or, does it have to do with the configuration at sr.ht? All settings are in .build.yaml and publish.sh (lisp) file. Sorry, I have missed the following code in your file #+begin_src emacs-lisp (org-babel-do-load-languages 'org-babel-load-languages '((org . t))) #+end_src I am unsure whether it should work in this form or it worked earlier, but on main branch it is not executed during export. If I change first line to the following, the block is executed during export: #+begin_src emacs-lisp :results value none :exports results My minimal example: Test #+begin_src emacs-lisp :results value none :exports results (org-babel-do-load-languages 'org-babel-load-languages '((org . t))) #+end_src #+name: org-hello #+begin_src org :var hello="World" Hello, $hello! #+end_src #+begin_src elisp :var x=org-hello[](hello="Org") :exports both (print x) #+end_src
Re: C-c C-* causes "org-element--cache: Unregistered buffer modifications detected."
Max Nikulin writes: > Org main, Emacs-26.3 > > c-star.org file: > >8 > Ф Put cursor on this line and hit =C-c C-*= to make it a heading > 8< > > Notice a Cyrillic letter that causes a problem with `org-ctrl-c-star'. Confirmed However, I can only trigger the warning up to Emacs 27. Emacs 28 and later has no issue. Need to investigate further. Best, Ihor
when ellipsis are "removed", org-cycle doesn't work "correctly" on list
** when ellipsis are "removed", org-cycle doesn't work "correctly" on list Hey everyone, This is my first communication on this mailing list and I hope I'll do it well. 1) The "bug" (I'm not sure if it is a bug): When you modify the `buffer-invisibility-spec` replacing `'(outline . t)` by `'outline` (in order to remove the `...` when headlines, list, etc are collapsed) by evaluating the following form: (remove-from-invisibility-spec '(outline . t)) (add-to-invisibility-spec 'outline) `org-cycle` stopped working "correctly" on lists. You still can collapse lists but you can get them to show the list content again. For instance, with the following list (and the ellipsis removed), with the point on the first item (- something), press TAB (`org-cycle`): - something - a - b - c - something else You'll obtain the first item collapsed: - something - something else but if you hit TAB (`org-cycle`) again, you won't see the content (a, b, c), the first item will stay collapsed. note-1: I don't know if it can be considered as a "bug" because I imagine that most org-mode users won't remove the visual feedback offered by the ellipsis. note-2: This "bug" was reported as an issue on github (https://github.com/tonyaldon/org-bars/issues/5) by jonathanmfung, regarding a section on the README where I wrote how to remove the ellipsis, knowing that `org-bars` offers dynamic stars that inform the visibility of subtrees. Maybe it wasn't a good idea. 2) a fix of the "bug" I was really interested in knowing why changing the `buffer-invisibility-spec` in the way previously described has an impact on `org-cycle`. I added a small patch (that modifies `org-list-struct`) to this email that makes `org-cycle` work with `buffer-invisibility-spec` changed in order to remove ellipsis. The outline of the patch is as follow: The command `org-cycle`, when in an item list, calls `org-cycle-internal-local`. And `org-cycle-internal-local` computes the local var `eos` (end of subtree or item) via the call of the function `org-list-struct`. (defun org-cycle-internal-local () ;;... (let ((goal-column 0) eoh eol eos has-children children-skipped struct) (save-excursion (if (org-at-item-p) (progn (beginning-of-line) (setq struct (org-list-struct)) (setq eoh (point-at-eol)) (setq eos (org-list-get-item-end-before-blank (point) struct)) (setq has-children (org-list-has-child-p (point) struct))) ;; ... ) ;;... ))) And the problem comes from the use of the function `current-indentation` in `org-list-struct` that doesn't compute correctly in that context the indentation when ellipsis are removed. The patch replaces this specific call of `current-indentation`. note-3: I don't understand why the function `current-indentation` doesn't compute "correctly" the indentation in that context. note-4: In a default org buffer, with the items either collapsed or not, with the following content and point on the first item, - [X] first item 1. sub-item 1 5. [@5] sub-item 2 some other text belonging to first item - last item + tag :: description evaluating `(org-list-struct)` gives the following structure (as written in the docstring): ((1 0 \"- \" nil \"[X]\" nil 97) (18 2 \"1. \" nil nil nil 34) (34 2 \"5. \" \"5\" nil nil 55) (97 0 \"- \" nil nil nil 131) (109 2 \"+ \" nil nil \"tag\" 131)) But if you removed the ellipsis (as specified previously), and you collapse the first item, evaluating `(org-list-struct)` with point on the first item gives you: ((1 0 "- " nil "[X]" nil 18) (18 0 "1. " nil nil nil 34) (34 0 "5. " "5" nil nil 55)) 3) Thank you for all your work on org-mode, I enjoy using it every day :) Have a nice day, Tony Aldon Done with: GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30, cairo version 1.15.10) of 2021-06-09 From 06636f4b14b138a3d6ca5366af3b5744f06d9c55 Mon Sep 17 00:00:00 2001 From: tony Date: Thu, 11 Nov 2021 12:00:07 +0100 Subject: [PATCH] lisp/org-list.el: modify current indentation calculation in org-list-struct * lisp/org-list.el (org-list-struct): Don't use `current-indentation` to compute the current indentation in the loop that collects the org list informations. This change is necessary only in the case where you modify the `buffer-invisibility-spec` replacing `'(outline . t)` by `'outline` (in order to remove the `...` when headlines, list, etc are collapsed) by evaluating the following form: (remove-from-invisibility-spec '(outline . t)) (add-to-invisibility-spec 'outline) --- lisp/org-list.el | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/lisp/org-list.el b/lisp/org-list.el index b08e72eb2..025ae0086 100644 --- a/lisp/org-list.el +++ b/lisp/org-list.el @@ -684,7 +684,14 @@ Assume point is at an item." ;;position of items in END-LST-2. (catch 'exit (while t - (let ((ind (current-i
Re: Incorrect link is stored (org-elements?)
On 10/11/2021 20:48, Ihor Radchenko wrote: I pushed the patch upstream. P.S. I am puzzled that `org-element-at-point' returns paragraph even when patch is not applied. After such call `org-store-link' does what I expect. However "after undo" erroneous state survives emacs restart, thanks to org-persist, I believe. The bug was in very specific case. org-element-at-point now has a special fast mode of operation when CACHED-ONLY argument is non-nil. In this mode, it does not try to parse anything, but only checks the nearest cached element and returns it if point is at the element beginning, within +begin/end line of the element, or inside a non-greater element. The error happened when the cached element was a section and point was within blank lines at the end of the section exactly one symbol before the following headline. In such cases, org-element-at-point must follow some special rules (see comments in org-element--parse-to), but it did not in this specific scenario. On top of that, org-element-parse-to cannot return section and the current code assumes that we ever attempt to return section when point is at the beginning of section. So, it returns (org-element-at-point (1+ pos)) instead. Hence, the next headline was wrongly returned when (1) point is 1- beginning of next headline (2) we are within blank lines at the end of section (3) some edit in buffer just cleared everything in cache inside current section (4) org-element-at-point is called with non-nil CACHED-ONLY argument. Thank you for the fix and for the detailed explanation, Ihor. I was naively suspecting some weird issue with undo, maybe similar to the one found with interference of tables and non-latin input methods.
[BUG] elisp links: cluttered prompt due to text properties
Try to "open" the following link (C-c C-o)
[[elisp:(require 'org-capture)][M-: (require 'org-capture)]]
Actual behavior:
> Execute #("(require 'org-capture)" 0 22 (face org-warning)) as Elisp?
(yes or no)
Org mode version 9.5 (release_9.5-225-g494c20) - main HEAD
Expected behavior:
> Execute "(require 'org-capture)" as elisp? (yes or no)
As it was in
Org mode version 9.1.9 (release_9.1.9-65-g5e4542 @
/usr/share/emacs/26.3/lisp/org/)
Currently text properties are not cleared before displaying the source code.
[BUG] Tables with square brackets do not compile in PDF (latex) export [9.5 (release_9.5-59-g52e6f1 @ /home/sjt015/repo/emacs/lisp/org/)]
(Apologies for sending this from gmail, my mail setup was not working
with the -Q option in emacs.)
A table in which a first column begins with square brackets is not
compiling. The square bracket is interpreted by latex as an argument
to the preceding line break.
Example org table:
| Input | Output |
|+|
| [1, 2] | {3, 4} |
| [5, 6] | null |
When exported to a PDF ( C-c C-e l o), I expect that the PDF to be rendered
with the brackets in the table as shown in org.
Instead, the result is a latex compilation error. The brackets are being
interpreted as length arguments to the preceding line break.
This is a relevant Stack Exchange issue (for pure latex) which suggests
some possible solutions.
[[https://tex.stackexchange.com/questions/34466/error-with-square-bracket-in-table][Error
with square bracket in table]]
To test, emacs was started with =emacs -q= to not load an init file.
Emacs : GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.22.30, cairo version 1.15.12)
of 2021-10-27
Package: Org mode version 9.5 (release_9.5-59-g52e6f1 @
/home/sjt015/repo/emacs/lisp/org/)
current state:
==
(setq
org-link-elisp-confirm-function 'yes-or-no-p
org-bibtex-headline-format-function #[257 "\300%1\236A\207" [:title]
3 "\n\n(fn ENTRY)"]
org-export-before-parsing-hook '(org-attach-expand-links)
org-archive-hook '(org-attach-archive-delete-maybe)
org-odt-format-inlinetask-function 'org-odt-format-inlinetask-default-function
org-ascii-format-drawer-function #[771 "%1\207" [] 4 "\n\n(fn NAME
CONTENTS WIDTH)"]
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-mode-hook '(#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-show-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-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
org-latex-format-headline-function 'org-latex-format-headline-default-function
org-confirm-shell-link-function 'yes-or-no-p
org-html-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
outline-isearch-open-invisible-function 'outline-isearch-open-invisible
org-odt-format-headline-function 'org-odt-format-headline-default-function
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-confirm-elisp-link-function 'yes-or-no-p
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-html-format-inlinetask-function
'org-html-format-inlinetask-default-function
org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
org-odt-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
org-latex-format-inlinetask-function
'org-latex-format-inlinetask-default-function
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-link-shell-confirm-function 'yes-or-no-p
org-babel-pre-tangle-hook '(save-buffer)
org-agenda-loop-over-headlines-in-active-region nil
org-occur-hook '(org-first-headline-recenter)
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link)
("id" :follow org-id-open)
("eww" :follow org-eww-open :store org-eww-store-link)
("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
:export org-irc-export)
("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)
("doi" :follow org-link-doi-open :export
org-link-doi-export)
("file+sys") ("file+emacs")
("shell" :follow org-link--open-shell)
("news" :follow
#[514 "\301\300\302%4Q%2\"\207"
["news" browse-url ":"] 6 "\n\n(fn URL ARG)"]
)
("mailto" :follow
#[514 "\301\300\302%4Q%2\"
Re: execute src block during export (Re: Worg HTML export problem?)
Aloha Max, Max Nikulin writes: On 11/11/2021 04:24, Thomas S. Dye wrote: Max Nikulin writes: On 08/11/2021 05:46, Thomas S. Dye wrote: to fail, but AFAICT ob-doc-org.org doesn't have this affliction--it exports locally. Have you tried to export it from "emacs -Q -L /path/to/org-mode/lisp"? I think, you just have "org" in customized "org-babel-load-languages". I've likely made some other error, but I don't have clue what it might be. I don't know how to debug this. Can someone help, please? https://builds.sr.ht/~bzg/job/623225 [exporting] org-contrib/babel/languages/ob-doc-org.org No org-babel-execute function for org! However I do not see explicit load/require for particular language in sibling files. I expected something like #+begin_src emacs-lisp :exports none (require 'ob-org) #+end_src Thanks for looking into this. Is the problem something I can fix in ob-doc-org.org? Or, does it have to do with the configuration at sr.ht? All settings are in .build.yaml and publish.sh (lisp) file. Sorry, I have missed the following code in your file #+begin_src emacs-lisp (org-babel-do-load-languages 'org-babel-load-languages '((org . t))) #+end_src I am unsure whether it should work in this form or it worked earlier, but on main branch it is not executed during export. If I change first line to the following, the block is executed during export: #+begin_src emacs-lisp :results value none :exports results My minimal example: Test #+begin_src emacs-lisp :results value none :exports results (org-babel-do-load-languages 'org-babel-load-languages '((org . t))) #+end_src #+name: org-hello #+begin_src org :var hello="World" Hello, $hello! #+end_src #+begin_src elisp :var x=org-hello[](hello="Org") :exports both (print x) #+end_src Thanks! The original problem is likely due to the default header arguments in ob-org.el, which are unusual. If I export both, then all is well. #+begin_src emacs-lisp :results value none :exports both (org-babel-do-load-languages 'org-babel-load-languages '((org . t))) #+end_src All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: emacs-jupyter does not send result form babel block
John Kitchin writes: >> On Sat, Sep 4, 2021 at 4:22 PM Rafael wrote: >> >>> >>> I am using emacs-jupyter (https://github.com/nnicandro/emacs-jupyter), >>> and I have just noticed that results from a block are not sent to >>> another block. I think it has to do with this issue >>> https://github.com/nnicandro/emacs-jupyter/issues/222. Can somebody >>> suggest a workaround? (I actually want to use the output from a kernel >>> different from python, but since the problem happens also with the python >>> kernel I'm using it as an example). >>> >>> #+name: atest >>> #+begin_src jupyter-python :session test >>> 1+1 >>> #+end_src >>> >>> #+RESULTS: graphst >>> : 2 >>> >>> #+begin_src python :var adjs=atest >>> adjs >>> #+end_src >>> >>> #+RESULTS >> : nil >> >> > > I think this is a bug in jupyter-org-client.el in this function: > > (defun jupyter-org--add-result (req result) > (cond >((jupyter-org-request-silent-p req) > (unless (equal (jupyter-org-request-silent-p req) "none") > (message "%s" (org-element-interpret-data result >((jupyter-org-request-async-p req) > (jupyter-org--clear-request-id req) > (jupyter-org--do-insert-result req result)) >(t > (push result (jupyter-org-request-results req) > > The problem is that when the jupyter block is executed to define the > variable in the python header, it is run with a "silent" results param. The > function above is responsible for adding the results to the > jupyter-org-request struct, and here when it sees the results are silent, > it does not do that, so the results are nil, which is why you see what you > see. > > I don't think that behavior is correct. It isn't quite right to just remove > the first block though, at least in this case. The result in this function > is already structured as a fixed-width results element intended to be > interpreted as a results string, and not the numeric value returned. So the > fix is probably upstream from this. > > I am not sure what the fix is for this. The code path from C-cC-c to > executing the code, handling the request to the kernel, getting results and > to the output is very hard to follow for me. I would post an issue at > https://github.com/nnicandro/emacs-jupyter/issues. Thanks for your answer and sorry for not following up. There is already an issue about this which has been open since March 2020, see https://github.com/nnicandro/emacs-jupyter/issues/222.
Re: [BUG] Unregistered buffer modifications detected [9.5 (9.5-g49e2f6 @ /Users/myuser/.emacs.d/straight/29/straight/build/org/)]
Another one: https://gist.github.com/aaronjensen/5114997373008e18a6473f513f5d5da8 I don't have the details of what I was doing in the time, sorry. I'm on: ded97b767 * main origin/main org-element.el: Fix regression from d3836c1a1 Aaron
