Re: [O] New feature? Remove duplicate subheadings, preserving order

[Adam Porter]

Nick Dokos  writes:

> There be dragons.
>
> The problem is that some things happen invisibly and far away from
> where you are, so you don't know about it and you don't find out for a
> couple of weeks.  Undo and automatic backups are useless in that case.
>
> That *has* happened: there have been multiple postings in the ML about
> such problems. Whenever it has happened, the devs have always modified
> org to make it safer: that is the prudent thing to do and the correct
> course of action IMO.
>
> Hell hath no fury like an orgmode user who lost part of his/her
> precious org file because of an errant keystroke a month ago and was
> not aware of the loss until it was too late.

Indeed.  Maybe I'm just paranoid, but having worked with Org code a bit,
I still wonder sometimes if I have ever accidentally wiped out a subtree
without noticing.  Would I ever notice that it's missing?  Even if it's
stored in git or a backup, how can I restore something that I don't know
needs restoring?

Some of this is simply the nature of computers, I think--a keystroke
here, a blink of the eye there, and poof, the data is gone.  If the
point is in one buffer when my fingers press C-c C-x C-w, but my eyes
are in another buffer, does the subtree still get deleted?  :)

And despite how great Emacs and Org are, this is one area in which their
power may make them more vulnerable to such issues.  Their use of global
state and special variables also makes unintended consequences easier to
achieve.

This is why I think we should always be very careful.  Org is nothing if
we can't trust it to keep our data safe!  :)

Re: [O] specify different agenda item colors for different custom agenda views

[Adam Porter]

Nicolas Goaziou  writes:

> Hello,
>
> Rainer Stengele  writes:
>
>> These posts which stay unanswered - either they are too stupid or too
>> complicated?!
>
> AFAIC, questions about the Agenda tend to belong to the second
> category.

Indeed!  :)

