all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* how do I know that the buffer is narrowed
@ 2005-11-30 16:27 mak kwak
  2005-11-30 19:54 ` Kevin Rodgers
  0 siblings, 1 reply; 12+ messages in thread
From: mak kwak @ 2005-11-30 16:27 UTC (permalink / raw)


Hallo
Do You know if there is any buffer local variable that tells this to me ?
Greetings

----------------------------------------------------
Już 28 Listopada największe wydarzenie muzyczno - wydawnicze 
tego roku. Rap Eskadra 3! 
http://klik.wp.pl/?adr=http%3A%2F%2Fmuzyka.wp.pl%2Fplyta.html%3Fid%3D52868%26g%3D0&sid=588

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: how do I know that the buffer is narrowed
  2005-11-30 16:27 mak kwak
@ 2005-11-30 19:54 ` Kevin Rodgers
  0 siblings, 0 replies; 12+ messages in thread
From: Kevin Rodgers @ 2005-11-30 19:54 UTC (permalink / raw)


mak kwak wrote:
 > Do You know if there is any buffer local variable that tells this to me ?

There is no such variable.

But why do you care?  Either respect the narrowing that's in effect or
wrap your code in (save-restriction (widen) ...)

-- 
Kevin Rodgers

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: how do I know that the buffer is narrowed
       [not found] <mailman.17354.1133368063.20277.help-gnu-emacs@gnu.org>
@ 2005-11-30 22:10 ` Pascal Bourguignon
  2005-11-30 22:41   ` Johan Bockgård
  0 siblings, 1 reply; 12+ messages in thread
From: Pascal Bourguignon @ 2005-11-30 22:10 UTC (permalink / raw)


"mak kwak" <makwak@wp.pl> writes:
> Do You know if there is any buffer local variable that tells this to me ?

Yes, there are some buffer local variables, but they're in C!

DEFUN ("widen", Fwiden, Swiden, 0, 0, "",
       doc: /* Remove restrictions (narrowing) from current buffer.
This allows the buffer's full text to be seen and edited.  */)
     ()
{
  if (BEG != BEGV || Z != ZV)
    current_buffer->clip_changed = 1;
...


>From lisp, you could compare (point-min) and (point-max):

(defun narrowedp ()
  (not (equal (list (point-min) (point-max))
              (save-restriction (widen) (list (point-min) (point-max))))))


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we. -- Georges W. Bush

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: how do I know that the buffer is narrowed
  2005-11-30 22:10 ` how do I know that the buffer is narrowed Pascal Bourguignon
@ 2005-11-30 22:41   ` Johan Bockgård
  2005-11-30 23:10     ` David Kastrup
  0 siblings, 1 reply; 12+ messages in thread
From: Johan Bockgård @ 2005-11-30 22:41 UTC (permalink / raw)


Pascal Bourguignon <spam@mouse-potato.com> writes:

> From lisp, you could compare (point-min) and (point-max):
>
> (defun narrowedp ()
>   (not (equal (list (point-min) (point-max))
>               (save-restriction (widen) (list (point-min) (point-max))))))


(not (and (= (point-min) 1)
          (= (point-max) (1+ (buffer-size)))))

-- 
Johan Bockgård

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: how do I know that the buffer is narrowed
  2005-11-30 22:41   ` Johan Bockgård
@ 2005-11-30 23:10     ` David Kastrup
  2005-12-01 11:31       ` Giorgos Keramidas
  0 siblings, 1 reply; 12+ messages in thread
From: David Kastrup @ 2005-11-30 23:10 UTC (permalink / raw)


bojohan+news@dd.chalmers.se (Johan Bockgård) writes:

> Pascal Bourguignon <spam@mouse-potato.com> writes:
>
>> From lisp, you could compare (point-min) and (point-max):
>>
>> (defun narrowedp ()
>>   (not (equal (list (point-min) (point-max))
>>               (save-restriction (widen) (list (point-min) (point-max))))))
>
>
> (not (and (= (point-min) 1)
>           (= (point-max) (1+ (buffer-size)))))

(<(-(point-max)(point-min))(buffer-size))

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: how do I know that the buffer is narrowed
  2005-11-30 23:10     ` David Kastrup
@ 2005-12-01 11:31       ` Giorgos Keramidas
  2005-12-01 12:12         ` David Kastrup
  2005-12-01 16:52         ` Stefan Monnier
  0 siblings, 2 replies; 12+ messages in thread
From: Giorgos Keramidas @ 2005-12-01 11:31 UTC (permalink / raw)


On Thu, 01 Dec 2005 00:10:01 +0100, David Kastrup <dak@gnu.org> wrote:
> bojohan+news@dd.chalmers.se (Johan Bockgård) writes:
>>> (defun narrowedp ()
>>>   (not (equal (list (point-min) (point-max))
>>>               (save-restriction (widen) (list (point-min) (point-max))))))
>>
>>
>> (not (and (= (point-min) 1)
>>           (= (point-max) (1+ (buffer-size)))))
>
> (<(-(point-max)(point-min))(buffer-size))

Pfeh!  Is there any good reason to obfuscate the beautiful:

    (not (and (= (point-min) 1)
              (= (point-max) (1+ (buffer-size)))))

*and* remove all its spaces? :)

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: how do I know that the buffer is narrowed
  2005-12-01 11:31       ` Giorgos Keramidas
@ 2005-12-01 12:12         ` David Kastrup
  2005-12-01 12:44           ` Giorgos Keramidas
  2005-12-01 16:52         ` Stefan Monnier
  1 sibling, 1 reply; 12+ messages in thread
