Re: Saving some kitten, plus some questions along the way

hed, Stefan >From 30f64453a570004524de07aa352f7c631414df7c Mon Sep 17 00:00:00 2001 From: Stefan Monnier Date: Sun, 19 May 2024 17:12:36 -0400 Subject: [PATCH 1/4] (org-*-in-calendar): Prefer `apply` to `eval * lisp/org.el (org-funcall-in-calendar): Rename from `org-eval-in-calendar`. Use `apply` rather th

Re: Saving some kitten, plus some questions along the way

>> -(org-eval-in-calendar '(setq cursor-type nil) t) >> +;; FIXME: Could we use `with-current-buffer' or do we really >> +;; need the `move-overlay' that's in `org-funcall-in-calendar'? >> +(org-funcall-in-calendar (lambda () (setq cursor-type nil)) t) > >

Saving some kitten, plus some questions along the way

The patch below replaces a use of `eval` with `apply`, but along the way I wondered about some of the details of `org-eval-in-calendar` (see the FIXMEs), the most important of them being: why doesn't it use `with-selected-window`? Assuming the change from `eval` to `apply` is OK, I'll upgrade my

Minor patch

The minor patch below clarifies what the computation is about and removes the assumption that point-min == 1, while arguably making the the code ever so slightly more efficient. Stefan >From d386af0653ff75956cc20e0df8ddb5bfa86fec9d Mon Sep 17 00:00:00 2001 From: Stefan Monnier Date:

Re: Provide sane default for the @direntry

patch ). Stefan >From 11a40ce47b104609c003c7b9d871db1f2f26be67 Mon Sep 17 00:00:00 2001 From: Stefan Monnier Date: Tue, 5 Mar 2024 14:11:19 -0500 Subject: [PATCH 1/2] lisp/ox-texinfo.el: Remove redundant `:group`s --- lisp/ox-texinfo.el | 21 + 1 file changed, 1 insertion(+), 20 deletions(-

Re: Provide sane default for the @direntry

list-get info :texinfo-dirname) >> +(plist-get info :texinfo-dirtitle))) ;Obsolete name. >> +;; Strip any terminating `.' from `dn'. >> +(dn (if (string-match "\\.\\'" dn) (substring dn 0 -1) dn)) > > `string-match' will throw an erro

Re: Provide sane default for the @direntry

New version of the patch, which I believe address your comments. Stefan >From 53c8fab18625e8a722657181cb3c825a1d8c895c Mon Sep 17 00:00:00 2001 From: Stefan Monnier Date: Tue, 5 Mar 2024 14:11:19 -0500 Subject: [PATCH 1/2] * lisp/org/ox-texinfo.el: Remove redundant `:group`s --- l

Re: Provide sane default for the @direntry

>> * doc/misc/org.org (Texinfo specific export settings): Adjust accordingly. > It would be nice to provide etc/ORG-NEWS entry as well. Yes, thanks. >>#+cindex: @samp{TEXINFO_DIR_TITLE}, keyword >>The directory title of the document. >> + This is the short name under which the ~m~

Re: Provide sane default for the @direntry

ounced in the news. New patch attached, Stefan >From 6cb66a8737adc8efdb053bd76607289dc120d60b Mon Sep 17 00:00:00 2001 From: Stefan Monnier Date: Sat, 2 Mar 2024 14:48:29 -0500 Subject: [PATCH] ox-texinfo:: Require only TEXINFO_DIR_CATEGORY Until now @dircategory/@direntry entries we

Provide sane default for the @direntry

When exporting to Texinfo, the patch below makes it easier to generate a good `@direntry` by using sane defaults. For most files, you'll just need #+TEXINFO_DIR_CATEGORY: {my-category} I believe it also makes it a bit harder to shoot oneself in the foot and generate an invalid entry (e.g.

Re: bug#65734: [BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)]

