Re: [O] Inline code block syntax highlighting absence
Nicolas Goaziou writes:
> Hello,
>
> stardiviner writes:
>
>> I did a search of "font-lock-add-keywords", "begin_src", "src_" etc in
>> Org Mode source code, but have not found exact place where fontify
>> function are. So I don't know where to modify the source code. Now I put
>> my current config here:
>
> [...]
>
>> (font-lock-add-keywords
>> 'org-mode
>> '(("\\(src_\\)\\([^[{]+\\)\\(\\[:.*\\]\\)\\({\\)\\([^}]*\\)\\(}\\)"
>> (1 '(:foreground "black" :weight 'normal :height 0.1)) ; src_ part
>> (2 '(:foreground "cyan" :weight 'bold :height 0.8 :box '(:color "light
>> gray"))) ; "lang" part.
>> (3 '(:foreground "#55" :height 0.7)) ; [:header arguments] part.
>> (4 '(:foreground "#33")) ; {
>> (5 'org-code) ; "code..." part.
>> (6 '(:foreground "#33")) ; }
>> ))
>> 'append)
>
> The first thing is to define new faces, or re-use existing one, instead
> of creating them ad-hoc.
>
> Then you need to create a function like `org-fontify-entities'.
>
> For example:
>
> --8<---cut here---start->8---
> (defun org-fontify-inline-code (limit)
> (when (re-search-forward "src_..." limit t)
> ;; here you need to make as sure as possible that you are really
> ;; at some inline code. You cannot really parse inline source code
> ;; or inline Babel calls with a regexp only.
> (org-remove-flyspell-overlays-in beg end)
> (add-text-properties beg end (list 'font-lock-fontified t 'face ...))
> t))
> --8<---cut here---end--->8---
>
> You then register the function above in `org-set-font-lock-defaults.
>
> Do you want to implement this?
>
> Regards,
I will take a try. Maybe later in few days.
--
[ stardiviner ]
I try to make every word tell the meaning what I want to express.
Blog: https://stardiviner.github.io/
IRC(freenode): stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
Re: [O] coderef does not provide file path for org-insert-link when not in original buffre
Nicolas Goaziou writes:
> Hello,
>
> stardiviner writes:
>
>> Thanks for this hint, I added a new entry in org-src--babel-info list to
>> pass the original parent file path.
>
> Thank you. Some comments follow.
>
>> - (language body arguments switches name start coderef)"
>> + (language body arguments switches name start coderef parent-file-path)"
>
> This is not needed. It would be better to create a new variable, e.g.
> `org-src-source-file', get the file name at the beginning of the
> function `org-src--edit-element', and set it from its INITIALIZE
> argument.
>
>> + (insert (format coderef-format label))
>> + (setq link (format "file:%s::%s"
>> + (car (last org-src--babel-info))
>> + (concat "(" label ")")))
>
> You can get the file name by reading `org-src-source-file' value.
>
> Does that make sense?
>
> Could you also provide some tests?
>
> Regards,
I regenerated the patch.
>From da491e12fcbf75d9b016f58fbcdeb74d601a1b91 Mon Sep 17 00:00:00 2001
From: stardiviner
Date: Wed, 24 Oct 2018 10:45:40 +0800
Subject: [PATCH] org.el: fix org-coderef does not support adaptive file path
link type.
* org-src.el (org-src-source-file): Add a variable to get the file path
at the beginning of the function `org-src--edit-element'.
* org.el (org-insert-link): support option org-link-file-path-type
'adaptive value.
---
lisp/org-src.el | 9 -
lisp/org.el | 9 ++---
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/lisp/org-src.el b/lisp/org-src.el
index 42e1225ed..0426ff96a 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -277,6 +277,11 @@ issued in the language major mode buffer."
"Type of element being edited, as a symbol.")
(put 'org-src--source-type 'permanent-local t)
+(defvar org-src--source-file nil
+ "A variable used to store the source file path before entering
+ source block dedicated buffer.")
+(put 'org-src--source-file 'permanent-local t)
+
(defvar-local org-src--tab-width nil
"Contains `tab-width' value from Org source buffer.
However, if `indent-tabs-mode' is nil in that buffer, its value
@@ -995,7 +1000,9 @@ name of the sub-editing buffer."
(let* ((lang
(if (eq type 'src-block) (org-element-property :language element)
"example"))
- (lang-f (and (eq type 'src-block) (org-src--get-lang-mode lang)))
+ (lang-f (progn
+ (setq-local org-src--source-file (buffer-file-name))
+ (and (eq type 'src-block) (org-src--get-lang-mode lang
(babel-info (and (eq type 'src-block)
(org-babel-get-src-block-info 'light)))
deactivate-mark)
diff --git a/lisp/org.el b/lisp/org.el
index 0b5e8d739..ab86345bf 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -9249,13 +9249,14 @@ non-nil."
(interactive?
(let ((label (read-string "Code line label: ")))
(end-of-line)
- (setq link (format coderef-format label))
(let ((gc (- 79 (length link
(if (< (current-column) gc)
(org-move-to-column gc t)
(insert " ")))
- (insert link)
- (setq link (concat "(" label ")"))
+ (insert (format coderef-format label))
+ (setq link (format "file:%s::%s"
+ org-src--source-file
+ (concat "(" label ")")))
(setq desc nil)))
(t (setq link nil)
@@ -9852,6 +9853,8 @@ Use TAB to complete link prefixes, then RET for type-specific completion support
(setq path (expand-file-name path)))
((eq org-link-file-path-type 'relative)
(setq path (file-relative-name path)))
+ ((eq org-link-file-path-type 'adaptive)
+ (setq path (file-relative-name path)))
(t
(save-match-data
(if (string-match (concat "^" (regexp-quote
--
2.19.1
--
[ stardiviner ]
I try to make every word tell the meaning what I want to express.
Blog: https://stardiviner.github.io/
IRC(freenode): stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
Re: [O] org-store/insert-link truncating the full subject of mails
Nicolas Goaziou writes: > I think limiting the number of characters in the description is to be on > the safe side. 30 characters are usually enough to understand what the > mail is about. Can you please elaborate on what you mean by being on the safe side in this context? What problems could potentially arise from returning the subject in full length? > In any case, if other users feel strongly about changing the default > value, I don't mind. I hope you understand that one data point is not > enough, tho. Considering my above question and me not knowing why/where this limit comes from, if there’s a legitimate reason to truncate the subject then so be it. But if not, I’d probably be in favour of changing the default to lift the limit. Or at the very least mentioning `org-email-link-description-format' in the docstring for `org-store-link' and potentially other functions affected by the setting. just my 2¢. -amin
Re: [O] electric-pair, autopair, smartparens, etc in org-mode
Samuel Wales writes: > can either of you give examples of code or settings that you had that > made behavior of new modes unpredictable because emacs started > supporting the behavior you made the code or settings for? > It is difficult to remember now as it was some time ago that I cleaned up my init and got rid of much of my old stuff. Areas I do remember include - Key bindings. This is probably the most common. You would enable a new Emacs feature only to find you had conflicts with key bindings. In the best case, some new features couldn't be easily accessed. In the worst case, a new feature would create unexpected behaviour. The hard part was often in deciding whether to try and change the bindings or change my finger memory. - Hooks. This was probably the second most common problem. A new feature would add to a hook where I had a similar feature also on that hook. As a result, both would run and result in unexpected outcomes. - Convenience functions for selecting files, buffers and windows, working with sets of files (i.e. projects), My setup predated ido, and packages like yasnippets, projectile and company mode which I now use. In many cases, my own tweaks were OK, but not as robust or feature rich as standard packages that were added to Emacs over releases which provided similar functionality. - As my init had grown in a rather 'organic' manner - bits added as I needed them, there was a lack of consistency or structure to my configuration. As a result, often when I tried a new feature, there would be parts of my init I would forget to remove/disable that would conflict with that feature. As I used autoloads quite a bit, things would also be a little inconsistent as conflicts could be dependent on the order things got loaded and that order could be affected by what I did in a specific session. - One area I do remember was with respect to handling of PDF, HTML and other document types. I had a lot of config which would automatically convert many of these types to plain text to make them easy to work with inside emacs. As modes like doc-view, eww etc were added. I recall at times, conflicts would occur. I remember at one point, what behaviour I would experience when opening a PDF would depend on what mode had been loaded. If doc-view was already loaded, I would see the PDF rendered using doc-view - if my code was already loaded, I would see a plain text version. Often, the result would not be the one I wanted. I now no longer have all that code in my init and leave such things to Emacs. In my case, much of my elisp config was pretty rough - I did as little as necessary to get the behaviour I wanted. It was often poorly tested, lacked sufficient error checking, was inconsistent and overall rough - it did the job. However, this did mean it often did not play well with others. For ages, I simply didn't bother looking at new features and modes unless I came across a new requirement e.g. learning a new programming language, working with a new system etc. My init also had large amounts of code borrowed with pride (aka stolen) from newsgroup postings, web sites, mail lists and various elisp repositories. As I tend not to bother compiling my init, you would not necessary be aware of obsolete and deprecated functions used by this code. The lack of any namespace for packages also meant name conflicts were sometimes the cause of weird bugs etc. Overall, things were 'fragile' and you would avoid making changes as much as possible. I was frequently surprised when I decided it was time to cleanup my init at various improvements and enhancements that had been added to Emacs. This is partially a result of the conservative approach Emacs tends to adopt - a good approach as it means you can usually upgrade to a new version and not end up spending hours fixing things just to get back to work. However, the downside is that it also means you may not even be aware of or benefit from some improvements. The positive is that now I have a nicely structured and documented org file with my init and making changes is easy. Actually, I have multiple configs - a standard working config, a 'new features' config where I try out new packages etc, a very simple minimal config I use for testing/debugging problems etc. I have a simple shell script which I can run and pass it an org file name which will generate a new init.el and I keep it all in git. At this time, I'm probably happier with my Emacs setup than during any period in the last 25 years. Tim Tim Cross
[O] Bug? Group tags not working properly with agenda searches
Hello,
First of all, thank you for org-mode. Without it, I literally would find
it much more difficult to do my job.
I am having a problem with group tags. I reproduced it using the latest
org-mode from the org package archive, 20181022. The minimal example is
this: say I have a group tag that looks like this:
(setq org-tag-alist
'((:startgrouptag)
("parentTag")
(:grouptags)
("childTag1")
("childTag2")
(:endgrouptag)))
with a org-todo-keywords like so:
(setq org-todo-keywords '((type "TODO" "NEXT" "|" "DONE" "CANCELLED")))
And then an org file that looks like this:
* Parent heading 1 :childTag1:
** NEXT child 1 of parent 1
** TODO child 2 of parent 1
* Parent heading 2
** NEXT child 1 of parent 2
** TODO child 2 of parent 2
Then when I hit C-c a M, I use this match string:
parentTag="NEXT"|-parentTag="TODO"
I would expect the resulting agenda to have exactly two items: "child 1 of
parent 1", and "child 2 of parent 2". However, I get three items: "child 1
of parent 1", "child 2 of parent 1", and "child 2 of parent 2". I don't
understand why "child 2 of parent 1" is in there.
This only arises when using the "|" operator. That is, if I do an agenda
with just
parentTag="NEXT"
then I get just "child 1 of parent 1", as expected. If I do an agenda with
-parentTag="TODO"
then I get just "child 2 of parent 2", as expected. But when I combine
them with "|", I get three items.
I also did some other tests showing that at least for me this problem
arises only with group tags. In particular, here if I do
childTag1="NEXT"|-childTag1="TODO"
I get just the two items I would expect.
Is there a bug here? Or am I doing something wrong? Thanks. --Omari
Re: [O] *markup*, /markup/ and _markup_ true semantics [Was: Re: Ox-html: Replace with and with ]
Garreau, Alexandre writes: > Sorry, just found out that interesting (to me) thread I shouldn’t have > let go: > > On 2018-10-25 at 08:00, Tim Cross wrote: >> Kaushal Modi writes: >>> […] >>> - b and i are not deprecated >>> - b and strong are both valid but their use depends on the writer's >>> context (but Org mode has just one mark for either "*") >>> - i and em are both valid but their use depends on the writer's >>> context (but Org mode has just one mark for either "/"). >>> >>> […] >>> >>> From "em" docs[em], in the NOTE section there: The em element isn’t a generic "italics" element. Sometimes, text is intended to stand out from the rest of the paragraph, as if it was in a different mood or voice. For this, the i element is more appropriate. >>> >>> […] >>> >>> I guess there's no need to change what "*" and "/" do right now in >>> ox-html, as there doesn't seem "one right way" to do things here. >>> >>> And folks strongly wanting to use and for bold and >>> italic can customize org-html-text-markup-alist. >>> >>> HTML experts, please chime in. >> >> I'll start by stating I'm definitely not an HTML expert. > > I don’t exactely know what an expert is, at least I’m not a > professional, but I have passed some time figuring out various HTML > specs semantic meaning. > > More especially, I’ve a big interest in semantics and typography, and > past many time on my now deleted-crecreated-then-lost github account, > and mail, to convince people to switch to more semantical markuping (oh, > and to use complex CSS selectors rather than classes, and stop using > and at all) and better typography (such as curly quotes, > simple quotes inside quotes, and many things specific to french). > >> The problem with b and i is that they specify how rather than what and >> don't always make sense for all possible media types. For example, what >> does 'bold' or 'italic' mean for a screen reader? > > Italic means often pronounced with a different pitch afair. Bold > probably means prounced differently too but I don’t know how this is > pronounced iirc. I need to recheck with orca and firefox addons (I’ll > do for a next mail). That might be change accross screenreaders so I > might have to find some friend having a windows computer with NVDA, JAWS > or some other non-free program to either ask or check. > > I believe the most correct handling for screen readers would be to use > the appropriate language from the attribute lang or xml:lang of tag, > otherwise slower and slightly higher pitch, and for the exact same > higher pitch as caps, without changing speed, plus adding it to an > easily reachable “keyword-list”, just as . > > Fyi: both italic, bold, and underline, have been invented in typography > as special ways of *purposely* making text harder to read. Both the > intent and result is that the reader taking more time to read something > in italic, for instance, will memorize it better, and have more free > time to think about it, hence increasing the importance of this > something. > > In the following “from far” means when you look at the global document > and are not focusing reading a particular part of it. It doesn’t mean > you are at a far distance and you can still read it, like it is for > uppercase. > > Italic is the best way, the most readable, as it’s only seen when > reading, near the text, but not “from far” and doesn’t break structure, > flowing, or “typographic grey” (“gris typographique”, I’m not aware of > the english term). It is hence commonly used for emphasis (best usage: > if ever it gets long, it gets hard to read, but that reflects the fact > original meaning was hard to grasp or hear or say originally), citation > of artistical work names (such as books: conventional usage, but still > okay, as these are mostly short anyway), and quotations (discouraged > usage as they can get long (and thus unreadable) and quote marks cover > this, *not* to be used *along* with them, never, as it is terribly > redundant and almost no serious professional printer do that). > > Bold is sometimes harder to read, and sometimes, if not too bold, > easier, however it’s really easy to “notice” its text from looking afar: > therefore it’s normally *exclusively* recommanded for text structures, > whose *role* is to purposely cut in parts the text, that is: *outlines*. > However, in an attempt of pseudo-backward compatibility and “but look > everybody was okay since the beginning”, by the W3C, another usage for > bold than in outlines has been found: keywords. These are *meant* to be > seen from far, are usually small (one word), and yet wouldn’t alter text > structure, and might not be candidate for (however most time they > should). > > Underline is to be banned from everywhere, theorically. It is an > especially simple and awful way of making text unreadable: it cuts the > legs of non-zero-ascent letters (making as hard to read as italic) *and* > is easy to lookup from far,
Re: [O] org-store/insert-link truncating the full subject of mails
"Garreau, Alexandre" writes: > How’s that? I think limiting the number of characters in the description is to be on the safe side. 30 characters are usually enough to understand what the mail is about. > it just feels wrong: if it’s to long, users can truncate themselves, > it’s straightforward, but finding again and adding the end, or finding > the appropriate customization, isn’t. > Also what’s the utility of it? See above. In any case, if other users feel strongly about changing the default value, I don't mind. I hope you understand that one data point is not enough, tho. Regards,
Re: [O] coderef does not provide file path for org-insert-link when not in original buffre
Hello,
stardiviner writes:
> Thanks for this hint, I added a new entry in org-src--babel-info list to
> pass the original parent file path.
Thank you. Some comments follow.
> - (language body arguments switches name start coderef)"
> + (language body arguments switches name start coderef parent-file-path)"
This is not needed. It would be better to create a new variable, e.g.
`org-src-source-file', get the file name at the beginning of the
function `org-src--edit-element', and set it from its INITIALIZE
argument.
> +(insert (format coderef-format label))
> +(setq link (format "file:%s::%s"
> + (car (last org-src--babel-info))
> + (concat "(" label ")")))
You can get the file name by reading `org-src-source-file' value.
Does that make sense?
Could you also provide some tests?
Regards,
--
Nicolas Goaziou
Re: [O] Inline code block syntax highlighting absence
Hello,
stardiviner writes:
> I did a search of "font-lock-add-keywords", "begin_src", "src_" etc in
> Org Mode source code, but have not found exact place where fontify
> function are. So I don't know where to modify the source code. Now I put
> my current config here:
[...]
> (font-lock-add-keywords
> 'org-mode
> '(("\\(src_\\)\\([^[{]+\\)\\(\\[:.*\\]\\)\\({\\)\\([^}]*\\)\\(}\\)"
> (1 '(:foreground "black" :weight 'normal :height 0.1)) ; src_ part
> (2 '(:foreground "cyan" :weight 'bold :height 0.8 :box '(:color "light
> gray"))) ; "lang" part.
> (3 '(:foreground "#55" :height 0.7)) ; [:header arguments] part.
> (4 '(:foreground "#33")) ; {
> (5 'org-code) ; "code..." part.
> (6 '(:foreground "#33")) ; }
> ))
> 'append)
The first thing is to define new faces, or re-use existing one, instead
of creating them ad-hoc.
Then you need to create a function like `org-fontify-entities'.
For example:
--8<---cut here---start->8---
(defun org-fontify-inline-code (limit)
(when (re-search-forward "src_..." limit t)
;; here you need to make as sure as possible that you are really
;; at some inline code. You cannot really parse inline source code
;; or inline Babel calls with a regexp only.
(org-remove-flyspell-overlays-in beg end)
(add-text-properties beg end (list 'font-lock-fontified t 'face ...))
t))
--8<---cut here---end--->8---
You then register the function above in `org-set-font-lock-defaults.
Do you want to implement this?
Regards,
--
Nicolas Goaziou
Re: [O] org-store/insert-link truncating the full subject of mails
Hello, "Garreau, Alexandre" writes: > Why so? See `org-email-link-description-format'. > It shouldn’t be this way by default. Truncating subject doesn't seem unreasonable to me. In any case, you can just set the variable above to suit your needs. Regards, -- Nicolas Goaziou
Re: [O] org-store/insert-link truncating the full subject of mails
Le 26/10/2018 à 17h35, Nicolas Goaziou a écrit : > "Garreau, Alexandre" writes: >> Why so? > > See `org-email-link-description-format'. Thank you! >> It shouldn’t be this way by default. > > Truncating subject doesn't seem unreasonable to me. In any case, you can > just set the variable above to suit your needs. How’s that? it just feels wrong: if it’s to long, users can truncate themselves, it’s straightforward, but finding again and adding the end, or finding the appropriate customization, isn’t. Also what’s the utility of it?
[O] agenda view help - viewing all time entries for a tag
Say I have a calendar file which is in the following format: * description of deadline:client1: DEADLINE: <2018-10-28 Tue> * a meeting :client1: <2018-11-1 Thu 10:00> I would like to be able to view all headlines and time entries associated with a particular tag, and to have that information visible in an agenda buffer, and for the entries to appear in chronological order along with the associated dates If I do C-c a m [tag], the dates do not appear Seems the best I can do to get dates associated with the headline and appear in chronological order is C-c a a, then filter by tag, then M-x org-agenda-year-view. This is ugly and slow. Say I filter for :client1: and put into year view, it looks something like: Tuesday 30 October 2018 Deadline: description of deadline :client1: Wednesday 31 October 2018 *[unnecessary date with no entry -- why is this here?]* Thursday 1 November 2018 10:00... a meeting :client1: Is there something obvious I am missing? I just want something like the above command, but without all of the dates shown that fall between time entries. This way I can get a view of all deadlines associated with a client, where those deadlines may exist months or even a year+ in advance (i.e., I don't want to be limited to a year view). Hope this makes sense. I am an orgmode newb. Was very excited at first but the learning curve is really starting to hit me lately. It seems like this should be relatively easy to accomplish.
Re: [O] org--string-from-props
Hello, Colin Baxter writes: > I think there may be an issue with commit > b886ebbc8924916c1e36df00639b3208a1c155a2. Using tables, I now get an error: > > org--string-from-props: Un-handled `display' value: (space :width 1) > > which goes away when I revert the commit. Oops. Fixed. Thank you. Regards, -- Nicolas Goaziou
Re: [O] C-c C-c in src block interpret line as table
On 2018/10/26 at 10:29, Eric S Fraga wrote: > On Friday, 26 Oct 2018 at 08:45, Garreau, Alexandre wrote: >> I tried to eval the following block, and my point was on the last line, >> of course, but since it begins with a “|”, it was interpreted as a >> table, and block was not evaled: I believe this is a bug. Why would a >> org table be inside a non-org source block? it’s not even inside a >> comment! >> >> #+BEGIN_SRC ocaml :results verbatim >> let rec premiers = >> function [] -> [] >>| (a,b) :: q -> a :: premiers q ;; | >> #+END_SRC > > This may be a bug but how were you editing this code? From org mode or > by editing the src block using C-c ' (org-edit-special)? Code blocks > should generally be edited using the special edit mode which knows about > the language. I was doing from org-mode: I find want to see rest of the buffer while writing (that’s why I’m using org-mode instead of just writing in a plain file), and to have to type that keystrokes, again and again. And anyway there’s org-src-tab-acts-natively for that (though it’s often unperfect but I’m not complaining until I had the time to figure out why).
Re: [O] C-c C-c in src block interpret line as table
On 2018/10/26 at 11:34, Nicolas Goaziou wrote: > "Garreau, Alexandre" writes: > >> I tried to eval the following block, and my point was on the last line, >> of course, but since it begins with a “|”, it was interpreted as a >> table, and block was not evaled: I believe this is a bug. Why would a >> org table be inside a non-org source block? it’s not even inside a >> comment! >> >> #+BEGIN_SRC ocaml :results verbatim >> let rec premiers = >> function [] -> [] >>| (a,b) :: q -> a :: premiers q ;; | >> #+END_SRC >> >> Note the remaining “|” at the end of the last line was added by org, not >> me, not part of source code. > > I cannot reproduce it. Never mind! orgtbl-mode was activated in org-mode, since org-mode is based on text-mode and I was wanting it for all text-mode-based modes. It seems to, in fact, not to very be integrated with org-mode, otherwise it should have behaved like normal org tables (that is, not inside source blocks). Sorry for wasted time ^^'
Re: [O] C-c C-c in src block interpret line as table
Hello, "Garreau, Alexandre" writes: > I tried to eval the following block, and my point was on the last line, > of course, but since it begins with a “|”, it was interpreted as a > table, and block was not evaled: I believe this is a bug. Why would a > org table be inside a non-org source block? it’s not even inside a > comment! > > #+BEGIN_SRC ocaml :results verbatim > let rec premiers = > function [] -> [] >| (a,b) :: q -> a :: premiers q ;; | > #+END_SRC > > Note the remaining “|” at the end of the last line was added by org, not > me, not part of source code. I cannot reproduce it. Regards, -- Nicolas Goaziou
Re: [O] C-c C-c in src block interpret line as table
On Friday, 26 Oct 2018 at 08:45, Garreau, Alexandre wrote: > I tried to eval the following block, and my point was on the last line, > of course, but since it begins with a “|”, it was interpreted as a > table, and block was not evaled: I believe this is a bug. Why would a > org table be inside a non-org source block? it’s not even inside a > comment! > > #+BEGIN_SRC ocaml :results verbatim > let rec premiers = > function [] -> [] >| (a,b) :: q -> a :: premiers q ;; | > #+END_SRC This may be a bug but how were you editing this code? From org mode or by editing the src block using C-c ' (org-edit-special)? Code blocks should generally be edited using the special edit mode which knows about the language. -- Eric S Fraga via Emacs 27.0.50, Org release_9.1.11-620-ga548e4
Re: [O] electric-pair, autopair, smartparens, etc in org-mode
On Thursday, 25 Oct 2018 at 15:57, Samuel Wales wrote: > can either of you give examples of code or settings that you had that > made behavior of new modes unpredictable because emacs started > supporting the behavior you made the code or settings for? In my case, mostly incompatible bindings of keys, e.g. the tab key, especially in the context of auto-completion mechanisms and auto-expansion (e.g. yasnippet). It's not so much unpredictable behaviour as wrong behaviour due to settings stepping on the toes of subsequently installed packages. -- Eric S Fraga via Emacs 27.0.50, Org release_9.1.11-620-ga548e4
[O] org--string-from-props
I think there may be an issue with commit b886ebbc8924916c1e36df00639b3208a1c155a2. Using tables, I now get an error: org--string-from-props: Un-handled `display' value: (space :width 1) which goes away when I revert the commit. Best wishes,
[O] C-c C-c in src block interpret line as table
I tried to eval the following block, and my point was on the last line, of course, but since it begins with a “|”, it was interpreted as a table, and block was not evaled: I believe this is a bug. Why would a org table be inside a non-org source block? it’s not even inside a comment! #+BEGIN_SRC ocaml :results verbatim let rec premiers = function [] -> [] | (a,b) :: q -> a :: premiers q ;; | #+END_SRC Note the remaining “|” at the end of the last line was added by org, not me, not part of source code.
