possible bug

possible bug

[Pete Phillips]

Evenin' all.  

(for all you UK-based 40-somethings and over, bet that brings back
Saturday night telly! for the rest, it was how "Dixon of Dock Green"
used to introduce the
programme. http://en.wikipedia.org/wiki/Dixon_of_Dock_Green)

I'm having two problems with org-mode.

Problem 1
=========
In org-agenda-custom-commands I have the 's' argument defined as:

 ("s" "SMTL Stuff"
  ((tags "'(time up tags-up)")
   (tags "Office")
   (tags "LaptopS")
   (tags "CAG")
   (tags "Q2")
   (tags "TG")
   (tags "WHS")
   (tags "WaitingS")
   (tags "SometimeS")
   ... bunch of other tags removed .....
   (agenda)))

If I am in my TODO.org file, and have everything collapsed except the
three top level items, and I hit C-c a s, I only get ONE of each tag
specified above displayed in the buffer.  If I hit <Shift><Tab> and
*then* run the command, I get all of the tagged items for each tag. I
can of course get around it by making sure I expand the whole outline
first of all, but suspect it shouldn't work like this.

Problem 2 
========== 

After a while, hitting C-c a s just throws the CPU into 100%
utilisation, and it doesn't come back.  It is interruptable with ^G.
Exiting emacs and starting it again make it work OK.

Trying to make it happen before I send this email, I can't, of course!
However, just before I started writing this email I had to restart emacs
because of just that problem.

I'm using 0rg-mode 4.49 and emacs 22.0.50.1 from CVS.


Regards,
Pete

Possible bug

[Richard Stallman]

Would someone like to take a look at this
and see if there is a bug?

To: bug-gnu-emacs@gnu.org
From: Dan Jacobson <jidanni@jidanni.org>
Date: Thu, 04 Jan 2007 02:32:38 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Re: see compilation results in a single window
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed 
	version=3.0.4

> But wait. What if I want to be left looking at the top of the
> compilation buffer, instead of following its tail?

< That should be the default behavior; did you try in "emacs -Q"?

< The variable compilation-scroll-output controls whether Emacs tracks
< the tail of the messages or not.

$ emacs -Q #using snapshot of late Sep 2006, sorry
(set-variable (quote compilation-window-height) 111 nil)
(compile "seq 222" nil)
And it still tracks the bottom, even though
compilation-scroll-output is nil, as default.

Re: Possible bug

[Robert J. Chassell]

    < The variable compilation-scroll-output controls whether Emacs tracks
    < the tail of the messages or not.

    $ emacs -Q #using snapshot of late Sep 2006, sorry
    (set-variable (quote compilation-window-height) 111 nil)
    (compile "seq 222" nil)
    And it still tracks the bottom, even though
    compilation-scroll-output is nil, as default.

Using
Today's GNU Emacs CVS snapshot, Thu, 2007 Jan  4  11:19 UTC
GNU Emacs 22.0.92.14 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
started with

    /usr/local/src/emacs/src/emacs -Q -D \
    --eval '(setq-default mode-line-buffer-identification
            (quote (#("%14b" 0 4 (face (:weight normal))))))' \
    -fn "-Misc-Fixed-Medium-R-Normal--20-200-75-75-C-100-ISO8859-1"

in a compile with 

    (setq compilation-scroll-output nil)

point stays at the top of the *compilation* buffer window;
and in a compile with

    (setq compilation-scroll-output t)

point tracks the bottom.

This is what is supposed to happen and no change is needed for the
current CVS Emacs.

    (set-variable 'compilation-window-height 111 nil)

sets compilation-scroll-output to a non-nil value, so we should expect
point to track the bottom.  As describe-function says

    (set-variable VARIABLE VALUE &optional MAKE-LOCAL)

    Set VARIABLE to VALUE.  VALUE is a Lisp object.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Possible bug

[Mark Tilford]

Does this happen for anyone else?

1)  Fill a window with about two screenfuls of text.
2)  Scroll down to the bottom.
3)  Position another window so it covers part of the first few lines.
4)  Hold the up arrow until the window scrolls.
5)  The parts of the text that were hidden by the other window will
not be drawn.

Re: Possible bug

[TheFlyingDutchman]

