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

[Eli Zaretskii]

> Date: Tue, 7 Jan 2020 13:29:27 -0500
> From: Boruch Baum <boruch_baum@gmx.com>
> Cc: 39002@debbugs.gnu.org
> 
> > 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.

Sorry, I'm still in the dark here.  What is "the LTR heading line"?
what is its text?  (There are quite a few lines in the screenshot
which could be candidates for that description).

Also, you are talking about "lines", but are those logical lines
(i.e. each one ends with a newline), or did Emacs wrap a single long
line?

> > 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.

That function exists because the correct solution isn't obvious.

> > 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.

If they are separate line with newlines between them, I don't see how
the order of the lines could change.  Bidi reordering doesn't reorder
logical lines.

> > IOW, it should not be necessary to change the paragraph direction in
> > these cases.
> 
> But in the current environment, it's much easier.

Maybe, but it doesn't mean it's TRT.  (But I'm not sure I understand
the problem now, so maybe I was talking nonsense.  It would be easier
if you just told me how to activate your code, so I could see the
issues with my own eyes.  I don't use calendar and diary in Emacs, so
I need detailed instructions.)

> 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.

This solution is quite dramatic, so it should be avoided if another,
less dramatic one is possible.

> > >   (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.

Sorry, what does "open a diary page" entail?  Again, I don't use these
features, so I need detailed instructions.

> > 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.

My proposal works on those cases as well.

> 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?

I think it all is relevant, because I'd like to make sure your
bidi-related tricks are indeed the right solutions to the issues you
saw.  So I'd appreciate if you could help me understand better what
were the original problems.

Thanks.