Re: "Invalid version syntax" with 9.4.4

[Kyle Meyer]

Hanns Mattes writes:

> Hi,
>
> as mentioned in the subject I ran into this error after upgrading from
> 9.4 to 9.4.4.
>
> With 9.4 org-version reports:
>
> ,
> | Org mode version 9.4 (9.4-elpa @ /home/hanns/.emacs.d/elpa/org-9.4/)
> `
>
> With 9.4.4:
>
> ,
> | Org mode version  ( @ /home/hanns/.emacs.d/elpa/org-9.4.4/)
> `
>
> resulting in "version-to-list: Invalid version syntax: ‘’ (must start
> with a number)" when using org-caldav for example

Thanks for reporting.  Should be fixed by 61336f80d.  See
.

Re: [Bug] org-version returns empty string when called uninteractively [9.4]

[Kyle Meyer]

Kyle Meyer writes:

> Thanks for the report.  I think this is the same issue as
> .  Org needs to be
> adjusted for the new ELPA setup.

Hopefully fixed by 61336f80d.

Re: Bug: (org-release) returns empty string on Elpa [ ( @ /home/pierre/.guix-profile/share/emacs/site-lisp/)]

[Kyle Meyer]

Stefan Monnier writes:

> Indeed that's the origin of the problem.

Thanks for confirming.

> I don't know exactly how `org-version.el` is created and how the release
> version is extracted, so I'm not sure how to fix it.
>
> The approach I'd advocate would be to use `package-get-version` (or
> something similar since `package-get-version` doesn't exist in
> Emacs<27).

Based on tested in a `git clone --no-tags ...` repo, should be fixed by
61336f80d.

Re: Free up C-c SPC/org-table-blank-field?

[Tim Cross]

Eric Abrahamsen  writes:

>> Does it actually need a key binding? I've never used it and just use
>>  to move to the next field, leaving the field blank.
>
> I assume it's meant for blanking a field you've already typed something
> into. But yes, I can't imagine it's a heavily-used command, and I
> suspect the C-c  binding is mostly mnemonic: "make this field
> contain only blanks".
>

I guess that makes sense, but not convinced the use of a valuable key
binding is justified given the need. Then again, others probably have
vastly different use cases to mine.


 What do people think about making it a no-op when not on a table
 (letting it fall through to the global map), or putting it in a keymap
 text property on tables, or otherwise not hogging the binding?
>>>
>>> In my view, the first would be fine, and the second also unless someone
>>> chimes in with a technical reason not to. For the last, perhaps `C-c
>>> C-SPC' would be an okay replacement, though I'd assume that would break
>>> some users' muscle memory in a surprising and unpleasant way.
>>
>> I'm not familiar with how this is all put together inside org mode.
>> If it is possible to configure things so that it is only bound when
>> inside a table and does not shadow other bindings for that sequence
>> outside a table, I think that would be a positive change. However, I do
>> also note that this is the type of change which tends to cause 'ripples'
>> and may have unexpected impact in other areas, such as other packages,
>> predefined or 'canned' emacs configurations etc.
>
> The way Org handles these situations now is to have a command that is
> named for its actual keybinding (eg `org-shiftmetaleft'), which then
> examines its context and dispatches to various other functions. That's a
> bit odd and not really how it's done in Emacs -- but I am not proposing
> we change this as it is pretty fundamental to how Org is set up and
> would wreck a bunch of stuff if it were changed.
>
> I thought Emacs might have some easy way to let a key event "fall
> through" to other keymaps, but I haven't been able to find anything
> immediately obvious. Maybe I can ask on emacs.devel...
>

I don't believe there is one. I think the basic model is a hierarchy of
key maps with bindings and the first match wins. I guess the only option
is to add a more sophisticated context test and only perform the action
if the context is inside a table cell. If not inside a table cell,
either perform some function which makes sense. It could be that on
loading, org checks to see if there is a binding and stores that as the
default action outside of tables or if we have some action which would
make sense, bind to that or keep it simple and have it defined as a user
option which defaults to a noop and allow the user to define something
if they want?

Since switching to spacemacs and its 'evil' key binding model, I've
become very aware of the dangers associated with modes that try to be
too clever when it comes to key bindings. I think they are really quite
a personal thing and best kept as simple as possible. In general, org
has been reasonably successful with its rather 'advanced' approach, but
there have been times I've found it frustrating. Smart key bindings are
great when they do what you expect, but when they don't

