* bug#39002: [feature requests] calendar-hebrew [code included]
@ 2020-01-07 6:28 Boruch Baum
2020-01-07 15:54 ` Eli Zaretskii
0 siblings, 1 reply; 7+ messages in thread
From: Boruch Baum @ 2020-01-07 6:28 UTC (permalink / raw)
To: 39002
[-- Attachment #1: Type: text/plain, Size: 1758 bytes --]
I've turned to playing with the emacs calendar and diary, and have
several suggestions for its surprisingly good Hebrew support. Attached
is an working elisp proof-of-concept.
Attach: /home/optimum/Projects/emacs-related/calendar-ivrit/cal-ivrit.el cal-ivrit.el
1) sunset-awareness. Currently, emacs does warn the user that a Hebrew
date being presented is for the period midnight-sunset, but its
trivial for emacs to check whether the current time is after sunset
and to increment the date accordingly. In such cases, the date is
labeled `eve of foo' to make it clear that sunset has been taken into
account.
2) Hebrew data in Hebrew. Instead of transliterating Hebrew words into
Latin characters, print them in unicode Hebrew.
2.1) This exposed three bugs in the bidi rendering of the diary buffer:
A) Hebrew text lines in the diary are rendered left justified.
B) Hebrew text lines in the diary are rendered in reverse sequence.
C) RTL and LTR lines are rendered out of sequence to each other.
2.1.1) Bug A can be avoided by locally redefining the regexes that
identify bidi paragraphs, and I've included that in the attached
code.
2.1.2) Bugs B and C may possibly be related to bug #15541.
3) The code includes a generalized function for rendering Hebrew numbers
for Hebrew dates, which is an improvement on a function
`Footnote-hebrew-numeric' submitted in bug report #29759. There
should only be a single function, generically named.
4) Parasha information is presented for the entire week leading up to
its Shabbat reading. Currently, it's only displayed on Saturdays.
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
[-- Attachment #2: cal-ivrit.el --]
[-- Type: text/plain, Size: 16391 bytes --]
;; cal-ivrit.el --- Hebraized Hebrew calendar and diary -*- coding: utf-8; -*-
;; ©2020 Boruch Baum <brouch_baum@gmx.com>, GPL3+, assignable to Free Software Foundation.
;;; Commentary:
;; This extends the existing Hebrew support of the Emacs calendar
;; (`cal-hebrew.el') and diary.
;;
;; * Hebrew data is presented in Hebrew characters.
;;
;; * Sunset awareness for Hebrew dates. Between sunset and midnight,
;; the Hebrew date is incremented, and the dates Hebrew details
;; displayed accordingy, without affecting the secular date.
;;; Installation:
;; * Refer to the installation instructions for packages `calendar'
;; and `diary'. Notably, variables `calendar-latitude' and
;; `calendar-longitude' must be set to the user's location.
;; * Without the following, when Hebrew text lines exist in the
;; diary, they will appear not only left justified, but also out
;; of sequence with LTR lines! Even, so the RTL lines themselves
;; appear in reverse. (TODO: File a bug report for this. It may be
;; related to a BIDI bug I reported years ago regarding org-mode
;; headings).
;;
;; (add-hook 'diary-fancy-display-mode-hook
;; 'cal-ivrit-diary-fancy-display-mode-hook-function)
;;
;; Here's an example of how to create a template for
;; entries to include Hebrew-related material
;;
;; #+NAME: ~/.emacs.d/diary
;; #+BEGIN_EXAMPLE
;; &%%(cal-ivrit-diary-date)
;; &%%(cal-ivrit-diary-parasha)
;; &%%(cal-ivrit-diary-candles)
;;
;; &%%(diary-hebrew-date)
;; &%%(diary-hebrew-omer)
;; &%%(diary-hebrew-parasha)
;; &%%(diary-hebrew-rosh-hodesh)
;; &%%(diary-hebrew-sabbath-candles)
;; &%%(diary-lunar-phases)
;; &%%(diary-sunrise-sunset)
;; #+END_EXAMPLE
;;; Developer notes:
;; Implementation options:
;; 1) Integrate these functions directly into the current
;; `cal-hebrew.el' equivalents by modifying those functions to
;; branch based upon the value of `calendar-hebrew-in-ivrit'.
;;
;; 2) Create a minor mode `calendar-hebrew-in-ivrit' that advises
;; around the functions of `cal-hebrew.el'.
;;
;; 3) Keep the two packages totally separate. Easiest for the
;; developers and most burdensome for a user intent on switching
;; back and forth.
;;
;; (cond
;; (calendar-hebrew-in-ivrit
;; (advice-add 'calendar-hebrew-date-string :around #'cal-ivrit-date-string))
;; (advice-add #'cal-ivrit-print-date
;; (t
;; (advice-remove 'calendar-hebrew-date-string #'cal-ivrit-date-string)))
;; Code duplication:
;; Variables `hebrew-numeric-regex' and `hebrew-numeric' are
;; duplications of variables `footnote-hebrew-numeric-regex' and
;; `footnote-hebrew-numeric', and function `hebrew-numeric' is
;; basically a duplicate of function `Footnote-hebrew-numeric', the
;; only difference being the option to add single/double
;; apostrophes. Consider refactoring the footnote versions, and
;; moving these to a generic hebrew support elisp file.
;; Advised functions:
;; The option to implement many/most/all/? of the features of this
;; package as advices around existing functions was made in order
;; to make it easy for the user to toggle between this Hebrew
;; language version and the default native language version. The
;; design is that the user need only change the boolean variable
;; `calendar-hebrew-in-ivrit' for this morsel of instant
;; gratification.
;;
;; calendar-hebrew-date-string -> cal-ivrit-date-string
;; diary-hebrew-parasha -> cal-ivrit-diary-parasha (NOT DONE!!)
;;; Code:
; (require 'calendar) ; Redundant. Brought in by `cal-hebrew'
(require 'cal-hebrew)
;;; Defcustoms:
(defcustom calendar-hebrew-in-ivrit t
"Whether to display Hebrew data in Hebrew."
:type 'boolean)
;;; Constants:
(defconst cal-ivrit-month-name-array-for-common-year
["ניסן" "אייר" "סיון" "תמוז" "אב" "אלול"
"תשרי" "חשון" "כסלו" "טבת" "שבט" "אדר"])
(defconst cal-ivrit-month-name-array-for-leap-year
["ניסן" "אייר" "סיון" "תמוז" "אב" "אלול"
"תשרי" "חשון" "כסלו" "טבת" "שבט" "אדר א" "אדר ב"])
(defconst cal-ivrit-day-name-array
["ראשון" "שני" "שלישי" "רביעי" "חמישי" "שישי" "שבת"])
(defconst cal-ivrit-day-name-array-ivrit
["יום א" "יום ב" "יום ג" "יום ד" "יום ה" "יום ו" "שבת"])
(defconst cal-ivrit-day-abbrev-array
["א'" "ב'" "ג'" "ד'" "ה'" "ו'" "ז'"])
(defconst cal-ivrit-day-header-array
["א" "ב" "ג" "ד" "ה" "ו" "ש"])
(defconst cal-ivrit-parashiot-names
["בראשית" "נוח" "לך לך" "וירא" "חיי שרה" "תולדות"
"ויצא" "וישלח" "וישב" "מקץ" "ויגש" "ויחי"
"שמות" "וארא" "בא" "בשלח" "יתרו" "משפטים"
"תרומה" "תצוה" "כי תשא" "ויקהל" "פקודי" "ויקרא"
"צו" "שמיני" "תזריע" "מצורע" "אחרי מות" "קדושים"
"אמור" "בהר" "בחקותי" "במדבר" "נשא" "בהעלתך"
"שלח לך" "קרח" "חקת" "בלק" "פנחס" "מטות"
"מסעי" "דברים" "ואתחנן" "עקב" "ראה" "שופטים"
"כי תצא" "כי תבוא" "נצבים" "וילך" "האזינו"]
"The names of the parashiot in the Torah, in Hebrew.")
(defconst cal-ivrit--jm-lat 31.77
"Lattitude for Jerusalem")
(defconst cal-ivrit--jm-long 35.22
"Lattitude for Jerusalem")
;;; Generic Hebrew utility constants and functions
(defconst hebrew-numeric-regex "[אבגדהוזחטיכלמנסעפצקרשת']+")
; (defconst hebrew-numeric-regex "\\([אבגדהוזחט]'\\)?\\(ת\\)?\\(ת\\)?\\([קרשת]\\)?\\([טיכלמנסעפצ]\\)?\\([אבגדהוזחט]\\)?")
(defconst hebrew-numeric '(
("א" "ב" "ג" "ד" "ה" "ו" "ז" "ח" "ט")
("י" "כ" "ל" "מ" "נ" "ס" "ע" "פ" "צ")
("ק" "ר" "ש" "ת" "תק" "תר"" תש" "תת" "תתק")))
;;;###cal-autoload
(defun hebrew-numeric(n &optional quote)
"Convert a base 10 Western number to it Hebrew character equivalent.
With QUOTE non-nil, include customary single or double quotes."
(let*
((quote (if quote "'" ""))
(n (+ (mod n 10000) (/ n 10000)))
(thousands (/ n 1000))
(hundreds (/ (mod n 1000) 100))
(tens (/ (mod n 100) 10))
(units (mod n 10))
(special (if (not (= tens 1)) nil
(or (when (= units 5) "טו")
(when (= units 6) "טז"))))
(result
(concat
(when (/= 0 thousands) (concat (nth (1- thousands) (nth 0 hebrew-numeric)) quote))
(when (/= 0 hundreds) (nth (1- hundreds) (nth 2 hebrew-numeric)))
(if special special
(concat
(when (/= 0 tens) (nth (1- tens) (nth 1 hebrew-numeric)))
(when (/= 0 units) (nth (1- units) (nth 0 hebrew-numeric))))))))
(cond
((= 1 (length result))
(concat result quote))
((string-match "'" result -2)
result)
(t
(concat (substring result 0 -1) (if quote "\"" "") (substring result -1))))))
;; Calendar functions
;; ;;;###cal-autoload
;; (defun cal-ivrit-location-checking ()
;; "Use Jerusalem if the system coordinates are invalid."
;; (message "Boruch 1")
;; (when (or (not calendar-latitude)
;; (> calendar-latitude 90)
;; (< calendar-latitude -90)
;; (not calendar-longitude)
;; (> calendar-longitude 180)
;; (< calendar-longitude -180))
;; (lwarn 'calendar-hebrew ":warning"
;; "Invalid calendar-lattitude/longitude %d/%d"
;; calendar-latitude calendar-longitude)
;; (message "Boruch 2")
;; (make-local-variable 'calendar-latitude)
;; (make-local-variable 'calendar-longitude)
;; (make-local-variable 'calendar-location-name)
;; (setq calendar-latitude cal-ivrit--jm-lat)
;; (setq calendar-longitude cal-ivrit--jm-long)
;; (setq calendar-location-name "ירושלים")))
;; ;; Um. This doesn't seem the right way to do this...
;; (add-hook 'calendar-mode-hook 'cal-ivrit-location-checking)
;; (add-hook 'diary-fancy-display-mode-hook 'cal-ivrit-location-checking)
;; ;; And, it doesn't work!
;; ;; + calendar calls solar.. before running the hook, so nil's cause an error/crash
;;;###cal-autoload
(defun cal-ivrit-date-string (&optional orig-fun date)
"Display a Hebrew date in a native Hebrew format.
The ORIG-FUN argument exists to allow this function to be advised
around function `calendar-hebrew-date-string'.
If DATE is nil, the current date is assumed.
Note that the native Hebrew format will often differ from
`calendar-date-display-form'."
;; Programming note: The code here is an adaptation of functions
;; `calendar-hebrew-date-string' and `calendar-date-string'.
(if (not calendar-hebrew-in-ivrit)
(apply orig-fun date)
(let* ((this-date (copy-tree (or date (calendar-current-date))))
(eve (if (not (equal this-date (calendar-current-date)))
""
(let ((sunset (caadr (solar-sunrise-sunset (calendar-current-date))))
(hour (string-to-number(format-time-string "%H"))))
(if (and sunset
(or (> hour (truncate sunset))
(and (= (truncate sunset) hour)
(> (string-to-number (format-time-string "%M") )
(truncate (* 60 (mod sunset 1)))))))
(and (incf (nth 1 this-date))
"ליל ") ; alternatively: "אור ליום " ; English: "eve of"
""))))
(hebrew-date (calendar-hebrew-from-absolute
(calendar-absolute-from-gregorian this-date)))
(calendar-month-name-array
(if (calendar-hebrew-leap-year-p (calendar-extract-year hebrew-date))
cal-ivrit-month-name-array-for-leap-year
cal-ivrit-month-name-array-for-common-year))
(calendar-day-name-array cal-ivrit-day-name-array-ivrit)
(calendar-day-abbrev-array cal-ivrit-day-abbrev-array)
(calendar-day-header-array cal-ivrit-day-header-array)
;; `abbreviate' and `nodayname' are optional args for function
;; `calendar-date-string'. Consider allowing those options
;; here, but for now hard-code defaults.
(abbreviate nil)
(nodayname t)
(dayname (unless nodayname (calendar-day-name hebrew-date)))
(month (calendar-extract-month hebrew-date))
(monthname (calendar-month-name month abbreviate))
(day (hebrew-numeric (calendar-extract-day hebrew-date) t))
(month (hebrew-numeric month t))
(year (substring (hebrew-numeric (calendar-extract-year hebrew-date) t) 2)))
(concat eve (when dayname (concat dayname ", "))
day " " monthname ", " year))))
;;;###cal-autoload
(defun cal-ivrit-parasha-name (p)
"Name(s) corresponding to parasha P."
(if (arrayp p) ; combined parasha
(format "%s/%s"
(aref cal-ivrit-parashiot-names (aref p 0))
(aref cal-ivrit-parashiot-names (aref p 1)))
(aref cal-ivrit-parashiot-names p)))
;;;###cal-autoload
(defun cal-ivrit-print-date ()
"Display in the echo area the Hebrew date at the cursor position."
(interactive)
(message "תאריך: %s"
(cal-ivrit-date-string nil (calendar-cursor-to-date t))))
;;; Diary functions
;; To be called from diary-list-sexp-entries, where DATE is bound.
;;;###diary-autoload
(defun cal-ivrit-diary-date ()
"Hebrew calendar equivalent of date diary entry, in Hebrew."
;; Note the leading space (See commentary/developer notes/RTL)
(format " תאריך: %s" (cal-ivrit-date-string nil date)))
;; To be called from diary-list-sexp-entries, where DATE is bound.
;;;###diary-autoload
(defun cal-ivrit-diary-parasha (&optional mark)
"Fancy diary entry for the Hebrew parasha, in Hebrew.
An optional parameter MARK specifies a face or single-character
string to use when highlighting the day in the calendar.
Note that unlike `diary-hebrew-parasha', this function displays a
Parasha name every day of the week."
(let* ((d (calendar-absolute-from-gregorian (or date (calendar-current-date))))
(shabbat (if (= (% d 7) 6)
""
(setq d (+ d 7))
" שבת"))
(h-year (calendar-extract-year
(calendar-hebrew-from-absolute d)))
(rosh-hashanah
(calendar-hebrew-to-absolute (list 7 1 h-year)))
(passover
(calendar-hebrew-to-absolute (list 1 15 h-year)))
(rosh-hashanah-day
(aref calendar-day-name-array (% rosh-hashanah 7)))
(passover-day
(aref calendar-day-name-array (% passover 7)))
(long-h (calendar-hebrew-long-heshvan-p h-year))
(short-k (calendar-hebrew-short-kislev-p h-year))
(type (cond ((and long-h (not short-k)) "complete")
((and (not long-h) short-k) "incomplete")
(t "regular")))
(year-format
(symbol-value
(intern (format "calendar-hebrew-year-%s-%s-%s" ; keviah
rosh-hashanah-day type passover-day))))
(first-saturday ; of Hebrew year
(calendar-dayname-on-or-before 6 (+ 6 rosh-hashanah)))
(saturday ; which Saturday of the Hebrew year
(/ (- d first-saturday) 7))
(parasha (aref year-format saturday)))
(if parasha
(cons mark
(format
;; Note the leading space (See commentary/developer notes/RTL)
"%s פרשת %s"
shabbat
(if (listp parasha) ; Israel differs from diaspora
(if (car parasha)
(format "%s (חו\"ל), %s (א\"י)"
(cal-ivrit-parasha-name
(car parasha))
(cal-ivrit-parasha-name
(cdr parasha)))
(format "%s (א\"י)"
(cal-ivrit-parasha-name
(cdr parasha))))
(cal-ivrit-parasha-name parasha)))))))
;; To be called from diary-list-sexp-entries, where DATE is bound.
;;;###diary-autoload
(defun cal-ivrit-diary-candles (&optional mark)
"Diary entry for candle lighting time on Sabbath and Holiday eves.
No diary entry if there is no sunset on that date. Uses
`diary-hebrew-sabbath-candles-minutes'.
An optional parameter MARK specifies a face or single-character string to
use when highlighting the day in the calendar."
(require 'solar)
(or (and calendar-latitude calendar-longitude calendar-time-zone)
(solar-setup))
(if (= (% (calendar-absolute-from-gregorian date) 7) 5) ; Friday
(let ((sunset (cadr (solar-sunrise-sunset date))))
(if sunset
(cons mark (format
" הדלקת נרות: %s"
(apply 'solar-time-string
(cons (- (car sunset)
(/ diary-hebrew-sabbath-candles-minutes
60.0))
(cdr sunset)))))))))
;;;###diary-autoload
(defun cal-ivrit-diary-fancy-display-mode-hook-function ()
(setq bidi-paragraph-start-re "^")
(setq bidi-paragraph-separate-re "^"))
;; TODO:
;;
;; + cal-ivrit-diary-candles
;; + erev chag
;; + second-day yom-tov / Sunday yom-tov
;;+ todo for hebraization:
;; (diary-lunar-phases)
;; (diary-hebrew-omer)
;; (diary-hebrew-rosh-hodesh)
;; (diary-sunrise-sunset)
(provide 'cal-ivrit)
;;; cal-ivrit.el ends here
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#39002: [feature requests] calendar-hebrew [code included]
2020-01-07 6:28 bug#39002: [feature requests] calendar-hebrew [code included] Boruch Baum
@ 2020-01-07 15:54 ` Eli Zaretskii
2020-01-07 17:11 ` Boruch Baum
0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2020-01-07 15:54 UTC (permalink / raw)
To: Boruch Baum; +Cc: 39002
> Date: Tue, 7 Jan 2020 01:28:30 -0500
> From: Boruch Baum <boruch_baum@gmx.com>
>
> 2.1) This exposed three bugs in the bidi rendering of the diary buffer:
>
> A) Hebrew text lines in the diary are rendered left justified.
>
> B) Hebrew text lines in the diary are rendered in reverse sequence.
>
> C) RTL and LTR lines are rendered out of sequence to each other.
>
> 2.1.1) Bug A can be avoided by locally redefining the regexes that
> identify bidi paragraphs, and I've included that in the attached
> code.
>
> 2.1.2) Bugs B and C may possibly be related to bug #15541.
I'm interested to understand better these problems. Please give
detailed instructions for how to reproduce them with your calendar
code, or show a screenshot, because I don't think I understand well
enough from the above description what the display looks like.
Thanks.
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#39002: [feature requests] calendar-hebrew [code included]
2020-01-07 15:54 ` Eli Zaretskii
@ 2020-01-07 17:11 ` Boruch Baum
2020-01-07 17:33 ` Eli Zaretskii
0 siblings, 1 reply; 7+ messages in thread
From: Boruch Baum @ 2020-01-07 17:11 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 39002
[-- Attachment #1: Type: text/plain, Size: 1955 bytes --]
On 2020-01-07 17:54, Eli Zaretskii wrote:
> > Date: Tue, 7 Jan 2020 01:28:30 -0500
> > From: Boruch Baum <boruch_baum@gmx.com>
> >
> > 2.1) This exposed three bugs in the bidi rendering of the diary buffer:
> >
> > A) Hebrew text lines in the diary are rendered left justified.
> >
> > B) Hebrew text lines in the diary are rendered in reverse sequence.
> >
> > C) RTL and LTR lines are rendered out of sequence to each other.
> >
> > 2.1.1) Bug A can be avoided by locally redefining the regexes that
> > identify bidi paragraphs, and I've included that in the attached
> > code.
> >
> > 2.1.2) Bugs B and C may possibly be related to bug #15541.
>
> I'm interested to understand better these problems. Please give
> detailed instructions for how to reproduce them with your calendar
> code, or show a screenshot, because I don't think I understand well
> enough from the above description what the display looks like.
>
> Thanks.
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. 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)
For an illustration of emacs bug #15541 (nine+ years old!), see the
attached org-mode file.
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
[-- Attachment #2: emacs_bug_report_39002.png --]
[-- Type: image/png, Size: 39290 bytes --]
[-- Attachment #3: emacs_bug_15541.org --]
[-- Type: text/plain, Size: 2866 bytes --]
-*- mode:org; mode:visual-line; -*-
* demonstration of emacs bug 15541
Here are two Hebrew RTL text paragraphs, taken from today's HaAretz:
נשיא פולין, אנדז'יי דודה, הודיע היום (שלישי) כי יחרים את הטקס לזכר
השואה שייערך בסוף החודש ביד ושם, בטענה שלא הורשה לנאום במהלכו. הוא
הוסיף כי הוא אינו מקבל את העובדה שנציגי רוסיה, צרפת, בריטניה, גרמניה
וארה"ב ינאמו בטקס בעוד הוא לא. שלשום דרש דודה לשאת דברים באירוע, והתנה
בכך את השתתפותו. השבוע פורסם בתקשורת הפולנית כי דודה שוקל לבטל את
הגעתו בשל חשש שנשיא רוסיה, ולדימיר פוטין, ינצל את הבמה בטקס כדי לתקוף
את פולין.
דודה אמר שלשום בריאיון לטלוויזיה הממלכתית בפולין כי הוא "נציג של
המדינה שאיבדה הכי הרבה אנשים" במחנה ההשמדה אושוויץ. לפי נתוני אתר
ההנצחה של יד ושם, באושוויץ נרצחו 1.1 מיליון בני אדם, מתוכם כמיליון היו
יהודים. שאר הקורבנות היו פולנים (כ-70 אלף), צוענים (כ-21 אלף), אסירי
מלחמה סובייטיים (כ-14 אלף) ובני לאומים אחרים.
Now look how those two paragraphs display when used as org-mode headings:
** נשיא פולין, אנדז'יי דודה, הודיע היום (שלישי) כי יחרים את הטקס לזכר השואה שייערך בסוף החודש ביד ושם, בטענה שלא הורשה לנאום במהלכו. הוא הוסיף כי הוא אינו מקבל את העובדה שנציגי רוסיה, צרפת, בריטניה, גרמניה וארה"ב ינאמו בטקס בעוד הוא לא. שלשום דרש דודה לשאת דברים באירוע, והתנה בכך את השתתפותו. השבוע פורסם בתקשורת הפולנית כי דודה שוקל לבטל את הגעתו בשל חשש שנשיא רוסיה,ולדימיר פוטין, ינצל את הבמה בטקס כדי לתקוף את פולין.
** דודה אמר שלשום בריאיון לטלוויזיה הממלכתית בפולין כי הוא "נציג של המדינה שאיבדה הכי הרבה אנשים" במחנה ההשמדה אושוויץ. לפי נתוני אתר ההנצחה של יד ושם, באושוויץ נרצחו 1.1 מיליון בני אדם, מתוכם כמיליון היו יהודים. שאר הקורבנות היו פולנים (כ-70 אלף), צוענים (כ-21 אלף), אסירי מלחמה סובייטיים (כ-14 אלף) ובני לאומים אחרים.
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#39002: [feature requests] calendar-hebrew [code included]
2020-01-07 17:11 ` Boruch Baum
@ 2020-01-07 17:33 ` Eli Zaretskii
2020-01-07 18:29 ` Boruch Baum
0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2020-01-07 17:33 UTC (permalink / raw)
To: Boruch Baum; +Cc: 39002
> Date: Tue, 7 Jan 2020 12:11:41 -0500
> From: Boruch Baum <boruch_baum@gmx.com>
> Cc: 39002@debbugs.gnu.org
>
> 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 (sorry if I'm
blind), but did you try to use the function
bidi-string-mark-left-to-right? 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. 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.
IOW, it should not be necessary to change the paragraph direction in
these cases.
> 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?
> 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. 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).
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#39002: [feature requests] calendar-hebrew [code included]
2020-01-07 17:33 ` Eli Zaretskii
@ 2020-01-07 18:29 ` Boruch Baum
2020-01-07 18:48 ` Eli Zaretskii
0 siblings, 1 reply; 7+ messages in thread
From: Boruch Baum @ 2020-01-07 18:29 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 39002
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#39002: [feature requests] calendar-hebrew [code included]
2020-01-07 18:29 ` Boruch Baum
@ 2020-01-07 18:48 ` Eli Zaretskii
2020-01-07 19:49 ` Boruch Baum
0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2020-01-07 18:48 UTC (permalink / raw)
To: Boruch Baum; +Cc: 39002
> 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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#39002: [feature requests] calendar-hebrew [code included]
2020-01-07 18:48 ` Eli Zaretskii
@ 2020-01-07 19:49 ` Boruch Baum
0 siblings, 0 replies; 7+ messages in thread
From: Boruch Baum @ 2020-01-07 19:49 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 39002
On 2020-01-07 20:48, Eli Zaretskii wrote:
> > 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?
Tuesday, January 7, 2020: Tzom Teveth
======================================
> Also, you are talking about "lines", but are those logical lines
> (i.e. each one ends with a newline),
It seems so, since altering the bidi paragraph regex alters the
justification.
> or did Emacs wrap a single long line?
Good question. How could I tell the difference? Wouldn't the buffer
result look the same?
> > > 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.
... ok ... but you do have the screenshot figuratively staring right
back at you ... that is the essence of the bugs reported.
> > > 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.)
The code I sent along with the original report includes the customary
commentary section with installation notes / instructions / etc.
Evaluate that file. Set variables `calendar-longitude',
`calendar-latitude', and `calendar-location'. I think also that variable
`diary-display-function' may need to be set to ‘diary-fancy-display'.
Add the hook function as described there and in my previous post(s?).
The commentary section also includes sample content for what you need to
put in ~/.emacs.d/diary (the middle third of the screenshot I sent), but
you see the content used in the screenshot I sent, which is slightly
different. Then start the calendar with .... `M-x calendar` (!). That
would be the top third of the screenshot I sent. Use the arrow keys to
navigate dates in the display, and press `d' to open a diary page for
the currently selected date (That would be the bottom third of the
much-cited screenshot). Edit ~/.emacs.d/diary to change what the diary
page will display.
> I don't use calendar and diary in Emacs, so I need detailed
> instructions.)
The calendar.el and diary-lib.el packages each say their author is
Edward M. Reingold <reingold@cs.uiuc.edu>, and their maintainer is
Glenn Morris><rgm@gnu.org>. Can they suckered into this thread?
> > 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.
I also had trouble getting up to speed on these features (#38859,
#38866). I explained the procedure in detail above, but briefly: 'M-x
calendar', followed by 'd'.
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-01-07 19:49 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-01-07 6:28 bug#39002: [feature requests] calendar-hebrew [code included] Boruch Baum
2020-01-07 15:54 ` Eli Zaretskii
2020-01-07 17:11 ` Boruch Baum
2020-01-07 17:33 ` Eli Zaretskii
2020-01-07 18:29 ` Boruch Baum
2020-01-07 18:48 ` Eli Zaretskii
2020-01-07 19:49 ` Boruch Baum
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.