> (setq-local kill-line-query-function #'org-kill-line-query) Please use `add-function` for such things. That's its raison d'être. Stefan

Re: bug#65734: [BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)]

>> I said that remapping widely-used keys to commands that behave >> significantly differently places a non-trivial burden on users, >> especially on those who use the remapping mode relatively rarely. > > Sure. From which I concluded that Org mode should avoid remapping I don't think that's what

Re: bug#65734: [BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)]

> Eli told me in the past that Org mode should not remap keys. > See the discussion branch starting at > https://yhetil.org/emacs-devel/8735gfs3is.fsf@localhost/ Then I'll let Eli take care of this :-) Stefan

Re: bug#65734: [BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)]

>> That's why I said "rule of thumb": there can be tradeoffs. >> In practice 99% of Emacs commands modify only a single contiguous chunk >> of text, so the tradeoff comes into play fairly rarely. > It would be nice if this advice were added to the relevant docstrings. Not sure exactly which

Re: bug#65734: [BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)]

>>> But in addition to that, I suspect that Org should probably not modify >>> visibility directly from the modification hooks. Instead, its >>> modification hook function should just stash the info somewhere and then >>> update the visibility later on, such as in a `post-command-hook`, timer,

Re: bug#65734: [BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)]

>> As a rule of thumb, I think modification hooks should be treated a bit >> like POSIX signal handlers: just record the event somewhere but don't do >> any substantial work in there. > Yet, it is sometimes necessary to modify text right inside the > modification hooks. Otherwise, it is very hard

Re: bug#65734: [BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)]

> The reported bug is a side effect of a feature when Org automatically > reveals hidden outlines that are "broken" due to edits and thus could > not be unfolded easily. For example, when destroying parent heading in a > folding subtree: I'd be in favor of changing `kill-whole-line` to do the

Re: org-assert-version considered harmful

>>> But then it will not run during byte-compilation. >> Yeah, I was assuming that you had replaced all `require`s with >> `org-require-with-shadowcheck`, but that's probably not what you'd done. > That's exactly what I have done. Ah. The issue comes from the fact that `require` is treated

Re: org-assert-version considered harmful

>> For this one I can see the problem. You define: >> >> (defmacro org-require-with-shadowcheck (feature) >> [...] >> `(eval-and-compile ...)) >> >> so it will behave like a function, except that it's also >> executed during macroexpansion, so the (require 'org-element) within >>

Re: org-assert-version considered harmful

> My attempt to use shadowcheck idea you proposed failed with some very > strange errors and I gave up. > See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62762#311 For this one I can see the problem. You define: (defmacro org-require-with-shadowcheck (feature) [...]

Re: org-assert-version considered harmful

Ihor Radchenko [2023-08-16 11:08:15] wrote: > Ihor Radchenko writes: >> Stefan Monnier writes: >>> BTW, rather than unloading, `package.el` relies on forcibly "re"loading >>> from the new version the already loaded files from the old version. >>&

Re: bug#59882: Multiple versions of Org in load-path problem

> I have noticed that neither `package--reload-previously-loaded` nor code > loading already compiled package unload the loaddefs file. E.g. I added The state of our unloading support is not good enough to use it blindly, indeed: it's too easy/common to have packages where `unload` leaves you

Re: bug#59882: Multiple versions of Org in load-path problem

> - "emacs -l org" to simulate a regular user session with some opened files. > - Update to Org-9.6 from ELPA. > - Close emacs and start it again "emacs -l org" > > Result: > byte-code: Invalid function: org-assert-version Hmm... there's code in `package.el` intended to avoid that problem, but

Re: bug#59882: Multiple versions of Org in load-path problem

Max Nikulin [2022-12-14 23:02:53] wrote: > On 14/12/2022 21:35, Stefan Monnier wrote: >>> Like I said in another message that I sent just before receiving yours >>> my conclusion came from the fact that hitting 'C-h v' with the cursor >>> on 'org-go

Re: bug#59882: Multiple versions of Org in load-path problem

> similar issues with several important Org components (ol-* and ob-*). In > particular, ob-*.el packages affect Org simply by defining function > symbols with specific name patters (by ob-core.el design). > Achieving no side effects is difficult in practice. That's true. It can be a balancing

Re: bug#59882: Multiple versions of Org in load-path problem

>> On a related note, is it normal that package like org-mouse.el gets >> loaded upon calling C-h f org-mouse- completion prompt? Yes. See `help-enable-completion-autoload`. >> I am asking because org-mouse.el advises some functions and its loading >> may cause unexpected consequences. See >>

Re: org-assert-version considered harmful

> when using unload-feature), so yes, ideally Emacs would make it > possible to have multiple versions of the same package. Having multiple versions *installed* has been supported since "for ever" (AFAIK support for that was added very early in `package.el`s life, before Emacs-24.1). Having

Re: Use lexical-scoping in tests

>> OK, here's a better version. As you can see, it's not nearly as simple. > > Applied onto main + commits addressing all but one FIXME (the one about > `find-file' in org-test.el). Great, thanks, Stefan

Re: Use lexical-scoping in tests

>> +;; FIXME: `s' is a symbol, so (car-safe s) is always nil. >> +;;(when (eq 'autoload (car-safe s)) >> +;; (unintern s obarray)) >> + > > If I understand correctly, the intended version of this code is supposed > to be > > (when (autoloadp

Re: Use lexical-scoping in tests

7241c67250ea Mon Sep 17 00:00:00 2001 From: Stefan Monnier Date: Wed, 14 Sep 2022 17:21:37 -0400 Subject: [PATCH] testing: Make all files use `lexical-binding` Mainly, add the corresponding cookie, but also add various `require`s so that the compiler knows which vars should be trated as dynboun

Re: Use lexical-scoping in tests

Ihor Radchenko [2022-09-14 20:32:53] wrote: > Stefan Monnier writes: >> The patch below simply enables `lexical-binding` in all the test files. >> As far as I can tell, it's all that's needed (beside a missing >> `require`). > Thanks, but the patch causes 23 tests to fail

Re: org-assert-version considered harmful

>> In my book step 3 above is a mistake (even if moved to step 2). > I am confused. > AFAIK, changing the load-path is a common way for users to install > packages manually. No, you're not confused, I just think that installing packages manually (including messing with `load-path` and writing

Re: org-assert-version considered harmful

>> Yup. But there's no option to automatically find those dependencies in >> ELisp, and (IIRC from last time I looked at it, in many packages obeying >> such dependencies would end up introducing circular dependencies in >> the Makefile), so we'd have to depend on the package's author to provide

Re: org-assert-version considered harmful

>> - git pull => switches to 9.5.5, but several .el files are left unchanged. >> - make autoloads => this refreshes the autoloads, but the .elc files >> of those .el files which didn't change still won't be recompiled. > > Isn't it a bug in the elpa scripts then? > If a macro definition is

Re: org-assert-version considered harmful

Ihor Radchenko [2022-09-13 09:52:37] wrote: > Stefan Monnier writes: >> I can see the reason for this macro, and I don't really have a better >> solution to offer, but as someone who has a Git clone of Org that is >> regularly updated using (basically) the normal compi

Use lexical-scoping in tests

The patch below simply enables `lexical-binding` in all the test files. As far as I can tell, it's all that's needed (beside a missing `require`). Stefan diff --git a/testing/examples/babel.el b/testing/examples/babel.el index a7bb0ccf52..cbd522e243 100644 --- a/testing/examples/babel.el

org-assert-version considered harmful

I can see the reason for this macro, and I don't really have a better solution to offer, but as someone who has a Git clone of Org that is regularly updated using (basically) the normal compilation system used in Emacs (i.e. not systematically recompiling all the files, but only those whose `.el`

Re: master 4a1f69ebca 2/2: Use (TICKS . HZ) for current-time etc.

> - (not (time-less-p (cl-subseq (nth 5 (file-attributes file)) 0 2) > - (cl-subseq time 0 2) > + (not (time-less-p (org-time-convert-to-integer > + (nth 5 (file-attributes file))) > + (org-time-convert-to-integer

Re: Drop defadvice from Org

> i was ok with the scold for a long time about (` thing but my reactin > time slowed significantly and that was trivial-er. The (` transition was not handled ideally, to be honest: we declared them obsolete very early but only started emitting warnings much later, so the transition period have

Re: Drop defadvice from Org

> thank you. just an idle question. is it common/desirable for built > in packages to use advice instead of hooks and such? Desirable? no. Common? kinda, yes, sadly. It's usually good to look at the existing advice as "requests for hooks". I haven't spent the energy to look at them this way,

Drop defadvice from Org

The patch below gets rid of the old `defadvice`, replacing it with `advice-add`. It also includes some FIXMEs about things I found along the way which look suspicious (they're not directly related to the patch, tho, nor are they affected by it AFAICT). Stefan 2022-03-31 Stefan Monnier

Re: Minor patch for org-attach.el

> I pushed this to the development branch 'main' of Org. Perfect, thanks, Stefan

Minor patch for org-attach.el

Here's a patch which cleans up some magic numbers in `org-attach.el` and gets rif of the use of the second arg of `commandp`, by making `org-attach-commands` accept any commands (including keyboard macros). Stefan diff --git a/lisp/org/org-attach.el b/lisp/org/org-attach.el index

Re: org-mode-map binds [tab]

> Does outline.el need to be fixed too? [...] > ——snippet from outline.el > (defvar outline-mode-cycle-map > (let ((map (make-sparse-keymap))) >(let ((tab-binding `(menu-item > "" outline-cycle > ;; Only takes effect if point is on a heading. >

Re: More use of lexical-binding in ox.el

>> Yes: >> >> (push (cons var val) varvals >> varvals))) >> >> should be >> >> (push (cons var val) varvals) >> varvals)) >> >> so that the final `varvals` is outside the `dolist` (it's the thing we >> want to return to store

Re: More use of lexical-binding in ox.el

> It looks great but it introduces a test failure, however. > > `org-export-expand-include-keyword' is called from within > `org-export-with-buffer-copy'. > > At the very beginning of `org-export-expand-include-keyword', there is > > (buffer-file-name (buffer-base-buffer)) > > Before the patch,

More use of lexical-binding in ox.el

Here's another patch to remove some more use of the old dynamically scoped dialect of ELisp. Stefan * lisp/ox.el: Fix various uses of the non-lexical-binding ELisp dialect. (org-export--get-global-options, org-export-insert-default-template): Use lexical-binding.

Re: Improving org-macro.el

> I mentioned it in the ORG-NEWS file, and applied your changes. We'll see > how it goes. I just saw that it burps in Emacs-26 because of a bug when functions are declared with 0 optional arguments like ( x). So I suggest the patch below, Stefan diff --git a/lisp/org-macro.el

Re: Improving org-macro.el

>> It seems to work on Org's own manual, but other than that I haven't gone >> out of my way to test it. > There were a few problems reported by the test suite that I tried to > address. I also updated `org-lint', which didn't handle macro > definitions as functions. Thanks. >> - It also changes

Improving org-macro.el

In the course of trying to get the Org package to work with the (then) new GNU ELPA scripts, I bumped into the org-macro.el monster (mostly because it has changed incompatibly between Emacs-26 and Emacs-27, IIRC). In any case, the code struck me as quite inefficient since it reparses the macro

Re: Using lexical-binding

Thanks. So now, I'm just waiting for that code to make its way to Emacs's `master` branch (which I guess first means to make its way to an Org release, so I had better find something else to do in the mean time). Stefan

Re: Using lexical-binding

Hi Kyle, >> Subject: [PATCH] * lisp/org-agenda.el: Use lexical-binding > [...] >> +(pcase type >> + ('agenda >> + (org-agenda-list current-prefix-arg)) > > Unfortunately Org's minimum Emacs version is still Emacs 24.3. Sorry 'bout that. I keep forgetting

Re: Using lexical-binding

>> Should I send a rebased patch for inclusion > Yes, please. Here it is, Stefan >From ba61c9660fc09321f9dfe5f746705f5d1202c474 Mon Sep 17 00:00:00 2001 From: Stefan Monnier Date: Tue, 23 Feb 2021 15:47:29 -0500 Subject: [PATCH] * lisp/org-agenda.el: Use lexical-binding

Re: Using lexical-binding

Should I send a rebased patch for inclusion or do you want to give more time for people to try it out? Stefan

Re: Using lexical-binding

> With a quick test of a few main commands, burps in one of four. Excellent, and thanks for the subsequent patch (I don't think I'd have come up with the move of `extra` on my own). >> - I believe I have quashed all the compiler warnings (some had nothing >> to do with lexical scoping), > >

Using lexical-binding

order to use a macro before it's defined (it would have been simpler/cleaner to just move that functions *after* the macro, but with the new code the problem doesn't occur any more anyway). - Replaced a few `(lambda...) with actual closures. >From d34f993044ee817f7ee18342bcc686285329bea

Re: Bug: (org-release) returns empty string on Elpa [ ( @ /home/pierre/.guix-profile/share/emacs/site-lisp/)]

> Based on tested in a `git clone --no-tags ...` repo, should be fixed by > 61336f80d. Looks like it works: the `version.el` in https://elpa.gnu.org/devel/org-9.5snapshot0.20210205.62105.tar now says: (defun org-release () "The release version of Org. Inserted by installing Org

Re: Bug: (org-release) returns empty string on Elpa [ ( @ /home/pierre/.guix-profile/share/emacs/site-lisp/)]

>> Since the latest update to 9.4.4, some of us in Guix have been >> experiencing issues with loading packages that depend on Org [0]. It >> seems the root of the problem is that (org-release) returns an empty >> string, you can see this manifesting in this email actually :-). [...] > In between

