Re: On the protection of emails in the archives

[Tim Cross]

Kyle Meyer  writes:

> Guillaume MULLER writes:
>
>> Hi all,
>>
>> I recently sent an email on this mailing list (see
>> https://orgmode.org/list/b1e778c5-acbf-8a17-c9bf-dcb6693e9...@univ-st-etienne.fr/
>> )
>>
>> Since then, I'm receiving spams on the email address I used to send
>> the message.
>>
>> After some research, it seems that this email address only appears on
>> 2 websites, notably this orgmode.org mailing list archive.
>
> Your email address can also be harvested from the lists.gnu.org
> archives.  Inspect the output of
>
>   $ curl -fSsL 
> https://lists.gnu.org/archive/html/emacs-orgmode/2020-07/msg00125.html
>   $ curl -fSsL https://lists.gnu.org/archive/mbox/emacs-orgmode/2020-07
>
>> Would it be possible to configure the archive to obfuscate / hide the
>> email addresses inorder to protect its users?
>
>  and its upstream source
>  are public-inbox
> () archives.  There's an option (disabled by
> default) to configure address obfuscation.  However, in my view email
> obfuscation is giving you a false sense of security.  Ignoring other
> ways spammers get your address, you're posting to a public space, and
> your address can be harvested (and, as shown above, not just from these
> public-inbox archives).
>
> And this isn't something specific to Org mode's archives.  Just as some
> examples, take a look at ,
> ,
> , or
> .
>
> Anyway, that being said and despite my opinion on this, I'm considering
> turning on obfuscation at  and
> .  There's at least one issue that'd need to
> be fixed before doing so though:
> .

I totally agree. I have no issue if 'hiding' email addresses can be done
and has no other unfortunate side effects, but I don't believe it
actually achieves much, so don't care if the default is not changed.

I think you have to accept that the email address you use in public mail
lists is going to be harvested and as others have mentioned, a lot of
email harvesting occurs when someone who has your address in their
address book has their system compromised.

The only sane action is good spam filtering. While I know a lot of
people complain about the Google gmail spam filtering, for me it is
remarkably accurate. It is unusual for me to see even a couple of spam
messages in my inbox every few months. My spam/junk box usually gets
around 10-15 messages a day and occasional messages flagged as spam
which are not (usually because the sender's mail server isn't doing SPF
or any of the other spam prevention headers correctly). Takes me about 1
minute to scan and 'delete forever' each day, so no big problem.  
-- 
Tim Cross

Re: Does wip-cite work with master or 9.4.5 release?

[Ramesh Nedunchezian]

On 08/04/21 8:37 pm, Nicolas Goaziou wrote:
> Hello,
> 
> Ramesh Nedunchezian  writes:
> 
>> Does wip-cite doesn't work with master or 9.4.5?  Am I doing something
>> wrong?
> 
> Although most of it is still relevant, wip-cite branch is to be
> considered as slightly outdated at the moment.
> 
> I have a local wip-cite-new that I did not take time to polish and push
> yet.
>

wip-cite-new merges cleanly with both the master and release_9.4.5
branch.  It also compiles fine.

git reset --hard  release_9.4.5
git merge origin/wip-cite-new

I am hoping that it is usable ... 

Texinfo exporter fails to export M-x helm-documentation

[Ramesh Nedunchezian]

