Hi, A quick wished feature, if you agree on its usefulness. Currently, all error messages are concatenated to the same buffer, execution after execution, which makes it *difficult to distinguish between the new errors*, and the ones already seen previously. Different propositions: - delete the contents of the buffer before every code execution - add something visible after every execution, like a separator line or a ^L character (new page, than can easily be displayed as a rule) - always show the last lines in a different color - in the same spirit, use two alternate colors for the messages (like in some HTML tables, for odd/even rows) - add a timestamp with the date, before every code execution. This is not exhaustive, just some (funny for some of them) ideas I have in mind in order to make the messages more visible than they currently are. Thanks. Best regards, Seb -- Sébastien Vauban _______________________________________________ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode-mXXj517/zsQ@public.gmane.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes: > Hi, > > A quick wished feature, if you agree on its usefulness. > > Currently, all error messages are concatenated to the same buffer, execution > after execution, which makes it *difficult to distinguish between the new > errors*, and the ones already seen previously. Hi Seb, I agree, that had been bothering me too. I had fixed it a week or so ago in my local set up, and I've just pushed that to master. It wipes the error buffer clean at the start of execution (on C-c C-c, and during export). Dan > > Different propositions: > > - delete the contents of the buffer before every code execution > > - add something visible after every execution, like a separator line or a ^L > character (new page, than can easily be displayed as a rule) > > - always show the last lines in a different color > > - in the same spirit, use two alternate colors for the messages (like in some > HTML tables, for odd/even rows) > > - add a timestamp with the date, before every code execution. > > This is not exhaustive, just some (funny for some of them) ideas I have in > mind in order to make the messages more visible than they currently are. > > Thanks. > > Best regards, > Seb
This is something that Dan and I have discussed as well. On the one
hand it would be nice to wipe the buffer between block executions, but
on the other hand when you are say exporting a file and running many
code blocks at once it would be preferable to retain error messages from
all of the code blocks.
I've been thinking that either a we could delete the buffer form all
manual entry points into code block execution so that it is refreshed
between manual code block execs but not between automated (e.g. on
export) code block execs.
Another option would be to separate the error messages with timestamps
as you've proposed, and maybe with some mark that can be jumped to with
a keystroke.
I'm not sure which approach would be best. -- Eric
Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> writes:
> Hi,
>
> A quick wished feature, if you agree on its usefulness.
>
> Currently, all error messages are concatenated to the same buffer, execution
> after execution, which makes it *difficult to distinguish between the new
> errors*, and the ones already seen previously.
>
> Different propositions:
>
> - delete the contents of the buffer before every code execution
>
> - add something visible after every execution, like a separator line or a ^L
> character (new page, than can easily be displayed as a rule)
>
> - always show the last lines in a different color
>
> - in the same spirit, use two alternate colors for the messages (like in some
> HTML tables, for odd/even rows)
>
> - add a timestamp with the date, before every code execution.
>
> This is not exhaustive, just some (funny for some of them) ideas I have in
> mind in order to make the messages more visible than they currently are.
>
> Thanks.
>
> Best regards,
> Seb
Hi Eric, Seb,
I'd actually just pushed my local fix that I had made to this so
far. Our emails crossed because mine is being held up by gmane as I
forgot to switch the obfuscated gmane reply address for the normal list
address, but here's what will come through eventually:
,----
| Hi Seb,
|
| I agree, that had been bothering me too. I had fixed it a week or so ago
| in my local set up, and I've just pushed that to master. It wipes the
| error buffer clean at the start of execution (on C-c C-c, and during
| export).
|
| Dan
`----
Hopfully this is a step in the right direction, although it doesn't
resolve all the problems you outline.
Dan
"Eric Schulte" <schulte.eric@gmail.com> writes:
> This is something that Dan and I have discussed as well. On the one
> hand it would be nice to wipe the buffer between block executions, but
> on the other hand when you are say exporting a file and running many
> code blocks at once it would be preferable to retain error messages from
> all of the code blocks.
>
> I've been thinking that either a we could delete the buffer form all
> manual entry points into code block execution so that it is refreshed
> between manual code block execs but not between automated (e.g. on
> export) code block execs.
>
> Another option would be to separate the error messages with timestamps
> as you've proposed, and maybe with some mark that can be jumped to with
> a keystroke.
>
> I'm not sure which approach would be best. -- Eric
>
> Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> writes:
>
>> Hi,
>>
>> A quick wished feature, if you agree on its usefulness.
>>
>> Currently, all error messages are concatenated to the same buffer, execution
>> after execution, which makes it *difficult to distinguish between the new
>> errors*, and the ones already seen previously.
>>
>> Different propositions:
>>
>> - delete the contents of the buffer before every code execution
>>
>> - add something visible after every execution, like a separator line or a ^L
>> character (new page, than can easily be displayed as a rule)
>>
>> - always show the last lines in a different color
>>
>> - in the same spirit, use two alternate colors for the messages (like in some
>> HTML tables, for odd/even rows)
>>
>> - add a timestamp with the date, before every code execution.
>>
>> This is not exhaustive, just some (funny for some of them) ideas I have in
>> mind in order to make the messages more visible than they currently are.
>>
>> Thanks.
>>
>> Best regards,
>> Seb
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> writes: > Hi, > > A quick wished feature, if you agree on its usefulness. > > Currently, all error messages are concatenated to the same buffer, execution > after execution, which makes it *difficult to distinguish between the new > errors*, and the ones already seen previously. > > Different propositions: > > - delete the contents of the buffer before every code execution > > - add something visible after every execution, like a separator line or a ^L > character (new page, than can easily be displayed as a rule) I like this one (above), especially if you could append the date+time to the formfeed and, ideally, some indication of the source code block responsible for what follows. The latter is important because I often have multiple source code blocks with the same language and it would be nice to distinguish between them in terms of error output. Having the srcname appear would be great, if it's possible. thanks, eric > - always show the last lines in a different color > > - in the same spirit, use two alternate colors for the messages (like in some > HTML tables, for odd/even rows) > > - add a timestamp with the date, before every code execution. > > This is not exhaustive, just some (funny for some of them) ideas I have in > mind in order to make the messages more visible than they currently are. > > Thanks. > > Best regards, > Seb -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 23.2.1 : using Org-mode version 7.3 (release_7.3.123.g950be)
Hi Eric, Eric S Fraga wrote: >> - add something visible after every execution, like a separator line or a >> ^L character (new page, than can easily be displayed as a rule) > > I like this one (above), especially if you could append the date+time to the > formfeed and, ideally, some indication of the source code block responsible > for what follows. The latter is important because I often have multiple > source code blocks with the same language and it would be nice to > distinguish between them in terms of error output. Having the srcname appear > would be great, if it's possible. I think that what'd be very useful is: - some kind of separator - some timestamp (à la Org? with or without seconds) - some language info? - a referrer to the code block (like the =comments= in tangled files) The separator could even be (why not?) a Org heading: the entire output buffer could be an Org file, allowing for folding of less useful entries, or sparse tree searches: --8<---------------cut here---------------start------------->8--- * 2010-11-23 Tue 22:29:11 sh block /* [[file:~/src/test.org::*Commands][Commands:1]] */ Invalid command: ls\r Invalid command: date\r /* Commands:1 ends here */ --8<---------------cut here---------------end--------------->8--- Just a proposition example... For me, whatever the format... Best regards, Seb -- Sébastien Vauban _______________________________________________ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode-mXXj517/zsQ@public.gmane.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> writes: > Hi Eric, > > Eric S Fraga wrote: >>> - add something visible after every execution, like a separator line or a >>> ^L character (new page, than can easily be displayed as a rule) >> >> I like this one (above), especially if you could append the date+time to the >> formfeed and, ideally, some indication of the source code block responsible >> for what follows. The latter is important because I often have multiple >> source code blocks with the same language and it would be nice to >> distinguish between them in terms of error output. Having the srcname appear >> would be great, if it's possible. > > I think that what'd be very useful is: > > - some kind of separator > - some timestamp (à la Org? with or without seconds) > - some language info? > - a referrer to the code block (like the =comments= in tangled files) > > The separator could even be (why not?) a Org heading: the entire output buffer > could be an Org file, allowing for folding of less useful entries, or sparse > tree searches: > > * 2010-11-23 Tue 22:29:11 sh block > /* [[file:~/src/test.org::*Commands][Commands:1]] */ > Invalid command: ls\r > Invalid command: date\r > /* Commands:1 ends here */ > These are great ideas, in the case of single block execution I think we're fine with the current behavior of a cleared error buffer containing only a single error output, but in the case of multiple block evaluations (e.g. chained code blocks or during export) I think that the above suggestions are great. I especially like the idea of one Org-mode top-level heading per error. I've added this to the Babel task stack. Cheers -- Eric > > Just a proposition example... For me, whatever the format... > > Best regards, > Seb
Hi Eric, "Eric Schulte" wrote: > Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes: >> Eric S Fraga wrote: >>>> - add something visible after every execution, like a separator line or a >>>> ^L character (new page, than can easily be displayed as a rule) >>> >>> I like this one (above), especially if you could append the date+time to >>> the formfeed and, ideally, some indication of the source code block >>> responsible for what follows. The latter is important because I often have >>> multiple source code blocks with the same language and it would be nice to >>> distinguish between them in terms of error output. Having the srcname >>> appear would be great, if it's possible. >> >> I think that what'd be very useful is: >> >> - some kind of separator >> - some timestamp (à la Org? with or without seconds) >> - some language info? >> - a referrer to the code block (like the =comments= in tangled files) >> >> The separator could even be (why not?) a Org heading: the entire output >> buffer could be an Org file, allowing for folding of less useful entries, >> or sparse tree searches: >> >> * 2010-11-23 Tue 22:29:11 sh block >> /* [[file:~/src/test.org::*Commands][Commands:1]] */ >> Invalid command: ls\r >> Invalid command: date\r >> /* Commands:1 ends here */ > > These are great ideas, in the case of single block execution I think we're > fine with the current behavior of a cleared error buffer containing only a > single error output, It certainly is already much better, though -- trying *on purpose* to play the devil's advocate -- we can imagine one would like to see the output of different executions at different times: I'm writing some code, testing, getting an error, updating the code, testing, and would like to see what diff it made with regard to the previous execution. > but in the case of multiple block evaluations (e.g. chained code blocks or > during export) I think that the above suggestions are great. I especially > like the idea of one Org-mode top-level heading per error. For your info, it's already what I'm doing with the messages from my .emacs file: at some points, I call:* (message "* Org mode stuff") and (message "** Org clocking stuff") so that I can easily switch my Messages buffer to org-mode and collapse sections which don't interest me at that point in time... > I've added this to the Babel task stack. Thanks a lot. Best regards, Seb -- Sébastien Vauban _______________________________________________ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode-mXXj517/zsQ@public.gmane.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode