Re: Suggestion for org-agenda-list: pre-open org-agenda-files

[John Wiegley]

Understood, I just haven’t had the time to dig into this. I’ll let you know 
once I find out.

John

On Sat, Mar 16, 2024, at 12:46 AM, Ihor Radchenko wrote:
> Ihor Radchenko  writes:
>
>> Ihor Radchenko  writes:
>>
>>> So, may you dig a bit further and check why `org-agenda-prepare' is not
>>> opening the agenda files?
>>
>> A gentle ping :)
>
> Canceled.
>
> -- 
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 

Suggestion for org-agenda-list: pre-open org-agenda-files

[John Wiegley]

Recently I switched all of my Org files from “properties at the bottom” to
“properties at the top”, in order to avoid maintaining my own fork with this
capability. Although that fork had been working well, Ihor had a good argument
that I’m potentially opting myself out of 3rd party tools by veering from what
has become the standard format.

Right away I discovered one of the reasons I had preferred properties at the
bottom: When I startup my Emacs and run org-agenda-list, and then hit RET on
an entry, no folding has been applied to the Org file and thus I see the full
property block at the beginning of entries (and in my case, they can often be
quite large). I have to scan down to find the actual text.

Reading through the code, I found that org-agenda-list calls
org-agenda-get-day-entries on each file in org-agenda-files, which
intentionally disables code folding before opening the file if it isn’t open
already:

  (defun org-agenda-get-day-entries (file date  args)
(let* ((org-startup-folded nil)
  …)))

My workaround for this is to visit every entry in org-agenda-files before
calling org-agenda-list:

  (require 'org-agenda)
  (mapc #’find-file-noselect org-agenda-files)
  (call-interactively 'org-agenda-list)

I’m wondering whether we might want to provide a customization option to do
this automatically at the top of org-agenda-list, for any org-agenda-files
that aren’t already in buffers, since proper folding can make a big difference
when visiting Org entries from the Agenda.

--
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2

Re: [POLL] [BUG] Inverse behavior from \ [9.6.4 (release_9.6.4-1-g76cf21 @ /Users/johnw/.emacs.d/lisp/org-mode/lisp/)]

[John Wiegley]

>>>>> Ihor Radchenko  writes:

> No further votes.
> I am thus leaving the current behavior.
> Closed, poll.
> Canceled, bug.

Understood, thank you very much for the consideration. I’m training my fingers
to the current behavoir.

-- 
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2

Re: [POLL] [BUG] Inverse behavior from \ [9.6.4 (release_9.6.4-1-g76cf21 @ /Users/johnw/.emacs.d/lisp/org-mode/lisp/)]

[John Wiegley]

>>>>> "IR" == Ihor Radchenko  writes:

IR> It would be nice to bisect down to the commit that changed the behaviour.
IR> As it usually goes with agenda, consequences of some changes are not
IR> always straightforward.

I have found the cause of the change in behavior:

  (org-agenda-filter-make-matcher '("+" . nil) 'tag)
=> 8.2.4: (and (not tags))
=> 9.6.6: (and (or tags))

This occurred during the refactoring in:

  commit 6c6ae990c10dbe7f96b24fccf840fe9f6d81a3b8
  Author: Gustav Wikström 
  Date:   Sat Jan 24 02:47:35 2015 +0100
  
  org-agenda: Filtering in the agenda on grouptags

  […]
  
  * lisp/org-agenda.el (org-agenda-filter-make-matcher): new optional
argument EXPAND and refactoring.

The change was released in 8.3, which is why I never noticed it, because I
upgraded from 8.2.4 directly to 9.6.

Since the documentation also mentions that space means “any tag”, I guess now
it’s a design question: Should  mean “no tags” or “any tag”? I feel
like it should mean “no tag” only because you also use space to clear all tags
in the agenda after pressing “:”.

If the decision is “desired behavior”, then the muscle memory needed is
‘\ - ‘ rather than ‘\ ‘. Still feels odd for space to mean
anything rather than nothing, though… I mean, space is empty, right? :)

-- 
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2

Re: [POLL] [BUG] Inverse behavior from \ [9.6.4 (release_9.6.4-1-g76cf21 @ /Users/johnw/.emacs.d/lisp/org-mode/lisp/)]

[John Wiegley]

>>>>> "IR" == Ihor Radchenko  writes:

IR> Are you sure?
IR> I can see 124017b6d that changes

IR> (setq org-agenda-tag-filter
IR> (cons (concat (if exclude "-" "+") tag)
IR>   current))

IR> to

IR> (setq org-agenda-tag-filter
IR> (cons (concat (if exclude "-" "+") tag)
IR>   (if accumulate current nil)))

IR> The former would leave the current filter unchanged.

IR> It would be nice to bisect down to the commit that changed the behaviour.
IR> As it usually goes with agenda, consequences of some changes are not
IR> always straightforward.

Since my data should all still be compatible with the old version I was using,
I’ll see if I can bisect this. I know I was used to that binding, but I’m not
100% certain it wasn’t due to extenuating factors in my configuration.

-- 
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2

Re: [POLL] [BUG] Inverse behavior from \ [9.6.4 (release_9.6.4-1-g76cf21 @ /Users/johnw/.emacs.d/lisp/org-mode/lisp/)]

[John Wiegley]

>>>>> Ihor Radchenko  writes:

> Changing the current behaviour will be a breaking change.
>
> I am inclined to change the current behaviour and document it, unless there
> are objections.

I would also note that in Org-mode 8 and earlier, ‘/ ’ would limit to
all untagged entries, which is why I had that expectations.

-- 
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2

[BUG] Inverse behavior from \ [9.6.4 (release_9.6.4-1-g76cf21 @ /Users/johnw/.emacs.d/lisp/org-mode/lisp/)]

[John Wiegley]

When I type ‘\ c’, the agenda view limits to my (c)all tags. This is what I
expected to see.

When I type ‘\ ’, however, it limits to every tag *but* the empty tag.
This is the opposite of what I expect to see.

Emacs  : GNU Emacs 28.2 (build 1, x86_64-apple-darwin22.5.0, Carbon Version 169 
AppKit 2299.6)
Package: Org mode version 9.6.4 (release_9.6.4-1-g76cf21 @ 
/Users/johnw/.emacs.d/lisp/org-mode/lisp/)
-- 
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2

Re: [ANN] lisp/ob-tangle-sync.el

[John Wiegley]

>>>>> "MT" == Mehmet Tekman  writes:

MT> - skip :: do nothing, just save the buffer, even if the sync mode is
MT>   active
MT> - pull :: only pull changes from =~/.bashrc= into the Emacs_conf org-mode 
file
MT> - export :: only export changes from Emacs_conf to =~/.bashrc=, even if 
called
MT> from =~/.bashrc=

For the sake of consistency, perhaps import and export, rather than pull and
export? And, great idea!

-- 
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2

Re: Allowing :PROPERTIES: drawer to appear at the end of entries

[John Wiegley]

Having said this, I recognize that since I’m likely the only person to use the 
feature, I’m asking you to take on testing and maintenance of a change that 
goes against established design. So on second thought, never mind. I can 
maintain the changes in a local fork, since I appreciate that a small change 
like this can lead to big headaches if not enough other people are actively 
using it.

John

On Wed, Apr 26, 2023, at 1:25 AM, John Wiegley wrote:
>>>>>> "IR" == Ihor Radchenko  writes:
>
> IR> Sorry, but I am against this feature.
> IR> The original motivation why we restricted the property drawers to be
> IR> only right at the beginning of a heading in Org 8.3 was performance.
> IR> See https://list.orgmode.org/orgmode/87oatek909@nicolasgoaziou.fr/
>
> I should be able to choose to trade performance for layout. It's my data.
> Since this does not impair the performance of those who do not opt in for
> this feature, it seems an unnecessary restriction to prevent it.
>
> --
> John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
> http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2

Re: Allowing :PROPERTIES: drawer to appear at the end of entries

[John Wiegley]

>>>>> "IR" == Ihor Radchenko  writes:

IR> Sorry, but I am against this feature.
IR> The original motivation why we restricted the property drawers to be
IR> only right at the beginning of a heading in Org 8.3 was performance.
IR> See https://list.orgmode.org/orgmode/87oatek909@nicolasgoaziou.fr/

I should be able to choose to trade performance for layout. It's my data.
Since this does not impair the performance of those who do not opt in for
this feature, it seems an unnecessary restriction to prevent it.

--
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2

Allowing :PROPERTIES: drawer to appear at the end of entries

[John Wiegley]

ning-line-re) (forward-line
- (cond ((looking-at org-property-drawer-re)
+ (cond ((and (< (point) end)
+ (if org-allow-properties-at-end
+ (and (re-search-forward org-property-drawer-re
+ (save-excursion
+   (outline-next-heading)
+   (point)) t)
+  (goto-char (match-beginning 0)))
+   (looking-at org-property-drawer-re)))
 (forward-line)
 (cons (point) (progn (goto-char (match-end 0))
 			 (line-beginning-position
@@ -20600,7 +20610,8 @@ properties, clocking lines and logbook drawers."
   ;; Skip planning information.
   (when (looking-at-p org-planning-line-re) (forward-line))
   ;; Skip property drawer.
-  (when (looking-at org-property-drawer-re)
+  (when (and (not org-allow-properties-at-end)
+ (looking-at org-property-drawer-re))
 (goto-char (match-end 0))
 (forward-line))
   ;; When FULL is not nil, skip more.

--
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2

Re: The meaning of / inverted in the agenda

[John Wiegley]

>>>>> Ihor Radchenko  writes:

> What am I missing?

My apologies, I really don't know what errant behavior had crept into my
configuration, but even now as I tried the steps, I saw that it had flipped
again, making the "fix" I proposed entirely incorrect, as you surmised. This
is really quite strange, I'm not even sure how my configuration had led to an
inversion of the tag filtering behavior.

Anyway, I reverted that change and now all things are working fine. Sorry
again for the noise.

-- 
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2

Re: The meaning of / inverted in the agenda

[John Wiegley]

>>>>> Ihor Radchenko  writes:

> "John Wiegley"  writes:
>> In previous version of Org-mode, I was used to "/ t" showing me only
>> entries that matched the tag keyed by 't'. Now it hides them instead.

> May you please provide a reproducer or at least more details?

- Enter the Org-agenda
- Press '/ t' to filter by the tag identified by 't'
- Note that it hides those tags, rather than showing only those tags

> which is fishy because "+" for "exclude" does not look right.

My thoughts too.

--
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2

The meaning of / inverted in the agenda

[John Wiegley]

In previous version of Org-mode, I was used to "/ t" showing me only entries
that matched the tag keyed by 't'. Now it hides them instead. I was able to
fix this using:

modified   lisp/org-agenda.el
@@ -8578,7 +8578,7 @@ also press `-' or `+' to switch between filtering and 
excluding."
   (org-agenda-filter-show-all-tag)
   (setq tag (car a))
   (setq org-agenda-tag-filter
-   (cons (concat (if exclude "-" "+") tag)
+   (cons (concat (if exclude "+" "-") tag)
  (if accumulate current nil)))
   (org-agenda-filter-apply org-agenda-tag-filter 'tag expand))
  (t (error "Invalid tag selection character %c" char)

The documentation for '/' says that "Keep only those lines in the agenda
buffer that have a specific tag.", so I'm pretty sure the current behavior is
a bug?

--
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2

Re: [O] Key binding popup interface

[John Wiegley]

>>>>> "SM" == Stefan Monnier <monn...@iro.umontreal.ca> writes:

SM> I have no opinion on that part, but if a part of Hydra would be useful for
SM> other packages, then it'd be good to split it out: for me "Hydra" means
SM> "define a Hydra via defhydra or something like that", so if you tell me to
SM> use Hydra to "show the available valid key bindings", I wouldn't know
SM> where to start.

Plus, there are other, less intrusive way to achieve "show the available valid
key bindings", such as the which-key package.

I think one area where Hydras come into their own is that once you have the
Hydra active, it stays active, allowing you to chain together many single-
letter commands.

For example, you could have a hydra for "large-scale syntactic structures",
where repeated uses of n/p are mapped to what C-c C-n and C-c C-p usually do
in modes like cc-mode.

-- 
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2

Re: [O] Sync up the org in emacs master to org maint branch?

[John Wiegley]

>>>>> "DE" == David Engster <d...@randomsample.de> writes:

DE> I find this whole core vs package argument strange. If you ship Emacs with
DE> Org, Gnus and CEDET, they are part of Emacs, so it's in the interest of
DE> all Emacs developers that they work well, whether they use them or not.
DE> The users won't care if they originate from a separate repo and are
DE> considered a "package". So if Paul is determined to fix all occurences of
DE> "compatilibity" in the doc-strings, why would he only do that for core?

If pulling Emacs.git also pulls ELPA.git (as it should, since it's within our
purview as well), then global search should still affect all the
files.

I hear your other points, so I'm curious now as to what more people think
about this who work on Emacs core: Do you want more modularity with regard
ELPA, or does the monolithic model work better for you?

-- 
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2

Re: [O] Sync up the org in emacs master to org maint branch?

[John Wiegley]

>>>>> "PL" == Phillip Lord <phillip.l...@russet.org.uk> writes:

PL> The alternative proposal is, essentially, to copy files into the Emacs
PL> core build structure and move from there.

PL> Reading the discussion reinforces my feeling that the latter is the wrong
PL> approach, because it reinforces a distinction between packages on ELPA and
PL> packages in core above and beyond the location that they are stored and
PL> versioned. I can't see the advantage of doing this.

PL> I will probably try to work a little further on my package.el solution,
PL> although there seems little enthusiasm for this as the way forward.

Correct, I don't want to move forward with the package.el option yet. Just
copying files into the core build structure should be very lightweight, and it
lets us focus on the ELPA separation first. I believe the package.el coupling
is something we can examine at a later date.

-- 
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2

Re: [O] Using CEDET modules from Emacs core

[John Wiegley]

>>>>> "SM" == Stefan Monnier <monn...@iro.umontreal.ca> writes:

SM> For one, I'd like to see more major modes come with support for Semantic
SM> right in the major mode's own definition (rather than have it part of
SM> CEDET). E.g. for Elisp mode, CC-mode, ...

SM> The idea is to get to the point where Semantic support is just another
SM> thing that a major mode should aim to support alongside syntax-tables,
SM> indentation, font-lock, outline-minor-mode, ...

Is the semantic support really at the point of warranting that? Does it have
many users currently? Is it something major-modes would want to include
default support for?

The last time I tried it, for C++ code, it was far too slow. Are you saying
it's effective for other languages, like Python or Javascript or Go?

-- 
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2

Re: [O] Sync up the org in emacs master to org maint branch?

[John Wiegley]

>>>>> "DE" == David Engster <d...@randomsample.de> writes:

DE> So if you don't get convinced, we'll just move again, right? No big deal.

I suppose I'm asking that of you, yes.

DE> You are insinuating that my motivation is to delegate CEDET development to
DE> the core Emacs developers. This is simply not true, and I don't see how my
DE> original mail could be interpreted like that.

I didn't mean to insinuate anything; it seems we may have gotten off on the
wrong foot, my intention is to make your life easier, not harder. If all this
would do is make more work for people, it's not worth it.

DE> So let me try again: What I find completely misguided is to move packages
DE> out of core *but still putting them into the release*. In other words, in
DE> my opinion there are really just two options that make sense: you either
DE> keep a package in core, or you kick it out and don't ship it with the
DE> release.

Why is this so? Right now I see the Emacs release as more than just releasing
Emacs core; it's more of a "batteries included" release, combining the editor
with lots of other default packages. It makes sense to me to move these
batteries outside the core repository, than to put them all together in the
same Git repository.

We can arrange things so that a Git clone of Emacs includes pulling the
submodules (or trees, or ELPA.git, or what not) that are considered part of
"main Emacs development", including some of those batteries. I see this all as
a process issue, and that "living in one Git repository" has just been an
implementation strategy to satisfy that process.

Why do the split at all? Core becomes smaller, its future history less
cluttered, updating packages within it is no longer a major issue, and (I
hope) it will be clearer when something is a core issue vs. a package issue.
Also, people wanting to contribute new code to Emacs will not feel we're
consigning them to disuse by saying it will go in ELPA. I've seen a few
arguments already for things going into core, just to ensure more people would
use it.

DE> Say the Python developers would decide: Hey, many people like Django, so
DE> let's just put their latest git master into our release and ship it. Would
DE> you think that is a good approach?

Some companies have actually done this. I remember when ActivePython bundled
quite a few things, making it an attractive alternate to installing core
Python (back when package management was still very poor in Python world).

-- 
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2

Re: [O] Sync up the org in emacs master to org maint branch?

[John Wiegley]

>>>>> "EJS" == Edward John Steere <edward.ste...@gmail.com> writes:

EJS> What I think that we shouldn't lose sight of (if I may suggest it): is
EJS> that packaging CEDET, Org Mode and other packages like them in a process
EJS> which integrates them only when producing the tarball would serve to
EJS> simplify things for everyone. Emacs core wouldn't be able to depend on
EJS> packages which are more relevant to the users (and package developers) of
EJS> Emacs, but these packages would still there like they always have been
EJS> when one downloads binary Emacs.

This is the very point I was hoping to make, thanks Edward. If it can simplify
things for everyone, great; if it really will only complicate things, not so
great.

Many software projects have package ecosystems surrounding them that deal with
similar issues, and I can't, off-hand, think of cases where the answer was
"let's move some of those packages into core development to ease ___". This is
why I find it a bit surprising that some feel so strongly about keeping these
large, external packages in core.

-- 
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2

[O] Using CEDET modules from Emacs core

[John Wiegley]

>>>>> "SM" == Stefan Monnier <monn...@iro.umontreal.ca> writes:

SM> 2- We wanted to integrate it more tightly with Emacs (not in terms of
SM>bug-tracking and releasing schedule, but in terms of making it
SM>possible for generic Emacs code to use some of CEDET, and to
SM>encourage more major modes and other features to use CEDET).

Hi Stefan,

Can you clarify what the plans are here?  Which CEDET features would we want
to use from core?

-- 
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2

Re: [O] Sync up the org in emacs master to org maint branch?

[John Wiegley]

>>>>> "LI" == Lars Ingebrigtsen <la...@gnus.org> writes:

LI> If Django had traditionally always been distributed along with Python, and
LI> maintained in the Python repo, and the suggestion now would be to move
LI> Django to a part of the Python repo that very few developers look at, but
LI> Django would continue to be distributed with Python, and all Django bug
LI> reports would continue to go to the Python bug repository, and Python
LI> developers would continue to be responsible for QA and bug fixing of
LI> Django.

OK, to continue the analogy, what is the right answer? Technically it doesn't
seem as though Django belongs there, even if culturally it sounds hard to
separate. Should it stay indefinitely, or should the development model change?

-- 
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2

Re: [O] Sync up the org in emacs master to org maint branch?

[John Wiegley]

>>>>> "DE" == David Engster <d...@randomsample.de> writes:

DE> Also, I currently have no idea how to continue with CEDET, as the future
DE> where development should happen is unclear, and I get the feeling we're
DE> just waisting our time with the ongoing merge.

Until the dust has settled, please proceed, assuming nothing has changed. Move
your primary development into Emacs.git.

The changes I'm proposing don't have to happen tomorrow, and I can still be
convinced they're unnecessary. My gut tells me, however, that we're supporting
an unnecessarily monolithic development model for no better reason than "we're
used to it".

In fact, what we're doing feels like if Python included Django in its main
repository, just to solve Django's problems of compatibility, testing, and
making its bugs known to the main Python developers.

-- 
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2

Re: [O] Sync up the org in emacs master to org maint branch?

[John Wiegley]

>>>>> "LI" == Lars Ingebrigtsen <la...@gnus.org> writes:

LI> I'm massively unenthusiastic about this future. Things in ELPA has to be
LI> backwards-and-forwards compatible with a wide Emacs version range, which
LI> makes maintaining things much more work. When you develop things in "Emacs
LI> core", you have one specific target and can make large internal changes
LI> without these considerations.

So far, all of these arguments against a tighter development integration with
ELPA have been predicated on the way that ELPA is used today. ELPA is under
our control; we can adjust our process to suit the needs of Emacs development.

LI> Emacs doesn't seem to have a massive surfeit of developers, so I wonder
LI> where this plan comes from.

It comes from the desire to decouple the development of large, mostly external
projects, from core Emacs. They don't belong in Emacs.git.

-- 
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2

Re: [O] Sync up the org in emacs master to org maint branch?

[John Wiegley]

>>>>> "DE" == David Engster <d...@randomsample.de> writes:

DE> It is a mistake because you are creating more moving targets and bring
DE> them together very late in the release process. This reduces the amount of
DE> testing that is done for those packages, so bugs will be noticed later and
DE> the quality of the relases suffer. It moves even more work into the
DE> RC-phase, which is already crowded and where people who can fix those bugs
DE> might not be readily available. It removes those packages from Emacs CI,
DE> so that breakages due to changes in core are not immediately noticed, and
DE> often times they have to be fixed not by those who created the breakage,
DE> but by those who notice them.

These are issues to be fixed in the way ELPA integrates with our development
process. I recognize today's ELPA may have these drawbacks, but I believe they
can be fixed.

We're moving toward a future where Emacs.git will represent "core Emacs", and
only contain what core needs (plus a few historical bits, I'm sure). There
should be no argument for keeping a project in core just to gain auxiliary
benefits.

-- 
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2

Re: [O] Sync up the org in emacs master to org maint branch?

[John Wiegley]

>>>>> "DE" == David Engster <d...@randomsample.de> writes:

DE> This is a misunderstanding. I said I wanted to move support for certain
DE> languages and project types into ELPA, not CEDET core. I'm still of the
DE> opinion that moving it completely to ELPA is a mistake.

It would only be a mistake if other parts of core need to use it. If only
users make use of it, then having it ELPA will be invisible to them.

-- 
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2

Re: [O] Sync up the org in emacs master to org maint branch?

[John Wiegley]

>>>>> "KM" == Kaushal Modi <kaushal.m...@gmail.com> writes:

KM> If we are able the release the new packaging method in emacs 26.x, then we
KM> can remove org from emacs master completely, but if not, then at least as
KM> backup we have a newer org version to go out with that release.

For Emacs 26, I intend the new ELPA process to be in place, whereby "default"
packages can be developed separately, and declare a way to get slip-streamed
into the release tarball so users are unaware of the separate nature of their
development.

The CEDET developers have agreed to support this, and it sounds like you are
willing to as well. If Lars is game, I'd like for Gnus to be third major
package we do this for initially. That will reduce considerably the number of
external files we track in Emacs.git.

The precise technical details have yet to be worked out, but it shouldn't be
too difficult. Phillip Lord has already began advance work on alternatives,
and I've received offers of help from others to work on this new process.

I think now is a good time to begin. The first step is to solidify what is
meant by "tarball EPLA", and the means of slip-streaming a package's contents.
This will require at least two bits:

  - Some form of declaration to indicate how external files should appear in
the tarball. In order for the first version of this scheme to be as low
impact as possible, this should probably be done with a sexp in a data
file, to be checked in alongside the EPLA.git import of the project.

  - changes to "make dist" to integrate these files, and setup autoloading so
their inclusion is transparent to end users.

Please comment with your recommendations for the first, and supporting changes
for the second, if anyone has ideas. Phillip, how is your work on these coming
along?

-- 
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2

Re: [O] Sync up the org in emacs master to org maint branch?

[John Wiegley]

>>>>> "EZ" == Eli Zaretskii <e...@gnu.org> writes:

EZ> AFAIR, we have never released a major version so quickly, and I don't see
EZ> why this one would be different. A year at least, I'd say, probably more.

This was my feeling as well.

-- 
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2

[O] bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)

[John Wiegley]

>>>>> Eli Zaretskii <e...@gnu.org> writes:

> My suggestion to fix this is below. I ask for opinions on (1) whether this
> looks like TRT, (2) whether it is safe enough for emacs-25, and (3) whether
> someone has better ideas.

I didn't even know match-data took arguments, so I defer to your judgment on
this issue, Eli.

-- 
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2


signature.asc
Description: PGP signature

Re: [O] bug#22182: 24.5; Org Mode Export

[John Wiegley]

elpa/org-20151214/ob-gnuplot hides 
> /usr/share/emacs/24.5/lisp/org/ob-gnuplot
> /home/bvr/.emacs.d/elpa/org-20151214/org-loaddefs hides 
> /usr/share/emacs/24.5/lisp/org/org-loaddefs
> /home/bvr/.emacs.d/elpa/org-20151214/ob-sqlite hides 
> /usr/share/emacs/24.5/lisp/org/ob-sqlite
> /home/bvr/.emacs.d/elpa/org-20151214/org-compat hides 
> /usr/share/emacs/24.5/lisp/org/org-compat
> /home/bvr/.emacs.d/elpa/org-20151214/org-mobile hides 
> /usr/share/emacs/24.5/lisp/org/org-mobile

> Features:
> (shadow sort mail-extr emacsbug message rfc822 mml mml-sec mm-decode
> mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
> sendmail rfc2047 rfc2045 ietf-drums mail-utils debug ox-texinfo
> ox-icalendar ox-html ox-beamer ox-latex ox-ascii ox-publish ox
> vc-dispatcher vc-svn flyspell ispell org-indent org-rmail org-mhe
> org-irc org-info org-gnus org-docview doc-view jka-compr image-mode
> org-bibtex bibtex org-bbdb org-element avl-tree org-w3m org org-macro
> org-footnote org-pcomplete pcomplete org-list org-faces org-entities
> org-version ob-emacs-lisp ob ob-tangle ob-ref ob-lob ob-table ob-exp
> org-src ob-keys ob-comint comint ansi-color ob-core ob-eval org-compat
> org-macs org-loaddefs find-func cal-menu calendar cal-loaddefs
> image-file face-remap server auctex-latexmk tex-jp latex tex-style
> tex-buf tex dbus xml crm multi-term cl-macs cl gv term disp-table ehelp
> ring edmacro cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles
> cc-align cc-engine cc-vars cc-defs wheatgrass-theme mb-depth two-column
> bookmark pp icicles icicles-mode icicles-cmd2 icicles-cmd1 advice
> icicles-mcmd help-mode image-dired format-spec dired icicles-fn
> icicles-var icicles-opt kmacro ffap url-parse auth-source eieio byte-opt
> bytecomp byte-compile cl-extra cconv eieio-core gnus-util mm-util
> help-fns mail-prsvr password-cache url-vars cus-theme cus-edit cus-start
> cus-load wid-edit cl-loaddefs cl-lib thingatpt icicles-face paren
> elec-pair time-date battery time noutline outline easy-mmode reveal
> linum tex-site info easymenu package epg-config debian-el
> debian-el-loaddefs tooltip electric uniquify ediff-hook vc-hooks
> lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt
> fringe tabulated-list newcomment lisp-mode prog-mode register page
> menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
> syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
> vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
> romanian slovak czech european ethiopic indian cyrillic chinese
> case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice
> loaddefs button faces cus-face macroexp files text-properties overlay
> sha1 md5 base64 format env code-pages mule custom widget
> hashtable-print-readable backquote make-network-process dbusbind
> gfilenotify dynamic-setting system-font-setting font-render-setting
> move-toolbar gtk x-toolkit x multi-tty emacs)

> Memory information:
> ((conses 16 392136 6731)
>  (symbols 48 47030 0)
>  (miscs 40 469 233)
>  (strings 32 110900 14123)
>  (string-bytes 1 3505337)
>  (vectors 16 42209)
>  (vector-slots 8 743867 4164)
>  (floats 8 175 131)
>  (intervals 56 1590 554)
>  (buffers 960 16)
>  (heap 1024 55644 2125))

-- 
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2

[O] bug#21938: [sgeorgii .] bug#21938:

[John Wiegley]

Closed

[O] [sgeorgii .] bug#21938: 24.5; PostScript Print Buffer fails on Agenda buffer

[John Wiegley]

Copying bug report.

John

--- Begin Message ---
I launch emacs (-q switch makes no difference), open my .org file and
proceed as follows:

M-x org-agenda

a (agenda for current week or day)

menu "File" ->  "PostScript Print Buffer"

instead of printout of agenda on my printer I get the following error
in Backtrace:

Debugger entered--Lisp error: (wrong-type-argument listp org-priority)
  ps-face-attribute-list((bold . org-priority))
  ps-plot-with-face(78 82 (bold . org-priority))
  ps-generate-postscript-with-faces1(1 4783)
  ps-generate-postscript-with-faces(1 4783)
  ps-generate(# 1 4783 ps-generate-postscript-with-faces)
  ps-spool-with-faces(1 4783 nil)
  ps-print-with-faces(1 4783 nil)
  ps-print-buffer-with-faces(nil)
  call-interactively(ps-print-buffer-with-faces nil nil)
  command-execute(ps-print-buffer-with-faces)


I have this error on both Windows and Linux hosts with emacs version
24.5. Emacs version 24.3 or earlier work just fine on same Windows and
Linux hosts.

I get this error with "PostScript Print Buffer". If I choose "File"->
""PostScript Print Buffer (B+W)" - this gives me printer printout all
right on all versions of emacs on both Windows and Linux hosts .

Any help?


In GNU Emacs 24.5.1 (i686-pc-mingw32)
 of 2015-04-11 on LEG570
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/usr --host=i686-pc-mingw32'

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1251

Major mode: Org-Agenda Week Ddl Grid

Minor modes in effect:
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Press key for agenda command (unrestricted):
Formatting...  0%
Collecting face information...
ps-plot-with-face: Wrong type argument: listp, org-priority

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util help-fns mail-prsvr
mail-utils ps-mule ps-print ps-def lpr diary-lib diary-loaddefs cal-iso
org-agenda org-element org-rmail org-mhe org-irc org-info org-gnus
gnus-util org-docview doc-view jka-compr image-mode dired cl-loaddefs
cl-lib org-bibtex bibtex org-bbdb org-w3m org org-macro org-footnote
org-pcomplete pcomplete org-list org-faces org-entities noutline outline
easy-mmode org-version ob-emacs-lisp ob ob-tangle ob-ref ob-lob ob-table
ob-exp org-src ob-keys ob-comint comint ansi-color ring ob-core ob-eval
org-compat org-macs org-loaddefs format-spec find-func cal-menu easymenu
calendar cal-loaddefs time-date tooltip electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel dos-w32 ls-lisp w32-common-fns
disp-table w32-win w32-vars tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment lisp-mode prog-mode register page menu-bar
rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax
facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak
czech european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer nadvice loaddefs button
faces cus-face macroexp files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process w32notify w32 multi-tty emacs)

Memory information:
((conses 8 221645 10009)
 (symbols 32 26574 0)
 (miscs 32 4419 2098)
 (strings 16 41593 5657)
 (string-bytes 1 1344167)
 (vectors 8 18490)
 (vector-slots 4 493986 7658)
 (floats 8 379 246)
 (intervals 28 2940 838)
 (buffers 508 16))



--- End Message ---

[O] bug#21938: 24.5; PostScript Print Buffer fails on Agenda buffer

[John Wiegley]

> sgeorgii   writes:

> I launch emacs (-q switch makes no difference), open my .org file and
> proceed as follows:

> M-x org-agenda

I've forwarded this to the Org-mode mailing list.

John

Re: [O] Allowing loose ordering in Org files

[John Wiegley]

> Achim Gratz  writes:

> If you don't use properties then it doesn't affect you at all. If you do,
> then… well, I personally simply don't care. Just like there's several style
> guides for writing C; as long as these are applied consistently I can live
> with most of them and put the braces and indents the way they prescribe.

In my regimen, every single entry has a PROPERTIES drawer, since I tag each
one with ID and CREATED, for future reference. Most items are SCHEDULED as
well. So when I open up a headline to look at the contents, I see:

* Head
SCHEDULED
text
:PROPERTIES:...

It's a trivial thing, but I'd rather not scan past two lines to start reading
my entry.

What a lot of people want is trivial, and only relevant to them, but part of
the Emacs philosophy is to give them the freedom to customize their
environment the way they want it to work, rather than decide for them what is
the "right way".

I won't argue for this anymore, if it really does incur work for you that only
benefits me and a few others. I suppose that I'm still writing these e-mails
because I want to inject some sensitivity about these matters into your future
decisions, so you don't take away such flexibility again lightly.

> So write the advise and move on? If you weren't so heavily invested in what
> you perceive as "the right style" you quite likely wouldn't care, or would
> you?

I'm invested in the spirit of the project, since I've been using it for a very
long time, and continue to recommend it to many people as an amazing tool for
self-organization. The more it becomes something I have to hack to like, the
less I feel like putting my heart into it.

I *care*, which is maybe both a blessing and a curse. It is the origin of my
creative contributions, but also the cause of these annoying threads. I'd
rather work with you guys than against you; but there are some sacred cows
that moan plaintively, when a sharp parenthesis is drawn across their throats.

Yours,
  John

Re: [O] Allowing loose ordering in Org files

[John Wiegley]

> Nicolas Goaziou  writes:

> I really don't like the idea of making Org /syntax/ customizable, would it
> be with the help of a hook or a variable.

>From what I've seen so far, several users want regularity of syntax to decide
formatting, and several users want user preference to decide formatting. There
do seem to be larger costs for letting the user decide; but there are also
costs to not letting the user decide, that I feel are not being appreciated.

The reason I'm sticking on this point is because it also relates to our future
road map. If Org continues to do this -- to trade flexibility of formatting
for regularity of parsing -- it might continue to alienate some of us.

John

Re: [O] Allowing loose ordering in Org files

[John Wiegley]

> Achim Gratz  writes:

> So isn't your request rather to hide the properties drawer better by
> default? You were _only_ talking about the UX in this whole thread and that
> might be a lot easier to adapt while not changing the way Org syntax is
> defined.

Good call, Achim! I became too focused on the problem, and missed the real
point.

> As I said above, the solution may well be different than both what you want
> to keep and what Org offers now. I don't find that thread particularly
> annoying, btw.

Thanks.

John

Re: [O] Allowing loose ordering in Org files

[John Wiegley]

> Stelian Iancu  writes:

> John, if you end up writing an advice for this function, please share it
> with the list, as I would like the 8.2 behavior as well (I unfortunately
> don't know enough elisp and org internals to do such a thing).

To Achim I would say that these are the reasons to have a hook: Because then
it gets documented as an option; it's supported within Org (rather than being
a separate thing people have to find in my .emacs on GitHub); and it shows up
when you M-x customize-group RET org RET.

John

Re: [O] Allowing loose ordering in Org files

[John Wiegley]

> Aaron Ecay  writes:

> Adding knobs to this parser increases the burden of those who have to build
> and maintain it.

Thank you for your reply, Aaron, I found it most illuminating.

If the answer from the maintainers is "It's more work than we want to do",
that's completely acceptable. I've been operating under the premise that it
wouldn't be difficult to add such an option (just the hook, mind you, not the
functionality behind it).

I suppose at this point it becomes a question of whether others want this as
much as I do. If it's just a handful of us, and the maintainers find the
option onerous, that's really the end of it.

> I think it’s more illuminating to think of it in terms of org as a tool:
> have the changes made it more difficult for you to accomplish your goals
> with org? Has something that was previously possible become impossible? Has
> something that was previously easy gotten harder? If the answer to one of
> these questions is yes, then we can think of ways to solve the difficulties.

There is another vector to consider, and a far more nebulous one: How does it
impact Org's "luft"? That is, the feeling of ease and comfort Org conveys in
its use.

There are many highly functional alternatives to Org that I've tried and
rejected because they lack the easy grace of Org. That grace is why I've been
able to stick with it after almost 9,000 handled tasks. Any perception of
"inertia" in a tasking system causes me to psychologically avoid it, even if I
have no rational basis for that aversion.

I sincerely hope that those with high technical motives will keep in mind the
usability of Org beyond purely technical considerations. It should say
something that a long-time user is unhappy with the way Org "feels" in 8.3.

John

Re: [O] Allowing loose ordering in Org files

[John Wiegley]

> Rasmus   writes:

>> To those who repeat the performance argument: This is an opt-in only
>> request. It is not about changing the performance of default Org, or making
>> files more difficult to parse outside of Emacs for everyone.

> I disagree with your last claim.

I'm not sure I understand, can you clarify? What I meant is that I don't want
to get in the way of the maintainer's vision for "default Org". I would just
like some customization options, to keep using Org as I'm used to it.

John

[O] Allowing loose ordering in Org files (Was: bug in org-habits)

[John Wiegley]

>>>>> John Wiegley <jo...@gnu.org> writes:

> I spoke to Nicolas directly and he mentioned that a goal for syntax
> regularity is to make it possible to reliably read and manipulate Org files
> outside of Emacs.
> 
> For this I *am* willing to give up order independence of PROPERTIES. Having
> a customization option would needlessly increases the number of
> possibilities external processors must consider, and so I retract my
> request.

I've had time this weekend to rethink my feature request, and I realized that
even machine-friendly formatting is something I should be able to give up, to
have an Org that works better for me.

What has always made Org great (to me) is that it's a rather "light" overlay
on a plain old text file. What structure it does enforce -- say, the actual
syntax of drawers -- has always felt fairly "fluid".

Lately there seems to be a push to sacrifice some of this freedom in order to
gain efficiency and regularity. I imagine this is for the benefit of machine
parsers; but what if one doesn't use any machine parsers? Org never asked me
to give up flexibility for unknown benefits before.

It should be asked whether users want to trade formatting freedom for those
benefits. If it has been asked, I missed that discussion. So unless it's an
heavy maintenance burden to allow floating properties, for example, I don't
see why I, as a user, shouldn't be allowed to make that choice.

To those who repeat the performance argument: This is an opt-in only request.
It is not about changing the performance of default Org, or making files more
difficult to parse outside of Emacs for everyone.

John

Re: [O] Allowing loose ordering in Org files

[John Wiegley]

> Achim Gratz  writes:

> The whole point of defining a formal syntax for Org is that it becomes
> possible to parse Org documents with something other than Emacs and still
> make sense of them. To reap that benefit, you need to drop some of the
> ad-hoc parsing that Org did in the past.

Yes, I know this. The benefits of regular structure are unrelated to my
request for freedom from the constraints of such regularity.

> You will find that the argument really wasn't about performance, but
> complexity.

I can accept a complexity argument, if my request were really "a separate
code-path". I'm not sure it is. For example, my needs could be satisfied by
something as simple as:

(defun parse-org-entry (...)
(let ((props (funcall 'parse-org-properties-function ...)))
   ...))

`parse-org-properties-function' would point to a function that does what Org
8.3 does now. This gives me the option of porting over the 8.2 version and
keeping the old behavior. All that needs to be done is to allow this hook, no?

John

Re: [O] Allowing loose ordering in Org files

[John Wiegley]

> Rasmus   writes:

> If the placement of properties is "free", the secondary interpreter /must/
> support this customization option to be able to interpret the org format.
> Note, this matters for both interactive usage (being able to click/open a
> reference) and for "export" (e.g. org-ruby).

If my request is fulfilled, I would expect that changing the "find properties
function" would imply that one's Org file is no longer usable by secondary
interpreters. I.e., "If you change this, you do so at your own risk".

John

[O] [Rittwik Chatterjee] bug#21838: Org Table edits item incorrectly

[John Wiegley]

In case this wasn't seen by the Org maintainers...

--- Begin Message ---
Start emacs with `emacs -Q'
Create a Org file `test.org'

Copy the following table into that file and save.

|---+-|
| Plugins   | How to install  |
|---+-|
| Bookmark plus | Create a folder "bookmark-plus" |
| Company-mode  | Create a folder "company"   |
|---+-|

Double click on the word `Create' (to select it) in the third row and press
`:'.

Expected output:
|---+-|
| Plugins   | How to install  |
|---+-|
| Bookmark plus | Create a folder "bookmark-plus" |
| Company-mode  | Create: a folder "company"  |
|---+-|

Actual output:
|---+-|
| Plugins   | How to install  |
|---+-|
| Bookmark plus | Create a folder "bookmark-plus" |
| Company-mode  | |
|---:+-|

This can be reproduce by pressing any other character keys, ex. a-z, ( { [
" etc.



In GNU Emacs 24.5.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.16.2)
 of 2015-04-22 on buildhw-10.phx2.fedoraproject.org
Windowing system distributor `Fedora Project', version 11.0.11702000
Configured using:
 `configure --build=x86_64-redhat-linux-gnu
 --host=x86_64-redhat-linux-gnu --program-prefix=
 --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
 --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
 --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
 --libexecdir=/usr/libexec --localstatedir=/var
 --sharedstatedir=/var/lib --mandir=/usr/share/man
 --infodir=/usr/share/info --with-dbus --with-gif --with-jpeg --with-png
 --with-rsvg --with-tiff --with-xft --with-xpm --with-x-toolkit=gtk3
 --with-gpm=no build_alias=x86_64-redhat-linux-gnu
 host_alias=x86_64-redhat-linux-gnu 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g
 -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4
 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
 -m64 -mtune=generic' LDFLAGS=-Wl,-z,relro'

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
help-fns mail-prsvr mail-utils help-mode easymenu time-date tooltip
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

Memory information:
((conses 16 72390 5112)
 (symbols 48 17647 0)
 (miscs 40 36 113)
 (strings 32 9239 4277)
 (string-bytes 1 254414)
 (vectors 16 8986)
 (vector-slots 8 383759 19219)
 (floats 8 64 222)
 (intervals 56 289 4)
 (buffers 960 12)
 (heap 1024 34048 744))

Thanks,
Rittwik
--- End Message ---

Re: [O] bug in org-habits

[John Wiegley]

> Bastien Guerry  writes:

> I think Achim's points above are very valid, and the flexibility offered by
> the option above should be very carefully examined.

I spoke to Nicolas directly and he mentioned that a goal for syntax regularity
is to make it possible to reliably read and manipulate Org files outside of
Emacs.

For this I *am* willing to give up order independence of PROPERTIES. Having a
customization option would needlessly increases the number of possibilities
external processors must consider, and so I retract my request.

John

Re: [O] contributing to work on citations

[John Wiegley]

> Will Monroe  writes:

> As someone who uses Zotero and org-mode quite a bit, I'd be glad to help
> with testing, if that would be useful. I'm learning Elisp but I'm still a
> beginner. Nevertheless, I have a keen interest in bringing together these
> tools.

Me too, I'm a fan and active user of both tools as well.

John

Re: [O] bug in org-habits

[John Wiegley]

> Puneeth Chaganti  writes:

>> Actually there has been introduced a constraint on the ordering planning
>> lines and property drawers in 8.3. See http://orgmode.org/Changes.html.>
>> This at least invalidates to use PROPERTIES before SCHEDULED afaics.

> Yes, that is correct and you can use the `org-repair-property-drawers`
> utility function provided to fix your org trees.

I would very much like to see this constraint removed from 8.3. I have always
preferred having SCHEDULED before PROPERTIES, as this is how all my Org files
are arranged.

In fact, this one aspect of 8.3 has kept me at 8.2. I do not understand the
need for such an abitrary restriction.

John

Re: [O] bug in org-habits

[John Wiegley]

> Nicolas Goaziou  writes:

> This is not a bug. The order is HEADLINE (SCHEDULED PROPERTIES).

Ah, I had misspoken. It's not SCHEDULE-before-PROPERTIES that has broken for
me, it is the inability to have PROPERTIES at the very end of the entry.

Why must the properties drawer appear before the entry's body?

John

Re: [O] bug in org-habits

[John Wiegley]

> Achim Gratz  writes:

> I don't think so. Search for end of entry can be complex in itself and you
> would never know if the properties you find by looking back aren't belonging
> to an entry one level down unless you scanned the whole span again. Also,
> properties can be any size and you have to search for the beginning of the
> drawer.

Good point.  Still, the option I'd still choose would be:

org-allow-floating-properties

  If set to `non-nil', the :PROPERTIES: drawer may begin anywhere within
  an entry. Note that this will slow down many operations due to the
  additional scan needed, and may lead to incorrect result if similar text
  is found elsewhere within an entry, which is the recommended and default
  value for this variable is nil.

John

Re: [O] bug in org-habits

[John Wiegley]

> Jonathan Leech-Pepin  writes:

> Wouldn't last item in entry scale without issues? Find end of headline
> (start of next or end of buffer) and search backwards. If first element from
> end is a property drawer you have it, otherwise you still know there is
> none.

That sounds even better than what I mentioned about re-search-forward, and
O(1) time complexity as well.

John

Re: [O] bug in org-habits

[John Wiegley]

> Nicolas Goaziou  writes:

> I'd rather not have syntax too much customizable, for portability, ease of
> maintenance, too. There are already too many mistakes in that area.

Thanks for discussing this with me, Nicolas. I appreciate there may be
technical complexities involved. Could we special-case allow PROPERTIES to be
the *very last thing* in an entry? I don't need it to float anywhere else. I
just like it to be at the end.

> If you need to end your entry with a drawer, couldn't you put any of them
> there? You can even have one there named "PROPERTIES".

But it wouldn't be the true PROPERTIES, would it? Most of my entries look like
this (and I have many thousands of them):

** TODO Update auto insurance cards :Home:ATTACH:
SCHEDULED: <2016-03-11 Fri +6m>
- State "DONE"   from "TODO"   [2015-09-11 Fri 11:28]
- State "WAITING"from "TODO"   [2015-07-22 Wed 19:48]
- State "DONE"   from "STARTED"[2014-12-13 Sat 15:56]
- State "DONE"   from "TODO"   [2014-03-31 Mon 03:11]
- State "CANCELED"   from "TODO"   [2013-12-11 Wed 19:23]
- State "CANCELED"   from "TODO"   [2013-05-21 Tue 12:30]
- State "DONE"   from "TODO"   [2012-05-17 Thu 22:24]
- State "CANCELED"   from "TODO"   [2011-04-23 Sat 22:04]
- State "TODO"   from "DONE"   [2010-10-23 Sat 21:54]
- State "DONE"   from "TODO"   [2010-10-08 Fri 14:26]
:PROPERTIES:
:ID:   B1F3D3F6-9F39-4899-9AF8-93E019E7C6BB
:CREATED:  [2010-05-08 Sat 17:34]
:LAST_REPEAT: [2015-09-11 Fri 11:28]
:Attachments: AutoInsuranceIdCards.pdf
:END:

I suppose I've just become familiar with seeing :PROPERTIES: as the "period"
at the end of the entry, and I'll like to keep it there if we can devise a
technical answer that does not make life more difficult for you.

John

Re: [O] bug in org-habits

[John Wiegley]

> Nicolas Goaziou  writes:

> It is for efficiency reasons. Properties are an important feature in Org,
> letting them anywhere in a potentially long entry doesn't scale well.

Since it scales for my use case, can I please have a customization variable to
relax this restriction? I prefer PROPERTIES drawers at the end, and would
prefer not to trade something I want for something that doesn't affect me.

Thanks, John

Re: [O] bug in org-habits

[John Wiegley]

> Nicolas Goaziou  writes:

> As a matter of fact, going to the end of an entry is not negligible, because
> of inlinetasks. Also, it is not really O(1) since it depends on the size of
> the entry. To get an idea, on my computer, moving past a 500 lines entry
> takes around 0.001s. I can imagine slower computers, or larger entries,
> neither being unheard of, having a slightly noticeable delay.

I'm having a hard time buying the performance argument, since I've been using
Org-mode for many years, and never has this been a problem. You're making me
pay a cost (enforced structure), for a value only one of us perceives.

> Also, supporting both locations means that users will pay the full price in
> entries without a property drawer, even if they chose the fast path, i.e.,
> drawer at the beginning of the entry, in the first place. This kind of
> defeats some of the advantages of the current state.

It wouldn't be "users": it would be people intentionally opting to allow
floating properties. _I_ would be paying the price, and I will pay it happily
to keep 8.2 behavior.

John

Re: [O] bug in org-habits

[John Wiegley]

> Achim Gratz  writes:

> Well, that's precisely the thing that doesn't scale and that Nicolas wanted
> to avoid. Putting the properties at the beginning of an entry makes the
> search pretty much constant time and if you find something else at the start
> of the entry then you know there aren't any and can go on (this is pretty
> important for making sure property inheritance works correctly, among other
> things). If you could put them _anywhere_ else, you'd have to keep searching
> until you either find them or you've exhausted the span of the entry.

As a user, I'm willing to pay that cost. Also, I never have other property
drawers. If it were just doing (re-search-forward "^:PROPERTIES:$"
(end-of-entry)), then it wouldn't matter where the properties drawer was, so
long as it's understood that the search may be wrong if the user has such a
string appearing elsewhere.

John

[O] org-habit and Org 8.3

[John Wiegley]

Hello,

I've upgrade today to Org 8.3.1, and I've noticed that any customization which
used overlays (mainly, org-habit) now displays no overlays in the Agenda
buffer.

Is this something others have already seen and found a fix for?

Thanks,
  John

Re: [O] org-habit and Org 8.3

[John Wiegley]

 Josiah Schwab jsch...@gmail.com writes:

 Upon upgrading, my org-habits did not display correctly, because the
 PROPERTY drawer where the habit style was indicated came after the LOGBOOK
 in my org files.

Is there a reason why this was done?  I rather liked having my PROPERTY
drawers at the bottom of each entry, out of the way.  That way, every record
in my Org file ends with :END:, closing its property drawer (every single
headline I create has an accompanying PROPERTY drawer).

John

Re: [O] org-attach + git annex not working

[John Wiegley]

 Erik Hetzner e...@e6h.org writes:

 I don’t know if the behavior of vc-git-root has changed, but I don’t see
 anything in the emacs git log for vc/vc-git.el and it seems to have the same
 behavior in 24  25.

I hadn't noticed it breaking, but is it possible to make your change a bit
more defensive?  I.e., make sure the string ends in .git if it doesn't
already, rather than always appending .git?

John

Re: [O] `org-attach-file-list' doesn't allow dotfiles

[John Wiegley]

No reason I can think of.

John

On Mar 12, 2014, at 1:39 PM, Bastien b...@gnu.org wrote:

 Hi Oleh,
 
 Oleh ohwoeo...@gmail.com writes:
 
 I wanted to store this file as an attachment in an org document, so I
 don't forget about it, but this attachment can't be opened due
 to `org-attach-file-list` ignoring all files that start with a dot.
 
 I'm copying John to this email, to see if there is any reason why
 files starting with a dot cannot be attached.
 
 Otherwise the change looks okay to me.
 
 Thanks,
 
 -- 
 Bastien

Re: [O] Changing the maintainer

[John Wiegley]

 Carsten Dominik carsten.domi...@gmail.com writes:

 Bastien's activity has been unmatched.  He has answered a huge amount of
 questions in the mailing list, fixed an uncounted number of bugs and he has
 been designing and applying changes over the entire breadth of the Org code
 base.  This is no easy feat and I really admire his work.  Besides this, he
 has done amazing work keeping the community together and making sure that
 the mailing list remains IMO one of the prime places on the internet.

Couldn't agree more.  Thank you so much, Bastien!  And to everyone who has
helped to keep Org-mode one of Emacs' killer apps for several years running.

John

Re: [O] todo-state change: agenda buffer scrolls

[John Wiegley]

 Michael Heinrich mich...@haas-heinrich.de writes:

 whenever I change the todo state of a task in the agenda this task becomes
 line 1 in my agenda buffer.  This is really annoying for me.  How can I
 change to the old behaviour where the agenda buffer is not scrolled down?

I'll second this, I just noticed this recently and I too would like to go back
to the previous behavior.

Thanks,
  John

Re: [O] agenda: personal priority for today

[John Wiegley]

 Michael Heinrich mich...@haas-heinrich.de writes:

 I came from planner-mode and use kind of GTD also in org-mode.  One
 thing I still miss in org-mode is the flexibility of moving tasks up and
 down on the today page.

Hi Michael, planner author here and now org-mode user too. :)

You'll have to change the positions of the items within the Org file itself.
It would be great if there was a single key to do this and then very quickly
update the agenda view.

John

[O] Bug in behavior of M-RET with latest Org-mode

[John Wiegley]

In Org I've liked that fact that hitting M-RET in a list of headlines which
have no intervening whitespace, will add a new headline without whitespace.
Example:

* One
* Twocursor
* Three

If hit M-RET at the cursor, I'll would get:

* One
* Two
* cursor
* Three

With the latest Org, I get:

* One
* Two
* cursor

* Three

Is this just a regression, or has the core behavior been changed to do this?
Is there a new variable I need to tweak to get the old behavior?

Thanks! John

[O] Bug in fontification of priority cookies

[John Wiegley]

I just upgraded to Org-mode's master branch today, and found that the
org-priority face gets applied not just to the '[#C]' cookie, but the entire
text of the headline in the Agenda buffer.  Is this intended?

Thanks,
  John

Re: [O] Offer for taking over maintainership

[John Wiegley]

 Jambunathan K kjambunat...@gmail.com writes:

 I offer to take over maintainership of Org.
 Offer closes in 7 days.  Only pre-condition will be that Org-8.0 and
 subsequent releases happen under my supervision.
 
 Principals and riff-raffs can PM me with your thoughts.  I defend your right
 to choose the maintainer or express yourself freely.

I don't know, Jambunathan, the tone of this offer makes me inclined to reject
it.  I didn't even realize Bastien was looking for a replacement.

John

Re: [O] Using git-annex with org-attach

[John Wiegley]

 John Wiegley jo...@newartisans.com writes:

 The value of git-annex is that it lets you associate truly huge files with a
 Git repository that are check-summed and easily archived, which you can then
 drop from your local attachments directory when you no longer need the file
 there.  Later, if you need files that you dropped, use `C-c C-a F' and `M-!
 git annex get . RET' to re-download those attachments back into your local
 repo.

I have some further git-annex integration here:

https://github.com/jwiegley/git-annex-el

In particular, when you use C-c C-a F to visit the attachments directory in
dired, locally available annexed files will be green, and locally unavailable
files will be red.  Use @g to get unavailable files from another reachable
repository, and @d to drop them from your local repository.

If you open the file in Emacs and type C-x C-q to make it editable, this will
automatically do a git annex edit, and when the buffer dies it will git
annex add the new version and then do a git commit automatically.

John

[O] Using git-annex with org-attach

[John Wiegley]

I pushed a change to master that allows you to use the wonderful git-annex
utility[1] seamlessly with org-attach.  The way it works is as follows:

 1. If your `org-attach-directory' is a git working tree,

 2. and if you have run git annex init there,

 3. and if `org-attach-git-annex-cutoff' is non-nil and smaller than the size
of the file you're attaching,

 4. then org-attach will git annex add the file; otherwise it will git add
it.  (See the documentation for git-annex to discover exactly what this
distinction means; basically it's the difference between stored in Git
forever, and check-summed and tracked until I decide I don't need it on
this machine anymore).

 5. You will have to run git annex sync yourself afterwards, or use the git
annex assistant to keep your attachments automagically in sync with all
your machines whenever they are reachable.

The value of git-annex is that it lets you associate truly huge files with a
Git repository that are check-summed and easily archived, which you can then
drop from your local attachments directory when you no longer need the file
there.  Later, if you need files that you dropped, use `C-c C-a F' and `M-!
git annex get . RET' to re-download those attachments back into your local
repo.

John

Footnotes: 
[1]  http://git-annex.branchable.com/

[O] Feature request: v1 - v9

[John Wiegley]

I can get an agenda report for the next 4 days using:

  M-: (org-agenda-change-time-span 4) RET

But there seems to be no command for doing so.  It would be nice if `v N',
where N is a number 1-9, could give me a report for the next N days.

This is useful to me right now because I have a house-move coming up on
Monday, so I need to see the state of everything that's scheduled to happen
between now and then.

John

Re: [O] DevonThink links in org mode?

[John Wiegley]

 Alan Schmitt alan.schm...@polytechnique.org writes:

 Thanks a lot, that was most helpful. Here is what I ended up with, if it may
 help other people:

 (org-add-link-type x-devonthink-item 'org-devonthink-open)

 (defun org-devonthink-open (link)
   Open the devonthink link.
   (start-process (concat open  link) nil open

 (concat x-devonthink-item: link)))

I created org-devonthink.el a long time ago:

https://github.com/jwiegley/dot-emacs/blob/master/lisp/org-devonthink.el

John

[O] Problem with org-babel and shell scripts

[John Wiegley]

I have a shell block in my todo.txt which I've been using for generating some
reports for about a year.  I just tried C-c C-c in that shell block today, and
got the following:

--8---cut here---start-8---
Debugger entered--Lisp error: (void-variable org-current-export-file)
  org-babel-confirm-evaluate((sh ... ((:comments . ) (:shebang . ) 
(:cache . no) (:padline . ) (:noweb . no) (:tangle . no) (:exports . 
code) (:results . replace) (:session . none) (:hlines . no) 
(:padnewline . yes) (:result-type . value) (:result-params replace) 
(:rowname-names) (:colname-names))  nil 0))
  org-babel-execute-src-block(nil (sh ... ((:comments . ) (:shebang . ) 
(:cache . no) (:padline . ) (:noweb . no) (:tangle . no) (:exports . 
code) (:results . replace) (:session . none) (:hlines . no) 
(:padnewline . yes) (:result-type . value) (:result-params replace) 
(:rowname-names) (:colname-names))  nil 0))
  org-babel-execute-src-block-maybe()
  org-babel-execute-maybe()
  org-babel-execute-safely-maybe()
  run-hook-with-args-until-success(org-babel-execute-safely-maybe)
  org-ctrl-c-ctrl-c(nil)
  call-interactively(org-ctrl-c-ctrl-c nil nil)
--8---cut here---end---8---

I guess something changed recently?

John

Re: [O] Organizing a collection of papers

[John Wiegley]

 Frank  f...@muenn.net writes:

 I've used org-mode about a year and a half, and I don't think it's the best
 application for what you describe.  There are several packages available to
 do this; the one I've used most often and successfully is Zotero
 (zotero.org).  This is a browswer plug-in which implements a very nice
 database for your papers.  At this point, I've indexed 1092 papers (PDFs,
 web pages and other materials).  In some cases, I have multiple files
 attached to each of them.

If you happen to have a Mac, the application DEVONthink Pro is simply
wonderful for organizing collections like this.  I have about 7k PDFs in a
financial database, and it's always easy to find what I'm looking for.

John

Re: [O] BBDB Sync

[John Wiegley]

 Karl Voit devn...@karl-voit.at writes:

 I am using Org-mode to organize my contacts following org-contacts.el[1] and
 a *lot* of additional properties. Those things are so far »by convention«
 and I always wanted to sum it up on WORG but did not find time for that.

You know, it really shouldn't be hard to write an org-contacts.el *backend*
for BBDB.  I mean, a data source is a data source, who cares if it's an Elisp
form (.bbdb) or text data?

In fact, my Org-X project would make transforming an org-contacts.el buffer
into a BBDB Lisp form trivial.  Transforming it back (for writing) would be a
bit more work, but nothing too onerous.

John

Re: [O] continuing org-clock after accidental emacs-kill

[John Wiegley]

 Mehul Sanghvi mehul.sang...@gmail.com writes:

 I was clocked-in and I absentmindedly quit out of emacs without doing a
 clock-out.  How do I get the clock working and picking up from where it left
 off ?  Or have I lost what I had for today ?

Type M-x org-resolve-clocks.

John

Re: [O] List all habits with consistency graph

[John Wiegley]

 Max Mikhanosha m...@openchat.com writes:

 In fact I kind of like it, so wondering maybe it should be made `t' by
 default?

Please no.  I do not want to be overwhelmed by seeing all of my habits every
day, since that defeats the whole purpose of Org-mode for me: reducing
overwhelm.

Thanks, John

Re: [O] Bug: SCHEDULED: positioning is fragile [7.8.06 (release_7.8.06.181.ga481)]

[John Wiegley]

 Bastien  b...@gnu.org writes:

 You might also look at org-element.el.

 FYI: Nicolas and I have been discussing about the issue you raised, and the
 integration of org-element.el will force us to be clearer about such cases,
 which is good.

I think Org-X and org-element can be merged.

Org-X is a bidirectional system for turning Org entries into Lisp structure,
and back again.  Because of this bidirectionality, it lets you send Org
entries to other Backends (like Redmine, Bugzilla, etc.), and also
receive/sync Org entries with those backends.

While Org-X does parse major structural elements within entries (the scheduled
date, property drawer, and a few others), it makes no attempt to interpret the
textual content of entries, nor does it deal with whole trees, or the
ancillary data outside of heading lines (like the #+keyword markers).

It might be very useful at this point to combine the efforts of these two
projects into a complete abstraction layer for Org.  And it would be
unfortunate to have two entirely separate efforts with different areas of
focus, fragmenting the community of people who want to work with their Org
data programmatically.

I've been using Org-X for utility code for many months now, and I'm ready to
push it to mainstream.  It simply needs some documentation at this point.

If you guys are interested in merging org-element and Org-X, we should discuss
that.  Org-X is already doing a few of the things that org-element does, but I
don't believe org-element is doing much of what Org-X does, in terms of
built-in support for shuttling data to/from various backends.  Even the
Org-mode support itself is implemented as a backend on top of a more general
abstraction layer.

John

[O] Filtering agenda by the top category

[John Wiegley]

I discovered the  key in the agenda yesterday (by accident!), which filters
the Agenda down to entries having the same category.

However, I use both *categories* and *projects*.  For example:

  * Work
:CATEGORY: Work
:OVERLAY:  (face (:background #fdfdeb))
  ** PROJECT Foo
:CATEGORY: Foo

I use :CATEGORY: for my project here so it shows up in the leftmost column of
my agenda.  I don't want every project displaying as just Work.  I use the
:OVERLAY: so that all Work items have the same background color, which is a
better way of seeing at a glance which *category* every item falls into.

What this means is that although I can use  to filter by *project*, I can't
filter down to the Work *category*.  So that's what the code below does.  I
bind it to , since I wasn't using what that binding does.

Also, I found a bug: passing a prefix argument to  doesn't have any effect.
The code doesn't use that argument in any meaningful way.

John

(define-key org-agenda-mode-map  'org-agenda-filter-by-top-category)

(defun org-find-top-category (optional pos)
  (save-excursion
(with-current-buffer (if pos (marker-buffer pos) (current-buffer))
 (if pos (goto-char pos))
 ;; Skip up to the topmost parent
 (while (ignore-errors (outline-up-heading 1) t))
 (ignore-errors
   (nth 4 (org-heading-components))

(defvar org-agenda-filtered-by-top-category nil)

(defun org-agenda-filter-by-top-category (strip)
  Keep only those lines in the agenda buffer that have a specific category.
The category is that of the current line.
  (interactive P)
  (if org-agenda-filtered-by-top-category
  (progn
(setq org-agenda-filtered-by-top-category nil)
(org-agenda-filter-show-all-cat))
(let ((cat (org-find-top-category (org-get-at-bol 'org-hd-marker
  (if cat (org-agenda-filter-top-category-apply cat)
(error No top-level category at point)

(defun org-agenda-filter-top-category-apply (category)
  Set FILTER as the new agenda filter and apply it.
  (org-agenda-set-mode-name)
  (save-excursion
(goto-char (point-min))
(while (not (eobp))
  (let* ((pos (org-get-at-bol 'org-hd-marker))
 (topcat (and pos (org-find-top-category pos
(if (and topcat (not (string= category topcat)))
(org-agenda-filter-hide-line 'category)))
  (beginning-of-line 2)))
  (if (get-char-property (point) 'invisible)
  (org-agenda-previous-line))
  (setq org-agenda-filtered-by-top-category t))

Re: [O] Org appt notifications with Growl (OSX)

[John Wiegley]

 Marcelo de Moraes Serpa celose...@gmail.com writes:

 Hi folks, What is the best way to setup notifications to work with Growl for
 orgmode? I know org can work with emacs Appt system, but is anyone currently
 using it with Growl for notifications?

 If you could point me to the right direction, I'd be grateful.

I recommend adding support for alert.el to Org-mode, which was created for
just this purpose:

https://github.com/jwiegley/alert

It solves the general problem, not just sending alerts through Growl.  Once
a package uses alert.el, the user can customize what gets alert and how to
their heart's content, while keeping the changes to Org minimal.

John

Re: [O] leave inactive timestamp inactive

[John Wiegley]

 Michael Brand michael.ch.br...@gmail.com writes:

 When one does Shift-right on an inactive timestamp it remains
 inactive. When one does C-c . S-right RET the inactive timestamp changes
 to active but I would like it also to remain inactive. What are the opinions
 on this?

C-c . is the keystroke for inserting an active timestamp.  Why would you want
it to keep an inactive timestamp inactive?  I'd use C-c ! S-right RET to do
what you're suggesting.

John

Re: [O] Feature idea: show last log entry

[John Wiegley]

 Bernt Hansen be...@norang.ca writes:

 I log stuff in :LOGBOOK: with the items reversed so the newest is always on
 top.

 SPC on a task in the agenda opens the task including the drawer so I can see
 the details for any given task.

Or in that case you should be able to type E in the agenda and see it also.

John

Re: [O] do it today, or well, tomorrow

[John Wiegley]

 Rainer Stengele rainer.steng...@online.de writes:

 I think I have read somewhere that you wrote a function which does the
 following:

 If a todos schedule date is more than one day in the past it will be
 scheduled automatically to today when using the function to move the
 schedule forward for one day.

 Is that right and if yes could you share it please?

That was a feature suggestion made by Dave Abrahams.  Hasn't been coded yet,
sorry. :(  But followup on the thread so Carsten sees it has more supporters!
:)

Thx, John

Re: [O] `f' in agenda view

[John Wiegley]

 Dave Abrahams d...@boostpro.com writes:

 Yeah, it's just a question of having to think absolutely when you want to
 think incrementally.  That's a lot of keystrokes when what I want is to hit
 `f' (or something) 3 times to move the items to three days from now.

+1.

John

Re: [O] do it today, or well, tomorrow

[John Wiegley]

 Andrea Crotti andrea.crott...@gmail.com writes:

 On 10/12/2011 03:54 PM, Dave Abrahams wrote:
 Binding `org-agenda-date-later' to a key like `f' ought to work out for
 you.

 'f' is already bound to next-week, and it's also quite useful.

I bind M-n/p to next/perv-week/day/etc.

John

Re: [O] do it today, or well, tomorrow

[John Wiegley]

 Andy Moreton andrewjmore...@gmail.com writes:

 I bind M-n/p to next/perv-week/day/etc.

 I fervently hope this an unfortunate typo. A whole week ? :-)

LOL.  Somehow, flyspell thinks prev is less correct than perv.

John

Re: [O] [feature request] More flexible repeats

[John Wiegley]

 Michael Steeves stee...@raingods.net writes:

 If I have something that I want to track in terms of consistency, and want
 to do it during the weekdays, is there a way I could express that other then
 having a series of 5 habits, one for each day of the week, each one of which
 would repeat every week?

The best answer I have for that is to schedule the habit with a daily repeat,
and then just check it off for the weekend days when it doesn't apply.  Then
you're being consistent, it's just that done doesn't necessarily mean that
you physically did something.

John

Re: [O] [feature request] More flexible repeats

[John Wiegley]

 Dave Abrahams d...@boostpro.com writes:

 I have habits that I need to perform, e.g., every weekday, or four times a
 week.  I don't see a way to express that.  If I could schedule a task for
 +1.4d or +1.75d (respectively), I'd be happy.

Habits aren't really for scheduling, they're for monitoring a simple kind of
consistency.  So, if you *actually* need to do something four times a week,
habits aren't the best way to express that need.

If I had something that I wanted to do around four times a week, I'd use this:

  .+1d/2d

Which means, I could do it 7 times a week, or I should do it 3 times a week,
but I'm likely going to fall somewhere in between.

Habits were never meant as a precise way to keep you on a schedule.  The
closest way I can think of to do that within Org's current framework is to
schedule four different instances of your task, each with its own 1 week
repeating interval.  That way, you'd see the item appearing in your agenda
four times.  However, if you start slipping, things get very messy, very fast.

Lastly, even if you did have a 1.4d repeating interval for a habit, Habits
would only show you if you'd been consistent at doing the task every 1.4 days.
It would never be able to tell you if you'd been consistent at doing it 4
times within any given week.

John

Re: [O] deft - A Notational Velocity mode for emacs

[John Wiegley]

 timetrap  timet...@gmail.com writes:

 http://jblevins.org/projects/deft/

 This is different than org-velocity, as it uses multiple text files rather
 than an org-file or a bucket file, you can also add or delete files from
 within deft-mode.

This is a *lot* like howm-mode, which adds Wiki-linking on top of the features
mentioned in the Deft page.  I do like Deft's incremental searching.

John

Re: [O] Change in org-babel with indenting code blocks?

[John Wiegley]

 Bastien  b...@altern.org writes:

 I will fix this today.  Sorry this caused so much problems.

Thanks so much, Bastien, you're awesome.

John

Re: [O] Change in org-babel with indenting code blocks?

[John Wiegley]

 Nick Dokos nicholas.do...@hp.com writes:

 Perhaps Seb Vauban identified the bug correctly (earlier in this thread): he
 pointed to the thread entitled Extra space inserted in repeated task's date
 line - see

  http://thread.gmane.org/gmane.emacs.orgmode/45623

In the current Org (updated today), this problem now affects *all* non-drawer
text in entries, including code blocks, lists, and log entries!  This is makes
entry shifting completely useless to me.  What do I need to revert to make it
work again?

Thanks,
  John

Re: [O] Change in org-babel with indenting code blocks?

[John Wiegley]

 John Wiegley jwieg...@gmail.com writes:

 In the current Org (updated today), this problem now affects *all*
 non-drawer text in entries, including code blocks, lists, and log entries!
 This is makes entry shifting completely useless to me.  What do I need to
 revert to make it work again?

Actually, it even worse: This affects all refiled blocks as well, resulting in
the indentation of the refiled entry being the same as the original level it
was captured in.  I just went through my entire Org file by eye and found a
huge number of indentation problems resulting from this bug.  Help!

John

Re: [O] Change in org-babel with indenting code blocks?

[John Wiegley]

 Nick Dokos nicholas.do...@hp.com writes:

 And while I'm at it, what is r bound to? In my case, it is
 'org-self-insert-command: even after turning on org-indent-mode, r
 self-inserts. What am I missing?

It is a speed key, which is bound only when point is on the '*' of a
headline.

John

Re: [O] Change in org-babel with indenting code blocks?

[John Wiegley]

 Nicolas Goaziou n.goaz...@gmail.com writes:

 So for now, a solution would be to move the block after the drawer.

I prefer my PROPERTIES block to be last, so I need another solution.

 I haven't checked but I don't think it is new.

I've been shifting code-containing entries for many months now.  This only
just started happening.

Thanks, John

[O] Change in org-babel with indenting code blocks?

[John Wiegley]

I don't have any org-babel variables customized.  I have a code block like
this:

*** NOTE Assets:Receivable:CEG
#+begin_src sh :results value :exports results
ledger reg --inject=Expected '^income:ceg'
ledger reg --sort date -b 2007 receivable:CEG
#+end_src
:PROPERTIES:
:ID:   8BEF6C42-8B23-495B-9421-3810B58907A1
:VISIBILITY: folded
:CREATED:  [2010-06-18 Fri 07:37]
:END:

When I put my cursor on the '*' in the heading and hit 'r', I was used to the
whole entry, including the code block, getting indented by one space.  Now
everything *but* the code block gets indented.

Is this new behavior?  How do I get back to the old behavior?  I don't want my
code blocks sticking to a fixed column.

Thanks,
  John

Re: [O] how to add font-lock keywords

[John Wiegley]

 Le Wang l26w...@gmail.com writes:

 I wasn't able to google a clear examples of how to do this.  For example,
 I'd like to highlight all text between double-quotes.

Typically it looks something like this:

  (font-lock-add-keywords org-mode
  (list (list (concat \\(\[^\]+\\\))
  1 highlight-face t)))

Where `highlight-face' is the face you'd like to use.  The regexp doesn't
handle cases where \ legitimately occurs in a string, either.  The part
between the \\(\\) is what gets colorized.

John

Re: [O] how to add font-lock keywords

[John Wiegley]

 John Wiegley jwieg...@gmail.com writes:

 Le Wang l26w...@gmail.com writes:
 I wasn't able to google a clear examples of how to do this.  For example,
 I'd like to highlight all text between double-quotes.

 Typically it looks something like this:

   (font-lock-add-keywords org-mode
[...]

Sorry, that should be 'org-mode, to name the symbol, not attempt to use its
value.

John

[O] Experiences with literate elisp and ob-tangle?

[John Wiegley]

Hi all, I'm considering switching my lengthy .emacs over to a literate Org
file, using ob-tangle, and as I was wondering if others had any experience
with this, and if so, does it slow down startup much?  Is there a way to get
ob-tangle to compile the resulting Elisp file?  I'm guessing it does not
regenerate the .el file if no changes have been made to the .org, right?

Thanks,
  John

Re: [O] A new module for Org-mode: Org-X

[John Wiegley]

Achim Gratz strom...@nexgo.ed writes:

 I can easily see how this works with bug/issue trackers.  What I'm not so
 sure is how you imagine it to work with files.  For my part I'm hoping that
 it might be able to get some interface to the various bits and pieces I've
 bookmarked and sometimes put into local versions with the ScrapBook Firefox
 extension.

The backend gets to define what the parts of an entry are.  Some backends will
import actual content into the related Org entry, while others will only
import a link back to the original content.  This is what I would do for a
backend that monitors files within an Inbox directory, for example.

 I'd check source code for FIXME, not TODO.

Sure, this would be configurable through both a customization variable (for
setting default behavior), and through an inherited property (as part of the
backend context).

 If org-x-states is backend specific, why not let the backend define it?

It is defined, by the ox-org backend. :)  I imagine that very soon now, I'll
pay attention to SEQ_TODO and the usual Org variable, rather than having my
own custom variable for this.

 LZW: is there really nothing in Emacs that already does this? In any case it
 seems to belong into an own library and should probably be unbundled from
 org before long.

There's really not!  I wrote it because I imagine at some point wanting to
take a snapshot of the state of an entry, for the purpose of accelerating
certain backends, but I haven't yet found that use.  For now, it's just living
in ox-lzw so that it's under version control.  If it becomes useful, I'll
submit it to Emacs separately and ahead of Org-X.

John

Re: [O] A new module for Org-mode: Org-X

[John Wiegley]

Karl Voit devn...@karl-voit.at writes:

 In my point of view, it is no problem at all because the «API» we do have is
 the format of Org-mode files. Memacs is - unlike your system - not done with
 Emacs at all: Python scripts generate Org-mode files and that is all.

Very likely Org-X will be able to make sure of your backends in some way, to
provide functionality for backends that don't get written Emacs Lisp.

John

Re: [O] A new module for Org-mode: Org-X

[John Wiegley]

Sebastien Vauban wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org
writes:

 Would you have a .emacs part about this (debugging, profiling, etc.) that
 you're willing to share. I am confident that I could jump easier into full
 Emacs Lisp if I would have a better environment.

I'm attaching my lang-emacs-lisp.el file.  The really big modules to know are:

  - edebug  -- sheer brilliance
  - eldoc
  - elint
  - elp (the Emacs Profiler)

If you do a LOT of code hacking in Lisp, then paredit and redshank are
invaluable.  If you only dabble/debug, they are unnecessary.

John



lang-emacs-lisp.el
Description: application/emacs-lisp

Re: [O] [bug] Captured item inserted in the wrong subtree

[John Wiegley]

David Maus dm...@ictsoc.ed writes:

 Does this problem still persist after commit 
 3771185caefc6d35c4ff0523bdbae878f3e92203?

It's all fixed now, thanks David!

John

[O] A new module for Org-mode: Org-X

[John Wiegley]

Hello all,

I've been working a new set of modules for Org to make it easy to associate
Org entries with data in external systems, such as Redmine, Bugzilla,
WordPress, or even your e-mail Inbox.  It's called Org-X, as its meant to
simplify writing linkup code for any system X.

It has two parts: one for users, and one for Org programmers.  The user code
will:

  - create a new entry on the selected remote based on an Org subtree
  - merge changes from all remotes into a subtree
  - push changes from the local subtree up to the remote(s)

For example, I currently use this code with Redmine to simplify creating new
bugs from existing Org tasks, and to push and pull any new comments.

For Org programmers, Org-X provides a data abstraction to ease working with
Org data in a programmatic way.  To add a tag to the current Org entry with
Org-X looks like this right now:

  (let ((entry (org-x-parse-entry)))
(org-x-add-tag entry Hello)
(org-x-replace-entry entry))

Where the value comes in for programmers is that you can propagate such
changes to all associated external systems by just passing t for the
propagate parameter:

  (let ((entry (org-x-parse-entry)))
(org-x-add-tag entry Hello t))

Without having to know what those remote systems even are.  Of course, Org
itself is a backend, which is why the call to `org-x-replace-entry' is no
longer needed here, since propagation will achieve the same affect.

The set of applicable backends is determined by context, and the appropriate
actions decided upon by each backend who answers for a given Org entry.

Anyway, the code is still in the beginnings stages, and in rough shape, with
the API undergoing fluctuations on a daily basis.  But I thought I'd let
people know, as maybe some would like to help flesh out the basics while it's
still so unformed.  My org-x branch is here:

git clone git://github.com/jwiegley/org-mode.git
git checkout -t origin/org-x
or
git remote add -f jwiegley git://github.com/jwiegley/org-mode.git
git checkout -t jwiegley/org-x

I'm currently working on backends for Redmine, Bugzilla and WordPress, since I
have an immediate need for them; but I also have ideas for others, such as a
backend that creates back-linked Org tasks for every FIXME comment in a
source code project...

Thanks, John

Re: [O] A new module for Org-mode: Org-X

[John Wiegley]

Karl Voit devn...@karl-voit.at writes:

 Wow. This looks like exactly what I want to achieve with the
 «Memacs» project on [1]. We certainly need to exchange ideas and
 code :-)

They sure do sound similar in spirit!!  It's like we are tuned to the same
wavelength. :)

 Our plan is to use Python to simply generate org (archive) files from
 different sources since we do have no ELISP knowledge and Python does
 already have beautiful libraries for RegEx, string manipulation, XML, JSON,

I have to say that one of my personal requirements is that such a system be
implemented as much in Emacs Lisp as possible.  I hate debugging code that's
in between Emacs and some other system.  Plus, I have excellent
documentation, debugging and profiling resources available to me in Emacs, but
I've never found anything close to equivalent in Python (and I've tried them
all: ipython, pydb, ropemacs, etc).  Developing in Emacs is just so efficient
and fun, that I do it as much for recreation as to get things done.

 We do not have any code yet but two of my students began to work on the
 project.

Are they Lisp programmers?  If so, perhaps we could combine our efforts.
There are many backends I'd like to write -- such as one that automatically
records ticked articles in my Inbox as linked Org tasks -- but I only have
so much time in each day.

Since my own needs are immediate for this project, I should have the first
three backends for Org-X completed by month's end.  By that time, the core API
should be stable and I'll be ready to merge this code into main.  I've also
been writing for org.texi at the same time, so it will come fully documented
when it arrives.

John

Re: [O] [bug] Captured item inserted in the wrong subtree

[John Wiegley]

Sebastien Vauban wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org
writes:

 Since this morning's update -- though I think I did not update yesterday --,
 I've a weird problem when capture some text through the standard template I
 use for months.

I'm having a similar problem, except that the capturing process now deletes
the first heading after my * Inbox group, and inserts part of the following
headline into my capture buffer, in addition to the new capture template.

John