From: David Kastrup @ 2005-12-01 12:12 UTC (permalink / raw)


Giorgos Keramidas <keramida@ceid.upatras.gr> writes:

> On Thu, 01 Dec 2005 00:10:01 +0100, David Kastrup <dak@gnu.org> wrote:
>> bojohan+news@dd.chalmers.se (Johan Bockgård) writes:
>>>> (defun narrowedp ()
>>>>   (not (equal (list (point-min) (point-max))
>>>>               (save-restriction (widen) (list (point-min) (point-max))))))
>>>
>>>
>>> (not (and (= (point-min) 1)
>>>           (= (point-max) (1+ (buffer-size)))))
>>
>> (<(-(point-max)(point-min))(buffer-size))
>
> Pfeh!  Is there any good reason to obfuscate the beautiful:
>
>     (not (and (= (point-min) 1)
>               (= (point-max) (1+ (buffer-size)))))
>
> *and* remove all its spaces? :)

It is impolite to let your parens do more work than necessary.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: how do I know that the buffer is narrowed
  2005-12-01 12:12         ` David Kastrup
@ 2005-12-01 12:44           ` Giorgos Keramidas
  0 siblings, 0 replies; 12+ messages in thread
From: Giorgos Keramidas @ 2005-12-01 12:44 UTC (permalink / raw)


On Thu, 01 Dec 2005 13:12:55 +0100, David Kastrup <dak@gnu.org> wrote:
> It is impolite to let your parens do more work than necessary.

HEHEH :)

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: how do I know that the buffer is narrowed
  2005-12-01 11:31       ` Giorgos Keramidas
  2005-12-01 12:12         ` David Kastrup
@ 2005-12-01 16:52         ` Stefan Monnier
  2005-12-01 18:41           ` Giorgos Keramidas
                             ` (2 more replies)
  1 sibling, 3 replies; 12+ messages in thread
From: Stefan Monnier @ 2005-12-01 16:52 UTC (permalink / raw)


>> (<(-(point-max)(point-min))(buffer-size))
> Pfeh!  Is there any good reason to obfuscate the beautiful:
>     (not (and (= (point-min) 1)
>               (= (point-max) (1+ (buffer-size)))))

Yes, there is a very good one: you unnecessarily assume that the buffer
starts at position 1.

Comparing (- (point-max) (point-min)) and (buffer-size) doesn't suffer from
this problem.  And conceptually, it also makes a lot of sense:
(- (point-max) (point-min)) is the amount of text shown and (buffer-size) is
the total mount of text, and the definition of non-narrowed is basically
"shows everything" i.e. "doesn't show less than the total".


        Stefan

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: how do I know that the buffer is narrowed
  2005-12-01 16:52         ` Stefan Monnier
