org-archive-subtree errors when logbook lines are unindented
Source: org-archive-subtree does not work on subtrees with clock entries #14033 https://github.com/syl20bnr/spacemacs/issues/14033 Description: The error message: indent-line-to: Wrong type argument: wholenump, -1 appears when org-archive-subtree (C-c C-x C-s) is called on a subheading that has :LOGBOOK: lines without indentation. With indentation: * a ** b :LOGBOOK: CLOCK: [2020-08-10 Mon 17:49]--[2020-08-10 Mon 18:34] => 0:45 :END: With the cursor on the subheading: ** b After pressing: C-c C-x C-s The buffer contents changed to: * a The *Messages* buffer shows: (New file) Copied: Subtree(s) with 89 characters Saving file c:/Users/username/Temp/14033/org-archive-subtree.org_archive... Wrote c:/Users/username/Temp/14033/org-archive-subtree.org_archive Cut: Subtree(s) with 89 characters Subtree archived in file: c:/Users/username/Temp/14033/org-archive-subtree.org_archive The file: org-archive-subtree.org_archive contains: #-*- mode: org -*- Archived entries from file c:/Users/username/Temp/14033/org-archive-subtree.org * b :PROPERTIES: :ARCHIVE_TIME: 2020-11-21 Sat 08:12 :ARCHIVE_FILE: c:/Users/username/Temp/14033/org-archive-subtree.org :ARCHIVE_OLPATH: a :ARCHIVE_CATEGORY: org-archive-subtree :END: :LOGBOOK: CLOCK: [2020-08-10 Mon 17:49]--[2020-08-10 Mon 18:34] => 0:45 :END: Without indentation: * a ** b :LOGBOOK: CLOCK: [2020-08-10 Mon 17:49]--[2020-08-10 Mon 18:34] => 0:45 :END: With the cursor on the subheading: ** b After pressing: C-c C-x C-s The buffer contents didn't change. The *Messages* buffer shows: (New file) Copied: Subtree(s) with 83 characters indent-line-to: Wrong type argument: wholenump, -1
Re: One vs many directories
* Texas Cyberthal [2020-11-21 10:19]: :PROPERTIES: :CREATED: [2020-11-21 Sat 12:53] :ID: 913ca9e4-17b4-4366-9a35-45838cace538 :END: > * Hi Ihor Radchenko, > > > I am wondering what you mean by Org's philosophy. Why would it have > > anything to do with directories? > > Org's philosophy is to have one or a handful of directories without > nesting of directories. Users are not expected to have their Org > files in a deeply nested tree. Org also prefers big files with large > trees rather than lots of little files. Is it? I did not know that. But it is definitely tedious to keep all Org files in one directory or few sub-directories. That is where 10 Bins paradigm becomes useful or other similar filing software. It is just good to file it into fixed place with fixed hyperlink that is easily captured somewhere. What I mean is when file is filed into ABC/STRUCT/XYZ/001/2020/11/20/2020-11-20/ is that such link can quickly be captured in some main file like: * ABC :PROPERTIES: :CREATED: [2020-11-21 Sat 12:53] :ID: 8459366d-e95e-4a2f-9eac-c093375d733c :END: ** STRUCT :PROPERTIES: :CREATED: [2020-11-21 Sat 12:53] :ID: 5d3b208f-dfec-4916-af7e-be784641d3f8 :END: *** XYZ :PROPERTIES: :CREATED: [2020-11-21 Sat 12:53] :ID: 19705797-19b5-46d4-ab7d-2414589a5e68 :END: 001 :PROPERTIES: :CREATED: [2020-11-21 Sat 12:53] :ID: ddf01399-3b6a-40d5-9a8c-55cadd2d08b2 :END: * 2020 :PROPERTIES: :CREATED: [2020-11-21 Sat 12:53] :ID: 5faef432-0abc-4953-bd81-2ffae69ecec1 :END: [[file:ABC/STRUCT/XYZ/001/2020/11/20/2020-11-20/file.org][File.org is filed file]] When such capture is done automatically upon filing then the link may be reused in other files. By using the Meta Org File user automatically creates an index of filed files and can search for the file in the Org file itself and open the file from the Meta Org File without knowing where the file is really located. > The rules are written to be straightforward at filing time. One need > only consider one object at a time. Cascade filing means one need > only compare the object with one directory at a time. The first match > wins. I should emphasize that in the docs. > > Having all your headings jumbled into three huge files sounds like a > state of permanent intractable overwhelm to me. That overwhelm I felt myself and found similar way like you Texas to file the files and I am still expanding into meta-level of organizing things. > You are using Hyperscope as your primary PIM but integrating it with > Org, and it sounds like you're using PostGreSQL and the directory tree > together somehow. I don't fully understand it. My primary PIM is on higher level than HyperScope as HyperScope is part of PIM which I call CRM or Customer Relationship Management as it does not manage only my personal information. In the practical sense it is more or less same thing only that allows work in group. It is just so similar to various other CRM software around. HyperScope is not file system. It is dynamical knowledge repository of hyperdocuments, any kinds of documents. Other similar projects are: Semantic Synchrony https://github.com/synchrony/smsn Hypothes.is Annotate the web, with anyone, anywhere. https://web.hypothes.is/ GNOWSYS: A Kernel for Semantic Computing! https://www.gnu.org/software/gnowsys gstudio https://gitlab.com/gnowledge/gstudio Project Xanadu https://en.wikipedia.org/wiki/Project_Xanadu Those links I am quickly inserting into buffer exactly by using Hyperscope. I am just pressing one key W and hyperlink from HyperScope buffer is creating those hyperlinks above. In general it is a tree based database that hyperlinks to all kinds of hyperdocuments. Hyperdocument is also a note in the database itself. But it can be Org file or any other file regardless where it is located, be it on the WWW or file system. It can be video that I have to watch or specific part of video. Then subtrees or the whole HyperScope database can be expanded into one Meta Org File if I wish. It is not "export" in the sense but one could say it is similar to export. > Clearly a database can do more than a directory tree alone. The cost > is that a database is more complex to use and maintain. So that which > can be handled by directory tree alone, should be. File system is database. What I keep in the PostgreSQL database it can be kept directly in the file system while program can manage various other relations. There is also EIEIO in Emacs which I found recently that also may be used as a database and there is GNU Emacs database. EDB or GNU Emacs database https://www.gnuvola.org/software/edb/ and various other interfaces to databases. Database need not be complex. It carries only the structure. I find it much easier and less complex to define the database table then to work with program that has to replicate all those algorithms that
Re: One vs many directories
Jean Louis writes: > My primary PIM is on higher level than HyperScope as HyperScope is > part of PIM which I call CRM or Customer Relationship Management as it > does not manage only my personal information. In the practical sense > it is more or less same thing only that allows work in group. It is > just so similar to various other CRM software around. > > HyperScope is not file system. It is dynamical knowledge repository of > hyperdocuments, any kinds of documents. Other similar projects are: > > Semantic Synchrony > https://github.com/synchrony/smsn > > Hypothes.is Annotate the web, with anyone, anywhere. > https://web.hypothes.is/ > > GNOWSYS: A Kernel for Semantic Computing! > https://www.gnu.org/software/gnowsys > > gstudio > https://gitlab.com/gnowledge/gstudio > > Project Xanadu > https://en.wikipedia.org/wiki/Project_Xanadu > > Those links I am quickly inserting into buffer exactly by using > Hyperscope. I am just pressing one key W and hyperlink from HyperScope > buffer is creating those hyperlinks above. > I have used similar tools in the past. However, what I find frustrating about them is that your now dependent on another bit of technology - a database of some type with all the issues that adds - installation, upgrades, maintenance, backups etc. The thing I like best about Org is that in the end, it is just a collection of plain text documents. I haven't had the challenges mentioned by others. My org files are broken into directories and I have a directory hierarchy and I use things like org id and other add ons to extend. I also have started playing around with org-roam, which I find to be quite interesting - especially the biity it has to handle bidirectional links etc. I also wanted to mention another Emacs project which is quite interesting and has actually been around a lot longer than org, Hyperbole. I've not got a URL handy, but I'm sure you can find it with google. It is an interesting system which pretty much makes everything possible in a document a hyperlink. Provides some very interesting ways of linking documents. My preference has always been to 'do my own thing'. I tend to look at other information management approaches and cherry pick the bits which I like and then replicate them in org. I don't find org as limiting as others seem to, but I'm also quite happy to add in my own elisp to tweak it the way I want it to be - thats why I love emacs. -- Tim Cross
Re: quick thanks
I would like to second this. We often come to this list only when something is not working, but it's also good to recognize how cool, powerful and indispensable Org is for many of us. Thanks to the maintainers and developers, and also to the community for the good discussion and great feedback. --Diego On Sat, Nov 21, 2020 at 7:14 AM Stephen Burke wrote: > Just wanted to say a quick thanks for the website updates, it looks > great. I'm glad org-mode is still available because it's just a joy to use > and super powerful. Thanks. > > -- > Stephen Burke >
org-plot line colors
I wanted to change line colors but didn't find a way. Is there a way? This almost works: #+PLOT: ind:1 deps:(2) set:"set style line 1 lc rgbcolor 'blue'" but it needs a `linestyle' set for each line, like this: plot '/tmp/org-plotiLccTT' using 1:2 with lines title 'some title' ls 1 note the `ls n' at the end. I think this is safe since there are default linestyle settings, so long as n doesn't exceed the number of linestyles available for the mode it doesn't matter if the plot config defines them. also note that I used single quotes for the color name in the plot config. I don't think org allows escaped quotes in headers. luckily gnuplot allows single quotes.
Re: One vs many directories
* Texas Cyberthal [2020-11-21 11:32]: > Hi Jean, > > I'll use some of the concepts in the first half of your email. I > disagree with the second. > > > In my opinion directories should never bother user. User should just > > pre-define sets of directories such as: People, Groups, you name it, and > > files should be accessible in such directories automatically. > > Productivity studies show that navigation dominates search. Human > animals are natural pathfinders and walking computer paths with > ergonomic file explorers such as Dired increases mastery of the > subject matter. Do you mean that navigating file system dominates the search? I also think that navigating file system dominates the search if that is what you refer. I think that users are inclined to navigate because computing tools such as file managers are given to users for that. Users did not get better systems to find or file files or other documents in computing. In other words I wish to say that we are under developed. Navigating does not necessarily contribute to production. Productivity may say what it wants but it may not reach those who are actually more productive without using the navigation. So studies may not tell us what is more productive, such may only tell what is currently used within the subject of being productive. You mentioned 2 things, navigation and search. Since years I am integrating pieces in my computing that drives me into direction of neither navigating nor searching. Examples: - I read your email in Mutt. Maybe I remember something you wrote earlier but not quite well and I wish to find your previous email. I click ESC-v and I can view all your previous emails. In this sense I do not need to know your email address and where your emails are stored on my system. For this particular type of object "Emails of user Texas" neither I am searching, neither navigating. I do not spend time searching and I do not spend time navigating to that object. It is by one click or two all in front of my eyes. Underlying functionality is very simple. All emails of users can be automatically (by sieve) or semi-automatically by key press saved into personalized mailboxes ~/Maildir/per...@example.com and by clicking ESC-v in Mutt, email address is extracted from the email I was reading and I new Mutt instance opens with all emails from ~/Maildir/per...@example.com -- then after reading, I click q and I am back in your first email, the top level email in the inbox. I could as well make it more automated, I could answer all emails and finish with Mutt, and upon finishing all emails could be sorted in personalized email files. - example with files belonging to user, let us say hyperlinks or anything, any piece of information, I could just press F4 on email and I could access all information related to that user. I do not need to know the phone number and I cand send SMS or initiate the call, share the contact, send email or fax, see all pictures of this person, notes, tasks, and financial transactions. I neither navigate neither search there. Maybe better way to call this type of locating objects is relational accessing. Somebody may correct me. There is some object like contact named "Texas Cyber". If object has any relation to anything else, then anything else can be displayed and found right there. Instead of me searching, computer is searching. Instead of me navigating, computer is navigating. > This value is trivial with retrieval tasks such as a person's name, > which is why 10 Bins stores such names in a flat list of > directories, sorted alphabetically by last name. It is easy to > integrate an automated retrieval script with such a predictable > path. Take care of duplicates. When marketing contact database is growing fast, some times 1000 people per day or more. People have same names. Often one cannot even know what is first and what is last name. You may know it for your country, in other countries is not so. Then those people engage in a course on distance. They are sending me images and files as results of their course assignments. I have to file the files in proper folder. Because names are not always unique I better file it under unique IDs, and keep separate symlinks with names of people to such unique IDs whereby symlinks can be automatically updated. That alone makes things easily very simple at least for objects such as people because people's names are in the file system. Then simple `locate` command can be used to find Texas Cyber's files: #!/bin/bash locate -e -d /home/data1/protected/.locate.database -A -i $@ I think that switch -A helps in finding all of these: Texas Cy Cyber Tex or similar variations. But in general I would just click ESC-e and I would get your profile and access to all files because location by email address from an email document is pretty much decisive. If person is not there, person is then created
Re: One vs many directories
* Tim Cross [2020-11-21 13:15]: > I have used similar tools in the past. However, what I find frustrating > about them is that your now dependent on another bit of technology - a > database of some type with all the issues that adds - installation, > upgrades, maintenance, backups etc. The thing I like best about Org is > that in the end, it is just a collection of plain text documents. Thank you, I understand your opinion. Let me share my viewpoint. Installing database such as PostgreSQL and configuring it is way more simpler than installing Emacs and configuring Org mode or Emacs itself. It goes like this: $ PACKAGE-MANAGER install DATABASE Later you just do: $ createdb MY-DB and then insert tables, usually program does that for you. - installation is simpler than Emacs, definitely, unless you install from sources which is in turn about the same as Emacs - upgrade is not necessary in general, majority of users need not ever upgrade. GNU/Linux distributions make upgrades easy and flowless normally. - for maintenance of database I do not know what this refers to. To me it means working with the database. Inserting, updating, editing records. That is writing text. I write text in Org and I write text in the database, it is about same thing without file on file system. It lacks maybe versioning system which in turn can be implemented easily to simple first backup the field into versioning table before editing such. Simple. - backup of the database is way easier than backup of the file system. export POSTGRESQL_BACKUPFILE="/home/data1/protected/Security/Backup/Database/PostgreSQL/`/bin/date -Iminutes`.sql.gz" alias backupPgDB='nice -n 19 /usr/local/bin/pg_dumpall | gzip > $POSTGRESQL_BACKUPFILE' That is all what is needed for the backup in my example. It can run by cron job that I do not even think about it. I can send database file by email or encrypt it by GnuPG and upload to some remote server automatically. > I also wanted to mention another Emacs project which is quite > interesting and has actually been around a lot longer than org, > Hyperbole. I've not got a URL handy, but I'm sure you can find it with > google. GNU Hyperbole https://www.gnu.org/s/hyperbole I am using Hyperbole everyday and it integrates with Org mode and can use Org links. It is on meta-level in comparison to hyperlinking in Org mode and in itself it is hypertextual information management system but is only in one part comparable to Org. It is not a mode for editing files, but that one part is named Koutliner and that is outline mode comparable to Org with one major difference that Koutliner provides specific ID for each part of the nodes in the substree. People often mix GNU Hyperbole and Org, but they are not comparable as Hyperbole is Hyper and Org is Org. Being Hyper it works in every file or every directory. I just wish to find out how to create buttons on the fly to interact between Hyperscope and Hyperbole. > It is an interesting system which pretty much makes everything > possible in a document a hyperlink. Provides some very interesting > ways of linking documents. Yes. When I enter my project directory there I keep ./HYPB directory button file. Then there are some tasks which are easily invoked by Hyperbole that relate to various maintenances: General actions === - <(Record the Developed Traffic incidents)> - <(Create General Log entry)> Search == Database actions - <(CF: Last 200 contacts)> - <(CF: People with mining lands)> - <(CF: Create contact and edit it)> Database settings = - <(Turn off speech)> Database Maintenance - <(CF: Find largest contact names)> - <(CF: Find possible doctors)> - <(CF: Normalize public email addresses)> - <(CF: Normalize phone numbers)> Now I am sure that same can be done with Org file as it offers many kinds of hyperlinking. While Org hyperlinks can be placed in any file and used in any mode they look ugly in non-Org text files without Org links mode enabled. > My preference has always been to 'do my own thing'. My preference for other people is same, that each should find their way and use the tools and paradigms they find familiar or appropriate. > I tend to look at other information management approaches and cherry > pick the bits which I like and then replicate them in org. I don't > find org as limiting as others seem to, but I'm also quite happy to > add in my own elisp to tweak it the way I want it to be - thats why > I love emacs. Of course. Me too. And I develop my own. I like to integrate things. For example tasks in Org mode I have to delegate to people so I click a button, choose person, choose valid email if there are many and task is sent to person. Person gives me feedback and I update the task conducted by that person. That is integrating. Maybe I am in the Org file for the person, how do I call quickly this person? If there is #+MACRO: contact-id
Re: One vs many directories
Hi Jean, I'll use some of the concepts in the first half of your email. I disagree with the second. > In my opinion directories should never bother user. User should just > pre-define sets of directories such as: People, Groups, you name it, and > files should be accessible in such directories automatically. Productivity studies show that navigation dominates search. Human animals are natural pathfinders and walking computer paths with ergonomic file explorers such as Dired increases mastery of the subject matter. This value is trivial with retrieval tasks such as a person's name, which is why 10 Bins stores such names in a flat list of directories, sorted alphabetically by last name. It is easy to integrate an automated retrieval script with such a predictable path. I think Treefactor is the correct means to refile files and directories, not a CLI program. The benefits of incremental inductive refiling outweigh those of the system you described. Incremental inductive refiling isn't compatible with your suggested automation, history and link features. Proper repo management is also incompatible. For example, text and binary files should be handled separately. I document rapid iterative inductive refiling here: https://treefactor-docs.nfshost.com I've come to depend on its cognitive benefits.
looking for a macro eval workaround (9.1 vs 9.2 and +) for export backend test
I have a *lot* of org files with a macro =if-backend= which enables me
to decide what to export depending on the backend :
#+begin_src org
#+macro: if-backend (eval (if (org-export-derived-backend-p
org-export-current-backend '$1) "$2"))
#+end_src
For instance, I use it to include =\hfill= in LaTeX family export
engines but not in others (html for instance) :
#+begin_src org
#+macro: hfill {{{if-backend(latex, \\hfill{} )}}}
#+end_src
I generally use emacs 26.3 as distributed by Debian bullseyes (which
offer org-mode version 9.1.9).
On another box I need to work with a more recent org-mode, precisely
9.4.
In that environment, due to an incompatible change introduced by
[[https://orgmode.org/Changes_old.html#outline-container-org003add6][release
9.2]] the same macro has to be written in a different way :
#+begin_src org
#+macro: if-backend (eval (if (org-export-derived-backend-p
org-export-current-backend (intern $1)) $2))
#+end_src
And thus I need to change also the macro using it, for instance the
=hfill= macro has to be written that way :
#+begin_src org
#+macro: hfill {{{if-backend(latex, \hfill{} )}}}
#+end_src
For now I need to work on the same files in these two different environment.
Do anyone have an idea on how to be able whether to define the
=if-backend= in a way that it can work in both org versions or if
there is a way to define these macro in different ways depending on
org version?
I would like to let the definitions in org files and not in emacs init
files.
--
Bruno BEAUFILS
signature.asc
Description: PGP signature
Re: One vs many directories
Texas, Ive been developing a paradigm over the years based upon a (recursive) 6x6 grid system, aligned with keybindings around the home row. Called Qiuy, I refer to it as a "Recursive Modelling Language", given the annotations work down to the level of functions and parameters, as well as directory naming. While migrating my OS (Debian -> Guix) and Editor (Vim -> Emacs) has muddied my workflows, I hope that my explorations with Org-Mode still permit me to operate with a highly broad but shallow folder structure. In any case, Im happy to be using Helm for browsing rapidly (as you will understand reading below!). Below is my home folder directory structure, please forgive legacy approaches clouding the vision (Ive been eating my dogfood for a longtime, I will be ending parental leave, hopefully the cruft and clutter can be trimmed/attic'd). Should you have any interest I am drafting some of my thoughts re Qiuy, as part of attendance at the upcoming Constant workshop Bureaucracksy. Id be happy to send you some material if you wish. = HOME FOLDER DIRECTORIES: = 1q10fq_music 1q10hqh_parsing 1q10iqi_authorship 1q10iqi_employment 1q10iqi_history 1q10iqi_initiating 1q10iqi_loops 1q10iqi_permutations 1q10iqi_states 1q10kq_bibliography 1q10rer_events 1q10rqr_coding 1q10rqr_tasks 1q10xq_etl 1q20beb_downloading 1q20be_bookmarks 1q20dq_appending 1q20dqd_document-management-systems 1q20dqd_editing 1q20dqd_file-managers 1q20dqd_removing 1q20dqd_text-editors 1q20dw_appending 1q20fe_images 1q20fq_diagrams 1q20fq_graph-plots 1q20fq_images 1q20fq_slides 1q20gq_fonts 1q20heh_parsing 1q20hqh_parsing 1q20iei_loading 1q20iqi_opening 1q20iqi_version-control 1q20jq_tables 1q20jq_templating 1q20ke_csv 1q20ke_html 1q20ke_json 1q20kq_csv 1q20kqk_document-management-systems 1q20kq_tables 1q20mq_contacts 1q20mq_content-types 1q20mq_document-body 1q20nqn_calendars 1q20oqo_classes 1q20rer_playing 1q20rq_analysing 1q20rq_calculating 1q20rq_comparing 1q20rqr_interviews 1q20tqt_curriculum-vitaes 1q20twt_notes 1q20ueu_searching 1q20uw_saving 1q20xq_converting 1q20xq_regular-expressions 1q20xq_substituting 1q20xqx_compression 1q20xqx_concatenating 1q20xqx_converting 1q20xqx_regex 1q20xqx_serialisation 1q30dqd_terminals 1q30fq_diagrams 1q30gq_backgrounds 1q30gq_color 1q30gq_fonts 1q30gqg_arcs 1q30gqg_arrows 1q30gqg_shapes 1q30gqg_theming 1q30gq_style 1q30iqi_prettifying 1q30iqi_states 1q30iqi_transparency 1q30jq_design 1q30jq_layouts 1q30jq_tables 1q30jq_templates 1q30mq_body 1q30mq_charts 1q30mq_graphs 1q30nq_networks 1q30uq_menus 1q30uw_outputting 1q30vq_backgrounds 1q30vq_columns 1q30vq_layers 1q30vq_monitors 1q30vq_panels 1q30vqv_graphics 1q30vqv_layouts 1q30vqv_statuslines 1q30vqv_window-managers 1q30vqv_windows 1q30xq_transforming 1q30yq_prettifying 1q30yq_visualising 1q40beb_scraping 1q40bqb_downloading 1q40bqb_networking 1q40bqb_servers 1q40bqb_transferring 1q40gqg_displaying 1q40gqg_theming 1q40hqh_coroutines 1q40hqh_scraping 1q40hq_navigating 1q40iqi_accessing 1q40jq_settings 1q40nqn_pathways 1q40nqn_positioning 1q40ueu_searching 1q40uq_exporting 1q40uq_importing 1q40uqu_searching 1q40yq_rotating 1q50cqc_terminals 1q50fe_files 1q50gqg_displaying 1q50hqh_interpreters 1q50hqh_parsing 1q50hq_navigating 1q50iqi_arguments 1q50iqi_building 1q50iqi_capturing 1q50iqi_contacts 1q50iqi_coroutines 1q50iqi_dates 1q50iqi_indexing 1q50iqi_keyboards 1q50iqi_loading 1q50iqi_parameters 1q50iqi_queues 1q50iqi_relationships 1q50iqi_states 1q50iqi_switching 1q50iqi_timing 1q50iqi_users 1q50iqi_vacancies 1q50iq_mappings 1q50iwi_terminating 1q50jq_manifests 1q50jq_options 1q50jq_stacks 1q50kek_tables 1q50mq_languages 1q50nqn_pathways 1q50nqn_relations 1q50nqn_trees 1q50nq_relations 1q50oqo_commands 1q50rq_analysing 1q50rq_calculating 1q50rq_graphs 1q50rq_identifying 1q50rq_rating 1q50rq_testing 1q50rq_watching 1q50tqt_curriculum-vitaes 1q50ueu_extracting 1q50uqu_filtering 1q50uqu_loading 1q50vqv_panels 1q50vqv_window-managers 1q50xq_companies 1q50xq_concatenating 1q60iei_loading 1q60jq_schemas 1q60jq_templating 1q60kek_databases 1q60me_classes 1q60me_schemas 1q60me_structure 1q60mq_asdls 1q60mq_catalogues 1q60nq_languages 1q60nq_package-management 1q60ue_updating 2q10dq_text-editing 2q10hqh_travelling 2q10iq_bureacracy 2q10iqi_history 2q10iqi_programming 2q10iqi_scheduling 2q10iwi_arbitration 2q10rqr_conferences 2q10rqr_employment 2q10rqr_travelling 2q20 2q20bqb_smtp 2q20cqc_text-editing 2q20cqc_word-processors 2q20dqd_text-editing 2q20fe_audio 2q20fe_film 2q20fe_graphics 2q20fe_images 2q20fe_literature 2q20fe_music 2q20fw_graphics 2q20fw_photos 2q20hqh_parsing 2q20hqh_scraping 2q20hq_navigating 2q20iwi_history 2q20kq_json 2q20kqk_databases 2q20kqk_document-management 2q20rq_analysing 2q20tq_signatures 2q20xq_converting 2q20xqx_converting 2q30fe_icons 2q30gqg_visualisations 2q30mq_columns 2q30mq_tables 2q30yqy_emphasizing 2q40bqb_downloading 2q40bqb_smtp 2q40bqb_transferring 2q40bq_downloading 2q40bq_websites
Re: One vs many directories
* Palak Mathur [2020-11-21 09:13]: > On Fri, Nov 20, 2020 at 6:34 PM Texas Cyberthal > wrote: > > > > Having a tall directory tree with many leaves and branches is against > > Org's philosophy. > > > > Here is my argument that such a structure is objectively correct for > > personal info management: > > > > https://github.com/cyberthal/10-Bins-template > > > > For the record, Org works fine with this, although I had to do a bit > > of config to get around the default philosophy. > > > > I read through the README but it seems overwhelming to have 10 > directories. I am not saying it is not good just that I will not be > able to handle those. Even now when I have just three main files - > inbox, work and archive, I am very bad at refiling items (I do it but > rarely). I mostly rely on Agenda views to make things make sense for > me. With 10 directories, I will surely never be able to refile > anything as half of the time I will just be spending time in deciding > where the item belongs. > > It surely will be good for more diligent people unlike me. Thank you for nice description of your file system. In my opinion for your use case the 10 Bins system looks very appropriate. One point I wish to present, that is that WHERE the file is stored need not be known to user. And when file is retrieved this also need not be known to user as user may search how Texas said by X methods. Since Texas have presented 10 Bins now I am eagerly wanting to organize all of the file system into structure that does not let me think where the file really is located. My structure is so much more complex but I do not think about it, computer is filing it for me. I think of people, groups, lists and I find files by thinking, not by looking into file system at least not so much. When I think of Texas I write: Texas, I find 12 contacts related to Texas, then I write "Emacs" or "Cyber" if I remember Cyber. From there on, I can see hyperlinks to 10 Bins system, I can find emails of Texas Cyber and find files and his Org file as well containing notes to Texas. But I have no clear idea where that file is really located on the file system. When finding the file I find it by X methods without knowing where it is located on file system. Basic structure any filing including emails could be following: 1. INBOX, items are coming here, if inbox is not empty something is wrong. Handled items should be filed appropriately. I file emails into maildir folders like ~/Maildir/per...@example.com 2. PENDING, those are things that cannot be handled for some reason, and because they are not handled they cannot be yet filed. 3. OUTBOX, those are things that need to be filed or dispatched. For example fax that has to be printed should be there. PDF export of Org file can be there as it has to be placed on USB stick to be brought to printer. SMS notes to be yet sent to people or files to be sent to people could be there. OUTBOX can be also handled by other people, not necessarily the organizer of things. 10 Bins system expands that not so related and offers more structure. There is need for org-of-org.org file that is meta Org file and that could be created on-the-fly Meta Org file by imagination named here org-of-org.org would be created based on information of: - filing the files and any types of hyperlinks like videos, movies, etc. including Org files. Upon filing such hyperlink has its structure stored somewhere. - retrieving of the files, as some files are not filed but are retrieved or launched. Retrieving files could then be logged or accounted in the file system or database for later on-the-fly referencing from org-of-org.org file. Then org-of-org.org file would be created on the fly: - it would create hierarchy of all filed files that helps the user locate the file easy without even knowing where the file is on file system - it would use the list of retrieved files to create the structured hierarchy of the retrieved files by its subjects, tags, groups Then user can click and get the meta Org file created on the fly and pinpoint where else to go with attention.
[ANN] org-super-agenda 1.2 released
Hi friends, FYI, I've released version 1.2 of org-super-agenda, which includes several improvements since the last stable release. https://github.com/alphapapa/org-super-agenda#changelog Please let me know if you have any feedback. Thanks, Adam
Re: [PATCH] org-plot abstractions and extension
On Sat, Oct 24, 2020 at 2:21 PM TEC wrote: > Sounds good then. I don't expect the changes to compromise any > existing > functionality. I tested these patches and didn't have a problem. I didn't go out of my way to see what changed and test it, but org-plot didn't break for what I was doing. I was hoping to be able to change line colors, but didn't find a way. I'll ask about it in another thread.
Re: One vs many directories
Am Samstag, dem 21. November 2020 schrieb Texas Cyberthal: > Productivity studies show that navigation dominates search. Human > animals are natural pathfinders and walking computer paths with > ergonomic file explorers such as Dired increases mastery of the > subject matter. This sounds interesting. As far as I am aware, search interfaces are increasingly deployed instead of hierarchical structures (just take the loss of the classic Windows Start Menu as an example). You suggest that this is unergonomic, which I, from a personal taste, would tend to agree. Do you have a source for the "productivity studies" you refer to? I would like to skim through them and see if I can cite them the next time someone wants me to convince to use a search-based interface. -quintus -- Dipl.-Jur. M. Gülker | https://mg.guelker.eu |For security: Passau, Germany | kont...@guelker.eu| () Avoid HTML e-mail European Union | PGP: see homepage | /\ http://asciiribbon.org
Re: looking for a macro eval workaround (9.1 vs 9.2 and +) for export backend test
Bruno BEAUFILS writes:
> I have a *lot* of org files with a macro =if-backend= which enables me
> to decide what to export depending on the backend :
>
> #+begin_src org
> #+macro: if-backend (eval (if (org-export-derived-backend-p
> org-export-current-backend '$1) "$2"))
> #+end_src
>
> For instance, I use it to include =\hfill= in LaTeX family export
> engines but not in others (html for instance) :
>
> #+begin_src org
> #+macro: hfill {{{if-backend(latex, \\hfill{} )}}}
> #+end_src
>
> I generally use emacs 26.3 as distributed by Debian bullseyes (which
> offer org-mode version 9.1.9).
>
> On another box I need to work with a more recent org-mode, precisely
> 9.4.
>
> In that environment, due to an incompatible change introduced by
> [[https://orgmode.org/Changes_old.html#outline-container-org003add6][release
> 9.2]] the same macro has to be written in a different way :
>
> #+begin_src org
> #+macro: if-backend (eval (if (org-export-derived-backend-p
> org-export-current-backend (intern $1)) $2))
> #+end_src
>
> And thus I need to change also the macro using it, for instance the
> =hfill= macro has to be written that way :
>
> #+begin_src org
> #+macro: hfill {{{if-backend(latex, \hfill{} )}}}
> #+end_src
>
> For now I need to work on the same files in these two different environment.
>
> Do anyone have an idea on how to be able whether to define the
> =if-backend= in a way that it can work in both org versions or if
> there is a way to define these macro in different ways depending on
> org version?
>
> I would like to let the definitions in org files and not in emacs init
> files.
Hmm, I just use backend specific blocks for this purpose. e.g.
#+begin_export latex
\hfil{}
#+end_export
Pretty sure 9.1 supports the same (there was a change, which used
#+EXPORT_LATEX instead of #+begin_export, but I think the old version
still works in 9.4, can't remember which version the change was
introduced). So if 9.1 only supports EXPORT_LATEX, you should still be
able to use it under 9.4
IMO the org #+MACRO is really just a text substitution mechanism (like
C), not a 'real' macro (like elisp has) and as is the case with C, you
really need to keep them pretty simple. Once you start using them to
evaluate code, it isn't hard to find yourself in a mine field.
--
Tim Cross
storing a link to a task from an agenda view
Hello, I'm trying to store a link to a task while the cursor is on it in the agenda view. I tried ~org-store-link~ on it, but it tells me there is no method to do so. So I looked at some of the org-agenda code to find a way to get to the underlying task, and I tried this: #+begin_src emacs-lisp (defun as/mk-agenda-link () (interactive) (let* ((marker (or (org-get-at-bol 'org-marker) (org-agenda-error))) (buffer (marker-buffer marker)) (pos (marker-position marker))) (with-current-buffer buffer (save-excursion (goto-char pos) (org-store-link nil) #+end_src but it does not store anything. (I have to put the ~nil~ at the ~org-store-link~ code otherwise I have an error, and looking at some of the ~org-capture~ code, I saw it there.) Do you have suggestions on how to store such a link from an agenda view? It can either end up in ~org-stored-links~ or captured in a variable. Thanks, Alan signature.asc Description: PGP signature
Using a code block as input to another code block
I know I can use an example block (literal example) as input to a code block, but I haven't found a way to fontify examples. Since my input is code (JSON, and various programming languages) I would really like to have that, as well as the language's mode when editing by using ~org-edit-source-code~. A code block gives me fontification, but I haven't found a way to pass a code block as is to another code block. For instance, something like this: #+name: code-input #+begin_src C #include #+end_src #+begin_src bash :var input=input :results verbatim cat
Re: One vs many directories
Jean Louis writes: > So in general I never need to use some general search through Org > files or any other files as my way of thinking begins with People or > Groups and that narrows what has to be searched. How do you deal with stuff that applies to several people? > it comfortable. My way of thinking is always People or Groups, and > from there various searches are performed and that narrows drastically > the subject that has to be searched. That does sound like it should speed up searching by directory. My mind works differently here: I remember some concept and need to find stuff connected to that, including people, but also additional ideas, instructions, and just bullet points with info I might need again later (which multiple times saved many hours of searching already). The one thing that keeps me from that is that I often file under specific projects, and the active projects are shifting constantly. For that I enjoy it a lot that I only need to customize the capture templates to add a project. > On my side I almost never put notes in Org files. As by definition > from Wordnet, note is "brief written record". With note I just mean "something". Mostly its bullet points with tasks, some links and references into source-code which allows me to quickly take up a tasks after some downtime. > Overall from this discussion I hope that people find some useful ways > of using Org, like org-rifle, semantic organization of stuff and > similar. I hope so, too. Thank you for describing the tools you use! I for one am still working on my workflow, and I guess that 10 years from now it won’t be the same as today. I hope that learning about other ways to work with org will help me a lot in future. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Re: One vs many directories
Hi Jean, > By using the Meta Org File user automatically creates an index of filed files > and can search for the file in the Org file itself and open the file from the > Meta Org File without knowing where the file is really located. Such a set of links could easily grow out of date if paths change, and I wouldn't want to maintain it. If the paths never change, then I would memorize the paths and linking them would be slower than Dired walking to them. I do have a method called "Zinks" for managing UID links. It permits paths to change without breaking anything, both target and source. However, in the vast majority of cases I find it much easier to just walk the directory tree. I doubt one can appreciate how useful a tree synced to one's mind is until one has experienced it. The tree adapts to the mind and vice versa. There's no need to know the exact locations of files; walking there is informative and useful. Or, for the trivial paths, walking is so quick that it is faster than searching. Search spawns distracting mismatches to read, whereas walking the tree progressively narrows scope in a mentally comfortable way that focuses the mind while error-checking each step. It's very comfortable to reach the destination and be confident from the process that I'm in the right place. > File system is database. Barely. Databaseness is a gradient with file system at one end and PostGres at the other. Plain text and file system are the computing foundation. The largest and best set of tools apply. Departing from them loses much. A filesystem is extremely ergonomic with the right tools, and handles bulk data very well. Any database, even Org's, has higher overhead. I do intend to integrate databases into Cyborganize with Dbmind, but have barely thought about it yet. Cyborganize should run fine without any database, but of course database is extremely useful for business etc. I just don't think paths need to be input into the database. The strength of the database is freedom from the file system. It should focus on the things a file system can't do. For example, querying all the people who work at X company, or who live in Y country. Duplicate Org IDs aren't a problem in my experience. Noticing their existence is a good way to reconcile the split after the dust of execution has settled. An Org workflow shouldn't generate lots of duplicate links. One that does probably indicates overuse of both links and heading duplication. If one really does need lots of unique IDs, it's probably a sign to move to a heavier database than Org. I'll fix that link. The correct URL is https://github.com/cyberthal/Textmind-template Glad to hear you're finding Cyborganize components useful.
Re: storing a link to a task from an agenda view
> Do you have suggestions on how to store such a link from an agenda view? > It can either end up in ~org-stored-links~ or captured in a variable. (org-store-link nil) -> (org-store-link nil 'interactive) Or you can just save the return value of (org-store-link nil) Best, Ihor Alan Schmitt writes: > Hello, > > I'm trying to store a link to a task while the cursor is on it in the > agenda view. I tried ~org-store-link~ on it, but it tells me there is no > method to do so. So I looked at some of the org-agenda code to find a > way to get to the underlying task, and I tried this: > > #+begin_src emacs-lisp > (defun as/mk-agenda-link () > (interactive) > (let* ((marker (or (org-get-at-bol 'org-marker) > (org-agenda-error))) > (buffer (marker-buffer marker)) > (pos (marker-position marker))) > (with-current-buffer buffer > (save-excursion > (goto-char pos) > (org-store-link nil) > > #+end_src > > but it does not store anything. (I have to put the ~nil~ at the > ~org-store-link~ code otherwise I have an error, and looking at some of > the ~org-capture~ code, I saw it there.) > > Do you have suggestions on how to store such a link from an agenda view? > It can either end up in ~org-stored-links~ or captured in a variable. > > Thanks, > > Alan
Re: Clock tables and two ways to categorize tasks
> On 20 Nov 2020, at 10:23, Leo Okawa Ericson > wrote: > > > Some time ago I hacked together a bunch of elisp to create a clock table > based on tags. [1] It uses org's dynamic block feature[2] to create a > piechart with gnuplot and a simple table that shows percentages of time > spent on different tags. I should say that it has basically no > documentation at all, but if there is interest I could write something > to explain the basic usage at least. > > [1] https://github.com/Zetagon/dotfiles/blob/master/doom/pichart-property.el > > [2] https://orgmode.org/manual/Dynamic-Blocks.html > Started to read through the code and yes, a bit more documentation would be great. Thanks /Kristian
Bug: Error message: "Symbol’s function definition is void: org-refile-get-location" [9.4 (9.4-41-g9bb930-elpaplus @ /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20201116/)]
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
The org-goto command doesn't work unless org-refile has been loaded.
I started Emacs, loaded org, opened and org file and tried running org-goto.
I got the following error message:
Symbol’s function definition is void: org-refile-get-location
That sounded like a function that should be defined in org-refile, so I ran the
org-refile command, which caused the org-refile library to be loaded, and after
that org-goto worked as expected.
I'm not sure what the best fix for this is, maybe the org-goto library should
simply require org-refile, or maybe org-refile-get-location should have an
autoload.
Emacs : GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.5,
cairo version 1.16.0)
of 2020-10-13, unofficial emacs-snapshot build: http://emacs.ganneff.de/, git
commit 8d241e8840fdb02dcfce52425626dd8f2125e51a
Package: Org mode version 9.4 (9.4-41-g9bb930-elpaplus @
/home/omarantolin/.emacs.d/elpa/org-plus-contrib-20201116/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-link-shell-confirm-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-refile-targets '((nil :maxlevel . 2) ("~/Notes/Notes.org" :maxlevel . 2)
("~/Notes/Someday.org" :level . 0)
("~/Notes/Daily.org" :level . 3))
org-pretty-entities t
org-latex-default-packages-alist '(("AUTO" "inputenc" t ("pdflatex"))
("" "graphicx" t) ("" "grffile" t)
("" "longtable" nil) ("" "wrapfig" nil)
("" "rotating" nil) ("normalem" "ulem" t)
("" "amsmath" t) ("" "amssymb" t)
("" "capt-of" nil) ("" "hyperref" nil))
org-special-ctrl-a/e t
org-agenda-files '("~/Notes/Refile.org" "~/Notes/Daily.org"
"~/Notes/Alumnos.org" "~/Notes/Someday.org")
org-mode-hook '(#[0 "\301\211%10\207"
[imenu-create-index-function org-imenu-get-tree] 2]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-show-all append local]
5]
#[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
ediff-with-org-show-all turn-on-org-cdlatex beginend-org-mode
org-eldoc-load)
org-outline-path-complete-in-steps nil
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-bibtex-headline-format-function #[257 "\300%1\236A\207" [:title] 3
"\n\n(fn ENTRY)"]
org-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-hide-leading-stars t
org-hide-emphasis-markers t
org-highlight-latex-and-related '(latex script entities)
org-ellipsis "…"
org-agenda-loop-over-headlines-in-active-region nil
org-src-lang-modes '(("latex-macros" . latex) ("inline-js" . javascript)
("redis" . redis) ("php" . php) ("arduino" . arduino)
("C" . c) ("C++" . c++) ("asymptote" . asy)
("bash" . sh) ("beamer" . latex) ("calc" . fundamental)
("cpp" . c++) ("ditaa" . artist) ("dot" . fundamental)
("elisp" . emacs-lisp) ("ocaml" . tuareg)
("screen" . shell-script) ("shell" . sh)
("sqlite" . sql))
org-occur-hook '(org-first-headline-recenter)
org-agenda-mode-hook '(beginend-org-agenda-mode)
org-structure-template-alist '(("a" . "export ascii") ("c" . "center")
("C" . "comment") ("e" . "example")
("E" . "export") ("h" . "export html")
("l" . "export latex") ("q" . "quote")
("s" . "src") ("v" . "verse")
("thm" . "theorem") ("pf" . "proof")
("lem" . "lemma") ("cor" . "corollary")
("def" . "definition") ("rem" . "remark")
("exer" . "exercise") ("prop" . "proposition")
Re: One vs many directories
* Dr. Arne Babenhauserheide [2020-11-22 01:48]: > > So in general I never need to use some general search through Org > > files or any other files as my way of thinking begins with People or > > Groups and that narrows what has to be searched. > > How do you deal with stuff that applies to several people? >From database viewpoint there are - accounts (which means companies, groups, entities, like "People who wish to get employed in Europe") - there are contacts, that may belong to account, additionally belong to company (also account), additionally be member of account, so there are 3 groupings for each contact how that contact may be related to account. If it is main account such as "Welders" or if maybe under "Company" is written "welders" (not quite correct) in reality it does not matter. - then there are lists to which other lists belong. Account A and account B, C, D can belong to list 01. Various accounts can be put together in uniting lists. Those lists are encompassing other lists, not individual people but people in the list (account) usually unless there is only one in the account. Those lists I am using for mailing them or informing them by letter, SMS, etc. Geologists and mining engineers and metallurgists are 3 different accounts but if all of them speak Swahili both in Kenya and Tanzania and are in the related branch of economy so they can be sent same type of information. Then there are groups, which is just another name for a new list. Then there are tags. I can freely tag account, contact or anything else. By tags I can finely select specific people belonging to specific group. There are account types and group types. Tags by itself have its own description or purpose to name it type. Some people introduce other people, few of them introduced thousands. So contacts have a column "introduced by". That becomes very handy when talking to somebody and it also helps in awarding introduces. It helps when people place their hyperlinks and become automated introducers (lead generation). When I know that person belongs to some group of people and I have to write email and I know it is better to inform everybody, then there is action to assign identity from which I am sending email. It could be public or internal identity with different email address. Emails to that person would always go from designated email address without me thinking about it. Then there are Cc and Bcc fields and in those fields I could designate: to inform same contact to each of email addresses with same message, and to inform group of people each time. Thus if writing to one contact all others get informed through same message. But I am not thinking about who belongs to the group, and what are their email addresses, that gets inserted automatically. Email composition is usually inside of Emacs. Sending files? If contact is in the group and others need to see the file, then Cc and Bcc fields work in the same way, file sent to one person is sent to other members of the group. Sometimes contact tells me to please exclude some people from Cc, so I just go into definition of identities for contact and exclude such. SMS I am sending by using kdeconnect.el package so any SMS I send this way it is getting recorded to the contact. If I need to send SMS to the group, then same SMS could be sent to whole group. If the note on one contact is related to other people then is trivial to automate to inform other people on that particular note. If any group of people is there, filing files under group does not make much sense to me. I would not file it as Group/ABC/file-01.pdf I would file it under By-ID/Contact-ID-123/Group/file-01.pdf as files are normally sent by one email address of one person or under one name. I deal with people not with empty groups that do not communicate. But group is important, so there can be /Group/ directory on the file system where all contacts of one group can be symlinked automatically if it happens that I need to search by Group on file system, but I don't. I search for groups in the database and see list of contacts there and then jump to contact. Same thing with invoices, they are written either to company or to individual or some individual in some company. I will not file or act based on invoice. I have to act based on authorirative or maybe hierarchically higher object first. In general is always good to make a list of things and then lists are foundation for dealing easier with whatever groups of anything. > > it comfortable. My way of thinking is always People or Groups, and > > from there various searches are performed and that narrows drastically > > the subject that has to be searched. > > That does sound like it should speed up searching by directory. You remember that I do not search by directory. Computer stuff I search by directory, like Work/Computer/Devices/Dictaphone or Work/Computer/Graphics/shadow Stuff related to any entity,
Re: One vs many directories
* Strongly suggest looking into Emacs' vlf-mode and the newer vlfi-mode
** That is Very-Large-File-Mode & Very-Large-File-Improved-Mode for issues
you're experiencing & if not, simply because they're very useful &
interesting & fun Emacs Modes to explore & put into your toolbox
https://www.emacswiki.org/emacs/VLF
https://github.com/m00natic/vlfi
* You mentioned other types of GREP, I second that, and the indexing
suggestion--I remember long ago using SGREP which is Simple-GREP, used
indexing & was much faster than the usual grep implementations for some
things; but, this is at the expense of the fancier & more elaborate GREP
functions
** You mention RipGrep--thanks for that, very interesting
* Which brings me to my main suggestion to you & why:
Emacs, believe it or not, has the FASTEST ENGINE available, without
augmentation in any way, for INTERACTIVE SEARCH--since the whole engine is
designed to be optimized to search-while-editing
But for many other searches, more elaborate searches, fancier GREP
searches, it's a VERY BAD choice of ways or programs to use for searching
What I mean is, say you're editing a file, and you search for your
"ProviderBuilderFactory"
Suggest you try opening a huge file--even MULTI-GIGABYTE FILES--huge files
in Emacs VLF-Mode--Very Large File-mode {which I believe can be done as a
sub-mode to/with Org-Mode}
And you can do this fearlessly since vlf-mode works by dividing the files
up for you in the background, etc.--while you're editing--but uses the same
built-in Emacs engine, optimized for such searches
And then you type:
Control-s
And start to type the first letters of "ProviderBuilderFactory"
This will interactive-search HUGE files, very quickly, and in near "Real
Time"--since this is what Emacs (implemented in C) is optimized to do--its
optimized for initial-character-searching "as you type them"--most other
engines are NOT
IF FOR NO OTHER REASON THAN IT SOUNDS LIKE FUN! And you might use vlf-mode
for other tasks you may face in the future.
Please try it out & tell how you like it--you'll never avoid opening huge
files again is one benefit
Beyond that, suggest you look into using LEX, it's as fast as you can get
for some things too.
Everything has its niche in the *nix world--which is where GREP came from,
Bell Labs, etc.--that's the Unix philosophy, Emacs & LEX tools came from
that world & the work of thousands of contributors--suggest you try these
tools too for these issues
Lastly, say you want to search for things without opening a file, you can
still use Emacs in batch-mode, at the command line, without opening a full
emacs session
On Sat, Nov 21, 2020 at 8:34 PM Jean Louis wrote:
> * Dr. Arne Babenhauserheide [2020-11-22 01:48]:
> > > So in general I never need to use some general search through Org
> > > files or any other files as my way of thinking begins with People or
> > > Groups and that narrows what has to be searched.
> >
> > How do you deal with stuff that applies to several people?
>
> From database viewpoint there are
>
> - accounts (which means companies, groups, entities, like "People who
> wish to get employed in Europe")
>
> - there are contacts, that may belong to account, additionally belong
> to company (also account), additionally be member of account, so
> there are 3 groupings for each contact how that contact may be
> related to account. If it is main account such as "Welders" or if
> maybe under "Company" is written "welders" (not quite correct) in
> reality it does not matter.
>
> - then there are lists to which other lists belong. Account A and
> account B, C, D can belong to list 01. Various accounts can be put
> together in uniting lists. Those lists are encompassing other lists,
> not individual people but people in the list (account) usually
> unless there is only one in the account. Those lists I am using for
> mailing them or informing them by letter, SMS, etc. Geologists and
> mining engineers and metallurgists are 3 different accounts but if
> all of them speak Swahili both in Kenya and Tanzania and are in the
> related branch of economy so they can be sent same type of
> information.
>
> Then there are groups, which is just another name for a new list. Then
> there are tags. I can freely tag account, contact or anything else. By
> tags I can finely select specific people belonging to specific group.
>
> There are account types and group types.
>
> Tags by itself have its own description or purpose to name it type.
>
> Some people introduce other people, few of them introduced
> thousands. So contacts have a column "introduced by". That becomes
> very handy when talking to somebody and it also helps in awarding
> introduces. It helps when people place their hyperlinks and become
> automated introducers (lead generation).
>
> When I know that person belongs to some group of people and I have to
> write email and I know it is better to inform everybody, then there is
Re: One vs many directories
Hi Texas, > Grepping my 94 Mb 6562 files (excluding archive) Textmind for > "elephantine" takes a few seconds, which is fine. For the sake of ruining my argument ( :-) ), you might want to check ripgrep. Searching within 30k files of in total around 150 MiB for ProviderBuilderFactory (guess what type the files are :-) ) takes 0.4s with ripgrep. (that’s on an nvme (M.2) disk) It’s still too slow for interactive use. Within 1k files of in tootal 7 MiB it is fast enough. > Org searching for a nonexistent UID link takes a few minutes, which is > why I run that search nightly, to refresh the index. My Org Agenda > search scope is only 252k in 58 files and is effectively lagless. That lagless is what I see as being required for actual operation. > I'm not sure what kind of lagless Org database operations are required > in your workflow, but I suspect they could be mostly replaced by a > proper Textmind workflow and 10 Bins structure. I need instant search in the knowledge database and quick filing of tasks. Also I need the agenda to create a clocktable (that’s on the limit of being too slow) and the calendar and tasks of the week. Also I need quick filing of notes and quotes (in specific files, not part of the agenda) and of long-form articles, one file per article (using journal.el, also outside the agenda, searched using M-x deft), and quick creation of website entries for a given category within the site (i.e. M-x draketo-software). > I guess I avoid the problem you're talking about by mostly excluding > bulk prose from the Agenda directory. They're fundamentally different > and should be handled differently. I do that, too. One is source code, one is organisation tasks. I link from org into the source code, though (but never check the targets). I do use org-planning within prose, but there the scope is only the one org-document. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Re: One vs many directories
> In fact the properties, custom ID and else inside is mostly visually > disturbing me though it is necessary. FYI: org-custom-properties and org-toggle-custom-properties-visibility Jean Louis writes: > * Texas Cyberthal [2020-11-21 18:46]: >> I guess I avoid the problem you're talking about by mostly excluding >> bulk prose from the Agenda directory. They're fundamentally different >> and should be handled differently. > > Well said. > >> One is about human language, the other is about database metadata. > > That is so. > > In fact the properties, custom ID and else inside is mostly visually > disturbing me though it is necessary. Before knowing about Org I have > already had a system of planning, projects, tasks, and all that could > be related to people, groups and what other else things. This part of > Org that is dependant on meta data is better managed through > dedicated databases. > >> The temptation to do everything inline just because Org supports it >> is one of Org's biggest traps. It's like the trap of trying to >> outline strictly when you should be rambling. > > Temptation is brought through the usage of Org as there are not so > many choices beyond it. Org is meant to keep simple things > simple. Data being managed may easily grow into complex thing.
Re: Clock tables and two ways to categorize tasks
Kristian Grönberg writes: >> On 20 Nov 2020, at 10:23, Leo Okawa Ericson >> wrote: >> >> >> Some time ago I hacked together a bunch of elisp to create a clock table >> based on tags. [1] It uses org's dynamic block feature[2] to create a >> piechart with gnuplot and a simple table that shows percentages of time >> spent on different tags. I should say that it has basically no >> documentation at all, but if there is interest I could write something >> to explain the basic usage at least. >> >> [1] https://github.com/Zetagon/dotfiles/blob/master/doom/pichart-property.el >> >> [2] https://orgmode.org/manual/Dynamic-Blocks.html >> > > Started to read through the code and yes, a bit more documentation would be > great. > > Thanks > The other thing to consider is writing your own clock table formatter. The one which is the default in org is somewhat long and looks a bit challenging. However, that is because of all the options it has to deal with. If you just consider how it works and can accept a formatter which does not support the whole range of clock table options - only the ones you need, it is actually very simple. The data structure passed in by the clocktable function is just a nested list where each row has the basic details of the tasks selected by the scope e.g. level, headline text, tags, timestamp, time and properties associated with the entry. You can sort, filter and present the data in whatever manner you want. Using something like pcase-dolist to destructure the data into variables and it can be quite clean. HTH Tim -- Tim Cross
Re: One vs many directories
Hi Jean, > Navigating does not necessarily contribute to production. Productivity may > say what it wants but it may not reach those who are actually more productive > without using the navigation. So studies may not tell us what is more > productive, such may only tell what is currently used within the subject of > being productive. Outside 10 Bins, navigation is often negatively productive. Whenever the user navigates bad tree structure without correcting it on the fly, he suffers profitless friction. That's why Treefactor combines with JiT sorting to make navigation and sorting a single activity. Frankly I was surprised people prefer navigation despite being generally so bad at tree structure. In the absence of good structure and tools, search is much better. I agree, email should be database-centric. Manually organizing emails into folders (or worse, trees) is therefore wrong except in tiny doses. > Take care of duplicates. When marketing contact database is growing fast, > some times 1000 people per day or more. People have same names. Often one > cannot even know what is first and what is last name. You may know it for > your country, in other countries is not so. Then those people engage in a > course on distance. They are sending me images and files as results of their > course assignments. I have to file the files in proper folder. Because names > are not always unique I better file it under unique IDs, and keep separate > symlinks with names of people to such unique IDs whereby symlinks can be > automatically updated. This is clearly a CRM database use case. In this situation, the CRM should define the unique ID, and then Textmind should accept it. You can still use the directory tree, though. Just file it under ~/Surname-given-name/ID-number/~ for the non-unique name. Recursively searching ~/1-Textmind/2-Linked/7-Name/2-Flat/~ for a directory named ~/ID-number/~ will find the target even if his name changes slightly. So you can save time by not inputting every scrap of text and files into the CRM.
Re: One vs many directories
* Texas Cyberthal [2020-11-21 17:45]: > Hi Jean, > > > By using the Meta Org File user automatically creates an index of > > filed files and can search for the file in the Org file itself and > > open the file from the Meta Org File without knowing where the > > file is really located. > Such a set of links could easily grow out of date if paths change, and > I wouldn't want to maintain it. If the paths never change, then I > would memorize the paths and linking them would be slower than Dired > walking to them. By principles of Doug Engelbart, once file is filed, it should be there and nowhere else, it becomes more or less static. Then you have some kind of DKR or dynamic knowledge repository that tracks where such files are. Let us say that DKR provides you with the hyperlink "K12A". This link is is then referenced from all other files. If the underlying location of the file changes, but it should not, all the hyperlinks remain always the same. > I do have a method called "Zinks" for managing UID links. It permits > paths to change without breaking anything, both target and source. > However, in the vast majority of cases I find it much easier to just > walk the directory tree. I doubt one can appreciate how useful a tree > synced to one's mind is until one has experienced it. The tree adapts > to the mind and vice versa. That is good and useful. While I do order things in a tree it is not that I think of those tree in hierarchical sense. By habit I could maybe remember but because it is not necessary to remember, it is not useful, then I don't. What I remember is the sub-tree name. For example Emacs or Emacs Lisp, then I just do the helm or ivy or other completion and find the subtree. From there on I browse for information, file it, open up or launch hyperlinks. It is not browsing the tree, it is more direct jump to the relevant part of the three. And if hyperlinks are represented as (hyperscope 123) then regardless if such link moves from subtree to subtree or underlying information changes somehow the reference to that link remains always same (as long as ID is always same). > There's no need to know the exact locations of files; walking there > is informative and useful. Or, for the trivial paths, walking is so > quick that it is faster than searching. That is good and isn't it general way of sorting things? I guess that general computer users may not be aware that they could make nice hierarchical tree of directories. System that users are offered are file managers and such are way to abstract for today's users. Back in time we did not have that many files, today we have loads and loads of files. Those programes named file manager do not manage anything by themselves. And they should. User should choose to file a file, and by any type of paradigm, user would maybe answer just 1-3 questions and file would be filed into appropriate place. It could be retrieved as fast as filed. That would be semi-automatic file management. If all files would have its meta-data then automatic file managemet could be possible. Then it would be known who is author, what is subject or tag of the file, what is its title, date of writing it, permissions (not file permissions but access permissions) and similar. Then program could file those files automatically. For images named IMG_2020111012345.jpg is possible to parse image names and if not image names then the built-in EXIF data and file all images by their dates automatically. Bunch of images coming from camera and they need to be sorted by date so in that case it can be automatic. Text files do not have its meta data. Org files could be said to have as there is TITLE and AUTHOR, DATE. But there is no rule for meta data. Good set of principles or rules when creating files could create meta data and by meta data files could be automatically filed and easily retrieved. > Search spawns distracting mismatches to read, whereas walking the > tree progressively narrows scope in a mentally comfortable way that > focuses the mind while error-checking each step. It's very > comfortable to reach the destination and be confident from the > process that I'm in the right place. That is exactly same mental concept that I use. It becomes pleasure as well. I could watch videos of other similar creators as you and I can feel the pleasure in their voices and I can understand the piece of mind when files are sorted. Unsorted files do bring mental mess in the person's mind. > > File system is database. > > Barely. Databaseness is a gradient with file system at one end and > PostGres at the other. > > Plain text and file system are the computing foundation. The largest > and best set of tools apply. Departing from them loses much. I know in computing we say "database" for those more sophisticated databases. By definition from Wordnet: * Overview of noun database The noun database has 1 sense (no senses from tagged texts) 1. database -- (an organized body of
Re: One vs many directories
* Texas Cyberthal [2020-11-21 18:01]: > Hi Jean, > > > Navigating does not necessarily contribute to production. Productivity may > > say what it wants but it may not reach those who are actually more > > productive without using the navigation. So studies may not tell us what is > > more productive, such may only tell what is currently used within the > > subject of being productive. > > Outside 10 Bins, navigation is often negatively productive. Whenever > the user navigates bad tree structure without correcting it on the > fly, he suffers profitless friction. That's why Treefactor combines > with JiT sorting to make navigation and sorting a single activity. > > Frankly I was surprised people prefer navigation despite being > generally so bad at tree structure. In the absence of good structure > and tools, search is much better. Do you really think people prefer? Or they simple have no other option? If I have no other option to drink a juice I will drink water, not necessarily I prefer drinking water in hot sunshine. I like Apfelschörle. Searching file contents is database search. I am not any more fan of that. Tools like Beagle or Tracker are making basically double database of files only for me to find or search files. Most of time I am only searching for meta data, not for contents. With 1000 GB one would need to have maybe that much indexed database and constant updating of files and their positions. That is why I prefer relational pinpointing or relational access and actions or locating files by using indexes. Relational access would mean when you inspect the object to quickly jump to all relational pieces of information relating to that object. If I look on person's name there need not be any note or contact information but I should be able to quickly access such information. And each object should have general actions like actions relating to email object could be to send email, delete email, forward, etc. that is what mail readers do. Action on file relating to user should be to quickly see emails of the user, social networks, websites, to call user, SMS, send information, jump into XMPP chat, share the file or request new version of file and similar. Locating files by indexes would be to index only meta data and then to use searches to find meta data such as title, date, author, or various attributes. Tools like locate and similar do that. > I agree, email should be database-centric. Manually organizing > emails into folders (or worse, trees) is therefore wrong except in > tiny doses. You missed this: - I am reading email, answering and if I wish to keep it all I do is `s` to save it into the mailbox related to the email address: ~/Maildir/te...@example.com Emails that I send to user are saved to same mailbox. That is all. No thinking, nothing, saving goes automatic. This single plan of filing emails enables me to see all conversations related to that email address. Database keeps all email addresses of specific person $ emailsof texas@examp would give me 3 views if there are 3 email addresses, I could basically review all conversations of that person. There need not be any true database like `mu` or `notmuch` as this way I find most of times what I need. I can search inside of mailboxes easily. I would not keep emails in the database like PostgreSQL, no. Emails have to be accessed by mail readers and there are just few that would be supporting databases. > > Take care of duplicates. When marketing contact database is > > growing fast, some times 1000 people per day or more. People have > > same names. Often one cannot even know what is first and what is > > last name. You may know it for your country, in other countries is > > not so. Then those people engage in a course on distance. They are > > sending me images and files as results of their course > > assignments. I have to file the files in proper folder. Because > > names are not always unique I better file it under unique IDs, and > > keep separate symlinks with names of people to such unique IDs > > whereby symlinks can be automatically updated. > > This is clearly a CRM database use case. In this situation, the CRM > should define the unique ID, and then Textmind should accept it. You > can still use the directory tree, though. Just file it under > ~/Surname-given-name/ID-number/~ for the non-unique name. Recursively > searching ~/1-Textmind/2-Linked/7-Name/2-Flat/~ for a directory named > ~/ID-number/~ will find the target even if his name changes slightly. > So you can save time by not inputting every scrap of text and files > into the CRM. That is right, good idea to file under surname/ID. I would rather prefer the approach ID/Full-Name as if directory is automatically created by its ID, so I do not need to think about it. CRM is for me not the database, it is method of management of anything related to people and I call it Central Files. I do not put text files
Re: One vs many directories
Hi Jean, > That is good and isn't it general way of sorting things? I guess that general > computer users may not be aware that they could make nice hierarchical tree > of directories. It's not that they're unaware. Everybody with a mouse and Windows Explorer tries to make good directories. It's just that Dired+Treefactor's order of magnitude improvement in speed and fluency means that the directory tree can be mind-synced as never before, making walking the tree an education in itself. With so much intelligence embedded in each level, bypassing it makes little sense. Also one should check during the walk whether key info is waiting in transit for batch refiling. For classic database tasks, I'd rather use Postgres than symlinks. I already use symlinks enough for conveniences such as connecting synonyms. Too many symlinks make paths unpredictably brittle, chilling sync dynamism, creating rigidity. Textmind is documented at http://cyberthal-docs.nfshost.com I neglected Dr. Arne's honorific.
Re: One vs many directories
* Texas Cyberthal [2020-11-21 21:02]:
> Hi Jean,
>
> > That is good and isn't it general way of sorting things? I guess
> > that general computer users may not be aware that they could make
> > nice hierarchical tree of directories.
>
> It's not that they're unaware. Everybody with a mouse and Windows
> Explorer tries to make good directories.
People try and people fail. I know hackers only on distance, I do not
know them personally face to face. Often computer users that I see in
offices like stationary, even sometimes legal office, have their
desktops overloaded of files on top of files on top of files where
majority of them are named something like unknown or whatever new-file
and similar nonsense. All sorting is taking place under Desktop on
Desktop space and it becomes mess.
> It's just that Dired+Treefactor's order of magnitude improvement in
> speed and fluency means that the directory tree can be mind-synced
Good term, mind synced. That is how it should be. In my opinion
various paradigms of file sorting should be sorted in a list similar
to those Awesome lists. Sorting files how mind thinks is how it should
be. Computer should help user to complement the mind and help in
execution of actions and not bother the mind or make mind confused
what is really the case with majority of users.
Side note: I was always sorting files, people, stuff from the command
line or from web browser into their places. And I mostly used readline
in bash for completion or finding of the selection candidate.
In Emacs I am using `ivy-mode` or `helm`, `selectrum` and similar,
Emacs offers quite good interface for completions.
And often I am completing file locations, maybe I wish to file into
this or the other subject. So the list of subjects has to be brought
up.
In X and outside of Emacs there is dmenu and I could use it even from
Emacs inside out.
(defun dmenu-completing-read (prompt collection)
;; predicate require-match initial-input history def
inherit-input-method)
"Uses external `dmenu' command for Emacs completions."
(let* ((collection (concat (string-join collection "\n") "\n"))
(file (string-to-file-force collection "/dev/shm/collection"))
(dmenu "dmenu"))
(with-temp-buffer
(call-process dmenu file (current-buffer) nil "-fn" "DejaVu:pixelsize=30"
"-l" "10" "-i" "-b" "-p" prompt "-nb" "dark goldenrod" "-nb" "black")
(string-trim (buffer-string)
(dmenu-completing-read "Subject: " '("People" "Work" "Group"))
I find dmenu as excellent tool to provide it for functions that are used within
Emacs and that may be used outside of Emacs to complement Emacs filing of files.
For example Rox filer file manager or Nautilus can invoke external command that
files the file into specific directory by using dmenu. Choose the directory by
few words, and if directory is semnatically written, file may be filed easily.
Three interfaces for selection among large line-based items were needed:
- [X] Emacs
- [X] X interface: Dmenu
- [ ] Console. I was using readline with TAB, it is not visual enough
Now I found finally `fzf`.
$ mv courier-crm114 `find Work/Computer -type d | fzf`
Then in the next step I can type "mail" or "spam" subdirectories and file it
there.
fzf is great tool for console and terminal emulators. It similar
things on console what helm does on Emacs and dmenu on X.
- [X] Console: fzf
fzf is great tool that may be used for finding stuff, filing, retrieval of
stuff, launching or opening files. Example:
$ mimeopen `locate *.org | fzf`
and similar with dmenu:
$ mimeopen `locate -d .locate.database -A Documents .org | dmenu -fn
DejaVu:pixelsize=20 -l 10 -i -b -p "Org: " -nb "dark goldenrod" -nb black `
As my files are in ~/Documents/Org/ I would find at least 185
files ending with .org there by its name and quickly open it with
emacs. Instead of "mimeopen" I could as well use emacsclient.
If you have set your mimeopen to open it by Emacs, you will
quickly locate the file and open it. Provided that Org file names
have some built-in semantics.
Re: One vs many directories
Hi Arne, *Almost* any computing cost pales, but not the computing cost of Emacs choking on rendering large files. Doubtless there are ways to mitigate that issue. I'm unsure what the tradeoffs would be. Perhaps my Spacemacs does too much prettifying of my Org buffers. But I like pretty buffers. It's easier to just stay under 1 MB file size. File opening cost should be reduced by storing text files on an SSD. A small one will do. Textmind/Exomind buffers should be left open. Thus the opening cost is paid once per session per needed file. That is acceptable. I'm not sure what kind of lagless Org database operations are required in your workflow, but I suspect they could be mostly replaced by a proper Textmind workflow and 10 Bins structure. The alternative is to do everything in a few big files. Org has too much potential to misfold or otherwise mangle huge outlines in ways difficult to spot and repair. Nor do I want to squint at endless asterisks when I could have Dired ergonomics instead. Grepping my 94 Mb 6562 files (excluding archive) Textmind for "elephantine" takes a few seconds, which is fine. Org searching for a nonexistent UID link takes a few minutes, which is why I run that search nightly, to refresh the index. My Org Agenda search scope is only 252k in 58 files and is effectively lagless. I guess I avoid the problem you're talking about by mostly excluding bulk prose from the Agenda directory. They're fundamentally different and should be handled differently. One is about human language, the other is about database metadata. The temptation to do everything inline just because Org supports it is one of Org's biggest traps. It's like the trap of trying to outline strictly when you should be rambling.
Re: Emacs-orgmode Digest, Vol 177, Issue 22
Hi Quintus, I recall with grim fondness arranging the Windows Start menu hierarchy by mouse. An inefficient experience I would never waste time on today. Voit> All relevant studies show that for file retrieval on the local computer system or local network, navigation is chosen over search in the absolute majority of cases. https://karl-voit.at/2020/01/25/avoid-complex-folder-hierarchies/ Back then, searching was a pain. However, today I hold no ill will towards desktop search, because Textmind handles the bulk retrieval affordance for which search is ill-suited. Hi McHugh, Looks like you compressed the directory hierarchy into single letters because you lacked Treefactor to iteratively batch refile stuff where it goes, so you needed to reach destinations in one move. I'm sure Vi keys could make my workflow even faster, but input speed isn't my bottleneck anyway. Nor is thought speed. It's just a question of putting in the hours. Cyborganize converts effort into intelligent action and publication, as fast as my biology can deliver productive keyboard hours. That wasn't true before I had Pubmind and 10 Bins working. The whole is greater than the parts. I'll hit another limit once I start feeling the absence of Dbmind, no doubt.
Re: One vs many directories
* Jonathan McHugh [2020-11-21 16:43]: > Texas, > > Ive been developing a paradigm over the years based upon a (recursive) 6x6 > grid > system, aligned with keybindings around the home row. Called Qiuy, I > refer to it as a "Recursive Modelling Language", given the annotations > work down to the level of functions and parameters, as well as > directory naming. Explain details please. How do you file stuff? How do you retrieve it? Side notes: > While migrating my OS (Debian -> Guix) Guix is fully free OS, GNU itself using GNU Shepherd init system with scheme as system language. > and Editor (Vim -> Emacs) Vim is just fine and Emacs too. I never switched from vi to Emacs, I use them both. And I use ed especially to edit system configurations quickly. > has muddied my workflows, I hope that my explorations with Org-Mode > still permit me to operate with a highly broad but shallow folder > structure. In any case, Im happy to be using Helm for browsing > rapidly (as you will understand reading below!). I did not understand it. Need details. > Should you have any interest I am drafting some of my thoughts re Qiuy, > as part of attendance at the upcoming Constant workshop > Bureaucracksy. Id be happy to send you some material if you wish. Yes pleas, send it. > = > HOME FOLDER DIRECTORIES: > = > 1q10fq_music > 1q10hqh_parsing How do you use that?
Re: One vs many directories
Jean Louis writes: > When there are more than 2000 people related notes, tasks, > calculations, questions arise if such better be kept in one Org file > or multiple Org files in one directory or multiple directories for > multiple Org files?! This came up multiple times in discussions. I think that it is wrong, and the reason comes down to efficiency. If you want to work efficiently, then sub-second delays matter, and having 4 files with 500 entries means that to search in them you need to open 4 files. If you have 100 files with 20 notes each, you have to open 100 files. Almost any other computing cost pales compared to opening files. My current setup has around 1200 notes in 10 files (most of them in the two main files, some of the notes are several pages long, but most take up around half a page). Using org-rifle (https://github.com/alphapapa/org-rifle) I can full-text-search them with barely perceptible delay on a system clocked down to 1 GHz. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Bug: Having '%p" in frame-title-format makes org-mode to freeze [9.4 (release_9.4-134-g0d525c @ /home/massimo/bugreport/org-mode/lisp/)]
Hi all,
I recently came across this weird issue using org-mode. Essentially
when I fold/unfold/fold some header in org-mode, pressing tab three
times,
I expect the section to fold again at the third keypress, and instead
emacs freezes. By detective work I discovered that it has to do with
having the '%p' option in
frame-title-format. The bug disappeared when I took "%p" option away
from frame-title-format.
Thank you for all you work and for any attention you will give to this
bug. I hope this message is useful.
I will now give enough info and data to reproduce the bug with a
minimal setup, and at the end of the message my emacs/org/Linux
configuration follows.
* Steps to reproduce the bug
Note that these steps only reproduce the bug when emacs runs
graphically. Using "emacs -nw" fails to reproduce the bug.
** Step 0. Prepare a folder ~/bugreport/ with the three files
"test.sh", "test.el" and "test.org" as follows
test.sh downloads org-mode and runs emacs with the test setup
cd ~/bugreport/
git clone https://code.orgmode.org/bzg/org-mode.git
cd org-mode/
make autoloads
cd ~/bugreport/
emacs -Q -l test.el test.org &
-
--- test.el loads org-mode from the repository and set frame-title-format
(add-to-list 'load-path "~/bugreport/org-mode/lisp")
(setq frame-title-format '("%p"))
-
test.org just an org file with a header
* Try to hang emacs
To hang emacs you should fold/unfold/fold the header of this section
a couple of times.
-
** Step 1. Run the test
It is sufficient to go "cd ~/bugreport/" and do "sh ./test.sh"
You should see emacs starting and opening "test.org" file, and by
running 'org-version' you could double check that the appropriate
version of org has been loaded.
** Step 2. Make emacs freeze
Go to first line in the "test.org" file and press TAB three times.
Emacs should freeze now.
* Emacs/Org/Linux configuration
Here's some more details about my environment.
Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0)
of 2020-09-19
Package: Org mode version 9.4 (release_9.4-134-g0d525c @
/home/massimo/bugreport/org-mode/lisp/)
Linux: Linux nuc2020 5.4.0-53-generic #59-Ubuntu SMP Wed Oct 21
09:38:44 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Content of /etc/lsb-release:
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04.1 LTS"
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-link-shell-confirm-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-mode-hook '((closure
(org--rds reftex-docstruct-symbol
org-element-greater-elements org-clock-history
org-agenda-current-date org-with-time org-defdecode org-def
org-read-date-inactive org-ans2 org-ans1
org-columns-current-fmt-compiled org-clock-current-task
org-clock-effort org-agenda-skip-function
org-agenda-skip-comment-trees org-agenda-archives-mode
org-end-time-was-given org-time-was-given
org-log-note-extra org-log-note-purpose
org-log-post-message org-last-inserted-timestamp
org-last-changed-timestamp
org-entry-property-inherited-from org-blocked-by-checkboxes
org-state org-agenda-headline-snapshot-before-repeat
org-agenda-start-on-weekday org-agenda-buffer-tmp-name
org-priority-regexp org-mode-abbrev-table
org-mode-syntax-table buffer-face-mode-face org-tbl-menu
org-org-menu org-struct-menu org-entities org-last-state
org-id-track-globally org-clock-start-time texmathp-why
remember-data-file
org-agenda-tags-todo-honor-ignore-options
iswitchb-temp-buflist calc-embedded-open-mode
calc-embedded-open-formula calc-embedded-close-formula
align-mode-rules-list org-emphasis-alist
org-emphasis-regexp-components
org-export-registered-backends org-modules
org-babel-load-languages org-id-overriding-file-name
org-indent-indentation-per-level
org-element-paragraph-separate ffap-url-regexp
org-inlinetask-min-level t)
nil
(add-hook 'change-major-mode-hook 'org-show-all 'append
'local)
)
(closure
(org-src-window-setup *this*
org-babel-confirm-evaluate-answer-no
org-babel-tangle-uncomment-comments
org-src-preserve-indentation org-src-lang-modes
org-edit-src-content-indentation org-babel-library-of-babel
t)
nil
(add-hook 'change-major-mode-hook 'org-babel-show-result-all
'append 'local)
)
org-babel-result-hide-spec org-babel-hide-all-hashes)
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-bibtex-headline-format-function '(closure
(org-id-locations
org-agenda-search-view-always-boolean
Re: One vs many directories
* Dr. Arne Babenhauserheide [2020-11-21 18:04]: > > Jean Louis writes: > > > When there are more than 2000 people related notes, tasks, > > calculations, questions arise if such better be kept in one Org file > > or multiple Org files in one directory or multiple directories for > > multiple Org files?! > > This came up multiple times in discussions. I think that it is wrong, > and the reason comes down to efficiency. If you want to work > efficiently, then sub-second delays matter, and having 4 files with > 500 entries means that to search in them you need to open 4 files. Hallo Dr. Arne, It maybe wrong and it depends of the approach. My approach is that I think with people and subjects, not with notes only. Subject can be special plan like ABC.org and I do not need to search notes related to that plan outside of ABC, because I do not mix things. I am searching within one file only. Things TODO are per subject or per person. Files pertaining to any person are filed in the person's folder. Somebody else deals only with personal notes and they maybe put such in various files and of course they need to search. I am thinking of "Joe Doe" and here is the flow: - press s-c (for contacts) - enter Joe Doe or Joe Doe, Berlin, etc. - among many Joe Doe, I may narrow down to right one - click F4 there is Org file for Joe Doe, enter Tasks, Transactions and whatever else, send Tasks, Notes to Joe Doe, collaborate or make agreements. I never construct or open file for a person, function is doing that. It makes the file ~/Work/People/By-ID/320431/320431.org If I need to search, I search inside of the file. - click F5 and find all other files for Joe Doe. For example contracts and similar. If I need to search there then I use find and grep and similar tools. No need for indexing. Files are mostly sorted by data how they come. There is same flow if I think of a group of people with the difference that if I need a person I still need to find the person in the list of people. So in general I never need to use some general search through Org files or any other files as my way of thinking begins with People or Groups and that narrows what has to be searched. > If you have 100 files with 20 notes each, you have to open 100 > files. You maybe mean opening automatically files and searching through such. I do not find Org system comfortable for that. I see it tries to remember files, IDs, and agenda among various files. Not that I find it comfortable. My way of thinking is always People or Groups, and from there various searches are performed and that narrows drastically the subject that has to be searched. > My current setup has around 1200 notes in 10 files (most of them in the > two main files, some of the notes are several pages long, but most take > up around half a page). People are all over the world using Org in various manners and every day I find different ways of using Org mode. On my side I almost never put notes in Org files. As by definition from Wordnet, note is "brief written record". If it is brief written record I do record it in the database under Notes related to person, or group or opportunity or some case, or it can be related to anything else. Then again I think of person and I can get all notes for the person. Org files I am using mostly for planning and project administration. There are almost no notes, just instructions on how to execute specific steps and there are headings with articles or instructions that do not need execution. There are no records that are saved for later or that do not need any execution or learning. Org files on my side thus offer: - hierarchical knowledge database that may be shared with other people, and is almost always directed to sharing with other people - plan and project administration with tasks, whereby such subtrees can be shared with other people and for multiple times executed If those are called notes by other people, alright fine. On my side those are not just notes. Notes I relate to objects like People, Groups, Opportunities, Cases, so I put some notes there. But general dynamical knowledge repository is better, that is where I mention HyperScope. It is like database of hyperlinks that hyperlink to anything, it is more abstract and I find that approach also versatile. No need to define specific database for notes, all I do is defining hyperdocument type to be "Note" and I can link it to anything else. Semantic Synchrony https://github.com/synchrony/smsn Semantic Synchrony is using maybe better type of a database I do not know, I am using SQL, SMSN uses graph database. > Using org-rifle (https://github.com/alphapapa/org-rifle) I can > full-text-search them with barely perceptible delay on a system > clocked down to 1 GHz. That is great tool for many. Org files are for me to write complex documents like 850 kb something like a organizational knowledge, training for each staff member, plans, projects, tasks,
Re: One vs many directories
* Texas Cyberthal [2020-11-21 18:46]: > I guess I avoid the problem you're talking about by mostly excluding > bulk prose from the Agenda directory. They're fundamentally different > and should be handled differently. Well said. > One is about human language, the other is about database metadata. That is so. In fact the properties, custom ID and else inside is mostly visually disturbing me though it is necessary. Before knowing about Org I have already had a system of planning, projects, tasks, and all that could be related to people, groups and what other else things. This part of Org that is dependant on meta data is better managed through dedicated databases. > The temptation to do everything inline just because Org supports it > is one of Org's biggest traps. It's like the trap of trying to > outline strictly when you should be rambling. Temptation is brought through the usage of Org as there are not so many choices beyond it. Org is meant to keep simple things simple. Data being managed may easily grow into complex thing.
