bug#39002: [feature requests] calendar-hebrew [code included]

[Boruch Baum <boruch_baum@gmx.com>]

On 2020-01-07 19:33, Eli Zaretskii wrote:
> > Date: Tue, 7 Jan 2020 12:11:41 -0500
> >
> > Attached is a screenshot displaying three relevant buffers. Below the
> > calendar buffer is the content of my ~/.emacs.d/diary file. Note the
> > sequence of elements: 1) Title line (LTR, implicit; 2) Hebrew date
> > (RTL); 3) sun times (LTR); 4) Parasha (RTL). However, in the diary
> > output buffer, at the bottom of the screen shot, the lines are displayed
> > in the sequence 1,4,2,3.
>
> I don't think I see the part with the 1,4,2,3 order

Look at the sequence of displayed lines in the screenshot - for example,
the first line after the LTR heading line is the parasha RTL line, but
the diary file (the middle buffer) says that the parasha should be the
fourth line, after the sun times.

> did you try to use the function bidi-string-mark-left-to-right?

I don't remember, but I can give it a try. I did play with manually
inserting several unicode bidi control sequences, and none were helpful.

> IIUC the problem, that function was created exactly for these use
> cases, where bidi reordering causes a jumble in what is supposed to be
> columnar display of several substrings.

But these aren't sub-strings, they're discrete paragraphs, as defined by
the bidi regex. Even without the regex redefinition, they are discrete
lines.

> You should wrap each substring in the wrapper produced by
> bidi-string-mark-left-to-right, and then concatenate the results with
> the "|" or whatever separators in-between.

That's doable, but generally burdensome, especially for discrete lines /
paragraphs.

> IOW, it should not be necessary to change the paragraph direction in
> these cases.

But in the current environment, it's much easier. It's the difference of
a one-time setting of a general rule (the bidi paragraph regex), and
having to programmatically perform concatenations for each and every
relevant string in the buffer.

> > That covers bugs B & C. Bug A and a fix for it
> > would be reproduced by applying / removing the hook function at line 372
> > of the previously submitted `cal-ivrit.el'
> >
> >
> >   (defun cal-ivrit-diary-fancy-display-mode-hook-function ()
> >     (setq bidi-paragraph-start-re "^")
> >     (setq bidi-paragraph-separate-re "^"))
> >
> >   (add-hook 'diary-fancy-display-mode-hook
> >     'cal-ivrit-diary-fancy-display-mode-hook-function)
>
> Removing this and then doing what?

With the hook function installed, you can open a diary page and see the
Hebrew lines properly aligned. Without the function, those lines justify
left.

> > For an illustration of emacs bug #15541 (nine+ years old!), see the
> > attached org-mode file.
>
> It is not a bug, it's the intended behavior.

It's marked "won't fix". See the discussion there.

> If you have Org files with such long headings of RTL text, you should
> set the variable bidi-paragraph-direction to nil in that buffer (or
> even to right-to-left, if all of the headings use RTL text).

The common case is a single line Hebrew heading, followed by a window
resize, shrinking the number of columns. I presented a case of very long
headings in order for it to obvious that what is happening is that the
lines are being displayed down-up.

Finally, I don't want to lose focus that this report was primarily a
feature request, with working code submitted. This bug discussion is
important, but if you feel it's worth continuing, should I file it/them
as separate reports?

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0