--
Tim Cross

Re: org-contacts problem

[Raoul Comninos]

Ihor Radchenko  writes:

> Raoul Comninos  writes:
>> Can someone perhaps guide me?
>
> You need to tell Emacs to load org-contacts:
>
> (require 'org-contacts)
>
> Best,
> Ihor

It worked. You are a genius! Thank you.
-- 

Re: Free up C-c SPC/org-table-blank-field?

[Kyle Meyer]

Eric Abrahamsen writes:

> Kyle Meyer  writes:
>
[...]
>> Does it actually need a key binding? I've never used it and just use
>>  to move to the next field, leaving the field blank.
>
> I assume it's meant for blanking a field you've already typed something
> into. But yes, I can't imagine it's a heavily-used command, and I
> suspect the C-c  binding is mostly mnemonic: "make this field
> contain only blanks".

[ Just for clarity: from this point on, the outer text you were quoting
  was from Tim Cross, not me. ]

> I thought Emacs might have some easy way to let a key event "fall
> through" to other keymaps, but I haven't been able to find anything
> immediately obvious. Maybe I can ask on emacs.devel...

Yeah, I don't know either.  When I read your initial message, I assumed
you were thinking of some sort of key lookup.  Something like below
seems to works, but it feels hacky and is probably pretty brittle.


diff --git a/lisp/org-table.el b/lisp/org-table.el
index ef4672e1b..c6d0e91c4 100644
--- a/lisp/org-table.el
+++ b/lisp/org-table.el
@@ -1203,22 +1203,28 @@ (defun org-table-goto-line (N)
 (= cnt N)))
 
 ;;;###autoload
