Re: [O] mailto link for the #+email keyword: Suppressing backslash and braces "escaping" for latex exports

[H. Dieter Wilhelm]

John Kitchin  writes:

> I posted this on your stack exchange question:
>
> #+latex_class: report
> #+options: author:nil email:nil
> #+latex_header: \author{Some user 
> \thanks{\href{mailto:b...@comp.org}{b...@comp.org}}}

Perfect, thanks a lot John!

Hmm, I'm asking now myself how can I get a mailto link for an html
export as well? ;-)

   Dieter
[...]

l
-- 
Best wishes
H. Dieter Wilhelm
Kelkheim, Germany

Re: [O] Expose value-begin and value-end instead of just value in org-element API

[John Kitchin]

Nicolas Goaziou writes:

> Hello,
>
> John Kitchin  writes:
>
>> +1 on this.
>>
>> I also have some janky code to do things like go to the beginning/end of
>> the value in a src block. Here is my solution to mark the code in a src
>> block.
>>
>> (defun ob-ipython-mark-code ()
>>   "Mark the code in the block."
>>   (interactive)
>>   (org-edit-special)
>>   (let ((p0 (point-min))
>> (p1 (point-max)))
>> (goto-char p0)
>> (org-edit-src-exit)
>> (set-mark (point))
>> (goto-char (+ (point) (- p1 2)
>
> You get the beginning of the code of a source block with
>
>   (org-with-point-at (org-element-property :post-affiliated element)
> (line-beginning-position 2))
>
> and its end with
>
>   (org-with-point-at (org-element-property :end element)
> (line-beginning-position (- (org-element-property :post-blank element
>

Wow. I would not have guessed either one of these! Thanks for sharing
them. Is that documented somewhere? I gather that given something like

#+header: :var a=5
#+name: test
#+BEGIN_SRC ipython

print(a)

#+END_SRC

which parses like (from org-element-context):

(src-block
 (:language "ipython" :switches nil :parameters nil :begin 362 :end 436 
:number-lines nil :preserve-indent nil :retain-labels t :use-labels t 
:label-fmt nil :value "\nprint(a)\n\n" :post-blank 1 :post-affiliated 394 
:header
(":var a=5")
:name "test" :parent nil))

In this:

:begin refers to the point at the beginning of the #+header line.

whereas

:post-affiliated is the point after all the "affiliated" header/name lines, 
i.e. the
beginning of #+BEGIN_SRC.

:end refers to the point where the end of the element is, which may
include blank lines.

:post-blank is the number of blank lines (including lines that are just
spaces) after the element.

is that the right interpretation?

For elements with a :contents-begin where does :post-affiliated come in?


> From there, you can easily construct something that doesn't rely on
> `org-edit-special'.
>
>>> I think it would be preferable to also expose the value by beginning and
>>> ending buffer positions for the following reasons:
>>> - Consistency with elements that expose contents-begin and contents-end.
>
> The point is terminal elements are not consistent with non-terminal
> ones, and should not be.
>
>>> - More powerful. In my evil-org plugin I want to be able to mark the value
>>> property of the org element at point (so the user can do stuff like easily
>>> copy the code of the current code block), but to do so I need the beginning
>>> and ending position in the buffer of "value". The org-element API does
>>> currently not provide clean way to retrieve these positions.
>
> See above. It is quite simple to extract this information from the parse
> tree.

Once you get the idea, maybe, but this approach seems specific to
src-blocks (maybe any block) where there are delimiting lines. It
doesn't work on all elements (which to be fair was not claimed). I think
the OP was interested in something more consistent, which I am
sympathetic to.

Some things aren't clear to me what should happen though, especially in
composite elements like tables and plain lists. E.g. To just select a
table without the affiliated lines, one can use :contents-begin and
:contents-end, once you get the table element (e.g. by walking up the
:parent chain if you are in a cell or row).

In the absence of a single way, maybe there could be a small number of
ways to do this? How many cases do you think there are?

- blocks (which have :value)
- composite elements (which have :contents-begin/end and/or non-nil :parents)
- regular elements (which have :contents-begin/end)

Are there any others?

>
>>> - It's usually more efficient to return the beginning and ending positions
>>> than to retrieve the substring that contains the value, which may require a
>>> large buffer partition to be copied.
>
> Efficiency is a moot point because you still need to store the value of
> the block. If you remove it, the parse tree is no longer an equivalent
> representation of the document.

I can see this argument, but I am still unclear on which elements need a
value, and which don't. For example, src-blocks have a value, but a
paragraph doesn't, nor do items in a plain list, at least from
(org-element-context).

I guess my confusion comes from these being different than what comes
out of (org-element-parse-buffer).

>
> Regards,


--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

[O] Bug: Bulk re-scheduling to a relative offset doesn't work [9.1.6 (9.1.6-48-gfe7619-elpa @ c:/Users/micha/.emacs.d/elpa/org-20180212/)]

[Michael Hoffman]

I previously asked a question about this on emacs-orgmode but it seems 
more likely that this is a bug.


https://lists.gnu.org/archive/html/emacs-orgmode/2018-02/msg00183.html

I am bulk re-scheduling items in an agenda view. I would like all the 
selected items to be re-scheduled to a year later from their current 
scheduled date. The org manual 
 seems to indicate this 
is possible using double plus:


> Schedule all items to a new date. To shift existing schedule dates by
> a fixed number of days, use something starting with double plus at the
> prompt, for example ‘++8d’ or ‘++2w’.

When I try this, however, I always get re-scheduling from the current 
date. I am using Org mode version 9.1.6 (9.1.6-48-gfe7619-elpa). Here's 
how to reproduce:


1. Create minimal.org.el:

(setq debug-on-error t
  debug-on-signal nil
  debug-on-quit nil)
(add-to-list 'load-path "c:/Users/micha/.emacs.d/elpa/org-20180212")

2. emacs.exe -Q -l minimal-org.el

3. Create a test.org buffer:

* TODO Task
  SCHEDULED: <2018-01-01 Mon>

4. Add it to the agenda files list with C-c [.

5. M-x org-agenda RET t results in

Global list of TODO items of type: ALL
Available with ‘N r’: (0)[ALL] (1)TODO (2)DONE
  test:   TODO Task

6. Move down to TODO Task and type m to mark

7. B s (bulk schedule). The minibuffer will state:

(Re)Schedule to Date+time [2018-02-11]: [cursor] => <2018-02-11 Sun>

8. ++1y. The right part of the minibuffer now states

<2019-02-11 Mon>

I expected <2019-01-01 Tue>

9. RET.

The task is now rescheduled to <2019-02-11 Mon> rather than <2019-01-01 
Tue> as initially expected.


Emacs  : GNU Emacs 25.2.1 (x86_64-w64-mingw32)
 of 2017-04-24
Package: Org mode version 9.1.6 (9.1.6-48-gfe7619-elpa @ 
c:/Users/micha/.emacs.d/elpa/org-20180212/)


current state:
==
(setq
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
  org-babel-header-arg-expand)
 org-speed-command-hook '(org-speed-command-activate
  org-babel-speed-command-activate)
 org-occur-hook '(org-first-headline-recenter)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-confirm-shell-link-function 'yes-or-no-p
 org-after-todo-state-change-hook '(org-clock-out-if-current)
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
 org-src-mode-configure-edit-buffer)
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-babel-pre-tangle-hook '(save-buffer)
 org-mode-hook '(#[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-show-block-all
append local]
   5]
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook
org-babel-show-result-all append local]
   5]
 org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-bibtex-headline-format-function #[257 "\300
\236A\207" [:title] 3 
"\n\n(fn ENTRY)"]

 org-archive-hook '(org-attach-archive-delete-maybe)
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
  org-cycle-show-empty-lines
  org-optimize-window-after-visibility-change)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-link-parameters '(("id" :follow org-id-open)
   ("rmail" :follow org-rmail-open :store
org-rmail-store-link)
   ("mhe" :follow org-mhe-open :store
org-mhe-store-link)
   ("irc" :follow org-irc-visit :store
org-irc-store-link)
   ("info" :follow org-info-open :export
org-info-export :store org-info-store-link)
   ("gnus" :follow org-gnus-open :store
org-gnus-store-link)
   ("docview" :follow org-docview-open :export
org-docview-export :store org-docview-store-link)
   ("bibtex" :follow org-bibtex-open :store
org-bibtex-store-link)
   ("bbdb" :follow org-bbdb-open :export
org-bbdb-export :complete org-bbdb-complete-link
:store org-bbdb-store-link)
   ("w3m" :store org-w3m-store-link) ("file+sys")
   ("file+emacs") ("doi" :follow org--open-doi-link)
   ("elisp" :follow org--open-elisp-link)
   ("file" :complete org-file-complete-link)
   ("ftp" :follow
(lambda (path) (browse-url (concat "ftp:" path
   ("help" :follow org--open-help-link)
   ("http" :follow
(lambda (path) (browse-url (concat "http:" path
   ("https" :follow
   

[O] Exploring picolisp

[Lawrence Bottorff]

I'm looking at picolisp -- and wondering how it works, or better, why it
doesn't really work work with babel. First problem, I couldn't get any form
of picolisp to work in Emacs -- until I stopped starting Emacs with

emacsclient -c -a ''

which sets up my daemon first. Got abstruse error -- and it creates a file
called `editor-orig` in `~/.pil` which blocks any further attempts. After
tearing stuff out of my init diaspora for hours, I finally found that a
straight

>emacs &

made picolisp-mode work, otherwise, not. Very weird. But then I see this
 and, yes, picolisp babel seems to
work for all the examples. However, a regular function declaration

#+name: hello
#+begin_src picolisp
(de hello (X)
   (prinl "Hello " X) )
#+end_src

-- goes nowhere. But then C-c C-c in a picolisp code block isn't firing up
a REPL, so where can it go? Nowhere. Lisp, Scheme & Cie. all require a
running REPL that org-mode knows about. And if I just bring up
picolisp-mode with a picolisp file and fire up a REPL, that REPL doesn't
know anything about my org-mode picolisp code blocks.

I don't mean to complain or sound negative, but picolisp as is can't really
be included as a babel language, can it? Maybe it worked once, but doesn't
now?

LB

Re: [O] src-blocks with captions do not respect attr_latex :placement options

[John Kitchin]

Nicolas Goaziou writes:

> Hello,
>
> John Kitchin  writes:
>
>> A block like this:
>>
>> #+attr_latex: :placement [H]
>>
>> #+caption: A test block
>> #+BEGIN_SRC ipython
>>
>> 'hello'
>> #+END_SRC
>>
>> exports to latex as:
>>
>> \begin{listing}[htbp]
>> \begin{minted}[frame=lines,fontsize=\scriptsize,linenos]{ipython}
>> 'hello'
>> \end{minted}
>> \caption{A test block}
>> \end{listing}
>>
>> The root of this is in  org-latex-src-block where (plist-get info
>> :latex-default-figure-position) is being used to specify the
>> placement.
>
> True. LaTeX back-end doesn't handle :placement attribute in source blocks.
>
>> It seems like a sort of easy fix, but requires a couple of changes in the
>> function.
>>
>> I think we could replace all instances of
>>
>> (plist-get info :latex-default-figure-position)
>>
>> with
>>
>> (or (plist-get attributes :placement)
>>(format "[%s]"
>>(plist-get info :latex-default-figure-position)))
>
> Why (format "[%s]" ...)?

That isn't changed from what is already in ox-latex, e.g. line 2367.

>
>> and also replace everything like:
>>
>> \\begin{figure*}[%s]
>>
>> with
>>
>> \\begin{figure*}%s
>>
>> I don't see a way around that unless :latex-default-figure-position is
>> changed from "htbp" to "[htbp]".
>
> I fail to see why this change is needed.

org-latex-default-figure-position is defined as "htbp"

where as :placement is usually defined as "[H]". One has brackets, and
one doesn't. This is reflected in ox-latex too.

For example in this code (line 3219. ox-latex.el)

(or (plist-get attr :placement)
  (format "[%s]" (plist-get info
  :latex-default-figure-position)))

it is implied that :latex-default-figure-position does not have
brackets, but that (plist-get attr :placement) does since it is later
used in line 3259 as:

(format "\\begin{%s}%s\n" float-env placement)

So, it seems like one either has to add [] to the default
org-latex-default-figure-position, or put them in the template, or
change how the :placement value is used. It doesn't seem like we can
have it both ways without testing if there are brackets or not. It also
doesn't seem right to modify org-latex-default-figure-position just to
get float listings to be "[H]" for src blocks.

>
>> Thoughts?
>
> Do you want to propose a patch? The manual would need to be updated
> accordingly.

Do you see another way to solve this?

>
> Regards,


--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

[O] question on org-element-interpret-data and when it works

[John Kitchin]

I am trying to find some ways to programatically modify org-elements that
use fewer regexps and motion commands. It seems like org-dp (
https://github.com/tj64/org-dp) was intended to do that but it is not clear
enough how you might use it, and it also doesn't seem to support
plain-lists yet.

What I imagined happening is that I would get the element to modify as a
data structure, modify the data structure, and replace the old element with
an interpreted version of the modified data structure.

I want to do something like a radio list where only one box can be checked
at a time. Suppose I have this:

#+attr_org: :radio
- [ ] one
- [ ] two
- [ ] three

It gets represented from org-element-context as:

(plain-list
 (:type unordered :begin 579 :end 630 :contents-begin 598 :contents-end 630
:structure
((598 0 "- " nil "[ ]" nil 608)
(608 0 "- " nil "[ ]" nil 618)
(618 0 "- " nil "[ ]" nil 630))
:post-blank 0 :post-affiliated 598 :attr_org
(":radio")
:parent nil))

What I thought I could is something like (here I simulate having point in
the first item):

#+BEGIN_SRC emacs-lisp :results code
(let* ((p 600) ;where current point is
   n
   (data '(plain-list
   (:type unordered :begin 579 :end 630 :contents-begin 598
:contents-end 630 :structure
  ((598 0 "- " nil "[ ]" nil 608)
   (608 0 "- " nil "[ ]" nil 618)
   (618 0 "- " nil "[ ]" nil 630))
  :post-blank 0 :post-affiliated 598 :attr_org
  (":radio")
  :parent nil)))
   (structure (plist-get (cadr data) :structure)))
  (loop for i from 0 for item in structure
do
(if (and (>= p (first item))
(< p (seventh item)))
;; in the item, toggle it
(setf (fifth item) (if (string= "[X]" (fifth item))
   "[ ]"
"[X]"))
  ;; not on the item
  (setf (fifth item) "[ ]")))

  data)
#+END_SRC

Which outputs:

#+RESULTS:
#+BEGIN_SRC emacs-lisp
(plain-list
 (:type unordered :begin 579 :end 630 :contents-begin 598 :contents-end 630
:structure
((598 0 "- " nil "[X]" nil 608)
(608 0 "- " nil "[ ]" nil 618)
(618 0 "- " nil "[ ]" nil 630))
:post-blank 0 :post-affiliated 598 :attr_org
(":radio")
:parent nil))
#+END_SRC

As a step towards getting to a data structure I could programmatically
modify, and then reinterpret, I made this little function:

(defun ointerp ()
  (interactive)
  (let ((el (org-element-context)))
(kill-new (org-element-interpret-data el

It works on some things, e.g. headlines, src blocks. I put the point on one
of those things, run this command, and then I can paste it somewhere to see
that it did indeed work.

But, it does not work on plain-lists, or paragraphs. I either get an empty
string, or Wrong type argument: char-or-string-p, nil

Is it possible to do what I am describing? Am I just missing how to get the
element data in the right form?

Thanks,



John

---
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

Re: [O] mailto link for the #+email keyword: Suppressing backslash and braces "escaping" for latex exports

[John Kitchin]

I posted this on your stack exchange question:

#+latex_class: report
#+options: author:nil  email:nil
#+latex_header: \author{Some user \thanks{\href{mailto:b...@comp.org}{
b...@comp.org}}}

That is basically what ox-latex expands those keywords into.

John

---
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu


On Sun, Feb 25, 2018 at 10:01 AM, H. Dieter Wilhelm <
die...@duenenhof-wilhelm.de> wrote:

> Dear orgers,
>
> I'd like to have a clickable mailto link in a latex pdf export (of a
> report) for the #+email:-keyword's content.
>
> I assume this is not achievable with latex commands, for example
>
>#+email: \href{mailto:a...@b.com}{a...@b.com}
>
> because org escapes here backslashes and the braces:
>
>   $\backslash$href\{mailto:a...@b.com\}\{a...@b.com\}
>
> Is it possible to suppress this escaping or what mechanism to achieve a
> clickable mailto link would you suggest?
>
> Thank you very much
>
> Dieter
>
> PS: Already asked this on stackexchange:
> https://emacs.stackexchange.com/q/39058/8979
>
> --
> Best wishes
> H. Dieter Wilhelm
> Kelkheim, Germany
>
>
>

Re: [O] [RFC] Could we get rid of Org specific "mark ring"

[Samuel Wales]

On 2/25/18, Nicolas Goaziou  wrote:
> Hello,
>
> Samuel Wales  writes:
>
>> in org maint, i can click on a link and, without any cognitive
>> overhead, and with certainty, run a command to get back to the link i
>> clicked on.  to me this seems like basic hypertext ability, such as
>> you might find in info or the back button on firefox.
>>
>> i think your change will make this "back button" behavior as stated in
>> the previous paragraph impossible.  please correct me if that is not
>> true.
>
> That is not true.
>
> If you're still in the same document, the local mark ring moves you back
> to the previous location. If you are not in the same document anymore,
> the global mark ring brings you back to the previous location.

i am at a link in file a that sends me to file b.  i click on it
[actually ret on it].  i pop the global mark ring.

you are saying i will always get back to the link in file a always?

now same example with the link pointing to file a.  will the global
mark ring take me there?  if not, then i will have to use local mark
ring.  this means i have to think about whether the file i was in was
the same file or not.  almost always, by the time i have done whatever
i was doing at target, that is totally forgotten.  the cognitive
overhead criterion in my first paragraph is violated.  so i /think/ my
statement about the back button behavior being broken with your change
is true.  please correct if that is wrong.

>> [for the bug that seems to have prompted your proposal, we could be
>> discussing pushing to the global and local mark rings.  but this does
>> not seem to be what we are discussing.]
>
> I don't want to alter the Emacs mark ring behaviour.

not asking you to.  my imperssion was that you could fix the bug by
having org mark ring push push to both rings.  you would keep the
current behavior of the org mark ring.  perhaps i misremember the bug.

> You are complaining about the global mark ring, which is an Emacs
> feature. So, this complaint should reach Emacs devel.

i am saying that it's not a substitute for the current org behavior.

iiuc, of course.

i don't want to have to care about the global mark ring.  i don't use
it, but if i am forced to by your change, then and only then do i
think it's a problem that its behavior is too fancy.  i don't think
emacs devs will fix it.  it has a mysterious value to its users.

Re: [O] Removing ding each time I type TAB when not after a structure template with org-tempo enabled

[Brent Goodrick]

Hi Nicolas,

Thanks. This is close, but not completely fixed: When I have the point at
the start of a line in a Org file, and type the TAB key, it does not move
like it should up underneath the prior heading. See annotated screenshot:

https://i.imgur.com/zUH28W0.png

I'll have to re-instate my workaround for now.

Thanks for the help!

Brent


On Sun, Feb 11, 2018 at 3:05 AM, Nicolas Goaziou 
wrote:

> Hello,
>
> Brent Goodrick  writes:
>
> > In this new version, I discovered that structure templates were not
> > enabled by default, so I enabled them. But to my chagrin, I found that
> > I get a "ding" each time I type the TAB key when on a blank line that
> > is _not_ right after a structure template such as " >
> > Below is my hackaround, but can someone take a look into arranging it
> > so that is not the default to ding if tempo-complete-tag cannot find
> > anything to complete, and thus I can remove my hack?
> >
> > Just passing silent to it will actually break TABing over (normal tab
> > meaning) in Org buffers, so the obvious fix won't work.  (ding)
> > returns nil which it must so that the hook works as expected.
>
> Fixed. Thank you.
>
> >   ;; Enable Structure templates that at one point were by default
> enabled in Org
> >   ;; mode, but someone changed that for some reason, so re enable it.
>
> There is another structure template expansion mechanism enable by
> default. You may want to try `C-c C-x C-w'.
>
> Regards,
>
> --
> Nicolas Goaziou
>

[O] mailto link for the #+email keyword: Suppressing backslash and braces "escaping" for latex exports

[H. Dieter Wilhelm]

Dear orgers,

I'd like to have a clickable mailto link in a latex pdf export (of a
report) for the #+email:-keyword's content.

I assume this is not achievable with latex commands, for example

   #+email: \href{mailto:a...@b.com}{a...@b.com}

because org escapes here backslashes and the braces:

  $\backslash$href\{mailto:a...@b.com\}\{a...@b.com\}

Is it possible to suppress this escaping or what mechanism to achieve a
clickable mailto link would you suggest?

Thank you very much

Dieter

PS: Already asked this on stackexchange:
https://emacs.stackexchange.com/q/39058/8979

-- 
Best wishes
H. Dieter Wilhelm
Kelkheim, Germany

Re: [O] Editing in two columns

[Peter Davis]

On Sat, Feb 24, 2018, at 7:26 PM, Peter Davis wrote:
> 
> On Sat, Feb 24, 2018, at 7:18 PM, Peter Neilson wrote:
> > On Sat, 24 Feb 2018 19:01:25 -0500, Peter Davis 
> > wrote:> >
> > > Is there a way to edit with two columns displayed so I’m only
> > > editing> > > and exporting the right hand column?
> > > I’m writing a parody of a poem, and I’d like to have the original
> > > in the> > > left column for reference, to make sure the rhyme scheme, 
> > > meters,
> > > etc.> > > match, but then I just want to export the right column to html.
> > > Thanks,
> > > -pd
> > >
> >
> > Have you tried ^X3 ? That's split-window-right . It'll go to one
> > column> > while it queries you during export, but exports only your current
> > window.> >
> 
> I haven’t tried it, but it sounds perfect. Thanks!

Works beautifully! I don’t know how I overlooked this. I used this all
the time to look at multiple files (usually with 4 windows open) when I
was writing code. In fact, I could really keep the reference in a
separate file for simplicity.
Thanks!

--
  Peter Davis
  www.techcurmudgeon.com

Re: [O] [RFC] Could we get rid of Org specific "mark ring"

[Nicolas Goaziou]

Hello,

Samuel Wales  writes:

> in org maint, i can click on a link and, without any cognitive
> overhead, and with certainty, run a command to get back to the link i
> clicked on.  to me this seems like basic hypertext ability, such as
> you might find in info or the back button on firefox.
>
> i think your change will make this "back button" behavior as stated in
> the previous paragraph impossible.  please correct me if that is not
> true.

That is not true.

If you're still in the same document, the local mark ring moves you back
to the previous location. If you are not in the same document anymore,
the global mark ring brings you back to the previous location.

> [for the bug that seems to have prompted your proposal, we could be
> discussing pushing to the global and local mark rings.  but this does
> not seem to be what we are discussing.]

I don't want to alter the Emacs mark ring behaviour.
>
> you have suggested filing a bug report against emacs.  but the emacs
> behavior is ancient.  emacs-devel is conservative.  emacs changing
> does not seem much more likely than every nation on earth switching to
> english as its official language tomorrow.

You are complaining about the global mark ring, which is an Emacs
feature. So, this complaint should reach Emacs devel.

Regards,

-- 
Nicolas Goaziou