Orgalist notes

Orgalist notes

[Eric Abrahamsen]

I'm very pleased that orgalist has become its own package! However I'm
    seeing a few of the same bugs that made the previous orgstruct-mode
    frustrating, though I'm hoping they will be easier to fix now.

    There's one right there! Spurious indentation of everything after
    the first line.

Now I'm explicitly deleting indentation, and starting again at the left
    margin. Another bug seems to appear when making lists: automatic
    filling starts a new list item, rather than continuing the paragraph
    of the first item.

- Here's an item, now I'll hit M-RET
- Very nice
- Now here's an item that is so long that eventually the auto-fill kicks
- in and the line wraps. This line is now a new line item, rather than a
- continuation of the previous list item. So is this line.

Those are my observations so far. But overall very happy to see this!

      Eric

Re: Orgalist notes

[Eric Abrahamsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> I'm very pleased that orgalist has become its own package! However I'm
>     seeing a few of the same bugs that made the previous orgstruct-mode
>     frustrating, though I'm hoping they will be easier to fix now.
>
>     There's one right there! Spurious indentation of everything after
>     the first line.
>
> Now I'm explicitly deleting indentation, and starting again at the left
>     margin. Another bug seems to appear when making lists: automatic
>     filling starts a new list item, rather than continuing the paragraph
>     of the first item.
>
> - Here's an item, now I'll hit M-RET
> - Very nice
> - Now here's an item that is so long that eventually the auto-fill kicks
> - in and the line wraps. This line is now a new line item, rather than a
> - continuation of the previous list item. So is this line.

  Though I just noted that, if I manually delete the hyphen from a second
       line, and then continue typing until it wraps to a third line,
       the third line (and the lines thereafter) is correctly
       interpreted as part of the first item (ie, no additional hyphens
       are inserted).

Re: Orgalist notes

[Eric S Fraga]

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

On Thursday,  3 May 2018 at 16:21, Eric Abrahamsen wrote:
> I'm very pleased that orgalist has become its own package! However I'm
>     seeing a few of the same bugs that made the previous orgstruct-mode
>     frustrating, though I'm hoping they will be easier to fix now.
>
>     There's one right there! Spurious indentation of everything after
>     the first line.
>
> Now I'm explicitly deleting indentation, and starting again at the left
>     margin. Another bug seems to appear when making lists: automatic
>     filling starts a new list item, rather than continuing the paragraph
>     of the first item.
>
> - Here's an item, now I'll hit M-RET
> - Very nice
> - Now here's an item that is so long that eventually the auto-fill kicks
> - in and the line wraps. This line is now a new line item, rather than a
> - continuation of the previous list item. So is this line.

Hi Eric,

Interesting.  I see the following:

- here is an item
- and a second from M-RET
- and the third one which is long but will hopefully be auto-filled when
  I type enough.  And, lo and behold, it seems to work just fine.

I find that orgalist works much better than orgstruct-mode ever
did.  The experience you are having is what I used to get with
orgstruct-mode which meant I usually did not enable it.  orgalist is
enabled all the time and I have yet to see any strange behaviour [1].

Hope this helps,

the other eric

Footnotes:
[1]  well, other than me sitting looking blankly at the screen while
     waiting for an email to be sent because I typed C-c C-c and forgot
     that I was sitting in a list when I did so...  orgalist takes over
     that binding when in a list and I keep forgetting!

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.1.6-591-gee336b

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: Orgalist notes

[Eric Abrahamsen]

Eric S Fraga <esflists@gmail.com> writes:

> On Thursday,  3 May 2018 at 16:21, Eric Abrahamsen wrote:
>> I'm very pleased that orgalist has become its own package! However I'm
>>     seeing a few of the same bugs that made the previous orgstruct-mode
>>     frustrating, though I'm hoping they will be easier to fix now.
>>
>>     There's one right there! Spurious indentation of everything after
>>     the first line.
>>
>> Now I'm explicitly deleting indentation, and starting again at the left
>>     margin. Another bug seems to appear when making lists: automatic
>>     filling starts a new list item, rather than continuing the paragraph
>>     of the first item.
>>
>> - Here's an item, now I'll hit M-RET
>> - Very nice
>> - Now here's an item that is so long that eventually the auto-fill kicks
>> - in and the line wraps. This line is now a new line item, rather than a
>> - continuation of the previous list item. So is this line.
>
> Hi Eric,
>
> Interesting.  I see the following:
>
> - here is an item
> - and a second from M-RET
> - and the third one which is long but will hopefully be auto-filled when
>   I type enough.  And, lo and behold, it seems to work just fine.

Huh! I tried the exact same typing as you've done above, and the third
     item wraps into a fourth item. I expect it will be some interaction
     with other minor modes. I've got:

Abbrev Ace-Pinyin Ace-Pinyin-Global Async-Bytecomp-Package
Auto-Composition Auto-Compression Auto-Encryption Auto-Fill
Cl-Old-Struct-Compat Company Company-Flx Diff-Auto-Refine Dired-Async
Display-Time Electric-Indent File-Name-Shadow Flyspell Font-Lock
Global-Company Global-Eldoc Global-Font-Lock Global-Git-Commit
Global-Visible-Mark Gnus-Message-Citation Helm Helm-Adaptive Line-Number
Magit-Auto-Revert Menu-Bar Mml Mouse-Wheel Orgalist Projectile
Pyim-Isearch Pyvenv Recentf Savehist Shell-Dirtrack Show-Paren Tooltip
Url-Handler Visible-Mark

It's bedtime now, but I will start again with "emacs -Q" in the morning.

> I find that orgalist works much better than orgstruct-mode ever
> did.  The experience you are having is what I used to get with
> orgstruct-mode which meant I usually did not enable it.  orgalist is
> enabled all the time and I have yet to see any strange behaviour [1].
>
> Hope this helps,
>
> the other eric

Good thing there's only two of us.

> Footnotes:
> [1]  well, other than me sitting looking blankly at the screen while
>      waiting for an email to be sent because I typed C-c C-c and forgot
>      that I was sitting in a list when I did so...  orgalist takes over
>      that binding when in a list and I keep forgetting!

       Yes! I tried to send an email not two minutes ago, and had the
       same experience. My guess is that a significant chunk of orgalist
       users are using it in message-mode, where this could create
       significant confusion, particularly since the orgalist command
       doesn't warn you that it tried (and failed) to do anything.

Re: Orgalist notes

[Alan Schmitt]

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

         Hello,

          I'm having the same indentation, as can be seen here. For some
              strange reason, as soon as I get to the next line (using
              return) I get extra space. I just refilled this paragraph
              and it looks like this.

                  - this is a list
                  - another list, and let's make is super long, even
                  - longer, and I have the same problem.

Here is the list of minor modes that I have:

Abbrev Anzu Async-Bytecomp-Package Auto-Composition Auto-Compression
Auto-Encryption Auto-Fill Beacon Clean-Aindent Column-Number
Company-Childframe Counsel Diff-Auto-Refine Diredp-Highlight-Autofiles
Editorconfig Electric-Indent Eval-Sexp-Fu-Flash Evil Evil-Escape
Evil-Lion Evil-Local Evil-Search-Highlight-Persist Evil-Surround
Eyebrowse File-Name-Shadow Flx-Ido Flyspell Font-Lock Global-Anzu
Global-Auto-Revert Global-Eldoc Global-Evil-Search-Highlight-Persist
Global-Evil-Surround Global-Font-Lock Global-Git-Commit
Global-Git-Gutter+ Global-Page-Break-Lines
Global-Spacemacs-Leader-Override Global-Undo-Tree Global-Vi-Tilde-Fringe
Global-Xah-Math-Input Gnus-Message-Citation Hl-Todo Ido-Vertical
Info-Breadcrumbs-In-Mode-Line Ivy Line-Number Mac-Mouse-Wheel Menu-Bar
Mixed-Pitch Mml Orgalist Override-Global Persp Projectile Pupo Purpose
Recentf Save-Place Savehist Shell-Dirtrack Show-Smartparens
Show-Smartparens-Global Spaceline-Helm Spaceline-Info
Spacemacs-Leader-Override Transient-Mark Undo-Tree Vi-Tilde-Fringe
Volatile-Highlights Which-Key Winner Winum Xah-Math-Input Xterm-Mouse
Yas Yas-Global

Best,

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Monthly Athmospheric CO₂, Mauna Loa Obs. 2018-03: 409.46, 2017-03: 407.18

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 528 bytes --]

Re: Orgalist notes

[Eric S Fraga]

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

On Thursday,  3 May 2018 at 23:45, Eric Abrahamsen wrote:

[...]

> Huh! I tried the exact same typing as you've done above, and the third
>      item wraps into a fourth item. I expect it will be some interaction
>      with other minor modes. I've got:

I've looked at your modes and mine and:

Yours that I don't have:

    Ace-Pinyin Ace-Pinyin-Global Async-Bytecomp-Package
    Cl-Old-Struct-Compat Company Company-Flx Dired-Async Global-Company
    Global-Git-Commit Global-Visible-Mark Helm Helm-Adaptive
    Magit-Auto-Revert Menu-Bar Projectile Pyim-Isearch Pyvenv
    Savehist Shell-Dirtrack Show-Paren Url-Handler Visible-Mark

Mine:

    Auto-Dictionary Beacon Column-Number Display-Line-Numbers Evil
    Evil-Local Flx-Ido Global-Aggressive-Indent Global-Auto-Revert
    Global-Undo-Tree Hl-Line Ido-Everywhere Minibuffer-Line
    Override-Global Pabbrev Save-Place Transient-Mark Undo-Tree
    Which-Key

The only one that jumps out immediately is that I have
Global-Aggressive-Indent and you don't.  And I use evil-mode but I don't
think that should matter and insert mode is almost (although not quite)
equivalent to normal emacs state.

It's quite interesting comparing, by the way!  I may have to look at
some of those minor modes you use.

HTH,
eric
-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.1.6-591-gee336b

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: Orgalist notes

[Eric Abrahamsen]

Eric S Fraga <esflists@gmail.com> writes:

> On Thursday,  3 May 2018 at 23:45, Eric Abrahamsen wrote:
>
> [...]
>
>> Huh! I tried the exact same typing as you've done above, and the third
>>      item wraps into a fourth item. I expect it will be some interaction
>>      with other minor modes. I've got:
>
> I've looked at your modes and mine and:
>
> Yours that I don't have:
>
>     Ace-Pinyin Ace-Pinyin-Global Async-Bytecomp-Package
>     Cl-Old-Struct-Compat Company Company-Flx Dired-Async Global-Company
>     Global-Git-Commit Global-Visible-Mark Helm Helm-Adaptive
>     Magit-Auto-Revert Menu-Bar Projectile Pyim-Isearch Pyvenv
>     Savehist Shell-Dirtrack Show-Paren Url-Handler Visible-Mark
>
> Mine:
>
>     Auto-Dictionary Beacon Column-Number Display-Line-Numbers Evil
>     Evil-Local Flx-Ido Global-Aggressive-Indent Global-Auto-Revert
>     Global-Undo-Tree Hl-Line Ido-Everywhere Minibuffer-Line
>     Override-Global Pabbrev Save-Place Transient-Mark Undo-Tree
>     Which-Key
>
> The only one that jumps out immediately is that I have
> Global-Aggressive-Indent and you don't.  And I use evil-mode but I don't
> think that should matter and insert mode is almost (although not quite)
> equivalent to normal emacs state.

- I installed global-aggressive-indent, but haven't turned it on yet.
  Just typing normally. Oh damn, it didn't do it this time. Well that's
  pretty weird.

Now a regular paragraph, still without having turned aggressive
    indent on. There's the weird indentation again. Now M-x
    global-aggressive-indent-mode.

- Here's the trick with the list items again, I should have just reduced
  fill-column to make this experiment less painful. Nope, now it's
  working correctly.

Well, I guess that's why this is a hard problem.

> It's quite interesting comparing, by the way!  I may have to look at
> some of those minor modes you use.

It was alarming to look at the whole list -- there's stuff in there I
haven't thought about in ages...

Re: Orgalist notes

[Eric S Fraga]

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

On Friday,  4 May 2018 at 09:44, Eric Abrahamsen wrote:

[...]

> It was alarming to look at the whole list -- there's stuff in there I
> haven't thought about in ages...

Me too.  Made me go in a clean some cruft out of my .emacs... :-)

Weekend now, it's sunny and time for a beer at a pub with a garden,
methinks, so I'm signing off!

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.1.6-591-gee336b

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: Orgalist notes

[Gregor Zattler]

Hi Eric, orgalist users,
* Eric Abrahamsen <eric@ericabrahamsen.net> [2018-05-03; 23:45]:
> Huh! I tried the exact same typing as you've done above, and the third
>      item wraps into a fourth item. I expect it will be some interaction
>      with other minor modes. I've got:

I have the very same problems with unstoppable indentation in
  orgalist and I don't think it is an interaction with other
  minor modes, because it hits even with no configuration.  Do:

emacs25 -Q  --debug-init  -l /home/grfz/.emacs.d/elpa-27.0/orgalist-1.3/orgalist.el   -f compose-mail --eval "(progn (orgalist-mode t) (end-of-buffer) (newline) (newline))"

(you'll have to adjust the path to your orglist.el)        

and hit RETURN in the newly created emacs frame and this last new
    line will be indented.


I also tested with a freshly build emacs from the master branch
  and it showed the same behaviour.


Ciao; Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-

Re: Orgalist notes

[Nicolas Goaziou]

Hello,

Gregor Zattler <telegraph@gmx.net> writes:

> Hi Eric, orgalist users,
> * Eric Abrahamsen <eric@ericabrahamsen.net> [2018-05-03; 23:45]:
>> Huh! I tried the exact same typing as you've done above, and the third
>>      item wraps into a fourth item. I expect it will be some interaction
>>      with other minor modes. I've got:
>
> I have the very same problems with unstoppable indentation in
>   orgalist and I don't think it is an interaction with other
>   minor modes, because it hits even with no configuration.  Do:
>
> emacs25 -Q  --debug-init  -l /home/grfz/.emacs.d/elpa-27.0/orgalist-1.3/orgalist.el   -f compose-mail --eval "(progn (orgalist-mode t) (end-of-buffer) (newline) (newline))"
>
> (you'll have to adjust the path to your orglist.el)        
>
> and hit RETURN in the newly created emacs frame and this last new
>     line will be indented.
>
>
> I also tested with a freshly build emacs from the master branch
>   and it showed the same behaviour.

Indeed. When I tried make Orgalist mode fair with other minor modes and
switched to using advices, I encountered a few unexpected hiccups, most
notably bug#31361, which is responsible for some erratic indentation.

I eventually worked around it, and just updated Orgalist. It should be
available on ELPA toworrow. Hopefully, thing will become a bit smoother.

Thank you for the reports.

Regards,

-- 
Nicolas Goaziou

Re: Orgalist notes

[Eric Abrahamsen]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> Gregor Zattler <telegraph@gmx.net> writes:
>
>> Hi Eric, orgalist users,
>> * Eric Abrahamsen <eric@ericabrahamsen.net> [2018-05-03; 23:45]:
>>> Huh! I tried the exact same typing as you've done above, and the third
>>>      item wraps into a fourth item. I expect it will be some interaction
>>>      with other minor modes. I've got:
>>
>> I have the very same problems with unstoppable indentation in
>>   orgalist and I don't think it is an interaction with other
>>   minor modes, because it hits even with no configuration.  Do:
>>
>> emacs25 -Q  --debug-init  -l /home/grfz/.emacs.d/elpa-27.0/orgalist-1.3/orgalist.el   -f compose-mail --eval "(progn (orgalist-mode t) (end-of-buffer) (newline) (newline))"
>>
>> (you'll have to adjust the path to your orglist.el)        
>>
>> and hit RETURN in the newly created emacs frame and this last new
>>     line will be indented.
>>
>>
>> I also tested with a freshly build emacs from the master branch
>>   and it showed the same behaviour.
>
> Indeed. When I tried make Orgalist mode fair with other minor modes and
> switched to using advices, I encountered a few unexpected hiccups, most
> notably bug#31361, which is responsible for some erratic indentation.
>
> I eventually worked around it, and just updated Orgalist. It should be
> available on ELPA toworrow. Hopefully, thing will become a bit smoother.
>
> Thank you for the reports.
>
> Regards,

And, as always, thank you! This is fairly heroic work -- I say that
after having made an attempt at orgstruct-mode, and run away screaming.
And look, no funny indentation!

- Yet a list item with a ridiculous amount of text in it does not wrap
  into a second list item.
- Neither does the second list item, despite having an equivalent amount
  of spurious typing in it.

- And before I get tired of the experiment, here's the same thing with
 a numbered list.
- Oh damn, I hit M-RET, and the numbered list turned into an unnumbered
  list.

No good deed goes unpunished :)

Re: Orgalist notes

[Nicolas Goaziou]

Hello,

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> - And before I get tired of the experiment, here's the same thing with
>  a numbered list.
> - Oh damn, I hit M-RET, and the numbered list turned into an unnumbered
>   list.

I cannot reproduce it. 

More explicitly, I typed "1." at the beginning of a line to start
a numbered list, then filled the item with random characters so Auto
fill could start another line below the first. Eventually, I used
M-<RET> and got

   1. Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
      eiusmod tempor incididunt.
   2. 

I'm using Orgalist 1.5.

Could it be related to another minor mode you're loading?
   
> No good deed goes unpunished :)

Heh.

Thank you for the report.

Regards,

-- 
Nicolas Goaziou

Re: Orgalist notes

[Gregor Zattler]

Hi Eric, Nicolas,
* Eric Abrahamsen <eric@ericabrahamsen.net> [2018-05-05; 16:55]:
> - And before I get tired of the experiment, here's the same thing with
>  a numbered list.
> - Oh damn, I hit M-RET, and the numbered list turned into an unnumbered
>   list.

with this:
emacs-snapshot -Q  --debug-init  -l /home/grfz/.emacs.d/elpa-27.0/orgalist-1.5/orgalist.el   -f compose-mail  --eval "(progn (orgalist-mode t) (end-of-buffer) (newline) (newline))"


I get


1. ha fkj hdhf kjh kdjfh kdjsh gjhdlkj ghkjdsgh dj ljgh kjdh kjhvgfkj
   hdgkjhkjh djhg kjdhf kjhdkjghf kdhödgkhödkj hödj öh ödfkj hökhdgfsjh kjgh dh hdgöf h h ö ökhkjhgdöhg jdhf kj ök ökdfj ödfj dfjkj kjg kj kjdökgh ödh öhg   g  g   

   - no autofill after the second line
   - M-RET gives: setq: Symbol’s function definition is void:
     org-in-regexp



With org-mode in the load-path, the line breaks happen for all
lines not only the first one.  But one has to (require 'org) in
order for M-RET to work.  This is no problem for me, since I work
with org-mode all the time, but is this intended?


In my highly customized emacs I get line breaks but M-RET gives

1. jesdgf oigjovgjis uh urh udrhfesgh ourhes ouh ouhroe uhos ho
   hg uirehui shgourheoug hhsou hogush oguhuishughsoieghoudrhes
   uhguhdsh ghourhg

orgalist-insert-item: Wrong type argument: integer-or-marker-p, nil

This is not the case with bullet lists:

- o ushurgh dusrh gdrhf oudrhesurgh urhrh oughou hortus houtgsh
  ou houhort rtgshM-RET
- 


Could you give me a hint on how to debug this?


Thanks, Gregor

Re: Orgalist notes

[Nicolas Goaziou]

Hello,

Gregor Zattler <telegraph@gmx.net> writes:

> With org-mode in the load-path, the line breaks happen for all
> lines not only the first one.  But one has to (require 'org) in
> order for M-RET to work.  This is no problem for me, since I work
> with org-mode all the time, but is this intended?

No, it is not intended. Orgalist 1.6 (to be released tomorrow) will
require Org right from the start.

> In my highly customized emacs I get line breaks but M-RET gives
>
> 1. jesdgf oigjovgjis uh urh udrhfesgh ourhes ouh ouhroe uhos ho
>    hg uirehui shgourheoug hhsou hogush oguhuishughsoieghoudrhes
>    uhguhdsh ghourhg
>
> orgalist-insert-item: Wrong type argument: integer-or-marker-p, nil
>
> This is not the case with bullet lists:
>
> - o ushurgh dusrh gdrhf oudrhesurgh urhrh oughou hortus houtgsh
>   ou houhort rtgshM-RET
> - 
>
>
> Could you give me a hint on how to debug this?

Please use M-x toggle-debug-on-error and report the backtrace here.
Loading an un-compiled Orgalist is better.

Thank you.

Regards,

-- 
Nicolas Goaziou

Re: Orgalist notes

[Gregor Zattler]

Hi Nicolas,
* Nicolas Goaziou <mail@nicolasgoaziou.fr> [2018-05-06; 13:32]:
> Gregor Zattler <telegraph@gmx.net> writes:
>
>> With org-mode in the load-path, the line breaks happen for all
>> lines not only the first one.  But one has to (require 'org) in
>> order for M-RET to work.  This is no problem for me, since I work
>> with org-mode all the time, but is this intended?
>
> No, it is not intended. Orgalist 1.6 (to be released tomorrow) will
> require Org right from the start.

This works now with bullet and numbered lists when called in a
non-configured emacs session.  Thanks.


>> In my highly customized emacs I get line breaks but M-RET gives
>>
>> 1. jesdgf oigjovgjis uh urh udrhfesgh ourhes ouh ouhroe uhos ho
>>    hg uirehui shgourheoug hhsou hogush oguhuishughsoieghoudrhes
>>    uhguhdsh ghourhg
>>
>> orgalist-insert-item: Wrong type argument: integer-or-marker-p, nil
[...]
>> Could you give me a hint on how to debug this?
>
> Please use M-x toggle-debug-on-error and report the backtrace here.
> Loading an un-compiled Orgalist is better.

1. rzhe juhgdhjvhj vghfjs y rvgfhjxd bvjxdbv mh vxnbxgbfvghg drgh
   djhxcjhbnjdfjhvgjhf jhfhjghfj hfjM-RET


gives:

Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p nil)
  org-list-insert-item(1504 ((1397 0 "1. " nil nil nil 1505)) ((1397)) nil nil)
  (setq struct (org-list-insert-item (point) struct prevs checkbox desc))
  (let* ((struct (save-excursion (goto-char item\?) (orgalist--struct))) (prevs (org-list-prevs-alist struct)) (desc (and (eq 'descriptive (org-list-get-list-type item\? struct prevs)) " :: "))) (setq struct (org-list-insert-item (point) struct prevs checkbox desc)) (org-list-write-struct struct (org-list-parents-alist struct)) (looking-at orgalist--item-re) (goto-char (if (and (match-beginning 4) (let ((save-match-data-internal (match-data))) (unwind-protect (progn (string-match "\\." (match-string 1))) (set-match-data save-match-data-internal 'evaporate)))) (match-beginning 4) (match-end 0))) (if desc (progn (backward-char 1))))
  (let ((item\? (orgalist--in-item-p))) (if item\? nil (user-error "Not in a list")) (let* ((struct (save-excursion (goto-char item\?) (orgalist--struct))) (prevs (org-list-prevs-alist struct)) (desc (and (eq 'descriptive (org-list-get-list-type item\? struct prevs)) " :: "))) (setq struct (org-list-insert-item (point) struct prevs checkbox desc)) (org-list-write-struct struct (org-list-parents-alist struct)) (looking-at orgalist--item-re) (goto-char (if (and (match-beginning 4) (let ((save-match-data-internal (match-data))) (unwind-protect (progn (string-match "\\." (match-string 1))) (set-match-data save-match-data-internal 'evaporate)))) (match-beginning 4) (match-end 0))) (if desc (progn (backward-char 1)))))
  orgalist-insert-item(nil)
  funcall-interactively(orgalist-insert-item nil)
  call-interactively(orgalist-insert-item nil nil)
  command-execute(orgalist-insert-item)


I have no clue how to read this.


Thanks for looking into this, Gregor

Re: Orgalist notes

[Nicolas Goaziou]

Hello,

Gregor Zattler <telegraph@gmx.net> writes:

> 1. rzhe juhgdhjvhj vghfjs y rvgfhjxd bvjxdbv mh vxnbxgbfvghg drgh
>    djhxcjhbnjdfjhvgjhf jhfhjghfj hfjM-RET
>
>
> gives:
>
> Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p nil)
>   org-list-insert-item(1504 ((1397 0 "1. " nil nil nil 1505)) ((1397)) nil nil)
>   (setq struct (org-list-insert-item (point) struct prevs checkbox desc))
>   (let* ((struct (save-excursion (goto-char item\?) (orgalist--struct))) (prevs (org-list-prevs-alist struct)) (desc (and (eq 'descriptive (org-list-get-list-type item\? struct prevs)) " :: "))) (setq struct (org-list-insert-item (point) struct prevs checkbox desc)) (org-list-write-struct struct (org-list-parents-alist struct)) (looking-at orgalist--item-re) (goto-char (if (and (match-beginning 4) (let ((save-match-data-internal (match-data))) (unwind-protect (progn (string-match "\\." (match-string 1))) (set-match-data save-match-data-internal 'evaporate)))) (match-beginning 4) (match-end 0))) (if desc (progn (backward-char 1))))
>   (let ((item\? (orgalist--in-item-p))) (if item\? nil (user-error "Not in a list")) (let* ((struct (save-excursion (goto-char item\?) (orgalist--struct))) (prevs (org-list-prevs-alist struct)) (desc (and (eq 'descriptive (org-list-get-list-type item\? struct prevs)) " :: "))) (setq struct (org-list-insert-item (point) struct prevs checkbox desc)) (org-list-write-struct struct (org-list-parents-alist struct)) (looking-at orgalist--item-re) (goto-char (if (and (match-beginning 4) (let ((save-match-data-internal (match-data))) (unwind-protect (progn (string-match "\\." (match-string 1))) (set-match-data save-match-data-internal 'evaporate)))) (match-beginning 4) (match-end 0))) (if desc (progn (backward-char 1)))))
>   orgalist-insert-item(nil)
>   funcall-interactively(orgalist-insert-item nil)
>   call-interactively(orgalist-insert-item nil nil)
>   command-execute(orgalist-insert-item)
>
> I have no clue how to read this.

I cannot reproduce the issue. It seems to be with "org-list.el".

Could you do it again, this time after loading Org uncompiled? I need
the backtrace to step into `org-list-insert-item'.


Regards,

-- 
Nicolas Goaziou

Re: Orgalist notes

[Gregor Zattler]

Hi Nicolas,
* Nicolas Goaziou <mail@nicolasgoaziou.fr> [2018-05-07; 14:37]:
> I cannot reproduce the issue. It seems to be with "org-list.el".
>
> Could you do it again, this time after loading Org uncompiled? I need
> the backtrace to step into `org-list-insert-item'.

Sure:

1. hdf ds gjdfg dzg vizdgvzu uid vjudgfvkjui dkjui uiv dfu du
   sjuds gdhfj dhfg vhjf df dfkjh vkjM-RET


Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p nil)
  goto-char(nil)
  (progn (goto-char pos) (goto-char (org-list-get-item-begin)))
  (let* ((item (progn (goto-char pos) (goto-char (org-list-get-item-begin)))) (item-end (org-list-get-item-end item struct)) (item-end-no-blank (org-list-get-item-end-before-blank item struct)) (beforep (progn (looking-at org-list-full-item-re) (<= pos (cond ((not (match-beginning 4)) (match-end 0)) ((let ((save-match-data-internal (match-data))) (unwind-protect (progn (string-match "[.)]" (match-string 1))) (set-match-data save-match-data-internal 'evaporate))) (match-beginning 4)) (t (save-excursion (goto-char (match-end 4)) (skip-chars-forward " \11") (point))))))) (split-line-p (org-get-alist-option org-M-RET-may-split-line 'item)) (blank-nb (org-list-separating-blank-lines-number pos struct prevs)) (ind (org-list-get-ind item struct)) (ind-size (if indent-tabs-mode (+ (/ ind tab-width) (mod ind tab-width)) ind)) (bullet (org-list-bullet-string (org-list-get-bullet item struct))) (box (if checkbox (progn "[ ]"))) (text-cut (and (not beforep) split-line-p (progn (goto-char pos) (if (< item-end pos) (progn (delete-region (1- item-end) (point-at-eol)))) (skip-chars-backward " \15\11\n") (setq pos (point)) (delete-and-extract-region pos item-end-no-blank)))) (body (concat bullet (if box (progn (concat box " "))) after-bullet (and text-cut (if (string-match "\\`[ \11]+" text-cut) (replace-match "" t t text-cut) text-cut)))) (item-sep (make-string (1+ blank-nb) 10)) (item-size (+ ind-size (length body) (length item-sep))) (size-offset (- item-size (length text-cut)))) (goto-char item) (indent-to-column ind) (insert body item-sep) (mapc (function (lambda (e) (let ((p (car e)) (end (nth 6 e))) (cond ((< p item) (if (> end item) (progn (setcar (nthcdr 6 e) (+ end size-offset))))) ((or beforep (not split-line-p)) (setcar e (+ p item-size)) (setcar (nthcdr 6 e) (+ end item-size))) ((< p pos) (setcar e (+ p item-size)) (if (< end pos) (setcar (nthcdr 6 e) (+ end item-size)) (setcar (nthcdr 6 e) (+ end size-offset)))) ((< p item-end) (setcar e (+ p size-offset (- item pos (length item-sep)))) (if (= end item-end) (setcar (nthcdr 6 e) (+ item item-size)) (setcar (nthcdr 6 e) (+ end size-offset (- item pos (length item-sep)))))) (t (setcar e (+ p size-offset)) (setcar (nthcdr 6 e) (+ end size-offset))))))) struct) (setq struct (cons (list item ind bullet nil box nil (+ item item-size)) struct)) (setq struct (sort struct (function (lambda (e1 e2) (< (car e1) (car e2)))))) (if beforep (goto-char item) (setq struct (org-list-swap-items item (+ item item-size) struct)) (goto-char (org-list-get-next-item item struct (org-list-prevs-alist struct)))) struct)
  (let ((case-fold-search t)) (let* ((item (progn (goto-char pos) (goto-char (org-list-get-item-begin)))) (item-end (org-list-get-item-end item struct)) (item-end-no-blank (org-list-get-item-end-before-blank item struct)) (beforep (progn (looking-at org-list-full-item-re) (<= pos (cond ((not (match-beginning 4)) (match-end 0)) ((let ((save-match-data-internal (match-data))) (unwind-protect (progn (string-match "[.)]" (match-string 1))) (set-match-data save-match-data-internal 'evaporate))) (match-beginning 4)) (t (save-excursion (goto-char (match-end 4)) (skip-chars-forward " \11") (point))))))) (split-line-p (org-get-alist-option org-M-RET-may-split-line 'item)) (blank-nb (org-list-separating-blank-lines-number pos struct prevs)) (ind (org-list-get-ind item struct)) (ind-size (if indent-tabs-mode (+ (/ ind tab-width) (mod ind tab-width)) ind)) (bullet (org-list-bullet-string (org-list-get-bullet item struct))) (box (if checkbox (progn "[ ]"))) (text-cut (and (not beforep) split-line-p (progn (goto-char pos) (if (< item-end pos) (progn (delete-region (1- item-end) (point-at-eol)))) (skip-chars-backward " \15\11\n") (setq pos (point)) (delete-and-extract-region pos item-end-no-blank)))) (body (concat bullet (if box (progn (concat box " "))) after-bullet (and text-cut (if (string-match "\\`[ \11]+" text-cut) (replace-match "" t t text-cut) text-cut)))) (item-sep (make-string (1+ blank-nb) 10)) (item-size (+ ind-size (length body) (length item-sep))) (size-offset (- item-size (length text-cut)))) (goto-char item) (indent-to-column ind) (insert body item-sep) (mapc (function (lambda (e) (let ((p (car e)) (end (nth 6 e))) (cond ((< p item) (if (> end item) (progn (setcar (nthcdr 6 e) (+ end size-offset))))) ((or beforep (not split-line-p)) (setcar e (+ p item-size)) (setcar (nthcdr 6 e) (+ end item-size))) ((< p pos) (setcar e (+ p item-size)) (if (< end pos) (setcar (nthcdr 6 e) (+ end item-size)) (setcar (nthcdr 6 e) (+ end size-offset)))) ((< p item-end) (setcar e (+ p size-offset (- item pos (length item-sep)))) (if (= end item-end) (setcar (nthcdr 6 e) (+ item item-size)) (setcar (nthcdr 6 e) (+ end size-offset (- item pos (length item-sep)))))) (t (setcar e (+ p size-offset)) (setcar (nthcdr 6 e) (+ end size-offset))))))) struct) (setq struct (cons (list item ind bullet nil box nil (+ item item-size)) struct)) (setq struct (sort struct (function (lambda (e1 e2) (< (car e1) (car e2)))))) (if beforep (goto-char item) (setq struct (org-list-swap-items item (+ item item-size) struct)) (goto-char (org-list-get-next-item item struct (org-list-prevs-alist struct)))) struct))
  org-list-insert-item(619 ((515 0 "1. " nil nil nil 620)) ((515)) nil nil)
  (setq struct (org-list-insert-item (point) struct prevs checkbox desc))
  (let* ((struct (save-excursion (goto-char item\?) (orgalist--struct))) (prevs (org-list-prevs-alist struct)) (desc (and (eq 'descriptive (org-list-get-list-type item\? struct prevs)) " :: "))) (setq struct (org-list-insert-item (point) struct prevs checkbox desc)) (org-list-write-struct struct (org-list-parents-alist struct)) (looking-at orgalist--item-re) (goto-char (if (and (match-beginning 4) (let ((save-match-data-internal (match-data))) (unwind-protect (progn (string-match "\\." (match-string 1))) (set-match-data save-match-data-internal 'evaporate)))) (match-beginning 4) (match-end 0))) (if desc (progn (backward-char 1))))
  (let ((item\? (orgalist--in-item-p))) (if item\? nil (user-error "Not in a list")) (let* ((struct (save-excursion (goto-char item\?) (orgalist--struct))) (prevs (org-list-prevs-alist struct)) (desc (and (eq 'descriptive (org-list-get-list-type item\? struct prevs)) " :: "))) (setq struct (org-list-insert-item (point) struct prevs checkbox desc)) (org-list-write-struct struct (org-list-parents-alist struct)) (looking-at orgalist--item-re) (goto-char (if (and (match-beginning 4) (let ((save-match-data-internal (match-data))) (unwind-protect (progn (string-match "\\." (match-string 1))) (set-match-data save-match-data-internal 'evaporate)))) (match-beginning 4) (match-end 0))) (if desc (progn (backward-char 1)))))
  orgalist-insert-item(nil)
  funcall-interactively(orgalist-insert-item nil)
  call-interactively(orgalist-insert-item nil nil)
  command-execute(orgalist-insert-item)


Thanks for your persitence, Gregor

Re: Orgalist notes

[Gregor Zattler]

Hi Nicolas,
* Nicolas Goaziou <mail@nicolasgoaziou.fr> [2018-05-07; 19:32]:
> Gregor Zattler <telegraph@gmx.net> writes:
>
>> Sure:
>>
>> 1. hdf ds gjdfg dzg vizdgvzu uid vjudgfvkjui dkjui uiv dfu du
>>    sjuds gdhfj dhfg vhjf df dfkjh vkjM-RET
>
> Do you have `org-plain-list-ordered-item-terminator' set to ?\) ?

Yes, I used the customization interface and choose "2)".  This
produces 41 as value of this variable.  I did so, because
sometimes a sentence ends in a number and a period but these
happen to be after a auto-fill line break and org would assume
it's a list, indenting the following lines.

And I now see, orgalist does not recognize

1) as a list.  Neither does it indent succeeding lines after the
first one, nor begin a new numbered item after M-RET

If it's not possible to use "2)", then perhaps this should be
documented?

Thanks for your help, Gregor

Re: Orgalist notes

[Nicolas Goaziou]

Gregor Zattler <telegraph@gmx.net> writes:

> Yes, I used the customization interface and choose "2)".  This
> produces 41 as value of this variable.  I did so, because
> sometimes a sentence ends in a number and a period but these
> happen to be after a auto-fill line break and org would assume
> it's a list, indenting the following lines.

This shouldn't happen. Org has guards against this kind of auto filling.

> And I now see, orgalist does not recognize
>
> 1) as a list.  Neither does it indent succeeding lines after the
> first one, nor begin a new numbered item after M-RET
>
> If it's not possible to use "2)", then perhaps this should be
> documented?

This is documented. In `orgalist-mode' docstring:

  When Orgalist mode is enabled, any line beginning with "-", "+", "1."
  or "a." followed by a space starts a list.

However, setting `org-plain-list-ordered-item-terminator' for Org mode
should not affect Orgalist minor mode. IOW, activating Orgalist should
set the variable to ?. unconditionally.

So... here comes Orgalist 1.7.

Re: Orgalist notes

[Gregor Zattler]

Hi Nicolas,
* Nicolas Goaziou <mail@nicolasgoaziou.fr> [2018-05-07; 22:29]:
> Gregor Zattler <telegraph@gmx.net> writes:
>
>> Yes, I used the customization interface and choose "2)".  [This
>> produces 41 as value of this variable.  I did so, because
>> sometimes a sentence ends in a number and a period but these
>> happen to be after a auto-fill line break and org would assume
>> it's a list, indenting the following lines.
>
[...]
> This shouldn't happen. Org has guards against this kind of auto
> filling.

OK.  Back then, when I customized this I used fill-adapt-mode, perhaps this
was the culpruit.  I do not use it anymore so after this test I
will switch it to t and see what happens.   Thanks for this hint.

>> And I now see, orgalist does not recognize
>>
>> 1) as a list.  Neither does it indent succeeding lines after the
>> first one, nor begin a new numbered item after M-RET
>>
>> If it's not possible to use "2)", then perhaps this should be
>> documented?
>
> This is documented. In `orgalist-mode' docstring:
>
>   When Orgalist mode is enabled, any line beginning with "-", "+", "1."
>   or "a." followed by a space starts a list.
>
> However, setting `org-plain-list-ordered-item-terminator' for Org mode
> should not affect Orgalist minor mode. IOW, activating Orgalist should
> set the variable to ?. unconditionally.
>
> So... here comes Orgalist 1.7.

1. zhfsiu zhuihg uidzhrg idzhg uidhr ihgi udhrg kuidh giudrhui
   tgui ui h iM-RET
2. hae foihfje ohfe oirh gesellschaftlich


Works now without a glitch!

Thanks a bundle for your fast help.

Ciao; Gregor 

Re: Orgalist notes

[Bernt Hansen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> And, as always, thank you! This is fairly heroic work -- I say that
> after having made an attempt at orgstruct-mode, and run away screaming.
> And look, no funny indentation!
>
> - Yet a list item with a ridiculous amount of text in it does not wrap
>   into a second list item.
> - Neither does the second list item, despite having an equivalent amount
>   of spurious typing in it.
>
> - And before I get tired of the experiment, here's the same thing with
>  a numbered list.
> - Oh damn, I hit M-RET, and the numbered list turned into an unnumbered
>   list.
>
> No good deed goes unpunished :)

I think you need 2 blank lines between the lists to separate them by
default - otherwise they are treated as one list and the first bullet
defines the type of list (and therefore changes your 1. back to -

Regards,
Bernt

Re: Orgalist notes

[Eric Abrahamsen]

On 05/06/18 10:34 AM, Bernt Hansen wrote:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> And, as always, thank you! This is fairly heroic work -- I say that
>> after having made an attempt at orgstruct-mode, and run away screaming.
>> And look, no funny indentation!
>>
>> - Yet a list item with a ridiculous amount of text in it does not wrap
>>   into a second list item.
>> - Neither does the second list item, despite having an equivalent amount
>>   of spurious typing in it.
>>
>> - And before I get tired of the experiment, here's the same thing with
>>  a numbered list.
>> - Oh damn, I hit M-RET, and the numbered list turned into an unnumbered
>>   list.
>>
>> No good deed goes unpunished :)
>
> I think you need 2 blank lines between the lists to separate them by
> default - otherwise they are treated as one list and the first bullet
> defines the type of list (and therefore changes your 1. back to -

You're quite right! That did the trick. All seems to be behaving
perfectly now.

Thanks,
Eric