GNU bug report logs -
#1779
23.0.60; proced with variable-pitch header line
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 1779 in the body.
You can then email your comments to 1779 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#1779
; Package
emacs
.
(Sat, 03 Jan 2009 22:10:04 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Stephen Berman <stephen.berman <at> gmx.net>
:
New bug report received and forwarded. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Sat, 03 Jan 2009 22:10:04 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):
Proced does not align the attribute names in the header line with the
corresponding columns when header-line face has variable pitch. To
reproduce:
1. emacs -Q
2. customize-face RET header-line RET, change the value of the inherit
attribute to variable-pitch and the value of the height attribute to
0.85, and set for the current session.
3. M-x proced
I know of two approaches to dealing with this situation in Emacs, namely
that of buff-menu.el and that of ibuffer.el. The latter imposes a
fixed-pitch face in the header line, overriding the
user customization. The former uses the display property with an
:align-to specification to get proper alignment. Maybe one of these
will work with proced.el too.
In GNU Emacs 23.0.60.27 (i686-pc-linux-gnu, GTK+ Version 2.12.9)
of 2009-01-03 on escher
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#1779
; Package
emacs
.
(Sun, 04 Jan 2009 08:30:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Chong Yidong <cyd <at> stupidchicken.com>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Sun, 04 Jan 2009 08:30:03 GMT)
Full text and
rfc822 format available.
Message #10 received at 1779 <at> emacsbugs.donarmstrong.com (full text, mbox):
> Proced does not align the attribute names in the header line with the
> corresponding columns when header-line face has variable pitch.
>
> I know of two approaches to dealing with this situation in Emacs, namely
> that of buff-menu.el and that of ibuffer.el. The latter imposes a
> fixed-pitch face in the header line, overriding the
> user customization. The former uses the display property with an
> :align-to specification to get proper alignment. Maybe one of these
> will work with proced.el too.
We can't use :align-to because proced justifies some headers to the
right hand side of the column.
I don't see where ibuffer.el imposes a fixed-pitch face on the header
line, though. Can you point out where it does this?
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#1779
; Package
emacs
.
(Sun, 04 Jan 2009 15:10:04 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Stephen Berman <stephen.berman <at> gmx.net>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Sun, 04 Jan 2009 15:10:05 GMT)
Full text and
rfc822 format available.
Message #15 received at 1779 <at> emacsbugs.donarmstrong.com (full text, mbox):
On Sun, 04 Jan 2009 03:23:53 -0500 Chong Yidong <cyd <at> stupidchicken.com> wrote:
>> Proced does not align the attribute names in the header line with the
>> corresponding columns when header-line face has variable pitch.
>>
>> I know of two approaches to dealing with this situation in Emacs, namely
>> that of buff-menu.el and that of ibuffer.el. The latter imposes a
>> fixed-pitch face in the header line, overriding the
>> user customization. The former uses the display property with an
>> :align-to specification to get proper alignment. Maybe one of these
>> will work with proced.el too.
>
> We can't use :align-to because proced justifies some headers to the
> right hand side of the column.
The justification is customizable in proced-grammar-alist. I set it to
`left' for all headers and modified proced-format by adapting the
:align-to code from buff-menu.el, but the headers still failed to align
with the columns with a variable-pitch header-line face. But shouldn't
it be possible in principle? Maybe someone who knows the code better
can make it work.
> I don't see where ibuffer.el imposes a fixed-pitch face on the header
> line, though. Can you point out where it does this?
I made two mistakes here, sorry. First, I shouldn't have said
fixed-pitch but the same face as is used in the buffer (which has to be
fixed-pitch in order for the columns to be aligned). But in addition,
what I assumed to be the header line in the ibuffer window is in fact
just the first line of the buffer (although I looked at the ibuffer code
and saw ibuffer-header-line-format, I overlooked that this was only for
filters, and unthinkingly took the first line to be a header line, as
with buff-menu). It's too bad the ibuffer "header" line isn't fixed
with respect to the rest of the buffer when scrolling, like a real
header line. Could this effect be achieved with an overlay?
Steve Berman
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#1779
; Package
emacs
.
(Sun, 04 Jan 2009 15:55:04 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Stefan Monnier <monnier <at> iro.umontreal.ca>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Sun, 04 Jan 2009 15:55:05 GMT)
Full text and
rfc822 format available.
Message #20 received at 1779 <at> emacsbugs.donarmstrong.com (full text, mbox):
> The justification is customizable in proced-grammar-alist. I set it to
> `left' for all headers and modified proced-format by adapting the
> :align-to code from buff-menu.el, but the headers still failed to align
> with the columns with a variable-pitch header-line face. But shouldn't
> it be possible in principle? Maybe someone who knows the code better
> can make it work.
You can also take a look at mpc.el
(bzr co http://www.iro.umontreal.ca/~monnier/bzr/mpc) where I do it with
align-to as well. I "try" to handle right alignment, but in a very
naive way. I don't think we can currently do it right in Elisp, because
there is a lot of missing information. I could imagine getting it to
work, with a lot of effort based on forcing redisplay and using
posn-at-point to measure the display size of particular pieces of text.
But it's likely to be too slow to be practical.
Stefan
Severity set to `minor' from `normal'
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> emacsbugs.donarmstrong.com
.
(Thu, 15 Jan 2009 23:45:06 GMT)
Full text and
rfc822 format available.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#1779
; Package
emacs
.
(Sun, 05 Dec 2010 23:25:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 1779 <at> debbugs.gnu.org (full text, mbox):
On Sun, 04 Jan 2009 03:23:53 -0500 Chong Yidong <cyd <at> stupidchicken.com> wrote:
>> Proced does not align the attribute names in the header line with the
>> corresponding columns when header-line face has variable pitch.
>>
>> I know of two approaches to dealing with this situation in Emacs, namely
>> that of buff-menu.el and that of ibuffer.el. The latter imposes a
>> fixed-pitch face in the header line, overriding the
>> user customization. The former uses the display property with an
>> :align-to specification to get proper alignment. Maybe one of these
>> will work with proced.el too.
>
> We can't use :align-to because proced justifies some headers to the
> right hand side of the column.
I (finally) took a look at this again and it appears that :align-to as
used in buff-menu.el with some additional tweaking pretty much DTRT
after all. With my variable-pitch font (Dejavu Sans) I find the spacing
between "%CPU" and "%Mem" too crowded; using fixed-pitch looks better,
and that's what the attached patch does. Alternatively, I think it
looks fine to let the header line font be variable-pitch as long as the
let-bound variable whitespace is set to two spaces. I actually think
this makes the proced listings also more legible, though it does leave
less space for the process invocation listing and is also a departure
from the Dired display that Proced is modelled on. Anyway, I'd be happy
with either approach; both are better than the current display when the
header-line face is variable-pitch.
Steve Berman
*** /data/steve/bzr/emacs/trunk/lisp/proced.el 2010-09-08 10:12:09.000000000 +0200
--- /data/steve/bzr/emacs/quickfixes/lisp/proced.el 2010-12-06 00:02:20.000000000 +0100
***************
*** 400,406 ****
:group 'proced-faces)
(defface proced-sort-header
! '((t (:inherit font-lock-keyword-face)))
"Face used for header of attribute used for sorting."
:group 'proced-faces)
--- 400,406 ----
:group 'proced-faces)
(defface proced-sort-header
! '((t (:family "Monospace" :inherit font-lock-keyword-face)))
"Face used for header of attribute used for sorting."
:group 'proced-faces)
***************
*** 1427,1433 ****
(hprops
(if (nth 4 grammar)
(let ((descend (if (eq key sort-key) proced-descend (nth 5 grammar))))
! `(proced-key ,key mouse-face highlight
help-echo ,(format proced-header-help-echo
(if descend "-" "+")
(nth 1 grammar)
--- 1427,1433 ----
(hprops
(if (nth 4 grammar)
(let ((descend (if (eq key sort-key) proced-descend (nth 5 grammar))))
! `(proced-key ,key face fixed-pitch mouse-face highlight
help-echo ,(format proced-header-help-echo
(if descend "-" "+")
(nth 1 grammar)
***************
*** 1509,1514 ****
--- 1509,1525 ----
(if (string-match "[ \t]+$" proced-header-line)
(setq proced-header-line (substring proced-header-line 0
(match-beginning 0))))
+ (setq proced-header-line (concat " " proced-header-line))
+ ;; From buff-menu.el: Turn whitespace chars in the header into stretch
+ ;; specs so they work regardless of the header-line face.
+ (let ((pos 0)
+ (header proced-header-line))
+ (while (string-match "[ \t\n]+" header pos)
+ (setq pos (match-end 0))
+ (put-text-property (match-beginning 0) pos 'display
+ ;; Assume fixed-size chars in the buffer.
+ (list 'space :align-to pos)
+ header)))
;; (delete-trailing-whitespace)
(goto-char (point-min))
(while (re-search-forward "[ \t\r]+$" nil t)
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#1779
; Package
emacs
.
(Sun, 05 Dec 2010 23:25:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#1779
; Package
emacs
.
(Tue, 07 Dec 2010 10:35:02 GMT)
Full text and
rfc822 format available.
Message #31 received at 1779 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, 06 Dec 2010 00:30:17 +0100 Stephen Berman <stephen.berman <at> gmx.net> wrote:
> On Sun, 04 Jan 2009 03:23:53 -0500 Chong Yidong <cyd <at> stupidchicken.com> wrote:
>
>>> Proced does not align the attribute names in the header line with the
>>> corresponding columns when header-line face has variable pitch.
>>>
>>> I know of two approaches to dealing with this situation in Emacs, namely
>>> that of buff-menu.el and that of ibuffer.el. The latter imposes a
>>> fixed-pitch face in the header line, overriding the
>>> user customization. The former uses the display property with an
>>> :align-to specification to get proper alignment. Maybe one of these
>>> will work with proced.el too.
>>
>> We can't use :align-to because proced justifies some headers to the
>> right hand side of the column.
>
> I (finally) took a look at this again and it appears that :align-to as
> used in buff-menu.el with some additional tweaking pretty much DTRT
> after all. With my variable-pitch font (Dejavu Sans) I find the spacing
> between "%CPU" and "%Mem" too crowded; using fixed-pitch looks better,
> and that's what the attached patch does. Alternatively, I think it
> looks fine to let the header line font be variable-pitch as long as the
> let-bound variable whitespace is set to two spaces. I actually think
> this makes the proced listings also more legible, though it does leave
> less space for the process invocation listing and is also a departure
> from the Dired display that Proced is modelled on. Anyway, I'd be happy
> with either approach; both are better than the current display when the
> header-line face is variable-pitch.
There was an oversight in my patch; the corrected version is below.
Also, I attach three screenshots: the first shows what the Proced
display generated by the current code looks like when the header line
face is variable-pitch, the second show the display using the below
patch (with the header line stretched and set to fixed-pitch), the third
shows the alternative mentioned above (with stretched variable-pitch
header line and added space).
Steve Berman
[proced_var.png (image/png, attachment)]
[proced_fixed.png (image/png, attachment)]
[proced_var2.png (image/png, attachment)]
[Message part 5 (text/plain, inline)]
*** /data/steve/bzr/emacs/trunk/lisp/proced.el 2010-09-08 10:12:09.000000000 +0200
--- /data/steve/bzr/emacs/quickfixes/lisp/proced.el 2010-12-07 11:15:38.000000000 +0100
***************
*** 400,406 ****
:group 'proced-faces)
(defface proced-sort-header
! '((t (:inherit font-lock-keyword-face)))
"Face used for header of attribute used for sorting."
:group 'proced-faces)
--- 400,406 ----
:group 'proced-faces)
(defface proced-sort-header
! '((t (:family "Monospace" :inherit font-lock-keyword-face)))
"Face used for header of attribute used for sorting."
:group 'proced-faces)
***************
*** 1427,1433 ****
(hprops
(if (nth 4 grammar)
(let ((descend (if (eq key sort-key) proced-descend (nth 5 grammar))))
! `(proced-key ,key mouse-face highlight
help-echo ,(format proced-header-help-echo
(if descend "-" "+")
(nth 1 grammar)
--- 1427,1433 ----
(hprops
(if (nth 4 grammar)
(let ((descend (if (eq key sort-key) proced-descend (nth 5 grammar))))
! `(proced-key ,key face fixed-pitch mouse-face highlight
help-echo ,(format proced-header-help-echo
(if descend "-" "+")
(nth 1 grammar)
***************
*** 1509,1514 ****
--- 1509,1525 ----
(if (string-match "[ \t]+$" proced-header-line)
(setq proced-header-line (substring proced-header-line 0
(match-beginning 0))))
+ (setq proced-header-line (concat " " proced-header-line))
+ ;; From buff-menu.el: Turn whitespace chars in the header into stretch
+ ;; specs so they work regardless of the header-line face.
+ (let ((pos 0)
+ (header proced-header-line))
+ (while (string-match "[ \t\n]+" header pos)
+ (setq pos (match-end 0))
+ (put-text-property (match-beginning 0) pos 'display
+ ;; Assume fixed-size chars in the buffer.
+ (list 'space :align-to pos)
+ header)))
;; (delete-trailing-whitespace)
(goto-char (point-min))
(while (re-search-forward "[ \t\r]+$" nil t)
***************
*** 1602,1608 ****
(while (not (eobp))
(insert " ")
(forward-line))
- (setq proced-header-line (concat " " proced-header-line))
(if revert (set-buffer-modified-p nil))
;; set `goal-column'
--- 1613,1618 ----
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#1779
; Package
emacs
.
(Tue, 07 Dec 2010 10:35:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#1779
; Package
emacs
.
(Sun, 10 Jul 2011 14:53:02 GMT)
Full text and
rfc822 format available.
Message #37 received at 1779 <at> debbugs.gnu.org (full text, mbox):
Stephen Berman <stephen.berman <at> gmx.net> writes:
> There was an oversight in my patch; the corrected version is below.
> Also, I attach three screenshots: the first shows what the Proced
> display generated by the current code looks like when the header line
> face is variable-pitch, the second show the display using the below
> patch (with the header line stretched and set to fixed-pitch), the third
> shows the alternative mentioned above (with stretched variable-pitch
> header line and added space).
The images included shows that the patch made an improvement. Was there
any reason it wasn't applied at the time?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#1779
; Package
emacs
.
(Mon, 11 Jul 2011 03:37:01 GMT)
Full text and
rfc822 format available.
Message #40 received at 1779 <at> debbugs.gnu.org (full text, mbox):
>> There was an oversight in my patch; the corrected version is below.
>> Also, I attach three screenshots: the first shows what the Proced
>> display generated by the current code looks like when the header line
>> face is variable-pitch, the second show the display using the below
>> patch (with the header line stretched and set to fixed-pitch), the third
>> shows the alternative mentioned above (with stretched variable-pitch
>> header line and added space).
> The images included shows that the patch made an improvement. Was there
> any reason it wasn't applied at the time?
I guess lack of time. I don't think I agree with the change to the face
definition, but the part of the code that adds :align-to properties to
the spaces looks fine.
Stefan
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#1779
; Package
emacs
.
(Fri, 15 Jul 2011 17:55:02 GMT)
Full text and
rfc822 format available.
Message #43 received at 1779 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> I guess lack of time. I don't think I agree with the change to the face
> definition, but the part of the code that adds :align-to properties to
> the spaces looks fine.
Stephen, could you send an updated patch with just the :align-to
properties? (If that makes any sense. :-) I'm not familiar enough
with the code to know whether that would be an improvement or not
without the other bits in the patch.)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#1779
; Package
emacs
.
(Fri, 15 Jul 2011 21:07:01 GMT)
Full text and
rfc822 format available.
Message #46 received at 1779 <at> debbugs.gnu.org (full text, mbox):
On Fri, 15 Jul 2011 19:54:11 +0200 Lars Magne Ingebrigtsen <larsi <at> gnus.org> wrote:
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>
>> I guess lack of time. I don't think I agree with the change to the face
>> definition, but the part of the code that adds :align-to properties to
>> the spaces looks fine.
>
> Stephen, could you send an updated patch with just the :align-to
> properties? (If that makes any sense. :-) I'm not familiar enough
> with the code to know whether that would be an improvement or not
> without the other bits in the patch.)
Sure. I'll do it as soon as I can, but I probably won't have time until
Monday or Tuesday.
Steve Berman
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#1779
; Package
emacs
.
(Tue, 19 Jul 2011 21:25:01 GMT)
Full text and
rfc822 format available.
Message #49 received at 1779 <at> debbugs.gnu.org (full text, mbox):
On Fri, 15 Jul 2011 23:05:59 +0200 Stephen Berman <stephen.berman <at> gmx.net> wrote:
> On Fri, 15 Jul 2011 19:54:11 +0200 Lars Magne Ingebrigtsen <larsi <at> gnus.org> wrote:
>
>> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>>
>>> I guess lack of time. I don't think I agree with the change to the face
>>> definition, but the part of the code that adds :align-to properties to
>>> the spaces looks fine.
>>
>> Stephen, could you send an updated patch with just the :align-to
>> properties? (If that makes any sense. :-) I'm not familiar enough
>> with the code to know whether that would be an improvement or not
>> without the other bits in the patch.)
>
> Sure. I'll do it as soon as I can, but I probably won't have time until
> Monday or Tuesday.
The patch is below. The only change I made from the previous patch
(aside from leaving out the face change) is to omit the comment from
buff-menu.el about assuming fixed-pitch, since obviously we aren't
making that assumption (though it's true that :align-to works best with
fixed-pitch, but still I definitely think it's an improvement).
Steve Berman
*** /home/steve/bzr/emacs/trunk/lisp/proced.el 2011-07-08 15:13:26.000000000 +0200
--- /home/steve/bzr/emacs/quickfixes/lisp/proced.el 2011-07-19 23:06:48.000000000 +0200
***************
*** 1509,1514 ****
--- 1509,1524 ----
(if (string-match "[ \t]+$" proced-header-line)
(setq proced-header-line (substring proced-header-line 0
(match-beginning 0))))
+ (setq proced-header-line (concat " " proced-header-line))
+ ;; From buff-menu.el: Turn whitespace chars in the header into
+ ;; stretch specs so they work regardless of the header-line face.
+ (let ((pos 0)
+ (header proced-header-line))
+ (while (string-match "[ \t\n]+" header pos)
+ (setq pos (match-end 0))
+ (put-text-property (match-beginning 0) pos 'display
+ (list 'space :align-to pos)
+ header)))
;; (delete-trailing-whitespace)
(goto-char (point-min))
(while (re-search-forward "[ \t\r]+$" nil t)
***************
*** 1602,1608 ****
(while (not (eobp))
(insert " ")
(forward-line))
- (setq proced-header-line (concat " " proced-header-line))
(if revert (set-buffer-modified-p nil))
;; set `goal-column'
--- 1612,1617 ----
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#1779
; Package
emacs
.
(Tue, 19 Jul 2011 21:33:02 GMT)
Full text and
rfc822 format available.
Message #52 received at 1779 <at> debbugs.gnu.org (full text, mbox):
Stephen Berman <stephen.berman <at> gmx.net> writes:
> The patch is below. The only change I made from the previous patch
> (aside from leaving out the face change) is to omit the comment from
> buff-menu.el about assuming fixed-pitch, since obviously we aren't
> making that assumption (though it's true that :align-to works best with
> fixed-pitch, but still I definitely think it's an improvement).
Thanks; I've now applied the patch.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
Added tag(s) fixed.
Request was from
Lars Magne Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Tue, 19 Jul 2011 21:33:02 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 24.1, send any further explanations to
1779 <at> debbugs.gnu.org and Stephen Berman <stephen.berman <at> gmx.net>
Request was from
Lars Magne Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Tue, 19 Jul 2011 21:33:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#1779
; Package
emacs
.
(Wed, 20 Jul 2011 01:31:02 GMT)
Full text and
rfc822 format available.
Message #59 received at submit <at> debbugs.gnu.org (full text, mbox):
On Tue, Jul 19 2011, Stephen Berman wrote:
> The patch is below. The only change I made from the previous patch
> (aside from leaving out the face change) is to omit the comment from
> buff-menu.el about assuming fixed-pitch, since obviously we aren't
> making that assumption (though it's true that :align-to works best with
> fixed-pitch, but still I definitely think it's an improvement).
I am sorry, this patch does not work for me!
I do not use variable-pitch fonts. But I use the longer proced formats.
With the new code the header line does not scroll horizontally anymore
as required for the longer proced formats.
Yet stranger, when scrolling the proced buffer to the right, some
headers on the left simply disappear, whereas headers on the right part
of the window stay where they are. So for the long proced formats, the
header line has become rather useless. -- What is more annoying: the old
wrong behavior for variable-pitch fonts or the new behavior?
Roland
PS: I just installed a patch for proced that should be completely unrelated.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#1779
; Package
emacs
.
(Wed, 20 Jul 2011 08:29:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 1779 <at> debbugs.gnu.org (full text, mbox):
On Tue, 19 Jul 2011 20:18:04 -0500 Roland Winkler <winkler <at> gnu.org> wrote:
> On Tue, Jul 19 2011, Stephen Berman wrote:
>> The patch is below. The only change I made from the previous patch
>> (aside from leaving out the face change) is to omit the comment from
>> buff-menu.el about assuming fixed-pitch, since obviously we aren't
>> making that assumption (though it's true that :align-to works best with
>> fixed-pitch, but still I definitely think it's an improvement).
>
> I am sorry, this patch does not work for me!
> I do not use variable-pitch fonts. But I use the longer proced formats.
> With the new code the header line does not scroll horizontally anymore
> as required for the longer proced formats.
> Yet stranger, when scrolling the proced buffer to the right, some
> headers on the left simply disappear, whereas headers on the right part
> of the window stay where they are. So for the long proced formats, the
> header line has become rather useless. -- What is more annoying: the old
> wrong behavior for variable-pitch fonts or the new behavior?
Certainly the new behavior is untenable; please revert my patch. I
didn't know about the long format and didn't test it. I took a quick
look but couldn't come up with a quick fix. I'll try some more when I
have time, but it won't be soon; if you or somebody else can find a fix,
that would be great. Or maybe this problem is a good argument for
hardcoding fixed-pitch for the proced header line.
Sorry for the poorly tested patch.
Steve Berman
bug No longer marked as fixed in versions 24.1 and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Wed, 20 Jul 2011 09:55:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#1779
; Package
emacs
.
(Wed, 20 Jul 2011 09:56:01 GMT)
Full text and
rfc822 format available.
Message #67 received at 1779 <at> debbugs.gnu.org (full text, mbox):
Stephen Berman <stephen.berman <at> gmx.net> writes:
> Certainly the new behavior is untenable; please revert my patch.
I've now reverted the patch and reopened this report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#1779
; Package
emacs
.
(Wed, 20 Jul 2011 11:57:01 GMT)
Full text and
rfc822 format available.
Message #70 received at 1779 <at> debbugs.gnu.org (full text, mbox):
On Wed Jul 20 2011 Stephen Berman wrote:
> Certainly the new behavior is untenable; please revert my patch. I
> didn't know about the long format and didn't test it. I took a quick
> look but couldn't come up with a quick fix. I'll try some more when I
> have time, but it won't be soon; if you or somebody else can find a fix,
> that would be great. Or maybe this problem is a good argument for
> hardcoding fixed-pitch for the proced header line.
Right now it's not clear to me where things went wrong with your
patch. The behavior I got did not make sense to me under any
circumstances. So possibly this really indicated that things are
going wrong elsewhere. I want to take a closer look at this, too.
I am sorry I missed your original bug report.
Roland
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#1779
; Package
emacs
.
(Thu, 21 Jul 2011 16:42:02 GMT)
Full text and
rfc822 format available.
Message #73 received at 1779 <at> debbugs.gnu.org (full text, mbox):
"Roland Winkler" <winkler <at> gnu.org> writes:
> On Wed Jul 20 2011 Stephen Berman wrote:
>> Certainly the new behavior is untenable; please revert my patch. I
>> didn't know about the long format and didn't test it. I took a quick
>> look but couldn't come up with a quick fix. I'll try some more when I
>> have time, but it won't be soon; if you or somebody else can find a fix,
>> that would be great. Or maybe this problem is a good argument for
>> hardcoding fixed-pitch for the proced header line.
>
> Right now it's not clear to me where things went wrong with your
> patch. The behavior I got did not make sense to me under any
> circumstances. So possibly this really indicated that things are
> going wrong elsewhere. I want to take a closer look at this, too.
>
> I am sorry I missed your original bug report.
AFAICT, the alignment issue does not occur in Tabulated List mode, which
uses :align-to. In the short run, you might be able to get a clue about
the correct fix from there. In the long run, I think proced.el should
be reworked to use Tabulated List mode.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#1779
; Package
emacs
.
(Fri, 22 Jul 2011 03:05:01 GMT)
Full text and
rfc822 format available.
Message #76 received at 1779 <at> debbugs.gnu.org (full text, mbox):
On Thu Jul 21 2011 Chong Yidong wrote:
> AFAICT, the alignment issue does not occur in Tabulated List mode, which
> uses :align-to. In the short run, you might be able to get a clue about
> the correct fix from there. In the long run, I think proced.el should
> be reworked to use Tabulated List mode.
Thanks, I'll have to find out what Tabulated List mode is doing.
I am just wondering: In general, proced was much inspired by dired.
Would you suggest that dired should likewise use Tabulated List mode?
Roland
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#1779
; Package
emacs
.
(Fri, 22 Jul 2011 05:16:02 GMT)
Full text and
rfc822 format available.
Message #79 received at 1779 <at> debbugs.gnu.org (full text, mbox):
"Roland Winkler" <winkler <at> gnu.org> writes:
> Thanks, I'll have to find out what Tabulated List mode is doing.
> I am just wondering: In general, proced was much inspired by dired.
> Would you suggest that dired should likewise use Tabulated List mode?
T-L mode is not suitable for Dired, because not every line is an
"entry", i.e. the first two summary lines---which are also the reason
why Dired does not use the header line. Other Dired features, like
showing multiple directories, also break T-L mode assumptions.
One mode that could be usefully converted to use T-L mode is Buffer Menu
mode. Maybe we'll get round to that in a future major Emacs version.
Removed tag(s) fixed.
Request was from
Lars Magne Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Tue, 02 Aug 2011 16:13:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#1779
; Package
emacs
.
(Sun, 11 Oct 2020 22:23:01 GMT)
Full text and
rfc822 format available.
Message #84 received at 1779 <at> debbugs.gnu.org (full text, mbox):
>> Certainly the new behavior is untenable; please revert my patch.
> I've now reverted the patch and reopened this report.
I fixed the patch so it also works correctly when
scrolling horizontally.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#1779
; Package
emacs
.
(Sun, 11 Oct 2020 22:51:02 GMT)
Full text and
rfc822 format available.
Message #87 received at 1779 <at> debbugs.gnu.org (full text, mbox):
On Sun, 11 Oct 2020 18:22:47 -0400 Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:
>>> Certainly the new behavior is untenable; please revert my patch.
>> I've now reverted the patch and reopened this report.
>
> I fixed the patch so it also works correctly when
> scrolling horizontally.
Thanks!
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#1779
; Package
emacs
.
(Mon, 22 Nov 2021 17:42:01 GMT)
Full text and
rfc822 format available.
Message #90 received at 1779 <at> debbugs.gnu.org (full text, mbox):
>>> Certainly the new behavior is untenable; please revert my patch.
>> I've now reverted the patch and reopened this report.
>
> I fixed the patch so it also works correctly when
> scrolling horizontally.
As discussed in
https://lists.gnu.org/archive/html/emacs-devel/2020-12/msg00084.html
I tried to fix this bug in the emacs-28 branch by copying code
from ‘tabulated-list-col-sort’ to ‘proced-sort-header’.
Maybe now variable-pitch could be enabled on proced-head-line.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#1779
; Package
emacs
.
(Wed, 24 Nov 2021 06:54:01 GMT)
Full text and
rfc822 format available.
Message #93 received at 1779 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
> As discussed in
> https://lists.gnu.org/archive/html/emacs-devel/2020-12/msg00084.html
> I tried to fix this bug in the emacs-28 branch by copying code
> from ‘tabulated-list-col-sort’ to ‘proced-sort-header’.
>
> Maybe now variable-pitch could be enabled on proced-head-line.
I'm not quite sure whether having the header line in a proportional font
when the rest of the text is monospaced is ideal -- it can sometimes
look pretty odd.
We should have a package for doing variable-pitch tables, and I've been
working on one, but I want to reimplement it before including in Emacs.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#1779
; Package
emacs
.
(Wed, 24 Nov 2021 09:17:02 GMT)
Full text and
rfc822 format available.
Message #96 received at 1779 <at> debbugs.gnu.org (full text, mbox):
>> Maybe now variable-pitch could be enabled on proced-head-line.
>
> I'm not quite sure whether having the header line in a proportional font
> when the rest of the text is monospaced is ideal -- it can sometimes
> look pretty odd.
>
> We should have a package for doing variable-pitch tables, and I've been
> working on one, but I want to reimplement it before including in Emacs.
Agreed, when tabulated-list-mode will support variable-pitch tables,
and proced will use tabulated-list-mode, only then its header line
could be in variable-pitch.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#1779
; Package
emacs
.
(Wed, 24 Nov 2021 16:52:02 GMT)
Full text and
rfc822 format available.
Message #99 received at 1779 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
> Agreed, when tabulated-list-mode will support variable-pitch tables,
> and proced will use tabulated-list-mode, only then its header line
> could be in variable-pitch.
I had in mind a bigger change than that. 😀 tabulated-list-mode is
nice, but there's things about it that makes it less suited to some work
flows, so I'd like to make a new package for this.
The main problem is that it wants to own the buffer, and you can only
have the table in it, and nothing else. The other issue is that the
interface functions are a bit obscure -- you set/manipulate a bunch of
buffer-local variables, and then call some functions.
I'd like to have a table that's an "object", with well-defined interface
functions, and which allows you to have many tables in the same buffer,
and mix with other text, too.
And with proportional fonts. 😀
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#1779
; Package
emacs
.
(Wed, 24 Nov 2021 18:52:02 GMT)
Full text and
rfc822 format available.
Message #102 received at 1779 <at> debbugs.gnu.org (full text, mbox):
> I had in mind a bigger change than that. 😀 tabulated-list-mode is
> nice, but there's things about it that makes it less suited to some work
> flows, so I'd like to make a new package for this.
>
> The main problem is that it wants to own the buffer, and you can only
> have the table in it, and nothing else.
Yes, I've said that many times. Glad it's finally
sunk in. That's a sufficient reason that it should
not have been used in things like the bookmark list.
(Even adding it to buffer-menu was a mistake.)
> The other issue is that the
> interface functions are a bit obscure -- you set/manipulate a bunch of
> buffer-local variables, and then call some functions.
A more important weakness of t-l-mode is that it
doesn't support arbitrary sort functions - it
doesn't make it easy to sort other than by an
individual column.
> I'd like to have a table that's an "object", with well-defined interface
> functions, and which allows you to have many tables in the same buffer,
> and mix with other text, too.
>
> And with proportional fonts. 😀
To me, t-l-mode is too limited for most real,
useful uses of "tabular" data. It should never
have been imposed on the bookmark list (I don't
use it in Bookmark+). And it's useless for
things like Dired (thank goodness). Maybe the
same for Ibuffer; dunno.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#1779
; Package
emacs
.
(Mon, 29 Nov 2021 17:23:01 GMT)
Full text and
rfc822 format available.
Message #105 received at 1779 <at> debbugs.gnu.org (full text, mbox):
> I'd like to have a table that's an "object", with well-defined interface
> functions, and which allows you to have many tables in the same buffer,
> and mix with other text, too.
I wonder how several tables could share the same header-line?
Or it would be possible to implement own header for each table
(not using the window header-line)?
Then each table could be scrolled separately.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#1779
; Package
emacs
.
(Mon, 29 Nov 2021 18:06:01 GMT)
Full text and
rfc822 format available.
Message #108 received at 1779 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov [2021-11-29 19:16:04] wrote:
>> I'd like to have a table that's an "object", with well-defined interface
>> functions, and which allows you to have many tables in the same buffer,
>> and mix with other text, too.
> I wonder how several tables could share the same header-line?
> Or it would be possible to implement own header for each table
> (not using the window header-line)?
> Then each table could be scrolled separately.
A `pre-redisplay-function` that looks at `window-start` and sets
the `header-line` accordingly might work.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#1779
; Package
emacs
.
(Mon, 29 Nov 2021 18:48:02 GMT)
Full text and
rfc822 format available.
Message #111 received at 1779 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> A `pre-redisplay-function` that looks at `window-start` and sets
> the `header-line` accordingly might work.
Hm... interesting. Do we do something similar to this elsewhere in Emacs?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#1779
; Package
emacs
.
(Mon, 29 Nov 2021 18:57:01 GMT)
Full text and
rfc822 format available.
Message #114 received at 1779 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen [2021-11-29 19:47:11] wrote:
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> A `pre-redisplay-function` that looks at `window-start` and sets
>> the `header-line` accordingly might work.
> Hm... interesting. Do we do something similar to this elsewhere in Emacs?
tabulated-list.el uses `pre-redisplay-function` to (re)set the
header-line in accordance to the line-number width. That's not quite
the same but the key words do match ;-)
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#1779
; Package
emacs
.
(Sun, 24 Apr 2022 14:01:02 GMT)
Full text and
rfc822 format available.
Message #117 received at 1779 <at> debbugs.gnu.org (full text, mbox):
Stephen Berman <stephen.berman <at> gmx.net> writes:
> Proced does not align the attribute names in the header line with the
> corresponding columns when header-line face has variable pitch. To
> reproduce:
>
> 1. emacs -Q
> 2. customize-face RET header-line RET, change the value of the inherit
> attribute to variable-pitch and the value of the height attribute to
> 0.85, and set for the current session.
> 3. M-x proced
(I'm going through old bug reports that unfortunately weren't resolved
at the time.)
This has apparently been fixed in the years since it was reported -- I
can reproduce it in Emacs 25.3, for instance, but it Emacs 29, the
headings line up pretty well when using variable pitch in the headers in
proced.
So I'm therefore closing this bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug closed, send any further explanations to
1779 <at> debbugs.gnu.org and Stephen Berman <stephen.berman <at> gmx.net>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sun, 24 Apr 2022 14:01:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 23 May 2022 11:24:07 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 50 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.