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