Re: bug#47885: [PATCH] org-table-import: Make it more smarter for interactive use

2021-06-03 Thread Utkarsh Singh
On 2021-06-02, 23:44 +0700, Maxim Nikulin  wrote:

> On 02/06/2021 22:08, Utkarsh Singh wrote:
>> ;;;###autoload
>>   (defun org-table-import (file separator)
>> @@ -955,12 +971,13 @@ lines.  It can have the following values:
>>   - integer When a number, use that many spaces, or a TAB, as field 
>> separator.
>>   - regexp  When a regular expression, use it to match the separator."
>> (interactive (list (read-file-name "Import file: ")
>> - (prefix-numeric-value current-prefix-arg)))
>> + current-prefix-arg))
>
> It seems, prefix argument works now. Let me remind that file name 
> completion was working better before your change.
>
> I have noticed a couple of error messages. Unsure what is going wrong, I 
> hope, command to launch emacs is correct (-Q -L ~/src/org-mode/lisp 
> test.org).
>
> At startup:
> Eager macro-expansion failure: (error "rx ‘not’ syntax error: (or 10 44)")
>
> In response to M-x org-table-import:
> rx-check-not: rx ‘not’ syntax error: (or 10 44)
>

Is `rx' library loading correctly? If no then you can try:

diff --git a/lisp/org-table.el b/lisp/org-table.el
index 20144c91b..9278f91bb 100644
--- a/lisp/org-table.el
+++ b/lisp/org-table.el
@@ -38,6 +38,7 @@
 (require 'org-macs)
 (require 'org-compat)
 (require 'org-keys)
+(require 'rx)

Can you also share test.org so that I can test locally?

>> Currently I am trying to refactor CSV parsing by applying techniques
>> used in pcsv library (MELPA package) which I think you will also enjoy
>> to play with!
>
> I do not know opinion of Org maintainers. Personally I believe that org 
> can take advantage of Emacs core features or of other packages if they 
> are available and fallback to minimal implementation otherwise. Unsure 
> whether borrowing code from pcsv can cause license issues. Current CSV 
> parser is not perfect but it works reasonably well.

Yes, I think you are right about how Org should make use of existing
feature rather than including everyting with itself but for now I am
considering this as an opportunity to learn how Org and Emacs work and
will leave it upto the maintainers if they find anything useful to be
including into Org itself.

Now on the topic of CSV parser, I have succesfully implemented a CSV
parser in less than 65 LOC which also preserves newline character but I
am facing a dilemma on how should I represent it as a Org table.  For
ex:

Row with newline as CSV data:

6,"Cell with new
Line",6.28

Row with newline as Lisp data:

("6" "Cell with new\nLine" "6.28")

Row with newline a Org table:

| 6 | Cell with new  |   6.28 |
|   | Line   ||

Rows in Org mode are separated using a newline-character which makes
"Cell with new" and "Line" as different cells which is different from
how Libreoffice Calc represents it.  Libreoffice Calc has a much
powerfull representation of a cell which is out of scope for any plain
text tables.  Possible solutions for this problem are:

1. Replace newline with a space character.  What will happen when
imported line as a really long line?

2. Represent every newline as distinct cell.  I was trying to implement
this method but the algorithm that I came up with requires time
complexity of O(n^2) to just print each row which is too much for large
CSV files.

(defun org-table--print-row (row)
  (let ((maxlines 1)
list1 list2 tmp)
;; get maxlines
(dolist (i row)
  (if (not (stringp i))
  (push (list i) list1)
(push (string-lines i) list1)
(setq tmp (length (car list1)))
(when (< maxlines tmp)
  (setq maxlines tmp
;; normalize row
(dolist (i list1)
  (setq tmp (length i))
  (when (< tmp maxlines)
(setq i (append i (make-list (- maxlines tmp) ""
  (push i list2))
;; print row
(dolist (i list2)
  (setq tmp (point))
  (dolist (j i) <-- Printing is still not complete

Thank you,
Utkarsh Singh

-- 
Utkarsh Singh
http://utkarshsingh.xyz



Re: Org Trademark [was: A formal grammar for Org]

2021-06-03 Thread Tim Cross


Jean Louis  writes:

> * Jakob Schöttl  [2021-06-02 11:23]:
>> I haven't tried BeOrg myself, but it's proprietary and we have an open
>> source, platform-independent alternative with Organice. See also
>> https://github.com/200ok-ch/organice#beorg
>
> As "Org" started first, it would be better that author ask the company
> to stop using the trademark. Trademark need not be registered, but
> when registered even better.
>
> By asking the author to either stop using "Org" as it is trademark in
> commerce (software is commerce) maybe they could get incentive to make
> it free software too.
>
>

This has nothing to do with defining a formal grammar for org mode.
Please refrain from hijacking threads in this manner. If something in a
thread makes you think of another issue (such as trademarks) or some
other tangential point, please start a new thread with an appropriate
subject. In addition to being correct netiquette and respectful to the
existing conversation, it will also ensure the point you raise has an
appropriate subject title, making it easier for those who are interested
in your point to see it and ensuring the indexing and searching of the
archives can be done more efficiently/accurately.

IMO there is no trademark issue here. Neither Emacs or org-mode have any
trademark ownership over the term 'Org' or any word which has 'org' in
it, like beorg.

-- 
Tim Cross



[PATCH] Add faces to improve contextuality of agenda views

2021-06-03 Thread Protesilaos Stavrou
Hello everyone!

The attached patch defines and implements a few new faces for the
agenda.  Quoting from the commit message:

These new faces are designed to improve the ability of themes/users to
control the presentation of agenda views.  They inherit from existing
faces in order to remain backward-compatible.

+ The 'org-imminent-deadline' is useful to disambiguate generic
  warnings from deadlines.  For example, a warning could be rendered
  in a yellow colored text and have a bold weight, whereas a deadline
  might be red and styled with italics.

+ The 'org-agenda-structure-filter' applies to all tag/term filters
  in agenda views that search for keywords or patterns.  It is
  designed to inherit from 'org-agenda-structure' in addition to the
  'org-warning' face that was present before (and removes the
  generic 'warning' face from one place).  This offers the benefit
  of consistency, as, say, an increase in font height or a change in
  font family in 'org-agenda-structure' will propagate to the filter
  as well.  The whole header line thus looks part of a singular
  design.

+ The 'org-agenda-structure-secondary' complements the above for those
  same views where a description follows the header.  For instance, the
  tags view provides information to "Press N r" to filter by a
  numbered tag.  Themes/users may prefer to disambiguate this line
  from the header above it, such as by using a less intense color or by
  reducing its height relative to the 'org-agenda-structure'.

+ The 'org-agenda-date-weekend-today' provides the option to
  differentiate the current date on a weekend from the current date on
  weekdays.

Some more words about the motivation behind this patch, which are not
included in the commit message:

+ The 'org-warning' is a generic face that should always convey a clear
  warning sign.  It does that well.  Deadlines also got styled with this
  by default, which meant that they could not be toned down a bit, or
  otherwise tweaked to meet the requirements of the agenda, without
  compromising the intended purpose of a prominent warning.  Ultimately
  this is about choice: users/themes may not want to use intense styles
  for deadlines by default.

  - For some prior work on applying a bespoke face instead of
'org-warning', refer to commit 7ebb2d562 in org.git.

+ The 'org-agenda-date-weekend-today' complements the existing faces for
  differentiating weekdays from weekends.  So the "current day" can now
  be adapted to this distinction, depending on the user's particular
  needs.

What do you think?  Is there something you would like to see done
differently?

I include Gustavo Barros in Cc, with whom we identified the potential
for these changes and who helped me think about their design and test
their implementation.  This is done for communication purposes: any
errors are exclusively my own.

I have already assigned copyright to the FSF and have made such
contributions before.

All the best,
Protesilaos or "Prot"

-- 
Protesilaos Stavrou
https://protesilaos.com
>From b47af2b79c5ecfe0954dfd0bbe1bedd531b81417 Mon Sep 17 00:00:00 2001
Message-Id: 
From: Protesilaos Stavrou 
Date: Wed, 2 Jun 2021 12:51:07 +0300
Subject: [PATCH] Add faces to improve contextuality of agenda views

* lisp/org-agenda.el (org-search-view)
(org-agenda-propertize-selected-todo-keywords, org-todo-list)
(org-tags-view): Implement new org-agenda-structure-filter and
org-agenda-structure-secondary faces.
(org-agenda-get-day-face): Add condition for rendering the current
date heading in org-agenda-date-weekend-today.

* lisp/org-faces.el (org-agenda-structure-secondary)
(org-agenda-date-weekend-today, org-agenda-structure-filter)
(org-imminent-deadline): Add new faces.
(org-agenda-deadline-faces): Use the 'org-imminent-deadline' for
current deadlines instead of the generic 'org-warning'.

-

These new faces are designed to improve the ability of themes/users to
control the presentation of agenda views.  They inherit from existing
faces in order to remain backward-compatible.

+ The 'org-imminent-deadline' is useful to disambiguate generic
  warnings from deadlines.  For example, a warning could be rendered
  in a yellow colored text and have a bold weight, whereas a deadline
  might be red and styled with italics.

+ The 'org-agenda-structure-filter' applies to all tag/term filters in
  agenda views that search for keywords or patterns.  It is designed to
  inherit from 'org-agenda-structure' in addition to the 'org-warning'
  face that was present before (and removes the generic 'warning' face
  from one place).  This offers the benefit of consistency, as, say, an
  increase in font height or a change in font family in
  'org-agenda-structure' will propagate to the filter as well.  The
  whole header line thus looks part of a singular design.

+ The 'org-agenda-structure-secondary' complements the above 

Bug: Duplicated TODO state change logging with `!' per-keyword markers and repeater [9.4.6]

