display-buffer-pop-up-frame causes many extra frames for capture
Hello all! I have been working to increase my frame use with emacs, and have taken the following from the manual: (custom-set-variables '(display-buffer-base-action '( (display-buffer-reuse-window display-buffer-pop-up-frame) (reusable-frames . 0) ) ) ) When used with org-capture, something surprising happens. At first, a new frame is popped up to show the capture template menu. So far, so good. However, after I hit a key to select a template instead of my new frame being replaced with one containing the template, instead I get 2 new frames (or it closes this one and makes 3 new -- I end up with 4 total including the original frame I ran org-capture from) one of the new frames contains the template result and the other contains `other-buffer` with the usual result that I am looking at 3 frames containing whatever I was working on and one frame containing the org capture template. I'm happy to make further customisations of my environment to avoid this, but it is very surprising to me so I wonder if anyone can guess what might be happening and give me some pointers about it? Thank you. signature.asc Description: PGP signature
Re: [O] error message at line break
Étienne Deparis writes: > > I confirm that I've the same variable set in my Emacs config file: > > (setq-default auto-fill-function 'do-auto-fill) > > Which I take from the Emacs Wiki AutoFill page¹, with the explanation > of: « If you would like to enable auto fill for all major modes, you can > add this single line to your configuration ». > > ¹ https://www.emacswiki.org/emacs/AutoFillMode > That is a weird way to turn on auto-fill mode and I would not be confident it is setting up the mode correctly. See the Emacs manual for the official way to do this using mode hooks. I don't think you want to turn on auto-fill mode in ALL modes. Some modes, you really don't want Emacs to modify buffer contents by filling. Typically, you only want this when your dealing with text (so text-mode hook is a popular choice for adding auto-fill-mode). I would also be wary of emacswiki advice. While there is some good advice there, there is some which is not very good and lots which is outdated/obsolete. This is the downside of wikis. Always try to verify the advice using the manual corresponding to your Emacs version. -- Tim Cross
Re: Can I "multi-include" a subtree?
to clarify. On 5/2/20, Samuel Wales wrote: > there are a bunch of existing sort-of solutions, but to me the best is > linking [as you mentioned], using org-id. although that only links to > entries, and it requires following links. one entry becomes > canonical. you have to set metadata for the linking node. i meant on the linked node, you set org-id in the properties drawer. on the linking node, if it is an org id link on a node, you ahve to set any metadata like todo kw. * [[id:9f4568cd-fdc8-4be3-86c0-98511e1d06a6][[2020-05-02 Sat 15:43] talked to jimmy carter]] -- needs metadata for good sorting and searching * CONV [2020-05-02 Sat 15:43] talked to jimmy carter :PROPERTIES: :ID: 9f4568cd-fdc8-4be3-86c0-98511e1d06a6 :END:
Re: Can I "multi-include" a subtree?
On May 2, 2020 1:57:02 p.m. PDT, Samuel Wales wrote: ... you could maybe color the one that is in the file itself differently, or keep all looking equal status to the user. In my situation it would certainly be fine to have only the canonical/original subtree editable, as long as any edits to it automatically propagated to the others. And the canonical/original one having a somewhat different appearance from the others is not an issue for me one way or the other. -- David
Re: Can I "multi-include" a subtree?
p.s. presumably the agenda would in some cases want to distinguish canonical [in the place whwere ther data will be saved] from non-canonical. also presumably a few traversing commands would want to recognize such regions in order tonot follow non-canonical, or to look for infinite looping, etc. presumably org-id is the best solution for keeping track of which files have or need virtual regions. basically an underneath layer of org-id [but maybe not limited to entries] that the user does not interact with. On 5/2/20, Samuel Wales wrote: > stating the obvious: org typically stores a forest [files] of trees of > nodes. some things you want to put into it are best expressed more > generally than with trees. i call it [boring name] the tree problem. > > there are a bunch of existing sort-of solutions, but to me the best is > linking [as you mentioned], using org-id. although that only links to > entries, and it requires following links. one entry becomes > canonical. you have to set metadata for the linking node. > > there are solutions not implemented that could be better that have > been talked about on the mailng list, but they still have the issues > of following links or other issues. > > duplication is out the window because dry. > > what you seem to want seems to require a feature in emacs in which you > have virtual includable regions. this can be done to a large degree > at the buffer level, but not at the region level. > > that would open up some interesting possibilities, maybe including > inline multi-mode stuff. and it would fix your problem. you could > maybe color the one that is in the file itself differently, or keep > all looking equal status to the user. > > i think there has been discussion on the mailing list and probalby on > emacs-devel recently about an idea similar to this. it migth be teh > same as what you want. not sure. > > it goes by a different name. smoevbody will chime in i hope. > > On 5/2/20, David Rogers wrote: >> Is there a method I can use to include the same subtree in several >> different >> files, such that editing one instance of that subtree updates the others >> automatically? I'm hoping to be able to view the full version of the >> subtree >> in each of the files, without having to follow a link; if what I'm >> describing isn't really possible, then I'll just use links in the other >> files to point to the original subtree, which I know how to do. I'm just >> exploring the sometimes-unexpected possibilities. :) >> >> -- >> Thanks >> David >> >> > > > -- > The Kafka Pandemic > > What is misopathy? > https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html > -- The Kafka Pandemic What is misopathy? https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: Can I "multi-include" a subtree?
stating the obvious: org typically stores a forest [files] of trees of nodes. some things you want to put into it are best expressed more generally than with trees. i call it [boring name] the tree problem. there are a bunch of existing sort-of solutions, but to me the best is linking [as you mentioned], using org-id. although that only links to entries, and it requires following links. one entry becomes canonical. you have to set metadata for the linking node. there are solutions not implemented that could be better that have been talked about on the mailng list, but they still have the issues of following links or other issues. duplication is out the window because dry. what you seem to want seems to require a feature in emacs in which you have virtual includable regions. this can be done to a large degree at the buffer level, but not at the region level. that would open up some interesting possibilities, maybe including inline multi-mode stuff. and it would fix your problem. you could maybe color the one that is in the file itself differently, or keep all looking equal status to the user. i think there has been discussion on the mailing list and probalby on emacs-devel recently about an idea similar to this. it migth be teh same as what you want. not sure. it goes by a different name. smoevbody will chime in i hope. On 5/2/20, David Rogers wrote: > Is there a method I can use to include the same subtree in several different > files, such that editing one instance of that subtree updates the others > automatically? I'm hoping to be able to view the full version of the subtree > in each of the files, without having to follow a link; if what I'm > describing isn't really possible, then I'll just use links in the other > files to point to the original subtree, which I know how to do. I'm just > exploring the sometimes-unexpected possibilities. :) > > -- > Thanks > David > > -- The Kafka Pandemic What is misopathy? https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: wip-cite status question and feedback
Nicolas Goaziou writes: > I think there are really two paths here: either we only support the > common denominator between all processors, like, e.g., Pandoc, or we > handle every possible command, knowing that most of them will not be > portable anyways. Yes, I think that is the core issue: which way to do we want to go here? My opinion has always been that it makes more sense to just support the common denominator at the level of Org citation syntax, for two reasons: (1) it makes implementing a good solution that will work for a lot of cases much more feasible, and (2) anyone who really needs more than the common denominator -- that is to say, anyone who needs BibLaTeX -- can already write arbitrary LaTeX snippets directly in an Org document. Thus the latter group doesn't really lose anything if the syntax only supports the common denominator, while everyone else has a lot to gain from an implementation of citation syntax that can be exported on other backends. On the other hand, this opinion is narrowly focused on the issue of how citation syntax can be rendered into citations when exporting a document. When I think about the other uses for the syntax that e.g. John Kitchin has talked about in this thread, and that something like a future org-ref could support, then I see that people who need to export citations as BibLaTeX *would* still be missing out if they couldn't use the citation syntax. So, I think it is good if the syntax can support advanced BibLaTeX users too, and it looks to me like the "cite/xxx" syntax can do that. I have no objections to the syntax you've proposed, Nicolas. I *do* think it's worth marking a clear distinction between citation syntax that can vs. cannot be expected to export correctly on non-LaTeX backends. It looks to me at the moment like that distinction will be expressed as the difference between "cite" and "cite/xxx". For me, that's a reason to make "cite/text" a special case and give it its own syntax, since this is such an important and widespread use case, and CSL supports it. But I don't feel that strongly about this. For me, it would be fine if it's mentioned as a special case in the manual. -- Best, Richard
Can I "multi-include" a subtree?
Is there a method I can use to include the same subtree in several different files, such that editing one instance of that subtree updates the others automatically? I'm hoping to be able to view the full version of the subtree in each of the files, without having to follow a link; if what I'm describing isn't really possible, then I'll just use links in the other files to point to the original subtree, which I know how to do. I'm just exploring the sometimes-unexpected possibilities. :) -- Thanks David
Re: TODO or checkboxes in org tables
>>> "AK" == Axel Kielhorn writes: Hi Alex, I am not sure my first answer made it, so I apologize for a possible crossposting. > Hi Uwe, >> I have an orgtable with a lot of useful information, I would like to add >> a column either for TODOS or checkboxes but it seems not work any idea >> whether such an addon package exist or any change that such a feature >> will be implemented? > I use a different approach. > I store the information in a normal org structure with TODO keywords. > I hide the checkboxes (and other meta information) in a drawer. I thought about this as well, but the table is an import form an excel documente and contains a row of 70 different persons, so to transform this to a normal org structure would require some work, I presume. In any case, thanks for you example I will try it out. > From this I generate a column view to present the information in a table. > You can generate different column views from the same data set. > I used the second version for years but recently discovered the :match argument. > If you mark the actual data as :noexport: only the table will be printed. A last question, which the command to generate the table org-insert-dblock:columnview ? Greetings Uwe smime.p7s Description: S/MIME cryptographic signature
Re: error message at line break
Hello, Étienne Deparis writes: > Debugger entered--Lisp error: (wrong-type-argument char-or-string-p nil) > insert-before-markers-and-inherit(nil) > org-comment-line-break-function(t) [...] > I confirm that I've the same variable set in my Emacs config file: > > (setq-default auto-fill-function 'do-auto-fill) > > Which I take from the Emacs Wiki AutoFill page¹, with the explanation > of: « If you would like to enable auto fill for all major modes, you can > add this single line to your configuration ». > > ¹ https://www.emacswiki.org/emacs/AutoFillMode This is a very bad (outdated ?) advice! With this, you force `do-auto-fill' function in every major mode, even if that function doesn't have a clue about what the major mode is about. Also this prevents the major mode from setting its own filling. Do you have any reason to do this? A correct way to activate auto fill in all text-based modes (including Org), is, for example, (add-hook 'text-mode-hook (lambda () (auto-fill-mode 1))) See (info "(emacs)Auto Fill") for more information. > To fix this, I simply replace the last line of > `org-comment-line-break-function' (in ./lisp/org.el, line 19723) from: > > (insert-before-markers-and-inherit fill-prefix) > > To > > (when fill-prefix > (insert-before-markers-and-inherit fill-prefix)) Well, the fix is cheap, sure, but, OTOH, the error is to be expected, since you force Org to use a function which is not adequate. I'm not sure we should paper over this kind of misuse of `auto-fill-function'. WDYT? Regards, -- Nicolas Goaziou
Re: wip-cite status question and feedback
Am 02.05.2020 um 18:34 schrieb Nicolas Goaziou: It seems you didn't copy the list. I add it again. No, I think that should be fine. (Perhaps also a fourth one for author-only. And what about nocite?) Sorry. I wasn't clear. There is still full support for styles behind the suggested syntax, e.g., [cite/author: ...], [cite/nocite: ...] (this one is odd). I was pointing out that we cover Citeproc needs, and more. Yeah, and I was pointing out that these might be necessary from a CSL/citeproc perspective. Author in text, the rest in a footnote. So it is not really a new style; you can have cite-text on top of any style. This might be a problem. Why? I can't follow you here... Either we invent an alternate syntax, with duplicated styles, e.g. [cite: ...] [cite/style: ...] [cite*: ...][cite*/style: ...] this was already suggested in this thread (with "citet"). Or we make use of sub-styles, e.g. [cite: ...] [cite/foot: ...] [cite/text: ...] [cite/foot/text: ...] This is ambiguous, tho: is it "cite/foot/text" or "cite/text/foot"? Of course, this is an issue for BibLaTeX only. AFAIU, [cite/text: ...] is totally unambiguous for Citeproc. What do Bib(La)TeX users think about it? I don't think it's a real problem. In CSL it's really clear. The CSL style defines the overall style, i.e.: cite => "Doe 2020" in parentheses or in a note cite/test => "Doe" in text, "2020" in parentheses or in a note. And I doubt it's a problem for biblatex: cite => autocite (or just cite, but I think autocite is a better choice) cite/text => textcite cite/foot => footcite I don't think duplicate styles or sub-styles are needed. Best, Denis
Re: [O] error message at line break
Hello, I allow myself to revive an old thread, as I encounter today the exact same problem: Emacs crash in org mode at line ending with the following backtrace: Debugger entered--Lisp error: (wrong-type-argument char-or-string-p nil) insert-before-markers-and-inherit(nil) org-comment-line-break-function(t) default-indent-new-line(t) do-auto-fill() internal-auto-fill() self-insert-command(1) org-self-insert-command(1) funcall-interactively(org-self-insert-command 1) call-interactively(org-self-insert-command nil nil) command-execute(org-self-insert-command) I confirm that I've the same variable set in my Emacs config file: (setq-default auto-fill-function 'do-auto-fill) Which I take from the Emacs Wiki AutoFill page¹, with the explanation of: « If you would like to enable auto fill for all major modes, you can add this single line to your configuration ». ¹ https://www.emacswiki.org/emacs/AutoFillMode To fix this, I simply replace the last line of `org-comment-line-break-function' (in ./lisp/org.el, line 19723) from: (insert-before-markers-and-inherit fill-prefix) To (when fill-prefix (insert-before-markers-and-inherit fill-prefix)) But I must admit I don't know all the implications of such a change. In my case, it does the job perfectly well, but maybe I miss something? I run make test and every thing goes fine too. I would like to suggest to fix the method `org-comment-line-break-function', in order to support user change of the variable auto-fill-function, as it seems to be a common thing. What do you think? Have a good week-end, Étienne >henry atting writes: > >> Nicolas Goaziou writes: >> >>> Hello, >>> >>> henry atting writes: >>> Okay, say I have an org file with two lines in it (fill-column is set to 70). Here you go: Jemand mußte Josef K. verleumdet haben, denn ohne daß er etwas Boeses getan haette, wurde er eines Morgens verhaftet. Die Koechin der Frau Then you go on with the text, which is: Grubach, seiner Zimmervermieterin, die ihm jeden Tag gegen acht Uhr frueh das Fruehstueck brachte,... At each automatic line skip I get the mentioned error message. But if you indent these two lines one space everything works fine. >>> >>> Strange, I still cannot reproduce it. >>> >> Strange, in deed. I can reproduce it even this way: >> >> 1. Start emacs with `emacs -Q' >> 2. Add my org directory to the load path >> 3. Load org-mode >> 4. Then type the above quoted beginning of Kafka's Prozess >> > >Finally... the culprit was: > >(setq-default auto-fill-function 'do-auto-fill) > >A very old setting in my ~/.emacs. Now that I start auto-fill with the >appropriate hook everythings works fine. > >henry
Re: wip-cite status question and feedback
It seems you didn't copy the list. I add it again. > No, I think that should be fine. (Perhaps also a fourth one for > author-only. And what about nocite?) Sorry. I wasn't clear. There is still full support for styles behind the suggested syntax, e.g., [cite/author: ...], [cite/nocite: ...] (this one is odd). I was pointing out that we cover Citeproc needs, and more. > Author in text, the rest in a footnote. So it is not really a new style; you can have cite-text on top of any style. This might be a problem. Either we invent an alternate syntax, with duplicated styles, e.g. [cite: ...] [cite/style: ...] [cite*: ...][cite*/style: ...] this was already suggested in this thread (with "citet"). Or we make use of sub-styles, e.g. [cite: ...] [cite/foot: ...] [cite/text: ...] [cite/foot/text: ...] This is ambiguous, tho: is it "cite/foot/text" or "cite/text/foot"? Of course, this is an issue for BibLaTeX only. AFAIU, [cite/text: ...] is totally unambiguous for Citeproc. What do Bib(La)TeX users think about it? > That doesn't exist in CSL. It could be useful though. It is odd that citeproc-el offers this, then. > citeproc-js handles pseudo-html, with pandoc-citeproc it's possible to > use markdown, but I think also raw HTML should be supported... It sounds good enough, then. Besides, i assume markup in prefix/suffix is not common. Thank you.
Re: wip-cite status question and feedback
Hello,
"Bruce D'Arcus" writes:
> So to sum up, I expect we will explicitly define three commands:
> default (the one defined in the citation template of the style),
> suppress-author (which need not be explicitly defined in the style,
> since the processor knows how to achieve this), and cite-text.
So, is there anything wrong with [cite:@key], [cite:-@key] and
[cite/text:@key] per above?
In particular, cite-text sounds like another non-default style to me,
rather than a derivative of the default style, and if it does, this
warrants introducing a "cite/text" syntax. E.g., what happens if default
style is footnote-like and cite-text is used?
Also, I've had a cursory look at "citeproc-el" implementation, and there
is apparent support for capitalized citations. You don't seem to talk
about this. If such a thing exists, we need to introduce another marker
at the cite key level (like suppress-author).
As a last, more technical point, I'm thinking about rendering citations
in a pre-export phase, where the processor is handled a list of all
citations as Org objects (so you can extract context about them, e.g.,
footnote label around it if applicable) where all prefixes and suffixes
are already in the target format.
More specifically, as an inaccurate but enough for the point example, in
the document
Go ahead, make my day [cite:@harry83 at *0:23:18*].
assuming target is LaTeX code, the processor would see something like.
((citation ... (citation-reference :key "harry83" :suffix " at
\bold{0:23:18}")))
In particular, does Citeproc handle raw LaTeX, or more generally, any
code in (pre|suf)fix, as long as the locator is accessible? I assume so,
but I'd rather ask.
Regards,
--
Nicolas Goaziou
Re: wip-cite status question and feedback
On Sat, May 2, 2020 at 9:13 AM Nicolas Goaziou wrote: > I suggested to support at least "cite", "cite/text" and "cite/paren", > but it sounds like "cite/paren" is not possible with Citeproc. This > doesn't matter much, we can limit the supported set to "cite" and > "cite/text" in Citeproc. Just to clarify here (hopefully I do; I know this is complicated), in author-date CSL styles, the default is effectively cite/paren. Here's the citation template layout for APA, for example: https://github.com/citation-style-language/styles/blob/master/apa.csl#L1672 Which means "(Doe, 2018)". Suppress-author and intext variants modify that default. Bruce
Re: Possible bug in subtree matching with empty title + tags
Hello, Christian Heinrich writes: > I'm often using empty header titles that only contain tags, such as > >> **:foo: > > In my case, this is sufficient (for instance for flashcards, where I never > have to actually have to > use the agenda etc.). However, since Nicolas's refactoring in > be31a0c4595a6d68b03b5cfbcbcdbf2cd76d2b7f empty titles seem to be prohibited. > In the above example, > using subtrees (C-/ m) on the "foo" tag will return nothing, even though the > tag is in the file. Is > this a deliberate change? I didn't see a note in the manual saying that > headings must not be empty > (this might be useful then). This is not totally about empty headings, which are fine in Org. Your example is ambiguous. Is it an empty headline with tags, or a headline titled ":foo:" with no tag? Since we cannot support both, choosing one breaks support for the other. You could use, e.g., a NO-BREAK SPACE character in your headline and lift the ambiguity. This is not a change, but rather and undefined corner-case. There was a discussion about it a couple of years ago, IIRC. I don't remember what the outcome was. Regards, -- Nicolas Goaziou
Re: wip-cite status question and feedback
Hello, Richard Lawrence writes: > If so, then I think Nicolas' proposal to have "cite" mean default and > make non-default citations available as "cite/xxx" makes sense > (especially with the other syntax supporting suppress-author, etc.). > > If not, then the "cite/xxx" syntax makes less sense to me; it just sort > of looks like a different way of writing BibLaTeX commands, and will be > hard to support when LaTeX is not the output format. I would be hesitant > in that case to make "cite/xxx" the standard way to express "this > citation should be rendered in manner xxx, instead of the default". Note that I only followed as many requests from participants to this thread as possible. Anyway, I'm a bit lost here. The point to the syntax is to support Citeproc as well as Bib(La)TeX and Org Ref, so it has to deal with both processors using a limited set of cite commands, and processors with an awful lot of cite commands. On top of that, some users requested name spaces for custom commands, which only makes sense in Bib(La)TeX context, IIUC. So, there we are. I suggested to support at least "cite", "cite/text" and "cite/paren", but it sounds like "cite/paren" is not possible with Citeproc. This doesn't matter much, we can limit the supported set to "cite" and "cite/text" in Citeproc. I think there are really two paths here: either we only support the common denominator between all processors, like, e.g., Pandoc, or we handle every possible command, knowing that most of them will not be portable anyways. WDYT? Regards, -- Nicolas Goaziou
Possible bug in subtree matching with empty title + tags
Hi, I'm often using empty header titles that only contain tags, such as > **:foo: In my case, this is sufficient (for instance for flashcards, where I never have to actually have to use the agenda etc.). However, since Nicolas's refactoring in be31a0c4595a6d68b03b5cfbcbcdbf2cd76d2b7f empty titles seem to be prohibited. In the above example, using subtrees (C-/ m) on the "foo" tag will return nothing, even though the tag is in the file. Is this a deliberate change? I didn't see a note in the manual saying that headings must not be empty (this might be useful then). Thanks for your help guys! Cheers Christian signature.asc Description: This is a digitally signed message part
Re: wip-cite status question and feedback
On Sat, May 2, 2020 at 5:51 AM Nicolas Goaziou wrote: ... > > Does that mean you'll be able to have the same or different processors > > for different backends? (Like biblatex for latex and citeproc-el for > > ODT/HTML/etc.; or when you need identical output you can use > > citeproc-el even for latex?) > > With the suggested set-up, you associate a single processor to each > export back-end. The same processor can be associated to multiple export > back-ends. > > Moreover, you can change this association globally, or per document. > > Is that sufficient? To my mind, it's perfect. Bruce
Re: How to properly set up reminders for paying cellphone fees in org?
On 2020-05-02, at 10:12, to...@tuxteam.de wrote: > On Sat, May 02, 2020 at 09:37:40AM +0200, Marcin Borkowski wrote: >> >> On 2020-04-30, at 07:02, Kyle Meyer wrote: >> >> > And note that a utility like datefudge or libfaketime is useful for >> > testing these sorts of things out. For example: >> > >> > $ datefudge "2020-02-18" emacs [...] >> >> Shameless plug: I wrote about this use-case of datefudge sime time ago: >> http://mbork.pl/2019-08-05_datefudge_and_agenda_testing >> >> (I don't know libfaketime). > > It just plays games with LD_PRELOAD to trick the application (which is > supposed to use the usual libs when asking for time, but most do that). > > Infinitely more lightweight than a container or a VM. On Debian: > > tomas@trotzki:~$ apt show libfaketime > Package: libfaketime > [...] > Download-Size: 31.2 kB > APT-Sources: http://ftp.de.debian.org/debian buster/main amd64 Packages > Description: Report faked system time to programs (preload library) >The Fake Time Preload Library (FTPL, a.k.a. libfaketime) intercepts >various system calls which programs use to retrieve the current date >and time [...] FTPL allows you to specify both absolute dates (e.g., >2004-01-01) and relative dates (e.g., 10 days ago). > > You might need a VM for an app which bypasses the "usual libraries", > but then, I don't know whether I would like to have such a thing on > my box. Probably not without a good reason :-) One use-case when this might be reasonable is an application which talks to a database, when you have to convince both the application and the database server that the time is different than in reality. Best, -- Marcin Borkowski http://mbork.pl
[idea] Dynamic agenda filtering
Hi,
These are a few lines of experimental code to bring dynamic filtering to
the agenda. I think it's not too bad already.
I'd like to invite you to check it out. Just mark the code and do
{M-x eval-region RET}. Then you have the "dynamic filtering" on key "&"
in the agenda. Just type to see the effect.
BTW recall key "|" to remove all filters.
#+begin_src emacs-lisp
(defun org-agenda-dynamic-filter-minibuffer-contents ()
"Return the contents of the minibuffer when it is active."
(when (active-minibuffer-window)
(with-current-buffer (window-buffer (active-minibuffer-window))
(minibuffer-contents
(defun org-agenda-dynamic-filter-update-regexp ()
(with-current-buffer "*Org Agenda*"
(org-agenda-remove-filter 'regexp))
(setq org-agenda-regexp-filter
(if (string= "" (org-agenda-dynamic-filter-minibuffer-contents))
nil
(list (concat "+" (org-agenda-dynamic-filter-minibuffer-contents)
(with-current-buffer "*Org Agenda*"
(cl-flet ((recenter ( arg redisplay) nil))
(org-agenda-finalize
(defun org-agenda-dynamic-filter-regexp-read ()
"Read string with PROMPT and display results dynamically.
See also `org-agenda-filter-by-regexp'."
(interactive)
(unwind-protect
(catch 'click
(add-hook 'post-command-hook #'org-agenda-dynamic-filter-update-regexp)
(read-string "Regexp: "))
(remove-hook 'post-command-hook #'org-agenda-dynamic-filter-update-regexp)))
(org-defkey org-agenda-mode-map "&" #'org-agenda-dynamic-filter-regexp-read)
#+end_src
As always comments and all are very much appreciated. Possibly this can be
developed into something useful.
BTW for the implementation I glanced at the--in my opinion very
nice--org-velocity.el .
Ciao,
--
Marco
Re: wip-cite status question and feedback
Hello, Thank you for the feedback. Denis Maier writes: > What about using quotes if someone needs this, like so [cite: "common > prefix; still common prefix"; pre @key post; pre @key2 post; common > suffix] ? Then we would have to find a way to escape the quote… > Does that mean you'll be able to have the same or different processors > for different backends? (Like biblatex for latex and citeproc-el for > ODT/HTML/etc.; or when you need identical output you can use > citeproc-el even for latex?) With the suggested set-up, you associate a single processor to each export back-end. The same processor can be associated to multiple export back-ends. Moreover, you can change this association globally, or per document. Is that sufficient? Regards, -- Nicolas Goaziou
Re: [ANN] faster org-table-to-lisp
Hello, tbanelwebmin writes: > There is a last cleanup that can be achieved > (or not, doesn't really matter): > simplifying two calls located in org-table.el: > > (org-table-to-lisp > (buffer-substring-no-properties (org-table-begin) (org-table-end))) > > to: > > (org-table-to-lisp) Indeed. Done. Thank you. Regards, -- Nicolas Goaziou
Re: TODO or checkboxes in org tables
Hi Uwe,
> I have an orgtable with a lot of useful information, I would like to add
> a column either for TODOS or checkboxes but it seems not work any idea
> whether such an addon package exist or any change that such a feature
> will be implemented?
I use a different approach.
I store the information in a normal org structure with TODO keywords.
I hide the checkboxes (and other meta information) in a drawer.
From this I generate a column view to present the information in a table.
You can generate different column views from the same data set.
I used the second version for years but recently discovered the :match argument.
If you mark the actual data as :noexport: only the table will be printed.
Greetings
Axel
** Arbeitsfortschritt
:PROPERTIES:
:EXPORT_FILE_NAME: Beispiele
:EXPORT_OPTIONS: num:nil
:COLUMNS: %50ITEM(Problem) %5PB(Nr BP) %11TODO(Status) %6TAGS(Wer)
%10TERMIN(Termin) %7ERLEDIGT(Erledigt){X/} %6SICHERHEIT(Sicher){X/}
:ID: Aufgaben
:END:
*** 2017-10-19 [5/7]
CAD nachpflegen Lasertaster :BKI:
:PROPERTIES:
:TERMIN:
:PB: 1
:ERLEDIGT: [ ]
:END:
DONE Ventilinsel:BKI:
:PROPERTIES:
:ERLMON: [X]
:PB: 2
:ERLEDIGT: [X]
:END:
- Kollision mit Verkleidung prüfen
DONE Schaltschrank
CLOSED: [2017-11-22 Mi 11:52]
:PROPERTIES:
:PB: 3
:ERLEDIGT: [X]
:TERMIN: 2017-12-05
:END:
DONE Schutzverkleidung
CLOSED: [2017-10-20 Fr 09:29]
:PROPERTIES:
:PB: 4
:ERLEDIGT: [X]
:TERMIN: 2017-11-03
:SICHERHEIT: [ ]
:END:
Projektleiter Bodenverankerung (Bohrtiefe) :PL:
:PROPERTIES:
:PB: 5
:ERLEDIGT: [ ]
:END:
- Befestigung kundenseitig
DONE Wartungseinheit
CLOSED: [2017-11-02 Do 07:54]
:PROPERTIES:
:PB: 6
:ERLEDIGT: [X]
:END:
- Luftzuführung
- zusätzlicher Verteiler für gesicherte Luft
- Rejekt und Stopper mit Einzelventilen
DONE Roboter Vakuumerzeuger
CLOSED: [2018-01-16 Di 13:33]
:PROPERTIES:
:PB: 7
:ERLEDIGT: [X]
:END:
- Bohrung in Rahmen fertig
- Blechteil fehlt noch
*** Aushang Arbeitsfortschritt
#+BEGIN: columnview :hlines 1 :id "Aufgaben" :indent t :match "/-DONE" :format
"%50ITEM(Problem) %5PB(Nr) %12TODO %8TAGS(Wer) %12Termin"
#+attr_latex: :align p{3.5cm}rlll
| Problem | Nr | TODO| Wer | Termin |
|--++-+---+|
| \_ Arbeitsfortschritt || | ||
| \_2017-10-19 || | ||
| \_ Lasertaster | 1 | CAD nachpflegen | :BKI: ||
| \_ Bodenverankerung (Bohrtiefe) | 5 | Projektleiter | :PL: ||
| \_Aushang Arbeitsfortschritt || | ||
#+END
*** Aushang Arbeitsfortschritt (alt)
#+BEGIN: columnview :hlines 1 :id "Aufgaben" :indent t :format
"%50ITEM(Problem) %5PB(Nr) %12TODO %8TAGS(Wer) %12Termin
%7ERLEDIGT(Erledigt){X/}"
| Problem | Nr | TODO| Wer |
Termin | Erledigt |
|--++-+---++--|
| \_ Arbeitsfortschritt || | |
| [0/1]|
| \_2017-10-19 || | |
| [5/7]|
| \_ Lasertaster | 1 | CAD nachpflegen | :BKI: |
| [ ] |
| \_ Ventilinsel | 2 | DONE| :BKI: |
| [X] |
| \_ Schaltschrank| 3 | DONE| |
2017-12-05 | [X] |
| \_ Schutzverkleidung| 4 | DONE| |
2017-11-03 | [X] |
| \_ Bodenverankerung (Bohrtiefe) | 5 | Projektleiter | :PL: |
| [ ] |
| \_ Wartungseinheit | 6 | DONE| |
| [X] |
| \_ Roboter Vakuumerzeuger | 7 | DONE| |
| [X] |
| \_Aushang Arbeitsfortschritt || | |
| |
#+END
Re: How to properly set up reminders for paying cellphone fees in org?
On Sat, May 02, 2020 at 09:37:40AM +0200, Marcin Borkowski wrote: > > On 2020-04-30, at 07:02, Kyle Meyer wrote: > > > And note that a utility like datefudge or libfaketime is useful for > > testing these sorts of things out. For example: > > > > $ datefudge "2020-02-18" emacs [...] > > Shameless plug: I wrote about this use-case of datefudge sime time ago: > http://mbork.pl/2019-08-05_datefudge_and_agenda_testing > > (I don't know libfaketime). It just plays games with LD_PRELOAD to trick the application (which is supposed to use the usual libs when asking for time, but most do that). Infinitely more lightweight than a container or a VM. On Debian: tomas@trotzki:~$ apt show libfaketime Package: libfaketime [...] Download-Size: 31.2 kB APT-Sources: http://ftp.de.debian.org/debian buster/main amd64 Packages Description: Report faked system time to programs (preload library) The Fake Time Preload Library (FTPL, a.k.a. libfaketime) intercepts various system calls which programs use to retrieve the current date and time [...] FTPL allows you to specify both absolute dates (e.g., 2004-01-01) and relative dates (e.g., 10 days ago). You might need a VM for an app which bypasses the "usual libraries", but then, I don't know whether I would like to have such a thing on my box. Probably not without a good reason :-) Cheers -- t signature.asc Description: Digital signature
Re: [ANN] faster org-table-to-lisp
Le 01/05/2020 à 15:11, Nicolas Goaziou a écrit : > Indeed. I also realized this, and fixed it a couple of hours ago. You > will notice I shamelessly used your "\\="© trick! :) This kind of shamelessness builds great communities :) > Great. I removed the check and added an entry in ORG-NEWS. It shouldn't > make any speed difference in your monster table, because it is located > right after a headline. It will, however, help tremendously in tables > buried deep within a section. Well done. There is a last cleanup that can be achieved (or not, doesn't really matter): simplifying two calls located in org-table.el: (org-table-to-lisp (buffer-substring-no-properties (org-table-begin) (org-table-end))) to: (org-table-to-lisp)
Re: How to properly set up reminders for paying cellphone fees in org?
On 2020-04-30, at 07:02, Kyle Meyer wrote: > And note that a utility like datefudge or libfaketime is useful for > testing these sorts of things out. For example: > > $ datefudge "2020-02-18" emacs [...] Shameless plug: I wrote about this use-case of datefudge sime time ago: http://mbork.pl/2019-08-05_datefudge_and_agenda_testing (I don't know libfaketime). Another way of testing that is using a VM or perhaps docker to run Emacs in an environment where you set up the system clock to whatever you want. Best, -- Marcin Borkowski http://mbork.pl
