Re: [O] FW: [RFC] Link-type for attachments, more attach options

[stardiviner]

Gustav Wikström  writes:

> FYI, pushed to master. Commit 26ace9004

Thanks

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

Re: Issues with nested begin..end blocks in inline math environments

[Matt Huszagh]

I'm submitting this as a patch. I've used it on hundreds of latex
fragments over the past week or so and haven't experienced any issues
(which is expected since the change is small).

>From a699b699ed4132839c39f1152868bb13364422c7 Mon Sep 17 00:00:00 2001
From: Matt Huszagh 
Date: Sat, 14 Dec 2019 19:54:41 -0800
Subject: [PATCH] org-element.el: allow environment blocks in math delimiters

* lisp/org-element.el (org-element--latex-begin-environment): Add a
non-capturing block for `\(' or `$' so that previously recognized
latex environments can also appear within an inline math environment.

* lisp/org-element.el (org-element--latex-end-environment): Match the
begin environment noncapturing block with `$' or `\)'.
---
 lisp/org-element.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisp/org-element.el b/lisp/org-element.el
index 110ff5624..6d7ec32c6 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -,14 +,14 @@ containing `:key', `:value', `:begin', `:end', `:post-blank' and
  Latex Environment
 
 (defconst org-element--latex-begin-environment
-  "^[ \t]*begin{\\([A-Za-z0-9*]+\\)}"
+  "^[ \t]*\\(?:(\\|\\$\\)?begin{\\([A-Za-z0-9*]+\\)}"
   "Regexp matching the beginning of a LaTeX environment.
 The environment is captured by the first group.
 
 See also `org-element--latex-end-environment'.")
 
 (defconst org-element--latex-end-environment
-  "end{%s}[ \t]*$"
+  "end{%s}[ \t]*\\(?:)\\|\\$\\)?$"
   "Format string matching the ending of a LaTeX environment.
 See also `org-element--latex-begin-environment'.")
 
-- 
2.24.0

Re: Removing horizontal space in latex fragments

[Matt Huszagh]

Nicolas Goaziou  writes:

> So, has anyone settled on which one to apply?

My vote goes for keeping the newlines to improve readability in the
generated tex file. But, again, I'm more than happy to be overuled.

> Minor nitpick:
>
>   (if (string-suffix-p string "\n") ...)
>
> is slightly less low-level.

Appreciate the nitpick; your version is better!

I've attached an updated patch.

Best,
Matt

>From bdb93a13a43d90ad6e66449797111e836a67a219 Mon Sep 17 00:00:00 2001
From: Matt Huszagh 
Date: Thu, 5 Dec 2019 23:25:32 -0800
Subject: [PATCH] org.el: Remove leading/trailing whitespace from latex
 fragment

* lisp/org.el (org-create-formula-image): Ensure user input ends
with a % character to remove trailing whitespace. Also, add %
characters between macros and newlines purely visual.
---
 lisp/org.el | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 9b84592ba..ae686e330 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -16554,12 +16554,17 @@ a HTML file."
 	(setq bg (org-latex-color :background))
   (setq bg (org-latex-color-format
 		(if (string= bg "Transparent") "white" bg
+;; remove tex \par at end of snippet to avoid trailing
+;; whitespace
+(if (string-suffix-p string "\n")
+(aset string (- (length string) 1) ?%)
+  (setq string (concat string "%")))
 (with-temp-file texfile
   (insert latex-header)
   (insert "\n\\begin{document}\n"
-	  "\\definecolor{fg}{rgb}{" fg "}\n"
-	  "\\definecolor{bg}{rgb}{" bg "}\n"
-	  "\n\\pagecolor{bg}\n"
+	  "\\definecolor{fg}{rgb}{" fg "}%\n"
+	  "\\definecolor{bg}{rgb}{" bg "}%\n"
+	  "\n\\pagecolor{bg}%\n"
 	  "\n{\\color{fg}\n"
 	  string
 	  "\n}\n"
--
2.24.0

Re: [Idea] Org Collections

[Eric Abrahamsen]

Tim Cross  writes:


[...]

> Its a +1 from me. 

And me -- I use Org across so many different contexts (in fact, I'd
propose the name org-contexts over org-collections \end{bikeshed}),
sometimes using the /same data in different contexts/, and while Org has
good tools for localizing config options, it's never felt "clean".

I agree with Tim's point about starting with a limited approach:
restrict it to namespaced collections of config options, and see if
that's sufficient.

Eric

Re: [Idea] Org Collections

[Tim Cross]

In general, I like the idea. While you are correct that most of what you
refer to can be achieved using existing org functionality, I like the
clear separation 'collections' would offer - it is like a namespace for
a collection of org documents. I like the idea of being able to isolate
customization/configuration on a per collection basis - it would
simplify some of my existing customisation plus I could experiment with
new/alternative setups in a manner which is less likely to adversely
impact my existing setup. I also suspect agenda generation and searching
could become more efficient if we can easily isolate such activities to
a collection (would still want 'global' options though). 

I would start by keeping it as simple as possible and I would restrict
configuration options (at least initially) to make things cleaner to
begin with. The .dir-locals approach has some benefits, but I've lost
count of the amount of time wasted trying to track down some
unwanted/incorrect setting only to realise it was from a .dir-locals I'd
forgotten about.

I do work in a number of different contexts - different employers,
contracts, etc. Currently, tags and properties are very useful in such
contexts. However, complete separation of these concerns into
collections sounds very appealing. Setup for a new contract/project
would be very simple and managing the different requirements would be
much easier (for example, these days, I often have to produce documents
with the correct format, logo, colour scheme etc). I have a growing set
of document style definitions that would be easier to manage on a per
collection basis rather than as a global setting).

In some of my work, I have restrictions on where data can be
stored. For example, I might be required to store all documents, data
etc relating to one contract only on a storage device owned by the
contractor. At the same time, I don't want any of my personal or
unrelated contract data stored on the corporate storage server. This can
be a little challenging when it comes to things like capture or
attachments. However, if I could have collections with completely
different 'roots' and have all my capture templates and attachment
actions apply relative to that root, then life might be easier.

Its a +1 from me. 

Gustav Wikström  writes:

> Hi list and all honored readers!
>
> I have an idea. One that I've mentioned before in side notes. And I want to 
> emphasize that this still only is an idea. But I want to present this idea to 
> you. As a way to gather feedback and get input. Maybe the idea is stupid!? 
> Maybe you think it's already solved? Or maybe it's not, and lots of you 
> resonate with it as well. In any case, please let me know what you think on 
> the piece below!
>
> 
>
>  ORG MODE: COLLECTIONS/PROJECTS
>
> Gustav Wikström
> 
>
>
> Table of Contents
> _
>
> 1. Motivation
> 2. Idea
> 3. Benefit
> .. 1. For the user
> .. 2. For the developer
> 4. Example use cases
> .. 1. Separate actions from reference
> .. 2. Work / Personal separation
> .. 3. Separated book library
> .. 4. More?
> 5. Risks and challenges
> .. 1. Which configuration to use?
> .. 2. Should project config allow local variables?
> . 1. How to initialize the local variables?
> .. 3. Conflict with other customizations
> .. 4. Files that belong to multiple collections
> .. 5. Dynamic lists of files and folders for a collection?
> 6. Alternatives
> 7. References
>
>
> 1 Motivation
> 
>
>   Org mode is more than a major mode for emacs buffers. That has been
>   clear for quite some time. Org mode can operate on sets of files.
>   Consolidate TODO's and calendar information into custom views. Publish
>   sets of files. To do this Org mode assumes that the user has a
>   configuration for each of those features. Each feature is responsible
>   for maintaining its own context. And almost all of that context has
>   to be set globally. So even though Org mode has commands and features
>   that operate on sets of files and folders it has not yet developed
>   that in a congruent, extensible and composable way. Thus, for the
>   sanity of our users and developers I think it's time to ... introduce
>   another concept! One that hopefully can simplify things both for users
>   and developers.
>
>
> 2 Idea
> ==
>
>   I propose to introduce `Collection' as a concept in the realm of Org
>   mode. [1]
>
>   An Org mode collection is defined as the combination of:
>   1. A short name and description
>   2. A collection of Org mode documents
>   3. A collection of files and/or folders called attachments and
>  attachment-locations for the project
>   4. A collection of configurations for the given project
>
>   Globally available collections are defined in a list,
>   `org-collections'. Org mode should include a safe parameter 

Re: Bug: Orgguide missing in Org-9.3 package [9.3 (9.3-elpa @ /home/David/.emacs.d/elpa/org-9.3/)]

[Nicolas Goaziou]

Hello,

Kyle Meyer  writes:

> Nicolas Goaziou  writes:

> Sorry, I don't have write access.  But this issue seems to be about the
> Org ELPA tarball, so I don't understand how it'd be related to the
> recent Org sync with the Emacs repo.

That's because I misread the bug report and though it was related to
Emacs master branch.

In any case, Org ELPA tarball and files merged with Emacs are two
different things. IOW, even if ELPA tarball contains the Org guide, it
is not sufficient for Emacs to ship it, too. So this also needs to be
fixed on the Emacs' side, AFAIU.

> Checking the tarball at  as
> well as some recent ones at , I didn't spot
> orgguide in any of them.  And when I run `make elpa' from the Org repo,
> the tarball indeed seems to be missing the orgguide info file.  Assuming
> there's not a good reason that orgguide is omitted, I think fixing this
> is just a matter of adding orgguide to server.mk's ORGELPA variable.

I have no objection, but, per above, we should check if there's
something to do in the Emacs repository, too.

Regards,

-- 
Nicolas Goaziou

Re: [PATCH] Fix verbatim block fontification to end blocks on headlines

[Nicolas Goaziou]

Hello,

Tom Gillespie  writes:

> I've written some basic tests for this and I couldn't find any other
> tests that seemed to deal with fontification at all. In order to get
> fontification tests to work I added a call to `font-lock-ensure' inside
> `org-test-with-temp-text' (see excerpted patch bit below). Given how
> frequently `org-test-with-temp-text' is used, does it make sense to
> create a separate version of that macro just for testing with
> fontification? I have no idea what the performance impact would be, so
> any guidance is appreciated.

FWIW, I simply suggest not bothering writing tests for fontification.

Regards,

-- 
Nicolas Goaziou

Re: Removing horizontal space in latex fragments

[Nicolas Goaziou]

Hello,

Matt Huszagh  writes:

> Thanks for the reply Eric. The thing I like about the newlines is that the
> generated tex files are slightly easier to read. However, this is really
> minor. I've created 2 separate patches: one keeping the newlines and the
> other without. I'm happy to defer to you or anyone else in regard to which
> is preferable.

So, has anyone settled on which one to apply?

> +;; remove tex \par at end of snippet to avoid trailing
> +;; whitespace

  Remove TeX \par at end of... trailing space.

> +(if (string= (substring string -1 nil) "\n")

Minor nitpick: 

  (if (string-suffix-p string "\n") ...)

is slightly less low-level.

Thank you.

Regards,

-- 
Nicolas Goaziou

[Idea] Org Collections

[Gustav Wikström]

Hi list and all honored readers!

I have an idea. One that I've mentioned before in side notes. And I want to 
emphasize that this still only is an idea. But I want to present this idea to 
you. As a way to gather feedback and get input. Maybe the idea is stupid!? 
Maybe you think it's already solved? Or maybe it's not, and lots of you 
resonate with it as well. In any case, please let me know what you think on the 
piece below!



 ORG MODE: COLLECTIONS/PROJECTS

Gustav Wikström



Table of Contents
_

1. Motivation
2. Idea
3. Benefit
.. 1. For the user
.. 2. For the developer
4. Example use cases
.. 1. Separate actions from reference
.. 2. Work / Personal separation
.. 3. Separated book library
.. 4. More?
5. Risks and challenges
.. 1. Which configuration to use?
.. 2. Should project config allow local variables?
. 1. How to initialize the local variables?
.. 3. Conflict with other customizations
.. 4. Files that belong to multiple collections
.. 5. Dynamic lists of files and folders for a collection?
6. Alternatives
7. References


1 Motivation


  Org mode is more than a major mode for emacs buffers. That has been
  clear for quite some time. Org mode can operate on sets of files.
  Consolidate TODO's and calendar information into custom views. Publish
  sets of files. To do this Org mode assumes that the user has a
  configuration for each of those features. Each feature is responsible
  for maintaining its own context. And almost all of that context has
  to be set globally. So even though Org mode has commands and features
  that operate on sets of files and folders it has not yet developed
  that in a congruent, extensible and composable way. Thus, for the
  sanity of our users and developers I think it's time to ... introduce
  another concept! One that hopefully can simplify things both for users
  and developers.


2 Idea
==

  I propose to introduce `Collection' as a concept in the realm of Org
  mode. [1]

  An Org mode collection is defined as the combination of:
  1. A short name and description
  2. A collection of Org mode documents
  3. A collection of files and/or folders called attachments and
 attachment-locations for the project
  4. A collection of configurations for the given project

  Globally available collections are defined in a list,
  `org-collections'. Org mode should include a safe parameter that can
  be set as a folder customization to the local active project,
  `org-collections-active'. The default should be to the first entry in
  `org-collections' unless customized. This local parameter would be
  used to instruct Emacs and Org mode on which collection is active.
  Only one collection at a time can be active.

  Org agenda should use `org-collections-active' as default for the
  collection of Org mode documents to operate on. Org agenda should get
  a new command to switch between active projects.

  I'm thinking that there could be a special Emacs major mode for the
  collection as well, called "Org collections mode". Not sure exactly
  what to display and how to represent the project there... But
  certainly some kind of list of included documents and attachments.
  When in that mode there should possibly be single key
  keyboard-shortcuts to the most important features that operate on the
  collection. And switch between them.


3 Benefit
=

3.1 For the user


  A user would gain mainly two benefits as I can see right now:
  1. The ability to clearly define (multiple) collections of files that
 belong together across org mode, with unique configurations.
  2. Less global configuration state to manage and worry about!

  The second point might not look like much but is sooo important! Most
  programmers know that global state should be avoided. Putting things
  in a context most of the time makes things better. And if we can
  configure Org mode connected to a context it makes it much more useful
  for those who use Org mode for multiple purposes.

  The first point is equally important in my opinion. Today one must
  configure Org mode per feature. If you want to configure publishing
  you do that globally. If you want to configure the agenda, you have to
  do that globally as well. If you want to define a location for
  attachments, do it globally! What about custom TODO-keywords? Do it
  globally! Track ID-locations? Define a location globally!

  All above adds cognitive load to the user and makes it difficult to
  maintain the configuration as the use of Org mode grows (as it should
  ;) ). You have to define the context for each and every feature for it
  to know what to operate on. I claim that both the human psyche and the
  system itself will have a much more easy time if it could configure
  these features together, in a given context!