Re: Folding headings which contain only blank lines
> Any chance you could provide a minimal reproducer for > your original issue so I can check on my end? Certainly, save this: ---cut * empty heading * another one ---cut end--- Now, when opening this file, you will see: ---cut * empty heading... * another one ---cut end--- (use shift-tab if fold on startup is disabled) Problem is: after unfolding "empty heading" you can't fold it back (barring the use of org-shifttab). One comorbid issue here, btw, is that "another one" isn't folded initially at all... сб, 24 окт. 2020 г. в 08:43, Kyle Meyer : > > Dmitrii Korobeinikov writes: > > >> was trying to find an example of the issue fixed by ee3c3b55. Dmitrii, > >> did ee3c3b55 solve the issue on you reported? > > > > Hi, Kyle, I haven't checked it, but since several people reported that > > it wasn't working for them, I decided to forego the trouble of > > installing it myself (I am using the stock org mode). > > Okay, thanks. Any chance you could provide a minimal reproducer for > your original issue so I can check on my end? As I mentioned in the > referenced thread [*], I haven't been able to figure out which case, if > any, was resolved by ee3c3b55. > > [*] https://orgmode.org/list/87tuviqyi4@kyleam.com
Re: Folding headings which contain only blank lines
> was trying to find an example of the issue fixed by ee3c3b55. Dmitrii, > did ee3c3b55 solve the issue on you reported? Hi, Kyle, I haven't checked it, but since several people reported that it wasn't working for them, I decided to forego the trouble of installing it myself (I am using the stock org mode).
Re: Preventing org-cycle from scrolling the buffer
Hi Bastien, Thank you, both for accepting this and for the fix with the blank line folding! Best, DK сб, 5 сент. 2020 г. в 11:26, Bastien : > > Hi Dmitrii, > > Dmitrii Korobeinikov writes: > > > Nice, I see! > > > >> IDK. AFAICS you are right with your argumentation. I don't see the > >> need of that feature, though, yet. But that's just me. I think you are > >> the best candidate to try an implementation of the feature. > > > > I have attached a small patch, seems to be working! Of course, if this > > is to be merged, that defvar will have to turn into a defcustom. > > thanks for the patch, I applied a small variant of it as 056fc532b. > > I don't think we need an option (defcustom) for this, the current > behavior seems correct -- but I'm convinced some people would prefer > the previous behavior. If there are a lot of such people with strong > argument, perhaps we will have to revert the change. > > Thanks, > > -- > Bastien
Re: auto-completion for file paths?
> org-insert-link (C-c C-l) will read a file name from you if you select > "file:" or call it with a prefix argument. This will do, thanks! ср, 2 сент. 2020 г. в 03:08, Kyle Meyer : > > Dmitrii Korobeinikov writes: > > > Hi, all! > > > > Is there a way to provide completions for paths > > [[file:suggest/completions/here]]? > > org-insert-link (C-c C-l) will read a file name from you if you select > "file:" or call it with a prefix argument.
auto-completion for file paths?
Hi, all! Is there a way to provide completions for paths [[file:suggest/completions/here]]? Best, DK
Re: org.elc failed to define function orgstruct-mode
> OrgStruct mode is no longer provided in Org. I see, thanks! PS Just found out about outshine and orgalist, gonna check them out. пн, 1 июн. 2020 г. в 13:31, Nicolas Goaziou : > > Hello, > > Dmitrii Korobeinikov writes: > > >> M-x orgstruct-mode > > > >> I get the error: > > > >> command-execute: Autoloading file > >> /usr/share/emacs/site-lisp/org/org.elc failed to define function > >> orgstruct-mode > > > > Interesting, with --no-site-lisp flag there's no error and the > > orgstruct-mode seems to load just fine... > > OrgStruct mode is no longer provided in Org. > > Regards, > > -- > Nicolas Goaziou
Re: org.elc failed to define function orgstruct-mode
> M-x orgstruct-mode > I get the error: > command-execute: Autoloading file > /usr/share/emacs/site-lisp/org/org.elc failed to define function > orgstruct-mode Interesting, with --no-site-lisp flag there's no error and the orgstruct-mode seems to load just fine... вс, 31 мая 2020 г. в 22:51, Dmitrii Korobeinikov : > > Hi! > > When I try > > M-x orgstruct-mode > > I get the error: > > command-execute: Autoloading file > /usr/share/emacs/site-lisp/org/org.elc failed to define function > orgstruct-mode > > Org mode version 9.3.6 (release_9.3.6-449-gb99357 @ > /usr/share/emacs/site-lisp/org/) > GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.10) of > 2019-08-30 > Arch Linux > > What could be going on here? > > Best, > DK
org.elc failed to define function orgstruct-mode
Hi! When I try M-x orgstruct-mode I get the error: command-execute: Autoloading file /usr/share/emacs/site-lisp/org/org.elc failed to define function orgstruct-mode Org mode version 9.3.6 (release_9.3.6-449-gb99357 @ /usr/share/emacs/site-lisp/org/) GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.10) of 2019-08-30 Arch Linux What could be going on here? Best, DK
Re: org-clock misleading description for a prompt option
Alright, I see. Thanks for the explanations! сб, 11 апр. 2020 г. в 03:40, Kyle Meyer : > > Dmitrii Korobeinikov writes: > > >> That seems confusing to me as well (at least being the not-advanced > >> clocker that I am). I suspect the confusion comes from the different > >> perspective from which it's written. You're talking about restarting > >> Emacs and clocking in again; the description is, I think, written > >> assuming the context of the prompt being triggered due to idle time. In > >> that scenario, hitting i/q or 'k => all' have the same effect; a new > >> entry is not created. > > > > I am not sure I follow. Is idle time some sort of concept used by > > org-clock for something more than the interface explanations? > > Yes, see > > (info "(org)Resolving idle time") > > Even if you don't customize org-clock-idle-time, the option mentioned in > the second paragraph of that page, you can trigger that prompt manually > to account for being idle by calling org-resolve-clocks (bound to 'C-c > C-x C-z' by default). > > > Whether I restart emacs or purposefully insert (while no clocks are > > running) `CLOCK: [2020-04-10 Fri 22:43]' into a logbook and do > > org-clock-in, the behaviour is the same. > > Right. I'd say that falls into the same category as the restart. The > key, as you mention, it that there is no clock running (versus a clock > running with idle time to account for). > > > Also, 'k => all' is not an > > option for me, it just asks for a number, defaulting to the elapsed > > time. Perhaps it's because I am running an older version of org-mode > > (9.3.6.) > > Sorry for the unclear shorthand. I just meant "hit k, select the > default value to keep all idle time".
Re: org-clock misleading description for a prompt option
> That seems confusing to me as well (at least being the not-advanced > clocker that I am). I suspect the confusion comes from the different > perspective from which it's written. You're talking about restarting > Emacs and clocking in again; the description is, I think, written > assuming the context of the prompt being triggered due to idle time. In > that scenario, hitting i/q or 'k => all' have the same effect; a new > entry is not created. I am not sure I follow. Is idle time some sort of concept used by org-clock for something more than the interface explanations? Whether I restart emacs or purposefully insert (while no clocks are running) `CLOCK: [2020-04-10 Fri 22:43]' into a logbook and do org-clock-in, the behaviour is the same. Also, 'k => all' is not an option for me, it just asks for a number, defaulting to the elapsed time. Perhaps it's because I am running an older version of org-mode (9.3.6.) пт, 10 апр. 2020 г. в 10:47, Kyle Meyer : > > Dmitrii Korobeinikov writes: > > > When you run org-clock-in and then restart emacs, clocking in again > > will show a prompt asking what to do w/ the unfinished entry. "i" > > means "ignore this question; the same as keeping all the idle time". > > However, a new entry is created if this is chosen without doing > > anything about unfinished one. Keeping all the idle time w/ "k" > > updates the unfinished entry before starting a new one. "i" doesn't do > > that, so the description seems a bit misleading. > > That seems confusing to me as well (at least being the not-advanced > clocker that I am). I suspect the confusion comes from the different > perspective from which it's written. You're talking about restarting > Emacs and clocking in again; the description is, I think, written > assuming the context of the prompt being triggered due to idle time. In > that scenario, hitting i/q or 'k => all' have the same effect; a new > entry is not created. > > This resolving on clock-in vs resolving when idle discrepancy shows in > at least one other part of the description: the final sentence says that > the uppercase variants leads to a clocked out state, but that's not true > when org-clock-resolve is triggered from an org-clock-in call. > > So, while I think things could be improved here (contributions welcome), > those changes should keep both contexts in mind.
Folding headings which contain only blank lines
Hi! When everything is folded (e.g. on startup), ellipses show after every heading which has anything in it at all. This is true as well for the headings containing only one or more blank lines. And while you can unfold such lines, you can't fold them back unless you use Shift-Tab. This appears to be inconsistent. Shouldn't it be possible to tab fold such headings too? Best, DK
org-clock misleading description for a prompt option
Hi! When you run org-clock-in and then restart emacs, clocking in again will show a prompt asking what to do w/ the unfinished entry. "i" means "ignore this question; the same as keeping all the idle time". However, a new entry is created if this is chosen without doing anything about unfinished one. Keeping all the idle time w/ "k" updates the unfinished entry before starting a new one. "i" doesn't do that, so the description seems a bit misleading. Best, DK
bug#35419: [O] [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter)
Thank you for the insight and the references! Quite useful to learn about this stuff. вс, 5 апр. 2020 г. в 07:46, Dmitry Gutov : > > Hi! > > Some late clarifications about mmm-mode. > > On 26.04.2019 00:00, Dmitrii Korobeinikov wrote: > > > A lot of the functionality of MMM Mode---that which makes the major mode > > > appear to change---is implemented by saving and restoring the values of > > > local variables, or pseudo-variables. > > > > What I don't understand is where the modes of the submode region run and > > when they are turned on. > > They are run in an empty temporary buffer, see mmm-update-mode-info. > That is true for all the "submodes" in a buffer. The primary major mode > is run in the context of that buffer (IIRC). After any of them runs, the > code responsible for it collects the values of a certain number of known > variables and associates that map with the major mode (this is a bit of > a simplification). > > > Are necessary modes just allowed to run at the right time for the whole > > buffer? > > When you move between the "chunks", no major mode functions are called. > Instead, the values of variables are swapped in. Including the value of > the 'major-mode' variable. > > > But then, how are they limited in their effect to just the > > necessary region? Narrowing? > > Usually, yes. Especially when we're talking about font-lock and > syntax-propertize-function. See mmm-fontify-region-list for an example. > > > Could, for example, syntax checking be done efficiently that way? > > That depends on the combination of modes and how they are used (either > they can be nested, like in web templates, or it's a flat list where > chunks are largely independent like in Jupyter). But in most cases, I > think, you could pick a good strategy. There are no universal ones, though.
Re: Preventing org-cycle from scrolling the buffer
> AFAICS this behavior can be controlled via customizable variable
> org-cycle-hook { M-x customize-variable RET org-cycle-hook RET } by
> removing entry org-optimize-window-after-visibility-change.
Nice, I see!
> IDK. AFAICS you are right with your argumentation. I don't see the
> need of that feature, though, yet. But that's just me. I think you are
> the best candidate to try an implementation of the feature.
I have attached a small patch, seems to be working! Of course, if this
is to be merged, that defvar will have to turn into a defcustom.
Best,
DK
вт, 31 мар. 2020 г. в 21:29, Marco Wahl :
>
> Dmitrii Korobeinikov writes:
> > When calling org-cycle on a collapsed section which contains a lot of
> > text, the headline is adjusted to the top of the page. Collapsing it
> > doesn't revert the scroll, which makes it hard to quickly peek at
> > what's in the section without getting disoriented. Is there a flag or
> > some other way of turning off this autoscroll?
>
> AFAICS this behavior can be controlled via customizable variable
> org-cycle-hook { M-x customize-variable RET org-cycle-hook RET } by
> removing entry org-optimize-window-after-visibility-change.
>
> > Scroll revert wouldn't be so bad to have either, by the way (in
> > addition to, not instead of, though). Since org knows when the cursor
> > moves away from the headline after tabbing, it seems this feature can
> > be implemented without too much hassle. I would even go as far as to
> > suggest making it a default if it gets done.
> >
> > What do you think?
>
> IDK. AFAICS you are right with your argumentation. I don't see the
> need of that feature, though, yet. But that's just me. I think you are
> the best candidate to try an implementation of the feature.
>
>
> Best regards,
> -- Marco
From ee9826f62698b2e5d200fdf90a963ddd751ad679 Mon Sep 17 00:00:00 2001
From: Dmitrii Korobeinikov
Date: Fri, 3 Apr 2020 16:19:33 +0600
Subject: [PATCH] org.el: Add an option to restore scroll position when
collapsing a tree
* lisp/org.el (org-optimize-window-after-visibility-change): Restore the
scroll position after folding a tree (if no commands other than
`org-cycle' get executed in the meantime, so has to be right after
its expansion).
(org-restore-scroll-position-on-collapse): Non-nil for the new behavior.
`org-cycle' scrolls the buffer when expanding a large tree to show as
much of the tree as possible, but doesn't restore the initial view when
folding back, which is disorienting.
TINYCHANGE
---
lisp/org.el | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index 06891b8bd..1b2dfdb8c 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -6071,6 +6071,9 @@ region as a drawer without further ado."
(put 'org-cycle-global-status 'org-state t)
(defvar-local org-cycle-subtree-status nil)
(put 'org-cycle-subtree-status 'org-state t)
+(defvar-local org-scroll-position-to-restore-after-cycling nil)
+(defvar org-restore-scroll-position-on-collapse t
+ "Non-nil if should restore display position after org-cycle folds the tree.")
(defun org-show-all ( types)
"Show all contents in the visible part of the buffer.
@@ -6501,9 +6504,17 @@ This function is the default value of the hook `org-cycle-hook'."
(cond
((eq state 'content) nil)
((eq state 'all) nil)
- ((eq state 'folded) nil)
- ((eq state 'children) (or (org-subtree-end-visible-p) (recenter 1)))
- ((eq state 'subtree) (or (org-subtree-end-visible-p) (recenter 1))
+ ((eq state 'folded)
+ (if (and org-restore-scroll-position-on-collapse
+ (eq last-command this-command))
+ (set-window-start nil org-scroll-position-to-restore-after-cycling)))
+ ((eq state 'children)
+ (setq org-scroll-position-to-restore-after-cycling (window-start))
+ (or (org-subtree-end-visible-p) (recenter 1)))
+ ((eq state 'subtree)
+ (if (not (eq last-command this-command))
+ (setq org-scroll-position-to-restore-after-cycling (window-start)))
+ (or (org-subtree-end-visible-p) (recenter 1))
(defun org-clean-visibility-after-subtree-move ()
"Fix visibility issues after moving a subtree."
--
2.25.1
Preventing org-cycle from scrolling the buffer
HI all, When calling org-cycle on a collapsed section which contains a lot of text, the headline is adjusted to the top of the page. Collapsing it doesn't revert the scroll, which makes it hard to quickly peek at what's in the section without getting disoriented. Is there a flag or some other way of turning off this autoscroll? Scroll revert wouldn't be so bad to have either, by the way (in addition to, not instead of, though). Since org knows when the cursor moves away from the headline after tabbing, it seems this feature can be implemented without too much hassle. I would even go as far as to suggest making it a default if it gets done. What do you think? Best, DK
Re: [BUG] Tags misalign while editing heading
Hi Bastien, Sure, filed it here https://github.com/emacs-evil/evil/issues/1264 Best, Dmitrii вс, 2 февр. 2020 г. в 03:30, Bastien : > > Hi Dmitrii, > > Dmitrii Korobeinikov writes: > > > Oh, I forgot about the "-Q"... Anyway, I figured the behavior is > > present with evil-mode. > > > > Here's is how to launch a clean evil environment: > > > > $ git clone https://github.com/emacs-evil/evil > > $ cd evil > > $ make emacs > > > > Should I file a bug in the evil tracker? > > Yes, probably. Thanks for the follow-up if any, > > -- > Bastien
Re: Command to edit the heading?
Hi, Bastien, Well, the idea was to have consistency, since there's already org-set-tags. But org-set-tags is useful for completion, which can't be said of the title. So I think you are right, plain editing is sufficient. Especially now that I have written a goto-heading function, it's hasn't been a big deal since then. Best, Dmitrii вс, 2 февр. 2020 г. в 03:31, Bastien : > > Hi Dmitrii, > > Dmitrii Korobeinikov writes: > > > There is the org-set-tags for tags, but is there anything for the > > title (org-set-heading/title)? > > Would be nice to have. > > When would it be more useful than editing the headline directly? > > From an agenda view? > > -- > Bastien
Re: Provide org-insert-subitem
Hi, Bastien, > `org-insert-subheading' and `org-insert-todo-subheading' are not used > anywhere in Org's code. Do you them? How? I use them as intended: for convenience. Basically, I have a binding for this: (defun my/insert-heading () (interactive) (end-of-line) (cond ((string-match (rx (and bol (0+ white) "- [")) (thing-at-point 'line t)) (command-execute 'org-insert-todo-heading)) ((string-match (rx (and bol (0+ white) "-")) (thing-at-point 'line t)) (command-execute 'org-insert-item)) (t (if (my/org-heading-collapsed-p) (evil-open-below 1)) (command-execute 'org-insert-heading) (evil-normal-state and a similar function for sub-things. This makes it very easy to insert (sub)headings/items/todo-items, all with just two bindings. > Hitting then seems swift and handy enough. Sometimes that would have to bewhen the items in the list are seperated with a newline. That's an awful lot of combinations for such a basic task, which I do quite often. > WDYT? To me, these functions seem fundamental enough to warrant the according out-of-the-box experience. Best, Dmitrii вс, 2 февр. 2020 г. в 13:49, Bastien : > > Hi Dmitrii, > > Dmitrii Korobeinikov writes: > > > In short: > > org-insert-heading -> org-insert-subheading > > org-insert-todo-heading -> org-insert-todo-subheading > > org-insert-item -> ? > > > > Maybe should provide org-insert-subitem for consistency? > > `org-insert-subheading' and `org-insert-todo-subheading' are not used > anywhere in Org's code. Do you them? How? > > I'm more inclined to delete these commands since they have no binding > than to add an `org-insert-subitem'. > > Hitting then seems swift and handy enough. > > WDYT? > > -- > Bastien
Re: Truncate lines option on file startup
> beware that it can also cause interference. > Here is the code shall someone need it: And just not to leave the bad code be, here is a different, better way: (setq my/org-truncate-option nil) (eval-after-load 'org (lambda () (push (list "truncate" 'my/org-truncate-option 1) org-startup-options) (push (list "notruncate" 'my/org-truncate-option -1) org-startup-options))) And in org-mode hook: (lambda () (case my/org-truncate-option (1 (setq truncate-lines t)) (-1 (setq truncate-lines nil this avoids interference w/ org-startup-truncated while giving flexibility to conditionally set truncation in .dir-locals.el and STARTUP will always work. пн, 11 нояб. 2019 г. в 14:40, Dmitrii Korobeinikov : > > # -*- truncate-lines: t; -*- > > This works nicely, thank you! Never knew about these. > > By the way, I got the STARTUP to function. Turns out it's enough to set > truncate-lines variable and the change is picked up automatically (docs > say: "Calls these functions when changed: (#)"). > Here is the code shall someone need it: > > (eval-after-load 'org > (lambda () > (setq org-startup-truncated nil) > (push (list "truncate" 'truncate-lines t) org-startup-options) > (push (list "notruncate" 'truncate-lines nil) org-startup-options))) > > Note that (setq org-startup-truncated nil) is needed for the notruncate > option to work. Plus the stuff in the org-mode-hook runs after the STARTUP > lines, so beware that it can also cause interference. > > Thanks all! > > вс, 10 нояб. 2019 г. в 18:47, Fraga, Eric : > >> On Sunday, 10 Nov 2019 at 18:12, Dmitrii Korobeinikov wrote: >> > PS if this turns out to be hairy, I can use .dir-locals.el, but the >> feature >> > would still be a nice-to-have. >> >> You could use file local variables for this, e.g. >> >> # Local Variables: >> # truncate-lines: t >> # End: >> >> at the end of your org file or >> >> # -*- truncate-lines: t; -*- >> >> as the first line of your file. >> >> This is not org specific so I guess there is no real justification for >> an org variable for this feature. >> >> -- >> Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-552-g8c5a78 >> >
Re: Truncate lines option on file startup
> # -*- truncate-lines: t; -*- This works nicely, thank you! Never knew about these. By the way, I got the STARTUP to function. Turns out it's enough to set truncate-lines variable and the change is picked up automatically (docs say: "Calls these functions when changed: (#)"). Here is the code shall someone need it: (eval-after-load 'org (lambda () (setq org-startup-truncated nil) (push (list "truncate" 'truncate-lines t) org-startup-options) (push (list "notruncate" 'truncate-lines nil) org-startup-options))) Note that (setq org-startup-truncated nil) is needed for the notruncate option to work. Plus the stuff in the org-mode-hook runs after the STARTUP lines, so beware that it can also cause interference. Thanks all! вс, 10 нояб. 2019 г. в 18:47, Fraga, Eric : > On Sunday, 10 Nov 2019 at 18:12, Dmitrii Korobeinikov wrote: > > PS if this turns out to be hairy, I can use .dir-locals.el, but the > feature > > would still be a nice-to-have. > > You could use file local variables for this, e.g. > > # Local Variables: > # truncate-lines: t > # End: > > at the end of your org file or > > # -*- truncate-lines: t; -*- > > as the first line of your file. > > This is not org specific so I guess there is no real justification for > an org variable for this feature. > > -- > Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-552-g8c5a78 >
Truncate lines option on file startup
Hi, Thought it would be handy to be able to do this: #+STARTUP: truncate and #+STARTUP: notruncate Modifying org-startup-options manually wouldn't work as it describes how to change a value of a variable or push onto a list, but no syntax for function calls and for this to work toggle-truncate-lines is to be envoked. I know about org-startup-truncated, but it's not file-by-file precision. PS if this turns out to be hairy, I can use .dir-locals.el, but the feature would still be a nice-to-have. Regards, Dmitrii
Re: Good way to pre/view LaTeX-lines?
>> https://ivanaf.com/Automatic_Latex_Fragment_Toggling_in_org-mode.html Exactly what I wanted. I will be using this. BTW just as a minor point, no need for setq when byte-compiling, https://www.gnu.org/software/emacs/manual/html_node/elisp/Compilation-Functions.html#Compilation-Functions /This function byte-compiles the function definition of symbol, replacing the previous definition with the compiled one./ And thank you! Regards, Dmitrii пн, 28 окт. 2019 г. в 07:22, Ivan Tadeu Ferreira Antunes Filho < iva...@mit.edu>: > for 2 I have adapted a solution from jkitchin: > > https://ivanaf.com/Automatic_Latex_Fragment_Toggling_in_org-mode.html > > > *Ivan Tadeu Ferreira Antunes Filho* > > > On Sun, Oct 27, 2019 at 3:29 PM Dmitrii Korobeinikov > wrote: > >> > https://orgmode.org/org.html#Previewing-LaTeX-fragments >> >> Thank you, William! This is great. >> >> After some digging, I still gotta wonder about a few things though. >> 1. Is there some sort of live-editing feature? By that I mean, being able >> to view the result (in a seperate buffer or minibuffer or even on the next >> line) as you type out the expression. In particular, it would be nice to >> know how to show an image in the minibuffer (and if possible at all) and >> how to effectively feed what's under cursor to the latex backend and get >> the image. >> 2. It would be handy to autoremove the image overlay when the cursor is >> on the fragment (and restore it when goes outside). I think no redraw >> should be necessary unless the the formula is edited. >> >> I guess I would have to dig into org-toggle-latex-fragment to know how to >> do these, but any help/pointers would be appreciated. >> >> Regards, >> Dmitrii >> >> вс, 27 окт. 2019 г. в 21:07, William Denton : >> >>> On 27 October 2019, Dmitrii Korobeinikov wrote: >>> >>> > I am looking for a comfortable way to view LaTeX (for math formulas) in >>> > org-mode. >>> >>> This shows how: >>> >>> https://orgmode.org/org.html#Previewing-LaTeX-fragments >>> >>> I don't use it often, but it works very nicely. >>> >>> Bill >>> -- >>> William Denton :: Toronto, Canada --- Listening to Art: >>> https://listeningtoart.org/ >>> https://www.miskatonic.org/ --- GHG.EARTH: https://ghg.earth/ >>> Caveat lector. --- STAPLR: https://staplr.org/ >>> >> ___ >> Ita mailing list >> i...@mit.edu >> http://mailman.mit.edu/mailman/listinfo/ita >> >
Re: Good way to pre/view LaTeX-lines?
Cool, I didn't know about maxima. I will look into trying it out. Thanks! Regards, Dmitrii пн, 28 окт. 2019 г. в 07:08, briangpowell . : > * Suggest reviewing these free software packages: > https://itsfoss.com/latex-editors-linux/ > > ** LyX and/or Kile are my faves > > ** Suggest trying these free software packages too > > apt-get install imaxima > apt-get install maxima > apt-get install maxima-emacs > apt-get install texlive > apt-get install texlive-math-extra > > > > > > > > On Sun, Oct 27, 2019 at 3:29 PM Dmitrii Korobeinikov > wrote: > >> > https://orgmode.org/org.html#Previewing-LaTeX-fragments >> >> Thank you, William! This is great. >> >> After some digging, I still gotta wonder about a few things though. >> 1. Is there some sort of live-editing feature? By that I mean, being able >> to view the result (in a seperate buffer or minibuffer or even on the next >> line) as you type out the expression. In particular, it would be nice to >> know how to show an image in the minibuffer (and if possible at all) and >> how to effectively feed what's under cursor to the latex backend and get >> the image. >> 2. It would be handy to autoremove the image overlay when the cursor is >> on the fragment (and restore it when goes outside). I think no redraw >> should be necessary unless the the formula is edited. >> >> I guess I would have to dig into org-toggle-latex-fragment to know how to >> do these, but any help/pointers would be appreciated. >> >> Regards, >> Dmitrii >> >> вс, 27 окт. 2019 г. в 21:07, William Denton : >> >>> On 27 October 2019, Dmitrii Korobeinikov wrote: >>> >>> > I am looking for a comfortable way to view LaTeX (for math formulas) in >>> > org-mode. >>> >>> This shows how: >>> >>> https://orgmode.org/org.html#Previewing-LaTeX-fragments >>> >>> I don't use it often, but it works very nicely. >>> >>> Bill >>> -- >>> William Denton :: Toronto, Canada --- Listening to Art: >>> https://listeningtoart.org/ >>> https://www.miskatonic.org/ --- GHG.EARTH: https://ghg.earth/ >>> Caveat lector. --- STAPLR: https://staplr.org/ >>> >>
Re: Good way to pre/view LaTeX-lines?
> https://orgmode.org/org.html#Previewing-LaTeX-fragments Thank you, William! This is great. After some digging, I still gotta wonder about a few things though. 1. Is there some sort of live-editing feature? By that I mean, being able to view the result (in a seperate buffer or minibuffer or even on the next line) as you type out the expression. In particular, it would be nice to know how to show an image in the minibuffer (and if possible at all) and how to effectively feed what's under cursor to the latex backend and get the image. 2. It would be handy to autoremove the image overlay when the cursor is on the fragment (and restore it when goes outside). I think no redraw should be necessary unless the the formula is edited. I guess I would have to dig into org-toggle-latex-fragment to know how to do these, but any help/pointers would be appreciated. Regards, Dmitrii вс, 27 окт. 2019 г. в 21:07, William Denton : > On 27 October 2019, Dmitrii Korobeinikov wrote: > > > I am looking for a comfortable way to view LaTeX (for math formulas) in > > org-mode. > > This shows how: > > https://orgmode.org/org.html#Previewing-LaTeX-fragments > > I don't use it often, but it works very nicely. > > Bill > -- > William Denton :: Toronto, Canada --- Listening to Art: > https://listeningtoart.org/ > https://www.miskatonic.org/ --- GHG.EARTH: https://ghg.earth/ > Caveat lector. --- STAPLR: https://staplr.org/ >
Good way to pre/view LaTeX-lines?
Hi, I am looking for a comfortable way to view LaTeX (for math formulas) in org-mode. I am not working with whole LaTeX files however, but rather with occasional lines of LaTeX inside an org-mode file. Good possibilities could be: 1. rendering a LaTeX-line *in the minibuffer* (when a cursor is placed on that line), or 2. rendering right there in the buffer. Emacs can show images, so these can't be too hard, right? Anyone know how to make this work? Best, Dmitrii
Re: [O] [BUG] Tags misalign while editing heading
Oh, I forgot about the "-Q"... Anyway, I figured the behavior is present with evil-mode. Here's is how to launch a clean evil environment: $ git clone https://github.com/emacs-evil/evil $ cd evil $ make emacs Should I file a bug in the evil tracker? Regards, Dmitrii. ср, 25 сент. 2019 г. в 09:00, David Masterson : > Dmitrii Korobeinikov writes: > > > When I edit a heading (the title), if I add characters, the tags > auto-align. > > But if I remove text, tags shift left and so are no longer aligned. > > Need much more information about your setup. You wouldn't, by chance, > be sharing your Org files with BeOrg on an iPhone? > > -- > David >
[O] [BUG] Tags misalign while editing heading
When I edit a heading (the title), if I add characters, the tags auto-align. But if I remove text, tags shift left and so are no longer aligned. Regards, Dmitrii
[O] Command to edit the heading?
There is the org-set-tags for tags, but is there anything for the title (org-set-heading/title)? Would be nice to have. Regards, Dmitrii
[O] Provide org-insert-subitem
In short: org-insert-heading -> org-insert-subheading org-insert-todo-heading -> org-insert-todo-subheading org-insert-item -> ? Maybe should provide org-insert-subitem for consistency? Regards, Dmitrii
Re: [O] Both italic and bold at the "edges": a bug?
Hi, Yes, how emacs renders this is what I meant. Regards, Dmitrii сб, 7 сент. 2019 г. в 01:37, Nicolas Goaziou : > Hello, > > Dmitrii Korobeinikov writes: > > >Here is what I mean. Everything in these will be italic-only: > > > >- /*italic, not bold*/ > >- /italic, *not bold*/ > >- /*italic*, not bold/ > > > >Is there a reason for not allowing multiple highlighters to start in > the > > same place? > > They are allowed. Try exporting this document to, e.g., LaTeX. > > You may be talking about fontification, which is but an approximation of > the real Org syntax (but it could be improved). > > Regards, > > -- > Nicolas Goaziou >
[O] Both italic and bold at the "edges": a bug?
Here is what I mean. Everything in these will be italic-only: - /*italic, not bold*/ - /italic, *not bold*/ - /*italic*, not bold/ Is there a reason for not allowing multiple highlighters to start in the same place? Regards, Dmitrii.
[O] [Performance] org-indent-mode slows down checklists
Reproduction steps: 1. emacs -Q 2. (progn (end-of-buffer) (insert "* Section [0/0]\n") (dotimes (n 150 nil) (insert "- [ ] item\n")) (org-mode)) 3. Try C-c on an item 4. turn on (org-indent-mode) and C-c gets noticably slow(er) Org mode version 9.1.9 (release_9.1.9-65-g5e4542 @ /usr/share/emacs/26.2/lisp/org/) Emacs 26.2 Regards, Dmitrii
Re: [O] Duplicate tags
BTW one possible behavior is to move the old tag to the end, providing both feedback and function вт, 3 сент. 2019 г. в 16:29, Dmitrii Korobeinikov : >org-set-tags-command allows duplicates. Example: >- M-x org-set-tags-command -> "tag" >- M-x org-set-tags-command -> "tag" >Result: >* Title:tag:tag: > >I think it would be handy to prevent this. >Not unimaginable that someone could use this as a feature, though, in > which case, a flag would be nice. > >Regards, >Dmitrii. >
[O] Duplicate tags
org-set-tags-command allows duplicates. Example: - M-x org-set-tags-command -> "tag" - M-x org-set-tags-command -> "tag" Result: * Title:tag:tag: I think it would be handy to prevent this. Not unimaginable that someone could use this as a feature, though, in which case, a flag would be nice. Regards, Dmitrii.
[O] Disallow empty tags
Creating an empty tag renders TAB-completion useless. Example: * Title :a::b: Pressing TAB in org-set-tags-command will now insert a colon `:`, which is quite puzzling to see. I thought something was wrong w/ my bindings till I noticed this was happening only in one of my files. Can such tags be ignored/disallowed as they hold no evident purpose? Regards, Dmitrii
Re: [O] org-todo & empty title -> misaligned tags
Thanks! пн, 12 авг. 2019 г. в 15:37, Carsten Dominik : > Fixed, thank you for the report. > > Carsten > > On Sun, Aug 11, 2019 at 1:27 PM Dmitrii Korobeinikov > wrote: > >>Reproduction steps (tested w/ emacs -Q): >>Version: GNU Emacs 26.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version >> 3.24.8) of 2019-04-13 >> >>1. M-x org-mode >>2. (insert "* ") >>3. M-x org-set-tags-command, enter any tag name >>4. M-x org-todo >> >>The tag jumps right next to the asterisk (expected: stays where it >> is). Doesn't happen if the title is not empty. >> >>5. M-x org-set-tags-command resets the tags back where they belong >> >>I think it's a bug. >> >
[O] org-todo & empty title -> misaligned tags
Reproduction steps (tested w/ emacs -Q): Version: GNU Emacs 26.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.8) of 2019-04-13 1. M-x org-mode 2. (insert "* ") 3. M-x org-set-tags-command, enter any tag name 4. M-x org-todo The tag jumps right next to the asterisk (expected: stays where it is). Doesn't happen if the title is not empty. 5. M-x org-set-tags-command resets the tags back where they belong I think it's a bug.
Re: [O] [Proposal] Source Blocks with Post-Extensions
Dear Martin, Your approach to test cases is quite valuable for more structured projects and for automation. For something that's either quick or w/out much architectural certainty to it, I would still prefer the handy one-liners. Nonetheless, thanks for the example! Best, Dmitrii. чт, 27 июн. 2019 г. в 04:09, Martin Alsinet : > Dmitrii, > > I use a different approach, where I tangle the source into files in > modules and then I import those modules from other blocks. > This allows me to organize my document with different sections for the > code and its tests, which then get exported into their corresponding files. > > > * Square Function > > This function receives a number and returns its square > > #+BEGIN_SRC python :tangle ./utils/math.py :mkdirp yes > def square(x): > return x * x > #+END_SRC > > ** __init__.py (module setup) > > #+begin_src python :tangle ./utils/__init__.py :mkdirp yes > from utils.math import square > > #+end_src > > ** Test cases > > 1. The square of five should be 25 > 2. The square of zero should be 0 > 3. The square of a negative number should be positive > > #+BEGIN_SRC python :tangle ./utils/test_square.py :mkdirp yes > from utils.math import square > > def test_square_of_five(): > assert square(5) == 25 > > def test_square_of_zero(): > assert square(0) == 0 > > def test_square_of_negative(): > assert square(-5) > 0 > #+END_SRC > > *** Run tests > > #+begin_src sh :results output raw > pytest ./utils > #+end_src > > #+RESULTS: > = test session starts > == > platform linux -- Python 3.7.3, pytest-4.6.3, py-1.8.0, pluggy-0.12.0 > rootdir: /app > collected 3 items > > utils/test_square.py ... > [100%] > > === 3 passed in 0.08 seconds > === > > > > > > > On Wed, Apr 24, 2019 at 2:19 PM Dmitrii Korobeinikov > wrote: > >> Sorry for not answering these two days. >> >> You are right, that's an option. >> But I just don't think that's the best possible one - for usability. >> >> Introducing this would imply architectural decisions, so it might not be >> immediately clear if it's right or not. >> Especially that the improvement might not seem that big. >> So, I understand that. >> >> I have proposed buffer lenses today and they seem like something that can >> solve the issue from the user side. Hopefully they will get some traction. >> >> пн, 22 апр. 2019 г. в 23:31, Berry, Charles : >> >>> >>> >>> > On Apr 22, 2019, at 10:15 AM, Dmitrii Korobeinikov >>> wrote: >>> > >>> > Thank you! >>> > That's a handy technique and it does help. >>> > As I understand, there's no way to extend that to multiple lines? >>> >>> AFAICS, no there is no way to split the :epilogue arg to multiple lines. >>> >>> Of course, you can always follow a src block that provides a function >>> with another src block that imports the code via noweb and then tests the >>> function with as many lines of code as you need. >>> >>> Chuck >>> >>> >>> >>>
[O] bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter)
Dear Ihor, > Regarding the question about buffer-lens interaction. Let's take even > more complicated example: To run the command, the user hits some key > combination, which happens to be bound to different commands in the main > buffer and in the lense buffer (i.e. the main buffer is in org-mode, the > lense is in mingus-mode, and the key is C-d). What should be the > behaviour in such a case? run the commands in both the buffers? decide > depending on the point position? It is easy to make up similar > complicated examples if you consider some exotic major modes in the > lense buffer. It's basically a question of customization, a client-side decision. In other words, this really depends on what the user wants to happen. This customization is done through the controller of the lens. To your example. If the desirable behavior (for you, as a user) for C-d is to run in the lens, then add "C-d" to the controller of the lens. And then, whenever the point is in the area, C-d runs in the lens unconditionally. (For the sake of terminology, we can say that the keybinding is "redirected".) If you want C-d to work conditionally (sometimes do the org-mode thing and sometimes the mingus-mode thing), I am afraid there is nothing better than to update the controller yourself on the go. And that's fine, because that's what the user wants (to use the same bind for two different things in the same place at different times). (BTW, the controller could be asked to work "in reverse" and redirect all keybindings, except the ones in its black list.) But speaking of the larger picture and integration, a user can define a list of key combinations for any mode and the list will be added to the controller if the lens runs that mode. I think this should cover the vast majority of use-cases. Of course, there is no reason for the logic of key addition not to be flexible enough to cover anything more exotic. > I think that it would be more effective if someone decide on some basic > approach for the low-level implementation of the lense-mode (which > probably involves modifying emacs C-level source code) and continue the > discussion according to the benefits/limitations of that kind of > implementation. I too look forward to hearing from someone about the low-level implementation possibilities :) I especially hope the approach for the border-case issue (as described in my previous message) can work. Best regards, Dmitrii.
[O] bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter)
Dear Ihor, > Note that indirect buffers always share *all* the contents with the master > buffer. As a result, it may not be easy to make things like flyspell > work on code blocks in org-mode, if these code blocks are treated as > lenses. I tried flyspell w/ different dictionaries on 2 buffers. The dictionary is switched every time I switch into one of the buffers. You are right, ispell and the like working w/ a file directly would have to learn to work w/ indirect buffers by managing multiple simultaneous processes. Fortunately, that doesn't seem like a big hurdle. >> (1) A question: when an indirect buffer is created and some region is >> narrowed to, is the rest of the buffer duplicated in memory somewhere? If >> this is so, there could be a useful efficiency-related modification to >> indirect buffers, which would allow "hard-narrowing": not duplicating the >> rest of the base buffer. > > There is no duplication of the buffer content in indirect buffers. > Internally, indirect buffer's content is a pointer to the main buffer > content. If you modify text in any of the indirect buffers or in the > main buffer, the text is modified in all of them and in the main buffer. > Only the buffer-local variables are duplicated. > You can refer to "27.11 Indirect Buffers" in the elisp manual for > details. Bad choice of wording on my side, I didn't mean duplication, but rather keeping unnecessary info, like text properties in the newly created indirect buffer, in the regions which were "permanently" chosen to be narrowed-out. Anyway, this is a premature optimization for now. > > The next immediately outstanding question is: > > (2) how can "embedding" (of a buffer as a part of another buffer as an > > area) be done efficiently? This could possibly be approached as two > > problems: (i) displaying the area and (ii) interacting with it. > > Any ideas? > > These issues have been discussed in > https://lists.gnu.org/archive/html/emacs-devel/2018-07/msg00863.html. > As I remember, the discussion stopped without a clear conclusion. It was > not clear how to separate the main buffer contents from the nested > buffer (I treat them as analogue of the buffer lenses). Another issue > was how the keymaps and buffer-local variables would interact when the > point is within a lense. It was not clear what should be the priority. The short answer is probably that lens-mode looks at the changes to the buffer and decides what's what. Here is my vision for this. Say, you have an indirect buffer, call it A, it's base has contents: > line 1 > line 2 > line 3 Also, there is a buffer, call it B, where we want to embed A, with contents: > word 1 > instruction: lens that displays A > word 2 Lens-mode decides to identify the second line as a lens and constructs layout of the file. > [text] > [lens#A] > [text] Now, construct and display the final buffer as: > word 1 > line 1 > line 2 > line 3 > word 2 The core question: how is this "displaying" done. In part, somewhat like how indirect buffers function. A displayed piece of text is a pointer/reference to the text in the indirect buffer. Of course, this should be done in a way so that the modes running in B don't change the properties of the text (following the layout constructed by lens-mode as in the example above). Though, this might better be done at the display unit level. What about interaction? Well, when the cursor is inside the lens, the controller decides what to do w/ each keybinding, whether to redirect it to the indirect buffer or not. And what about the case when borders are crossed? As I see it, any code that executes - does so as is. For instance, consider a buffer with a lens (contents: "lens"), which looks like this: "word1 lens word2". Place the cursor on the first word, run a command to remove 2 words. Now there are to possibilities here, depending on the implementation of the function which does the removal: 1. Implementation identifies the boundaries of deletion and removes the words as contents of the main buffer. Lens-mode identifies the removal and deletes the lens altogether. 2. Delete "word1" -> the cursor is on "lens" -> next deletion command is redirected to the indirect buffer, which does the removal. Lens-mode identifies the lens as empty and removes it. The second way might not be always desirable, so whenever a function is called with the cursor outside a lens, as an option, decide to never redirect the input to a lens while the function runs. For another case, consider the first example with lines and, cursor being in the beginning of the file, remove three lines. To make this interesting, assume the first kind of implementation runs, identifying the bounds, never redirecting a command to the lens. Well, if the implementation of the lens is inspired by how indirect buffers work, I imagine, the necessary changes in the embedded buffer take place directly, in which case everything works as desirable. Afterwards, lens-mode processes the
[O] bug#35419: bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter)
Understood, thank you! пт, 3 мая 2019 г. в 17:03, Roland Everaert : > For what I understand of eev (which I discover following this thread), > the idea is to create "notebooks" (à la Jupyter) of commands that can be > executed in > any orders the user want. So, lenses could be useful to apply the > correct mode the block of code at point. > > Dmitrii Korobeinikov writes: > > >> I see lens to be useful for the eev mode, too. > > > > Never heard of eev, but judging by some demos, it's a way to execute > elisp > > commands interactively. > > Something like stitching blocks of commands together, or the data to > > operate on, or embedding a target such as a shell in the same buffer is > the > > use-case idea then? > > > -- > Luke, use the FOSS > > Sent from Emacs >
[O] bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter)
I found a clarification on how mmm-mode works. https://github.com/polymode/polymode/issues/187 > mmm-mode also allows having multiple major modes depending on cursor position in the buffer. However, it does not fully replace major mode locally. This mode is only taking care about keymap, menu, local variables, font-lock, and indentation. It does not really take care about the minor modes and does not run the submode hooks either. Just to reiterate, polymode's idea is to switch between indirect buffers, one for each major mode. OK, detail largely disregarded, I now can draw a bird-eye view comparison between lenses and multi-mode modes. - Neither polymode nor mmm-mode treat a region as if it were truly on its own in a seperate buffer. Effects: no stuff like seperate truncation options, implied syntax checking and so on. - Moreover, the region must be a part of the buffer. Effects: no data sharing between buffers, no possibility of stitching different buffers together, etc. Now, with these out of the way. Indirect buffers give the answer to the issue of sharing some textual data between several buffer. (1) A question: when an indirect buffer is created and some region is narrowed to, is the rest of the buffer duplicated in memory somewhere? If this is so, there could be a useful efficiency-related modification to indirect buffers, which would allow "hard-narrowing": not duplicating the rest of the base buffer. The next immediately outstanding question is: (2) how can "embedding" (of a buffer as a part of another buffer as an area) be done efficiently? This could possibly be approached as two problems: (i) displaying the area and (ii) interacting with it. Any ideas?
[O] bug#35419: bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter)
> I see lens to be useful for the eev mode, too. Never heard of eev, but judging by some demos, it's a way to execute elisp commands interactively. Something like stitching blocks of commands together, or the data to operate on, or embedding a target such as a shell in the same buffer is the use-case idea then?
[O] bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter)
чт, 25 апр. 2019 г. в 23:52, Philipp Stephani : > Am Do., 25. Apr. 2019 um 10:41 Uhr schrieb Dmitrii Korobeinikov > : > > I have imagined that at the low level there is an actual data structure > that keeps the raw textual data and it could be directly shared by multiple > buffers. > > That's what indirect buffers do. Maybe the indirect buffer > functionality could be beefed up to support what you want? > https://www.gnu.org/software/emacs/manual/html_node/emacs/Indirect-Buffers.html > The text of the indirect buffer is always identical to the text of its base buffer; changes made by editing either one are visible immediately in the other. But in all other respects, the indirect buffer and its base buffer are completely separate. They can have different names, different values of point, different narrowing, different markers, different major modes, and different local variables. Awesome! Looks like we have some solid rails to drive on. BTW what's the purpose of lentic-mode then? To be "providing multiple persistent views"? https://github.com/phillord/lentic
[O] bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter)
Dear Ihor, > Another use case for me is to speed up agenda creation. > I usually do not like to split my org files into too many. However, it > results in very large and slow org buffers later. If I can store some > parts of the org files externally and only show them if some condition > is met (say, for certain todo state of the parent entry), it would speed > up my agenda and the buffer navigation quite significantly. That's a good one! > Let me put some historical context to this proposal. > There was a discussion of similar feature in emacs-dev last year. > The idea was to implement nested buffers: > https://lists.gnu.org/archive/html/emacs-devel/2018-07/msg00863.html An interesting read, provides another use-case (collect external data in one place to easily view/edit): https://lists.gnu.org/archive/html/emacs-devel/2018-07/msg00890.html > There are also several projects, which implement part of the > functionality you described: > - mmm-mode: https://github.com/purcell/mmm-mode > - polymode: https://github.com/polymode/polymode Pretty cool stuff. For thoroughness, let's discuss how these work. I found a comment which mentions polymode's working principle. https://www.reddit.com/r/emacs/comments/50p34n/polymode_is_awesome/?depth=1 >> Polymode doesn't keep its modes in a single emacs buffer but in several indirect buffers, as many as different modes are there in a file. Consequently, polymode is as fast as switching emacs buffers because it never re-installs major modes like other multi-modes do. Dave Love's multi-mode.el gets full credit for this idea. > It looks like it slows emacs to a crawl in my main org config file. It seems to work fairly well in some of my notes files (though with some weird indenting behavior). Basically, simplicity is in place but at the cost of duplication. Lenses could avoid duplication, while yielding increased functionality and speed. (e.g. in polymode, a syntax checker couldn't yield correct results unless narrowing was constantly used, which is inefficient) Now, to MMM-mode. According to the info file: > Within the file, MMM-mode creates /submode regions/ within which other major modes are in effect. > While the point is in a submode region, the following changes occur: > <...> keymap <...> local variables <...> syntax table and indentation <...> font-lock > The submode regions are represented internally by Emacs Lisp objects known as /overlays/. > A lot of the functionality of MMM Mode---that which makes the major mode > appear to change---is implemented by saving and restoring the values of > local variables, or pseudo-variables. What I don't understand is where the modes of the submode region run and when they are turned on. Are necessary modes just allowed to run at the right time for the whole buffer? But then, how are they limited in their effect to just the necessary region? Narrowing? Could, for example, syntax checking be done efficiently that way? Could someone, please, explain? Best regards, Dmitrii.
[O] bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter)
> Have you looked at Phil Lord's lentic package? I think it implements a > lot of what you're talking about. > https://github.com/phillord/lentic This is nice to see! Indeed, except for embedding, there is a large overlap with what I described as buffer lenses. BTW, judging by this description: "changes percolation now happens incrementally, so only those parts of the buffer are updated. As a result, lentic now cope with long files with little noticable delay", the buffers don't share any data and need to sync with the master [linked] buffer. Is this the best solution? I have imagined that at the low level there is an actual data structure that keeps the raw textual data and it could be directly shared by multiple buffers. I mean, when a buffer is saved to a file, the text doesn't need to be stripped of properties beforehand, right? чт, 25 апр. 2019 г. в 07:37, Noam Postavsky : > Dmitrii Korobeinikov writes: > > > * Implementation > > > > I am not familiar with Emacs internals to say what's feasible of the > > proposed structure. > > Have you looked at Phil Lord's lentic package? I think it implements a > lot of what you're talking about. > > https://github.com/phillord/lentic >
[O] [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter)
I have written a proposal for buffer lenses which could prove useful in Org-mode, especially for interacting with code. If you are interested, please, see this link: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35419
Re: [O] [Proposal] Source Blocks with Post-Extensions
Sorry for not answering these two days. You are right, that's an option. But I just don't think that's the best possible one - for usability. Introducing this would imply architectural decisions, so it might not be immediately clear if it's right or not. Especially that the improvement might not seem that big. So, I understand that. I have proposed buffer lenses today and they seem like something that can solve the issue from the user side. Hopefully they will get some traction. пн, 22 апр. 2019 г. в 23:31, Berry, Charles : > > > > On Apr 22, 2019, at 10:15 AM, Dmitrii Korobeinikov > wrote: > > > > Thank you! > > That's a handy technique and it does help. > > As I understand, there's no way to extend that to multiple lines? > > AFAICS, no there is no way to split the :epilogue arg to multiple lines. > > Of course, you can always follow a src block that provides a function with > another src block that imports the code via noweb and then tests the > function with as many lines of code as you need. > > Chuck > > > >
Re: [O] [Proposal] Source Blocks with Post-Extensions
Thank you! That's a handy technique and it does help. As I understand, there's no way to extend that to multiple lines? One-liners for tests are enough sometimes, but not always. For those cases, it is cumbersome to split as well. пн, 22 апр. 2019 г. в 22:51, Berry, Charles : > It looks like you want the :epilogue header argument. See inline. > > > On Apr 22, 2019, at 2:00 AM, Dmitrii Korobeinikov > wrote: > > > > When I write several source blocks, which depend on one another, I tend > to debug them one by one. > > > > So, I write this function and test it: > > > > #+NAME: square > > #+BEGIN_SRC python > > square = lambda x: x * x > > return square(5) > > #+END_SRC > > > > #+RESULTS: square > > : 25 > > > > > Equivalently, you could run this: > > #+NAME: square > #+BEGIN_SRC python :epilogue return square(5) > square = lambda x: x * x > #+END_SRC > > > > > After I see that the test is successful, I write this client function: > > > > #+BEGIN_SRC python :noweb yes > > <> > > return 5 + square(5) > > #+END_SRC > > > > #+RESULTS: > > : 25 > > > > And here, to get the correct result, I have to remove the ~return > square(5)~ line in ~<>~. > > But I don't want to lose testing! > > S > > With my version of `square`, the epilogue is not included. > > So it works as you want it to. > > HTH, > > Chuck > > >
[O] [Proposal] Source Blocks with Post-Extensions
For your convenience, I have attached this e-mail as an org-mode file. When I write several source blocks, which depend on one another, I tend to debug them one by one. So, I write this function and test it: #+NAME: square #+BEGIN_SRC python square = lambda x: x * x return square(5) #+END_SRC #+RESULTS: square : 25 After I see that the test is successful, I write this client function: #+BEGIN_SRC python :noweb yes <> return 5 + square(5) #+END_SRC #+RESULTS: : 25 And here, to get the correct result, I have to remove the ~return square(5)~ line in ~<>~. But I don't want to lose testing! So I find nothing better to do than to seperate the source block: #+NAME: square-1 #+BEGIN_SRC python square = lambda x: x * x #+END_SRC And, by the way, there was no error/warning that I have just redefined ~<>~, so, for the test-snippet below to work, I renamed it to ~<>~. I think the org-mode team is aware of it, but anyway: - [ ] no error checking of the description of a code block. #+NAME: square-1-tester #+BEGIN_SRC python :noweb yes <> return square(5) #+END_SRC #+RESULTS: square-1-tester : 25 - [ ] For every such source block used for testing purposes, you have to repeat the inclusion statement and part of the name, which is cumbersome. A fair solution is maybe to extend the block like this: #+NAME: square-1 #+BEGIN_SRC python square = lambda x: x * x #+END_SRC return square(5) #+END_SRC_TEST When I call this individually, the test part would run, but when I :noweb it in another block, the test part would be ommited. As an extension of this idea, it could be useful to have several test attachments like this, each producing its own result. Maybe, the TEST part could as well be ommited. Custom names are also an option: #+NAME: square-multiple #+BEGIN_SRC python square = lambda x: x * x #+END_SRC return square(5) #+END_SRC NAME: ext_1 return square(10) #+END_SRC NAME: ext_2 #+RESULTS: square-multiple-ext-1 : 25 #+RESULTS: square-multiple-ext-2 : 100 Overall, these techniques should reduce noise and increase usability. org-test-suite.org Description: Binary data