2021-06-03 Thread Leon Vack


Hello,

Starting with version 9.4.6, state logging through a per-keyword marker
`!' produces duplicate log entries on tasks with a repeater.

A minimal test configuration to reproduce the issue is:

(setq org-todo-keywords '((sequence "TODO" "DONE(!)")))

Then, creating a task with a repeater:

* TODO Test Task
SCHEDULED: <2021-06-04 Fri .+1d>

And marking it done yields:

* TODO Test Task
SCHEDULED: <2021-06-04 Fri .+1d>
:PROPERTIES:
:LAST_REPEAT: [2021-06-03 Thu 19:58]
:END:
- State "DONE"   from "TODO"   [2021-06-03 Thu 19:58]
- State "DONE"   from "TODO"   [2021-06-03 Thu 19:58]

Instead of:

* TODO Test Task
SCHEDULED: <2021-06-04 Fri .+1d>
:PROPERTIES:
:LAST_REPEAT: [2021-06-03 Thu 19:58]
:END:
- State "DONE"   from "TODO"   [2021-06-03 Thu 19:58]

I have done some debugging and testing. The first commit in which I was
able to reproduce the bug is c670379adfbdc4883d3cfa230289fd2829993265.
This commit changed the behavior of `org-add-log-setup' to call
`org-add-log-note' directly (instead of just adding it to the
`post-command-hook') when logging only a timestamp and no note. The
problem is, that with a repeater when enabling logging through a `!'
marker, `org-add-log-setup' is called twice: Once by `org-todo' directly
and once by `org-auto-repeat-maybe' resulting in the two state log
entries.

Emacs: GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.27, 
cairo version 1.16.0)

Leon Vack



Re: [org-cite, oc-basic] Citation disambiguation

2021-06-03 Thread Bruce D'Arcus
On Thu, Jun 3, 2021 at 5:13 PM András Simonyi  wrote:

> I think some kind of disambiguation strategy should be implemented for
> the basic citation backend to be really usable with the author-year
> style. WDYT?

I hadn't tested that, but I agree.

As you know, disambiguation can get complicated, but that approach is
easy low-hanging fruit.

Bruce



[org-cite, oc-basic] Citation disambiguation

2021-06-03 Thread András Simonyi
Dear All,

experimenting with the 'basic' citation backend I noticed that the
default author-year citation style (and its derived variants, like
text and year) does not perform citation disambiguation for items that
have the same author and year. E.g. the Org document
--8<---cut here---start->8---
#+cite_export: basic author-year author-year
First: [cite:@disamb1examp]

Second: [cite:@disamb2examp]
--8<---cut here---end--->8---
is exported as
--8<---cut here---start->8---
First: (Doe, John, 1973)

Second: (Doe, John, 1973)

Doe, John (1973). /Minor Work/, Journal of Philosophy.

Doe, John (1973). /Magnum Opus/, Journal of Philosophy.
--8<---cut here---end--->8---
which makes it impossible to identify the cited item. Perhaps the most
widespread solution to this problem is to add so called year-suffixes
to the year to disambiguate:
--8<---cut here---start->8---
First: (Doe, John, 1973a)

Second: (Doe, John, 1973b)

Doe, John (1973a). /Minor Work/, Journal of Philosophy.

Doe, John (1973b). /Magnum Opus/, Journal of Philosophy.
--8<---cut here---end--->8---
I think some kind of disambiguation strategy should be implemented for
the basic citation backend to be really usable with the author-year
style. WDYT?

best regards,
András



[bug?] org-link-set-parameters: when `:display 'full', link face is applied only in description part

