[PATCH v2] org-agenda: Use `window-max-chars-per-line' to calculate max text width
"N. Jackson" writes: > (- (window-text-width)) > ^ > > Changing window-text-width to window-max-chars-per-line fixes the > problem here and seems like the right thing to do. Sounds reasonable. Attaching the updated patch. Best, Ihor >From 5251305db6032a4a10f337fe13c519cee6d0fb94 Mon Sep 17 00:00:00 2001 Message-Id: <5251305db6032a4a10f337fe13c519cee6d0fb94.1650606943.git.yanta...@gmail.com> From: Ihor Radchenko Date: Thu, 21 Apr 2022 13:18:39 +0800 Subject: [PATCH] org-agenda: Use `window-max-chars-per-line' to calculate max text width * lisp/org-agenda.el (org-agenda-prepare): (org-todo-list): (org-agenda-align-tags): (org-agenda-show-new-time): Calculate the maximum number of chars fitting into window via `window-max-chars-per-line' instead of `window-with' or `window-text-with'. The latter functions can return larger number when fringes are disabled [1]. [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19395 Reported in https://orgmode.org/list/87czhdqi9p.fsf_-_@moondust.localdomain --- lisp/org-agenda.el | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index a09b53563..0f656a6ad 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -3925,7 +3925,7 @@ (defun org-agenda-prepare ( name) (insert "\n" (if (stringp org-agenda-block-separator) org-agenda-block-separator - (make-string (window-width) org-agenda-block-separator)) + (make-string (window-max-chars-per-line) org-agenda-block-separator)) "\n")) (narrow-to-region (point) (point-max))) (setq org-done-keywords-for-agenda nil) @@ -4944,7 +4944,7 @@ (defun org-todo-list ( arg) (let ((n 0)) (dolist (k kwds) (let ((s (format "(%d)%s" (cl-incf n) k))) - (when (> (+ (current-column) (string-width s) 1) (window-width)) + (when (> (+ (current-column) (string-width s) 1) (window-max-chars-per-line)) (insert "\n ")) (insert " " s (insert "\n")) @@ -10032,8 +10032,8 @@ (defun org-agenda-align-tags ( line) current line." (let ((inhibit-read-only t) (org-agenda-tags-column (if (eq 'auto org-agenda-tags-column) -(- (window-text-width)) - org-agenda-tags-column)) + (- (window-max-chars-per-line)) + org-agenda-tags-column)) (end (and line (line-end-position))) l c) (save-excursion @@ -10301,10 +10301,7 @@ (defun org-agenda-show-new-time (marker stamp prefix) (line-end-position) '(display nil)) (org-move-to-column - (- (if (fboundp 'window-font-width) - (/ (window-width nil t) (window-font-width)) -;; Fall back to pre-9.3.3 behavior on Emacs <25. -(window-width)) + (- (window-max-chars-per-line) (length stamp)) t) (add-text-properties -- 2.35.1
Re: Fix M-j with default fill-prefix value
Javier Olaechea writes: > org-comment-line-break-function does not handle fill-prefix being set to > nil, which is the default value for fill-prefix. This means that pressing > M-j inside an org-mode buffer in a vanilla installation of Emacs results in > an error. From looking at other callers of > insert-before-markers-and-inherit it is clear that a guard against > fill-prefix being nil is missing. I guess this is fine to fix the immediate error, but I do not see much point in the whole org-comment-line-break function. AFAIU, it does not even recognise whether we are inside comment or not. I just tried to use the default comment-indent-new-line and it correctly indents paragraphs and also comments. On the other hand, it does not indent item lists and src-blocks. Rather than applying this patch I would remove org-comment-line-break-function alltogether. It will already be better than the current state. Alternatively, it should be rewritten to take into account current element context, similar to org-insert-comment. Best, Ihor
Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones
> Date: Thu, 21 Apr 2022 16:56:25 -0700 > Cc: maniku...@gmail.com, emacs-orgmode@gnu.org, 54...@debbugs.gnu.org, > bug-gnu...@gnu.org > From: Paul Eggert > > What appears to be happening here is that the MS-Windows native > timestamp resolution is 1/64th of a second, and your system's clock is > offset by 0.0075 s from an integer boundary. I.e., the timestamps in > increasing order are: > >... >1650522862 + 62/64 + 0.0075 = 1650522862.976250 >1650522862 + 63/64 + 0.0075 = 1650522862.991875 >1650522863 + 0/64 + 0.0075 = 1650522863.007500 >1650522863 + 1/64 + 0.0075 = 1650522863.023125 >1650522863 + 2/64 + 0.0075 = 1650522863.038750 >... > > and the system clock never returns a timestamp on an integer boundary > (i.e., tv_nsec is never zero). > > We have two options to express this as Emacs timestamps: > > (1) We can keep information about resolution but lose information about > time, by using a resolution of 15.625 ms (i.e., 1/64 s) and truncating > timestamps to the nearest 1/64 second. This would generate the > following (TICKS . HZ) timestamps: > >... >(105633463230 . 64) = 1650522862 + 62/64 = 1650522862.968750 >(105633463231 . 64) = 1650522862 + 63/64 = 1650522862.984375 >(105633463232 . 64) = 1650522863 + 0/64 = 1650522863.00 >(105633463233 . 64) = 1650522863 + 1/64 = 1650522863.015625 >(105633463234 . 64) = 1650522863 + 2/64 = 1650522863.031250 >... > > (2) We can keep information about time but lose information about the > resolution, by using a resolution of 0.625 ms (i.e., HZ = 10 / > 625000 = 16000). (We use 0.625 ms because it is the coarsest resolution > that does not lose time info.) This would generate the following (TICKS > . HZ) timestamps: > >... >(2640836580762 . 1600) = 1650522862 + 1562/1600 = 1650522862.976250 >(2640836580762 . 1600) = 1650522862 + 1587/1600 = 1650522862.991875 >(2640836580762 . 1600) = 1650522863 + 12/1600 = 1650522863.007500 >(2640836580762 . 1600) = 1650522863 + 37/1600 = 1650522863.023125 >(2640836580762 . 1600) = 1650522863 + 62/1600 = 1650522863.038750 >... > > The patch does (2), and this explains the "gettime_res returned 625000 > ns" in your output. > > It shouldn't be hard to change the patch to do (1), if desired. I doubt > whether users will care one way or the other. These are very fine details of the implementation, which we can get back to later. I would like first to discuss the more general issue of basing the design on such tests, and on the notion of "clock resolution" as expressed by these tests. TBH, what you propose makes no sense to me for now, and for some reason you didn't answer my more general questions about that, but instead preferred to respond only to their secondary aspects. At this point, I object to any changes in this area until we discuss the more general aspects of this design and decide whether we agree with it. Such a discussion should be on emacs-devel, so I move this there; please continue the discussion there. Thanks.
Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones
What appears to be happening here is that the MS-Windows native timestamp resolution is 1/64th of a second, and your system's clock is offset by 0.0075 s from an integer boundary. I.e., the timestamps in increasing order are: ... 1650522862 + 62/64 + 0.0075 = 1650522862.976250 1650522862 + 63/64 + 0.0075 = 1650522862.991875 1650522863 + 0/64 + 0.0075 = 1650522863.007500 1650522863 + 1/64 + 0.0075 = 1650522863.023125 1650522863 + 2/64 + 0.0075 = 1650522863.038750 ... and the system clock never returns a timestamp on an integer boundary (i.e., tv_nsec is never zero). We have two options to express this as Emacs timestamps: (1) We can keep information about resolution but lose information about time, by using a resolution of 15.625 ms (i.e., 1/64 s) and truncating timestamps to the nearest 1/64 second. This would generate the following (TICKS . HZ) timestamps: ... (105633463230 . 64) = 1650522862 + 62/64 = 1650522862.968750 (105633463231 . 64) = 1650522862 + 63/64 = 1650522862.984375 (105633463232 . 64) = 1650522863 + 0/64 = 1650522863.00 (105633463233 . 64) = 1650522863 + 1/64 = 1650522863.015625 (105633463234 . 64) = 1650522863 + 2/64 = 1650522863.031250 ... (2) We can keep information about time but lose information about the resolution, by using a resolution of 0.625 ms (i.e., HZ = 10 / 625000 = 16000). (We use 0.625 ms because it is the coarsest resolution that does not lose time info.) This would generate the following (TICKS . HZ) timestamps: ... (2640836580762 . 1600) = 1650522862 + 1562/1600 = 1650522862.976250 (2640836580762 . 1600) = 1650522862 + 1587/1600 = 1650522862.991875 (2640836580762 . 1600) = 1650522863 + 12/1600 = 1650522863.007500 (2640836580762 . 1600) = 1650522863 + 37/1600 = 1650522863.023125 (2640836580762 . 1600) = 1650522863 + 62/1600 = 1650522863.038750 ... The patch does (2), and this explains the "gettime_res returned 625000 ns" in your output. It shouldn't be hard to change the patch to do (1), if desired. I doubt whether users will care one way or the other. > don't we use time values for file timestamps? Yes, but file timestamps should use the resolution of the file system, which in general is different from the resolution of the system clock. That's a separate matter, which would be the subject of a separate patch. For now we can stick with what we already have in that department. > And for Windows, all this does is measure the "resolution" of the > Gnulib emulation of timespec functions on MS-Windows, it tells nothing > about the real resolution of the system time values. If Emacs Lisp code (which currently is based on the Gnulib code) can see only (say) 1-microsecond timestamps, then it doesn't matter that the underlying system clock has (say) 1-nanosecond precision. Of course it would be better for Emacs to see the system timestamp resolution, and if we can get the time of day on MS-Windows to a precision better than 1/64 second then I assume Emacs should do that. Once it does, the patch should calculate a higher HZ value to tell users about the improved resolution. > if the "time resolution" determined by this procedure > is different between two systems, does it mean that two time values > that are 'equal' on one of them could be NOT 'equal' on another? Sure, but the traditional (HIGH LOW MICROSEC PICOSEC) representation has the same issue. For example, if A's clock has 1 ms resolution and B's clock has 10 ms resolution, A's (time-convert nil 'list) called twice would return (say) the two timestamps (25184 64239 1000 0) and (25184 64239 1001 0) at the same moments that B's calls would return (25184 64239 1000 0) twice. A would say that the two timestamps differ; B would say they're the same. This sort of disagreement is inherent to how timestamp resolution works. It doesn't matter whether the timestamps are represented by (HIGH LOW MICROSEC PICOSEC) or by (TICKS . HZ); users will run into the same problem in both cases.
[RESOLVED] Re: gnus links not followed, also avl-tree error (org-capture issues)
The avl-tree error was an issue with vertico, which I updated and it went away. The Gnus Links error seems to have gone away with that updgrade, too. Thanks! - Tory Ihor Radchenko writes: > "Tory S. Anderson" writes: > >>> Thanks for reporting! Are you able to reproduce with emacs -Q? >> >> Thanks! I am not sure what an emacs -Q would mean in cases like this, since >> they are custom written capture templates in the first place, so -Q would >> lose them. > > Please refer to https://orgmode.org/manual/Feedback.html > Basically, you can create the minimal possible config containing your > problematic custom capture template and whatever it takes to trigger the > problem and share it + steps to reproduce. > > Otherwise, it is very difficult to debug the problem on our side. > >> Important update: By including all of org-contrib the two problems go away, >> although other problems are introduced. But trying to search the contrib for >> which things in particular are solving these errors has not been successful. > > You may try to bisect your config. I have recorded a video explaining > how to do it: > https://open.tube/videos/watch/4d819114-43bf-42df-af94-f94fc53dd0d9 > > Best, > Ihor
Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones
On 17/04/2022 02:23, Paul Eggert wrote: On 4/15/22 10:23, Max Nikulin wrote: if you are storing future events bound to wall time then namely time zone identifier should have precedence. Although that would make sense for some applications it's not a good idea in general. For example, if you're scheduling a Zoom meeting you should save both, because other meeting participants may interpret strings like "Pacific/Apia" differently. I would say that in such cases there is a primary time zone for such event and secondary time zones of other participants. Time transitions in the primary time zone (unless it is UTC that is the reference) affect participants from all other time zones. If some secondary time zone is changed then it affects only wall time in this particular time zone. So primary timezone and offsets in all time zones should be stored for user convenience and to figure out which notification should be sent after introducing new rules for some time zones. Just identifier may be ambiguous around DST transition. So timezone abbreviations are ambiguous per se but when identifiers are known they may be still necessary to resolve uncertainties for backward time shifts. At certain moment the Olson DB started to use "+04" abbreviations instead of letters for transitions unrelated to daylight saving time. Yes, timezone names like "Europe/Lisbon" are ambiguous during fallback transitions, or if the meaning of "Europe/Lisbon" changes. This is why one should also save UT offsets when generating localtime timestamps. Before/after time transition around the date may be more meaningful for people. Local tradition may use other reference than Greenwich. Around five years ago I changed TZDB to numeric use time zone abbreviations like "+04" instead of my inventions like "GET", because I wanted TZDB to follow existing practice, not invent it. A nice side effect is that numeric abbreviations are unambiguous. (Besides, even _I_ couldn't remember what "GET" meant. :-) Numerical abbreviation broke parsers in stable linux distribution, e.g. a patch for Qt required in addition to tzdata update. I do not remember details, but removed old-style abbreviations caused some problems as well. I may be wrong concerning usage of such abbreviation in the postgres parser and earlier generated text timestamps. On the other hand an abbreviation for a timezone with evolved offset significantly contributes to uncertainties and does not help to resolve ambiguity around time shift. And WET/WEST gets another bit of info in addition to numerical offset. That info is meant only for users; I wouldn't rely on it for calculations because those abbreviations are ambiguous. It could well be, for example that the meaning of "PST" in the United States will change in the near future. I agree that abbreviations are ambiguous when considered globally. When constrained to particular location (time zone) and moment of time, they may provide additional bit of information that is more convenient for users and enough to resolve ambiguity. It is not a general rule, sometimes uncertainty remains even when abbreviation is known. I do not remember if it is possible at all to obtain using libc the period of constant time offset, when time shift value is valid. Sometimes it is necessary to recalculate offset. Sorry, I don't understand this point. One can easily recalculate the UT offset in Emacs Lisp by generating the desired timestamp and calling decode-time on it. You surely are talking about something else, but I don't know what it is. Let's assume Europe/Lisbon timezone. `decode-time' for today gives just +0100. It tells nothing if I need to process some thousands of timestamps for yesterday and past week. If some function returns "+0100 for given timestamp and the same offset is valid for Europe/Lisbon since Sun Mar 27 01:00:00 2022 UT = Sun Mar 27 02:00:00 2022 WEST till Sun Oct 30 00:59:59 2022 UT = Sun Oct 30 01:59:59 2022 WEST" then I can process whole bunch without any worry concerning non-existing or ambiguous time, extra or lost hour in time intervals. mktime should have all this information during intermediate calculations but it does not expose it to callers. Interface of mktime is suitable for conversion of isolated timestamps. For bunch of related data there is enough room for optimizing. You wrote that "2021-01-31 23:30:00 +0300" is parsed correctly. My opinion is that when time zone is known to be Africa/Juba (system-wide setting, environment variable, or an argument of the parsing function) then "2021-01-31 23:30:00 CAT" and "2021-01-31 23:30:00 EAT" should be parsed correctly (and localized date-time formats should be parsed as well). That's not possible in general, since the two abbreviations can be the same. Traditionally in Australia, for example, "CST" meant both "Central Standard Time" and "Central Summer Time", and there are probably still apps
Re: [PATCH] Re: New source block results option for attaching file to node
Yeah I just recently updated my fourth and realized there were some necessary conflicts to resolve with the latest. I'll take a look at addressing these issues and submit an updated patch. Surprised I missed a calling location and secretly hope that it was added recently for the sake of my poor ego. :) With all of the layers and assumptions/behaviors inherent in the way src block parameters are handled, do you feel like this is an approach that can work, or should it be abandoned? Thanks for looking into this. On Thu, Apr 21, 2022, 05:46 Ihor Radchenko wrote: > Ryan Scott writes: > > > Here's my latest patch. > > Uses special :dir value 'attach to use attachment directory as working > dir. > > Now prompts to create IDs for nodes that are missing. > > Solved a handful of issues with my previous versions of this and I've > been > > using it regularly for a bit now. > > > > I've added documentation and completed the copyright assignment to the > FSF. > > I have consulted Bastien about our merge policy and apparently it is ok > to merge staff into files without maintainer. ob-core.el is one of such > files. > > So, I did a more elaborate testing of your patch. I have some comments. > > Firstly, the patch does not apply onto current main. > > > +Setting =dir= to the symbol ~attach~ or the string ~"'attach"~ will > > ... > > +Passing the symbol ~attach~ or string ='attach= to the =:dir= option > > When I was trying to use your patch, I felt slightly confused about the > "'attach" part. It _looks_ like a type and I first tried to do :dir > "attach" yielding predictable lack of attachment: file link. > > Maybe you can say "or the string ~"'attach"~ (with quote)". > > > + (org-babel-result-to-file > > + result > > + (org-babel--file-desc (nth 2 info) result) > > + 'attachment > > There are only 2 calls to org-babel-result-to-file in the whole Org > codebase. And you did not change the second call, which yield strange > side-effects: > > #+NAME: attr_wrap > #+BEGIN_SRC sh :var data="" :var width="\\textwidth" :results output > echo "#+ATTR_LATEX: :width $width" > echo "$data" > #+END_SRC > > #+begin_src gnuplot :dir 'attach :file test.png > plot x > #+end_src > > #+RESULTS: > [[attachment:test.png]] > > #+begin_src gnuplot :dir 'attach :file test.png :post > attr_wrap(width="5cm", data=*this*) :results drawer > plot x > #+end_src > > #+RESULTS: > :results: > #+ATTR_LATEX: :width 5cm > [[file:data/4d/6a76f8-4016-4edf-9d26-e0b3a634dbc1/test20.png]] this is not expected > :end: > > > +If the optional TYPE is passed as 'attachment` and the path is a > > +descendant of the DEFAULT-DIRECTORY, the generated link will be > > +specified as an an \"attachment:\" style link" > > + (in-attach-dir (when (and request-attachment (> (length > result-file-name) attach-dir-len)) > > +(string= > > + (substring result-file-name 0 > attach-dir-len) > > + attach-dir > > This is a risky heuristics. > One can do something like > (setq org-attach-id-dir > "/tmp/alsjkdsalkjdlaskdjklasjdlkasjdlkasjdlkajdklasjdlasjlasdjk/") > and often get your heuristics fail. > Of course, it will require some terribly noncomplying ob-* library that > will create file disregarding default-directory, but still... > > > + (if (y-or-n-p (format "Create ID for entry \"%s\"?" > > + (org-get-heading t t t t))) > > This is a nice dialogue, but note that Emacs can run noninteractively or > execute source block during export (including asynchronous). I would > guard the query after consulting `noninteractive' variable. > > > Best, > Ihor >
Re: Small patch for org-refile
Hi, On 2022-04-21 21:55 +08, Ihor Radchenko wrote: > Are you sure that you cloned the repo we mention at > https://orgmode.org/? > > The change you are suggesting is already in Org 9.5.3 and that alias has > been moved to org-compact.el long time ago. awfully sorry for the noise! I manage my packages with straight and thought I had checked out the latest tag, while I hadn't. Thanks Kambiz
Re: Small patch for org-refile
Kambiz Darabi writes: > I recently switched to Emacs 28 and stumpled upon a call in org-refile to > define-obsolete-function-alias which doesn't have the 'when' parameter. > As Emacs 28 has made the 'when' parameter mandatory, this is a problem > for me. > > Attached is a tiny patch against the git repo which I cloned today which > resolves the problem. > > Thanks for your great work Are you sure that you cloned the repo we mention at https://orgmode.org/? The change you are suggesting is already in Org 9.5.3 and that alias has been moved to org-compact.el long time ago. Best, Ihor
Re: org-cite styles don't allow * in them
Nicolas Goaziou writes: > I had your > > *bold [cite:citet*:@key] > > example in mind. Sure, if bold jumps across the citation this is > different. I'm not sure this is something that is frequent enough to > worry. According to Prof. Kitchin, it is not frequent. However, if it does happen it will be very annoying to deal with. > Besides, the suggested idea of using [cite/citet*/:@key] for > disambiguation seems fine (as long as they are implemented). Maybe we can make trailing "/" alias of the same style without slash? (e.g. cite/citet*/ is treated as alias of cite/citet* even if cite/citet*/ is not explicitly defined by the processor) I do not think that we can afford to rely on external processors to take care about this. best, Ihor
Re: [PATCH] Re: No mathematics in Texinfo exports
Nicolas Goaziou writes: >>> My Texinfo 6.7 manual does not contain any reference to displaymath >>> environment, which is used throughout the patch. Where is it coming >>> from? >> >> I do see @displaymath in my TeXinfo 6.8. Also, >> https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Inserting-Math.html > > So it is a fairly recent addition, since Texinfo 6.8 was released last > July. For example, it is not available in Debian stable. I don't know if > displaymath was stealthily supported before. I see. Compatibility may indeed be an issue. However, I still believe that the feature may be useful for users aiming for newer TeXinfo. Maybe, this feature can be disabled by default unless the user explicitly customize some variable. > Anyway, AFAIU, we need FSF papers from Rudolf Adamkovič before > processing. Yeah. The patch is certainly over 15LOC. Rudolf Adamkovič, feel free to ask questions if you find the copyright assignment instructions unclear. Best, Ihor
Re: [PATCH] ol: Fix org-link-search
Patch marked as cancelled.
Re: [PATCH] Re: New source block results option for attaching file to node
Ryan Scott writes: > Here's my latest patch. > Uses special :dir value 'attach to use attachment directory as working dir. > Now prompts to create IDs for nodes that are missing. > Solved a handful of issues with my previous versions of this and I've been > using it regularly for a bit now. > > I've added documentation and completed the copyright assignment to the FSF. I have consulted Bastien about our merge policy and apparently it is ok to merge staff into files without maintainer. ob-core.el is one of such files. So, I did a more elaborate testing of your patch. I have some comments. Firstly, the patch does not apply onto current main. > +Setting =dir= to the symbol ~attach~ or the string ~"'attach"~ will > ... > +Passing the symbol ~attach~ or string ='attach= to the =:dir= option When I was trying to use your patch, I felt slightly confused about the "'attach" part. It _looks_ like a type and I first tried to do :dir "attach" yielding predictable lack of attachment: file link. Maybe you can say "or the string ~"'attach"~ (with quote)". > + (org-babel-result-to-file > + result > + (org-babel--file-desc (nth 2 info) result) > + 'attachment There are only 2 calls to org-babel-result-to-file in the whole Org codebase. And you did not change the second call, which yield strange side-effects: #+NAME: attr_wrap #+BEGIN_SRC sh :var data="" :var width="\\textwidth" :results output echo "#+ATTR_LATEX: :width $width" echo "$data" #+END_SRC #+begin_src gnuplot :dir 'attach :file test.png plot x #+end_src #+RESULTS: [[attachment:test.png]] #+begin_src gnuplot :dir 'attach :file test.png :post attr_wrap(width="5cm", data=*this*) :results drawer plot x #+end_src #+RESULTS: :results: #+ATTR_LATEX: :width 5cm [[file:data/4d/6a76f8-4016-4edf-9d26-e0b3a634dbc1/test20.png]] +If the optional TYPE is passed as 'attachment` and the path is a > +descendant of the DEFAULT-DIRECTORY, the generated link will be > +specified as an an \"attachment:\" style link" > + (in-attach-dir (when (and request-attachment (> (length > result-file-name) attach-dir-len)) > +(string= > + (substring result-file-name 0 attach-dir-len) > + attach-dir This is a risky heuristics. One can do something like (setq org-attach-id-dir "/tmp/alsjkdsalkjdlaskdjklasjdlkasjdlkasjdlkajdklasjdlasjlasdjk/") and often get your heuristics fail. Of course, it will require some terribly noncomplying ob-* library that will create file disregarding default-directory, but still... > + (if (y-or-n-p (format "Create ID for entry \"%s\"?" > + (org-get-heading t t t t))) This is a nice dialogue, but note that Emacs can run noninteractively or execute source block during export (including asynchronous). I would guard the query after consulting `noninteractive' variable. Best, Ihor
Re: org-cite styles don't allow * in them
Ihor Radchenko writes: >> I think the zero-width space can be inserted on the other side. > > Could you elaborate? In the following example, inserting zero-width > space at *bold will break the intended bold emphasis *bold ... here*. > > Some *bold emphasis with reference [cite/citet*:@key] will end at "citet*", > but not here*. I had your *bold [cite:citet*:@key] example in mind. Sure, if bold jumps across the citation this is different. I'm not sure this is something that is frequent enough to worry. Besides, the suggested idea of using [cite/citet*/:@key] for disambiguation seems fine (as long as they are implemented). Regards,
Re: [PATCH] Re: No mathematics in Texinfo exports
Ihor Radchenko writes: > Nicolas Goaziou writes: > >>> Rudolf Adamkovič writes: >>> >>> The idea sounds good and having tests is very good. Though I am not >>> expert in texinfo. CC-ing Nicolas. He is the maintainer. >> >> My Texinfo 6.7 manual does not contain any reference to displaymath >> environment, which is used throughout the patch. Where is it coming >> from? > > I do see @displaymath in my TeXinfo 6.8. Also, > https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Inserting-Math.html So it is a fairly recent addition, since Texinfo 6.8 was released last July. For example, it is not available in Debian stable. I don't know if displaymath was stealthily supported before. Anyway, AFAIU, we need FSF papers from Rudolf Adamkovič before processing. Regards,
Re: [PATCH] ol: Fix org-link-search
On Thu, Apr 21, 2022 at 12:23 PM tony aldon wrote: > You're right I was effectively missing affiliated keywords and so my > patch is wrong. > > Thank you for your quick feedback and insight. > > Have a nice day, > Tony Aldon > > On Thu, Apr 21, 2022 at 7:39 AM Ihor Radchenko wrote: > >> tony aldon writes: >> >> > If I'm not wrong, name defined after #+NAME: should be match first >> > before trying a fuzzy search in the function `org-link-search`. >> > ... >> > - (name (org-element-property :name element))) >> > + (name (org-element-property :value element))) >> >> I think you are missing something. >> >> A standaline >> >> #+name: some name >> >> is a keyword, not an element name, but a generic keyword element. >> >> Named elements are the elements with affiliated keywords (not ordinary >> keywords): >> >> #+name: some other name >> Some element that can have affiliated keywords. It may be a paragraph, >> like here or e.g. source block. Link search should not try to search >> standalone keywords and hence it is sufficient to check for :name >> element property. :value will miss e.g. named source blocks. >> >> Try running (org-element-at-point) on the first and second #+name in org >> buffer. >> >> Best, >> Ihor >> >
Small patch for org-refile
Hello, I recently switched to Emacs 28 and stumpled upon a call in org-refile to define-obsolete-function-alias which doesn't have the 'when' parameter. As Emacs 28 has made the 'when' parameter mandatory, this is a problem for me. Attached is a tiny patch against the git repo which I cloned today which resolves the problem. Thanks for your great work Kambiz PS: please keep me in Cc as I'm not subscribed to the list >From 9b2ac43338945022418389168835a5cd2cc2adcd Mon Sep 17 00:00:00 2001 From: Kambiz Darabi Date: Thu, 21 Apr 2022 10:29:13 +0200 Subject: [PATCH] org-refile: add 'when' param to obsolete org-copy --- lisp/org-refile.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org-refile.el b/lisp/org-refile.el index a8a2ef2a6..ee19788fc 100644 --- a/lisp/org-refile.el +++ b/lisp/org-refile.el @@ -373,7 +373,7 @@ the *old* location.") (defvar org-refile-keep nil "Non-nil means `org-refile' will copy instead of refile.") -(define-obsolete-function-alias 'org-copy 'org-refile-copy) +(define-obsolete-function-alias 'org-copy 'org-refile-copy "Org 9.4") ;;;###autoload (defun org-refile-copy () -- 2.25.1
Re: org-cite styles don't allow * in them
Nicolas Goaziou writes: >> Note that inserting zero-width space will not only be awkward here, but >> also breaks parser: e.g. [cite/citet:@key] is not currently >> recognised as a citation. > > I think the zero-width space can be inserted on the other side. Could you elaborate? In the following example, inserting zero-width space at *bold will break the intended bold emphasis *bold ... here*. Some *bold emphasis with reference [cite/citet*:@key] will end at "citet*", but not here*. Best, Ihor
Re: [PATCH] Re: No mathematics in Texinfo exports
Nicolas Goaziou writes: >> Rudolf Adamkovič writes: >> >> The idea sounds good and having tests is very good. Though I am not >> expert in texinfo. CC-ing Nicolas. He is the maintainer. > > My Texinfo 6.7 manual does not contain any reference to displaymath > environment, which is used throughout the patch. Where is it coming > from? I do see @displaymath in my TeXinfo 6.8. Also, https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Inserting-Math.html >> Why don't we just have an extra element property with the bracket info >> in the output of org-element-latex-fragment-parser? > > Because we didn't need it so far, as Org doesn't make a difference > between the different markers. Fair point. I somehow assumed that knowing about latex fragment type is commonly needed in exporters. Grepping through the code revealed that it is not the case. Best, Ihor
tag based translation
Hi folks Long time!!! Hope you folks are doing well in these bizarre times Can someone help me to write a filter (or some such) so that headings like -- *** Recursion before Iteration :L: Lorem ipsum etc get transformed to -- *** Dummy :ignore: #+begin_law Recursion before Iteration #+end_law Lorem Ipsum etc -- 1. Assume suitable environment defs in latex using newtheorem for 2. Assume: :L: -> begin_law :F: -> begin_fact :A: -> begin_action IOW I want to preserve the document structure of the headline but want the headline to use equation style typesetting on the latex side. Thanks Rusi PS I used to have a subscription but cant seem to find how to activate it So pls keep me cced
Re: [PATCH v2 00/38] Final call for comments: Merge org-fold feature branch
Ihor Radchenko writes: > https://github.com/yantar92/org/tree/feature/org-fold-universal-core-tidy Thanks -- I confirm the bug I reported is not present in this branch. -- Bastien
Re: [PATCH v2 00/38] Final call for comments: Merge org-fold feature branch
Bastien writes: >> Since the actual patch does not have the problem, I'd prefer to ignore >> this problem unless it appears again after merging. > > Sure - can you point the exact branch/commit I should test for the > version that will be merged? https://github.com/yantar92/org/tree/feature/org-fold-universal-core-tidy
Re: org-cite styles don't allow * in them
Hello, Ihor Radchenko writes: > "Bruce D'Arcus" writes: > >> On Sun, Apr 3, 2022 at 5:07 PM John Kitchin wrote: >>> >>> I was looking into using latex commands as styles in org-cite, e.g. >>> >>> [cite/citet:@key]. That example works fine, but [cite/citet*:@key] is not >>> allowed. Could that be allowed? >> >> I have no insight into the restriction, but I hope it can be removed. > > I do like the proposal in general, but I can see a potential issue for > users. Constructs like "word*:" can be recognised as a valid bold > emphasis ending. For example: > Some *bold emphasis with reference [cite/citet*:@key] will end at "citet*", but not here*. Note the issue already exists for italics and underline markers. > Note that inserting zero-width space will not only be awkward here, but > also breaks parser: e.g. [cite/citet:@key] is not currently > recognised as a citation. I think the zero-width space can be inserted on the other side. If there's no objection, I'll add asterisk character to the list of allowed characters in citation style. More generally, what other characters should be allowed ? Regards, -- Nicolas Goaziou
#3 Org mode profiling meetup on Sat, Apr 23 (was: #2 Org mode profiling meetup on Sat, Mar 26)
Dear all, I am continuing my experiment with Org mode meetups and online debugging. This time, I plan to 1. Talk about contributing patches to Org - Applying patches sent by others - Testing changes (make test) - Creating patches - Sending patches to the mailing list 2. Talk about and debug any issues related to Org interactively via screen sharing. Note that using microphone and/or camera should not be required. Jitsi does have chat. The time will be the same: 9pm SG time (4pm Kyiv; 2pm London; 9am New York). Sat, Apr 23 I will post the link to the meeting one hour before the meeting start. Best, Ihor
Re: [PATCH] org-agenda: Use `window-max-chars-per-line' instead of `window-width'
Hello Ihor, At 03:16 -0400 on Thursday 2022-04-21, N. Jackson wrote: > > However, the problem with the tags wrapping in Agenda (instead of > being right aligned) remains. I believe the problem with the wrapping of the Agenda tags is here: (defun org-agenda-align-tags ( line) "Align all tags in agenda items to `org-agenda-tags-column'. When optional argument LINE is non-nil, align tags only on the current line." (let ((inhibit-read-only t) (org-agenda-tags-column (if (eq 'auto org-agenda-tags-column) (- (window-text-width)) ^ org-agenda-tags-column)) (end (and line (line-end-position))) l c) ... Changing window-text-width to window-max-chars-per-line fixes the problem here and seems like the right thing to do. Regards, N.
Re: Maintenance Request
Hello, Bastien writes: > Daniel Fleischer writes: > >> I would like to maintain the 'ox-latex.el' file. It's one of the many >> files created by Nicolas but few of the files that are not maintained >> (by him). I have a long experience (14) with latex and relatively long >> experience with org->latex. > > Sorry for the late answer and thanks for proposing this. > > I added you as the ox-latex.el maintainer, assuming this is okay for > Nicolas (Nicolas, let me know if I'm wrong.) AFAIC, this is certainly okay. Regards, -- Nicolas Goaziou
Re: Maintenance Request
Edouard Debry [2022-04-21 Thu 00:58] wrote: > Thanks for offering to maintain 'ox-latex.el'. > > One of the thing that could be improved is the generation of svg > images through tikz. Currently, unless I am mistaken, it does > not work well. I had to tweak 'ox-latex.el' to make it work again. > I did post a question about this on the mailing list. > I'll try to find the question. Would you like to submit a patch based on your modifications?
Re: [PATCH v2 00/38] Final call for comments: Merge org-fold feature branch
Hi Ihor, thanks for double-checking this. Ihor Radchenko writes: > Since the actual patch does not have the problem, I'd prefer to ignore > this problem unless it appears again after merging. Sure - can you point the exact branch/commit I should test for the version that will be merged? -- Bastien
Re: [PATCH] Re: No mathematics in Texinfo exports
Hello,
Ihor Radchenko writes:
> Rudolf Adamkovič writes:
>
> The idea sounds good and having tests is very good. Though I am not
> expert in texinfo. CC-ing Nicolas. He is the maintainer.
My Texinfo 6.7 manual does not contain any reference to displaymath
environment, which is used throughout the patch. Where is it coming
from?
> A more general comment is rather about our org-element.el (maybe Nicolas
> can answer)
>
>> + (cond
>> + ((or (string-match-p "^\\[" value)
>> +(string-match-p "^\\$\\$" value))
>> ...
>> + ((string-match-p "^\\$" value)
>> ...
>> + ((string-match-p "^(" value)
>
> Why don't we just have an extra element property with the bracket info
> in the output of org-element-latex-fragment-parser?
Because we didn't need it so far, as Org doesn't make a difference
between the different markers.
Regards,
--
Nicolas Goaziou
Re: [PATCH] org-agenda: Use `window-max-chars-per-line' instead of `window-width'
At 13:25 +0800 on Thursday 2022-04-21, Ihor Radchenko wrote: > > Attaching the patch. Great. I tested the patch (with Org mode version 9.5.3) and that fixes the problem for the block separator wrapping. However, the problem with the tags wrapping in Agenda (instead of being right aligned) remains. Thank you and best regards, N. > From 5de3de87872ddae994f5b68eba74d915d5f73201 Mon Sep 17 00:00:00 2001 > Message-Id: > <5de3de87872ddae994f5b68eba74d915d5f73201.1650518543.git.yanta...@gmail.com> > From: Ihor Radchenko > Date: Thu, 21 Apr 2022 13:18:39 +0800 > Subject: [PATCH] org-agenda: Use `window-max-chars-per-line' instead of > `window-width' > > * lisp/org-agenda.el (org-agenda-prepare): > (org-todo-list): > (org-agenda-show-new-time): Calculate the maximum number of chars > fitting into window via `window-max-chars-per-line' instead of > `window-with'. The latter can return larger number when fringes are > disabled [1]. > > [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19395 > > Reported in https://orgmode.org/list/87czhdqi9p.fsf_-_@moondust.localdomain > --- > lisp/org-agenda.el | 9 +++-- > 1 file changed, 3 insertions(+), 6 deletions(-) > > diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el > index a09b53563..9ddee81ee 100644 > --- a/lisp/org-agenda.el > +++ b/lisp/org-agenda.el > @@ -3925,7 +3925,7 @@ (defun org-agenda-prepare ( name) > (insert "\n" > (if (stringp org-agenda-block-separator) > org-agenda-block-separator > - (make-string (window-width) org-agenda-block-separator)) > + (make-string (window-max-chars-per-line) > org-agenda-block-separator)) > "\n")) > (narrow-to-region (point) (point-max))) > (setq org-done-keywords-for-agenda nil) > @@ -4944,7 +4944,7 @@ (defun org-todo-list ( arg) > (let ((n 0)) >(dolist (k kwds) > (let ((s (format "(%d)%s" (cl-incf n) k))) > - (when (> (+ (current-column) (string-width s) 1) > (window-width)) > + (when (> (+ (current-column) (string-width s) 1) > (window-max-chars-per-line)) > (insert "\n ")) >(insert " " s > (insert "\n")) > @@ -10301,10 +10301,7 @@ (defun org-agenda-show-new-time (marker stamp > prefix) > (line-end-position) > '(display nil)) > (org-move-to-column > - (- (if (fboundp 'window-font-width) > - (/ (window-width nil t) (window-font-width)) > -;; Fall back to pre-9.3.3 behavior on Emacs <25. > -(window-width)) > + (- (window-max-chars-per-line) >(length stamp)) > t) >(add-text-properties
Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones
> Date: Wed, 20 Apr 2022 17:11:34 -0700 > Cc: maniku...@gmail.com, emacs-orgmode@gnu.org, 54...@debbugs.gnu.org, > bug-gnu...@gnu.org > From: Paul Eggert > > On 4/20/22 12:30, Eli Zaretskii wrote: > > > I see the time samples change in jumps of 15 msec. > > Could you give the first part of the output? I would like to see what > the the samples are jumping from and to, and how often they jump. That "first part", as I understand what you wanted, would be too long and tedious to examine, as the value changes once every 5500 lines. So I've modified the test program to print the time only when it changes, and here's the output: gettime_res returned 625000 ns time = 1650522863.03875 time = 1650522863.054375000 time = 1650522863.07000 time = 1650522863.085625000 time = 1650522863.10125 time = 1650522863.116875000 time = 1650522863.13250 time = 1650522863.148125000 time = 1650522863.16375 time = 1650522863.179375000 time = 1650522863.19500 time = 1650522863.210625000 time = 1650522863.22625 time = 1650522863.241875000 time = 1650522863.25750 time = 1650522863.273125000 time = 1650522863.28875 time = 1650522863.304375000 time = 1650522863.32000 time = 1650522863.335625000 time = 1650522863.35125 time = 1650522863.366875000 time = 1650522863.38250 time = 1650522863.398125000 time = 1650522863.41375 > > Which is expected > > on MS-Windows, given the scheduler time tick, but what does that have > > to do with the system's time resolution? > > The resolution of Elisp's (time-convert nil t) is determined by the > smallest nonzero gap between timestamps that are returned by C's > current_timespec. This is the system time resolution as far as Elisp is > concerned, because Elisp cannot return the current time at a finer > resolution than what current_timespec gives it. This resolution is not > necessarily the same as the time resolution of the motherboard clock, OS > high-res timestamp, file timestamps, etc. Then I think I don't understand the purpose of this measurement, as applied to Emacs Lisp. For example, you say that this is unrelated to file timestamps, but don't we use time values for file timestamps? And for Windows, all this does is measure the "resolution" of the Gnulib emulation of timespec functions on MS-Windows, it tells nothing about the real resolution of the system time values. More generally, if the "time resolution" determined by this procedure is different between two systems, does it mean that two time values that are 'equal' on one of them could be NOT 'equal' on another? And if so, wouldn't that mean Emacs Lisp programs will be inherently not portable? IOW, how do you intend to incorporate this "time resolution" into Emacs Lisp, and what will be affected by that value?
Re: [PATCH] Re: No mathematics in Texinfo exports
Rudolf Adamkovič writes:
> My patch (from almost a month ago) has yet to appear at
>
> https://updates.orgmode.org
This is strange. Marking the patch manually.
In any case, thanks for your contribution and patience.
> Any ideas what to do? Could someone review it?
The idea sounds good and having tests is very good. Though I am not
expert in texinfo. CC-ing Nicolas. He is the maintainer.
A more general comment is rather about our org-element.el (maybe Nicolas
can answer)
> + (cond
> + ((or (string-match-p "^\\[" value)
> +(string-match-p "^\\$\\$" value))
> ...
> + ((string-match-p "^\\$" value)
> ...
> + ((string-match-p "^(" value)
Why don't we just have an extra element property with the bracket info
in the output of org-element-latex-fragment-parser?
> Please note that I have never contributed patches via mail, and I have
> never signed any FSF papers. I would appreciate your guidance.
See https://orgmode.org/worg/org-contribute.html#copyright
Best,
Ihor
Re: [PATCH v2 00/38] Final call for comments: Merge org-fold feature branch
Bastien writes: > I'm on commit e0abbbacf9427b69482c6c47c3ea0975b0e6fa6d from the > feature/org-fold-universal-core branch of your org repo. > > Using Emacs 29.0.50 and this as the content for ~/test.org: > > * TODO [[https://orgmode.org][test]] > SCHEDULED: <2022-04-20 mer.> > > Then run: > > - emacs -q > - C-x C-f test.org > - M-x org-agenda RET > - < a . n t > > You should see the link losing its invisibility specs. I did see it in fork/feature/org-fold-universal-core and it is very strange. The properties are suddenly lost after running add-text-properties and things become normal if I simply move add-text-properties above org-fold-region in org-activate-links--text-properties. What is more strange, the actual patch I proposed (fork/feature/org-fold-universal-core-tidy) does not have the problem. At least, I cannot reproduce it with you recipe. And the patch have exactly same org-activate-links--text-properties... Since the actual patch does not have the problem, I'd prefer to ignore this problem unless it appears again after merging. Best, Ihor
