Cycle Org Shift Select

Cycle Org Shift Select

[Christopher Dimech]

I have this code to cycle the Shift Select option for Org Mode.

I am a little concerned that (nconc Shftsel Shftsel) will continually
append, rather than just cycle through the list.

Looking for a better way to this job.

(defun Org-Shftsel-Cycle ()
   ;; Switches between options to org-support-shift-select
   (interactive)
   (let ((Shftsel (list nil t nil 'always)))
      (nconc Shftsel Shftsel)
      (setq org-support-shift-select
         (cadr (member org-support-shift-select Shftsel))) ))

Re: Cycle Org Shift Select

[Noam Postavsky]

On Fri, 6 Nov 2020 at 10:23, Christopher Dimech <dimech@gmx.com> wrote:

> I am a little concerned that (nconc Shftsel Shftsel) will continually
> append, rather than just cycle through the list.

I don't understand what you mean by "continually append", but your
code will never reach `always' because you have `nil' again after `t'.
It should be enough to just put `nil' after `always':

    (defun Org-Shftsel-Cycle ()
      ;; Switches between options to org-support-shift-select
      (interactive)
      (setq org-support-shift-select
            (cadr (memq org-support-shift-select '(nil t always nil)))))

You could also use a circular list which saves a cons cell (i.e.,
point back to the first `nil', instead of having an "extra" one at the
end):

'#1=(nil t always . #1#)

Re: Cycle Org Shift Select

[Michael Heerdegen]

Christopher Dimech <dimech@gmx.com> writes:

> I have this code to cycle the Shift Select option for Org Mode.
>
> I am a little concerned that (nconc Shftsel Shftsel) will continually
> append, rather than just cycle through the list.
>
> Looking for a better way to this job.

What behavior do you want to get?  Do you want to cycling to start
always from the same point and cycle only for repeated commands
invocations?

Or do you want to have a state remembered by the command (I guess so)?
Should this then really be a global or a per-buffer or per-window state?


Regards,

Michael.

Re: Cycle Org Shift Select

[Michael Heerdegen]

Noam Postavsky <npostavs@gmail.com> writes:

> '#1=(nil t always . #1#)

I once have been told that circular programs are problematic.  Today I
would prefer the use of a (maybe buffer local) helper variable (or, if
it's only in my init file, simply maybe make the command a closure).

Regards,

Michael.

Re: Cycle Org Shift Select

[Noam Postavsky]

On Mon, 9 Nov 2020 at 15:13, Michael Heerdegen <michael_heerdegen@web.de> wrote:

> > '#1=(nil t always . #1#)
>
> I once have been told that circular programs are problematic.  Today I
> would prefer the use of a (maybe buffer local) helper variable

It's not a program, just a replacement for the '(nil t always nil)
literal I put in my suggestion.

Re: Cycle Org Shift Select

[Michael Heerdegen]

Noam Postavsky <npostavs@gmail.com> writes:

> It's not a program, just a replacement for the '(nil t always nil)
> literal I put in my suggestion.

But isn't meant to be used in the code?

Michael.

Re: Cycle Org Shift Select

[Christopher Dimech]

It can always start from the first item in the list.  Then I can
check if (eq last-command this-command).  That is, if the user calls
same command it will cycle.  Can start with the first item in the list,
and when I get to the last, get back to the beginning.


> Sent: Monday, November 09, 2020 at 9:10 PM
> From: "Michael Heerdegen" <michael_heerdegen@web.de>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: "Help Gnu Emacs" <help-gnu-emacs@gnu.org>
> Subject: Re: Cycle Org Shift Select
>
> Christopher Dimech <dimech@gmx.com> writes:
>
> > I have this code to cycle the Shift Select option for Org Mode.
> >
> > I am a little concerned that (nconc Shftsel Shftsel) will continually
> > append, rather than just cycle through the list.
> >
> > Looking for a better way to this job.
>
> What behavior do you want to get?  Do you want to cycling to start
> always from the same point and cycle only for repeated commands
> invocations?
>
> Or do you want to have a state remembered by the command (I guess so)?
> Should this then really be a global or a per-buffer or per-window state?
>
>
> Regards,
>
> Michael.
>
>

Re: Cycle Org Shift Select

[Noam Postavsky]

On Mon, 9 Nov 2020 at 15:31, Michael Heerdegen <michael_heerdegen@web.de> wrote:

> But isn't meant to be used in the code?

It's meant like this:

    (defun Org-Shftsel-Cycle ()
      ;; Switches between options to org-support-shift-select
      (interactive)
      (setq org-support-shift-select
            (cadr (memq org-support-shift-select '#1=(nil t always . #1#)))))

If you are uncomfortable with the circular syntax, then using '(nil t
always nil) instead, as in my first post, is effectively the same
(i.e., you don't really need a circular list here anyway). I don't
understand your comments about local variables or closures though.

https://lists.gnu.org/archive/html/help-gnu-emacs/2020-11/msg00298.html

Re: Cycle Org Shift Select

[Christopher Dimech]

It cannot be 'nil t always'.  Got to introduce nil between
t and always because the user will have no way to figure out
if the Org Shift Select was changed.


> Sent: Monday, November 09, 2020 at 9:13 PM
> From: "Michael Heerdegen" <michael_heerdegen@web.de>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Cycle Org Shift Select
>
> Noam Postavsky <npostavs@gmail.com> writes:
>
> > '#1=(nil t always . #1#)
>
> I once have been told that circular programs are problematic.  Today I
> would prefer the use of a (maybe buffer local) helper variable (or, if
> it's only in my init file, simply maybe make the command a closure).
>
> Regards,
>
> Michael.
>
>
>

Re: Cycle Org Shift Select

[Noam Postavsky]

On Mon, 9 Nov 2020 at 15:40, Christopher Dimech <dimech@gmx.com> wrote:
>
> It cannot be 'nil t always'.  Got to introduce nil between
> t and always because the user will have no way to figure out
> if the Org Shift Select was changed.

Why not just add a message?

Re: Cycle Org Shift Select

[Christopher Dimech]

I have thought about that but how do I keep track of which one was selected in the list?



> Sent: Monday, November 09, 2020 at 9:42 PM
> From: "Noam Postavsky" <npostavs@gmail.com>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: "Michael Heerdegen" <michael_heerdegen@web.de>, "Help Gnu Emacs mailing list" <help-gnu-emacs@gnu.org>
> Subject: Re: Cycle Org Shift Select
>
> On Mon, 9 Nov 2020 at 15:40, Christopher Dimech <dimech@gmx.com> wrote:
> >
> > It cannot be 'nil t always'.  Got to introduce nil between
> > t and always because the user will have no way to figure out
> > if the Org Shift Select was changed.
>
> Why not just add a message?
>

Re: Cycle Org Shift Select

[Noam Postavsky]

On Mon, 9 Nov 2020 at 15:52, Christopher Dimech <dimech@gmx.com> wrote:
>
> how do I keep track of which one was selected in the list?

The value of org-support-shift-select tells you that.

Re: Cycle Org Shift Select

[Michael Heerdegen]

Noam Postavsky <npostavs@gmail.com> writes:

> If you are uncomfortable with the circular syntax [...]

In my case it was not me but a code walker that had been uncomfortable...

> then using '(nil t
> always nil) instead, as in my first post, is effectively the same
> (i.e., you don't really need a circular list here anyway). I don't
> understand your comments about local variables or closures though.
>
> https://lists.gnu.org/archive/html/help-gnu-emacs/2020-11/msg00298.html

I suggested to use a variable or a closure to remember the state of
cycling instead of self-modifying code.

Michael.

Re: Cycle Org Shift Select

[Michael Heerdegen]

Christopher Dimech <dimech@gmx.com> writes:

> It can always start from the first item in the list.  Then I can
> check if (eq last-command this-command).  That is, if the user calls
> same command it will cycle.  Can start with the first item in the list,
> and when I get to the last, get back to the beginning.

I would just use a special variable (defined globally with `defvar') to
store your cyclic list.

Then your command can just `pop' to get the next state.  If you want the
command can reinitialize the variable if (not (eq last-command
this-command)).

Michael.

Re: Cycle Org Shift Select

[Noam Postavsky]

On Mon, 9 Nov 2020 at 16:08, Michael Heerdegen <michael_heerdegen@web.de> wrote:

> I suggested to use a variable or a closure to remember the state of
> cycling instead of self-modifying code.

"No constants were destructively modified"® in the evaluation of my code :)

Re: Cycle Org Shift Select

[Michael Heerdegen]

Noam Postavsky <npostavs@gmail.com> writes:

> > how do I keep track of which one was selected in the list?
>
> The value of org-support-shift-select tells you that.

Maybe that variable is even enough to get rid of the cyclic list?

Michael.

Re: Cycle Org Shift Select

[Noam Postavsky]

On Mon, 9 Nov 2020 at 16:20, Michael Heerdegen <michael_heerdegen@web.de> wrote:
>
> Noam Postavsky <npostavs@gmail.com> writes:
>
> > > how do I keep track of which one was selected in the list?
> >
> > The value of org-support-shift-select tells you that.
>
> Maybe that variable is even enough to get rid of the cyclic list?

I already showed how to get rid of the cyclic list, in fact my first
example didn't use a cyclic list.

https://lists.gnu.org/archive/html/help-gnu-emacs/2020-11/msg00298.html
(non-cyclic)
https://lists.gnu.org/archive/html/help-gnu-emacs/2020-11/msg00305.html (cyclic)

Re: Cycle Org Shift Select

[Michael Heerdegen]

Noam Postavsky <npostavs@gmail.com> writes:

> I already showed how to get rid of the cyclic list, in fact my first
> example didn't use a cyclic list.
>
> https://lists.gnu.org/archive/html/help-gnu-emacs/2020-11/msg00298.html
> (non-cyclic)

Yes I know, it's just...late.  And I'm trying to find out why my Emacs
is using 7 GB of memory (Bug#43389), and I have no clue how to do that.
If you have any hints... it will not take long until the thing starts
swapping.

Regards,

Michael.

Re: Cycle Org Shift Select

[Christopher Dimech]

Aw having trouble printing the value of org-support-shift-select
in the mini-buffer.


> Sent: Monday, November 09, 2020 at 9:53 PM
> From: "Noam Postavsky" <npostavs@gmail.com>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: "Michael Heerdegen" <michael_heerdegen@web.de>, "Help Gnu Emacs mailing list" <help-gnu-emacs@gnu.org>
> Subject: Re: Cycle Org Shift Select
>
> On Mon, 9 Nov 2020 at 15:52, Christopher Dimech <dimech@gmx.com> wrote:
> >
> > how do I keep track of which one was selected in the list?
>
> The value of org-support-shift-select tells you that.
>

Re: Cycle Org Shift Select

[Noam Postavsky]

On Mon, 9 Nov 2020 at 16:45, Christopher Dimech <dimech@gmx.com> wrote:
>
> Aw having trouble printing the value of org-support-shift-select
> in the mini-buffer.

Doesn't (message "org-support-shift-select = %S" org-support-shift-select) work?

Re: Cycle Org Shift Select

[Michael Heerdegen]

Christopher Dimech <dimech@gmx.com> writes:

> Aw having trouble printing the value of org-support-shift-select
> in the mini-buffer.

  (message "org-support-shift-select: %S" org-support-shift-select)

See `format' docstring for the meaning of the % sequences.

Michael.

Re: Cycle Org Shift Select

[Christopher Dimech]

Had used  (message org-support-shift-select) and that didn't
show up.

> Sent: Monday, November 09, 2020 at 10:50 PM
> From: "Michael Heerdegen" <michael_heerdegen@web.de>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: "Noam Postavsky" <npostavs@gmail.com>, "Help Gnu Emacs mailing list" <help-gnu-emacs@gnu.org>
> Subject: Re: Cycle Org Shift Select
>
> Christopher Dimech <dimech@gmx.com> writes:
>
> > Aw having trouble printing the value of org-support-shift-select
> > in the mini-buffer.
>
>   (message "org-support-shift-select: %S" org-support-shift-select)
>
> See `format' docstring for the meaning of the % sequences.
>
> Michael.
>

Re: Cycle Org Shift Select

[Christopher Dimech]

What is the meaning of the '.' in '#1=(nil t always . #1#)?


> Sent: Monday, November 09, 2020 at 9:40 PM
> From: "Christopher Dimech" <dimech@gmx.com>
> To: "Michael Heerdegen" <michael_heerdegen@web.de>
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: Cycle Org Shift Select
>
> It cannot be 'nil t always'.  Got to introduce nil between
> t and always because the user will have no way to figure out
> if the Org Shift Select was changed.
>
>
> > Sent: Monday, November 09, 2020 at 9:13 PM
> > From: "Michael Heerdegen" <michael_heerdegen@web.de>
> > To: help-gnu-emacs@gnu.org
> > Subject: Re: Cycle Org Shift Select
> >
> > Noam Postavsky <npostavs@gmail.com> writes:
> >
> > > '#1=(nil t always . #1#)
> >
> > I once have been told that circular programs are problematic.  Today I
> > would prefer the use of a (maybe buffer local) helper variable (or, if
> > it's only in my init file, simply maybe make the command a closure).
> >
> > Regards,
> >
> > Michael.
> >
> >
> >
>
>

Re: Cycle Org Shift Select

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1826 bytes --]

On Mon, Nov 09, 2020 at 11:49:33PM +0100, Christopher Dimech wrote:
> What is the meaning of the '.' in '#1=(nil t always . #1#)?

This means that the last cdr in that list isn't nil, as "decent,
normal lists" (aka "proper lists") have, but a reference to something,
in this case to the list's head (#1#), which you have taken previously,
in #1=. Making the whole thing an Ouroboros [1].

In box-and-pointer-ish, the list '(nil t always) looks like so
(WARNING: psychedelic effects guaranteed when using variable-pitch
fonts. But who does that, anyway?):

  +-----+--+      +--+--+      +--+-----+  
  | nil |  | ---> |  |  | ---> |  | nil |
  +-----+--+      +--+--+      +--+-----+     
                    |            |
                    v            v
                   't          'always

Note how the list ends with a pair whose cdr is nil.

The dot notation allows you to fill both slots of a pair (car
and cdr), thus putting something other than the "link to next"
in a cdr, creating an improper list; the reference notation
(that #...= and #...#) allows you to take a ref at some place
and use it later. That's what your above monster looks like
in box-and-pointer:

        +---------------------------------+
        |                                 |
        v                                 |
  +-----+--+      +--+--+      +--+--+    |
  | nil |  | ---> |  |  | ---> |  |  | ---+
  +-----+--+      +--+--+      +--+--+     
                    |            |
                    v            v
                   't          'always


So if you run *that* list along (by doing cdr), you'll run
in circles, over and over again. That was this device's
intention, anyway, if I followed along correctly.

Cheers

[1] https://en.wikipedia.org/wiki/Ouroboros
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Cycle Org Shift Select

[Christopher Dimech]

Many thanks Tomas, have gone though the Elisp Manual yesterday
and I am getting to understand this list Ouroboros thing. :)


> Sent: Tuesday, November 10, 2020 at 9:08 AM
> From: tomas@tuxteam.de
> To: help-gnu-emacs@gnu.org
> Subject: Re: Cycle Org Shift Select
>
> On Mon, Nov 09, 2020 at 11:49:33PM +0100, Christopher Dimech wrote:
> > What is the meaning of the '.' in '#1=(nil t always . #1#)?
>
> This means that the last cdr in that list isn't nil, as "decent,
> normal lists" (aka "proper lists") have, but a reference to something,
> in this case to the list's head (#1#), which you have taken previously,
> in #1=. Making the whole thing an Ouroboros [1].
>
> In box-and-pointer-ish, the list '(nil t always) looks like so
> (WARNING: psychedelic effects guaranteed when using variable-pitch
> fonts. But who does that, anyway?):
>
>   +-----+--+      +--+--+      +--+-----+
>   | nil |  | ---> |  |  | ---> |  | nil |
>   +-----+--+      +--+--+      +--+-----+
>                     |            |
>                     v            v
>                    't          'always
>
> Note how the list ends with a pair whose cdr is nil.
>
> The dot notation allows you to fill both slots of a pair (car
> and cdr), thus putting something other than the "link to next"
> in a cdr, creating an improper list; the reference notation
> (that #...= and #...#) allows you to take a ref at some place
> and use it later. That's what your above monster looks like
> in box-and-pointer:
>
>         +---------------------------------+
>         |                                 |
>         v                                 |
>   +-----+--+      +--+--+      +--+--+    |
>   | nil |  | ---> |  |  | ---> |  |  | ---+
>   +-----+--+      +--+--+      +--+--+
>                     |            |
>                     v            v
>                    't          'always
>
>
> So if you run *that* list along (by doing cdr), you'll run
> in circles, over and over again. That was this device's
> intention, anyway, if I followed along correctly.
>
> Cheers
>
> [1] https://en.wikipedia.org/wiki/Ouroboros
>  - t
>

Re: Cycle Org Shift Select

[Michael Heerdegen]

Christopher Dimech <dimech@gmx.com> writes:

> Many thanks Tomas, have gone though the Elisp Manual yesterday
> and I am getting to understand this list Ouroboros thing. :)

If you want a simple way to think about it starting from a syntax point
of view:

A very simple way to think about the dotted syntax is to start from
regular lists.  You can write

  (elt1 elt2 . rest)

to describe a list of the elements elt1 elt2 (any positive number of
starting elements will do) with the elements in the list `rest'
appended. For example try to eval

  '(x y . ())

or

  '(x y . (z))

(You need the quote "'" because we don't want to evaluate the lists as
an expression.)

Of course the dot syntax is ambiguous, e.g.

  '(x y z)
  '(x . (y z))
  '(x . (y . (z)))
  '(x . (y . (z . ())))

all describe equal three element lists containing the symbols x, y and z.

Then you need to know that the "rest" can be actually anything.  If the
`rest' doesn't describe a regular list, you get a "dotted" list (it will
be printed using the dot syntax).  In the simplest case

  (x . y)

you have a pair, a `cons' cell which is the building block lists are
constructed from in Lisp.  A cons with a list cdr is also a list.

And when `rest' refers to the list itself (possible using the # reader
syntax):

  '#1=(nil t always . #1#)

you get a circular list.

HTH,
Michael.

RE: Cycle Org Shift Select

[Drew Adams]

> (defun Org-Shftsel-Cycle ()
>   (interactive)
>   (setq org-support-shift-select
>         (cadr (memq org-support-shift-select '(nil t always nil)))))


Elegant Lisp, IMO!  A good idiom.
___


Slightly cuter: the last nil isn't needed, since (car nil) = nil.

(defvar toto nil)

(defun foo ()
  (interactive)
  (setq toto  (cadr (memq toto '(nil t always))))
  (message "NOW: %s" toto))

Of if you want to show also what'll come next:

(defun foo ()
  (interactive)
  (let ((xs  '(nil t always))
        next)
    (setq toto  (cadr (memq toto xs))
          next  (cadr (memq toto xs)))
    (message "NOW: %s, NEXT: %s" toto next)))

RE: Cycle Org Shift Select

[Drew Adams]

> > (defun Org-Shftsel-Cycle ()
> >   (interactive)
> >   (setq org-support-shift-select
> >         (cadr (memq org-support-shift-select '(nil t always nil)))))
> 
> Elegant Lisp, IMO!  A good idiom.
> ___
> 
> 
> Slightly cuter: the last nil isn't needed, since (car nil) = nil.
> 
> (defvar toto nil)
> 
> (defun foo ()
>   (interactive)
>   (setq toto  (cadr (memq toto '(nil t always))))
>   (message "NOW: %s" toto))
> 
> Of if you want to show also what'll come next:
> 
> (defun foo ()
>   (interactive)
>   (let ((xs  '(nil t always))
>         next)
>     (setq toto  (cadr (memq toto xs))
>           next  (cadr (memq toto xs)))
>     (message "NOW: %s, NEXT: %s" toto next)))

On the other hand, if you want to be able to go either
forward or backward then you might want to use a ring
(as defined in standard library ring.el):

(defvar ring (ring-convert-sequence-to-ring '(nil t always)))
(defvar current nil)

(defun next ()
  (interactive)
  (setq current  (ring-next toto current))
  (message "NOW: %s" current))

(defun previous ()
  (interactive)
  (setq current  (ring-previous toto current))
  (message "NOW: %s" current))