2021-06-03 Thread Juan Manuel Macías
Hi all,

In master:

if I do:

(org-link-set-parameters "foo"
 :display 'full
 :face '(:foreground "chocolate" :weight bold 
:underline t))

and then:

[[foo:target][description]]

the face parameter is only applied in the description part.

Expected result: shouldn't the face be applied to the entire link?

Best regards,

Juan Manuel 



Re: A formal grammar for Org

2021-06-03 Thread Jean Louis
* Jakob Schöttl  [2021-06-02 11:23]:
> I haven't tried BeOrg myself, but it's proprietary and we have an open
> source, platform-independent alternative with Organice. See also
> https://github.com/200ok-ch/organice#beorg

As "Org" started first, it would be better that author ask the company
to stop using the trademark. Trademark need not be registered, but
when registered even better.

By asking the author to either stop using "Org" as it is trademark in
commerce (software is commerce) maybe they could get incentive to make
it free software too.


Jean

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

Sign an open letter in support of Richard M. Stallman
https://stallmansupport.org/



Re: LaTeX fragment preview weirdness

2021-06-03 Thread Scott Randby

On 6/2/21 1:28 PM, Nick Dokos wrote:

You probably want #+LATEX_HEADER_EXTRA, not #+LATEX_HEADER. Do

    (info "(org) Latex header and sectioning")

