Re: http: links in the manual
Max Nikulin writes: > One may got no response trying to fix a link. > > Max Nikulin to emacs-orgmode. [PATCH] org-manual.org: Update links to > MathJax docs. Sun, 3 Oct 2021 23:17:46 +0700. > https://list.orgmode.org/sjcl3b$gsr$1...@ciao.gmane.io > > In the particular case of docs.mathjax.org I am unsure if mild > preference of http: over https: is not a mistake in the server > configuration. I do not mind "https:" there, any variant is better > than the old broken link. Maybe, instead of repairing the links manually, we could think of some code that would do this work periodically, and also check the health of the links, running a url request on each link and returning a list of broken links. I don't know if it is possible to do something like that in Elisp, as I don't have much experience with web and link issues. I think there are also external tools, like Selenium Web Driver, but my experience with it is very limited (I use Selenium from time to time when I want to take a screenshot of a web page). Best regards, Juan Manuel
Re: [Feature Request] Create an org-md-toplevel-hlevel variable to allow users to set the level of top level headings in markdown export
> This contribution will be welcome. I've attached a patch which implements the change. I followed the pattern that ox-html uses to the greatest extent possible. I tested it by exporting org-mode files to markdown with the table of contents both enabled and disabled. I didn't see any errors, and I was able to make the top level heading a level 2 (or even level 3) heading rather than level 1. Thanks, Rohit 0001-Added-top-level-header-setting-for-md-export.patch Description: Binary data
Re: [PATCH v3] Show org file title in org-clock clocktable
> Thanks for the update! > Applied onto main via 2cc2d8f1f with amendments. > I fixed on double space " " between sentences, removed autoload cookie > (that function is not used outside org-clock), and altered the docstring > making the first line a single sentence and clarifying about the return > value a bit. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=2cc2d8f1f6265d12c92b734931f2e3e417276b05 Thank you so much for your guidance throughout this patch, hopefully I will be able to contribute to better patches myself in the future! Duy
Re: [Feature Request] Create an org-md-toplevel-hlevel variable to allow users to set the level of top level headings in markdown export
On 21/08/2022 18:07, Rohit Patnaik wrote: I've attached a patch which implements the change. Thank you for the patch. @@ -229,9 +242,10 @@ When optional argument SCOPE is non-nil, build a table of contents according to the specified element." (concat (unless scope - (let ((style (plist-get info :md-headline-style)) + (let ((level (plist-get info :md-toplevel-hlevel)) + (style (plist-get info :md-headline-style)) Since md backend is derived from html, is it necessary to define an option specific to markdown or the value defined for HTML may be reused? I am unsure which variant will be more convenient, so it is not more than an idea that may be easily discarded.
Re: [PATCH v2] ol-info: Define :insert-description function
On 20/08/2022 14:29, Ihor Radchenko wrote:
Max Nikulin writes:
On 19/08/2022 11:28, Ihor Radchenko wrote:
Max Nikulin writes:
+(defun org-info--link-file-node (path)
+ "Extract file name and node from info link PATH.
+
+Return cons consisting of file name and node name or \"Top\" if node
+part is not specified. Components may be separated by \":\" or by \"#\"."
It looks like the docstring does not match what the function actually
returns.
It returns a cons, doesn't it? Is it confusing that separator for
components is related to the argument?
It is confusing that cons consist of _file name_ and node name.
However, the function may return non-file as car of the cons.
"dir" should not appear in well-formed links . If a user
adds "info:" links then it is unlikely that their has never used info
and has never seen directory index. Moreover I do not see real problem
since it is considered as a virtual info file:
https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/info.el#n2344
(add-to-list 'Info-virtual-files
'("\\`dir\\'" ; ...
After all, it is an internal function and I am still unsure that I have
chosen the best variant. I believed that underspecified behavior here
may give less harm than making some 3rd party code relying on the
proposed variant.
I can drop "(dir)" special case to consider incomplete links as invalid
ones. The only problem is test cases for escaping of various characters
since they use links without file name as the input, but they may be
easily adjusted by adding some file name.
There is huge room for improvements in "ol-info.el", e.g. other virtual
files such as "(*History*)" may signal an error during HTML export.
Fwd: Re: [Feature Request] Create an org-md-toplevel-hlevel variable to allow users to set the level of top level headings in markdown export
> Since md backend is derived from html, is it necessary to define an > option specific to markdown or the value defined for HTML may be reused? > I am unsure which variant will be more convenient, so it is not more > than an idea that may be easily discarded. I considered reusing the value from the HTML exporter, but I rejected it, because the org-html-toplevel-hlevel defaults to 2. Reusing it would alter the existing default behavior for markdown exports, which I thought was undesirable. If you think it's okay to alter the existing behavior of Markdown exports, I could change the code to use org-html-toplevel-hlevel to control the top level heading level of both HTML and markdown exports. Thanks, Rohit
Re: Suspected bug: '#+STARTUP: indent' messes up inlinetasks' tag alignment
Ihor Radchenko writes on Sat 20 Aug 2022 15:20: > I have tested the patch on emacs-27.2, and it works just fine. Can > you please check again using the newest development version of Org? Indeed, now it works for me too. Thanks. > > I noticed that the section of the manual > > > >* Feedback:: Bug reports, ideas, patches, etc. > > > > does not even contain the word 'patch'. So I was thinking it might be > > a good idea to say a few words in that section about what patches are > > and how to apply them. > > Applying patches is out of scope of the manual. Fair enough, but in that case shouldn't the word "patches" be removed from "Bug reports, ideas, patches, etc."? > Next time, you can just ask to provide an alternative way of testing. I > can then just upload the patched version to an alternative repository. Well, I was trying to save you some time so that you can spend it on more constructive actions. I succeeded, and learned things in the process -- patching (at least basic concepts and actions) is relatively simple, so I think it could easily be _within_ the scope of the manual. Regards -- EOST (École et Observatoire des Sciences de la Terre) ITE (Institut Terre & Environnement) | alain.coch...@unistra.fr 5 rue René Descartes [bureau 106] | Phone: +33 (0)3 68 85 50 44 F-67084 Strasbourg Cedex, France | [ slot available for rent ]
Re: [PATCH] org-manual.org: Update links to MathJax docs
Max Nikulin writes: >> It is not erring on my side. Maybe they changed something since last year? > > curl -I https://docs.mathjax.org/ > ^^ > HTTP/2 302 > date: Sun, 21 Aug 2022 06:16:52 GMT > content-type: text/html; charset=utf-8 > content-length: 0 > location: http://docs.mathjax.org/en/latest/ >^ Hmm. I actually missed that 302 it is not actual error. Applied onto main via 8d93f9b6b. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=8d93f9b6b4e15427d62b84013ee726a0e6760ad9 Feel free to bump any other patch you that did not get a response. While I did track the new patches recently, the ones introduced more than a few months ago and those not being tracked at updates.orgmode.org have likely slipped through the cracks. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Auto-checking dead links in the manual (was: http: links in the manual)
Juan Manuel Macías writes: >> Max Nikulin to emacs-orgmode. [PATCH] org-manual.org: Update links to >> MathJax docs. Sun, 3 Oct 2021 23:17:46 +0700. >> https://list.orgmode.org/sjcl3b$gsr$1...@ciao.gmane.io >> >> In the particular case of docs.mathjax.org I am unsure if mild >> preference of http: over https: is not a mistake in the server >> configuration. I do not mind "https:" there, any variant is better >> than the old broken link. > > Maybe, instead of repairing the links manually, we could think of some > code that would do this work periodically, and also check the health of > the links, running a url request on each link and returning a list of > broken links. I don't know if it is possible to do something like that > in Elisp, as I don't have much experience with web and link issues. I > think there are also external tools, like Selenium Web Driver, but my > experience with it is very limited (I use Selenium from time to time > when I want to take a screenshot of a web page). This is a good idea. Selenium is probably an overkill since we should better not link JS-only websites from the manual anyway. What we can do instead is a make target that will use something like wget. Patches are welcome! -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: [Feature Request] Create an org-md-toplevel-hlevel variable to allow users to set the level of top level headings in markdown export
"Rohit Patnaik" writes: >> This contribution will be welcome. > > I've attached a patch which implements the change. I followed the pattern that > ox-html uses to the greatest extent possible. I tested it by exporting > org-mode > files to markdown with the table of contents both enabled and disabled. I > didn't see any errors, and I was able to make the top level heading a level 2 > (or even level 3) heading rather than level 1. Thanks for your contribution! Please also add the NEWS entry and an item to "14.1.5 Options for the exporters" section of the manual. > Subject: [PATCH] Added top level header setting for md export > > This commit adds a customization, org-md-toplevel-hlevel, which sets the > heading level of top-level headings in the exported markdown. This makes > markdown export behave more like HTML export, which reads > org-html-toplevel-hlevel to decide what the top level heading for HTML > export should be. Please follow the changelog style as described in https://orgmode.org/worg/org-contribute.html#commit-messages > +(defcustom org-md-toplevel-hlevel 1 > + "The markdown heading level to use for level 1 headings in markdown export. > +If this is 1, the top level headings will be level 1 markdown headings. If > this > +is 2, then top level headings will be level 2 markdown headings. By default > +this is 1, so that org-mode headings correspond to the same level markdown > +headings. Incrementing this value may be helpful creating markdown for > +inclusion in another document or application that reserves top-level headings > +for its own use." > + :group 'org-export-md > + :type 'string) Please follow the recommended documentation style: double space between sentences, 80 chars fill. See "D.6 Tips for Documentation Strings" section of Elisp manual. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: [PATCH v2] ol-info: Define :insert-description function
Max Nikulin writes:
>>> It returns a cons, doesn't it? Is it confusing that separator for
>>> components is related to the argument?
>>
>> It is confusing that cons consist of _file name_ and node name.
>> However, the function may return non-file as car of the cons.
>
> "dir" should not appear in well-formed links . If a user
> adds "info:" links then it is unlikely that their has never used info
> and has never seen directory index. Moreover I do not see real problem
> since it is considered as a virtual info file:
>
> https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/info.el#n2344
> (add-to-list 'Info-virtual-files
>'("\\`dir\\'" ; ...
I do not see ("dir" . "etc") as a problematic return value.
The only issue is that docstring is a bit confusing.
Maybe, in addition to "Return cons consisting of file name and node name",
you can put something like "File name may also be a virtual file name
(see `Info-virtual-files')."
> After all, it is an internal function and I am still unsure that I have
> chosen the best variant. I believed that underspecified behavior here
> may give less harm than making some 3rd party code relying on the
> proposed variant.
>
> I can drop "(dir)" special case to consider incomplete links as invalid
> ones. The only problem is test cases for escaping of various characters
> since they use links without file name as the input, but they may be
> easily adjusted by adding some file name.
I am ok with current behavior. It is only the docstring that I find
slightly confusing.
> There is huge room for improvements in "ol-info.el", e.g. other virtual
> files such as "(*History*)" may signal an error during HTML export.
May you open a separate bug report about this?
--
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92
