[O] Dates with repeaters, times and range
Hello all, I have a question that's probably FAQ material but I was wondering what the "best" way to do something like this would be: I have a meeting that's scheduled from 10:00 - 11:00 for the next three days. I tried to create a heading with this property: <2019-10-02 Wed 08:30-15:00 +1d>--<2019-10-04 Fri 08:30-15:00 +1d> and I also tried this: <2019-10-02 Wed 08:30-15:00>--<2019-10-04 Fri 08:30-15:00> but the agenda shows Wednesday with the 8:30 - 15:00 and the Friday with the 15:00 but on Thursday it shows simply 2/3. - Is there a way to fix get Thursday to show up in the agenda with the times blocked out? I'd like to have the benefit of blocking out the time, as well as avoiding the need to define a new heading for every day. Thanks, --Nate
Re: [O] fill function: Put a newline at the end of each sentence in paragraph.
>>> "MB" == Marcin Borkowski writes: > On 2019-10-01, at 08:34, Uwe Brauer wrote: >> Hi >> >> I am looking for a filling function, which puts a newline at the end of >> each sentence. I have one for LaTeX mode but it does not work in org >> mode. >> >> Anybody has a pointer? > How about these? > http://mbork.pl/2019-01-20_Filling_and_version_control and the two links there aha, your code works, but not the code in the links you posted. Small disadvantage of your code. If I execute it twice several (unwanted) newlines are inserted after each sentence! But anyhow it works, if I keep this in mind, it is almost perfect. > https://emacs.stackexchange.com/questions/443/editing-files-with-one-sentence-per-line The second one does not help. The coded posted there (defun ospl/fill-paragraph () Does not work in org mode. I obtain Debugger entered--Lisp error: (wrong-number-of-arguments #f(compiled-function (ad--addoit-function arg) #) 1) ad-Advice-fill-paragraph(#f(compiled-function (arg) (interactive "*P") #)) apply(ad-Advice-fill-paragraph #f(compiled-function (arg) (interactive "*P") #) nil) fill-paragraph() (save-excursion (fill-paragraph) (ospl/unfill-paragraph) (let ((end-of-paragraph (make-marker))) (save-excursion (forward-paragraph) (backward-sentence) (forward-sentence) (set-marker end-of-paragraph (point))) (forward-sentence) (while (< (point) end-of-paragraph) (just-one-space) (delete-backward-char 1) (newline) (forward-sentence)) (set-marker end-of-paragraph nil))) ospl/fill-paragraph() funcall-interactively(ospl/fill-paragraph) call-interactively(ospl/fill-paragraph record nil) command-execute(ospl/fill-paragraph record) execute-extended-command(nil "ospl/fill-paragraph" "ospl/f") funcall-interactively(execute-extended-command nil "ospl/fill-paragraph" "ospl/f") call-interactively(execute-extended-command nil nil) command-execute(execute-extended-command) And the github packages https://github.com/andersjohansson/tex-fold-linebreaks Works for tex files, but for these I have a solution already, it is org mode where the filling fails. > Hth,
Re: [O] fill function: Put a newline at the end of each sentence in paragraph.
On 2019-10-01, at 08:34, Uwe Brauer wrote: > Hi > > I am looking for a filling function, which puts a newline at the end of > each sentence. I have one for LaTeX mode but it does not work in org > mode. > > Anybody has a pointer? How about these? http://mbork.pl/2019-01-20_Filling_and_version_control and the two links there https://emacs.stackexchange.com/questions/443/editing-files-with-one-sentence-per-line Hth, -- Marcin Borkowski http://mbork.pl
Re: [O] [ANN] org-sidebar-tree: Sidebar tree-view buffer for outline navigation
On Tuesday, 1 Oct 2019 at 09:01, Adam Porter wrote: > I've published an easy-to-use version of a tool that I think Org has > long needed: a sidebar tree-view buffer for navigating outlines. Hi Adam, thanks for the heads up. I have my own hand-crafted rather primitive tool for this so it will be nice to see a properly implemented version. I'll give it a try and will get back to you. I hope it works well with evil... -- Eric S Fraga via Emacs 27.0.50, Org release_9.2.4-401-gfabd6d
[O] [ANN] org-sidebar-tree: Sidebar tree-view buffer for outline navigation
Hi friends, I've published an easy-to-use version of a tool that I think Org has long needed: a sidebar tree-view buffer for navigating outlines. https://github.com/alphapapa/org-sidebar#org-sidebar-tree There have been some similar, unpolished tools floating around, including an answer I posted on Emacs.StackExchange several years ago. And the org-panes package has been around even longer, but hasn't been touched for 5 years, and it isn't on MELPA, so few people know about it. So I've put together org-sidebar-tree and released it as part of org-sidebar, which makes it easy to use and customize. Here are some screenshots: https://github.com/alphapapa/org-sidebar/raw/master/images/tree.gif https://github.com/alphapapa/org-sidebar/raw/master/images/sidebar-with-tree.png https://github.com/alphapapa/org-sidebar/raw/master/images/tree-and-item-sidebars.png It seems to work well, but I'm sure wider testing will reveal some improvements to be made. I'd appreciate any feedback. Thanks, Adam
Re: [O] [RFC] Document level property drawer
Marco Wahl writes: > Adam Porter writes: > >> Gustav Wikström writes: >> >>> 3) Properties defined in a property drawer will have precedence over >>>properties defined as a property keyword, if the same property is >>>defined using both conventions. >> >> That protocol seems unnatural and confusing to me: >> >> - If precedence were to be defined by something other than file-order, >> it seems to me that those defined with #+ keywords should have >> precedence, because they are more visible, while those in drawers are >> hidden. >> - However, it seems to me that the simplest, most natural protocol would >> be for later declarations to override earlier ones. > > I think it would be quite natural to use the tree structure of Org. A > property setting in a subtree overrides the setting in a parent (which > could be the document(= the whole file.)) Hi Marco, I think you misunderstood his point #3 and my objection to it. :)
Re: [O] small bash/awk script to query org-mode tables
Greg Minshall writes: > i've renamed the gitlab *project* org-table-query-script, though i've > kept the command, itself, the simpler org-query. does that seem > reasonable? Sure, thanks. :)
Re: [O] [RFC] Document level property drawer
Marco Wahl writes: > [..] > > I think the distinction between Org file and Org subtree should be kept > to a minimum. Wouldn't it be nice if Org files can be considered as Org > subtrees? Yes, this would be very nice. I have a related question or proposal. Up until now, I basically do not use property drawers except absolutely necessary, because properties are invisible by default. Properties "need to be inserted into a [..] drawer", and "in order to look inside the drawer, you need to move point to the drawer line and press ‘’ there." A place that comes to mind where I really would like to use properties is the header-args property in order to specify parameters related to tangling for all src blocks in certain subtrees. But for such properties to satisfactorily work for me, they would have to be visible by default. E.g. I would want the header-args to be immediately visible just like they are when they are written after #+BEGIN_SRC or #+HEADER. Otherwise I would find myself constantly wondering whether this or that property drawer contains something essential and every TAB on a collapsed headline would have be followed by an accompanying move to the property drawer and a TAB there. On the other hand, there are properties that are very good candidates for remaining hidden by default, like ID. I would like to be able to make a clear distinction between properties that are visible by default and properties that are not. Maybe it would be possible to allow some #+.. syntax following headings for subtree properties that are visible by default. A requirement could be made that such property specifications always have to be followed by a property drawer, even if that is empty. Then everything #+.. that is before the property drawer would belong to the heading/subtree, and everything #+.. that follows the drawer would be treated as it is until now. Please tell me if I missed something and Org is already capable of something like that. If not, are there others who would like visible-by-default property specifications for headings/subtrees in addition to invisible-by-default property specifications in drawers, too? Finally, I would like to state an opinion: If there is visible-by-default (by #+..) and invisible-by-default (by drawers) syntax for headings/subtrees, including level 0, it may be viable to require them to be disjoint for each heading/subtree. Most probably it would be good practice, anyway. And the precedence question raised previously in this thread would be eliminated.
[O] fill function: Put a newline at the end of each sentence in paragraph.
Hi I am looking for a filling function, which puts a newline at the end of each sentence. I have one for LaTeX mode but it does not work in org mode. Anybody has a pointer? Regards Uwe Brauer smime.p7s Description: S/MIME cryptographic signature