where it says:

#+BEGIN_QUOTE
    The LaTeX export back-end appends values from ‘LATEX_HEADER’ and
‘LATEX_HEADER_EXTRA’ keywords to the LaTeX header.  The docstring for
‘org-latex-classes’ explains in more detail.  Also note that LaTeX
export back-end does not append ‘LATEX_HEADER_EXTRA’ to the header when
previewing LaTeX snippets (see *note Previewing LaTeX fragments::).
#+END_QUOTE


On 6/2/21 2:19 PM, Scott Randby wrote:

That worked after I deleted the old images in the ltximg directory. I hardly 
ever preview LaTeX fragments, but I'm changing #+latex_header: to 
#+latex_header_extra: everywhere.



I had to do a little extra work to get subtree export to work properly. Subtree 
export appears to also not append ‘LATEX_HEADER_EXTRA’ to the header. I had to 
add the values I need to the properties of the subtree using 
'EXPORT_LATEX_HEADER_EXTRA'. This actually cleaned up a lot of the code, but it 
was work I'd been putting off.

Scott



Re: Formatting content in a footnote for ox-tufte

2021-06-03 Thread Galaxy Being
I just discovered that the ox-tufte handling of footnote formatting is
different from normal org mode formatting. Normal footnotes take source
blocks while ox-tufte ignores them and all other blocks as well.

On Wed, Jun 2, 2021 at 11:22 AM Galaxy Being  wrote:

