Re: Why not org-tempo insert upcased strings?

[Kyle Meyer]

tsuucat  writes:

>> Yes, the convention is now to have downcased keywords. 
> Thanks. Is the convention documented?
>
> https://orgmode.org/manual/Structure-Templates.html#Structure-Templates 
> 
> It doesn’t seems that The Org Manual uses such a convention.

While the manual doesn't recommend which you should prefer (I don't
think), it does provide a rationale for its use of uppercase:

(info "(org)Conventions")

Re: Why not org-tempo insert upcased strings?

[tsuucat]

> Yes, the convention is now to have downcased keywords. 
Thanks. Is the convention documented?

https://orgmode.org/manual/Structure-Templates.html#Structure-Templates 

It doesn’t seems that The Org Manual uses such a convention.

--
tsuucat

Re: how to get an org-link to open a program in eshell

[Kyle Meyer]

Joseph Vidal-Rosset  writes:

> I'm trying to get something via an org-link. I suspect that it is
> possible, but the documentation is not clear enough for me to get it.
>
> I want to make an org-link that get me directly in eshell a program,
> and if it is possible to do it, I will bookmark this org-link.

What have you tried?  Have you looked at ol-eshell.el?

> To explain precisely what I want to do: I have an executable in
> /usr/local/bin that I  have called SMinlog , in a shell, the command
> SMinlog -p -i open directly the following output:
> SEQUENT:
> and in the my Linux desktop xfce I have also an icon that is a
> shortcut to open directly this program in a xfce4-terminal.

IIUC what you want boils down to having an eshell link that runs a
command.  I don't use ol-eshell myself, but, taking a quick look, this
seems to be possible.  For example, say I have a link like

[[eshell:*eshell*:echo hello]]

Following that gives me

Welcome to the Emacs shell

/tmp $ echo hello
hello
/tmp $ 

Re: Debugging at least 2 regressions in org-mode master breaking ox-hugo

[Kyle Meyer]

Daniel Kraus  writes:

> Just want to say that I'm (like everyone else who uses the Emacs 
> `native-comp` branch
> with org-mode from master) are also affected by this and
> would appreciate if this can be merged.

I'll plan to bring that commit into master tomorrow.  We can
reevaluate/rework the change if needed when Bastien is back in action.

Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

