Re: Using lexical-binding

[Greg Minshall]

Kyle,

thanks.  i see.  i wondered why the talk was all about agendas.

since, in my (brand new, experimenting) use of
=org-babel-map-src-blocks=, i'm calling a function, and that function is
trying to de-reference, e.g., =beg-block=, i get an error.

it is (or does seem to be) the case that if the macro included all the
valueless =defvars=, a function called from it has access to all those.
i don't know if this would be a useful modification.

cheers, Greg

Re: Using lexical-binding

[Kyle Meyer]

Greg Minshall writes:

> hi.  i just upgraded to
> : Org mode version 9.4.4 (9.4.4-27-gb712b9-elpa @ 
> /home/minshall/.emacs.d/elpa/org-20210315/)
>
> and, have also just started playing with
> (org-babel-map-inline-src-blocks), the documentation for which says
> 
> During evaluation of BODY the following local variables
> are set relative to the currently matched code block.
> ...
> 

Is there a specific error/misbehavior that you're seeing?

The patch in this thread switched only one file, lisp/org-agenda.el,
over to lexical binding.  org-babel-map-inline-src-blocks is in ob-core,
and that file has used lexical binding since 6cefae163 (ob-core: Use
lexical binding, 2016-06-20).

> but, iiuc, that relies on dynamic binding.  so, as =lexical-binding= is
> =t=, i don't have access to those appealing variables.

org-babel-map-inline-src-blocks is a macro, and these variables are
defined in its expansion.  Try:

  (pp-macroexpand-expression
   '(org-babel-map-src-blocks nil
  (message "%d %s %s" beg-block lang body)))

Re: How to jump from one spelling mistake to the next?

[Kyle Meyer]

Samuel Wales writes:

> i wonder why the generic next-error is not used.

Hmm, good question.  Ignoring any historical reasons for why flyspell
does what it does, a quick search on the Emacs lists makes me think at
least one open issue is how to prioritize/combine different next-error
sources:

 * https://lists.gnu.org/archive/html/emacs-devel/2018-04/msg00207.html
   87zi2esn7l@mail.linkov.net

 * https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30674#8
   87a7vkrelc@mail.linkov.net

That's getting a bit off-topic for the Org mode list though...

Re: Using lexical-binding

[Greg Minshall]

> but, iiuc, that relies on dynamic binding.  so, as =lexical-binding= is
> =t=, i don't have access to those appealing variables.