I was trying to learn [Helm](https://github.com/emacs-helm/helm), is
an Emacs framework for incremental completions and narrowing
selections

The official documentation is generated by M-x helm-documentation, and
it is org format.  I wanted to read the documentation as an info file.
So, when I exporter to texinfo format, I found some issues.

I am attaching a stripped version of the documentation that is posing
problems.  The problem is with level 5 headers.  One such thing is at
https://github.com/emacs-helm/helm/blob/45450d57d5ff97e1a6fbd2a9816ae912ac50edcb/helm-help.el#L651.
I am exporting the file with option set to H:5.

See attachment for the problematic org file, texi output and the error
generated by texinfo exporter.

There are bunch of other issues that the helm documentation poses.  I
will take these up as soon as this bug is addressed.








helmdocumentation.org.texi:83: @menu reference to nonexistent node `Recursively 
rename all files with "JPG" extension to "jpg"'
helmdocumentation.org.texi:84: @menu reference to nonexistent node 
`Batch-rename files from number 001 to 00x'
helmdocumentation.org.texi:43: @detailmenu reference to nonexistent node 
`Recursively rename all files with "JPG" extension to "jpg"'
helmdocumentation.org.texi:44: @detailmenu reference to nonexistent node 
`Batch-rename files from number 001 to 00x'
\input texinfo@c -*- texinfo -*-
@c %**start of header
@setfilename helmdocumentation.org.info
@settitle helmdocumentation.org
@documentencoding UTF-8
@documentlanguage en
@c %**end of header

@finalout
@titlepage
@title helmdocumentation.org
@author Ramesh Nedunchezian
@end titlepage

@contents

@ifnottex
@node Top
@top helmdocumentation.org
@end ifnottex

@menu
* Helm Find Files::

@detailmenu
--- The Detailed Node Listing ---

Helm Find Files

* Tips::

Tips

* Use the wildcard to select multiple files::
* Query replace regexp on filenames::

Query replace regexp on filenames

* Examples::

Examples

* Recursively rename all files with ".JPG" extension to ".jpg": Recursively rename all files with "JPG" extension to "jpg". 
* Batch-rename files from number 001 to 00x::


@end detailmenu
@end menu

@node Helm Find Files
@chapter Helm Find Files

@menu
* Tips::
@end menu

@node Tips
@section Tips

@menu
* Use the wildcard to select multiple files::
* Query replace regexp on filenames::
@end menu

@node Use the wildcard to select multiple files
@subsection Use the wildcard to select multiple files

Use of wildcard is supported to run an action over a set of files.

@node Query replace regexp on filenames
@subsection Query replace regexp on filenames

Replace different parts of a file basename with something else.

@menu
* Examples::
@end menu

@node Examples
@subsubsection Examples

@menu
* Recursively rename all files with ".JPG" extension to ".jpg": Recursively rename all files with "JPG" extension to "jpg". 
* Batch-rename files from number 001 to 00x::
@end menu

@enumerate
@item
Recursively rename all files with ".JPG" extension to ".jpg"


Use the ‘helm-file-globstar’ feature described in recursive globbing
by entering "**.JPG" at the end of the Helm-find-files pattern, then hit
M-@@ and enter "JPG" on first prompt, then "jpg" on second prompt and hit ‘RET’.

@item
Batch-rename files from number 001 to 00x


Use "\#" inside the second prompt.
@end enumerate

@bye

helmdocumentation.org.org
Description: Lotus Organizer

Re: On the protection of emails in the archives

[Jean Louis]

* Guillaume MULLER  [2021-04-08 11:30]:
> Hi all,
> 
> I recently sent an email on this mailing list (see 
> https://orgmode.org/list/b1e778c5-acbf-8a17-c9bf-dcb6693e9...@univ-st-etienne.fr/
>  )
> 
> Since then, I'm receiving spams on the email address I used to send the 
> message.
> 
> After some research, it seems that this email address only appears on 2 
> websites, notably this orgmode.org mailing list archive.
> 
> Would it be possible to configure the archive to obfuscate / hide
> the email addresses inorder to protect its users?

While your assumption is that you are getting spam because your email
is published on those websites, this does not say it is true cause of
you getting spam.

It is enough that you give your email address to anybody, like a
friend or associate, and you can start getting spam.

Mailing list archives do not obfuscate email addresses, and in
automated data harvesting that is easily solved.

Please note, it is more important for people to communicate and be
able to reach each other than taking care of individual spam
problems.

My side spam is mostly being solved automatically, server side, by
using Spamhouse. You may advise to your email service provider to use
that feature or some other feature.

Spam problem is not a remote problem, not something on outside parties
to solve, it is to be solved on your side. You may train your email
client to recognize spam. Email is not and never was perfect.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://rms-support-letter.github.io/

Re: On the protection of emails in the archives

[Jean Louis]

* Tim Cross  [2021-04-09 10:06]:
> The only sane action is good spam filtering. While I know a lot of
> people complain about the Google gmail spam filtering, for me it is
> remarkably accurate.

Maybe, but then you may also receive email mostly form public
providers. My experience from stories of recipients tells me Google is
not accurate, many genuine emails are missed.

Nobody should use Google for emails. Why trust some 100,000 staff
members with personal information?


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://rms-support-letter.github.io/

Re: Bug: org-columns--compute-spec tries to set CLOCKSUM property [9.4.4 (release_9.4.4-231-gf46925 @ /home/nick/elisp/org-mode/lisp/)]

[Nick Dokos]

Nicolas Goaziou  writes:

>>   | ITEM  | CLOCKSUM |
>>   |---+--|
>>   | Goal 3| 2:11 |
>>   |---+--|
>>   | Task 1| 2:11 |
>>   |---+--|
>>   | Subtask 1 | 1:00 |
>>   #+END
>> --8<---cut here---end--->8---
>
> Why do you say the entries are wrong?
>

Temporary (I hope...) brain damage.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: Texinfo exporter fails to export M-x helm-documentation

[Nicolas Goaziou]

Hello,

Ramesh Nedunchezian  writes:

> I was trying to learn [Helm](https://github.com/emacs-helm/helm), is
> an Emacs framework for incremental completions and narrowing
> selections
>
> The official documentation is generated by M-x helm-documentation, and
> it is org format.  I wanted to read the documentation as an info file.
> So, when I exporter to texinfo format, I found some issues.
>
> I am attaching a stripped version of the documentation that is posing
> problems.  The problem is with level 5 headers.  One such thing is at
> https://github.com/emacs-helm/helm/blob/45450d57d5ff97e1a6fbd2a9816ae912ac50edcb/helm-help.el#L651.
> I am exporting the file with option set to H:5.

The problem is that you are explicitly requesting a level of headlines
without providing a sectioning command for them. By default
`org-texinfo-classes' stops at level 4.

Anyway, this should be fixed. Thank you.

Regards,
-- 
Nicolas Goaziou

Re: Bug: inconsistent escaping of coderef regexp

[Nicolas Goaziou]

Hello,

Tom Gillespie  writes:

> I've included the simplest patch I could come up with for the
> divergence in behavior between org-babel-tangle-single-file and
> org-link-search.

Thank you. I applied it.

> https://code.orgmode.org/bzg/org-mode/src/2d78ea57cfad1ddc3e993c949daf117b76315170/lisp/org-src.el#L882
>
> That line defines a hardcoded regular expression for matching
> coderefs.

It is a reasonable one, however, since it just means "the coderef is the
last thing on the line".

> The codref prefix is the first =[ \t]*= and the coderef
> regexp is the equivalent to the fully formatted version of that format
> string. Neither of those can currently be specified by the user. 

[...]

> The coderef prefix is something that should probably be configurable
> by the user so that empty comments are not left in the file.

I'm not convinced this should be configurable, as I fail to see
a use-case for such a customization. Note that in the case you mention,
comment syntax should probably be part of the coderef label itself.

Regards,
-- 
Nicolas Goaziou

Re: [Patch] to correctly sort the items with emphasis marks in a list

[Nicolas Goaziou]

Hello,

Juan Manuel Macías  writes:

> I have noticed that a couple of (spurious?) spaces in a `format'
> expression of `org-sort-remove-invisible' is causing `org-sort-list' not
> to sort correctly (alphabetically) the items that contain emphasis marks
> in a plain list. I propose this very simple patch to fix that problem.

Thank you.

Could you apply the same fix to the `org-verbatim-re' match above, and
provide an appropriate commit message?

Regards,
-- 
Nicolas Goaziou

Re: On the protection of emails in the archives

[Tim Cross]

Jean Louis  writes:

> Nobody should use Google for emails. Why trust some 100,000 staff
> members with personal information?

Please do not tell me what I should or shold not do. I am an adult 
and am perfectly capable of making up my own mind thank you. 
-- 
Tim Cross

Re: [Patch] to correctly sort the items with emphasis marks in a list

[Juan Manuel Macías]

Hellow Nicolas:

Nicolas Goaziou writes:

> Thank you.
>
> Could you apply the same fix to the `org-verbatim-re' match above, and
> provide an appropriate commit message?

Done! I've attached the corrected patch. Sorry for the flaws in me
previous patch: I'm a bit of a novice at submitting patches...

Best regards,

Juan Manuel

>From ab104bb079e3e32d622a6ff53824b5047dc25c14 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias 
Date: Fri, 2 Apr 2021 21:20:17 +0200
Subject: [PATCH] Remove spurious spaces in org-sort-remove-invisible

Some spurious spaces in org-sort-remove-invisible is causing
org-sort-list not to sort correctly (alphabetically) the items that
contain emphasis marks in a plain list
---
 lisp/org.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 675a614e2..74e2afac9 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -8113,9 +8113,9 @@ Optional argument WITH-CASE means sort case-sensitively."
   "Remove invisible part of links and emphasis markers from string S."
   (remove-text-properties 0 (length s) org-rm-props s)
   (replace-regexp-in-string
-   org-verbatim-re (lambda (m) (format "%s " (match-string 4 m)))
+   org-verbatim-re (lambda (m) (format "%s" (match-string 4 m)))
(replace-regexp-in-string
-org-emph-re (lambda (m) (format " %s " (match-string 4 m)))
+org-emph-re (lambda (m) (format "%s" (match-string 4 m)))
 (org-link-display-format s)
 t t) t t))
 
-- 
2.26.0

Re: On the protection of emails in the archives

[Jean Louis]

Sorry Tim. While that is my opinion, it is not meant to be taken
personally, I am corresponding with many people with Google account,
that is really nothing personal.

My opinion is for safety of users and awareness, though. Would you
stubmle upon similar opinions on websites, it would not be taken that
way. I did not mean to.

Examples of privacy nightmare:
https://medium.com/digitalprivacywise/why-you-should-stop-using-google-chrome-6c934c9a827c

Example of surveillannce:
https://en.wikipedia.org/wiki/PRISM_(surveillance_program)


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://rms-support-letter.github.io/

Bug: TexInfo: Links to listified headlines don't work [9.4.5 (release_9.4.5-279-g80bce0 @ /home/rameshnedunchezian/src/org-mode/lisp/)]

[Ramesh Nedunchezian]

See attachments.

In the attached files, there are links pointing to itemized headlines
... and the problem is the items have no anchors associated with it.

See

(info "(texinfo) @anchor")
helmdocumentation.org.texi:3: warning: @setfilename missing argument
helmdocumentation.org.texi:9: warning: @dircategory missing argument
helmdocumentation.org.texi:16: warning: @title missing argument
helmdocumentation.org.texi:90: @ref reference to nonexistent node `Grepping on 
remote files'
\input texinfo@c -*- texinfo -*-
@c %**start of header
@setfilename 
@settitle helmdocumentation.org 
@documentencoding UTF-8
@documentlanguage en
@c %**end of header

@dircategory 
@direntry
* . .
@end direntry

@finalout
@titlepage
@title 
@author Ramesh Nedunchezian Ramesh Nedunchezian
@end titlepage

@contents

@ifnottex
@node Top
@top helmdocumentation.org 
@end ifnottex

@menu
* Helm Find Files::

@detailmenu
--- The Detailed Node Listing ---

Helm Find Files

* Tips::

Tips

* Grep files from ‘helm-find-files’::
* Using TRAMP with ‘helm-find-files’ to read remote directories::

@end detailmenu
@end menu

@node Helm Find Files
@chapter Helm Find Files

@menu
* Tips::
@end menu

@node Tips
@section Tips

@menu
* Grep files from ‘helm-find-files’::
* Using TRAMP with ‘helm-find-files’ to read remote directories::
@end menu

@node Grep files from ‘helm-find-files’
@subsection Grep files from ‘helm-find-files’

You can grep individual files from ‘helm-find-files’ by using
‘C-s’.  This same command can also
recursively grep files from the current directory when called with a prefix
argument.  In this case you will be prompted for the file extensions to use
(grep backend) or the types of files to use (ack-grep backend).  See the
‘helm-grep-default-command’ documentation to set this up.  For compressed files
or archives, use zgrep with ‘M-g z’.

@enumerate
@item
Grepping on remote files


On remote files grep is not well supported by TRAMP unless you suspend updates before
entering the pattern and re-enable it once your pattern is ready.
To toggle suspend-update, use ‘C-!’.
@end enumerate

@node Using TRAMP with ‘helm-find-files’ to read remote directories
@subsection Using TRAMP with ‘helm-find-files’ to read remote directories

‘helm-find-files’ works fine with TRAMP despite some limitations.

@itemize
@item
Grepping files is not very well supported when used incrementally.
@end itemize
See @ref{Grepping on remote files}.

@itemize
@item
Locate does not work on remote directories.
@end itemize

@bye

helmdocumentation.org.org
Description: Lotus Organizer

Re: On the protection of emails in the archives

[Tim Cross]

Jean Louis  writes:

> Sorry Tim. While that is my opinion, it is not meant to be taken
> personally, I am corresponding with many people with Google account,
> that is really nothing personal.
>

Your statement was personal and if that was not your intent, then think
before you post and ensure what you write is what you mean. 

> My opinion is for safety of users and awareness, though. Would you
> stubmle upon similar opinions on websites, it would not be taken that
> way. I did not mean to.
>

Completely irrelevant. I did not join the org list to be lectured by you
on privacy or your Google paranoia. I'm sure you can find a more
appropriate outlet for such opinions. 


> Examples of privacy nightmare:
> https://medium.com/digitalprivacywise/why-you-should-stop-using-google-chrome-6c934c9a827c
>
> Example of surveillannce:
> https://en.wikipedia.org/wiki/PRISM_(surveillance_program)

I'm not at all interested in your opinion on Google. This is an org mail
list. If it does not relate to org or the list, I don't think it belongs
here. 

-- 
Tim Cross