Re: [O] Curious as to message in echo area
On 06/18/2018 02:51 AM, Nick Dokos wrote: Charles Millar writes: Hello, I have always concerned myself that a table column formula returns what is expected.and is correct. However I never paid attention to the echo area and I just noticed that it displays the following message "cells in region copied, use M-x org-table-paste-rectangle to paste them in a table" when I C-c C-c on the formula in the following table | 1 | | 2 | | 3 | | | #+tblfm: @>$>=vsum(@1..@>>) The correct result is returned. Have I been ignoring something for the past several years, i.e. has the above message always been displayed? No, it was added recently: , | $ git blame -L 1868,1870 -- org-table.el | 5c8cb1e733 (Bastien 2018-04-28 12:52:20 +0200 1868) (setq org-table-clip (nreverse region)) | 5c8cb1e733 (Bastien 2018-04-28 12:52:20 +0200 1869) (message (substitute-command-keys "Cells in the region copied, use \\[org-table-paste-rectangle] to paste them in a table." | fe939ecb95 (Carsten Dominik 2008-03-22 16:52:18 +0100 1870) | $ git show 5c8cb1e733 | commit 5c8cb1e7332a9fd8ba71cd0a5fe7bdf5d19d09fd | Author: Bastien | Date: Sat Apr 28 12:52:20 2018 +0200 | | Add messages for `org-table-copy-region' and `org-copy-visible' | | * lisp/org-table.el (org-table-copy-region): | * lisp/org.el (org-copy-visible): Add a message. thank you.
[O] Bug: org-toggle-tag always marks buffer modified [9.1.13 (9.1.13-elpaplus @ .emacs.d/elpa/org-plus-contrib-20180618/)]
org-toggle-tag always marks the buffer as modified due to how it is implemented. It would be better if it did not mark the buffer modified if it does not change anything. This is annoying for org-depend.el (which is contrib, not officially supported) because the org-blocker-hook set by org-depend.el will mark the buffer modified whenever an agenda view is built/refreshed. Glancing at org-toggle-tag, the feature isn't difficult to implement, but it'll be ugly. Emacs : GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.24), modified by Debian Package: Org mode version 9.1.13 (9.1.13-elpaplus @ /usr/local/google/home/ayatane/.emacs.d/elpa/org-plus-contrib-20180618/)
Re: [O] ox-texinfo: use an Org section as Info Top node
Nicolas Goaziou writes: > > Jonas Bernoulli writes: > >> Currently ox-texinfo uses the text before the first Org section as the >> "Top" Info node. That is fine for manuals like org-manual.org where >> that part of the document only consists of a few lines. In my manuals >> there are up to 40 lines before the first heading, which makes it >> desirable to make that part of the document collapsible. > > You can use a drawer for that: > > :PREAMBLE: > ... > :END: That works for me. >> It is already possible to set the section whose content is to be used >> on the copyright page (and which can be inserted elsewhere using >> "#+texinfo: @insertcopying") using the COPYING property. >> >> Could you please implement something similar for the "Top" node, using >> a property such as TOP? > > This sounds awkward, e.g., what would become the text before the first > heading? I guess it could either be ignored or prepended to the text from the TOP section. > AFAIU, there no really need for it, isn't it? I didn't know about the PREAMBLE thing. Now that I do, I don't need anything else. Thanks for your help Jonas
Re: [O] Agenda search: setting sort-order
I had a look at org-agenda.el, and took a first stab at "coding" :)
I fixed the sorting problem when using agenda-search-view, and
I have a DIFF/patch at the bottom of this e-mail [1] that provided the fix.
Would this be of interest to the org-mode project? This code fixes the
problem,
but it is duplicated in the function org-agenda-get-todos, and seems
redundant,
therefore a more "long term" fix would probably not resemble the minor patch
below. Also, I have no experience with lisp, nor the org-mode codebase :-O
Here's steps I used to find the problem. Feel free to skip to [1]
for the DIFF/patch.
I found that if I perform an agenda-search, and change
the sort method to priority or tag, then the agenda items
matching my search are indeed sorted in the correct order.
This lead me to think to inspect the code that is performing
the time/date comparison of entries found by the org-search-view.
I put a debug-watch on the function org-cmp-ts and set
the sort method to "ts-down". I ran an agenda search, and I
noticed that none of the entries matching my search had a 'ts-date
property.
I ran another agenda search (by tag) and noticed that the entries
being compared in the org-cmp-ts function did indeed have a 'ts-date
property.
So, I came to the conclusion that org-search-view does not give matching
entries a 'ts-date property. Also, the 'type property of these entries
needed
the ts-date-type appended to their 'type property (e.g. "search timestamp"
instead of just "search"). Otherwise, the org-cmp-ts function would think
the two entries it was comparing did not have matching timestamp types
and simply return nil, indicating both entries were "equal" in sort order.
Thanks,
--Nate
[1]
I ran a DIFF of org-agenda.el (mine) against org-agenda.el (9.1.13) and
here's the DIFF.
diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 322480c..5af6743 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -4567,6 +4567,9 @@ is active."
(goto-char beg)
(setq marker (org-agenda-new-marker (point))
category (org-get-category)
+ ts-date-pair (org-agenda-entry-get-agenda-timestamp
(point))
+ ts-date (car ts-date-pair)
+ ts-date-type (cdr ts-date-pair)
level (make-string (org-reduced-level
(org-outline-level)) ? )
inherited-tags
(or (eq org-agenda-show-inherited-tags
'always)
@@ -4584,10 +4587,12 @@ is active."
(org-add-props txt props
'org-marker marker 'org-hd-marker marker
'org-todo-regexp org-todo-regexp
+ 'ts-date ts-date
+ 'ts-date-type ts-date-type
'level level
'org-complex-heading-regexp
org-complex-heading-regexp
'priority 1000
- 'type "search")
+ 'type (concat "search" ts-date-type))
(push txt ee)
(goto-char (1- end))
(setq rtn (nreverse ee))
On Tue, Jun 12, 2018 at 3:07 PM, Nathan Neff wrote:
> Bumping this question to see if anyone has a workaround -
> I recently have been wishing to search for keywords and order
> the results in reverse timestamp order.
>
> This sounds like a fairly useful and common feature, so I think
> there must be something I'm configuring incorrectly. I am able
> to reproduce the problem using a fairly clean Emacs install (a
> VM with no customizations).
>
> Thanks,
> --Nate
>
>
>
> On Wed, May 30, 2018 at 4:57 PM, Nathan Neff
> wrote:
>
>> Hi all,
>>
>> I'm using org-mode version 9.1.13 from elpa, and
>> have a custom agenda command:
>>
>>
>> (setq org-agenda-custom-commands
>>'(
>> ("z" search ""
>>((org-agenda-sorting-strategy '(timestamp-up))
>>
>> And I have an org-file with this data:
>>
>> * TODO [#C] Test1
>> :foo:
>> <2018-04-24 Tue 19:30>
>> * TODO [#A] Test2
>> :foo:
>> <2018-05-24 Thu 19:30>
>> * TODO [#B] Test3
>> :foo:
>> <2017-12-24 Sun 23:33>
>>
>> The data is not sorted according to timestamp. I cannot seem to
>> get the data sorted in any fashion when using the "search" agenda mode.
>>
>> However, if I change "search" to "tags" and search for the "foo" tag, then
>> it appears that the sorting works. I've tested it with priority and
>> timestamp
>> using the above data and it sorts the items correctly.
>>
>> Why is my "search" agenda command ignoring the
>> org-agenda-sorting-strategy?
>>
>> Thanks,
>> --Nate
>>
>
>
[O] Patch adding from-logo commentary ox-koma-letter.el
On Sat, Apr 28, 2018 at 1:32 AM, Bastien wrote: > Hi Grant, > > Grant Rettke writes: > >> Here is how it works, the same way as the other ones: > > If needed, don't hesitate to advertize this in the comment section > of the code. Here is a patch to a commentary on how to use FROM_LOGO. 0001-exporters-koma-letter-export.org-Add-FROM_LOGO-comme.patch Description: Binary data
[O] problem with frequency table if it contains strings.
Hi Please consider the following example #+BEGIN_SRC emacs-lisp (defun in-interval (bounds el) (and (>= el (car bounds)) (<= el (cadr bounds #+END_SRC #+TBLNAME: raw-data | Test | |--| |0 | |1 | |2 | |3 | |4 | |5 | |6 | |7 | |8 | |9 | | NP | | NP | | NP | #+TBLNAME: stat-marco #+ATTR_HTML: :border 2 :rules all :frame border || lower bound | upper bound | frequency | |+-+-+---| | SS | 0 | 4.9 | 8 | | AP | 5 | 6.9 | 2 | | NT | 7 | 8.9 | 2 | | SB | 9 | 10 | 1 | #+TBLFM: $4='(length (org-lookup-all '($2 $3) '(remote(raw-data,@2$1..@>$1)) nil 'in-interval));N The result is incorrect this the function also counted the entries NP, which should have been ignored. That is a annoying and I would strongly appreciate any clarification/help Thanks Uwe Brauer
[O] archiving in the same file always creates top-level headings
Hi, when I have this file === cut === * A ** B ** C === cut === and set org-archive-location to "::* Archived Tasks", as recommended in the documentation of this variable. Then, after doing C-c C-x C-a (org-archive-subtree-default) both on B and on C, I get === cut === * A * Archived Tasks ** B... * Archived Tasks ** C... === cut === while I would have expected === cut === * A * Archived Tasks ** B... ** C... === cut === (only one Archived Tasks heading). Is it really intended that org-archive-subtree-default inserts the heading, even if it does already exist? Thanks, Hendrik
[O] [Solution?] (was: table lookup combine remote: problems)
>>> "Uwe" == Uwe Brauer writes: It seems that the following works. #+TBLNAME: raw-data |---++---+| | First | Second | Third | Forth | |---++---+| |NP | NP |NP | NP | |NP | NP |NP | NP | | 3.5 | NP |NP |2.8 | |NP | NP |NP | NP | | 2.5 | 3.25 | 7.7 |3.5 | | 4 | NP | 4.5 |3.7 | |NP | NP |NP | NP | |---++---+| #+TBLNAME: stat-marco #+ATTR_HTML: :border 2 :rules all :frame border || lower bound | upper bound | frequency | |+-+-+---| | SS | 0.1 | 4.9 | 1 | | AP | 5 | 6.9 | 0 | | NT | 7 | 8.9 | 1 | | SB | 9 | 10 | 0 | | NP | | | 5 | #+TBLFM: $4='(length (org-lookup-all '($2 $3) '(remote(raw-data,@2$3..@>$3)) nil 'in-interval));N::@>$4='(length(org-lookup-all "NP" '(remote(raw-data,(@2$3..@>$3)) nil))) smime.p7s Description: S/MIME cryptographic signature
Re: [O] Curious as to message in echo area
Charles Millar writes: > Hello, > > I have always concerned myself that a table column formula returns what is > expected.and is correct. > > However I never paid attention to the echo area and I just noticed that it > displays the following message > > "cells in region copied, use M-x org-table-paste-rectangle to paste them in a > table" > > when I C-c C-c on the formula in the following table > > | 1 | > | 2 | > | 3 | > | | > #+tblfm: @>$>=vsum(@1..@>>) > > The correct result is returned. > > Have I been ignoring something for the past several years, i.e. has the above > message always been displayed? > No, it was added recently: , | $ git blame -L 1868,1870 -- org-table.el | 5c8cb1e733 (Bastien 2018-04-28 12:52:20 +0200 1868) (setq org-table-clip (nreverse region)) | 5c8cb1e733 (Bastien 2018-04-28 12:52:20 +0200 1869) (message (substitute-command-keys "Cells in the region copied, use \\[org-table-paste-rectangle] to paste them in a table." | fe939ecb95 (Carsten Dominik 2008-03-22 16:52:18 +0100 1870) | $ git show 5c8cb1e733 | commit 5c8cb1e7332a9fd8ba71cd0a5fe7bdf5d19d09fd | Author: Bastien | Date: Sat Apr 28 12:52:20 2018 +0200 | | Add messages for `org-table-copy-region' and `org-copy-visible' | | * lisp/org-table.el (org-table-copy-region): | * lisp/org.el (org-copy-visible): Add a message. ` > Just wondering. > > Charlie Millar > > > -- Nick "There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors." -Martin Fowler
