emacs and scheme talk to each other https://jao.io/cgit/geiser/atom?h=0.33 2024-07-06T15:37:23Z 2024-07-06T15:37:23Z Jonas Bernoulli jonas@bernoul.li 2022-08-12T13:07:18Z urn:sha1:f74612686b468069849ab36d1c49229312f3434e `geiser-doc--xbutton' will be tackled in the next commit. 2024-07-06T15:37:23Z Jonas Bernoulli jonas@bernoul.li 2022-07-14T12:33:38Z urn:sha1:de52f0e36f1709181c1ce4e787d79208fa2cb870 - In the summary line, use three dashes to separate the file name from the summary. That is the convention, which some tools depend on, and for some libraries we already did it here too. - Capitalize the first word in the summary. That is the convention, and for some libraries we already did it here too. - For libraries that have a commentary, make sure it is placed in a "Commentary:" section. - Make sure the "Code:" heading, which separates the header from the code part of the library, exists in all files. 2023-12-15T21:33:58Z Jonas Bernoulli jonas@bernoul.li 2023-12-15T21:29:45Z urn:sha1:b20dd4d77b92197d88d7cf3512fe202581d5c430 Emacs 30.0.50 has started to warn when this variable isn't set, presumably so that the default can be changed from nil to t in a few years. I see no reason not to use lexical-binding. 2020-12-02T19:28:40Z Jonas Bernoulli jonas@bernoul.li 2020-10-02T13:08:00Z urn:sha1:5d8a721c48e5d839ed69c3cac7f2cf65c6998627 The whole first sentence should fit on the first line. If that makes the line a bit long then that is unfortunate but better than wrapping it onto a new line. When wrapping onto a new line anyway then the second line should never be intended. When it can be avoided, then long first lines should be made shorter. 2020-03-27T20:38:45Z Jonas Bernoulli jonas@bernoul.li 2020-02-25T13:32:18Z urn:sha1:3ceb31b71824e59e3f000edf7cb09ab86616d723 It's the convention and by following it we make a big step towards supporting outline navigation. The convention doesn't say much about what parts of the code are supposed to be part of that sections and what parts belong in a subsequent section. Here we put the `require' forms in this section and maybe some setup code, that's a popular approach. In most cases there was "" where we now insert "Code:". They both serve a similar purpose and we keep the former because some users depend on that for navigation. We even add this "" in libraries where it previously was missing. In some cases the permission statement was followed by a commentary, which obviously does not belong in the "Code:" section. In such cases add the conventional "Commentary:" section. 2020-03-27T20:38:45Z Jonas Bernoulli jonas@bernoul.li 2020-02-25T13:29:01Z urn:sha1:715f4c0ee0f50b251679e55650cedcae3a246b57 It's the convention and by following it we make a big step towards supporting outline navigation. 2015-01-19T01:46:00Z Jose Antonio Ortega Ruiz jao@gnu.org 2015-01-19T01:46:00Z urn:sha1:286bc6c6144d88b1ee19e7a2f10b8b10b421e15e Image cache cleaning was being performed during comint output filtering and, since that can happen in batches, if the total output had more images than the maximum cache size, some of them would be gone (in fact it was even worse: we were cleaning the cache after each image display). Now we just perform cache maintenance before sending the input, and avoid paying a price for non-rackets by making the cache dir setting implementation-specific. 2012-12-10T22:26:31Z Jose Antonio Ortega Ruiz jao@gnu.org 2012-12-10T22:26:31Z urn:sha1:e896e08cfabd87d1a2d2e06c178bf47c41aaa85d We were not taking into account windows paths, with their backslashes and colons. 2012-09-02T20:34:33Z Jose Antonio Ortega Ruiz jao@gnu.org 2012-09-02T20:34:33Z urn:sha1:52dc30c7e6277e950fa3fab89030a258be0cfd9a 2012-09-02T18:56:22Z Jose Antonio Ortega Ruiz jao@gnu.org 2012-09-02T18:56:22Z urn:sha1:0c301d52faa33423cd27b64638667bbe338e5fbb Images rendered via put-image won't be deleted by erase-buffer (they're overlays), while those inserted by insert-image (text properties) will.