@ 2005-12-01 18:41           ` Giorgos Keramidas
  2005-12-04 12:13           ` Ehud Karni
       [not found]           ` <mailman.17838.1133698823.20277.help-gnu-emacs@gnu.org>
  2 siblings, 0 replies; 12+ messages in thread
From: Giorgos Keramidas @ 2005-12-01 18:41 UTC (permalink / raw)


On Thu, 01 Dec 2005 11:52:19 -0500, Stefan Monnier wrote:
>>> (<(-(point-max)(point-min))(buffer-size))
>> Pfeh!  Is there any good reason to obfuscate the beautiful:
>>     (not (and (= (point-min) 1)
>>               (= (point-max) (1+ (buffer-size)))))
>
> Yes, there is a very good one: you unnecessarily assume that the
> buffer starts at position 1.
>
> Comparing (- (point-max) (point-min)) and (buffer-size) doesn't suffer
> from this problem.  And conceptually, it also makes a lot of sense:
> (- (point-max) (point-min)) is the amount of text shown and
> (buffer-size) is the total mount of text, and the definition of
> non-narrowed is basically "shows everything" i.e. "doesn't show less
> than the total".

Ah!  Very nice explanation, thanks :)

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: how do I know that the buffer is narrowed
  2005-12-01 16:52         ` Stefan Monnier
  2005-12-01 18:41           ` Giorgos Keramidas
@ 2005-12-04 12:13           ` Ehud Karni
       [not found]           ` <mailman.17838.1133698823.20277.help-gnu-emacs@gnu.org>
  2 siblings, 0 replies; 12+ messages in thread
From: Ehud Karni @ 2005-12-04 12:13 UTC (permalink / raw)
  Cc: help-gnu-emacs

On Thu, 01 Dec 2005 11:52:19 -0500, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> Yes, there is a very good one: you unnecessarily assume that the buffer
> starts at position 1.

Both `what-cursor-position' and `what-line' (in simple.el) do this
assumption. After looking in buffer.h and seeing:
    /* Position of beginning of buffer.  */
    #define BEG (1)
I don't see any reason NOT to assume this.

Ehud.


--
 Ehud Karni           Tel: +972-3-7966-561  /"\
 Mivtach - Simon      Fax: +972-3-7966-667  \ /  ASCII Ribbon Campaign
 Insurance agencies   (USA) voice mail and   X   Against   HTML   Mail
 http://www.mvs.co.il  FAX:  1-815-5509341  / \
 GnuPG: 98EA398D <http://www.keyserver.net/>    Better Safe Than Sorry

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: how do I know that the buffer is narrowed
       [not found]           ` <mailman.17838.1133698823.20277.help-gnu-emacs@gnu.org>
@ 2005-12-04 14:54             ` Stefan Monnier
  0 siblings, 0 replies; 12+ messages in thread
From: Stefan Monnier @ 2005-12-04 14:54 UTC (permalink / raw)


>> Yes, there is a very good one: you unnecessarily assume that the buffer
>> starts at position 1.

> Both `what-cursor-position' and `what-line' (in simple.el) do this
> assumption. After looking in buffer.h and seeing:
>     /* Position of beginning of buffer.  */
>     #define BEG (1)
> I don't see any reason NOT to assume this.

I didn't say it was a bad assumption. Just an unneeded one.
Code with fewer assumptions is generally better than a code with
more assumptions.  Especially when it's shorter and more efficient,
of course.


        Stefan "whose Emacs uses #define BEG (12345678)"

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2005-12-04 14:54 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <mailman.17354.1133368063.20277.help-gnu-emacs@gnu.org>
2005-11-30 22:10 ` how do I know that the buffer is narrowed Pascal Bourguignon
2005-11-30 22:41   ` Johan Bockgård
2005-11-30 23:10     ` David Kastrup
2005-12-01 11:31       ` Giorgos Keramidas
2005-12-01 12:12         ` David Kastrup
2005-12-01 12:44           ` Giorgos Keramidas
2005-12-01 16:52         ` Stefan Monnier
2005-12-01 18:41           ` Giorgos Keramidas
2005-12-04 12:13           ` Ehud Karni
     [not found]           ` <mailman.17838.1133698823.20277.help-gnu-emacs@gnu.org>
2005-12-04 14:54             ` Stefan Monnier
2005-11-30 16:27 mak kwak
2005-11-30 19:54 ` Kevin Rodgers

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.