Re: [O] [ANN] org-info-find-node: Jump from Org to specific Info
Hello, Marco Wahl writes: > I just pushed command `org-info-find-node' bound to "C-c C-x I" by > default for Org files and agenda buffers. Nitpick: Would you mind removing the dangling parens left in the function? Also, I'd like to avoid making changes to "master" branch. It should be considered frozen while we're waiting for Org 9.2. Please install next new features (that one is OK, I guess) in "next" branch, and rebase it on top of "master". Thank you! Regards, -- Nicolas Goaziou
Re: [O] ox-hugo-like "DWIM" cope for other exporters?
Hello, Kaushal Modi writes: > @Nicolas: If this another scope can be baked into the existing exporters in > Org source, I can get working on it. Sure, go ahead. Don't forget the tests :) Regards, -- Nicolas Goaziou
Re: [O] Bug: org-insert-structure-template leaves point at inconvenient place [9.1.14 (9.1.14-932-gf82a30-elpaplus @ .emacs.d/elpa/org-plus-contrib-20180923/)]
Hello, Allen Li writes: > That's very interesting. Perhaps this is too invasive, but maybe C-c > C-, should do C-c ' automatically? No, it shouldn't. You can also create non-verbatim blocks, e.g. "center" with C-c C-,. There C-c ' doesn't do anything useful. Regards, -- Nicolas Goaziou
Re: [O] Bug: org-insert-structure-template leaves point at inconvenient place [9.1.14 (9.1.14-932-gf82a30-elpaplus @ .emacs.d/elpa/org-plus-contrib-20180923/)]
On Tue, Oct 2, 2018 at 2:14 PM Bernt Hansen wrote: > > Nicolas Goaziou writes: > > > Hello, > > > > Allen Li writes: > > > >> org-insert-structure-template (C-c C-,) leaves point at an inconvenient > >> place (X marks the spot): > >> > >> #+begin_example > >> X#+end_example > >> > >> My expectation is that right after inserting the template, I can start > >> typing or yank right into it: > >> > >> #+begin_example > >> X > >> #+end_example > > > > Use `C-o'. > > > > I think the current behaviour is better because you can yank text within > > the newly created block without dealing with a blank line later on. > > I also prefer the current behaviour. > > I regularly use C-c C-, e C-c ' C-y C-c ' > > to create and populate my example blocks. This handles the newline > correctly and does not break the syntax. This also has the benefit of > properly escaping text that interferes with org's syntax. That's very interesting. Perhaps this is too invasive, but maybe C-c C-, should do C-c ' automatically? Since the user almost certainly wants to populate the block immediately, this saves the user a step, and also handles characters to escape and a missing final newline correctly. > > When you have text in the kill buffer that looks like org headlines it > pastes outside the example block -- which is proper behaviour when > moving headlines around. > > try this: > > C-c C-, e C-y > with the following your yank buffer > > > *** one > some text > *** two > more text > > > You can't paste that inside > > #begin_example > #end_example > > or > > #begin_example > > #end_example > > Regards, > Bernt
[O] bug#32906: org-in-src-block-p always returns nil
I thought I had updated emacs to the latest version, but apparently not. After upgrading to emacs-26 the command org-in-src-block-p works as expected. Thanks! Best, Eivind On Tue, Oct 2, 2018 at 10:30 AM Robert Pluim wrote: > Eivind Otto Hjelle writes: > > > The function 'org-in-src-block-p' always returns nil on my system > > running Windows 10. > > > > How to reproduce this bug starting from 'emacs -Q': > > Define a function 'test-org-in-src-block-p' in the scratch buffer as > > follows: > > > > (defun test-org-in-src-block-p () > > (interactive) > > (print (org-in-src-block-p))) > > > > Navigate to a src block in org mode and call 'M-x > > test-org-in-src-block-p'. Now nil is printed to the message buffer. > > Works for me in emacs-26. Would it be possible to try that version? > > Regards > > Robert >
Re: [O] ox-hugo-like "DWIM" cope for other exporters?
On Sat, Sep 29, 2018 at 8:23 PM Thomas S. Dye wrote: > Aloha Matt, > > I've often wished LaTeX export had this capability. I'd certainly be > happy if this were a feature of all the exporters. > Hello Tom, Matt, I can work on a DWIM scope that's generic. For ox-hugo, the criteria for the start of export scope is simple: EXPORT_FILE_NAME must not be "". I believe this should apply to other exporter backends too. (I needed, that criteria can be made configurable too). @Nicolas: If this another scope can be baked into the existing exporters in Org source, I can get working on it.
[O] bug#32906: org-in-src-block-p always returns nil
> From: Eivind Otto Hjelle > Date: Tue, 2 Oct 2018 09:22:56 -0500 > > The function 'org-in-src-block-p' always returns nil on my system > running Windows 10. > > How to reproduce this bug starting from 'emacs -Q': > Define a function 'test-org-in-src-block-p' in the scratch buffer as > follows: > > (defun test-org-in-src-block-p () > (interactive) > (print (org-in-src-block-p))) > > Navigate to a src block in org mode and call 'M-x > test-org-in-src-block-p'. Now nil is printed to the message buffer. > > I should mention that on my other system running a Linux distribution I > do not have this problem. Please show a short Org file where this function returns nil on Windows, but non-nil on GNU/Linux. (Are you testing this in the same Emacs version on both systems, btw?) > I know that this bug was also reported by Ryan > on 07 Aug 2014, as his bug report is still in the org mailing list > archives. Ryan's bug report can be found here: > > https://lists.gnu.org/archive/html/emacs-orgmode/2014-08/msg00305.html I don't see any bug there, just explanations why Ryan's implementation was wrong. > > In GNU Emacs 25.3.1 (x86_64-w64-mingw32) > of 2017-09-12 built on KAEL > Windowing system distributor 'Microsoft Corp.', version 10.0.17134 Are you using the version of Org that came with this version of Emacs? Or are you using a different version?
[O] bug#32906: org-in-src-block-p always returns nil
Eivind Otto Hjelle writes: > The function 'org-in-src-block-p' always returns nil on my system > running Windows 10. > > How to reproduce this bug starting from 'emacs -Q': > Define a function 'test-org-in-src-block-p' in the scratch buffer as > follows: > > (defun test-org-in-src-block-p () > (interactive) > (print (org-in-src-block-p))) > > Navigate to a src block in org mode and call 'M-x > test-org-in-src-block-p'. Now nil is printed to the message buffer. Works for me in emacs-26. Would it be possible to try that version? Regards Robert
[O] [ANN] org-info-find-node: Jump from Org to specific Info
Hi, I just pushed command `org-info-find-node' bound to "C-c C-x I" by default for Org files and agenda buffers. `org-info-find-node' opens the Info section that deals with the Org context at point. For the cases I could not find a suitable Info section `org-info-find-node' opens the top level Info section of Org. This function emerged from a similar feature in the gnus package. Ciao, -- Marco
Re: [O] Bug: org-insert-structure-template leaves point at inconvenient place [9.1.14 (9.1.14-932-gf82a30-elpaplus @ .emacs.d/elpa/org-plus-contrib-20180923/)]
Nicolas Goaziou writes: > Hello, > > Allen Li writes: > >> org-insert-structure-template (C-c C-,) leaves point at an inconvenient >> place (X marks the spot): >> >> #+begin_example >> X#+end_example >> >> My expectation is that right after inserting the template, I can start >> typing or yank right into it: >> >> #+begin_example >> X >> #+end_example > > Use `C-o'. > > I think the current behaviour is better because you can yank text within > the newly created block without dealing with a blank line later on. I also prefer the current behaviour. I regularly use C-c C-, e C-c ' C-y C-c ' to create and populate my example blocks. This handles the newline correctly and does not break the syntax. This also has the benefit of properly escaping text that interferes with org's syntax. When you have text in the kill buffer that looks like org headlines it pastes outside the example block -- which is proper behaviour when moving headlines around. try this: C-c C-, e C-y with the following your yank buffer *** one some text *** two more text You can't paste that inside #begin_example #end_example or #begin_example #end_example Regards, Bernt
Re: [O] Bug: org-insert-structure-template leaves point at inconvenient place [9.1.14 (9.1.14-932-gf82a30-elpaplus @ .emacs.d/elpa/org-plus-contrib-20180923/)]
On Tue, Oct 2, 2018 at 8:06 AM Nicolas Goaziou wrote: > > Hello, > > Allen Li writes: > > > org-insert-structure-template (C-c C-,) leaves point at an inconvenient > > place (X marks the spot): > > > > #+begin_example > > X#+end_example > > > > My expectation is that right after inserting the template, I can start > > typing or yank right into it: > > > > #+begin_example > > X > > #+end_example > > Use `C-o'. > > I think the current behaviour is better because you can yank text within > the newly created block without dealing with a blank line later on. But it works less well when you yank text that doesn't have a trailing newline. Either you need to press C-o in one case, or DEL/backspace in the other (to get rid of the extra blank line). I guess I don't have a huge preference, but the current behavior is annoying because it's the opposite of the old template behavior (e.g. < s TAB). One advantage that I can think of is that an extra newline is an annoyance but otherwise harmless, whereas missing a newline messes up the syntax. #+begin_example yanked text #+end_example #+begin_example yanked text#+end_example > > Regards, > > -- > Nicolas Goaziou
Re: [O] Bug: org-insert-structure-template leaves point at inconvenient place [9.1.14 (9.1.14-932-gf82a30-elpaplus @ .emacs.d/elpa/org-plus-contrib-20180923/)]
Hello, Allen Li writes: > org-insert-structure-template (C-c C-,) leaves point at an inconvenient > place (X marks the spot): > > #+begin_example > X#+end_example > > My expectation is that right after inserting the template, I can start > typing or yank right into it: > > #+begin_example > X > #+end_example Use `C-o'. I think the current behaviour is better because you can yank text within the newly created block without dealing with a blank line later on. Regards, -- Nicolas Goaziou
Re: [O] How about lifting the limit of 35 tasks in org-clock-history?
On 2018-09-06, at 16:18, Nicolas Goaziou wrote: > Hello, > > Marcin Borkowski writes: > >> I decided to put a warning about this in the docstring in my patch. My >> assumption was that this is enough. If a user wants to change the >> default, he will most probably see the docstring and will have to >> actively ignore the warning. > > I don't think this is enough. As you put it, it instills doubt without > explaining anything. Why 35? Why "may not work"? What "may not work"? Agreed. I attach a patch with a more verbose docstring. It is perhaps still not ideal - in particular, the warning is not visible in the Customize interface - but I do not think this is a big deal. My line of thinking is that: - if a user wants to change this setting, they will either look up the docstring and understand the limitation (btw, even the built-in way works for org-clock-history-length as high as 76 or so, provided you have a really high frame), or - use Customize, which is potentially a trouble - but in that case, I would assume that the user fiddles with org-clock-history-length because they clock in many tasks, and then they will see that the list in the *Clock Task Select* buffer is too long anyway, and dial the setting down. An alternative could be to change the hard-coded 35 in the code into yet another variable, say, org-clock-history-max-length, and set it to 35. Still, if a user wants to increase org-clock-history-length beyond 35 (or whatever this could be changed to), it is IMHO the /current/ behavior which is really confusing, and introducing a cap on the cap would only make things worse. WDYT? -- Marcin Borkowski http://mbork.pl >From bd5c4b7f3afe6a906b91e7f0bd33e2842fcf8656 Mon Sep 17 00:00:00 2001 From: Marcin Borkowski Date: Fri, 31 Aug 2018 07:53:42 +0200 Subject: [PATCH] Lift the artificial limit on the clock history length. The default limit of 35 was hard-coded, and was especially annoying when using an alternative way of selecting from history, e.g. https://github.com/unhammer/org-mru-clock. --- lisp/org-clock.el | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/lisp/org-clock.el b/lisp/org-clock.el index 9819fcff2..71ed99f69 100644 --- a/lisp/org-clock.el +++ b/lisp/org-clock.el @@ -156,7 +156,10 @@ state to switch it to." (symbol :tag "Function"))) (defcustom org-clock-history-length 5 - "Number of clock tasks to remember in history." + "Number of clock tasks to remember in history. +Clocking in using history works best if this is at most 35, in +which case all digits and capital letters are used up by the +*Clock Task Select* buffer." :group 'org-clock :type 'integer) @@ -534,7 +537,7 @@ cannot be translated." (defun org-clock-history-push ( pos buffer) "Push a marker to the clock history." - (setq org-clock-history-length (max 1 (min 35 org-clock-history-length))) + (setq org-clock-history-length (max 1 org-clock-history-length)) (let ((m (move-marker (make-marker) (or pos (point)) (org-base-buffer (or buffer (current-buffer) -- 2.19.0
