[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eli Zaretskii
Subject: bug#39002: [feature requests] calendar-hebrew [code included]
Date: Tue, 07 Jan 2020 20:48:33 +0200

> Date: Tue, 7 Jan 2020 13:29:27 -0500
> From: Boruch Baum <address@hidden>
> Cc: address@hidden
> > 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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]