Re: Fixing the automatic generation of Tex info node names

[Ihor Radchenko]

Philip Kaludercic  writes:

> Would you happen to know what the issue is?  As I said, the documents
> appear to render just as expected in my case, but it might just be due
> to the version or because I didn't hit some specific edge-case.

The link I shared is all I know. Apparently, using some symbols in node
names is discouraged by texinfo manual exactly because it can break some
edge cases. The recommendation is replacing those symbols with texinfo
commands, which is less discouraged.

Probably, the right way to approach this issue is using texinfo commands
to insert [.,:] and also issuing a warning during export.

Best,
Ihor

Re: [BUG] Off-by-one error in width of Agenda window?

[Ihor Radchenko]

"N. Jackson"  writes:

> It turns out there is already an Emacs bug for this (Bug 19395:
> Setting left fringe to 0 messes up window-width
> (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19395)).
>
> My understanding of the discussion is that the bug is caused by
> window-width including in its return value the width of the column
> reserved for the continuation glyph (which column exists when one or
> both of the fringes is/are turned off), so window-width over-reports
> the available width of the window in this case.

Thanks a lot for the detailed analysis!

> The bug hasn't been closed, but IIUC it has been "fixed" by changing
> the documentation of window-width to indicate the limitation. The
> latter part of the bug thread is a discussion and development of the
> function window-max-chars-per-line.
>
> It seems that Org maybe should be using window-max-chars-per-line
> rather than window-width.
>
> [Unfortunately w-m-c-p-l is not a drop in replacement for
> window-width; it doesn't just fix the continuation glyph column
> "bug", but it also adds additional functionality and has a different
> signature.]

Could you elaborate why window-max-chars-per-line cannot be used instead
of window-width by Org? It appears to be strictly more accurate.

Best,
Ihor

Re: citations: org-cite vs org-ref 3.0