[stardiviner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Nicolas Goaziou  writes:

> Hello,
>
> Ihor Radchenko  writes:
>
>> To my surprise, the patch did not break org to unusable state and
>> the performance on the sample org file [3] improved drastically. You can
>> try by yourself!
>
> It is not a surprise, really. Text properties are much faster than
> overlays, and very close to them features-wise. They are a bit more
> complex to handle, however.
>
>> However, this did introduce some visual glitches with drawer display.
>> Though drawers can still be folded/unfolded with , they are not
>> folded on org-mode startup for some reason (can be fixed by running
>> (org-cycle-hide-drawers 'all)). Also, some drawers (or parts of drawers)
>> are unfolded for no apparent reason sometimes. A blind guess is that it
>> is something to do with lack of 'isearch-open-invisible, which I am not
>> sure how to set via text properties.
>
> You cannot. You may however mimic it with `cursor-sensor-functions' text
> property. These assume Cursor Sensor minor mode is active, tho.
> I haven't tested it, but I assume it would slow down text properties
> a bit, too, but hopefully not as much as overlays.
>
> Note there are clear advantages using text properties. For example, when
> you move contents around, text properties are preserved. So there's no
> more need for the `org-cycle-hide-drawer' dance, i.e., it is not
> necessary anymore to re-hide drawers.
>
>> Any thoughts about the use of text properties or about the patch
>> suggestion are welcome.  
>
> Missing `isearch-open-invisible' is a deal breaker, IMO. It may be worth
> experimenting with `cursor-sensor-functions'.
>
> We could also use text properties for property drawers, and overlays for
> regular ones. This might give us a reasonable speed-up with an
> acceptable feature trade-off.

That's great, making Org Mode faster will be great. (Even thought I have not
found big performance problem on Org Mode yet.) I like Thor's try.

This indeed is is an acceptable feature trade-off, if only related to
`isearch-open-invisible'.

>
> Anyway, the real fix should come from Emacs itself. There are ways to
> make overlays faster. These ways have already been discussed on the
> Emacs devel mailing list, but no one implemented them. It is a bit sad
> that we have to find workarounds for that.
>
> Regards,


- -- 
[ stardiviner ]
   I try to make every word tell the meaning what I want to express.

   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner, Matrix: stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
  
-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl6jhG0UHG51bWJjaGls
ZEBnbWFpbC5jb20ACgkQG13xyVromsPHDAf+OVnhOq5H5MYm1/RK+9xSzwAT6qc8
ajSNVNzI31q6CIesvO65GoiZ3Rpaiq/O31B9JQ1mTyXvyX81tFecKrDpsrqIc/bR
Xo3Z4dCXzCbRKD1861t4tcphtPBk+rABpl83YpXafYNDKHnp2MuWSheV0ogF7LYd
6HWCl9D351onGAHGcebXEUTvvDiqLGx5qVnrpjomH00uCj5RoSI4cpdzXydBcIYY
B6lDvsat8AHhvbPXqJc4PHOd4hPtNVehWyPfOGaAXhp/pS0y+c4cJMbHjXCwFCkj
r8bUfdK+ZyMubNiboNI9xO8EwINvZLl+C5Lt5siYs/v2mrt1+UiVrxYWTw==
=dnH4
-END PGP SIGNATURE-

Bug: lisp error on user error [9.3.6 (9.3.6-43-gc77edd-elpa @ /home/minshall/.emacs.d/elpa/org-20200413/)]

[Greg Minshall]

hi.  the following example should possibly result in an error message,
but actually causes a lisp error/backtrace.  i have a code block with
":results vertatim :colnames yes", and am returning a simple character
string (so, no headers -- tsk, tsk, a user error).  this happens with
'emacs -Q'.  if either the ":results verbatim" or the ":colnames yes" is
left out, i get no error.  below is a sample file.  cheers.

Emacs  : GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.10)
 of 2019-08-29
Package: Org mode version 9.3.6 (9.3.6-43-gc77edd-elpa @ 
/home/minshall/.emacs.d/elpa/org-20200413/)


evaluating the R code block gives an error in lisp code

#+name: getRenabled
#+BEGIN_SRC elisp
  (progn
(setq debug-on-error t)
(org-babel-do-load-languages
 'org-babel-load-languages
 '((R . t)))
1)
#+END_SRC

#+begin_src R :var first=getRenabled :results verbatim :colnames yes
"that"
#+end_src

Re: small patch for ox-bibtex.el in contrib

[Nicolas Goaziou]

Hello,

Eric S Fraga  writes:

> the contrib package ox-bibtex.el has a function for jumping to a
> specific bibtex citation key.  The current regex assumes a particular
> indentation style (leading spaces) and only one space between the
> CUSTOM_ID key and the value of that key.  This small patch (hopefully)
> generalizes the search regex.
>
> I've done only some simple testing but seems to work for my
> configuration.

Thank you. I eventually pushed a different fix as I noticed other issues
in the code. Could you confirm it still solves your problem?

Regards,

-- 
Nicolas Goaziou

Re: [RFC] DOCT: Declarative Org Capture Templates

[No Wayman]

Nicolas Goaziou  writes:


Hello,

No Wayman  writes:


* [RFC] DOCT: Declarative Org Capture Templates


Thank you for your work.


Thank you for taking the time to respond.

Disclaimer: I am only using very basic capture templates. So, I 
cannot
comment realistically on the new syntax you suggest. In 
particular, the
example you give is way too complex for me to understand the 
benefits of
your syntax. I suggest to start out with showing simple 
use-cases.


Apologies, it's hard to strike a balance between showing something 
practical and over-writing.


- Is it compatible with the current syntax? If it isn't, is 
there a way

  to ease transition to the new syntax?


My package translates DOCT's syntax into the current syntax.
I have written a separate package that does basic translation from 
the current syntax to DOCT's as well.

It is not optimal yet, but does work for simple cases.
There are a few features of DOCT (property inheritance, management 
of hooks/contexts) that make it more difficult than just a syntax 
swap.
I could come up with something more fully featured, but in my 
experience thus far, it does not take long to translate from one 
syntax to the other manually.



- Is it simple to use on simple use-cases?


I would say so. There is a single function that does the 
translation. For example:


(doct '("Example" :keys "e" :file ""))

Returns:

(("e" "Example" entry (file "") nil :doct (:doct-name "Example" 
:keys "e" :file "")))


Part of my frustration of writing templates was always having to 
look up the structure of the template list.
Keys, description, type, target (with its variations) and 
template-string (with its variations) is a lot to remember.


Whereas, with:

(doct '("Example" :keys "e" :file ""))

I need only remember that the description comes first. The 
keywords are more self-describing as well.
There's an inherent complexity to the flexibility that org-capture 
offers, but this makes templates easier to write/read.


- Is it more capable than the current syntax, i.e., does it 
handle
  situations that are not possible, even in a convoluted way, 
  currently?



- DOCT validates templates before runtime execution.

For exmaple, you have a template with an entry type of `'entry'
and you forget the leading star in the template string.
Days later you go to use that template. It's borked.


This is different from introducing a new syntax for capture 
templates.


Actually, `org-insert-place-item' and 
`org-capture-place-table-line'

both try to fix misshaped templates already. OTOH
`org-capture-place-entry' merely calls `org-capture-verify-tree' 
on the

template, i.e., it barfs if the template is ill-defined. It is
a discrepancy we could fix independently on your new syntax.

I invite you to propose a patch for `org-capture-place-entry' so 
it does
a better job at fixing the initial template, if needed. I'll 
gladly

apply it.


`org-capture-place-entry' is run after `org-capture' is invoked, 
so while I agree a patch could improve the error, the user still 
hits that error when they are using their capture template 
(defeating the point of org-capture letting you take a quick note 
without losing your current context).
DOCT checks while converting declarations to templates, so the 
error is thrown before org-capture is used (almost like linting 
for templates).


Aside from that, most of what DOCT does is sugar for common use 
patterns I've observed in others' org-capture-templates.

For example, adding per-declaration hooks:

Without DOCT:

;;rest of template configured elsewhere...
;;make sure you update this if you ever change the key for this 
 template!

(defun my-org-template-hook ()
 (when (string= (org-capture-get :key t) "t")
   (message "Template \"t\" selected.")))

(add-hook 'org-capture-mode-hook 'my-org-template-hook)

With DOCT:

(doct `("Example" :keys "t" :file ""
   :hook (lambda () (message "Template %s selected." 
   (doct-get :keys)


DOCT ensures that function is only run for that template without 
having the user manually filter against `org-capture-plist's :key.
It also allows the user to do this inline with the rest of the 
declaration vs spreading it out.

Re: Why not org-tempo insert upcased strings?

[Kaushal Modi]

On Fri, Apr 24, 2020, 2:52 AM tsuucat  wrote:

> Hi,
> I tried Emacs 27 and found org mode shortcuts such as  then I found org-tempo.el.
>
> However, org-tempo.el’s shortcuts insert downcased blocks (e.g.
> #+begin_src).
> Is this intended?
>

Yes, the convention is now to have downcased keywords.

>

Re: adding paragraph folding to visibility cycling?

[Bruce D'Arcus]

On Tue, Apr 21, 2020 at 1:51 PM Nicolas Goaziou  wrote:
>
> Hello,
>
> "Bruce D'Arcus"  writes:
>
> > Right now, I just keybindings for  origami-toggle-all-nodes 
> > origami-toggle-node.
> >
> > But I was thinking to have this folding as a step between disclosing
> > all headings, and disclosing everything.
> >
> > Does that make sense?
>
> There could be elements between headlines and paragraphs, e.g., a drawer
> or a block. Why would you fold the paragraphs without taking care of the
> intermediate levels.

I would treat them the same; fold at the same step.

> I'm not sure this is a great idea to add that to the global cycling
> mechanism. Or maybe the global cycling should be configurable, e.g., as
> a list of symbols that can be expanded with TAB. It could be complicated
> to handle intermediate steps, as explained above.
>
> As a data point, I wouldn't like to have to hit TAB five times before
> returning to the original visibility state.

Agreed. In my case here, I was imagining adding a single step.

But why I asked; wasn't sure how good an idea it was.

Re: Debugging at least 2 regressions in org-mode master breaking ox-hugo

[Carsten Dominik]

On Fri, Feb 28, 2020 at 1:04 AM Adam Porter  wrote:

> Kaushal Modi  writes:
>
> > Failure 1: org-get-outline-path has moved, and not mentioned in ORG-NEWS
> >
> > Compiling ox-hugo.el now gives:
> >
> > ox-hugo.el:4284:1: Warning: the function ‘org-get-outline-path’ is not
> known to be defined.
> >
> > I see that defun has now moved to org-refile.el. I see that
> > org-get-outline-path has nothing to do specific to refiling. Can that
> > be moved back to org.el, or may be a separate library? Otherwise,
> > ox-hugo.el will have to load org-refile.el too (yes, I don't use
> > org-refile (yet), and that's how I discovered this :))
>
> Yes, please move that function back.  This is going to cause breakage in
> a variety of packages that use that function but do not load
> org-refile.  I can hear the bug reports rumbling already...  ;)
>

I support this. getting the outline path has more general applications that
just refiling, so tugging it away into org-refile does not make sense.

- Carsten

small patch for ox-bibtex.el in contrib

[Eric S Fraga]

Dear all,

the contrib package ox-bibtex.el has a function for jumping to a
specific bibtex citation key.  The current regex assumes a particular
indentation style (leading spaces) and only one space between the
CUSTOM_ID key and the value of that key.  This small patch (hopefully)
generalizes the search regex.

I've done only some simple testing but seems to work for my
configuration.

Thank you,
eric

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-520-ge69937
>From a5439ba716978a447274993a2b77cf8e2898c530 Mon Sep 17 00:00:00 2001
From: Eric S Fraga 
Date: Fri, 24 Apr 2020 11:46:28 +0100
Subject: [PATCH] generalize search pattern for finding bibtex entry

* ox-bibtex.el (org-bibtex-goto-citation): The search regex for
finding a particular citation assumed a particular indentation style
for properties.  This change generalizes the regex to work
independently of the indentation style.
---
 contrib/lisp/ox-bibtex.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/lisp/ox-bibtex.el b/contrib/lisp/ox-bibtex.el
index 47e2d5dcc..16d538ee5 100644
--- a/contrib/lisp/ox-bibtex.el
+++ b/contrib/lisp/ox-bibtex.el
@@ -163,7 +163,7 @@ to `org-bibtex-citation-p' predicate."
 (find-file (or org-bibtex-file
 		   (error "`org-bibtex-file' has not been configured")))
 (goto-char (point-min))
-(when (re-search-forward (format "  :CUSTOM_ID: %s" citation) nil t)
+(when (re-search-forward (format "[ \t]*:CUSTOM_ID:[ \t]+%s" citation) nil t)
   (outline-previous-visible-heading 1)
   t)))
 
-- 
2.25.0

Re: Debugging at least 2 regressions in org-mode master breaking ox-hugo

[Daniel Kraus]

Hi!

Kyle Meyer  writes:

> Despite being sympathetic to any attempt to break up org.el, I agree
> that it'd be good to move the outline path functionality back.  Also,
> there are a number of loading issues related to the org-refile move,
> which can be seen by running `make single'.
>
> I've prepared a commit that resolves these issues, which includes moving
> org-get-outline-path and friends back to org.el, on the km/refile-fixups
> branch:
>
>   
> https://code.orgmode.org/bzg/org-mode/commit/18e58aa0d7fd367b3506891b633a493f402e9fee

Just want to say that I'm (like everyone else who uses the Emacs `native-comp` 
branch
with org-mode from master) are also affected by this and
would appreciate if this can be merged.

Thanks for everyone involved :)
-Daniel

Re: [RFC] DOCT: Declarative Org Capture Templates

[Nicolas Goaziou]

Hello,

No Wayman  writes:

> * [RFC] DOCT: Declarative Org Capture Templates

Thank you for your work. 

I have some comments.

Disclaimer: I am only using very basic capture templates. So, I cannot
comment realistically on the new syntax you suggest. In particular, the
example you give is way too complex for me to understand the benefits of
your syntax. I suggest to start out with showing simple use-cases.

Anyway, I hope more advanced capture template users can chime in and
comment your design.

My beginner questions are the following :

- Is it compatible with the current syntax? If it isn't, is there a way
  to ease transition to the new syntax?

- Is it simple to use on simple use-cases?

- Is it more capable than the current syntax, i.e., does it handle
  situations that are not possible, even in a convoluted way, currently?

> - DOCT validates templates before runtime execution.
>
> For exmaple, you have a template with an entry type of `'entry' 
> and you forget the leading star in the template string.
> Days later you go to use that template. It's borked.

This is different from introducing a new syntax for capture templates.

Actually, `org-insert-place-item' and `org-capture-place-table-line'
both try to fix misshaped templates already. OTOH
`org-capture-place-entry' merely calls `org-capture-verify-tree' on the
template, i.e., it barfs if the template is ill-defined. It is
a discrepancy we could fix independently on your new syntax.

I invite you to propose a patch for `org-capture-place-entry' so it does
a better job at fixing the initial template, if needed. I'll gladly
apply it.


Regards,

-- 
Nicolas Goaziou

Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

[Nicolas Goaziou]

Hello,

Ihor Radchenko  writes:

> To my surprise, the patch did not break org to unusable state and
> the performance on the sample org file [3] improved drastically. You can
> try by yourself!

It is not a surprise, really. Text properties are much faster than
overlays, and very close to them features-wise. They are a bit more
complex to handle, however.

> However, this did introduce some visual glitches with drawer display.
> Though drawers can still be folded/unfolded with , they are not
> folded on org-mode startup for some reason (can be fixed by running
> (org-cycle-hide-drawers 'all)). Also, some drawers (or parts of drawers)
> are unfolded for no apparent reason sometimes. A blind guess is that it
> is something to do with lack of 'isearch-open-invisible, which I am not
> sure how to set via text properties.

You cannot. You may however mimic it with `cursor-sensor-functions' text
property. These assume Cursor Sensor minor mode is active, tho.
I haven't tested it, but I assume it would slow down text properties
a bit, too, but hopefully not as much as overlays.

Note there are clear advantages using text properties. For example, when
you move contents around, text properties are preserved. So there's no
more need for the `org-cycle-hide-drawer' dance, i.e., it is not
necessary anymore to re-hide drawers.

> Any thoughts about the use of text properties or about the patch
> suggestion are welcome.  

Missing `isearch-open-invisible' is a deal breaker, IMO. It may be worth
experimenting with `cursor-sensor-functions'.

We could also use text properties for property drawers, and overlays for
regular ones. This might give us a reasonable speed-up with an
acceptable feature trade-off.

Anyway, the real fix should come from Emacs itself. There are ways to
make overlays faster. These ways have already been discussed on the
Emacs devel mailing list, but no one implemented them. It is a bit sad
that we have to find workarounds for that.

Regards,

-- 
Nicolas Goaziou

[patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

[Ihor Radchenko]

Emacs becomes very slow when opening and moving around huge org files
with many drawers. I have reported this issue last year in bug-gnu-emacs
[1] and there have been other reports on the same problem in the
internet [2]. You can easily see this problem using the attached file if
you try to move down the lines when all the headings are folded. Moving
a single line down may take over 10 seconds in the file.

According to the reply to my initial emacs bug report [1], the reasons
of performance degradation is huge number of overlays created by org in
the PROPERTY and LOGBOOK drawers. Emacs must loop over all those
overlays every time it calculates where the next visible line is
located. So, one way to improve the performance would be reducing the
number of overlays.

I have been looking into usage of overlays in the org-mode code recently
and tried to redefine org-flag-region to use text properties instead of
overlays:

#+begin_src emacs-lisp
(defun org-flag-region (from to flag spec)
  "Hide or show lines from FROM to TO, according to FLAG.
SPEC is the invisibility spec, as a symbol."
  (pcase spec
;; outlines must still use overlays because they rely on
;; 'reveal-toggle-invisible feature from reveal.el
;; That only works for overlays
('outline 
 (remove-overlays from to 'invisible spec)
 ;; Use `front-advance' since text right before to the beginning of
 ;; the overlay belongs to the visible line than to the contents.
 (when flag
   (let ((o (make-overlay from to nil 'front-advance)))
 (overlay-put o 'evaporate t)
 (overlay-put o 'invisible spec)
 (overlay-put o 'isearch-open-invisible #'delete-overlay
(_
 (let ((inhibit-modification-hooks t))
   (remove-text-properties from to '(invisible nil))
   ;; Use `front-advance' since text right before to the beginning of
   ;; the overlay belongs to the visible line than to the contents.
   (when flag
 (put-text-property from to 'rear-non-sticky t)
 (put-text-property from to 'front-sticky t)
 (put-text-property from to 'invisible spec)
 ;; no idea if 'isearch-open-invisible is needed for text
 ;; properties 
 ;; (overlay-put o 'isearch-open-invisible #'delete-overlay)
 )
#+end_src

To my surprise, the patch did not break org to unusable state and
the performance on the sample org file [3] improved drastically. You can
try by yourself!

However, this did introduce some visual glitches with drawer display.
Though drawers can still be folded/unfolded with , they are not
folded on org-mode startup for some reason (can be fixed by running
(org-cycle-hide-drawers 'all)). Also, some drawers (or parts of drawers)
are unfolded for no apparent reason sometimes. A blind guess is that it
is something to do with lack of 'isearch-open-invisible, which I am not
sure how to set via text properties.

Any thoughts about the use of text properties or about the patch
suggestion are welcome.  

Best,
Ihor

[1] https://lists.gnu.org/archive/html/bug-gnu-emacs/2019-04/msg01387.html
[2] 
https://www.reddit.com/r/orgmode/comments/e9p84n/scaling_org_better_to_use_more_medsize_files_or/
[3] See the attached org file in my Emacs bug report: 
https://lists.gnu.org/archive/html/bug-gnu-emacs/2019-04/txte6kQp35VOm.txt

-- 
Ihor Radchenko,
PhD,
Center for Advancing Materials Performance from the Nanoscale (CAMP-nano)
State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong 
University, Xi'an, China
Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg