[O] Bug: Incorrect/incomplete documentation for org-timestamp-change

2019-05-05 Thread Tim Landscheidt
I wanted to (and did) change a number of timestamps by a
constant.  So I found (and successfully used)
org-timestamp-change which starts with (master):

| […]
| (defun org-timestamp-change (n  what updown suppress-tmp-delay)
|   "Change the date in the time stamp at point.
| The date will be changed by N times WHAT.  WHAT can be `day', `month',
| `year', `minute', `second'.  If WHAT is not given, the cursor position
| in the timestamp determines what will be changed.
| When SUPPRESS-TMP-DELAY is non-nil, suppress delays like \"--2d\"."
| […]

Incorrect is the enumeration of valid values for WHAT: 'hour
is missing and 'second is probably wrong (?).

Incomplete is the documentation for UPDOWN: I had assumed it
was the "direction" of change, but that is determined in-
stead by the sign of N.



[O] bug#35453: 26.1; Poor performance of vertical-motion in large org buffer

2019-05-05 Thread Eli Zaretskii
> From: Ihor Radchenko 
> Cc: 35...@debbugs.gnu.org
> Date: Sun, 05 May 2019 09:05:46 +0800
> 
>   > Of course, if someone comes up with ideas how to speed up
>   > vertical-motion without changing what Org does with overlays and/or
>   > how overlays are implemented, such ideas will be most welcome.
> 
>   Rather dumb idea.
>   Currently, vertical-motion just loops over all the intervals in the
>   buffer. What if we optimise next-single-char-property-change and use it
>   in vertical-motion? Say, the interval data structure can extended. In
>   addition to the currently available pointers to next and previous
>   intervals, each (or just 'invisible') property of the interval might
>   also contain a pointer to next/previous interval with different property
>   value. Then, by increasing the structure size a bit, we can
>   significantly speed up the buffer motion commands.

There are no intervals in this story.  The way overlays are
implemented, they don't use intervals (if by that you mean the
facilities in intervals.c).  Someone was working on making overlays
more efficient by changing the low-level implementation details, but
that work is yet unfinished.





Re: [O] Parens matching off in babel code block

2019-05-05 Thread Marco Wahl
"Fraga, Eric"  writes:

> On Thursday,  2 May 2019 at 21:11, Lawrence Bottorff wrote:
>> Well, at least there is a sane explanation. Ironically, I was also about to
>> complain about all my loose ">"s getting flagged. So they are related!
>> Would there be a way to make an exception for < and > inside of actual code
>> forms? Languages need them for "greater than" and "less than".
>
> I have the following in my org mode customization:
>
> (modify-syntax-entry ?< ".")
> (modify-syntax-entry ?> ".")
>
> as many of my org files have these symbols not as paren but as operators.

I'll follow your lead and add the lines

(add-hook
 'org-mode-hook
 (lambda ()
(modify-syntax-entry ?< ".")
(modify-syntax-entry ?> ".")))

to my config.


Thanks,
-- 
Marco 




[O] bug#34977: org-edit-src-code undesirable behaviour

2019-05-05 Thread Nicolas Goaziou
Hello,

pinkanon pinkanon  writes:

> There are two things that work undesirably for me when using 
> org-edit-src-code:
> (1) With a selected region, the point in the edit buffer will be one line 
> below the bottom of the selection.
> (2) After closing the edit buffer, if it was modified, the point jumps to the 
> beginning of the block.
> (3) If I wanted to programmatically edit src code in the block, is calling 
> 'org-edit-src-code the right way anyway? Because there seems to be some lag, 
> besides the points mentioned above.
>
> Steps to reproduce:
>
> M-x org-mode
>
> Eval this function:
>
>   (defun commit-bad-deeds ()
> (interactive)
> (let* ((p (point))
>(w (get-buffer-window (current-buffer
>   (org-edit-src-code)
>   (gnus-delete-line) ; any code that modifies buffer
>   (org-edit-src-exit)
>   (set-window-point w p)))
>
> Bind it:
>
> (global-set-key (kbd "M-w") 'commit-bad-deeds)
>
> Paste this code:
>
> #+BEGIN_SRC elisp
> (1) cursor jumps to the beginning of this line
> (2) lawfully-good line to be selected
> (3) and this line to be murdered instead
> (4) w/ no witnesses
> #+END_SRC
>
> - Jump to line (2)
> - Select whole line: (progn (end-of-line) (set-mark 
> (line-beginning-position))) or any other way
> - press M-w
>
> Observe:
> (1) Line (3) removed instead of (2)
> (2) Point jumping to the beginning of the block
> (3) Lag?

I cannot reproduce any of these observations. Could you check that no
other function is interfering?

Regards,

-- 
Nicolas Goaziou





[O] bug#35122: 27.0.50; item nubmers are not maintained when shifting items in org plain lists

2019-05-05 Thread Nicolas Goaziou
Hello,

Li Feng  writes:

> 0. clean start emacs with "emacs -q"
> 1. create an org-mode file
> 2. enter a few plain list items
> 3. use M-S-up/down to move them
> 4. observe that the numbers are wrong

This is expected. M-S-up/down moves lines around /without taking context
into consideration/. Note that you can fix again the numbers with `C-c
C-c'.

In any case, if you want to adjust structure of the list, use dedicated
commands, like M-up and M-down, as for headlines.

I'm closing this bug. Feel free to re-open it if you disagree.

Regards,

-- 
Nicolas Goaziou





[O] bug#34891: 25.2; ORG-PUBLISH-FIND-DATE should not use Creation/Publish date (#+DATE:) in file as a modification timestamp.

2019-05-05 Thread Nicolas Goaziou
Hello,

David Trudgett  writes:

> Reproduce:
>
> In an Org mode file, add a #+DATE tag as follows:
>
> #+DATE: First published: 1 February 2014
>
> Then initiate a project publish, which publishes (by default) only
> changed files. A date such as the above will not be parsed, so
> ox-publish.el will always publish it, even though it has not changed.
> Using instead a parsable date format (such as 2014-02-01), this date will be
> recognised, and will result in the file never being published, because
> it is treating the date as a modification date instead of a creation date.
>
> Desired Behaviour:
>
> ox-publish.el, in function ORG-PUBLISH-FIND-DATE should not be using
> this date to detect modifications, as it will never change, and no
> modifications will be detected for publishing.

I don't understand how you come to this conclusion. 

The function responsible for deciding if a file should be published is
`org-publish-cache-file-needs-publishing'. It doesn't call
`org-publish-find-date', but `org-publish-cache-ctime-of-src'. The
latter only uses `file-attribute-modification-time'.

IOW, I think the file is published because you modified since last
publishing.

WDYT?

Regards,

-- 
Nicolas Goaziou





[O] bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter)

2019-05-05 Thread Ihor Radchenko
Dear Dmitrii,

> Indirect buffers give the answer to the issue of sharing some textual data
> between several buffer.

Note that indirect buffers always share *all* the contents with the master
buffer. As a result, it may not be easy to make things like flyspell
work on code blocks in org-mode, if these code blocks are treated as
lenses. 

> (1) A question: when an indirect buffer is created and some region is
> narrowed to, is the rest of the buffer duplicated in memory somewhere? If
> this is so, there could be a useful efficiency-related modification to
> indirect buffers, which would allow "hard-narrowing": not duplicating the
> rest of the base buffer.

There is no duplication of the buffer content in indirect buffers.
Internally, indirect buffer's content is a pointer to the main buffer
content. If you modify text in any of the indirect buffers or in the
main buffer, the text is modified in all of them and in the main buffer.
Only the buffer-local variables are duplicated.
You can refer to "27.11 Indirect Buffers" in the elisp manual for
details. 

> The next immediately outstanding question is:
> (2) how can "embedding" (of a buffer as a part of another buffer as an
> area) be done efficiently? This could possibly be approached as two
> problems: (i) displaying the area and (ii) interacting with it.
> Any ideas?

These issues have been discussed in
https://lists.gnu.org/archive/html/emacs-devel/2018-07/msg00863.html. As
I remember, the discussion stopped without a clear conclusion. It was
not clear how to separate the main buffer contents from the nested
buffer (I treat them as analogue of the buffer lenses). Another issue
was how the keymaps and buffer-local variables would interact when the
point is within a lense. It was not clear what should be the priority.

Best,
Ihor


Dmitrii Korobeinikov  writes:

> I found a clarification on how mmm-mode works.
>
> https://github.com/polymode/polymode/issues/187
>> mmm-mode also allows having multiple major modes depending on cursor
> position in the buffer. However, it does not fully replace major mode
> locally. This mode is only taking care about keymap, menu, local variables,
> font-lock, and indentation. It does not really take care about the minor
> modes and does not run the submode hooks either.
>
> Just to reiterate, polymode's idea is to switch between indirect buffers,
> one for each major mode.
>
> OK, detail largely disregarded, I now can draw a bird-eye view comparison
> between lenses and multi-mode modes.
>
> - Neither polymode nor mmm-mode treat a region as if it were truly on its
> own in a seperate buffer.
>
> Effects: no stuff like seperate truncation options, implied syntax checking
> and so on.
>
> - Moreover, the region must be a part of the buffer.
>
> Effects: no data sharing between buffers, no possibility of stitching
> different buffers together, etc.
>
> Now, with these out of the way.
>
> Indirect buffers give the answer to the issue of sharing some textual data
> between several buffer.
> (1) A question: when an indirect buffer is created and some region is
> narrowed to, is the rest of the buffer duplicated in memory somewhere? If
> this is so, there could be a useful efficiency-related modification to
> indirect buffers, which would allow "hard-narrowing": not duplicating the
> rest of the base buffer.
>
> The next immediately outstanding question is:
> (2) how can "embedding" (of a buffer as a part of another buffer as an
> area) be done efficiently? This could possibly be approached as two
> problems: (i) displaying the area and (ii) interacting with it.
> Any ideas?

-- 
Ihor Radchenko,