John Q Splittist | 3 May 2005 19:30
Picon
Favicon

Pathnames and cl-fad

Wondering why the Find File completion was funky on my openmcl+clx 
climacs, and after a delightful tour through the mcclim completion code, 
I realised that it's because (directory ...) on openmcl requires 
:directories t to list directories.

I made a start on adding this to gui.lisp, but I've ended up just 
replicating a portion of cl-fad (http://www.weitz.de/cl-fad/). I should 
really have gone further and conditionalized wildcard as well, and then 
further back... Is there any benefit to adding cl-fad as a dependency, 
or just adding cl-fad to the climacs distribution? (Or does it really 
live at the McClim level?)

Anywho, a diff is attached. Not tested on all the lisps listed.

JQS

--- gui.lisp.~1.128.~	Sat Mar 19 22:08:31 2005
+++ gui.lisp	Tue May  3 18:13:47 2005
 <at>  <at>  -621,9 +623,17  <at>  <at> 
  	   (full-so-far (concatenate 'string directory-prefix so-far))
  	   (pathnames
  	    (loop with length = (length full-so-far)
-		  for path in (directory (concatenate 'string
-						       (remove-trail so-far)
-						      "*.*"))
+		  and wildcard = (concatenate 'string (remove-trail so-far) "*.*")
+		  for path in
+		   #+(or :sbcl :cmu :lispworks) (directory wildcard)
+		   #+:openmcl (directory wildcard :directories t)
+		   #+:allegro (directory wildcard :directories-are-files nil)
(Continue reading)

John Q Splittist | 3 May 2005 20:45
Picon
Favicon

Re: Pathnames and cl-fad

John Q Splittist wrote:
> Anywho, a diff is attached. Not tested on all the lisps listed.

And complete rubbish it is, being the product of an earlier cut-n-paste. 
Sorry about that. Try this one.

JQS

--- gui.lisp.~1.128.~	Sat Mar 19 22:08:31 2005
+++ gui.lisp	Tue May  3 19:43:44 2005
 <at>  <at>  -621,9 +625,15  <at>  <at> 
  	   (full-so-far (concatenate 'string directory-prefix so-far))
  	   (pathnames
  	    (loop with length = (length full-so-far)
-		  for path in (directory (concatenate 'string
-						       (remove-trail so-far)
-						      "*.*"))
+		  and wildcard = (concatenate 'string (remove-trail so-far) "*.*")
+		  for path in
+		   #+(or :sbcl :cmu :lispworks) (directory wildcard)
+		   #+:openmcl (directory wildcard :directories t)
+		   #+:allegro (directory wildcard :directories-are-files nil)
+		   #+:cormanlisp (nconc (directory wildcard)
+					(cl::directory-subdirs dirname))
+		   #-(or :sbcl :cmu :lispworks :openmcl :allegro :cormanlisp)
+		     (directory wildcard)
  		  when (let ((mismatch (mismatch (namestring path) full-so-far)))
  			 (or (null mismatch) (= mismatch length)))
  		    collect path))
(Continue reading)

John Q Splittist | 3 May 2005 20:47
Picon
Favicon

Line and column number display

More useless aesthetic fiddling (cf. my Isearch feedback code, in the 
moderator queue because I brilliantly managed to send it before my 
subscription verification): adding line and column numbers to the status 
display.

I've added 1 to the buffer-line-number return value, because a 
line-number of 0 seems wrong (and contrary to Emacs), but perhaps I've 
missed a trick here.

JQS

--- gui.lisp.~1.128.~	Sat Mar 19 22:08:31 2005
+++ gui.lisp	Tue May  3 19:43:44 2005
 <at>  <at>  -125,9 +125,13  <at>  <at> 
    (declare (ignore frame))
    (with-slots (climacs-pane) pane
       (let* ((buf (buffer climacs-pane))
-	    (name-info (format nil "   ~a   ~a   Syntax: ~a~a~a~a    ~a"
+	    (point-offset (offset (point climacs-pane)))
+	    (tab-width (tab-space-count (stream-default-view climacs-pane)))
+	    (name-info (format nil "   ~a   ~a ~10<(~a,~a)~>  Syntax: ~a~a~a~a 
    ~a"
  			       (if (needs-saving buf) "**" "--")
  			       (name buf)
+			       (1+ (buffer-line-number buf point-offset))
+			       (buffer-display-column buf point-offset tab-width)
  			       (name (syntax buf))
  			       (if (slot-value climacs-pane 'overwrite-mode)
  				   " Ovwrt"
(Continue reading)

Aleksandar Bakic | 3 May 2005 22:55
Picon
Favicon

Re: Line and column number display

> adding line and column numbers to the status display.

I'm afraid that this one has to wait until I make standard-buffer work faster
with lines and columns. (Something similar used to be there but was removed for
performance reasons.)

Regards,
Alex

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
John Q Splittist | 4 May 2005 09:38
Picon
Favicon

Point - buffer or pane? (plus syntax resetting)

Currently point is kept in the climacs-pane object. While this means one 
can have multiple panes on the same buffer with different points, it 
does mean that switching buffers in the same pane loses the point 
information, so point is always reset.

Below are some changes to pane.lisp that move point to the 
climacs-buffer object. This has the effect of _not_ resetting point when 
doing a com-switch-to-buffer. Of course, when you com-split-window-*, 
there is only one point for each of the panes, so the cursors follow one 
another. Interesting redisplay features can be observed.

Presumably the right thing to do is have one point (and mark, and 
perhaps other things - isearch, query-replace?) per buffer per pane. On 
a com-split-window the new pane could be given some kind of proxy 
climacs-buffer pointing to the original, but with its own state.

Or maybe I'm barking up the wrong tree.

Anyway, consider this a quick fix for the annoyance of losing one's 
place in a file when switching buffers.

Also, by commenting out lines in com-switch-to-buffer (in gui.lisp) as 
follows, a syntax reset can be avoided on c-x b as well:

(define-named-command com-switch-to-buffer ()
   (let ((buffer (accept 'buffer
			:prompt "Switch to buffer"))
	(pane (current-window)))
     (setf (buffer pane) buffer)
;    (setf (syntax buffer) (make-instance
(Continue reading)

John Q Splittist | 1 May 2005 19:41
Picon
Favicon

Isearch feedback

Hi,

To celebrate getting climacs to run (openmcl 0.14.3, clx) I had a go at 
adding some minibuffer feedback for the Isearch functions. A diff is 
attached.

Some questions:

1. Is this actually a useful thing for me to do?

2. Is this the right form of diff?

3. Is (display-message ..) the way to go for this kind of thing? (It 
almost seems too easy...)

Loading an edited gui file into a running climacs and seeing the changes 
instantly (or as close to instantly as climacs gets, these days) is very 
cool!

cheers,
JQS

--- gui.lisp.~1.128.~   Sat Mar 19 22:08:31 2005
+++ gui.lisp    Sun May  1 17:23:22 2005
 <at>  <at>  -1086,6 +1086,7  <at>  <at> 
                (offset mark) (if forwardp
                                  (- (offset mark2) (length string))
                                  (+ (offset mark2) (length string)))))
+      (display-message "~:[Failing ~;~]Isearch~:[ backward~;~]: ~A" 
success forwardp string)
(Continue reading)

Nicolas Sceaux | 4 May 2005 13:15
X-Face
Picon
Favicon

regex

Hello,

Some months ago, there was a discussion about adapting cl-ppcre for
use with climacs buffers iso. plain strings.

  http://common-lisp.net/pipermail/climacs-devel/2005-January/000077.html

I would like to know if maybe someone (Lawrence?) had got some
results, and eventually some advices to give, before putting my noze
inside the beast.

Writing lexers (ie, the NEXT-LEXEME method) is not exactly trivial
with complicated syntaxes; having something like emacs' looking-at
function might make that task a bit easier.

Regards,
Nicolas
Lawrence Mitchell | 4 May 2005 18:09
Picon

Re: regex

Hi there,

Nicolas Sceaux wrote:

> Hello,

> Some months ago, there was a discussion about adapting cl-ppcre for
> use with climacs buffers iso. plain strings.

>   http://common-lisp.net/pipermail/climacs-devel/2005-January/000077.html

> I would like to know if maybe someone (Lawrence?) had got some
> results, and eventually some advices to give, before putting my noze
> inside the beast.

I started looking at this, and then, unfortunately, real life
intervened, so I haven't had much of a chance to get things
working.

I had a very trivial proof-of-concept implementation that just
turned buffers into strings and then matched on them, obviously,
this is far from ideal.

After discussing alternatives here and with Edi, it seems like
the way forward is to modify cl-ppcre to change all occurances of
(SCHAR *STRING* ...) and the like in the sources to some function
that returns a character in a Climacs buffer.

That is, rather than doing (scan regex string) and then matching
in string, do (scan regex buffer) and somehow match in buffer.
(Continue reading)

Aleksandar Bakic | 5 May 2005 01:15
Picon
Favicon

Re: Point - buffer or pane? (plus syntax resetting)

Hi,

Sounds fine to me, but I need to check the archive first. I think there were
some discussions on where point and friends should belong. As for the syntax
reset, I am not familiar enough with syntax-related code to approve this change
at the moment.

Regarding your Isearch-related post:

> 1. Is this actually a useful thing for me to do?

My guess is that things like this are useful to other users, too. I'm not sure
if I understood the question.

> 2. Is this the right form of diff?

The form is probably fine, but the line numbers did not match, so I patched
gui.lisp manually.

> 3. Is (display-message ..) the way to go for this kind of thing? (It
almost seems too easy...)

I don't know, it seems to work. I saw similar uses of display-message, too.

Thanks,
Alex

		
__________________________________ 
Yahoo! Mail Mobile 
(Continue reading)

Nicolas Sceaux | 5 May 2005 12:09
X-Face
Picon
Favicon

Re: Re: regex

Lawrence Mitchell <wencel <at> gmail.com> writes:

> After discussing alternatives here and with Edi, it seems like
> the way forward is to modify cl-ppcre to change all occurances of
> (SCHAR *STRING* ...) and the like in the sources to some function
> that returns a character in a Climacs buffer.
>
> That is, rather than doing (scan regex string) and then matching
> in string, do (scan regex buffer) and somehow match in buffer.
> This is around the point that I got not much further.  I didn't
> manage to figure out a way to make this work nicely and didn't
> get round to figuring out what was wrong before other work
> intervened.
>
> Sorry not to have any better news really, I'll probably have more
> time come the end of May but won't really be able to look at
> things before that.  I can send you what I do have (non-working)
> so far if you're interested.

Yes please. I have a few ideas, and would like to see if you took the
same direction, or another path.

Gmane