Re: [PATCH] Add mode for automatically unhiding emphasis markers in the current region

[Kyle Meyer]

Thanks for the patch, and sorry for the slow reply.

Shankar Rao writes:

> Sorry, I've never submitted a patch before. Looking through this mailing
> list, I see that you're supposed to attach the .patch file to the e-mail,
> so here it is.

Inline is fine as well, though it can take a little more work on the
sender's end to make sure that the patch doesn't get mangled by their
mail client and that the commit message is formatted correctly.

> This patch adds a minor mode that makes emphasis markers be automatically
> unhidden when the point is inside the region of emphasis and then the
> markers are rehidden when the point is moved elsewhere. I posted this on
> /r/orgmode on reddit (
> https://www.reddit.com/r/orgmode/comments/gss1g4/update_i_made_my_own_sbrorgemphasizemode_that/),
> and people there suggested that I submit this here as a patch.

I don't prefer my emphasis markers hidden (i.e. I leave
org-hide-emphasis-markers at nil), so perhaps I'm not the best to judge,
but that does sound like a nice feature.

I'm hoping others will try this out and give their thoughts.

> On Mon, Jun 1, 2020 at 4:14 PM Shankar Rao  wrote:
[...]
>>
>> This code was adapted from prettify-symbols-mode in prog-mode.el
>>
>> I have not yet signed the papers assigning copyright to the FSF.  I sent a
>> request for the papers to ass...@gnu.org, but have not yet received a
>> response.

Are you still waiting for a response?

> Subject: [PATCH] Add mode for automatically unhiding emphasis markers in the
>  current region
[...]
>  lisp/org.el | 98 +++--
>  1 file changed, 87 insertions(+), 11 deletions(-)
>
> diff --git a/lisp/org.el b/lisp/org.el
> index 7ff7ec685..870c5c958 100644

Note that this no longer applies to the current master due to a conflict
with b68090e0b (2020-06-04).  I applied this to b68090e0b^ to try this
out, and it seems to work as advertised.

Here are some comments from an initial read-through.

> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -3644,6 +3644,19 @@ following symbols:
>:type 'boolean
>:safe #'booleanp)
>  
> +(defcustom org-auto-emphasis-unhide-at-point nil
> +  "If non-nil, show the unhide the emphasis markers for the region when 
> point is on it.

s/show the// ?

Also, I find using "region" here (and elsewhere) a little confusing.
Perhaps something like "unhide the emphasis markers for the text at
point" instead?

> +If set to the symbol `right-edge', also unhide the emphasis
> +markers if point is immediately after the emphasized region.  The
> +emphasis markers will be rehidden as soon as point moves away
> +from the region.  If set to nil, the emphasis markers remain
> +hidden even when point is in the region."
> +  :version "25.1"

This can instead be

:package-version '(Org . "9.5")

Emacs can then use customize-package-emacs-version-alist to map to the
Emacs version.

(The next release will be v9.4, but we're in a feature freeze at the
moment.)

> +  :type '(choice (const :tag "Never unhide emphasis markers" nil)

Hmm, I don't see the point of having a nil value.  That already seems
covered by toggling org-auto-emphasis-mode on and off.

I also wonder whether we can get away with not having an option here at
all.  Is one of the below values more likely to be the predominant
preference?

> + (const :tag "Unhide emphasis markers when point is inside" 
> t)
> + (const :tag "Unhide emphasis markers when point is inside 
> or at right edge" right-edge))

IMO these descriptions could be more concise but as clear by dropping
"emphasis markers" from the t and right-edge items.

> +(defvar-local org-auto-emphasis--current-region-bounds nil)
> +
> +(defun org-auto-emphasis--get-prop-as-list (prop)
> +  "Helper function to get org-auto-emphasis properties as a list.
> +If `org-auto-emphasis-unhide-at-point' is set to `t' then return

convention nit: Drop quotes from t.

> +(defun org-auto-emphasis--post-command-hook ()
> +  ;; Rehide emphasis markers for the previous region.
> +  (when (and org-auto-emphasis--current-region-bounds
> +  (or (< (point) (car org-auto-emphasis--current-region-bounds))
> +  (> (point) (cadr org-auto-emphasis--current-region-bounds))
> +  (and (not (eq org-auto-emphasis-unhide-at-point 'right-edge))
> +   (= (point) (cadr 
> org-auto-emphasis--current-region-bounds)
> + (apply #'font-lock-flush org-auto-emphasis--current-region-bounds)
> + (setq org-auto-emphasis--current-region-bounds nil))
> +  ;; Unhide emphasis markers for the current region.
> +  (when-let* ((s (org-auto-emphasis--get-prop-as-list 'org-emph-start))

Our minimum supported Emacs version is 24.3, so we can't rely on
when-let and friends being available.

> +(define-minor-mode org-auto-emphasis-mode
> +  "Toggle Org Auto Emphasis mode.
> +This mode, when enabled, unhides emphasis markers for the region
> +at point, depending on the value of
> +`org-a

Re: Emacs-orgmode Digest, Vol 172, Issue 21

[Ian Garmaise]

Hi,

In this version of the org-mode manual in the current repo, there are three
capture template properties (shown in the source) which are not documented:

:jump-to-captured
:empty-lines-before
:empty-lines-after

I hope that these can be added in time for v. 9.4

Best,

Ian




On Sat, Jun 20, 2020 at 12:02 PM  wrote:

> Send Emacs-orgmode mailing list submissions to
> emacs-orgmode@gnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.gnu.org/mailman/listinfo/emacs-orgmode
> or, via email, send a message with subject or body 'help' to
> emacs-orgmode-requ...@gnu.org
>
> You can reach the person managing the list at
> emacs-orgmode-ow...@gnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Emacs-orgmode digest..."
>
>
> Today's Topics:
>
>1. Re: New mailing list archive at https://orgmode/list/
>   (Eric Abrahamsen)
>2. [FR] Add check for attachments in org-lint (Gustavo Barros)
>3. [Feature request] toggle inline image display only under
>   current subtree (stardiviner)
>4. Re: Get Grades Done: the joys of Org's simple power
>   (Richard Lawrence)
>5. Re: Anyone doing any fancy customizations of source blocks?
>   (Diego Zamboni)
>6. [Manual] missing parameter documentation in the Capturing
>   column view paragraph (Paul Bonaud)
>7. Re: [Manual] missing parameter documentation in the Capturing
>   column view paragraph (Kyle Meyer)
>8. patch: ob-clojure improvements (Ag Ibragimov)
>9. Re: patch: ob-clojure improvements (stardiviner)
>   10. org-mode as a logging target in three easy steps (Meng Weng Wong)
>   11. texinfo manual links not working? (Leo Alekseyev)
>   12. Re: texinfo manual links not working? (Nicolas Goaziou)
>
>
> --
>
> Message: 1
> Date: Fri, 19 Jun 2020 10:37:01 -0700
> From: Eric Abrahamsen 
> To: Eric Wong 
> Cc: Kyle Meyer ,  emacs-orgmode@gnu.org
> Subject: Re: New mailing list archive at https://orgmode/list/
> Message-ID : <
> 875zbn554y@ericabrahamsen.net>
> Content-Type: text/plain; charset="utf-8"
>
> Eric Wong  writes:
>
> > Kyle Meyer  wrote:
> >> Eric Abrahamsen writes:
> >>
> >> > Hey, that works great! It's a bit weird that it still asks for a
> >> > username and password, I wonder if there's any way to skip that. I've
> >> > never dealt with anonymous IMAP before -- is there anything in the
> >> > connection process that explicitly tells us "you don't need to log
> on"?
> >>
> >> The server advertises AUTH=ANONYMOUS as a capability [*], so Gnus could
> >> detect that and send "AUTHENTICATE ANONYMOUS", I _think_.
> >
> > Fwiw, mutt detects AUTH=ANONYMOUS and uses it automatically,
> > so I think it's reasonable for Gnus and others do the same.
>
> Looks like it would be as simple as the attached diff. I have very
> little confidence in my understanding of the potential ramifications,
> though, so I'll open an Emacs bug and see what other people think.
>
> Eric
>
> -- next part --
> A non-text attachment was scrubbed...
> Name: nnimap-anonymous.diff
> Type: text/x-patch
> Size: 1140 bytes
> Desc: not available
> URL: <
> https://lists.gnu.org/archive/html/emacs-orgmode/attachments/20200619/16079c41/attachment.bin
> >
>
> --
>
> Message: 2
> Date: Fri, 19 Jun 2020 15:43:15 -0300
> From: Gustavo Barros 
> To: emacs-orgmode@gnu.org
> Subject: [FR] Add check for attachments in org-lint
> Message-ID: <878sgi522l@gmail.com>
> Content-Type: text/plain; format=flowed
>
> Hi All,
>
> Org 'attachment:' links are essentially file links to local files and,
> while 'org-lint' checks 'file:' links for the existence of the
> corresponding files with `org-lint-link-to-local-file', as far as I can
> tell, the same check is not done for 'attachment:' links.
>
> So, I'd like to kindly suggest that either "attachment" be included as a
> case in `org-lint-link-to-local-file' or that an equivalent check for
> attachments be included in `org-lint'.  I'd be much thankful.
>
> Best,
> Gustavo.
>
>
>
> --
>
> Message: 3
> Date: Sat, 20 Jun 2020 10:25:28 +0800
> From: stardiviner 
> To: Org Mode 
> Subject: [Feature request] toggle inline image display only under
> current subtree
> Message-ID: <87wo42lbhj@gmail.com>
> Content-Type: text/plain
>
>
> For some Org documents which has lots of images, toggle display of all
> inline
> images will suspend Emacs, and use lot of memory. I suggest Org Mode can
> add an
> [C-u] universal prefix detect before [C-c C-x C-v] to only display inline
> images
> under subtree.
>
> WDYT?
>
> --
> [ stardiviner ]
>I try to make every word tell the meaning that I want to express.
>
>Blog: https://stardiviner.github.io/
>IRC(freenode): stardiviner, Matrix: stardiviner
>   

Re: org-mode as a logging target

[Russell Adams]

Take my upvote!

+1

On Sun, Jun 21, 2020 at 09:09:01PM +0200, Diego Zamboni wrote:
> This is actually pretty cool! Thanks for the tip,
> --Diego
>
>
> On Sun, Jun 21, 2020 at 5:39 PM Meng Weng Wong  wrote:
>
> > I've been enjoying a featherweight alternative to log levels, made
> > possible by org-mode.
> >
> > Try this the next time you write a little throwaway command-line utility
> > script:
> >
> > Step 1: Add asterisks to the front of your printf traces.
> >
> > Step 2: Tee your STDOUT / STDERR to a file named log.org
> >
> > Step 3: Open the log file in org-mode.
> >
> > Step 4: Rejoice!
> >
> > Optional: You can tail the logfile with M-x auto-revert-mode.
> >
> > This illustration uses a Github scraper as an example:
> > https://github.com/mengwong/git-scrape
> > https://twitter.com/mengwong/status/1274236595109982208
> >
> > This is no substitute for real structured logging, of course :)
> >
> > That is all.
> >
> >


--
Russell Adamsrlad...@adamsinfoserv.com

PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/

Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: org-mode as a logging target

[Diego Zamboni]

This is actually pretty cool! Thanks for the tip,
--Diego


On Sun, Jun 21, 2020 at 5:39 PM Meng Weng Wong  wrote:

> I've been enjoying a featherweight alternative to log levels, made
> possible by org-mode.
>
> Try this the next time you write a little throwaway command-line utility
> script:
>
> Step 1: Add asterisks to the front of your printf traces.
>
> Step 2: Tee your STDOUT / STDERR to a file named log.org
>
> Step 3: Open the log file in org-mode.
>
> Step 4: Rejoice!
>
> Optional: You can tail the logfile with M-x auto-revert-mode.
>
> This illustration uses a Github scraper as an example:
> https://github.com/mengwong/git-scrape
> https://twitter.com/mengwong/status/1274236595109982208
>
> This is no substitute for real structured logging, of course :)
>
> That is all.
>
>

org-mode as a logging target

[Meng Weng Wong]

I've been enjoying a featherweight alternative to log levels, made possible
by org-mode.

Try this the next time you write a little throwaway command-line utility
script:

Step 1: Add asterisks to the front of your printf traces.

Step 2: Tee your STDOUT / STDERR to a file named log.org

Step 3: Open the log file in org-mode.

Step 4: Rejoice!

Optional: You can tail the logfile with M-x auto-revert-mode.

This illustration uses a Github scraper as an example:
https://github.com/mengwong/git-scrape
https://twitter.com/mengwong/status/1274236595109982208

This is no substitute for real structured logging, of course :)

That is all.

Org Spreadsheet Documentation Suggestion

[Michael Partridge]

Hello,
In the spreadshconfidentendlyeet intro
 under
"Column formulas and field formulas" starting with "Finally, we can add the
row for the means per discipline..." there is no walkthrough and thus a
great teaching opportunity missed.

I take it the writer intended for the reader to imply that we apply a
similar formula using the row notation, and if they need a hint they can
review the 'TBLFM' line. But, I would've liked to have discussion as to:
  1. Why the writer explicitly marked the cells instead of just using
'vmean(@2..@4)'?
  2. How to repeat this formula on the next cell in the row (the previous
methods don't seem to work).

This would complete the tutorial and would have allowed me to jump right
into my task confidently (save the fact that the Calc manual link is
broken).


MCP

Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

[Nicolas Goaziou]

Hello,

Ihor Radchenko  writes:

> I am currently working on org-fold.el. However, I am not sure if it is
> acceptable to move some of the existing functions from org.el to
> org-fold.el.
>
> Specifically, functions from the following sections of org.el might be
> moved to org-fold.el:
>> ;;; Visibility (headlines, blocks, drawers)
>>  Reveal point location
>>  Visibility cycling
>
> Should I do it?

That makes sense, yes.

Note that you can first copy and rename most functions to make the
transition easier. As a second step, we can plug new functions into the
main system.

Regards,
-- 
Nicolas Goaziou

exporting latex table to html as png

[Jeremie Juste]

Hello,

I would like to export the following table as a png in an html page. But
it seams that the latex table requires multiple compilations. I can
achieve this when I export to latex by customizing the
org-latex-pdf-process as follows


(setq org-latex-pdf-process (quote ("texi2dvi --pdf --build=local --verbose 
--batch %f"
"bibtex %b"
"texi2dvi --pdf  --verbose --batch %f"
"texi2dvi --pdf  --verbose --batch %f")))


But it seems that when the table is compiled only once when I export to
html. As a result the table notes end up being badly formatted.

Do you have a way to solve this problem?

Best regards,
Jeremie


* latex preambule
#+LATEX_HEADER:\usepackage[flushleft]{threeparttablex}
#+LATEX_HEADER: \usepackage{dcolumn}
#+LATEX_HEADER:\usepackage{siunitx}
#+LATEX_HEADER:\usepackage{longtable,tabularx,ltablex}
 

* 
 
 \begin{ThreePartTable}
  \sisetup{table-format=-2.3, table-space-text-post=***, 
table-number-alignment=center}
 \keepXColumns
 \begin{TableNotes}\footnotesize
  \item[\hspace{-\fontdimen2\font}]\emph{Note:}   This table reprensents the 
results of the models 1 2 3, 4, 
 on page 12. Standard errors are shown in parenthesis.
 $^{***}p<0.01$, $^{**}p<0.05$, $^*p<0.1$ \end{TableNotes}
 \begin{tabularx}{\textwidth}{l *{6}{c}}
   \toprule
 &Pooled & Ind & Ind+Time & Mundlak &Within\\
   \midrule
  Intercept & 18.60$^{***}$ & 22.25$^{***}$ & 24.08$^{***}$ & -5.55$^{**}$ & 
53.03$^{***}$ \\ 
 & (0.91) & (1.09) & (0.60) & (2.40) & (1.98) \\ 
score & 6.34$^{***}$ & 5.97$^{***}$ & 5.11$^{***}$ & 5.11$^{***}$ & 
5.11$^{***}$ \\ 
 & (0.29) & (0.27) & (0.13) & (0.23) & (0.64) \\ 
$\overline{score_i}$ &  &  &  & 3.72$^{***}$ &  \\ 
 &  &  &  & (0.59) &  \\ 
$\overline{score_t}$ &  &  &  & 5.54$^{***}$ &  \\ 
 &  &  &  & (0.58) &  \\ 
 \midrule 
  N.obs & 100 & 100 & 100 & 100 & 100 \\ 
$R^{2}$ & 0.83 & 0.88 & 0.98 & 0.92 & 0.40 \\ 
$Adj R^2$ & 0.83 & 0.87 & 0.97 & 0.92 & 0.39 \\ 
LogL & -235.71 & -218.37 & -133.63 & -196.29 & -299.50 \\ 
 \bottomrule
 \insertTableNotes
 \end{tabularx}
 \end{ThreePartTable}

Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

[Ihor Radchenko]

> Once done, I think we should move (or copy, first) _all_ folding-related
> functions into a new "org-fold.el" library. Functions and variables
> included there should have a proper "org-fold-" prefix. More on this in
> the detailed report.

I am currently working on org-fold.el. However, I am not sure if it is
acceptable to move some of the existing functions from org.el to
org-fold.el.

Specifically, functions from the following sections of org.el might be
moved to org-fold.el:
> ;;; Visibility (headlines, blocks, drawers)
>  Reveal point location
>  Visibility cycling

Should I do it?

Best,
Ihor

Nicolas Goaziou  writes:

> Hello,
>
> Ihor Radchenko  writes:
>
>> [The patch itself will be provided in the following email]
>
> Thank you! I'll first make some generic remarks, then comment the diff
> in more details.
>
>> I have four more updates from the previous version of the patch:
>>
>> 1. All the code handling modifications in folded drawers/blocks is moved
>>to after-change-function. It works as follows:
>>- if any text is inserted in the middle of hidden region, that text
>>  is also hidden;
>>- if BEGIN/END line of a folded drawer do not match org-drawer-regexp
>>  and org-property-end-re, unfold it; 
>>- if org-property-end-re or new org-outline-regexp-bol is inserted in
>>  the middle of the drawer, unfold it;
>>- the same logic for blocks.
>
> This sounds good, barring a minor error in the regexp for blocks, and
> missing optimizations. More on this in the detailed comments.
>
>> 2. The text property stack is rewritten using char-property-alias-alist.
>>This is faster in comparison with previous approach, which involved
>>modifying all the text properties every timer org-flag-region was
>>called. 
>
> I'll need information about this, as I'm not sure to fully understand
> all the consequences of this. But more importantly, this needs to be
> copiously documented somewhere for future hackers.
>
>> 3. org-toggle-custom-properties-visibility is rewritten using text
>>properties. I also took a freedom to implement a new feature here.
>>Now, setting new `org-custom-properties-hide-emptied-drawers' to
>>non-nil will result in hiding the whole property drawer if it
>>contains only org-custom-properties.
>
> I don't think this is a good idea. AFAIR, we always refused to hide
> completely anything, including empty drawers. The reason is that if the
> drawer is completely hidden, you cannot expand it easily, or even know
> there is one.
>
> In any case, this change shouldn't belong to this patch set, and should
> be discussed separately.
>
>> 4. This patch should work against 1aa095ccf. However, the merge was not
>>trivial here. Recent commits actively used the fact that drawers and
>>outlines are hidden via 'outline invisibility spec, which is not the
>>case in this branch. I am not confident that I did not break anything
>>during the merge, especially 1aa095ccf.
>
> [...]
>
>> Also, I have seen some optimisations making use of the fact that drawers
>> and headlines both use 'outline invisibility spec. This change in the
>> implementation details supposed to improve performance and should not be
>> necessary if this patch is going to be merged. Would it be possible to
>> refrain from abusing this particular implementation detail in the
>> nearest commits on master (unless really necessary)?
>
> To be clear, I didn't intend to make your life miserable.
>
> However, I had to fix regression on drawers visibility before Org 9.4
> release. Also, merging invisibility properties for drawers and outline
> was easier for me. So, I had the opportunity to kill two birds with one
> stone. 
>
> As a reminder, Org 9.4 is about to be released, but Org 9.5 will take
> months to go out. So, even though I hope your changes will land into
> Org, there is no reason for us to refrain from improving (actually
> fixing a regression in) 9.4 release. Hopefully, once 9.4 is out, such
> changes are not expected to happen anymore.
>
> I hope you understand.
>
>> I would like to finalise the current patch and work on other code using
>> overlays separately. This patch is already quite complicated as is. I do
>> not want to introduce even more potential bugs by working on things not
>> directly affected by this version of the patch.
>
> The patch is technically mostly good, but needs more work for
> integration into Org.
>
> First, it includes a few unrelated changes that should be removed (e.g.,
> white space fixes in unrelated parts of the code). Also, as written
> above, the changes about `org-custom-properties-hide-emptied-drawers'
> should be removed for the time being.
>
> Once done, I think we should move (or copy, first) _all_ folding-related
> functions into a new "org-fold.el" library. Functions and variables
> included there should have a proper "org-fold-" prefix. More on this in
> the detailed report.
>
> The functions `org-find-text-pr