Re: Regression in table.el detection? [maint]

2021-01-05 Thread Kaushal Modi
On Tue, Jan 5, 2021 at 12:09 PM Nicolas Goaziou 
wrote:

> Oops. Fixed. Thank you.
>

Thank you! for fixing this so quick :)

I confirm that fix you made in
https://code.orgmode.org/bzg/org-mode/commit/332da69b3c3ca222943728c20287e4ace6d40e61
.

Can you also please add a test for that? [My ox-hugo test suite will
anyways keep on serving via its weekly crons :) ]


Re: Regression in table.el detection? [maint]

2021-01-04 Thread Kaushal Modi
Hi Kyle,

I was able to reproduce with issue with ox-html as well.

Please copy paste this in a new temp.org file and run `C-c C-e h H':

* Subtree 1
+--+--+--+
| Header 1 | Header 2 | Header 3 |
+--+--+--+
| a| b| c|
+--+--+--+
| d| e| f|
+--+--+--+
* Subtree 2


The issue is when the "* Subtree 2" begins in the very next line after that
last line of table.el table ending in "--+".

When I export that, I see that ox-html fails to detect that table.el table
because I see this in the exported buffer:

=












Header 1
Header 2
Header 3




--


=

But if I introduce a newline before "* Subtree 2", the table.el table
detection works fine.



--
Kaushal Modi


Re: Regression in table.el detection? [maint]

2021-01-04 Thread Kaushal Modi
On Tue, Jan 5, 2021 at 1:36 AM Kaushal Modi  wrote:

>
> I'll keep looking..
>

OK, when I added the same debug messages to ox-html.el, I see:

=
(table (:begin 1860 :end 2104 :type table\.el :tblfm nil :contents-begin
nil :contents-end nil :value "+--+--+--+
| Header 1 | Header 2 | Header 3 |
+--+--+--+
| a| b| c|
+--+--+--+
| d| e| f|
+--+--+--+" :post-blank 1 :post-affiliated 1860
:parent (section (:begin 1703 :end 2104 :contents-begin 1703 :contents-end
2104 :post-blank 1 :post-affiliated 1703 :parent (org-data nil #2))
(special-block (:type "description" :begin 1703 :end 1783 :contents-begin
1723 :contents-end 1765 :post-blank 1 :post-affiliated 1703 :parent #2)
(paragraph (:begin 1723 :end 1765 :contents-begin 1723 :contents-end 1765
:post-blank 1 :post-affiliated 1723 :parent #3) #("Support tables written
in table.el format
" 0 42 (:parent #4 (paragraph (:begin 1783 :end 1860 :contents-begin
1783 :contents-end 1859 :post-blank 1 :post-affiliated 1783 :parent #2)
(verbatim (:value "ox-hugo" :begin 1783 :end 1793 :post-blank 1 :parent
#3)) #("Issue #" 0 7 (:parent #3)) (link (:type "https" :path "//
github.com/kaushalmodi/ox-hugo/issues/374" :format bracket :raw-link "
https://github.com/kaushalmodi/ox-hugo/issues/374; :application nil
:search-option nil :begin 1800 :end 1858 :contents-begin 1853 :contents-end
1856 :post-blank 0 :parent #3) #("374" 0 3 (:parent #4))) #("
" 0 1 (:parent #3))) #0)))
"
=

ox-hugo is stripping the leading/trailing spaces from the table cells,
while ox-html is not. Somehow that doesn't play with the recent change to
table.el detection.

I'll try fixing that in ox-hugo.


Re: Regression in table.el detection? [maint]

2021-01-04 Thread Kaushal Modi
On Tue, Jan 5, 2021 at 1:15 AM Kyle Meyer  wrote:

>
>
> Exporting that table to html, I see "Before" on release_9.4.4, maint
> (273391c97), and master (00b4de329).
>
> You're able to trigger the issue with a vanilla configuration on maint?
>

Hi Kyle,

Thanks for checking. Indeed ox-html export does not show that issue.

But the weekly cron (and even local) ox-hugo exports started showing this
issue after the update to table.el table detection change that happened a
few weeks ago.

I'll investigate why only ox-hugo is showing this issue.. I am simply
calling the table.el related function from ox-html:

=
(defun org-blackfriday-table (table contents info)
  "Transcode TABLE element into Blackfriday Markdown format.

CONTENTS is contents of the table.  INFO is a plist holding
contextual information."
  ;; (message "[ox-bf-table DBG] In contents: %s" contents)
  (if (eq (org-element-property :type table) 'table.el)
  ;; "table.el" table.  Convert it using appropriate tools.
  (let ((tbl (org-html-table--table.el-table table info)))
(message "%S" table) ; just added this for debug
(message "%S" tbl) ; just added this for debug
=

and I am getting only partial table in the "tbl" variable

=
(table (:begin 1860 :end 2062 :type table\.el :tblfm nil :contents-begin
nil :contents-end nil :value "+--+--+--+
| Header 1 | Header 2 | Header 3 |
+--+--+--+
| a | b | c |
+--+--+--+
| d | e | f |
+--+--+--+" :post-blank 1 :post-affiliated 1860
:parent (section (:begin 1703 :end 2062 :contents-begin 1703 :contents-end
2062 :post-blank 1 :post-affiliated 1703 :parent (org-data nil #2))
(special-block (:type "description" :begin 1703 :end 1783 :contents-begin
1723 :contents-end 1765 :post-blank 1 :post-affiliated 1703 :parent #2)
(paragraph (:begin 1723 :end 1765 :contents-begin 1723 :contents-end 1765
:post-blank 1 :post-affiliated 1723 :parent #3) #("Support tables written
in table.el format
" 0 42 (:parent #4 (paragraph (:begin 1783 :end 1860 :contents-begin
1783 :contents-end 1859 :post-blank 1 :post-affiliated 1783 :parent #2)
(verbatim (:value "ox-hugo" :begin 1783 :end 1793 :post-blank 1 :parent
#3)) #("Issue #" 0 7 (:parent #3)) (link (:type "https" :path "//
github.com/kaushalmodi/ox-hugo/issues/374" :format bracket :raw-link "
https://github.com/kaushalmodi/ox-hugo/issues/374; :application nil
:search-option nil :begin 1800 :end 1858 :contents-begin 1853 :contents-end
1856 :post-blank 0 :parent #3) #("374" 0 3 (:parent #4))) #("
" 0 1 (:parent #3))) #0)))
"

  

  Header1


  Header2


  Header3

  
"
=

I'll keep looking..


Regression in table.el detection? [maint]

2021-01-04 Thread Kaushal Modi
Hello,

There has been a recent regression in table.el detection.

Earlier, this used to be detected as a table.el table, but now it's not
(entirely):


+--+--+--+
| Header 1 | Header 2 | Header 3 |
+--+--+--+
| a| b| c|
+--+--+--+
| d| e| f|
+--+--+--+


Before:


  

  Header1


  Header2


  Header3

  
  

  a


  b


  c

  
  

  d


  e


  f

  



After:


  

  Header1


  Header2


  Header3

  


I stumbled across this regression as I was looking into why my weekly cron
for ox-hugo tests failed:
https://travis-ci.org/github/kaushalmodi/ox-hugo/jobs/752831865


--
Kaushal Modi


Re: pcase failure with Emacs 24 (was Emacs version for Org 9.4?)

2020-09-17 Thread Kaushal Modi
> On 2020-09-15, Kyle Meyer wrote:

> >
> >> It is pretty tricky to debug, but the failure starts with 4a27b67fd
> >> (org-element: Fix property drawers parsing, 2020-04-22).  As far as I
> >> can see, the pattern introduced there is perfectly valid and should be
> >> compatible with Emacs 24.  I'd _guess_ this is a pcase bug in Emacs 24,
> >> particularly the one fixed by 528872c5f8 (bug#18554, 2014-09-27), but I
> >> didn't make an effort to try to understand that commit.
> >>
> >> Interestingly, the error goes away if I just swap the elements in the
> >> pcase (and ...) pattern added by that commit.  Dunno, but if that clears
> >> up the failure on your end as well, I don't see any reason to not make
> >> that change.
> >>
> >>
> >> diff --git a/lisp/org-element.el b/lisp/org-element.el
> >> [...]
> >
> > Yes, that fixes the problem over here.
>
> Thanks for confirming.  Pushed (73c929e3b).
>
>
I just stumbled on this as I was looking into why ox-hugo tests failed on
emacs 24.x (
https://travis-ci.org/github/kaushalmodi/ox-hugo/builds/728059027 ). This
should pass next week now. Thanks for your fix.


Re: Debugging at least 2 regressions in org-mode master breaking ox-hugo

2020-09-07 Thread Kaushal Modi
On Sun, Sep 6, 2020, 5:37 PM Bastien  wrote:

> Hi Kaushal,
>
> sorry for the late reply, and thanks for the detailed report.
>
> Kaushal Modi  writes:
>
> > *The regression is that earlier (org-babel--string-to-number "1,3-5")
> > used to return nil, but now it returns 1.*
>
> This should be fixed now in master, as of 15a6836e4, it will be
> in Org 9.4.


Thank you very much! For now, I have just overridden that Org Babel
function in ox-hugo with a package-local fix. Once the maint is fixed, I'll
remove that workaround.


Re: ox-* vs org-* naming convention?

2020-06-10 Thread Kaushal Modi
Hello Diego,

That's great! Thanks for your PR.

On Wed, Jun 10, 2020 at 12:57 PM Diego Zamboni  wrote:

> Hi everyone,
>
> Just a quick update: issue
> https://github.com/purcell/package-lint/issues/89 submitted by Kaushal
> has been closed through the PR I submitted, so now package-lint
> officially accepts "org-" symbols in "ox-" and "ob-" packages :)
>
> --Diego
>


Re: ox-* vs org-* naming convention?

2020-06-07 Thread Kaushal Modi
Hello,

This came up when I submitted ox-hugo to Melpa as well[1].

I stayed with the norm.. naming the package ox-hugo, but naming all the
functions and variables with org-hugo-* prefix.

[1] https://github.com/purcell/package-lint/issues/89


Re: `#+author:' stopped setting the author to empty string

2020-05-20 Thread Kaushal Modi
On Tue, May 19, 2020 at 8:38 PM Kyle Meyer  wrote:

> Nicolas Goaziou writes:
>
> > At first glance, it looks harmless. If the test suite passes, we can
> > apply it.
>
> The test suite does pass with the change.  Pushed, along with a
> regression test (962b8e765).
>

Thank you for the debug and quick fix! I confirm the fix.


Re: `#+author:' stopped setting the author to empty string

2020-05-19 Thread Kaushal Modi
On Mon, May 18, 2020 at 7:30 PM Kyle Meyer  wrote:

>
> It bisects to b4e91b7e9 (New function: org-collect-keywords,
> 2020-04-26).  I haven't done much digging, but I was able to restore the
> behavior with the change below, which may be a bad idea for other
> reasons.
>

Thanks for that bisect!

If the current tests (and the new test with blank author "#+author:") pass,
then we should be good :)


`#+author:' stopped setting the author to empty string

2020-05-18 Thread Kaushal Modi
Hello,

At some point in the past month or so, I have noticed that on Org master,
#+author: does not set the author to empty in the exports.

Simply example to reproduce:

=
#+author:
Test
=

Run C-c C-e t A

Expected output:

=
Table of Contents
_




Test
=

Observed output:


=


Table of Contents
_




Test
=

I looked through the commits on master in the past month, but I don't see
any author-specific change that would affect *all* the exporter backends.

Can anyone else reproduce this issue?

--
Kaushal Modi


Re: Why not org-tempo insert upcased strings?

2020-04-27 Thread Kaushal Modi
On Mon, Apr 27, 2020, 4:35 AM tsuucat  wrote:

