emacs-pretest-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: flyspell + longlines: hang/wait


From: Ralf Angeli
Subject: Re: flyspell + longlines: hang/wait
Date: Sat, 29 Oct 2005 11:12:07 +0200
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux)

* David Reitter (2005-10-27) writes:

> On 27 Oct 2005, at 16:27, Ralf Angeli wrote:
>>>
>>> - I've been doing some work in Python lately. Python enforces strict
>>>   formatting, and you don't have the option of inserting a newline at
>>>   almost arbitrary (whitespace) positions like in C, for example.
>>
>> Of course there is such an option.  Just put a backslash in front of
>> the linebreak.  See
>> <URL:http://www.python.org/doc/2.4.2/ref/explicit-joining.html>.
>
> Sure, but that involves me assuming a fixed line length (that's where  
> I insert the line break, including the backslash).
> The next time I open the file in a frame with a different (smaller)  
> width, things get messy again.

If by "messy" you mean that you are getting continuation lines you
could set `truncate-lines' to t.  (That's probably how most IDEs
work.)  Because even if you had soft line-wrapping being done at white
space you would get messy results unless line-wrapping also handles
indentation as well as removal of hard newlines.  At least I would not
want C code which originally looked like

if (foo == bar)
  {
    foo = bar
      + baz;
  }

to be displayed like

if (foo ==
bar)
  {
    foo =
bar
      + baz;
  }

(Assuming the frame width is approximately 12 characters.)

I don't think that soft line-wrapping is generally suited for
programming languages.

>> Personally I think the longer text lines become the more readability
>> decreases.  So for me a 70-something character limit is desirable even
>> in a wide frame.
>
> Fair enough, that's your choice. And I wouldn't use very wide frames,  
> for that reason. But I use narrow ones.

I didn't exclude support for narrow frames.  But if soft line-wrapping
is introduced, it would be nice have a maximum line length that could
be set.

> People who use window managers with several windows concurrently on  
> the screen will probably more appreciate the problem at hand than  
> someone who uses Emacs in TTY, or within a basic window manager with  
> several desktop to switch between.

You can have (narrow) side-by-side windows in Emacs even on a TTY.

> I have a feeling that most people  
> in the development community use the latter (desktop switching comes  
> off the shelf on KDE, I think, and I've seen several GNU/Linux-to-Mac- 
> switchers install a switchable-desktop extension first thing).

A pity that Apple doesn't include this by default.

>> Anyway, keep in mind that the buffer size of TeX is limited.  And that
>> means the maximal line length which can be processed is limited as
>> well.  Depending on the value of the limit this can make problems if
>> you save your LaTeX files with long lines.
>
> This limit should be fairly high. TeXShop uses (visual) soft wrapping  
> and this app has tons of regular users. Apart from that, I guess it  
> should be up to the mode to enforce limits to line lengths if the  
> syntax / processors require that.

There is no practical way for the mode to figure out the maximum line
length because it may differ between TeX systems and the buffer is
used for macro expansion as well.  But the Emacs mode is not able to
figure out how long a line will be after macro expansion.

-- 
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]