Re: simple code to use focus-mode with org

2020-04-23 Thread stardiviner
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


This looks interesting, thanks.

Marc Ihm  writes:

> Hi,
>
> when presenting things informally from org I often use the great focus-mode 
> (see
> https://github.com/larstvei/Focus) to keep my audience focused on the 
> individual
> nodes of my presentation:
>
>
> (defun forward-heading ( N)
>   "Forward one orgmode-heading for thing-at-point"
>   (interactive "p")
>   (if (= N -1)
>   (outline-previous-heading)
> (outline-next-heading)))
>
> (require 'thingatpt)
> (require 'focus)
>
> (setq focus-mode-to-thing '((org-mode . heading)))
> (focus-mode)
>
>
> The only interesting thing here is the trivial function forward-heading, which
> allows focus-mode to handle org-nodes and focus on them.
> The connection is made by setting focus-mode-to-thing; the symbol heading 
> leads
> focus-mode to invoke forward-heading, see the documentation of thingatpt for
> details.
>
> Hope someone finds this useful.
>
> regards,
> Marc


- -- 
[ 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-

iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl6icT8UHG51bWJjaGls
ZEBnbWFpbC5jb20ACgkQG13xyVromsOnMwf+IBLbJnh4WSk3BzK9syarP75MI0oc
G7LF6y9sBeDdTWJMcI0ogwmSWGN/AUbon8BLAcgUhemztAP91QXt94nb1hyZlQPR
qY5OgAjYFlEfM3kKWt+T2Uexb0eqwyjR4BPKkyCzvbppuUQ8RXvQuFvVrhOz0yoj
NB302fu94dMeBhtr3OKLpuKX7enl6UK3RH+Uw2/zCaAcpS1do/wbIEZ1/MwThQKN
SAqI0QH2gX9Bn7Dbdza3rSP7G17Eu8VDpgScfS+cHFtZoHzOIyodi9wRgQ0MlUBv
zgVFSr6qP+m/U/mvy9Zjf7zQWPEwiHiHxCmoh+7XWg4r71Wmvv2aU0ycGw==
=AQr+
-END PGP SIGNATURE-



simple code to use focus-mode with org

2020-04-23 Thread Marc Ihm

Hi,

when presenting things informally from org I often use the great 
focus-mode (see https://github.com/larstvei/Focus) to keep my audience 
focused on the individual nodes of my presentation:



(defun forward-heading ( N)
  "Forward one orgmode-heading for thing-at-point"
  (interactive "p")
  (if (= N -1)
  (outline-previous-heading)
(outline-next-heading)))

(require 'thingatpt)
(require 'focus)

(setq focus-mode-to-thing '((org-mode . heading)))
(focus-mode)


The only interesting thing here is the trivial function forward-heading, 
which allows focus-mode to handle org-nodes and focus on them.
The connection is made by setting focus-mode-to-thing; the symbol 
heading leads focus-mode to invoke forward-heading, see the 
documentation of thingatpt for details.


Hope someone finds this useful.

regards,
Marc




[RFC] DOCT: Declarative Org Capture Templates

2020-04-23 Thread No Wayman

* [RFC] DOCT: Declarative Org Capture Templates

I've been working on an alternative syntax for 
org-capture-templates.
The result is a package called "DOCT" (declarative org capture 
templates):


https://github.com/progfolio/doct

A brief list of what I believe to be improvements over the current 
syntax/implementation:


- 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.
You have a number of options:
- forget about whatever you wanted to capture and press on with 
 your original task
- manually take a note about what you originally wanted to capture 
 and another note to fix the broken template

- drop what you're doing and fix everything
None of these are ideal and all of them result in distraction.
DOCT performs a number of checks ahead of time when possible to 
prevent these types of errors.


- DOCT makes the parent/child relationship between templates 
 explicit.


`org-capture-templates` is a flat list. The relationship between 
templates is hardcoded in each template's "keys" value.
If you want to change the key for a top-level menu, you must then 
change it in each descendant's keys. DOCT uses nested plists

and implements property inheritance.

- DOCT manages per-template hooks/contexts.

Currently if you want to have a hook run for a particular 
template, you have to filter against `org-capture-plist' to check 
for the appropriate :key value.
As stated above, this is fragile and you have to update that key 
value in numerous places if it ever changes. The same goes for 
`org-capture-templates-contexts`.
DOCT allows specifying per-template contexts and hooks with the 
rest of the template's configuration.


- DOCT makes adding custom metadata to templates easy.

A common pattern for attaching data to a template is to add to 
`org-capture-plist'. This pollutes `org-capture-plist' more than 
necessary.
DOCT adds custom data to `org-capture-plist' under a single :doct 
keyword and allows users to access that data in the template 
string with familiar %-escape syntax.


This example is one I use daily for taking notes in programming 
projects:


#+begin_src emacs-lisp
(doct
`("Note"
  :keys "n"
  :file ,(defun my/project-note-file ()
   (let ((file (expand-file-name "notes.org" (when 
   (functionp 'projectile-project-root)

   
(projectile-project-root)
 (with-current-buffer (find-file-noselect file)
   (org-mode)
   ;;set to utf-8 because we may be visiting raw file
   (setq buffer-file-coding-system 'utf-8-unix)
   (when-let ((headline (doct-get :headline)))
 (unless (org-find-exact-headline-in-buffer 
 headline)

   (goto-char (point-max))
   (insert "* " headline)
   (org-set-tags (downcase headline
   (unless (file-exists-p file) (write-file file))
   file)))
  :template (lambda () (concat  "* %{todo-state} " (when 
  (y-or-n-p "link?") "%A\n") "%?"))

  :todo-state "TODO"
  :children (("bug"   :keys "b" :headline "Bugs")
 ("documentation" :keys "d" :headline 
 "Documentation")
 ("enhancement"   :keys "e" :headline "Enhancements" 
 :todo-state "IDEA")
 ("feature"   :keys "f" :headline "Features" 
 :todo-state "IDEA")
 ("optimization"  :keys "o" :headline 
 "Optimizations")
 ("miscellaneous" :keys "m" :headline 
 "Miscellaneous")

 ("security"  :keys "s" :headline "Security"
#+end_src

Each template inherits its parent's file finding function,template 
string, and a default :todo-state.
The template string access the child's :todo-state keyword with 
the "%{KEYWORD}" syntax in the template string.


I would be happy to work on getting these features into Org if 
there is any interest.

Any feedback is welcome.

Thanks, nv.


Re: #+BEGIN_SRC sh C-c C-c in Windows

2020-04-23 Thread Neil Cherry
On 4/23/20 2:15 AM, Robert Klein wrote:
> Hi,
> 
> On Wed, 22 Apr 2020 08:09:39 -0400
> Neil Cherry  wrote:
> 
>> I've searched for a resolution for this but haven't found one. I want
>> to be able to call a different command shell in Windows. What I keep
>> seeing is that it can't find /bin/sh
>>
>> #+BEGIN_SRC sh :results output
>> set
>> #+END_SRC
>>
>> I would prefer that I can change it to the bash shell in PortableGit.
>> Also I have no ability to add packages to the machine (other than
>> emacs). I don't have admin on this machine.
>>
>> Thanks
> 
> use
> 
> #begin_src bash ...

#+BEGIN_SRC sh bash :results value raw
  set
#+END_SRC

Hit C-c C-C in the block results in:

emacs returns /usr/bin/sh: sh: command not found

-- 
Linux Home Automation Neil Cherry   nche...@linuxha.com
http://www.linuxha.com/ Main site
http://linuxha.blogspot.com/My HA Blog
Author of:  Linux Smart Homes For Dummies



Re: Cannot export org mode to collapsible HTML

2020-04-23 Thread Daniel Clemente
> Is this happening because org-info.js is no longer being maintained?
Another solution I saw was Daniel Clemente's tool, though I am at a total
loss for what to specify in the org file to incorporate his esquemadorg.js
script. I appreciate any help that could let me export large org files to
HTML while having the headers be collapsible.

Sorry for the very late answer. I just added some instructions
 about what to add to
the .org file.
But it looks like the best way is to adapt any existing tool to your needs.
Collapsing/expanding headers isn't very hard — the harder parts are things
like how to make links keep working (e.g. links to sections which are now
collapsed should auto-open it).


On Wed, Nov 6, 2019 at 12:04 AM Kris Brown  wrote:

> Hi, I am trying to have basic folding functionality for my org file that
> has been exported to HTML. I am using Emacs 26.2 (9.0) and Org 9.1.9 on a
> Mac.
>
> This seems to be a built-in feature: JavaScript supported display of web
> pages
> .
> I downloaded my own copy of org-info.js
> . However, I cannot see any
> difference when I use the #+INFOJS_OPT commands or not (org with
> , org without
> , html with
> , html without
> ). I would expect
> to see collapsible headers and no TOC displayed when I use those commands.
>
> There *is* a difference in the generated HTML files (an extra CDATA
> region with a bunch of statements like: *org_html_manager.set("VIEW",
> "info");*) but nothing different visually.
>
> Is this happening because org-info.js is no longer being maintained
> ?
> Another solution I saw was Daniel Clemente's tool
> ,
> though I am at a total loss for what to specify in the org file to
> incorporate his esquemadorg.js script. I appreciate any help that could let
> me export large org files to HTML while having the headers be collapsible.
>


Re: Policy proposal: Do not move existing functions/macros except in major version increments

2020-04-23 Thread Nicolas Goaziou
Hello,

Adam Porter  writes:

> Of course, I am biased here, but I feel like it's not quite as
> exceptional as it ought to be.  The more Org-related packages I make and
> maintain, the more version-specific workarounds I have to add due to
> changed function names, signatures, etc.  These are sometimes necessary,
> of course, but I think they should be made more carefully and
> deliberately.
>
> Of course, Org doesn't make any promises to third-party packages.  But
> that is the issue, isn't it?  I'm saying that I think it should start
> taking this issue a little more seriously.  :)

[...]

> That is a matter of policy, which is what I'm proposing.  When such a
> change is desired (symbol name, function signature, etc), it should be
> targeted at the next major version increment.  If the project as a whole
> is not ready to make that increment, that change should be delayed until
> then--it can be developed in a branch and merged when preparing the
> major release.  These kinds of changes could even be documented in
> advance, e.g. in a ROADMAP or PLANS file, or whatever you want to call
> it, which would be more explicit and referenceable than merely a mailing
> list post.

I think it isn't a realistic policy, because it is not even close to how
Org development happens.

Unlike what you write, even with a smiley, I am taking compatibility
issues and breakages as seriously as I can. I do my best to not
introduce them in the first place, and, if I do, because I think that's
for the better, I do my best to make the transition easier. Yet,
breakage happens, and I am sincerely sorry about that. Now, fire me if
you want.

However, please remember that Org development happens in a best effort,
and in a somewhat opportunistic, fashion. Most internal changes, and
therefore breakages, stem off a bug report or an enhancement request,
not from a big ROADMAP file in the sky. Call it amateurism, but I think
it is in its most noble meaning.

Maybe in the not-so-distant future, professional-minded folks will lead
the project, defining road maps, strict rules for features integration,
proper issue tracking, and whatnot. And maybe that will be a good thing.
Any help is welcome. Until then, we have two branches:

1. master, where breakage can happen, which implies at least minor
   version numbers bumps.

2. maint, where breakage is to be avoided at all cost, which implies
   only bugfix version number bumps.

Close to a release, we also happen to have "feature-freeze" periods. In
that situation, development happens in a temporary third branch: next.

You may consider it to be an insufficient policy, but AFAICT, this is
all we have at the moment, and, possibly, all we can afford, too.

Of course, this is only my opinion. I wouldn't dare talking for other
developers. AFAIC, I already do all I can, with the time I have;
I cannot follow your policy.

> That is a good idea, and one that needs addressing.  I'd be glad to give
> some feedback on it, but in a separate thread, please, because it seems
> like a different matter from the issue I'm raising and the proposal I'm
> making.

I thought most third-party breakages came from misuse of internal
functions in Org. But if you say it is orthogonal, and that I am
off-topic, so be it.

Regards,

-- 
Nicolas Goaziou



Re: babel/noweb concatenation of equally-named code blocks fails?

2020-04-23 Thread Nicolas Goaziou
Hello,

Greg Minshall  writes:

> below is a format-patch.  i signed FSF papers for emacs a number of
> years ago (and for gawk more recently).

Perfect. I applied it. Thank you!

Regards,

-- 
Nicolas Goaziou



Re: Bug: Linking to plain text [9.3.6 (release_9.3.6-471-g9e385d @ c:/Users/awu/.emacs.d/straight/build/org-plus-contrib/)]

2020-04-23 Thread Nicolas Goaziou
Hello,

"Adriane Würfl"  writes:

> Detailed description:
> I link with M-l to store the link and with C-l to insert it (see below for 
> implementation).
> Normally I press M-l at the top of the .org file and it stores the following 
> link: file:~/Documents/.../filename.org
> If the first line is a empty line it works just like mentioned above and how 
> it's supposed to.
> But now if the first line in the file is plain text (eg jsdlj) it links to 
> file:~/Documents/.../filename.org::jsdlj; a behavior not wanted.
> I thought this is only possible with headings (* Heading); (that's why I 
> avoid using them in the first line of an .org file).
> Is this a bug or a newly added feature?

Neither :) I partly rewrote this part of links recently, but I didn't
add any feature. However, I probably uncovered some previous bugs. 

In this case, it seems to be the correct behaviour: see variable
`org-link-context-for-files' for an explanation and a solution.

WDYT?

-- 
Nicolas Goaziou



Bug: Linking to plain text [9.3.6 (release_9.3.6-471-g9e385d @ c:/Users/awu/.emacs.d/straight/build/org-plus-contrib/)]

2020-04-23 Thread Adriane Würfl

Hi there :)
 

I use a higly customized Emacs with org-mode. Lately I have a problem when creating Links between .org files. Rather than linking to the general file, the link will be to a specific position (not intended).
I know this is is a build-in function with Headings, but lately this even happens with plain text.

 

Detailed description:
I link with M-l to store the link and with C-l to insert it (see below for implementation).

Normally I press M-l at the top of the .org file and it stores the following link: file:~/Documents/.../filename.org
If the first line is a empty line it works just like mentioned above and how it's supposed to.
But now if the first line in the file is plain text (eg jsdlj) it links to file:~/Documents/.../filename.org::jsdlj; a behavior not wanted.
I thought this is only possible with headings (* Heading); (that's why I avoid using them in the first line of an .org file).

Is this a bug or a newly added feature?


Implementation in customized init.el file (no further changes were made to the linking functions):

;; Links & Embedding
(advice-add #'org-insert-link :after #'org-display-inline-images)
(global-set-key (kbd "C-l") 'org-insert-link)
(global-set-key (kbd "M-l") 'org-store-link)


Emacs  : GNU Emacs 26.1 (build 1, x86_64-w64-mingw32)
 of 2018-05-30
Package: Org mode version 9.3.6 (release_9.3.6-471-g9e385d @ c:/Users/awu/.emacs.d/straight/build/org-plus-contrib/)

 

 

Disposition-Notification-To: adriane.wue...@gmx.at




Re: #+BEGIN_SRC sh C-c C-c in Windows

2020-04-23 Thread Robert Klein
Hi,

On Wed, 22 Apr 2020 08:09:39 -0400
Neil Cherry  wrote:

> I've searched for a resolution for this but haven't found one. I want
> to be able to call a different command shell in Windows. What I keep
> seeing is that it can't find /bin/sh
> 
> #+BEGIN_SRC sh :results output
> set
> #+END_SRC
> 
> I would prefer that I can change it to the bash shell in PortableGit.
> Also I have no ability to add packages to the machine (other than
> emacs). I don't have admin on this machine.
> 
> Thanks

use

#begin_src bash ...


Best regards
Robert