Re: [BUG] Prefer lowercase #+results [9.5.2 (release_9.5.2-3-geb9f34 @ /Users/salutis/src/emacs/nextstep/Emacs.app/Contents/Resources/lisp/org/)]
On 2022-01-09 06:21 PM, Rudolf Adamkovič wrote: Thank you for providing me with such a clear explanation! To make my point clear, I do not care about whether Org uses upper case or lower case keywords, but I do care about consistency. Specifically, I think Emacs should not make new users fiddle with variables just to make its behavior internally consistent. Thus, while I do understand both the "lowercase religion" and the "uppercase religion", I do not understand the "inconsistency religion". Rudy Consider Emerson's quote: "A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines. With consistency a great soul has simply nothing to do." ;-) -gyro
Re: [PATCH] Treat :tangle-mode as an octal value not integer
On 2021-09-29 10:22 AM, to...@tuxteam.de wrote: On Wed, Sep 29, 2021 at 09:52:23AM +0200, dkrm wrote: Jeremy Cowgar writes: [...] Are you suggesting this currently works or that the patch should be changed to make that work? A quick try on my local system (pre-patch), I receive the error: Wrong type argument: fixnump, "#o660" You have to use the `identity` function for it to works: :tangle-mode (identity #o660) Not the original poster, but I'd understand if they think this is "too roundabout" to just express a file mode. I think #o would have been acceptable, but changing that now might break a lot of stuff out there (every param beginning with `#o'? OTOH, adding special rules for params seems at least as dangerous. Are there better ideas? Cheers - t I don't know if it would ever be ambiguous, but could :tangle-mode have the ability to infer if it were integer- or octal-format based on checking against 'reasonable' permission settings in octal notation? Kind regards, gyro
Re: Microsoft Excel getting features we have had for a long time in org :-)
In one of the simulation classes I teach, I try to convey the same message. :-) In a past life, I had to extend applications that used Excel as a front-end with a combination of interlinked functions in spreadsheet cells plus plenty of Visual Basic with a few compiled dlls rolled into the mix. The dlls (which I wrote in fortran) were the only components for which I had any confidence. Fun times! ;-) -gyro On 1/31/2021 11:17 AM, Eric S Fraga wrote: > On Friday, 29 Jan 2021 at 13:36, gyro funch wrote: >> Oooh. That should make Excel spreadsheets even funner to audit. > :-) > > I actually tell (warn?) my students that spreadsheets are an example of > a "write-only programming language", the other being APL (for those with > long memories). >
Re: Microsoft Excel getting features we have had for a long time in org :-)
On 1/28/2021 4:01 AM, Eric S Fraga wrote: > Interesting: > https://www.microsoft.com/en-us/research/blog/lambda-the-ultimatae-excel-worksheet-function/ > > (somebody doesn't know how to spell ultimate?) > > I still would rather work with text than in a GUI and in Lisp than > Excel's language (whatever that may actually be) but good to see. > Oooh. That should make Excel spreadsheets even funner to audit. -gyro
Re[2]: set source directory for org-attach
Thank you, Ihor. That is very helpful. Kind regards, gyro -- Original Message -- From: "Ihor Radchenko" To: "gyro funch" ; emacs-orgmode@gnu.org Sent: 11/29/2020 6:21:27 PM Subject: Re: set source directory for org-attach gyro funch writes: I am probably missing something obvious, but is there a way to set the default source directory for attachments? Not by default. I am using the following advice (requires helm and f.el): (defvar yant/org-attach-default-source "~/Downloads/" "Default directory to attach the files from.") (define-advice org-attach-attach (:around (oldfun files args) start-from-default-directory) "Look for new attachments from `yant/org-attach-default-source' directory instead of `default-directory'." (interactive (list (mapcar #'directory-file-name (helm-read-file-name "File to keep as an attachment:" :initial-input (or (progn (require 'dired-aux) (dired-dwim-target-directory)) (and yant/org-attach-default-source (f-slash yant/org-attach-default-source)) default-directory) :marked-candidates t)) current-prefix-arg nil)) (unless (listp files) (setq files (list files))) (mapc (lambda (file) (apply oldfun file args)) files)) Best, Ihor
Re[2]: bug#44935: Emacs inserts hardwired org-agenda-files variable, overwriting user options
Sent: Sunday, November 29, 2020 at 10:20 PM From: "Kyle Meyer" To: daniela-s...@gmx.it Cc: "gyro funch" , emacs-orgmode@gnu.org Subject: Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, overwriting user options daniela-s...@gmx.it writes: >> From: "gyro funch" [...] >> If I'm not mistaken, all of the development is done by volunteers. >> >> Perhaps you could help resolve your issue instead of asking other >> people, who are likely already overworked, to shoulder the burden. > > Is there a mailing list for abuse? If I want abuse I shall ask for it. > Loser! I don't see anything that gyro said as abuse. Name calling, on the other hand, has no place on this list. One asks for help, and people tell you to go fix it yourself. If there is any disrespect, you bring it upon yourselves. And now you start. Another Gnu Goon. I have found that people on this list are extremely friendly, courteous, and helpful. I suggest that you look back at the way you asked for/demanded help and the various responses you gave in this thread. Taking on an attitude of entitlement and showing a lack of respect for others, their perspectives, and efforts may not be the best way to get help.
Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, overwriting user options
On 11/29/2020 11:08 AM, daniela-s...@gmx.it wrote: > > >> Sent: Sunday, November 29, 2020 at 6:22 PM >> From: "Jean Louis" >> To: daniela-s...@gmx.it >> Cc: "Eli Zaretskii" , 44...@debbugs.gnu.org >> Subject: Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, >> overwriting user options >> >> * daniela-s...@gmx.it [2020-11-29 20:02]: >>> Correct, everything tells you it is part of Emacs. Then one sends a report >>> and people >>> start sending in in a long winded road to find the appropriate >>> channel. >> >> We can consider those features of reporting bugs still in >> development. I never knew since recently that there are various >> reporting bug functions. You can discover it easier by using >> completion such as ivy package. > > Still in development? How much thinking do people have to do > for this. I can make 34 mailing lists in a few hours! > If I'm not mistaken, all of the development is done by volunteers. Perhaps you could help resolve your issue instead of asking other people, who are likely already overworked, to shoulder the burden. -gyro
set source directory for org-attach
Hi, I'm relatively new to org-mode. I am tending to use org-attach quite a bit as part of my workflow. Instead of having to navigate from default-directory to the source of the attachment, it would be great if I could set a better default. I am probably missing something obvious, but is there a way to set the default source directory for attachments? Any advice is greatly appreciated. Thank you for your help. -gyro
Re: Changed list indentation behavior: how to revert?
On 11/16/2020 9:26 AM, Tom Gillespie wrote: > Would it help if major releases maintained a mini-config that if added > to init.el would allow users to retain old behavior? That way they > wouldn't have to read the NEWS but could just add the relevant lines, > or maybe even just call the org-old-default-behavior-9.1 or > org-old-default-behavior-9.4. The workflow during development would be > to account for any change to defaults in those functions. Thoughts? > Tom > > I hate to open a new can of worms, but could semantic versioning be used such that it is obvious when there are changes that are not backwards compatible? -gyro
Re: Changed list indentation behavior: how to revert?
On 11/16/2020 9:26 AM, Tom Gillespie wrote: > Would it help if major releases maintained a mini-config that if added > to init.el would allow users to retain old behavior? That way they > wouldn't have to read the NEWS but could just add the relevant lines, > or maybe even just call the org-old-default-behavior-9.1 or > org-old-default-behavior-9.4. The workflow during development would be > to account for any change to defaults in those functions. Thoughts? > Tom > > I hate to open a new can of worms, but could semantic versioning be used such that it is obvious when there are changes that are not backwards compatible? -gyro
Re: New website - back to the old unicorn!
On 10/26/2020 4:27 AM, TEC wrote: > > TEC writes: > >> there are a few teething issues that have appeared when deploying the >> site on orgmode.org. > > These issues have now been fixed! Go wild :P > > I've taken the liberty of making a post on reddit: > https://www.reddit.com/r/emacs/comments/jic3ww/the_org_website_has_been_revamped/ > > > Once again, thanks to everyone who's helped out with this! > > Timothy. > > The new site looks really great! If we stumble upon minor issues (e.g., typos), what would be the best way to notify you? -gyro pEpkey.asc Description: application/pgp-keys
Re: a catastrophic orgmode issue - a definite show stopper, put on your tin hats
On 9/6/2020 2:17 AM, hj-orgmod...@hj.proberto.com wrote: > === The alien abduction of Bastien === > > Just in: > > The relentless activity - plethora of unstoppable emails - on the > orgmode mailing list under the name "Bastien" is a clear proof that the > impostor doesn't sleep and that it doesn't eat. It's a robot that just > hammers and hammers at the keyboard. The only logical conclusion is that > our Bastien has been abducted by aliens. > > Aliens! Beware! ... We will be looking for Bastien. Give us back our > Bastien, or you will have a war on your hands! > > Until we find him, we'll enjoy all that this robot has got going ... > > - 23 - Based on the incredible number of posts and amazing responsiveness, I think it is more likely that all of the inhabitants from the planet Bastien have been party to this. -gyro pEpkey.asc Description: application/pgp-keys
Re: Website revamp?
Your website update is looking great! A couple of comments: - If materials are presented that are not relatively recent, it may indicate to potential users a lack of project vitality. - Because so many people these days are enticed by videos, I wonder if links to a few selected, engaging videos could be made prominent on the home page. I know that creating such a list could be difficult, but perhaps some consensus could be reached on a few outstanding selections. -gyro On 8/4/2020 12:27 AM, TEC wrote: > > Good to hear from you! > > Eric S Fraga writes: >> I do like the animated images in the features page! > > Glad you like them! I recently converted the static images to SVGs with > the help of someone using Emacs27 w/ Cairo, would be nice go do > something like an animated SVG in the future, but that's for (much) > later :P > >> I do wonder about the order of the topics within that page, e.g. >> working with source code, although powerful, is probably not the lead >> item for new users. However, that's a minor point at this stage. > > Thanks for this feedback. I prioritised the source code blocks because: > a) my impression is that to Comp/Data Sci people, they are one of /the/ > most compelling features of Org-mode b) they're similar to elements > people are familiar with (Jupyter notebooks, R markdown), so the > Comp/Data Sci segment of our audience is already roughy familiar with > part of their capabilities > I shifted the agenda/capture/clocking/etc. features down because > a) they semantically seem like they should go together b) having them > near the top pushes down too many other features too much, IMO > > Absolutely worth considering the order, please share any further > thoughts you may have :) > >> More generally, can the column width for the text be a function of the >> window width and have images scaled so that they are not wider than >> the text column? It should be possible to have mobile friendly >> without making the columns too narrow for full desktop use. The fact >> that the images are much wider than the text makes the page look ugly, >> in my opinion. > > The column width already is. I just find long lines undesirable. 50-80 > characters is the standard in publishing for a reason. > > To quote from /The Elements of Typographic Style/, >> Anything from 45 to 75 characters is widely regarded as a satisfactory >> line length of line for a single-column page set in a serifed text >> face in a text size. The 66-character line (counting both letters and >> spaces) is widely regarded as ideal. For multiple-column work, a >> better average is 40 to 50 characters. If the type is well set and >> printed, lines of 85 or 90 characters will pose no problem in >> discontinuous texts, such as bibliographies, or, with generous >> leading, in footnotes. But even with generous leading, a line that >> averages more than 75 or So characters is likely to be too long for >> continuous reading. > > There's more to be said about line spacing and the reasons for this - if > I recall correctly /A practical guide to typography/ (available online) > goes over this. > > I look forward to hearing any further comments you may have! > > Timothy. > > pEpkey.asc Description: application/pgp-keys
Re: issue tracker?
On 5/19/2020 1:48 PM, Russell Adams wrote: > On Tue, May 19, 2020 at 01:50:26PM -0500, James R Miller wrote: >> I think an actual issue tracker has merit to large projects. >> >> And I don't think simply saying "we've always done it through a ML" or "$FOO >> project is bigger than us and uses a ML" is good enough. $FOO project may >> very >> well increase efficiency, code quality, and/or participation by implementing >> an issue tracker. >> >> A project to consider then, might be some sort of system that interfaces with >> the ML (as well as a simple REST api so that issues could be submitted from >> inside emacs directly), that creates some sort of org-based issue tracker, >> and >> then ox-html exports to a static web page or pages. > > My point about duplication of effort stands. Who/how/which solution? Who has > to > maintain it, and does that make two places to check while managing > bugs/patches? > > Please note I'm not a complete luddite, nor have I any real influence in any > decision. > > However I'll point out that with limited resources, the onus to sufficiently > justify a major change falls on the person(s) making the recommendation. > Change > "just because" or "it's prettier" tend to fall on deaf ears in technical > communities. > > I'd argue that code quality is more improved by the proper application of > version control than whether bug reports are web based. This appears to > already > be the case. > > If email is unmanageable, I'd assert that perhaps the user has a poor quality > mail reader that lacks threading support, and perhaps they should find a > better > one. > > Is there a problem with submitting issues via the mailing list? Has something > gone unaddressed? Do you have any statistics to show that there is decreased > participation because you have to use email? Is something really inefficient > at > the moment? Did you have patches ignored? > This idea that the tools used by a potential contributor are inadequate misses the point. If the intention is to keep a project going, or better yet increase the number of contributors, tools have to be used that will be convenient and familiar to those thinking about contributing. For better or worse, the workflows embodied by Github and Gitlab are familiar to the current generation of potential contributors upon which sustaining a project will depend. Holding up the 'Linux uses email for development and thus any project doing similar is right' fails to recognize the peculiar nature of the Linux kernel (and its developers) and neglects the thousands of projects that have increased their visibility and participation by using tools such as Github. I agree that Github/Gitlab may not be the best choice owing to their stance or implementation related to software freedom, but an honest discussion of alternatives seems prudent. -gyro pEpkey.asc Description: application/pgp-keys
Re: [O] refresh from google calendar before showing agenda
On 6/21/2017 7:54 AM, Eric S Fraga wrote: > On Wednesday, 21 Jun 2017 at 13:33, Gyro Funch wrote: >> Unfortunately, I am a newbie with elisp, so am not sure of the best >> way to accomplish this? > > You could possibly *advice* the agenda dispatch command. See "Advising > Named Functions" in the Elisp info manual. > Thank you for the advice. It was very helpful. Though perhaps not optimal, the following seems to work: (advice-add 'org-agenda :before #'org-gcal-fetch) -gyro
[O] refresh from google calendar before showing agenda
Hi, I set up org-gcal to download my google calendar to an org file and would like to do an automatic org-gcal-fetch before displaying an org agenda view. Unfortunately, I am a newbie with elisp, so am not sure of the best way to accomplish this? I would appreciate any help or suggestions on code I can use to make this happen. Thank you. -gyro
[O] Thank you!
I have recently adopted org-mode for both task lists and technical writing and wanted to express my sincere thanks to the creator, developers, and maintainers for such a wonderful piece of software. Keep up the great work! -gyro