>> Anybody an idea, a hint?
>
> It may help to know what you have tried so far. For example, how is your
> block configuration, including the settings part (see
> `org-agenda-custom-commands' docstring)?
>
> Note that it might not be possible to achieve what you want.

Probably the way to do it would be to wrap the agenda code which
operates on certain files, and let-bind the org-agenda-done face around
that code depending on which file it is.  That would probably require
copying the function in question and overriding it with advice.
Certainly doable (on first glance, anyway), but not easy for someone
unfamiliar with elisp or the agenda code.

I would guess that a more general solution, which could bind certain
variables to certain values depending on which file the agenda is being
constructed from, could be useful in other ways as well.  It might be
possible to integrate this with org-agenda-custom-commands, or in a
customizeable variable mapping files to lists of variables, to make it
fairly straightforward to use.

Re: [O] New feature? Remove duplicate subheadings, preserving order

[Adam Porter]

Allen Li  writes:

> Designing around actual use cases that users have an immediate use for
> is better than trying to predict what users might need in the far
> future, especially if adding those features requires extra complexity.

You seem to be approaching this from a "use case" perspective.  I and
several other posters on the list are concerned from the "potential
damage" perspective.  It's vitally important as software developers to
anticipate potential user *actions*, regardless of their intentions or
needs, and to proactively defend against mistakes that may cause data
loss.

>  Everyone should be keeping reliable backups.  This is reiterated all
>  the time, yet no one seems to follow it? =)

As I mentioned, I am not merely hypothesizing: I have experienced such
data loss myself, which I only recovered months after the fact when I
noticed and was able to track it down in the git repository I
automatically commit most of my Org files to.  This was a
time-consuming, laborious, manual process which we cannot expect most
Org users to be able to do; how many Org users do you think know how to
use git and commit all their Org files to it?  On top of that, as I and
others mentioned, due to the nature of Emacs, Org, and plain-text
buffers, it is very easy for such changes to happen outside the visible
portion of the buffer, in which case even the most experienced user is
unlikely to notice such data loss.  In that case, it might go
permanently unnoticed.  For example, I have some large Org files that I
capture data into, with hundreds or thousands of top-level headings.  If
I accidentally cut one of those subtrees, outside the visible portion of
the buffer, which I had captured weeks or months earlier, how would I
even know that it was missing?  Most likely I would not, because the
whole point of storing them in Org is that I will forget about them if I
don't.

An analogy is, if you ran an "rm -rf" command with a wildcard, and
accidentally left off a slash somewhere without realizing it, how long
would it be before you noticed that you had deleted the wrong data?
What if you were operating on a directory deep in a hierarchy that is
essentially an archive of rarely accessed files?  How long would it be
before you noticed the mistake?  Would you still be able to recover from
it?  What if this happened in a script you wrote, rather than an
interactive command?  Have you ever made a mistake in a Bash script that
had undesirable effects?  I can't help but be reminded of this recent
classic:

https://github.com/ValveSoftware/steam-for-linux/issues/3671

Another anecdote: I once almost lost my GPG private key, because somehow
(I still have no idea what happened) it was truncated.  This went
unnoticed by me for a long time, and the truncated file was *backed up*
over and over again.  When I finally noticed, all of my readily
available backups had the truncated version of the file.  I was
only--very luckily!--able to recover it by digging out old CD-R backups
I had made years earlier, one of which had an intact copy of the file.
That experience taught me some lessons, among which are 1. Keep your old
backups, and 2. Respect Murphy's Law.

> If you had an immediate use case in mind, I would love to hear it.
> There's no need to suggest your use case as conceivable if it's
> something you could benefit from immediately.

So the "use case" here is simply "using Org, without losing data by
accidentally activating a command in Emacs that operates on data that
may or may not be currently visible--because Emacs and Org are
incredibly complex software that is extensively customized by users in
ways that the developers often do not anticipate--therefore we should
use extra caution in code that manipulates user data in destructive
ways."

I hope that these explanations help clarify our perspectives.  We are
not attacking you, your code, or its potential usefulness.  We are
simply concerned about implementing such things in ways that are best
for users.

Thanks,
Adam

Re: [O] BeOrg

[Scott Randby]

On 01/02/2018 09:43 PM, Ilya Shlyakhter wrote:
> "as a GNU package, we're not allowed to mention proprietary software"
> -- how is that consistent with GNU prominently distributing Emacs for
> Windows from its own website?  I think this shows that the guideline
> is not absolute.  And it's specifically phrased as a guideline
> ("should"), not as a requirement.
> 

Emacs for Windows is still free software with source code and everything. BeOrg 
is not free software.

Scott Randby

Re: [O] BeOrg

[Ilya Shlyakhter]

"as a GNU package, we're not allowed to mention proprietary software"
-- how is that consistent with GNU prominently distributing Emacs for
Windows from its own website?  I think this shows that the guideline
is not absolute.  And it's specifically phrased as a guideline
("should"), not as a requirement.

To _mention_ is not the same as to _endorse_.  One can mention a
non-free program, along with a link to GNU's reasoning against such
programs, and let users decide.  Deciding for them is paternalistic.
It also looks like simple protectionism: rather than writing a free
program superior to the non-free one, mentioning both and letting
users decide, we'll just hide the non-free one.

I don't see why not to write beOrg at all is perfectly ethical, but to
write it without making it free is unethical.  What freedoms does a
non-existing program give users?

On Tue, Jan 2, 2018 at 9:06 PM, Ian Dunn  wrote:
>> "Peter" == Peter Davis  writes:
>
> Peter> If we refuse to provide useful information just because it
> Peter> violates some purist idea of what is or is not acceptably
> Peter> unencumbered, then we’re just denying users potential helpful
> Peter> capabilities that may make the difference between using
> Peter> org-mode or abandoning it completely in favor of some
> Peter> commercial, cross-platform solution.
>
> Nicolas mentioned that as a GNU package, we're not allowed to mention
> proprietary software[1].  My understanding is that the reasoning behind
> this is that we don't want to appear to endorse proprietary software.
> The GNU project finds proprietary software unethical, so they will not
> see it as providing useful information, but endorsing an unethical
> solution.
>
> Peter, I understand your reasoning; the LGPL was designed specifically
> for this purpose, i.e. allowing a non-free solution built upon a free
> one.  However, I don't believe we should encourage use of such solutions
> without evidence that people are turned away from Org mode because of a
> mobile solution they don't like.
>
> [1] https://www.gnu.org/prep/standards/html_node/References.html#References
>
> --
> Ian Dunn

Re: [O] BeOrg

[Ian Dunn]

> "Peter" == Peter Davis  writes:

Peter> If we refuse to provide useful information just because it
Peter> violates some purist idea of what is or is not acceptably
Peter> unencumbered, then we’re just denying users potential helpful
Peter> capabilities that may make the difference between using
Peter> org-mode or abandoning it completely in favor of some
Peter> commercial, cross-platform solution.

Nicolas mentioned that as a GNU package, we're not allowed to mention
proprietary software[1].  My understanding is that the reasoning behind
this is that we don't want to appear to endorse proprietary software.
The GNU project finds proprietary software unethical, so they will not
see it as providing useful information, but endorsing an unethical
solution.

Peter, I understand your reasoning; the LGPL was designed specifically
for this purpose, i.e. allowing a non-free solution built upon a free
one.  However, I don't believe we should encourage use of such solutions
without evidence that people are turned away from Org mode because of a
mobile solution they don't like.

[1] https://www.gnu.org/prep/standards/html_node/References.html#References

-- 
Ian Dunn

Re: [O] BeOrg

[Thomas S. Dye]

Aloha all
Peter Davis writes:


On Tue, Jan 2, 2018, at 3:43 PM, Nicolas Goaziou wrote:


I think you are missing the point. Free software is primarily 
about

source code (the four definitions).


If we refuse to provide useful information just because it 
violates some
purist idea of what is or is not acceptably unencumbered, then 
we’re
just denying users potential helpful capabilities that may make 
the
difference between using org-mode or abandoning it completely in 
favor

of some commercial, cross-platform solution.


IIUC, the question is about where to provide this information, not 
whether or not to provide it.  OP asked about putting it in the 
Org manual and Nicolas has pointed out that the manual is for 
documenting Org software.


Perhaps Worg is a better place to provide information about BeOrg?

hth,
Tom

--
Thomas S. Dye
http://www.tsdye.com

Re: [O] Bug: incorrect display of tables after alignment [9.1.8 (9.1.8-elpa @ /Users/michelschinz/.emacs.d/elpa/org-20171228/)]

[Melleus]

Michel Schinz  writes:

> (Melleus, the same procedure should fix the problem for you too).

Yes, after update I got version 9.1.5 and everything works perfectly
with tables now. Thank you, guys.

Re: [O] BeOrg

[Peter Davis]

On Tue, Jan 2, 2018, at 3:43 PM, Nicolas Goaziou wrote:
>
> I think you are missing the point. Free software is primarily about
> source code (the four definitions).

I’m not well versed in the theories and arguments for or against free or
open source software. However, based on my 40 years of experience as a
software developer and UI designer, I would say ALL software, free or
otherwise, is about usability and usefulness. Otherwise, there’s no
reason for that software to exist.
If we refuse to provide useful information just because it violates some
purist idea of what is or is not acceptably unencumbered, then we’re
just denying users potential helpful capabilities that may make the
difference between using org-mode or abandoning it completely in favor
of some commercial, cross-platform solution.
--
  Peter Davis
  www.techcurmudgeon.com

Re: [O] New feature? Remove duplicate subheadings, preserving order

[Allen Li]

On Tue, Jan 2, 2018 at 6:36 AM, Robert Horn  wrote:
>
> Allen Li writes:
>
>> On Mon, Jan 1, 2018 at 8:07 PM, Adam Porter  wrote:
>>
>> I don’t see a use case for checking all heading data.
>>
>
> I can see such cases arising from templates and time tracking.  I can
> have a template that captures telephone calls.  The call comes in and I
> start the template.  At this point the heading is just "Received Phone
> Call" and a time tracking start.  Time tracking is eventually kept in a
> drawer, not in the headline.
>
> I might eventually go back an revise the headline based on notes from
> the call, but that will not happen during the call.  It's quite likely
> that sorting out the calls will happen at the end of the day or the next
> day.
>
> Similarly, I receive lab results.  These will initially be a headline
> with just "Lab Result", a time tag like CLOCK, and a tag to indicate
> that it is a lab result.  Some time later I might move them around to
> attach them to a patient or project, but often by just moving them as
> element into the right section for that patient or project.  So these
> also have the same headline contents and different headline data.

It doesn’t sound like you end up with duplicates though?  How do you
envision using duplicate removal for your workflows?

In any case, it sounds like you want to assign unique IDs to each entry
as suggested by Florian and remove duplicates using IDs instead of
matching against heading data, which could collide through sheer luck.

Re: [O] New feature? Remove duplicate subheadings, preserving order

[Allen Li]

On Tue, Jan 2, 2018 at 7:28 AM, Florian Beck  wrote:
>
>> AFAIK, this is the first time this need is expressed on this ML. There
>> is no equivalent in "org-list.el" either.
>
>
> A way to handle duplicates would be useful, indeed. But a basic function
> should only remove duplicates that are truly identical (same properties,
> same tags, same/no content). Still, removing true duplicates from subtrees
> (AND lists) would be useful.
>
> More useful would be a slightly more general approach. I have three kinds of
> duplicates:
>  - duplicate IDs (which are handled rather poorly),
>  - duplicate content (which often is only almost identical) and
>  - duplicate headings (which usually I want to rectify when they are on
>the same level of the same subtree)
>
> As you can see, a fixed concept of duplication is probably not going to
> work.

It sounds like this problem might vary too much across use cases to
generalize and include in Org mode because...

>
> What I'd like is a function finds duplicates according to scope, match (as
> in `org-map-entries') and a user defined function. This function should then
> display the problem cases (via agenda view?). Then we need a couple of
> convenience functions like
>  - delete all duplicates but the one at point,
>  - mark duplicates I want to keep,
>  - uniquify entries (tricky; for headlines maybe prompt the user; for
>IDs, we should check if the ID is referenced from somewhere)
>  - merge entries.
>
> But then, I also have duplicates (in content) I want to keep, e.g. one in my
> notes and in a writing project. So, we'd need a property like
> "DUPLICATE_OF".

You’re requesting a different feature, removing duplicates across all
agenda files.  My initial proposal was just for removing duplicate
direct children (whether by heading or full text pending discussion)
under the heading at point.

Re: [O] New feature? Remove duplicate subheadings, preserving order

[Allen Li]

On Tue, Jan 2, 2018 at 8:36 AM, Nick Dokos  wrote:
> Allen Li  writes:
>>
>> There is always undo and automatic Emacs file backups.
>>
>
> There be dragons.
>
> The problem is that some things happen invisibly and far away from
> where you are, so you don't know about it and you don't find out for a
> couple of weeks.  Undo and automatic backups are useless in that case.
>
> That *has* happened: there have been multiple postings in the ML about
> such problems. Whenever it has happened, the devs have always modified
> org to make it safer: that is the prudent thing to do and the correct
> course of action IMO.
>
> Hell hath no fury like an orgmode user who lost part of his/her
> precious org file because of an errant keystroke a month ago and was
> not aware of the loss until it was too late.

I can see where you're coming from, but for me there are various reasons
why I don’t think warning is right:

1. org-sort-entries, which performs an action of similar scope and
   destructiveness, does not need to warn so far.

2. Since I see the only use case for warning is checking beforehand, a
   user that uses this command frequently is not going to type C-c d C-u
   C-c d every time (assuming the user has bound this command to C-c d),
   they’re just going to type C-u C-c d or get frustrated and just bind
   the actual command without warning to C-c d.  So warning provides
   zero safety in practice.

   Another possibility is using a y or n confirmation prompt before
   removing duplicates, however this falls into the same trap that a
   user who uses this frequently is just going to bind the command to a
   key and disable this check.

3. I don’t propose binding this command to any key by default, and I
   don’t think M-x org-remove-duplicates RET is a very common typo.

4. The only commands in Emacs that warn beforehand are truly
   irreversible commands, like deleting in Dired or killing a buffer.
   Everything else in Emacs follows the philosophy of using undo if the
   user makes a mistake, including lots of commands that could have
   unintentional, low visibility effects.  I would prefer following this
   policy unless it proves to actually be a problem.  It seems like
   org-sort-entries in practice has not suffered from this problem, so I
   believe a remove duplicates command will similarly not suffer from
   this problem in practice.

5. Everyone should be keeping reliable backups.  This is reiterated all
   the time, yet no one seems to follow it? =)

