Re: [PATCH] Allow tangling to a list of files

[Tim Cross]

Jacopo De Simoi via "General discussions about Org-mode." 
 writes:

> Hi Greg, 
>
> thanks for your comments!
>
> On Tuesday, July 6, 2021 12:43:54 AM EDT Greg Minshall wrote:
>> hi, Jacopo,
>> 
>> i'm not convinced this is needed over and above your old "solution" of
>> using <> witn N-different source blocks, each :tangle'ing to a
>> different file.
>
> To be honest I never quite managed to get it work... =) 
>
> My point here is to be able to have one org file tangle'ing to several, 
> slightly different outputs.  Ideally I want to use one readable literate 
> config 
> for all my machines; the config can then be published (or exported) to html
>
> Say I want to create an org file to tangle .tmux.conf (or .zshrc) for 
> different 
> machines; then most of the conf file would be the same (and each such block 
> would be tangled to all files) whereas some specifics could be tangled to 
> corresponding files only (e.g. ALIASes or EDITORs) 
>
> Even if a solution using noweb could work, I find being able to tangle to a 
> list of files more readable and elegant. Especially when exporting the org in 
> an external format, I think the noweb solution would look like a hack, 
> whereas 
> a solution with tangle-to-list would be much easier to parse. 
>
>> 
>> but, i'm curious -- in the example you sent, did you miss a ":tangle" on
>> the "#+begin_src" line?
>
> Yikes! of course I did! Good catch.
>> 
>> > #+begin_src sh '("filename1" "filename2")
>> > #my script
>> > #+end_src
>> 

I'm not sure I fully understand the rationale behind this patch. It
seems to be very niche oriented and not a terribly useful general
feature. It feels like it is just a partial solution to a problem (i.e.
generate multiple different files from the same org file). If this is
the case, then you probably need some additional control structures to
determine which bits/blocks go into which files. From what I can see,
all the patch is doing is creating multiple files, which I imagine would
then need to be modified anyway?

If I understand it correctly, all the files will end up with the same
content. This seems odd to me. Am I missing something (like some ability
to have different contents tangled to different files)?

If it is just generating multiple copies of the same file, I don't
really see the value. It would be less processing/overhead to just
create one file and then copy it (possibly copying it to different
locations, such as a tramp filespec). Using the 'devops' style of org
files, this could even be coded into a script block which could be
executed after tangling. 

Personally, I've used a different approach to a similar problem. For
example, my .zshrc and init.el files have conditional tests which check
either the hostname or platform type and set things accordingly. This
way, I only ever have one .zshrc and one init.el file for all systems,
but they behave differently based on the system they are running on.
When the config does not support conditional tests, then I'll have
different source blocks included in the tangle. Currently, I just turn
off blocks I don't want (:tangle no), but I guess I could do something
more sophisticated using noweb or tags, but the manual setting has
worked fine so far as I don't have many files requiring this. 

-- 
Tim Cross

Re: [PATCH] make org-notify support for macOS desktop notification

[Tim Cross]

stardiviner  writes:

>> On Jul 6, 2021, at 8:06 AM, Tim Cross  wrote:
>> 
>> 
>> stardiviner  writes:
>> 
 On Jul 5, 2021, at 7:55 PM, Maxim Nikulin  wrote:
 
 On 05/07/2021 10:50, stardiviner wrote:
> I updated the patch, I found the package `osx-lib` contains solution.
> So I removed the directly osascript process invocation.
 
 I have no objections any more. On the other hand I have no access to 
 macOS, so
 I have not tested this patch. Feel free to ignore comments from this 
 message,
 they are mostly matter of taste.
 
 I expect that a simple script "notify-send" may allow to avoid 
 modification of
 code. Something like (untested, unsure concerning "quoted form of ...")
 
 #!/usr/bin/env osascript
 display notification (item 1 of argv)
 
 However if osx-lib in is installed automatically, it may be more 
 convenient.
 Unsure if some of currently supported linux distributions have notify-send
 that can not handle title as the first argument.
 