Re: Microsoft Excel spreadsheet editing directly from within emacs.

>> Is it possible for me to edit Microsoft Excel spreadsheet directly >> from within emacs, especially utilizing the powerful capabilities of >> orgmode? > > Not directly, but you could first save the Excel spreadsheet as CSV and > then import it into Org-Mode using M-x org-table-import. There's

Re: [ANN] EmacsConf 2020 videos are out!

> The EmacsConf 2020 videos are now ready. Thanks to everyone who helped > make it happen! Wow! I've been too busy with other things to pay attention to EmacsConf-2020 but the program looks terrific, thank you very much for organizing it. Stefan "downloading some videos"

Re: [PATCH] Make RET and C-j obey `electric-indent-mode' in org-mode

> +(defmacro org-test-with-minor-mode (mode state body) > + "Run BODY after setting MODE to STATE. > +Restore MODE to its former state afterward." > + (declare (debug (sexp sexp body)) (indent 2)) > + `(let ((old-state ,mode)) > + (,mode (if ,state 1 0)) > + ,@body > + (,mode

Re: org 9.2.6 and org 9.1.9

> [[https://lists.defectivebydesign.org/archive/html/emacs-orgmode/2012-09/msg01365.html][Installing > Org through the new http://orgmode.org ELPA]] > > - > [[https://lists.defectivebydesign.org/archive/html/emacs-orgmode/2015-08/msg00316.html][latest > org from Elpa error: Invalid function:

Re: org 9.2.6 and org 9.1.9

> Here's what I do, at the shell: > > > > emacs -Q -batch -eval "(progn (require 'package) (add-to-list > 'package-archives '(\"org\" . > \"http://orgmode.org/elpa/\;;)) > (package-initialize) (package-refresh-contents) (package-install >

Re: org 9.2.6 and org 9.1.9

> But I don't think the issue is with package.el per se. Maybe it needs fixes elsewhere as well, but it's via package.el that the problem is usually exposed. > You get the same problem if you try to install org-mode manually > without package.el. Depends how you do it. > What is really needed

Re: org 9.2.6 and org 9.1.9

> What should happen is that > 1) packages.el should see that I'm trying to install a package that requires > 9.2.6 as a dependency and it should notify me that 9.1.9 is already > installed and do I really want to do that, etc. > > 2) *or* just consider that it's better for me to use 9.2.6 instead

[O] Suggested patch for org-agenda.el

Misc changes: - Assume Emacs≥22 (we're using defvaralias already anyway). - Try to make sure -function only contain functions (and never nil). - Use define-minor-mode and define-derived-mode. - Use command remapping. - Initialize map from within its definition. - Use suppress-keymap. There'd be

Re: [O] orgalist-mode: wrong indentation in message mode after recent change in emacs

>>> The first is whether orgalist-mode couldn't use a custom >>> indent-line-function instead of advising what may or may not be set to >>> indent-relative by the user. >> I don't know how that would work in practice. > Me neither. >> But a minor mode taking control over `indent-line-function'

Re: [O] orgalist-mode: wrong indentation in message mode after recent change in emacs

> The third is why indent-according-to-mode hard-codes the check for > indent-relative and indent-relative-first-indent-point. Wouldn't it be > nice if this check instead looked up some variable akin to > electric-indent-functions-without-reindent, that can be more easily > customised? Agreed.

Re: [O] orgalist-mode: wrong indentation in message mode after recent change in emacs

> Now that add-function sets indent-line-function to a custom closure, > however, (advice--cd*r indent-line-function) no longer returns > indent-relative and the workaround breaks. I think this qualifies as a problem in nadvice: the ad-hoc closure introduced to "redirect to the default-value"

Re: [O] General advice beyond Org

> It is only when we have to collaborate directly that the issue > arises. I guess that it's a similar situation as you are having > (programming? she does not care, I can do whatever I want; publication > abstract? she wants a DOCX or DOC). Collaborating on an article does require a fairly

[O] bug#30321: 25.3; Melpa ox- packages listed as incompatible

> Stefan, can you shed any light as to why Org is no longer on elpa.gnu.org? I wasn't aware of it. I'll try and investigate, Stefan

Re: [O] Key binding popup interface

> (defhydra hydra-zoom () > "zoom" > ("g" text-scale-increase "in") > ("l" text-scale-decrease "out")) > (global-set-key (kbd "C-c") 'hydra-zoom/body) But now this one suffers from other problems: - `C-h k` does not let me directly find the binding of `C-c g`. - A `C-c a` binding in a lower

Re: [O] Key binding popup interface

>> While Hydra might include the feature you're looking for, AFAICT it does >> something else than what you're looking for. > I don't follow "it does something else than what you're looking for". hydra > is used to define interfaces to temporary keymaps with well-formatted hints. I tend to think

Re: [O] Key binding popup interface

> Problem statement: Need to have a pretty interface that shows the available > valid key bindings. [...] > Of all those options and more that I've seen out there, hydra.el looks like > the most elegant and *configurable* option. While Hydra might include the feature you're looking for, AFAICT it

Re: [O] Using CEDET modules from Emacs core

>> "Semantic is too slow for C++" complaint (e.g. compared to Clang-based >> background process solutions) is unlikely to go away. > While I haven't had time to work on CEDET lately, I'd be happy to discuss > specific performance issues and share ideas on how to improve them, > presumably after

Re: [O] Sync up the org in emacs master to org maint branch?

> AFAIU, the main motivation for the "drive to ELPA" comes from > developers of individual packages, not from those working on the core Not sure what you mean exactly by "drive to ELPA". If you mean "drive to put packages in GNU ELPA rather than in core", then this drive is linked to various

Re: [O] Using CEDET modules from Emacs core

SM> For one, I'd like to see more major modes come with support for Semantic SM> right in the major mode's own definition (rather than have it part of SM> CEDET). E.g. for Elisp mode, CC-mode, ... SM> The idea is to get to the point where Semantic support is just another SM> thing that a major

Re: [O] Using CEDET modules from Emacs core

SM> 2- We wanted to integrate it more tightly with Emacs (not in terms of SM> bug-tracking and releasing schedule, but in terms of making it SM> possible for generic Emacs code to use some of CEDET, and to SM> encourage more major modes and other features to use CEDET). > Can you clarify what the

Re: [O] Sync up the org in emacs master to org maint branch?

> So let me try again: What I find completely misguided is to move > packages out of core *but still putting them into the release*. In other > words, in my opinion there are really just two options that make sense: > you either keep a package in core, or you kick it out and don't ship it > with

Re: [O] Sync up the org in emacs master to org maint branch?

> It is a mistake because you are creating more moving targets and bring > them together very late in the release process. This reduces the amount > of testing that is done for those packages, so bugs will be noticed > later and the quality of the relases suffer. It moves even more work > into the

[O] bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)

>> - maybe we can even adjust_match_data in every call to replace_range >> rather than just in the one from Freplace_match. > That would be simpler, though I wasn't sure if it would be correct. I think it's definitely not an option for emacs-25. But maybe we can try it on master.

[O] bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)

> Solution: adjust in between the before and after change functions. > Patch below. I think there shouldn't be performance problems, although > it does add yet another flag to replace_range (by the way, I noticed > that the MARKERS flags is never 0, so it's redundant). I tested with > the

[O] bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)

> Maybe there's a misunderstanding. What Noam suggested was just to > move the code which adjusts search_regs.start[i] and .end[i] to before > the call to replace_range. Oh, right, that's also an option. It might suffer from another problem, which is that the match-data will be broken while the

[O] bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)

> Is it OK to adjust the match data before actually making the > replacement? If so, I think it's a simpler solution. >> PS: I can think of one (theoretical) other/better way to fix this >> problem: move the match-data adjustment so it's done within >> replace_range before running the

[O] bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)

> Do we care that using save-match-data in every call to replace-match > might mean a performance hit? I do but: - to be honest, it's probably lost in the noise. - if we copy search_regs.start and search_regs.end with something like alloca+memcpy (instead of calling Fmatch_data), the cost

[O] bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)

> Before call to replace_range in replace-match: > >|---|---|--|| >s1 e1 s2e2 EOB > > (s1, e1, etc. are the start and end of the corresponding > sub-expressions.) > > After the call to replace_range in replace-match: > >

[O] bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)

> The more general problem is when there's at least one more > sub-expression, whose start and/or end are after the new EOB. > Those sub-expression's data will be completely bogus after the > adjustment, If they were after the EOB, they were already bogus to start with. So there's really not much

[O] bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)

> In the case in point, a single character at EOB (= 62) was deleted, > which made EOB be 61, one less than its previous value. When > save-match-data was called from within a hook set up by Org, it tried > to record the end of the sub-expression as 62, but set-marker silently > changed that to

[O] bug#22399: org-mode fontification

> No, I don't have commit rights. I'll update the Org side, but, for > issues that were introduced in the Emacs tree post 24.5, I don't know if > it's preferable to also update Emacs instead of waiting for the changes > to come over with a full sync. Looks like there's no Org people following

[O] bug#22399: org-mode fontification

>> I see the problem. org-src-font-lock-fontify-block is using buffers >> named " org-src-fontification:" in an unusual way: >> they're updated via normal buffer modifications, but they're not put in >> font-lock-mode, so all the font-lock machinery which tries to keep the >> fontification

[O] bug#22399: org-mode fontification

> Sure. With > > --8<---cut here---start->8--- > > #+BEGIN_SRC elisp > (require 'cl-lib) > (message "test") > #+END_SRC > --8<---cut here---end--->8--- > > in /tmp/scratch.org, run > > emacs -Q --eval "(setq

[O] bug#22399: org-mode fontification

> (defalias 'org-font-lock-ensure > - (if (fboundp 'org-font-lock-ensure) > + (if (fboundp 'font-lock-ensure) >#'font-lock-ensure > -(lambda (_beg _end) (font-lock-fontify-buffer > +(lambda ( _beg _end) (font-lock-fontify-buffer Looks good. > (unless (eq

Re: [O] Why does evaluating a piece of Elisp code seemingly not expand a macro?

> Does it mean that C-M-x is different than loading? Yes. > Or C-x C-e, for that matter? As well. > Is this covered by the manual? (If not, it might need correcting.) Not really. The basic idea is that macroexpansion can take place *anytime* (tho, before the code is actually executed). If

Re: [O] Why does evaluating a piece of Elisp code seemingly not expand a macro?

> Does that mean that it's possible that a function definition contains > unexpanded macros? Yes. > Does that mean that `symbol-function' will expand them? AFAIK it currently never happens there, but if your code relies on this property it's probably got a bug. > Does that mean that if I

[O] Avoiding `intangible'

I'm on a crusade to eradicate the `intangible' property, which happens to rub me the wrong way because it's implemented at too-low a level (it affects every point movement) which incurs a significant performance penalty (even when not used) and affects a lot of code which then needs to be fixed by

[O] bug#11774: bug#11774: bug#11774: org-mode causes undo boundaries to be lost

There is one possible bug. I have undo-boundary on self-insert-hook. If I do newline-and-indent, for some reason both the newline and the indent get undo boundaries. My expectation is that typing RET should only have one undo boundary. I don't know if that is user expectation error, but

Re: [O] Fontification of org code block not printed

I'm sure that this is not what I expect but I'm not sure if this is a fault in ps-def.el or org.el. Because of this I send this to both mailing lists to get help before sending an error report. It's a problem in the ps-def.el code which handles the `face' property in a naive way: it fails to

[O] bug#17724: 24.4.50; regression: error `recenter'ing a window that does not display current-buffer. when opening org-mode file

Ask savannah-hack...@gnu.org. Then it's not worth the trouble (since it's a temporary change that will need to be modified yet again when we release 24.4). Stefan

[O] bug#17724: 24.4.50; regression: error `recenter'ing a window that does not display current-buffer. when opening org-mode file

Not sure what you have in mind, but perhaps we should rename the branch to something like 'release-branch', and then its name won't need to change with the Emacs versions. It's not just the name: after the release we won't ask people to track the release-branch. Maybe we could use a branch

[O] bug#17724: 24.4.50; regression: error `recenter'ing a window that does not display current-buffer. when opening org-mode file

if (buf != current_buffer) // error (`recenter'ing a window that does not display current-buffer.); return Qnil; ... in src/window.c seems to work for me. Using `emacs-24' also works, without defeating the purpose of the error message ;-) Stefan

  1   2   >