From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thorsten Jolitz Subject: Re: [NEW FEATURE] org-hlc.el - hidden-lines-cookies (hlc) for Org-mode Date: Fri, 24 May 2013 19:45:41 +0200 Message-ID: <87ip28b7ay.fsf@gmail.com> References: <87zjvmiw1k.fsf@gmail.com> <6219E7E2-9951-4B05-A977-DE0DD1B120BE@gmail.com> <87a9nkcwnc.fsf@gmail.com> <86a9nktm2m.fsf@iro.umontreal.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([208.118.235.92]:58077) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ufw42-0000XW-C7 for emacs-orgmode@gnu.org; Fri, 24 May 2013 13:46:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ufw3z-00009h-RC for emacs-orgmode@gnu.org; Fri, 24 May 2013 13:46:02 -0400 Received: from plane.gmane.org ([80.91.229.3]:48963) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ufw3y-00009Q-Se for emacs-orgmode@gnu.org; Fri, 24 May 2013 13:45:59 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Ufw3u-0007JX-5J for emacs-orgmode@gnu.org; Fri, 24 May 2013 19:45:54 +0200 Received: from e178061221.adsl.alicedsl.de ([85.178.61.221]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 24 May 2013 19:45:54 +0200 Received: from tjolitz by e178061221.adsl.alicedsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 24 May 2013 19:45:54 +0200 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org François Pinard writes: Hi Francios, > You're quite generous when you say "full fledged" :-). There are many > details in which I find org-weights.el unsatisfactory, but as it is > sufficient as it stands for my day-to-day usage, I'm not overly pushing > on it (the pun is purely accidental). > >> | * Header 1 * 2 + 1... > >> | ## * Header 1 [#1] > > I find the "* 2 + 1" far too verbose, in that it uses too much horizontal > space, I much prefer the compact aspect of "[#1]". The weights are a bit heavy, and I had to move them to column 65 to make them fit in a vertically splitted screen. But they carry more information of course, the question is if one can process this information quickly enough, or if one single number is not enough to give an impression of the subtrees 'weight'. Or maybe ,---------------------- | * Header 1 [2/1]... `---------------------- is easier on the eyes than ,----------------------------------------------- | * Header 1 * 2 + 1... `----------------------------------------------- > What would be ideal, but I do not know if it can be organized, would > keep the weights or hidden-lines information always glued to the > ellipsis, and not hiding any underlying text as org-weights currently > does. On the other hand, there are some virtue to the vertical > alignment of weight information. Sigh! Nothing is perfect... It would be easy to make the position of the weight/cookie a user option - either direcctly behind the headline text, or aligned at a certain column. >> [...] shows the overlay-info for *all* headlines except the one where >> point is on. > > That exception is a sad and questionable workaround, for being able to > edit the current line. When, in normal and standard Org mode, I edit a > line which has an ellipsis at the end, I may edit the line like any > other one without seeing undesired effects. org-weights should be > equally capable, and there should be no reason (ideally) to hide the > information for the line where the point is, merely for editing to work. I would still like to have my original idea (which was actually a user request for outshine.el by Jonas Bernoulli): show the number of hidden lines only when the headline is folded, and update with every visibility change. >> one problem I hit is that a visibility change does not uptdate all >> cookies/weights at once, they are only updated headline per headline >> when point is moved up and down. Is that for performance reasons? > > See the Caveats section at the end of org-weights documentation. > Normally, the information to be updated may be minimized to the header > above the line holding point, and then, recursively up. But there is a > bug in this optimization when a header is demoted (as explained in > Caveats). Another performance-related detail is the quadratic behaviour > which may be seen in big, deeply nested Org files: it could be avoided > by cleverly saving (in a hidden way) information on computations already > done, and reusing it instead of recomputing it many times. But as usual > with most cached optimization, it is difficult to get fully right. This task seems to bring Emacs to its limits, at least in 5000+ lines outshine buffers (e.g. my init.el). So maybe its not that suited for a visibility-change hook, but rather for occasional activation by an explicit user command? -- cheers, Thorsten