> - ((fboundp 'notifications-notify)
> + ((and (eq system-type 'gnu/linux) (fboundp 'notifications-notify))
 
 Does it mean that `notifications-notify' is bound but it does not work on
 macOS? If so, maybe it is better to put new clause for 'darwin above and to
 drop 'gnu/linux here. From my point of view, it is preferable to avoid
 additional requirement for `notifications-notify'. If someone will create a
 feature request for `notifications-notify' for macOS, it will just work
 without installing of additional packages as soon as such feature is
 implemented.
 
 
>>> I indeed tried `notifications-notify`. And it does not work, reports error 
>>> that
>>> it needs dbus. PS. I used the Homebrew formulae version Emacs.
>>> I considered the order of conditions. Because notifications and notify-send 
>>> etc
>>> requires dbus. So I guess only Linux supports that. So add system-type 
>>> detection
>>> will be better. WDYT?
>> 
>> I think you can add dbus support to macOS using homebrew and that might
>> resolve the issue.
>
> I checked my homebrew, I found the `dbus` is installed already. And in Emacs 
> `(featurep ‘dbus)` returns t.
>
> But `(org-show-notification “test”)` returns error:
> ```
> Debugger entered--Lisp error: (dbus-error "No connection to bus" :session)
>   dbus-message-internal(1 :session "org.freedesktop.Notifications"
> "/org/freedesktop/Notifications" "org.freedesktop.Notifications" "Notify"
> dbus-call-method-handler :string "Emacs" :uint32 0 :string
> "/opt/homebrew/Cellar/emacs-head@28/28.0.50_1/share..." :string "Org mode
> message" :string "test" (:array) ((:dict-entry "urgency" (:variant :byte 0)))
> :int32 3000)
>   apply(dbus-message-internal 1 :session "org.freedesktop.Notifications"
> "/org/freedesktop/Notifications" "org.freedesktop.Notifications" "Notify"
> dbus-call-method-handler (:string "Emacs" :uint32 0 :string
> "/opt/homebrew/Cellar/emacs-head@28/28.0.50_1/share..." :string "Org mode
> message" :string "test" (:array) ((:dict-entry "urgency" (:variant :byte 0)))
> :int32 3000))
>   dbus-call-method(:session "org.freedesktop.Notifications"
> "/org/freedesktop/Notifications" "org.freedesktop.Notifications" "Notify"
> :string "Emacs" :uint32 0 :string
> "/opt/homebrew/Cellar/emacs-head@28/28.0.50_1/share..." :string "Org mode
> message" :string "test" (:array) ((:dict-entry "urgency" (:variant :byte 0)))
> :int32 3000)
>   notifications-notify(:title "Org mode message" :body "test" :timeout 3000 
> :urgency low)
>   (cond ((functionp org-show-notification-handler) (funcall
> org-show-notification-handler notification)) ((stringp
> org-show-notification-handler) (start-process "emacs-timer-notification" nil
> org-show-notification-handler notification)) ((fboundp 
> 'w32-notification-notify)
> (let ((id (w32-notification-notify :title "Org mode message" :body 
> notification
> :urgency 'low))) (run-with-timer org-show-notification-timeout nil #'(lambda 
> nil
> (w32-notification-close id) ((fboundp 'notifications-notify)
> (notifications-notify :title "Org mode message" :body notification :timeout (*
> org-show-notification-timeout 1000) :urgency 'low)) ((executable-find
> "notify-send") (start-process "emacs-timer-notification" nil "notify-send"
> notification)) (t (message "%s" notification)))
>   org-show-notification("test")
>   eval((org-show-notification "test") nil)
>   elisp--eval-last-sexp(nil)
>   eval-last-sexp(nil)
>   funcall-interactively(eval-last-sexp nil)
>   call-interactively(eval-last-sexp nil nil)
>   command-execute(eval-last-sexp)
>
> ```
>
> Seems Emacs can’t connect to Homebrew dbus session. But I checked homebrew 
> services, the dbus service is running.

Probably some permission issue. I'll try to boot up my old mac on the
weekend and see if I can get it working. 

The other thing which also needs to be considered is whether your patch
will have any advers

how to avoid 0.0 in an org-table

[Uwe Brauer]

Hi 

In the following example 

#+begin_src elisp
| ||   |   |  Res | Min |
|-++---+---+--+-|
|   0 |  0 | 0 | 0 |0 | 0.0 |
| 1.2 | 10 | 1 | 1 | 13.2 | 0.1 |
#+TBLFM: $5=vsum($1..$4);f1::$6=min(10,$4)*0.1;f1 E
#+end_src

I obtain 0.0 in the last column, this looks bad, any idea how to avoid
it?

Thanks

Uwe Brauer 

Re: convert subtree or nested list to table

[Eric S Fraga]

On Tuesday,  6 Jul 2021 at 15:10, Tim Cross wrote:
> One advantage working with HTML has over latex is
> that you don't have to worry about lines and line breaks and can have
> really long cell lines which will get wrapped in HTML rendering. 

Minor point: in LaTeX, the standard tabular environment has "p{X}" for
paragraph columns (as opposed to "l" and "r", say) where X is some size
(e.g. 10cm) and each entry is formatted as paragraphs.  You don't have
to worry about line breaks etc.  So quite easy really.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-577-gf76d4d
: Latest paper written in org: https://arxiv.org/abs/2106.05096

[PATCH] Show drawers in text entries in Org Agenda

[Rodrigo Morales]

Rodrigo Morales  writes:

>
> For this reason, I am wondering whether there is a way to make
> =org-agenda-entry-text-mode= to show the drawers without much
> tinkering.
> 

After inspecting the source code of Org Mode, I managed to do what I was
searching by deleting the relevant part of the function
=org-agenda-get-some-entry-text=. This function unconditionally removes
drawers from subtrees in order for the remaining content be shown in
text entries.

I've created the following patch which adds a defcustom that would allow
the user to decide whether drawers must be hidden or shown in text
entries. Hope this helps.


-- 
La información contenida en este e-mail y sus anexos es confidencial, 
privilegiada y está dirigida exclusivamente a su destinatario, en 
consecuencia, solo puede ser utilizada por aquel. Si usted no es el 
destinatario original, no deberá examinar, usar, copiar o distribuir este 
mensaje o la información que contiene. Si lo recibe por error, por favor 
reenvíelo a la persona que se lo envió y elimínelo. Cualquier retención o 
uso total o parcial no autorizada de este mensaje está estrictamente 
prohibida y sancionada por ley.

-- 
[[[ If you see a signature in spanish below this message, please omit
it, it has to do with the internal privacy policies of the organization
that owns the domain of my email address. ]]]
>From 389ac7b8029d9ed4d0b862481465e3edfa8515de Mon Sep 17 00:00:00 2001
From: Rodrigo Morales 
Date: Tue, 6 Jul 2021 06:26:11 -0500
Subject: [PATCH] org-agenda.el: Added defcustom for visiblity of drawers in
 text entries

* lisp/org-agenda.el: Added boolean defcustom for visibility of
drawers in text entries in Org Agenda buffers.
---
 lisp/org-agenda.el | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 44acd035a..c558e7fcd 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -1074,6 +1074,11 @@ removed from entry text before it is shown in the agenda."
   :group 'org-agenda
   :type 'string)
 
+(defcustom org-agenda-entry-text-hide-drawers t
+  "Non-nil means hide drawers in entry text in agenda buffers."
+  :group 'org-agenda
+  :type 'boolean)
+
 (defvar org-agenda-entry-text-cleanup-hook nil
   "Hook that is run after basic cleanup of entry text to be shown in agenda.
 This cleanup is done in a temporary buffer, so the function may inspect and
@@ -3676,12 +3681,13 @@ removed from the entry content.  Currently only `planning' is allowed here."
 	   (set-text-properties (match-beginning 0) (match-end 0)
 nil))
 	 (goto-char (point-min))
-	 (while (re-search-forward drawer-re nil t)
-	   (delete-region
-		(match-beginning 0)
-		(progn (re-search-forward
-			"^[ \t]*:END:.*\n?" nil 'move)
-		   (point
+ (when org-agenda-entry-text-hide-drawers
+   (while (re-search-forward drawer-re nil t)
+ (delete-region
+  (match-beginning 0)
+  (progn (re-search-forward
+  "^[ \t]*:END:.*\n?" nil 'move)
+ (point)
 	 (unless (member 'planning keep)
 	   (goto-char (point-min))
 	   (while (re-search-forward kwd-time-re nil t)
-- 
2.32.0

Re: how to avoid 0.0 in an org-table

[Roger Mason]

Hello Uwe,

Uwe Brauer writes:

> I obtain 0.0 in the last column, this looks bad, any idea how to avoid
> it?

I think you can use a printf format specification in the formula.

Cheers,
Roger

Re: convert subtree or nested list to table

[Uwe Brauer]

>>> "MP" == Matt Price  writes:

> I have to write a number of text-heavy documents which need to be delivered
> as tables with wrapped paragraphs in most cells. Working directly in table
> format is pretty arduous and uncomfortable.  Has anyone ever written a
> function to accept a list or subtree as input and process it into a table?

> If anyone has done something similar, I'd love some tips!

There is org-listcruncher, which I started to use some days ago. For my
needs it works quite nicely.


smime.p7s
Description: S/MIME cryptographic signature

Re: convert subtree or nested list to table

[Tim Cross]

Eric S Fraga  writes:

> On Tuesday,  6 Jul 2021 at 15:10, Tim Cross wrote:
>> One advantage working with HTML has over latex is
>> that you don't have to worry about lines and line breaks and can have
>> really long cell lines which will get wrapped in HTML rendering. 
>
> Minor point: in LaTeX, the standard tabular environment has "p{X}" for
> paragraph columns (as opposed to "l" and "r", say) where X is some size
> (e.g. 10cm) and each entry is formatted as paragraphs.  You don't have
> to worry about line breaks etc.  So quite easy really.

Yes, that is true. However, you have to decide before hand how wide you
want the columns to be (i.e. it won't auto scale based on other data).
Typically, you have to do some 'trial and error' to work out what width
to make each column and avoid overful parbox warnings etc. With HTML,
you just specify the number of columns and it will scale to fit to the
page (screen) width. So, HTML great for display, sucks for printing.
latex, great for printing, but sucks for display. Getting things right
for latex tables/tabular environments is much harder than for HTML. Then
again, HTML tables sort of suck as well - much more flexible to have div
elements which you can style using a good grid/flow layout scheme.

-- 
Tim Cross

Re: [wip-cite-new] Quick note about citation insertion

[Bruce D'Arcus]

On Sat, Jul 3, 2021 at 3:58 AM Nicolas Goaziou  wrote:

> Anyway, I'll try to provide something a little more useful out of the
> box, based on your comment and Bruce D'Arcus suggestion.

Nicolas - I saw you pushed some changes, per the discussion.

First, my initial thought is the behavior at point is perfect.

Second, what's your intended way one enters a citation with two references?

In selectrum, I:

1. select one reference with RET
2. select another
3. C-j to exit

Is that the expected workflow and behavior?

Just want to confirm, as that doesn't work in Vertico, so I need to
figure out why (maybe a keybinding issue?).

Bruce

Re: add #+ATTR_SOMETHING to headline?

[John Kitchin]

Why don’t you just use a property for this?

On Mon, Jul 5, 2021 at 11:12 PM Matt Price  wrote:

> Does anyone know if attributes get attached to headline elements during
> the export process? I am writing a derived backend in which I would like to
> have a line like
>
> (let (add-toggle (org-export-read-attribute :attr_canvas_html headline
> :toggle))
> )
>
> But as var as i can tell, the call to org-rexport-read-attribute always
> evaluates to nil in a file like this:
>
> #+ATTR_CANVAS_HTML: :toggle t
> * My TOggle Headline
>
> Am I missing something obvious, or is htis not possible? I notice that
> none of the org-xxx-headline functions in ox-xxx.el seem to check for
> attributes, so maybe this is by design?
>
> THanks,
>
> Matt
>
-- 
John

---
Professor John Kitchin (he/him/his)
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

Re: [PATCH] make org-notify support for macOS desktop notification

[Maxim Nikulin]

On 06/07/2021 08:45, stardiviner wrote:

Here is the new patch which invokes notifications though Emacs built-in API 
`ns-do-applescript`.


I suspect, you considered your original patch as small and simple, 
didn't you?



+  (format "display notification \"%s\" with title \"Org mode 
notification\""
+  (replace-regexp-in-string "\"" "#" notification


Last character of notification might be "\" so it might escape the 
closing quote. Some less common quote character like "´" may be less 
confusing than "#" in this confusing if proper escaping is a challenge. 
I am unsure how many people are still using 8-bit charsets.


It seems there is no way to pass argv through `ns-do-applescript'. Is 
there at least a helper to escape strings similar to 
`shell-quote-argument'? Otherwise it is not friendly to developers since 
everyone has to do it himself.


On 06/07/2021 07:06, Tim Cross wrote:

I suspect that any code
which 'encourages' the use of melpa packages will not be acceptabl
If there are license problems with `osx-lib-notify2', I expect, it can 
be utilized through `org-show-notification-handler'. However users have 
to manually add such customization that is not really convenient.


If `org-show-notification' depends on runtime configuration (whether 
DBus socket is available), maybe it is reasonable to rewrite the 
function and to add a convention that e.g. 'default return value causes 
attempt to call next handler in the responsibility chain. The intention 
is to allow fallback from `org-show-notification-handler' to standard 
notifiers or graceful degradation from `notifications-notify' to 
`message' if dbus connection is not available (e.g. Emacs is running in 
a minimal container). Such changes however out of scope of this patch.

Re: convert subtree or nested list to table

[Juan Manuel Macías]

Hi Matt, sorry for the slow reply...

Matt Price writes:

> I'd love to try that, thanks. I think it would be really helpful. 
> Much appreciated!

Some previous caveats:

- *The code is very raw*. I wrote it almost as a "proof of concept" for
  my personal use, therefore it is quite improvable. In any case, it
  works (but i don't know if it will help you get what you want...).

- The attached example is optimized to export to LaTeX. Use the tabularx
  environment, which is ideal for tables with a lot of textual content.

- As for the code, there are two basic functions:
  `my-org/edit-table-cell' and
  `my-org/kill-edit-table-cell-buffer-and-save'. To edit an empty cell,
  you have to write something in that cell first.

- The basic idea is that within each cell, the content is a single line
  (unfilled). In the edit buffer, the content is filled. There are two
  macros to indicate a line break and a paragraph end: {{{nl}}} and
  {{{par}}}. In the edit buffer you can put line breaks and white lines,
  but all of that is lost inside the cell once saved (all is a single
  line), so those macros are needed to indicate line or paragraph breaks
  (in LaTeX).

Best regards,

Juan Manuel



test-tables.org
Description: Lotus Organizer

Re: LaTeX-producing code : how to export results to HTML/ODT

[John Kitchin]

Here is a way way to combine the output with a name/caption. I adapted this
from the post-processing section in
https://orgmode.org/manual/Results-of-Evaluation.html

#+NAME: caption
#+BEGIN_SRC sh :var data="" :var caption="" name=""  :results output
echo "#+name: $name"
echo "#+caption: $caption"
echo "$data"
#+END_SRC


Here we have a block that outputs a latex string, for example.

#+BEGIN_SRC emacs-lisp :results value drawer :post
caption(name="eq-integral", caption="This is an equation.", data=*this*)
"$\int_0^2 e^x dx$"
#+END_SRC

#+RESULTS:
:results:
#+name: eq-integral
#+caption: This is an equation.
$int_0^2 e^x dx$
:end:
John

---
Professor John Kitchin (he/him/his)
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu



On Mon, Jul 5, 2021 at 1:04 PM autofrettage 
wrote:

> Hi,
>
> I simply cannot ignore this opportunity to expose my utter Org Mode
> ignorance!
>
> Emmanuel > ... and how to use it with captions, labels and
> cross-references.
>
> I have tried using the code-splicing functionality with some success; The
> result from one source code block "foo", can be inserted into another one
> with <>.
>
> If you take away the parentheses, then the source code block "foo" instead
> of its results will be inserted.
>
> Emm.> But I still don't "get" drawers, I thonk.
>
> You're not alone.
>
> Rasmus
>
>

problems with (customize-option 'org-structure-template-alist)

[Uwe Brauer]

Hi 

I would like to have templates for the following to blocks



#+begin:  aggregate :table final :cols "Nombre  'Calificación' "
#+end:

#+begin: join :mas-table "actas" :mas-column "Nombre" :ref-table "actas-dni" 
:ref-column "Nombre" 
#+end:

However I am only able to obtain:

#+begin_:  aggregate :table final :cols "Nombre  'Calificación' "
#+end_:


#+begin_: join :mas-table "actas" :mas-column "Nombre" :ref-table "actas-dni" 
:ref-column "Nombre" 
#+end_:


And that does not work, so shall I use the tempo templates instead?

Regards

Uwe Brauer 

Re: [PATCH] ob-R output file with graphics parameter

[Jack Kamm]

Hello again,

>> A user might like to construct a figure consisting of various subfigures 
>> such as in a subfloat environment.
>>
>> Will this be reasonably simple to accomplish if `:results graphics' (with no 
>> `file' element) automatically inserts a link?
>>
>> Currently, omitting the file element leaves the link out, which I believe is 
>> the most direct way to approach subfloats.
>
> Thanks for bringing up this use case, it hadn't occurred to me before.

Thinking about this more, it occurred to me that the ":exports code" or
":exports none" header should already handle this.

When that header is set, the graphics result won't be added to the latex
document, and the user can construct the subfigure separately in latex.

Then we wouldn't need to support the use-case of ob-R creating a graphic
but not producing a result from it...which still feels a little strange
to me, to be honest.

Or am I missing something still?

Re: [new patch] [PATCH] make org-notify support for macOS desktop notification

[stardiviner]

Thanks for your suggestion. Does your Emacs build supports imagemagick image 
view and svg feature support? Because company-mode now have built-in icons 
support. This is the reason that I switch from https://emacsformacosx.com/ 
 to Homebrew cask Emacs version.

> On Jul 6, 2021, at 12:21 PM, Christian Hopps  wrote:
> 
> Hi,
> 
> Please consider: I added full native notification support to the popular OS X 
> Emacs build available in homebrew. This supports rewrites 
> notifications-notify defun to use the native code rather than dbus, and so 
> everything "Just Works".
> 
> Info can be found here:
> 
> https://github.com/choppsv1/homebrew-emacsmacport
> 
> Thanks,
> Chris.
> 
> stardiviner  writes:
> 
>> Here is the new patch which invokes notifications though Emacs built-in API 
>> `ns-do-applescript`.
>> 
>> [2. text/x-patch; 
>> 0001-org-clock.el-Make-org-notify-support-macOS-notificat.patch]...
>> 
>> 
>> 
>>> On Jul 6, 2021, at 8:06 AM, Tim Cross  wrote:
>>> 
>>> 
>>> stardiviner  writes:
>>> 
> On Jul 5, 2021, at 7:55 PM, Maxim Nikulin  wrote:
> 
> On 05/07/2021 10:50, stardiviner wrote:
>> I updated the patch, I found the package `osx-lib` contains solution.
>> So I removed the directly osascript process invocation.
> 
> I have no objections any more. On the other hand I have no access to 
> macOS, so
> I have not tested this patch. Feel free to ignore comments from this 
> message,
> they are mostly matter of taste.
> 
> I expect that a simple script "notify-send" may allow to avoid 
> modification of
> code. Something like (untested, unsure concerning "quoted form of ...")
> 
> #!/usr/bin/env osascript
> display notification (item 1 of argv)
> 
> However if osx-lib in is installed automatically, it may be more 
> convenient.
> Unsure if some of currently supported linux distributions have notify-send
> that can not handle title as the first argument.
> 
>> -((fboundp 'notifications-notify)
>> +((and (eq system-type 'gnu/linux) (fboundp 
>> 'notifications-notify))
> 
> Does it mean that `notifications-notify' is bound but it does not work on
> macOS? If so, maybe it is better to put new clause for 'darwin above and 
> to
> drop 'gnu/linux here. From my point of view, it is preferable to avoid
> additional requirement for `notifications-notify'. If someone will create 
> a
> feature request for `notifications-notify' for macOS, it will just work
> without installing of additional packages as soon as such feature is
> implemented.
> 
> 
 I indeed tried `notifications-notify`. And it does not work, reports error 
 that
 it needs dbus. PS. I used the Homebrew formulae version Emacs.
 I considered the order of conditions. Because notifications and 
 notify-send etc
 requires dbus. So I guess only Linux supports that. So add system-type 
 detection
 will be better. WDYT?
>>> 
>>> I think you can add dbus support to macOS using homebrew and that might
>>> resolve the issue. At the very least, this will need to be investigated
>>> because otherwise, adding this patch may break configurations for users
>>> who have added dbus support via homebrew and have notifications working,
>>> but have not installed the osx-lib package.
>>> 
>>> My only small concern with your proposed changes is that it will add a
>>> dependency on a new package osx-lib, which I think is only available in
>>> melpa. At the very least, this will need to be documented somewhere.
>>> However, I'm not sure what the situation is wrt adding code which
>>> depends on an external package which is not available in either elpa or
>>> nongnuELPA? As org mode is a part of GNU Emacs, I suspect that any code
>>> which 'encourages' the use of melpa packages will not be acceptable.
>>> 
>>> --
>>> Tim Cross
>>> 
> 

Re: [PATCH] Allow tangling to a list of files

[General discussions about Org-mode.]

Dear Vladimir, 

 thanks for your reply.

Let me show you two examples; they are both WIP and incomplete, but you'll get 
the gist. 

- Example 1

https://gist.github.com/85c9b9c9ab151c5fd35bd761ef6ef569

This is my literate config for .zshrc; as you can see different blocks are 
tangled to different set of files; hence the output files differ (as some 
blocks 
are present and other are not) 

- Example 2

https://gist.github.com/2bce5d6df3f04c934fb4beda0c6560ad

This is my literate config for xkb maps; I have several keyboards, and some of 
them require slightly different maps.

Once again, likely all this can be accomplished by some noweb magic, but I find 
my approach much less intrusive (particularly the initial bit in the .zshrc, 
which I am still refactoring, where the list of tangle targets is inferred 
from the headline tags)

Thanks again for your comments. I'd really like to see how to do the same with 
noweb and compare my approach with the "standard" one. Once more, I hope these 
examples clarify my point of view. 

Best 
 Jacopo

On Tuesday, July 6, 2021 2:11:09 AM EDT Vladimir Lomov wrote:
> Hello!
> 
> ** Jacopo De Simoi via General discussions about Org-mode.
> 
>  [2021-07-06 01:09:30 -0400]:
> > Hi Greg,
> > 
> > thanks for your comments!
> > 
> > On Tuesday, July 6, 2021 12:43:54 AM EDT Greg Minshall wrote:
> >> hi, Jacopo,
> >> 
> >> i'm not convinced this is needed over and above your old "solution" of
> >> using <> witn N-different source blocks, each :tangle'ing to a
> >> different file.
> > 
> > To be honest I never quite managed to get it work... =)
> > 
> > My point here is to be able to have one org file tangle'ing to several,
> > slightly different outputs.  Ideally I want to use one readable literate
> > config for all my machines; the config can then be published (or
> > exported) to html
> I do the same with 'noweb' feature.
> 
> > Say I want to create an org file to tangle .tmux.conf (or .zshrc) for
> > different machines; then most of the conf file would be the same (and
> > each such block would be tangled to all files) whereas some specifics
> > could be tangled to corresponding files only (e.g. ALIASes or EDITORs)
> 
> How this could be solved by your approach by tangling to several files? They
> will be identical!
> 
> > Even if a solution using noweb could work, I find being able to tangle to
> > a
> > list of files more readable and elegant.
> 
> Could you explain this a bit more? How you will see that (assuming you have
> exported Org to HTML) this goes into different files? Again, if you tangle
> to several files they content will be the same! Then why you need different
> files?
> 
> > Especially when exporting the org in an external format,
> > 
> > I think the noweb solution would look like a hack,
> 
> IMHO, yes, this is a hack and the "standard" way. I would suggest to read
> again Org manual concerning "Literate programming".
> 
> > whereas a solution with tangle-to-list would be much easier to parse.
> 
> How that? You will tangle source block to several files, they content will
> be identical! Or you suggesting to add some syntax for source block
> indicating to which file to tangle that code snippet?
> 
> I would recommend you to describe your needs and how you do things right
> now.
> 
> [...]
> 
> > Best,
> > 
> >  Jacopo
> 
> ---
> WBR, Vladimir Lomov

Re: [PATCH] ob-R output file with graphics parameter

[Berry, Charles]

> On Jul 6, 2021, at 8:04 AM, Jack Kamm  wrote:
> 
> Hello again,
> 
>>> A user might like to construct a figure consisting of various subfigures 
>>> such as in a subfloat environment.
>>> 
>>> Will this be reasonably simple to accomplish if `:results graphics' (with 
>>> no `file' element) automatically inserts a link?
>>> 
>>> Currently, omitting the file element leaves the link out, which I believe 
>>> is the most direct way to approach subfloats.
>> 
>> Thanks for bringing up this use case, it hadn't occurred to me before.
> 
> Thinking about this more, it occurred to me that the ":exports code" or
> ":exports none" header should already handle this.
> 
> When that header is set, the graphics result won't be added to the latex
> document, and the user can construct the subfigure separately in latex.
> 
> Then we wouldn't need to support the use-case of ob-R creating a graphic
> but not producing a result from it...which still feels a little strange
> to me, to be honest.
> 
> Or am I missing something still?


Well, if the src blocks export nothing, the graphics results are not produced 
and no files are created. 

Here is an ECM that when exported with `C-c C-e l o y y` (or 'yes RET' for each 
`y' depending on your setup)


1) Produces two graphics files:
   - fig1.png
   - fig2.png

2) Produces file `subfigures.pdf` with a page with one figure containing those
   subfigures rendered side-by-side.

If you modify the ECM to change `:exports results' to `:exports none' and clean 
older fig[12].png's from the  directory, the export fails.

Of course, there are workarounds to having Type=file implied by 
Format=graphics. So if everyone else is determined to make this change I can 
live with it.

Best,
Chuck


 

Re: [new patch] [PATCH] make org-notify support for macOS desktop notification

[Christian Hopps]

It supports imagemagick (specify —with-imagemagick), and it includes svg by 
default, I simply forked the railwaycat version and added the native 
notification code.

Thanks,
Chris.

> On Jul 6, 2021, at 11:30 AM, stardiviner  wrote:
> 
> Thanks for your suggestion. Does your Emacs build supports imagemagick image 
> view and svg feature support? Because company-mode now have built-in icons 
> support. This is the reason that I switch from https://emacsformacosx.com/ 
>  to Homebrew cask Emacs version.
> 
>> On Jul 6, 2021, at 12:21 PM, Christian Hopps > > wrote:
>> 
>> Hi,
>> 
>> Please consider: I added full native notification support to the popular OS 
>> X Emacs build available in homebrew. This supports rewrites 
>> notifications-notify defun to use the native code rather than dbus, and so 
>> everything "Just Works".
>> 
>> Info can be found here:
>> 
>> https://github.com/choppsv1/homebrew-emacsmacport 
>> 
>> 
>> Thanks,
>> Chris.
>> 
>> stardiviner mailto:numbch...@gmail.com>> writes:
>> 
>>> Here is the new patch which invokes notifications though Emacs built-in API 
>>> `ns-do-applescript`.
>>> 
>>> [2. text/x-patch; 
>>> 0001-org-clock.el-Make-org-notify-support-macOS-notificat.patch]...
>>> 
>>> 
>>> 
 On Jul 6, 2021, at 8:06 AM, Tim Cross >>> > wrote:
 
 
 stardiviner mailto:numbch...@gmail.com>> writes:
 
>> On Jul 5, 2021, at 7:55 PM, Maxim Nikulin > > wrote:
>> 
>> On 05/07/2021 10:50, stardiviner wrote:
>>> I updated the patch, I found the package `osx-lib` contains solution.
>>> So I removed the directly osascript process invocation.
>> 
>> I have no objections any more. On the other hand I have no access to 
>> macOS, so
>> I have not tested this patch. Feel free to ignore comments from this 
>> message,
>> they are mostly matter of taste.
>> 
>> I expect that a simple script "notify-send" may allow to avoid 
>> modification of
>> code. Something like (untested, unsure concerning "quoted form of ...")
>> 
>> #!/usr/bin/env osascript
>> display notification (item 1 of argv)
>> 
>> However if osx-lib in is installed automatically, it may be more 
>> convenient.
>> Unsure if some of currently supported linux distributions have 
>> notify-send
>> that can not handle title as the first argument.
>> 
>>> -   ((fboundp 'notifications-notify)
>>> +   ((and (eq system-type 'gnu/linux) (fboundp 
>>> 'notifications-notify))
>> 
>> Does it mean that `notifications-notify' is bound but it does not work on
>> macOS? If so, maybe it is better to put new clause for 'darwin above and 
>> to
>> drop 'gnu/linux here. From my point of view, it is preferable to avoid
>> additional requirement for `notifications-notify'. If someone will 
>> create a
>> feature request for `notifications-notify' for macOS, it will just work
>> without installing of additional packages as soon as such feature is
>> implemented.
>> 
>> 
> I indeed tried `notifications-notify`. And it does not work, reports 
> error that
> it needs dbus. PS. I used the Homebrew formulae version Emacs.
> I considered the order of conditions. Because notifications and 
> notify-send etc
> requires dbus. So I guess only Linux supports that. So add system-type 
> detection
> will be better. WDYT?
 
 I think you can add dbus support to macOS using homebrew and that might
 resolve the issue. At the very least, this will need to be investigated
 because otherwise, adding this patch may break configurations for users
 who have added dbus support via homebrew and have notifications working,
 but have not installed the osx-lib package.
 
 My only small concern with your proposed changes is that it will add a
 dependency on a new package osx-lib, which I think is only available in
 melpa. At the very least, this will need to be documented somewhere.
 However, I'm not sure what the situation is wrt adding code which
 depends on an external package which is not available in either elpa or
 nongnuELPA? As org mode is a part of GNU Emacs, I suspect that any code
 which 'encourages' the use of melpa packages will not be acceptable.
 
 --
 Tim Cross
 
>> 
> 

Re: [PATCH] ob-R output file with graphics parameter

[Jack Kamm]

Hi Chuck,

> Here is an ECM that when exported with `C-c C-e l o y y` (or 'yes RET' for 
> each `y' depending on your setup)

I don't see the example on your last email, could you try re-attaching
it?

Thanks,
Jack

Emacs-orgmode Digest, Vol 185, Issue 7

[Ypo]

Hi

Several things around my mind. Pick one if you like, and I will try to explain 
it better.

- when using ediff, if there is an image near the text which has differences, 
it works wrong. Like if the image wouldn't allow ediff to scroll and show the 
difference. I just see the image, stationary, while jumping to the next 
difference.

- I have started to read Chassell's. Introduction... to Emacs Lisp. But my 
ideas grow much much faster than my reading. I even feel I won't be able to 
implement simple ideas in years. Example: I would like that every time "I see" 
a heading with a special TODO state, this heading is expanded. Should I keep 
reading the book to materialize this little idea or should I take different 
actions?

- when I export to latex, I get an error and no document is produced. Sorry I 
can't share here the error, since I am writing from the mobile, but it seems 
related to xelatex. Buuut, if I take the .tex produced file and I open it with 
an external latex editor, the document is compiled into a decent PDF. How could 
orgmode generate a valid tex document but not to be able to produce its PDF?

- some more bugs I found, I should share from the PC.

- oh, wait. I have an old PC I don't use much (2008 AD - Core 2 Duo). I was 
thinking about using it just for orgmode. Would you recommend me an OS?

Thanks for being there

Re: Emacs-orgmode Digest, Vol 185, Issue 7

[Samuel Banya]

- oh, wait. I have an old PC I don't use much (2008 AD - Core 2 Duo). I was 
thinking about using it just for orgmode. Would you recommend me an OS?

What are the other specs for the machine, as in what's the RAM?

This matters a ton because it means the difference of what desktop environment 
(DE) or Window Manager (WM) you could use.

I would say for something that old, you might want to consider Debian, a 
lightweight Ubuntu variant (Lubuntu, Xubuntu, etc), Puppy Linux, or even Arch 
Linux.

Sincerely,

Sam

On Tue, Jul 6, 2021, at 5:28 PM, Ypo wrote:
> Hi
> 
> Several things around my mind. Pick one if you like, and I will try to 
> explain it better.
> 
> - when using ediff, if there is an image near the text which has differences, 
> it works wrong. Like if the image wouldn't allow ediff to scroll and show the 
> difference. I just see the image, stationary, while jumping to the next 
> difference.
> 
> - I have started to read Chassell's. Introduction... to Emacs Lisp. But my 
> ideas grow much much faster than my reading. I even feel I won't be able to 
> implement simple ideas in years. Example: I would like that every time "I 
> see" a heading with a special TODO state, this heading is expanded. Should I 
> keep reading the book to materialize this little idea or should I take 
> different actions?
> 
> - when I export to latex, I get an error and no document is produced. Sorry I 
> can't share here the error, since I am writing from the mobile, but it seems 
> related to xelatex. Buuut, if I take the .tex produced file and I open it 
> with an external latex editor, the document is compiled into a decent PDF. 
> How could orgmode generate a valid tex document but not to be able to produce 
> its PDF?
> 
> - some more bugs I found, I should share from the PC.
> 
> - oh, wait. I have an old PC I don't use much (2008 AD - Core 2 Duo). I was 
> thinking about using it just for orgmode. Would you recommend me an OS?
> 
> Thanks for being there
> 
> 

Re: Emacs-orgmode Digest, Vol 185, Issue 7

[Samuel Banya]

Regarding the latex issue, you need to have a version of Latex installed on 
your machine in order to be able to utilize LaTeX within Emacs to export PDFs.

On Linux machines, this is often labeled 'texlive' in your distribution's 
package manager, ex on a Debian or Ubuntu based Linux distribution: sudo apt 
install texlive

On Tue, Jul 6, 2021, at 5:28 PM, Ypo wrote:
> Hi
> 
> Several things around my mind. Pick one if you like, and I will try to 
> explain it better.
> 
> - when using ediff, if there is an image near the text which has differences, 
> it works wrong. Like if the image wouldn't allow ediff to scroll and show the 
> difference. I just see the image, stationary, while jumping to the next 
> difference.
> 
> - I have started to read Chassell's. Introduction... to Emacs Lisp. But my 
> ideas grow much much faster than my reading. I even feel I won't be able to 
> implement simple ideas in years. Example: I would like that every time "I 
> see" a heading with a special TODO state, this heading is expanded. Should I 
> keep reading the book to materialize this little idea or should I take 
> different actions?
> 
> - when I export to latex, I get an error and no document is produced. Sorry I 
> can't share here the error, since I am writing from the mobile, but it seems 
> related to xelatex. Buuut, if I take the .tex produced file and I open it 
> with an external latex editor, the document is compiled into a decent PDF. 
> How could orgmode generate a valid tex document but not to be able to produce 
> its PDF?
> 
> - some more bugs I found, I should share from the PC.
> 
> - oh, wait. I have an old PC I don't use much (2008 AD - Core 2 Duo). I was 
> thinking about using it just for orgmode. Would you recommend me an OS?
> 
> Thanks for being there
> 
> 

Re: [PATCH] ob-R output file with graphics parameter

[Berry, Charles]

> On Jul 6, 2021, at 12:20 PM, Jack Kamm  wrote:
> 
> Hi Chuck,
> 
>> Here is an ECM that when exported with `C-c C-e l o y y` (or 'yes RET' for 
>> each `y' depending on your setup)
> 
> I don't see the example on your last email, could you try re-attaching
> it?
> 
> Thanks,
> Jack

Mea culpa.

#+begin_src org

  ,* subfig ECM
  :PROPERTIES:
  :EXPORT_FILE_NAME: subfigures.tex
  :EXPORT_OPTIONS: toc:nil
  :EXPORT_LATEX_HEADER: \usepackage{subfig}
  :END:

  ,#+macro: subfig @@latex: 
\subfloat[$1]{\includegraphics[width=0.49\linewidth]{$2}}@@

  ,#+name: sub1
  ,#+begin_src R :exports results :results graphics :file fig1.png
plot(0:1,0:1)
text(0.5,0.5,"Fig 1")
  ,#+end_src


  ,#+name: sub2
  ,#+begin_src R :exports results :results graphics  :file fig2.png
plot(0:1,0:1)
text(0.5,0.5,"Fig 2")
  ,#+end_src


  ,#+begin_figure
  @@latex: {\centering@@
  {{{subfig(First,fig1)}}}
  {{{subfig(Second,fig2)}}}
  @@latex: }@@
  ,#+end_figure
#+end_src

Ability to hide / collapse in-buffer settings?

[Matthew Twomey]

 

Greetings, 

I'm trying to find a way to visually collapse settings related to images
in my org docs. I have many images with a syntax similar to: 

#+NAME: fig:figure name
#+CAPTION: figure name
#+ATTR_ORG: :width 200
#+ATTR_LATEX: :width 2.0in
#+ATTR_HTML: :width 200
[[file:homepage.org_imgs/20210706_002617_ok9v4c.png]] 

The setting vary per image and I prefer tailoring each image, but I
don't like all the clutter on my screen while editing. I've tried
putting the settings in a drawer, but that make it invisible to the link
element. I've been digging through source code, thinking maybe I could
give advice to some function or find something to hook into, but I'm not
getting anywhere. Any thoughts or ideas on this? 

Thanks, 

-Matt 
 

Re: Emacs-orgmode Digest, Vol 185, Issue 7

[Tim Cross]

Ypo  writes:

> Hi
>
> Several things around my mind. Pick one if you like, and I will try to 
> explain it better.
>
> - when using ediff, if there is an image near the text which has differences, 
> it
> works wrong. Like if the image wouldn't allow ediff to scroll and show the
> difference. I just see the image, stationary, while jumping to the next
> difference.

I'm not sure how well ediff supports diffs containing things like
images. The ediff program (which is not part of org-mode, only used by
org mode) is designed for showing the differences between buffers of
text and to help with merging such differences. I'm actually surprised
ediff even displays images. 


>
> - I have started to read Chassell's. Introduction... to Emacs Lisp. But my 
> ideas
> grow much much faster than my reading. I even feel I won't be able to 
> implement
> simple ideas in years. Example: I would like that every time "I see" a heading
> with a special TODO state, this heading is expanded. Should I keep reading the
> book to materialize this little idea or should I take different actions?
>

Definitely keep reading the book and spend some time writing some elisp
code to do simple things. A basic understanding of Emacs lisp is
extremely valuable. Although the functional style of lisp based
languages can seem confusing at first, it is actually very simple. There
is only a small amount of syntax to learn, but it can take a bit of time
to start thinking in a 'functional' paradigm. Probably the hardest part
to learn is all the terminology for things like point, mark, buffers,
region and the wealth of functions provided by core elisp libraries.
Make sure you spend time getting to understand the Emacs help system and
the info manuals. This is critical and one of the key powers of Emacs -
you can explore and find functions easily and get the documentation with
just a few key strokes. 

With org mode, and with Emacs generally, often your best course of
action is to be patient and avoid customising the system initially.
Emacs and to some extent, org mode, is complex, often uses weird terms
for things and incorporates new approaches and ways of doing things
which can seem very odd at first. The normal response is to try and
change things to be more familiar and make the experience more similar
to what you are use to. This is often a mistake.

Those who take the time to really experience the way both Emacs and org
mode work often find there are significant benefits to the Emacs and org
approaches over what they are use to. These differences are not always
obvious initially and it is only once you have been using them for a
while you recognise some of the more subtle benefits.

I think it is good to realise that while we are all different, what we
require in our editor is remarkably similar. Emacs is a program with a
very large user base and which has been around for many decades. It is
highly likely when you come up with an idea someone else has already had
one which is very similar. I have lost count of the number of times I've
thought "I wish emacs could do ' only to later find that not only
could it do it, the feature already exists and is even more refined and
powerful than my original idea. The challenge with Emacs is often just
finding that feature or recognising it. After using Emacs for nearly 30
years, I am still discovering stuff and refining my configuration. I
frequently learn about things in forums, blog posts, videos and other
sources which either give me ideas, help me refine my setup or introduce
me to something new. The amount of custom elisp code I have has actually
reduced over the years as I find existing better ways to do things than
my horrible elisp hacking. 

A common error, one which I made myself, is to initially be really
impressed by the possibilities org mode offers and immediately start
customizing things to realise some of the great ideas it has generated.
However, this is often a mistake. It can result in over engineering and
workflows which are overly complex and to some extent self defeating. In
many cases, you end up partially re-inventing wheels which already
exist, but which perhaps look slightly different to how you conceived
them (which makes them difficult to recognise). Often the differences
are because org's approach is more refined or deals with other related
issues you have not seen or yet identified.

When starting with org mode, the best approach is to only do as little
configuration as you need to get things working. Avoid defining new todo
states, capture templates, adding custom hook functions etc until after
you have used org mode for a time and have become familiar with what
features it provides and its approach to organising information. Often,
this will expose you to new ways of doing things which are actually
better. You will also often find that org or Emacs already implements
some feature you would like, but called something you did not expect or
implemented in such a way it

Bug: tab key no longer bound to org-cycle in commit 565361eb69 [9.4.6 (9.4.6-10-gee652a-elpaplus @ /Users/bartm002/.emacs.d/elpa/org-plus-contrib-20210705/)]

[Mark Barton]

I normally use C-RET to enter a new headline and then press TAB to make it 
child headline. Recently it stopped working and I think I have it tracked down 
to the change that was made last week. I could be missing something that allows 
“TAB” to work for a kdb binding, but the previous format of "" works.

Emacs  : GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin20.5.0, NS 
appkit-2022.50 Version 11.4 (Build 20F71))
 of 2021-07-06
Package: Org mode version 9.4.6 (9.4.6-10-gee652a-elpaplus @ 
/Users/bartm002/.emacs.d/elpa/org-plus-contrib-20210705/)

In commit 565361eb69 org-keys.el line 445

(org-defkey org-mode-map (kbd "TAB") #'org-cycle)

This does not work for my configuration and tab ends up bound to outline-cycle 
instead.

If I change “TAB” back to “” and byte compile org-keys.el then the tab key 
gets bound to org-cycle
(org-defkey org-mode-map (kbd "") #'org-cycle)

Re: [PATCH] Allow tangling to a list of files

[Vladimir Lomov]

Hello Jacopo.
** Jacopo De Simoi  [2021-07-06 11:24:40 -0400]:

> Dear Vladimir, 

>  thanks for your reply.

> Let me show you two examples; they are both WIP and incomplete, but you'll 
> get 
> the gist. 

> - Example 1

> https://gist.github.com/85c9b9c9ab151c5fd35bd761ef6ef569

> This is my literate config for .zshrc; as you can see different blocks are
> tangled to different set of files; hence the output files differ (as some
> blocks are present and other are not) 

I couldn't find in Org manual how tangling should work if there are several
source code blocks with the same file name for ':tangle'. The Org manual
section "15.8 Extracting Source Code" is a bit obscure. There are these two
sentences

  When Org tangles code blocks, it expands, merges, and transforms
  them.  Then Org recomposes them into one or more separate files, as
  configured through the options.

The second sentence assumes that it might be possible to tangle to more than
one file but possible options for ':tangle' don't give certain answer:

  yes’

   Export the code block to source file.  The file name for the source
   file is derived from the name of the Org file, and the file extension
   is derived from the source code language identifier.
   Example: ‘:tangle yes’.

  FILENAME

   Export the code block to source file whose file name is derived from
   any string passed to the ‘tangle’ header argument.  Org derives the
   file name as being relative to the directory of the Org file’s
   location.  Example: ‘:tangle FILENAME’.

If I understand first choice correctly then the only source block ("the code
block") will be tangled (exported) to a source file. What Org will do if there
are several source blocks? Concatenate them or write to a file only last one?
(I didn't test that).

The same applies to 'FILENAME' case: what Org will do if there are several
source code blocks with the same 'FILENAME' for ':tangle'.

I would say that you use here undocumented feature and you workflow could be
broken if in some future Org version developers decide to implement only
documented features.

> - Example 2

> https://gist.github.com/2bce5d6df3f04c934fb4beda0c6560ad

> This is my literate config for xkb maps; I have several keyboards, and some 
> of 
> them require slightly different maps.

> Once again, likely all this can be accomplished by some noweb magic, but I 
> find 
> my approach much less intrusive (particularly the initial bit in the .zshrc, 
> which I am still refactoring, where the list of tangle targets is inferred 
> from the headline tags)

I found you way of doing things a bit strange. As I already told I use 'noweb'
feature a lot. I won't advise you to use it or not to use it but I find it
very powerful.

> Thanks again for your comments. I'd really like to see how to do the same
> with noweb and compare my approach with the "standard" one. Once more, I
> hope these examples clarify my point of view. 

If you don't distract by foreign language (Russian) you could look how I use
'noweb' feature for scripts (one example):

https://git.sr.ht/~vp1981/scripts/tree/master/item/docs/scripts/misc.org

for shell configurations:

https://git.sr.ht/~vp1981/scripts/tree/master/item/docs/shell/bash.org

and for Emacs configuration:

https://git.sr.ht/~vp1981/scripts/tree/master/item/docs/emacs/emacs.org

> Best 
>  Jacopo

[...]

---
WBR, Vladimir Lomov

-- 
str->str_pok |= SP_FBM; /* deep magic */
s = (unsigned char*)(str->str_ptr); /* deeper magic */
-- Larry Wall in util.c from the perl source code


signature.asc
Description: PGP signature

Re: [PATCH] Allow tangling to a list of files

[Tim Cross]

Vladimir Lomov  writes:

> [[PGP Signed Part:Undecided]]
> Hello Jacopo.
> ** Jacopo De Simoi  [2021-07-06 11:24:40 -0400]:
>
>> Dear Vladimir, 
>
>>  thanks for your reply.
>
>> Let me show you two examples; they are both WIP and incomplete, but you'll 
>> get 
>> the gist. 
>
>> - Example 1
>
>> https://gist.github.com/85c9b9c9ab151c5fd35bd761ef6ef569
>
>> This is my literate config for .zshrc; as you can see different blocks are
>> tangled to different set of files; hence the output files differ (as some
>> blocks are present and other are not) 
>
> I couldn't find in Org manual how tangling should work if there are several
> source code blocks with the same file name for ':tangle'. The Org manual
> section "15.8 Extracting Source Code" is a bit obscure. There are these two
> sentences
>
>   When Org tangles code blocks, it expands, merges, and transforms
>   them.  Then Org recomposes them into one or more separate files, as
>   configured through the options.
>
> The second sentence assumes that it might be possible to tangle to more than
> one file but possible options for ':tangle' don't give certain answer:
>
>   yes’
>
>Export the code block to source file.  The file name for the source
>file is derived from the name of the Org file, and the file extension
>is derived from the source code language identifier.
>Example: ‘:tangle yes’.
>
>   FILENAME
>
>Export the code block to source file whose file name is derived from
>any string passed to the ‘tangle’ header argument.  Org derives the
>file name as being relative to the directory of the Org file’s
>location.  Example: ‘:tangle FILENAME’.
>
> If I understand first choice correctly then the only source block ("the code
> block") will be tangled (exported) to a source file. What Org will do if there
> are several source blocks? Concatenate them or write to a file only last one?
> (I didn't test that).
>
> The same applies to 'FILENAME' case: what Org will do if there are several
> source code blocks with the same 'FILENAME' for ':tangle'.
>
> I would say that you use here undocumented feature and you workflow could be
> broken if in some future Org version developers decide to implement only
> documented features.
>


As it stands at the moment, if the :tangle keyword is followed by a
filename, that block will be tangled into that file. If there is more
than one block with the same filename, the blocks will all be
concatenated into the same file. If you have multiple source blocks, but
with different filenames for the blocks, multiple files will be created
when you tangle the file - one file for each unique filename given to
the :tangle argument in each block.

I use this to generate my emacs config. I have both an early-init.el and
an init.el. These files are created from multiple source blocks where
some blocks have :tangle early-init.el and some have :tangle init.el.
(actually, I have changed that now. I tangle to tangle-early-init.el and
tangle-init.el. I then have a simple 'install.sh' script which first
moves the old early-init.el and init.el to new files with a timestamp
added to the name i.e. init.el-20210722 and then it installs the new
init files, renaming them to early-init.el and init.el).

I'm not sure this is an undocumented feature. The manual just says that
the code will be tangled into the file specified with the :tangle
keyword. Nothing states the filename can only appear once or you cannot
have different filenames for different blocks.

If you don't specify a filename i.e. :tangle yes, the block will be
tangled into a file with the same name as the org file and the extension
appropriate to the language in the source block. For example, if my org
file is called emacs-config.org and I just have :tangle yes, I will get
the source tangled into emacs-config.el. Same will happen if I just have
the keyword :tangle.

When I don't want a source block added to a file, I just add :tangle no
to the block header. This is a handy way of removing something from a
config file. I find it useful when trying to track down problems with my
emacs init as I can quickly remove lots of stuff, generate a new config
and see if the issue persists. I find this easier than commenting and
uncommenting multiple lines in my init file. I also find it useful when
I run into a problem with something (possibly due to a package update)
as my source blocks are all broken up into specific bits of
configuration which are as far as possible completely independent of
each other. For example, a while ago, I had problems with one of the
magit add on packages I use after it was updated. I changed the header
to :tangle no, generated a new init file and waited until a new version
of the package was released. This happened a few days later and I just
changed the header back to :tangle init.el and generated the new config
and all was back to normal.

-- 
Tim Cross

Re: [PATCH] Allow tangling to a list of files

[Jacopo De Simoi]

On Tuesday, July 6, 2021 11:27:18 PM EDT Vladimir Lomov wrote:
> Hello Jacopo.
>
> ** Jacopo De Simoi  [2021-07-06 11:24:40 -0400]:
> > Dear Vladimir,
> >
> >  thanks for your reply.
> >
> > Let me show you two examples; they are both WIP and incomplete, but you'll
> > get the gist.
> >
> > - Example 1
> >
> > https://gist.github.com/85c9b9c9ab151c5fd35bd761ef6ef569
> >
> > This is my literate config for .zshrc; as you can see different blocks are
> > tangled to different set of files; hence the output files differ (as some
> > blocks are present and other are not)
>
> I couldn't find in Org manual how tangling should work if there are several
> source code blocks with the same file name for ':tangle'. The Org manual
> section "15.8 Extracting Source Code" is a bit obscure. There are these two
> sentences
>
>   When Org tangles code blocks, it expands, merges, and transforms
>   them.  Then Org recomposes them into one or more separate files, as
>   configured through the options.
>
> The second sentence assumes that it might be possible to tangle to more than
> one file but possible options for ':tangle' don't give certain answer:
>
>   yes’
>
>Export the code block to source file.  The file name for the source
>file is derived from the name of the Org file, and the file extension
> is derived from the source code language identifier.
>Example: ‘:tangle yes’.
>
>   FILENAME
>
>Export the code block to source file whose file name is derived from
>any string passed to the ‘tangle’ header argument.  Org derives the
>file name as being relative to the directory of the Org file’s
>location.  Example: ‘:tangle FILENAME’.
>
> If I understand first choice correctly then the only source block ("the code
> block") will be tangled (exported) to a source file. What Org will do if
> there are several source blocks? Concatenate them or write to a file only
> last one? (I didn't test that).
>
> The same applies to 'FILENAME' case: what Org will do if there are several
> source code blocks with the same 'FILENAME' for ':tangle'.
>
> I would say that you use here undocumented feature and you workflow could be
> broken if in some future Org version developers decide to implement only
> documented features.

I am quite sure that if more than one blocks are tangled to the same file, then
the blocks must be concatenated.  There is at least one test in the test suite
which is designed to check precisely this behavior.

>
> > - Example 2
> >
> > https://gist.github.com/2bce5d6df3f04c934fb4beda0c6560ad
> >
> > This is my literate config for xkb maps; I have several keyboards, and
> > some of them require slightly different maps.
> >
> > Once again, likely all this can be accomplished by some noweb magic, but I
> > find my approach much less intrusive (particularly the initial bit in the
> > .zshrc, which I am still refactoring, where the list of tangle targets is
> > inferred from the headline tags)
>
> I found you way of doing things a bit strange. As I already told I use
> 'noweb' feature a lot. I won't advise you to use it or not to use it but I
> find it very powerful.
>
> > Thanks again for your comments. I'd really like to see how to do the same
> > with noweb and compare my approach with the "standard" one. Once more, I
> > hope these examples clarify my point of view.
>

Thanks, I will certainly have a good look.

> If you don't distract by foreign language (Russian) you could look how I use
> 'noweb' feature for scripts (one example):
>
> https://git.sr.ht/~vp1981/scripts/tree/master/item/docs/scripts/misc.org
>
> for shell configurations:
>
> https://git.sr.ht/~vp1981/scripts/tree/master/item/docs/shell/bash.org
>
> and for Emacs configuration:
>
> https://git.sr.ht/~vp1981/scripts/tree/master/item/docs/emacs/emacs.org
>
> > Best
> >
> >  Jacopo
>
> [...]
>
> ---
> WBR, Vladimir Lomov

Re: convert subtree or nested list to table

[Uwe Brauer]

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

> Hi Matt, sorry for the slow reply...

> Matt Price writes:

>> I'd love to try that, thanks. I think it would be really helpful. 
>> Much appreciated!

> Some previous caveats:

> - *The code is very raw*. I wrote it almost as a "proof of concept" for
>   my personal use, therefore it is quite improvable. In any case, it
>   works (but i don't know if it will help you get what you want...).

> - The attached example is optimized to export to LaTeX. Use the tabularx
>   environment, which is ideal for tables with a lot of textual content.
Sorry for jumping into that thread. I could not resist downloading your
code and trying it out.


> - As for the code, there are two basic functions:
>   `my-org/edit-table-cell' and
that worked. 

>   `my-org/kill-edit-table-cell-buffer-and-save'. To edit an empty cell,
>   you have to write something in that cell first.

When I changed the text in a cell and called that function I obtained
and error
,
| 
| Debugger entered--Lisp error: (wrong-number-of-arguments #f(compiled-function 
(arg) (interactive "*P") #) 2)
|   fill-paragraph(nil t)
|   (let ((fill-column (point-max)) (emacs-lisp-docstring-fill-column t)) 
(fill-paragraph nil region))
|   unfill-paragraph(t)
|   funcall-interactively(unfill-paragraph t)
|   call-interactively(unfill-paragraph)
|   my-org/kill-edit-table-cell-buffer-and-save()
|   funcall-interactively(my-org/kill-edit-table-cell-buffer-and-save)
|   call-interactively(my-org/kill-edit-table-cell-buffer-and-save record nil)
|   command-execute(my-org/kill-edit-table-cell-buffer-and-save record)
|   execute-extended-command(nil "my-org/kill-edit-table-cell-buffer-and-save" 
"my-org/k")
|   funcall-interactively(execute-extended-command nil 
"my-org/kill-edit-table-cell-buffer-and-save" "my-org/k")
|   call-interactively(execute-extended-command nil nil)
|   command-execute(execute-extended-command)
| 
`

I am running (a couple of week old) GNU emacs master and org-mode git
master. I even restarted my emacs session

What do I miss?

Regards

Uwe Brauer 


smime.p7s
Description: S/MIME cryptographic signature

Bug: Behavior of org-adapt-indentation [9.4.6 (9.4.6-10-gee652a-elpa @ /home/fsantos/.emacs.d/elpa/org-20210705/)]

[Frédéric Santos]

Hi!

This might not be *really* a bug, but since a recent update of Org, I
noticed an unwanted indentation of code blocks when the variable
org-adapt-indentation is set to 'headline-data. It can be reproduced
with this very minimal org config:

(use-package org
  :config
  (require 'org-tempo)
  (setq org-adapt-indentation 'headline-data))

In an org buffer, create a headline, and then:

1. Type some text which does *not* follow an empty line an press TAB:
nothing happens (which is the expected behavior).
2. Type some text which does follow an empty line an hit TAB: this text
gets indented according to the current headline level (the help page
looks unclear to me: it might also be the expected behavior,
although I don't really understand the rationale for it).

Point 2. has a side effect: when you still use the old template
expansion mechanism for code blocks (the one provided by org-tempo.el,
e.g. type https://www.zupimages.net/up/21/26/8b3n.gif

Is there a workaround to avoid this indentation of code blocks?

All the best,
Frédéric

==
Emacs  : GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.27, 
cairo version 1.17.4)
 of 2021-03-26
Package: Org mode version 9.4.6 (9.4.6-10-gee652a-elpa @ 
/home/fsantos/.emacs.d/elpa/org-20210705/)

Re: how to avoid 0.0 in an org-table

[Uwe Brauer]

>>> "RM" == Roger Mason  writes:

> Hello Uwe,
> Uwe Brauer writes:

>> I obtain 0.0 in the last column, this looks bad, any idea how to avoid
>> it?

> I think you can use a printf format specification in the formula.

Thanks I tried

#+begin_src elisp
| ||   |   |  Res | Min |
|-++---+---+--+-|
|   0 |  0 | 0 | 0 |0 | 0.0 |
| 1.2 | 10 | 1 | 1 | 13.2 | 0.1 |
#+TBLFM: $5=vsum($1..$4);f1::$6=min(10,$4)*0.1;f1 E
#+end_src

#+begin_src elisp
| ||   |   |  Res | Min |
|-++---+---+--+-|
|   0 |  0 | 0 | 0 |0 |   0.0 |
| 1.2 | 10 | 1 | 1 | 13.2 |   0.1 |
#+TBLFM: $5=vsum($1..$4);f1::$6=min(10,$4)*0.1;%0.1f
#+end_src


But it does not change, it seems if I want 0.1 I have to pay the price
to also obtain 0.0.

Regards

Uwe 



smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH] Allow tangling to a list of files

[Greg Minshall]

Vladimir,

> I couldn't find in Org manual how tangling should work if there are
> several source code blocks with the same file name for ':tangle'. The
> Org manual section "15.8 Extracting Source Code" is a bit
> obscure. There are these two sentences

i think what Tim answered is correct.  but, i believe the "desired"
approach is to put all those blocks to be tangled to the same file under
a headline with a property drawer containing something like:

:header-args+::tangle "submsim.jl"


i believe this is for performance of tangling, but possibly the
"multiple source blocks to same :tangle'd file" feature may disappear?

cheers, Greg