Re: [PATCH] org-src.el Do not ask to revert unmodified buffers
You are right I clearly missed org-src-ask-before-returning-to-edit-buffer Don't know how . . . Sorry for the noise. Kyle Meyer writes: Thanks for the patch. pillule writes: Hi, it is asked to the user if we want to revert changes when re-entering in a org-source buffer. Even if the buffer have no modifications. Hmm, that description seems to be focusing on the prompt's parenthetical note. When org-src-ask-before-returning-to-edit-buffer is non-nil and there's an existing source buffer, the caller is asked whether to return to it or regenerate/overwrite it. The message warns that the second option (i.e. answering "no, don't return to existing buffer") will discard changes. It looks like this patch assumes that, when the buffer is unmodified, the answer to the above question necessarily becomes "yes, return to the existing buffer", but it's not clear to me why that should be. With an unmodified buffer, I suppose there's less of a difference between the two answers, but at least with the default org-src-window-setup value, there's still a user-visible difference in terms of window organization. --
[PATCH] org-agenda.el: Rename org-agenda-format-item parameters
* org-agenda.el (org-agenda-format-item): Rename parameters so they don't clash with dynamic variables used by `org-prefix-format-compiled'. TINYCHANGE --- lisp/org-agenda.el | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 33b3786f2..f22e6fa65 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -6654,14 +6654,14 @@ The flag is set if the currently compiled format contains a `%b'.") (cl-return (cadr entry)) (cl-return (apply #'create-image (cdr entry))) -(defun org-agenda-format-item (extra txt level category tags dotime +(defun org-agenda-format-item (extra txt with-level with-category tags dotime remove-re habitp) "Format TXT to be inserted into the agenda buffer. In particular, add the prefix and corresponding text properties. EXTRA must be a string to replace the `%s' specifier in the prefix format. -LEVEL may be a string to replace the `%l' specifier. -CATEGORY (a string, a symbol or nil) may be used to overrule the default +WITH-LEVEL may be a string to replace the `%l' specifier. +WITH-CATEGORY (a string, a symbol or nil) may be used to overrule the default category taken from local variable or file name. It will replace the `%c' specifier in the format. DOTIME, when non-nil, indicates that a time-of-day should be extracted from @@ -6698,7 +6698,7 @@ Any match of REMOVE-RE will be removed from TXT." (defvar breadcrumbs) (defvar category) (defvar category-icon) (defvar effort) (defvar extra) (defvar level) (defvar tag) (defvar time)) - (let* ((category (or category + (let* ((category (or with-category (if buffer-file-name (file-name-sans-extension (file-name-nondirectory buffer-file-name)) @@ -6796,7 +6796,7 @@ Any match of REMOVE-RE will be removed from TXT." time-grid-trailing-characters))) (t "")) category (if (symbolp category) (symbol-name category) category) - level (or level "")) + level (or with-level "")) (if (string-match org-link-bracket-re category) (progn (setq l (string-width (or (match-string 2) (match-string 1 -- 2.31.0
[PATCH 1/1] org-src.el: Add option to delay fontification of source blocks
From: Leo Okawa Ericson * lisp/org-src.el (org-src-font-lock-fontify-block): Add option to delay fontification of source blocks. If `org-src-font-lock-fontify-idle-delay' is non-nil fontification of code blocks is delayed until the user has become idle. Fontification of source blocks can be very slow. This will add an option for users to delay the fontification until they have become idle so that the typing delay is kept low. The trade-off is that there will be no syntax highlighting when the user is typing. --- lisp/org-src.el | 29 + 1 file changed, 29 insertions(+) diff --git a/lisp/org-src.el b/lisp/org-src.el index 20acee4e6..b1446e105 100644 --- a/lisp/org-src.el +++ b/lisp/org-src.el @@ -584,11 +584,40 @@ (defun org-src--edit-element ;;; Fontification of source blocks +(defvar org-src-font-lock-fontify-idle-timer nil + "Idle timer to use for when fontifying with a timer.") + + +(defvar org-src-font-lock-fontify-idle-delay nil + "Duration of the delay until fontification of source blocks. +If non-nil, source blocks are fontified when the user has been +idle for `org-src-font-lock-fontify-idle-delay' seconds. This +means that instead of applying syntax highlighting when you type +it is delayed until you become idle. Not that when typing there +will be no fontification. +") (defun org-src-font-lock-fontify-block (lang start end) "Fontify code block. This function is called by emacs automatic fontification, as long as `org-src-fontify-natively' is non-nil." + (if org-src-font-lock-fontify-idle-delay + (progn +(when org-src-font-lock-fontify-idle-timer + (cancel-timer org-src-font-lock-fontify-idle-timer)) +(setq org-src-font-lock-fontify-idle-timer + (let ((buf (current-buffer))) +(run-with-idle-timer + org-src-font-lock-fontify-idle-delay + nil + (lambda () + (with-current-buffer buf + (org-src-font-lock-fontify-block-1 lang start end) + (when org-src-font-lock-fontify-idle-timer + (cancel-timer org-src-font-lock-fontify-idle-timer)) )) +(org-src-font-lock-fontify-block-1 lang start end))) + +(defun org-src-font-lock-fontify-block-1 (lang start end) (let ((lang-mode (org-src-get-lang-mode lang))) (when (fboundp lang-mode) (let ((string (buffer-substring-no-properties start end)) -- 2.25.1
[PATCH 0/1] Add option to delay fontification of source blocks
From: Leo Okawa Ericson I tried sending this patch once before, but I think it got caught as spam so I'm trying this again. Fontification of long code blocks can be very slow. The patch (in the reply to this email) mitigates this by adding an option to delay the fontification after the user has become idle by using idle timers. This seems to be faster from my limited testing, but I'm not sure if something will go horribly wrong because of the timers. There is a trade-off in that there will be no syntax highlightinting when the user is typing. I don't know how to keep existing fontification so it would be great if somebody could share a solution to that. I have signed the copyright papers so that shouldn't be a problem. This is my first patch submission so any suggestions for improvement are welcome. Leo Okawa Ericson (1): org-src.el: Add option to delay fontification of source blocks lisp/org-src.el | 29 + 1 file changed, 29 insertions(+) -- 2.25.1
Re: org-plot/gnuplot: question and feature suggestions
On Thursday, 25 Mar 2021 at 20:31, Timothy wrote: > Eric S Fraga writes: > >> or some similar way but I cannot figure out how to do it. > > [ Update: He figured it out :P ] ;-) > If no-one else takes care of these, I'll take a look in a bit* :) Thank you! And no pressure, of course. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-254-g37749c
Re: org-plot/gnuplot: question and feature suggestions
Eric S Fraga writes: > or some similar way but I cannot figure out how to do it. [ Update: He figured it out :P ] > I also have two feature requests should anybody be able to help: > > 1. it would be consistent and useful if "C-c C-c" executed >org-plot/gnuplot when on such a #+PLOT line. > > 2. why does point move to the next line when I do execute the command? >This is somewhat annoying when playing around with the settings. It >would be nice to have point remain where it is. If no-one else takes care of these, I'll take a look in a bit* :) -- Timothy *a bit = several weeks
Re: org-plot/gnuplot: question and feature suggestions
On Thursday, 25 Mar 2021 at 11:58, Eric S Fraga wrote: > In a #+PLOT line, I would set this using > > #+PLOT: ... set:"format \"%T\"" Solved it. I had forgotten that gnuplot is quite relaxed about the quotes used so this works: #+PLOT: ... set:"format '%T'" My feature requests stand, mine you. :-) Thank you, eric -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-254-g37749c
org-plot/gnuplot: question and feature suggestions
Hello all, I normally use gnuplot directly with src blocks but sometimes it's useful to use the #+PLOT for some quick and dirty plots. I have one problem: I wish to set the format for axes labels to %T. Normally, in gnuplot, this would be simply a line format "%T" In a #+PLOT line, I would set this using #+PLOT: ... set:"format \"%T\"" or some similar way but I cannot figure out how to do it. I also have two feature requests should anybody be able to help: 1. it would be consistent and useful if "C-c C-c" executed org-plot/gnuplot when on such a #+PLOT line. 2. why does point move to the next line when I do execute the command? This is somewhat annoying when playing around with the settings. It would be nice to have point remain where it is. Thank you all! -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-254-g37749c
An interesting LaTeX package
Hi all, This is not directly related to Org-Mode (apologies for the light off-topic), but I thought this new LaTeX package uploaded to CTAN could be of interest to those who regularly export from Org to LaTeX and want to get a document as 'perfect' as possible, typographically speaking ;-) The Lua-typo package (according to its description): "tracks common typographic flaws in LuaLaTeX documents, especially widows, orphans, hyphenated words split over two pages, consecutive lines ending with hyphens, paragraphs ending on too short lines, etc." (https://ctan.org/pkg/lua-typo). This package can detect any of the following scenarios (taken from the package documentation): - paragraph’s last line nearly full? - paragraph’s last line too short? - nearly empty page (just a few lines)? - overfull lines? - underfull lines? - widows (top of page)? - orphans (bottom of page) - hyphenated word split across two pages? - too many consecutive hyphens? - paragraph’s last full line hyphenated? - short words (1 or 2 chars) at end of line? - same (part of) word starting two consecutive lines? - same (part of) word ending two consecutive lines? It should be noted that the package works only in LuaLaTeX, and that it highlights flaws only (in draft mode), but does not correct them. It's similar to another older package, Impnattypo (https://ctan.org/pkg/impnattypo). Best regards, Juan Manuel
Re: MacOS (emacsformacosx) c-spc, does not run set-mark-command
Uwe Brauer writes: "TC" == Tim Cross writes: > >> Diego Zamboni writes: > >>> I have seen differences in this behavior depending on the Emacs >>> build. The emacs-mac port >>> (https://github.com/railwaycat/homebrew-emacsmacport) >>> seems to intercept certain Mac-specific keybindings such as C-space >>> and C-M-space and gives them their "Mac meaning", e.g. to bring up >>> Spotlight or the >>> symbol chooser. I could never figure out how to disable this behavior. >>> >>> Now I use emacs-plus (https://github.com/d12frosted/homebrew-emacs-plus) >>> and this no longer happens. >>> > >> Normally, you need to disable those 'shortcuts' at the OS level i.e. >> under the keyboard shortucts item in macOS preferences panel. Problem is >> any macOS shortcut will grab the keys before Emacs sees them. Not sure >> how the emacs-plus version gets around this. > > Right, it seems and issue of the OS shortcuts as C-space is for > switching keyboards (US->spanish>etc etc).[1] > > Do you know how to change or disable them? > I'm not on a mac at present, but from memory it is under system preferences -> keyborad -> shortcuts.
Re: MacOS (emacsformacosx) c-spc, does not run set-mark-command
On Thu, 25 Mar 2021 at 08:28, Uwe Brauer wrote: > Right, it seems and issue of the OS shortcuts as C-space is for > switching keyboards (US->spanish>etc etc).[1] > > Do you know how to change or disable them? > > Uwe > > > > Footnotes: > [1] the same happens on Linux/KDE On macOS, these shortcuts can be changed in the Keyboard preference panel. --Diego > >
Re: MacOS (emacsformacosx) c-spc, does not run set-mark-command
>>> "TC" == Tim Cross writes: > Diego Zamboni writes: >> I have seen differences in this behavior depending on the Emacs >> build. The emacs-mac port >> (https://github.com/railwaycat/homebrew-emacsmacport) >> seems to intercept certain Mac-specific keybindings such as C-space >> and C-M-space and gives them their "Mac meaning", e.g. to bring up >> Spotlight or the >> symbol chooser. I could never figure out how to disable this behavior. >> >> Now I use emacs-plus (https://github.com/d12frosted/homebrew-emacs-plus) and >> this no longer happens. >> > Normally, you need to disable those 'shortcuts' at the OS level i.e. > under the keyboard shortucts item in macOS preferences panel. Problem is > any macOS shortcut will grab the keys before Emacs sees them. Not sure > how the emacs-plus version gets around this. Right, it seems and issue of the OS shortcuts as C-space is for switching keyboards (US->spanish>etc etc).[1] Do you know how to change or disable them? Uwe Footnotes: [1] the same happens on Linux/KDE smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] org.el (org-do-latex-and-related): Fix duplicate 'latex-and-related faces
Kyle Meyer writes: > Please add a period after the changelog entry. Done. > Any reason not to pass limit as re-search-forward's BOUND instead? I've looked at the history of this code, and some earlier comment indicated that limit was ignored on purpose. The only case where it'd make a difference with my patch is when limit is in the middle of a latex fragment (since re-search-forward's BOUND bounds the end of the match). Now, AFAIU, this should almost never happen, since the fontified region is extended + according to the font-lock-multiline text property, that latex fragment do have + and to contain matching begin/end delimiters. I can think of a few edge cases where it may make a difference : - If you write a multiline fragment, and add $ delimiters afterwards, starting with the closing one. Then when you add the opening one, you wouldn't get fontification, I think - If you add an empty line in a multiline $ fragment by mistake, which breaks fontification, then remove it -- Sébastien Miquel >From 7fb4e2d408791742281bf220d227ccdcfd5baa71 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= Date: Fri, 19 Mar 2021 16:55:27 +0100 Subject: [PATCH] org.el (org-do-latex-and-related): Fix duplicate 'latex faces * lisp/org.el (org-do-latex-and-related): Do not add a 'org-latex-and-related face beyond the fontification limit. --- lisp/org.el | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lisp/org.el b/lisp/org.el index 4db2dbe04..a0c703630 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -5502,6 +5502,8 @@ highlighting was done, nil otherwise." (while (and (< (point) limit) (re-search-forward org-latex-and-related-regexp nil t)) (cond + ((>= (match-beginning 0) limit) + (throw 'found nil)) ((cl-some (lambda (f) (memq f '(org-code org-verbatim underline org-special-keyword))) -- 2.31.0