>
> > tsuucat  writes:
> >
> >>> Yes, the convention is now to have downcased keywords.
> >> Thanks. Is the convention documented?
> >>
> >> https://orgmode.org/manual/Structure-Templates.html#Structure-Templates
> 
> >> It doesn’t seems that The Org Manual uses such a convention.
> >
> > While the manual doesn't recommend which you should prefer (I don't
> > think), it does provide a rationale for its use of uppercase:
> >
> >(info "(org)Conventions")
> >
>
> Hmm…
> According to etc/ORG-NEWS, org-tempo.el was introduced in Org 9.2.
> Unfortunately the section doesn’t refer the change of convention.
>
> Why the convention is changed in org-tempo?
>

I'm a bit hazy about this, but I believe that org-tempo got introduced
after this commit:
https://code.orgmode.org/bzg/org-mode/commit/13424336a6f30c50952d291e7a82906c1210daf0

This was a few years ago. There was even a discussion thread on this list
that showed preference to make that change.

https://lists.gnu.org/archive/html/emacs-orgmode/2017-10/msg00449.html


Re: Why not org-tempo insert upcased strings?

2020-04-24 Thread Kaushal Modi
On Fri, Apr 24, 2020, 2:52 AM tsuucat  wrote:

> Hi,
> I tried Emacs 27 and found org mode shortcuts such as  then I found org-tempo.el.
>
> However, org-tempo.el’s shortcuts insert downcased blocks (e.g.
> #+begin_src).
> Is this intended?
>

Yes, the convention is now to have downcased keywords.

>


Re: Adding Romanian translation for ox.el

2020-04-21 Thread Kaushal Modi
On Tue, Apr 21, 2020 at 12:43 PM Claudiu Tănăselia 
wrote:

> Yay! My first contribution to org-mode and Emacs!
>
> Thank you cleaning it up and making it part of the official branch!
>
> Regards,
> Claudiu.
>

Congrats! Really glad you followed through the whole submission procession.
:)


Re: Debugging at least 2 regressions in org-mode master breaking ox-hugo

2020-03-05 Thread Kaushal Modi
On Thu, Mar 5, 2020 at 9:04 AM Bastien  wrote:

> Hi Kaushal,
>
> Kaushal Modi  writes:
>
> > I'm just pinging again on this thread to bring it to attention.
>
> I'm reading the list but I didn't find the time to reply to the
> threads yet, I'll get back to this.
>
> Thanks,
>

Thanks, no hurry. I just wanted to make sure that these issues are read
before Org 9.4 drops, and also that regression in Org maint is noted.


Re: Debugging at least 2 regressions in org-mode master breaking ox-hugo

2020-03-05 Thread Kaushal Modi
Hello,

I'm just pinging again on this thread to bring it to attention.

Thanks.

Kaushal


Re: Bug or not a bug? dot expansion in ob-shell

2020-02-27 Thread Kaushal Modi
Hello all,


On Wed, Feb 19, 2020 at 7:11 AM Bastien  wrote:

> Hi Eric,
>
> note that the previous behavior only _seemed_ right by chance: there
> is no notion of getting the exit code of the shell command in
> ob-shell.el, and returning "0" is just a hazard here, just because
> (org-babel--string-to-number ".") returns "0", while it should return
> nil.
>

Seems like I missed this long thread. After this change to
org-babel--string-to-number, now (org-babel--string-to-number "1,3-5") is
now returning 1 (instead of returning nil as before).

Related thread that I just started:
https://lists.gnu.org/r/emacs-orgmode/2020-02/msg00932.html


Re: Debugging at least 2 regressions in org-mode master breaking ox-hugo

2020-02-27 Thread Kaushal Modi
On Thu, Feb 27, 2020 at 9:13 AM Kaushal Modi  wrote:

> The regression is caused by
> https://code.orgmode.org/bzg/org-mode/commit/6b2a7cb20b357e730de151522fe4204c96615f98
> or the later commit that changes `org-babel--string-to-number'.
>
> Using this function redefinition with additional debug messages:
>
> (defun org-babel--string-to-number (string)
>   "If STRING represents a number return its value.
> Otherwise return nil."
>   (message "DBG: string: %S" string)
>   (unless (string-match-p "\\s-" (org-trim string))
> (let ((interned-string (ignore-errors (read string
>   (when (numberp interned-string)
> (message "DBG: interned string: %S" interned-string)
> interned-string
>
> I get:
>
> DBG: string: "1,3-5"
> DBG: interned string: 1
>
> So that ",3-5" piece of information is lost.
>

To be more specific, here is the call order:

org-babel-parse-header-arguments -> org-babel-read ->
org-babel--string-to-number

org-babel-read returns the string as-is if org-babel--string-to-number
returns nil.

*The regression is that earlier (org-babel--string-to-number "1,3-5") used
to return nil, but now it returns 1.*

I think that it should return a number only if 100% of the input string
represents a number. In the case of "1,3-5", it makes sense for it to still
return nil, so that org-babel-read does not throw away the ",3-5" piece of
information.


Re: Debugging at least 2 regressions in org-mode master breaking ox-hugo

2020-02-27 Thread Kaushal Modi
On Thu, Feb 27, 2020 at 9:00 AM Kaushal Modi  wrote:

> Failure 2: Change in parsing of org babel header arguments.
>
> The relevant snippet where I parse the header arguments in ox-hugo.el is
> at
> https://github.com/kaushalmodi/ox-hugo/blob/f8ec4aa5ad7d92f94bd8dbb814d85f980be67aea/ox-hugo.el#L2563
>
> This behavior change in org-babel-parse-header-arguments is also not
> documented in ORG-NEWS. I will now investigate what cause this regression.
>

The regression is caused by
https://code.orgmode.org/bzg/org-mode/commit/6b2a7cb20b357e730de151522fe4204c96615f98
or the later commit that changes `org-babel--string-to-number'.

Using this function redefinition with additional debug messages:

