Re: org-mode Publishing fails xhtml validation and LibreJS test.
Dear Time, > Tim Cross writes: > Colin Baxter writes: >> Hello, >> >> When publishing, org-mode inserts the following javascript in the >> xhtml file: >> >> #+begin_src js // @license >> magnet:?xt=urn:btih:e95b018ef3580986a04669f1b5879592219e2a7a&dn=public-domain.txt >> Public Domain // >> @license-end #+end_src >> >> There are issues with this script. >> >> 1. The script gives errors in XHTML 1.0 Strict validation. For >> example, the line beginning //@license ... gives errors of the >> type: a. cannot generate system identifier for general entity >> "dn" b. general entity "dn" not defined and no default entity >> c. reference not terminated by REFC delimiter etc. >> >> 2. The script fails the LibreJS (gnu.org/software/librejs) >> tests. This can be tested by opining the page in icecat. >> >> In order to pass XHTML and LibreJS validation tests, I have to >> delete the script from my web pages by hand. >> > Given the move to HTML5 and deprecation of XHTML, how valid are > XHTML compliance requirements these days? Could it be time to > 'reverse' the org defaults and export using HTML5 by default > rather than XHTML? I believe it remains important to have XHTML compliance, a view which would seem consistent with W3C's retention of its validation service. > Would it be sufficient to just have the license information > embedded as a simple comment? I think this might be a good idea. And if it gets rid of the non-free javascript (as defined by LibreJS and therefore by gnu) then so much the better. Best wishes, Colin Baxter. Colin Baxter URL: http://www.Colin-Baxter.com - GnuPG fingerprint: 68A8 799C 0230 16E7 BF68 2A27 BBFA 2492 91F5 41C8 -
Re: [PATCH] Margin added for overflow visibility problem
Fatih Aydin writes: > Write a code block in an org file and publish it to a html file. You > will see that only bottom part of the name of the programming language > is visible when you hover on it because of the css of that block > (overflow:auto) > To fix this, a margin-top can be added. Ah, that's a nice visual improvement. Thanks! To more closely follow conventions for commit messages in this project [1], I'd suggest to rewrite the message to something like this: --8<---cut here---start->8--- Subject: [PATCH] ox-html: Add margin to fix overflow visibility problem * lisp/ox-html.el (org-html-style-default): Add the margin-top property to pre.src:hover:before so that the programming language is fully visible. TINYCHANGE --8<---cut here---end--->8--- Does that look okay to you? If so, I can amend your commit when applying. (I'll wait a few more days for any CSS gurus on the list to weigh in.) [1] https://orgmode.org/worg/org-contribute.html#commit-messages
Re: Variables not set during tangle of sh code (org 9.5)
Robby Kiggen | Essential IT writes: > Hi, > > in OrgMode 9.5 it seems that the variables during the tangling of sh > aren't set/initialized. > > For example the block below: > #+begin_src sh :var str="Hello World" :tangle helloworld.sh > echo $str > #+end_src > > Gets tangled into: > echo $str > > Which means the str="Hello World" line is missing. My guess is that you haven't loaded ob-shell, as that's how I can reproduce what you report. After (require 'ob-shell), I see str='Hello World' echo $str
Re: Bug: Orgmode export takes "AC:" as a link keyword [9.5 (nil @ /Users/junwei/.emacs.d/.local/straight/build-27.1/org-mode/)]
Junwei Wang writes:
> When exporting orgmode file into HTML file, the exporter "mistakely"
> consider "AC:" as some keyword for linking and the string following
> "AC:" would be something link to.
It looks like org-ref is setting up these links for you. Here's the
relevant bit from the configuration you included:
org-link-parameters '([...]
("Ac" :follow or-follow-acronym :face org-ref-acronym-face :help-echo
or-acronym-tooltip :export
#[771 "\211\301>\203\302\303\300A#\207\302\304\226\"\207"
[("Ac" . "Gls") (latex beamer) format "\\%s{%s}" "%s"] 7
"\n\n(fn PATH _ FORMAT)"]
)
("ac" :follow or-follow-acronym :face org-ref-acronym-face :help-echo
or-acronym-tooltip :export
#[771 "\211\301>\203\302\303\300A#\207\302\304\226\"\207"
[("ac" . "gls") (latex beamer) format "\\%s{%s}" "%s"] 7
"\n\n(fn PATH _ FORMAT)"]
[...]
I suspect the uppercase "AC" being treated as a link despite it not
appearing in org-link-parameters is a case-related bug somewhere in
Org's link handling. While that's worth looking into, it just shifts
things as far as your original example is concerned: replace "AC" with
"ac", and you have the same issue that you reported.
One way to make Org not treat "ac:foo" as a link is to insert a
zero-width space (with, e.g., ) between "ac" and ":".
(info "(org)Escape Character")
bug#45212: org-capture user-error: Abort
> Sent: Sunday, December 13, 2020 at 6:22 AM > From: "Jean Louis" > To: daniela-s...@gmx.it > Cc: 45...@debbugs.gnu.org > Subject: bug#45212: org-capture user-error: Abort > > * daniela-s...@gmx.it [2020-12-12 23:19]: > > Emacs fires "user-error: Abort" after pressing "q" to abort org-capture. > > Those are error messages invented by programmers who never had any > project supervisor who thinks of users. > > If user wish to abort it is not an error. Even if it is error, why it > should be written with the dash as "user-error"?! > > If message is at all necessary then computer should say "Action > aborted" or similar. Agreed > >
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
> Sent: Sunday, December 13, 2020 at 6:19 AM > From: "Jean Louis" > To: daniela-s...@gmx.it > Cc: to...@tuxteam.de, emacs-orgmode@gnu.org, "Ihor Radchenko" > > Subject: Re: Emacs inserts hardwired org-agenda-files variable, overwriting > user options > > * daniela-s...@gmx.it [2020-12-12 05:41]: > > > And I think it is possible for anybody regardless of programming skill > > > level to make one's own system of management of tasks within less than > > > a week that will get more aligned to personal individualized way of > > > handling tasks, then trying to accommodate personal needs to software > > > that may have gone one completly wrong direction. > > > > If I said that I would be barraged by accusations of rudeness! :) > > The key is in steganography: > https://en.wikipedia.org/wiki/Steganography :) > Org mode is popular within subset of population using it where each > other encourage to use it more regardless of how much tedious efforts > it needs itself just to function how users would like it. Additionally > majority of users use functions of Org mode which they would not need > would they be simple be organized. A person well organized does not > look throug agenda as that means lack of organization. Agenda helps > those which are not organized. Just look at any friend or person who > organizes life without computer and compare to people using Org > mode. Software should replace slow methods with papers and make > planning faster and non-repetitive. Any software shall help human to > speed up actions. > > In general Org mode is excellent for personal TODO lists. That is what > is offered in the menu, that is what is advertised. Problem is that > there is no warning for users that personal TODO lists are not meant > for anything but that. There is no collaboration, putting TODO items > eveywhere IS procrastination. Using org-agenda to find procrastination > is another procrastination. Trying to glue everything together is > absence of good planning and not planning. Carsten would disagree with that evaluation. It is also for organising professional life - with plain text. Still, if you are disorganized, you can use it. Or perhaps if one is lazy - like myself, many things I do nat have an interest in but have to oversee at least some parts of them. > While reading how people write to mailing list trying to solve > problems they would never solve in the real world with paper I am > getting more and more surprised. > > What Org mode needs is at least few Wiki pages where various methods > of planning are presented as that could be useful to help people > minimize their procrastination. > > My experience comes from writing plans since more than 25 years. I was > always writing it on paper. Actions are chronologically and logically > ordered. Main objectives are always well defined for which purpose > subordinate actions have to be conducted. If main objectives are > fullfiled those subordinate actions become redundant or superfluous. > > From Org info file: > > > 5 TODO Items > > > > > Org mode does not maintain TODO lists as separate documents(1). > > Instead, TODO items are an integral part of the notes file, because TODO > > items usually come up while taking notes! > > For personal planning this may be fine for many, but I consider it bad > habbit. If there is an action item then put any information necessary > for that action within the action item. Print it along if > necessary. Handle your thinker notes first once and completely and > include what is necessary in action items. > > - person will not read the notes written back in time over and over > again. > > - if notes are not necessary for the action, why put them in front of > oneself to be read > > - horrible situations will take place if those notes which are not > necessary are put in front of collaborator who is now expected to > read action item and fulfill the action > > > because TODO items usually come up while taking notes! > > My action items have been written in project documents executed by > multiple groups of people in multiple countries on distances of 5000+ > kilometers away including by people who have never seen me face to > face. I have never put "notes" together with action items. > > Whoever wrote that "TODO items usually comes up while taking notes" > was referring to oneself and imposes this habit which I never had onto > others. > > In other words the manual imposes specific method of planning without > comparison to other methods of planning. Then users learn that is > right thing to do, ah, let me put everything together. > > Since 2016 almost all project planning was written by Org mode as I > find it useful to get LaTeX/PDF output. It is then printed, carried > physically by people on the ground and signed with initialy physically > by hand as DONE with the date and time. There known objectives and > those are targets to be fulfilled. > > Any notes arriving back from
bug#45212: org-capture user-error: Abort
* Ihor Radchenko [2020-12-13 07:35]: > > What case scenarios would rely > > on user quitting capture rather than going ahead with an entry? > > For example, I have a custom capture function from email. The email is > removed from inbox upon capture. However, I would not want to proceed > with removal if capture is aborted for whatever reason. If user wish to capture maybe it should be done more atomic and safely for some types of capturing email message ID, or emails, or capturing URLs, basically that data which already exists and which user need not create oneself. It excludes notes for example or anything related to real time annotations: - item that user wants to be captured should be captured in separate storage which I will mark here as (S) at the moment that users desired to do so. Nothing else should prevent that capture. Implementation of the storage is not important. Maybe it could be one file among many in a directory, maybe it could be in one big file, it does not matter. - in the next step would come the formatting of the storage. This can be aborted as people do various things. Maybe they wish to put some date, or this or that. When user signals that capture editing is finished at that moment only would the item from the storage (S) be removed. Examples of such workflow: - URL that only need to be captured without much annotations, click button. Finished. When time comes sort one by one into various categories. Not in real time. In real time user is browsing Internet and may like rather to continue reading the WWW instead of annotating the URLs or sorting into some categories. Click once, and Emacs WILL NOT open. It captured the URL. Why it should open? Annotate it or categorize it later when you annotate many items at once. - Messages like you said, one click. Finished. If necessary categorize later several messages at once. As a side note messages are always related to people or groups of people such as Org users. I am always extracting the email address and relating message to people automatically. - Pictures, videos, files quickly captured when browsing or searching for files. - Tasks related to message by related people I was always capturing with one single F10 or F11 in mutt. No thinking more than this. The subject and person would get captured. Later I have the list of the simple TODOs, how I called it and how I will soon re-implement it. Such tasks are more a reference to my thought. My thought is not written anywhere and for onlooker it would be not conclusive why I have captured that as an action. It is just a reference: person's name, subject, maybe email body, all that is reference as it associates me to the thought of some action I have to do related to that. But I need not write that action anywhere. That way a series of actions and series of thoughts do not get interrupted by Emacs capture window opening and requesting user to write something. Instead the item is capture by one key and user continues with the original uninterrputed serious of actions and thoughts. Focus remains on one action getting done, while some actions are postponed for later review. Later review is again done in a series of actions and thoughts not interrupted by something else. For collaboration this will not work. In that case one has to annotate things as the captured item does not serve well as association to the thought. The thought has to be written for collaboration unless group has well aligned thoughts to understand the meaning from the reference provided. Jean
Re: org-capture user-error: Abort
* daniela-s...@gmx.it [2020-12-12 23:19]: > Emacs fires "user-error: Abort" after pressing "q" to abort org-capture. Those are error messages invented by programmers who never had any project supervisor who thinks of users. If user wish to abort it is not an error. Even if it is error, why it should be written with the dash as "user-error"?! If message is at all necessary then computer should say "Action aborted" or similar.
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
* daniela-s...@gmx.it [2020-12-12 05:41]: > > And I think it is possible for anybody regardless of programming skill > > level to make one's own system of management of tasks within less than > > a week that will get more aligned to personal individualized way of > > handling tasks, then trying to accommodate personal needs to software > > that may have gone one completly wrong direction. > > If I said that I would be barraged by accusations of rudeness! :) The key is in steganography: https://en.wikipedia.org/wiki/Steganography Org mode is popular within subset of population using it where each other encourage to use it more regardless of how much tedious efforts it needs itself just to function how users would like it. Additionally majority of users use functions of Org mode which they would not need would they be simple be organized. A person well organized does not look throug agenda as that means lack of organization. Agenda helps those which are not organized. Just look at any friend or person who organizes life without computer and compare to people using Org mode. Software should replace slow methods with papers and make planning faster and non-repetitive. Any software shall help human to speed up actions. In general Org mode is excellent for personal TODO lists. That is what is offered in the menu, that is what is advertised. Problem is that there is no warning for users that personal TODO lists are not meant for anything but that. There is no collaboration, putting TODO items eveywhere IS procrastination. Using org-agenda to find procrastination is another procrastination. Trying to glue everything together is absence of good planning and not planning. While reading how people write to mailing list trying to solve problems they would never solve in the real world with paper I am getting more and more surprised. What Org mode needs is at least few Wiki pages where various methods of planning are presented as that could be useful to help people minimize their procrastination. My experience comes from writing plans since more than 25 years. I was always writing it on paper. Actions are chronologically and logically ordered. Main objectives are always well defined for which purpose subordinate actions have to be conducted. If main objectives are fullfiled those subordinate actions become redundant or superfluous. >From Org info file: > 5 TODO Items > > Org mode does not maintain TODO lists as separate documents(1). > Instead, TODO items are an integral part of the notes file, because TODO > items usually come up while taking notes! For personal planning this may be fine for many, but I consider it bad habbit. If there is an action item then put any information necessary for that action within the action item. Print it along if necessary. Handle your thinker notes first once and completely and include what is necessary in action items. - person will not read the notes written back in time over and over again. - if notes are not necessary for the action, why put them in front of oneself to be read - horrible situations will take place if those notes which are not necessary are put in front of collaborator who is now expected to read action item and fulfill the action > because TODO items usually come up while taking notes! My action items have been written in project documents executed by multiple groups of people in multiple countries on distances of 5000+ kilometers away including by people who have never seen me face to face. I have never put "notes" together with action items. Whoever wrote that "TODO items usually comes up while taking notes" was referring to oneself and imposes this habit which I never had onto others. In other words the manual imposes specific method of planning without comparison to other methods of planning. Then users learn that is right thing to do, ah, let me put everything together. Since 2016 almost all project planning was written by Org mode as I find it useful to get LaTeX/PDF output. It is then printed, carried physically by people on the ground and signed with initialy physically by hand as DONE with the date and time. There known objectives and those are targets to be fulfilled. Any notes arriving back from collaborators are not placed into project planning. If such would enhance project planning they could become part of planning for the next project. But generally the feedback notes do not relate to project planning itself, they relate to people, organizations, findings on ground, they are part of the report. It is not necessary to re-write the report back into any Org file as the plan is separate from reports and executions. Conclusions which come later could result in some new plan. But initial plan is not to be mixed with new information, it is rather kept intact and maybe improved for next time execution. > With Org mode, simply mark any entry in a tree as being a TODO > item. In this way, information is not
bug#45212: org-capture user-error: Abort
> Sent: Sunday, December 13, 2020 at 5:37 AM > From: "Ihor Radchenko" > To: daniela-s...@gmx.it > Cc: 45...@debbugs.gnu.org > Subject: bug#45212: org-capture user-error: Abort > > daniela-s...@gmx.it writes: > > > Can't one throw a capture abort signal instead? > > Sure, that is possible. However, consider a possibility that some > external package wants to detect when capture is aborted. If I was > writing such package, I would need to do something like > > (condition-case err > > (t )) > > If org-capture is rewritten using catch-throw, the above code would be > broken. Also, there will be no easy way for a user to know if the > capture was completed successfully or if it was aborted. The problem is not the "Abort" itself, but more precisely "user-error", rather than Abort. I suppose that depends on how many packages on ELPA check on "capture user-error". > Note that I do not oppose this change too firmly. I agree that throw (or > even just normal exit) would be cleaner. However, changing user-error to > throw may break external packages and should be considered carefully. On > the other hand, user-error is internal detail of the implementation. So, > changing it should not be a big deal. As a precaution, it can be > announced and implemented as a part of major release. > > If you want this change to happen, I suggest to provide the patch. This > will encourage the maintainers to provide feedback. It is not so much about imposing it, but it would make the whole thing cleaner as you described. > > What case scenarios would rely > > on user quitting capture rather than going ahead with an entry? > > For example, I have a custom capture function from email. The email is > removed from inbox upon capture. However, I would not want to proceed > with removal if capture is aborted for whatever reason. I see. Still, I am not against signaling an abort. > Best, > Ihor > > > > >
Re: Org Capture Menu cannot be fully viewed
> If you care to share a slightly bigger picture view, particularly about
> the structure of the data you are trying to capture (and/or, your
> workflow) we could likely come up with something that would work much
> better for you than a capture template, at least in this particular
> case.
Most agencies, universities, museums and archaeological organizations use
standard forms for recording sites. Generally speaking these are used but
with a couple of caveats. First, there are occasions when a standard form
may not call for recording enough data or the right kinds of data to satisfy
particular needs. Then there are Exclusive Surveys (Incomplete coverage,
portions of the project are excluded) and Unsystematic Surveys (done without
a specific plan, methods at varied level of intensity; coverage random,
opportunistic, or intuitive). In many instances, previous work would have
been done, so people would want to quickly skip entries.
The plan for Org-Mode Capture is primarily for such Exclusive and Unsystematic
Surveys
where we do not necessarily use standard forms. I'm not sure if you capture
the drift
concerning unsystematic surveys. Most times I cannot tell you exactly what
people in
the field came up with. The pace can be rapid and some could be working in
challenging
conditions. The plan is for the Crew Chief to make a quick template, and which
could
change each day. maintain and review notebooks and records and overseeing
quality
control is done daily. It is customary to split the day. One of the best ways
we
improve survey efficiency is to anticipate bottlenecks and invent creative
logistical
solutions right in the field.
The long template situation then occurs. You can access better than myself as
you
know what org and org-capture can do and what not. I briefly reported on what
we
found problematic in practice. But we're at the beginning of this, and would
likely report on other things as we progress. Still, most things are likely
to be done by the "Institute for Technologies applied to Cultural Heritage
(itabc)".
Nevertheless, we see some aspects where your scheme can be improved to cater
for more
serious work. Emacs is quite good software.
Hope my comments helped somewhat.
Pietru
> Sent: Sunday, December 13, 2020 at 4:16 AM
> From: "TRS-80"
> To: emacs-orgmode@gnu.org
> Subject: Re: Org Capture Menu cannot be fully viewed
>
> On 2020-12-12 21:08, pie...@caramail.com wrote:
> > Here is one version of a template
> >
> > (setq capture-template-investigation-type '(
> >
> > ("a" "Historic Background Research Site Evaluation/Testing" entry
> > (file "~/histr/archaeol.org")
> > "* Site_Type: %?\n %T\n")
> >
> > [...]
> >
> > ("u" "Remote Sensing" entry
> > (file "~/histr/archaeol.org")
> > "* Site_Type: %?\n %T\n") ))
> >
>
> Are there any more to these templates you did not show?
>
> Because, (and unless I am missing something) what I see are essentially
> all the same (and quite simple). You would end up with something like
> the following in your target file (with the cursor ending up at the x):
> #+begin_example
>
> * Site_Type: x
> [2020-12-12 Sat 21:58]
>
> #+end_example
>
> In fact I don't even see where the type name ends up in the result?
>
> If all my assumptions above are true, I think you would probably be
> better served with a simple completing-read (or similar) function to
> select the "Investigation Type" from a list and then simply insert that
> along with a timestamp. Which it will take you longer to reply to this
> email and confirm than it would take me to write such a function. :)
>
> Benefit of that way also removes possibility of typos in the type name.
>
> In fact, the above could even be done with something as simple as
> Yankpad[0].
>
> I have no idea what your workflow looks like, or where this data ends
> up. However, thinking further, I would imagine it might even be helpful
> to set one or more Org properties[1] for things like "Investigation
> Type" (along with some other things I could speculate like "Location"
> etc.). But all of that depends on even more things I don't know about.
>
> If you care to share a slightly bigger picture view, particularly about
> the structure of the data you are trying to capture (and/or, your
> workflow) we could likely come up with something that would work much
> better for you than a capture template, at least in this particular
> case.
>
> Cheers,
> TRS-80
>
> [0] https://github.com/Kungsgeten/yankpad
> [1] https://orgmode.org/manual/Properties-and-Columns.html
>
>
bug#45212: org-capture user-error: Abort
daniela-s...@gmx.it writes: > Can't one throw a capture abort signal instead? Sure, that is possible. However, consider a possibility that some external package wants to detect when capture is aborted. If I was writing such package, I would need to do something like (condition-case err (t )) If org-capture is rewritten using catch-throw, the above code would be broken. Also, there will be no easy way for a user to know if the capture was completed successfully or if it was aborted. Note that I do not oppose this change too firmly. I agree that throw (or even just normal exit) would be cleaner. However, changing user-error to throw may break external packages and should be considered carefully. On the other hand, user-error is internal detail of the implementation. So, changing it should not be a big deal. As a precaution, it can be announced and implemented as a part of major release. If you want this change to happen, I suggest to provide the patch. This will encourage the maintainers to provide feedback. > What case scenarios would rely > on user quitting capture rather than going ahead with an entry? For example, I have a custom capture function from email. The email is removed from inbox upon capture. However, I would not want to proceed with removal if capture is aborted for whatever reason. Best, Ihor
Re: Bug: html export fails after upgrading to 9.4 [9.4.1 (9.4.1-elpa @ /Users/jb/Library/Preferences/Aquamacs Emacs/Packages/elpa/org-20201212/)]
Johannes Brauer writes:
> Hi!
>
> Trying to export a buffer to html containing
>
> #+TITLE: Titel
> * header
>
> yields the error message:
> apply: Wrong type argument: listp, #("Titel" 0 5 (:parent (#0)))
>
> What can I do?
Thanks for the report and the minimal snippet. I'm not able to trigger
the above error on 9.4.1 using the default configuration. Based on
similar problems reported in the past, I think that you have a mixed
installation.
Re: Org Capture Menu cannot be fully viewed
On 2020-12-12 22:49, pie...@caramail.com wrote:
TRS-80 wrote:
Are there any more to these templates you did not show?
Because, (and unless I am missing something) what I see are
essentially
all the same (and quite simple). You would end up with something like
the following in your target file (with the cursor ending up at the
x):
It was an example for long agenda option. Wanted to send a basic one
without the details that could bother you. The real one will have
information regarding Site_Type [Domestic, Funerary, Water-Related,
Settlement]. But we don't have the things in org though.
It's no bother. In fact I am already thinking ahead as to the structure
of the data, which is the most important consideration. Choice of
tool(s) should flow from that, and also from the desired workflow,
instead of the other way around.
Just so you know, you /could/ have the things in Org, if you wanted to
(or even in a separate plain text file, and use that as input for your
narrowing selection list). Maybe they change, or there are other
reasons, but you could have the options in a list to choose from. This
sort of thing reduce typos and errors. You could limit to such list
strictly, or not (the latter allowing flexibility to add things on the
fly).
If all my assumptions above are true, I think you would probably be
better served with a simple completing-read (or similar) function to
select the "Investigation Type" from a list and then simply insert
that
along with a timestamp. Which it will take you longer to reply to
this
email and confirm than it would take me to write such a function. :)
Yes, I know about " %^{Investigation Type: |Site
Stabilization|Heritage Management|Environment Research} %?\n"
I am beginning to suspect you have bigger data and more options than fit
comfortably into a capture template. I could be wrong, but in my mind
at least, the idea of capture templates is to quickly store small ideas,
notes, TODOs, etc. so you can go back to what you were working on in the
first place, with minimal interruption to your original train of
thought.
Data can then be parsed into database once we get tho data files at
home
base.
True, however well designed "capture" mechanism (in reality, data
structure) will make this job much easier.
What sort of thing better than template capture? My basic idea was to
see
what org tools are available, see what kind of problems me get to,
without
asking too much things specific to us. We can then work through things
ourselves. Perhaps share them with some other organisations.
As I mentioned in last mail, I think Org Properties might be more what
you might be looking for. You may or may not even need any custom Elisp
in addition to that.
[1] https://orgmode.org/manual/Properties-and-Columns.html
Try and just play around with that, create some heading and do
org-set-property and then enter a key and value. If you want to set a
list to choose from, you put at top of file something like:
#+PROPERTY: Investigation_Type_ALL Site_Stabilize Heritage_Management
#+PROPERTY: District_ALL 1 2 3
#+PROPERTY: Site_Type_ALL Domestic Funerary Water-Related Settlement
[...]
You may need to press C-c C-c within the above to re-load and make it
live.
If you like something like that, it's easy to copy blank template and
just open new one for each survey or whatever you are doing and go from
there. And then here is where Emacs and Orgmode really shine, as they
are unparalleled as note taking tools. You can include pictures,
tables, etc. headlines and lists, etc. But you probably know all that
already.
Cheers,
TRS-80
Re: [PATCH] ob-ruby.el: Don't reuse the same buffer among different named
Aaron Madlon-Kay writes: >> + (run-ruby-or-pop-to-buffer >> + cmd (or session "ruby") >> + (unless session >> +(inf-ruby-buffer))) > > I have just run into an issue with this: If you don't specify :ruby > then `cmd' for me is calculated by > > (cdr (assoc inf-ruby-default-implementation inf-ruby-implementations)) > > which gives the function `inf-ruby--irb-command' as a result. > > However `run-ruby-or-pop-to-buffer' expects to get a string only. Thanks for noting this. Indeed it looks like the old call through run-ruby handled this (run-ruby-or-pop-to-buffer (let ((command (or command (cdr (assoc inf-ruby-default-implementation inf-ruby-implementations) (if (functionp command) (funcall command) command)) ...) and that's lost with this switch to run-ruby-or-pop-to-buffer. > I'm not sure if it should be org-mode's responsibility to resolve the > actual command string, or if it should be done by > `run-ruby-or-pop-to-buffer'. (It kind of seems like the latter?) > > Any thoughts? Given the current situation, I don't see a good option aside from doing the functionp dance in org-babel-ruby-initiate-session as well. Even if inf-ruby's check was moved downstream of run-ruby-or-pop-to-buffer, I think it'd be good to fix on ob-ruby's end to work with the current inf-ruby. Juri, what do you think?
Re: Org Capture Menu cannot be fully viewed
> Sent: Sunday, December 13, 2020 at 4:16 AM
> From: "TRS-80"
> To: emacs-orgmode@gnu.org
> Subject: Re: Org Capture Menu cannot be fully viewed
>
> On 2020-12-12 21:08, pie...@caramail.com wrote:
> > Here is one version of a template
> >
> > (setq capture-template-investigation-type '(
> >
> > ("a" "Historic Background Research Site Evaluation/Testing" entry
> > (file "~/histr/archaeol.org")
> > "* Site_Type: %?\n %T\n")
> >
> > [...]
> >
> > ("u" "Remote Sensing" entry
> > (file "~/histr/archaeol.org")
> > "* Site_Type: %?\n %T\n") ))
> >
>
> Are there any more to these templates you did not show?
>
> Because, (and unless I am missing something) what I see are essentially
> all the same (and quite simple). You would end up with something like
> the following in your target file (with the cursor ending up at the x):
It was an example for long agenda option. Wanted to send a basic one
without the details that could bother you. The real one will have information
regarding Site_Type [Domestic, Funerary, Water-Related, Settlement]. But we
don't have the things in org though.
> #+begin_example
>
> * Site_Type: x
> [2020-12-12 Sat 21:58]
>
> #+end_example
>
> In fact I don't even see where the type name ends up in the result?
>
> If all my assumptions above are true, I think you would probably be
> better served with a simple completing-read (or similar) function to
> select the "Investigation Type" from a list and then simply insert that
> along with a timestamp. Which it will take you longer to reply to this
> email and confirm than it would take me to write such a function. :)
Yes, I know about
" %^{Investigation Type: |Site Stabilization|Heritage Management|Environment
Research} %?\n"
At any rate, we come across long capture menus at one point or another. The
list is not fixed
but can vary by project that we cannot always predict (i.e. it could be changed
in the field).
> Benefit of that way also removes possibility of typos in the type name.
>
> In fact, the above could even be done with something as simple as
> Yankpad[0].
>
> I have no idea what your workflow looks like, or where this data ends
> up. However, thinking further, I would imagine it might even be helpful
> to set one or more Org properties[1] for things like "Investigation
> Type" (along with some other things I could speculate like "Location"
> etc.). But all of that depends on even more things I don't know about.
Data can then be parsed into database once we get tho data files at home
base.
> If you care to share a slightly bigger picture view, particularly about
> the structure of the data you are trying to capture (and/or, your
> workflow) we could likely come up with something that would work much
> better for you than a capture template, at least in this particular
> case.
What sort of thing better than template capture? My basic idea was to see
what org tools are available, see what kind of problems me get to, without
asking too much things specific to us. We can then work through things
ourselves. Perhaps share them with some other organisations.
> Cheers,
> TRS-80
>
> [0] https://github.com/Kungsgeten/yankpad
> [1] https://orgmode.org/manual/Properties-and-Columns.html
>
>
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
On 2020-12-11 21:35, Jean Louis wrote: By the way I have completely switched all action management to my database system with tabulated list mode. No more using Org for action management, only for document, not even short notes. It sounds like you have well moved on to another solution by now, however I did want to point out what I thought was one small factual inaccuracy. Org mode have imposed reverse on users where for example a list of items is only then completed as DONE when subordinate tasks have been completed as DONE Unless I am badly mistaken, I think this is only true when org-enforce-todo-dependencies is non-nil? Cheers, TRS-80
Re: Org Capture Menu cannot be fully viewed
On 2020-12-12 21:08, pie...@caramail.com wrote:
Here is one version of a template
(setq capture-template-investigation-type '(
("a" "Historic Background Research Site Evaluation/Testing" entry
(file "~/histr/archaeol.org")
"* Site_Type: %?\n %T\n")
[...]
("u" "Remote Sensing" entry
(file "~/histr/archaeol.org")
"* Site_Type: %?\n %T\n") ))
Are there any more to these templates you did not show?
Because, (and unless I am missing something) what I see are essentially
all the same (and quite simple). You would end up with something like
the following in your target file (with the cursor ending up at the x):
#+begin_example
* Site_Type: x
[2020-12-12 Sat 21:58]
#+end_example
In fact I don't even see where the type name ends up in the result?
If all my assumptions above are true, I think you would probably be
better served with a simple completing-read (or similar) function to
select the "Investigation Type" from a list and then simply insert that
along with a timestamp. Which it will take you longer to reply to this
email and confirm than it would take me to write such a function. :)
Benefit of that way also removes possibility of typos in the type name.
In fact, the above could even be done with something as simple as
Yankpad[0].
I have no idea what your workflow looks like, or where this data ends
up. However, thinking further, I would imagine it might even be helpful
to set one or more Org properties[1] for things like "Investigation
Type" (along with some other things I could speculate like "Location"
etc.). But all of that depends on even more things I don't know about.
If you care to share a slightly bigger picture view, particularly about
the structure of the data you are trying to capture (and/or, your
workflow) we could likely come up with something that would work much
better for you than a capture template, at least in this particular
case.
Cheers,
TRS-80
[0] https://github.com/Kungsgeten/yankpad
[1] https://orgmode.org/manual/Properties-and-Columns.html
Re: org-table change time from UTC to other timezones
Thank for the ideas. The 'date' command examples look interesting. I think R would not be too unwieldy as a hammer here. My use case is a humble one: just take a several clock times in HH:MM format (utc) and adjust to another timezone by adding or subtracting the relevant number of hours. The day of week is not important; i will have to deal with it. I did imagine a conditional subtraction by adding of subtracting 24:00 as needed. Much thanks for the advice. Alan On Sat, Dec 12, 2020, 15:00 Tim Cross wrote: > > Maxim Nikulin writes: > > > 2020-12-12 Alan E. Davis wrote: > >> > >> Thank for the clear explanation. My little problem seems to require a > >> super steam hammer. Your insights are most helpful. > > > > In my opinion, org mode is too rigid in respect to timestamp format. > > Sometimes I would prefer to specify timestamps with timezone. > > > > Well known example of idiosyncrasy of particular applications. > > Timestamps in xls files are represented by floating point numbers, > > namely days since 1 Jan 1900, fractional part is time. Unfortunately > > 1900 is not a leap year, so to avoid unnecessary complications of code > > and keep memory footprint small, on Macs epoch starts in 1904, on > > windows year 1900 has Feb, 29... > > Although there are likely some dark corners where bugs can be found, I > think you could probably add timezone data to org timestamps by changing > the default format strings. Org also uses an 'internal' 'time' value to > represent timestamps which are then converted to the required format > using these format strings. > > What is possibly missing is an easy way to specify a time zone when > creating a timestamp. I suspect it will default to whatever the local > system tz is and I don't think there is any convenient way to change tz > values like there is for the other timestamp components. > > -- > Tim Cross > >
Html export custom container with attribute
I know I can have a headline render to a custom container during export to html with a property eg HTML_CONTAINER: details But what If I want an attribute to set the state? Specifically I want the container to be `` in some situation and just plain `` in some others. What are my options? Thanks a lot, George
bug#45212: org-capture user-error: Abort
> Sent: Sunday, December 13, 2020 at 3:51 AM > From: "Ihor Radchenko" > To: daniela-s...@gmx.it, daniela-s...@gmx.it > Cc: 45...@debbugs.gnu.org > Subject: bug#45212: org-capture user-error: Abort > > daniela-s...@gmx.it writes: > > > Why it is intended? The user wanted to abort and Emacs obeyed. (q) is an > > option, the user used it, > > and Emacs should not throw an error at the user. > > I guess the intention was throwing signal + showing message to user. The > same could certainly be implemented without user-error. However, some > packages might be relying on the present behaviour and changing it could > break user's workflows. If you have any ideas how to implement quitting > from org-capture without using user-error *and supporting backward > compatibility*, patches are welcome. Can't one throw a capture abort signal instead? What case scenarios would rely on user quitting capture rather than going ahead with an entry? > Also, you can add this error to debug-ignored-errors to avoid annoyance > when debug-on-error is active. > > Best, > Ihor > > > > > >
bug#45212: org-capture user-error: Abort
daniela-s...@gmx.it writes: > Why it is intended? The user wanted to abort and Emacs obeyed. (q) is an > option, the user used it, > and Emacs should not throw an error at the user. I guess the intention was throwing signal + showing message to user. The same could certainly be implemented without user-error. However, some packages might be relying on the present behaviour and changing it could break user's workflows. If you have any ideas how to implement quitting from org-capture without using user-error *and supporting backward compatibility*, patches are welcome. Also, you can add this error to debug-ignored-errors to avoid annoyance when debug-on-error is active. Best, Ihor
Re: Bug fix attached: org-babel sql postgres, fix hardcode
It looks like the two patches are sequential, there should probably be a rebase into a single patch. I would remove the comment in the second patch because it is a single command to jump to the default value and it might change in the future, so no reason to put it in a comment. One way to communicate about the source of that variable is to include (require 'sql) in ob-sql which is likely needed anyway due to the fact that sql-postgres-program is defined by sql.el and there will be a byte compiler error because the variable is undefined. Having the value of "psql" present as a backup in case sql-postgres-program is somehow nil seems reasonable. Best, Tom
Org Capture Menu cannot be fully viewed
Here is one version of a template
(setq capture-template-investigation-type '(
("a" "Historic Background Research Site Evaluation/Testing" entry
(file "~/histr/archaeol.org")
"* Site_Type: %?\n %T\n")
("b" "Systematic Survey Data Recovery/Excavation" entry
(file "~/histr/archaeol.org")
"* Site_Type: %?\n %T\n")
("c" "Records Search or Inventory Checking" entry
(file "~/histr/archaeol.org")
"* Site_Type: %?\n %T\n")
("d" "Site Stewardship Monitoring" entry
(file "~/histr/archaeol.org")
"* Site_Type: %?\n %T\n")
("e" "Site Stabilization" entry
(file "~/histr/archaeol.org")
"* Site_Type: %?\n %T\n")
("f" "Heritage Management" entry
(file "~/histr/archaeol.org")
"* Site_Type: %?\n %T\n")
("g" "Environment Research" entry
(file "~/histr/archaeol.org")
"* Site_Type: %?\n %T\n")
("h" "Reconnaissance or Survey" entry
(file "~/histr/archaeol.org")
"* Site_Type: %?\n %T\n")
("i" "Methodology, Theory, or Synthesis" entry
(file "~/histr/archaeol.org")
"* Site_Type: %?\n %T\n")
("j" "Collections Research" entry
(file "~/histr/archaeol.org")
"* Site_Type: %?\n %T\n")
("k" "Consultation" entry
(file "~/histr/archaeol.org")
"* Site_Type: %?\n %T\n")
("l" "Ethnographic Research" entry
(file "~/histr/archaeol.org")
"* Site_Type: %?\n %T\n")
("m" "Research Design or Data Recovery Plan" entry
(file "~/histr/archaeol.org")
"* Site_Type: %?\n %T\n")
("n" "Architectural Survey" entry
(file "~/histr/archaeol.org")
"* Site_Type: %?\n %T\n")
("o" "Ethnohistoric Research" entry
(file "~/histr/archaeol.org")
"* Site_Type: %?\n %T\n")
("p" "Ground Disturbance Monitoring" entry
(file "~/histr/archaeol.org")
"* Site_Type: %?\n %T\n")
("q" "Geophysical Survey" entry
(file "~/histr/archaeol.org")
"* Site_Type: %?\n %T\n")
("r" "Archaeological Overview" entry
(file "~/histr/archaeol.org")
"* Site_Type: %?\n %T\n")
("s" "Bioarchaeological Research" entry
(file "~/histr/archaeol.org")
"* Site_Type: %?\n %T\n")
("t" "Architectural Documentation" entry
(file "~/histr/archaeol.org")
"* Site_Type: %?\n %T\n")
("u" "Remote Sensing" entry
(file "~/histr/archaeol.org")
"* Site_Type: %?\n %T\n") ))
> Sent: Sunday, December 13, 2020 at 2:32 AM
> From: pie...@caramail.com
> To: "Tim Cross"
> Cc: emacs-orgmode@gnu.org
> Subject: Re: Org Capture Menu cannot be fully viewed
>
> > Sent: Sunday, December 13, 2020 at 1:46 AM
> > From: "Tim Cross"
> > To: emacs-orgmode@gnu.org
> > Subject: Re: Org Capture Menu cannot be fully viewed
> >
> >
> > pie...@caramail.com writes:
> >
> > > Dear All,
> > >
> > > When making a relatively long Org Capture Menu for Archaeological Field
> > > Management,
> > > the relevant capture window cannot be scrolled down. This becomes
> > > particularly
> > > problematic with small field laptops.
> > >
> >
> > I'm assuming you mean the window which pops up where you select the
> > capture template to use.
>
> Correct
>
> > Just wondering if perhaps what we really need to do is provide some sort
> > of support for using Emacs completion facilities to select templates? I
> > realise this is challenging because of the huge wealth of completion
> > frameworks available in Emacs, but perhaps adding support for something
> > like fido-mode would be beneficial. To some extent, it feels like org is
> > re-inventing a wheel here and we would be better off using an existing
> > facility rather than develop/maintain an org specific version.
>
> I have used icomplete, which works really well. But I am not in a position
> to claim it is the right solution
>
> > I see a very similar problem with the export menu, but that is a more
> > complex situation.
> > --
> > Tim Cross
> >
> >
>
>
bug#45212: org-capture user-error: Abort
> Sent: Sunday, December 13, 2020 at 2:34 AM > From: daniela-s...@gmx.it > To: "Ihor Radchenko" > Cc: 45...@debbugs.gnu.org > Subject: bug#45212: org-capture user-error: Abort > > > > > Sent: Sunday, December 13, 2020 at 2:07 AM > > From: "Ihor Radchenko" > > To: daniela-s...@gmx.it, 45...@debbugs.gnu.org > > Subject: bug#45212: org-capture user-error: Abort > > > > daniela-s...@gmx.it writes: > > > > > Emacs fires "user-error: Abort" after pressing "q" to abort org-capture. > > > > This is intended. Normally, it just shows up as a message in the > > minibuffer. Or do you have debug-on-error enabled? > > I have debug-on-error enabled Why it is intended? The user wanted to abort and Emacs obeyed. (q) is an option, the user used it, and Emacs should not throw an error at the user. > > Best, > > Ihor > > > > > > > > > > > > > >
bug#45212: org-capture user-error: Abort
> Sent: Sunday, December 13, 2020 at 2:07 AM > From: "Ihor Radchenko" > To: daniela-s...@gmx.it, 45...@debbugs.gnu.org > Subject: bug#45212: org-capture user-error: Abort > > daniela-s...@gmx.it writes: > > > Emacs fires "user-error: Abort" after pressing "q" to abort org-capture. > > This is intended. Normally, it just shows up as a message in the > minibuffer. Or do you have debug-on-error enabled? I have debug-on-error enabled > Best, > Ihor > > > > >
Re: Org Capture Menu cannot be fully viewed
> Sent: Sunday, December 13, 2020 at 1:46 AM > From: "Tim Cross" > To: emacs-orgmode@gnu.org > Subject: Re: Org Capture Menu cannot be fully viewed > > > pie...@caramail.com writes: > > > Dear All, > > > > When making a relatively long Org Capture Menu for Archaeological Field > > Management, > > the relevant capture window cannot be scrolled down. This becomes > > particularly > > problematic with small field laptops. > > > > I'm assuming you mean the window which pops up where you select the > capture template to use. Correct > Just wondering if perhaps what we really need to do is provide some sort > of support for using Emacs completion facilities to select templates? I > realise this is challenging because of the huge wealth of completion > frameworks available in Emacs, but perhaps adding support for something > like fido-mode would be beneficial. To some extent, it feels like org is > re-inventing a wheel here and we would be better off using an existing > facility rather than develop/maintain an org specific version. I have used icomplete, which works really well. But I am not in a position to claim it is the right solution > I see a very similar problem with the export menu, but that is a more > complex situation. > -- > Tim Cross > >
Bug: LaTeX: inline maths expression in \textrm is not fully supported
Sometimes, we want to nest inline maths expression in \textrm to
handle spaces easily and avoid repetition.
Examples:
1. $A = \{n : \textrm{$n$ odd in $X$}\}$
2. $A = \{n : \textrm{\(n\) odd in \(X\)}\}$
3. \(A = \{n : \textrm{\(n\) odd in \(X\)}\}\)
4. \(A = \{n : \textrm{$n$ odd in $X$}\}\)
are all equivalent to
- $A = \{n : n \textrm{ odd in } X}\}$
But Org mode exports them in LaTeX as
\begin{enumerate}
\item \$A = $\backslash${n : \textrm{$n$ odd in $X$}$\backslash$}\$
\item \(A = \{n : \textrm{\(n\) odd in \(X\)}\}\)
\item \(A = \{n : \textrm{\(n\) odd in \(X\)\}$\backslash$}$\backslash$)
\item \(A = \{n : \textrm{$n$ odd in $X$}\}\)
\end{enumerate}
Namely, only cases 2. and 4., where nested maths delimiters are different
than the outer-most maths delimiters, are correctly exported.
On the other hand, Cases 1. and 3. introduced extra $\backslash$.
Interestingly, display style maths expressions are correctly exported.
5. $$A = \{n : \textrm{$n$ odd in $X$}\}$$
6. $$A = \{n : \textrm{\(n\) odd in \(X\)}\}$$
7. \[A = \{n : \textrm{\(n\) odd in \(X\)}\}\]
8. \[A = \{n : \textrm{$n$ odd in $X$}\}\]
exports to
\begin{enumerate}
\item $$A = \{n : \textrm{$n$ odd in $X$}\}$$
\item $$A = \{n : \textrm{\(n\) odd in \(X\)}\}$$
\item \[A = \{n : \textrm{\(n\) odd in \(X\)}\}\]
\item \[A = \{n : \textrm{$n$ odd in $X$}\}\]
\end{enumerate}
without extra $\backslash$.
Best,
Firmin
Emacs : GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20,
cairo version 1.16.0) of 2020-10-16
Package: Org mode version 9.4 (9.4-55-g706ba9-elpaplus @
~/.emacs.d/elpa/org-20201207/)
Re: Better heading links in org-mode exports
On 2020-12-12 15:29, Jussi Norlund wrote: Hi, I would like to propose improving the naming of anchor heading links in primarily HTML and Markdown exports in org-mode. Here's an example of an implementation of a better naming setup: http://ivanmalison.github.io/dotfiles/#usemyowndefaultnamingschemefororgheadings Best regards Hi Jussi, This is actually being discussed already at some length in another thread titled "stability of toc links" which was last posted to as recently as today. I don't know if this should be re-posted over there or not? At any rate, I expect you will be interested in that conversation, as well. Cheers, TRS-80
Re: org-mode Publishing fails xhtml validation and LibreJS test.
Colin Baxter writes: > Hello, > > When publishing, org-mode inserts the following javascript in the xhtml file: > > #+begin_src js > > // @license > magnet:?xt=urn:btih:e95b018ef3580986a04669f1b5879592219e2a7a&dn=public-domain.txt > Public Domain > > // @license-end > > #+end_src > > There are issues with this script. > > 1. The script gives errors in XHTML 1.0 Strict validation. For example, > the line beginning //@license ... gives errors of the type: > a. cannot generate system identifier for general entity "dn" > b. general entity "dn" not defined and no default entity > c. reference not terminated by REFC delimiter > etc. > > 2. The script fails the LibreJS (gnu.org/software/librejs) tests. This > can be tested by opining the page in icecat. > > In order to pass XHTML and LibreJS validation tests, I have to delete > the script from my web pages by hand. > Given the move to HTML5 and deprecation of XHTML, how valid are XHTML compliance requirements these days? Could it be time to 'reverse' the org defaults and export using HTML5 by default rather than XHTML? Would it be sufficient to just have the license information embedded as a simple comment? -- Tim Cross
Re: org-capture user-error: Abort
daniela-s...@gmx.it writes: > Emacs fires "user-error: Abort" after pressing "q" to abort org-capture. This is intended. Normally, it just shows up as a message in the minibuffer. Or do you have debug-on-error enabled? Best, Ihor
Re: Org Capture Menu cannot be fully viewed
pie...@caramail.com writes: > Dear All, > > When making a relatively long Org Capture Menu for Archaeological Field > Management, > the relevant capture window cannot be scrolled down. This becomes > particularly > problematic with small field laptops. > I'm assuming you mean the window which pops up where you select the capture template to use. Just wondering if perhaps what we really need to do is provide some sort of support for using Emacs completion facilities to select templates? I realise this is challenging because of the huge wealth of completion frameworks available in Emacs, but perhaps adding support for something like fido-mode would be beneficial. To some extent, it feels like org is re-inventing a wheel here and we would be better off using an existing facility rather than develop/maintain an org specific version. I see a very similar problem with the export menu, but that is a more complex situation. -- Tim Cross
Re: Bug fix attached: org-babel sql postgres, fix hardcode
> when defined. psql will For future: You need to use 2 spaces after sentence end ^_^. As I understand, these NEWS entries must have specific formatting to be harvested automatically into NEWS file. So, patches should comply with all the requirements listed in https://orgmode.org/worg/org-contribute.html Best, Ihor Alan Light writes: > New patch file attached.
Re: Bring up a screen giving option to open a series of orgmode files
Jean Louis writes: > While it is easy to teach people to open single program, press a key, > and insert title, it is harder and time consuming to teach random > people how to use Emacs. This may not be true, it is just my current > impression. I guess one would not need to teach people about everything in Emacs. If the aim is just editing and viewing PDF, one can provide custom Emacs configuration with added toolbars and menu items for common operations with pdf. I do not see why it would be any different from specialised pdf viewers.
Re: Bring up a screen giving option to open a series of orgmode files
Jean Louis writes: > For private annotations with hypothes.is one can install it on own > server and protect system for one's own group. That will do only a > group that is serious enough or have serious demands for annotations. > Myself I do not prefer having too much software installed online > especially not databases that are private. What is private I keep off > the Internet. If I wish to communicate over Internet to somebody I > always establish first encrypted line. I have hypothes.is installed inside docker container locally. No serious protection is required in such case (at least, no more than one would use to protect private files from dangerous software like browsers). Public annotations would better be just exported to a public server (automatically or not). > So I am about to develop system to provide annotation to somebody over > Internet, without compromising security of the file or annotation. > > As each hyperdocument has its unique ID, it is easy to expand it into: > > example.com/1/2/3/4 for ID 1234 > > That would be HTML with PDF annotation where user could open PDF > inside of that HTML or click on the PDF to open it. I do hope that > pdfjs does support specific page jumps. And such annotation on HTML > should work with or without Javascript. Those without can simply open > PDF file and manually jump to specific page as annotated and > instructed. I am not sure how it is different from using hypothes.is for the same purpose. Note that hypothes.is uses pdf fingerprinting, so you don't even need to store pdf on server side. If user can open the pdf (obtained from you directly, for example), hypothes.is will automatically show the up-to-date annotations shared via public hypothes.is instance for that particular user. > Then I would inject web server password protection and protect it from > public. But that does not protect the document of those who could > intrude into the server and also does not protect from cracking > attempts as username and password are not alone well secure. Better > would be having the encrypted HTML that is protected by user's private > PGP key, but I have no idea if such technology exists yet. hypothes.is uses OAuth mechanism with fine-grained control over the access to various annotations. Also, one can run it inside encrypted docker container (or even inside virtual machine) reducing the risk if server is compromised.
Better heading links in org-mode exports
Hi, I would like to propose improving the naming of anchor heading links in primarily HTML and Markdown exports in org-mode. Here's an example of an implementation of a better naming setup: http://ivanmalison.github.io/dotfiles/#usemyowndefaultnamingschemefororgheadings Best regards
Re: Bug fix attached: org-babel sql postgres, fix hardcode
New patch file attached. On Sat, Dec 12, 2020 at 7:14 PM Ihor Radchenko wrote: > Alan Light writes: > > > Sorry, I don't understand. That's what I did. The patch was attached to > my > > email. > > You need to add patch description, not just title. Something like: > > * ob-sql.el (org-babel-execute:sql): Use `sql-postgres-program' as > postgresql executable (instead of psql) when defined. > > Best, > Ihor > 0002-ob-sql.el-ob-sql.el-org-babel-execute-sql-Use-sql-po.patch Description: Binary data
Re: Bug fix attached: org-babel sql postgres, fix hardcode
Alan Light writes: > Sorry, I don't understand. That's what I did. The patch was attached to my > email. You need to add patch description, not just title. Something like: * ob-sql.el (org-babel-execute:sql): Use `sql-postgres-program' as postgresql executable (instead of psql) when defined. Best, Ihor
Re: Org Capture Menu cannot be fully viewed
> Sent: Sunday, December 13, 2020 at 1:00 AM > From: "TRS-80" > To: emacs-orgmode@gnu.org > Subject: Re: Org Capture Menu cannot be fully viewed > > On 2020-12-12 18:30, pie...@caramail.com wrote: > >> From: "TRS-80" > >> > >> Well, it's up to you. If you want we can pursue either option, or > >> both > >> (one potentially as a temporary workaround). Or we can wait for more > >> list replies and see what others think. As I said there may also be a > >> better way I am not aware of. If I'm being honest, I have plenty > >> other > >> things to work on, too. ;) But since I open my big mouth now, I > >> can't > >> very well leave you hanging, now can I? :D It also depends on how > >> complicated stuff we are talking... > > > > Very good of you. If you let me give a basic long template (perhaps > > "Investigation Site"). I can do both, get a fix, and work for an > > Emacs incorporation . > > > >> Actually, another option just occurred to me. I don't know where you > >> are sending results of the capture template, but if you are just > >> appending to file(s) perhaps you could break the one big template up > >> into some number of smaller ones? > > > > One problem with that is that new entries are appended in vertical > > (newline) > > and cannot put options in a table. > > How about post up your long template somewhere and we can have a look? > Maybe a paste site is better than the mailing list? If you want to do > that and are not aware of any good (non proprietary) one, I like and use > a lot https://bpaste.net/ (which redirects now to https://bpa.st/, > apparently). > > Maybe while I am at it I have a play about what might be required to get > some scrolling to work with the template. For all I know, it could be a > simple fix... That would be very good. Very appreciative. I am currently making a standalone example template to play with. > Others please feel free to jump in, too, maybe you know something I > don't (about scrolling, I mean). > > Cheers, > TRS-80 > >
Re: Org Capture Menu cannot be fully viewed
On 2020-12-12 18:30, pie...@caramail.com wrote: From: "TRS-80" Well, it's up to you. If you want we can pursue either option, or both (one potentially as a temporary workaround). Or we can wait for more list replies and see what others think. As I said there may also be a better way I am not aware of. If I'm being honest, I have plenty other things to work on, too. ;) But since I open my big mouth now, I can't very well leave you hanging, now can I? :D It also depends on how complicated stuff we are talking... Very good of you. If you let me give a basic long template (perhaps "Investigation Site"). I can do both, get a fix, and work for an Emacs incorporation . Actually, another option just occurred to me. I don't know where you are sending results of the capture template, but if you are just appending to file(s) perhaps you could break the one big template up into some number of smaller ones? One problem with that is that new entries are appended in vertical (newline) and cannot put options in a table. How about post up your long template somewhere and we can have a look? Maybe a paste site is better than the mailing list? If you want to do that and are not aware of any good (non proprietary) one, I like and use a lot https://bpaste.net/ (which redirects now to https://bpa.st/, apparently). Maybe while I am at it I have a play about what might be required to get some scrolling to work with the template. For all I know, it could be a simple fix... Others please feel free to jump in, too, maybe you know something I don't (about scrolling, I mean). Cheers, TRS-80
Re: [org-save-all-org-buffers] Saving is not reliable?
an undo-boundary bug can make something unexpected get undone as part of a batch or make an org operation require two undos. the agenda is one place where these bugs have existed. On 12/9/20, Eric S Fraga wrote: > On Wednesday, 9 Dec 2020 at 11:16, Mikhail Skorzhisnkii wrote: >> It's kind of reproduction scenario. Basically I need to >> modify buffer from search-type agenda. > > In the past, anecdotally I have seen something similar: adjust the > scheduled date for an entry via the agenda view and ask to save all org > buffers. The change to the scheduled date is sometimes forgotten. I > haven't tried with emacs -Q so it could, as in Mikhail's case, be > configuration dependent and it's also not entirely reproducible (i.e. it > sometimes happens, sometimes doesn't). > > But I've not seen this happen recently so maybe it was a bug along the > way. Sorry for vagueness but I thought I'd chime in just in case it > helps. > -- > : Eric S Fraga via Emacs 28.0.50, Org release_9.4-160-g7c8dce > > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: Org Capture Menu cannot be fully viewed
> Sent: Sunday, December 13, 2020 at 12:13 AM > From: "TRS-80" > To: emacs-orgmode@gnu.org > Subject: Re: Org Capture Menu cannot be fully viewed > > On 2020-12-12 17:46, pie...@caramail.com wrote: > >> From: "TRS-80" > > > > The problem also exists when making capture templates. The solution > > could be additional functionality coded in elisp that can then be used > > for handling longer template entries. As the problem is dependent on > > screen size, the problem is likely to occur, requiring the patch. It > > then becomes natural that the fix is introduced without the template > > developer having to call the fix explicitely. > > All true! > > > I assume it would involve some elisp and would be willing to word > > towards > > a solution. But it would be even better that the solution would be > > incorporated in the official version of emacs. > > What gets into Org / Emacs is up to maintainer(s?) and pending list > discussion. Which might take some time, but in many cases (I imagine > even including this one) is probably The Right Thing to do. That is understood. > If you can wait for that, it will end up improving Org and likely > helping a lot of people, including yourself (eventually). > > I guess some times I just prefer my own local "quick and dirty" solution > which can be "good enough" or a workaround pending a more proper > solution. Although, to be fair, the ability to maintain such solutions > (long term) is sort of dependent on knowing a bit of Elisp. So it's a > bit of a trade-off. > > I can send a long capture template. And any additional information > > people > > require. > > Well, it's up to you. If you want we can pursue either option, or both > (one potentially as a temporary workaround). Or we can wait for more > list replies and see what others think. As I said there may also be a > better way I am not aware of. If I'm being honest, I have plenty other > things to work on, too. ;) But since I open my big mouth now, I can't > very well leave you hanging, now can I? :D It also depends on how > complicated stuff we are talking... Very good of you. If you let me give a basic long template (perhaps "Investigation Site"). I can do both, get a fix, and work for an Emacs incorporation . > Actually, another option just occurred to me. I don't know where you > are sending results of the capture template, but if you are just > appending to file(s) perhaps you could break the one big template up > into some number of smaller ones? One problem with that is that new entries are appended in vertical (newline) and cannot put options in a table. > Cheers, > TRS-80 > >
Re: Org Capture Menu cannot be fully viewed
On 2020-12-12 17:46, pie...@caramail.com wrote: From: "TRS-80" The problem also exists when making capture templates. The solution could be additional functionality coded in elisp that can then be used for handling longer template entries. As the problem is dependent on screen size, the problem is likely to occur, requiring the patch. It then becomes natural that the fix is introduced without the template developer having to call the fix explicitely. All true! I assume it would involve some elisp and would be willing to word towards a solution. But it would be even better that the solution would be incorporated in the official version of emacs. What gets into Org / Emacs is up to maintainer(s?) and pending list discussion. Which might take some time, but in many cases (I imagine even including this one) is probably The Right Thing to do. If you can wait for that, it will end up improving Org and likely helping a lot of people, including yourself (eventually). I guess some times I just prefer my own local "quick and dirty" solution which can be "good enough" or a workaround pending a more proper solution. Although, to be fair, the ability to maintain such solutions (long term) is sort of dependent on knowing a bit of Elisp. So it's a bit of a trade-off. I can send a long capture template. And any additional information people require. Well, it's up to you. If you want we can pursue either option, or both (one potentially as a temporary workaround). Or we can wait for more list replies and see what others think. As I said there may also be a better way I am not aware of. If I'm being honest, I have plenty other things to work on, too. ;) But since I open my big mouth now, I can't very well leave you hanging, now can I? :D It also depends on how complicated stuff we are talking... Actually, another option just occurred to me. I don't know where you are sending results of the capture template, but if you are just appending to file(s) perhaps you could break the one big template up into some number of smaller ones? Cheers, TRS-80
Re: org-table change time from UTC to other timezones
Maxim Nikulin writes: > 2020-12-12 Alan E. Davis wrote: >> >> Thank for the clear explanation. My little problem seems to require a >> super steam hammer. Your insights are most helpful. > > In my opinion, org mode is too rigid in respect to timestamp format. > Sometimes I would prefer to specify timestamps with timezone. > > Well known example of idiosyncrasy of particular applications. > Timestamps in xls files are represented by floating point numbers, > namely days since 1 Jan 1900, fractional part is time. Unfortunately > 1900 is not a leap year, so to avoid unnecessary complications of code > and keep memory footprint small, on Macs epoch starts in 1904, on > windows year 1900 has Feb, 29... Although there are likely some dark corners where bugs can be found, I think you could probably add timezone data to org timestamps by changing the default format strings. Org also uses an 'internal' 'time' value to represent timestamps which are then converted to the required format using these format strings. What is possibly missing is an easy way to specify a time zone when creating a timestamp. I suspect it will default to whatever the local system tz is and I don't think there is any convenient way to change tz values like there is for the other timestamp components. -- Tim Cross
Re: stability of toc links
On 2020-12-12 16:51, TRS-80 wrote: "If we are not in MAJOR-MODE, exit with error." I noticed a small typo: - "If we are not in MAJOR-MODE, exit with error." + "If we are not in major MODE, exit with error." Cheers, TRS-80
Re: Org Capture Menu cannot be fully viewed
> Sent: Saturday, December 12, 2020 at 11:09 PM > From: "TRS-80" > To: emacs-orgmode@gnu.org > Subject: Re: Org Capture Menu cannot be fully viewed > > On 2020-12-12 13:02, pie...@caramail.com wrote: > > Dear All, > > > > When making a relatively long Org Capture Menu for Archaeological > > Field Management, the relevant capture window cannot be scrolled down. > > This becomes particularly problematic with small field laptops. > > Hi Pietru, > > Capture templates are great, but I suppose there are a lot of advantages > to doing some custom Elisp which is why I do a lot more stuff that way > now that I have learned a little bit of Elisp. The problem also exists when making capture templates. The solution could be additional functionality coded in elisp that can then be used for handling longer template entries. As the problem is dependent on screen size, the problem is likely to occur, requiring the patch. It then becomes natural that the fix is introduced without the template developer having to call the fix explicitely. > Sorry, I guess that's not helpful if you are not comfortable with Elisp. > As an aside and thinking long term, I can say the investment was well > worth the payoff. However back to the issue at hand. I assume it would involve some elisp and would be willing to word towards a solution. But it would be even better that the solution would be incorporated in the official version of emacs. > Maybe if you are willing (or able) to share some more information, we > could help you through some basics. Or maybe someone else might even > have some better idea (not involving Elisp) which might be more > appealing to you. I can send a long capture template. And any additional information people require. > Cheers, > TRS-80 > >
Re: Org Capture Menu cannot be fully viewed
On 2020-12-12 13:02, pie...@caramail.com wrote: Dear All, When making a relatively long Org Capture Menu for Archaeological Field Management, the relevant capture window cannot be scrolled down. This becomes particularly problematic with small field laptops. Hi Pietru, Capture templates are great, but I suppose there are a lot of advantages to doing some custom Elisp which is why I do a lot more stuff that way now that I have learned a little bit of Elisp. Sorry, I guess that's not helpful if you are not comfortable with Elisp. As an aside and thinking long term, I can say the investment was well worth the payoff. However back to the issue at hand. Maybe if you are willing (or able) to share some more information, we could help you through some basics. Or maybe someone else might even have some better idea (not involving Elisp) which might be more appealing to you. Cheers, TRS-80
Re: stability of toc links
On 2020-12-08 20:39, Tom Gillespie wrote:
It sounds like you are looking for the CUSTOM_ID property. See
https://orgmode.org/manual/Handling-Links.html and
https://orgmode.org/manual/Internal-Links.html. I don't remember
whether there is a way to generate ids matching headlines within org
itself, but there is
https://github.com/alphapapa/unpackaged.el#export-to-html-with-useful-anchors.
Best!
Tom
I had set out to shave this particular yak just yesterday I think it
was. I know I came across alphapapa's solution and maybe TEC's too, but
they were more complex than I could seem to get my feeble brain around
at the time.
Also, I was going for more of a deterministic result, trying to end up
with something like a Markdown style link id. This coming up in the
course of my larger mission towards better support for exporting
README.org to Markdown (and ultimately, nicely rendered HTML) files over
at Sourcehut[0].
Finally, this operates by a totally different way than replacing some
part of Org export function(s). My approach was simply to dynamically
assign a CUSTOM_ID property to every heading in current buffer (that did
not have one already) which would be generated according to some
deterministic method. With the idea to then go on after that and do
whatever regular Org export you want.
Right off the bat I will say this is a very, VERY immature
implementation (literally yesterday). And I have only done the very
lightest of testing (however it does basically work). Therefore this is
not for consideration for inclusion into Orgmode but rather just my own
workaround in the meantime. At best I might hope to add something
useful to the ongoing discussion (or perhaps become enlightened why this
is completely wrong approach). ;)
I would like to point out the following problems which I have not (yet)
addressed in the following functions (#1 being most glaring probably) as
they are still too new:
1. The punctuation removal regexp needs to have many more characters
added (currently only containing {!.'}). In fact, this strikes me as a
bit hacky, I am not even sure it's the best approach.
2. This function operates only on the current buffer.
3. Many things still need to be parameterized, in particular the TODO
state is hard coded to be included in the generated id and already I am
starting to think that's a bad idea (but it depends on context I
suppose, hence thinking to make it an option).
4. If I am trying to emulate Markdown (or any other spec) I really
should study and more properly and fully implement said spec. I have
done /absolutely no such thing/ so far, only a (quite off the cuff)
"Markdown like" implementation.
5. Naming the function beginning with `my-ox-' is not meant that this
should be included in ox- package necessarily but rather that I am
associating it with exporting from Org within my own mind and personal
init files.
My plan (before stumbling across this thread ;) ) was to continue to use
and polish these functions (privately) and eventually publish them on my
(relatively new) sr.ht profile[1]. But since this came up, I guess I
will go ahead and put it out there for feedback here on the mailing
list. I still plan to eventually publish somewhere more properly with
license, where patches can be accepted, etc... However in the
meantime...
With the above disclaimers out of the way, I present the following
function (and another simple one it depends on) in the hope they are
useful to someone.
[0] https://sourcehut.org
[1] https://sr.ht/~trs-80/
#+begin_src emacs-lisp
(defun my-major-mode-insure (mode)
"If we are not in MAJOR-MODE, exit with error."
(unless (string= major-mode mode)
(user-error "Buffer not in %s, exiting" mode)))
(defun my-ox-assign-custom-ids ()
"Assign reliable CUSTOM_ID to each heading in current buffer.
CUSTOM_ID will only be assigned if one does not exist already.
The generated CUSTOM_ID roughly[0] follows (my very basic and
limited understanding of) the Markdown spec. In other words, it
will be generated by taking the heading text plus TODO state (so
as not to break link) and:
1. Lower case it.
2. Remove all punctuation.[1]
3. Replace spaces with hyphens.
[0] Currently, likely VERY roughly...
[1] Currently this is a bit hacky `replace-regexp-in-string'
featuring only a few common punctuation (right now only
exclamation point, period, apostrophe (i.e., single quote). Much
more will need to be added here, in fact I am not even sure this
is the best approach."
(interactive)
(my-major-mode-insure 'org-mode)
(org-map-entries '(org-set-property
"CUSTOM_ID"
;; replace space with hyphen
(replace-regexp-in-string
" " "-"
;; remove punctuation
(replace-regexp-in-string
"\\\!\\|\\\.\\|'" ""
(downcase
(substring-no-properties
Bug: html export fails after upgrading to 9.4 [9.4.1 (9.4.1-elpa @ /Users/jb/Library/Preferences/Aquamacs Emacs/Packages/elpa/org-20201212/)]
Hi!
Trying to export a buffer to html containing
#+TITLE: Titel
* header
yields the error message:
apply: Wrong type argument: listp, #("Titel" 0 5 (:parent (#0)))
What can I do?
Johannes
Emacs : Aquamacs 3.5nightly GNU Emacs 25.3.50.1 (x86_64-apple-darwin19.6.0,
NS appkit-1894.60 Version 10.15.7 (Build 19H2))
dated 2020-12-12 rev. 29cda0694004ad1fc615be7b1553fe7b9bb884ca
Package: Org mode version 9.4.1 (9.4.1-elpa @
/Users/jb/Library/Preferences/Aquamacs Emacs/Packages/elpa/org-20201212/)
current state:
==
(setq
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-shiftleft-final-hook '(windmove-left)
org-latex-default-packages-alist '(("AUTO" "inputenc" t ("pdflatex")) ("T1"
"fontenc" t ("pdflatex")) ("" "graphicx" t nil)
("" "grffile" t nil) ("" "longtable" nil
nil) ("" "wrapfig" nil nil) ("" "rotating" nil nil)
("normalem" "ulem" t nil) ("" "amsmath" t
nil) ("" "textcomp" t nil) ("" "amssymb" t nil)
("" "capt-of" nil nil) ("greek, ngerman"
"babel" t nil) ("" "hyperref" nil nil))
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-clock-display-default-range 'untilnow
org-re-reveal-revealjs-version "4"
org-occur-hook '(org-first-headline-recenter)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-html-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
org-latex-format-inlinetask-function
'org-latex-format-inlinetask-default-function
org-confirm-shell-link-function 'yes-or-no-p
org-image-actual-width nil
org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
org-agenda-loop-over-headlines-in-active-region nil
org-latex-pdf-process '("pdflatex -shell-escape -interaction nonstopmode
-output-directory %o %f" "%bibtex %b"
"pdflatex -shell-escape -interaction nonstopmode
-output-directory %o %f"
"pdflatex -shell-escape -interaction nonstopmode
-output-directory %o %f")
org-babel-clojure-backend 'cider
org-file-apps '((auto-mode . emacs) ("\\.mm\\'" . default) ("\\.x?html?\\'" .
default) ("\\.pdf\\'" . "open -a /Applications/Skim.app %s"))
org-list-allow-alphabetical t
org-support-shift-select t
org-latex-format-headline-function 'org-latex-format-headline-default-function
org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
org-odt-format-headline-function 'org-odt-format-headline-default-function
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-babel-pre-tangle-hook '(save-buffer)
org-mode-hook '(org-clock-load #[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-show-all append local] 5]
#[0 "\301\211\207" [imenu-create-index-function
org-imenu-get-tree] 2]
#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-babel-show-result-all append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes)
org-bibtex-headline-format-function '(closure (org-id-locations
org-agenda-search-view-always-boolean org-agenda-overriding-header t) (entry)
(cdr (assq :title entry)))
org-archive-hook '(org-attach-archive-delete-maybe)
org-ascii-format-drawer-function #[771 "\207" [] 4 "\n\n(fn NAME CONTENTS
WIDTH)"]
org-odt-format-inlinetask-function 'org-odt-format-inlinetask-default-function
org-clock-persist 'history
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-shiftup-final-hook '(windmove-up)
org-link-shell-confirm-function 'yes-or-no-p
org-export-before-parsing-hook '(org-attach-expand-links)
org-html-mathjax-options '((path
"https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS_HTML;) (scale
"100") (align "center")
(font "TeX") (linebreaks "false") (autonumber
"AMS") (indent "0em") (multlinewidth "85%") (tagindent ".8em")
(tagside "right"))
org-export-with-drawers '(not "LOGBOOK DRAWERNAME")
org-link-elisp-confirm-function 'yes-or-no-p
org-latex-packages-alist '(("" "minte
Re: New startup options, showlevels
Hi Bastien, Thanks for the feedback. Regarding naming, there may ofc be other possibilities. I considered spelling the level out but discarded that option due to its verbosity. I find this quite elegant actually. One might argue that it's not general enough, with 2 to 5 hard-coded. But thinking of the use-case a bit more, I struggled to find a reason for more dynamics. I don't object to the mailing list RFC method of doing things, but in this case it felt like a too small contribution for that trouble. Had there been a more streamlined pull-request workflow than the list I'm sure I'd have taken another decision. In this case the option was to just not do it due to time and energy constraints. Nitpick noted, I'll try to care better with ending sentences moving forward! Best Gustav From: Bastien Sent: Saturday, December 12, 2020 6:54:21 PM To: Gustav Wikström Cc: emacs-orgmode@gnu.org Subject: Re: New startup options, showlevels Hi Gustav, Gustav Wikström writes: > Prompted by a question on StackOverflow, > https://stackoverflow.com/questions/56536184/set-initial-visiblity-to-a-certain-level-in-org-mode, > a few new options are added to the startup setting. thanks -- in the future, I suggest discussing such additions on this list before committing them. In this case, I think we could come up with better option names than "show2levels", even if I don't have a better suggestion right now. > Patch is applied to master as this is non-critical and it is > communicated here and now for full transparency. See commit hash > a71ac14e4, > https://code.orgmode.org/bzg/org-mode/commit/a71ac14e46bb820abdbd2e6651c58179c50eb2fa Mandatory nitpick: the log should contain proper sentences, ending with a dot. I'm mentioning this because your other commit has the same small error. > Hope these new options will be usable for some of you! It sure is, thanks for taking care of this, -- Bastien
org-capture user-error: Abort
Emacs fires "user-error: Abort" after pressing "q" to abort org-capture.
Re: org-table change time from UTC to other timezones
2020-12-12 Alan E. Davis wrote: Thank for the clear explanation. My little problem seems to require a super steam hammer. Your insights are most helpful. You do not need a steam hammer. There are a number of tools around. Some of hammers however could not deal with all nails. Even "date" util could be used to convert between timestamps and human readable representation, between timezones. It could even do some arithmetic date --utc -d @1234567890 Fri Feb 13 23:31:30 UTC 2009 date -d 'now' +%s 1607787784 date -d 'now +10hours' +%s 1607823786 TZ=America/New_York date -d "@`TZ=Europe/Berlin date -d '2020-11-10 09:08:07 +10hours' '+%s'`" Mon Nov 9 19:08:07 EST 2020 In my opinion, org mode is too rigid in respect to timestamp format. Sometimes I would prefer to specify timestamps with timezone. Well known example of idiosyncrasy of particular applications. Timestamps in xls files are represented by floating point numbers, namely days since 1 Jan 1900, fractional part is time. Unfortunately 1900 is not a leap year, so to avoid unnecessary complications of code and keep memory footprint small, on Macs epoch starts in 1904, on windows year 1900 has Feb, 29...
org-mode Publishing fails xhtml validation and LibreJS test.
Hello, When publishing, org-mode inserts the following javascript in the xhtml file: #+begin_src js // @license magnet:?xt=urn:btih:e95b018ef3580986a04669f1b5879592219e2a7a&dn=public-domain.txt Public Domain // @license-end #+end_src There are issues with this script. 1. The script gives errors in XHTML 1.0 Strict validation. For example, the line beginning //@license ... gives errors of the type: a. cannot generate system identifier for general entity "dn" b. general entity "dn" not defined and no default entity c. reference not terminated by REFC delimiter etc. 2. The script fails the LibreJS (gnu.org/software/librejs) tests. This can be tested by opining the page in icecat. In order to pass XHTML and LibreJS validation tests, I have to delete the script from my web pages by hand. Best wishes, Colin Baxter. Colin Baxter URL: http://www.Colin-Baxter.com - GnuPG fingerprint: 68A8 799C 0230 16E7 BF68 2A27 BBFA 2492 91F5 41C8 -
Re: Bug fix attached: org-babel sql postgres, fix hardcode
Sorry, I don't understand. That's what I did. The patch was attached to my email. On Sat, Dec 12, 2020 at 1:32 PM Bastien wrote: > Hi Alan, > > Alan Light writes: > > > ob-sql.el does not respect the value of sql-postgres-program, thus > > causing problem when running on Windows, etc. > > Patch attached. > > Thanks. Can someone confirm the patch is good? > > Alan, can you check how to submit a patch with a changelog on this > page: https://orgmode.org/worg/org-contribute.html and resubmit it? > > Best, > > -- > Bastien >
Re: [PATCH][9.4] Mention org-adapt-indentation as escape hatch in ORG-NEWS
Hi Kévin, Kévin Le Gouguec writes: > If it's not too late for this to make it into 27.2, I think this could > make dealing with the electric-indent-mode kerfuffle easier for > unsuspecting users. Applied, thanks, -- Bastien
Re: Bug: org-capture does not work if called from minibuffer [9.4 (9.4-55-g706ba9-elpaplus @ /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20201207/)]
Hi Omar, thanks for reporting this. Omar Antolín Camarena writes: > I have enable-recursive-minibuffers set to t, and just noticed that > org-capture does not work if called from the minibuffer. > > Steps to reproduce: > > 1. run emacs -Q > 2. evaluate (setq enable-recursive-minibuffers t) in the scratch buffer > 3. Open the minibuffer, say by using C-x C-f > 4. While still in find-file, run M-x org-capture and pick a template (t for > Task seems to be offered by default). > > You should get an error message saying "Can't expand minibuffer to > full frame". Would you be okay with a user-error message like "Cannot call org-capture from the minibuffer" ? -- Bastien
Re: [PATCH] ob-C.el: Fix a number a bugs related to table parameters
Hi Asa, Asa Zeren writes: > Here are a number of fixes to ob-C.el. There is still probably a bunch > of general cleanup to do in this file, but these changes make it work > for me. thanks for the patch. I'm copying Thierry as the (new) maintainer for ob-C.el. -- Bastien
Org Capture Menu cannot be fully viewed
Dear All, When making a relatively long Org Capture Menu for Archaeological Field Management, the relevant capture window cannot be scrolled down. This becomes particularly problematic with small field laptops. Regards Pietru Pietru Caxaro Director General - Subsurface Imaging Archaeological Superintendency of Rome
Re: New startup options, showlevels
Hi Gustav, Gustav Wikström writes: > Prompted by a question on StackOverflow, > https://stackoverflow.com/questions/56536184/set-initial-visiblity-to-a-certain-level-in-org-mode, > a few new options are added to the startup setting. thanks -- in the future, I suggest discussing such additions on this list before committing them. In this case, I think we could come up with better option names than "show2levels", even if I don't have a better suggestion right now. > Patch is applied to master as this is non-critical and it is > communicated here and now for full transparency. See commit hash > a71ac14e4, > https://code.orgmode.org/bzg/org-mode/commit/a71ac14e46bb820abdbd2e6651c58179c50eb2fa Mandatory nitpick: the log should contain proper sentences, ending with a dot. I'm mentioning this because your other commit has the same small error. > Hope these new options will be usable for some of you! It sure is, thanks for taking care of this, -- Bastien
Re: Bug fix attached: org-babel sql postgres, fix hardcode
Hi Alan, Alan Light writes: > ob-sql.el does not respect the value of sql-postgres-program, thus > causing problem when running on Windows, etc. > Patch attached. Thanks. Can someone confirm the patch is good? Alan, can you check how to submit a patch with a changelog on this page: https://orgmode.org/worg/org-contribute.html and resubmit it? Best, -- Bastien
Re: updates website broken
Bastien writes: > Fixed, thanks! FWIW I'm now monitoring whether https://updates.orgmode.org is up. -- Bastien
