[PATCH] ox-latex: Replace \verb instances in headings with \texttt
Hello again,
This time with a smaller patch that works around LaTeX peculiarities.
When LaTeX encounters \verb inside another command it's expanding, it
can panic and compilation fails.
This occurs inside \section commands, and so it's worth modifying the
default header format function to convert any instances of \verb to
\texttt, as that can actually compile successfully.
See https://www.texfaq.org/FAQ-verbwithin for more info.
--
Timothy
>From b15af4ac23fabe501121e0fd45de603367cb12ed Mon Sep 17 00:00:00 2001
From: TEC
Date: Wed, 31 Mar 2021 23:06:14 +0800
Subject: [PATCH] ox-latex: convert verbatim text in headings to tt
* lisp/ox-latex.el (org-latex-format-headline-default-function): Convert
any instances of \verb text with \texttt. This is required to work
around LaTeX peculiarities that would otherwise cause compilation to
fail (see the code comment for more information).
---
lisp/ox-latex.el | 12
1 file changed, 12 insertions(+)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index da3c3f815..8a2787a62 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -2055,6 +2055,18 @@ (defun org-latex-format-headline-default-function
(and todo (format "{\\bfseries\\sffamily %s} " todo))
(and priority (format "\\framebox{\\#%c} " priority))
text
+ ;; LaTeX isn't happy when you try to use \verb inside the argument of other
+ ;; commands (like \section, etc.), and this causes compilation to fail.
+ ;; So, within headings it's a good idea to replace any instances of \verb
+ ;; with \texttt.
+ (replace-regexp-in-string
+"verb\\(.\\).+?\\1"
+(lambda (verb-string)
+ (replace-regexp-in-string
+ "" ""
+ (org-latex--text-markup (substring verb-string 6 -1)
+ 'code
+ '(:latex-text-markup-alist ((code . protectedtexttt)))
(and tags
(format "\\hfill{}\\textsc{%s}"
(mapconcat #'org-latex--protect-text tags ":")
--
2.30.1
Re: [PATCH] ox-latex: Replace \verb instances in headings with \texttt
... and somehow I forgot to remove the old `text' :facepalm:
Third time's the charm.
>From ee6ec00145c442804d945bae292c199689f626ed Mon Sep 17 00:00:00 2001
From: TEC
Date: Wed, 31 Mar 2021 23:06:14 +0800
Subject: [PATCH] ox-latex: convert verbatim text in headings to tt
* lisp/ox-latex.el (org-latex-format-headline-default-function): Convert
any instances of \verb text with \texttt. This is required to work
around LaTeX peculiarities that would otherwise cause compilation to
fail (see the code comment for more information).
---
lisp/ox-latex.el | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index da3c3f815..13de07728 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -2054,7 +2054,19 @@ (defun org-latex-format-headline-default-function
(concat
(and todo (format "{\\bfseries\\sffamily %s} " todo))
(and priority (format "\\framebox{\\#%c} " priority))
- text
+ ;; LaTeX isn't happy when you try to use \verb inside the argument of other
+ ;; commands (like \section, etc.), and this causes compilation to fail.
+ ;; So, within headings it's a good idea to replace any instances of \verb
+ ;; with \texttt.
+ (replace-regexp-in-string
+"verb\\(.\\).+?\\1"
+(lambda (verb-string)
+ (replace-regexp-in-string
+ "" ""
+ (org-latex--text-markup (substring verb-string 6 -1)
+ 'code
+ '(:latex-text-markup-alist ((code . protectedtexttt))
+text)
(and tags
(format "\\hfill{}\\textsc{%s}"
(mapconcat #'org-latex--protect-text tags ":")
--
2.30.1
Adding Quick Notes in Org-mode Agenda View Inserts then In Drawer in Reverse Order
Hello. I use org-agenda frequently for getting an overview of my work. I clock-in when I start working on something. I often find myself needing to add a note to the task I am working on. To do that from the Agenda view, I run org-agenda-add-note. I add typical notes like what my findings are, anything I did related to the task, but it is nothing related to notes about why the task changed status (at least not always). However, I do have in my config (setq org-log-into-drawer t) which should add clocking into my LOGBOOK drawer by default. I discovered however that org-mode adds my notes in the LOGBOOK drawer. I am not sure why, but it appears that these notes are considered "status notes" (?) and thus by org-log-into-drawer documentation are logged into the drawer. I am not certain if this is correct. This setup, works fine except for two cases: a. When I want to export my notes to HTML, exporters will ignore the LOGBOOK, and I would like to export my notes. b. Notes are ordered in reverse: newer notes are put first. Because of this behavior, I suspect that I am hijacking the notion of "status change notes" and using them as notes. My questions are: 1. Am I using the notes correctly in org? 2. If not, what is equivalence of adding quick notes into a task (ideally, with time stamp of sort)? 3. If yes, then how can I work around the limitations (a) and (b)? -- Husain Alshehhi
Re: [PATCH] ox-latex: Replace \verb instances in headings with \texttt
Ooops, I spotted a minor in my patch.
Try this instead.
>From 1065e1ee71c1f169ca419f5cbfc94409088c44e6 Mon Sep 17 00:00:00 2001
From: TEC
Date: Wed, 31 Mar 2021 23:06:14 +0800
Subject: [PATCH] ox-latex: convert verbatim text in headings to tt
* lisp/ox-latex.el (org-latex-format-headline-default-function): Convert
any instances of \verb text with \texttt. This is required to work
around LaTeX peculiarities that would otherwise cause compilation to
fail (see the code comment for more information).
---
lisp/ox-latex.el | 13 +
1 file changed, 13 insertions(+)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index da3c3f815..c00667f34 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -2055,6 +2055,19 @@ (defun org-latex-format-headline-default-function
(and todo (format "{\\bfseries\\sffamily %s} " todo))
(and priority (format "\\framebox{\\#%c} " priority))
text
+ ;; LaTeX isn't happy when you try to use \verb inside the argument of other
+ ;; commands (like \section, etc.), and this causes compilation to fail.
+ ;; So, within headings it's a good idea to replace any instances of \verb
+ ;; with \texttt.
+ (replace-regexp-in-string
+"verb\\(.\\).+?\\1"
+(lambda (verb-string)
+ (replace-regexp-in-string
+ "" ""
+ (org-latex--text-markup (substring verb-string 6 -1)
+ 'code
+ '(:latex-text-markup-alist ((code . protectedtexttt))
+text)
(and tags
(format "\\hfill{}\\textsc{%s}"
(mapconcat #'org-latex--protect-text tags ":")
--
2.30.1
Idea for handling timezones
Hi everyone, I, like many others on this list, have to move between timezones quite frequently. As I gathered from the archive, it seems the main complexity in supporting timezones is the difficulty revolving the change of timestamp format. So I have an idea, suppose we add a new keyword, "TIMEZONE" that can be set at the start of the file like so #+TIMEZONE: America/Toronto This specifies the timezone of all timestamps in the file. Together with it, there can be a function called e.g. org-shift-time, that shifts all the timestamp in the file to another specified timezone and updates the keyword. Of course, care needs to be taken when dealing with dates without time, e.g. it should be treated as at time 00:00 when it is alone or as the start of a time range, and be treated as at time 24:00 when it is the end of a time range. Then there could be hooks that offer to run the function automatically when it detects the user's system or emacs is set to a different timezone as in the file (e.g. when they open the file, or opens the agenda). This will make sure the timestamps always aligns with their current one (if they wish). This change would be backwards compatible, and it should do the job well enough. Regards, shironeko
Idea for handling timezones
Hi everyone, I, like many others on this list, have to move between timezones quite frequently. As I gathered from the archive, it seems the main complexity in supporting timezones is the difficulty revolving the change of timestamp format. So I have an idea, suppose we add a new keyword, "TIMEZONE" that can be set at the start of the file like so #+TIMEZONE: America/Toronto This specifies the timezone of all timestamps in the file. Together with it, there can be a function called e.g. org-shift-time, that shifts all the timestamp in the file to another specified timezone and updates the keyword. Of course, care needs to be taken when dealing with dates without time, e.g. it should be treated as at time 00:00 when it is alone or as the start of a time range, and be treated as at time 24:00 when it is the end of a time range. Then there could be hooks that offer to run the function automatically when it detects the user's system or emacs is set to a different timezone as in the file (e.g. when they open the file, or opens the agenda). This will make sure the timestamps always aligns with their current one (if they wish). This change would be backwards compatible, and it should do the job well enough. Regards, shironeko
Re: Idea for handling timezones
On Thu, Apr 01, 2021 at 07:40:47AM +, shironeko wrote: > Hi everyone, > > I, like many others on this list, have to move between timezones quite > frequently. As I gathered from the archive, it seems the main complexity in > supporting timezones is the difficulty revolving the change of timestamp > format. > So I have an idea, suppose we add a new keyword, "TIMEZONE" that can be set at > the start of the file like so > > #+TIMEZONE: America/Toronto > > This specifies the timezone of all timestamps in the file [...] Hm. Just a mumbling from the peanut gallery: isn't the timezone a property of the timestamp itself? Specifying the timezone for the whole file is progress, but imagine the following scenario: I have a big file which is more or less a diary of things which happened, with lots of timestamps thrown in (also LOGBOOK entries). If I move through timezones, only some of the timestamps are "elsewhere". Switching "the whole file" to reflect the "current" timezone feels somehow wrong to me (which timezone a specific timestamp "happened" in has also some documentary value, after all). To keep things unambiguous, more than just the timezone must be kept. The current time offset is necessary to actually reconstruct the time (DST and such things). Of course, convincing Org to extend the timestamp format and regexps might be a tough call :-) Cheers - t signature.asc Description: Digital signature
Re: [PATCH 0/1] Add option to delay fontification of source blocks
Kyle Meyer writes: > Have you explored whether jit-lock (e.g., jit-lock-defer-time) helps for > your use case? No I didn't know about it. I have tried it now and it seems to solve the same problem as my patch. > If we do go this route, I think the case needs to be made why this > spot is special, and why we don't expect or would reject follow-up > patches for this and that other area. > I can't think of a reason either (now that I know that jit-lock exists) so I will retract my patch.
Re: Font lock in org+elisp confused with ?\[
This is related to the issues with <> in src blocks. [ and ] have open and close syntactical meanings like < and > do in org files. A similar solution as found in https://emacs.stackexchange.com/questions/50216/org-mode-code-block-parentheses-mismatch seems to work to fix it. John --- Professor John Kitchin (he/him/his) Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu On Fri, Apr 2, 2021 at 12:24 AM Tim Cross wrote: > I'm forwarding this to the emacs-orgmode list as this is something org > maintainers probably need to see. > > On Thu, 1 Apr 2021 at 15:43, Arthur Miller wrote: > >> >> Is it me or is it a bug? >> >> When in org mode in an elisp block, this seems to confuse syntax >> checker: >> >> #+begin_src emacs-lisp >> (progn >> (if (= (following-char) ?\]) >> (forward-char -1)) >> ) >> #+end_src >> >> Identation seems to think it is one level extra, and it also shows as >> error. Same of course when testing for ?\[. >> >> It does evaluate correctly. Ordinary elisp buffer does not have problem >> with this, only when in code blocks in org-mode or elisp mode.I can send >> in some screenshot with errors if needed. >> >> >> > > -- > regards, > > Tim > > -- > Tim Cross > >
Re: How to have a repeating item within some hours?
Ping? On 2021-03-28, at 11:52, Marcin Borkowski wrote: > Hi Orgers, > > I'd like to have a repeating time block on the agenda, say every Monday > from 5:15 to 6:15. I tried this: > > ** <2021-03-29 Mon 05:15 +7d>--<2021-03-29 Mon 06:15 +7d> Time block > > but it didn't show on the agenda, and this: > > ** Time block > SCHEDULED: <2021-03-29 Mon 05:15 +7d>--<2021-03-29 Mon 06:15 +7d> > > but it didn't show the end time. > > Any hints? -- Marcin Borkowski http://mbork.pl
Re: About exporting
Looks interesting indeed. You're using many more LaTeX features than I ever do and I can see how your configuration would be useful in those cases. More examples will help in understanding when it will be useful. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-254-g37749c
Re: Bug: Error while exporting o TexInfo. Html export works fine. [9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)]
Hello, Ramesh Nedunchezian writes: > FWIW, TexInfo manual has a bunch of gotchas here: > > (info "(texinfo) Node Line Requirements") > > > https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Node-Line-Requirements.html > > The following are the lines that seem relevant to the problem at hand. No, this is a different issue. We're talking about the first part of a menu entry, which doesn't have the same limitations as a node name. Those limitations are not explicit in the Texinfo manual, AFAICT. Regards, -- Nicolas Goaziou
Re: Bug: Error while exporting o TexInfo. Html export works fine. [9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)]
Ramesh Nedunchezian writes: > While in the lint buffer, I was expecting that M-g M-n, M-g M-p would > take me to the relevant source lines. Unfortunately, this isn't the > case. And the linter report is derived from > `org-lint--report-mode-map' which is derived from > `tabulated-list-mode'. The departure from convention surprised me. I don't know what convention you're talking about and I don't understand why that would be unfortunate. I think RET will take you to the relevant source lines whereas TAB and C-j will display them. See manual, or minor mode docstring, for details. > And the following snippet works fine i.e., The linter finds any > issue with an "unknown" language but complaints if the "unknown" > language happens to be empty. > > #+begin_src z >make packages/ > #+end_src > > I wonder why an unknown langauge would be acceptable for export and > not a "empty" language. > Isn't source blocks with no language equivalent to example blocks. I don't think such assumption is written anywhere. If that was the case, we wouldn't need example blocks, would we? A source block without a source language is just a meaningless construct. Forcing a meaning here would just be a sad hack, IMO. Regards,
Re: [PATCH] ox-latex: Replace \verb instances in headings with \texttt
Hello, Timothy writes: > * lisp/ox-latex.el (org-latex-format-headline-default-function): Convert > any instances of \verb text with \texttt. This is required to work > around LaTeX peculiarities that would otherwise cause compilation to > fail (see the code comment for more information). This is not the appropriate location for the fix. In `section-back-end' variable within `org-latex-headline', you can extend the local export back-end to handle correctly verbatim markup. Regards, -- Nicolas Goaziou
Re: [PATCH] ox-latex: Replace \verb instances in headings with \texttt
Nicolas Goaziou writes:
> Hello,
>
> Timothy writes:
>
>> * lisp/ox-latex.el (org-latex-format-headline-default-function): Convert
>> any instances of \verb text with \texttt. This is required to work
>> around LaTeX peculiarities that would otherwise cause compilation to
>> fail (see the code comment for more information).
>
> This is not the appropriate location for the fix.
>
> In `section-back-end' variable within `org-latex-headline', you can
> extend the local export back-end to handle correctly verbatim markup.
>
> Regards,
I've just had a look; I don't feel that confident with my usage after
checking the docstring for `org-export-create-backend'. Would you mind
giving the below a quick look and letting me know if it looks right to
you?
#+begin_src diff
@@ -1960 +1960,3 @@ (defun org-latex-headline (headline contents info)
-'((underline . (lambda (o c i) (format "\\underline{%s}" c))
+'((underline . (lambda (o c i) (format "\\underline{%s}" c
+:options
+'((:latex-text-markup-alist ((code . protectedtexttt))
#+end_src diff
--
Timothy
Including Email Address in the Reply in Mailing-list
Hello all, I just noticed that some of us here, when replying, include the email of the sender of the previous email in the response as part of body of the email. This email address shows up in plain text in the mailing list[1]. This is certainly done without any ill-intentions, but that could cause the email address to receive quite a bit of spam if spammers crawl these pages. I suggest refraining from doing so, and instead use the name. Please let me know what you think. [1] this is an example: https://lists.gnu.org/archive/html/emacs-orgmode/2021-04/msg00042.html -- Husain Alshehhi
Re: [PATCH] ox-latex: Replace \verb instances in headings with \texttt
Nicolas Goaziou writes: >> * lisp/ox-latex.el (org-latex-format-headline-default-function): Convert >> any instances of \verb text with \texttt. This is required to work >> around LaTeX peculiarities that would otherwise cause compilation to >> fail (see the code comment for more information). > > This is not the appropriate location for the fix. > > In `section-back-end' variable within `org-latex-headline', you can > extend the local export back-end to handle correctly verbatim markup. > > Regards, Thanks Nicolas, I'll take a look at that and send over a revised patch :) -- Timothy
Re: Including Email Address in the Reply in Mailing-list
> I just noticed that some of us here, when replying, include the email of > the sender of the previous email in the response as part of body of the > email. /.../ > I suggest refraining from doing so, and instead use the name. Good idea! Cheers Rasmus
[Patch] to correctly sort the items with emphasis marks in a list
Hi all, I have noticed that a couple of (spurious?) spaces in a `format' expression of `org-sort-remove-invisible' is causing `org-sort-list' not to sort correctly (alphabetically) the items that contain emphasis marks in a plain list. I propose this very simple patch to fix that problem. Best regards, Juan Manuel diff --git a/lisp/org.el b/lisp/org.el index 04da1afcd..d10cc2f5c 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -8114,7 +8114,7 @@ Optional argument WITH-CASE means sort case-sensitively." (replace-regexp-in-string org-verbatim-re (lambda (m) (format "%s " (match-string 4 m))) (replace-regexp-in-string -org-emph-re (lambda (m) (format " %s " (match-string 4 m))) +org-emph-re (lambda (m) (format "%s" (match-string 4 m))) (org-link-display-format s) t t) t t))
Re: Using backticks for the inline code delimeter?
On Do 01 Apr 2021 at 09:32, autofrettage wrote: > I vote against backticks, since I think we can learn to live with some > diversity. Running with the crowd, the latest fashion, would, in the > end, leave us with something like Word and Windows, that is, something > which is seductively easy to use the first two days, but a pain in the > neck the rest of your life. > > Unfortunately, I have seen these tendencies in Linux, in Emacs -- yes, > live-move-visual is now default, which makes Emacs less consistent, but more > like Word -- and even in my favourite window manager. > > Please evaluate the design of Org Mode (and other things) without > putting a value on how similar it is to other things. A bicycle would > appear more familiar to a car driver if we replaced the handlebar with > a steering wheel, but it wouldn't make the bike any better. > > If someones fingers cannot adjust, let him/her customise a bit. > > Just my two cents. > > Rasmus +1 'Andreas
Bug: Incompatible return type in org-babel C when using a table of doubles with a header as a variable [9.4.4 (release_9.4.4-272-ga9f38b @ /home/richard/.emacs.d/straight/build/org/)]
When a table of floating pointer numbers that contains a header row is
set as a variable to a C source block, the generated header file
contains an invalid return type, causing the program to not compile.
For example, if I have a table that looks like
#+NAME: tbl-doubles-org-bug-report
#+begin_src C :includes :results table :colnames '("i" "val")
for (int i = 0; i < 5; i++) {
printf("%f %f\n", (double)i, i * 2.0);
}
#+end_src
#+RESULTS: tbl-doubles-org-bug-report
| i | val |
|-+-|
| 0.0 | 0.0 |
| 1.0 | 2.0 |
| 2.0 | 4.0 |
| 3.0 | 6.0 |
| 4.0 | 8.0 |
And then attempt to include that table as a variable called data
#+begin_src C :includes stdio.h :var data=tbl-doubles-org-bug-report
printf("No errors!");
#+end_src
Nothing is printed, and *Org-Babel Error Output* will display
/tmp/babel-NQHi51/C-src-lsA892.c: In function ‘data_h’:
/tmp/babel-NQHi51/C-src-lsA892.c:24:65: error: incompatible types when
returning type ‘double’ but ‘const char *’ was expected
24 | const char* data_h (int row, const char* col) { return
data[row][get_column_num(2,data_header,col)]; }
|
~^~~
/bin/bash: line 1: /tmp/babel-NQHi51/C-bin-90Zk27: Permission denied
If we look in the /tmp file mentioned, it's easy to see the
inconsistency.
double data[5][2] = {
{0.00,0.00},
{1.00,2.00},
{2.00,4.00},
{3.00,6.00},
{4.00,8.00}
};
const int data_rows = 5;
const int data_cols = 2;
int get_column_num (int nbcols, const char** header, const char* column)
{
int c;
for (c=0; c
Re: Font lock in org+elisp confused with ?\[
Reposting my reply to the emacs-devel thread here as well. The hack I mention that has performance issues was derived from John's solution for the <> issue (though the performance issues are all of my own creation). Best, Tom This is a known issue with org babel blocks. It is due to the fact that org babel translates the font locking for the language but not the syntax propertization. Another frequent cause is the bash case statement. The end result is that unmatched parens leak out from the babel blocks and wreak havoc elsewhere in the org file unless you balance out the parens e.g. in a comment. I have a hacked fix for this, but it has horrible performance, especially with line numbers enabled. I think that a proper solution would run arbitrary syntax propertization on subsets of a buffer without having to continually check where those subsets start or end.
Re: Including Email Address in the Reply in Mailing-list
I have no issue with this suggestion and am happy to try and comply. The challenge for many will be that they either - need to remember to remove the email details manually (line/header automatically added by mail client) while sorting out either - how to modify mail client for all replies (may not be appropriate for non-ML replies), or - how to modify mail client for just ML replies My personal belief is that if you subscribe to a public mail list, you need to accept that your email address will be 'out there' - more generally, over time, your email address is going to be harvested regardless and your better off trying to improve filtering and spam detection than any attempt to minimise the address appearing in archived content on-line. Off now to try and work out how to change the reply header in my mail clients! Husain Alshehhi > Hello all, > > I just noticed that some of us here, when replying, include the email of > the sender of the previous email in the response as part of body of the > email. This email address shows up in plain text in the mailing > list[1]. This is certainly done without any ill-intentions, but that > could cause the email address to receive quite a bit of spam if spammers > crawl these pages. > > I suggest refraining from doing so, and instead use the name. Please let > me know what you think. > > [1] this is an example: > https://lists.gnu.org/archive/html/emacs-orgmode/2021-04/msg00042.html -- Tim Cross
Re: Including Email Address in the Reply in Mailing-list
* Husain Alshehhi [2021-04-02 18:58]: > > Hello all, > > I just noticed that some of us here, when replying, include the email of > the sender of the previous email in the response as part of body of the > email. This email address shows up in plain text in the mailing > list[1]. This is certainly done without any ill-intentions, but that > could cause the email address to receive quite a bit of spam if spammers > crawl these pages. > > I suggest refraining from doing so, and instead use the name. Please let > me know what you think. I don't think it is a problem that you can solve by directing people on what is to be done. It will work with few people, but is always error prone. People read mailing list with various email clients, correcting the email or removing it by directing people who reply is simple not feasible. As you see, mailing list is pretty spam free, so either moderators do the work, or spam filters do the work. You can do the same with your domain, Protonmail is hosting it for you, and maybe they have spam filter or similar, there is server side check against spammer IP database and various other techniques. Spam that fraudulently originates from your domain would be, in my opinion, detected by Protonmail and placed in Spam folder due to ~all in the SPF record. alshehhi.io.299 IN TXT "v=spf1 include:_spf.protonmail.ch mx ~all" -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns Sign an open letter in support of Richard M. Stallman https://rms-support-letter.github.io/
Re: Including Email Address in the Reply in Mailing-list
* Tim Cross [2021-04-03 02:35]: > My personal belief is that if you subscribe to a public mail list, you > need to accept that your email address will be 'out there' - more > generally, over time, your email address is going to be harvested > regardless and your better off trying to improve filtering and spam > detection than any attempt to minimise the address appearing in archived > content on-line. > > Off now to try and work out how to change the reply header in my mail > clients! I am using this one, but not because of spam, rather when I have to forward email and don't want to disclose email addresses of related parties. (defun remove-emails () "Removes all emails from buffer. At some occasions user may want to forward email messages from other people without revealing their email addresses. mutt email client usually displayes email addresses in this format and all such addresses may be easily removed with this command." (interactive) (save-excursion (goto-char (point-min)) (let ((match (re-search-forward "<.*@.*>"))) (replace-match "" -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns Sign an open letter in support of Richard M. Stallman https://rms-support-letter.github.io/
Re: Including Email Address in the Reply in Mailing-list
Tim Cross writes: > I have no issue with this suggestion and am happy to try and comply. > > The challenge for many will be that they either > > - need to remember to remove the email details manually (line/header > automatically added by mail client) while sorting out either > > - how to modify mail client for all replies (may not be appropriate for > non-ML replies), or > > - how to modify mail client for just ML replies > [...] For Gnus users, one possibility might be: (defun my-gnus-reply-ml () (interactive) (let* ((message-citation-line-format "%N writes:\n") (message-citation-line-function 'message-insert-formatted-citation-line)) (gnus-article-reply-with-original))) ...And then assign any free key to gnus-article-mode-map Best regards, Juan Manuel
Re: Idea for handling timezones
shironeko writes: > Hi everyone, > > I, like many others on this list, have to move between timezones quite > frequently. As I gathered from the archive, it seems the main complexity in > supporting timezones is the difficulty revolving the change of timestamp > format. > So I have an idea, suppose we add a new keyword, "TIMEZONE" that can be set at > the start of the file like so > > #+TIMEZONE: America/Toronto > > This specifies the timezone of all timestamps in the file. Together with it, > there can be a function called e.g. org-shift-time, that shifts all the > timestamp in the file to another specified timezone and updates the keyword. > Of > course, care needs to be taken when dealing with dates without time, e.g. it > should be treated as at time 00:00 when it is alone or as the start of a time > range, and be treated as at time 24:00 when it is the end of a time range. > > Then there could be hooks that offer to run the function automatically when it > detects the user's system or emacs is set to a different timezone as in the > file > (e.g. when they open the file, or opens the agenda). This will make sure the > timestamps always aligns with their current one (if they wish). > I'm sorry, but I don't like this idea. In general, I think it is the wrong approach and not sophisticated enough to work with the complexities associated with timestamps. This is actually a very hard problem and not one which can be adequately addressed with something this simple. Problems include 1. Timzone alone is not sufficient. Offsets from UTC change due to daylight savings times etc. 2. You can easily have timestamps from different timezones in the same org file 3. Storing timestamps in local time is problematic because of the inherent ambiguity this can have (again, due to daylight savings times and what occurs at the 'cut over' time). 4. Sometimes, you may want the timestamp to reflect the date/time as it was when recorded and don't want it to 'change' because your now viewing it in a different timezone etc. Personally, I think timestamp 'storage' and timestamp 'display' need to be treated separately. I also think all relevant information (timezone, offset) need to be stored with the timestamp. I also think the fundamental base timestamp should be stored as UTC, allowing all time calculations to be consistent (free of daylight savings time changes). The user can then manage how the value is displayed by setting timezone and offsets as appropriate (with perhaps the default being the local system settings or whatever offset/tz was stored with the timestamp itself). It is very difficult to predict or understand all the use cases for timestamps. Therefore, any scheme must be extremely flexible. Experience has taught me that one critical component is that at the lowest level, many problems are avoided if the value is in UTC. Problem is, UTC is not terribly human friendly. Luckily, this can largely be automated for many common use cases. Unfortunately, it does also mean that if you are someone who frequently moves between many timezones, your situation will be more complicated. ne of the most frustrating parts of working with timestamps is daylight saving times. This causes complications at so many levels. In particular, I hate the fact change over dates often change and more often than not, those changes are based around politics and at the whim of politicians, which makes programatic handling more complex than it needs to be. -- Tim Cross
[fr] add timestamp to appended archive header
(defcustom org-archive-file-header-format "\nArchived entries from file %s\n\n" perhaps above could include a timestamp, or the ability to add one, so that one need not add archiving ts for every entry. -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: Idea for handling timezones
org has capability of overlaying [or similar] tses with user-defined something or other. for locale type purposes. perhaps, in principle, all tses for users who need tz could be in utc or similar, and such overlays could be used to localize on the fly? On 4/2/21, Tim Cross wrote: > > shironeko writes: > >> Hi everyone, >> >> I, like many others on this list, have to move between timezones quite >> frequently. As I gathered from the archive, it seems the main complexity >> in >> supporting timezones is the difficulty revolving the change of timestamp >> format. >> So I have an idea, suppose we add a new keyword, "TIMEZONE" that can be >> set at >> the start of the file like so >> >> #+TIMEZONE: America/Toronto >> >> This specifies the timezone of all timestamps in the file. Together with >> it, >> there can be a function called e.g. org-shift-time, that shifts all the >> timestamp in the file to another specified timezone and updates the >> keyword. Of >> course, care needs to be taken when dealing with dates without time, e.g. >> it >> should be treated as at time 00:00 when it is alone or as the start of a >> time >> range, and be treated as at time 24:00 when it is the end of a time >> range. >> >> Then there could be hooks that offer to run the function automatically >> when it >> detects the user's system or emacs is set to a different timezone as in >> the file >> (e.g. when they open the file, or opens the agenda). This will make sure >> the >> timestamps always aligns with their current one (if they wish). >> > > I'm sorry, but I don't like this idea. In general, I think it is the > wrong approach and not sophisticated enough to work with the > complexities associated with timestamps. > > This is actually a very hard problem and not one which can be adequately > addressed with something this simple. Problems include > > 1. Timzone alone is not sufficient. Offsets from UTC change due to > daylight savings times etc. > > 2. You can easily have timestamps from different timezones in the same > org file > > 3. Storing timestamps in local time is problematic because of the > inherent ambiguity this can have (again, due to daylight savings times > and what occurs at the 'cut over' time). > > 4. Sometimes, you may want the timestamp to reflect the date/time as it > was when recorded and don't want it to 'change' because your now viewing > it in a different timezone etc. > > Personally, I think timestamp 'storage' and timestamp 'display' need to > be treated separately. I also think all relevant information (timezone, > offset) need to be stored with the timestamp. I also think the > fundamental base timestamp should be stored as UTC, allowing all time > calculations to be consistent (free of daylight savings time changes). > The user can then manage how the value is displayed by setting timezone > and offsets as appropriate (with perhaps the default being the local > system settings or whatever offset/tz was stored with the timestamp > itself). > > It is very difficult to predict or understand all the use cases for > timestamps. Therefore, any scheme must be extremely flexible. Experience > has taught me that one critical component is that at the lowest level, > many problems are avoided if the value is in UTC. Problem is, UTC is not > terribly human friendly. Luckily, this can largely be automated for many > common use cases. Unfortunately, it does also mean that if you are > someone who frequently moves between many timezones, your situation will > be more complicated. > > ne of the most frustrating parts of working with timestamps is daylight > saving times. This causes complications at so many levels. In > particular, I hate the fact change over dates often change and more > often than not, those changes are based around politics and at the whim > of politicians, which makes programatic handling more complex than it > needs to be. > > -- > Tim Cross > > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: Idea for handling timezones
On Fri, 2021-04-02 at 13:34 +0200, to...@tuxteam.de wrote: > On Thu, Apr 01, 2021 at 07:40:47AM +, shironeko wrote: > > Hm. Just a mumbling from the peanut gallery: isn't the timezone a property > of the timestamp itself? > > Specifying the timezone for the whole file is progress, but imagine the > following scenario: I have a big file which is more or less a diary of > things which happened, with lots of timestamps thrown in (also LOGBOOK > entries). > > If I move through timezones, only some of the timestamps are "elsewhere". > There are separate hacks for that, see https://emacs.stackexchange.com/questions/13463/specify-timezone-in-org-date-format > Switching "the whole file" to reflect the "current" timezone feels somehow > wrong to me (which timezone a specific timestamp "happened" in has also > some documentary value, after all). > > To keep things unambiguous, more than just the timezone must be kept. > The current time offset is necessary to actually reconstruct the time > (DST and such things). This is why timezones need to be specified in the tz database format, it does all the right things and makes sure the converted timestamp corresponds to the same instant. > Of course, convincing Org to extend the timestamp format and regexps > might be a tough call :-) This is exactly the problem I'm trying to avoid. Regards, shiro signature.asc Description: This is a digitally signed message part
Re: Idea for handling timezones
On Sat, 2021-04-03 at 10:37 +1100, Tim Cross wrote: > > 1. Timzone alone is not sufficient. Offsets from UTC change due to > daylight savings times etc. > > 2. You can easily have timestamps from different timezones in the same > org file > > 3. Storing timestamps in local time is problematic because of the > inherent ambiguity this can have (again, due to daylight savings times > and what occurs at the 'cut over' time). > > 4. Sometimes, you may want the timestamp to reflect the date/time as it > was when recorded and don't want it to 'change' because your now viewing > it in a different timezone etc. 1 and 3 is addressed by the use of tz database, it makes sure the timezone conversion is lossless. 2 and 4 is really not the target for this proposal, this feature is completely optional and this is really meant to solve the "I want to see when I need to get my tasks done" which is a particular headache when there is timezone involved. > Personally, I think timestamp 'storage' and timestamp 'display' need to > be treated separately. I also think all relevant information (timezone, > offset) need to be stored with the timestamp. I also think the > fundamental base timestamp should be stored as UTC, allowing all time > calculations to be consistent (free of daylight savings time changes). > The user can then manage how the value is displayed by setting timezone > and offsets as appropriate (with perhaps the default being the local > system settings or whatever offset/tz was stored with the timestamp > itself). > > It is very difficult to predict or understand all the use cases for > timestamps. Therefore, any scheme must be extremely flexible. Experience > has taught me that one critical component is that at the lowest level, > many problems are avoided if the value is in UTC. Problem is, UTC is not > terribly human friendly. Luckily, this can largely be automated for many > common use cases. Unfortunately, it does also mean that if you are > someone who frequently moves between many timezones, your situation will > be more complicated. > > ne of the most frustrating parts of working with timestamps is daylight > saving times. This causes complications at so many levels. In > particular, I hate the fact change over dates often change and more > often than not, those changes are based around politics and at the whim > of politicians, which makes programatic handling more complex than it > needs to be. > yes, this is why I want to avoid changing the timestamp itself, since that will never lead to working solutions soon. Regards, shiro
Re: Idea for handling timezones
what i proposed is this. which uses text properties. it might not suit your needs, but might be a workaround. at least it is a brainstorm. suitable for wrapping fish. 1] convert all your tses to utc [exercise for the reader] 2] make org's idea of time be utc [there /might/ be code] 3] make org display local time and tz [see below] 3 is customizable: (info "(org) Custom time format") On 4/2/21, Shironeko wrote: > On Sat, 2021-04-03 at 10:37 +1100, Tim Cross wrote: >> >> 1. Timzone alone is not sufficient. Offsets from UTC change due to >> daylight savings times etc. >> >> 2. You can easily have timestamps from different timezones in the same >> org file >> >> 3. Storing timestamps in local time is problematic because of the >> inherent ambiguity this can have (again, due to daylight savings times >> and what occurs at the 'cut over' time). >> >> 4. Sometimes, you may want the timestamp to reflect the date/time as it >> was when recorded and don't want it to 'change' because your now viewing >> it in a different timezone etc. > > 1 and 3 is addressed by the use of tz database, it makes sure the timezone > conversion is lossless. 2 and 4 is really not the target for this proposal, > this > feature is completely optional and this is really meant to solve the "I want > to > see when I need to get my tasks done" which is a particular headache when > there > is timezone involved. > >> Personally, I think timestamp 'storage' and timestamp 'display' need to >> be treated separately. I also think all relevant information (timezone, >> offset) need to be stored with the timestamp. I also think the >> fundamental base timestamp should be stored as UTC, allowing all time >> calculations to be consistent (free of daylight savings time changes). >> The user can then manage how the value is displayed by setting timezone >> and offsets as appropriate (with perhaps the default being the local >> system settings or whatever offset/tz was stored with the timestamp >> itself). >> >> It is very difficult to predict or understand all the use cases for >> timestamps. Therefore, any scheme must be extremely flexible. Experience >> has taught me that one critical component is that at the lowest level, >> many problems are avoided if the value is in UTC. Problem is, UTC is not >> terribly human friendly. Luckily, this can largely be automated for many >> common use cases. Unfortunately, it does also mean that if you are >> someone who frequently moves between many timezones, your situation will >> be more complicated. >> >> ne of the most frustrating parts of working with timestamps is daylight >> saving times. This causes complications at so many levels. In >> particular, I hate the fact change over dates often change and more >> often than not, those changes are based around politics and at the whim >> of politicians, which makes programatic handling more complex than it >> needs to be. >> > > yes, this is why I want to avoid changing the timestamp itself, since that > will > never lead to working solutions soon. > > Regards, > shiro > > > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: Bug: Error while exporting o TexInfo. Html export works fine. [9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)]
On 02/04/21 8:29 pm, Nicolas Goaziou wrote: > Ramesh Nedunchezian writes: > >> While in the lint buffer, I was expecting that M-g M-n, M-g M-p would >> take me to the relevant source lines. Unfortunately, this isn't the >> case. And the linter report is derived from >> `org-lint--report-mode-map' which is derived from >> `tabulated-list-mode'. The departure from convention surprised me. > > I don't know what convention you're talking about and I don't understand > why that would be unfortunate. I think RET will take you to the relevant > source lines whereas TAB and C-j will display them. See manual, or minor > mode docstring, for details. I was expecting that the linter report will be in `compilation-minor-mode`. (info "(emacs) Compilation Mode") If the linter buffer were in compilation mode, I can do M-g M-n, M-g to move to next or previous errors. And these key-presses will work when I am in _either_ of the source org buffer or linter report. With things as it is now, is there a way I can quickly move between next or previous errors, when I am in _either_ of the source buffer or the linter report?
