D writes:
> I fully understand, though I do believe that this change is beneficial
> to the way org-forward-heading-same-level works overall, in a "principle
> of least astonishment" sort of way.
Yes, that's why I allowed this exception, but still, I think it's best
to leave the FIXME for future
Ihor Radchenko writes:
>> I applied a small variant of it as a700fadd7, thanks.
>>
>> (See also the comment I added with f17d301e1, which basically means
>> that such changes are made as exceptions.)
>
> For record, the old behaviour did not only affect a single external
> package. For example, h
> I applied a small variant of it as a700fadd7, thanks.
>
> (See also the comment I added with f17d301e1, which basically means
> that such changes are made as exceptions.)
For record, the old behaviour did not only affect a single external
package. For example, https://github.com/TonCherAmi/org-s
Hi Bastien,
> I applied a small variant of it as a700fadd7, thanks.
thank you!
> (See also the comment I added with f17d301e1, which basically means
> that such changes are made as exceptions.)
I fully understand, though I do believe that this change is beneficial
to the way org-forward-heading
Hi D,
D writes:
>> Then, can as well use `mapcar', or even simply manual loop over line
>> positions.
>
> How about this?
I applied a small variant of it as a700fadd7, thanks.
(See also the comment I added with f17d301e1, which basically means
that such changes are made as exceptions.)
--
B
> Then, can as well use `mapcar', or even simply manual loop over line
> positions.
How about this?
>From 2324d745f12fe8e8d4f7864307eb55c46fc49504 Mon Sep 17 00:00:00 2001
From: "D. Williams"
Date: Mon, 7 Sep 2020 14:13:12 +0200
Subject: [PATCH] org.el: let heading navigation check the entire hea
> Can you try the attached patch and tell wether it fixes your issue?
The patch will fail in the following headline, because of invisible last
char:
* [[file:test.el][test]]
In general, we can only guarantee that partially visible headline is not
skipped only if we check all the positions. Or we
Hi,
D writes:
>> Does it fix a problem for org-superstar-mode or a more general problem
>> in Org?
>
> It mostly fixes an org-superstar-mode problem (see
> https://github.com/integral-dw/org-superstar-mode/issues/19).
Can you try the attached patch and tell wether it fixes your issue?
>> If yo
Hi,
> Does it fix a problem for org-superstar-mode or a more general problem
> in Org?
It mostly fixes an org-superstar-mode problem (see
https://github.com/integral-dw/org-superstar-mode/issues/19).
> Why do you need to check the visibility status every character in the
> headline (even for the
D writes:
>> Probably, it is easier if you just use seq-every-p instead of
>> mapcar on (number-sequence max-pos min-pos -1). The result of
>> seq-every-p will be inverse of the currently used expression.
>
> Oh yeah, that's much nicer. I also made the predicate check
> right-to-left, which just
> Probably, it is easier if you just use seq-every-p instead of
> mapcar on (number-sequence max-pos min-pos -1). The result of
> seq-every-p will be inverse of the currently used expression.
Oh yeah, that's much nicer. I also made the predicate check
right-to-left, which just causes it to check
> The issue with that is that it reintroduces the thing the patch is
> trying to fix, as it considers any partially invisible line as fully
> invisible (while the opposite should be the case).
Oops. Sorry, I wrote that function without much thinking.
Indeed, it should be
(defun org--line-visible-
>> + (mapcar #'org-invisible-p
>> + (number-sequence (line-beginning-position)
>> + (1- (line-end-position)
>
> This is a bad idea. org--line-visible-p will be called for every single
> invisible headline. If you check every single point at every sin
> + (mapcar #'org-invisible-p
> + (number-sequence (line-beginning-position)
> + (1- (line-end-position)
This is a bad idea. org--line-visible-p will be called for every single
invisible headline. If you check every single point at every single
i
> I do not think that setting visibility the leading stars is a correct
> approach to control the movement commands. After second though about the
> issue you raised in the first email, I think that it would make more
> sense for org-forward-heading-same-level to check if any part of the
> heading
> What I am wondering is whether it would make more sense as an argument
> for org-forward-heading-same-level and similar commands, or as a
> (potentially buffer-local) org variable to tweak the behavior, given
> it's most likely going to affect these functions as interactive commands
> (see altern
> I guess it is simply because nobody though that the leading stars can be
> hidden via fontification.
>
> I think the whole issue can be fixed by changing the call to
> org-invisible-p inside org-forward-heading-same-level. org-invisible-p
> has an optional third argument to ignore text hidden v
> So I thought it is best to ask *why* the
>navigation commands take invisibility into account the way they do,
>and whether you guys have a suggestion that may be more elegant than
>the approach I came up?
I guess it is simply because nobody though that the leading stars can be
hidden via fontifi
18 matches
Mail list logo