> I'm using the org tufte  ox-tufte
> and started tweaking the underlying tufte.css
> to my needs. It's really meant
> for org html export, not like the more elaborate org-to-latex Tufte
> formatting from org mode luminary Thomas Dye. As such, it gives you the
> Tufte look-and-feel with fonts and the famed sidenote/margin note feature
> -- all for just making a footnote (that appears beside its link in the text
> rather than the usual at the bottom of the page). The margin note
> capability is gnarlier in that it is just a link in the main text that then
> appears to the right of the main text
>
> [[mn:1][Here is some text that will appear as a side column block]][[mn:2][And
> putting one right after the first one makes it look like a new paragraph]]
>
> Obviously, this is a limiting factor on how elaborate and expressive these
> side columns can be, especially the margin note which has your content
> inside the link. However, the sidenote as a redirected footnote isn't too
> bad. Still, I'd like to be able to fully format what goes into a footnote
> without jumping through a lot of hoops. Here's an example of one footnote
> as sidenote that comes out looking okay despite the kludginess
>
> [fn:1] Star chart for \\
> \\
> file:./images//Celestial_map_Hyi.png \\
> \\
> Just text for a few lines of text that is just meant as filler, not
> anything important. Just here to show how text looks in a
> sidenote. Cool, I think this is enough.\\
> \\
> ~foldr :: (a → b → b) → b → [a] → b~ \\
> ~foldr f e [ ] = e~\\
> ~foldr f e (x : xs) = f x (foldr f e xs)~ \\
> \begin{align*}
> v = \frac{x}{t}
> \end{align*}
> [[
> https://learning.edx.org/course/course-v1:EPFLx+MatlabeOctaveBeginnersX+1T2017/home][MatLab
> 
> and Octave training]]
>
> For one, I couldn't get any sort of normal org block formatting (e.g.,
> #+BEGIN_example...) for the code snippet to be recognized. Is there any
> sort of "normal" content formatting for org footnotes? Obviously, the worst
> is the margin note [[mn:... situation. That simply needs to be redone.
> But a margin note differs from a sidenote only because the margin note is
> not numbered. I tried the org-footnote-auto-label set to confirm, but it
> always reverts back to plain numbering.
>
> Any ideas for improvement appreciated. This would be a really good-looking
> org html export option if it was bit more user-friendly.
>
> ⨽
> Lawrence Bottorff
> Grand Marais, MN, USA
> borg...@gmail.com
>


-- 
⨽
Lawrence Bottorff
Grand Marais, MN, USA
borg...@gmail.com


Remove all Org metadata with header argument `:comments org'

2021-06-03 Thread Juan Manuel Macías
I am writing an *.el file from an *.org file (and then I run
org-babel-tangle). With the header argument `:comments org' not only the
text in my org file is converted to comments (my desired goal) but also
the drawers, keywords and other Org metadata. Since I don't see that all
that stuff is necessary in a source file, wouldn't it be better to get
rid of it during the tangle process, leaving only pure content as
comment strings? Maybe converting the Org file content to plain text
with ox-ascii, or something like that?

What do you think?

Best regards,

Juan Manuel 





Re: [PATCH] org-table.el: Fix usage of user-error

2021-06-03 Thread Bastien
Hi Utkarsh,

Utkarsh Singh  writes:

> Ping!

Please read 
https://orgmode.org/worg/org-mailing-list.html#i-didnt-receive-an-answer

>From what I understand, the change is not really a bugfix.

I hope someone can review and approve it.  If not, I will look at it
when I have some time

Thanks,

-- 
 Bastien



[oc-csl] citations in footnotes

2021-06-03 Thread Bruce D'Arcus
In the approach taken by CSL implementations, and by biblatex
autocite, when dealing with note styles, you have two kinds of
citations in notes:

1. what we might call "automatically footnoted"; citations in the
running text that get converted on export to footnotes (or endnotes)
2. citations within footnotes, that get output as is, without any
footnote wrapping.

With this input:

---
Body text with a citation: [cite:@mcneill2011].

Footnote: [fn:1]

#+print_bibliography:

* Footnotes

[fn:1] A commentary, and then a citation: [cite:@low2001].
-

... the citation within the footnote now generates an additional footnote.


[3] A commentary, and then a citation:[4].

[4] Low, “The Edge and the Center: Gated Communities and the Discourse
of Urban Fear.”
-

It should not; output should be:


[3] A commentary, and then a citation: Low, “The Edge and the Center:
Gated Communities and the Discourse of Urban Fear.”
-

Bruce



Re: import xls(x) into org on MacOS

2021-06-03 Thread Uwe Brauer
>>> "NS" == Nick Savage  writes:

> If you're looking to go the python route of importing an xls file, you
> could try the xlrd package. It's actually just for xls. I'm not sure
> if it converts to csv, but once you have the spreadsheet open in
> python that should be a pretty trivial exercise.

Thanks, but what I was looking for was a command line package, like the
one I mentioned, xlrd, seems to involve some more fiddling.
I try, for the moment to surve with xlsx files.

Uwe 


smime.p7s
Description: S/MIME cryptographic signature