-(defun org-table-blank-field ()
+(defun org-table-blank-field ( interactive-p)
   "Blank the current table field or active region."
-  (interactive)
-  (org-table-check-inside-data-field)
-  (if (and (called-interactively-p 'any) (org-region-active-p))
-  (let (org-table-clip)
-   (org-table-cut-region (region-beginning) (region-end)))
-(skip-chars-backward "^|")
-(backward-char 1)
-(if (looking-at "|[^|\n]+")
-   (let* ((pos (match-beginning 0))
-  (match (match-string 0))
-  (len (org-string-width match)))
- (replace-match (concat "|" (make-string (1- len) ?\ )))
- (goto-char (+ 2 pos))
- (substring match 1)
+  (interactive "p")
+  (cond
+   ((org-at-table-p)
+(org-table-check-inside-data-field)
+(if (and interactive-p (org-region-active-p))
+(let (org-table-clip)
+  (org-table-cut-region (region-beginning) (region-end)))
+  (skip-chars-backward "^|")
+  (backward-char 1)
+  (if (looking-at "|[^|\n]+")
+  (let* ((pos (match-beginning 0))
+ (match (match-string 0))
+ (len (org-string-width match)))
+(replace-match (concat "|" (make-string (1- len) ?\ )))
+(goto-char (+ 2 pos))
+(substring match 1)
+   (interactive-p
+(let ((key (lookup-key (current-global-map) (this-command-keys
+  (unless (numberp key)
+(call-interactively key))
 
 (defun org-table-get-field ( n replace)
   "Return the value of the field in column N of current row.

Re: org-contacts problem

[Ihor Radchenko]

Raoul Comninos  writes:
> Can someone perhaps guide me?

You need to tell Emacs to load org-contacts:

(require 'org-contacts)

Best,
Ihor

 

Re: Free up C-c SPC/org-table-blank-field?

[Eric Abrahamsen]

Kyle Meyer  writes:

> Eric Abrahamsen writes:
>
>> Hi all,
>>
>> The C-c SPC keybinding is pretty prime property (it's also, according to
>> Emacs conventions, meant to be reserved for the user, though I know
>> that's already out the window with Org),
>
> Based on my reading of (info "(elisp)Key Binding Conventions"), I think
> `C-c SPC` doesn't fall into the user's `C-c LETTER' territory but
> instead into the this group:
>
>   Sequences consisting of ‘C-c’ followed by any other ASCII
>   punctuation or symbol character are allocated for minor modes.
>   Using them in a major mode is not absolutely prohibited, but if you
>   do that, the major mode binding may be shadowed from time to time
>   by minor modes.

Oh, interesting, thanks -- I've always found that section impossible to
remember, and it seems to often be disregarded, anyway. In this case, I
guess we could consider the keybinding to be kind of "minor-mode-ish",
if you thought of commands that operate on Org tables to be like a minor
mode that's only active when point is inside a table.

[...]

>> But, either way, I don't disagree with what you say next.
>>
>>> and it's currently bound to `org-table-blank-field', which is useless
>>> unless you... happen to be in a table. I don't use tables often (or
>>> blank fields when I do), which means this binding is effectively just
>>> removed.
>
> Does it actually need a key binding? I've never used it and just use
>  to move to the next field, leaving the field blank.

I assume it's meant for blanking a field you've already typed something
into. But yes, I can't imagine it's a heavily-used command, and I
suspect the C-c  binding is mostly mnemonic: "make this field
contain only blanks".

>>>
>>> What do people think about making it a no-op when not on a table
>>> (letting it fall through to the global map), or putting it in a keymap
>>> text property on tables, or otherwise not hogging the binding?
>>
>> In my view, the first would be fine, and the second also unless someone
>> chimes in with a technical reason not to. For the last, perhaps `C-c
>> C-SPC' would be an okay replacement, though I'd assume that would break
>> some users' muscle memory in a surprising and unpleasant way.
>
> I'm not familiar with how this is all put together inside org mode.
> If it is possible to configure things so that it is only bound when
> inside a table and does not shadow other bindings for that sequence
> outside a table, I think that would be a positive change. However, I do
> also note that this is the type of change which tends to cause 'ripples'
> and may have unexpected impact in other areas, such as other packages,
> predefined or 'canned' emacs configurations etc.

The way Org handles these situations now is to have a command that is
named for its actual keybinding (eg `org-shiftmetaleft'), which then
examines its context and dispatches to various other functions. That's a
bit odd and not really how it's done in Emacs -- but I am not proposing
we change this as it is pretty fundamental to how Org is set up and
would wreck a bunch of stuff if it were changed.

I thought Emacs might have some easy way to let a key event "fall
through" to other keymaps, but I haven't been able to find anything
immediately obvious. Maybe I can ask on emacs.devel...

Eric

Re: OT: M-S-$ Not Working

[Tim Cross]

Bo Grimes  writes:

> I beg your indulgence.  I am confident this isn't an Emacs problem, let
> alone an org problem, but my eyes hurt from searching for an answer,
> and this list, the only one I subscribe to, is populated with gurus.  I
> promise never to use it this way again.
>
> OS: PopOS 20.10, DE: GNOME 3.38.2 WM: Mutter
> GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.14)
>
> M-S-$ does not spellcheck word.  It will work from the menu bar, and it
> will work if I drop into a tty and run Emacs.  Emacs gives no
> response in the minibuffer in the GUI when I press M-S-$. M-x
> describe-key M-S-$ does nothing. C-h b C-s 'spell' reveals that indeed
> M-S-$ is bound to spellcheck word. And other M-S- keys work like M-S->
> just fine.
>
> There has to be some keybinding outside Emacs taking precedence. I have
> gone through dconf-editor until my eyes bleed. Done gsettings
> list-recursively  org.gnome.desktop.wm.keybindings | sort | more and
> gone line by line.  I have done dconf dump / > dconf.dump and read
> through them all, in addition to checking PopOS' keybindings in
> Settings. And trying a different keyboard.
>
> Nothing in Tweeks, dconf, or Settings uses M-S-$, but I disabled
> anything that uses Shift anyway (nothing uses $). No joy. I don't want
> to rebind it for this machine only, nor do I want to go through the
> hassle of installing a different DM/WM.
>
> StackExchange, et.al are full of problems with the the M key, but not
> one specific keychord only.
>

Do you see the same behaviour if you run emacs -Q?

--
Tim Cross

OT: M-S-$ Not Working

[Bo Grimes]

I beg your indulgence.  I am confident this isn't an Emacs problem, let
alone an org problem, but my eyes hurt from searching for an answer,
and this list, the only one I subscribe to, is populated with gurus.  I
promise never to use it this way again.

OS: PopOS 20.10, DE: GNOME 3.38.2 WM: Mutter 
GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.14)

M-S-$ does not spellcheck word.  It will work from the menu bar, and it
will work if I drop into a tty and run Emacs.  Emacs gives no
response in the minibuffer in the GUI when I press M-S-$. M-x
describe-key M-S-$ does nothing. C-h b C-s 'spell' reveals that indeed
M-S-$ is bound to spellcheck word. And other M-S- keys work like M-S->
just fine.

There has to be some keybinding outside Emacs taking precedence. I have
gone through dconf-editor until my eyes bleed. Done gsettings
list-recursively  org.gnome.desktop.wm.keybindings | sort | more and
gone line by line.  I have done dconf dump / > dconf.dump and read
through them all, in addition to checking PopOS' keybindings in
Settings. And trying a different keyboard.

Nothing in Tweeks, dconf, or Settings uses M-S-$, but I disabled
anything that uses Shift anyway (nothing uses $). No joy. I don't want
to rebind it for this machine only, nor do I want to go through the
hassle of installing a different DM/WM.

StackExchange, et.al are full of problems with the the M key, but not
one specific keychord only.

Any ideas? I will accept rebukes.  I'm desperate.  TIA!

Bo Grimes

use-package mistake?

[Lawrence Bottorff]

Each time I call up list-package and update, I get this message after the
updates

Operation finished.  Packages that are no longer needed: 43.  Type ‘M-x
package-autoremove’ to remove them

Below is my init.el concerning use-package

(require 'package)
(setq package-enable-at-startup nil)

(setq package-archives '(("ELPA"  . "http://tromey.com/elpa/;)
("gnu"   . "http://elpa.gnu.org/packages/;)
("melpa" . "https://melpa.org/packages/;)
("org"   . "https://orgmode.org/elpa/;)))

(package-initialize)

;;; Bootstrapping use-package, i.e., if use-package isn't installed
;;; then install it
(unless (package-installed-p 'use-package)
  (package-refresh-contents)
  (package-install 'use-package))

;;;This will ensure all packages are installed if not already
(require 'use-package-ensure)
(setq use-package-always-ensure t)

;;;This will make sure packages are updated
(use-package auto-package-update
  :config
  (setq auto-package-update-delete-old-versions t)
  (setq auto-package-update-interval 1)
  (setq auto-package-update-hide-results t)
  (auto-package-update-maybe))


I obviously don't want to uninstall all the packages on my system. What
have I done wrong? Can you critique my setup here?

LB

Re: Turning off all indentation in 9.4.4

[Kévin Le Gouguec]

Raoul Comninos  writes:

> I noticed a change in org since I updated to the latest version when it
> comes to automatic indentation. I prefer to turn this off globally,
> including for lists. I have tinkered with various settings but have had
> no luck so far.

ORG-NEWS provides these hints:

> To get the previous behaviour back, disable ~electric-indent-mode~
> explicitly:
> 
> #+begin_src emacs-lisp
> (add-hook 'org-mode-hook (lambda () (electric-indent-local-mode -1)))
> #+end_src
> 
> Alternatively, if you wish to keep =RET= as the "smart-return" key,
> but dislike Org's default indentation of sections, you may prefer to
> customize ~org-adapt-indentation~ to either =nil= or ='headline-data=.

Normally I would recommend customizing org-adapt-indentation over
disabing electric-indent-local-mode, but if you'd rather move back to
column 0 when hitting RET in a list, the hook is probably the way to go.

Re: http links translated to html : target "_blank"

[Uwe Brauer]

>>> "JMM" == Juan Manuel Macías  writes:

> Uwe Brauer  writes:
>> That is odd (maybe my org version is a bit rusty (master june 2020)

> It's strange...

> It should work fine for you (as long as you set
> `org-export-allow-bind-keywords' as non-nil)

Aha, indeed it was nil! I was not even aware of this variable, after
switching to t, your code worked. Thanks because it save me the hassle
to add manually 
#+attr_latex

On the other hand it is good to know that booth solution exits.

Thanks

Uwe 


smime.p7s
Description: S/MIME cryptographic signature

Re: word counts and org-mode drawers

[Sharon Kimble]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


Hi Juan.

Thanks very much for this code, it fits my purpose very well, thanks
again.

Thanks
Sharon.

>   Juan Manuel Macías  writes:
>
> Hi,
>
> Sharon Kimble  writes:
>
>> How can I exempt an org-mode drawer, and its contents, from word counts
>> please. I am using 'wc-mode' but I can't see how to do it.

>
> #+begin_src emacs-lisp
> (defun my-count-words-in-org-buffer ()
>   (interactive)
>   (let ((words 0))
> (save-excursion
>   (save-restriction
>   (narrow-to-region (point-min) (point-max))
>   (goto-char (point-min))
>   (while (forward-word-strictly 1)
> (if (org-at-drawer-p)
> (re-search-forward ":END:")
>   (setq words (1+ words))
> (message "Org buffer has %d word%s."
>words (if (= words 1) "" "s"
> #+end_src
>

> Juan Manuel 
>

- -- 
Debian 10.7, fluxbox 1.3.7, emacs 27.1.50, org 9.4.4
-BEGIN PGP SIGNATURE-

iQJPBAEBCgA5FiEELSc/6QwVBIYugJDbNoGAGQr4g1sFAmAb+6sbHGJvdWRpY2Nh
c0Bza2ltYmxlLnBsdXMuY29tAAoJEDaBgBkK+INbKfcP/i/rVfnnXUSViX7dD2Rm
Gu2+mvzfwv+lzyRMUsbZoEMi2hYDQ/5CkBChFVtgrG84KqF9+wmxjikCG9q2hL0b
BMYrZ60XNfwMsJ1nd7Q/CHypPgr7//cn6r89B29w2ez0/noWID9OiTDS+dfJFoQQ
8MFv32TeLQtlYiONsiO0Z38iqkyQDGn5aSOtQjMjIxOJ5fiAVAsO/GBiwrNunwbN
yeCrOJQhiooZB/dOQgYwZkd9yDOQ3C/jPfRflLxIBGWUJ3EgCuFqBCuKin+JBnhJ
JUghkoX1BSDfs72QDq5yyzezHTgDnq0IdKBdqz0GVrMH6tkHFxfLDdUbxJgY2KcF
uW/GX17A23EXLT11MhI0C+W3VnG68HWvqZc/x4kY0SKy9pxUbXy9y2BGJFdGl+no
CPMyEn3tA+E8klDVDWe6DSJj2JUxarAT0gaizs7KOJpHCDeHja2i+rN1S0eLZ+t8
PmY32zYHoe5w8yzdwm43V3+mZp6kvusK6SODNalRCIykqPrCeeYMmzolfwXpi6qW
va5g4OigBHmY165SfVdLr8iGzi96VqLlTWkzBN3bCiu9F/fJGqUiPdgDEAR8A2f0
/nFaEbYBNq4h1I8OMAMNhfA2PMeo0qn7vmBsmwboIXn6G+4yaTnQk9R80hb/7JFv
SN043NVKF1XKT5lcjxfDEIWr
=hiQu
-END PGP SIGNATURE-

Re: emphasizing source code words

[Juan Manuel Macías]

Hi Luca

Luca Ferrari  writes:

> Thanks, but stil Im not able to figure it out. I've searched thru the
> org documentation without any luck.
>
> Luca

To use the minted package as backend (https://www.ctan.org/pkg/minted),
I have in my Emacs:

(setq org-latex-listings 'minted)
  (setq org-latex-minted-options
 '(("frame" "lines") ("linenos=true") ("breaklines")))

You also need to install the Python pigments library on your OS. In
Arch (in my case) is the python-pygments package.

And you have to make sure that when you export to LaTeX it always compiles
with the -shell-escape option. For example:

(setq org-latex-pdf-process
  '("lualatex -shell-escape -interaction nonstopmode -output-directory %o 
%f"
"lualatex -shell-escape -interaction nonstopmode -output-directory %o 
%f"
"lualatex -shell-escape -interaction nonstopmode -output-directory %o 
%f"))

Lastly, in Org docs you need of course to load the minted package:

#+LaTeX_HEADER: \usepackage{minted}

You can see how the highlighting looks like in this post from my blog (in
Spanish): under the title there is a button to download the entry in PDF
version: https://lunotipia.juanmanuelmacias.com/evitar_funcion_lua.html

Finally, you may be interested in this new package that TEC has written:

https://www.reddit.com/r/emacs/comments/lbkmmz/the_best_syntax_highlighting_in_a_pdf_youll_see_a/

Best regards,

Juan Manuel 

Re: emphasizing source code words

[Luca Ferrari]

On Mon, Feb 1, 2021 at 1:56 PM TEC  wrote:
> I'd have to look at the manual for specifics, but I know that you can
> highlight lines when using the minted backend.

Thanks, but stil Im not able to figure it out. I've searched thru the
org documentation without any luck.

Luca