[O] Global TODO: display more than the TODO heading line?
I use orgmode as a to do tracker rather than a scheduler, so C-cat is my main command. I have a bunch of files with TODO items in various states including WAITING and HOLD. When I change something to the WAITING or HOLD state, the C-c C-t command is set to ask why so a line of information is in the org file after the TODO line. (setq org-todo-keywords (quote ((sequence "TODO(t)" "NEXT(n)" "SCHEDULED(s)" "|" "DONE(d)") (sequence "WAITING(w@/!)" "HOLD(h@/!)" "|" "CANCELLED(c@/!)" "PHONE" "MEETING" I'd love to see that line of information in the TODO list so I know why something is waiting or on hold without having to visit it. So and org file entry that looks like this: * HOLD make staffauth group and upload keys - State "HOLD" from "TODO" [2013-12-16 Mon 11:54] \\ Hold till we can work out a group to create (or a current one to use?) Now appears in the global todo list as: 56726-user-keys-ovl01.syd:HOLD make staffauth group and upload keys and I'd like to see something like 56726-user-keys-ovl01.syd:HOLD make staffauth group and upload keys Hold till we can work out a group to create (or a current one to use?) Can the todo list be tweaked in this way? Can some other agenda view be created so that the comments made when the item is set to WAITING or HOLD show up? With or without the date the comment was made? Zebee
[O] Missing patch from Eric Schulte from 2013-10-09
Hi, I noticed that I miss the following patch from Eric Schulte (from 2 months ago): http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=15847336c39e7219e1c51c55d487f99956a06e34 I have Org-mode version 8.2.4 (8.2.4-8-gf1b933-elpaplus @ c:/Users/fpz/Documents/home/.emacs.d/elpa/org-plus-contrib-20131216/) taken from elpa. When I download the current stable release of Org-mode (version 8.2.4 from http://orgmode.org/) I see that this patch is missing too (the org-babel-tangle-use-relative-file-links variable is missing). Any chance to get this patch in elpa (without having to clone the git master branch)? Thanks a lot for your help, Francesco
[O] Missing contrib packages
Hi, I have Org-mode version 8.2.4 (8.2.4-8-gf1b933-elpaplus @ c:/Users/fpz/Documents/home/.emacs.d/elpa/org-plus-contrib-20131216/). I notice that I miss several packages like htmlize (important) and org-effectiveness. My questions are: - why, in the org-plus-contrib from elpa, I miss these packages (present in the master branch)? - why, in the release version 8.2.4 downloaded from http://orgmode.org/, I have htmlize but not org-effectiveness? Thanks a lot, Francesco
Re: [O] Bug: Bad ODT files when including multiple images [7.9.3f (release_7.9.3f-17-g7524ef @ /usr/share/emacs/24.3/lisp/org/)]
At Tue, 03 Dec 2013 21:17:06 +0530, Jambunathan K wrote: > > Let me upgrade my LibreOffice and report back. > Jambunathan, was wondering if you had a chance to look at this error ? I can confirm it is an issue on my Ubuntu 13.10 system with : - emacs 24.3.1 - org-mode 8.2.4 (org-plus-contrib elpa package 20131216) - libreoffice 4.1.3.2 I use the odt export to create student handouts and *really* don't want to go back through 200+ documents to add captions to all of the images ! Thanks -Tim
Re: [O] Bug: Bad ODT files when including multiple images [7.9.3f (release_7.9.3f-17-g7524ef /usr/share/emacs/24.3/lisp/org/)]
> Let me upgrade my LibreOffice and report back. Jambunathan, was wondering if you had a chance to look at this error ? I can confirm it is an issue on my Ubuntu 13.10 system with : - emacs 24.3.1 - org-mode 8.2.4 (org-plus-contrib elpa package 20131216) - libreoffice 4.1.3.2 I use the odt export to create student handouts and *really* don't want to go back through 200+ documents to add captions to all of the images ! Thanks -Tim
[O] #+TEXT: disappeared
Hi there, I just found that #+TEXT: from pre 8 org-mode has disappeared. Does anybody know how this is done with org-mode 8? -- Thanks, Manfred
Re: [O] #+TEXT: disappeared
Manfred Lotz wrote: > I just found that #+TEXT: from pre 8 org-mode has disappeared. > > Does anybody know how this is done with org-mode 8? IIUC, it became `#+ascii:'. Best regards, Seb -- Sebastien Vauban
[O] one step ahead
Hi, after my first prob (with TODO), now, I've my second one :-( the Agenda. Following the guide: http://orgmode.org/worg/org-tutorials/org4beginners.html#sec-5 I've: - opened the 1.org - press the Cca (So, again, visit 1.org. Next press *C-c a*, which calls the agenda. It looks like this:) But, nothing appens... I mean, I don' t see that: Press key for an agenda command --- a Agenda for the current week or day t List of all TODO entries Can someone help me? TIA Renato
Re: [O] one step ahead
Renato Pontefice writes: > Hi, > after my first prob (with TODO), > now, I've my second one :-( > > the Agenda. > > Following the guide: > http://orgmode.org/worg/org-tutorials/org4beginners.html#sec-5 > > I've: > - opened the 1.org > - press the Cca (So, again, visit 1.org. Next press C-c a, which calls the > agenda. It looks like this:) > > But, nothing appens... > I mean, I don' t see that: > > Press key for an agenda command > --- > a Agenda for the current week or day > t List of all TODO entries > > Can someone help me? > The tutorial makes certain assumptions that you probably have not satisfied. In particular, it assumes that you have done the setup described in section 1.3, "Activation", of the Org manual, available through Info or on the web at: http://orgmode.org/manual/Activation.html# The keybindings described there should be placed in your .emacs initialization file. Nick
Re: [O] [parser] subscripts and underlines interacting badly
Hello, Aaron Ecay writes: > Since the present syntax is inadequate for representating these > sequences, the new syntax will have to break backwards compatibility > somehow in order to fix the problem. So there’s no long-term harm in > having a short-term kludge that will eventually disappear. OK. Thanks for the patch. Though, I think you are patching the wrong location. Modifying `org-element--get-next-object-candidates' is expensive. It would be better to patch `org-element-sub/superscript-successor' and make it ignore underline matches with brackets followed by an underscore character and resume searching. > But eventually it will (assuming the cache implementation proves robust > enough), right? So, changes in org-element.el will eventually percolate > to the rest of org, whereas changes elsewhere will wither and dry up. But it will be a slow process, and, meanwhile both org-element and the rest of Org must be handled. > I don’t think escaped characters help with the problem that it is > presently impossible to represent the following (pseudo)-element > sequence in org syntax: [...] You are right, escaped characters cannot help us here. > Anyway, what do escaped characters do that entities cannot? Not much. But they could be used in verbatim context. Also, they are somehow inconvenient to use, as you noticed. This can be troublesome in an environment also meant for note-taking. Regards, -- Nicolas Goaziou
Re: [O] [export] org-export-with-* bugs
Hello,
Aaron Ecay writes:
> 1) In exporting the following org buffer to latex, I get the following
> stack trace (at end of email because of length):
>
> =
> #+options: |:nil
>
> | foo | bar |
> =
The more I look at it, the more I'm inclined to think that it's totally
useless. I don't think anyone wants tables removed from Org syntax.
Though, occasionally some line starting with "|" can be interpreted as
a table. In this case, it's possible to use "\vert" entity anyway.
I'm not sure it is worth fixing. I think we really should remove it, or
change its meaning, like "|:nil means that all tables are ignored in
export process" (which is probably almost as useless). The same goes for
"::nil".
> 2) When exporting the following buffer to latex:
>
> =
> #+options: ^:nil
>
> foo_{*bar*}
> =
>
> I get (ignoring document preamble):
>
> =
> foo\_\{$\backslash$textbf\{bar\}\}
> =
>
> Note the escaping of the backslash and inner pair of braces. I would
> have expected:
>
> =
> foo\_\{\textbf{bar}\}
> =
I attach a patch that should solve this (but doesn't handle tables or
fixed-width areas).
Regards,
--
Nicolas Goaziou
>From f906c641d6dc0dce9314ac952e70f8c8ece93d26 Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou
Date: Mon, 16 Dec 2013 22:01:59 +0100
Subject: [PATCH] ox: Fix export of uninterpreted elements
* lisp/ox.el (org-export-data): Do not check for uninterpreted
elements or objects. These are removed from parse tree anyway.
(org-export--remove-uninterpreted): New function.
(org-export--interpret-p): Removed function.
(org-export-as): Handle uninterpreted elements and objects.
---
lisp/ox.el | 107 ++---
1 file changed, 67 insertions(+), 40 deletions(-)
diff --git a/lisp/ox.el b/lisp/ox.el
index ad6ee04..44f6241 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -2170,10 +2170,8 @@ a tree with a select tag."
;; Internally, three functions handle the filtering of objects and
;; elements during the export. In particular,
;; `org-export-ignore-element' marks an element or object so future
-;; parse tree traversals skip it, `org-export--interpret-p' tells which
-;; elements or objects should be seen as real Org syntax and
-;; `org-export-expand' transforms the others back into their original
-;; shape
+;; parse tree traversals skip it and `org-export-expand' transforms
+;; the others back into their original shape
;;
;; `org-export-transcoder' is an accessor returning appropriate
;; translator function for a given element or object.
@@ -2208,16 +2206,6 @@ Return transcoded string."
(let ((transcoder (org-export-transcoder data info)))
(if transcoder (funcall transcoder data info) data))
info))
- ;; Uninterpreted element/object: change it back to Org
- ;; syntax and export again resulting raw string.
- ((not (org-export--interpret-p data info))
- (org-export-data
- (org-export-expand
- data
- (mapconcat (lambda (blob) (org-export-data blob info))
- (org-element-contents data)
- ""))
- info))
;; Secondary string.
((not type)
(mapconcat (lambda (obj) (org-export-data obj info)) data ""))
@@ -2315,31 +2303,68 @@ recursively convert DATA using BACKEND translation table."
;; will probably be used on small trees.
:exported-data (make-hash-table :test 'eq :size 401)
-(defun org-export--interpret-p (blob info)
- "Non-nil if element or object BLOB should be interpreted during export.
-If nil, BLOB will appear as raw Org syntax. Check is done
-according to export options INFO, stored as a plist."
- (case (org-element-type blob)
-;; ... entities...
-(entity (plist-get info :with-entities))
-;; ... emphasis...
-((bold italic strike-through underline)
- (plist-get info :with-emphasize))
-;; ... fixed-width areas.
-(fixed-width (plist-get info :with-fixed-width))
-;; ... LaTeX environments and fragments...
-((latex-environment latex-fragment)
- (let ((with-latex-p (plist-get info :with-latex)))
- (and with-latex-p (not (eq with-latex-p 'verbatim)
-;; ... sub/superscripts...
-((subscript superscript)
- (let ((sub/super-p (plist-get info :with-sub-superscript)))
- (if (eq sub/super-p '{})
- (org-element-property :use-brackets-p blob)
- sub/super-p)))
-;; ... tables...
-(table (plist-get info :with-tables))
-(otherwise t)))
+(defun org-export--remove-uninterpreted (data info)
+ "Change uninterpreted elements back into Org syntax.
+DATA is the parse tree. INFO is a plist containing export
+options."
+ (org-element-map data
+ '(entity bold fixed-width italic latex-environment latex-fragment
+ strike-through subscript superscript underline)
+(lambda (blob)
+ (let ((type (org-element-type blob))
+ new)
+ (case type
+ ;; ... entities...
+ (entity
+ (unless (plist-get info :with-entities)
+ (setq new (list (org-export-e
Re: [O] [RFC] [patch] open/delete attachment with inherited directory
Hello,
Aaron Ecay writes:
> I have some org files where each headline corresponds to an entry in a
> bibliography. The headlines each have attached to them a pdf file of
> the corresponding document. The attachment directory is set as a
> file-level property and inherited by the children (this is so that I can
> access the files easily also outside of org).
>
> In the current implementation of org-attach-{open,delete-one}, I am
> prompted to choose among all files in the attachment directory (i.e. all
> the pdfs of entries in the bibliography), not just the (usually single)
> file attached to the headline at point. I think the latter behavior
> makes more sense. The attached (heh) patch implements this change. Are
> there any comments?
Thanks for the patch.
I see one major problem, though. Org attach doesn't require to list
files attached to the entry (see `org-attach-file-list-property').
Therefore, `org-entry-get-multivalued-property' could return nil even
though there are attached files.
Regards,
--
Nicolas Goaziou
Re: [O] [export] org-export-with-* bugs
Nicolas Goaziou writes: > Hello, > > Aaron Ecay writes: > >> 1) In exporting the following org buffer to latex, I get the following >> stack trace (at end of email because of length): >> >> = >> #+options: |:nil >> >> | foo | bar | >> = > > The more I look at it, the more I'm inclined to think that it's totally > useless. I don't think anyone wants tables removed from Org syntax. > > Though, occasionally some line starting with "|" can be interpreted as > a table. In this case, it's possible to use "\vert" entity anyway. > > I'm not sure it is worth fixing. I think we really should remove it, or > change its meaning, like "|:nil means that all tables are ignored in > export process" (which is probably almost as useless). The same goes for > "::nil". I personally agree with this. I can think of no cases where it's useful /and/ =·= isn't a solution /for my use-cases/. –Rasmus -- Got mashed potatoes. Ain't got no T-Bone. No T-Bone
Re: [O] PNG R plots size
Vicente Vera gmail.com> writes: > How can I control the size of a PNG graphic? Do I need to tweak > something inside Org or specify something in R? I use a line like this: #+HEADER: :res 300 :units cm :width 15 :height 15 to create a 15cm square PNG at 300 dpi.
[O] PNG R plots size
Hello. I have a source code block for an R plot with the following header: #+BEGIN_SRC R :results output graphics :file figure1.png :exports results It works, but the default size is too small. When I change the extension to SVG or PDF (i.e. when exporting to LaTeX, but is not what i need right now) the dimensions are fine. How can I control the size of a PNG graphic? Do I need to tweak something inside Org or specify something in R? Thanks.
Re: [O] Bug: Bad ODT files when including multiple images [7.9.3f (release_7.9.3f-17-g7524ef @ /usr/share/emacs/24.3/lisp/org/)]
At Wed, 18 Dec 2013 00:16:25 +0530, Jambunathan K wrote: > > Tim writes: > > > Jambunathan, > >was wondering if you had a chance to look at this error ? I can confirm > > it is an issue on my Ubuntu 13.10 system with : > >- emacs 24.3.1 > >- org-mode 8.2.4 (org-plus-contrib elpa package 20131216) > >- libreoffice 4.1.3.2 > > I can see the problem on my side. > > > I use the odt export to create student handouts and *really* don't > > want to go back through 200+ documents to add captions to all of the > > images ! > > This issue is a bit unfortunate. Please don't modify your Org files. I > will circulate a fix - if not a fix, atleast a workaround - in another > day. Thank you ! -Tim
Re: [O] Bug: Bad ODT files when including multiple images [7.9.3f (release_7.9.3f-17-g7524ef @ /usr/share/emacs/24.3/lisp/org/)]
Tim writes: > Jambunathan, >was wondering if you had a chance to look at this error ? I can confirm > it is an issue on my Ubuntu 13.10 system with : >- emacs 24.3.1 >- org-mode 8.2.4 (org-plus-contrib elpa package 20131216) >- libreoffice 4.1.3.2 I can see the problem on my side. > I use the odt export to create student handouts and *really* don't > want to go back through 200+ documents to add captions to all of the > images ! This issue is a bit unfortunate. Please don't modify your Org files. I will circulate a fix - if not a fix, atleast a workaround - in another day. Jambunathan K.
Re: [O] preview beamer frame in org/beamer
Hi Mirko,
2013ko abenudak 14an, Mirko Vukovic-ek idatzi zuen:
>
> Is there a command to generate a pdf output of a single beamer frame?
>
> The command would generate the latex file with the correct header, and a
> single frame, and process it into a pdf file.
You could do this partially with the \includeonlyframes command
(Sec. 4.3.3 of the Beamer manual). This will cut down on the Latex
compilation time needed, but not the time used by org to export the
document to Latex, so if the bottleneck is expensive babel computations
(for example) this won’t help – but other things (e.g. babel’s cache)
might.
Such a command isn’t currently implemented; what would be needed would
be to:
1) find out the label of the \frame corresponding to the current
headline
2) perform the usual export
3) insert \includeonlyframes{the-label-from-step-1} into the generated
latex (just above the \begin{document} line should be fine)
4) compile as usual
--
Aaron Ecay
Re: [O] [RFC] [patch] open/delete attachment with inherited directory
Hi Nicolas, 2013ko abenudak 17an, Nicolas Goaziou-ek idatzi zuen: > > Thanks for the patch. > > I see one major problem, though. Org attach doesn't require to list > files attached to the entry (see `org-attach-file-list-property'). > Therefore, `org-entry-get-multivalued-property' could return nil even > though there are attached files. Hmm, good catch. Perhaps then we should read the property if it exists, but fall back to querying the filesystem in case it does not. WDYT? Thanks, -- Aaron Ecay
Re: [O] [export] org-export-with-* bugs
2013ko abenudak 17an, Nicolas Goaziou-ek idatzi zuen: > The more I look at it, the more I'm inclined to think that it's totally > useless. I don't think anyone wants tables removed from Org syntax. > > Though, occasionally some line starting with "|" can be interpreted as > a table. In this case, it's possible to use "\vert" entity anyway. > > I'm not sure it is worth fixing. I think we really should remove it, or > change its meaning, like "|:nil means that all tables are ignored in > export process" (which is probably almost as useless). The same goes for > "::nil". I think either suggestion (total removal or changing semantics) is a reasonable option. > I attach a patch that should solve this (but doesn't handle tables or > fixed-width areas). (fixed-width is one of the branches in the ‘case’ form in the new code...?) I can confirm the fix. It looks like the new mechanism is equivalent to a parse tree filter. (Also, reading the patch I feel like I finally understand what a parse tree filter can/should look like.) Should org-export--remove-uninterpreted be added to the default value of org-export-filter-parse-tree-functions, rather than hard-coding it into org-export-as? Thanks for the quick patch, -- Aaron Ecay
Re: [O] org-mode habits graph dissapears
Hi Javier, > Thank you for your response. Here it is what I do: Thanks for the more detailed information. This is helpful. Please continue to cc the org-mode list your responses. > I open one of my agenda files, write the new habit, schedule it with > C-s, then add a repeat interval, and then I do C-c C-x p, write > =STYLE=, and then habit. The result, is like this: > > * new habit > SCHEDULED: <2013-12-17 Tue .+2d/4d> > :PROPERTIES: > :STYLE:habit > :END: > > I notice that I don't have the line: :LAST_REPEAT: then, I check my > agenda, with C-a a, and I see the habit, with a color bar on the > right, and the symbol "!". = personal: new habit ! = > > Then I mark the new habit as "DONE", C-c C-t DONE, now I update the > agenda view with "r". The new habit is gone, and It won't appear, > again, If I check the agenda file, it says: > > * DONE new habit > CLOSED: [2013-12-17 Tue 07:55] > SCHEDULED: <2013-12-17 Tue .+2d/4d> > - State "DONE" from "STARTED"[2013-12-17 Tue 07:55] > :PROPERTIES: > :STYLE: >habit > :END: > > And It won't appear again, I noticed that it doesn't say: > :LAST_REPEAT: Am I missing something? If I follow your example, I observe the same behavior. Though I dispute that the habit won't appear again: I think it will, just in 2 days, when it is time for you to do that habit again. So as I understand it, you are observing the expected behavior. If this is not what you want, you may want to look at the ways to customize org-habit, in particular , | (defcustom org-habit-show-all-today nil | "If non-nil, will show the consistency graph of all habits on | today's agenda, even if they are not scheduled." | :group 'org-habit | :type 'boolean) ` If I (setq org-habit-show-all-today t) then all habits are shown, even ones which I don't need to do today. At least to me, this sounds like the behavior you are seeking. Hope that helps, Josiah
Re: [O] [parser] subscripts and underlines interacting badly
2013ko abenudak 17an, Nicolas Goaziou-ek idatzi zuen:
>
> Hello,
>
> Aaron Ecay writes:
>
>> Since the present syntax is inadequate for representating these
>> sequences, the new syntax will have to break backwards compatibility
>> somehow in order to fix the problem. So there’s no long-term harm in
>> having a short-term kludge that will eventually disappear.
>
> OK. Thanks for the patch.
>
> Though, I think you are patching the wrong location. Modifying
> `org-element--get-next-object-candidates' is expensive. It would be
> better to patch `org-element-sub/superscript-successor' and make it
> ignore underline matches with brackets followed by an underscore
> character and resume searching.
We (perhaps) have to worry about cases like: '_foo bar_ . Here it’s not
enough to look at the character immediately following the (possible)
subscript, but rather to take into account the full logic of
org-emph-re.
But now that I think about it, this is the only correct way, since what
org-element--get-next-object-candidates sees is limited by the
restriction.
The attached patch implements this. It also updates the fontification
to match (by calling out to the parser, so there are potential
performance issues although with the cache it will hopefully not be an
issue in practice), and notes the new heuristic in the manual. The test
suite passes.
>From e2044312b95f8b427ddc662cd1abf10bf4d87b2d Mon Sep 17 00:00:00 2001
From: Aaron Ecay
Date: Sun, 15 Dec 2013 21:30:27 -0500
Subject: [PATCH] org-element: use brackets to disambiguate subscript/underline
* lisp/org-element.el (org-element-sub/superscript-successor): use
brackets to disambiguate subscript/underline
* lisp/org.el (org-do-emphasis-faces): incorporate the above
disambiguation
* doc/org.texi: reflect these changes in the manual
In an org-syntax string like 1 or 2 below, both subscript and
underline are possible interpretations. This patch uses the presence
of brackets to disambiguate these cases, that is, 1 is interpreted as
an underlined "foo" whereas 2 is subscript "foo" followed by
plain-text "_"
1: '_foo_
2: '_{foo}_
This the in-buffer highlighting is updated to match.
---
doc/org.texi| 14 ++
lisp/org-element.el | 22 +++---
lisp/org.el | 36 ++--
3 files changed, 55 insertions(+), 17 deletions(-)
diff --git a/doc/org.texi b/doc/org.texi
index b4c4078..3eefe9a 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -9739,6 +9739,17 @@ can tweak @code{org-emphasis-regexp-components}. Beware that changing one of
the above variables will no take effect until you reload Org, for which you
may need to restart Emacs.
+When it follows an alphanumeric character, the underscore is always
+interpreted as a subscript (@pxref{Subscripts and superscripts}), and when it
+follows whitespace it is always the start of an underline (assuming a
+matching underscore is found in a proper position further along). However,
+after a punctuation character (for example the apostrophe), the underscore
+character can be ambiguous between these two interpretations. Org uses a
+simple heuristic for these cases: if the character following the underscore
+is an opening brace @samp{@{} or if no matching underscore is seen in the
+following text, the underscore is considered to be the start of a subscript.
+Otherwise, it is the start of underlining.
+
@node Horizontal rules
@subheading Horizontal rules
@cindex horizontal rules, markup rules
@@ -10123,6 +10134,9 @@ In addition to showing entities as UTF-8 characters, this command will also
format sub- and superscripts in a WYSIWYM way.
@end table
+For discussion of the resolution of ambiguities between the underscore as the
+introducer of a subscript vs.@ underline, see @ref{Emphasis and monospace}.
+
@node @LaTeX{} fragments
@subsection @LaTeX{} fragments
@cindex @LaTeX{} fragments
diff --git a/lisp/org-element.el b/lisp/org-element.el
index 089ecfb..faa1e44 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -3408,9 +3408,25 @@ Return value is a cons cell whose CAR is either `subscript' or
`superscript' and CDR is beginning position."
(save-excursion
(unless (bolp) (backward-char))
-(when (re-search-forward org-match-substring-regexp nil t)
- (cons (if (string= (match-string 2) "_") 'subscript 'superscript)
- (match-beginning 2)
+(let (res)
+ (while (and (not res)
+ (re-search-forward org-match-substring-regexp nil t))
+ (goto-char (match-beginning 0))
+ (when (or
+ ;; this subscript uses brackets -> handle as subscript
+ ;; unconditionally
+ (eq (aref (match-string 3) 0) ?{)
+ ;; it is not ambiguous with an underline -> handle as
+ ;; subscript
+ (not (looking-at-p org-emph-re)))
+ (setq res (cons (if (string= (match-string 2) "_")
+ 'subscript
+ 'superscript)
+ (match-beginning 2
+ ;; otherwise -> keep going, and let the u
