* lisp/org.el (org-copy-visible): Decide whether text is invisible by
calling invisible-p rather than checking whether the invisible
property at point is non-nil.
Text may have a non-nil invisible property but _not_ be hidden from
the user (and thus should be copied by org-copy-visible). For
example, the link itself is shown when org-link-descriptive is nil,
but it still has an invisible property of `org-link'.
* lisp/org.el (org-copy-visible): Don't copy invisible text that
follows invisible text with a different property value.
If org-copy-visible sees that the left bound position has a non-nil
invisible property, it uses next-single-char-property-change to find
the new bound. However, next-single-char-property-change may just
find a bound that still has a _different_ non-nil invisible property.
Reported-by: "Максим Бабушкин" <maxbabushkin@gmail.com>
Link: https://debbugs.gnu.org/49967
* lisp/org.el (org-priority): When reading numeric priorities, provide
special handling of SPC so that it clears the priority, as advertised.
If the user has configured numeric priorities and tries to clear a
priority by inputting SPC at the prompt, org-priority feeds " " to
string-to-number and ends up with 0 instead of the ?\s (32) that's
used downstream to signal "remove". Explicitly check for " " and
translate it to ?\s.
Reported-by: "Bruce E. Robertson" <brucer42@gmail.com>
Link: https://list.orgmode.org/877dch89s1.fsf@kyleam.com/
* lisp/org.el: (org-save-all-org-buffers): Ensure `save-some-buffers' PRED returns boolean.
As of this upstream commit:
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=a9ad3d477441feefa3bf6107d58281cb64e0e78a
`save-some-buffers' will call its PRED argument if it returns a function.
Since (derived-mode-p 'org-mode) returns the symbol org-mode,
and org-mode is a function, org-mode is reloaded in modified Org
buffers when calling `org-save-all-org-buffers'. Among other
undesirable behavior, this will cause the buffer's visibility to be
reset to its initial visibility.
* lisp/org.el (org-do-emphasis-faces): Make sure that we never match
ending marker of an emphasis as a beginning marker of another
emphasis. For example, in "(~-~) test (~+~)" "~) test (~" is a valid
code match unless we move point to the end the first code emphasis
completely during parsing.
Fixes https://orgmode.org/list/87fsujp7mc.fsf@web.de
* lisp/org.el (org-latex-default-packages-alist): Remove grffile and
textcomp from the list of default LaTeX packages to load, as they've
been obsolete for quite a few years now.
* etc/ORG-NEWS: Announce the removal of grffile and textcomp from
`org-latex-default-packages-alist'.
* lisp/org.el (org-fill-element): `mark-whole-buffer' introduced in
7b85a64da is only for interactive use and causes compiler warning.
Replace it using noninteractive commands.
* lisp/org.el (org-display-inline-image--width): Instead of interpreting
an image :width of X% as X pixels, take it as X% of the text width of
the buffer.
* lisp/org.el (org-display-inline-images,
org-display-inline-image--width): Extract the width determination in
`org-display-inline-images' into a new function
`org-display-inline-image--width' where I have taken the opportunity to
refactor the width-determination code.
* lisp/org.el (org-display-inline-images): When the image width is given
as a float less than 2, interpret the value as that portion of the text
area width. This works well with cases such as "#+attr_latex: :width
0.6\linewidth" as this will now be interpreted as 60% of the text area
width. The upper bound is set to 2 not 1, as more than 100% of the text
width can be realistic, e.g. "1.2\linewidth" in LaTeX, but more than
200% seems unrealistic.
* lisp/org.el (org-fontify-extend-region): Fix fontification of
headline or meta line created by inserting a newline.
Unrelated to the fix: `org-fontify-extend-region' is added to
`font-lock-extend-after-change-region-function' and doesn't need to
use `save-excursion'.
* lisp/org.el (org-fontify-meta-lines-and-blocks-1): When this is run on
a src block, a "leaky" major mode called in
`org-src-font-lock-fontify-block' can modify the match data.
This is problematic, as the match data already set is important for
font-lock. To protect ourselves from this behaviour, we can wrap
`org-src-font-lock-fontify-block' in `save-match-data' to ensure that
the match data for the src block is conserved.
* lisp/org.el (org-add-log-setup): Always run `org-add-log-note' via
`post-command-hook'. Otherwise, there is no way to know if a note was
requested for `this-command'. Running `org-add-log-note' directly
would, for example, break `org-auto-repeat-maybe' as reported in [1].
[1] https://orgmode.org/list/CAOn=hbcaW1R6vtun-E2r4LS=j3dp=VjqmjGtzy8UC1SyPArKbA@mail.gmail.com
* lisp/org-src.el (org-src--contents-for-write-back): Do not indent blank lines, except for the
current line maybe.
(org-src--preserve-blank-line): New variable, whether to preserve
indentation of the current blank line.
(org-src--edit-element): Set `org-src--preserve-blank-line'.
* lisp/org.el (org-indent-line): When tab acts natively, do some
preindentation, which signals `org-src--edit-element' to
preserve the indentation of current blank line.
Removing all the whitespace was the original behaviour for all blank lines, before `857ae366b3`.
* lisp/org.el (org-add-log-setup): Always run `org-add-log-note' via
`post-command-hook'. Otherwise, there is no way to know if a note was
requested for `this-command'. Running `org-add-log-note' directly
would, for example, break `org-auto-repeat-maybe' as reported in [1].
* lisp/org-agenda.el (org-agenda-todo): Avoid reintroducing the bug
fixed in c670379adf.
* testing/lisp/test-org.el: Add test checking the reported bug.
[1] https://orgmode.org/list/CAOn=hbcaW1R6vtun-E2r4LS=j3dp=VjqmjGtzy8UC1SyPArKbA@mail.gmail.com
* lisp/org.el (org-get-previous-sibling): Rename from
org-get-last-sibling to be more consistent with the rest of Emacs.
org-get-last-sibling stays as obsolete alias.
* lisp/org.el (org-insert-heading): Fix insertion of headings when
point is before any heading in the case of "respect content" insertion.
Kudos to Victor Stoichita. https://orgmode.org/list/87lf4594t3.fsf@svictor.net/