[Bruce D'Arcus]

On Mon, Mar 21, 2022 at 10:06 AM John Kitchin  wrote:
>
> Bruce and I looked into this UI approach in 
> https://github.com/jkitchin/org-ref-cite/issues/9. Bruce and I discussed and 
> worked on this for almost two weeks. There are 70 comments in this issue.
>
> There are opportunities now to annotate completion targets, which you can see 
> in the link above. The annotations are not selectable though during 
> completion, and this implementation was not too fast as I recall.

FWIW, an alternative I was playing with is something like this, which
makes use of the new oc-biblatex styles defcustom:

(defcustom style-select-latex-commands nil
  "Whether to use latex commands for style selection."
  :group 'style
  :type '(boolean))

(defun style-latex-alist ( swap)
  "Return org-cite-biblatex-styles as alist.
By default, each car is the latex command, and the cdr the
org-cite style with variant. With SWAP, they are reversed."
  (let ((raw-styles org-cite-biblatex-styles))
(mapcar
 (lambda (s)
   (let* ((style (elt s 0))
  (variant (elt s 1))
  (command (elt s 2))
  (cstyle (concat style (when variant "/") variant)))
 (if swap
 (cons cstyle command)
 (cons command cstyle
 raw-styles)))

(defun style-select ()
  "Select oc style."
  (let* ((latex-commands style-select-latex-commands)
 (styles
 (if latex-commands (style-latex-alist)
   (style-latex-alist t)))
 (choice
  (completing-read
   (if latex-commands "Biblatex command: "
 "Style: ") styles)))
(cdr
 (if style-select-latex-commands (assoc choice (style-latex-alist))
   (rassoc choice (style-latex-alist))

> You probably should also augment the tooltips like this because you have to 
> be able to tell what a citation format is in the future too, not just at 
> insert time, e.g. suppose you are reading work of a collaborator. It was hard 
> to write, and ambiguous in ways, e.g. what is the export backend you want? 
> The annotations should differ for LaTeX (where you want to see the latex 
> command) vs HTML (where you probably want to see the formatted CSL cite)...

I was thinking it'd be enough to have a tooltip preview of the
citation, and allow the actual preview to be configurable.

Bruce

> We did not surmount these challenges at the time. Maybe others will succeed 
> in this another day.
>
> John
>
> ---
> Professor John Kitchin (he/him/his)
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu
>
>
>
> On Mon, Mar 21, 2022 at 8:42 AM Bruce D'Arcus  wrote:
>>
>> On Mon, Mar 21, 2022 at 8:23 AM John Kitchin  wrote:
>>
>> >> A package could be created, say `org-cite-literal-biblatex' which is just 
>> >> a copy
>> >> of `oc-biblatex.el' with a different default `org-cite-biblatex-styles' 
>> >> and
>> >> `org-cite-biblatex-style-shortcuts' (or just sets those variables in
>> >> `org-cite-biblatex'). As far as I can tell this would provide exactly the
>> >> functionality you say org-cite can’t provide but org-ref does.
>> >
>> >
>> > I wrote this package you suggest in org-ref-cite. In discussions during 
>> > that development, it was clear the preference was on the more abstracted, 
>> > and uniform syntax across backends cite commands in org-cite, and not this 
>> > kind of variant. Of course one can do this. It is not that org-cite can't 
>> > provide it, it is that it doesn't at this time.
>>
>> Just for some broader context on this particular issue.
>>
>> The advantage of the org-cite style/variant design reflected in the
>> included export processors (natbib, biblatex, csl) is that the same
>> styles will mostly generate the same final output.
>>
>> But that portability will only work with those styles and variants.
>>
>> With the new org-cite-biblatex-styles defcustom, however, one can
>> augment or completely replace all those. But if you care about that
>> portability, you'd want to be aware of this, and think about it.
>>
>> So per Timothy's point, you actually don't even need a new processor
>> for biblatex if you want to include all the extensive list of biblatex
>> commands.
>>
>> Natbib AFAIK is already fully covered.
>>
>> There's another POV on this though:
>>
>> If one doesn't like to see the org-cite styles, because of familiarity
>> with LaTeX commands etc., I would argue that can be addressed in the
>> style part of an insert processor and/or in an activate processor.
>> E.g. I would argue this is a UI issue; not fundamentally about the
>> styles names.
>>
>> Bruce

[BUG] org-screenshot cl-lib function name errors [9.5.2 (9.5.2-gbebf0b @ /home/jds6696/.emacs.d/straight/build/org/)]

[Justin Silverman]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See



Your bug report will be posted to the Org mailing list.


I started getting errors in the org-screenshot library.

Errors such as void function incf or plusp. I was able to fix them by adding 
(require 'cl-lib) and changing incf -> cl-incf and plusp -> cl-plusp

Best,
Justin

Emacs  : GNU Emacs 28.1.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, 
cairo version 1.17.6)
 of 2022-04-18
Package: Org mode version 9.5.2 (9.5.2-gbebf0b @ 
/home/jds6696/.emacs.d/straight/build/org/)

current state:
`'
(setq
 org-msg-attached-file-reference "see[  \n]\\(?:the[\n]\\)?\\(?:\\w+[   
\n]\\)\\{0,3\\}\\(?:attached\\|enclosed\\)\\|(\\(?:attached\\|enclosed\\))\\|\\(?:attached\\|enclosed\\)[
   \n]\\(?:for\\|is\\)[\n]"
 org-link-elisp-confirm-function 'yes-or-no-p
 org-directory "~/Dropbox/org"
 org-after-refile-insert-hook '(org-gcal--refile-post)
 org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 "\n\n(fn 
ENTRY)"]
 org-agenda-custom-commands '(("d" "Custom Day View"
   ((agenda ""
 ((org-agenda-span 'day)
  (org-agenda-skip-function
   '(lambda nil (interactive) (skip-tag 
"mail")))
  )
 )
(todo "NEXT"
 ((org-agenda-sorting-strategy
   `(priority-down effort-down))
  (org-agenda-overriding-header "Next")
  (org-agenda-skip-function
   '(org-agenda-skip-entry-if 'timestamp))
  )
 )
(agenda ""
 ((org-agenda-span 'day)
  (org-agenda-overriding-header "Mail")
  (org-agenda-format-date "")
  (org-agenda-skip-function
   '(lambda nil (interactive) (skip-not-tag 
"mail")))
  )
 )
(tags-todo "REFILE"
 ((org-agenda-overriding-header "To Refile")
  (org-tags-match-list-sublevels nil))
 )
)
   )
  )
 org-agenda-skip-scheduled-if-done t
 org-agenda-files '("~/Dropbox/org/GTAM_hours.org" "~/Dropbox/org/cal-gmail.org"
"~/Dropbox/org/cal-psu.org" "~/Dropbox/org/calendar.org"
"~/Dropbox/org/inbox.org" "~/Dropbox/org/inbox_mobile.org"
"~/Dropbox/org/mail.org" 
"~/Dropbox/org/meetings_anarres.org"
"~/Dropbox/org/meetings_psu.org" "~/Dropbox/org/notes.org"
"~/Dropbox/org/tasks.org")
 org-capture-templates '(("#" "used by gnus-icalendar-org" entry
  (file+olp "~/Dropbox/org/calendar.org" "Calendar") 
"%i"
  :immediate-finish t)
 ("t" "todo")
 ("ta" "todo with attachment" entry
  (file "~/Dropbox/org/inbox.org") "* TODO %?\n %U\n 
%a")
 ("te" "todo tweaks" entry
  (file+headline "~/Dropbox/org/tasks.org" "Emacs")
  "* TODO %? :TWEAKS:\n %U")
 ("tt" "plain todo" entry (file 
"~/Dropbox/org/inbox.org")
  "* TODO %?\n %U")
 ("m" "meetings")
 ("ma" "meeting anarres" entry
  (file "~/Dropbox/org/meetings_anarres.org")
  "* MEETING with %? :MEETING:\n %U" :jump-to-captured 
t)
 ("mp" "meeting psu" entry
  (file "~/Dropbox/org/meetings_psu.org")
  "* MEETING with %? :MEETING:\n %U" :jump-to-captured 
t)
 ("mP" "meeting specific person")
 ("mPm" "meeting Michelle" entry
  (file "~/Dropbox/org/meetings_psu.org")
  "* MEETING with Michelle :MEETING:w_michelle:\n  
%U\n** TRAM :p_tram:\n** Bacteremia :p_bacteremia:\n" :jump-to-captured t)
 ("mPd" "meeting DIHI" entry
  (file "~/Dropbox/org/meetings_psu.org")
  "* MEETING with DIHI 
:MEETING:w_michelle:p_bacteremia:\n  

Re: Some feature requests/questions

[Eric S Fraga]

Hi Philip,

some quick comments on two of your requests:

On Tuesday, 19 Apr 2022 at 15:49, Philip Kaludercic wrote:

> 3. Related to the previous point, is there a way to configure capture
>templates /in/ org files?  That would make it easier to dynamically
>add notes, without having to do so centrally, in my configuration
>file.

You can define local variables in files and directories.  Check out the
info manual,

[[info:emacs#Specifying File Variables][emacs#Specifying File Variables]]

> 4. Limiting until when events may repeat, without having to duplicate
>timestamps manually (or via `org-clone-subtree-with-time-shift').
>Better yet being able to do so for an entire subtree/file, and have
>the property inherit itself.

You can use Emacs diary s-expressions to specify ranges of dates in org:

[[info:emacs#Special Diary Entries][emacs#Special Diary Entries]]

-- 
: Eric S Fraga, with org release_9.5.2-426-gf6813d in Emacs 29.0.50

Some feature requests/questions

[Philip Kaludercic]

Hi,

I was wondering if someone could help me out to solve these annoyances I
have been having with Org:

1. Most things I would like to clock are related to Emacs, but I often
   forget to check my agenda first, clock in, then clock out.  Is there
   some way I can automatically manage clocking when I enter a
   directory/kill the last buffer?

2. Capturing is configured by describing what keys should do via
   `org-capture-templates'.  Is there some way to use bookmark-like
   strings and completing-read?

3. Related to the previous point, is there a way to configure capture
   templates /in/ org files?  That would make it easier to dynamically
   add notes, without having to do so centrally, in my configuration
   file.

4. Limiting until when events may repeat, without having to duplicate
   timestamps manually (or via `org-clone-subtree-with-time-shift').
   Better yet being able to do so for an entire subtree/file, and have
   the property inherit itself.

All of these issues I have encountered by trying to use Org for the last
few years at University, managing courses, notes, assignment due dates,
appointments, etc.  The friction that these issues cause often have me
become sloppy after a while, which defeats the entire purpose.

I have little experience with the Org codebase, but would be interested
in helping to implement these features, in so far they don't just exist
and I haven't found out about them.

-- 
Philip Kaludercic

Re: [BUG] Off-by-one error in width of Agenda window?

[N. Jackson]

At 11:16 +0800 on Tuesday 2022-04-19, Ihor Radchenko wrote:
>
> Thanks! I was able to reproduce the problem.
>
> I believe that it is not Org's fault. Org is trusting (window-width)
> return value to calculate the width of the separator line. However, with
> you settings, (window-width) apparently returns a wrong value. You can
> see it yourself by running (insert (make-string (window-width) ?=)) in
> scratch buffer with and without your fringe settings.
>
> Probably, you should report this as Emacs bug.

It turns out there is already an Emacs bug for this (Bug 19395:
Setting left fringe to 0 messes up window-width
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19395)).

My understanding of the discussion is that the bug is caused by
window-width including in its return value the width of the column
reserved for the continuation glyph (which column exists when one or
both of the fringes is/are turned off), so window-width over-reports
the available width of the window in this case.

The bug hasn't been closed, but IIUC it has been "fixed" by changing
the documentation of window-width to indicate the limitation. The
latter part of the bug thread is a discussion and development of the
function window-max-chars-per-line.

It seems that Org maybe should be using window-max-chars-per-line
rather than window-width.

[Unfortunately w-m-c-p-l is not a drop in replacement for
window-width; it doesn't just fix the continuation glyph column
"bug", but it also adds additional functionality and has a different
signature.]

Regards,
N.

P.S. I learnt in my reading that turning off one of my fringes gains
me nothing because Emacs then turns around an puts an empty column
on the right side of my window to potentially display a continuation
glyph. So, to work around this Agenda bug temporarily I have turned
on both fringes.

Re: Bug: Order of drawers is important [9.1.9 (release_9.1.9-65-g5e4542 @ /usr/share/emacs/26.3/lisp/org/)]

[Olaf Dietsche]

Ihor Radchenko  writes:

> Olaf Dietsche  writes:
>
>> This seems much more useful than the non-working "repair" of
>> org-set-property.
>
> FYI, even repair is no longer there in the latest Org release.
> In future, I recommend running org-lint. It is usually able to catch
> this and similar problems in Org files regardless of Org version.
>
> Note that the latest stable Org release is 9.5.2. Org 9.1.9 is 4 years
> old. All the reported bugs are fixed in the current release only.

Thanks again for this hint.

Most of the time my orgmode usage is very basic, mostly taking outline
notes and logging time spent on (sub-)tasks. Insofar, I just to use the
version coming bundled with Ubuntu's Emacs without any problems.

Kind regards, Olaf

Re: Fixing the automatic generation of Tex info node names

[Philip Kaludercic]

Ihor Radchenko  writes:

> Philip Kaludercic  writes:
>
>> For some reason ox-texinfo removes periods from node names.  It seems
>> this is not necessary as info can render these files without any issues,
>> and in certain cases not intended (e.g. I had a node named "Emacs 28.1"
>> and it was abbreviated to "Emacs 281").
>
> According to
> https://www.gnu.org/software/texinfo/manual/texinfo/texinfo.html#Node-Line-Requirements
>
>>> Unfortunately, you cannot reliably use periods, commas, or colons
>>> within a node name; these can confuse the Info reader. Also, a node
>>> name may not start with a left parenthesis preceding a right
>>> parenthesis, as in (not)allowed, since this syntax is used to specify
>>> an external manual. (Perhaps these limitations will be removed some
>>> day.)
>
> Not that we cannot work around this, but we need something different
> than the proposed patch.

Would you happen to know what the issue is?  As I said, the documents
appear to render just as expected in my case, but it might just be due
to the version or because I didn't hit some specific edge-case.

> Best,
> Ihor

-- 
Philip Kaludercic

Re: Fixing the automatic generation of Tex info node names

[Ihor Radchenko]

Philip Kaludercic  writes:

> For some reason ox-texinfo removes periods from node names.  It seems
> this is not necessary as info can render these files without any issues,
> and in certain cases not intended (e.g. I had a node named "Emacs 28.1"
> and it was abbreviated to "Emacs 281").

According to
https://www.gnu.org/software/texinfo/manual/texinfo/texinfo.html#Node-Line-Requirements

>> Unfortunately, you cannot reliably use periods, commas, or colons
>> within a node name; these can confuse the Info reader. Also, a node
>> name may not start with a left parenthesis preceding a right
>> parenthesis, as in (not)allowed, since this syntax is used to specify
>> an external manual. (Perhaps these limitations will be removed some
>> day.)

Not that we cannot work around this, but we need something different
than the proposed patch.

Best,
Ihor

Fixing the automatic generation of Tex info node names

[Philip Kaludercic]

For some reason ox-texinfo removes periods from node names.  It seems
this is not necessary as info can render these files without any issues,
and in certain cases not intended (e.g. I had a node named "Emacs 28.1"
and it was abbreviated to "Emacs 281").

This patch should resolve the issue:

>From f9a8d9738cb118939a8307bf13f63ec5950bd59b Mon Sep 17 00:00:00 2001
From: Philip Kaludercic 
Date: Tue, 19 Apr 2022 12:17:40 +0200
Subject: [PATCH] ox-texinfo: Allow for periods in node names

* ox-texinfo.el (org-texinfo--sanitize-node): Don't remove periods
  from node names.
---
 lisp/ox-texinfo.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/ox-texinfo.el b/lisp/ox-texinfo.el
index a01bb268c..3a2c4791b 100644
--- a/lisp/ox-texinfo.el
+++ b/lisp/ox-texinfo.el
@@ -555,7 +555,7 @@ periods, commas and colons."
(replace-regexp-in-string
 "[ \t]+" " "
 (replace-regexp-in-string
- "[:,.]" ""
+ "[:,]" ""
  (replace-regexp-in-string "\\`(\\(.*?)\\)" "[\\1" title)
 
 (defun org-texinfo--sanitize-title (title info)
-- 
2.30.2


-- 
Philip Kaludercic