(defun org-babel--string-to-number (string)
  "If STRING represents a number return its value.
Otherwise return nil."
  (message "DBG: string: %S" string)
  (unless (string-match-p "\\s-" (org-trim string))
(let ((interned-string (ignore-errors (read string
  (when (numberp interned-string)
(message "DBG: interned string: %S" interned-string)
interned-string

I get:

DBG: string: "1,3-5"
DBG: interned string: 1

So that ",3-5" piece of information is lost.


Debugging at least 2 regressions in org-mode master breaking ox-hugo

2020-02-27 Thread Kaushal Modi
Hello,

I recently updated to the latest org-mode master and it is failing
ox-hugo[1] build and tests at 2 places.

Failure 1: org-get-outline-path has moved, and not mentioned in ORG-NEWS

Compiling ox-hugo.el now gives:

ox-hugo.el:4284:1: Warning: the function ‘org-get-outline-path’ is not
known to be defined.

I see that defun has now moved to org-refile.el. I see that
org-get-outline-path has nothing to do specific to refiling. Can that be
moved back to org.el, or may be a separate library? Otherwise, ox-hugo.el
will have to load org-refile.el too (yes, I don't use org-refile (yet), and
that's how I discovered this :))

Failure 2: Change in parsing of org babel header arguments.

This was caught by my weekly Travis CI cron jobs for ox-hugo:
https://travis-ci.org/kaushalmodi/ox-hugo/jobs/655410731#L2426

26c26
< {{< highlight emacs-lisp "hl_lines=1" >}}
---
> {{< highlight emacs-lisp "hl_lines=1 3-5" >}}

Earlier this kind of src block header:

#+begin_src emacs-lisp :hl_lines 1,3-5
...
#+end_src

got exported as

{{< highlight emacs-lisp "hl_lines=1 3-5" >}}

The regression is that now it is getting exported as

{{< highlight emacs-lisp "hl_lines=1" >}}

The values that I have after the comma in ":hl_lines 1,3-5" are getting
lost.

The relevant snippet where I parse the header arguments in ox-hugo.el is at
https://github.com/kaushalmodi/ox-hugo/blob/f8ec4aa5ad7d92f94bd8dbb814d85f980be67aea/ox-hugo.el#L2563

This behavior change in org-babel-parse-header-arguments is also not
documented in ORG-NEWS. I will now investigate what cause this regression.

...

--
Kaushal Modi

[1]: https://github.com/kaushalmodi/ox-hugo


Re: Survey: changing a few default settings for Org 9.4

2020-02-20 Thread Kaushal Modi
>
> > However, hiding emphasis and macro markers can make editing text at
> > the boundaries of emphasized text non-intuitive, which I can imagine
> > might frustrate some new users, so that should probably be carefully
> > considered.
>

+1e6


> Interestingly, hiding emphasis and macro markers are the two changes
> that get the *less* votes, so we probably won't change these.
>

Thank you! Hiding those will somehow take away the "Org-ness" in my humble
opinion :)


Re: A few changes to test in master

2020-01-31 Thread Kaushal Modi
On Fri, Jan 31, 2020, 9:45 PM Samuel Wales  wrote:

> org-table-header-line-mode?
>

+1

>


Re: A few changes to test in master

2020-01-31 Thread Kaushal Modi
On Fri, Jan 31, 2020, 6:28 AM Bastien  wrote:

> Dear all,
>
> I would like to highlight three changes from master that need to be
> carefully tested before Org 9.4 can be released:
>
> - M-x org-table-electric-header-mode RET will display the first row
>   of the table at point in the header line when the first row is not
>   visible anymore.
>

Hello Bastien,

Thanks for that mode!

Minor nitpick coming up..

May I suggest naming the mode org-table-sticky-header-mode instead? Somehow
the "electric" in the name wasn't intuitive to me.. or maybe that's just
me.


Re: documenting python module examples in orgmode

2019-12-09 Thread Kaushal Modi
On Mon, Dec 9, 2019, 5:49 AM Divan Santana  wrote:

> Hi All,
>
> I'm trying to document python module examples in orgmode.
>
> I'm sure this is possible, but not quite sure how to do it.
>
> I'd like to define the python module in one block, and then import it in
> another.
>

Have you looked at the Noweb syntax?

It might so what you want (inject code from one Org src block into multiple
other src blocks).

Here's an example from my notes where I use Noweb syntax with both Python
and Nim src blocks:
https://gitlab.com/kaushalmodi/kaushalmodi.gitlab.io/raw/master/content-org/notes/string-fns-nim-vs-python.org

>


Re: ox-latex: missing :LATEX_HEADER:

2019-12-04 Thread Kaushal Modi
On Wed, Dec 4, 2019 at 1:32 PM Karl Voit  wrote:

> Hi,
>
> For LaTeX export, I'd love to use ::LATEX_HEADER: instead of
> file-based settings with #+LATEX_HEADER.
>

Typically all Org export keywords work in properties too, but with an
"EXPORT_" prefix.

See if the ":EXPORT_LATEX_HEADER:" property works ..


Re: Gnus org-mode link problems in org 9.3

2019-12-04 Thread Kaushal Modi
On Wed, Dec 4, 2019 at 11:31 AM Kaushal Modi  wrote:

>
> Not sure if the issue you are seeing is because of the same cause.
>

It's very much likely that's the case:

>From https://orgmode.org/Changes.html :

> The old org-link-escape and org-link-unescape functions have been renamed
into org-link-encode and org-link-decode.


Re: Gnus org-mode link problems in org 9.3

2019-12-04 Thread Kaushal Modi
On Wed, Dec 4, 2019 at 11:27 AM Bob Newell  wrote:

> Aloha,
>
> Posting to both org-mode and gnus groups.
>
> Just updated to latest org (9.3 of 3 December) on Emacs 26.3.1
> and my gnus link functions seem to have quit.
>
> Now, whenever I do C-c C-o on an email link I get something like this:
>
> org-link-search: No match for fuzzy expression: gnus:nnimap+imap.gmail.com:
> %5BGmail%5D/All%20Mail#
> can9lugf6qkkyxt9ewjjs+hoyc6ywjasft4k4hv5zr2d10vy...@mail.gmail.com
>

Very strange! Just an hour back, my test suite failed because earlier
org-link-unescape used to unhex but now it doesn't. I haven't yet traced
back to the commit where this change happened.

Then replacing org-link-unescape with url-unhex-string fixed my use case[1].

Not sure if the issue you are seeing is because of the same cause.

[1]:
https://github.com/kaushalmodi/ox-hugo/commit/4badf135967c03c402ef8fc636ac4968ac98e57c


Re: [O] Emacs master, faces with :extend t let cursor vanish at EOL?!

2019-10-22 Thread Kaushal Modi
On Tue, Oct 22, 2019 at 3:52 PM Ingo Lohmar  wrote:

> I am writing to the org-mode list first, because I have only been able
> to reproduce this problem in org-mode.
>
> With a recent Emacs master build, faces can have the :extend t property
> to indicated that they should extend after the newline.  This is useful
> for a user to customize, eg, for `org-block', and it also applies to
> default faces like `region', `highlight' or `secondary-selection'.
>

Hello,

I have been seeing this issue too, but I haven't found time to create a
proper bug report for it.

But now that you have this email, I am forwarding this to the Emacs devel
list too.

The issue occurs because of the new :extend feature for faces to extend
till end of lines.

With that enabled, I have also seen that the cursor "hides" automatically
only at end of lines inside the Org source blocks. i.e within

#+begin_src emacs-lisp
(message "hello")X
#+end_src

Above: X is where the cursor would be, but it would not be visible (with
the :extend t added to the org-block face). The cursor would show up again
on doing C-b i.e. bringing it to any column position other than the EOL.


> Using this with a current elpa pkg of org-mode, and setting :extend t on
> faces like `org-block`, "often" the cursor vanishes at the EOL of a line
> using such a face.  It reliably happens for `org-block', only sometimes
> for `secondary-selection'.
>
> Has anybody else experienced that as well, or do you have any pointers
> on how to further investigate this?  I think I remember that org-mode does
> something with text overlays, but I can't relate that to what I see.
>
> There might also be an issue with face inheritance and the new :extend
> attribute --- I might post on emacs-devel to get a better idea of that
> as well.
>
> Thanks,
> Ingo
>
>


Re: [O] Shameless plug: blog series on how to use org mode features (PIM)

2019-09-25 Thread Kaushal Modi
On Wed, Sep 25, 2019, 5:49 AM Karl Voit  wrote:

> Hi!
>
> I created a series of my own blog articles on how I am using
> features from Org mode.
>
> It's not related to the manual, it's related to "how to combine misc
> features for everyday's work".
>
> Maybe you find a few tricks here or there:
> https://karl-voit.at/2019/09/25/using-orgmode/


Thanks for putting these together!

PS: Sorry for the advertisement in case you're feeling upset. I'm not
> earning
> any money with my web page though!
>

No upset felt here :)

>


Re: [O] export outside of emacs

2019-07-28 Thread Kaushal Modi
On Sun, Jul 28, 2019, 6:28 AM Luca Ferrari  wrote:

> Hi all,
> how can I run emacs to export org-mode files from outside of Emacs?


You just run with --batch. That starts "emacs -Q" in batch mode. If you
need to load some elisp at that point to make your export work, you can
pack all that in an elisp file and pass that to the --eval switch. Finally
use -f switch to specify which function to run to do the export.

Here's one example[1] (look at the "emacs-batch" target in there.

I would like to provide  a Makefile or a script to automatically build
> PDFs (LaTeX and Beamer) out of my org file repository.
>

[1]: https://github.com/kaushalmodi/ox-hugo/blob/master/Makefile

>


Re: [O] Compile failure

2019-06-24 Thread Kaushal Modi
That issue on Emacs master is fixed now for me.

--
Kaushal Modi

On Mon, Jun 24, 2019, 11:43 AM William Denton  wrote:

> On 24 June 2019, Robert Pluim wrote:
>
> > Thatʼs an emacs issue, not an org-mode issue. If you specify the full
> > path to your emacs binary instead of using a symlink, does it compile?
>
> I'm just going to wait, not touch anything more, and wait until the Emacs
> developers fix things.  I should have realized it wasn't an Org problem.
>
> It's often fun to keep on top of the current Emacs development tree, but
> then
> things like this happen.  Ah well!
>
> Bill
> --
> William Denton :: Toronto, Canada   ---   Listening to Art:
> https://listeningtoart.org/
> https://www.miskatonic.org/ ---   GHG.EARTH: https://ghg.earth/
> Caveat lector.  ---   STAPLR: http://staplr.org/


[O] Question about using #+call to insert Org mode snippet with different noweb refs

2019-05-10 Thread Kaushal Modi
Hello,

I recently came across this awesome tool call wavedrom and was taking my
notes as I was following its tutorial: https://wavedrom.com/tutorial.html.

In order to prevent copy/pasting the same "wavedrom snippet" in the src
text block and the begin_export html block, I did the below. It works.. but
I wonder if this can be made more concise by using #+call.

If it's possible, what would be "called" org source block look like so that
I can pass it the noweb reference string?

Or .. what would be a concise way to write the below?

Thanks!

=

*** Step {{{n(,1)}}}. The Signal
#+begin_src text :noweb-ref wavedrom-eg-1
{ signal: [{ name: "Alfa", wave: "01.zx=ud.23.45" }] }
#+end_src
#+begin_src org :noweb yes :exports results :results output replace
,#+begin_export html

<<wavedrom-eg-1>>

,#+end_export
#+end_src

#+RESULTS:
#+begin_export html

{ signal: [{ name: "Alfa", wave: "01.zx=ud.23.45" }] }

#+end_export

*** Step {{{n}}}. Adding Clock
#+begin_src text :noweb-ref wavedrom-eg-2
{ signal: [
  { name: "pclk", wave: 'p...' },
  { name: "Pclk", wave: 'P...' },
  { name: "nclk", wave: 'n...' },
  { name: "Nclk", wave: 'N...' },
  {},
  { name: 'clk0', wave: 'phnlPHNL' },
  { name: 'clk1', wave: 'xhlhLHl.' },
  { name: 'clk2', wave: 'hpHplnLn' },
  { name: 'clk3', wave: 'nhNhplPl' },
  { name: 'clk4', wave: 'xlh.L.Hx' },
]}
#+end_src
#+begin_src org :noweb yes :exports results :results output replace
,#+begin_export html

<<wavedrom-eg-2>>

,#+end_export
#+end_src

#+RESULTS:
#+begin_export html

{ signal: [
  { name: "pclk", wave: 'p...' },
  { name: "Pclk", wave: 'P...' },
  { name: "nclk", wave: 'n...' },
  { name: "Nclk", wave: 'N...' },
  {},
  { name: 'clk0', wave: 'phnlPHNL' },
  { name: 'clk1', wave: 'xhlhLHl.' },
  { name: 'clk2', wave: 'hpHplnLn' },
  { name: 'clk3', wave: 'nhNhplPl' },
  { name: 'clk4', wave: 'xlh.L.Hx' },
]}

#+end_export

=

--
Kaushal Modi


Re: [O] Regression in org-table-recalculate-buffer-tables and #+startup: shrink [devel branch]

2019-04-23 Thread Kaushal Modi
Hello Nicolas,

On Tue, Apr 23, 2019 at 4:37 AM Nicolas Goaziou 
wrote:

>
> Fixed. Thank you.
>

Thank you for the quick fix!


[O] Regression in org-table-recalculate-buffer-tables and #+startup: shrink [devel branch]

2019-04-22 Thread Kaushal Modi
Hello,

Lately (past week), I have noticed a failure for all functions to run from
my org-mode-hook, because I got an error like:

File mode specification error: (user-error Not at a table)

This error happens if:

1. I call M-x org-table-recalculate-buffer-tables (I have that function in
my org-mode-hook).
2. The Org buffer has #+startup: shrink, and
3. An Org table with column width cookies has #+caption.

Here's a minimal reproducible example:

=
#+title: User-error when trying to recalculate tables in buffer with shrink
enabled
#+startup: shrink

#+caption: Foo
| <25> |
| Foo  |
=

1. Save above to an Org file, close and reopen that file so that #+startup
gets evaluated.
2. M-x org-table-recalculate-buffer-tables and you will get the
"user-error: Not at a table" error.

Interestingly, this error does not show up if simply that #+caption line is
removed.

I believe that this commit caused this regression:
https://code.orgmode.org/bzg/org-mode/commit/222408d70a3674f06ddd6b77e4e1126c602e7361
.

Org mode version 9.2.3 (release_9.2.3-336-g09a1a2 @
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/)

Thanks!

--
Kaushal Modi


Re: [O] Lowercase keywords in 9.2?

2019-02-12 Thread Kaushal Modi
On Tue, Feb 12, 2019 at 3:59 PM Carlos Pita 
wrote:

> > What do you mean with the "uppercase legacy"? You mean all the current
> documents we already have?
>
> Specifically what motivated this post: collections of snippets that
> have been written with the historical convention in mind. It's easy to
> convert them but it's not that easy to convert users :).
>

I am one of those who prefer the lower-case keywords :)

I started converting my Org documents to use the new convention around the
time it landed in the Org mode master branch little more than a year back:
https://scripter.co/org-keywords-lower-case/.


Re: [O] Key bindings for Org export back-ends?

2019-02-08 Thread Kaushal Modi
On Fri, Feb 8, 2019 at 10:48 AM Thomas S. Dye  wrote:

> One place for the list of key bindings might be here:
> https://orgmode.org/worg/exporters/index.html
>

That's a great idea! How about creating a single Org table with columns
like Name, Description, Binding, Core/Contributed, and then sort the rows
by the Binding column?

We can leave the obsolete exporters section separate as it is right now.


Re: [O] Key bindings for Org export back-ends?

2019-02-08 Thread Kaushal Modi
On Fri, Feb 8, 2019, 3:28 AM Jens Lechtenboerger 
> - org-reveal [3]: R
> - org-re-reveal [4]: r (conflict with RSS)
>

I see that org-re-reveal is based off org-reveal. So do you see a use case
where people would `require' both org-reveal and org-re-reveal? If not,
then using the same binding as that of org-reveal should be fine too.


Where could we document the resulting list?
>

I'm pretty sure there are many more Org backends out there. For example, I
have a little ox-minutes backend that uses the M binding (and overrides the
binding for ox-man, but that's fine for me as I don't use ox-man).

We can start collecting a list of all Org backends on the Worg wiki. That's
a good idea. But doing so in order to not override the binding of some
other backend might not be possible.

I’m thinking of changing org-re-reveal to p (for presentation) or v
> (as occurring letter).


What about R as I suggested above?

  Or C-r?  So far, no back-end uses the
> control key.  Any reasons not to do this?
>

You could probably use C-, but one has to ensure that it doesn't
override the inbuilt bindings like C-s (C-c C-e C-s ..). Also, not sure if
that override would actually be effective.

>


Re: [O] Manual available?

2019-02-04 Thread Kaushal Modi
On Mon, Feb 4, 2019 at 11:33 AM Lawrence Bottorff  wrote:

> Is the latest org-mode manual available as an org file? Is there a github
> for it somewhere?
>
> LB
>

It's here:
https://code.orgmode.org/bzg/org-mode/raw/master/doc/org-manual.org


Re: [O] M-S-RET doesn't work anymore?

2019-01-23 Thread Kaushal Modi
On Wed, Jan 23, 2019, 7:45 PM Amin Bandali 
> Also notice the left over greater sign ‘>’ on the fourth line.
>

Yeah, that was fixed in a later commit. I was surprised to see that too,
but confirmed that the latest master doesn't have that.

>


Re: [O] M-S-RET doesn't work anymore?

2019-01-23 Thread Kaushal Modi
On Wed, Jan 23, 2019 at 3:54 PM Marco Wahl  wrote:

> As a workaround you can evaluate the lines (that were active before the
> commit)
>
> (org-defkey org-mode-map (kbd "S-") #'org-table-copy-down)
> (org-defkey org-mode-map (kbd "M-S-") #'org-insert-todo-heading)
> (org-defkey org-mode-map (kbd "ESC S-") #'org-insert-todo-heading)
>
> or put them into your init file AFAICS.
>

Yep, that commit broke the - bindings for me too. I'll have to do
the same.

Copying Kevin who originally requested the change of these bindings (this
switching of bindings between RET and  feels like dejavu to me .. I
have seen this done before in Org repo).

Is this a reliable fix to add these lines to the source code again?
> To be honest I don't see clearly.
>

May be those keys should be bound to both RET and  variants?

For Emacs GUI, I think that the  variant is needed, RET does
nothing.


Re: [O] Shift-RETURN in table doesn't copy the value of the cell above

2019-01-23 Thread Kaushal Modi
Possible a regression caused by
https://code.orgmode.org/bzg/org-mode/commit/8a1957d59201940613ee90be9ed0a49e70131f37
?

--
Kaushal Modi


On Wed, Jan 23, 2019 at 3:27 PM William Denton  wrote:

>
> |A|B|
>
> This set of keystrokes makes:
>
> | A | B |
> |   |   |
> |   |   |
>
> But it used to make:
>
> | A | B |
> | A |   |
>
> Shift-RETURN doesn't copy the value of the cell above.  This changed a
> little
> while ago (in the main development tree) but I don't know exactly when.
>
> Bill
> --
> William Denton :: Toronto, Canada   ---   Listening to Art:
> https://listeningtoart.org/
> https://www.miskatonic.org/ ---   GHG.EARTH: http://ghg.earth/
> Caveat lector.  ---   STAPLR: http://staplr.org/
>
>


Re: [O] M-S-RET doesn't work anymore?

2019-01-23 Thread Kaushal Modi
On Wed, Jan 23, 2019 at 3:13 PM Bernt Hansen  wrote:

> Hi,
>
> I regularly create checkbox lists on the fly with
>
> 1. [ ] blah and M-S-RET to create  the second entry
>
> 2. [ ]
>
> But the checkbox is missing today.  Has this functionality changed?
>
> I am running the latest master from git on windows emacs 25.1
>

Possible a regression caused by
https://code.orgmode.org/bzg/org-mode/commit/8a1957d59201940613ee90be9ed0a49e70131f37
?


Re: [O] How to get ordinal of an element in the subtree when exporting?

2019-01-17 Thread Kaushal Modi
On Thu, Jan 17, 2019 at 8:21 AM mgcyung  wrote:

>
> The function "org-export-get-ordinal" returns the ordinal of an element
> in the whole file. How to get ordinal of an element in the subtree when
> exporting?
>

Do you mean you want the ordinal counting to reset when the subtree begins?
In that case, export with the subtree scope: C-c C-e C-s ..


[O] Org Elpa deployment failing for past 2 weeks

2019-01-15 Thread Kaushal Modi
Hello,

The Org Elpa deploys a new release every week on Mondays.

But it looks like that release has been failing for past 2 weeks.

Here's the log file from yesterday that shows the error during make
cleanall: https://orgmode.org/elpa/build-org-pkg.txt

--
Kaushal Modi


Re: [O] Displaying inline svg images

2019-01-09 Thread Kaushal Modi
Hello Colin, Eric:

First of all, thanks for checking things on your end, and apologize for the
noise.

I had an experimental setting of image-type-header-regexps lying in my
Emacs config and that messed up the SVG inlining.

All good now.


Re: [O] Displaying inline svg images

2019-01-09 Thread Kaushal Modi
>
> Thanks Eric, Colin.

Please see my further questions below.

> Eric S Fraga  writes:
>
> > Your example works fine for me but I am using a slightly old
> > version of org so maybe something has changed?
>
> > -- Eric S Fraga via Emacs 27.0.50, Org release_9.1.14-1035-gfeb442
>

I see that you are running Emacs master. Can you also report the git hash
used to build it? Also, what is your imagemagick version?

On Wed, Jan 9, 2019, 3:18 AM Colin Baxter  (release_9.2-152-gc006a6).
>

Great! So any regression in Org mode 9.2 is ruled out :)

I need to see what's different in my environment: Emacs version,
imagemagick version.

Later today, I'll find out my imagemagick version, and also try running my
example on Emacs 26.1.

Thanks all!

>


[O] Displaying inline svg images

2019-01-08 Thread Kaushal Modi
Hello,

I am unable to display inline SVG images.

Here is the minimum reproducible example:

1. I have org-image-actual-width defcustom at its default value of t.
2. Here is the Org file:

=
#+startup: inlineimages

[[file:red-blue-squares.svg]]
=

3. Here is the example SVG file. Put it in the same dir as the Org file as
red-blue-squares.svg.

=

http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd;>

http://www.w3.org/2000/svg;
 width="467" height="462">
  

  

=

Upon saving the .svg file and then opening the .org file, I do not see the
image inlined.

Is anyone able to reproduce this?

Upon investigating the org-display-inline-images function in org.el, I
found that this happens because the internal variable width is evaluated as
nil and `:width nil' gets passed to the `create-image' function ..
resulting in a zero-width SVG.

Though, this is not a problem with PNG and JPG images.

As a quick workaround, I did this:

=
diff --git a/lisp/org.el b/lisp/org.el
index ea1607d85..54e8d0142 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -18618,7 +18618,8 @@ boundaries."
  (let ((image (create-image file
 (and width 'imagemagick)
 nil
-:width width)))
+;; :width width
+)))
(when image
  (let ((ov (make-overlay
 (org-element-property :begin link)
=

i.e. I stopped passing the :width property to create-image altogether and
after that the SVG image showed inline just fine.

So, is there any point passing `:width width' if width is nil? If not, I
can work on a patch that prevents passing that property only in that case.



Org version: Org mode version 9.2 (release_9.2-151-g8a5d8f ..) | master
branch
Emacs version: GNU Emacs 27.0.50 (build 5, x86_64-pc-linux-gnu, GTK+
Version 2.24.23)
 of 2019-01-08, built using commit 55c5e26307a1e8f1fff74415fc560aa172a421cf
| master branch


--
Kaushal Modi


Re: [O] Change in order of tag collation from #+filetags plus heading tags [Regression 9.1 -> 9.2]

2019-01-08 Thread Kaushal Modi
On Fri, Jan 4, 2019 at 4:43 PM Kaushal Modi  wrote:

> I am also copying Matt Lundin as I believe that this commit[1] caused this
> regression.
>
> If above looks good, I will go ahead the commit this patch with test,
> proper commit log, etc.
>

I went ahead and committed this fix to maint (and merged to master) as it
did not fail any existing test:
https://code.orgmode.org/bzg/org-mode/commit/34e5dcfb06800802a5e06f13340d646b6d829f04
.


Re: [O] batch failure of first org-num test

2019-01-08 Thread Kaushal Modi
On Mon, Jan 7, 2019, 2:56 PM Kyle Meyer  Sorry, I just now spotted an earlier message from Kaushal that reports
> the same test failure:
> https://lists.gnu.org/archive/html/emacs-orgmode/2019-01/msg00112.html


No need to be sorry. You did the debugging and even found a fix for this. :)


[O] Failing org-num-mode test

2019-01-07 Thread Kaushal Modi
Hello Nicolas,

While recently working on few Org tag fixes in org.el, I was running make
test, and saw 1 test related to the recently added org-num-mode fail.

The failure can be quickly recreated with:

 make test BTEST_RE=test-org-num

=
Test test-org-num/format-function condition:
(ert-test-failed
 ((should
   (equal '...
(org-test-with-temp-text "* H1
** H2" ... ...)))
  :form
  (equal
   ("foo" "foo")
   (#("1.1 " 0 4 ...)
 #("1 " 0 2 ...)))
  :value nil :explanation
  (list-elt 0
(arrays-of-different-length 3 4 "foo"
#("1.1 " 0 4 ...)
first-mismatch-at 0
   FAILED  1/4  test-org-num/format-function (0.002472 sec)
   passed  2/4  test-org-num/max-level (0.000511 sec)
   passed  3/4  test-org-num/skip-numbering (0.003965 sec)
   passed  4/4  test-org-num/update (0.038399 sec)

Ran 4 tests, 3 results as expected, 1 unexpected (2019-01-07 08:32:35-0500,
0.184330 sec)

1 unexpected results:
   FAILED  test-org-num/format-function
=

Can you confirm?

--
Kaushal Modi


Re: [O] Change in order of tag collation from #+filetags plus heading tags [Regression 9.1 -> 9.2]

2019-01-04 Thread Kaushal Modi
On Fri, Jan 4, 2019 at 8:15 AM Nicolas Goaziou 
wrote:

>
> The order of tags is unspecified, either in the docstring, in the
> manual, or in the syntax. So it doesn't really matter.
>

This regression was caught by one of the ox-hugo tests. I'd to like to fix
it to the former tag order because I think it makes sense to have the
#+filetags tags in the very beginning instead of embedding it between the
parent heading tags and local tags.


> Feel free to provide a patch if it bothers you.
>

Here is the proposed rough patch; locally I also have a test ready that
tests this regression.

=
diff --git a/lisp/org.el b/lisp/org.el
index 2273a6997..15744704a 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -14607,11 +14607,11 @@ Inherited tags have the `inherited' text
property."
 (org-back-to-heading t)
 (let ((ltags (org--get-local-tags)) itags)
   (if (or local (not org-use-tag-inheritance)) ltags
-(setq itags org-file-tags)
 (while (org-up-heading-safe)
   (setq itags (append (mapcar #'org-add-prop-inherited
   (org--get-local-tags))
   itags)))
+(setq itags (append org-file-tags itags))
 (delete-dups
  (append (org-remove-uninherited-tags itags) ltags
=

I am also copying Matt Lundin as I believe that this commit[1] caused this
regression.

If above looks good, I will go ahead the commit this patch with test,
proper commit log, etc.

Thanks for reviewing.

[1]:
https://code.orgmode.org/bzg/org-mode/commit/5e27b2fd326810e4ed876b094df852338909c1f8


Re: [O] Fix C-u C-c C-q (align all tags in visible buffer)

2019-01-04 Thread Kaushal Modi
Hello Nicolas,

On Fri, Jan 4, 2019 at 8:17 AM Nicolas Goaziou 
wrote:

> Hello,
>
>
> > If this looks good, I can commit this to maint and master.
>
> Sure. Please also provide a regression test for it.
>

Thank you.

Commited to maint, merged to master, with a test.

https://code.orgmode.org/bzg/org-mode/commit/539091799b370a1c452fe4952e8074d7dfe8656f


[O] Change in order of tag collation from #+filetags plus heading tags [Regression 9.1 -> 9.2]

2019-01-03 Thread Kaushal Modi
Hello,

I have noticed a minor regression in the order in which Org collects the
"ALLTAGS" tags at point.

Here is a simple Org file to reproduce that issue:

=
#+filetags: a

* Level 1
:b:
** Level 2
:c:
*** Level 3
:d:

=

With point anywhere under ~* Level 3~ heading, evaluate:

M-: (org-entry-get (point) "ALLTAGS")


In Org 9.1.x, the order of tags returned was ":a:b:c:d:".
But in Org 9.2, the order becomes ":b:c:a:d:".

So, earlier (Org 9.1.x) the order was:
1. tags from filetags
2. tags from parent headings in order
3. current heading tags

In Org 9.2, the order is:
1. *tags from parent headings in order*
2. *tags from filetags*
3. current heading tags

Is this switch of order expected?


--
Kaushal Modi


[O] Fix C-u C-c C-q (align all tags in visible buffer)

2019-01-03 Thread Kaushal Modi
Hello,

This minor bug had been bothering me for a while and I eventually got to
looking into the source code for it.

As of current master, C-u C-c C-q doesn't work as in the doc-string i.e.
"When optional argument ALL is non-nil, align all tags in the visible part
of the buffer.".

Here's an example Org buffer:

=
* Foo :abc:
** Bar :def:
=

- With point on Foo heading, C-u C-c C-q aligns only :def: tag (tags from
*next* heading onwards).
- So when point is on Bar, no tags get aligned.

Though I remember that C-u C-c C-q worked quite some time back.

A commit in Apr 28, 2018 broke that behavior in
https://code.orgmode.org/bzg/org-mode/commit/1615261cdc5da6dbe50176d7958c775d6d54411e#diff-f9a90d66b3053f60bd4e8d63f214273067d0d28L14288
.

While I don't understand that entire commit, this simple fix brings back
the true C-u C-c C-q behavior:

diff --git a/lisp/org.el b/lisp/org.el
index db3c11b5f..b8daa3bfc 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -14203,8 +14203,10 @@ visible part of the buffer."
 (org--align-tags-here (funcall get-indent-column))
   (save-excursion
 (if all
+(progn
+  (goto-char (point-min))
   (while (re-search-forward org-tag-line-re nil t)
-  (org--align-tags-here (funcall get-indent-column)))
+(org--align-tags-here (funcall get-indent-column
   (org-back-to-heading t)
   (org--align-tags-here (funcall get-indent-column)))


If this looks good, I can commit this to maint and master.

Thanks.


--
Kaushal Modi


Re: [O] How to specify block quote language?

2018-12-20 Thread Kaushal Modi
On Thu, Dec 20, 2018 at 3:09 PM Abigaile Johannesburg  wrote:

>
> Is there a way to specify the language for quoted text? For example,
>
> #+begin_quote :lang=jp
> quotes
> #+end_quote
>

You can do this instead which is already supported:

#+attr_html: :lang jp
#+begin_quote
quotes
#+end_quote

This creates:



quotes




Re: [O] Meta : what can be sent to this mailing list ?

2018-12-19 Thread Kaushal Modi
I think that emails with attachments exceeding a certain size are blocked.

You might want to upload your attachments somewhere else, and simply link
to them in your emails sent to this list.

--
Kaushal Modi

On Wed, Dec 19, 2018, 9:40 AM Emmanuel Charpentier <
emanuel.charpent...@gmail.com wrote:

> Dear list,
>
> I have made five attempts in three days to post a question to this list.
> Three of them may have failed due to the use of an SMTP server flagged on
> one site as possible spam source. The other two has been sent via gmai. So
> far, none of these message have appeared on the list, and I received no
> error message.
>
> I know tha *some* attachments are accepted (a previous question of mine
> included .tex, .pdf and .org files). However, I waonder if my mails may
> have been blocked by .docx and .odt attachments.
>
> Could you let me know if some attachments are blocked by the list manager
> or mail server ?
>
> Tkanks in advance,
>
> --
> Emmanuel Charpentier
>
>


Re: [O] [PATCH] org-capture: Add a custom to control save target file or not.

2018-12-13 Thread Kaushal Modi
On Thu, Dec 13, 2018 at 11:25 AM Nicolas Goaziou 
wrote:

>
> > +(unless (org-capture-get :no-save)
> > +  ;; Save the target file.
> > +  (save-buffer))
>
> The comment does not look terribly useful. I would put the whole
> `unless' in a single line.
>
> Barring that nitpicking of mine, LGTM!
>

Thanks. I have made the suggested change, and pushed to master, merged into
next.


Re: [O] [PATCH] org-capture: Add a custom to control save target file or not.

2018-12-13 Thread Kaushal Modi
On Thu, Dec 13, 2018 at 10:24 AM Kaushal Modi 
wrote:

>
> I have formatted 2 patches to address this (attached). If they look fine,
> I can commit them to master.
>

I forgot to properly format the commit messages.. locally, I have fixed the
commit message of 0002 patch to the below:

=
Add :no-save keyword for Org capture templates

* lisp/org-capture.el (org-capture-finalize): Do not save the target
  capture file if :no-save keyword is non-nil in the capture template.
* doc/org-manual.org (Template elements),
  lisp/org-capture.el (org-capture-templates): Document :no-save.

Ref: https://lists.gnu.org/r/emacs-orgmode/2018-09/msg00325.html
=


Re: [O] [PATCH] org-capture: Add a custom to control save target file or not.

2018-12-13 Thread Kaushal Modi
On Thu, Dec 13, 2018 at 10:08 AM Kaushal Modi 
wrote:

> Hello Nicolas,
>
> While we are planning to cut Org 9.2 release this week, this one
> regression in the Org Capture and auto-saving behavior comes to my mind,
> that I think should be fixed.
>
> Summary:
>
> In Org 9.1.x, org-capture target files got auto-saved after C-c C-c when
> ending the capture. In Org master branch, that stopped happening.
>
> As per your last proposal, we should revert
> https://code.orgmode.org/bzg/org-mode/commit/b4422add3745c26ec3b2e11b8da425844b2e9d3d
> and then add a :no-save option that skips that save-buffer call.
>

I have formatted 2 patches to address this (attached). If they look fine, I
can commit them to master.


0001-Revert-org-capture-Do-not-save-buffer-when-running-o.patch
Description: Binary data


0002-Add-no-save-keyword-for-Org-capture-templates.patch
Description: Binary data


Re: [O] [PATCH] org-capture: Add a custom to control save target file or not.

2018-12-13 Thread Kaushal Modi
Hello Nicolas,

While we are planning to cut Org 9.2 release this week, this one regression
in the Org Capture and auto-saving behavior comes to my mind, that I think
should be fixed.

Summary:

In Org 9.1.x, org-capture target files got auto-saved after C-c C-c when
ending the capture. In Org master branch, that stopped happening.

As per your last proposal, we should revert
https://code.orgmode.org/bzg/org-mode/commit/b4422add3745c26ec3b2e11b8da425844b2e9d3d
and then add a :no-save option that skips that save-buffer call.

Past references:
- https://lists.gnu.org/r/emacs-orgmode/2018-04/msg00204.html
- https://lists.gnu.org/r/emacs-orgmode/2018-09/msg00325.html

--
Kaushal Modi


On Sat, Sep 29, 2018 at 6:36 AM Van L  wrote:

>
> >> Then saving should be the default again, and not saving optional.
> >
> > I believe this would be the best option.
>
> Very, very strongly concur with this belief.
>
>


Re: [O] [PATCH] ox.el: Define subtitle macro

2018-12-12 Thread Kaushal Modi
> master branch is meant to be released... at some point. For the record,
> I cannot do it myself.

+1 It would be great to have Org 9.2 released!



Re: [O] meaning for _ (and perhaps ^) temporalily changed

2018-12-12 Thread Kaushal Modi
On Mon, Dec 10, 2018 at 5:34 AM Rudolf Sykora  wrote:
>
> Dear list,
>
> is there a way to *temporalily* disable the default interpretation
> of _ as a subscript?
>
> I use filenames which include _ , while I have
> many other places where I want the default behaviour
> (I don't want to rewrite these with explicit {} and changing
> org-use-sub-superscripts variable to {}).

If you set this in your Emacs config:

(setq org-export-with-sub-superscripts '{})

The subscripts and superscripts will be parsed only when the
to-be-subscripted/superscripted is enclosed in _{..} and ^{..}
respectively.

If you don't want to set this option globally,add this to the top of
your Org file:

#+options: ^:{}

>From Org manual (org) Export Settings:

‘^’
 Toggle TeX-like syntax for sub- and superscripts.  If you write
 ‘^:{}’, ‘a_{b}’ is interpreted, but the simple ‘a_b’ is left as it
 is (‘org-export-with-sub-superscripts’).



Re: [O] Noweb blocks duplicate during Org export if part of #+include

2018-12-12 Thread Kaushal Modi
On Sat, Dec 8, 2018 at 4:42 AM Nicolas Goaziou  wrote:

> Now, onto the second case. When evaluating Babel code, the whole initial
> buffer is taken as reference. It allows, for example, to define source
> blocks in a dedicated section, and export another one that calls them.
> When the INCLUDE keyword is expanded, there are two ":noweb-ref
> some_snippet". Even if they are outside the exported subtree, they are
> still concatenated and used as a replacement for "<".
>
> In a nutshell, that can be surprising, but this is to be expected.


Thank you for the detailed answer.

As I don't know how to "fix" this, I will just remember to not use
Noweb in subtrees that I plan to  #+include.



Re: [O] Where is org-mime?

2018-12-10 Thread Kaushal Modi
On Mon, Dec 10, 2018 at 10:44 AM Alexandre Garreau
 wrote:
>
> I recently learnt about org elpa repo, including its package with the contrib 
> directory (I always wondered about what were the canonical way to get it!), 
> but it seems not to include org-mime (org-plus-contrib-20181210)… where are 
> we supposed to get it as an installable package?

You can find it here: https://github.com/org-mime/org-mime

Here's the raw wgettable link:
https://raw.githubusercontent.com/org-mime/org-mime/master/org-mime.el



[O] Noweb blocks duplicate during Org export if part of #+include

2018-12-06 Thread Kaushal Modi
Hello,

Here is a MWE:

1. With point on the "** Foo" section, running C-c C-e C-s h o, will
result in noweb-duplicate-bug.html with the <> block
expanded only once, as expected.

2. But with point on the "* Foo Included" section, running the same
C-c C-e C-s h o, will result in foo_included.html with the
<> block expanded twice! It seems like the Noweb
expansion happens first as usual, and then again when parsing
#+include (which shouldn't happen?).

=
#+title: Noweb Duplicating Bug
#+author: Kaushal Modi

* Reused Sections
** Foo
:PROPERTIES:
:CUSTOM_ID: foo
:END:
*** Some Snippet
#+begin_src emacs-lisp :noweb-ref some_snippet
(message "Hello")
#+end_src
*** Some Snippet used again
#+begin_src emacs-lisp :noweb yes
(defun foo ()
  <>
  )
#+end_src
* Foo Included
:PROPERTIES:
:EXPORT_FILE_NAME: foo_included
:END:
#+include: "./noweb-duplicate-bug.org::#foo" :only-contents t
=


Org version, built from next branch: Org mode version 9.1.14
(release_9.1.14-1147-g6f8347 @
/home/kmodi/usr_local/apps/6/emacs/old-emacsclient/share/emacs/site-lisp/org/)

--
Kaushal Modi



Re: [O] Ox-html: Replace with and with

2018-10-24 Thread Kaushal Modi
On Wed, Oct 24, 2018 at 2:04 AM Nicolas Goaziou  wrote:
>
>
> No objection from me. Thank you!

Actually, before making this change, I started reading up on the HTML5
spec on the b, strong, i, em tags, and now I am confused as ever.

Facts:

- b and i are not deprecated
- b and strong are both valid but their use depends on the writer's
context (but Org mode has just one mark for either "*")
- i and em are both valid but their use depends on the writer's
context (but Org mode has just one mark for either "/").

>From "em" docs[em], in the NOTE section there:

> The em element isn’t a generic "italics" element. Sometimes, text is intended 
> to stand out from the rest of the paragraph, as if it was in a different mood 
> or voice. For this, the i element is more appropriate.

See the b tag docs[b] and i tag docs[i], and this W3C FAQ on using b
and i tags[faq] for more.


*Summary* (/see what I did there?/):

I guess there's no need to change what "*" and "/" do right now in
ox-html, as there doesn't seem "one right way" to do things here.

And folks strongly wanting to use  and  for bold and
italic can customize org-html-text-markup-alist.

HTML experts, please chime in.



[em]: https://www.w3.org/TR/html5/textlevel-semantics.html#the-em-element
[b]: https://www.w3.org/TR/html5/textlevel-semantics.html#the-b-element
[i]: https://www.w3.org/TR/html5/textlevel-semantics.html#the-i-element
[faq]: https://www.w3.org/International/questions/qa-b-and-i-tags



[O] Ox-html: Replace with and with

2018-10-23 Thread Kaushal Modi
Hello,

I am not an HTML expert. But recently off-list, I learnt that  and 
tags aren't recommended to be used for styling any more (for a while now).

Instead  and  should be used respectively.

If there are no objections, I can commit this little change to the master
branch.

References:

- https://developer.mozilla.org/en-US/docs/Web/HTML/Element/b
- https://developer.mozilla.org/en-US/docs/Web/HTML/Element/i#Usage_Notes

--
Kaushal Modi


Re: [O] Problem in removing the invisible brackets of a link

2018-10-14 Thread Kaushal Modi
On Sun, Oct 14, 2018, 4:08 AM Nicolas Goaziou 
wrote:

> Hello,
>
> alain.coch...@unistra.fr writes:
>
> >  > =[[xx]]= and ~[[xx]]= are not links; try to export them.
> >
> > Indeed.  Thanks once more.
>
> For the record, I fixed fontification of verbatim markup. Links within
> =...= and ~...~ are no longer fontified.
>

You fixed a little long time pet peeve :) Many thanks!

>


Re: [O] Branch "next" garbled

2018-10-11 Thread Kaushal Modi
On Thu, Oct 11, 2018, 9:46 PM Adrian Bradd  wrote:

>
> Sorry if this is obvious, but what is the next branch
>

Simply put, the next branch is even more bleeding edge than the master.

Bleeding-edgeness: next > master > maint

- maint :: gets published to Org Elpa, etc. Right now the version there is
9.1.x. This branch only takes bug and doc fixes right now
- master :: this is the soon(TM)-to-be released Org 9.2 version. This has
quite a many features (including few breaking) on top of Org 9.1.x. As this
version is planned to be released soon, the plan is to not touch this
branch for the time being as it gets tested out more. Touch this only for
doc and bug fixes for Org 9.2.
- next :: This branch is open to all sorts of commits. Changes here won't
be visible until the next to next major Org release (probably 9.3?).

In general, you would always commit to the most stable branch first and
then merge that to the next less stable branch in succession.

The less stable branch always contains all commits (as-is or merged) from
the more stable branch.

It isn't mentioned on worg in the developers section either
> (https://orgmode.org/worg/dev/index.html).
>

My understanding is that the next branch is not a long term thing.

>


Re: [O] Order of tangled blocks reversed?

2018-10-10 Thread Kaushal Modi
On Wed, Oct 10, 2018 at 6:05 PM Nicolas Goaziou  wrote:
> It is. Fixed. Thank you.

Awesome! Thank you!



[O] Order of tangled blocks reversed?

2018-10-07 Thread Kaushal Modi
Hello,

I was playing with Org Tangle header-args inheritance and came up with
this example:

=
#+property: header-args :tangle yes

At Org level 0.

* Heading 1
:PROPERTIES:
:header-args: :tangle foo.el
:END:
At Org level 1.
#+name: block1
#+begin_src emacs-lisp
(message "this will be tangled to property_drawer2.el")
#+end_src
** Heading 1.1
:PROPERTIES:
:header-args:emacs-lisp: :tangle no
:END:
At Org level 2.

Only the emacs-lisp block will *not* be tangled from this subtree.
#+name: block2
#+begin_src emacs-lisp
(message "this block will *not* be tangled")
#+end_src

But the below Nim block will tangle fine (though incorrectly to the
foo.el file!). Though, the below /block3/ appears *above* /block1/ in
the tangled file foo.el.
#+name: block3
#+begin_src nim
echo "this block will be tangled to property_drawer2.nim"
#+end_src
=

Tangling this (C-c C-v t) gives this foo.el file:

=
echo "this block will be tangled to property_drawer2.nim"

(message "this will be tangled to property_drawer2.el")
=

Ignoring that Nim code gets inserted into the Emacs-Lisp file because
of incorrect :tangle header-args under Heading 1, why is the block3
code appearing above block1?

Is this a bug?

Org mode version 9.1.14 (release_9.1.14-933-gfe72a0 @
/home/kmodi/usr_local/apps/6/emacs/master/share/emacs/site-lisp/org/)


--
Kaushal Modi



Re: [O] [RFC] Replace lambda functions added to org-mode-hook with named funcs

2018-10-06 Thread Kaushal Modi
On Fri, Oct 5, 2018, 6:42 AM Nicolas Goaziou  wrote:

>
> If that's a function added to `org-mode-hook', it is not useful to add
> "on major mode change".
>

Yes, I'll remove that one hook addition.

> If there is no objection to this, I can fix this everywhere in maint,
> > and then merge that into master.
>
> Please make changes in "master" instead, and merge them into "next"
> then.
>

OK. I'll get to this sometime this week.

Thanks.

>


[O] [RFC] Replace lambda functions added to org-mode-hook with named funcs

2018-10-04 Thread Kaushal Modi
Hello,

Yesterday, while helping someone out[0] with why their custom
functions added to org-mode-hook didn't work, I asked them to reveal
the value of org-mode-hook, and they presented this as the default
value of org-mode-hook once Org was loaded:

=
'(org-mode-hook
   (quote
(#[0 "\300\301\302\303\304$\207"
 [add-hook change-major-mode-hook org-show-block-all append local]
 5]
 #[0 "\300\301\302\303\304$\207"
 [add-hook change-major-mode-hook org-babel-show-result-all
append local]
 5]
 org-babel-result-hide-spec org-babel-hide-all-hashes)))
=

Going down the rabbit hole, I discovered many places in Org source
where lambdas were added to org-mode-hook.

I propose to replace such lamba functions with named functions.
Here's an example of diff on maint branch, after making one such change:

=
diff --git a/lisp/org.el b/lisp/org.el
index 2cc9b6a1c..9f28502d4 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -7429,10 +7429,10 @@ a block.  Return a non-nil value when toggling
is successful."
   (when (eq (overlay-get ov 'invisible) 'org-hide-block)
 (delete-overlay ov

-;; Remove overlays when changing major mode
-(add-hook 'org-mode-hook
-  (lambda () (add-hook 'change-major-mode-hook
-   'org-show-block-all 'append 'local)))
+(defun org--unfold-all-blocks-on-major-mode-change ()
+  "Remove overlays when changing major mode."
+  (add-hook 'change-major-mode-hook #'org-show-block-all 'append 'local))
+(add-hook 'org-mode-hook #'org--unfold-all-blocks-on-major-mode-change)

 ;;; Org-goto
 =

If there is no objection to this, I can fix this everywhere in maint,
and then merge that into master.

Comments?


--
Kaushal Modi

[0]: 
https://www.reddit.com/r/emacs/comments/9l1aji/org_mode_hooks_dont_work/e73awsc/



Re: [O] Section on #+include keyword is missing quite some info in the org-manual.org

2018-10-04 Thread Kaushal Modi
On Mon, Oct 1, 2018 at 3:25 PM Kaushal Modi  wrote:

> I was thinking of adding cindices like the ones you added for header
> arguments.
>
> #+cindex: @samp{minlevel}, include
> #+cindex: @samp{lines}, include
> .. etc.
>
> Would that be OK?
>

I went ahead as this wasn't a major edit, and committed this in
https://code.orgmode.org/bzg/org-mode/commit/5abfdeeb8f72dfc2db324e8e731f4e16f2b54bea
.


Re: [O] ox-hugo-like "DWIM" cope for other exporters?

2018-10-02 Thread Kaushal Modi
On Sat, Sep 29, 2018 at 8:23 PM Thomas S. Dye  wrote:

> Aloha Matt,
>
> I've often wished LaTeX export had this capability.  I'd certainly be
> happy if this were a feature of all the exporters.
>

Hello Tom, Matt,

I can work on a DWIM scope that's generic. For ox-hugo, the criteria for
the start of export scope is simple: EXPORT_FILE_NAME must not be "". I
believe this should apply to other exporter backends too. (I needed, that
criteria can be made configurable too).

@Nicolas: If this another scope can be baked into the existing exporters in
Org source, I can get working on it.


Re: [O] Concatenating Org property values from parent subtrees

2018-10-01 Thread Kaushal Modi
On Mon, Oct 1, 2018 at 11:50 AM Ihor Radchenko  wrote:

> Hi,
>
> Check out the following code:
>
> 
> (defvar org-concatenated-properties '("AA")
>   "A list of property names (strings), which should be computed via
> concatenation with the parent properties.")
>
> (define-advice org-entry-get (:around (oldfun pom property 
> inherit literal-nil) concatenate-parents-maybe)
>

Hello Ihor,

That code is perfect!

I was able to get what I want with minor refactoring. Thanks!

Refactored code:

=
(defvar org-concatenated-properties '("AA")
  "List of property names whose values are allowed to be concatenated.
The list is of type '(PROP1 PROP2 ..) where each element is a string.")

(defvar org-property-concat-string "/"
  "String use to concat the `org-concatenated-properties' properties.")

(defun org-get-parent-property (property inherit literal-nil)
  "Get the value of PROPERTY from the parent relative to current point."
  (org-with-wide-buffer
   (if (org-up-heading-safe)
   (or (org-entry-get nil property inherit literal-nil) "")
 "")))

(defun org/advice-concatenate-properties-maybe (orig-fun  args)
  "Concatenate an Org Property value with its inherited value.
The concatenation happens only if the Org Property is in
`org-concatenated-properties' list."
  (let* ((value-orig (apply orig-fun args))
 (property (nth 1 args))
 (dont-concat (not (member property org-concatenated-properties
;; (message "dbg: args:%S value-orig:%S property:%S" args value-orig
property)
(if dont-concat
value-orig
  (let* ((pom (nth 0 args))
 (inherit (nth 2 args))
 (literal-nil (nth 3 args))
 (value-here-no-inherit (apply orig-fun `(,pom ,property nil
,literal-nil)))
 (value-parent (apply #'org-get-parent-property `(,property
,inherit ,literal-nil
;; (message "dbg advice: value-here-no-inherit: %S"
value-here-no-inherit)
(if value-here-no-inherit
(format "%s%s%s"
value-parent
(if (org-string-nw-p value-parent)
org-property-concat-string
  "")
value-orig)
  value-parent)
(advice-add 'org-entry-get :around
#'org/advice-concatenate-properties-maybe)
;; (advice-remove 'org-entry-get #'org/advice-concatenate-properties-maybe)
=

Example Org file:

=

* heading 1
:PROPERTIES:
:FOO:  abc
:END:

asdf
** heading 1
:PROPERTIES:
:FOO: def
:AA: pqr
:END:
*** heading 2
:PROPERTIES:
:FOO: 123
:AA: 456
:END:
 heading 3
=


Re: [O] Section on #+include keyword is missing quite some info in the org-manual.org

2018-10-01 Thread Kaushal Modi
On Wed, Sep 26, 2018 at 6:47 AM Nicolas Goaziou 
wrote:

>
> This is not intentional. Could you re-introduce the latest revision of
> that section?
>

I was just setting out to fix this in the manual, but I see that you
already did this :)

I was thinking of adding cindices like the ones you added for header
arguments.

#+cindex: @samp{minlevel}, include
#+cindex: @samp{lines}, include
.. etc.

Would that be OK?


Re: [O] Concatenating Org property values from parent subtrees

2018-09-29 Thread Kaushal Modi
On Sat, Sep 29, 2018 at 2:39 PM Michael Welle  wrote:

>
> I asked something similar earlier this year (concatenating compiler
> flags given as header-args property, used for linking against different
> libs in different sections of the Org file). I ended with a function
> that grabs the current property value and returns the value concatenated
> with new value. That function can be used as a 'property value'. That's
> not a nice and bullet proof solution, but works good enough to me to
> generate the solutions to the psets for the lecture.
>

Please share it if you don't mind. I plan to use it or its derivative in
ox-hugo. The property is planned to be a path property, and with nested
property values of "a","b" and "c", which I want to parse as "a/b/c".


Re: [O] [PATCH] org-capture: Add a custom to control save target file or not.

2018-09-28 Thread Kaushal Modi
On Fri, Sep 28, 2018 at 4:50 PM Nicolas Goaziou 
wrote:

> Hello,
>
> Kaushal Modi  writes:
>
> > @Nicolas, tumashu: Would love to get your comments.
>
> I don't remember the initial report.
>

Sorry. Here's the original thread:
https://lists.gnu.org/r/emacs-orgmode/2018-04/msg00204.html

My email client shows the whole thread from then to now, so I forgot
pasting that.


> However, saving the capture buffer may be problematic if there was
> unsaved modifications before the capture process. Saving silently the
> file would also save unrelated changes.
>

That's a valid concern, though I see the risk of losing unsaved data as
higher than that.

Also, isn't it easy enough to add a `save-buffer' call in a hook?
>

The problem is that when org-capture-after-finalize-hook is run, the
indirect capture buffer is already killed, and the "context" is back to the
buffer where the M-x org-capture was initiated. So trying to do save-buffer
in that hook simply saves the unrelated buffer.

So another possible solution is:

- Save the capture base buffer to a new key in the org-capture-plist. And
have a org-capture-save-buffer function that save the buffer retrieved from
that key. That fn can then be run in org-capture-after-finalize-hook.

Since I last posted my workaround, I have updated that workaround to this:

(defun modi/org-capture-get-base-buffer ()
  "Stores base buffer of the Org Capture indirect buffer.
 The base buffer is stored in `:base-buffer' entry in
 `org-capture-plist'."
  (let ((base-buffer (buffer-base-buffer (current-buffer
(org-capture-put :base-buffer base-buffer)))
(add-hook 'org-capture-before-finalize-hook
#'modi/org-capture-get-base-buffer)

(defun modi/org-capture-save-base-buffer ()
  "Saves the base buffer of the Org Capture indirect buffer.
 The base buffer is retrieved from the `:base-buffer' entry in
 `org-capture-plist'."
  (when-let ((base-buffer (org-capture-get :base-buffer)))
(with-current-buffer base-buffer
  (save-buffer
(add-hook 'org-capture-after-finalize-hook
#'modi/org-capture-save-base-buffer)

So the proposal is to do modify org-capture-finalize to set that
:base-buffer key so that one doesn't need to customize the
org-capture-before-finalize-hook hook.
And then modi/org-capture-save-base-buffer is basically
org-capture-save-buffer that I mentioned above.

With these changes, a user would need to just do:

(add-hook 'org-capture-after-finalize-hook #'org-capture-save-buffer)


Re: [O] [PATCH] org-capture: Add a custom to control save target file or not.

2018-09-28 Thread Kaushal Modi
On Thu, Sep 27, 2018, 9:33 AM Kaushal Modi  wrote:

>
> Summary:
>
> - Proposal to revert
> https://code.orgmode.org/bzg/org-mode/commit/b4422add3745c26ec3b2e11b8da425844b2e9d3d
> - Use the above advice if you don't want to save buffer during org-capture.
>

@Nicolas, tumashu: Would love to get your comments.

>


Re: [O] Feature proposal: Triple square brackets to create a link to a file AND include the file

2018-09-27 Thread Kaushal Modi
On Thu, Sep 27, 2018 at 11:03 AM Nicolas Goaziou 
wrote:

> As I said, link syntax is inadequate here. I still think what Org
> provides is enough.
>

+1. Also the proposed link syntax is too confusing with the existing and
also for a very corner use case. And then we need to worry about fontifying
those and existing links correctly, adding support to exporters, etc.

Unrelated:

@ST: btw also please update to the latest Org 9.1.x on maint branch or via
Org Elpa. Version 8.x is too old.


Re: [O] [PATCH] org-capture: Add a custom to control save target file or not.

2018-09-27 Thread Kaushal Modi
On Thu, Sep 27, 2018 at 1:47 AM Eric S Fraga  wrote:

> On Wednesday, 26 Sep 2018 at 13:11, Kaushal Modi wrote:
> > I had been wondering for quite some time (about since 5 months :P) why
> > my Org captures have stopped auto-saving.
>
> This has been really annoying me for some time.  Thanks for the code
> you've posted which I will try out.  I use at least 2 instances of Emacs, 1
> for gnus which often leads to capturing notes and tasks and the others for
> writing etc.  Not having an automatic save can lead to problems.
>

I'd suggest reverting that commit.

Removing save-buffer from org-capture-finalize, makes the whole concept of
Org Capture very unsafe (i.e. no guarantee that the captured date will be
saved - unless the finalize hooks workaround is used). It feels like a bit
more extra work is needed to make org capture do the "right thing". If the
hooks are not configured, then there's a mental overhead of having to save
all the capture target buffers manually.

@tumashu  You can easily avoid saving of the capture
target buffers on your phone by adding this to the emacs config just on
your phone:

(defun advice/dont-save-during-org-capture (orig-fun  args)
  "Make `save-buffer' do nothing during `org-capture-finalize'."
  (cl-letf (((symbol-function #'save-buffer)
 (lambda ()
   (message "Skipping `save-buffer' in `org-capture-finalize'")
   nil)))
(apply orig-fun args)))
(advice-add 'org-capture-finalize :around
#'advice/dont-save-during-org-capture)

Above just makes save-buffer to do nothing, but *only* in
org-capture-finalize.

Summary:

- Proposal to revert
https://code.orgmode.org/bzg/org-mode/commit/b4422add3745c26ec3b2e11b8da425844b2e9d3d
- Use the above advice if you don't want to save buffer during org-capture.


[O] Concatenating Org property values from parent subtrees

2018-09-26 Thread Kaushal Modi
Hello,

Is there a way to achieve something like below? See the content in each
nested subtree in the example below.



#+title: Concatenating property values from parent subtrees

* Section
:PROPERTIES
:EXPORT_XYZ: a
:END:
At this point, the value of XYZ property should be "a".
** Sub-section
:PROPERTIES
:EXPORT_XYZ: b
:END:
At this point, the value of XYZ property should be "ab".
*** Sub-sub-section
:PROPERTIES
:EXPORT_XYZ: c
:END:
At this point, the value of XYZ property should be "abc".

--
Kaushal Modi


Re: [O] [PATCH] org-capture: Add a custom to control save target file or not.

2018-09-26 Thread Kaushal Modi
> Also that suggestion to use org-capture-after-finalize-hook does not
> work.. I am investigating to find the right way.

I got the captures to auto-save with the below work-around:

(with-eval-after-load 'org-capture
  (defvar modi/org-capture-base-buffer nil)
  (defun modi/org-capture-before-finalize ()
(let ((base-buffer (buffer-base-buffer (current-buffer
  (setq modi/org-capture-base-buffer base-buffer)))
  (add-hook 'org-capture-before-finalize-hook
#'modi/org-capture-before-finalize)

  (defun modi/org-capture-save-buffer ()
(when modi/org-capture-base-buffer
  (let ((base-buffer-already-open (bufferp modi/org-capture-base-buffer)))
(with-current-buffer modi/org-capture-base-buffer
  (save-buffer
(setq modi/org-capture-base-buffer nil)) ;Reset the buffer name cache
  (add-hook 'org-capture-after-finalize-hook #'modi/org-capture-save-buffer))

tumashu: I am wondering if it's possible to undo this commit and we
can figure out how to prevent file saving during org-capture.



Re: [O] [PATCH] org-capture: Add a custom to control save target file or not.

2018-09-26 Thread Kaushal Modi
> On Sat, Apr 14, 2018 at 5:43 AM tumashu  wrote:
> >
> > Agree this idea,  If user want to save-buffer when capture finish, they can
> > add save-buffer to org-capture-after-finalize-hook  or just type C-x C-s

Also that suggestion to use org-capture-after-finalize-hook does not
work.. I am investigating to find the right way.

The reason is that the (current-buffer) when that hook is run is the
buffer from where the capture is initiated (which usually is not the
capture target buffer).

So running save-buffer in that hook simply saves a buffer unrelated to
the capture (which is not good).



Re: [O] [PATCH] org-capture: Add a custom to control save target file or not.

2018-09-26 Thread Kaushal Modi
On Sat, Apr 14, 2018 at 5:43 AM tumashu  wrote:
>
> At 2018-04-14 15:44:00, "Nicolas Goaziou"  wrote:
> >Hello,
> >
> >tumashu   writes:
> >
> >> I do not know why must save-buffer, may be for  information safe :-)
> >
> >If there is no objection, I suggest to simply remove this call to
> >`save-buffer' instead of introducing a new variable.
> >
>
> Agree this idea,  If user want to save-buffer when capture finish, they can
> add save-buffer to org-capture-after-finalize-hook  or just type C-x C-s

I just stumbled across this today; the relevant commit
https://code.orgmode.org/bzg/org-mode/commit/b4422add3745c26ec3b2e11b8da425844b2e9d3d

I had been wondering for quite some time (about since 5 months :P) why
my Org captures have stopped auto-saving.

Today I started looking into it, and found that commit.

I believe this 1-liner commit is a pretty serious change. Users used
to have they captures safely auto-saved might be in for a surprise. So
just wanted to write this email about it. This commit does not affect
the stable releases of Org so far (9.1). This change is present only
on master as of today.

I'll add a note about this to NEWS on master branch.



[O] Section on #+include keyword is missing quite some info in the org-manual.org

2018-09-25 Thread Kaushal Modi
Hello,

I was visiting the Org manual to verify if I got the :only-contents
parameter of #+include keyword correct, and noticed that that info is
completely missing from that section in the new org-manual.org.

Reverting back to older texi, it is missing pieces like below and much more too:

#+INCLUDE: "./paper.org::#theory" :only-contents t
   @r{Include the body of the heading with the custom id @samp{theory}}
#+INCLUDE: "./paper.org::mytable"  @r{Include named element.}
#+INCLUDE: "./paper.org::*conclusion" :lines 1-20
   @r{Include the first 20 lines of the headline named @samp{conclusion}.}


If this is not intentional (looks like it's not because that feature
works great and I would miss it if it did not), I can commit update to
org-manual.org with that whole section restored from the past.

But I am wondering if things are more serious.. how do we ensure that
the org-manual.org is not missing out the useful info from the old
org.texi?

--
Kaushal Modi



Re: [O] Unable to instrument `org-export-data' using `edebug-defun'

2018-09-22 Thread Kaushal Modi
On Sat, Sep 22, 2018 at 9:00 PM Nicolas Goaziou  wrote:
>
> Hello,
>
> Adrian Bradd  writes:
>
> > Running `edebug-defun' on `org-export-data' produces the following
> > error:
> >
> > edebug-syntax-error: Invalid read syntax: "Failed matching", (
> > ( name ( arg) cl-declarations-or-string def-body))
> >
> > The issue seems to relate to the NAME field of the `cl-macrolet'
> > function, but I'm not sure if this is user error or a bug.
>
> This is probably a bug in the debugger.

Adrian: What emacs version are you using?

Yes, this was a bug in edebug up to Emacs 26.1, but is fixed on the
emacs master branch.

(I happened to have opened this bug on debbugs and it got resolved:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30348 :))



Re: [O] bug#32722: bug#32722: bug#32722: 26.1; Org-publish depend on non-free platform ?

2018-09-21 Thread Kaushal Modi
On Thu, Sep 20, 2018 at 9:55 PM Adam Porter  wrote:

> 1.  Why not?  I just git-blamed this line in ox-html.el:
>
>   (declare-function htmlize-region "ext:htmlize" (beg end))
>
> It's from February, 2012.  That's 6 and a half years, at least, that
> that code has been present.  Why are we suddenly concerned about it?

I just so happens that someone recently filed this bug report:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=32722.

htmlize.el was living in the Org contrib directory until Aug 2017:

=
commit d0ced98943da0e5851ba1145515db27e939bff08
Author: Bastien 
Date:   Fri Aug 18 09:54:19 2017 +0200

Delete htmlize.el from Org’s contrib directory

* lisp/ox-org.el (org-org-publish-to-org):
* lisp/ox-html.el (org-html-htmlize-generate-css):
(org-html-fontify-code):
* lisp/org-agenda.el (org-agenda-write): Throw an error
requesting the user to install htmlize.el.

* doc/org.texi (Exporting agenda views, Literal examples):
Don’t assume htmlize.el is available.

You need to install it from https://github.com/hniksic/emacs-htmlize

See https://github.com/hniksic/emacs-htmlize/issues/7 for this issue.

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -1746,1 +1747,1 @@
-  (require 'htmlize)
+  (error "Please install htmlize from
https://github.com/hniksic/emacs-htmlize;))
=

That change lived in Org master branch (devel) for a while, then
propagated to Org 9.1 and eventually to Emacs 26.1 release. So users
switching from Emacs 25.3 to 26.1. would see as an abrupt change, when
in fact it's just that htmlize.el got removed from contrib and instead
started being correctly referenced to its source on GitHub.

> 2.  Is Org part of "Emacs core"?  I didn't think that was how "Emacs
> core" was defined, but I may be wrong.  It is officially part of Emacs,
> of course.  So is there a distinction between "part of Emacs" and "Emacs
> core"?

Sorry, please don't quote me on that. By "Emacs core", I meant all
packages that you can get from an Emacs installation without having to
fetch one from internet.

> Are there any other "time bombs"
> in Org that we should be concerned about?

Not that I know of. I think this is the only one.

> a.  That is not the originally stated problem.

Yes, I know. The original problem was GitHub, and it snowballed to
"htmlize cannot be fetched from outside Emacs". It's just so happens
that someone noticed it and filed a bug report. In Emacs 25.3, if
htmlize weren't installed, it would have thrown an error when (require
'htmlize) got executed (or not, if people were using org-plus-contrib
which htmlize was part of, until Aug 2017).

> 4.  I'm certainly in favor of using built-in libraries as much as
> possible.  If htmlfontify is a better or equivalent solution, and
> someone's willing to write the code and ensure there are no regressions,
> that would be great, because it would save users from having to manually
> install other packages to get expected functionality.

+1

> 5.  Having a passing familiarity with the complexity of the Org code
> base, I am concerned about the potential for regressions in
> functionality and usability.  I'm also a bit disappointed to see this
> burden potentially thrust upon Nicolas and other Org maintainers, to
> replace working code that's existed for over 6 years, for little-to-no
> technical reason.  Their time available for working on Org is very
> valuable.

That's my concern too. And I think that it's mainly Nicolas, and in
another thread, he mentioned that he will do this refactoring, but
without an urgency (which makes sense).



Re: [O] bug#32722: bug#32722: bug#32722: 26.1; Org-publish depend on non-free platform ?

2018-09-20 Thread Kaushal Modi
On Thu, Sep 20, 2018, 7:19 PM Adam Porter  wrote:

>
> Why?  What's going on?
>

I kind of get why the rewrite needs to happen. But I also see that this
rewrite is an unfortunate waste of time and resources.

The reason is the same why a core Emacs package wouldn't rely on a non-core
package, no matter how useful or awesome that package might be.

For example, we cannot have a core package, say vc.el rely on hydra.el even
though it's in GNU Elpa. It would have been awesome to see all the vc
actions in the hydra interface, but that cannot happen until hydra.el is
part of the core.

With Org/ox-html, it's the same thing. Ox-html is part of Emacs core. So it
cannot rely on htmlize.el. The author doesn't want to assign the copyright
of the package to FSF. So it cannot be a part of Emacs core (or even GNU
Elpa).

[Captain hindsight: htmlize.el shouldn't have been used in ox-html in the
first place without the author having assigned the copyright to FSF.]

>


[O] bug#32722: bug#32722: bug#32722: 26.1; Org-publish depend on non-free platform ?

2018-09-19 Thread Kaushal Modi
On Tue, Sep 18, 2018 at 6:24 PM Amin Bandali  wrote:
>
> I set up a mirror: https://code.orgmode.org/aminb/emacs-htmlize
>
> Assuming code.orgmode.org uses Gogs' default mirror settings, the
> repo should be automatically synchronized with upstream roughly
> every 8 hours or so.
>
> This way, we'd still be able to point the users to a concrete
> address to get htmlize from, without directly pointing them to a
> proprietary platform.  Further, we're not claiminig copyright or
> maintainership of the repo and we're merely mirroring it on a
> freedom-respecting platform along with Org itself.

I got approval from Hrvoje Nikšić that he was fine with your mirror[0].

So I believe it should be OK reference that mirror repo in ox-html?

[0]: https://github.com/hniksic/emacs-htmlize/issues/23#issuecomment-422946622





Re: [O] bug#32722: bug#32722: bug#32722: bug#32722: 26.1; Org-publish depend on non-free platform ?

2018-09-18 Thread Kaushal Modi
Hello all,

I heard back from htmlize.el author Hrvoje Nikšić in his repo's issue thread[0].

So here's the summary:

- Hrvoje Nikšić does not want to assign the copyright of htmlize to
FSF. So it cannot be part of Emacs, Org mode or even GNU Elpa.
- The package will keep living in its GitHub repo.

1. If user has issues with GitHub's non-free JS:

- Download htmlize directly from
https://raw.githubusercontent.com/hniksic/emacs-htmlize/master/htmlize.el.

2. If user does not want to use htmlize, or want Org mode to suggest
installing it from GitHub, set org-html-htmlize-output-type to nil.

Note that the htmlize.el package by itself is GPLv2, so it is free.

Does this settle the issue?

[0]: https://github.com/hniksic/emacs-htmlize/issues/23



[O] bug#32722: bug#32722: bug#32722: bug#32722: 26.1; Org-publish depend on non-free platform ?

2018-09-18 Thread Kaushal Modi
On Tue, Sep 18, 2018 at 2:53 PM Robert Klein  wrote:

> When the original poster doesn't want to use htmlize, he probably
> should try to export without fontifying source code (I think there's a
> switch, but I'm not sure).

Setting org-html-htmlize-output-type to nil will not prompt the user
to install htmlize. With that setting, code blocks will not be
htmlized, and instead just exported as plain text.





Re: [O] Table column width and HTML export

2018-09-18 Thread Kaushal Modi
On Tue, Sep 18, 2018 at 7:35 AM Martin Dalgaard Villumsen <
mvillum...@health.sdu.dk> wrote:
>
> How do you in org-mode override/identify the column-class for a single
column when you have multiple columns of the same type in the same table?

As I said, you can do everything using CSS and the existing ox-html version.

Here's an example:

=
#+title: Specify widths different for different table columns in HTML export
#+author: Kaushal Modi

#+begin_export html

/* First column */
table.foo td:first-child {
  width: 200px;
}
/* Second column */
table.foo td:nth-child(2) {
  width: auto;
}
/* Last column */
table.foo td:last-child {
  width: 400px;
}

#+end_export

The column widths in below table will stay at default.

|--+--+--|
| Header 1 | Header 2 | Header 3 |
|--+--+--|
| abc  | def  | ghi  |
| jkl  | mno  | pqr  |
| stu  | vwx  | yz   |
|--+--+--|

Below, the left-most column will be 200px wide and the right-most will
be 400px wide. The center column will stay at default width.

#+attr_html: :class foo
|--+--+--|
| Header 1 | Header 2 | Header 3 |
|--+--+--|
| abc  | def  | ghi  |
| jkl  | mno  | pqr  |
| stu  | vwx  | yz   |
|--+--+--|
* CSS References
- https://stackoverflow.com/a/6254367/1219634
- [[https://www.w3schools.com/cssref/sel_element_pluss.asp][CSS --
/element+element/ selector]]
- [[https://www.w3schools.com/cssref/sel_firstchild.asp][CSS --
~:first-child~]]
- [[https://www.w3schools.com/cssref/sel_last-child.asp][CSS --
~:last-child~]]
- [[https://www.w3schools.com/cssref/sel_nth-child.asp][CSS --
~:nth-child()~]]
- [[https://www.w3schools.com/cssref/sel_nth-last-child.asp][CSS --
~:nth-last-child()~]]
=

Screenshot (see below/attached):

[image: image.png]


Re: [O] bug#32722: bug#32722: 26.1; Org-publish depend on non-free platform ?

2018-09-18 Thread Kaushal Modi
On Tue, Sep 18, 2018 at 10:22 AM Nick Dokos  wrote:
> Why is that a problem? What do we gain by doing that? What do we lose by 
> staying put
> on htmlize?
>
> These are not rhetorical questions: I really don't understand the problem.
>
> --
> Nick

I also don't get the problem. The software is free. If people don't
like the non-free JS on GitHub, they can get htmlize.el using a simple
wget or curl from
https://raw.githubusercontent.com/hniksic/emacs-htmlize/master/htmlize.el.

In any case, I have asked the htmlize.el author if he is willing to
assing his copyright to FSF in this GitHub Issue[0] for anyone
interested.

[0]: https://github.com/hniksic/emacs-htmlize/issues/23



Re: [O] Table column width and HTML export

2018-09-18 Thread Kaushal Modi
Hello,

There seems to be quite a bit of confusion.

On Tue, Sep 18, 2018, 6:51 AM Martin Dalgaard Villumsen <
mvillum...@health.sdu.dk> wrote:

> I am not interested in editing the exported HTML file (conflicts the point
> of using org-mode)
>
I did not say that HTML should be edited manually. I said that ox-html
probably needs an update that inserts the col tag with user-specified
col-classes.

>  I can add a class to the  tag with
>
> #+ATTR_HTML: :class my-table
>

Correct. That class won't help here. You need a class that scopes the
individual columns.

>  But I don’t know how to add a new class to  in org-mode; or how to
> define a custom column (one that is now , , ).
>
Right, that needs to be investigated. Most likely, at the moment, we cannot
set individual classes for each column.

> No point in CSS-restyling default class="org-center", class="org-left",
> etc.  … this would affect columns in other tables
>
That's a CSS problem. You can set a unique class for a table using the
attr_html syntax you showed above and then set CSS rules only for that
table using ".my-table td+td" and so on.

The org-* classes you mentioned can be easily overridden or used along with
the new classes, based on how the CSS rules are written.

>


Re: [O] Table column width and HTML export

2018-09-18 Thread Kaushal Modi
On Tue, Sep 18, 2018, 3:38 AM Martin Dalgaard Villumsen <
mvillum...@health.sdu.dk> wrote:

> How do I control the column width when exporting a table to HTML?
>
>
>
> I know how to control the width of the table, but not the width of its
> columns. For example, I want the width of column A to be 2 cm and the width
> of B to be 4 cm:
>
>
>
> |  A |  B |
>
> |+|
>
> | 11 | 12 |
>
> | 21 | 22 |
>
>
>
> Relative settings are also appreciated, A 33% and B 67% of total table
> width.
>
Hello,

This needs to be solved using CSS. See an example here:
https://stackoverflow.com/questions/6253963/table-with-table-layout-fixed-and-how-to-make-one-column-wider

In that two solutions are suggested in the selected answer. You should be
able to implement the first way using the "td+td" CSS rule.

For the second way using the "col" tag, I don't have the computer
accessible right now, to check if ox-html can insert that tag. Even if it
did add that tag, you would need to specify the class string for each
column, and then use CSS to set the width of each column class.

Right now, the first method seems to be the best?/fastest/easiest way
forward.

>


Re: [O] bug#32722: 26.1; Org-publish depend on non-free platform ?

2018-09-13 Thread Kaushal Modi
On Thu, Sep 13, 2018 at 11:28 AM Glenn Morris  wrote:
>
> Emacs already includes htmlfontify, since 23.2.
> Is there some obstacle to Org using that? (bug#7506)

This has been discussed before on the Org mailing list.

>From what I remember, there is not objection to use that instead; it's
just that someone has to work on converting ox-html to use htmlfontify
instead of htmlize.



Re: [O] Emacs mobile org

2018-09-09 Thread Kaushal Modi
On Sun, Sep 9, 2018 at 7:53 PM M. P.  wrote:

> Hello I am running emacs on a mac I have a galaxy s8 android phone. I am
> wanting to sync my phone with emacs on my computer.
> I would prefer not to use a cloud service but instead use
> something like a usb or ther to sync with.
>

So, what is the question? :)

Looking at just "Org" and "Android phone", I can suggest the Orgzly app.

It can sync notes to a directory on your phone, and you can sync that dir
to your computer via USB if you like (I like the Dropbox sync option).
-- 

Kaushal Modi


  1   2   3   4   5   6   7   8   >