Re: [O] Minibuffer popup for org-contacts contact linking?

2019-06-17 Thread John Kitchin
I use https://github.com/jkitchin/scimax/blob/master/contacts.el for
something like this. There are helm/ivy interfaces in there for doing
things like you describe. Mostly I use it to fill in email fields in
messages.


Daryl Manning  writes:

> I'm trying to figure out a way to hotkey bringing up a minibuffer in
> ivy/ivy-rich much as I would with say `C-x b/k` for switching/killing
> buffers, but allowing me to filter down to a contact and then, when
> selected, have that put a `C-c l` link into a document for them.
>
> Is there any way to do this? org-contacts documentation is light and while
> there is a search function in there, having trouble bending it as much as
> I'd like to my will (see previous message about a week's notice on
> birthdays/anniversaries) though I like the fact it's nice and lightweight
> and seems to do most of what I want within the workflow I've sort of
> created for myself (
> https://daryl.wakatara.com/a-better-gtd-and-crm-flow-for-emacs-org-mode )
>
> Anyone have any idea or tips on how they've handled that?
> thanks!
> Daryl.


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



Re: [O] table, calc, reorder and protect calculation in one cell

2019-06-17 Thread Uwe Brauer
>>> "MB" == Michael Brand  writes:

> Hi Uwe
> On Tue, Jun 11, 2019 at 11:36 AM Uwe Brauer  wrote:

>> Is this behavior possible? When I delete a row or a column, the  TBLFM
>> is updated, could that be done for reordering?

> You may want to use something like this, (I knew the syntax for ~"$1"~
> and used the formula debugger ~C-c {~ to find the syntax for
> ~"(Smith)"~):

> | name   | C1 | C2 | Res |
> |+++-|
> | Smith  |  9 |  1 | 1.7 |
> | Miller |  6 |  2 |   8 |
> | Adams  |  5 |  5 |  10 |

> #+TBLFM: $4 = if("$1" == "(Smith)", 0.1 * $2 + 0.8 * $3, $3 + $2)

Ha, of course, thanks, why did that occur to me? I am bit surprised by
the () in Smith, should "Smith" not be sufficient? But it is not indeed,
how odd?

Anyhow, thanks a lot.

Uwe 


smime.p7s
Description: S/MIME cryptographic signature


[O] DMARC related changes starting this week for FSF hosted Mailman lists

2019-06-17 Thread Ian Kelling
Over the next few days, the Free Software Foundation will be making
changes to our GNU Mailman systems, including lists.gnu.org,
lists.nongnu.org, lists.libreplanet.org, lists.fsf.org, and
lists.endsoftwarepatents.org, in order to address mailing list
deliverability issues reported by many users.

I wanted to specifically let orgmode know about this since it is a
fairly active list that is affected.

Messages sent from users with strict DMARC policy domains like yahoo.com
are often being rejected when sent to list subscribers by Mailman. See
the end of this email for a technical overview of DMARC and DKIM. There
are two ways to fix the issue by changing Mailman list settings.

The first option, and the preferable way for discussion lists, is what
we call the "unmodified message fix." There are Mailman list settings
which modify the messages by adding a subject prefix (e.g. [list-name])
or a footer. Modifying the message breaks DKIM message signatures and
thus DMARC. Following this option, we would turn those settings
off. Many lists are already this way and there is no change for
them. Instead of using the subject prefix to identify a list,
subscribers should use the "List-Id" header, To, and Cc.  List footer
information can also be be put in the welcome email to subscribers and
the list information page by list administrators.

Related to this, on June 7th, we upgraded the version Mailman that we
run. This fixed a bug where we were breaking the DKIM signature of any
reply message.

The second option is for lists which want or need to continue to modify
the message, for example with subject prefix or footer settings. We
would enable a Mailman list setting called dmarc_moderation_action:
"Munge From". With this setting, if a strict DMARC sender sends to the
list, we alter the headers of that message like so:


A message sent to the list:

To: al...@gnu.org
From: Anne Example Person 
Subject: Hi, I have a suggestion to improve x

The message Mailman sends to list subscribers:

To: al...@gnu.org
From: Anne Example Person via Alist 
Reply-To: Anne Example Person 
Subject: [alist] Hi, I have a suggestion to improve X

Without going into all of the details, here's a few points about why we
concluded the unmodified message fix is better for discussion
lists. Email clients don't all treat munged messages the same way as
unmunged, and humans read these headers so it can confuse people,
causing messages not to be sent to the expected recipients. GNU Mailman
has an option to do "Munge From" always, but does not recommend using
it[1]. While we're not bound by what others do, it's worth noting that
other very large free software communities like Debian GNU/Linux have
adopted the unmodified message fix[2]. The unmodified messages fix
avoids breaking DKIM cryptographic signatures, which show the message was
authorized by the signing domain.

New discussion lists' default settings will be to send unmodified
messages. Existing discussion lists that add subject prefixes or footers
will have "Munge From" turned on, and then we will email the list
administrators and moderators asking if they are ok with changing to
unmodified messages. If they do not object within 1 month, we will
change their list settings to send unmodified messages. Sometimes the
list administrators and moderators emails goes out of date. If you have
the administration password for a list, please log in and check that
they are up to date at the top of the "General Options" section of the
list administration interface.

For announcement lists that do not have discussion, munging does not
have nearly as bad an impact. Announce lists with subject prefixes or
footers will get "Munge From" applied. I will email the list owners and
moderators to let them know about this issue and they can change to
using unmodified messages if they want. Announce lists created in the
future will send unmodified messages by default.

Debbugs lists prepend a bug # to the subject. These will get "Munge
From" applied. An example of a debbugs list is bug-gnu-emacs[3]. Debbugs
maintainers can consider if there are any other changes they want.

For -commit lists, commit messages are created by a program running on a
single server, not the authors in the from headers. This means they cannot have
valid DKIM signatures and so they will get "Munge From" applied and
always need it. An example of a -commit list is gnuastro-commits[4].

For any Mailman list administrator who wants to change or look over the
relevant settings: The dmarc_moderation_action setting is under "Privacy
Options" subsection "Sender Filters". The only options that should be
selected are "Accept" or "Munge From", along with corresponding changes
to the subject_prefix option under "General Options", and msg_footer
under "Non-digest options".


A short DMARC technical overview:

DMARC policy is a DNS txt record at a _dmarc subdomain. For example:

$ host -t txt _dmarc.yahoo.com
_dmarc.yahoo.com descriptive text "v=DMARC1;

[O] Bug: Docstrings of =org-agenda-todo-ignore-with-date= and =org-agenda-todo-ignore-timestamp= unclear [9.2 (release_9.2-215-g5b39d8 @ /home/mbork/others-works/emacs/org-mode/lisp/)]

2019-06-17 Thread Marcin Borkowski



Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


The docstrings of =org-agenda-todo-ignore-with-date= and
=org-agenda-todo-ignore-timestamp= do not really tell what these
settings are doing.  They should (imho) emphasize that the former just
omits from the global todo list all entries with at least one active
timestamp (in the hedaline or the body), and the latter checks the first
active timestamp which is not SCHEDULED or DEADLINE and compares it to
today's date.

It could also be mentioned in the manual.

I have GNU papers for Emacs signed.  If this is enough, I'd be happy to
submit a patch.  If so, what would be better: to patch only the
docstrings or the docstrings and the manual.

Best,
mb


Emacs  : GNU Emacs 27.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.8)
 of 2019-06-15
Package: Org mode version 9.2 (release_9.2-215-g5b39d8 @ 
/home/mbork/others-works/emacs/org-mode/lisp/)
-- 
Marcin Borkowski
http://mbork.pl