>
> --
> Nick
>
>

Re: [O] BeOrg

[Nicolas Goaziou]

Ilya Shlyakhter  writes:

>>as GNU software, we should not suggest to use non-free software
>
> But, clearly, we already do: suggesting to use MobileOrg necessarily
> suggests to use iOS.
>
> Besides, some of the main critiques of non-free software do not apply
> here: e.g. beorg doesn't lock the user into some proprietary format.

I think you are missing the point. Free software is primarily about
source code (the four definitions). Vendor lock-in is but one of the
possible consequences of non-free software. It's still non-free.

> And while it may be unethical to lure unsophisticated computer users
> into freedom-relinquishing decisions the consequences of which they
> may not fully grasp, most Org users are sophisticated enough to make
> an intelligent and informed choice.

Straw man argument.

> GNU itself distributes Emacs for Windows from its main site (
> http://ftp.gnu.org/gnu/emacs/windows/ ), so there's a balance of
> considerations.  I think here the balance tips in favor of mentioning
> beOrg.  I've tried MobileOrg and gave up on it, while beOrg is more
> usable; judging by the reviews, others had a similar impression.

beOrg may be technically superior, yet usability has never been
a criterion.

Really there's no balance at all: this software doesn't use any of our
libraries and doesn't share our goals. I'm happy someone developed such
software, really, but the way it was done saddens me. If you think that
is worth the shot, you may want to convince its author to turn beOrg
into free software (is that even possible on the Apple store?).

In any case, you may want to discuss this further on gnu-misc-discuss
mailing list, or possibly emacs-devel. For the time being, as far as Org
is concerned, I stand on my ground: there is no reason to reference it
in the manual.

Re: [O] BeOrg

[Ilya Shlyakhter]

>as GNU software, we should not suggest to use non-free software

But, clearly, we already do: suggesting to use MobileOrg necessarily
suggests to use iOS.

Besides, some of the main critiques of non-free software do not apply
here: e.g. beorg doesn't lock the user into some proprietary format.
And while it may be unethical to lure unsophisticated computer users
into freedom-relinquishing decisions the consequences of which they
may not fully grasp, most Org users are sophisticated enough to make
an intelligent and informed choice.

GNU itself distributes Emacs for Windows from its main site (
http://ftp.gnu.org/gnu/emacs/windows/ ), so there's a balance of
considerations.  I think here the balance tips in favor of mentioning
beOrg.  I've tried MobileOrg and gave up on it, while beOrg is more
usable; judging by the reviews, others had a similar impression.


On Tue, Jan 2, 2018 at 2:20 PM, Nicolas Goaziou  wrote:
> Hello,
>
> ilya shlyakhter  writes:
>
>> Neither is iOS or MATLAB, and yet the Org manual mentions both.
>
> We have good reasons for that. The former is because MobileOrg, which
> uses "org-mobile.el", provided by Org, and therefore, documented. The
> latter is because "ob-matab.el", which is free software.
>
> OTOH, as GNU software, we should not suggest to use non-free software.
> Besides, it is not related to any library in our source code.
>
> Regards,
>
> --
> Nicolas Goaziou

Re: [O] BeOrg

[Nicolas Goaziou]

Hello,

ilya shlyakhter  writes:

> Neither is iOS or MATLAB, and yet the Org manual mentions both.

We have good reasons for that. The former is because MobileOrg, which
uses "org-mobile.el", provided by Org, and therefore, documented. The
latter is because "ob-matab.el", which is free software.

OTOH, as GNU software, we should not suggest to use non-free software.
Besides, it is not related to any library in our source code.

Regards,

-- 
Nicolas Goaziou

Re: [O] BeOrg

[ilya shlyakhter]

>This may be because the app is not open source?

Neither is iOS or MATLAB, and yet the Org manual mentions both.

On Tue, Jan 2, 2018 at 12:39 PM, Eric S Fraga  wrote:
> On Tuesday,  2 Jan 2018 at 12:32, Ilya Shlyakhter wrote:
>> The org features page at https://orgmode.org/features.html, and the
>> Org manual, mention MobileOrg, but not the newer BeOrg app
>> ( http://beorgapp.com/ ).  Maybe add a reference to it?
>
> This may be because the app is not open source?
>
> --
> Eric S Fraga via Emacs 27.0.50, Org release_9.1.6

Re: [O] BeOrg

[Eric S Fraga]

On Tuesday,  2 Jan 2018 at 12:32, Ilya Shlyakhter wrote:
> The org features page at https://orgmode.org/features.html, and the
> Org manual, mention MobileOrg, but not the newer BeOrg app
> ( http://beorgapp.com/ ).  Maybe add a reference to it?

This may be because the app is not open source?

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.1.6


signature.asc
Description: PGP signature

[O] BeOrg

[Ilya Shlyakhter]

The org features page at https://orgmode.org/features.html, and the
Org manual, mention MobileOrg, but not the newer BeOrg app
( http://beorgapp.com/ ).  Maybe add a reference to it?

Re: [O] New feature? Remove duplicate subheadings, preserving order

[Nick Dokos]

Allen Li  writes:

>
> I don’t see a use case for checking all heading data.
>
>>> Since the point would be remove duplicates from lists, I don’t think
>>> warning is very useful.  I would want to remove the duplicate list
>>> items, not get a warning about it and delete them manually.  Perhaps
>>> that would be a useful additional feature however (like uniq -d).
>>
>> I think warning or asking for confirmation should be the default action,
>> because it's the safest option.  Users who want to skip that could use a
>> prefix argument or call it from a custom command.
>
> There is always undo and automatic Emacs file backups.
>

There be dragons.

The problem is that some things happen invisibly and far away from
where you are, so you don't know about it and you don't find out for a
couple of weeks.  Undo and automatic backups are useless in that case.

That *has* happened: there have been multiple postings in the ML about
such problems. Whenever it has happened, the devs have always modified
org to make it safer: that is the prudent thing to do and the correct
course of action IMO.

Hell hath no fury like an orgmode user who lost part of his/her
precious org file because of an errant keystroke a month ago and was
not aware of the loss until it was too late.

-- 
Nick

Re: [O] New feature? Remove duplicate subheadings, preserving order

[Florian Beck]

AFAIK, this is the first time this need is expressed on this ML. There
is no equivalent in "org-list.el" either.


A way to handle duplicates would be useful, indeed. But a basic function 
should only remove duplicates that are truly identical (same properties, 
same tags, same/no content). Still, removing true duplicates from 
subtrees (AND lists) would be useful.


More useful would be a slightly more general approach. I have three 
kinds of duplicates:

 - duplicate IDs (which are handled rather poorly),
 - duplicate content (which often is only almost identical) and
 - duplicate headings (which usually I want to rectify when they are on
   the same level of the same subtree)

As you can see, a fixed concept of duplication is probably not going to 
work.


What I'd like is a function finds duplicates according to scope, match 
(as in `org-map-entries') and a user defined function. This function 
should then display the problem cases (via agenda view?). Then we need a 
couple of convenience functions like

 - delete all duplicates but the one at point,
 - mark duplicates I want to keep,
 - uniquify entries (tricky; for headlines maybe prompt the user; for
   IDs, we should check if the ID is referenced from somewhere)
 - merge entries.

But then, I also have duplicates (in content) I want to keep, e.g. one 
in my notes and in a writing project. So, we'd need a property like 
"DUPLICATE_OF".

[O] bug#24865: more information

[Nicolas Goaziou]

Nicolas Goaziou  writes:

> Hello,
>
> Wensheng Xie  writes:
>
>> Hi, bug-fixer:
>>
>> I find out that my link description text contain "[" and "]" so that the
>> display is not correct.
>>
>> Is it a bug or is there a way to use "[" and "]" in the description
>> text?
>
> Square brackets are forbidden in description text. If you use
> `org-insert-link', it changes them into curly brackets.

Closing bug report per OP request.

Re: [O] New feature? Remove duplicate subheadings, preserving order

[Robert Horn]

Allen Li writes:

> On Mon, Jan 1, 2018 at 8:07 PM, Adam Porter  wrote:
>
> I don’t see a use case for checking all heading data.
>

I can see such cases arising from templates and time tracking.  I can
have a template that captures telephone calls.  The call comes in and I
start the template.  At this point the heading is just "Received Phone
Call" and a time tracking start.  Time tracking is eventually kept in a
drawer, not in the headline.

I might eventually go back an revise the headline based on notes from
the call, but that will not happen during the call.  It's quite likely
that sorting out the calls will happen at the end of the day or the next
day.

Similarly, I receive lab results.  These will initially be a headline
with just "Lab Result", a time tag like CLOCK, and a tag to indicate
that it is a lab result.  Some time later I might move them around to
attach them to a patient or project, but often by just moving them as
element into the right section for that patient or project.  So these
also have the same headline contents and different headline data.

R Horn

Re: [O] top headline's visibility property blocked by subheadline's property

[Nicolas Goaziou]

Hello,

Michael Maurer  writes:

> Basically what I expect is to see 2017 folded, with none of its
> children visible (because I added the visibility/folded property).
> Instead I see all the children, apparently because they themselves
> have a visibility/folded property. When I delete the children's
> visibility/folded property, the 2017 visibility/folded property gets
> respected and they are all folded.
>
> What I want to see
>
> * 2017
> * 2016
>
> What I get
>
> * 2017
> ** January
> ** February
> 
> * 2016
> ** January
> ** February
> 

I see. Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou

[O] Bug: Org tables not correctly displayed in org-mode [9.1.5 (9.1.5-1-gb3ddb0-elpa @ c:/Users/sane/AppData/Roaming/.emacs.d/elpa/org-20171225/)]

[Michael Ziems]

Hello,

since the latest update to org-mode 20171225 the table alignment is not 
displayed properly on windows.

I cannot see the same issue on linux.

Interesstingly it seems to only be in connection with the displaying of 
data: When i copy the table to notepad++ or any other editor it looks 
absolutely proper.


Any idea what could be the issue?

Thanks,

Michael

Emacs  : GNU Emacs 25.3.1 (x86_64-w64-mingw32)
 of 2017-09-26
Package: Org mode version 9.1.5 (9.1.5-1-gb3ddb0-elpa @ 
c:/Users/sane/AppData/Roaming/.emacs.d/elpa/org-20171225/)


current state:
==
(setq
 org-table-export-default-format "orgtbl-to-csv"
 org-hide-leading-stars t
 org-agenda-current-time-string "now - - - - - - - - - - - - - - "
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe 
org-babel-header-arg-expand)

 org-agenda-clockreport-parameter-plist '(:link t :maxlevel 4)
 org-insert-heading-hook '(org-expiry-insert-created)
 org-speed-command-hook '(org-speed-command-activate 
org-babel-speed-command-activate)

 org-occur-hook '(org-first-headline-recenter)
 org-checkbox-hierarchical-statistics nil
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-clock-into-drawer "CLOCK"
 org-log-done 'time
 org-confirm-shell-link-function nil
 org-after-tags-change-hook '(org-expiry-insert-created)
 org-agenda-sticky t
 org-agenda-skip-scheduled-if-done t
 org-display-internal-link-with-indirect-buffer t
 org-agenda-custom-commands '(("x" "Nur Kalender ohne Aufgaben" agenda 
""

   ((org-agenda-span 80) (org-deadline-warning-days 
1)
(org-agenda-include-diary t)
(org-agenda-entry-types (quote (:timestamp 
:sexp)))
(org-agenda-files
 (quote
  ("K:\\Box Sync\\Stuff\\org\\work" "K:\\Box 
Sync\\Stuff\\org\\privat"

   "K:\\Box Sync\\Stuff\\org")
  )
 )
)
   )
  ("p" "Agenda Privat" agenda ""
   ((org-agenda-files
 (quote
  ("K:\\Box Sync\\Stuff\\org\\privat"
   "K:\\Box Sync\\Stuff\\org\\privat\\info")
  )
 )
(org-agenda-span 1) (org-deadline-warning-days 
14)
(org-agenda-include-diary t))
   )
  ("k" "kombinierte Ansicht"
   ((agenda ""
 ((org-agenda-span 1) (org-agenda-include-diary 
t)
  (org-agenda-entry-types (quote (:timestamp 
:sexp
 )
(agenda ""
 ((org-agenda-span 1) (org-agenda-start-day 
"+1d")
  (org-agenda-include-diary t)
  (org-agenda-entry-types (quote (:timestamp 
:sexp)))
  (org-agenda-use-time-grid nil)
  (org-agenda-files
   (quote
("K:\\Box Sync\\Stuff\\org\\work"
 "K:\\Box Sync\\Stuff\\org\\privat")
)
   )
  )
 )
(agenda ""
 ((org-agenda-overriding-header "Aufgaben 
Arbeit")
  (org-agenda-entry-types (quote (:deadline 
:scheduled)))
  (org-deadline-warning-days 5)
  (org-agenda-files
   (quote
("K:\\Box Sync\\Stuff\\org\\work"
 "K:\\Box Sync\\Stuff\\org\\work\\info")
)
   )
  (org-agenda-span 1)
  (org-agenda-sorting-strategy
   (quote (time-up priority-down category-up)))
  )
 )
)
   nil)
  ("2" "Aufgabenliste Privat" alltodo ""
   ((org-agenda-overriding-header "Aufgaben")
(org-agenda-sorting-strategy (quote 
(scheduled-up)))
(org-agenda-files
 (quote
  ("K:\\Box Sync\\Stuff\\org\\privat"
   

[O] bug#22352: 25.0.50; org-capture doesn't work out of the box

[Nicolas Goaziou]

Hello,

Anders Lindgren  writes:

> `org-capture' doesn't work in the default configuration.
>
> emacs -Q
> (setq debug-on-error t) C-j
> M-x org-capture RET
> t
>
> This will yield the error "Target buffer ".notes" for file+headline should
> be in Org mode". The backtrace is as follows:
>
> Debugger entered--Lisp error: (error "Target buffer \".notes\" for
> file+headline should be in Org mode")

Org expects the target file to be in Org mode (or some regexps are not
defined). I demoted it into a warning and let Capture switch to Org mode
nonetheless.

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou0x80A93738

Re: [O] specify different agenda item colors for different custom agenda views

[Nicolas Goaziou]

Hello,

Rainer Stengele  writes:

> These posts which stay unanswered - either they are too stupid or too
> complicated?!

AFAIC, questions about the Agenda tend to belong to the second category.

> Anybody an idea, a hint?

It may help to know what you have tried so far. For example, how is your
block configuration, including the settings part (see
`org-agenda-custom-commands' docstring)?

Note that it might not be possible to achieve what you want.

Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: incorrect display of tables after alignment [9.1.8 (9.1.8-elpa @ /Users/michelschinz/.emacs.d/elpa/org-20171228/)]

[Michel Schinz]

Hello Bastien and Nicolas,

On Tue, Jan 2, 2018, at 12:05, Bastien Guerry wrote:

> Things should be fine now.

Indeed, they seem to be: after upgrading my version of Org from Org's ELPA, the 
problem I reported has disappeared, and M-x org-version reports that it's 
9.1.5, as it should.

(Melleus, the same procedure should fix the problem for you too).

Thank you for the fix,
Michel.

Re: [O] Bug: incorrect display of tables after alignment [9.1.8 (9.1.8-elpa @ /Users/michelschinz/.emacs.d/elpa/org-20171228/)]

[Bastien Guerry]

Hi Michel and Nicolas,

Nicolas Goaziou  writes:

> I think this is an issue with Org ELPA. I'm cc'ing Bastien. 

Yes it was, thanks for reporting it.

Things should be fine now.

PS: I'm on the road, with limited access to my emails, so please bare
with me if there is any delay in fixing this kinds of problems.

-- 
 Bastien

Re: [O] specify different agenda item colors for different custom agenda views

[Rainer Stengele]

Am 19.12.2017 um 14:32 schrieb Rainer Stengele:

Hi all,

I cannot seem to find a way how to customise colors in custom org agenda blocks.
I have 2 agenda views, both drawing from different set of org files.
I would like to have different org-agenda-done faces for the 2 views.

Can anyone give me a hint please.

Thank you.
Regards, Rainer




These posts which stay unanswered - either they are too stupid or too 
complicated?!
Anybody an idea, a hint?

Thank you.
Regards, Rainer

Re: [O] top headline's visibility property blocked by subheadline's property

[Michael Maurer]

On Mon, Jan 1, 2018 at 7:52 PM, Nicolas Goaziou  wrote:
> Hello,
>
> Michael Maurer  writes:
>
>> I'm not sure if this is a feature, or I'm missing something, but if I
>> set up an outline like this:
>>
>> * 2017
>> :PROPERTIES:
>> :VISIBILITY: folded
>> :END:
>> ** december
>> :PROPERTIES:
>> :VISIBILITY: folded
>> :END:
>> *** 31
>> *** 30
>> ** november
>> :PROPERTIES:
>> :VISIBILITY: folded
>> :END:
>>
>> 
>>
>> the headlines underneath 2016 don't get folded.
>
> I'm not sure to understand. Where is headline "2016"? What do you get
> upon opening the document (or pressing C-u C-u )? What did you
> expect instead?
>
> Regards,
>
> --
> Nicolas Goaziou

2016 was a typo, I meant 2017.

Basically what I expect is to see 2017 folded, with none of its
children visible (because I added the visibility/folded property).
Instead I see all the children, apparently because they themselves
have a visibility/folded property. When I delete the children's
visibility/folded property, the 2017 visibility/folded property gets
respected and they are all folded.

What I want to see

* 2017
* 2016

What I get

* 2017
** January
** February

* 2016
** January
** February


Doing a #STARTUP: overview isn't really an option, since I want to see
the content unless I specifiy otherwise.