Re: [O] are super-hidden technical blocks required?
Hi Torsten, thanks for the mock-ups -- very useful to get a quick overview. I'm still reluctant to implement what you propose, because the two issues (cycling and hiding) are still too intertwined for me. Here is how I would like the problems: 1. The fact that property drawers with only technical properties are shown when cycling. 2. The fact that property drawers with only technical properties are shown altogether. 3. The fact that technical properties are shown when unfolding a drawer. 4. The fact that technical properties are shown altogether. We started from (4), moved to (3), then stumbled on (1) and (2). It seems to me that (4) is fundamental -- other issues depend on it. It also occurred to me you only want this kind of feature when you are actually editing your org file -- not when it is processed by a third-part tool or by the Agenda. Chances are that you don't want the properties to be always invisible... and editing HIDE_PROPS just to hide/unhide some properties is not handy. So I implemented this simple solution, now available in the git repo: M-: (setq org-custom-properties '(ID)) RET M-x org-toggle-custom-properties-visibility RET will hide all :ID: properties in the buffer. The same command again will show them. If `org-catch-invisible-edits' is non-nil, trying to edit an invisible property will throw a question/error. I hope this suits most people needs in this thread. Thanks again for triggering this dicussion! -- Bastien
Re: [O] are super-hidden technical blocks required?
Torsten Wagner torsten.wag...@gmail.com writes: So how to satisfy both views, a clutter free view and the awareness of what is saved in your file? I think we must untangle two issues here: one is about the visibility by itself (what should be visible, invisible, how visible, how invisible?) and the other one is about cycling (changing visibility interactively.) For example, if a user wants to consider that a drawer doesn't make an entry non-empty while cycling, this can be done, avoiding cluttering the with stuff you don't want when cycling. But that's a different problem than the one of visibility /by itself/. I know I'm making the question even more complex, but that's hopefully just a temporary step in this discussion. -- Bastien
Re: [O] are super-hidden technical blocks required?
Hey Bastien, On 7 August 2012 19:23, Bastien b...@gnu.org wrote: that a drawer doesn't make an entry non-empty while cycling, ohhh you challenge us... does not ... non-empty is in fact the same like if there is only a drawer, the entry is still empty right ?! Yes, I agree that should be separated. Maybe an idea would be a rule like if all properties in a drawer are marked as hidden and there is nothing else for the particular entry (no body), do not open the entry for the next cycling rounds. I just tested a bit and org-mode is clever enough already to avoid any text-insertion before the property drawer if text get added to a collapsed entry. Thus, this rule just might work and hide technical properties completely during cycling. Combined with a #+HIDDEN_PROP: line each and everyone can adjust individually how much and what he likes to hide. #+HIDDEN_PROP: * - all properties are hidden would be the extreme and all property drawers will be hidden in case they are the only element of a entry. In case other elements are included, they collapsed drawer line will be dimmed by a different face to indicate that only hidden properties are included #+HIDDEN_PROP: this means no properties are hidden would be the other extreme and nothing would be hidden (that essentially would represent the present state). I created two mock-ups. One shows the present solution and the other shows how certain properties can be marked hidden and which effect does this have on different level and combinations. Hope that helps within this discussion. I choose a arbitrary colour scheme to make it rather good visible. Torsten attachment: org_hidden_drawer_mockup_proposed_method.pngattachment: org_hidden_drawer_mockup_orignal.png
Re: [O] are super-hidden technical blocks required?
Nice! I like this approach. The only slight change I would make is to the All entries are unfolded one level. If there are only hidden properties but there is other content, show the other content but not the PROPERTIES drawer: * All entries are unfolded one level ** Only hidden properties with other content This is more content The :PROPERTIES: is not shown. Question -- are you proposing a new step in cycling that opens all property drawers, or is this already available via some command or setting? I've never seen a way to open everything including PROPERTIES via Tab or S-Tab cycling. ...cj On 8/7/12 9:20 AM, Torsten Wagner wrote: Hey Bastien, On 7 August 2012 19:23, Bastien b...@gnu.org wrote: that a drawer doesn't make an entry non-empty while cycling, ohhh you challenge us... does not ... non-empty is in fact the same like if there is only a drawer, the entry is still empty right ?! Yes, I agree that should be separated. Maybe an idea would be a rule like if all properties in a drawer are marked as hidden and there is nothing else for the particular entry (no body), do not open the entry for the next cycling rounds. I just tested a bit and org-mode is clever enough already to avoid any text-insertion before the property drawer if text get added to a collapsed entry. Thus, this rule just might work and hide technical properties completely during cycling. Combined with a #+HIDDEN_PROP: line each and everyone can adjust individually how much and what he likes to hide. #+HIDDEN_PROP: * - all properties are hidden would be the extreme and all property drawers will be hidden in case they are the only element of a entry. In case other elements are included, they collapsed drawer line will be dimmed by a different face to indicate that only hidden properties are included #+HIDDEN_PROP: this means no properties are hidden would be the other extreme and nothing would be hidden (that essentially would represent the present state). I created two mock-ups. One shows the present solution and the other shows how certain properties can be marked hidden and which effect does this have on different level and combinations. Hope that helps within this discussion. I choose a arbitrary colour scheme to make it rather good visible. Torsten
Re: [O] are super-hidden technical blocks required?
Hey Christopher,
* All entries are unfolded one level
** Only hidden properties with other content
This is more content
The :PROPERTIES: is not shown.
I left it there, because some people claimed the dislike to hide
property drawers to much. A different face colour might be a good
compromise.
Question -- are you proposing a new step in cycling that opens all property
drawers, or is this already available via some command or setting? I've
never seen a way to open everything including PROPERTIES via Tab or S-Tab
cycling.
No, I do not know how to open drawers by tab-cycling and would not
propose it. This view is just to show the most verbose way by open
each property drawer in addition manually.
The nice part on this solution, change the properties in the
HIDDEN_PROP line and you can get a complete different view only focus
on what is important for a certain task. It would rather easy to adapt
it quickly to the different requirements. I believe this goes even
further rather then only hide technical properties. E.g. entries
with many properties could be limited to show only what you are
working on.
See for example the following entry which I stole from Thomas S. Dyes
post about org-bibtex.el
** {Cultural Resources of Naval Air Station, Barbers
:PROPERTIES:
:TYPE: book
:CUSTOM_ID: tuggle94:_cultur_resour_naval_air_station_barber_point
:MONTH:December}
:ADDRESS: Honolulu
:SERIES: Prepared for Belt Collins Hawaii
:YEAR: 1994
:PUBLISHER: iarii
:AUTHOR: {H. David Tuggle and M. J. Tomonari-Tuggle}
:END:
This has many properties. If you have hundred of this entries you
might be interested to see only AUTHOR and YEAR line for some task. I
am aware of the column view but with the proposed method people could
get a plain text view only showing what they just need. If the
HIDDEN_PROP line could include regular expressions one could even
negate a list to get a hide all but behavior. To get
** {Cultural Resources of Naval Air Station, Barbers
:PROPERTIES:
:YEAR: 1994
:AUTHOR: {H. David Tuggle and M. J. Tomonari-Tuggle
...
:END:
You simple would have to add #+HIDDEN_PROP: ^[YEAR AUHOR]
Torsten
Re: [O] are super-hidden technical blocks required?
Separating out the issue of how to hide and expose the content, why not use s-expressions for the hidden content? Org is built on a lisp engine and these will fit nicely into automation. It avoids a lot of parsing and other headaches, and an s-expression can hold any of the discussed information. It could be an a-list that is designed for the purpose, or it could be a list structured like the custom configuration list used in emacs config. I think of the latter when considering the potential to steal code for using the contents, updating the contents, and providing a user interface when that is needed. It also provides a model for sharing the list among independent groups of developers with overlapping interests. It permits automatically generated comments, advice, and warnings for those who look at it, much like you find when looking over the tail end of a .emacs file. The property construction could then be a simple :HIDDEN-ALIST-PROPERTIES: (( stuff )) It would be very unreadable and unfriendly to the novice, but that is already a characteristic of the data being discussed. R Horn rjh...@alum.mit.edu
Re: [O] are super-hidden technical blocks required?
On 8/6/2012 2:16 PM, Allen S. Rout wrote: One common use would be to store the creation last-modification dates of each entry. I've tried various ways of doing it and they all were too obtrusive to use on _every_ entry. Time-stamping of all entries would be extremely useful, just as time-stamping of files is. But I don't want to see the timestamps during normal Org usage. As a user, if your code is decorating my tree, I want to know it. If you hide it, I'd be mad. Org is my life in plain text, not WordPerfect with reveal-codes. For decorations that change behavior, e.g. export options or inherited properties, sure. But meta-information such as creation/modification times or unique node ids, which do not change behavior and are known to be associated with every node, displaying them is a distraction. If you already know that every node has a creation time, what is added by seeing a :PROPERTIES: line for that node? If anything, it obscures nodes that do have unique properties you want to know about.
Re: [O] are super-hidden technical blocks required?
On 8/2/2012 11:10 AM, Bastien wrote: If the whole point is to make some properties less visible, why not a solution based on fontification? We could have a user-defined regexp to highlight (or dim) certain properties. That would still leave the :PROPERTIES: line visible, which is problem for universal properties assigned to every entry. I don't believe in a solution that would change the current flow of cycling through drawers. I feel that's too much. I agree. Showing hidden drawers is a rarely-used operation and should be a separate command, not part of the commonly-used cycling.
Re: [O] are super-hidden technical blocks required?
Hello, On Sun, Aug 5, 2012 at 11:01 PM, Ilya Shlyakhter ilya_...@alum.mit.edu wrote: On Sun, Aug 5, 2012 at 10:46 PM, Torsten Wagner torsten.wag...@gmail.com wrote: I can see the point that the property drawer header can be annoying too. Actually, when I used orgmobile for the first time I was not too happy to see all this property drawers suddenly appearing in my files. Alternatively to a new kind of drawer, I would think of the HIDDEN_PROP: line and an additional method which hides a drawer even more if it only contains hidden property elements. That could be done, for example, by the already mentioned custom face. That is, a drawer is clearly visible if it contains properties intend to be read/changed by the user (not marked invisible). A drawer is less visible, if it contains only properties marked as hidden. That would be great. Except, if a PROPERTIES drawer holds only hidden properties, it would be best to completely hide the :PROPERTIES: line (using outline-flag-region), rather than display it in a dimmed font. So that, unless you explicitly ask to reveal these lines, you edit the file as if they weren't there. The issue I can see with completely hiding :PROPERTIES: line is that you would then run the risk of adding text at the wrong location (between the headline and the drawer for example). At the moment when the drawer is folded you know if the point is before, within or after the drawer (even though you still can remove parts of :end: by accident with backspaces), if it isn't visible at all you don't have that ability.
Re: [O] are super-hidden technical blocks required?
Hi Folks, I thought I'd throw in my 2c on the topic. I work on org-toodledo which syncs TODO items with Toodledo.com. On first sync, it creates adds a ToodledID property to track the ID assigned by the server. In my use case, that majority of TODO items have *no* other properties. As such, many items have a PROPERTIES drawer with just the one entry. What I see is visual clutter. Many of my TODO items are also very small -- often no body at all. So the only thing beneath the item is the property drawer plus other properties like DEADLINE/SCHEDULED/CLOSED. When trying to browse my todo list, it gets a little painful when every other line is :PROPERTIES:..., or DEADLINE, etc. I rarely (never?) edit any of these properties directly manually. I either modify them via agenda mode, keys (C-c C-s), or via column view that pulls out interesting properties that I like to edit. So for me, I want the entire *drawer* to disappear, as well as SCHEDULED/DEADLINE and CLOSED lines. I've personally thought there should be an extra step in the visibility cycling: TAB - FOLDED - CHILDREN - SUBTREE - PROPERTIES S-TAB - OVERVIEW - CONTENTS - SHOW ALL (minus PROPS) - PROPERTIES ...cj On 8/1/12 9:19 PM, Torsten Wagner wrote: Hey Bastien, thanks for keeping the topic up. Well, I guess people who are dealing with import/export from third-party programs might have an idea how to use this functionality (and can tell us how useful this would be). I can try to contact the authors of mobileorg for iphone and android as well as some other authors of sync-tools (if they are not already contributing to this discussion). Lets see what is there opinion. All the best Torsten On 1 August 2012 22:29, Bastien b...@gnu.org wrote: Hi Thorsten, thanks for the detailed example. As I said, I tend to be conversative about such topics. Not because I'm already too old, but because this is often not worth the time-to-implement/complexity-in-code. So I'm still open to read a very compelling case where tech properties need to be hidden... Of course, need is subjective -- let's say if you manage to have at least 3 friends complaining about tech properties being visible when unfolding a drawer, I'm all ears :) -- Bastien
Re: [O] are super-hidden technical blocks required?
On Mon, Aug 6, 2012 at 8:12 AM, Jonathan Leech-Pepin jonathan.leechpe...@gmail.com wrote: The issue I can see with completely hiding :PROPERTIES: line is that you would then run the risk of adding text at the wrong location (between the headline and the drawer for example). At the moment when the drawer is folded you know if the point is before, within or after the drawer (even though you still can remove parts of :end: by accident with backspaces), if it isn't visible at all you don't have that ability. Maybe, Org should allow text between the headline and the drawer? Is there a reason not to? Alternately, if a UNIVERSAL_PROPERTIES drawer was always on the line immediately following the headline, there would be no way to place text between it and the headilne. Also, maybe a hidden drawer could be protected by setting character properties on it to make it unmodifiable?
Re: [O] are super-hidden technical blocks required?
On 08/04/2012 02:10 PM, Ilya Shlyakhter wrote: One common use would be to store the creation last-modification dates of each entry. I've tried various ways of doing it and they all were too obtrusive to use on _every_ entry. Time-stamping of all entries would be extremely useful, just as time-stamping of files is. But I don't want to see the timestamps during normal Org usage. As a user, if your code is decorating my tree, I want to know it. If you hide it, I'd be mad. Org is my life in plain text, not WordPerfect with reveal-codes. - Allen S. Rout
Re: [O] are super-hidden technical blocks required?
On Mon, Aug 6, 2012 at 8:16 PM, Allen S. Rout a...@ufl.edu wrote: Org is my life in plain text, not WordPerfect with reveal-codes. I always wondered what Ford Prefect is doing in the Org Manual and why he is related with Org. :-)) Michael
Re: [O] are super-hidden technical blocks required?
Hi, I would say this discussion is just showing how difficult it becomes to save all extra information provided by more and more 3rd party tools in a smart way in plain-text. I can understand both arguments * hide stuff which is not useful or needed for the user vs. * its my data and my file, I want to know what is stored in it. The extra property line is really verbose if the only element inside is a ID, a timestamp, or some other technical stuff. Imagine a single list of task each only a view words on a single line. The property drawer adds three lines to this just to add an ID. Even collapsed it still doubles the amount of lines. However, hiding even the collapsed property line has the danger that people might forget about it and that devs need to make sure that by any possible way of copy and pasting (and emacs knows many ways) those hidden lines are not left behind, that text get not added in between and the syntax remain valid for all kind of operation. I am unsure how to deal with this. Any kind of font face, special character, etc. on the next line below the title does not really give any win. There will be still a second line per tree-node. Adding something to the title line itself is tricky too. The title line is rather full already with all the possible features. I still prefer the proposed selective masking of properties to hide them. In addition maybe a flag can be set to + hide a property drawer line, + set a different font face, + or leave it as it is for the special case that the property drawer only contains hidden properties. But I frighten that this, even it might be the most flexible solution, might also be the most complex one to implement. So how to satisfy both views, a clutter free view and the awareness of what is saved in your file? Torsten
Re: [O] are super-hidden technical blocks required?
Hi Ilya, Ilya Shlyakhter ilya_...@alum.mit.edu writes: But I don't want to see the timestamps during normal Org usage. What do you think of hiding them by having a new face for properties matching a custom regexp? This has the advantage of letting the user decide what to do with such properties: either hiding or highlighting them. This is also easier to implement. -- Bastien
Re: [O] are super-hidden technical blocks required?
On 8/5/2012 5:16 AM, Bastien wrote: Hi Ilya, Ilya Shlyakhter ilya_...@alum.mit.edu writes: But I don't want to see the timestamps during normal Org usage. What do you think of hiding them by having a new face for properties matching a custom regexp? This has the advantage of letting the user decide what to do with such properties: either hiding or highlighting them. This is also easier to implement. Then _every_ entry will still have a PROPERTIES drawer. The problem wasn't what's in the drawer (which you hardly ever open), but having to see (and step around) that PROPERTIES line on every entry. What about a HIDDEN_PROPERTIES drawer that, when folded, folds completely (so that its title line is hidden too), and have a key to reveal such drawers (the way M-tab opens archived entries)?
Re: [O] are super-hidden technical blocks required?
Hello, What about a HIDDEN_PROPERTIES drawer that, when folded, folds completely (so that its title line is hidden too), and have a key to reveal such drawers (the way M-tab opens archived entries)? This is begging for problems. At some point, an user will start to notice weird behaviour he cannot explain from, let's say, the exporter, because he will have completely forgotten about one totally hidden drawer setting export options. I don't think anything should be made totally invisible. There should always be visual clues for such things. PROPERTIES drawer is as hidden as it can decently be. Since its contents are mostly for Org internals, the average user is, usually, not supposed to expand it. If you often need to have a look at some properties, you may use column view instead. Regards, -- Nicolas Goaziou
Re: [O] are super-hidden technical blocks required?
On Sun, Aug 5, 2012 at 6:20 PM, Nicolas Goaziou n.goaz...@gmail.com wrote: What about a HIDDEN_PROPERTIES drawer that, when folded, folds completely (so that its title line is hidden too), and have a key to reveal such drawers (the way M-tab opens archived entries)? This is begging for problems. At some point, an user will start to notice weird behaviour he cannot explain from, let's say, the exporter, because he will have completely forgotten about one totally hidden drawer setting export options. I don't think anything should be made totally invisible. There should always be visual clues for such things. But if _every_ entry has a visible PROPERTIES drawer (because a creation and last-modification dates of the entry are stored there), then entries for which custom export options were set no longer stand out. Just as, if you BOLD every word in a document, BOLD no longer acts as a highlight. So, I agree that unique customizations should lead to a visible indicator. But for properties that aren't really customizations ( creation date, modification date, unique ID ), a visible indicator only clutters things without acting as a useful highlight. So, what about making a UNIVERSAL_PROPERTIES drawer that is normally completely hidden, unless you explicitly reveal it?
Re: [O] are super-hidden technical blocks required?
Hey, during this discussions people already claimed that they would prefer to know what is stored and I can understand this. That was the reason for the proposal of a HIDDEN_PROP: line to mark certain properties hidden. The benefit of this approach, people are actively aware of what they hide and they can hide whatever they want, even stuff which they might under other working schemes. E.g., for a certain workflow they might prefer to hide each and all properties. I can see the point that the property drawer header can be annoying too. Actually, when I used orgmobile for the first time I was not too happy to see all this property drawers suddenly appearing in my files. Even proposing it first, I would not suggest to introduce a second kind of drawer anymore. Chances are great that people start mixing informations between two different drawers and then stuff could get ugly and messy. It also introduce much new syntax and bug-fixing, problem-solving, and further improvements have to be done for two almost identically cases. Alternatively to a new kind of drawer, I would think of the HIDDEN_PROP: line and an additional method which hides a drawer even more if it only contains hidden property elements. That could be done, for example, by the already mentioned custom face. That is, a drawer is clearly visible if it contains properties intend to be read/changed by the user (not marked invisible). A drawer is less visible, if it contains only properties marked as hidden. Hidden properties do not reveal by the normal way of opening a drawer. However, there presence might be indicate by a ... line at the end. A special key-combo reveals them (e.g. for debugging, or as some kind of expert-mode). That would really give the largest amount of flexibility, is backward compatible, does not introduce to much new syntax (just a new header parameter) and people can easily change what should be visible and invisible by changing one single line. BTW. Timestamps of the last changes are really a good example for a hidden property. I was thinking already of a hashtag created by the title and body of a node. That could be compared by synctools with the present hash and thus, local changes could be identified. If I just would now more about elisp ;) Greetings Torsten
Re: [O] are super-hidden technical blocks required?
On Sun, Aug 5, 2012 at 10:46 PM, Torsten Wagner torsten.wag...@gmail.com wrote: I can see the point that the property drawer header can be annoying too. Actually, when I used orgmobile for the first time I was not too happy to see all this property drawers suddenly appearing in my files. Alternatively to a new kind of drawer, I would think of the HIDDEN_PROP: line and an additional method which hides a drawer even more if it only contains hidden property elements. That could be done, for example, by the already mentioned custom face. That is, a drawer is clearly visible if it contains properties intend to be read/changed by the user (not marked invisible). A drawer is less visible, if it contains only properties marked as hidden. That would be great. Except, if a PROPERTIES drawer holds only hidden properties, it would be best to completely hide the :PROPERTIES: line (using outline-flag-region), rather than display it in a dimmed font. So that, unless you explicitly ask to reveal these lines, you edit the file as if they weren't there.
Re: [O] are super-hidden technical blocks required?
On 7/31/2012 9:23 AM, Robert Horn wrote: I agree. The real use needs more clarification. Things like ID are already well hidden as :PROPERTIES: until the user explicitly opens the drawer for viewing. I don't understand the need to hide those further, so a better explanation of why is needed. One common use would be to store the creation last-modification dates of each entry. I've tried various ways of doing it and they all were too obtrusive to use on _every_ entry. Time-stamping of all entries would be extremely useful, just as time-stamping of files is. But I don't want to see the timestamps during normal Org usage.
Re: [O] are super-hidden technical blocks required?
If the whole point is to make some properties less visible, why not a solution based on fontification? We could have a user-defined regexp to highlight (or dim) certain properties. I don't believe in a solution that would change the current flow of cycling through drawers. I feel that's too much. Patch welcome, -- Bastien
Re: [O] are super-hidden technical blocks required?
Hi, On Mon, Jul 30, 2012 at 10:42 AM, Ivy Foster joyfulg...@archlinux.us wrote: On 30 Jul 2012, at 11:26 am +0900, Torsten Wagner wrote: Hi, Hi, [Because of the problems of syncing and interaction with third-party programs] I was wondering if it would be time to switch org-mode from text to some sort of XML. I mostly lurk on this list, but reading the preceding proposal I figured I should note that, as a user, one of the key features of org-mode is its lovely simplicity of syntax and interface. If I really wanted to keep my files in hand-hacked or generated XML, I could, but I'd much rather keep 'em in, well, org (-: . Would it help [alleviate the problem of property-blocks containing mixed user technical data] to introduce a technical-property block which only contains information intend to be used by other programs and parsers? Sounds like an interesting idea. It sounds interesting however my first instinct is that it will not be easy to make the distinctions. Is :ID: meant as technical-data or user-data? Columns and Archive properties are more 'technical', yet they are for use by Org. With the new exporter/org-element you retrieve the properties using =org-element-property= so the unneeded properties don't need to be parsed by the exporters. This blocks could be hidden under all normal means unlike really someone want to see them and hit a special key-combo. Hmm, personally I'd rather have it visible but clearly labeled. Transparency is nearly always a good thing. Agreed. If it's there I'd want to know it was there. the :ARCHIVED: tag does well enough at keeping content hidden for that purpose, but you still see that it is present. (So just don't open the drawer unless you need it.) It's great that you're thinking about this stuff, and I'll look forward to seeing where these ideas go. Cheers, iff Regards, Jon