On Aug 10, 2:58 pm, Mark Tilford <ralphmerri...@gmail.com> wrote:
> Does this happen for anyone else?
>
> 1)  Fill a window with about two screenfuls of text.
> 2)  Scroll down to the bottom.
> 3)  Position another window so it covers part of the first few lines.
> 4)  Hold the up arrow until the window scrolls.
> 5)  The parts of the text that were hidden by the other window will
> not be drawn.

What OS and version of Emacs are you running? On Windows I can't hit
the up arrow without Emacs becoming the top window and hiding the
other window. But all text displays and scrolling back up I don't see
any non-displayed text with Emacs 23.2.1 on Windows 7.

Re: Possible bug

[Michal Sojka]

On Tue, 10 Aug 2010, Mark Tilford wrote:
> Does this happen for anyone else?
> 
> 1)  Fill a window with about two screenfuls of text.
> 2)  Scroll down to the bottom.
> 3)  Position another window so it covers part of the first few lines.
> 4)  Hold the up arrow until the window scrolls.
> 5)  The parts of the text that were hidden by the other window will
> not be drawn.

Hi,

you didn't write on which platform you have these problems. It doesn't
happen for me on Linux/XFCE.

-Michal

Re: Possible bug

[Mark Tilford]

ii  emacs23-common                                  23.1+1-4ubuntu7


On Thu, Aug 12, 2010 at 9:56 AM, Michal Sojka <sojkam1@fel.cvut.cz> wrote:
> On Tue, 10 Aug 2010, Mark Tilford wrote:
>> Does this happen for anyone else?
>>
>> 1)  Fill a window with about two screenfuls of text.
>> 2)  Scroll down to the bottom.
>> 3)  Position another window so it covers part of the first few lines.
>> 4)  Hold the up arrow until the window scrolls.
>> 5)  The parts of the text that were hidden by the other window will
>> not be drawn.
>
> Hi,
>
> you didn't write on which platform you have these problems. It doesn't
> happen for me on Linux/XFCE.
>
> -Michal
>

Possible bug

[Subhan Michael Tindall]

[-- Attachment #1: Type: text/plain, Size: 1446 bytes --]

I'm not sure if this counts as a bug or not:

If I run a custom agenda (eg. "R") with sticky agendas, it displays in an buffer with the name
*Org Agenda (R)*
If this buffer is then renamed to e.g.
(rename-buffer "*R-Agenda*")
*R-Agenda*
And is then refreshed by hitting r, the agenda is properly rebuilt BUT in a new buffer named *Org Agenda(R)*, resulting in two differing agendas.

Is this appropriate behavior? It seems that rebuilding the agenda should respect the current buffer name. I'm very new at programing for lisp, so I'm not sure I'm using the right functions here.

I've poked around a bit in the code, but my elisp-fu is quite weak. I couldn't find an easy way to pass a buffer name in to org-agenda to be used, nor was it entirely clear to me how to modify org-agenda to grab & respect the buffer name when rebuilding a 'sticky' one.





This message is intended for the sole use of the individual and entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended addressee, nor authorized to receive for the intended addressee, you are hereby notified that you may not use, copy, disclose or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete the message.  Thank you.

[-- Attachment #2: Type: text/html, Size: 3802 bytes --]

Re: Possible bug

[Nicolas Goaziou]

Hello,

Subhan Michael Tindall <SubhanT@familycareinc.org> writes:

> I'm not sure if this counts as a bug or not:
>
> If I run a custom agenda (eg. "R") with sticky agendas, it displays in an buffer with the name
> *Org Agenda (R)*
> If this buffer is then renamed to e.g.
> (rename-buffer "*R-Agenda*")

Why would you need that?

> *R-Agenda*
> And is then refreshed by hitting r, the agenda is properly rebuilt BUT in a new buffer named *Org Agenda(R)*, resulting in two differing agendas.
>
> Is this appropriate behavior? It seems that rebuilding the agenda
> should respect the current buffer name. I'm very new at programing for
> lisp, so I'm not sure I'm using the right functions here.

IIRC, sticky agenda relies on buffer names to know if agenda needs to be
updated. So, it is not a good idea to rename agenda buffers.


Regards,

-- 
Nicolas Goaziou