Re: [DISCUSSION] org-capture.el vs remember.el (was: [ELPA] New package: jami-bot and org-jami-bot)
On Sat, Dec 30, 2023 at 7:16 PM João Távora wrote: > > On the face of things, remember.el does not comprise a huge amount of > > code, and I don't see why the above two features couldn't be retrofitted > > into it. > > Seems like the first one could be done with narrowing. > But would also need some kind of indirect buffer, too, > right? How does org-capture.el do it? Answering myself, with indirect buffers :-) João
Re: [DISCUSSION] org-capture.el vs remember.el (was: [ELPA] New package: jami-bot and org-jami-bot)
On Sat, Dec 30, 2023 at 5:21 PM Stefan Kangas wrote: > > Ihor Radchenko writes: > > > The refactoring de-coupled what used to be org-remember.el into > > completely rewritten org-capture.el that added important features that > > could not be implemented within remember.el framework: > > > > 1. org-capture arranges writing the text to remember directly into the > >target location where it is to be stored. This addressed an important > >problem of remember.el - remember.el always uses temporary buffer for > >user input and does not save it until remember-finalize is executed > >explicitly. A number of users sometimes forgot to call > >remember-finalize, leading to annoying data losses. > > > > 2. remember.el only allows a single text input at a time. org-capture > >makes it possible for users to write multiple notes in parallel. > > > > I am wondering if it would be possible to have the above two key > > features supported by remember.el. Then, org-capture.el could go back to > > re-using remember.el infrastructure and thus reduce code duplication. > > This is, of course, desirable. The real question is how much work it > will take and who will volunteer to do it. Not volunteering but those two goals seems good, especially the first one > On the face of things, remember.el does not comprise a huge amount of > code, and I don't see why the above two features couldn't be retrofitted > into it. Seems like the first one could be done with narrowing. But would also need some kind of indirect buffer, too, right? How does org-capture.el do it? It would also mean "commiting to remember" is just C-x C-s and file recovery works as normal, which is how it should be IMO. Maybe after-save-hook in this indirect buffer specifically would have the effect of quitting the window displaying the indirect buffer? ... Well I just checked and the hook approach doesn't work, because save-buffer always saves the base buffer. But surely some other hook or some remapped key would do the trick. If this works (big if since given all this is vapourware), we'll finally have found good use for indirect buffers :-) The second one is just multiple such setups, which the window-management code should in theory already allow. João
Re: [FR] Allow flattened imenu index
On Mon, Dec 11, 2023 at 11:54 PM Dmitry Gutov wrote: > > On 12/12/2023 01:48, João Távora wrote: > > On Mon, Dec 11, 2023 at 11:41 PM Dmitry Gutov wrote: > >> On 12/12/2023 01:35, João Távora wrote: > >>> Or maybe say what the ruby-mode imenu backend > >>> does? > >> Juri just posted a long example of what ruby-mode does (and ruby-ts-mode > >> too) in his last message in this thread. > > OK, and doesn't it answer_your_ question? With Eglot > > > > Method > ModuleExample::ClassExample > instance_method > > Method > ClassExample > class_method > > > > If both methods were named "foo" no problem, right? > > But this doesn't look right: if 'class_method' is in a class called > ModuleExample::ClassExample, shouldn't its entry look like > >Method > ModuleExample::ClassExample > class_method > > as well? Take it up with the LS. I didn't write it. > And then, if both 'instance_method' and 'class_method' actually are > called 'foo', then we'd have a problem. Bizarrely, you wouldn't have a tree to start with, which probably explains why the devs of the LS Juri is using opted for that layout. > This entry from his message also looks odd: > >Module > > ModuleExample If you can reproduce it, show the repro. João
Re: [FR] Allow flattened imenu index
On Mon, Dec 11, 2023 at 11:41 PM Dmitry Gutov wrote: > > On 12/12/2023 01:35, João Távora wrote: > > Or maybe say what the ruby-mode imenu backend > > does? > > Juri just posted a long example of what ruby-mode does (and ruby-ts-mode > too) in his last message in this thread. OK, and doesn't it answer _your_ question? With Eglot Method > ModuleExample::ClassExample > instance_method Method > ClassExample > class_method If both methods were named "foo" no problem, right? When run without Eglot, also no problem, no duplicate strings, right? ??
Re: [FR] Allow flattened imenu index
On Mon, Dec 11, 2023 at 11:23 PM Dmitry Gutov wrote: > >> But if the LS will produce distinct strings, good. > > All imenu backends, at least all the ones I've seen, produce > > trees, not strings. > > There are exceptions, like the previously mentioned one. What is the imenu backend that produces strings? A list of strings is still a tree, albeit very flat. Some LS's produce such things. Are there imenu backends that produce lists of strings with duplicates? Where, when, how is that not a problem with the existing imenu UI already, and have we heard of it all these years? > > If you collect all the paths from the root to > > all the nodes into lists and make strings thereof, the resulting > > set will always be a distinct strings. So I don't understand the > > problem you were surfacing: any particular imenu backend in mind? > > Do you have an example of such tree produced by Eglot when a class > contains an instance and a singleton method with the same name? No. I thought you did, else why would you bring it up? Grab a Ruby LS and try it. Or maybe say what the ruby-mode imenu backend does? No rush, but as usual I think there's no point discussing odd conjectures without something palpable in front. Thanks, João
Re: [FR] Allow flattened imenu index
On Mon, Dec 11, 2023 at 7:24 PM Dmitry Gutov wrote: > > It's no invention, it's docstring syntax for reference to a method. In Ruby right? > But if the LS will produce distinct strings, good. All imenu backends, at least all the ones I've seen, produce trees, not strings. If you collect all the paths from the root to all the nodes into lists and make strings thereof, the resulting set will always be a distinct strings. So I don't understand the problem you were surfacing: any particular imenu backend in mind? João
Re: [FR] Allow flattened imenu index
On Mon, Dec 11, 2023 at 7:27 PM Ihor Radchenko wrote: > > Indeed, it's unfortunate that imenu--make-index-alist and imenu--index-alist > > are named as internal. > > Should they be renamed to `imenu-make-index-alist' and `imenu-index-alist' > then? Maybe, but it's much more urgent IMO to review the representation they describe, since it's all over the place. Ideally do this before any rename. Incidentally, I just remembered why breadcrumb-jump uses the 'breadcrumb-region' text property cookie: it's because without it the current imenu tree structure has no way to for backends to store locations to non-leaf nodes, which are often among the places you want to jump to. text-properties + standard cons trees + "special elements" is a bit of a ugly mess, but OTOH it works and is backwards compatible to existing frontends and backends. So one of the possibilities that whoever conducts this review may consider is an 'imenu-region' text property similar to 'breadcrumb-region', describe it imenu--index-alist, and make M-x imenu take advantage of it. João
Re: [FR] Allow flattened imenu index
On Mon, Dec 11, 2023 at 5:43 PM Dmitry Gutov wrote: > > is still usable even without special characters like "#". > > Until a class contains both an instance and a class method with the same > name, I suppose. If that happens, the LS will have to provide to distinct paths to these two distinct items and breadcrumb will have two distinct strings, so no need to invent #-things.
Re: [FR] Allow flattened imenu index
On Mon, Dec 11, 2023 at 5:21 PM Juri Linkov wrote: > > By the way, this seems to be exactly what the breadcrumb-jump command > > in my breadcrumb.el package does. Goes reasonably well with a flex/fuzzy > > completion style. > > It would be great to have some form of breadcrumb-jump in imenu.el > since it's useful on its own even for someone who doesn't use breadcrumbs. You can copy it over, it doesn't really need breadcrumbs, though, it just needs imenu. The only things I'm seeing in its implementation in a penchant for a particular text property `breadcrumb-region`, which has information that imenu's structure didn't have a good place to place. But it's not required, as you noticed, I suppose it just gives it increased accuracy. > When eglot is enabled then imenu-create-index-function returns a tree. > > What is interesting is that breadcrumb-jump already correctly handles both > a flat list and a tree: Yes, that's the point. Though when using Eglot, the exact tree structure -- of any -- depends on the language server. João
Re: [FR] Allow flattened imenu index
On Sat, Dec 9, 2023 at 5:39 PM Juri Linkov wrote: > menu1 > sub-item1 > sub-item2 > > could be flattened to > > menu1 -> sub-item1 > menu1 -> sub-item2 By the way, this seems to be exactly what the breadcrumb-jump command in my breadcrumb.el package does. Goes reasonably well with a flex/fuzzy completion style. You can look at it for an implementation idea. Just be sure to do this flattening at the presentation level (i.e. M-x imenu), not at the internal representation level. It shouldn't be needed here at all, but in case anyone's thinking about it, please avoid messing with imenu's internal representation of hierarchies as that structure is relied upon by many extensions (not just mine, but several others). Even certain things supported by certain imenu-presenting frontends (like "special elements") are not supported by other frontends. It's a bit of a mess. The symbols holding/describing this representation (imenu--index-alist, maybe others) are incorrectly named '--' but they are most definitely externally visible and used customization points. João
bug#45091: 27.1; M-x org-table-paste-rectangle
Okay, your bisect scripts points to one of my commits. But I wish it was more automated. Because I tried quite hard and sometimes I _could_ reproduce the problem and sometimes I couldn't. So you could be seeing noise here. Maybe you can make your script do those copy-paste operations automatically and reliably? Then we'd be sure. Anyway, I think is might be enough to point to a bug that was introduced by my commit, or rather exposed by it. I'll have another look. João On Fri, Jan 15, 2021 at 12:11 PM Naoya Yamashita wrote: > > > Hi, I'm new on this thread, but I can reproduce tak's issue and I > tried to do bisect. > > Finally, I got 5b45c269cda09fe46e110adb6f6767040f4ade59 is a > commit has a some problem. > > I'm happy if this information could help you. > > ``` > 5b45c269cda09fe46e110adb6f6767040f4ade59 > New jit-lock-antiblink-grace feature > > * lisp/jit-lock.el (jit-lock-antiblink-grace): New defcustom. > (jit-lock--antiblink-line-beginning-position) > (jit-lock--antiblink-string-or-comment): New variables > (jit-lock--antiblink-post-command): New helper. > (jit-lock-mode): Tweak post-command-hook and > jit-lock-context-timer. > > * etc/NEWS: Mention jit-lock-antiblink-grace > > 2 files changed, 81 insertions(+), 1 deletion(-) > etc/NEWS | 7 ++ > lisp/jit-lock.el | 75 +++- > ``` > > --- > > Here is my bash script and do `C-c l` (org-table-copy-region) on > first table and `C-c ;` (org-table-paste-rectangle) on second table. > (~/dev/tmp/taks-file.tex have first tak's mention contents.) > > ```sh > make clean > ./autogen.sh > ./configure --prefix=$HOME/.local/head > make -j6 > ./src/emacs -Q ~/dev/tmp/taks-file.tex --eval " \ > (progn\ > (setq truncate-lines t) \ > (setq debug-on-error t) \ > (require 'org) \ > (require 'org-table)\ > (orgtbl-mode) \ > (global-set-key (kbd \"C-c l\") \ >(lambda () \ > (interactive) \ > (org-table-copy-region (1+ (org-table-begin)) (- (org-table-end) > 2 \ > (global-set-key (kbd \"C-c ;\") \ >(lambda () \ > (interactive) \ > (org-table-paste-rectangle)\ > (set-buffer-modified-p nil"\ > 2>/dev/null > ``` > > And here is my bisect log. > ``` > Bisect Log (14) > git bisect start 'emacs-27.1' 'emacs-26.3' > git bisect good 38564f8a664347c42f7614d9c91e0d49e4a073e8 > git bisect good 825fd4d34165e5edc718a9df93838a410d25ea81 > git bisect good 5c5c1b559313d06aab6516ff1b1acf1da3a01c7d > git bisect bad d7cd4ab7d948427104003f1d35cf52a4eac45d0a > git bisect bad 4b2c2faab83fe3b13430b837be7d450b5cd47caf > git bisect good 16ce6dbef279bda70b4d60b4d2d0aff008bfa5f7 > git bisect bad 5063e38921de8cb872965abda32bcc6fd8894532 > git bisect bad 4c933077157ba409d645f4649c8a3a8e534d53d5 > git bisect good 096be9c4541329af259273fe604dc4f8669fbd8a > git bisect bad bd95d66ae97f3dcfe73b972de935e27e434e49be > git bisect bad 5b45c269cda09fe46e110adb6f6767040f4ade59 > git bisect good 0e774d4f355b4f12a625da5ca9602d1ba876bcc1 > 5b45c269cda09fe46e110adb6f6767040f4ade59 is the first bad commit > ``` > > > -- João Távora
bug#45091: 27.1; M-x org-table-paste-rectangle
On Sun, Dec 20, 2020 at 12:15 AM Tak Kunihiro wrote: > > > I'll keep looking a bit, but at this point it doesn't seem to have > > anything to do with the antiblink feature. I might be wrong, but I > > think that only shows up first in the messages buffer because it's > > unlucky enough to be one of the first users of syntax-ppss after a > > command. > > I confirmed that I can reproduce the problem with 27.1.90. Although the > recipe seems complicated, I see the problem quite often when I work with > LaTeX-mode. I still have to stick on 26.3. > > I appreciate if the problem would be fixed. Are you familiar with `git bisect`? It's a bit of work, but it usually points to the culprit commit. Emacs history is very good. I don't have time for this right now, but maybe you have? It's a question of compiling Emacs methodically and then testing your recipe each time. João Távora
bug#45091: 27.1; M-x org-table-paste-rectangle
> I apologize that the file I posted is NG. Please try the following file > as shown below. Thanks, now I did reproduce... something. I get the "Marker does not point anywhere" error you describe, but also mentions to other broken functionality, not only the "antiblink": Error in post-command-hook (jit-lock--antiblink-post-command): (error "Marker does not point anywhere") primitive-undo: Marker does not point anywhereError during redisplay: (jit-lock-function 772) signaled (error "Marker does not point anywhere") Error during redisplay: (jit-lock-function 1272) signaled (error "Marker does not point anywhere") Error during redisplay: (jit-lock-function 1772) signaled (error "Marker does not point anywhere") Error during redisplay: (jit-lock-function 2272) signaled (error "Marker does not point anywhere") Error during redisplay: (jit-lock-function 2772) signaled (error "Marker does not point anywhere") If I turn on debug-on-error, I also get the stacktrace below on RET, which runs newline. It seems the problem comes from "syntax-ppss", which is also called from "antiblink". I cannot always reproduce this, and often I can reproduce without needing the "undo". I'll keep investigating: I still don't know which marker the message is referring to. It could be antiblink's marker, but it could be anything else. João Debugger entered--Lisp error: (error "Marker does not point anywhere") syntax-ppss() electric-indent-post-self-insert-function() self-insert-command(1) newline(nil 1) funcall-interactively(newline nil 1) call-interactively(newline) (let (orgtbl-mode) (call-interactively (or (key-binding "\15") (key-binding [(return)]) 'orgtbl-error))) (if (org-at-table-p) (call-interactively 'orgtbl-ret) (let (orgtbl-mode) (call-interactively (or (key-binding "\15") (key-binding [(return)]) 'orgtbl-error orgtbl-hijacker-command-101(1) funcall-interactively(orgtbl-hijacker-command-101 1) call-interactively(orgtbl-hijacker-command-101 nil nil) command-execute(orgtbl-hijacker-command-101)
bug#45091: 27.1; M-x org-table-paste-rectangle
João Távora writes: > I'll keep investigating: I still don't know which marker the message > is referring to. It could be antiblink's marker, but it could be > anything else. > > João I've now reproduced after setting (setq jit-lock-antiblink-grace nil) Which turns off the antiblink feature _almost_ entirely. I've also been able to reproduce it from the command line via: ~/Source/Emacs/emacs-27/src/emacs -Q ~/tmp/taks-file.latex \ --eval "(progn \ (require 'org) \ (require 'org-table) \ (orgtbl-mode) \ (remove-hook 'post-command-hook \ 'jit-lock--antiblink-post-command t))" Which _completely_ turns off the antiblink feature. It doesn't need a window system, -nw is fine to reproduce. This was with a fresh build of the Emacs 27.1 tag. It's hard to reproduce sometimes, but iterating the undo/paste rectangle cycle eventually gets one there. It has to be done on the very same file that Tak Kunihiro posted. Sometimes I mess the file slightly (in ways that I can't tell) and it doesn't happen again. Tak Kunihiro, what is in your opinion the deciding character of these files? I.e. what did you change from the first file (where I couldn't reproduce) to the second? I'm quite lost as to why this happens, of course, but it seems it's always coming from syntax-ppss. When I evaluate that definition (rather than compiling), I get more clues: Debugger entered--Lisp error: (error "Marker does not point anywhere") >(# 2919) (and old-pos (> old-pos pos)) (if (and old-pos (> old-pos pos)) (setq old-pos nil)) (let* ((cell (syntax-ppss--data)) (ppss-last (car cell)) (ppss-cache (cdr cell)) (old-ppss (cdr ppss-last)) (old-pos (car pps$ (progn (set-syntax-table (or syntax-ppss-table (syntax-table))) (let* ((cell (syntax-ppss--data)) (ppss-last (car cell)) (pps$ (unwind-protect (progn (set-syntax-table (or syntax-ppss-table (syntax-table))) (let* ((cell (syntax-ppss--data)) (ppss-last $ (let ((table (syntax-table)) (buffer (current-buffer))) (unwind-protect (progn (set-syntax-table (or syntax-ppss-table (synta$ syntax-ppss() I'll keep looking a bit, but at this point it doesn't seem to have anything to do with the antiblink feature. I might be wrong, but I think that only shows up first in the messages buffer because it's unlucky enough to be one of the first users of syntax-ppss after a command. João