from reading the elisp manual, it seems that one could define those
variables to be "special variables", and, iiuc, one can achieve this by
using a =defvar= without a value, previous to the =let= where values are
assigned.  something like (for just full-block):

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index af2c9912e..a0528bb06 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -1121,6 +1121,7 @@ end-body - point at the end of the body"
 (while (re-search-forward org-babel-src-block-regexp nil t)
   (when (org-babel-active-location-p)
 (goto-char (match-beginning 0))
+(defvar full-block)
 (let ((full-block (match-string 0))
   (beg-block (match-beginning 0))
   (end-block (match-end 0))

i could do a patch in this style, for all these variables.

cheers, Greg

Re: How to jump from one spelling mistake to the next?

[Samuel Wales]

i wonder why the generic next-error is not used.

On 3/19/21, Kyle Meyer  wrote:
> Sharon Kimble writes:
>
>> When I'm writing in org-mode I very often make spelling mistakes which I
>> can go back to later to correct. So how can I jump from one mistake to
>> the next please?
>
> If you have Flyspell mode enabled in the buffer,
> flyspell-goto-next-error (bound to `C-,' by default) will jump to the
> next marked word, cycling around once you've reached the last marked
> word in the buffer.
>
> There's also `M-x ispell', which provides an interface for going through
> misspelled words and presents you with suggestions.
>
> See (info "(emacs)Spelling") for more information.
>
>


-- 
The Kafka Pandemic

Please learn what misopathy is.
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

Re: How to jump from one spelling mistake to the next?

[Kyle Meyer]

Sharon Kimble writes:

> When I'm writing in org-mode I very often make spelling mistakes which I
> can go back to later to correct. So how can I jump from one mistake to
> the next please?

If you have Flyspell mode enabled in the buffer,
flyspell-goto-next-error (bound to `C-,' by default) will jump to the
next marked word, cycling around once you've reached the last marked
word in the buffer.

There's also `M-x ispell', which provides an interface for going through
misspelled words and presents you with suggestions.

See (info "(emacs)Spelling") for more information.

Re: How to jump from one spelling mistake to the next?

[Timothy]

Sharon Kimble  writes:

> So in that example how do I jump, using the keyboard only, from the
> misspelled apples to the misspelled oranges so that I can correct them?

With a package like spell-fu or flyspell you'll be able to find a
command like `spell-fu-goto-previous-error'. Bind that to some
keybinding and there you go :)

--
Timothy

How to jump from one spelling mistake to the next?

[Sharon Kimble]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


When I'm writing in org-mode I very often make spelling mistakes which I
can go back to later to correct. So how can I jump from one mistake to
the next please?

For example -

- --8<---cut here---start->8---
John likes applles but Sarah likes orangies.
- --8<---cut here---end--->8---
  
So in that example how do I jump, using the keyboard only, from the
misspelled apples to the misspelled oranges so that I can correct them?

Thanks
  Sharon.  
- -- 
Debian 10.7, fluxbox 1.3.7, emacs 28.0.50, org 9.4.4
-BEGIN PGP SIGNATURE-

iQJPBAEBCgA5FiEELSc/6QwVBIYugJDbNoGAGQr4g1sFAmBVVysbHGJvdWRpY2Nh
c0Bza2ltYmxlLnBsdXMuY29tAAoJEDaBgBkK+INbDuYP/1mj5JcjTcK9+lxrNveB
AE2AtlU52JgdakCCnFTZ9cIUM3qdLelpP4uZkKUiLkmaqK3va9fD9Bp7DdlsolJy
Z/YbJv8xXSdeXJPXUW0kZMFJlUsMpJClcGELnwv1Vvy1XrEeZR4nz7VaVgOMtGzT
x2bWp+Njv70a/C6hJC0bhQ2JfERGg0A6QM0ihe8kWPrfNoIA9q0vYRxpnex0wzJW
6bn1Jf8e+t/a1sSiKiWwnny6mUv17dJr/H0WXkFcl6Dna80Hy6zyfrElelMSoR//
Jkh0vRKN3wu/N7yWzPgsWB+gSC6J8VoBRZSePvLI8rDAzVu1P4ovepHJeKGpwh7w
Azt1gg4j9Zdr6WikpVfzLKaSnWsLK/IOHuHTF3xWmF9GUygxr3MkE7DtvD43T88j
0InvCK1Ha/pQAE3R8THJAXIzhAc88QSV8WuAlEX7CpHaIpkRFHsCedN16w6Noxlm
jst1AZzaiPHWBtqssuox/kPF3s9w8ZScUjxP57xTNFY0PB3ZRKQCdfQxfC0O0hf1
+lBY9uZVluTfJNPiyJ0rwrOftJx6K65+//QgJf2wO4kBceNG8EPci9fVeV8wE/GN
qYOK3OjeO9Ay7hTnNvv3PcXZoo20hCPUNIW3wLe7I5U5HSPoogE0QoYakLhdKQWw
iwK/WTeQPMWtuvhEqsifbTdS
=+Ws4
-END PGP SIGNATURE-

Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping

[Tim Cross]

Eric S Fraga  writes:

> On Friday, 19 Mar 2021 at 08:58, Tim Cross wrote:
>> I am a little concerned about the expansion and addition of features in
>> org mode when there seems to already be a challenge with respect to
>> maintenance and bug fixing. Personally, I would prefer an org mode which
>> is consistent and reliable over one with large numbers of features that
>> is less stable and slower.
>
> +1 on this.
>
> With respect to the topic at hand, I believe it's the result of the same
> tendency that Excel users have of using spreadsheets (aka tables) for
> everything, something I hate when I'm given some Excel sheet that I need
> to modify and where entries are huge paragraphs.  The UI in Excel is
> horrible for these types of tables.  I would hate to see org go in the
> same direction.
>

Those excel 'workbooks' are the absolute worst. I sometimes wonder if
project managers would be more popular if they hadn't decided to use
that as their primary tool. The UI to navigate through those
spreadsheets is horrible.  

The other problem is that tables with large cells of 'paragraph' like
data are not terribly nice from an accessibility perspective. They can
be difficult to navagate and things like screen readers can find it
difficult to 'render' the content in a sensible manner i.e. where the
spoken representation 'makes sense'.

It has also been stated that the Latex exporter won't be a problem as
tabularx (and other Latex packages) will just handle this. Sadly, I don't think 
it is
that simple. I have used that package a lot over the years and there
have been times I've had to render tables with multiple columns and
rows. While the various latex table like packages do provide a much
better outcome for tables with more complex cell structure, it is rare
that you don't need to do a fair amount of tweaking to actually get good
looking complex tables. Handling a cell with a couple of lines may be
fine, but it is very easy to hit the limits of what the package can
handle without some tweaking. This is where I think things begin to fall
down. My suspicion is that the amount of work needed to make the Latex
exporter handle the majority of common use cases for this new syntax is
much larger and more complex than it seems and getting this to work
reliably and consistently will be extremely difficult. 

We can be pretty certain that if we introduce some additional syntax to
allow for multi-line cells and perhaps multi-row+multi-column cells, if
the exporters do not render good looking output for every use case, bugs
will be reported. I also have no idea how this will impact some of the
other exporters, such as odt, texinfo etc. 

I do think we can probably add additional functionality to make working
with more complex tables in org files somewhat easier from an editing
perspective. I do have some concern over the potential performance
impact, but in general, feel this is probably the easier part of the
challenge. 

> In many cases, I believe that a simple text based database format would
> be more appropriate.  I wonder if the time would be better spent
> providing native support for GNU recutils [1] in org instead.  It could
> even have a table like export...
>

That would be an interesting exercise. However, it does add another
dependency and in some ways breaks the 'everything as text' philosophy
(though I guess the last 'rendering' in the org file is still all text). 

To some extent, discussions like this remind me of the early days of the
web where tables were used as the primary formatting 'tool'. Remember
those horrible web pages which consisted of deeply nested tables? We
learnt pretty quickly what a bad idea that turned out to be.

I wonder if part of the issue here is with the different characteristics
of displays and formatted or printed output. Displays have the property
of being 'infinite' - a row can be as long as you like and a column can
be as high as you like. With the growth in large screens many users now
have windows far wider than the old 80 characters that were standard in
old terminals. This tends to make tables a more appealing 'layout'
facility as you can have a number of columns with multiple rows fitting
on the screen. However, now you have a new problem - how do you map this
very wide structure to a fixed width, relatively narrow, sheet of
paper? 

The advantage of 80 characters was that generally, you could fit that on
a standard sheet of paper. It is also a good width for reading, allowing
you to take in multiple 'blocks' of text at a time. Really wide text can
look ok, but many find such wide text more difficult to read as you have
to scan long lines and cannot easily take in a 'block' at a time.

I think there is probably some very good reasons multi-row cells were
not supported in org mode initially. I suspect the reasons are not
necessarily obvious until you try to implement such support. I could
also be completely wrong and the issues I've seen in dealing with such
tables in 

Re: org-ref / Edit notes problem

[Christian Barthel]

Christian Barthel writes:

> I am using Emacs 27.1 on OpenBSD 6.8 and org-ref
> (20210315.1730).  When I am trying to Edit notes on an existing
> org-ref entry ([f9] Edit Notes), emacs stops working and hangs. 
>
> By some observation, I saw that emacs is consuming a lot of
[..]
> Other observation: when I am starting emacs with "-nw" (no GUI),
> "Edit Notes" seems to work as expected and opens a new file as
> expected. 

OK, I guess I found a solution:  I have had a similar issue with
org-capture were emacs freezed as well.  However, org-capture did
work in xterm and I thought about some weird usage of the X11
clipboard manager.  After doing some more research, I found [1].
According to Daimrod's Blog, the workaround is:

  (setq x-selection-timeout 10)

This seems to work for org-ref as well as org-capture.

[1] https://www.omecha.info/blog/org-capture-freezes-emacs.html
-- 
Christian Barthel 

Re: org-capture-template: table lines including newline of sorts

[TRS-80]

On 2021-03-18 03:38, Uwe Brauer wrote:

I commented out all my templates

So the only entry is

("s" "timeslip" table-line
 (file "/home/oub/timeslips.org")
   ;;   (file "d:/ActiveFiles/timeslips.org")
  "\| %(org-read-date)\| %^{FileName} %i\|
  %^{Narrative} %i\| %^{Time} %i\| %^{Expense} %i"

Timeslips.org is empty.

I mark a line in my org-init file and fire up org-capture using your
template, I insert as file name org-init,
narrative I insert blabla
time I insert 10:00
Expense I insert 10

And I obtain

| Bad template

What do I miss here?


Maybe try a minimal Emacs, just to make sure something else isn't
affecting it?

Cheers,
TRS-80

Re: org-capture-template: table lines including newline of sorts

[TRS-80]

On 2021-03-15 10:14, Uwe Brauer wrote:

Uwe Brauer  writes:



Break up the line however you wish into quoted substrings and
concat them together..?


No entirely sure that you mean by quoted substrings, can you give me
an example, please?


I am not same guy you were replying to, but:

#+begin_src emacs-lisp
  (concat "Add "
  "all "
  "these "
  "strings "
  "together!")
  ;; result:
  "Add all these strings together!"
#+end_src

I use it a lot when:

- things start to get complicated (some regexp)
- I want to maintain lines in source that will match output
- in some other cases, too.

Really helpful!

Cheers,
TRS-80

[PATCH] org.el (org-do-latex-and-related): Fix duplicate 'latex-and-related faces

[Sébastien Miquel]

Hi,

With the current org-do-latex-and-related function, fontification of
a region before a LaTeX fragment repeatedly adds the
'org-latex-and-related face to the fragment.

You can reproduce with an org buffer with the following content.

#+BEGIN_SRC org
Foo
 $a^2 + b^2 = c^2$
#+END_SRC

 - Use (setq org-highlight-latex-and-related '(latex))
 - Write some text at the end of the first line, triggering
   refonfication of the line
 - For each character inserted, the org-latex-and-related face is
   added (as a duplicate) to the fragment, as you can check using
   describe-text-properties.

The attached patch fixes this.

--
Sébastien Miquel

>From ccce24e08b903e0e955a6b22f6c7321851ec5750 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Fri, 19 Mar 2021 16:55:27 +0100
Subject: [PATCH] org.el (org-do-latex-and-related): Fix duplicate 'latex faces

* lisp/org.el (org-do-latex-and-related): Do not add a
'org-latex-and-related face beyond the fontification limit
---
 lisp/org.el | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lisp/org.el b/lisp/org.el
index 4db2dbe04..a0c703630 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5502,6 +5502,8 @@ highlighting was done, nil otherwise."
 	(while (and (< (point) limit)
 		(re-search-forward org-latex-and-related-regexp nil t))
 	  (cond
+   ((>= (match-beginning 0) limit)
+	(throw 'found nil))
 	   ((cl-some (lambda (f)
 		   (memq f '(org-code org-verbatim underline
 	  org-special-keyword)))
-- 
2.30.2

Re: Using lexical-binding

[Greg Minshall]

hi.  i just upgraded to
: Org mode version 9.4.4 (9.4.4-27-gb712b9-elpa @ 
/home/minshall/.emacs.d/elpa/org-20210315/)

and, have also just started playing with
(org-babel-map-inline-src-blocks), the documentation for which says

During evaluation of BODY the following local variables
are set relative to the currently matched code block.
...

but, iiuc, that relies on dynamic binding.  so, as =lexical-binding= is
=t=, i don't have access to those appealing variables.

am i missing something?  or, is this a place where the "API" is no
longer compatible?  should those variables somehow be passed as a
parameter (alist?) to =,@body=?  or, (let ((lexical-binding nil)) ...)?
(if that would work.)

cheers, Greg

Re: [PATCH] Re: Bug: Plain https links with brackets are not recognised [9.4.4 (release_9.4.4-625-g763c7a @ /home/yantar92/.emacs.d/straight/build/org/)]

[Ihor Radchenko]

Maxim Nikulin  writes:

> To be clear, I do not ask for any changes. It is great to have some 
> tests even in the current form. I just have never tried ert before, so I 
> have some questions.

Note that I have no experience with tests since I never did programming
professionally. I wrote the tests in the patch simply by looking at
other examples in the file.

> Am I right that just one failure will be reported if a change in the 
> regexp causes problems with several test inputs? I am afraid, it is 
> rather inconvenient since this tests are rather for quality of 
> heuristics than exact requirements. To find proper balance of accuracy 
> and speed/regexp complexity, it is better to have all failures at once. 
> I am looking up for a feature like EXPECT_EQ (delayed failure) in 
> addition to strict ASSERT_EQ in googletest or at least like 
> TestCase.subTest in puthon unittest. For this particular case even 
> parametrized tests are enough (googletest, pytest).

I cannot find anything like delayed failure in the info node for ERT and
in the source code. There are should, should-not, should-error, and
skip-unless asserts.

> I have tried implement something similar to illustrate my expectations. 
> I think, for experienced lisp programmers the code looks ugly

Using a macro is certainly more efficient than my copy-paste in the
patch :) Though you may probably use more backquoting (see Backquote in
Elisp manual) when writing macros. That would look more readable.

> I do not know if it is possible to implement "might" (in addition to 
> "should") that using restart or some other technique will prevent 
> immediate abandoning of the test but will mark whole test as failed at 
> the end.

It is indeed possible and maybe even welcome in emacs-devel.

> Actually I hope to get response that I am trying to reinvent a wheel and 
> org or emacs has an established way to write tests feeding the same 
> function with list of cases

Well... Example from ERT info page:

 (ert-deftest ert-test-mismatch ()
   (should (eql (cl-mismatch "" "") nil))
   (should (eql (cl-mismatch "" "a") 0))
   (should (eql (cl-mismatch "a" "a") nil))
   (should (eql (cl-mismatch "ab" "a") 1))
   (should (eql (cl-mismatch "Aa" "aA") 0))
   (should (eql (cl-mismatch '(a b c) '(a b d)) 2)))

> ... and to get all failures in a reasonably readable report.

When running ert interactively, things should get a little more
manageable. See Running Tests Interactively node of ERT manual.

Hope it helps.

Best,
Ihor

Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping

[Juan Manuel Macías]

to...@tuxteam.de writes:

> [...] My point was that it probably makes sense to separate concerns
> here.

Yes, that separation is essential. I agree.

> That's right. OTOH, people will try to stretch it in every conceivable
> direction. That's in a way Org's biggest strength (and at the same time
> its biggest weakness :)

Great truth! I always try to take things to the extreme :-D, and I
continue thinking that Org is (among many other things) an excellent
'interface' for LaTeX (maybe the best). But I have to admit that a table
with a lot of complexity is a special case when maybe you have to write
LaTeX code, and get lost between all those & and backslashes, at least
if the goal is the typographic refinement. The greatest power of Org
resides in his lightness and in its chameleon versatility, but his worst
temptation may be to become in a (poor) LaTeX 'translation'.

Best regards,

Juan Manuel 

Re: [PATCH] Re: Bug: Plain https links with brackets are not recognised [9.4.4 (release_9.4.4-625-g763c7a @ /home/yantar92/.emacs.d/straight/build/org/)]

[Ihor Radchenko]

Maxim Nikulin  writes:

> I could not guess how to benchmark font-lock. I have tried to open file 
> (to get everything loaded), kill the buffer,

I usually just use profiler-start/open buffer/profiler-report. However,
there is also https://github.com/Lindydancer/font-lock-profiler for more
fine-grained benchmark. Also, you may instrument org-activate-links with
elp.el (built-in).

> but I see some changes in the buffer after 0.19 is reported (both with 
> and without the patch). However I have not converted bracketed links 
> into plain ones yet. I was going to try if some tricks could improve 
> performance. E.g. I am curious if it will work noticeably faster when no 
> nested parenthesis are allowed, but single ones may be at any position, 
> not necessary at the end.

I am currently looking into somewhat orthogonal approach. Instead of
tweaking individual regexps (there were similar issues with priority
regexp in the past), I am trying to use custom
font-lock-fontify-region-function. Once we avoid fontifying folded text,
startup time drops several times at least. I can see the difference
immediately. It comes at the cost though - the behaviour of some Org API
functions changes. They will not always return fontified text. AFAIK, at
least helm-org and helm-org-ql do reply on such fontification.

> Are changes in white spaces below actually modified lines in your patch 
> intended?

They are generated by aggressive-indent. Since org files mix indentation
styles I keep getting those whitespace changes in my patches. Forgot to
remove this time. Should I?

Best,
Ihor

Re: Sharing variables between source blocks without session

[Eric S Fraga]

On Friday, 19 Mar 2021 at 14:59, Loris Bennett wrote:
> To be honest, I find it is a wee bit confusing that it's
>
>   #+PROPERTY: header-args:sh :var user="loris"
>
> *without* a colon after the language (if I add it, there is not error,
> but the variable is just not set) but
>
>   :PROPERTIES:
>   :header-args:sh: :var user="loris"
>   :END:

When in a property drawer, the name of the property you want to set is
enclosed within a pair of :s.  When in a #+PROPERTY statement, there is
no need for the :s, just the name.  It's not about the language part of
it at all.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-254-g37749c

Re: Sharing variables between source blocks without session

[Loris Bennett]

Eric S Fraga  writes:

> On Friday, 19 Mar 2021 at 07:38, Loris Bennett wrote:
>> However, the restriction to source blocks of a particular language does
>> not seem to work like this, but maybe I have got the syntax wrong
>> (again).
>
> Maybe ;-)
>
> This seems to work for me for a shell:
>
> :PROPERTIES:
> :header-args:sh: :var user="loris"
> :END:

That works for me, too.  The following correctly does not work:

  :PROPERTIES:
  :header-args:R: :var user="loris"
  :END:

  #+begin_src sh
echo user ${user}
  #+end_src

  #+RESULTS:
  : user

To be honest, I find it is a wee bit confusing that it's

  #+PROPERTY: header-args:sh :var user="loris"

*without* a colon after the language (if I add it, there is not error,
but the variable is just not set) but

  :PROPERTIES:
  :header-args:sh: :var user="loris"
  :END:

*with* a colon after the language, but maybe I'm just easily confused
 :-)

Thanks for the help,

Loris
-- 
This signature is currently under construction.

org-ref / Edit notes problem

[Christian Barthel]

Hi,

I am using Emacs 27.1 on OpenBSD 6.8 and org-ref
(20210315.1730).  When I am trying to Edit notes on an existing
org-ref entry ([f9] Edit Notes), emacs stops working and hangs. 

By some observation, I saw that emacs is consuming a lot of
memory and the garbage collector seems to run quite frequently
(see the trace above).  This happens after pressing [f9].

Output top(1)
--8<---cut here---start->8---
$ top
  PID USERNAME PRI NICE  SIZE   RES STATE WAIT  TIMECPU COMMAND
45199 bch   43   -5  273M  307M onproc/1  - 0:13 36.33% emacs-27.1

...

PID USERNAME PRI NICE  SIZE   RES STATE WAIT  TIMECPU COMMAND
45199 bch   47   -5  409M  444M onproc/1  - 0:25 49.27% emacs-27.1
--8<---cut here---end--->8---

The profile-report was generated by pressing [f9] and pressing
C-g a few seconds afterwards.   (emacs will become unresponsive
when waiting longer)

Profile:
--8<---cut here---start->8---
- command-execute  52  51%
 - call-interactively  52  51%
  - funcall-interactively  52  51%
   - org-ref-helm-insert-cite-link 51  50%
- helm-bibtex  48  47%
 - bibtex-completion-candidates30  29%
  - bibtex-completion-parse-bibliography   18  17%
   - parsebib-read-entry   11  10%
- parsebib--find-bibtex-field   9   8%
 - parsebib--parse-value9   8%
  - parsebib--expand-strings7   6%
   - mapcar 7   6%
- #  7   6%
   replace-regexp-in-string 6   5%
  parsebib--looking-at-goto-end 1   0%
- parsebib--match-paren-forward 1   0%
 - parsebib--match-brace-forward1   0%
forward-sexp1   0%
   - bibtex-completion-prepare-entry7   6%
- mapcar3   2%
 - # 3   2%
  - bibtex-completion-find-note-multiple-files  2   1%
 f-directory?   2   1%
  - bibtex-completion-find-note-one-file1   0%
 f-file?1   0%
- bibtex-completion-find-pdf2   1%
 - bibtex-completion-find-pdf-in-library2   1%
  - -first  1   0%
 f-file?1   0%
  - f-join  1   0%
   - -map   1   0%
- mapcar1   0%
 - # 1   0%
f-expand1   0%
  member-ignore-case1   0%
- bibtex-completion-remove-duplicated-fields1   0%
 - cl-remove-duplicates 1   0%
  - cl--delete-duplicates   1   0%
 cl--position   1   0%
  - secure-hash 8   7%
   - select-safe-coding-system  8   7%
  find-coding-systems-region8   7%
  - message 1   0%
   - redisplay_internal (C function)1   0%
- funcall   1   0%
 - # 1   0%
  - gui-backend-selection-exists-p  1   0%
   - apply  1   0%
  #  1   0%
  - bibtex-completion-resolve-crossrefs 1   0%
   - bibtex-completion-make-entry-hash  1   0%
- bibtex-completion-get-value   1   0%
   replace-regexp-in-string 1   0%
 - helm18  17%
  

Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping

[tomas]

On Fri, Mar 19, 2021 at 11:53:14AM +0100, Juan Manuel Macías wrote:
> to...@tuxteam.de writes:
> 
> > For export formats, there could be (yet another) "signal" to convey
> > "new paragraph here" which then is the exporter's job. Perhaps an
> > empty line (as is traditional in TeX) or something else.
> 
> I think that signal would be a good solution within a single line. For
> example, for an emergency a simple macro would suffice, something as:
> 
> #+MACRO: par @@latex:\par{}@@

Yes, something like that. My point was that it probably makes sense to
separate concerns here.

> Anyway, I suspect that Org tables are not originally intended for such a
> 'literary' content :-) ...

That's right. OTOH, people will try to stretch it in every conceivable
direction. That's in a way Org's biggest strength (and at the same time
its biggest weakness :)

> LaTeX tabular(x) environment and Org tables
> have in common that they are plain text, but that’s where the
> similarities end [...]

Rigth. (La)TeX is a typesetting language. Cool things can be done,
but they have a cost.

Cheers
 - t


signature.asc
Description: Digital signature

Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping

[Eric S Fraga]

On Friday, 19 Mar 2021 at 08:58, Tim Cross wrote:
> I am a little concerned about the expansion and addition of features in
> org mode when there seems to already be a challenge with respect to
> maintenance and bug fixing. Personally, I would prefer an org mode which
> is consistent and reliable over one with large numbers of features that
> is less stable and slower.

+1 on this.

With respect to the topic at hand, I believe it's the result of the same
tendency that Excel users have of using spreadsheets (aka tables) for
everything, something I hate when I'm given some Excel sheet that I need
to modify and where entries are huge paragraphs.  The UI in Excel is
horrible for these types of tables.  I would hate to see org go in the
same direction.

In many cases, I believe that a simple text based database format would
be more appropriate.  I wonder if the time would be better spent
providing native support for GNU recutils [1] in org instead.  It could
even have a table like export...

Just my 2¢.  Ignore as you see fit!

eric

Footnotes:
[1]  https://www.gnu.org/software/recutils/

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-254-g37749c

Re: Sharing variables between source blocks without session

[Eric S Fraga]

On Friday, 19 Mar 2021 at 07:38, Loris Bennett wrote:
> However, the restriction to source blocks of a particular language does
> not seem to work like this, but maybe I have got the syntax wrong
> (again).

Maybe ;-)

This seems to work for me for a shell:

:PROPERTIES:
:header-args:sh: :var user="loris"
:END:

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-254-g37749c

Re: [PATCH] Re: Bug: Plain https links with brackets are not recognised [9.4.4 (release_9.4.4-625-g763c7a @ /home/yantar92/.emacs.d/straight/build/org/)]

[Maxim Nikulin]

On 16/03/2021 19:35, Ihor Radchenko wrote:

+;;; Link regexps
+
+(ert-deftest test-ol/plain-link-re ()
+  "Test `org-link-plain-re'."
+  (should
+   (equal
+'("https" "//example.com/qwe()")
+(org-test-with-temp-text
+"(Some text in parenthesis followed by link with brackets 
https://example.com/qwe())"
+  (list (org-element-property :type (org-element-link-parser))
+(org-element-property :path (org-element-link-parser))
+  (should
+   (equal
+'("https" "//doi.org/10.1016/0160-791x(79)90023-x")
+(org-test-with-temp-text
+"https://doi.org/10.1016/0160-791x(79)90023-x"
+  (list (org-element-property :type (org-element-link-parser))
+(org-element-property :path (org-element-link-parser))


To be clear, I do not ask for any changes. It is great to have some 
tests even in the current form. I just have never tried ert before, so I 
have some questions.


Am I right that just one failure will be reported if a change in the 
regexp causes problems with several test inputs? I am afraid, it is 
rather inconvenient since this tests are rather for quality of 
heuristics than exact requirements. To find proper balance of accuracy 
and speed/regexp complexity, it is better to have all failures at once. 
I am looking up for a feature like EXPECT_EQ (delayed failure) in 
addition to strict ASSERT_EQ in googletest or at least like 
TestCase.subTest in puthon unittest. For this particular case even 
parametrized tests are enough (googletest, pytest).


I have tried implement something similar to illustrate my expectations. 
I think, for experienced lisp programmers the code looks ugly


(defmacro test-ol/deftest-parametrized
(prefix func  cases)
  (declare (indent 2))
  (cons
   #'progn
   (mapcar
(lambda (case)
  (pcase-let ((`(,id ,docstring ,expect ,arguments) case))
(let ((test (intern (concat prefix "--" id)))
  (exp (if (and expect (listp expect)) `'(,@expect) expect))
  (args (if (listp arguments) arguments (list arguments
  `(ert-deftest ,test ()
 ,docstring
 (should (equal ,exp ,(cons func args)))
cases)))

(defun test-ol/match-link-plain (text)
  (and (string-match org-link-plain-re text)
   (mapcar (lambda (i) (match-string-no-properties i text))
   ;; Currently there is a useless additional group
   ;; and I think it should cause failure.
;; (number-sequence 1 (- (/ (length (match-data)) 2) 1) 1)
   '(1 2

(test-ol/deftest-parametrized "test-ol/org-link-plain-re"
  test-ol/match-link-plain
  ("sheme-only" "No match without host or path"
   nil "Secure https: connection")
  ("scheme-slashes" "Questionable case with no host or path"
   ("file" "///") "Use file:/// for local files")
  ("simple-link" "Simple link"
   ("https" "//orgmode.org/") "Link https://orgmode.org/ to Org site")
  ("false-match" "Failure example: unexpected match"
   nil "Valid file:///bin/bash link")
  ("failed-match" "Failure example: host-path is too short to match"
   ("https" "a") "file:a")
  ("a-typo" "Failure example: slashes missed in expectation"
   ("http" "www.gnu.org") "http://www.gnu.org/;))

(ert t)

In my opinion, test report is acceptable

FFF...

F test-ol/org-link-plain-re--a-typo
Failure example: slashes missed in expectation
(ert-test-failed
 ((should
   (equal
'("http" "www.gnu.org")
(test-ol/match-link-plain "http://www.gnu.org/;)))
  :form
  (equal
   ("http" "www.gnu.org")
   ("http" "//www.gnu.org/"))
  :value nil :explanation
  (list-elt 1
		(arrays-of-different-length 11 14 "www.gnu.org" "//www.gnu.org/" 
first-mismatch-at 0


F test-ol/org-link-plain-re--failed-match
Failure example: host-path is too short to match
(ert-test-failed
 ((should
   (equal
'("https" "a")
(test-ol/match-link-plain "file:a")))
  :form
  (equal
   ("https" "a")
   nil)
  :value nil :explanation
  (different-types
   ("https" "a")
   nil)))

F test-ol/org-link-plain-re--false-match
Failure example: unexpected match
(ert-test-failed
 ((should
   (equal nil
  (test-ol/match-link-plain "Valid file:///bin/bash link")))
  :form
  (equal nil
 ("file" "///bin/bash"))
  :value nil :explanation
  (different-types nil
   ("file" "///bin/bash"

I do not know if it is possible to implement "might" (in addition to 
"should") that using restart or some other technique will prevent 
immediate abandoning of the test but will mark whole test as failed at 
the end.


Actually I hope to get response that I am trying to reinvent a wheel and 
org or emacs has an established way to write tests feeding the same 
function with list of cases and to get all failures in a reasonably 
readable report.

[PATCH] Improve documentation of #+startup keyword

[Timothy]

Hello all,

I was talking to someone who was finding the behaviour of `#+startup'
confusing, and they managed to work out a table summarising the
behaviour.

I think that this would be a good addition to the manual, and help
clarify the behaviour --- so I've prepared a little patch to the manual.
I notice that there are some `#+cindex' lines lying around but I'm not
quite sure what they do. Please let me know if I should add anything
like that etc.

All the best,
*Timothy*
>From 8ff32dfbf2e14419eb542d58ee39c1545f34354b Mon Sep 17 00:00:00 2001
From: TEC 
Date: Fri, 19 Mar 2021 20:01:03 +0800
Subject: [PATCH] doc/org-manual.org: clarify #+startup behaviour

* doc/org-manual.org: clarify the behaviour that each #+startup option
implies.
---
 doc/org-manual.org | 13 +
 1 file changed, 13 insertions(+)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index e8763ff17..a005cce52 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -598,6 +598,19 @@ *** Initial visibility
   is requested by startup options and =VISIBILITY= properties in
   individual entries.
 
+A summary of each keyword's behaviour may be seen in the table below.
+| #+startup:  | org-startup-folded | VISIBILITY | shows headings | shows body |
+|-++++|
+| overview (or fold)  | t  | x  | lvl1   ||
+| content | 'content   | x  | all||
+| show2levels | 'show2levels   | x  | lvl1-2 ||
+| ... | 'showNlevels   | x  | lvl1-N ||
+| show5levels | 'show5levels   | x  | lvl1-5 ||
+| showall (or nofold) | nil| x  | all| x  |
+| showeverything  | 'showeverything|| all| x  |
+|| 'showeverything|| all| x  |
+
+
 *** Catching invisible edits
 :PROPERTIES:
 :DESCRIPTION: Preventing mistakes when editing invisible parts.
-- 
2.30.1

Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping

[Juan Manuel Macías]

* sorry for the typo. I meant "...n columns x n rows..." 

Juan Manuel Macías  writes:

> Anyway, I suspect that Org tables are not originally intended for such a
> 'literary' content :-) ... LaTeX tabular(x) environment and Org tables
> have in common that they are plain text, but that’s where the
> similarities end. Org tables are visual (close to the WYSIWYG concept),
> which is why they are wonderful when it comes to mere data tables (and n
> files x n rows). The LaTeX tabular environment is crude, it is not
> 'visual' (except for the facilities provided by the editor), and when
> the table becomes large and complex it can be a torture working in
> there... So perhaps (IMHO) the solution to edit a cell in a dedicated
> buffer could be the least traumatic in complex cells, in case one wants
> to avoid going crazy by editing this kind of huge and literary tables in
> LaTeX ;-)

Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping

[Juan Manuel Macías]

to...@tuxteam.de writes:

> For export formats, there could be (yet another) "signal" to convey
> "new paragraph here" which then is the exporter's job. Perhaps an
> empty line (as is traditional in TeX) or something else.

I think that signal would be a good solution within a single line. For
example, for an emergency a simple macro would suffice, something as:

#+MACRO: par @@latex:\par{}@@

Anyway, I suspect that Org tables are not originally intended for such a
'literary' content :-) ... LaTeX tabular(x) environment and Org tables
have in common that they are plain text, but that’s where the
similarities end. Org tables are visual (close to the WYSIWYG concept),
which is why they are wonderful when it comes to mere data tables (and n
files x n rows). The LaTeX tabular environment is crude, it is not
'visual' (except for the facilities provided by the editor), and when
the table becomes large and complex it can be a torture working in
there... So perhaps (IMHO) the solution to edit a cell in a dedicated
buffer could be the least traumatic in complex cells, in case one wants
to avoid going crazy by editing this kind of huge and literary tables in
LaTeX ;-)

Best regards,

Juan Manuel 

Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping

[tomas]

On Fri, Mar 19, 2021 at 10:22:20AM +0100, Juan Manuel Macías wrote:
> to...@tuxteam.de writes:
> 
> > My post was rather a warning that "multi-line" will mean
> > different things to different people.
> 
> Yes I agree. It is not the same as how a table is represented in Org and
> how it should be rendered when exported to some typographic format like
> (let's say) LaTeX [...]

Exactly :-)

> The problem here (IMHO) is a problem of discomfort of edit within Org,
> when the cell has a lot of text and when we are under the 'tyranny' of
> the single line.

I understood that this is your focus. And it's IMHO a good idea to
separate things and solve one at a time.

For export formats, there could be (yet another) "signal" to convey
"new paragraph here" which then is the exporter's job. Perhaps an
empty line (as is traditional in TeX) or something else.

But that's another building site :)

Cheers
 - t


signature.asc
Description: Digital signature

Re: Exam LaTeX class

[Christine Köhn]

Hi Xianwen,

Xianwen Chen (陈贤文) writes:

> Does someone have experiences with the exam LaTeX class: 
> http://www-math.mit.edu/~psh/exam/examdoc.pdf?

Yes, but I haven't useid it with orgmode.

> The next step I'm trying to do, but don't know how, is to ask LaTeX 
> exporter to create two exports to PDF.

> I guess one way is to modify the org-latex-export-to-pdf function, so 
> that when the document class is exam, the exporter first export without 
> solutions, and then export to an other PDF file (such as 
> foo-with_solutions.pdf).

Here is one way to do the latex part. You could pass a jobname to latex.

I have this

\IfEndWith*{\jobname}{withsolution}{%
  \usepackage{todonotes}
  \printanswers
}{\usepackage[disable]{todonotes}}

in a myexam.sty file to switch between modes (with or without solutions
and todo notes) and use it in the latex file with

\usepackage{myexam}

You could add your own latex class to org-latex-classes and add this
line there.

The jobname has to be passed to latex with something like -jobname
withsolution if you want it to be with solutions. I use a Makefile for
this purpose which calls latexmk

latexmk -pdf -pdflatex="pdflatex --interaction=errorstopmode" -use-make

and adds -jobname=$(basename $@) if asked to create a pdf ending with
withsolution.pdf. I can send you the Makefile if you're interested.

To use the jobname from within orgmode, you'll have to change
org-latex-pdf-process to use the jobname if needed. I think one way to
achieve this is to add a new export backend which is derived from latex
(see org-export-define-derived-backend) and which sets
org-latex-pdf-process accordingly (and resets it afterwards).

Hope this helps.

Best,
Christine

Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping

[Juan Manuel Macías]

to...@tuxteam.de writes:

> My post was rather a warning that "multi-line" will mean
> different things to different people.

Yes I agree. It is not the same as how a table is represented in Org and
how it should be rendered when exported to some typographic format like
(let's say) LaTeX. I think also 'multi-line' is a very imprecise concept
for Org tables. If we are talking about a cell whose content is a
paragraph, then for LaTeX it is no problem, with the help of the
tabularx package (in these contexts it is the best solution).

The problem here (IMHO) is a problem of discomfort of edit within Org,
when the cell has a lot of text and when we are under the 'tyranny' of
the single line. Luckily it is not a very extended issue, and the tables
in Org are much easier to view and edit than in LaTeX code, when it
comes to simple cells. What happens is that the LaTeX's `tabular(x)'
environment encompasses many more (typographic) contexts than the
concept of `table' in Org. It is a translation problem between Org and
LaTeX and vice versa...

Best regards,

Juan Manuel 

org-capture-template with changing heading (including a TIMESTAMP)

[Uwe Brauer]

Hi

For an org-capture-template I have a setting of the form

("mg" "Exercicios Annu21: asignados"
table-line (file+headline "~/somefile.org" "Exercicios Annu21: asignados")

However in that file I also want a header of the form 

* Exercicios Annu21: asignados <2021-03-19 vie 09:48>

That is a changing timestamp in the heading. How can I achieve that for
my template?

Thanks

Uwe Brauer 

Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping

[tomas]

On Fri, Mar 19, 2021 at 09:44:48AM +0100, Juan Manuel Macías wrote:
> Hi Tomas,

[...]

> I was writing yesterday some rudimentary code (just a proof of concept)
> and I've made this screencast:
> 
> https://lunotipia.juanmanuelmacias.com/edit-cell-sample-2021-03-19_09.29.17.mp4

Looks nice. And for a heavy table user, it might be useful.

It seems you are in the "table row is a big unstructured text" camp.

For my case, as I said, I'm not a heavy table user anyway.
Opening another window is (to me, at least) so disruptive
that I'd be motivated to find alternatives (I very rarely
use C-c ', org-edit-special for source blocks for the same
reason).

But I can envision people needing that badly.

My post was rather a warning that "multi-line" will mean
different things to different people.

Cheers
 - t


signature.asc
Description: Digital signature

Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping

[Juan Manuel Macías]

Hi Tomas,

 writes:

> If the aim is "just rendering in Org" and "breaks have no special
> meaning" (so each render is allowed to re-flow), then your approach
> makes sense (I think Org table has something like that: you can
> set the column width and shrink/expand the column appropriately.
> Personally, I've found that somewhat awkward, so I don't use it,
> but OTOH I'm not a heavy table user: perhaps that's why).

I was writing yesterday some rudimentary code (just a proof of concept)
and I've made this screencast:

https://lunotipia.juanmanuelmacias.com/edit-cell-sample-2021-03-19_09.29.17.mp4

Best regards,

Juan Manuel

Re: Syntax Proposal: Multi-line Table Cells/Text Wrapping

[tomas]

On Thu, Mar 18, 2021 at 11:41:11PM +0100, Juan Manuel Macías wrote:
> Tim Cross  writes:
> 
> > From watching these discussions in the past, I think the big stumbling
> > block is how easily multi-row columns can be added and maintained in the
> > various export formats [...]

> I don't know if anyone has come up with this other possibility: if the
> problem is (usually) the inconvenience of editing cells with a lot of
> text within an Org document (since when exporting to LaTeX [...]

I think this point is very important: "multi-row" is ambiguous.

Does it mean the rendering in Org?  In someother output format? Are the
row breaks chosen by the user (and thus they have /some/ "meaning") or
are they chosen by some rendering mechanism (word wrap, perhaps
hyphenation)?

> the possibility of editing a cell in a dedicated buffer would be very
> practical here.

If the aim is "just rendering in Org" and "breaks have no special
meaning" (so each render is allowed to re-flow), then your approach
makes sense (I think Org table has something like that: you can
set the column width and shrink/expand the column appropriately.
Personally, I've found that somewhat awkward, so I don't use it,
but OTOH I'm not a heavy table user: perhaps that's why).

Cheers
 - t


signature.asc
Description: Digital signature

Re: Sharing variables between source blocks without session

[Loris Bennett]

Loris Bennett  writes:

> "Cook, Malcolm"  writes:
>
>> Eric S Fraga  writes:
>>>
 On Tuesday, 16 Mar 2021 at 09:56, Loris Bennett wrote:
> How can I avoid having to declare the variable 'user' for both blocks?

 I imagine you could use a property, as in

 #+property: header-args :var user=loris

 or even make it specific for the particular language.

 (untested)
>>>
>>>Thanks for point out using 'header-args;' as property. However, if I do
>>>the following, the variable is unset in the shell script:
>>>
>>>#+properties: header-args :var user=loris
>>>
>>>#+begin_src sh
>>>echo user: ${user}
>>>#+end_src
>>>
>>>#+RESULTS:
>>>: user:
>>>
>>>Is that supposed to work, or am I doing something wrong?
>>
>> I am unfamiliar with using the plural form of property, as you are trying, at
>> buffer-level nor do I see documented possible here:
>> https://orgmode.org/manual/Property-Syntax.html#Property-Syntax
>>
>> try this:
>>
>> #+property: header-args:sh :var user="loris"
>> #+begin_src sh
>>
>> echo user: ${user}
>> #+end_src
>>
>> Important: After adding or modifying the #+property line, you will need to
>> instruct org to "refresh your local setup" which I typically accomplish by
>> positioning the point on that line and typing C-c C-c
>
> This doesn't work for me - there is no error, but I get the same result
> as above, i.e. the variable ${users} is not set.  Does it work for you?  

Sorry, this does work for me.

> What does work for me is using a section property rather than a buffer
> property: 
>
> * Dummy Section
>   :PROPERTIES:
>   :header-args: :R :var user="loris"
>   :END:
>
> #+begin_src sh
>   echo user: ${user}
> #+end_src
>
> #+RESULTS:
> : user: loris
>
> However, the restriction to source blocks of a particular language does
> not seem to work like this, but maybe I have got the syntax wrong
> (again).

Quotes around string variables is the important thing.

>>
>>>
>>>Cheers,
>>>
>>>Loris
>>>
>>>-- 
>>>This signature is currently under construction.
>>>
>
>
-- 
This signature is currently under construction.

Re: Sharing variables between source blocks without session

[Loris Bennett]

Eric S Fraga  writes:

> On Thursday, 18 Mar 2021 at 14:21, Loris Bennett wrote:
>> Thanks for point out using 'header-args;' as property.  However, if I do
>> the following, the variable is unset in the shell script:
>
> Works for me.
>
> Make sure you reload properties by hitting C-c C-c on the property line
> (or some other #+ meta line in the file).  Also, you will need to put
> the value of the user variable in "quotes", i.e. user="loris", for some
> reason.

OK, works for me, too now.  The quotes were the important thing, thanks.

For future me and the future in general, would it be a good idea to add
an example to

  https://orgmode.org/manual/Using-Header-Arguments.html

which illustrates the difference between strings and numbers,
e.g.

#+property: header-args:sh :var user="loris" fails=3 temp=17.1

#+begin_src sh
  echo user ${user}
  echo fails ${fails}
  echo temp ${temp}
#+end_src

#+RESULTS:
| user  | loris |
| fails | 3 |
| temp  |  17.1 |

?

Cheers,

Loris

-- 
This signature is currently under construction.

Re: [FR] Add eldoc support to show cell contents in shrunk table

[Samuel Wales]

just a note about what you are getting yourself into.  there be dragons.

emacs actually provides several mechanisms for help text.  idk the
complete list.  perhaps some have done it de novo with timers.

they have different actual [i've seen them] or possible characteristics:

- some being annoying because of subtle showing too much or not enough
issues [like they show even if you did not move the pointer or cursor
into the relevant area]
- possible interactions with scrolling with pointer or cursor over
stuff that flies by
- some working for text cursor but not mouse pointer or vice-versa or
not controllable [kind of a dealbreaker]

i have notes like these scribbles and had to give up trying to figure it out:

;; fixme currently
;;   mouse ignores tooltip delays for things it works for
;; that is maybe help-echo dunno
;;   mouse ignores my eldoc thing for org tses
;; mode is off, which i think for some reason works for mouse
;; still to put in echo area

that weas referring to tooltip mode i think.

;; fixme why does this not work in either org or elisp?
;;   because there is no help-echo
;;   fixme add help-echo
;; [2017-01-16 Mon 12:48]
;;
;; fixme if i am using help-at-pt-display-when-idle to show
;; links, then put cursor over ts to activate eldoc, then put it
;; over link, the link does not show until i move cursor again.
;; thus, /eldoc breaks help-at-pt-display-when-idle/.
;; * 
[[https://mail.google.com/mail/u/0/h/chu69nhq3y6w/?=176f7fa279b7c934=c][Gmail
- bug#42484: 26.1: org-mode should display value of links in
mini-buffer]]
;; fixme capture buffer point is on a link which is annoying.
;; fixme what did i do before?  see git somewhat before
;; [2021-01-22 Fri 00:32].  perhaps i used eldoc.  perhaps htat
;; will not activate if already on link.

as you can see i wasn't too pleased with the elisp ball of wax in this
particular case.


On 3/18/21, Nicholas Harrison  wrote:
> I'm trying to create an automatic way to see the full contents of an
> org table cell while keeping the table compact. I've discovered
> org-table-shrink and then display-local-help to see the contents, but
> I want this to be done automatically using eldoc. I grabbed and
> modified a function from org-eldoc.el which could be added into
> org-eldoc-documentation-function:
>
> (defun org-eldoc-get-cell-contents ()
>   "Return cell contents if in a shrunken table cell."
>   (let ((case-fold-search t))
> (save-excursion
>   (save-match-data
> (when (org-at-table-p)
>   (display-local-help))
>
> I don't really know what I'm doing since I'm not a developer of Emacs
> or org-mode and straight up using display-local-help doesn't seem
> right to me. I think I have unneeded code in there too. Does anyone
> have a better direction on how to get the cell contents when in an org
> table or corrections to this function?
>
> Nicholas
>
>


-- 
The Kafka Pandemic

Please learn what misopathy is.
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

Re: Sharing variables between source blocks without session

[Loris Bennett]

"Cook, Malcolm"  writes:

> Eric S Fraga  writes:
>>
>>> On Tuesday, 16 Mar 2021 at 09:56, Loris Bennett wrote:
 How can I avoid having to declare the variable 'user' for both blocks?
>>>
>>> I imagine you could use a property, as in
>>>
>>> #+property: header-args :var user=loris
>>>
>>> or even make it specific for the particular language.
>>>
>>> (untested)
>>
>>Thanks for point out using 'header-args;' as property. However, if I do
>>the following, the variable is unset in the shell script:
>>
>>#+properties: header-args :var user=loris
>>
>>#+begin_src sh
>>echo user: ${user}
>>#+end_src
>>
>>#+RESULTS:
>>: user:
>>
>>Is that supposed to work, or am I doing something wrong?
>
> I am unfamiliar with using the plural form of property, as you are trying, at 
> buffer-level nor do I see  documented possible here:
> https://orgmode.org/manual/Property-Syntax.html#Property-Syntax
>
> try this:
>
> #+property: header-args:sh :var user="loris"
> #+begin_src sh
>
> echo user: ${user}
> #+end_src
>
> Important: After adding or modifying the #+property line, you will need to 
> instruct org to "refresh your local setup" which I typically accomplish by 
> positioning the point on that line and typing C-c C-c

This doesn't work for me - there is no error, but I get the same result
as above, i.e. the variable ${users} is not set.  Does it work for you?  

What does work for me is using a section property rather than a buffer
property: 

* Dummy Section
  :PROPERTIES:
  :header-args: :R :var user="loris"
  :END:

#+begin_src sh
  echo user: ${user}
#+end_src

#+RESULTS:
: user: loris

However, the restriction to source blocks of a particular language does
not seem to work like this, but maybe I have got the syntax wrong
(again).

>
>>
>>Cheers,
>>
>>Loris
>>
>>-- 
>>This signature is currently under construction.
>>

[FR] Add eldoc support to show cell contents in shrunk table

[Nicholas Harrison]

I'm trying to create an automatic way to see the full contents of an
org table cell while keeping the table compact. I've discovered
org-table-shrink and then display-local-help to see the contents, but
I want this to be done automatically using eldoc. I grabbed and
modified a function from org-eldoc.el which could be added into
org-eldoc-documentation-function:

(defun org-eldoc-get-cell-contents ()
  "Return cell contents if in a shrunken table cell."
  (let ((case-fold-search t))
(save-excursion
  (save-match-data
(when (org-at-table-p)
  (display-local-help))

I don't really know what I'm doing since I'm not a developer of Emacs
or org-mode and straight up using display-local-help doesn't seem
right to me. I think I have unneeded code in there too. Does anyone
have a better direction on how to get the cell contents when in an org
table or corrections to this function?

Nicholas